3个AI Agent协作实战：3周交付原本2个月的企业项目

4 人团队评估 2 个月的企业项目，我带着 3 个 AI Agent，3 周交付了。这不是标题党，是我真实跑完的一个交付闭环。很多朋友听说 AI Agent 能写代码，但真到企业项目里就懵了——需求怎么喂给它？写完的代码谁敢上线？3 个 Agent 怎么分工？这篇文章把整套打法拆开讲：角色怎么设计、工具链怎么选、每一步怎么做、坑在哪里。如果你也是小团队负责人、独立开发者，或者被工期压得喘不过气的交付人员，这篇内容可以直接抄作业。

我先把背景交代清楚。这个项目是一个企业内部订单管理系统，包含组织权限、客户管理、订单流程、库存联动、报表中心和消息通知六大模块。客户方带队的人体验过太多外包翻车案例，给了一个相对保守的工期评估：4 人团队 2 个月，按 6 人周折算大概 32 个工作日。我接手的时候心里大概估算了一下，这类系统的业务复杂度并不高，真正耗时的是需求梳理、接口对齐、边界 case 处理和验证反馈这些环节。所以我没有按传统方式推进，而是用 3 个职责完全不同的 AI Agent 搭了一条虚拟生产线。

1. 整体设计：为什么是 3 个 Agent，而不是 1 个全能助手

很多人一听到 AI Agent，第一反应是"让机器人帮我写代码"，然后打开 ChatGPT 把需求文档往里一贴，等它吐出一个巨型项目。这种方式做 demo 没问题，做企业项目会死得很难看——上下文窗口撑不住，代码风格前后矛盾，模块之间互相打架，最后你花在修复上的时间比从零手写还多。

我的思路完全不同：用团队管理的逻辑管理 Agent。一个 Agent 就是一个虚拟成员，给它明确职位、明确职责边界、明确汇报关系。它不需要什么都会，但必须在自己的岗位上做到稳定输出。3 个 Agent 分别是规划 Agent、编码 Agent、质检 Agent，对应传统软件团队里的架构师、开发工程师、测试工程师。

1.1 三个 Agent 的分工与协作模型

规划 Agent 是团队里的"大脑"。它负责接收原始需求文档，拆解任务树，定义数据模型、接口契约和验收标准。它不直接写业务代码，但所有编码 Agent 的工作都基于它产出的契约文档展开。这样做的好处是，需求变更不再是人肉同步，而是通知规划 Agent 重新生成一版契约，编码 Agent 按新契约改代码，质检 Agent 按新契约跑验证，闭环非常干净。

编码 Agent 是"手"，按照规划 Agent 输出的任务卡片，一个模块一个模块地实现。我要求它严格遵循既定目录结构和命名规范，每完成一个功能点必须附带简单的自测说明。质检 Agent 是"眼睛"，它对编码 Agent 的输出做静态检查、代码审查、测试用例补充，还会实际执行测试命令，把失败信息返回给编码 Agent 去修复。

协作关系不是串行的。编码 Agent 写完模块 A 就可以立刻交给质检 Agent 审查，同时编码 Agent 转身开始模块 B。规划 Agent 在初期集中输出契约之后，后面只处理需求变更和跨模块问题。这个模型在 LangGraph 上实现起来很顺，因为 LangGraph 支持有状态图、并行分支和人在环路（human-in-the-loop），正好用得上。

1.2 为什么能压缩 4 人团队 2 个月的工作量

传统 4 人团队做这个项目，时间消耗在四件事上：需求澄清与反复确认、前后端接口对齐、代码联调排错、人工测试与 bug 修复。这些环节的共同特征是大量低密度沟通。需求里一个字段的定义，A 同事和 B 同事在 IM 上拉扯了两个小时，最后发现是同一个意思；接口返回格式不统一，前端等后端改，后端等前端提，时间全耗在等待上。

