Posts

引言 Prompt工程关注"如何写好一条提示"，而上下文工程关注"如何设计Agent的整个认知环境"。在2026年，随着Agent需要处理越来越复杂的任务，单条Prompt的优化已经触及天花板。上下文工程——系统性地设计Agent在每一步推理时看到什么信息、以什么顺序、什么格式——成为了新的性能提升杠杆。 一、什么是上下文工程 1.1 从Prompt到Context Prompt工程是上下文工程的子集。一条Prompt包含在上下文中，但上下文远不止Prompt： Agent上下文 = System Prompt + 用户消息 + 对话历史 + 工具描述 + 检索到的记忆 + 工具调用结果 + 环境状态 + 元指令 每个组成部分都需要精心设计，任何一个部分的质量问题都会影响Agent的整体表现。 1.2 上下文预算 上下文窗口是有限的资源。2026年主流模型的上下文窗口为128K-2M tokens，但"能用"和"用好"是两回事： 过长上下文导致注意力分散：模型对中间部分的信息关注不足（“lost in the middle"问题） 成本与长度正相关：每多1000 tokens的输入，就多一份成本 延迟与长度正相关：更长的上下文意味着更长的处理时间 因此，上下文工程的核心是：在有限的预算内，让每一条信息都发挥最大价值。 二、上下文组装策略 2.1 上下文分区 将上下文分为不同的功能区，每个区有明确的职责： ┌─────────────────────────────────────┐ │ System Prompt (固定区) │ ← 身份、能力、规则 ├─────────────────────────────────────┤ │ Tool Descriptions (工具区) │ ← 可用工具的描述 ├─────────────────────────────────────┤ │ Retrieved Memory (记忆区) │ ← 检索到的相关记忆 ├─────────────────────────────────────┤ │ Conversation History (对话区) │ ← 对话历史 ├─────────────────────────────────────┤ │ Current Input (输入区) │ ← 用户当前输入 ├─────────────────────────────────────┤ │ Instructions (指令区) │ ← 当前步骤的具体指令 └─────────────────────────────────────┘ 2.2 动态上下文组装 不同任务、不同阶段需要不同的上下文结构： ...

AIGC版权第一案：里程碑式的判决 2026年6月30日，最高人民法院对"李某诉某AI公司著作权侵权案"作出终审判决。这是中国首例AI生成内容版权案件终审判决，对AI产业的版权规则产生了深远影响。 案件的核心问题是：AI生成的内容是否享有版权？版权归谁所有？训练AI模型时使用受版权保护的作品是否构成侵权？ 案件背景 事实经过 原告李某是一名插画师，2025年4月，她发现某AI公司的图像生成平台上出现了与她作品风格高度相似的AI生成图片。经调查，该AI公司在训练模型时使用了李某发布在社交媒体上的200余幅插画作品，且未获得授权也未支付费用。 更关键的是，该平台在生成图片时可以明确指定"李某风格"作为生成提示词，生成的图片在构图、色彩、笔触等方面与李某的原作高度相似。 李某遂以著作权侵权为由，将AI公司诉至法院，要求停止侵权、赔偿损失500万元。 一审判决 2026年2月，某市中级人民法院一审判决： AI公司在训练中使用李某作品构成著作权侵权 AI生成图片不构成对李某特定作品的复制，不侵犯复制权 但"李某风格"作为生成选项，侵犯了李某的署名权 判令AI公司赔偿80万元 判令AI公司从训练数据中移除李某作品 双方均不服一审判决，向最高人民法院提起上诉。 终审判决要点 1. 训练数据使用构成侵权 最高人民法院认定，AI公司在未经授权的情况下，将李某的200余幅插画用于模型训练，构成对著作权人复制权和信息网络传播权的侵犯。 关键裁判理由： “将受著作权保护的作品用于AI模型训练，虽然不是传统意义上的’复制’，但实质上是对作品的数字化复制和利用。训练数据的使用不属于’合理使用’的法定情形，应当取得著作权人许可并支付合理报酬。” 这一认定意义重大——它明确了AI模型训练中使用受版权保护的作品需要获得授权。 2. AIGC可享有版权，但需满足条件 法院首次明确了AI生成内容的版权归属规则： “AI生成内容要获得著作权保护，必须体现人类的独创性表达。具体而言，用户需要对AI生成过程进行实质性的创造性控制，包括但不限于：精心设计提示词、对生成结果进行选择和修改、将AI生成内容融入自己的创作中。” 法院提出了"三要素测试法"来判断AIGC的版权性： 人类创意主导：人类是否提出了原创性的创意构想 过程控制：人类是否对AI生成过程进行了实质性的控制和选择 后期加工：人类是否对AI输出进行了有意义的编辑和修改 如果三个要素都满足，AI生成内容可以作为"人类作品"获得版权保护，版权归实际创作者所有。 3. “风格模仿"构成不正当竞争 关于"李某风格"作为生成选项的问题，法院认定： “虽然著作权法不保护创作风格本身，但将特定艺术家的姓名或风格作为AI生成的卖点进行宣传和商业化利用，构成不正当竞争行为。” 法院判令AI公司： 不得使用艺术家姓名作为生成选项 不得在宣传中暗示生成内容与特定艺术家的关联 赔偿李某经济损失120万元（较一审增加40万元） 4. 合理使用边界 法院对AI训练中的"合理使用"给出了指导性意见： “以下情形可能构成合理使用：（1）为科学研究目的使用少量作品；（2）使用的作品已经合法公开且不影响作品的正常使用；（3）使用方式不会不合理地损害著作权人的合法权益。但商业化的AI模型训练不属于合理使用。” 判决的产业影响 对AI训练的影响 这个判决将从根本上改变AI模型的训练方式： 影响1：训练数据合规成本大幅增加 AI公司需要： 获得训练数据的版权许可 建立数据版权追溯体系 向版权方支付合理费用 预计训练成本将增加15-30%。 影响2：数据授权市场兴起 判决催生了AI训练数据授权市场： Getty Images推出AI训练数据授权服务 中国音像著作权集体管理协会推出AI音乐数据授权 多家版权代理公司开始提供AI数据授权中间服务 影响3：合成数据重要性上升 为避免版权风险，AI公司开始大量使用合成数据： 用已有模型生成训练数据 使用公有领域的作品 与版权方合作创建授权数据集 对AIGC产业的影响 对AI绘画平台： ...

