标签归档：Agent

从 Claude Code到 Gemini CLI，AI Agent 的上下文管理策略

发表回复

对于一个与大型语言模型（LLM）打过交道的开发者来说，上下文管理都是一个绕不开的核心问题。它不仅决定了 AI 的智能程度，也直接关系到系统的性能和成本。

上周研究了各家 Agent 系统的实现，各家的上下文管理策略都不相同。最简单最傻的策略是一个不断累加对话历史，这种策略很快就会遇到 Token 限制和 API 的成本问题。

如果你是一个技术负责人，或者正在开发 AI Agent 相关的产品，需要在性能和成本之间找到平衡点，这篇文章应该对你有一些帮助。

今天所聊的内容是基于对 Claude Code、Manus、Gemini CLI，OpenManus 等多个项目的分析，以及自己在实践中的一些思考。

为什么要做上下文管理？

最新的 LLM 现在提供 128K Token 或更多的上下文窗口。听起来还挺多的，但在真实世界的 Agent 场景中，这通常远远不够。

尤其是当 Agent 与网页或PDF等非结构化数据交互时，Token 数需求会爆炸。

并且，随着 Token 数的增加，模型性能会在超过一定长度后明显下降，这就像让一个人同时记住一本书的所有细节，理论上可能，实际上很难做好。

就算我们的大模型有更多的窗口上下文支持，成本也是一个需要考虑的问题，就算有前缀缓存这样的优化，但传输和预填充每个 Token 都是要付费的。

为了解决这些问题，许多团队选择了压缩策略。但过度激进的压缩不可避免地导致信息丢失。

这个问题的本质在于 Agent 必须根据所有先前状态预测下一个动作——而我们无法可靠地预测哪个观察结果可能在十步之后变得至关重要。从逻辑角度看，任何不可逆的压缩都带有风险。

接下来我们看一看各项目的上下文管理策略，看看从中能否给到各位看官一些启发。

OpenManus 的上下文管理策略

OpenManus 采用了一个相对简单直接的上下文管理方案，主要特点是：

  1. 轻量级消息列表机制
  • 使用固定长度（默认100条）的消息列表作为内存存储
  • 采用简单的 FIFO（先进先出）策略，超出限制时截断最早的消息
  • 没有智能的上下文压缩或摘要机制
  1. Token 限制处理
  • 实施硬性 token 检查，超限直接抛出异常终止
  • 缺乏优雅的降级策略或自适应窗口裁剪
  • 在长对话或工具密集场景中容易触碰上限

虽然上下文管理比较简单，但是 OpenManus 为不同使用场景提供了定制化的上下文处理，如浏览器场景会动态注入浏览器状态，截图保存等

总的来说，这是一个原型实现，并不适合作为生产级环境使用，如果要上到生产环境需要自行做精细化的处理和架构。

Manus 的上下文管理策略

Manus 没有开源，但是其官方有发一篇文章出来。

Manus 采用了一种创新的方法：将文件系统作为终极上下文存储，而不是依赖传统的内存中上下文管理。

文件系统作为存储有如下的核心特性：

  • 无限容量：文件系统大小不受限制
  • 天然持久化：数据自动保存，不会丢失
  • 直接操作：智能体可以主动读写文件
  • 结构化记忆：不仅是存储，更是结构化的外部记忆系统

相对于传统的将完整的观察结果保存在上下文中，容易超限，Manus 实现了可恢复的信息压缩：

  • 观察结果指向外部文件（Document X, File Y）
  • 上下文中只保留引用，不保存完整内容
  • 需要时可以从文件系统恢复完整信息

具体实现：

  • 网页内容可从上下文移除，只保留 URL
  • 文档内容可省略，只保留文件路径
  • 实现上下文压缩的同时不会永久丢失信息

Manus 团队认为，如果状态空间模型能够掌握基于文件的记忆管理：

  • 将长期状态外部化而非保存在上下文中
  • SSM 的速度和效率优势可能开启新型智能体
  • 基于 SSM 的智能体可能成为神经图灵机的真正继任者

与 OpenManus 的简单消息列表管理，Manus 的方案更加成熟：

  • OpenManus：固定长度消息列表，硬性截断，缺乏智能管理
  • Manus：文件系统作为无限外部记忆，可恢复压缩，主动记忆管理

Claude Code 的上下文管理

Claude Code 没有开源代码，但是国外有大神反编译其源码（虽然大神自己说:这并非真正意义上的反编译或逆向工程尝试，而更像是对 Claude 团队杰出工作的致敬。）