Agent 协作消除了大部分这类损耗。Agent 之间的信息传递不是自然语言讨论，而是标准化的契约文件和结构化数据。如果需求文档里没有写清楚"订单状态流转规则"，规划 Agent 不会反复追问，它会直接列出三条候选规则并标注需要业务方确认，我再拿着这三条去问客户。原本需要 3 天来回的需求澄清，压缩成 30 分钟的规则确认。

团队管理的另一个隐藏成本是上下文切换。一个开发同时负责模块 A 和模块 B，上午写订单逻辑，下午改库存逻辑，大脑需要两次加载，效率至少打七折。在 Agent 流水线里，这个问题被分摊掉了：3 个 Agent 各管一段，互不共享心智负担。我做过实测，同样一个中等复杂度的模块，Agent 连续作战的模式比人肉模式快 5 倍左右，而且几乎没有状态切换损耗。

这里要快速回应一个搜索热词：ai agent token 是什么意思。Token 是大模型处理文本的最小单位，类似中文里的"字"和英文里的"词"混合切分。Agent 每调用一次模型，都要消耗输入 token 和输出 token。企业级交付里 token 消耗不是一个小数字，必须做预算管理，后文我会专门讲成本控制。

1.3 方案选型时的三个核心判断

第一个判断是，不要试图训练或微调模型。企业项目的业务复杂度不值得投入微调成本，直接用成熟的通用大模型 API 就够了。第二个判断是，不要迷信单一 Agent 一肩挑。市面上的 AutoGPT 类项目看起来热闹，实际用在长链路业务开发中经常失控。多 Agent 分支治理虽然看起来复杂，但每一步都有检查点和局部目标，反而稳定。第三个判断是，一定要保留人在环路。不是说让 AI 全自动跑完就完事，而是把决策权的关键节点留给人——比如架构调整、契约定稿、上线审批。这个边界想清楚，后面所有流程设计都不会跑偏。

2. 工具链选型与 Agent 资源配置

定好角色和协作模型，接下来是落地工具。选型的原则只有一条：尽量用成熟生态，不为炫技引入不稳定组件。这套配置不是唯一答案，但对我来说是一个经过多项目验证的组合，可靠性很高。

2.1 Agent 编排框架：LangGraph 是当前最顺手的选择

我试过 LangChain 的老版 Agent 方案、AutoGen 和 LangGraph。AutoGen 强在对话式多 Agent 模拟，但实际生成企业级代码时的结构化输出能力比较弱。LangChain 老版 Agent 在复杂链路中容易因为工具调用失误导致死循环。LangGraph 是目前最适合"企业项目交付"这个场景的——它把 Agent 之间的流转建模成一张图，节点是 Agent，边是状态的传递，天然支持条件分支和循环重试。

具体到这套系统里，图的结构大概是这样的：规划 Agent 节点输出契约文件后，进入"任务分发"节点，把任务列表拆成 N 个独立卡片，并行触发编码 Agent 节点；编码 Agent 完成后进入质检 Agent 节点，质检不过则带着问题描述重新回到编码节点，质检通过则进入"汇编"节点，最终合并到主干分支。整个过程可以随时暂停、检查、修改，非常适合半自动的交付节奏。

2.2 模型选型与 token 成本控制

不同 Agent 对模型能力的要求不一样。规划 Agent 需要理解和抽象需求，做数据建模和接口设计，这对推理能力要求最高，我给它配的是 Claude 3.5 Sonnet 级别的模型，上下文长、输出结构稳定。编码 Agent 是工作量最大的角色，既要理解任务卡又要写大量代码，同样用中高端的通用模型，但参数调整上更强调输出代码的完整性和可编译性。质检 Agent 主要做审查和执行测试，判断任务居多，生成类任务少，可以搭配相对便宜、速度快的模型，像是 GPT-4o mini 层级，能控制成本。

