上下文工程：构建高效AI代理的核心策略

在AI代理的时代，如何管理不断膨胀的上下文已成为一个关键挑战。LangChain的创始工程师Lance和Manis的联合创始人兼首席科学家Pete在本次网络研讨会中，深入探讨了上下文工程的理论与实践。

上下文工程的兴起背景

上下文工程这一概念在2023年兴起,对应着"代理之年"的到来。与早期的"提示工程"(Prompt Engineering)专注于如何与聊天模型交互不同,上下文工程关注的是在代理长时间运行过程中,如何管理不断增长的上下文信息。

代理面临的核心挑战

AI代理的工作机制是:大语言模型绑定多个工具,在循环中自主调用这些工具。但每次工具调用都会产生观察结果,这些结果会被追加到消息列表中,导致上下文爆炸:

• 典型任务需要约50次工具调用
• 生产环境中的代理对话可能跨越数百轮
• 研究表明,随着上下文增长,模型性能会下降

这就形成了一个悖论:代理需要大量上下文来完成任务,但上下文过多又会导致性能下降。

上下文工程的五大核心策略

1. 上下文卸载(Context Offloading)

上下文卸载的核心思想是:不是所有信息都需要保存在代理的消息历史中。

实施方法:

• 将工具调用的输出转储到文件系统
• 仅向代理返回最小必要信息(如文件路径)
• 需要时可以检索完整内容

应用案例:

• Manis使用文件系统存储工具输出
• DeepAgents项目利用文件系统管理上下文
• Claude Code广泛使用文件系统卸载

这种方法避免了将重量级的工具输出(如网页搜索结果)永久性地塞入上下文窗口。

2. 上下文精简(Context Reduction)

上下文精简与卸载类似,但侧重于总结或压缩信息,而非完全移除。

主要技术:

• 总结工具调用输出 - OpenDeepResearch采用此方法
• 裁剪旧的工具消息 - Claude 4.5已将此功能内置到SDK中
• 压缩完整消息历史 - Claude Code的压缩功能
• 在代理交接时总结 - Cognition的实践经验

3. 上下文检索(Context Retrieval)

关于上下文检索,目前有两种主流方法,各有优劣:

方法一:索引与语义搜索

• Cursor使用索引和语义搜索
• 适合大规模知识库

方法二:文件系统搜索

• Claude Code仅使用glob和grep等简单搜索工具
• 更轻量级,延迟更低

选择哪种方法取决于具体应用场景和数据规模。

4. 上下文隔离(Context Isolation)

通过多代理架构实现上下文隔离,每个子代理拥有独立的上下文窗口和职责范围。

优势:

• 分离关注点
• 每个子代理有专门的系统提示和动作空间
• 适合复杂的多阶段任务

应用实例:

• Manis的Wide Agents
• DeepAgents工作流
• OpenDeepResearch的多代理架构
• Claude的子代理研究助手

5. 上下文缓存(Context Caching)

上下文缓存是一个经常被忽视但非常重要的优化策略。通过缓存KV(键值对),可以:

• 减少重复计算
• 降低延迟
• 节省成本

Anthropic的输入缓存功能就是这一策略的典型应用。

Manis的实践经验

为什么需要上下文工程而非模型微调?

Pete分享了Manis选择上下文工程而非模型微调的深刻见解:

历史教训:

• 过去构建语言模型时,产品创新速度完全受限于模型迭代速度
• 单次训练+评估周期需要1-2周
• 在找到产品市场契合点(PMF)前,这种投入往往是无效的

微调的陷阱:

• 需要固定动作空间
• 需要围绕当前产品行为设计奖励
• MCP的推出彻底改变了Manis设计,从紧凑的静态动作空间转向无限可扩展
• 开放域问题的泛化训练极其困难

**核心观点:**在找到PMF之前,应该尽可能依赖通用模型和上下文工程,而非过早构建专用模型。

可逆压缩与不可逆总结

Manis对上下文精简进行了细致的分类:

压缩(Compaction) - 可逆操作

每个工具调用和工具结果有两种格式:

• 完整格式 - 包含所有信息
• 紧凑格式 - 剔除可从文件系统重建的信息

示例:

完整格式:
{
  "path": "/data/report.txt",
  "content": "... 大量内容 ..."
}

紧凑格式:
{
  "path": "/data/report.txt"
}

文件已存在于环境中,代理需要时可通过路径检索。信息没有丢失,只是外部化了。

这种可逆性至关重要,因为代理的预测是链式的,10步之后可能突然需要某个早期动作的详细信息。

总结(Summarization) - 不可逆操作

当压缩仍无法满足需求时,才谨慎使用总结:

最佳实践:

1. 总结前卸载关键部分 - 将重要上下文保存到文件
2. 转储完整的预总结上下文 - 作为日志文件保存
3. 使用结构化schema - 而非自由格式总结
4. 保留最近的完整工具调用 - 提供上下文示例