地址：southbridge-research.notion.site/claude-code…

通过反编译内容的分析，可以大概了解一些其策略和比较巧妙的点：

TodoWrite 工具

Claude Code 引入 TodoWrite 工具，支持模型主动维护自己的 To-Do 列表，替代传统的多 Agent 分工策略。

其优势：

  • 专注：Prompt 中反复提醒模型参考 ToDo，始终聚焦目标。
  • 灵活：「交错思考」机制使得 ToDo 可动态增删。
  • 透明：用户可实时查看计划与进度，提高信任度。

Token 统计的反向遍历

Toke 统计从后往前查找这个细节相当精妙。大部分系统都是傻乎乎地从头遍历，但 Claude Code 意识到了一个关键事实：Token 使用情况的统计信息总是出现在最新的 assistant 回复里。这种”知道去哪找”的优化思路，把原本可能的 O(n) 操作优化到了 O(k)，在高频调用场景下，这种优化带来的性能提升是指数级的。

92% 阈值

留 8% 的缓冲区既保证了压缩过程有足够的时间完成，又避免了频繁触发压缩带来的性能开销。更重要的是，这个缓冲区给了系统一个”反悔”的机会——如果压缩质量不达标，还有空间执行降级策略。

8 段式结构化摘要

Claude Code 的 8 段式结构特别值得借鉴：

markdown

体验AI代码助手
代码解读
复制代码

1. Primary Request and Intent - 主要请求和意图

2. Key Technical Concepts - 关键技术概念

3. Files and Code Sections - 文件和代码片段

4. Errors and Fixes - 错误和修复

5. Problem Solving - 问题解决过程

6. All User Messages - 所有用户消息

7. Pending Tasks - 待处理任务

8. Current Work - 当前工作状态

优雅降级

当压缩失败时，系统不会死板地报错或者强行应用低质量的压缩结果，而是有一整套 Plan B、Plan C。从自适应重压缩，到混合模式保留，再到最后的保守截断——每一步都在努力保护用户体验。这种”永不放弃”的设计理念，让系统在各种极端情况下都能稳定运行。

向量化搜索

长期记忆层引入向量搜索，实际上是在为 AI 构建一个”联想记忆”系统。当用户提出新问题时，系统不仅能看到当前对话，还能”回忆”起过去处理过的类似问题。这种跨会话的知识迁移能力，让 Claude Code 从一个简单的对话工具进化成了一个真正的智能编程助手。

Gemini-cli 的上下文管理

Gemini-cli 的上下文管理走了一条和 Claude Code 相似但更加轻量的路线。它的核心理念很简单：文件系统就是天然的数据库。

三层混合存储架构

与 Claude Code 类似，Gemini-cli 也采用了分层设计，但实现更加简洁：

第一层：纯内存工作区

  • 存储当前会话的聊天历史、工具调用状态、循环检测状态
  • 零延迟访问，不涉及任何 I/O 操作
  • 会话结束即清空，不留痕迹

第二层：智能压缩层

  • 触发阈值：70%（比 Claude Code 的 92% 更保守）
  • 保留策略：最新 30% 的对话历史
  • 压缩产物：5 段式结构化摘要

第三层：文件系统持久化

  • 全局记忆：~/.gemini/GEMINI.md
  • 项目记忆：向上递归查找直到项目根目录
  • 子目录上下文：向下扫描并尊重忽略规则

70/30

Gemini-cli 选择了 70% 作为压缩触发点，30% 作为保留比例。这个比例设计很有讲究：

为什么是 70% 而不是 92%？

  • 更早介入，避免紧急压缩导致的卡顿
  • 给压缩过程留出充足的缓冲空间
  • 适合轻量级应用场景，不追求极限性能

30% 保留的合理性

  • 刚好覆盖最近 5-10 轮对话
  • 足够维持上下文连续性
  • 不会让用户感觉”突然失忆”

5 段式压缩：够用就好

相比 Claude Code 的 8 段式结构，Gemini-cli 的压缩更简洁：

markdown

体验AI代码助手
代码解读
复制代码

1. overall_goal - 用户的主要目标

2. key_knowledge - 重要技术知识和决策

3. file_system_state - 文件系统当前状态

4. recent_actions - 最近执行的重要操作

5. current_plan - 当前执行计划

忽略规则

Gemini-cli 的 .geminiignore 机制是个亮点：

独立但兼容

  • 可以单独在非 git 仓库中生效
  • 与 .gitignore 并行工作，互不干扰
  • 每个工具都有独立的忽略开关