引言 Agent的很多操作是独立的——搜索三个不同的关键词、查询多个数据源、分析多个文件。如果串行执行，总时间是所有操作时间的总和；如果并发执行，总时间接近最慢操作的时间。 并发执行是Agent性能优化的重要手段。但并发带来了复杂性：资源竞争、状态同步、错误处理、死锁风险。2026年的Agent并发架构需要在性能和复杂性之间找到最佳平衡。 一、Agent并发场景 1.1 工具调用并发 一个请求需要调用多个独立工具时，可以并发执行： 串行: search_web(3s) → query_db(2s) → call_api(1s) = 6s 并发: search_web(3s) ─┐ query_db(2s) ─┼─ 并行 = 3s call_api(1s) ─┘ 1.2 多Agent并发 多个Agent同时处理不同子任务： 用户: "调研三家公司的市场表现" Agent A: 调研公司甲 ─┐ Agent B: 调研公司乙 ─┼─ 并行 Agent C: 调研公司丙 ─┘ 1.3 批量处理并发 对一批数据并行处理： 100个文档需要摘要 → 分成10批，每批10个文档 → 10个Worker并行处理 → 总时间 ≈ 单个文档的10倍（而非100倍） 1.4 竞争执行 同一任务由多个Agent竞争执行，取最优结果： Agent A → 方案A ─┐ Agent B → 方案B ─┼→ 评估器选择最优 Agent C → 方案C ─┘ 二、并发模型 2.1 异步IO模型 Agent的绝大多数操作是IO密集型（LLM API调用、工具调用），适合异步IO模型： ...

AI Agent应用商店：新平台的诞生 2026年6月，OpenAI、Google和Anthropic几乎同时宣布推出各自的AI Agent应用商店。加上微软的Copilot Agent Store和苹果的App Intents Marketplace，AI应用分发正在从"API调用"走向"应用商店"模式。 这种转变的意义堪比2008年Apple App Store的诞生——它将创造一个全新的AI应用生态系统，改变AI能力的分发和商业化方式。 五大Agent应用商店对比 平台 运营方 上线时间 Agent数量(首月) 分成比例 特点 GPT Store OpenAI 2026.6 12,000+ 30% 最大生态 Gemini Agent Hub Google 2026.6 8,000+ 25% 多模态优势 Claude Agent Market Anthropic 2026.7 5,000+ 20% 企业级 Copilot Agent Store Microsoft 2026.5 15,000+ 30% Office集成 App Intents Market Apple 2026.9(预计) N/A 30% 端侧运行 OpenAI GPT Store详解 平台架构 GPT Store是OpenAI推出的Agent分发平台，开发者可以发布自定义的GPT Agent，用户可以浏览、安装和使用这些Agent： 开发者侧： 创建Agent → 定义工具 → 设置权限 → 发布到GPT Store 用户侧： 浏览Agent → 查看评价 → 一键安装 → 即时使用 商业化： 免费Agent / 订阅制 / 按次付费 / 按使用量计费 热门Agent分类 工作效率类（35%）： ...

