做 Agent 系统时，人们很容易有一个直觉：模型知道得越多，应该就越聪明。

于是任务说明、历史对话、用户资料、工具返回、执行日志、其他 Agent 的思考结果，能塞的都塞进 Context。Planner 看全部，Worker 看全部，Reviewer 也看全部，Sub-Agent 再把 Parent 的上下文完整继承下来。

结果往往很反直觉：Token 花得更多，响应更慢，模型反而更容易跑偏。

问题并不在于模型“看不懂这么多信息”，而在于我们经常把 Context 当成了数据库。

其实，Context 更像一个人的工作台。真正重要的不是桌上资料有多少，而是当前这一步，桌上放的是不是正确的资料。

Context 的价值，不等于信息量

假设你让一个同事处理客户退款。

你可以把公司全部产品文档、过去三年的客服记录、所有退款案例、完整组织架构和财务制度都发给他。

这些信息可能都“相关”，但显然没有必要。

他真正需要的，也许只有当前订单、退款规则、客户诉求和可执行的操作权限。

模型也是一样。

过多 Context 会带来三个问题。

一个是注意力竞争。真正决定当前任务的信息，会被大量低相关内容包围。

另一个是信息冲突。历史记录里可能存在旧规则、旧计划、已经失效的判断。如果没有明确优先级，模型需要自己猜“到底听谁的”。

还有一个常被忽略的问题：Context 会影响行为。模型看到的信息，不只是知识，也可能变成暗示。

所以设计 Context 时，一个更有用的问题不是：

“还有什么信息可以给模型？”

而是：

“如果删掉这条信息，当前 Step 的决策质量会下降吗？”

如果答案是否定的，它大概率不应该进入当前上下文。

每个 Step，只拿完成当前决策所需的信息

Agent 的执行过程通常不是一个巨大任务一次完成，而是一系列 Step。

例如：“研究三家竞争对手，并形成产品建议。”

Planner 当前需要做的是拆任务。它需要知道目标、约束、已有资源，以及什么算完成。

负责搜索竞争对手资料的 Worker，需要的是明确的搜索对象、输出字段和搜索工具。

负责写最终建议的 Worker，则应该看到已经整理后的竞争信息，而不是前面几十次搜索请求的原始日志。

这意味着 Context 最好围绕“当前决策”组织，而不是围绕“整个任务”组织。

可以用一个简单框架判断：

Goal：这一 Step 要完成什么？

Constraint：有什么边界不能突破？

Evidence：做判断必须依赖哪些事实？

State：前面哪些结果会影响当前状态？

Capability：当前可以使用哪些工具或动作？

如果一段信息不属于这几类中的任何一类，就应该警惕它是不是只是“因为已经有了，所以顺便塞进去”。

Context Engineering 的核心工作，很多时候不是补充信息，而是持续删除低价值信息。

Planner 和 Worker 不应该看到完全相同的世界

Planner 和 Worker 的职责不同，Context 也应该不同。

Planner 负责回答：“接下来应该做什么？”

因此它需要看到全局目标、关键约束、已有进展、任务依赖和可用能力。

Worker 负责回答：“这一步应该怎么做好？”

它更需要局部任务说明、必要输入、工具规范和输出格式。

可以想象一个项目经理和工程师。

项目经理需要知道整体项目为什么做、当前进度、依赖关系和风险。但具体执行某个接口联调的工程师，没有必要每天阅读完整项目会议纪要。

反过来也一样。

工程师需要大量技术细节，但 Planner 未必需要把每个 API 返回字段都装进上下文。

一种常见的 Agent 设计问题，就是让 Planner 和 Worker 共用一份不断增长的 Conversation History。

这样虽然实现简单，却把职责边界彻底抹掉了。

更合理的方式是共享“状态”，而不是共享“所有文本”。

Reviewer 需要证据，但未必需要完整执行轨迹

Reviewer 的任务是判断结果是否正确，因此很自然会产生一个想法：

既然要审查，就让它看看 Agent 从头到尾是怎么做的。

但这可能制造新的偏差。

假设 Worker 在执行过程中走了很多弯路，最终答案却是正确的。如果 Reviewer 阅读了完整轨迹，它可能被中间的错误推理影响。

另一种情况更危险：Reviewer 看到 Worker 很详细、很自信的解释后，可能更倾向于接受结果，而不是独立检查。

Reviewer 真正需要的通常是三类东西：

任务要求、最终结果、可以验证结果的证据。

必要时，可以再提供关键操作记录，例如调用了什么工具、使用了什么数据源、做过哪些不可逆动作。

但“所有执行过程”不应该默认进入 Reviewer Context。

好的 Reviewer 应该尽可能拥有独立判断空间。

这和代码审查很像。

你真正希望 Reviewer 检查代码是否满足需求，而不是先听开发者讲二十分钟“我是怎么一步一步想到这个实现的”。

Sub-Agent 继承的应该是任务边界，而不是 Parent 的记忆

Sub-Agent 还有一个非常常见的问题：Context 继承。

最简单的实现方式当然是 Parent 创建 Sub-Agent 时，把自己的全部 Context 复制过去。

这很方便，但扩展以后会迅速失控。

假设 Parent 已经运行了二十轮，里面包含用户聊天、搜索结果、多个工具日志和几个失败方案。现在它创建一个 Sub-Agent，只是为了“比较两个数据库方案”。

这个 Sub-Agent 真正需要的可能只有比较目标、约束条件、候选方案和输出标准。

如果把 Parent Context 全部继承过去，相当于让一个临时顾问入职第一天先阅读整个公司邮箱。

更好的设计是让 Parent 生成一个明确的 Task Packet：

当前目标是什么；
已确认事实是什么；
必须遵守哪些约束；
允许使用什么能力；
最终应该返回什么。

这样 Sub-Agent 得到的是经过压缩和选择的任务上下文，而不是 Parent 的全部人生经历。

好的 Context 系统，关键能力是“选择”

很多 Agent 系统最终都会遇到同一个瓶颈。

一开始大家关心 Prompt 怎么写、模型怎么选、工具怎么接。系统变复杂以后，真正困难的问题逐渐变成：

谁应该知道什么？

什么时候知道？

知道到什么粒度？

哪些信息应该共享，哪些应该隔离？

这时 Context 已经不再是 Prompt 的附属品，而变成了 Agent 架构的一部分。

一个实用原则是：让每个 Agent、每个 Step，只看到完成当前职责所需的最小充分信息。

“最小”可以减少噪声、冲突和成本；“充分”则保证模型不会因为缺少关键事实而盲目行动。

所以下次设计 Agent 时，与其问“模型还能看到什么”，不如为每一个 Step 多问一句：

它现在到底需要根据哪些信息，做出什么决定？

当这个问题足够清楚时，Planner、Worker、Reviewer 和 Sub-Agent 的 Context 边界，往往也就自然清楚了。