Token 消耗是很多人忽略的坑。一次大型代码生成，输入输出轻松破万 token；一个模块从编码到质检再返工，消耗可能到 5 万 token。我这套流程整体跑下来，不算人工复核的对话消耗，光 Agent 自动流转的 token 花费大约在几百元级别。如果完全不做控制，盲跑半个月烧掉上万元也不是不可能。控制手段有几个：任务卡尽量精炼，只带必要上下文；中间结果用摘要而不是完整日志；对质检 Agent 的代码审查部分设定"只输出问题清单，不重复贴正确代码"。

2.3 企业项目落地必须打通的基础设施

Agent 不是孤岛，它必须能真正操作代码仓库、数据库和命令终端，否则产出的代码无法被验证。我的基础环境分三层：代码层是 Git 仓库，每个 Agent 有独立工作分支；执行层是本地 Docker 环境，编码和质检 Agent 通过 Tool 调用 Docker 命令跑测试；验证层是 CI 脚本，每次合并入库自动跑单元测试和接口冒烟测试。

这里要提醒一个敏感但重要的问题：数据安全。企业内部项目的代码、业务规则、客户数据都不能直接喂给云端大模型。我的方案是做两层隔离：一是代码发送前用脚本自动脱敏，把真实的内部域名、密钥、客户名替换成占位符；二是涉及核心业务规则的需求描述只用"规则编号"引用，不在 prompt 里出现具体内容，详细规则留在本地知识库中。这个方案不完美，但能有效把风险控制在一个可接受的水平。如果企业对数据管控有硬性要求，可以考虑私有化部署开源模型，但推理能力会下降一个档次，需要在方案里权衡。

3. 实操记录：从需求文档到上线清单的完整闭环

这一部分我直接把三周的操作过程摊开来写，包含关键 prompt 模板、任务树样例和每一步的实际产出。想抄作业的朋友重点看这一节。

3.1 第一周：需求解析、架构设计与契约产出

第一周的前两天，我没有让 Agent 碰任何代码，全部精力花在把客户发来的 20 页需求文档转化成结构化契约。传统的做法是写一份需求规格说明书再开会评审。我用规划 Agent 做了更高效的处理：把需求文档整理成结构化文本后投喂给规划 Agent，要求它输出四类产物——数据模型定义、API 接口清单、任务树分解、验收标准列表。

这里分享一个非常有用的 prompt 模板，它可以复用到很多项目里：

你是一位资深解决方案架构师。以下是项目需求文档的整理稿，请完成以下任务： 1. 抽取所有实体，输出它们的字段、类型、关系和索引需求； 2. 基于实体关系设计 RESTful API，给出方法、路径、请求与响应示例； 3. 将需求分解为可独立开发的模块，每个模块标注依赖关系和预估工作量； 4. 为每个模块生成 5 条以上可自动验证的验收标准。 输出格式：Markdown 文档，分四个章节。不要编写任何业务代码。

第一天产出数据模型，我人工花了两个小时核对字段完整性，挑出了 3 个需求里确实没有定义清楚的字段。第二天产出 API 清单和任务树，最开始有 48 个子任务，我手动压缩成 36 个，砍掉的主要是过度拆分——比如把一个简单列表页拆成了查询设计、列表组件、权限控制三个任务，实际这些都是同一个模块里一起完成的。第三天规划 Agent 产出了验收标准，一共 37 条，我挑了 9 条发给客户确认，客户反馈了 4 处规则调整。到这里，图纸基本定稿。

任务树的最终形态长这样，这是节选的一部分：

模块二：客户管理 ├── 2.1 客户实体与数据库迁移 ├── 2.2 CRUD API 实现 ├── 2.3 查询过滤与分页 ├── 2.4 客户与订单关联逻辑 └── 2.5 验收测试用例补充 模块三：订单流程 ├── 3.1 订单状态机定义 ├── 3.2 下单接口与库存扣减联动 ├── 3.3 取消 / 退款流程 ├── 3.4 订单列表与详情 └── 3.5 对账接口