明确的约束

  • 修改 .geminiignore 需要重启会话才生效
  • 这不是 bug，而是 feature——避免运行时状态混乱

Gemini-cli 的设计哲学可以总结为：不求最优，但求够用。

它没有追求理论上的完美压缩比，也没有搞复杂的向量检索，而是用最简单的方案解决了 80% 的问题。这种务实的态度在工程实践中往往更受欢迎——系统简单意味着 bug 少，维护容易，用户上手快。

特别是”文件系统就是数据库”这个理念，虽然听起来有点”土”，但在实际使用中却异常可靠。你不需要担心数据库挂了、连接断了、事务死锁了…文件就在那里，看得见摸得着，出了问题 cat 一下就知道怎么回事。

这种设计思路值得很多过度工程化的项目学习：有时候，简单就是最好的复杂。

小结

上下文是智能的边界，压缩是性能的艺术。

在与大型语言模型打交道的过程中，上下文管理已成为决定智能上限与系统稳健性的关键。虽然现代 LLM 提供了百万级 Token 的窗口，但在实际 Agent 场景中，这远远不够，尤其当涉及非结构化数据（如网页、PDF）时，Token 使用会迅速膨胀。即使有前缀缓存等机制，成本与性能的双重压力仍然存在。因此，上下文压缩成了必选项——但压缩得太激进，又会导致信息丢失，损害 Agent 的决策能力。

聪明的系统不是记住所有，而是记住该记住的。

应对上下文限制的最佳方式不是简单保留或截断历史，而是构建一个具备“记忆力”的智能系统。Claude Code 以三层记忆架构为核心（短期、高速；中期、结构化压缩；长期、跨会话向量化搜索），同时引入 TodoWrite 工具，让模型自我管理计划任务。这使得 Agent 能专注目标、灵活调整、透明运行，形成类人思维般的任务记忆系统。关键机制如 Token 反向遍历、92% 阈值缓冲、8段式摘要结构与优雅降级策略，共同打造了一个稳健又高效的上下文生态。

工程的智慧在于‘够用’，而非‘极致’。

对比 Gemini-cli、OpenManus 与 Manus 的上下文策略，可以看出不同系统在工程实现上的取舍哲学。Gemini-cli 采用实用主义的轻量分层设计，70/30 压缩策略既简单又高效，让用户可控又无需担心性能瓶颈；Manus 则大胆将文件系统作为智能体的“外部大脑”，通过引用而非存储规避 Token 限制；而 OpenManus 则为最小可运行原型提供了基础模板。这些方案展现出一个共识：上下文不一定要复杂，关键在于是否服务于目标。

以上。

Multi-Agent 系统的主从架构

发表回复

最近一年，Multi-Agent 系统持续发热发烫，融资不断，火了起来。

从 AutoGPT 到 MetaGPT，从 CrewAI 到 LangGraph，各种多代理框架层出不穷。国内现象级的 Manus，以及当天由 MetaGPT 的同学开源的 OpenManus。OpenAI 的 Swarm、微软的 AutoGen，还有 Anthropic 的 Claude Code，每个大厂都在探索自己的 Multi-Agent 方案。GitHub 上相关项目的 Star 数动辄上万，社区讨论热度持续攀升。

从这股热潮，我们可以看出 AI 应用的一个重要趋势：从单一模型调用走向多智能体协作。就像软件开发从单体应用演进到微服务架构，AI 系统也在探索如何通过多个专门化的 Agent 协同工作，完成更复杂的任务。

当我们仔细观察这些 Multi-Agent 系统的架构时，会发现一个规律：

MetaGPT 里有个产品经理角色，负责协调其他工程师角色；AutoGen 支持 Manager-Worker 模式；Claude Code 更是明确采用了主循环引擎加子任务代理的设计。在 OpenAI Swarm 中，也能看到 Orchestrator Agent 的影子。

这些系统都采用了某种形式的「主从」架构——有一个 Agent 负责全局协调，其他 Agent 提供专门化支持。

为什么？巧合吗？

今天我们就聊聊 Multi-Agent 系统的主从架构。从大模型的底层原理开始。

1 从大模型的原理说起

1.1 大模型的「注意力」机制

要理解为什么需要主从架构，得先理解大模型是怎么「思考」的。

大模型的核心是 Transformer 架构，而 Transformer 的灵魂是注意力机制（Attention）。简单来说，模型在生成每个 token 时，会「注意」到输入中的所有相关信息（上下文窗口内），然后综合这些信息做出决策。

这里有个关键点：大模型的每次决策都是基于它能「看到”」的全部上下文。

