上周把签完字的交付文档扫描进文件夹的那一刻我才真正松了口气。一个人三周用 3 个 AI Agent 干完了一个 4 人团队排期 2 个月的企业项目。项目本身不复杂但绝对是那种最典型的“没人愿意接”的内部管理系统——一堆旧 Excel 报表要迁移、十几个角色要配权限、月底导出对账数据还要准点完成。要没 AI Agent按传统打法我大概率也得搬个小板凳去会议室跟产品经理磨一个星期需求。说到 AI Agent很多人第一反应是“能用自然语言让我干活的东西”。这么理解没错但真正落地到企业项目里它更像一个“有手有脚有脑子的实习生”能读文档、能写代码、能跑测试、能调部署脚本关键是不睡觉。我这次没有搞一个万能的超级 Agent而是拆了三个各管一摊的 Agent一个管需求和验收标准一个管代码实现一个管测试和上线。这种拆法不是我拍脑袋想的而是被前几次单 Agent 干大活的惨痛教训逼出来的。这篇东西不想讲虚的就把我怎么搭、怎么配置、怎么控制成本和避坑的全过程写出来。适合谁看想用 AI Agent 提效的开发、项目经理、技术负责人尤其是对“Agent 能不能交付真实企业项目”还存疑的人。1. 交付前先想清楚3 个 AI Agent 为什么这么分工1.1 为什么不是一个“万能 Agent”一次性搞定先说我之前踩的坑。最早我想得很简单一个 Agent把需求文档全塞给它让它从数据库设计一路干到部署脚本。结果第一天就崩了。原因不是模型不够聪明而是“什么都让它管”这件事本身就违背了工程原则。第一个问题是上下文窗口。大模型单次能处理的信息量是有限的用行话讲叫 token 上限。一个企业项目的需求文档、接口文档、旧表结构、前端页面描述加起来轻松超过几十万 token。你不可能全部塞进一次对话里更不可能让一个 Agent 边写登录模块边记着另一个模块的权限逻辑。第二个问题是职责混乱。当一个 Agent 同时负责写代码、写测试、写部署脚本一旦任务链路中间出错你根本不知道是它理解错了需求还是代码生成了但测试用例写错了还是部署脚本本身有问题。排查成本比人工写还高。第三个问题是失败放大的代价。单 Agent 跑一个长任务链越往后越容易因为最初的某个小错而全盘崩掉。你只能重来前面所有成功步骤都被浪费。所以这次我痛定思痛采用了多 Agent 协作的方式。核心思路很简单参照软件开发团队的岗位分工把“一个人从头干到尾”拆成“三个角色各管一段”彼此通过共享的产物交接。这其实就是现在 AI Agent 主流架构里最常见的编排模式云厂商的白皮书也基本都是这个分层逻辑模型层、记忆层、工具层、编排层。我不追求技术上的花活只追求能稳定交付。1.2 三个 Agent 的职责边界与协作方式这三个 Agent 我分别叫它们“需求分析 Agent”“编码实现 Agent”“测试部署 Agent”。你可以把它们理解成一个迷你研发团队。需求分析 Agent 的输入是原始材料客户给的会议纪要、旧 Excel 报表、历史系统的操作录屏、零散的 Word 说明。输出是结构化的需求清单用户故事、页面清单、字段字典、验收标准。这个环节的核心要求是“克制”不能模型自己脑补需求遇到不一致的地方必须标记为“待确认”交给我去跟客户核实。编码实现 Agent 的输入是需求分析 Agent 产出的任务清单再加上我手写的技术规范文档。输出是后端代码、前端页面、数据库迁移脚本、接口文档。这个 Agent 只干一件事把拆好的任务一个个实现每个任务完成就提交一次代码并且必须跑过对应的单元测试才能算完。我给它单独建了一个项目仓库它看不到需求分析 Agent 的原始材料只看结构化后的任务卡避免被无关信息干扰。测试部署 Agent 的输入是需求分析 Agent 写的验收标准加上编码 Agent 生成的可运行系统。输出是自动化测试用例、测试报告、部署脚本、上线检查清单。它负责的是“最后一公里”先把验收标准翻译成可执行的接口测试和页面冒烟测试然后启动系统跑一遍发现问题就把日志和复现步骤丢给编码 Agent 去修。这三个 Agent 之间不直接对话全靠共享的中间产物接力。需求分析 Agent 把任务卡写进项目文档库编码 Agent 从文档库取任务、把代码推到 Git 仓库测试部署 Agent 从 Git 仓库拉代码、把测试结果回写到文档库。这种“异步协作”的好处是每个 Agent 的输入输出都是结构化、可审查的哪一步出问题我一眼就能定位。1.3 我参考的 Agent 架构编排层、模型层、工具层、记忆层如果你去看现在各家的 AI Agent 白皮书会发现大家讲的架构基本收敛到了四层模型层、记忆层、工具层、编排层。这次实践我基本就是按这个框架落地的只不过没把架子搭得太重。模型层就是选哪个大模型来当 Agent 的“大脑”。我用了三个不同定位的模型而不是一个模型通吃。需求分析 Agent 用上下文理解能力强、指令跟随好的模型编码实现 Agent 用代码能力最强的模型测试部署 Agent 用便宜、速度快、稳定性好的模型。这个选择后面详细说先记住一个原则Agent 的效率很大程度取决于你愿不愿意为不同岗位花不同的钱。记忆层解决的是“Agent 怎么记住前面的信息”。我建了一个项目知识库把需求文档、验收标准、技术规范、数据库字典都放进去。每个 Agent 在开始任务前通过检索只把跟自己相关的片段取出来而不是把整个项目文档塞进上下文。这能省大量 token也能减少模型被无关内容干扰的几率。工具层是让 Agent 能“动手”的接口。我给 Agent 接的工具包括文件读写、命令行执行、Git 操作、数据库查询、接口调用。没有这一层Agent 只是个聊天机器人有了这一层它才能真的改代码、跑测试、发部署请求。编排层是最容易被低估的。它决定了三个 Agent 谁先跑、谁后跑、失败怎么重试、结果怎么汇总。我这次用的是 Python 写的轻量任务调度脚本没有上重型框架。任务队列、状态标记、重试机制加起来也不到 300 行代码。很多团队喜欢一上来就搭漂亮的 Agent 平台但我建议先把编排的核心逻辑搞清楚任务状态要可追踪失败要可重试产物要可审查。2. 搭建细节模型选择、提示词、Token 控制与编排2.1 需求分析 Agent把原始材料变成可验收的任务清单我先说需求分析 Agent 怎么搭因为它决定了后面所有环节的质量。这个 Agent 不写一行业务代码但它产出的任务卡如果质量差编码 Agent 再强也白搭。我给它设计的提示词里最重要的一句话是“不要臆造需求。原始材料里没有的内容一律标记为待确认放在单独章节等待人工回答。”这句话救了我很多次。AI 模型天然有“补全”倾向给它三页会议纪要它能脑补出十页详细设计。用在创意写作上没问题用在企业项目上就是灾难。具体的输入材料我整理成三种一是客户提供的旧 Excel 报表模板这能直接看出页面上必须有哪些字段二是历史系统的操作录屏能看出真实业务流程三是会议纪要能看出哪些功能是客户迫切要的哪些只是随口一提。我把这些材料按目录放好让需求分析 Agent 先通读再输出四个文档。第一个文档是用户故事清单每条用户故事包含角色、操作、目的三个要素。第二个文档是页面清单每个页面包含页面名称、入口、核心组件、权限要求。第三个文档是字段字典把所有业务字段、类型、来源、校验规则列清楚。第四个文档最重要是验收标准每条用户故事对应至少一条可验证的验收标准比如“月底最后一天 18:00 后财务角色可以在报表页导出上月对账单文件大小不超过 50MB”。我还给这个 Agent 加了一个输出格式要求最终结果必须是一个 Markdown 文件加一个 JSON 任务汇总。JSON 里每条任务的 ID、标题、优先级、依赖关系都要结构化。因为后面编码 Agent 要读 JSON 才能按顺序执行如果只是一篇漂亮文档机器没法直接消费。关于成本需求分析阶段我只跑了一轮全量分析加两轮补充提问总共消耗的 token 大概是八十万左右如果用多模态模型看录屏会更贵。但这部分花得值因为它压缩出了整个项目的基础结构。我常跟人说需求阶段省下的 token会在测试阶段十倍还回去。2.2 编码实现 Agent用 Django 写后端时我是怎么约束它的这次项目后端我用的是 Django因为客户内部技术栈就是这个以后他们自己的团队要接手维护。用 AI Agent 生成 Django 代码有个好处Django 的惯例约定非常强model、view、serializer、url 该放哪、该怎么命名都有标准答案大模型训练数据里这类代码特别多生成质量很稳定。但我没有让编码 Agent 直接“从需求到代码”一把梭。中间必须有一份技术规范文档这是我人工写的主要是为了让 Agent 的输出符合项目长期维护要求。规范文档里我明确写了Python 版本和依赖管理用 Poetry、数据库迁移必须生成独立的 migration 文件、所有查询必须在数据库层做分页、异常处理不能吞掉错误、日志必须包含 request_id、接口返回格式统一封装成 {code, message, data}。然后我给编码 Agent 设计的任务流程是从需求分析 Agent 产出的 JSON 任务清单里每次只拿一个任务根据任务卡里的页面清单和字段字典生成对应的 model、serializer、view、url 和前端页面写完立即在本地跑语法检查和单元测试通过之后提交代码并写一段变更说明再拿下一个任务。每个任务之间互不干扰前面失败也不影响后面。这里有个非常关键的点每次任务只喂“当前任务 相关字段字典 项目规范摘要”绝不把整个项目代码都塞给它。这是 token 成本控制的核心。一个大型 Django 项目全部代码可能有几十万 token如果每个任务都全量喂成本会失控而且模型会混淆不同模块之间的逻辑。我实际测算过每个任务平均只需要两万到四万 token几十个任务加起来比全量塞给模型要便宜一个数量级。关于“基于 Rust 语言写 AI Agent”这个话题圈子里最近很热但我这次没有自己从零写 Rust 框架。Rust 的好处是高并发和内存安全适合做 Agent 编排的底层调度但企业项目交付要的是快和稳我用 Python 写编排脚本、把大模型 API 和工具调用串起来完全够用。技术选型永远要服务于交付目标不是为了时髦。2.3 测试部署 Agent用便宜模型跑重复劳动的闭环测试部署 Agent 是我最意外的惊喜。一开始我觉得让 AI 写测试用例肯定不稳后来发现只要需求分析 Agent 的验收标准写得好测试用例的生成反而非常顺。甚至可以说这种机械化的翻译工作AI 做得比人还标准。我给测试部署 Agent 的输入是验收标准文件和编码 Agent 的可运行项目。它会自动做三件事第一根据验收标准生成接口测试用例每个用例包含请求路径、参数、预期状态码和预期返回结构第二启动本地测试环境执行测试把失败用例的日志和响应信息保存下来第三根据失败信息生成缺陷报告标记可能出问题的代码文件发给编码 Agent 修复。我选这个 Agent 的模型时没有用最强的代码模型因为它的任务大多是重复性、结构性的推理不需要太强的创造力。用便宜型号就行。同样的 token 数量成本可能只有编码模型的十分之一。这是很现实的问题测试环节要跑很多轮一轮任务可能消耗几十万 token如果不控制单价整个项目做完 API 费用会很难看。部署环节我也归给了这个 Agent。测试通过后它执行部署脚本打包、备份数据库、运行迁移、重启服务、做健康检查。我把服务器命令封装成工具接口Agent 只能调用白名单内的命令不能随意执行 bash。这个安全边界很重要否则 Agent 一旦生成错误命令可能直接把线上库给清了。整个闭环是这样的编码 Agent 修完代码推送到 Git测试部署 Agent 拉取最新代码重新跑测试测试通过后更新部署状态。只要质量门槛没过它就会一直循环直到通过或重试次数耗尽。我把最大重试次数设成 3超过 3 次自动暂停、通知我介入避免它在一个 bug 上空转几小时。2.4 把 3 个 Agent 串起来编排层与部署方式编排层是这次能三周交付的隐形功臣。我不需要手动在每个阶段切换不同 Agent而是写了一个任务调度脚本按状态机的方式流转。整个系统的状态可以简化成需求待拆解 - 需求拆解中 - 任务待开发 - 开发中 - 测试中 - 验收通过 - 已部署。每个 Agent 都只认任务状态而不是直接互相调用。我维护了一张任务表每条任务记录当前状态、负责 Agent、产物路径、历史日志。调度脚本每隔一分钟扫描一次状态表发现有处于“待开发”状态的任务就调用编码 Agent发现代码仓库有新提交就触发测试 Agent发现测试通过就标记该任务为“验收通过”。这样人只需要看状态表就知道整个项目走到哪了。部署环境我用了最简单的单机 Docker 方式。后端、前端、数据库各一个容器测试 Agent 在容器内执行迁移和冒烟测试线上部署也复用同一套镜像只是改了环境变量。没有搞 K8s也没有搞微服务因为企业项目规模摆在那复杂架构反而是负担。很多人在这一步容易陷入技术洁癖总想用最好的架构但用户要的是“月底能导出对账数据的系统”不是一堆放烟花的技术名词。我在这篇里反复讲“状态可追踪”是因为多 Agent 协作最大的风险就是失控。三个 Agent 各跑各的如果中间产物没有固定格式、状态没有统一登记很快会变成一场混乱。哪怕你只用最简单的 Excel 表记录任务状态也比三个 Agent 在一个聊天窗口里互相 要强得多。3. 三周实操流程每个阶段做什么、产出什么3.1 第一周需求结构化、系统骨架与第一版可运行后台第一周我把重心全部放在需求分析和系统骨架上。很多人拿到项目就急着让 Agent 写业务代码这不对。需求不确认清楚后面所有生成代码都是在打移动靶。周一我花了大半天做了最原始的脏活把客户发来的 17 个 Excel 报表模板、几段录屏和会议纪要整理成规范目录分类命名写了一个 README 说明每个文件是什么。这步没法自动化因为材料命名乱七八糟AI 也猜不出“最终版2.xlsx”和“最终版3.xlsx”的区别。周二上午启动需求分析 Agent。第一次全量分析跑了将近两个小时生成了 42 个用户故事、20 个页面清单、97 个字段定义。我逐条看了一遍改掉了三处明显脑补出来的需求。比如客户只说“首页能看到本月销售额”Agent 居然自动加了环比趋势图还设计了折扣率显示。这种补充看着贴心但企业项目里属于需求变更必须经过确认不能写进合同范围里。我把它标成“待确认”后来问客户对方确实不需要直接删掉。周三到周五搭建项目骨架。我不会让 Agent 从零手搓整个项目而是我先把 Django 项目初始化好配好数据库连接、依赖管理、基础目录结构把技术规范和代码风格配置文件放进去。这样做的好处是 Agent 只需要在既定框架里填业务代码出格的概率大大降低。从周三下午开始编码 Agent 开始实现第一批基础模块用户登录、角色权限、部门管理。这些是后面所有模块的依赖必须最先做而且要人工重点审查。第一周末尾系统已经能跑起来管理员账号可以登录角色权限的基础模型已经建好。这个进度如果按传统团队算大概需要一周半因为还涉及产品确认和前后端联调。Agent 帮我省掉的主要是“把需求转成代码”的时间但它省不掉我核对验收标准的时间。3.2 第二周批量实现业务模块我做代码评审与控制节奏第二周是产出最猛的一周。已经被确认过的 42 个任务里剩下 30 多个业务模块进入排队开发状态。我把任务按依赖关系排成序列每天分三批喂给编码 Agent。每批三到五个任务每个任务从开始到提交代码大约二十到四十分钟。一天下来编码 Agent 能完成十来个模块这个速度人工绝对做不到。但我没有当甩手掌柜。每个任务提交后我会做代码评审。重点看四件事一是模型生成的模型字段和需求分析的字段字典是否完全一致二是权限控制有没有漏三是数据库查询有没有写成全表扫描四是日志和异常处理是否符合规范。这四件事用眼睛扫一遍很快但能堵住 80% 的线上事故。第二周里我抓到过最典型的问题Agent 写导出功能时查询条件漏了时间范围等于每次导出都把全表拉出来数据量一大必崩。这种问题如果信誓旦旦让 Agent 自动交付到月底导出日就是事故现场。第二周中间我还让需求分析 Agent 做了一次增量需求解析。客户看到第一周的可运行后台后提了三个新需求新增一个“门店调拨”流程、报表支持自定义列、导出文件加公司 logo。我没有把这三个需求直接手写任务卡而是把客户原话丢给需求分析 Agent让它按原来的用户故事格式拆解再挂到任务队列后面。整个过程不到一个小时就处理完传统团队这里少不了一轮排期讨论。第二周结束项目的主要功能全部完成。编码 Agent 累计生成了一百多个 Django 模型字段、四十多个接口、二十个前端页面。Git 提交记录超过两百条。数据库迁移文件从 1 号排到了 36 号。这个体量的人工工作量四人的团队大概需要三到四周但还要算上互相等待的联调时间所以市场排期报两个月一点不夸张。3.3 第三周自动化测试、修复返工、灰度上线第三周进入测试和上线阶段。我把测试部署 Agent 放开让它接管质量检查。周一上午测试 Agent 根据验收标准生成了三百多条测试用例。这里我没有人工逐条写而是做了两轮抽查。第一轮抽查了 30 条用例确认它确实是按验收标准翻译的没有自作聪明改预期第二轮抽查了涉及权限控制的用例因为权限问题是企业系统最容易出事故的点。抽查没问题后我把整套测试跑起来第一次执行就暴露了 27 个失败用例覆盖了 6 个模块。周一下午到周二编码 Agent 进入修复模式。每个失败用例生成缺陷报告编码 Agent 根据报告定位代码并修复。这里要提一个执行细节我让测试 Agent 每个缺陷报告必须包含“复现步骤、预期结果、实际结果、相关日志片段”四要素这样编码 Agent 才能独立修不用再来回上下文拉扯。到周二晚上27 个失败用例降到 3 个。剩下 3 个不是代码问题是需求定义本身有歧义比如“导出对账单要包含已作废订单”里的“已作废”到底指什么状态我找客户确认后更新了验收标准再让 Agent 重跑。周三做上线前准备。测试 Agent 跑回归测试、检查数据库迁移脚本、生成上线检查清单。我人工做了最后两项一是让财务同事用测试账号实际跑了一遍月底结账流程确认操作手感没问题二是开了个半小时的线上演示会让客户业务负责人验收。整个过程没有出现大问题。周四下午申请灰度发布先在一个分支机构账号上开启新系统第二天观察数据无误后周五上午全量切换。这里我不是让 Agent 一键部署到生产环境。生产环境的切换时机、回滚预案、通知客户的时间点都得人拍板。 Agent 能帮你把部署技术动作做完但不能替你承担业务风险。三周结束项目交付完成。客户满意唯一“投诉”是文档太多了他们内部接手的人看不过来。我只好让需求分析 Agent 又花了一个小时把几十页文档压缩成三页操作手册加一页系统架构说明。4. 避坑与排查这些坑我替你踩过了4.1 三大高频问题幻觉、token 暴涨、Agent 进入死循环第一个高频问题是模型幻觉也就是 AI 自己编造不存在的需求或者代码逻辑。我前面说的“需求待确认清单”就是专门对付这个的。还有一种幻觉更隐蔽写代码时Agent 会引用一个不存在的第三方库函数或者以为 Django 有个内置功能其实没有。这种情况在语法检查阶段就会被拦下来。所以我一直坚持Agent 写完代码必须立即跑本地测试不能只靠肉眼看。第二个高频问题是 token 消耗暴涨。我有一次让编码 Agent 同时处理三个相互关联的任务它为了“稳妥”把整个项目的代码文件都读了一遍一次任务跑了二十多万 token相当于正常任务的十倍。后来我限制了它的工具调用只能读取任务列表里指定的文件不能随意列出目录内容。工具层一定要给 Agent 最小必要权限它能访问的信息越少消耗越少产生幻觉的可能也越少。第三个高频问题是死循环。测试 Agent 发现一个 bug编码 Agent 修完提交测试 Agent 再跑又发现新问题理论上这是正常迭代但有一次它俩在同一个问题上反复横跳了四次。我看日志发现编码 Agent 每次只修了表面现象没有修根因。这时候不能继续让 Agent 自己玩我直接介入看了两次失败用例的差异手动改了一行查询条件问题立刻解决。所以在编排层设置最大重试次数不是怕 Agent 不够努力而是怕它“无效努力”浪费时间。4.2 什么情况下必须人工介入别硬扛我总结下来有三类情况必须立刻人工介入不能指望把流程图调得更复杂就能自动解决。第一类是需求歧义导致的返工。只要 Agent 发现“验收标准无法翻译成可执行的测试用例”或者两个用户故事相互矛盾直接暂停找人确认。这个信号比什么都重要硬让 Agent 猜只会越猜越偏。第二类是涉及权限和数据安全的模块人工必须过一遍。AI 生成的权限检查一般能覆盖常规角色但“越权访问他人的数据明细”这类反常识漏洞初版代码大概率漏。我用十分钟手写了一个测试验证普通员工账号不能访问管理员接口结果真发现了三处越权点。第三类是线上发布动作本身。即使 Agent 能把部署脚本执行得很完美决定“什么时候切流量、要不要发公告、回滚阈值是什么”的必须是负责任的人。AI 只能当操作手不能当指挥官。4.3 想复制这套打法先满足这 3 个前提如果你看完也想在自己项目里复制这套打法我劝你先冷静对照三个前提。第一个前提是需求必须是“可以被结构化”的。如果你的项目本身没有明确的流程、字段、角色概念比如一个纯探索性的算法研究项目那让 Agent 拆任务只会拆出一堆幻觉。反过来像报表系统、管理系统、订单模块这种业务边界清晰的项目就是 Agent 的主场。第二个前提是你自己必须能看懂代码、能抓重点做评审。Agent 提效的前提是有人能兜底。如果你看不懂它生成的代码那这个效率不仅不可控还很危险。我三周交付是因为我知道哪里的代码容易出问题、哪里可以快速扫一眼放行。第三个前提是你要有最基础的工程纪律版本管理、任务状态表、产物目录、单测脚本。没有这些骨架Agent 只是会说话的键盘不是能干活的团队。我的经验是AI Agent 的靠谱程度极大程度上取决于喂给它的流程规范。你越是用做软件工程的态度去管理 Agent它就越像个稳定的工程团队你越是把它当许愿机它就越会一本正经地胡说八道。这套打法后续我打算继续复用做成一个可复用的企业内部项目交付模板把需求分析、编码、测试的提示词和工具封装成包以后新项目直接套壳开工。最后再说一个小技巧每次让 Agent 干活之前先在任务卡第一行写清楚“这个任务做完了成功的标志是什么”。这句话逼着我把验收标准前置也让 Agent 不会跑偏。这个习惯我保持了半年省下的返工时间远比写那一行字的时间多得多。