3.2 第一周后半段到第二周：编码 Agent 的模块化冲刺

从第四天开始，编码 Agent 正式上岗。我的做法是一次只派发一个模块的任务卡，而不是把 36 个子任务一次性喂进去。这是因为当前主流模型虽然有长上下文能力，但输出长度超过一定限度后质量会衰减。小步快跑反而更稳。

每个任务卡的结构是统一的：

模块编号：3.2 模块名称：下单接口与库存扣减联动 需求描述：[在这里粘贴规划 Agent 生成的模块描述] 数据模型：[粘贴与本模块相关的表结构] 接口契约：[粘贴 POST /api/orders 的请求响应定义] 编码规范： - 使用 Django DRF 实现 - 事务放在 Service 层 - 库存扣减失败必须回滚订单 - 不要新增未定义的依赖 验收要求：运行 python manage.py test apps.order.tests.OrderCreateTests 全部通过

编码 Agent 平均一个模块耗时 1 到 2 个小时。它输出的代码不会一次通过，但实体结构和接口签名通常八九不离十，真正需要返工的是细节——字段校验不够严谨、异常处理遗漏、边界条件考虑不足。这些问题正是质检 Agent 发挥作用的地方。

第二周的后半段是整个项目压力最大的时候：库存联动里有个并发扣减的问题。Agent 写出了一版先查后扣的代码，质检 Agent 在审查时判断有超卖风险，返回给编码 Agent 修复。编码 Agent 给出的修复方案是加悲观锁。我介入叫停，让编码 Agent 改用乐观锁加重试机制，因为订单系统并发量没有高到需要牺牲吞吐。这种架构决策层面的纠偏，就是章节 1.3 里讲"人在环路"必要性的典型场景。

3.3 第三周：质检 Agent 全面收口与交付组装

第三周的主要工作是测试、修复、部署和文档。质检 Agent 在这一阶段变成核心角色，它做了三件事：逐模块补齐单元测试和集成测试用例、把验收标准翻译成自动化测试脚本、检查所有 API 的实际返回是否符合契约。

特别值得说的一点是，质检 Agent 带上了"契约校验"能力。它不是只看代码有没有语法错误，而是会拿着规划 Agent 定义的接口契约去核对编码 Agent 的实现——字段名是否一致、类型是否正确、幂等性是否满足、权限标注是否生效。这个环节的价值极大，传统 4 人团队里最费时的前后端联调问题，在这个流程里被压缩成了 Agent 之间的自动比对。

部署环节也纳入了一个轻量 Agent 任务。我给规划 Agent 追加了环境部署任务卡，它生成了一份 Dockerfile 加 docker-compose 配置，配合 Nginx 反向代理。本地起环境实测跑通了主流程，然后把部署文档同步给客户的运维。最终交付物包括：完整代码仓库、数据库初始化脚本、API 文档、部署手册、38 条验收测试的通过记录。

3.4 三周时间线复盘：每天在干什么

每天实际消耗时间大概是 4 到 6 小时，不是传统意义上的"996 赶工"，更像是一个人在同时管理一条三人虚拟团队的产线。早上合并前一天的产出，上午集中回复 Agent 的卡点问题，下午做人工审查和决策，傍晚汇总进度。

4. 实战中踩过的坑：常见问题与排查技巧

这个部分是我认为整篇文章里价值最密的内容。Agent 交付不是一路顺风的，我在三周里踩了不少坑，有些问题几乎每个项目都会遇到，值得整理成一套速查笔记。

4.1 Agent 写出的代码风格分裂怎么办

编码 Agent 在不同模块里产出的代码会出现明显的风格漂移。第一个模块的异常处理方式是统一的APIException，到了第三个模块它直接抛了裸的Exception；有的模块用了select_related优化查询，后面的模块又 N+1 查询满天飞。根本原因是大模型每次生成时都会"自由发挥"。