这就像你在做一道数学题。如果题目是”小明有 5 个苹果，给了小红 2 个”，你要回答”小明还剩几个”，你必须同时看到”5 个”和”给了 2 个”这两个信息。如果你只看到其中一部分，就无法得出正确答案。

大模型也是如此。它的智能来源于对上下文的完整理解（其智能还来源于预训练时学到的知识，模式识别、知识迁移等能力）。一旦上下文缺失或者矛盾，模型的输出质量就会急剧下降。

1.2 多个模型协作的挑战

当多个大模型（Agent）需要协作时，如何保证它们都拥有必要的上下文？

假设我们有三个 Agent 并行进行开发部署工作：

  • Agent A：负责前端开发
  • Agent B：负责后端开发
  • Agent C：负责部署运维

理想情况下，它们应该像一个经验丰富的全栈工程师一样，时刻知道其他部分的设计决策。但实际上，每个 Agent 都是独立的大模型实例，它们各自维护着自己的上下文。

这就产生了第一个问题：上下文分裂。

Agent A 决定使用 React，Agent B 决定用 Python Flask，这本来没问题。但当 Agent A 后续生成代码时假设后端返回 GraphQL，而 Agent B 实际提供的是 REST API，最终代码就无法正常工作。

并且大模型有个特性叫「自回归生成」——每个新的输出都依赖于之前的所有输出。这意味着一旦某个 Agent 做出了错误假设，这个错误会在后续生成中不断放大。

2 主从架构的设计哲学

2.1 为什么主从架构有效

主从架构的核心思想很简单：一个指挥，多个执行。一个主 Agent 掌控全局，其他从 Agent 提供子领域专业化的支持。

这个设计直接解决了上下文分裂的问题。主 Agent 始终维护着完整的任务上下文，它知道：

  • 整体目标是什么
  • 已经做了哪些决策
  • 各个部分如何配合
  • 当前的优先级是什么

从 Agent 则像是主 Agent 的「外脑」——当主 Agent 需要专门知识时，会调用相应的从 Agent，但最终的决策和执行都由主 Agent 完成。

在我们做具体实现的时候，每个不同的从 Agent 都有自己的角色和系统 Prompt。

2.2 Claude Code 的实践印证

Claude Code 的设计诠释了主从的理念。根据 Github 上逆向工程的分析，它的架构中：

nO 主循环引擎（主 Agent）负责：

  • 维护完整的代码上下文
  • 协调所有子任务
  • 做最终决策
  • 生成实际代码

I2A 子任务代理（从 Agent）负责：

  • 回答特定问题
  • 提供专业建议
  • 探索可能的解决方案

Claude Code 刻意避免了子 Agent 的并行修改。当需要调查多个方向时，主 Agent 会有限范围内并行地咨询不同的子 Agent，确保每个决策都基于最新的完整上下文。

这种设计看起来「低效」，但实际上避免了大量的错误和重做，总体效率反而更高。

2.3 生物学的启发

并且，主从架构在生物界也是有比较多例子的。

人脑就是一个典型的例子。前额叶皮质充当「主 Agent」，负责高级决策和规划。而各个专门脑区（视觉皮层、听觉皮层、运动皮层等）就像「从 Agent」，处理特定类型的信息。

所有的感官输入最终都会汇聚到前额叶皮质，由它整合信息并做出决策。即使是反射动作，大脑也会在事后「知晓」并可能调整后续行为。

这种中心化的架构经过了数亿年的进化验证。

3 主从架构的技术实现

3.1 上下文管理

实现主从架构，最核心的是上下文管理。主 Agent 需要：

1. 维护完整但精简的上下文

并不是所有信息都同等重要。主 Agent 需要智能地压缩和总结历史信息。Claude Code 使用了一个策略：

当 token 使用量达到阈值的 92% 时，触发压缩机制。关键决策被保留，而从 Agent 的中间探索过程被压缩或丢弃。这样既保持了决策的连贯性，又避免了上下文爆炸。

2. 构建结构化的决策记录

不要只是简单地拼接所有的对话历史。需要结构化地记录：

  • 任务目标和约束
  • 已做出的关键决策
  • 各决策之间的依赖关系
  • 待解决的问题队列

3. 动态调整上下文窗口

根据任务的复杂度和当前阶段，动态调整传递给从 Agent 的上下文量。初期探索阶段可以更开放，后期执行阶段需要更精确。

3.2 Agent 的设计原则

Agent 不是越智能越好，而是要专注和可控：

1. 明确的能力边界

