上下文工程 (Context Engineering)

深度解析与前沿实践

演讲者:

Lance (LangChain 创始工程师)

Peak (Manus 联合创始人 & 首席科学家)

参考资料

原始访谈 · YouTube
Context Engineering for AI Agents with LangChain and Manus · 2025-10-14
https://www.youtube.com/watch?v=6_BcCthVvb8
内容整理 · 公众号
作者：孔某人 · 公众号：孔某人的低维认知
https://mp.weixin.qq.com/s/ZYrOcuBBB2u1lsWtOb8rFQ

提纲

Part 1 概念篇：什么是上下文工程？
Part 2 全景篇：核心技术概览
Part 3 实践篇：来自 Manus 的前沿经验
Part 4 问答篇：Q&A 精华

什么是上下文工程？

  • 一个随 ChatGPT 和 Agent 概念兴起的新学科。
  • 核心挑战：Agent 在自主循环中调用工具，会导致上下文（Context）爆炸式增长。
  • 典型任务可能需要 50次 工具调用，生产环境 Agent 可能有数百轮对话。
  • 上下文腐烂 (Context Rot)：随着上下文增长，模型性能会下降，出现重复、推理变慢、质量下降等问题。

- Lance

上下文工程核心技术全景

卸载 (Offload)

将大块信息（如工具输出）移出上下文，存到外部（如文件），仅保留引用。

精简 (Reduce)

通过总结(Summarization)、压缩(Compaction)或修剪(Pruning)来减少上下文长度。

检索 (Retrieve)

在需要时，按需从外部存储中获取相关信息，重新注入上下文。

隔离 (Isolate)

使用多 Agent 架构，每个 Agent 拥有独立的上下文窗口，分离关注点，防止干扰。

缓存 (Cache)

利用 KV Cache 等技术，避免重复计算共同的前缀，降低成本和延迟。

平衡 (Balance)

以上技术相互关联，需要在多个潜在冲突的目标之间找到完美平衡。

定义：一门精妙的艺术与科学

将上下文工程理解为一门精妙的艺术和科学，用恰当的信息填充上下文窗口以支持下一步操作。

  • 目标是管理和对抗上下文爆炸，在所有时间点为 Agent 呈现正确的信息，让它做出正确的下一步决策。

- Lance (引用 Karpathy)

核心技术 1: 上下文卸载 (Offloading)

  • 核心思想：并非所有上下文都需要存在于消息历史中。
  • 可以将信息卸载到上下文窗口之外的地方，需要时再检索。
  • 最流行的方法：使用文件系统。例如，将 Token 消耗大的 Web 搜索结果存入文件，只向 Agent 返回文件路径。
  • 应用案例：Manus, OpenDevin, Claude Code, LangChain Agents 等。

- Lance

核心技术 2: 上下文精简 (Reducing)

  • 核心思想：对信息进行总结或压缩。
  • 总结工具调用输出：将冗长的结果提炼成精华。
  • 修剪 (Pruning)：移除旧的或不那么重要的工具调用及其输出。
  • 历史压缩 (Compaction)：当上下文达到某个阈值时，对整个消息历史进行总结。
  • 应用案例：Claude Sonnet 4.5 (内置修剪), Claude Code (Compaction), Cognition。

- Lance

核心技术 3 & 4: 检索与隔离

  • 上下文检索 (Retrieving)：为 Agent 按需获取上下文。
    • 方法1: 索引和语义搜索 (如 Vector DB)。
    • 方法2: 文件系统和简单搜索工具 (如 glob, grep)。
  • 上下文隔离 (Isolation)：通过 Multi-agents 分离上下文，每个 Sub-agent 拥有自己的上下文窗口，实现关注点分离。

- Lance

来自 Manus 的前沿经验

"今天我想深入探讨一些我之前要么没有深入讨论，要么根本没有涉及的领域。我们会关注那些非共识的想法，因为探索它们往往会带来最大的启发。"

Peak

Manus 联合创始人 & 首席科学家

为什么需要上下文工程 (而非微调)？

  • 陷阱1：从头训练模型：产品创新速度完全受限于模型迭代速度 (通常1-2周)，且可能在不重要的基准上空耗。
  • 陷阱2：微调基础模型：强化学习 (RL) 通常需要固定 Action Space，但在 Agent 早期阶段，产品可能因新技术（如 MCP）而巨变，导致模型作废。
  • 结论：上下文工程是当前应用和模型之间最清晰、最实用的边界。创业公司应尽可能长时间地依赖它。

- Peak

