客户第一次跟我开线上会议，甩过来一份 47 页的需求文档，附带一句灵魂拷问：“这个项目我们内部 4 人团队评估是 2 个月，你一个人打算怎么排？”我说按 3 周排验收就行，屏幕对面沉默了两秒，然后问我是不是需要换个时间再聊。不是我不尊重工期，而是我很清楚这单的成色：需求文档写得足够细、模块边界清晰、技术栈常见，属于典型的“人多派得上用场但未必快得起来”的项目。后面证明，用 3 个 AI Agent 拆掉执行层之后，3 周交付不但做到了，而且上线后只改过两个小补丁。
这篇文章就把我接单、拆解、搭建 Agent、控成本、踩坑兜底的全过程写出来，给也想拿 AI Agent 干正事的朋友当一份实战参考。先说明一点，这不是教你用 Agent 自动发小红书、批量做内容的玩法——市面上这类教程很多，但真正能体现 AI Agent 价值的地方，恰恰是正儿八经的企业项目：需求明确、流程固定、要出可验收的交付物。
1. 这单我为什么敢接：2 个月工期的活需要拆开看
1.1 需求画像：一个标准的三明治项目
客户是一家做电商履约的公司，要上一个内部订单履约管理平台。功能不算花哨：对接企业现有的 SSO 登录，做订单数据的 Excel 导入导出，跟 ERP 系统做对账，给仓库生成拣货和打包任务，再给管理层出一个 KPI 看板，外加一个给仓库小哥扫码用的 H5 页面。后端是 Django + PostgreSQL + Redis，前端 Vue3，部署走 Docker Compose。放在整个软件交付大盘子里看，这是一个夹在稳定上层和稳定下层之间的典型三明治项目：上层是“需求文档已经写明白”，下层是“技术栈已经被千万人踩熟”，中间夹着大量业务 CRUD 和报表逻辑。
这种项目最尴尬的地方在于，传统人力排期很难快起来。你说它简单吧，牵涉 ERP 对账、状态机映射、移动端适配，细节多得像老太太的裹脚布；你说它难吧，又没有真正算法级、架构级的深水区。客户内部估 2 个月，不是因为他们笨，是因为企业项目里大量时间被沟通、联调、返工和验证吃掉了。我接单之前先干了一件事：把需求文档逐条过了一遍，给每个功能模块标记“确定性”——凡是口径清楚、流程固定、输入输出可定义的模块，都打上高确定性标签。最后统计下来，80% 以上的功能都属于这一类。这就意味着，它们可以被非常结构化地拆给 Agent 去执行。
1.2 4 人团队的 2 个月，到底花在哪了
客户内部排的是 4 人团队：1 个产品经理、1 个后端、1 个前端、1 个测试，排期 2 个月。这 8 个人月看着吓人，但拆开看，真正写业务代码的时间并不占大头。第一周要做需求澄清和原型对齐，第二周搭架构和定接口，中间三四周写功能，最后两周留给测试、修 bug、走验收流程。再加上团队内部的信息同步、跨端联调、产品经理反复确认字段口径，这些隐性成本全要摊进排期，实际落到键盘上的有效编码时间可能连一半都不到。也就是说，如果需求本身足够清晰，真正的“制造时间”压到三四个人周是有可能的。
我接单时给自己定的策略很简单：需求澄清由我直接和客户做，架构决策由我拍板，把写代码、补测试、做交付这三段拆给三个专职的 AI Agent，我只做拆票和验收。这个思路后来被证明是对的——但前提是这三个 Agent 的分工必须划得足够干净，谁该干什么、谁不干什么，一开始就要写在纸面上。
2. 三个 Agent 的分工设计：写码、挑刺、交付各管一段
很多人一上来就想搞一个“万能 Agent”，让它既写代码又跑测试还负责上线，结果哪个都干不深。我的做法恰恰相反：三个 Agent 各有且只有一段职责，谁都不越界。这就像现实团队里不会让开发顺手当测试、让运维顺手改业务代码一样，职责边界本身就是质量边界。每个 Agent 的系统提示词、工具权限、上下文范围，全都围绕它的唯一职责定制。
2.1 编码 Agent：写代码的人，但必须约法三章
编码 Agent（我内部叫它 Coder）负责从任务票里读需求，在仓库里实现功能并提交 PR。它手里的工具是文件读写、shell、git 和 linter，权限集中在开发分支。我给它的系统提示词里写死了三条规则：第一，只允许修改任务票里列出的文件，要动额外文件必须单独说明；第二，禁止顺手做重构，哪怕看到“很丑”的代码也只能记到备注里；第三，PR 描述必须写清楚改了哪些文件、对应什么验收标准、有没有已知风险。这三条规则看起来像废话，但在多 Agent 协作里是保命的。
为什么？因为大模型天然有“过度表现”的倾向。你让它修一个查询 bug，它可能顺手把整个视图函数重写了，再牵出一个不存在的依赖，最后合并完才发现线上某个旧接口的参数被改了。约法三章的本质，是把 Agent 的自由度收敛到任务票的边界里，让它把有限的上下文和算力全部集中在真正该做的事情上。我还给 Coder 配了一份“项目约定”文件，里面写了目录结构、命名规范、异常处理习惯，Agent 每次动工前先读这份文件，相当于给新人发了一本员工手册。
2.2 测试 Agent：把“我觉得”变成“我证明”
测试 Agent（Reviewer）接到的不是业务需求，而是 Coder 提交的 PR。它的职责是读 diff、补测试、跑测试、查边界条件，最后输出一份带证据的报告。它不允许直接修改业务代码，最多只能往 tests/ 目录里加测试用例。它跑完 pytest 之后会把通过率、覆盖率、可疑的边界 case 全部列出来，结论只有三种：放行、打回、需人工复核。这三种结论都有对应的输出模板，Agent 不能含糊地说“看起来没问题”，必须列出它实际执行过的命令和结果。
这一步是整个流水线的“刹车片”。在没有 Reviewer 的时候，Coder 的自测基本等于“编译过了就行”，很多逻辑错误在合并之后才暴露。有了专职挑刺的 Agent，问题能在产生它的环节就被拦住，而不是拖到集成阶段爆雷。尤其在企业项目里，一个隐藏的边界 bug 到生产环境才炸，修复成本可能是开发阶段的十倍。让一个专门的 Agent 去盯质量，这钱花得值。
2.3 交付 Agent：环境、迁移、CI/CD 一条龙
交付 Agent（Ops）负责最后一公里：构建 Docker 镜像、执行数据库迁移、触发 CI 流水线、部署到 staging 环境、检查健康检查接口，然后写一份部署报告。它手里有 docker compose 和运维脚本的权限，而且被明确告知：生产环境任何变更都必须先经过我确认，staging 可以自动执行，生产必须出“人工闸门”。后面我们会聊到，这条闸门规则差点救了我一命。Ops 每次部署完还要检查关键接口的返回值，而不是只看“进程起来了”就宣布成功。
三个 Agent 这样一分，整条交付链路就成了：Coder 产出 → Reviewer 验证 → Ops 上线。每段只有一个入口和一个出口，上下文不会交叉污染，出问题也能快速定位到是哪个环节。这比堆一个全能 Agent 靠谱得多，也比两个 Agent 互相“客气”要高效得多——因为每个节点都有明确的交付物和验收标准，没有扯皮的空间。
3. 落地架构：我在主流方案里挑了一套轻量编排
3.1 主流 Agent 架构先扫一遍
做之前我先把主流方案过了一遍：单 Agent 多工具、多 Agent 自由协作、Supervisor 调度、以及 Pipeline 流水线。单 Agent 多工具适合答问答、做研究，但塞进一个完整项目里上下文会炸；多 Agent 自由协作看起来优雅，实际沟通成本高得离谱，适合学术实验不适合交付；LangGraph、CrewAI、AutoGen 这些框架我都试过，老实说能力很强，但对一个固定流程的项目来说，框架自身的学习成本和 debug 成本反而成了负担。你很难跟一个底层框架争论“为什么 Agent 聊着聊着偏题了”，你只能顺着它的调度逻辑去猜。
最后我选了 Supervisor + Pipeline 的混搭：一个极简调度器负责把任务票分发给三个 Agent，三个 Agent 之间不直接对话，所有信息通过任务状态和文件传递。原因很简单——这个项目的流程是确定性的，我要的是可控，不是自由。你可以把这种架构理解成一条生产流水线：每个工位上都有一个机器人在干活，但它们之间不聊天，只通过传送带传递半成品。如果你想系统了解这几种架构的权衡，可以找阿里云的 AI Agent 白皮书翻翻，里面把编排、记忆、工具调用讲得比大部分博客系统。
3.2 为什么编排层用 Rust 写，而不是 Python
调度器我自己写了一个很薄的程序，用的是 Rust。当时很多人问我为什么不用 Python 顺手写个脚本拉倒，毕竟业务项目本身是 Django。我的理由有三条：第一，这个调度器要长期挂在我自己的工具箱里，Rust 编译出来是一个独立二进制，扔到服务器上不用装 Python 环境，连依赖冲突都没有；第二，调度器内部要维护一个任务状态机，Rust 的所有权和模式匹配让状态流转的错误在编译期就暴露，而不是跑到一半才崩；第三，三个 Agent 的日志和 token 统计都是高并发写入，Rust 的并发模型更省心。性能反而是最不重要的理由，只是送的。
当然，如果你是第一次搭 Agent，我不建议直接用 Rust 入门，学习曲线不划算。先用 Python 或 TypeScript 把流程跑通，再来考虑是不是值得换一个更硬的运行时。基于 Rust 的 AI Agent 这条路更适合已经有工程基础、想把 Agent 运行时做成稳定基础设施的人。我之所以强调“编排层要薄”，是因为 Agent 真正的智能在模型调用和提示词设计里，编排层只是把正确的输入送到正确的 Agent 嘴边，越薄越不容易出错。
3.3 工具调用边界：给 Agent 装什么样的手脚
三个 Agent 的工具列表我看着很短：文件读写、shell、git、测试运行器、docker compose、HTTP 请求。没有开放任意互联网浏览，没有给生产库写权限。所有的外部接口调用都走标准化的接口协议，Agent 只需要按照 schema 调工具，不需要自己去拼 URL 和密钥。这个设计的出发点很朴素：Agent 的能力越强，闯祸半径也越大。你给它装上网页浏览和数据库写权限，它确实能多干很多活，但也可能把企业的数据安全底线捅破。工具列表里每一项都要能回答一个问题：这个 Agent 的职责需要它吗？不需要就砍掉。
我把这叫做“最小权限原则”，跟现实里给员工发门禁卡一个道理——一个只需要进机房的运维，没必要给他财务室的钥匙。工具边界设好之后，Agent 反而更专注，因为它不需要在一个巨大的能力面板里反复犹豫该用什么。
4. Token 账单和上下文控制：成本是怎么压下来的
4.1 先掰扯清楚 token 在 Agent 里到底是什么意思
很多人问“AI Agent token 是什么意思”，这里先统一口径：token 是模型处理文本的最小单位，也是计费单位。一个汉字大概对应一到两个 token，一段 500 行的 Python 文件大概几千 token。在 Agent 场景里，token 有两个绕不开的约束：一是上下文窗口有上限，二是每一轮交互都会产生费用。单轮问答的 token 消耗不大，但 Agent 是一轮接一轮地调工具、看结果、再思考，这些历史消息全都要留在上下文里，越滚越大。
举个具体例子：Coder 修一个 bug，先读了 5 个文件，跑了 3 次测试，每次测试输出几百行，光这一个任务就可能烧掉几万 token。如果任务的上下文管理不好，上下文窗口一满，模型就开始“失忆”，忘了任务票里的约束，甚至开始答非所问。所以 token 不只是账单上一个冷冰冰的数字，它直接决定 Agent 有没有“记性”。这也是为什么我在任务票里写相关文件时宁缺毋滥——你把多余的文件塞进去，看起来信息全，实际是把有限的上下文预算浪费在了无关代码上。
4.2 实际账单：三周到底烧了多少钱
整个项目下来，我统计过 token 消耗：三个 Agent 合计大概烧了 3000 万 token 量级。我没有全程用最贵的旗舰模型，而是做了分级：Coder 写常规 CRUD 用性价比档模型，Reviewer 做代码审查用旗舰档模型，Ops 这种偏确定性的脚本执行干脆用最便宜的模型。这样配下来，总账单压在了国内一个全职工程师月薪的零头水平，相比 4 人团队 2 个月的薪资成本，基本可以忽略不计。这才是企业项目里 Agent 真正恐怖的地方——不是说它写得比人好，而是单位产出成本被打下来了。
这个账算清楚之后，客户的心态也发生了变化。一开始他们担心“AI 写的东西能不能用”，后来看到 staging 环境每周都在肉眼可见地变完整，随即开始关心“这套流程能不能复用”。我提醒他们：token 成本可以忽略的前提，是任务票拆得好、上下文控制得住。你要是让 Agent 在十万行代码的仓库里裸奔，再便宜的模型也能烧出让你肉疼的账单。
4.3 压 token 的三个土办法
第一是上下文瘦身。我不让 Agent 看整个仓库，每个任务票里只列出相关文件，Agent 也只能把这些文件的 diff 或指定片段放进上下文。第二是缓存复用。系统提示词、需求文档、代码规范这些固定内容只在第一轮注入，后续轮次用引用和缓存，不让模型反复“重读”。第三是三振出局。我给每个任务设了三次循环上限，同一个任务来回打回超过三次，我就自己接手，不让它继续烧 token 死磕。这三条土办法听着不高级，但能把账单砍到原来的三分之一，而且顺手治好了 Agent “一条道走到黑”的毛病。
5. 三周冲刺实录：从搭骨架到上生产环境的完整节奏
5.1 第一周：先看见一个能登录的系统
第一周的目标只有一个：staging 环境上跑起来一个能登录的系统。我先把仓库骨架、docker compose、CI 文件准备好，然后交给 Ops 把基础环境搭通，Coder 去实现 Django 的登录和 SSO 对接，Reviewer 把权限相关的测试补上。到周五，客户自己拿账号登录进去，看到的是一个能正常认证、菜单齐全、空壳但五脏俱全的后台。这一步太重要了——任何项目，第一周如果连一个能打开的版本都拿不出来，后面再解释都是在找借口。
第一周还有一个容易被忽略的成果：跑通了整个 Agent 协作流程。哪类任务票 Coder 一次能过，哪类票容易被打回，Reviewer 的报告该怎么读，Ops 部署一套环境要多久，这些经验数据在第一周积累下来，后面两周的节奏就有了参照。我把第一周叫作“磨刀周”，刀磨快了，砍柴才有意义。
5.2 第二周：核心业务模块的生产流水线
第二周是硬仗，订单导入导出、ERP 对账、仓库任务调度这三大模块要在 10 个工作日内全部落地。我的做法是按模块拆票，每个模块拆成 5 到 8 张任务票，每天上午给 Coder 派两到三张，下午 Reviewer 出验证报告，打回的就当晚返工。对账模块是里面最复杂的，涉及两套系统的状态机映射，我多写了一页需求说明，把每个状态组合和数据修正规则写死，Agent 才没有自由发挥的余地。到第二周结束，三个核心模块全部进了 staging，联调和生产数据模拟都跑通了。
这一周给我最大的感受是，Agent 流水线的产能其实是均匀的，不像人类团队会有“周一没状态、周五想下班”的波动。只要任务票的质量跟得上，它每天产出的量基本一致。所以真正限制项目速度的，已经变成了我自己拆票和验收的速度，而不是编码速度。这个认知对以后排期特别有用。
5.3 第三周：收口、打磨、预演上线
第三周做的是看起来不起眼但最磨人的活：KPI 报表的数据口径校准、H5 扫码页在不同手机上的兼容、权限矩阵的逐个核对、写部署文档和上线检查单。这些活很碎，但很适合 Agent——Reviewer 负责把报表口径和测试用例对照，Coder 修小 bug，Ops 反复做 staging 到预发环境的演练。最后一天，我手动在预发环境把整个流程从登录到打单扫码走了一遍，确认无误后，才把生产部署的钥匙交到 Ops 手里。
这里我想多说一句：第三周千万不要因为“功能都好了”就放松。企业项目上线后出问题，往往就是出在边界场景、权限遗漏、数据不一致这些不起眼的地方。Agent 能帮你把大路修好，但路边的护栏和指示牌，一定要有专门的力量去查漏补缺。
5.4 我的日常：上午拆票，下午验收，别当打字员
这 15 个工作日里，我自己的节奏很固定：上午只做一件事——把客户的需求翻译成任务票，每张票包含背景、验收标准、相关文件、明确禁止事项；下午集中时间看三个 Agent 的输出，review 代码、跑回归、做判断；晚上写明天的票并处理打回的任务。说白了，我把自己定位成项目经理兼验收员，而不是打字员。你可能会问，这么重的拆票工作是不是反而比写代码还累？答案是前期确实累，但票写得越细，Agent 的一次通过率就越高，后面返工就越少。票的品质决定整个流水线的效率，这句话我在这三周里体会得特别深。
6. 翻车现场与兜底机制：Agent 不可靠时你该怎么办
如果这篇文章只让你记住一件事，那就是：Agent 一定会犯错，而且犯错方式五花八门。三周里我们不是没翻过车，只是每辆车都翻在了兜底网里。预期管理很重要——你不是在用一个“不会出错的员工”，而是在用一个“犯错方式跟人类不同但速度极快的员工”。管理它的方式，就是建好护栏。
6.1 事故一：它给我写了一个不存在的库函数
Coder 在订单导出功能里引用了一个“看起来很合理”的库函数，但实际上这个函数根本不存在，是模型自己脑补出来的。幸运的是 Reviewer 在跑测试时立刻暴露了 ImportError，整张任务票被打了回来。事后我总结了一条规则：任务票里必须声明允许使用的依赖，Agent 声称要用某个新库时，必须给出安装和引入证据，不允许凭空 import。这条规则听起来像是给小学生立规矩，但大模型的幻觉就是这么低级且直白，你不在流程里堵住它，它就敢在深夜悄悄给你埋雷。
6.2 事故二：测试全绿，但测了个寂寞
比代码报错更阴险的是测试“全绿但没测到点上”。有一张对账任务票，Reviewer 补的测试全过，但我拿着真实业务数据一看，发现它断言的是 mock 数据里的硬编码值，根本不是真实的对账逻辑。从那以后，我要求每张票必须带一个黄金用例：一组已知输入和预期输出，跑测试时先用黄金用例验证逻辑，再谈覆盖率。Golden Case 这四个字母，值回整个项目的服务费。因为测试的意义不在于“有没有测试”，而在于“测试有没有证明该证明的东西”。
6.3 事故三：Agent 的代码洁癖惹祸
Coder 有一次在修报表 bug 时，顺手把工具类里的几个函数“整理”了一遍，还自我感觉良好地写进了 PR 备注。结果就是另一个页面开始报错。我查了半天才发现是那个“顺手重构”干的。这就是为什么我给 Coder 定下死规矩：禁止重构，哪怕代码再丑。Agent 可以把丑代码记进 issue 建议栏，但未经允许改一个标点都不行。人类团队里你还能跟同事讲道理说“这段是历史遗留不要动”，Agent 不会跟你讲道理，它只会觉得自己在做正确的事。所以规矩必须写在系统提示词里，而不是靠“它应该知道”。
6.4 事故四：交付 Agent 差点动了生产数据库
最惊险的一次是 Ops 在跑迁移脚本时读到了错误的环境变量，差点在连接信息指向生产库的情况下执行危险语句。幸好有一条当初被客户吐槽“太麻烦”的规则救了我们：生产库的任何变更都必须由我手动确认，Ops 只有 staging 的自动权限。从那之后，我把所有生产凭证彻底从 Agent 的环境变量里移除，你要上线可以先叫停，绝不能让 Agent 拿着钥匙自己开门。这也是为什么我坚持最小权限原则——你永远不知道 Agent 会在哪一刻做出一个你完全意想不到的操作，唯一能兜底的，就是它根本没有那个权限。
6.5 兜底的黄金原则与学习路线建议
经历过这些之后，我给自己定了一套兜底原则：最小权限，Agent 只有完成职责所必需的工具和权限；黄金用例，每个关键任务必须有可验证的输入输出对；人工闸门，生产环境永远保留人的最终确认；三振出局，同一个任务循环超过三次就换人处理；日志全留，每个 Agent 的每次调用和工具执行都留痕，复盘时能定位到具体环节。这五条不是我拍脑袋定的，是每一条背后都有一次真实的翻车经历在撑腰。
如果你也想走这条路线，我建议你的学习路径是：先玩单个 Agent 加工具调用，把 token、上下文、工具 schema 这几件事摸透；然后搭一个“写代码 + 跑测试”的双 Agent 流水线，感受协作和返工节奏；最后再加交付 Agent，把部署闭环补齐。别一上来就上重型框架，也别指望 Agent 能替你做判断。它们真正擅长的是执行，而不是拍板。
验收那天，客户看着完整跑通的系统，问我下个项目还打算一个人干吗。我说是啊，还是一个人，外加三个不收钱的组员。他们笑，我也笑，但我知道这句话不是玩笑。这一趟下来，最大的收获不是省了几个月工期，而是我接项目的排期方式彻底变了——以后但凡需求能写清楚、流程能拆成票的项目，我都有一套完全不同的报价和排期逻辑。希望这篇记录也能给你一点可复制的思路。