每个从 Agent 应该有清晰定义的能力范围。比如：

  • 代码审查 Agent：只负责发现潜在问题
  • 重构 Agent：只负责改进代码结构
  • 测试 Agent：只负责生成测试用例

2. 标准化的输入输出

从 Agent 的接口要标准化，这样主 Agent 可以用统一的方式调用它们。输出格式也要规范，便于主 Agent 解析和整合。

3. 无状态设计

从 Agent 最好是无状态的，每次调用都是独立的。这样可以避免状态管理的复杂性，也便于并行化（当任务确实独立时）。

3.3 协调机制的关键点

主 Agent 的协调能力决定了整个系统的表现：

1. 任务分解策略

并不是所有任务都要分解。主 Agent 需要学会判断：

  • 简单任务直接处理
  • 复杂任务分解但保持上下文
  • 探索性任务可以并行但结果需要串行整合

2. 冲突检测与解决

即使在主从架构下，从 Agent 的建议也可能相互矛盾。主 Agent 需要：

  • 检测潜在的冲突
  • 评估不同方案的优劣
  • 做出最终决策并保持一致性

3. 优雅降级

当从 Agent 失败或不可用时，主 Agent 应该能够：

  • 尝试从其它从 Agent 获取
  • 降级到自己处理
  • 调整任务策略

4 主从架构的优势与局限

4.1 主从架构的核心优势

1. 全局一致性保证主 Agent 作为唯一的决策中心，天然保证了架构决策的一致性。不只是技术栈的选择（比如统一使用 REST 还是 GraphQL），更重要的是接口约定、错误处理策略、命名规范等细节都能保持统一。这种一致性在复杂项目中价值巨大。

2. 清晰的决策链路每个决策都有明确的来源和依据。你可以在主 Agent 的对话历史中追踪每个架构决定是如何做出的，为什么选择某个方案。这种可追溯性在调试问题或向他人解释系统设计时非常有价值。

3. 优雅的错误处理主 Agent 掌握全局状态，当某个子任务失败时，它可以准确判断影响范围并制定恢复策略。比如，如果数据库设计出错，主 Agent 知道哪些 API 设计需要相应调整。而在去中心化系统中，这种级联影响很难追踪和修复。

4. 上下文利用最大化看似串行的决策流程，实际上优化了整体效率：

  • 避免了重复劳动（多个 Agent 不会各自生成相似的代码）
  • 减少了协调开销（不需要 Agent 间的大量通信）
  • 上下文复用充分（主 Agent 的决策历史可以直接传递给从 Agent）

在 Claude Code 的实践中，这种设计让系统能在有限的 token 预算内完成相当复杂的编程任务。

4.2 主从架构的局限性

1. 主 Agent 成为性能瓶颈所有决策都要经过主 Agent，当需要并行处理多个复杂子任务时，主 Agent 的串行决策会限制整体效率。就像一个项目经理同时管理太多团队，协调成本会急剧上升。

2. 对主 Agent 能力的高度依赖系统的智能上限取决于主 Agent 的能力。如果主 Agent 对某个领域理解不深，即使有专业的从 Agent，整体表现也会受限。这就像一个不懂技术的经理，很难充分发挥技术团队的潜力。

3. 缺乏真正的协作智能主从架构本质上是”分解-执行-组合”的模式，缺少 Agent 之间的平等协商和创造性互动。在需要头脑风暴或多视角探索的任务中，这种层级结构可能限制了解决方案的多样性。

4. 任务分解的粒度难题主 Agent 需要准确判断任务分解的粒度。分得太细，协调成本高；分得太粗，从 Agent 可能无法胜任。而且随着任务复杂度增加，找到合适的分解方式越来越难。

4.3 适用场景分析

主从架构特别适合：

1. 工程化任务

  • 代码生成
  • 系统设计
  • 文档编写

这些任务需要高度的一致性和结构化。

2. 有明确目标的任务

  • 问题诊断
  • 数据分析
  • 流程自动化

目标明确时，中心化协调更高效。

3. 需要可控性的场景

  • 金融交易
  • 医疗诊断
  • 法律咨询

这些领域不能接受不可预测的行为。

不太适合：

1. 创意生成

  • 头脑风暴
  • 艺术创作
  • 探索性研究

2. 大规模并行处理

  • 日志分析
  • 图像批处理
  • 分布式爬虫

3. 对等协作

  • 多人游戏 AI
  • 群体仿真
  • 去中心化系统

5 小结