引言 在理想世界中，Agent的每个请求都能得到完美处理。但现实是，LLM API会限流、工具会超时、外部服务会宕机。当主路径不可用时，Agent需要有备选方案——这就是降级链（Fallback Chain）。 降级链的设计哲学是"逐步退化"——不是在失败时直接报错，而是尝试一系列替代方案，每一步都比上一步弱一些但仍然能提供价值。就像人类的处理方式：想不起来精确答案时，先给个近似答案；近似答案也没有时，至少给个方向。 一、降级链的核心原则 1.1 逐步退化 完美结果 → 良好结果 → 可用结果 → 基本结果 → 优雅失败 每一步降级都是可控的、有意的，而不是崩溃式的。 1.2 价值保留 每一步降级都应尽可能保留核心价值。用户问"帮我分析这份数据"，如果AI分析不可用，至少展示原始数据；如果展示也不行，至少告知用户数据已收到、稍后处理。 1.3 透明告知 降级时应告知用户当前状态，而不是假装一切正常： "由于实时数据服务暂时不可用，以下分析基于最近缓存数据（更新于5分钟前）。" 1.4 可观测 每次降级都应该被记录和监控，用于发现系统性问题。 二、LLM降级链 2.1 模型降级链 GPT-4o / Claude Opus → GPT-4o-mini / Claude Sonnet → GPT-3.5 / Claude Haiku → 规则引擎 第一级：最强模型，提供最佳质量 第二级：中等模型，质量略降但更快更便宜 第三级：轻量模型，保证基本功能 第四级：规则引擎，不依赖LLM 2.2 降级触发条件 class LLMFallbackChain: def __init__(self): self.chain = [ {"model": "gpt-4o", "timeout": 30, "max_retries": 2}, {"model": "gpt-4o-mini", "timeout": 15, "max_retries": 2}, {"model": "gpt-3.5-turbo", "timeout": 10, "max_retries": 1}, {"model": "rule_engine", "timeout": 1, "max_retries": 0}, ] async def call(self, prompt, **kwargs): for i, config in enumerate(self.chain): try: if config["model"] == "rule_engine": return await self.rule_engine_fallback(prompt) result = await self.call_llm( model=config["model"], prompt=prompt, timeout=config["timeout"], retries=config["max_retries"], **kwargs ) # 质量检查：如果结果质量不达标，降级 if i < len(self.chain) - 1 and not self.quality_check(result): logger.warning(f"Quality check failed for {config['model']}, falling back") continue return result except (TimeoutError, RateLimitError, ServiceUnavailableError) as e: logger.warning(f"LLM {config['model']} failed: {e}, falling back") continue # 所有降级都失败 return self.graceful_failure(prompt) 2.3 质量降级 不只是模型级别的降级，还可以在功能级别降级： ...

