多Agent协作实战：从一个人硬扛到四条AI员工，需求到上线的分工与交接复盘

2026年8月24日，我又被一个新功能整破防了。

事情不大：给一个SaaS后台加一个CSV批量导入，顺便做重复数据检测和导入结果摘要。我一开始还是老路子，打开Claude Code，把需求、设计稿、历史代码一股脑丢进去，让它"把功能做了"。结果三个小时过去，它能跑，但验收时冒出4个bug：空文件没处理、重复判定逻辑反了、一个接口命名前后不一致、导入大文件直接OOM。那天晚上我盯着账单：18.5刀，1.2M token，外加28分钟人工返工。我不是在修bug，我是在给AI擦屁股。

于是我就动了心思：既然一个人硬扛全栈会累，那一个Agent硬扛全栈会不会也累？能不能把需求理解、架构设计、代码实现、代码审查拆成四个认知角色，让不同模型各干一摊？过去一个月，我用Kimi、Claude Code、Codex、DeepSeek搭了一条最小可跑的多Agent流水线。今天这篇不是概念科普，是我的实战踩坑记录，带数字、带配置、带结论。

01 问题：单Agent的上下文会在全栈任务里炸掉

我之前的用法和很多独立开发者一样：打开一个最强的模型，把所有上下文塞进去，让它端到端搞定。短平快的CRUD确实爽，但一旦任务跨越需求理解→架构设计→代码实现→自检，单Agent就开始"人格分裂"。它既是产品经理，又是架构师，又是码农，又是测试，上下文里塞了太多互相冲突的目标。

以CSV导入为例，Claude Code在前10分钟还在跟我讨论"重复判定是按邮箱还是按手机号"，后10分钟已经去纠结React表格的列宽；等我让它补测试，它又回头改接口命名。最终产出的代码里有三处接口不一致、一处类型错误、一处没处理空文件。我统计了一下：有效交互时间大约110分钟，其中40分钟全在跟它掰扯"我们刚才不是这么说的"。

我也试过用GPT-4.1一统全局，结果它在长上下文里的代码一致性更差，成本也没优势。单Agent方案真正的痛点不是模型不够聪明，而是一个上下文里同时存在太多决策维度。需求理解需要发散，架构设计需要收敛，代码实现需要精确，代码审查需要挑剔——这四个目标天然冲突，全压在一个会话里，不炸才怪。

更隐蔽的是成本。Claude Code的Agent模式会在每次思考时反复读取整个工作区，1.2M token里有将近一半是重复扫描。18.5刀对于个人项目不算小，但关键不是钱，而是心智负担：你时时刻刻在盯着一个"全能助手"别跑偏。

这个阶段的教训就一句话：一个人硬扛全栈可以，但别指望一个Agent也硬扛全栈。 我需要的不是更强的模型，而是把任务切成几棒，每棒交给最适合的人。

02 试错：四模型分工听起来美，交接却一地鸡毛

我决定按认知角色拆分：

• Kimi：负责需求蒸馏。它上下文长，我给它丢需求文档、飞书妙记转录、设计稿链接，让它输出结构化PRD。
• Claude Code：负责架构与测试。它代码理解强，先写接口契约和测试用例，定好"规矩"。
• Codex：负责代码实现。OpenAI的Codex在纯编码上又快又听话，照着测试补实现。
• DeepSeek：负责审查与成本优化。DeepSeek-Coder便宜，专做diff review和简化建议。

理想很丰满，现实第一周我就踩了四个大坑。

第一坑：交接不是甩链接。 我最开始让Kimi输出一份3000字的PRD markdown，直接喂给Codex。结果Codex只看标题和代码示例，把"支持10万行CSV"这条非功能性需求漏了，生成的实现用了一次性读入内存。问题不在模型，在于交接格式。后来改成带字段约束的prd.json，每个需求项有ID、优先级、验收标准、非功能约束，下游必须逐条确认。

第二坑：每个模型都想改接口。 Claude定的函数签名是parse_csv(file_stream, options)，Codex写着写着变成parse_csv_buffer(buffer)，DeepSeek又建议改成parse_csv(file_stream)但参数语义不同。三天下来接口文件像战场。最后我加了一道接口冻结机制：Claude输出interface.lock，里面锁定函数签名、错误码、数据库字段；下游若要改，必须先在handoff.yaml里写变更理由并触发人工确认。

第三坑：Reviewer会变成 cheerleader。 第一次让DeepSeek审查，提示词写得太温和，它全是"整体不错，建议再优化"。这还不如不审。后来我改成严格的reviewer prompt，要求它必须按Severe/Major/Minor分级，Severe直接打回重写。同时给Codex加了"只修被指出的问题，禁止额外重构"的约束，否则它会顺手改出一堆新bug。

第四坑：编排框架是智商税。 我一开始被某开源Multi-Agent框架吸引，学DAG、定义工具、配状态机，折腾两天发现它给我的收益就是调API。对于个人开发者和小团队，一条线性流水线加两个条件回环就够了。我现在用的编排器就是100行Python，读JSON状态、调SDK、跑测试、写日志。别为用框架而用框架。