随着大模型能力的提升，主从架构也在演进：

  • 更长的上下文窗口：GPT-4 已经支持 128K 的上下文，Claude 3 甚至到了 200K。这意味着主 Agent 可以维护更完整的历史，减少信息损失。
  • 更好的指令跟随：新一代模型在指令跟随上有显著提升，从 Agent 可以更准确地理解和执行主 Agent 的指令。
  • 原生的工具调用：模型开始原生支持函数调用，这让主从 Agent 之间的接口更加标准化和可靠。

如果你要实现一个主从架构的 Multi-Agent 系统，以下是一些建议：

1. 设计清晰的 Agent 角色：不要让从 Agent 职责过于宽泛。每个从 Agent 应该像 Unix 工具一样——做一件事，并做好。

2. 实现鲁棒的错误处理

从 Agent 失败是常态，不是异常。主 Agent 需要：

  • 超时机制
  • 重试策略
  • 降级方案
  • 错误隔离

3. 优化上下文传递：控制上下文的边界，并不是所有上下文都需要传递给给到 Agent。根据任务类型，精心设计上下文的内容和格式。

4. 监控和可观测性：记录所有的决策点和 Agent 交互，后面调试和优化用得上。

Multi-Agent 的主从架构，本质上是在解决一个古老的问题：如何组织多个智能体高效地完成复杂任务。

从生物进化到人类社会，从计算机架构到分布式系统，我们一次次地发现：在需要一致性和可控性的场景下，某种形式的中心化协调是必要的。

大模型的出现并没有改变这个规律。相反，由于大模型对上下文的强依赖，主从架构变得更加重要。

随着大模型能力的提升和 Agent 技术的成熟，我们会看到更多创新的架构出现。但无论如何演进，那些基本的原则——上下文一致性、决策可控性、错误可恢复性——都是我们在实践中需要谨慎考虑的。

以上。

 

聊下 AI Agent 的 上下文工程（Context Engineering)

发表回复

2025 年确实成了 AI Agent 元年。不只是 Manus 这种通用型 Agent，还有设计领域的 Lovart、编程领域的 Claude Code 和 Cursor 等垂直产品。经常会有人问：这些 Agent 到底是如何工作的？为什么有的 Agent 看着很智能，有的却在掉链子？

大模型大家都可以用，但为啥结果差异比较大呢？

这是由于在大模型能力一致的前提下，决定 Agent 成败的，我们给它提供了多少有用的信息。这就是今天要聊的核心话题——从提示词工程到上下文工程的演进。

1. Agent 的三个核心动作

要理解上下文工程，我们得先从 AI Agent 的基本工作原理说起。简单来说，Agent 就像一个能自主完成任务的助手，它的工作流程可以概括为三个核心动作：感知、计划、行动。

1.1 感知

感知是 Agent 的第一步，也是最容易被忽视的一步。就像开车需要看清路况，Agent 需要准确理解当前的情况。

这里有个关键点：感知包含两个层面。

状态感知是对客观环境的理解。比如你让 Agent 帮你改代码，它需要知道：

  • 项目用的是什么语言和框架
  • 现有的代码结构是怎样的
  • 有哪些依赖和限制

意图感知则是理解你真正想要什么。当你说”优化这段代码”时，Agent 需要判断：

  • 是要提升性能还是改善可读性？
  • 有没有特定的性能指标要求？
  • 是否需要保持向后兼容？

很多 Agent 失败的案例，根源就在于感知出了问题。比如用户说”这个太慢了”，如果 Agent 只是机械地理解为”需要优化”，而没有深入了解具体慢在哪里、期望达到什么速度，那后续的优化很可能南辕北辙。

1.2 计划

有了准确的感知，Agent 需要制定行动计划。这就像做菜，你得先想好步骤：先切菜还是先热油，什么时候放调料。

计划能力很大程度上取决于底层的大语言模型。不同模型有不同的”性格”：

  • Claude 喜欢深思熟虑，会考虑多种可能性
  • GPT-4 比较均衡，执行标准任务很稳定
  • Gemini 更大胆，有时会提出创新方案

从技术架构上来说：

  • Gemini 侧重多模态融合和大规模上下文处理
  • Claude 专注于精确推理和复杂任务执行

但光有好模型还不够。Agent 的计划质量很大程度上取决于它掌握的信息是否充分。如果缺少关键信息，再聪明的模型也会做出糟糕的计划。

1.3 行动

最后是行动模块，让 Agent 真正能够”做事”。目前主流的实现方式是函数调用（Function Calling）——预先定义一系列工具函数，比如搜索网页、读写文件、发送邮件等，然后让模型根据需要调用这些函数。