解决办法是把编码规范文档化、契约化。我把项目的高质量代码片段抽出来，做成一份带批注的规范样例，放进每个任务卡的最后一段。同时要求质检 Agent 的审查清单里包含风格一致性检查项，一旦发现新增了未约定的模式，直接打回。两条措施叠加之后，风格问题出现频率大幅度下降。

4.2 上下文窗口膨胀导致 Agent 低能

第二周的时候，编码 Agent 在一个任务卡里因为要求参考之前的代码，我用了一段长日志把上下文撑到了接近 2 万 token。结果模型开始丢三落四，生成的代码里出现了两次定义同一个函数、引用不存在的包这类低级错误。这其实不是模型变笨了，而是注意力机制在超长上下文里会被稀释。

解决方案是给 Agent 建一个外部记忆库。不在 prompt 里搬运大段代码，而是把历史决策记录、模块索引、公共接口说明放在一个独立的项目知识文件里，Agent 需要时通过检索工具按关键词拉取，而不是全量塞进上下文。做完这个调整，返工率肉眼可见地下降。

4.3 大模型一本正经地编造 API 和函数

这大概是所有 Agent 使用者都会碰到的经典问题。编码 Agent 在实现邮件通知模块时，引用了一个我根本没有安装过的第三方库，并且编造了不存在的函数签名。质检 Agent 执行测试时直接ModuleNotFoundError。这是大模型的"幻觉"问题在代码生成领域的典型表现。

破解思路不是让模型"不要编造"——效果有限——而是建立验证闭环。第一步，编码 Agent 每引一个新的库，必须走"查询本地依赖清单 → 确认存在 → 再使用"的流程。第二步，质检 Agent 必须实际运行测试，而不是只看代码。任何无法编译、无法导入的代码直接打回，不进入人工 review 环节。这两条规则彻底根治了这个问题。

4.4 人工介入的临界点在哪里

我负责任地说，三周里我亲自介入的次数在 6 次左右。介入的场景集中在：跨模块依赖的架构决策、并发控制策略选择、对外接口的语义约定、以及客户临时加需求时的优先级判断。其余时间，Agent 之间的自循环基本能自己跑通。

判断是否该人工介入的一个经验法则：如果这个问题只影响当前模块的代码，交给 Agent 自己去返工；如果会影响多个模块之间的契约，立刻停止流水线，人工决策。拿不准的时候多问一句规划 Agent，让它列出备选方案和影响面，往往能帮你快速判断是放手还是接管。

4.5 客户临时改需求，整个系统怎么应变

原以为最麻烦的场景最容易翻车，实际上因为契约先行，需求变更成了一个高效率的过程。第三天客户中途确认规则调整了 4 处，我只花了一个小时处理：把变化点给规划 Agent，它更新了两个接口的契约定义和验收标准；编码 Agent 按新契约改了对应模块；质检 Agent 重跑关联测试。传统流程里这种变更至少要一天的沟通和返工，在契约驱动流水线下，变更管理完全是可控的。

5. 影响范围分析：AI Agent 在重构什么样的交付逻辑

做完这个项目，我对 AI Agent 在软件开发领域造成的影响有了非常具体的体感。它正在改变的不只是"写代码的速度"，而是整个交付协作的底层逻辑。

5.1 小团队和个人开发者被大幅赋能

过去一个独立开发者在企业级项目面前几乎是不可想象的，精力上限让它无法兼顾需求、开发、测试、运维。但在 Agent 流水线模式下，一个人完全可以撑起一个三人虚拟团队。这次项目里我实际做的事是需求决策、契约审批、架构把关、客户沟通和风险处理，代码产出的绝对大头由 Agent 承担。这等于给个人开发者装了一个团队级别的产能放大器。

