AI Coding 工作流中的上下文边界

最近我自己摸索出一套更实用的 AI Coding 工作流，核心不是“找一个最强的 Agent 把所有事情包掉”，而是把角色拆开，让不同 Agent 分别维护不同层次的上下文。

第一类 Agent，我更愿意让它扮演产品经理或者架构师。

它的职责不是写代码，而是：

• 和我讨论需求
• 收敛边界和架构
• 拆分任务
• 最后把结果落成可执行的 GitHub issue

如果任务复杂，就继续往下拆成多个子 issue。这样做的关键价值在于，让这个 Agent 尽量不被实现细节淹没，始终保留全局视角。

第二类是 Coder Agent。

它只拿一个明确的 issue，目标就是完成代码、提交 PR。如果权限给够，而且流程边界清楚，它的执行效率会明显更高。这里最忌讳的是让它一边写代码，一边不断回头重新讨论需求，这样上下文很快就乱了。

第三类是 Reviewer Agent。

代码提交后，让另一个 Agent 或者像 GitHub Copilot 这类工具去 review。review 结果再交回给 Coder Agent 修复，形成一个闭环。

所以这套流程更像是：

1. 架构 Agent 负责把模糊问题变清楚。
2. Coder Agent 负责把清楚的问题变成代码。
3. Reviewer Agent 负责把代码里的问题再反馈回去。

这个模式的好处是，每个角色都只维护和自己最相关的上下文，不会因为上下文膨胀太快而迅速失真。

当然，这个流程现在还不算完全顺滑，几个典型问题我自己也踩到了：

• 如果给 Coder Agent 很高权限，又担心它误操作删错项目外文件。
• Reviewer Agent 还不太会高质量地使用 GitHub 的 inline review comment。
• 拉取 PR review comments 时，接口结果过长，有时会被中间层截断。

这些问题说明，今天阻碍 Agent 协作自动化的，已经不只是模型能力，而是工具链边界、权限模型和上下文传递机制。

所以我最近的一个方向，是把 Coding Agent 放进容器里跑，再和 GitHub Actions 之类的自动化链路配合，把上面这套流程尽量收成一个更稳定的系统。

我现在越来越倾向于认为，未来真正成熟的 AI Coding 体系，不是一个万能智能体，而是一组角色清晰、边界明确、通过标准接口协作的 Agent。