这里面临的挑战是工具选择。当可用工具很多时，Agent 可能会困惑。就像给你一个装满各种工具的工具箱，如果不清楚每个工具的用途，很容易选错。

2. Agent 的四大支撑系统

除了核心的感知-计划-行动循环，现代 Agent 还需要四个重要的支撑系统：

2.1 记忆系统

记忆让 Agent 能够积累经验。就像人类一样，Agent 需要不同类型的记忆：

  • 工作记忆：处理当前任务的临时信息
  • 情景记忆：之前的对话和任务记录
  • 语义记忆：领域知识和最佳实践

但这里有个反直觉的发现：好的记忆系统不仅要会记住，更要会遗忘。

为什么？因为不是所有信息都值得保留。过时的信息、错误的尝试、无关的细节，如果都保存下来，反而会干扰 Agent 的判断。这就像你的电脑，定期清理缓存才能保持流畅运行。

2.2 工具系统

工具让 Agent 能够与外部世界交互。早期的 Agent 只能回答问题，现在的 Agent 可以：

  • 搜索信息
  • 操作文件
  • 调用 API
  • 甚至控制其他软件

Anthropic 推出的 MCP（Model Context Protocol）协议，试图为工具调用建立统一标准。这就像 USB 接口的标准化，让不同的工具都能方便地接入 Agent 系统。

2.3 安全系统

给 Agent 执行能力就像给孩子一把剪刀，必须要有安全措施。Manus 刚上线时就出现过安全问题，有人通过特殊的提示词，让 Agent 打包了执行环境的所有代码。

现代 Agent 通常采用多层防护：

  • 沙箱隔离：所有操作都在受控环境中执行
  • 权限管理：根据用户和场景动态分配权限
  • 审计日志：记录所有操作便于追溯

2.4 评估系统

如何判断一个 Agent 的表现？这比想象中复杂。不像传统软件有明确的对错，Agent 的输出往往有多种可能的”正确答案”。

评估需要考虑多个维度：

  • 任务完成度
  • 效率和成本
  • 用户满意度
  • 安全合规性

3. 从提示词工程到上下文工程

理解了 Agent 的工作原理，我们再来看看工程实践的演进。

3.1 提示词工程的局限

去年大家还在研究怎么写提示词。什么”你是一个专业的XX”、”请一步一步思考”，各种模板层出不穷。但很快我们发现，光靠精心设计的提示词，很难让 Agent 处理复杂任务。

原因很简单：提示词只是静态的指令，而真实任务需要动态的信息。

就像你请人帮忙，光说”帮我订个机票”是不够的，还需要告诉对方：

  • 出发地和目的地
  • 时间和预算
  • 个人偏好
  • 可用的支付方式

3.2 上下文工程的兴起

上下文工程是一个更宏大的概念。也有人说又是套壳包装了一下。但是我觉得非包装，而是大家对于如何和大模型交互有了更全面的认知。用 Shopify CEO Tobi Lütke 的话说，上下文工程是「提供所有必要上下文，让任务对 LLM 来说变得可解的艺术」。

上下文不只是提示词，而是 Agent 在生成回复前能看到的所有信息：

  1. 指令上下文：系统提示词、任务说明、行为规范
  2. 对话上下文：当前和历史对话记录，包含用户意图，如输出的结构
  3. 知识上下文：相关文档、数据库信息、搜索结果
  4. 工具上下文：可用函数的描述和使用方法
  5. 状态上下文：环境变量、用户偏好、系统状态

更重要的是，上下文工程是一个动态系统，不是静态模板：

  • 它根据任务类型选择相关信息
  • 它随着对话进展更新内容
  • 它平衡信息的全面性和简洁性

从终局的逻辑来看，上下文工程的结果还是给到大模型的提示词。

Google DeepMind 的一位工程师写了一篇博客，地址：www.philschmid.de/context-eng… 其中有一张图，如下：

image.png

讲了七个部分：

  • 指令 / 系统提示词：定义模型在对话过程中行为的初始指令集，可以/应该包含示例、规则等。
  • 用户提示词：来自用户的即时任务或问题。
  • 状态 / 历史记录（短期记忆）：当前对话，包括导致此刻的用户和模型响应。
  • 长期记忆：持久的知识库，从许多先前的对话中收集而来，包含已学习的用户偏好、过去项目的摘要，或被告知要记住以供将来使用的事实。
  • 检索信息（RAG）：外部的最新知识，从文档、数据库或API中获取的相关信息，用于回答特定问题。
  • 可用工具：它可以调用的所有函数或内置工具的定义（例如：check_inventory（检查库存）、send_email（发送邮件））。
  • 结构化输出：关于模型响应格式的定义，例如JSON对象。

