相信大家应该都有体会，AI Coding Agent 正在从“模型会不会写代码”，变成“Agent 系统能不能稳定运行”。当 AI Coding Agent 接入代码仓、命令行和测试环境，并持续执行长任务时，它要生成代码、管理上下文、降低工具噪声、拆分任务，和处理各种写入权限。

如何设计更好的 Agent 工程，成了我们不得不面对的问题。在这篇文章中，我们将从上下文管理和多 Agent 分工两个角度，拆解 Coding Agent 走向工程化时遇到的关键问题。

## 长上下文里的噪声

我们很容易把 Agent 的能力和上下文窗口是否变大关联起来，却忽略了一件事：上下文越长，说明模型能看到的代码、日志、文档和历史操作就越多。日益增长的长上下文除了带来更多的信息，也带来更多的噪声。

一个 Agent 在代码库里工作时，会做大量探索性动作：找文件、读代码片段、跑命令、看报错信息、查找某个函数的调用关系、验证代码是否如期运行……这些动作对当时的任务是有用操作，却不一定都值得长期保留。比如，Agent 为了找到一个函数，会连续执行几次搜索；为了确认一个依赖，可能打开多个无关文件；为了排查一个测试失败，可能读一长串日志。虽说它们都是某次 Coding 工作过程的一部分，但未必都值得留在主上下文里。

由此带来的问题就是，一旦这些内容持续堆积，模型后面做判断时看到的就不再是清晰的任务上下文，而是一团混合了历史记录、无关输出、过期假设和中间过程的材料。

这就是上下文污染。

它可能不会立马导致系统崩溃，但会让 Agent 的判断变得不稳定：该记住的没记住，不该被影响的反而被影响。最后，模型可能因为上下文环境太差，开始做出奇怪的决策。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/aa0ee42c95c97c399d2ca635a2b5f963.png)

Daniel San 在「[Keep your Claude Code context clean with Subagents](https://x.com/dani_avila7/status/2048486242321662189)」中就提到过 `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](https://cognition.ai/blog/multi-agents-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 提出问题和风险，最终是否修改，仍然回到主线判断。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/bdcedaaa52aa2b1cb4a01f904e125ea3.png)

图注：Review Agent 的价值，是用更干净的上下文重新看 diff，发现 Coding Agent 在长任务路径中可能忽略的问题。

## Smart Friend 与判断增强

“Smart Friend” 模式也是一个有意思的实践。它的思路是：日常任务可以由较快、较便宜的主模型推进；当任务变得复杂时，再调用更强、更贵的模型提供判断。Cognition 在 Windsurf 中尝试过让较快的 SWE-1.5 搭配 Sonnet 4.5 做规划，以在成本、速度和质量之间取得平衡。

这个模式看起来符合直觉，但难点也很明显：

- 主模型怎么知道自己什么时候该求助？
    
- 求助时该带什么上下文？
    
- 它应该问一个具体问题，还是让强模型整体判断下一步该怎么做？
    
- 强模型返回建议后，主模型又该如何理解和执行？
    

如果主模型不够强，它可能连“这个问题已经超出我的能力范围”都判断不准。它也可能把一堆杂乱上下文直接丢给强模型，让强模型重新在噪声里找线索。

Smart Friend 模式的重点就是上下文传递和沟通方式的设计，而不只是简单调用一个更强模型。强模型适合在关键时刻补位判断，但不一定要接管执行。它可以提醒主 Agent 哪个方向有风险、哪个文件该检查、下一步要验证什么。真正的代码写入，仍然应该回到主流程里完成。

![](https://developer.qcloudimg.com/http-save/yehe-12464096/82a105eeee4ddb89d6cc3d5ec8456cf2.png)

图注：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)（https://x.com/dani_avila7/status/2048486242321662189）
    
- Walden Yan：[Multi-Agents: What’s Actually Working](https://cognition.ai/blog/multi-agents-working)（https://cognition.ai/blog/multi-agents-working）

相信大家应该都有体会，AI Coding Agent 正在从“模型会不会写代码”，变成“Agent 系统能不能稳定运行”。当 AI Coding Agent 接入代码仓、命令行和测试环境，并持续执行长任务时，它要生成代码、管理上下文、降低工具噪声、拆分任务，和处理各种写入权限。

AI Coding Agent 如何工程化：从上下文污染到多 Agent 分工

复杂任务不仅需要会写代码 Agent，更需要能够负责派活、整理结果与汇报 Manager Agent~

人工智能

架构设计

开发工具

本文探讨AICodingAgent工程化中的关键问题，聚焦上下文管理和多Agent分工。长上下文带来信息过载和噪声污染，Subagent机制能有效隔离探索过程。多Agent系统需遵循"智能分布，写入收敛"原则，通过角色边界划分确保系统一致性。文章还分析了ReviewAgent、SmartFriend等实践模式，指出工程系统设计对Agent稳定运行的决定性作用。

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

本文探讨AICodingAgent工程化中的关键问题，聚焦上下文管理和多Agent分工。长上下文带来信息过载和噪声污染，Subagent机制能有效隔离探索过程。多Agent系统需遵循"智能分布，写入收敛"原则，通过角色边界划分确保系统一致性。文章还分析了ReviewAgent、SmartFriend等实践模式，指出工程...

AI Coding Agent 如何工程化：从上下文污染到多 Agent 分工-腾讯云开发者社区-腾讯云

AI Coding Agent 如何工程化：从上下文污染到多 Agent 分工

AI Coding Agent 如何工程化：从上下文污染到多 Agent 分工

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