三个月前接手一个企业项目时没人想到能用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定义了一个简单但够用的Flowspec-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我备注对应员工表的工号非自增IDAgent就会自动外键关联而不是生成一个无关联的字符串字段。页面清单也是一样每个页面必须标明路由、核心交互、调用的接口ID。比如我的申请列表页路径/leave/list交互包括分页查询和取消草稿调用APIGET /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人团队不是一句广告是真实可复制的打法。