最近我在做一个企业内部的业务系统，4人团队排期2个月，最后我一个人用3个AI Agent，3周做完。不是炫耀，是这套打法确实改了我的工作方式，也踩了不少坑，值得好好复盘一次。

先说背景。项目是一个典型的中后台业务系统：权限体系、审批流、数据看板、客户管理，外加一堆增删改查的报表页面。传统做法是前后端拆分，产品经理写需求，后端出接口，前端调接口，测试再来一轮轮回归。听起来不复杂，但企业项目真正的耗时点从来不在写代码，而在沟通、对齐和返工——需求细节没对齐，接口字段没说清，页面效果和预期不一致，每一条都能吃掉一两天。

我把项目拆成了三条Agent流水线，分别承担规划、编码、审查的职责，自己只做需求接口人和最终验收人。这套模式跑通后，干活节奏基本就是：早上给Agent派活，中午回来做一轮review，下午修问题、继续派下一批活，晚上合代码。3周下来，业务功能、部署、演示、交付一个没少。

这篇就把我的完整方案、Prompt设计、工具链选型、成本消耗，以及所有踩过的坑都写出来，给想在真实项目里用AI Agent的人一个直接能抄的参考。

1. 项目到底做了什么，为什么传统2个月的项目能压到3周

先把这个项目的范围说清楚，不然“3周做完”听起来像吹牛。项目是给一家做供应链贸易的公司做的内部订单协作平台，核心模块有：

• 组织架构与用户权限：支持多角色、多层级审批，数据权限要能隔离到部门。
• 订单全流程管理：从下单、审核、出库到对账，状态机流转，异常订单要能回退。
• 数据看板与报表：包括销售趋势、回款统计、库存周转，图表不能只是摆设，要能按时间段筛选。
• 客户与供应商管理：基础资料维护、关联订单查询、信用额度控制。
• 操作日志与消息通知：关键操作留痕，审批待办要推送到内部工作台。

原计划是4个人（1个产品、2个后端、1个前端）干2个月。但我和老板商量后，把范围做了硬约束：不做移动端App，不做复杂的自定义报表设计器，不做遗留系统数据迁移。所有业务逻辑在一个新系统里闭环，对接老系统只走导出导入。

为什么3周能做完？核心原因不是AI写代码比人快多少，而是提前把“返工成本”压到了最低。传统模式里，2个月里有大量时间耗在“产品写完文档—开发理解错—测试发现不对—返工”这个循环里。而我用Agent架构后，需求文档会先被规划Agent转成可直接落地的任务清单和接口定义，编码Agent只按图施工，审查Agent又专门查逻辑漏洞。每一层都有独立的“质检关”，错误在递进过程中就被拦下来了，不会累积到最后才爆发。

这里要解释一个关键认知：AI Agent交付项目的优势，不是代码生成速度（说实话生成速度也就那么回事），而是“执行链路的确定性”。只要你把每个Agent的职责边界和协作接口定义清楚，它可以像个不知疲倦的初级团队一样，把需求逐步变成可运行的软件，并且每一层都有审查和校验。

我后来复盘，真正让2个月的活压到3周的因素大概是这个配比：规划Agent省掉了约70%的返工，编码Agent顶掉了约90%的普通CRUD开发，审查Agent省掉了约一半的测试人工介入。省下来的时间刚好用在了最容易出问题的联调和部署上。

2. 三个AI Agent怎么分工，谁干规划、谁写代码、谁做质检

很多人在项目里用AI Agent，一上来就开一堆角色，什么“前端Agent”“后端Agent”“测试Agent”“运维Agent”，结果Agent之间互相打架，代码互相覆盖，上下文互相污染，最后比人工还乱。我的经验是，3个Agent是上限，超过这个数，协调成本会指数增长。

我设计的三个Agent分别是：

这里的关键是，三个Agent不是平行的，是流水线式的上下游关系：Agent A的输出是Agent B的输入，Agent B的输出又交给Agent C审查，发现问题后打回给Agent B修改，Agent C复核通过后才算任务完成。

在实际操作中，我不让Agent之间直接对话，所有交接都通过文件和消息队列完成。比如Agent A产出一个任务卡，就是一个Markdown文件，里面包含需求描述、验收标准、涉及的数据表、接口签名。Agent B只认任务卡，不自己发挥。Agent C只认代码仓库的diff和测试结果。这样每一环都是“输入—处理—输出”的标准结构，中间出了问题我一眼就能定位是哪一环的问题。

接下来是我实际在用的Prompt框架，我把它简化后贴在下面，你可以直接改改就用。

Agent A（规划者）的核心Prompt：