03 落地：我用100行Python串了一条流水线

现在的流程长这样：Kimi产PRD → Claude定架构和测试 → Codex写实现 → DeepSeek审diff → 自动跑测试 → 人工最终合并。每个阶段之间有一份handoff.yaml，记录上游产物哈希、变更文件、未决决策、测试结果。

我把核心配置贴出来，可以直接参考。

Kimi需求蒸馏：

kimi_client = OpenAI(
    api_key=os.getenv("KIMI_API_KEY"),
    base_url="https://api.moonshot.cn/v1"
)
system = """
你是一名需求分析师。只输出结构化PRD，禁止写代码。
必须包含：背景、用户故事、验收标准（每条可测试）、非功能约束、风险点。
输出格式为JSON，字段名固定。
"""
prd = kimi_client.chat.completions.create(
    model="kimi-latest",
    messages=[
        {"role": "system", "content": system},
        {"role": "user", "content": raw_requirements}
    ],
    temperature=0.2
)

Claude Code架构与测试： 我给它加了项目级提示文件.claude/CLAUDE.md：

1. 先写测试，再写实现。
2. 所有函数必须带类型注解。
3. 不要修改 interface.lock 中的签名。
4. 输出 ARCHITECTURE.md 说明模块关系。
5. 测试必须覆盖空文件、超大文件、重复数据三种场景。

Claude Code用Sonnet跑Agent模式，每次只处理一个任务包，避免它东拉西扯。

Codex实现： .codex/config.yaml：

model: codex-latest
instructions: |
  - 只根据已有测试补实现，不要新增函数。
  - 禁止重构与当前任务无关的代码。
  - 读取 interface.lock 和 handoff.yaml 后再开始。
  - 输出变更摘要到 IMPLEMENTATION.md。

DeepSeek审查：

review_prompt = """
你是一名资深代码审查员。审查以下git diff，按Severe/Major/Minor分级。
Severe包括：安全漏洞、逻辑错误、接口破坏、未处理异常。
只评论与本次变更相关的问题，不要泛泛而谈。
输出JSON：{"summary": "...", "blockers": [...], "suggestions": [...]}
"""

模型用deepseek-coder-v2，温度0.0，便宜且稳定。

三阶质检： - 第一阶：Codex自身跑pytest，失败直接重试一次。 - 第二阶：DeepSeek审diff，有Severe就回退给Codex，最多循环3次。 - 第三阶：我人工过一遍handoff.yaml和最终diff，控制在5-10分钟。

这个回环看起来增加了步骤，实际把"写完再返工"变成了"中途拦截"。回到CSV导入那个需求，跑完整条线的数字如下：

• 端到端耗时：42分钟（Kimi 8分钟、Claude 12分钟、Codex 18分钟、DeepSeek 4分钟，编排几乎不占时间）。
• API成本：7.2美元，约52元人民币。其中Kimi $0.5、Claude $3.8、Codex $2.5、DeepSeek $0.4。
• Token消耗：约98万，比单Agent方案少了约22%。
• 返工时间：我只需花8分钟做最终确认和合并，之前是28分钟修bug。
• 上线后bug：0个严重问题，1个UI文案小问题；之前是4个功能性bug。

算下来，端到端快了2.6倍，成本降了2.6倍，返工时间降到原来的不到三分之一。更重要的是我的精神状态——我不再需要同时扮演需求方、架构师和测试员去跟同一个模型拉锯。

04 可照搬清单：多Agent协作的七条经验

如果你也想试，不用照抄我的四模型组合，先把这七条原则落地：

1. 按认知角色分，不要按文件分。 需求、架构、实现、审查是四种思维方式，不是前端后端那种文件切分。
2. 每个Agent只干一件事，并且必须明确禁止它越界。 比如Kimi禁止写代码，Codex禁止改接口，DeepSeek禁止给实现建议只能给审查结论。
3. 交接用结构化产物，不要用长文。 PRD用JSON/YAML，diff用git，状态用handoff.yaml，别让下游去猜。
4. 冻结接口和契约。 用一个interface.lock或ARCHITECTURE.md把函数签名、错误码、数据库字段钉死，谁改谁负责。
5. Review必须能阻塞流程。 cheerleader式的审查毫无意义。Severe问题直接打回，并限制Codex只修被点名的问题。
6. 编排先线性，再谈DAG。 个人和小团队用100行脚本就能跑通，别一上来就搞复杂状态机。
7. 贵的模型用在刀刃上。 需求理解和架构用强模型，纯审查和简单生成用DeepSeek这种便宜的。省下的token就是利润。

最后说句得罪人的话：市面上很多"AI员工团队"SaaS，本质就是套了个多Agent壳的API调用器，按月收几百块席位费，对独立开发者来说大概率是智商税。 你自己花一下午搭一条流水线，可控、可改、账单透明。当然，如果你团队已经有10个人、流程标准化，买成熟工具能省管理成本，那是另一回事。

说明：数据来源为公开行业报告综合整理、部分数值为估算仅供参考