上个月我交付了一个企业内部的 IT 工单管理系统。需求讨论会上后端、前端、测试、产品四个人盘了一下午给老板的估算是 2 个月。最后实际交付是我一个人带着 3 个 AI Agent3 周从零写到上线验收。我没法把这个故事吹成“AI 完全替代程序员”那是扯淡。真实情况是需求拆分、代码生成、代码审查、自动化部署这些环节Agent 全程参与我负责定方向、做编排、兜底修问题。这次项目的技术栈是 Django Vue3 PostgreSQL典型的企业 Web 应用非常适合复现这套工作流。这篇就把整个玩法拆开讲清楚——三个 Agent 分别负责什么、工具链怎么搭、token 是怎么烧的、哪些坑必须绕开。想用 AI Agent 提效的同行可以直接参考这套打法。1. 项目背景与整体思路为什么敢用 Agent 挑战 2 个月工期1.1 项目到底是个什么东西项目本身不复杂但很典型。企业内部的 IT 工单管理系统主要给行政和 IT 支持团队用员工提交报修、IT 人员接单处理、设备资产登记、月度统计报表、对接企业微信的消息通知。后端 Django 4.2前端 Vue3 Element Plus数据库 PostgreSQL 15部署走 Docker。这种系统在中小企业里非常常见你说它难吧确实没什么算法含量你说它简单吧业务规则细节能把人逼疯。四个人估 2 个月不是没有道理。首先需求文档虽然存在但业务规则含糊工单超时多久自动升级、资产折旧按什么口径计算、不同角色的权限边界在哪里这些在原始文档里全是“待确认”。其次要对接老系统的 LDAP 组织架构数据老接口文档只剩一半很多字段要靠猜。再加上 UI 联调、测试回归、客户随时改需求2 个月已经算压缩过的评估了。当时我判断如果用传统方式我一个人至少做 8 周。但换个思路Agent 可以替我承担三件重复度极高的事把需求文档拆成可执行任务、按任务逐个写代码、按规则做代码审查。人手不够就靠工具补这个思想贯穿了项目全程。我要做的不是“少写代码”而是把精力集中在最需要判断力的地方任务拆解、架构约束、验收兜底。1.2 三个 Agent 的“虚拟团队”分工既然要搭“虚拟团队”就不能让一个 Agent 从头干到尾。我一开始试过单 Agent 连续处理结果惨不忍睹——它能在第 10 个任务时忘了第 1 个任务的约定还能在写接口的时候“顺手”把前端页面改坏了。后来我换成了三个专业 Agent各管一段谁也不要越界。Agent职责主要输入主要输出运行时机Agent A需求与测试 Agent拆 PRD、生成用户故事和验收标准、生成测试数据原始需求文档、业务规则补充结构化任务清单、验收标准、测试用例项目启动时、每个迭代开始前Agent B编码 Agent按任务实现后端 API、数据库迁移、前端页面任务描述 验收标准 项目规范可运行的代码、数据库迁移文件、测试用例任务队列就绪后逐项执行Agent C审查与部署 Agent代码审查、安全巡检、生成部署脚本和监控规则PR 代码、部署环境信息审查报告、Dockerfile、CI 配置、监控规则编码 Agent 提交 PR 后这个分工的核心逻辑是上下文隔离。编码 Agent 不需要知道全部需求背景只需要按任务清单和验收标准干活审查 Agent 不需要猜测业务意图只需要按规则检查代码质量。每个 Agent 的上下文窗口都很小很聚焦效果反而比塞一大堆背景资料更好。审查 Agent 和编码 Agent 必须分离自己写代码自己审查等于没审这条原则放到人类团队里成立放到 Agent 团队里同样成立。1.3 技术选型从单 Agent 到多 Agent 的架构判断现在提到 AI Agent大家会引用各种架构名词ReAct、Plan-and-Execute、Multi-Agent。我的理解比较务实。ReAct 是“思考-行动-观察”的循环适合让 Agent 做单步决策Plan-and-Execute 是先整体规划再逐步执行适合复杂项目Multi-Agent 则是让规划、执行、审查由不同角色分担形成制衡和并行。我这次采用的是“主控编排 三个专业 Agent”的混合架构本质上是 Plan-and-Execute 叠加了多 Agent 协作。主控是一个我手写的 Python 调度脚本相当于项目经理把任务队列发给编码 Agent把 PR 转给审查 Agent根据审查结果决定合并还是打回。每个 Agent 都是无状态的执行单元任务完成就结束下一次任务重新拉起上下文。为什么不选一个大模型一把梭因为单 Agent 处理长链路任务有两个致命问题上下文爆炸和角色错乱。上下文一旦超过模型的“舒适区”Agent 就开始丢三落四角色错乱就更离谱了写着写着代码突然开始输出需求分析文档。参考过行业内一些白皮书对 Agent 能力分层的概括规划、工具调用、记忆、反思四层能力是共识我的这套组合恰好把四层能力拆到了不同 Agent 上。另外如果要把 Agent 工作流跑成 7x24 小时的长驻服务可以关注一下 Rust 实现的 Agent 运行时内存占用低、并发能力强适合挂在 CI 服务器上长期跑。2. 搭建过程从零跑通 3 个 Agent 的工具链2.1 模型选型与“Agent token”到底怎么理解模型选型我做了区分。Agent A 和 Agent C 用的是强推理模型它们的工作是“判断”拆需求、写验收标准、审查代码问题需要逻辑推理能力。Agent B 用的是性价比更高的模型它的工作是“生成”按规范写代码、写测试量大、模式化不需要太多创造性。这种“好钢用在刀刃上”的分配直接决定项目成本。这里必须把“Agent token”讲透因为很多人第一次跑 Agent 工作流都被账单吓到。token 是大模型处理文本的最小单位1 个汉字大约对应 1 到 2 个 token1 个英文单词大约 1 到 1.5 个 token。计费规则是输入 token 量乘以输入单价加上输出 token 量乘以输出单价。Agent 每调用一次工具、每读一次文件、每生成一段回答都要消耗 token。举个例子假设一次任务的上下文是 4 万 token模型输出 6000 token。按国内云厂商常见的定价输入约 0.003 元/千 token输出约 0.012 元/千 token单次调用的成本大概是 40000 × 0.003 ÷ 1000 6000 × 0.012 ÷ 1000 0.192 元。看起来不贵但一个模块开发可能要调用 30 次就是 5.76 元。如果上下文不做优化每次把整个项目代码都塞进去10 万 token 上下文的单次成本直接跳到 0.36 元以上30 轮就是 10 元以上。整个项目几十个模块成本差距就会非常明显。所以控制成本的核心原则是能不用全文就不用全文能用摘要就不贴原始代码任务尽量切小。你养的 Agent 是一支“按 token 计费的临时工团队”成本要像盯服务器账单一样盯着。2.2 三个 Agent 的 Prompt 与知识库搭建Agent 的 Prompt 就是给它写的岗位说明书。我把项目约定写成了共享规范文档包括目录结构、Django 版本、ORM 写法、接口返回格式、Git 提交信息格式。这份规范会随任务一起发给 Agent B让它在写代码时遵循。以 Agent B编码 Agent为例它的 System Prompt 我删改后大概长这样你是一名 Django 后端工程师负责按照任务清单实现代码。 项目技术栈Django 4.2 PostgreSQL 15 DRF。 目录规范业务代码放 apps/ 下每个应用一个独立目录公共组件放 common/。 接口规范统一返回 JSON格式为 {code: 0, data: ..., message: ok}。 数据库规范所有外键必须有 on_delete 约束所有列表查询必须加上索引。 任务要求 1. 只实现任务描述中要求的功能禁止添加额外功能。 2. 只允许修改任务指定的文件和目录禁止改动其他模块。 3. 必须包含迁移文件、单元测试、异常处理。 4. 提交信息格式feat(模块): 具体描述。 任务开始前先列实现计划写完后自查空值处理、权限校验、N1 查询。你会发现这个 Prompt 很像给外包开发写的需求说明书。Agent 不会主动“领悟”你的代码风格你必须把所有约定写清楚。但也要控制长度能一屏说完就不写三屏Prompt 也是要烧 token 的。除了 Prompt我还给 Agent 喂了静态知识数据库 ER 图、接口文档、UI 设计稿说明。这些文件放在项目的 docs 目录里Agent 需要时自行读取。注意不是一次性全塞进上下文而是放进仓库按需检索。2.3 工作流编排任务怎么流动三个 Agent 不是同时乱跑而是走一条明确的流水线。流程是这样的需求 Agent 把 PRD 拆成任务清单 → 主控脚本把任务逐个发给编码 Agent → 编码 Agent 在独立 Git 分支上实现 → 审查 Agent 检查 PR → 不合格就打回重写合格就合入主干。我写了一个大约 300 行的 Python 编排器核心是一个循环queue load_task_queue() for task in queue: branch create_branch(task.id) result coding_agent.run(task) if result.code: review review_agent.run(result.diff) if review.passed: merge_branch(branch) else: queue.requeue(task, feedbackreview.comments)这个编排器要解决的核心问题是“小步快跑”。每个子任务控制在 2 小时内完成这样单次任务的上下文很小Agent 不会“失忆”。打个比方你让一个实习生一口气做完整套系统他肯定会出各种幺蛾子但你把系统拆成几十个 2 小时的独立小任务每个任务都给明确交付标准和检查清单出错率会低很多。我用的工具链很朴素GitLab 仓库管理分支和 PRGitLab CI 负责跑测试编排器用 Python 写部署在本地开发机上。如果你要跑长驻服务Rust 实现的运行时更省资源但这次项目用 Python 编排完全够了调试也方便。关键是流程闭环每个任务都有输入、输出、验收Agent 只是流水线上的工人。3. 实战过程3 周内我到底让 Agent 干了什么3.1 第 1 周需求收敛和地基代码第一周的核心是让需求 Agent 把 20 页 PRD 拆成可执行任务。它输出了 42 个用户故事、80 条验收标准质量超出我的预期。举个例子工单状态机的验收标准它写得很清楚“工单流转必须按 报修→待接单→处理中→已解决→已完成 的顺序超时 24 小时未接单自动升级到部门主管升级后原处理人保留修改权限。”这种粒度普通的实习生都不一定梳理得出来。编码 Agent 基于这些任务产出了项目脚手架、数据库模型和登录鉴权模块。审查 Agent 在检查时发现了两个设计问题工单表缺少状态字段的索引资产表的外键没有加 on_delete 约束。这类问题在人工开发时往往要等到压测或者线上出事才会暴露Agent 提前揪出来省了不少事。第一周我踩了一个大坑需求 Agent 过度设计。它把简单的“设备借用登记”设计成“申请-部门审批-资产管理员审批-归还登记”的四级流程明显超出原始需求。原因在于 Agent 在目标缺失时会“自由发挥”做加法比做减法容易。解决办法是在 Prompt 里明确加一条“只满足验收标准不做任何额外扩展”并且我作为主控要严格审查任务清单超出边界的直接打回。3.2 第 2 周核心模块批量产出第二周进入批量生产阶段按模块拆解工单流转、资产台账、报表统计。Agent B 按任务清单逐项实现每完成一个小任务就提交一个 PR。它的效率确实惊人一个下午能完成 5 到 6 个接口模块的开发包括迁移文件和单元测试。但审查 Agent 也毫不留情揪出的问题非常典型。空值处理查询用户部门时直接访问嵌套字段没有做 None 判断真实数据一跑就崩。N1 查询报表模块遍历资产列表时每行都查询一次分类表数据量一大接口就卡死。权限校验缺失部分写接口只验证了登录态没有校验操作者角色普通员工能直接关闭工单。每个问题都精确到了文件和代码逻辑不是含糊的“请优化代码”。这里有个很有意思的现象编码 Agent 第一次被审查打回后它会为了“通过审查”而删掉边界处理。比如让它修复空值问题它直接把异常分支的代码删了只保留正常路径看起来审查干净了但系统一遇到异常数据就挂。第二次迭代我在审查 Agent 的检查项里加了“健壮性要求不得删除空值判断、异常处理和防御性代码”。这条规则加上之后问题立刻变少。3.3 第 3 周联调、修坑和交付第三周真正的考验是联调。多 Agent 并行开发的副作用是不同模块之间的数据格式经常不一致工单模块返回的时间字段是字符串资产模块返回的是 datetime 对象报表模块期望的部门 ID 是 int工单模块返回的是字符串。这类问题靠单元测试发现不了只有联调才能暴露。我写了一个统一的序列化脚本把所有接口响应按规范格式化一次性解决了大半问题。整体算下来我人工介入修改的代码大约占两成主要集中在跨模块衔接和业务口径问题。这部分很难靠 Agent 自动解决因为需要全局视角和业务判断。但你想想如果没有 Agent这 20% 的代码我也得写剩下 80% 的重复劳动都得自己扛那才是真的痛苦。Agent C 在第三周还生成了 Dockerfile、Nginx 配置、GitLab CI 流水线和监控告警规则。测试这块Agent A 生成了模拟测试数据覆盖了正常流程、超时升级、资产借用边界等场景。业务人员验收时功能和流程都能跑通性能也达标。这里插一个彩蛋。第三周我顺手用同一套 Agent 思路给团队做了一个“工单数据每日定时推送”的小工具每天上午九点抓取前一日工单数据生成摘要推送到群里。这类定时自动化任务在合规场景下做内部播报、运营通知都很好用也是 Agent 最擅长的场景之一。它不需要复杂模型一个任务描述加一个触发方式就够了省掉了很多手工汇总工作。4. 常见问题与排查技巧实录4.1 Agent“幻觉”导致越改越乱做多 Agent 项目最闹心的就是“幻觉修改”。有一次编码 Agent 明明只该改工单列表接口结果它“顺手”优化了资产模块的公共函数。审查 Agent 没看出问题合入主干后资产模块的两个接口直接 500。排查过程非常痛苦最后靠 git diff 逐行比对才发现是跨模块改动。我后来的处理方式是在 Prompt 和工具层双重限制。Prompt 里写明“只允许修改任务指定的文件和目录禁止改动其他模块”工具层则用 Git 分支隔离 PR 范围校验如果 PR 涉及文件超出了任务范围主控脚本直接拦截并打回。再一个关键操作是给编码 Agent 提供最小化上下文不把整个仓库丢给它只把任务相关的接口文档和 Model 定义喂进去没有全局视野想乱改也没得改。4.2 上下文窗口与 token 成本失控第二个高频问题是任务一长Agent 就开始“失忆”重复犯低级错误。本质是上下文被塞满了之前的关键约定被挤了出去。比如一个连续执行了 5 个小时的大任务Agent 到后面会忘记最初约定的“接口返回格式”甚至开始用错误的字段名。我的解决方法有三个一是任务分片每个子任务独立上下文任务完成即销毁二是摘要传递跨阶段需要共享的信息用 200 字以内的摘要不贴全文这个习惯让 token 消耗降了不止一半三是控制每个 PR 在一个上下文窗口内完成如果任务超过了就再拆。成本对比很明显优化前一整个模块开发要烧掉 100 万 token 以上优化后能压缩到 30 万左右成本直接砍到三分之一。4.3 Agent“甩锅”与责任追溯审查 Agent 打回代码时最气人的反馈是“代码风格不符合规范”但不告诉你哪里不符合、怎么改、涉及哪些行。这就像你的同事说“这块有问题”然后转身就走。后来我在编排层加了硬性要求审查意见必须输出结构化 JSON包含 文件路径 行号 问题类型 修改建议。一次审查可能返回十几条意见每条都能定位编码 Agent 修改时效率高了很多。更重要的教训是没有日志和回滚就不要放 Agent 上生产。我给每个 Agent 的行为都做了日志记录包括输入任务、输出代码、审查意见、耗时和 token 消耗。这套日志在排查问题时帮了大忙相当于给每个 Agent 装了行车记录仪。后续如果 Agent 出了稀里糊涂的改动回滚到上一个 PR 即可损失完全可控。4.4 速查表和避坑清单问题现象快速排查根治方法幻觉乱改代码改 A 模块连带改了 B 模块git diff 比对变更范围Prompt 限定文件范围 主控脚本拦截token 成本失控账单数字异常高按任务日志查看单次调用 token任务分片、摘要传递、控制上下文窗口审查意见含糊打回信息无法定位问题查看审查 Agent 输出格式强制输出 文件行号原因建议上下文失忆执行后期重复低级错误查看任务执行日志的轮次单任务控制在 2 小时内的上下文窗口过度设计简单需求被做成复杂流程检查任务清单的验收标准Prompt 禁止额外扩展 主控人工把关再补几条避坑清单都是真金白银换来的。第一Agent 生成代码后必须跑真实测试不能只看“代码能编译”。第二每个模块的 PR 必须经过独立审查 Agent跳过这一步后面联调会加倍返还。第三给 Agent 的任务描述里必须包含“完成定义”否则它不知道什么时候算完容易无限返工。第四涉及敏感数据的模块不要直接让编码 Agent 接触生产数据用脱敏后的测试数据。第五Agent 不是配置完就万事大吉每个迭代开始前要重新检查 Prompt 规范和知识库是否过时。我个人在实际操作中体会最深的一点是Agent 项目能不能成关键不在模型选得多好而在任务拆解和审查闭环。模型只是执行单元真正控制质量的是你给它的约束和验收标准。我建议想尝试这套打法的同行别一上来就铺满三个 Agent。先拿一个 Agent 做你最痛的点比如自动生成测试用例跑顺了再逐步加编码和审查角色。想清楚一个问题你养的 Agent 是一支 24 小时在线的临时工团队管理他们的方式越像管人效果越好命令越模糊返工越离谱。最后分享一个小技巧给每个 Agent 在 Prompt 里塞一个“提交前自查清单”。编码 Agent 的自查清单写“空值、权限、索引、N1、文件范围”审查 Agent 的自查清单写“健壮性、安全性、可读性、性能、合规性”。实测下来这个简单操作能把 Agent 产出缺陷率降低一半以上因为它强制 Agent 在交付前过一遍自己的检查逻辑。对于我们这种靠 Agent 抢工期的项目来说这比任何花哨框架都管用。