你是本项目的规划Agent。你只能输出规划和设计，不允许编写业务代码。 针对下面这个需求，你必须输出： 1. 按优先级排序的任务清单（每个任务包含：标题、描述、验收标准、预估工时） 2. 涉及的数据表和字段定义（用DDL描述） 3. 核心接口签名（用OpenAPI格式描述） 4. 潜在风险点和回滚方案 需求内容： 【在这里粘贴你的需求描述】 输出时严格按以上四部分组织，不要有多余内容。

Agent B（执行者）的核心Prompt：

你是本项目的编码Agent。你只负责实现下面这个任务卡，不允许擅自重构其他模块，不允许修改任务范围以外的代码。 任务卡： 【在这里粘贴Agent A生成的任务卡】 实现要求： 1. 严格遵循项目现有的代码风格和目录结构 2. 必须编写对应的单元测试 3. 完成后输出：修改的文件列表、关键实现说明、测试结果 4. 如果遇到任务卡描述不清的地方，列出疑问清单，不要自行假设

Agent C（审查者）的核心Prompt：

你是本项目的审查Agent。你只负责审查代码变更，不修改代码。 审查对象是下面这个代码diff或文件列表： 【在这里粘贴Agent B的改动】 你必须检查： 1. 逻辑漏洞和边界条件（比如空指针、除零、状态机非法流转） 2. 安全风险（SQL注入、越权访问、敏感信息泄露） 3. 测试覆盖率（关键分支是否都有测试） 4. 需求覆盖度（任务卡里的验收标准是否全部满足） 输出格式： - 严重问题列表（必须修复才能合入） - 建议优化列表（可延迟处理） - 结论：通过 / 打回

这个流水线跑起来之后，你会发现一个很有意思的现象：Agent A和Agent C都是“不写代码的”，但它们恰恰是提升效率的关键。因为正是它们把需求和实现之间的缝隙填平了，编码Agent才能像“按图纸施工”一样高效。我给那些“让Agent自由发挥写整个项目”的人一句忠告：自由发挥的Agent产出的是看起来很合理但实际跑不通的代码，必须有人在前面定方向、在后面做验收。

3. 技术选型：为什么用Django做业务、Rust做边缘服务、部署在阿里云

技术栈选型这事，在AI Agent交付项目里比传统项目更敏感。原因很现实：你选的每一种语言、每一个框架，AI生成代码的“靠谱程度”天差地别。Python + Django生态成熟，AI训练语料极多，生成代码的准确率远高于那些冷门框架。而冷门技术栈一旦让AI去写，它经常会一本正经地编造不存在的API，坑到你怀疑人生。

这个项目我最终用在业务侧的是Python + Django + PostgreSQL，直接用Django自带的Admin和DRF（Django REST Framework）快速搭CRUD接口。为什么不用Java Spring Boot？按理说企业项目用Spring更“正统”，但Spring那套注解和依赖注入配置，AI生成时的出错率明显高于Django。Django的ORM和Model定义接近字面表述，一个请求进来到数据落库之间几乎没有黑魔法，这对AI生成代码的可控性和可审查性都是极大的加分项。

那Rust在这个项目里干什么用了？我用Rust写了一个独立的边缘数据服务，负责三件事：从外部Excel批量导入订单数据、做数据格式校验和清洗、生成对账报表。为什么这部分用Rust？因为它是一个高频、独立、并发压力大的模块，而且逻辑闭环，不需要和Django的业务模型纠缠。Rust在这里的优势是编译期就能拦住很多问题，单二进制文件部署特别友好。但我不建议把Rust塞给规划Agent去生成大量复杂业务代码——Rust的所有权和生命周期对AI来说还是容易出概念错误，调试成本高，我在这个项目里就让Agent只在极小范围内生成Rust代码，核心代码我自己手写校验。

Django和Rust两个服务之间通过一个简单的HTTP接口通信，Rust服务纯粹做数据处理，把清洗好的结构化数据吐给Django的API，Django负责落库和业务流转。这样的边界设计，让AI Agent写Django侧的代码时不需要理解Rust内部，反过来Rust侧的手写代码也不受Agent代码的干扰。

部署这块我放在阿里云上，一台4核8G的ECS跑Django（Gunicorn + Nginx），一台2核4G的跑Rust服务，数据库用云上的PostgreSQL，对象存储放导入的Excel源文件和生成的报表。打包部署直接编写Dockerfile，用云效流水线做CI/CD，提交代码后自动跑测试、构建镜像、推送、发布。整个部署链路，我花了大概一天半的时间搭好，之后3周里再也没有手工上服务器操作过。

