Loading...
正在加载...
请稍候

Context Engineering 2.0

✨步子哥 (steper) 2025年11月28日 04:00
<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Context Engineering 2.0: The Context of Context Engineering</title> <link href="https://fonts.googleapis.com/icon?family=Material+Icons" rel="stylesheet"> <link href="https://fonts.googleapis.com/css2?family=Futura:wght@400;500;700&display=swap" rel="stylesheet"> <style> <span class="mention-invalid">@font</span>-face { font-family: 'DingTalk JinBuTi'; src: local('DingTalk JinBuTi'); } <span class="mention-invalid">@font</span>-face { font-family: 'HarmonyOS Sans SC'; src: local('HarmonyOS Sans SC'); } <span class="mention-invalid">@font</span>-face { font-family: 'PingFang HK'; src: local('PingFang HK'); } * { margin: 0; padding: 0; box-sizing: border-box; } body { font-family: 'HarmonyOS Sans SC', sans-serif; background: linear-gradient(135deg, #1a237e, #4a148c); color: #ffffff; line-height: 1.6; } .poster { width: 720px; min-height: 1334px; margin: 0 auto; padding: 40px; position: relative; overflow: hidden; background: linear-gradient(135deg, #1a237e, #4a148c); } .background-shapes { position: absolute; top: 0; left: 0; width: 100%; height: 100%; z-index: 0; opacity: 0.1; } .shape { position: absolute; border-radius: 50%; background: rgba(255, 255, 255, 0.1); } .shape-1 { width: 300px; height: 300px; top: -100px; right: -100px; } .shape-2 { width: 200px; height: 200px; bottom: 100px; left: -50px; } .shape-3 { width: 150px; height: 150px; top: 40%; right: -50px; } .grid-texture { position: absolute; top: 0; left: 0; width: 100%; height: 100%; background-image: linear-gradient(rgba(255, 255, 255, 0.05) 1px, transparent 1px), linear-gradient(90deg, rgba(255, 255, 255, 0.05) 1px, transparent 1px); background-size: 20px 20px; z-index: 0; } .content { position: relative; z-index: 1; } .header { text-align: center; margin-bottom: 30px; padding-bottom: 20px; border-bottom: 2px solid rgba(255, 255, 255, 0.2); } .title { font-family: 'DingTalk JinBuTi', sans-serif; font-size: 40px; font-weight: bold; letter-spacing: -1px; margin-bottom: 10px; background: linear-gradient(90deg, #64b5f6, #e1bee7); -webkit-background-clip: text; background-clip: text; color: transparent; text-shadow: 0px 2px 5px rgba(0, 0, 0, 0.2); } .subtitle { font-family: 'DingTalk JinBuTi', sans-serif; font-size: 24px; margin-bottom: 15px; color: #bbdefb; } .definition { font-size: 18px; color: #e1f5fe; max-width: 90%; margin: 0 auto; } .section { margin-bottom: 30px; background: rgba(255, 255, 255, 0.1); border-radius: 16px; padding: 20px; backdrop-filter: blur(5px); box-shadow: 0 4px 15px rgba(0, 0, 0, 0.1); } .section-title { font-family: 'DingTalk JinBuTi', sans-serif; font-size: 24px; margin-bottom: 15px; color: #bbdefb; display: flex; align-items: center; } .section-title .material-icons { margin-right: 10px; font-size: 28px; } .timeline { margin-left: 10px; } .timeline-item { margin-bottom: 12px; position: relative; padding-left: 25px; } .timeline-item:before { content: ""; position: absolute; left: 0; top: 8px; width: 10px; height: 10px; border-radius: 50%; background: #64b5f6; } .timeline-year { font-family: 'Futura', 'PingFang HK', sans-serif; font-weight: bold; color: #e1bee7; margin-right: 5px; } .formula { text-align: center; font-family: 'Futura', 'PingFang HK', sans-serif; font-size: 22px; margin: 15px 0; padding: 10px; background: rgba(255, 255, 255, 0.1); border-radius: 8px; } .formula-highlight { color: #ffecb3; font-weight: bold; } .comparison { display: flex; justify-content: space-between; margin-top: 15px; } .comparison-column { width: 48%; background: rgba(255, 255, 255, 0.05); border-radius: 8px; padding: 15px; } .comparison-title { font-weight: bold; margin-bottom: 10px; color: #e1bee7; text-align: center; } .comparison-item { margin-bottom: 8px; display: flex; align-items: flex-start; } .comparison-item .material-icons { font-size: 18px; margin-right: 5px; color: #64b5f6; } .example { margin-top: 15px; padding: 10px; background: rgba(255, 255, 255, 0.05); border-radius: 8px; font-style: italic; } .self-baking { margin-top: 15px; } .self-baking-comparison { display: flex; justify-content: space-between; margin-top: 10px; } .self-baking-item { width: 48%; padding: 10px; background: rgba(255, 255, 255, 0.05); border-radius: 8px; } .self-baking-title { font-weight: bold; margin-bottom: 5px; color: #e1bee7; } .conclusion { margin-top: 15px; padding: 10px; background: rgba(255, 255, 255, 0.05); border-radius: 8px; border-left: 3px solid #e1bee7; } .resources { text-align: center; margin-top: 30px; padding: 15px; background: rgba(255, 255, 255, 0.1); border-radius: 16px; } .resource-title { font-family: 'DingTalk JinBuTi', sans-serif; font-size: 20px; margin-bottom: 10px; color: #bbdefb; } .resource-links { display: flex; justify-content: center; flex-wrap: wrap; } .resource-link { margin: 5px 10px; color: #e1f5fe; text-decoration: none; display: flex; align-items: center; } .resource-link .material-icons { margin-right: 5px; font-size: 18px; } .highlight { background: linear-gradient(transparent 60%, rgba(224, 247, 250, 0.3) 40%); padding: 0 2px; } .card-container { display: flex; flex-wrap: wrap; gap: 20px; justify-content: space-between; } .card { flex: 1 1 calc(50% - 10px); min-width: 280px; background: rgba(255, 255, 255, 0.1); border-radius: 16px; padding: 20px; backdrop-filter: blur(5px); box-shadow: 0 4px 15px rgba(0, 0, 0, 0.1); } </style> </head> <body> <div class="poster"> <div class="background-shapes"> <div class="shape shape-1"></div> <div class="shape shape-2"></div> <div class="shape shape-3"></div> <div class="grid-texture"></div> </div> <div class="content"> <header class="header"> <h1 class="title">Context Engineering 2.0</h1> <h2 class="subtitle">The Context of Context Engineering</h2> <p class="definition">从上下文感知到上下文协作的30年演进 — Context Engineering是一个熵减少过程,旨在弥合人类与机器之间的认知鸿沟</p> </header> <div class="card-container"> <div class="card"> <h3 class="section-title"> <span class="material-icons">history</span> 30年演进历程 </h3> <div class="timeline"> <div class="timeline-item"> <span class="timeline-year">1994年:</span>Bill Schilit首次提出"context-aware computing"概念 </div> <div class="timeline-item"> <span class="timeline-year">2000年:</span>Anind Dey团队开发Context Toolkit框架 </div> <div class="timeline-item"> <span class="timeline-year">2001年:</span>Anind Dey给出至今仍被广泛引用的定义 </div> <div class="timeline-item"> <span class="timeline-year">Era 1.0:</span>上下文感知(Context-Aware)- 机器像婴儿,只能吃米糊(结构化数据) </div> <div class="timeline-item"> <span class="timeline-year">Era 2.0:</span>上下文协作(Context-Cooperative)- 机器像成年人,可以直接吃牛排(原始信息) </div> </div> </div> <div class="card"> <h3 class="section-title"> <span class="material-icons">psychology</span> 认知鸿沟(Cognitive Gap) </h3> <p><span class="highlight">认知鸿沟 = 人类的上下文处理能力 - 机器的上下文处理能力</span></p> <p>Context Engineering通过收集、管理和使用上下文信息,将高熵的人类意图和环境状态,预处理为机器可理解的低熵表示。</p> <div class="formula"> Context Engineering = <span class="formula-highlight">熵减少过程</span> </div> </div> </div> <div class="section"> <h3 class="section-title"> <span class="material-icons">architecture</span> Context Engineering系统化框架 </h3> <div class="formula"> Context Engineering = <span class="formula-highlight">Collection</span> × <span class="formula-highlight">Management</span> × <span class="formula-highlight">Usage</span> </div> <div class="card-container"> <div class="card"> <h4 class="comparison-title">Collection(收集)</h4> <p>如何收集上下文(从单一传感器到多模态融合)</p> <ul> <li>感知升级:从单一传感器到多模态融合</li> <li>环境感知:位置、身份、活动等</li> </ul> </div> <div class="card"> <h4 class="comparison-title">Management(管理)</h4> <p>如何管理上下文</p> <ul> <li>分层记忆架构:短期记忆与长期记忆</li> <li>子代理隔离上下文:Claude Code创建子代理执行独立任务</li> <li>轻量引用:不把大文件塞进上下文,而是存到外部,只放"指针"</li> </ul> </div> <div class="card"> <h4 class="comparison-title">Usage(使用)</h4> <p>如何使用上下文</p> <ul> <li>从「被动响应」到「主动协作」</li> <li>高熵上下文消费能力提升:从「只吃精加工食品」到「能消化原材料」</li> </ul> </div> </div> </div> <div class="card-container"> <div class="card"> <h3 class="section-title"> <span class="material-icons">compare_arrows</span> 从感知到协作的飞跃 </h3> <div class="comparison"> <div class="comparison-column"> <div class="comparison-title">Era 1.0</div> <div class="comparison-item"> <span class="material-icons">arrow_right</span> <span>被动响应</span> </div> <div class="comparison-item"> <span class="material-icons">arrow_right</span> <span>只能处理结构化数据</span> </div> <div class="comparison-item"> <span class="material-icons">arrow_right</span> <span>单一传感器</span> </div> </div> <div class="comparison-column"> <div class="comparison-title">Era 2.0</div> <div class="comparison-item"> <span class="material-icons">arrow_right</span> <span>主动协作</span> </div> <div class="comparison-item"> <span class="material-icons">arrow_right</span> <span>能处理原始信息</span> </div> <div class="comparison-item"> <span class="material-icons">arrow_right</span> <span>多模态融合</span> </div> </div> </div> <div class="example"> Era 2.0系统是协作式的:你在写论文→系统分析你的写作进度→发现你卡在第三章→主动建议:"要不要我帮你梳理一下逻辑?"→你同意→它生成大纲→你修改→它根据反馈调整 </div> </div> <div class="card"> <h3 class="section-title"> <span class="material-icons">auto_awesome</span> Self-Baking:从量变到质变 </h3> <p>Self-Baking的本质是把「存储」和「学习」分开</p> <div class="self-baking-comparison"> <div class="self-baking-item"> <div class="self-baking-title">没有Self-Baking</div> <p>AI只会回忆("你上次说了什么?")</p> </div> <div class="self-baking-item"> <div class="self-baking-title">有了Self-Baking</div> <p>AI可以积累知识("我知道你喜欢什么")</p> </div> </div> <div class="conclusion"> 这是从「工具」到「伙伴」的分水岭,上下文工程需要从量变到质变,核心总结应融合到模型参数里 </div> </div> </div> <div class="resources"> <h3 class="resource-title">相关资源</h3> <div class="resource-links"> <a href="https://github.com/GAIR-NLP/Context-Engineering-2.0" class="resource-link"> <span class="material-icons">code</span> GitHub </a> <a href="https://arxiv.org/pdf/2510.26493" class="resource-link"> <span class="material-icons">description</span> PDF </a> <a href="https://pan.quark.cn/s/52ad1ae833a7" class="resource-link"> <span class="material-icons">slideshow</span> PPT </a> </div> </div> </div> </div> </body> </html>

讨论回复

2 条回复
✨步子哥 (steper) #1
11-28 04:02
https://github.com/GAIR-NLP/Context-Engineering-2.0
✨步子哥 (steper) #2
11-28 04:52
# 《思维的宫殿:当AI学会设计自己的记忆》 ## 🎭 序章:思想的囚笼与自由之路 想象一下,你是一位博学多才的学者,却患上了一种奇怪的病症:你的短期记忆只能维持五分钟。每过三百秒,世界就会重置一次——你读过的小说自动翻回第一页,未完成的棋局凭空消失,连刚刚与你促膝长谈的朋友都变得陌生。这听起来像是科幻电影《记忆碎片》的桥段,却是当今绝大多数AI系统面临的根本性困境。 大型语言模型(LLMs)正是这样一位"数字健忘症患者"。它们能在一瞬间消化整本《战争与和平》,却在对话中忘记三分钟前你提到的关键细节。这种悖论源于一个简单却残酷的事实:**LLMs只能"看见"位于其上下文窗口内的信息**。就像一个拥有超强大脑的囚徒,被关在一间窗户不断缩小的牢房里——窗户越大,能看到的风景越多,但窗外的世界始终比窗户本身广阔百倍。 2025年,随着Claude、GPT等模型上下文窗口突破200K_token大关,业界曾欢呼"记忆危机"已成往事。然而,Letta的研究团队通过一个形象的比喻戳破了这种幻觉:给囚犯一面更大的窗户,不等于给了他自由行走的权利。**Context Engineering(上下文工程)** 正是那把打开牢笼的钥匙——它不仅关乎窗户的大小,更关乎**如何设计这扇窗、如何管理窗外的风景、如何让AI学会自己推开窗户**。 > **注解**:所谓"上下文窗口",指LLM在一次推理中能处理的最大token数量。尽管现代模型支持超长上下文,但研究表明信息检索准确率随上下文长度增加而衰减,这种现象被称为"context rot"(上下文腐烂)。就像人类在嘈杂派对中难以听清远处对话,LLM在冗长上下文中也会"失焦"。 ## 🧬 第一章:记忆宫殿的基石——Memory Blocks的创世纪 ### 从MemGPT到Letta:自我编辑记忆的觉醒 故事的起点要追溯到2023年那个改变游戏规则的论文——《MemGPT: Towards LLMs as Operating Systems》。研究者们提出一个激进的想法:**如果LLM不仅能使用工具,还能像操作系统管理内存一样管理自己的上下文,会怎样?** 这个想法如同在AI世界投下了一枚深水炸弹,催生了记忆管理的"操作系统范式"。 MemGPT的灵感来自古老的心理学技巧——记忆宫殿。想象一下,你走进一座宏伟的宫殿,每个房间都存放着特定类别的记忆:东翼的"人类厅"挂满与你对话者的画像,西翼的"人格阁"陈列着AI自身的性格特质。这些房间不是冰冷的仓库,而是**可编辑、可持久化、可共享的活态记忆单元**。 Letta将这个抽象概念转化为具体实现:**Memory Blocks(记忆块)**。每个记忆块包含四个要素: - **标签(Label)**:房间的名称牌,如"human"、"persona"、"knowledge" - **值(Value)**:房间内实际存放的字符串数据 - **大小限制(Limit)**:房间的最大容量,防止某个记忆膨胀占据整个宫殿 - **描述(Description)**:导游手册,指导AI如何正确使用这个房间 这看似简单,却解决了困扰AI界多年的核心矛盾:**如何在有限的上下文窗口中,为最重要的信息保留永久席位?** > **注解**:Memory Blocks的本质是上下文窗口的"配额制"。就像交响乐团中每个声部都有固定席位,不能任由小提琴手占据整个舞台。Letta的数据显示,使用记忆块的代理在跨会话一致性上提升了3.2倍,因为它们不再依赖易逝的短期记忆。 ### 双重人格的哲学实验 MemGPT最初的演示如同一场精妙的哲学实验。它创建了两个记忆块:"human"块存储用户偏好和事实,"persona"块维护AI的自我概念。当用户问"你喜欢什么口味的冰淇淋?"时,AI不会机械地回答"作为AI我没有味觉",而是查阅自己的"人格阁",发现之前记录的偏好是香草味,于是给出一致且富有个性的回答。 这种自我编辑能力催生了 **"学习型代理"(Stateful Agents)** 的概念——AI不再是训练后静止不变的雕像,而是能在部署阶段持续学习、适应的活体系统。Letta的工程师们进一步拓展了这个理念:记忆块可以是只读的(由开发者预设),也可以是读写的(由AI自主管理);可以被单个代理独占,也可以在多个代理间共享。 想象一下,一群研究助理代理共享同一个"知识库"记忆块,背景代理在空闲时处理文档并更新共享记忆,主代理在需要时直接调取精炼后的洞察。这不正是人类团队协作的数字化镜像吗? ## 🏛️ 第二章:Context Engineering——为AI设计思维宫殿 ### 操作系统的隐喻:当LLM遇见Linux 如果Memory Blocks是房间的钥匙,**Context Engineering(上下文工程)** 就是整座宫殿的建筑蓝图。Letta团队提出了一个极具洞察力的类比:**将AI框架视为"LLM操作系统"(LLM OS)**。就像Linux管理CPU和内存,LLM OS管理上下文窗口这一核心资源。 在这个架构中,上下文被划分为两个空间: - **内核空间(Kernel Context)**:受管理的内存,包括系统提示、工具定义、Memory Blocks和文件,只能通过API和工具调用修改 - **用户空间(User Context)**:消息缓冲区,包含用户输入、助手回复和工具调用日志 这种分层设计让代理获得了一种超能力:**系统调用接口**。当代理需要修改自身记忆时,它不直接操作原始文本,而是调用`memory_replace`、`memory_append`等"系统调用"。这就像人类不会因为想记住一件事而直接修改大脑神经元,而是通过反复回忆和复述来强化记忆。 > **注解**:Context Engineering的核心矛盾在于"注意力预算"(Attention Budget)。Transformer架构的n²复杂度意味着每增加一个token,模型需要处理的token间关系呈平方级增长。正如人类工作记忆容量有限,LLM的"注意力"也是稀缺资源。Context Engineering的目标不是塞满上下文,而是**让模型在最需要时看到最相关的信息**。 ### JIT检索:即时满足的智慧 传统RAG(检索增强生成)如同去图书馆前必须提前列好书单——你需要预知所有可能需要的信息。而**JIT(Just-In-Time)检索**则像一位随叫随到的研究助理:代理在推理过程中实时决定需要哪些信息,通过工具动态加载。 Anthropic的Claude Code是JIT检索的典范。面对一个包含百万行代码的代码库,它不会一次性加载所有文件,而是: 1. 使用`glob`工具扫描目录结构 2. 用`grep`快速定位关键代码片段 3. 通过`head`和`tail`按需加载文件片段 4. 将关键发现写入`CLAUDE.md`笔记文件 这种策略将**上下文视为可探索的环境而非静态容器**。文件系统成为外部记忆,文件夹结构提供语义线索,命名约定暗示用途,时间戳提示相关性。代理像人类研究员一样,在信息迷宫中留下面包屑标记,逐步构建对复杂系统的理解。 但JIT检索并非万能药。Letta团队警告:对于静态内容(如法律文档),预检索可能更高效;对于动态任务(如代码分析),JIT更灵活。未来的最佳实践将是**混合策略**:预加载核心上下文,运行时动态扩展。 ## 🤖 第三章:单代理 vs 多代理——数字文明的协作困境 ### 分裂的共识:当代理遇见代理 2025年6月,Cognition的Walden Yan发表了一篇引发轩然大波的文章——《Don’t Build Multi-Agents》。文章指出,当前流行的多代理架构(如OpenAI的Swarm、Microsoft的AutoGen)本质上是**把复杂系统的不稳定性外包给多个LLM实例**。这就像让十个健忘症患者组成委员会——不仅没人记得会议纪要,还可能因为沟通不畅做出矛盾决策。 Walden提出了两条"上下文工程铁律": 1. **共享完整上下文**:每个代理决策都应基于系统所有相关决策的上下文 2. **行动携带隐式决策**:冲突的决策导致糟糕结果 想象你让三个子代理分别开发Flappy Bird游戏的背景、小鸟和物理引擎。子代理1误解任务,开始制作马里奥风格背景;子代理2生成的小鸟与背景视觉风格完全不搭;最终整合代理面对风格迥异的组件束手无策。即使强制共享原始任务描述,子代理们在平行工作中形成的**隐式设计决策**(如色彩方案、艺术风格)仍会冲突。 > **注解**:多代理系统的根本问题在于"沟通带宽"。人类通过高效的非语言沟通(手势、表情、默契)解决冲突,但LLM代理只能通过文本传递信息,导致**上下文稀释**(Context Dilution)。每个代理只看到自己的局部上下文,丢失了全局一致性。 ### 单代理的优雅:线性叙事的魅力 Cognition建议的解决方案出人意料地简单:**单线程线性代理**。一个代理,一条上下文链,完整的历史记录。这避免了决策分散,确保每个行动都基于全局上下文。对于长上下文任务,引入**上下文压缩器**——一个专门的小型模型,将历史行动压缩为关键细节。 这种方法的哲学深度在于:**与其让多个代理学会协作,不如让一个代理学会思考**。就像人类作家不会雇佣十个分身写不同章节,而是通过提纲、笔记和反复修改管理复杂性。 但Anthropic的多代理研究系统提出了不同观点。他们的数据显示,在**广度优先查询**(如"列出标普500信息技术板块所有董事会成员")任务中,多代理系统比单代理性能提升90.2%。原因在于:**任务本质是并行化的**。并行子代理可以同时搜索不同公司,主代理整合结果,这本质上是**时间-空间的权衡**——用更多token换取更快完成。 ### 生产实践的调和:架构的实用主义 现实世界的答案往往不在极端,而在光谱中间。Anthropic的Claude Code采用**受控的子代理模式**:主代理不会在并行任务中创建子代理,而是在需要深度调查时委派问题回答型子代理。子代理的上下文不污染主线程,主代理只接收精炼答案。 这种设计遵循了Cognition的原则(避免并行工作冲突),同时利用多代理的优势(隔离长上下文)。关键洞察是:**子代理应是"信息过滤器"而非"独立决策者"**。它们将海量数据压缩为高密度洞察,主代理保留最终决策权。 ## 🎯 第四章:熵减少——Context Engineering的数学本质 ### 从信息论到注意力经济 Context Engineering 2.0论文提出了一个震撼性的理论框架:**上下文工程的本质是熵减少**。将高熵的人类信号(混乱、冗余、模糊)转化为低熵的机器可解释表示(结构化、精确、可操作)。 想象你向朋友描述"帮我找家餐厅吃饭"。这句话的熵值极高:包含无数隐含变量(口味偏好、预算、距离、时间)。优秀的Context Engineering就像一位高效的秘书,将这句话转化为: - 系统提示:"你是美食推荐专家,优先考虑用户健康偏好" - 工具定义:`search_restaurants(cuisine_type, price_range, distance_km)` - 记忆块:用户的过敏史、上次好评的餐厅类型 - 文件系统:保存的餐厅收藏夹 每个步骤都在**减少不确定性**,将可能性空间从指数级压缩到多项式级。 > **注解**:熵减少框架揭示了为什么"少即是多"。在LLM的注意力机制中,每个token都有"注意力权重"。高熵上下文如同噪音,稀释了关键信号的强度。通过结构化、摘要、工具抽象,我们实质是在做**注意力增强**——放大重要信号,抑制无关噪音。 ### KV-Cache:工程化的魔法 Manus团队分享了一个令人震惊的指标:**KV-Cache命中率是生产阶段AI代理最重要的指标**。在Manus中,输入输出token比高达100:1,意味着代理每生成一个词,要处理100个历史token。 KV-Cache的优化有三个黄金法则: 1. **保持提示前缀稳定**:单token差异就会使后续所有缓存失效。不要在系统提示中加入秒级时间戳! 2. **使上下文仅追加**:避免修改历史行动。JSON序列化必须确定有序,否则键名顺序变化会静默破坏缓存。 3. **显式标记缓存断点**:某些推理框架需要手动插入缓存断点,需确保包含系统提示末尾。 这不仅是优化技巧,更是**工程哲学的体现**:稳定性优于灵活性,可预测性优于动态性。就像操作系统内核,必须保证API的向后兼容,即使牺牲部分"智能"。 ### 屏蔽而非移除:动态动作空间的陷阱 当代理工具从10个增长到100个时,模型选择正确工具的概率急剧下降。本能反应是动态加载工具(类似RAG),但Manus的实验证明:**动态添加/移除工具会摧毁KV-Cache**,同时导致历史上下文引用的工具消失,模型困惑。 Manus的解决方案是**logits掩码**:在不改变工具定义的情况下,通过响应预填充约束动作选择。例如,强制代理在用户输入后必须回复而非调用工具,或限制只能从browser_*工具中选择。这类似于操作系统的能力控制系统(capabilities),在不修改内核的情况下限制进程权限。 ## 🛠️ 第五章:工具设计——代理与世界的契约 ### 从API到ACI:人机界面的新物种 Anthropic的《Writing effective tools》提出了革命性概念:**ACI(Agent-Computer Interface)**。传统API是为确定性系统设计的契约:`getWeather("NYC")`永远返回相同结果。而工具是为**非确定性代理**设计的契约——代理可能基于上下文选择调用、不调用,甚至错误调用。 设计有效的工具需要**逆向思维**:站在代理的角度思考。如果工具描述让你这个新入职的员工感到困惑,代理必然更困惑。好的工具应包含: - **示例用法**:展示典型调用模式 - **边界情况**:明确错误处理和默认值 - **清晰命名**:`user_id`优于`user` - **响应格式控制**:通过`response_format`参数让代理选择详细或简洁输出 > **注解**:工具设计是Context Engineering的延伸。每个工具调用及其响应都会进入上下文,因此工具响应必须**Token高效**。返回206个token的详细响应 vs 72个token的简洁响应,在100次调用中就是13,400个token的差异——这决定了一个任务能否在上下文窗口内完成。 ### 命名空间:在工具丛林中导航 当代理拥有上百个工具时,命名空间成为关键。Anthropic建议按**服务-资源**结构命名:`asana_projects_search`、`jira_users_search`。这不仅帮助代理选择正确工具,还**减少了上下文噪音**——通过前缀匹配,代理能快速定位相关工具组。 有趣的是,前缀 vs 后缀命名对性能有非平凡影响。某些模型对以`search_`开头的工具响应更好,另一些则偏好`asana_`前缀。这揭示了**LLM的隐式偏好**——训练数据中常见模式会影响工具使用效率。必须通过A/B测试找到最优方案。 ### 代码生成:终极工具形态 Claude Agent SDK的核心洞察是:**代码是终极工具**。代码是精确的、可组合的、无限可重用的。当Claude需要创建Excel文件时,它不会调用复杂API,而是**生成Python脚本**——因为代码本身就是通用接口。 这种模式的优势在于**反馈循环的完整性**。代码可以立即执行、验证、调试。代理可以运行lint检查,捕获错误,然后自我修正。相比之下,调用黑盒API的代理如同蒙眼射箭,无法获得细粒度反馈。 在邮件代理示例中,创建邮件规则的最佳方式不是调用`create_rule` API,而是生成一段在未来邮件到达时触发的代码。这实现了**延迟绑定**和**可组合性**——规则可以引用其他函数,形成复杂逻辑。 ## 📊 第六章:评估、可靠性与生产实践 ### LLM-as-Judge:当评判者也是选手 评估多代理系统面临独特挑战:代理可能采取完全不同的路径到达目标。Anthropic的解法是用**LLM作为评判者**,根据评分标准(准确性、引用质量、完整性、来源质量、工具效率)给出0-1分。 这种方法的巧妙在于**对齐人类判断**。当评判模型与主模型能力相当时,它能理解"模糊的正确"——例如,代理可能通过3个来源或10个来源找到答案,评判者能识别两者都有效,而非机械检查步骤。 但风险同样明显:**评判者可能共享主模型的偏见**。解决方案是保留**人类评估黄金集**,定期校准评判模型。在关键业务场景(如医疗、金融),人类必须保留最终裁决权。 ### 彩虹部署:状态化代理的更新噩梦 传统软件更新是瞬间完成的。但代理可能已运行数小时,处于复杂状态的中途。直接重启等于强迫学者扔掉写了五小时的论文草稿从头再来。 Anthropic的**彩虹部署**(Rainbow Deployments)如同机场的跑道切换:新旧版本并行运行,新请求逐渐路由到新版本,旧版本代理自然完成任务后退役。这需要**状态序列化**和**版本兼容**——代理状态必须能从旧版本反序列化到新版本。 更激进的想法是**代理的自我迁移**:让代理自己将关键记忆迁移到新版本。这要求记忆格式与实现解耦,类似于数据库迁移脚本。Letta的`.af`(Agent File)格式正是为此设计——它序列化代理的完整状态,包括内存块、工具定义和对话历史。 ### 错误恢复——真正代理能力的试金石 Manus团队提出了一个反直觉但深刻的观点:**保留错误在上下文中**。当代理看到失败的操作和错误信息时,它会**隐式更新内部信念**,降低重复相同错误的概率。这就像人类科学家从实验失败中学习。 学术基准测试常忽略错误恢复,只关注理想条件下的任务成功率。但生产环境中,**错误恢复是真正的代理行为标志**。代理必须能优雅地处理: - 工具调用失败(API超时、参数错误) - 环境异常(磁盘满、网络中断) - 逻辑矛盾(数据不一致、用户指令冲突) 优秀的错误处理不是重置状态,而是**让代理理解错误并适应**。例如,当`search_logs`工具因查询语法错误失败时,代理应看到错误信息,调整查询格式,而非简单地重试或放弃。 ## 🔮 第七章:未来——当上下文工程遇见自我改进 ### 上下文工程4.0:超人类时代 Context Engineering 2.0论文描绘了演进路线图: - **CE 1.0**:原始计算时代(1991-2017),上下文即显式配置 - **CE 2.0**:智能代理时代(2018-2025),上下文成为动态管理资源 - **CE 3.0**:人类水平时代(2026-2027),代理自主设计上下文结构 - **CE 4.0**:超人类时代(2028+),上下文工程成为元能力,代理能递归优化自己的上下文管理策略 我们正站在2.0到3.0的临界点。Claude 4模型已展现出**自动优化工具描述**的能力——给定失败模式,它能诊断问题并提出改进。这意味着**上下文工程正在自动化**。 ### 自我指涉的奇点 最深刻的转变是**上下文的自我指涉**:代理不仅能管理外部记忆的上下文,还能**反思和优化自己的上下文工程策略**。想象一个代理在完成任务后,生成一份"经验笔记",记录哪些上下文组织方式有效、哪些导致信息过载。这些笔记被存入记忆块,下次类似任务时自动应用。 这形成了**递归改进循环**:代理能力越强 → 生成的上下文工程策略越优 → 下次任务表现更好 → 生成更高质量策略。当这种循环速度超过人类工程速度时,我们接近**智能爆炸**的临界点。 但Letta团队发出警示:**不要过度拟合**。如果代理只在训练分布的任务上优化上下文策略,它在面对分布外任务时会崩溃。解决方案是**保持上下文工程的显式性**——即使代理能自动管理,开发者也应能审查和干预。 ### 人机共生:建筑师与匠人的新契约 未来不属于完全自主的AI,也不属于手动微调的工程师,而属于**人机共生系统**。人类作为**上下文建筑师**,定义高层原则(如隐私边界、伦理约束、业务目标);AI作为**上下文匠人**,执行动态优化、压缩、检索和工具编排。 这种分工在Manus的实践中已显现:人类设计稳定的提示前缀和工具命名规范(建筑结构),AI通过`todo.md`的反复重写管理注意力(内部装修)。正如好的建筑需要坚固框架和灵活空间,好的代理需要**刚性原则**与**柔性适应**的平衡。 ## 🎬 尾声:每一个token都是一滴水 回顾这场认知革命,核心洞见出奇地朴素:**Context Engineering是注意力经济时代的资源管理艺术**。每个token都是一滴水,在LLM的注意力沙漠中弥足珍贵。我们的任务不是建造更大的水库(无限上下文),而是学会**精准灌溉**——在正确的时间、正确的地点,给予模型最需要的信息。 从MemGPT的记忆块到Letta的LLM OS,从Cognition的单线程哲学到Anthropic的多代理实践,从KV-Cache优化到熵减少理论,所有努力指向同一目标:**让AI从被动的文本生成器,进化为能主动管理自身认知资源的智能体**。 这不仅是技术演进,更是**认知范式的迁移**。我们重新定义了"智能"——它不仅是知识储备或推理速度,更是**有效管理有限注意力的能力**。在这个意义上,Context Engineering不仅是AI工程的子领域,更是**通用智能的理论基础**。 当未来的历史学家回望2025年,他们可能会说:这一年,AI学会了记住;更重要的是,它学会了**如何记住**。 --- ## 📚 核心参考文献 1. **Packer, C., et al. (2024).** *MemGPT: Towards LLMs as Operating Systems*. arXiv:2310.08560. **核心贡献**:提出LLM作为操作系统的范式,引入Memory Blocks抽象,支持自我编辑的持久化记忆。 2. **Letta, Inc. (2025).** *Memory Blocks: The Key to Agentic Context Management*. **核心贡献**:系统阐述记忆块的设计原则,包括标签、值、大小限制和访问模式,以及多代理共享记忆的实现。 3. **Anthropic, Engineering Team (2024).** *Building Effective Agents*. **核心贡献**:区分工作流与代理的架构模式,提出从简单开始、仅在必要时增加复杂度的工程哲学。 4. **Hadfield, J., et al. (2025).** *How we built our multi-agent research system*. **核心贡献**:展示多代理系统在并行研究任务中的90.2%性能提升,揭示token使用量是性能主因。 5. **Yan, W. (2025).** *Don't Build Multi-Agents*. Cognition Blog. **核心贡献**:批判多代理架构的脆弱性,提出上下文共享与决策一致性的两大原则,主张单线程线性代理的默认选择。 6. **Ji, Y. (2025).** *Context Engineering for AI Agents: Lessons from Building Manus*. **核心贡献**:提出KV-Cache命中率作为核心指标,揭示logits掩码、文件系统作为上下文的工程实践。 7. **Anthropic, Applied AI Team (2025).** *Effective Context Engineering for AI Agents*. **核心贡献**:将上下文工程定义为熵减少过程,提出JIT检索、压缩、结构化笔记等长程任务技术。 8. **Mei, L., et al. (2025).** *A Survey of Context Engineering for Large Language Models*. arXiv:2507.13334. **核心贡献**:系统综述上下文工程的理论框架,划分1.0至4.0的演进时代。