Pete特别强调:不要使用自由格式的总结,而应定义结构化的schema,例如:

• 修改的文件列表
• 用户目标
• 当前进度

这样既保证了输出稳定性,也便于迭代优化。

上下文长度阈值管理

Manis采用了细致的阈值管理策略:

三层阈值:

1. 硬限制 - 模型的最大上下文(如100万tokens)
2. 腐烂阈值 - 性能开始下降的点(通常128K-200K)
3. 触发阈值 - 开始上下文精简的点

精简策略:

• 先压缩最老的50%工具调用
• 保持新的调用完整,作为few-shot示例
• 压缩后检查释放的空间
• 收益微小时才启用总结
• 总结时始终使用完整版本数据
• 保留最后几个完整的工具调用和结果

上下文隔离的两种模式

Manis借鉴了Go语言的并发哲学:不要通过共享内存来通信,而是通过通信来共享内存。

通过通信(By Communicating)

适用场景:

• 任务有简短明确的指令
• 只关心最终输出
• 例如:在代码库中搜索特定代码片段

实现:

• 主代理编写提示
• 子代理的上下文仅包含该指令
• 主代理不关心子代理如何找到代码,只需要结果

Claude Code通常使用这种模式,通过task工具委派清晰的任务。

通过共享内存(By Sharing Memory)

适用场景:

• 复杂场景需要完整历史
• 最终输出依赖大量中间结果
• 例如:深度研究场景

实现:

• 子代理可以看到完整的先前上下文
• 拥有自己的系统提示和动作空间
• 共享所有工具使用历史

权衡考虑:

• 共享上下文成本较高(更大的输入预填充)
• 由于系统提示和动作空间不同,无法重用KV缓存
• 但避免了重复读取文件的延迟和token消耗

分层动作空间 - Manis的创新

这是Pete分享的最新实践,尚未在之前的博客中详细讨论。

三层抽象:

第一层:函数调用(Function Calling)

• 特点: Schema安全,通过约束解码实现
• 限制: 工具过多会破坏缓存,造成混淆
• Manis策略: 仅使用固定数量的原子函数
  • 读写文件
  • 执行shell命令
  • 搜索文件和互联网
  • 浏览器操作

这些原子函数边界清晰,可以组合成复杂工作流。其他功能全部卸载到下一层。

第二层:沙盒工具(Sandbox Utilities)

• 实现: 每个Manis会话运行在完整的虚拟机沙盒中
• 使用方式: 通过shell命令调用预装工具
• 工具示例:
  • 格式转换器
  • 语音识别工具
  • MCP CLI - 这是Manis调用MCP的方式!

优势:

• 不触碰模型的函数调用空间即可添加新能力
• 就像Linux预装命令,代理知道如何找到它们
• 可以运行--help了解用法
• 大输出可写入文件或分页返回
• 可使用grep、cat、less等工具即时处理结果

权衡:

• 适合大输出处理
• 但前端的低延迟交互可视化较复杂

第三层:包和API(Packages and APIs)

• 实现: 编写Python脚本调用预授权API或自定义包
• 应用场景:
  • 使用3D设计库建模
  • 调用金融API获取市场数据
  • 分析整年股价数据(计算后仅返回摘要)

特点:

• API密钥预装在沙盒中,包含在订阅费用中
• 代码和API高度可组合
• 一个Python脚本可链式执行多个操作(如获取城市名→城市ID→天气)
• 类似Code Act论文的思想

注意事项:

• 不是schema安全的
• 很难进行约束解码
• 需要在编译器/解释器运行时处理的场景

统一接口: 从模型角度看,三层仍通过标准函数调用访问:

• 沙盒工具 → 使用shell函数
• 包和API → 使用file函数写入,然后shell函数执行

这样不会增加模型开销,都是模型训练时已熟悉的操作。

上下文工程的平衡艺术

Pete强调,上下文工程的五个维度并非独立:

相互关系:

• 卸载和检索 → 实现更高效的精简
• 稳定的检索 → 使隔离更安全
• 隔离 → 减缓上下文增长,降低精简频率
• 但更多的隔离和精简 → 影响缓存效率和输出质量

核心观点: 上下文工程是在多个潜在冲突的目标之间寻求完美平衡的科学与艺术。这非常困难,但至关重要。

避免上下文过度工程化

在分享所有技术细节后,Pete给出了一个看似矛盾但极其重要的建议:

"回顾Manis发布后的6-7个月,我们最大的飞跃并非来自添加更多精巧的上下文管理层或聪明的检索技巧,而是来自简化,来自移除不必要的技巧,更多地信任模型。"

关键教训:

• 每次简化架构,系统都变得更快、更稳定、更智能
• 上下文工程的目标是让模型的工作更简单,而非更困难
• 构建更少,理解更多