对小型工作室和自由职业者来说，更直接的影响是接单能力变强了。以前不敢接的"周期紧、模块多"的项目，现在可以用更激进的排期去竞争。但这也带来了新的内卷——当交付速度被普遍提高之后，客户的预期也会拉高，单子不会简单变多，对交付质量和沟通能力的要求反而更高了。

5.2 流程、文档和高阶技能的价值被重估

很多人以为 AI Agent 会让文档写作失去意义，我的体验恰好相反。Agent 协作效率高低，很大程度上取决于需求文档和契约文件是否结构化。那些写给人看的、满是形容词的需求描述，Agent 消化不了；而那些字段清晰、边界明确、规则可验证的文档，Agent 的输出质量会翻倍。这逼着我重新练习"把话说清楚"的能力。

传统软件开发里的很多技巧正在被重新定价。纯编码能力的重要性会下降，因为生成代码的门槛被打下来了；而架构设计、规则拆解、质量和风险管理这些"围绕代码之外"的能力，成为了真正稀缺的竞争力。说得直白一点，以后重要的不是你会不会写这段代码，而是你能不能定义清楚这段代码应该做什么、怎么验证它有没有做对。

5.3 企业定制项目的报价与价值模型会被重塑

这个项目做完之后，客户方其实也做了内部复盘。以前的外包报价模型是"人月"，几百人天按人头算钱。Agent 流水线把这个游戏改了——交付方的人力投入只有 3 周，成本显著下降，但客户的业务目标没有缩水。短期内聪明的主包方会把省下来的成本转化为利润，但长期来看客户一定会重新定义"合理报价"的锚点。

这个趋势对两类公司影响最大：一类是低附加值的"人力外包"型企业，单纯卖人在未来几年会非常难过；另一类是已经建立了标准化产品、以 IP 为核心的软件公司，AI Agent 会进一步放大它们的边际收益。中间地带的定制开发生意，如果没有方法论护城河，会最先感受到价格压力。

5.4 边界在哪里：什么活 AI Agent 现在还接不了

我不想把 AI Agent 吹成万能工具，边界非常清楚。第一，涉及复杂业务战略判断的事做不了。客户说"我们的订单审批流程要根据组织架构调整灵活适配"，这句话背后隐含的权力结构和部门利益，Agent 不理解，只有人能拍板。第二，跨周期的一致性和技术债管理做不好。Agent 擅长局部最优，但对一个运行了三年的老系统做全局重构，它缺少对历史背景和隐性约束的认知。第三，人际协作和信任建立是空白。客户的安全感、团队成员的成长、项目里的情绪价值，这些仍然必须由人来完成。

这些边界不是缺陷，反而给我一种安全感——AI Agent 虽然猛，但离"取代交付型从业者"还有距离。它会替代掉大量执行层面的工作，也会让不行使判断力的人显形。

说一点我个人实操中的体会吧。这个项目做完之后，我最大的收获不是"3 周搞定了 2 个月的活"，而是整个流程把我逼成了一个更清醒的决策者。以前我写代码的时候经常一边写一边改接口，思路是模糊推进的；现在契约先行、任务卡先行、验收标准先行，每一步都清清楚楚，反而比之前少走了很多弯路。如果你也想试这套打法，我建议不要一上来就搭三 Agent 的完整流水线。先从一个简单项目开始，用一个规划 Agent 加一个编码 Agent 跑通最小闭环，感受一下"任务卡驱动开发"是什么感觉，再逐步加质检 Agent 和部署自动化。这个循序渐进的路径，踩坑成本最低。

最后分享一个小技巧：每个工作日结束前，让规划 Agent 输出一份"变更清单和风险说明"，把当天所有契约调整、代码变更、残留问题列成一张表。这张表既是第二天开工的指引，也是项目周报的素材。我靠这个习惯，让整个交付过程在客户眼里始终保持透明可追踪，信任就是这么一点一点建立起来的。