精简技术深潜：压实 vs. 总结

  • 压实 (Compaction)：一种可逆的精简。将信息外部化（如存入文件），只保留引用（如文件路径）。没有信息真正丢失。
  • 总结 (Summarization)：一种不可逆的精简。会真正丢失信息，需非常小心使用。
  • 策略：
    1. 达到“预腐烂”阈值 (如 128k-200k tokens) 时触发。
    2. 先对最旧的 50% 内容进行压实。
    3. 如果压实收益甚微，再对（压实前的）完整内容进行总结。
    4. 始终保留最近几个工具调用的完整细节，以保证 Agent 行为连贯。

- Peak

隔离技术深潜：通信 vs. 共享内存

"不要通过共享内存来通信。相反，通过通信来共享内存。" - Go 语言社区

  • 通过通信 (By Communicating)：经典的 Sub-agent 模式。主 Agent 发送清晰指令，Sub-agent 在隔离的上下文中完成任务，只返回最终结果。适用于简单、独立的任务。
  • 通过共享内存 (By Sharing Context)：Sub-agent 可以看到完整的历史上下文，但有自己的系统提示和 Action Space。适用于需要大量历史信息的复杂任务（如 Deep Research）。

- Peak

卸载技术深潜：分层的 Action Space

  • 问题：工具太多会导致“上下文混乱”，模型可能调用错误或不存在的工具。动态加载工具会破坏 KV Cache。
  • Manus 的方案：将 Action Space 分为三个抽象层级，卸载工具本身。
  • 层级 1: Function Calling
    仅保留少数（10-20个）核心原子函数，如读写文件、执行 shell、搜索。保证 schema 安全且对 Cache 友好。
  • 层级 2: Sandbox Utilities
    在虚拟机沙箱中预装大量命令行工具。Agent 通过 shell 命令调用。可无限扩展能力而不污染函数空间。
  • 层级 3: Packages & APIs
    Agent 编写并执行脚本来调用第三方库和 API。适用于需要大量计算或内存的任务。

- Peak

最终思考：避免过度工程化

我们见到的最大飞跃并非来自添加更多花哨的管理层或巧妙的技巧，而是来自简化，来自移除不必要的技巧并更多地信任模型。

少构建，多理解。

- Peak

问答篇：Q&A 精华

Q&A 精华

从真实场景出发，聚焦工具、记忆、模型、规划与安全的关键抉择。

工具调用 索引与记忆 模型选择 规划 多 Agent 安全 评估

Q&A: 工具调用、索引与长期记忆

如何调用 Shell 工具?
在系统提示中告知工具位置，并鼓励 Agent 使用 --help 自行学习用法。
索引 vs. Grep/Glob?
对于会话级任务，动态构建索引太慢。Manus 依赖 grep 和 glob，更快速直接。对于企业知识库等长期记忆场景，索引是必要的。
长期记忆?
Manus 采用显式的、用户确认的“知识”系统。同时在探索从集体用户反馈中进行无参数在线学习的“自我改进”机制。

Q&A: 架构演进、数据格式与总结技巧

如何应对模型升级?
不断重构。通过在强弱模型间切换来测试架构的未来适应性，可以提前为下一代模型做准备。
最佳数据格式?
优先考虑基于行的格式（如纯文本），因为它允许模型使用 grep 或按行读取，比 Markdown 更稳定。
如何做好总结?
不要用自由形式的 Prompt。定义一个结构化的 Schema（像表单），让 AI 填写关键字段，输出更稳定可靠。

Q&A: Agent 通信、模型选择与规划

Agent 间如何通信?
通过共享沙箱（文件系统）和契约 (Schema)。主 Agent 定义输出 Schema，Sub-agent 使用约束解码来确保返回符合格式的数据。
模型选择?
旗舰模型因其全球分布式 KV Cache 基础设施，在 Agent 场景（输入远长于输出）下可能比开源模型更具成本效益。不同模型擅长不同任务，应做任务级路由。
规划 (Planning)?
从浪费 Token 的 todo.md 范式，演进为由一个独立的 Planner Agent（Agent as Tool）进行更结构化的规划。

Q&A: 多 Agent 设计、安全与评估

多 Agent 设计?
避免拟人化（如设计师、程序员 Agent）。Manus 采用少数功能性 Agent（执行器、规划器、知识管理器），而非按角色划分。
安全性?
沙箱是核心。严格控制出站流量，对敏感操作要求用户手动确认。与模型提供商合作，利用其内置的 Guardrails。
如何评估 (Eval)?
用户反馈是金标准（1-5星评分）。结合内部自动化测试集和大量人工（实习生）评估主观输出（如 UI 美观度）。

感谢观看

愿我们以更少的技巧，更深的理解，构建真正有用的智能系统。

少构建 · 多理解 · Keep It Simple

PPT 目录
作者：兮尘 · 主页： https://linxueyuan.online/
1 / 20