有一说一，阿里云这种主流的云平台，胜在文档全、控制台顺手、生态工具齐。AI Agent在写部署脚本和Dockerfile时，也能从训练数据里学到大量阿里云的正确用法，不会给我编造一堆根本不存在的控制台按钮或CLI参数。

4. 3周实操复盘：每天在干什么、任务怎么拆、节奏如何把控

光说方案太虚，我直接把这3周的关键节奏复盘出来，你可以对照着看AI Agent到底是怎么实打实干活的。

第一周，核心是做架构和数据地基。周一上午，我把项目需求文档扔给规划Agent，让它输出全量任务清单。它产出大概52个任务卡，我花了一下午把任务卡一个一个过了一遍，把明显不合理的地方打回重做，比如它把权限模型设计得过于复杂，把简单的RBAC搞成了多租户隔离，我让它简化。周二到周三，让规划Agent产出数据库DDL和接口签名，这个环节就是不断“挑毛病”的阶段。数据字典对齐、字段类型确认、状态机枚举值统一，全部在周四前定稿。周五，Agent B开始按任务卡搭建Django项目骨架，实现用户登录、权限校验、基础CRUD。周末我自己加班补了一些Agent做不好的事：编写初始种子数据，配置Nginx和Gunicorn的部署脚本。

第一周跑下来，我最大的体会是：规划Agent的产出质量，直接决定后续两周的顺畅程度。如果你不花时间在前期去校验它的任务拆解、数据模型和接口契约，后面所有Agent都会在一个错误的地基上疯狂盖楼，那种返工是灾难级的。

第二周进入业务功能密集开发期。我把52个任务卡按依赖关系排成队列，每天早晨并发派给Agent B两到三个任务，它完成一个我立刻跑一轮测试并把diff丢给Agent C审查。Agent C打回的问题，我再连同审查意见一起发回给Agent B修改。这个循环一天能跑三到四轮，每天大概合并20到30个文件。我在这个阶段的角色，已经从“写代码的”变成了“派活、复核、把关的工头”。

这个环节里我总结了一个特别重要的技巧：永远不要让Agent B同时处理两个关联度高的任务。比如“订单创建”和“订单审批流”如果一起交给它，它会自作主张地合并表结构或调整字段语义，然后两边逻辑全乱。我宁可把任务切得更小，一个卡只干一件事，哪怕多派几轮都行。

整个第二周，订单管理、客户管理、供应商管理、库存台账这些核心模块陆续跑通，测试用例从0涨到260多个。当然，这不是说没有返工，但Agent C审查提前拦掉了七八成的问题，人工返工基本控制在“改需求”范畴内。

第三周，进入联调、修数、演示交付。这一周的工作大头其实是“接缝处修补”。Django后端、Rust数据处理服务、前端页面这三块单独看起来各自都能跑，但连起来总有数据对不上的地方。比如Rust导入的订单金额在Excel里是“元”，Django业务里存的是“分”，对账报表里又用“万元”，同一个数字三个口径，反复改了好几轮才统一。这种事Agent不会替你发现，必须靠人工盯着看全局数据流。

第三周后半段，我做了一次全量回归测试，把所有核心流程按真实业务场景跑了一遍，然后把部署流水线调整到生产环境，做了数据初始化、权限分配、操作手册编写。第21天下午，项目演示给业务方，订单流转、审批通知、报表导出全部顺畅，项目交付。做演示的时候，业务方还在问功能细节是不是要再调，我心里清楚，这套代码里埋着Agent C拦住的那些雷，所以心里还算有底。

5. 实战中出的问题，以及我的排查与规避方法

用AI Agent交付项目，一定不是一帆风顺的。我在3周里遇到了不少具体问题，挑几个典型的说说，也附上我的处理办法和避坑建议。

第一个问题是上下文丢失，这是最多发、最头疼的问题。Agent B在实现复杂任务时，经常写到一半忘记任务卡里的约束条件。比如任务卡里明确写了“只有部门主管角色可以发起审批”，它实现到后期竟然只判断了登录态，权限校验没做。追问它为什么没写，它的回复是“根据上下文推断此处不需要权限”。这种“自信的理解偏差”是AI生成代码的第一大杀手。

我的解法是两条腿走路：第一条，把任务卡写得特别细，验收标准必须量化、可执行，比如“非主管角色调用该接口必须返回403”，不写“需要权限控制”这种模糊表述；第二条，依赖Agent C的审查兜底，提醒它在审查时把任务卡里的每一条验收标准和代码行为逐一对应，缺少权限判断等问题就会被打回返工。

第二个问题是幻觉API，多见于Rust侧。我在让Agent B补一段读写文件并做并发处理的Rust代码时，它使用了某个并不存在于标准库的并发工具函数，编译直接报错。解决这个问题没有捷径，只能是我自己在编译错误面前逐行排查，把幻觉API换成了标准库的成熟方案。