这七个部分都包含在上面的 5 个上下文中。

4. 上下文工程的核心挑战

Karpathy 把 LLM 比作新型操作系统，上下文窗口就像 RAM。这个比喻很精确——就像内存管理是操作系统的核心功能，上下文管理是 Agent 工程的核心挑战。

主要挑战包括：

1. 容量限制 即使 Claude 已支持 20 万 token，Gemini 甚至支持 200 万 token，但这些容量在复杂任务面前仍然捉襟见肘。一个长时间运行的 Agent，轻易就能产生海量的交互记录。

2. 注意力分散 研究发现，当上下文过长时，模型会出现”迷失在中间”现象——对开头和结尾的内容记忆较好，但中间部分容易遗漏。这就像看一本太厚的书，中间章节的内容总是记不清。

3. 性能退化 过长的上下文不仅增加成本和延迟，还会降低模型的推理能力。Drew Breunig 总结了几种典型问题：

  • 上下文污染：错误信息影响后续判断
  • 上下文干扰：无关信息分散注意力
  • 上下文冲突：不同部分信息相互矛盾

5. 上下文工程的四种核心策略

面对这些挑战，有四种核心策略：

5.1 有选择的保存

这是把重要信息保存到上下文窗口之外，需要时再取用。

便签本模式：Agent 在执行任务时记笔记，保存中间结果和重要发现。Anthropic 的研究系统会在开始时制定计划并保存，避免因上下文截断而丢失。

长期记忆：跨会话保存的信息，包括用户偏好、领域知识、成功案例等。ChatGPT、Cursor 都实现了这种机制。

关键是要有选择地保存。不是什么都值得记住，需要识别真正有价值的信息。

5.2 选择对的信息

保存了信息，还需要在合适的时候取出来用。

记忆检索：当积累了大量记忆后，如何找到相关的部分？简单的关键词匹配往往不够，需要语义理解。ChatGPT 会根据当前对话内容，自动检索相关的历史记忆。

工具筛选：当可用工具很多时，全部列出会让模型困惑。研究表明，通过语义匹配只提供相关工具，可以将准确率提升 3 倍。

知识召回：这就是 RAG（检索增强生成）的核心。但实现好的 RAG 系统很有挑战。Windsurf 的工程师分享说，他们结合了多种技术：向量检索、关键词搜索、AST 解析、知识图谱，最后还要重排序。

5.3 压缩提炼

当信息太多时，需要压缩和精炼。

轨迹总结：Claude Code 的”自动压缩”功能就是典型例子。当上下文使用超过 95% 时，它会总结整个对话历史，保留关键信息的同时大幅减少 token 使用。

定点压缩：在特定环节进行信息精炼。比如搜索工具返回大量结果后立即总结，或者在不同 Agent 交接时压缩传递的信息。

智能裁剪：根据相关性和时效性，自动删除不必要的信息。可以基于时间（删除过早的对话）、频率（删除很少用到的信息）或相关性（删除与当前任务无关的内容）。

5.4 分而治之

把不同类型的信息分开管理，避免相互干扰。

多智能体架构：让不同的 Agent 处理不同的子任务，每个都有自己的上下文空间。Anthropic 的研究显示，多个专门的 Agent 往往比一个通用 Agent 表现更好。

环境隔离：HuggingFace 的做法很有启发——让 Agent 生成代码，在沙箱中执行，只把必要结果返回。这样可以把大量中间数据隔离在执行环境中。

状态分离：通过精心设计的状态结构，把不同类型的信息存在不同字段，只在需要时才暴露给模型。

6 小结

上下文工程正在成为 AI 工程师的核心技能。随着 Agent 能力的提升，如何管理和优化上下文将变得更加重要。

几个值得关注的发展方向：

  1. 自适应上下文：Agent 自己学习什么信息重要，自动调整上下文策略
  2. 分布式上下文：跨多个 Agent 和系统共享和同步上下文
  3. 个性化上下文：根据用户特点和偏好定制上下文管理策略
  4. 实时优化：在运行时动态调整上下文，而不是预先设定

当前不再是简单地“调教”模型说出正确的话，而是构建一个完整的信息系统，让 Agent 真正理解任务、掌握必要信息、做出正确决策。这种转变，预示着 AI Agent 正在从实验室的玩具，变成真正能够解决实际问题的工具。

如 Cognition 所说：”上下文工程实际上是构建 AI Agent 的工程师的头号工作。”。

以上。