---
title: AI Coding 工作流中的上下文边界
date: '2025-12-22 10:01:40'
draft: false
summary: 更稳的 AI Coding 流程不是让一个 Agent 包打天下，而是把实现、审查和修复拆给不同角色，并限制各自上下文。
slug: ai-coding-workflow-with-specialized-agents
syndication:
- platform: Weibo
  url: https://weibo.com/1648815335/Qjy7hgZCM
tags:
- ai
- coding-agent
- workflow
- github
topics:
- ai
type: post
---

最近我自己摸索出一套更实用的 `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。