实例: 早期Manis使用todo.md范式,但发现约三分之一的动作都在更新待办列表,浪费大量轮次。现在改用结构化规划,通过独立的规划代理管理计划,显著节省了tokens。

模型选择与评估策略

为何不使用开源模型进行微调?

Pete给出了出人意料的答案:成本考虑。

分析:

• 对于Manis规模的应用,输入远长于输出
• 分布式KV缓存至关重要
• 开源方案的分布式缓存实现困难
• 前沿模型提供商有更可靠的全球缓存基础设施
• 经过计算,使用旗舰模型有时比开源模型更便宜

多模型策略

Manis采用任务级路由,根据不同子任务选择最佳模型:

• 编程任务 → Claude(Anthropic)
• 多模态任务 → Gemini(Google)
• 复杂数学推理 → OpenAI模型

这是应用公司的优势:不必绑定单一模型,可以为不同任务选择最佳工具。

评估方法论

Manis的三层评估体系:

1. 用户评分(金标准)

• 每个完成的会话请求用户打1-5星
• 关注平均用户评分
• 最重要的指标

2. 自动化测试

• 可验证结果的内部数据集
• 关注执行任务(而非仅阅读任务)
• 利用沙盒可频繁重置测试环境的优势
• 仍使用公开学术基准,但发现与用户满意度不完全对齐

3. 人工评估

• 雇用大量实习生
• 评估难以自动化的任务(如网站生成、数据可视化)
• 关注审美品味等主观因素
• 很难设计好的奖励模型来评判视觉吸引力

其他重要实践

工具选择策略

• 经验法则: 不超过30个工具
• Manis方法: 仅10-20个原子函数在动作空间中
• 其他一切 → 卸载到沙盒
• 核心理念: 计算机是图灵完备的,理论上代理可以做初级实习生能用计算机完成的任何事

有了shell工具和文本编辑器,动作空间已经完备。

规划代理设计

• 不再使用todo.md范式(浪费轮次)
• 使用独立的规划代理(agent-as-tool范式)
• 可以用不同模型进行规划
• 独立视角可进行外部审查
• 例如:OpenAI的o1有时能生成非常有洞察力的规划

多代理架构原则

Manis不按角色划分代理(如设计师代理、程序员代理、管理者代理):

原因: 这种划分源于人类公司架构,是人类上下文限制的产物,对AI代理并不必要。

Manis的代理:

• 通用执行代理(主力)
• 规划代理
• 知识管理代理
• 数据/API注册代理

对添加新子代理非常谨慎,因为代理间通信很困难。

更多使用"agent-as-tool"模式:将复杂子任务封装为工具,而非独立角色代理。

代理间通信

方法1: 通过文件系统共享沙盒

• 主代理和子代理共享同一沙盒
• 仅传递路径,而非完整内容
• 适合需要访问完整历史的场景

方法2: Schema约束输出

• 主代理定义输出schema
• 子代理有特殊的"submit_result"工具
• 使用约束解码确保输出符合schema
• 类似MapReduce操作,生成结构化的"电子表格"

安全与防护

沙盒安全:

• 确保信息不会泄露出沙盒
• 检查出站流量(如防止token泄露)
• 用户打印信息时进行脱敏处理

浏览器挑战:

• 可持久化登录状态
• 网页内容可能包含提示注入
• 超出应用公司能力范围

解决方案:

• 与Anthropic、Google等模型提供商紧密合作
• 敏感操作需要手动确认
• 随着模型内置防护栏改进,可逐步放松限制

数据存储格式建议

优先选择基于行的格式:

• 方便使用grep或按行范围读取
• Markdown有时会导致模型输出过多项目符号
• 更倾向于纯文本格式

关于强化学习的思考

当被问及是否进行强化学习时,Pete给出了深思熟虑的答案:

为何目前不做RL:

• MCP改变了游戏规则 - 不再是固定动作空间
• 开放动作空间很难设计好的奖励
• 无法生成平衡的反馈数据
• 支持MCP意味着要自己构建基础模型 - 这不是应用公司应该做的

但在探索新方向:

• 个性化或在线学习
• 使用无参数方法 - 如集体反馈
• 利用用户纠正(如字体问题的重复修正)
• 自我改进的代理,但不依赖参数更新

结语

上下文工程不仅是一套技术方法,更是一种在应用层和模型层之间划清界限的哲学。

核心要点:

1. 信任模型的能力 - 随着模型改进,简化架构往往比增加复杂度更有效
2. 使用架构适应性测试 - 在弱模型和强模型之间切换,检验架构的未来适应性
3. 避免过度工程 - 上下文工程的目标是简化模型工作,而非使其复杂化
4. 持续迭代 - Manis在7个月内重构了5次,保持对模型演进的响应能力

正如Pete所说:构建更少,理解更多。 这或许是上下文工程乃至整个AI代理开发领域最重要的指导原则。