三个月前接手一个企业项目时，没人想到能用3周交付完。原本的方案是4人团队干2个月：1个项目经理、1个后端、1个前端、1个测试，外加企业内部协调，标准排期就是8周。我最终只用了约15个工作日完成，靠的是3个 AI Agent 全职协作，外加我一个人做架构设计和最终拍板。这篇文章把整个过程拆开讲，包括Agent怎么分工、任务流怎么编排、并发和Token怎么管理，以及哪些坑是常规教程根本不会告诉你的。
这个项目本身不复杂，但很典型：一家中型制造企业的内部审批流程管理系统，包含请假、报销、采购三类流程，涉及多部门、多级审批、邮件通知、统计报表和移动端适配。传统团队做这种项目，大量时间花在需求对齐、接口联调和反复改页面上。AI Agent 的价值不是替你玄幻地"写代码"，而是把这三块容易被压缩但极其耗时的工作自动化。如果你也在考虑用 Agent 交付真实业务项目，这篇分享能让你少走一个月弯路。
1. 项目复盘：4人团队2个月的需求，为什么能压缩到3周
1.1 原计划的4人团队怎么分工，钱和时间花在哪
这类企业内部管理项目看起来不起眼，但细拆工作量不小。原计划4人团队2个月，分工大致是：项目经理全职对接业务部门，梳理流程节点和审批规则；后端工程师设计数据库、开发审批引擎和权限模块；前端工程师做主控台、表单页、审批页和报表页，并兼容PC和手机浏览器；测试工程师负责功能测试和回归。人力成本按市场价估算，光工资就要小几十万。
时间主要消耗在几个地方：业务流程反复确认，业务方今天说审批要三级，明天改成"部分部门两级"；前后端接口联调因为字段命名不统一来回改；页面边边角角的样式和交互，前端调一版，业务看着不满意再调一版。这些工作在传统模式下很难通过增加人手压缩，因为沟通成本会指数级上升。
1.2 我能3周交付的三个前提，缺一个都不行
第一个前提是业务边界清晰。这个项目虽然跨三个流程，但都是"提交-审批-归档"的通用模型，没有复杂的算法和硬件交互。边界清晰意味着AI生成代码的出错率可接受，需求变化也能快速重新生成。如果上来就是老系统改造，数据库几百张表，规则一堆历史包袱，我也不敢只用三周。
第二个前提是我自己做过完整的交付。AI Agent 可以替代执行，但替代不了判断。哪些环节必须人工review，哪些可以放权给Agent，这个判断只能来自对全栈开发、数据库设计、测试要点的熟悉。没有这个功底，Agent生成的垃圾代码你根本识别不出来。
第三个前提是企业方愿意配合压缩沟通路径。我直接对接业务部门负责人，所有需求走文档加语音会议，决策以最小闭环推进。传统项目经理的汇报链被砍掉了，这也是能省时间的关键原因。AI Agent 再强，也解决不了多方扯皮。
2. 三个Agent的角色设计：把"团队"装进开发环境
2.1 Agent1：需求翻译官，负责把业务话说成人话再变成任务
第一个Agent我命名为"需求翻译官"，英文代号spec-agent。它的输入是业务方提供的原始需求文档、会议录音转写文本、流程截图。输出是一份结构化的任务书，包含数据模型定义、API接口清单、页面清单、审批规则逻辑和验收标准。
这里的核心不是让它直接生成代码，而是生成人和代码之间的"中间层"。比如业务说"报销金额超过5000元需要总经理审批"，spec-agent会把它转成一条规则：amount > 5000 && approval_level = 3。它还会主动发现歧义，比如"超过5000"是否含5000，需要确认。我在实践中发现，让Agent先做需求结构化，比直接让它写代码稳定得多，因为一次代码生成如果建立在错误的需求理解上，返工成本极高。
给这个Agent的system prompt里，我要求它输出必须是Markdown表格和结构化JSON，并且每个字段都要标注"来源依据"。这样我可以回溯它的判断是否来自原始需求，而不是自己编。它还会生成验收用例模板，比如"采购申请单，金额3000元，部门预算充足，部门经理审批通过后到达财务岗"，这些用例后来直接成了测试Agent的素材。
2.2 Agent2：后端与数据模型专家，不只会写CRUD
第二个Agent负责后端，代号api-agent。它的输入是spec-agent输出的任务书，输出是FastAPI工程代码、SQLAlchemy模型、数据库迁移脚本、权限校验逻辑和接口自动化测试用例。我选择FastAPI而不是Spring，一方面因为项目是中小规模，另一方面FastAPI的Pydantic模型能和spec-agent生成的JSON结构无缝衔接，Agent生成的代码类型错误明显减少。
api-agent的prompt强调几件事：所有接口必须做输入校验和权限校验；数据库操作必须走事务；查询列表必须分页；金额字段用Decimal不能用Float。这些约束如果只靠Agent自觉，大概率会翻车，所以我把它们写成固定的开发规范片段，每次都拼进Prompt。实践下来，代码规范符合率从50%出头提升到90%以上。
它还负责自动生成数据库迁移脚本。在LangGraph工作流里，api-agent运行完代码生成后，会调用一个工具执行alembic revision --autogenerate，然后读取结果，如果有错误就自动修正代码再重试。这个过程它自己循环最多三次，超过三次才转人工。实际项目里有两次循环到第三次才通过，原因是数据库字段类型推断出错，一次是Text和String的取舍，一次是时区字段默认值。
2.3 Agent3：前端与测试工程师，一个人干两个人的活
第三个Agent身兼两职，代号web-agent。输入是spec-agent的页面清单和api-agent生成的接口定义文件，输出是Vue3前端工程、页面交互逻辑、API调用封装，以及E2E回归测试用例。它调用一个专门准备的Playwright测试环境，每完成一组页面就自动跑一遍冒烟测试，截图反馈到我的工作台。
前端最大的坑是UI组件版本不匹配。Agent很容易生成一个看起来没问题但实际跑不起来的代码，比如Element Plus版本和Vue版本不兼容，或者漏了按需导入。我让web-agent每次安装依赖后先锁版本，并且用npm run build作为闸门，构建失败则不进入下一环节。它还会读取后端接口的实际返回结构，确保前端类型定义和FastAPI响应schema一致。
你可能会问，前端和测试为什么合并成一个Agent？因为很多企业项目的测试重点其实是流程串联，也就是"提交申请-审批-状态流转-报表更新"这一整条链路。让同一个Agent既改前端又跑测试，它可以更快定位问题是出在页面调用、接口返回还是逻辑判断，省掉了传统团队里"前端说后端没问题，测试说前端没传对"的扯皮环节。
3. Agent编排与并发控制：LangGraph让三个Agent有章法地协作
3.1 为什么选LangGraph而不是自己写状态机
三个Agent不是简单按顺序跑一遍就完事。比如后端接口定义变了，前端Agent要能感知并重新生成相关页面；测试Agent发现审批规则实现有误，要能回到后端Agent去修改，而不是只报个失败。这需要一个可持久化、可控回退的工作流引擎。我选了LangGraph，它天然支持把每个Agent封装成Graph里的节点，节点之间用条件边连接。
如果用传统代码硬写状态机，每个Agent之间的交互都要自己维护状态表，调试起来极其痛苦。LangGraph自带的状态快照和断点恢复能力，允许我在任意Agent执行前打断，插入人工审批。这一点很关键，因为AI生成的代码不能无节操放行，关键节点必须要人工闸门，而我需要的是"闸门不阻塞Agent之间的低频协作"。
实践里我用LangGraph定义了一个简单但够用的Flow：spec-agent完成需求结构化后，进入人工确认节点；确认通过后api-agent和web-agent并行启动，但web-agent依赖api-agent生成的接口文档，所以实际上并行度没有想象中高；测试Agent在两者都完成后启动，如果发现问题，根据问题类型路由回对应Agent继续修。
3.2 三个Agent之间的任务交接协议
设计Agent协作时，最容易犯的错是让Agent之间直接用自然语言对话。看起来智能，实际上下文越聊越长，Token消耗爆炸，还容易出现"你觉得我觉得"的无意义循环。我的做法是定义严格的交接协议，每个Agent的输出都必须是一个符合Schema的JSON文件。
spec-agent输出task-spec.json，包含entities、endpoints、pages、rules、acceptance_criteria五个数组。api-agent读入它，逐项生成代码，同时维护一个implementation-status.json，记录每个接口和模型的完成状态。web-agent同时读取task-spec和implementation-status，只处理状态为complete的部分。测试Agent运行完成后输出test-report.json，包含失败用例和失败原因。整个系统里，人机界面就是一个共享目录，我用一个简单的脚本监控目录变化，每次关键文件更新就通知我review。
这个协议的好处是任何Agent的输出都可以被其他Agent和人类无歧义地消费。坏处是我需要设计前花半天定义Schema。但相比省下的联调时间，这半天回报率极高。如果未来加入新Agent，只要它遵循同样的Schema就能接入，扩展性也好很多。
3.3 AI Agent怎么扛并发：限流、重试、和任务队列
这次实践里，我同时跑多个Agent时遇到了实际的并发问题。OpenAI、Anthropic这些API都有分钟级请求限制，一个大型代码生成任务往往要拆成多个子调用，稍不注意就触发429限流。尤其当api-agent试图并发生成10个接口代码时，每个接口又涉及多次模型调用，并发一大直接全军覆没。
我的解决办法是给每个Agent加一层请求队列，用Python的asyncio.Semaphore控制同时发出的模型请求数，并配合指数退避重试。实测时把并发数从10降到3，再配合1秒延迟，429发生率从70%降到接近0。代价是单次批量生成时间变长，但总体更稳定。另一个思路是把大任务拆小，让Agent分多次增量编码，而不是一次性生成一个大文件。这样即使某次调用失败，重试的成本也很低。
如果你要理解Token的含义，可以简单地把它看作模型处理的字数单位，输入和输出都计费。一次代码生成任务动辄消耗几千Token，三个Agent一天跑下来可能几十万Token。如果不做上下文裁剪，一个Agent的对话历史就能烧掉大量无效Token。我的做法是每个Agent只保留最近一轮的对话摘要加上最新输入，历史代码文件内容不再重复塞进对话，而是通过工具读取。
4. 核心环节实现：从需求到可运行系统的完整链路
4.1 需求输入与任务拆解的输出格式，稳不稳看这里
第一步，我拿到业务方的原始材料后，先自己通读一遍，剔除明显的前后矛盾，再丢给spec-agent。Business侧材料越乱，Agent发挥空间越大，越容易生成幻觉内容。所以我给spec-agent的要求是"不确定的不要猜，列成待确认问题清单"，这样可以减少后面的返工。
一份最终的任务书里，数据模型定义节选长这样：
{ "entity": "leave_request", "fields": [ {"name": "id", "type": "integer", "pk": true}, {"name": "employee_id", "type": "string", "description": "员工工号"}, {"name": "start_date", "type": "date", "description": "开始日期"}, {"name": "end_date", "type": "date", "description": "结束日期"}, {"name": "days", "type": "decimal", "computed": "end_date - start_date + 1"}, {"name": "reason", "type": "text", "max_length": 500}, {"name": "status", "type": "enum", "options": ["draft", "pending", "approved", "rejected", "cancelled"]} ] }这些JSON不是给数据库用的，而是给api-agent生成模型和接口用的。表格里每行字段都要求有description，因为模型在被Agent二次理解时，描述不清晰就会产生理解偏差。比如"employee_id"我备注"对应员工表的工号，非自增ID"，Agent就会自动外键关联，而不是生成一个无关联的字符串字段。
页面清单也是一样，每个页面必须标明路由、核心交互、调用的接口ID。比如"我的申请列表页，路径/leave/list，交互包括分页查询和取消草稿，调用API：GET /api/v1/leaves?status={status}&page={page}"。这样web-agent不需要自己猜页面和接口的对应关系，生成的代码才能直接对接上。
4.2 后端Agent的代码生成策略：从模型到接口再到迁移脚本
得到任务书后，api-agent开始工作。我给它设定的执行顺序是：先建数据库模型，再写Schema和接口，最后跑迁移。为什么是这个顺序？因为模型是一切的地基，模型字段不对，后面的接口和前端全是空中楼阁。它每生成一个模型文件，我会在review节点检查一次，不是一股脑全部生成完才看。
具体实现上，我要求api-agent必须使用SQLAlchemy 2.0的Mapped和mapped_column写法，显式指定类型和索引，不允许model里出现裸字符串字段。它还必须在每个表的ModelMeta里加__table_args__定义复合唯一约束，比如"同一员工的同一天请假不能提交两条"，这在实际业务里经常被忽略，导致脏数据。
写接口时它遵循一个固定模板：每个路由函数先做当前用户权限判断，再做请求体校验，最后执行数据库操作，异常统一由全局exception handler处理。接口返回格式全部是{code, message, data}，data部分是列表时要包含total字段。这些约定都在Prompt和Schema里写死，Agent即使不聪明，照着模板填也能填个八九不离十。
迁移脚本生成后，它会自动执行alembic upgrade head，如果失败，就读取错误信息，定位到具体模型或迁移文件进行修复。实测中这类问题主要有两个来源，一是字段类型和底层数据库不兼容，比如SQLite不支持某些DateTime精度，换个数据库类型就过了；二是主键和外键的类型不匹配，整数外键配了字符串主键。Agent只要能看到错误详情，修起来不比人慢。
4.3 前端Agent的页面生成与联调：组件库锁版本才能不翻车
web-agent拿到接口文档时，api-agent已经生成了OpenAPI schema。我让web-agent用openapi-typescript生成类型定义文件，再基于这个文件去写页面，这样前端参数传错这类低级错误能被TypeScript直接拦住。页面使用Vue3加Element Plus，路由用vue-router，状态管理用Pinia，都是国内企业项目最主流的组合。
它生成的页面不是一次性全部搞定，而是按模块分批。第一批做登录和主框架，第二批做审批流核心页面，第三批做报表。每批次结束都跑一次npm run build和Playwright冒烟脚本，发现构建报错就自动修复再试。这个循环最多5次，超过就暂停等我处理。
联调阶段最有意思，web-agent会根据mock数据和真实接口的差异自动调整。比如真实接口的分页参数是page和page_size，而task-spec里写的是page和per_page，这时候它会读OpenAPI schema后自动修正前端请求参数，并更新调用代码。我在review记录里看到它做了两次这样的自我修正，省去了传统团队联调时"等对方改"的时间。
4.4 自动化测试与交付报告：用一套用例覆盖三大流程
测试Agent在三个流程都跑通后才正式启动。它读取验收用例清单，转成Playwright脚本。三个Agent里，这个Agent的Prompt最容易出错，因为它要同时理解业务规则和前端选择器。我给它的提示是：优先用data-testid定位元素，不要依赖CSS class，因为Element Plus的class名经常变化。
测试用例覆盖了业务核心：请假流程，普通员工请假3天，部门经理通过后状态变为已通过；报销流程，金额超过5000，提交后需要总经理审批；采购流程，金额3万以上需要比价附件，缺少附件时提交按钮置灰。测试Agent会跑完所有正向用例，再设计几个逆向用例，比如重复提交同一时间段的请假单应被拒绝。
最终交付时，test-report.json里路径通过率100%，三套流程全部跑通。我还让它生成了用户操作手册，基于测试步骤自动截图并配上文字说明。这节省了一个文档工时，企业方也很满意，因为交付物里包含了可以直接给业务人员培训的材料。
5. 踩坑实录与效率复盘：哪些坑是教程不会告诉你的
5.1 最常见的5个坑，每个都真实浪费过半天以上
坑一，Agent上下文污染。有一次api-agent在连续生成了很多个接口后，突然开始把上一个项目的命名风格混进来，原因是我没做好上下文隔离，旧代码片段漏进了新请求。后来我给每个Agent配置了独立的会话目录，每次新任务都重新初始化上下文，问题就再没出现过。
坑二，Agent以为自己能做超出能力的事。web-agent第一次尝试封装复杂的人工审批流程图时，生成了一大段用Canvas手绘节点的代码，看起来高大上，但在移动端完全不能跑。我没有让它自己修，而是要求它使用现成的流程图组件，因为自定义画布的开发和测试成本不是一个Agent短期能扛住的。教训是：Prompt里必须限制技术选型，给它几个允许选择的方案，而不是让它自由发挥。
坑三，数据库Seeding数据不一致。api-agent生成测试数据时，部门、人员、审批规则都是自己编的，导致前端联调看到的页面数据乱成一锅粥。后来我专门写了一份seed-data.json作为公共测试数据，所有Agent都只能从这份数据里取，不允许自行编造，否则校验不通过。
坑四，模型选择一刀切。代码生成和需求分析其实适合不同的模型。现在主流模型各有强项，有的写代码更好，有的对长文档理解更强。我让spec-agent使用上下文窗口更大的模型，api-agent和web-agent则使用代码能力更专注的模型，测试Agent又用回长上下文模型。跑下来总成本没增加，但错误率明显下降。
坑五，没有备份和恢复机制。有一次LangGraph的状态因为进程崩溃丢失，三个Agent的进度全没了。后来我启用了checkpoint持久化到Redis，每完成一个节点就保存一次，崩溃后能恢复到最近一个稳定的快照。这个必须有，否则一旦半夜跑崩，第二天醒来看到全空的状态会血压飙升。
5.2 我是怎么判断Agent输出不可信的
AI生成的内容看起来都很有逻辑，但严格讲每一句都可能是幻觉。我的判断方法不是看代码有没有报错，而是看几个信号。
第一，代码文件突然出现大段重复逻辑。Agent在偷懒，把之前的处理函数复制一份改个名，而不是重构公共函数。这种代码初期能跑，后期维护就是灾难。第二，接口返回结构和OpenAPI schema对不上。表面看着字段都对，但类型不对，比如把字符串数组写成了单个字符串，联调时才会爆雷。第三，测试用例只覆盖"成功路径"，完全没有错误分支。这说明Agent没有真正理解业务约束，只是照着例子套。只要我在review时发现这三类信号，就会让对应Agent重新回答，并且要求它解释自己的设计选择和理由。它能解释清楚，我再放行。
人工review不是每行代码都看，而是看关键文件：模型定义、权限校验、审批状态机、所有涉及金额和日期计算的逻辑。这些地方错了直接影响业务正确性。其余CRUD代码，只要通过了接口层Pytest和类型检查，我信任度可以高一些。
5.3 效率提升的真相：3周里其实有2周在和人Agent"磨合"
坦白讲，三周交付不是AI第一个工作周就直接跑出来的。第一周是痛苦的磨合期。spec-agent一开始生成的需求文档经常缺失边界条件，api-agent生成的代码能编译但业务逻辑有小毛病，web-agent的页面UI经常丑得离谱。我一直在改Prompt、修Schema、调测试脚本。
真正跑顺是在第8天以后。一旦工作流稳定下来，增量需求的交付速度开始惊人。一个新增的"部门主管代填申请"功能，传统团队估1天，我实测从驱动Agent到生成完代码和测试，约2小时。打磨后的Agent在单一任务上不会累、不会抱怨、不需要重复解释上下文，这才是真实提效来源。
所以这3周里，如果按产出来算，后两周实际是两周干了传统团队一个半月的活，第一周基本消耗在基建上。网上那种"今天配置Agent明天交付项目"只存在于演示环境。真实项目里的环境、依赖、业务规则、版本兼容，每一个都需要人来兜底。
6. 越用越顺的三条经验，直接抄就完了
第一条经验是模板化Prompt工程。我把每个Agent的system prompt拆成固定底座加业务插件。固定底座包括角色定义、通用开发规范、输出JSON格式、禁止行为清单。业务插件则承载本次项目特有的流程、字段、规则。换到下一个项目时，只需要换插件，底座不动。这套模式让我准备Agent的时间从半天缩小到半小时。
第二条经验是坚持"小步快跑，人工闸门"。不要让Agent一口气生成全部代码，而是按功能模块切分，每完成一个小模块就构建、测试、人工review。看着慢，实际总耗时更低，因为问题在最小范围内就被修复。人Agent结合时，人是流程设计者，Agent是执行者。千万不能让Agent自己设计流程并执行到底，那会失控。
第三条经验是留一个Agent当"评审者"角色。虽然标题里说3个Agent，但我后来在关键阶段临时起了一个第四角色，没有写代码，只做代码审查。它会从安全、性能、可维护性三个角度给其他Agent的输出挑毛病。比如它发现某个查询接口没有加数据库索引，大概率会导致大表查询慢，然后直接提示api-agent去修复。这个角色不需要很强的生成能力，但需要很强的分析和约束意识，同类模型都能胜任。如果你有条件，强烈建议加一个这样的"质检员"。
最后再分享一个小技巧：每天开工前，我会把所有Agent的日志汇总成一个简报，只看三件事——今天完成了什么、哪些地方自动重试过、哪些节点被人为打断过。这三行信息基本能反映系统的健康度。自动重试过多，说明模型执行稳定性有问题，需要调整任务粒度；人为打断过多，说明指令不清或预期不对，需要更新Prompt。这套监测习惯帮我避免了很多次无效加班。
越到后面你越会发现，AI Agent交付企业项目的瓶颈不再是模型能力，而是你对自己业务流程的把控能力和Agent协作机制的用心程度。把这三样做到位，3个Agent代替4人团队不是一句广告，是真实可复制的打法。