这里延伸出一个思考：热词里总被提到的“基于Rust语言的AI Agent”，我在这个项目里用到的程度比较克制。Rust本身做高性能数据处理服务没有任何问题，但让Agent大规模生成Rust代码，当前阶段我还不太推荐。相比Python和TypeScript，Rust代码一旦生成错误，纠错成本高得多，这会让“Agent提效”大打折扣。

第三个问题是Token成本控制。规划Agent在分析需求时会一次性读入很长的项目背景，Coder在实现大任务时还会反复读入之前的代码，Token消耗大得吓人。我一度担心项目做完后AI工具账单会爆炸。后来我做了两个调整：一是严格控制Agent B的输入，只让它读当前任务相关的代码文件，不把整个项目一股脑塞给它；二是给每个Agent设置一个“输出精简模式”，比如要求Agent C只输出严重问题和打回原因，不要长篇大论地写分析报告，既省Token又没降低审查质量。

整个项目跑下来，三个Agent的Token消耗折合人民币大概400多元，加上云服务器费用，总共不超过600元。相较于4人团队2个月的人力成本，这个成本完全可以忽略。

第四个问题是Agent的“过度自信”。这个问题在一开始尤其严重，Agent B写完代码后，它会自信地说“代码已完成，测试全部通过”，但实际上测试用例一个都没跑。后来我在Agent B的工作流里硬性加了“必须贴出测试执行命令和输出结果”的要求，它才老实下来。从此我发现，给Agent设定行为约束比给它灌知识更重要。

最后一个问题是多Agent协作时的模型幻觉释放。因为Agent A想把数据模型设计得特别完整，Agent B又想把功能实现得特别全面，两者叠加，很容易把一个简单需求放大成一个怪物系统。比如本来一个客户管理模块，Agent A给出了30多个字段的复杂表结构，Agent B又加上了批量导入、历史版本、数据对比等一堆额外功能。面对这种“撒欢行为”，我就是砍。需求文档没有明确提及的功能，一律不进开发范围，这是我对所有Agent的绝对红线。

6. 什么样的项目适合用Agent交付，以及最后的几条心得

这套3 Agent交付的打法，并不是所有项目都能复制的。我做完这个项目后，仔细想了想它的适用边界，毫无保留说清楚。

最适合的是“逻辑闭环清晰、需求边界稳定、没有太多历史包袱”的企业业务系统。比如订单管理、审批流、库存管理、CRM这种，业务规则明确，CRUD占比高，状态流转可预测，AI Agent能发挥最大价值。反过来，如果项目是探索性的、需求天天变，或者要深度集成一堆老旧系统，甚至要处理大量晦涩的业务历史遗留逻辑，我劝你不要硬上Agent，老老实实靠人一步步摸。

我的最终交付配置很简单：4人团队，实际全职投入只有我一个人（你如果也想像我一样压缩团队，前提是你自己有足够的技术判断力），外加三个Agent分别承担规划、编码、审查。项目结束时，代码仓库里大约有3000多次提交，超过1100个测试用例，最终项目按期交付，业务方验收一次通过。

最后分享几条我自己最深的体会，也是这个项目真正教给我的东西：

第一，AI Agent交付项目，人永远是最关键的瓶颈和天花板。Agent可以把你的产能放大，但它不会替你思考。需求怎么拆、边界怎么定、Agent产出怎么把关、哪些功能不能做，这些判断只能由人来完成。别指望扔一个需求给Agent，它就能自己把项目做完。

第二，流水线式协作优于自由式协作。3个Agent各司其职、上一个的输出是下一个的输入，远比一个全能Agent什么活都干要稳定。后者看着灵活，实际跑起来，上下文混乱和各种幻觉会让你崩溃。

第三，审查永远不要省。规划、编码、审查这个铁三角里，审查Agent的价值是被我严重低估后重新抬起来的。它不只是找Bug，它还在持续用任务卡校准Agent B的“跑偏倾向”，这种“用代码审查对抗代码幻觉”的机制，是整个模式稳定运行的定海神针。

第四，迭代节奏越短越好。我的实操经验是，把大任务切小，让“编码—审查—修复—复核”这个循环以2到3小时为单位推进，比让Agent长跑几小时交一个大结果要靠谱得多。每一个小循环，都是一次纠错和校准的机会。

这套方案现在还能不能继续优化？我觉得可以。下一步我想把Agent A和Agent C的上下文做成知识库形式，把项目历史决策、常见返工原因沉淀下来，让它们在后续项目中越用越聪明。但那是下一篇的题材了，这3周的项目，先记到这里。