ERNIE 5.0：百度的多模态推理之跃 2026年5月，百度在百度AI开发者大会上发布文心一言5.0（ERNIE 5.0）。与4.0版本相比，5.0最大的突破在多模态推理——不仅能看懂图片，还能对图片进行逻辑推理、数学计算和科学分析。 百度CTO王海峰在发布会上演示了一个场景：给ERNIE 5.0看一张物理实验照片，它不仅能识别实验器材，还能推导实验原理、计算物理量、预测实验结果。这种"看图推理"能力标志着多模态AI从"感知"走向了"认知"。 模型架构 统一多模态架构 ERNIE 5.0采用了"统一多模态"架构，与之前"语言模型+视觉编码器"的拼接方案有本质区别： 输入模态 → 统一Token化 → 共享Transformer主干 → 统一输出 关键设计： 1. 多模态统一Token化 文本：BPE分词 图像：动态分辨率Patch（最高4096x4096） 音频：WavLM特征 + 线性投影 视频：每帧图像Patch + 时序位置编码 表格：结构化序列编码 2. 视觉推理增强 ERNIE 5.0在Transformer主干中加入了"视觉推理模块"（VRM）： class VisualReasoningModule(nn.Module): """ 在标准自注意力之上增加空间推理能力 """ def __init__(self, config): super().__init__() self.spatial_attention = SpatialAttention( num_heads=16, num_spatial_scales=4 # 多尺度空间注意力 ) self.relation_extractor = RelationExtractor( hidden_size=config.hidden_size, num_relation_types=128 # 空间关系类型 ) self.logic_units = LogicUnits( hidden_size=config.hidden_size, operations=["count", "compare", "deduce", "calculate"] ) def forward(self, image_tokens, text_tokens): # 1. 空间注意力：理解图像中的空间关系 spatial_features = self.spatial_attention(image_tokens) # 2. 关系提取：识别物体之间的关系 relations = self.relation_extractor(spatial_features) # 3. 逻辑推理：基于关系进行推理 reasoning_output = self.logic_units(relations, text_tokens) return reasoning_output 这种设计使得ERNIE 5.0能够进行： ...

引言 在Agent系统中，失败是常态。LLM API超时、工具调用失败、网络波动——这些故障随时会发生。如何处理这些失败，决定了系统的可靠性。 重试是最直接的容错手段，但"盲目重试"——不分析原因、不调整策略地反复重试——不仅浪费资源，还可能加剧问题。2026年的Agent系统需要的是"智能重试"——根据故障类型、上下文和历史数据做出最优的重试决策。 一、何时应该重试 1.1 可重试错误 vs 不可重试错误 可重试错误： 网络超时 服务暂时不可用（503） 速率限制（429） 临时性数据冲突 不可重试错误： 参数错误（400） 认证失败（401/403） 资源不存在（404） 业务逻辑错误（如"余额不足"） 1.2 判断框架 def should_retry(error, attempt_count, context): # 不可重试错误直接返回False if error.type in NON_RETRYABLE_ERRORS: return False # 超过最大重试次数 if attempt_count >= context.max_retries: return False # 速率限制：可以重试，但需要等待 if error.type == "rate_limit": wait_time = error.retry_after or calculate_backoff(attempt_count) return True, wait_time # 网络超时：检查是否值得重试 if error.type == "timeout": if context.estimated_remaining_time > context.deadline: return False # 重试也无法在截止时间内完成 return True, calculate_backoff(attempt_count) # 服务不可用：重试 if error.type == "service_unavailable": return True, calculate_backoff(attempt_count) # 未知错误：保守重试 return True, calculate_backoff(attempt_count) 二、退避算法 2.1 固定间隔 每次重试间隔相同时间。简单但可能造成"重试风暴"——所有失败请求同时重试。 2.2 指数退避 每次重试间隔按指数增长： Retry 1: wait 1s Retry 2: wait 2s Retry 3: wait 4s Retry 4: wait 8s Retry 5: wait 16s def exponential_backoff(attempt, base=1, factor=2, max_delay=60): delay = min(base * (factor ** attempt), max_delay) return delay 指数退避是最常用的策略，有效避免重试风暴。 ...

通义千问3企业版：阿里云的AI生态战略 2026年6月，阿里云在云栖大会2026上发布了通义千问3企业版（Qwen3 Enterprise）。与消费级版本不同，企业版专注于私有部署、行业适配和开源生态建设——阿里云正在用"开源+企业服务"的双轮驱动策略，构建中国最大的AI生态。 模型规格 企业版模型矩阵 Qwen3 Enterprise不是单一模型，而是一个模型矩阵： 模型 参数量 激活参数 上下文 定位 Qwen3-Ent-72B 72B (Dense) 72B 128K 通用企业级 Qwen3-Ent-MoE-110B 110B 18B 256K 高性价比 Qwen3-Ent-MoE-320B 320B 35B 1M 旗舰版 Qwen3-Ent-VL-72B 72B + ViT 72B 128K 多模态 Qwen3-Ent-Coder-32B 32B 32B 128K 代码专用 企业可以根据自身需求选择不同规格。所有模型都支持私有部署，并提供完整的微调工具链。 技术架构 旗舰版Qwen3-Ent-MoE-320B的关键设计： qwen3_enterprise_config = { # MoE配置 "num_experts": 48, "experts_per_token": 5, "router_type": "noisy_top_k_gating", "load_balancing_loss": 0.01, # 注意力 "num_layers": 64, "hidden_size": 12288, "num_attention_heads": 96, "num_kv_heads": 8, # GQA 12:1 "head_dim": 128, # 上下文 "max_position_embeddings": 1048576, # 1M "rope_type": "dynamic_ntk", "rope_base": 1000000, # 词表 "vocab_size": 152000, # 中文优化 # 量化支持 "supported_precisions": ["fp16", "bf16", "int8", "int4"], "kv_cache_quantization": ["fp8", "int4"], } 开源策略 Qwen3的开源策略是其最大亮点： ...

引言 LLM推理是昂贵的——每次调用消耗Token、产生延迟、花费金钱。在Agent系统中，大量请求其实是重复的或高度相似的。缓存是解决这个问题的最有效手段。 一个设计良好的缓存架构可以将LLM调用减少60-80%，将响应延迟降低一个数量级，将运行成本压缩到原来的几分之一。2026年，缓存已经成为Agent系统的标配组件。 一、Agent缓存的多层模型 1.1 L1：响应缓存 缓存完整请求-响应对。当完全相同的请求再次出现时，直接返回缓存结果。 Request: "总结这篇文章" + article_content (hash: a1b2c3) Cache Hit → Return cached summary Cache Miss → Call LLM → Cache result → Return 适用场景：用户重复提问、模板化任务。 注意事项：必须对请求进行标准化处理——“总结这篇"和"帮我总结这篇"应该命中同一缓存。使用请求的语义哈希而非原始字符串作为缓存键。 1.2 L2：前缀缓存 LLM推理中，请求的前缀部分如果与之前请求相同，可以复用已计算的KV Cache。这在多轮对话中特别有效。 对话第1轮: [System Prompt + User Msg 1] → 生成回复1 对话第2轮: [System Prompt + User Msg 1 + Reply 1 + User Msg 2] ↑ 前缀相同，可复用KV Cache 2026年主流推理框架（vLLM、SGLang）都已支持前缀缓存，命中率通常在70%以上。 1.3 L3：语义缓存 即使请求不完全相同，只要语义相似就命中缓存。通过embedding计算请求的向量表示，与缓存中的请求向量比较相似度。 def semantic_cache_lookup(query, cache, threshold=0.95): query_embedding = embed(query) for cached_query, cached_response, cached_embedding in cache: similarity = cosine_similarity(query_embedding, cached_embedding) if similarity > threshold: return cached_response return None 适用场景：用户用不同措辞问同一个问题。 ...

Seed 3.0：字节跳动的AI野心 2026年6月，字节跳动在火山引擎FORCE大会上正式发布Seed 3.0大模型。在中文NLP基准测试C-Eval、CMMLU和AlignBench上，Seed 3.0全面超越了GPT-6、Claude 5和Gemini 3 Ultra，成为中文能力最强的大模型。 这是中国AI公司首次在中文综合能力上全面登顶。对于一直在大模型领域默默投入的字节跳动来说，Seed 3.0是一个里程碑式的成果。 模型规格 架构设计 Seed 3.0的技术报告显示，它采用了MoE架构： 规格 Seed 3.0 Seed 2.0 总参数 520B 180B 激活参数 65B 40B 专家数 64 16 激活专家 6 4 层数 80 64 隐藏维度 14336 8192 注意力头 112 (GQA 14 KV) 80 (GQA 10 KV) 上下文长度 1M 256K 词表大小 150K（中文优化） 100K Seed 3.0的词表从100K扩展到150K，新增的50K主要覆盖中文字词、成语、专业术语和emoji。更大的中文词表意味着中文token的压缩比更高——同样的中文文本，Seed 3.0的token数比GPT-6少约30%，这直接降低了推理成本。 训练数据 字节在技术报告中披露了训练数据的构成： 中文网页：35T tokens（高质量过滤后） 英文网页：45T tokens 代码：15T tokens 学术文献：12T tokens（中文3T + 英文9T） 多模态数据：20T tokens 合成数据：18T tokens 其他语言：5T tokens 总计：约150T tokens 中文数据占比超过30%，这是Seed 3.0中文能力领先的数据基础。作为对比，GPT-6的中文数据占比估计不到10%。 ...