AI Coding Agent 如何工程化：从上下文污染到多 Agent 分工
相信大家应该都有体会，AI Coding Agent 正在从“模型会不会写代码”，变成“Agent 系统能不能稳定运行”。当 AI Coding Agent 接入代码仓、命令行和测试环境，并持续执行长任务时，它要生成代码、管理上下文、降低工具噪声、拆分任务，和处理各种写入权限。
如何设计更好的 Agent 工程，成了我们不得不面对的问题。在这篇文章中，我们将从上下文管理和多 Agent 分工两个角度，拆解 Coding Agent 走向工程化时遇到的关键问题。
长上下文里的噪声
我们很容易把 Agent 的能力和上下文窗口是否变大关联起来，却忽略了一件事：上下文越长，说明模型能看到的代码、日志、文档和历史操作就越多。日益增长的长上下文除了带来更多的信息，也带来更多的噪声。
一个 Agent 在代码库里工作时，会做大量探索性动作：找文件、读代码片段、跑命令、看报错信息、查找某个函数的调用关系、验证代码是否如期运行……这些动作对当时的任务是有用操作，却不一定都值得长期保留。比如，Agent 为了找到一个函数，会连续执行几次搜索；为了确认一个依赖，可能打开多个无关文件；为了排查一个测试失败，可能读一长串日志。虽说它们都是某次 Coding 工作过程的一部分，但未必都值得留在主上下文里。
由此带来的问题就是，一旦这些内容持续堆积，模型后面做判断时看到的就不再是清晰的任务上下文，而是一团混合了历史记录、无关输出、过期假设和中间过程的材料。
这就是上下文污染。
它可能不会立马导致系统崩溃，但会让 Agent 的判断变得不稳定：该记住的没记住，不该被影响的反而被影响。最后，模型可能因为上下文环境太差，开始做出奇怪的决策。
Daniel San 在「Keep your Claude Code context clean with Subagents」中就提到过grep / find / ls会留在上下文；而使用 Subagent，可以把这些临时探索隔离出去，让主上下文保持相对干净。
Subagent 与上下文隔离
从字面上来说，Subagent 不是多一个 Agent 来处理任务。它是一种上下文隔离机制。主 Agent 不需要把所有搜索、试错、排查过程都塞进自己的上下文。它可以把一部分任务交给 Subagent：“帮我找一下这个函数在哪里被调用了”“帮我读一下这几个文件，总结相关逻辑”“帮我排查这个报错最可能来自哪里”“帮我确认这个模块有没有类似实现”。
Subagent 会在自己的上下文窗口里完成主 Agent 交代的探索工作，在消化掉大量过程性信息之后，只返回一个相对干净的结论。
这样一来，主 Agent 看到的就不是一堆命令输出，而是经过压缩后的有效信息。它的上下文不会被临时噪声持续污染，后面它的决策也更容易保持稳定。这很像工程协作中的分工。在一个团队里，不会所有人都挤在同一份文档里同时书写，一般是有人查资料，有人复核，有人整理结论，最后再由一个人把结果写进主线里。
Subagent 也是类似逻辑：它承担探索和压缩的工作，主 Agent 则继续保留任务主线。
多 Agent 的写入权
Subagent 的上下文隔离解决的是“信息怎么进来”的问题。接下来还有另一个问题：Agent 该如何行动，行动权又该如何分配。
可能会有人觉得多 Agent 系统是一群 Agent 合理分工，同时工作：这个写前端，那个写后端，还有一个改测试，最后一起合并。这个画面看起来很合理，也很像现实中的团队协作。
但在 AI Coding Agent 里，这种方式是很容易出问题的。毕竟写代码不是单纯的劳动分配。一个 Agent 要修改一段代码，需要做很多隐含决策：采用什么风格、怎么处理边界情况、是否沿用原有模式、这个模块的职责边界应该怎么划。如果多个 Agent 并行写代码，它们可能各自做出一套局部合理、但整体会发生冲突的判断。问题不在于代码有没有写出来，而在于系统一致性被破坏了。
Cognition 的实践分享「Multi-Agents: What’s Actually Working」中提到过，过去反对多 Agent 的一个重要原因，就是并行 Agent 会在代码风格、边界情况和代码模式上做出互相冲突的隐含选择，最终让产品变得脆弱。
所以，多 Agent 真正要解决的问题是：哪些 Agent 可以参与搜索、分析、审查和建议；哪些 Agent 可以执行命令、调用工具、跑测试，甚至改文件；最关键的一环是，由谁写入文件：接受哪个方案、忽略哪些建议、是否扩大修改范围、如何保持项目风格一致。
判断权与写入权
Cognition 的实践告诉我们，目前更可行的多 Agent 结构是让多个 Agent 围绕一条主写入路径提供支持，而不是让一群 Agent 自由行动。也就是说：
Agent A 负责搜索代码库；
Agent B 负责审查 diff；
Agent C 负责提供更强模型的判断；
Agent D 负责拆解更高层任务；
…
多 Agent 可以一起参与工作，但最后真正改代码、拍板方案、继续推进任务的那条主线，不能乱。这就是“智能分布，写入收敛”的具体体现。
而多 Agent 系统今天最有效的方式，是写入保持单线程，额外的 Agent 贡献智能，避免到处行动。
这句话背后的工程含义很重要。多 Agent 可以扩大判断来源，但写入权要控制好。否则，系统会从“多个 Agent 协作”变成“多个 Agent 各自带着不同上下文修改同一个系统”。
Review Agent 与干净上下文
代码审查是一个典型的多 Agent 分工场景。在 Cognition 的实践中，Devin 负责生成代码并提交 PR，Devin Review 负责审查改动、发现潜在问题。
它和前面提到的 Subagent 有相似之处：都利用了相对干净的上下文。但二者的角色不同。Subagent 更偏向任务过程中的信息探索和压缩，Review Agent 则是在主 Agent 完成写入后，围绕最终 diff 做独立审查。
所以，这里的重点不只是“多了一层检查”，而是多 Agent 分工里出现了更清晰的角色边界：主 Agent 负责写入，Review Agent 负责复核；Review Agent 提出问题和风险，最终是否修改，仍然回到主线判断。
图注：Review Agent 的价值，是用更干净的上下文重新看 diff，发现 Coding Agent 在长任务路径中可能忽略的问题。
Smart Friend 与判断增强
“Smart Friend” 模式也是一个有意思的实践。它的思路是：日常任务可以由较快、较便宜的主模型推进；当任务变得复杂时，再调用更强、更贵的模型提供判断。Cognition 在 Windsurf 中尝试过让较快的 SWE-1.5 搭配 Sonnet 4.5 做规划，以在成本、速度和质量之间取得平衡。
这个模式看起来符合直觉，但难点也很明显：
主模型怎么知道自己什么时候该求助？
求助时该带什么上下文？
它应该问一个具体问题，还是让强模型整体判断下一步该怎么做？
强模型返回建议后，主模型又该如何理解和执行？
如果主模型不够强，它可能连“这个问题已经超出我的能力范围”都判断不准。它也可能把一堆杂乱上下文直接丢给强模型，让强模型重新在噪声里找线索。
Smart Friend 模式的重点就是上下文传递和沟通方式的设计，而不只是简单调用一个更强模型。强模型适合在关键时刻补位判断，但不一定要接管执行。它可以提醒主 Agent 哪个方向有风险、哪个文件该检查、下一步要验证什么。真正的代码写入，仍然应该回到主流程里完成。
图注：Smart Friend 模式的关键，是让主 Agent 知道什么时候该求助、带什么上下文、如何消化强模型给的建议。
Agent 管理与组织结构
当任务进一步变大，多 Agent 就会遇到更高层的组织问题。一个任务可能不是只改一个 PR，而是跨多个 PR、多个服务，持续执行几天甚至一周。这个时候，系统需要的不只是一个会写代码的 Agent，还要有能拆解任务、派发任务、汇总结果的工作流。
在更高层的多 Agent 结构里，Manager Agent 可以把较大的任务拆成多个部分，生成子 Coding Agent 来执行，并通过内部 MCP 协调进展。但这里的问题也很明显。如果 Manager Agent 缺少足够的代码库上下文，却又过度约束子 Agent 该怎么做，就可能适得其反。子 Agent 也有可能误以为自己和 Manager Agent 共享状态，但实际上它们并不共享状态。
一个比较合理的结构是：Manager 负责拆分任务，子 Agent 执行，Manager 综合结果并向用户汇报。这类结构听起来没有“蜂群式 Agent 协作”那么酷，但更接近真实可落地的工程系统。这也是 Coding Agent 工程化真正要解决的问题：模型能力决定它能不能做事，工程系统决定它能不能持续、稳定、可控地做事。
参考资料：
Daniel Avila：Claude Code 长会话里的上下文污染（https://x.com/dani_avila7/status/2048486242321662189）
Walden Yan：Multi-Agents: What’s Actually Working（https://cognition.ai/blog/multi-agents-working）