先说一个核心判断：当多Agent协作成为标配，真正的瓶颈已经不是单个Agent的能力，而是它们之间的“交接棒”问题。
这几天用13个Agent完整跑通了一个真实的AI工具站，结果发现：出问题最多的地方，不是写代码，而是交接。
现在Codex、Claude Code、Cursor、Copilot都在往同一个方向走——多Agent、后台任务、并行执行、远程接管。OpenAI把Codex App定位成“command center for agents”，支持多个coding agent并行运行和长任务协作。GitHub Copilot cloud agent可以直接从issue启动，自动创建PR，请求人工review。Cursor也在推automations、background agents，支持schedule、GitHub、GitLab、Slack、webhook等多种触发方式。
工具厂商都在把coding agent平台化。能力变强之后，新的问题也浮出水面：多Agent的时代，到底谁来负责交接？
01 多Agent不是多开几个聊天窗口
多开Agent很容易。难的是每一棒都能被下游稳稳接住。
一条真正能用的Agent流程，必须回答4个问题：
- 输入是什么？——上一棒给了什么。
- 输出是什么？——这一棒交出什么。
- 证据是什么？——怎么证明这棒DONE了。
- 什么时候必须停？——BLOCKED的条件是什么。
这4个问题回答不清楚，Agent越多，噪音越大。
02 用一个真实案例来解释：aicodingpricing.com
案例是aicodingpricing.com，一个专门比较AI编程工具定价的站点。
从关键词研究到上线后复盘，13个Agent依次接棒：市场研究 → SEO复核 → PRD → 定价 → 合规 → 文案 → 设计 → 前端 → 后端 → QA → 运营 → 数据复盘，外加一个主持台负责节奏和GO/NO-GO。
每一棒都有明确的输入来源、输出格式、交接文档和暂停条件。站做出来了，而且不止一个首页，还包括具体的对比页面。
这个案例真正有价值的地方，是它暴露了哪些位置——如果没有闸门，就会出大事。
03 13个Agent怎么分工
整理成容易理解的版本：
- 市场研究 — 判断关键词有没有机会
- SEO复核 — 看SERP竞争难度和页面矩阵
- PRD — 把机会变成页面、功能、验收标准
- 定价 — 看竞品、成本和套餐边界
- 合规 — 检查文案声明、数据风险
- 文案 — 生成首页、功能页、结果页的文案
- 设计 — 出页面结构和视觉方向
- 前端 — 实现页面与交互
- 后端 — 处理API、存储、鉴权、支付
- QA — 功能、异常态、移动端、SEO、合规、埋点
- 运营 — 提交目录、冷启动、外链和渠道
- 数据复盘 — 接管GSC、Bing、GA4、Plausible、Clarity
- 主持台 — 负责节奏、BLOCKED、GO/NO-GO、交接
ShipSolo把这13个阶段封装成Skills，每个阶段都有标准的输入和输出模板。
04 真正踩坑的地方
完整跑完一遍，坑主要在4个地方。
SEO / 合规的NO-GO不能被情绪压过去。 aicodingpricing.com选词阶段，有几个关键词搜索量看起来不错，但SERP前三页全是大厂官网和头部评测媒体。市场研究Agent直接打出BLOCKED，原因是短期渗透机会极小，继续推进就是在错误的方向上浪费所有后续棒次的时间。这个结论不好听，但它卡住了。文案和设计没有在错误的词上把功夫用完。合规也是同理：法务没有给出明确结论之前，页面不能上承诺性语句，不能用“更便宜”“保证准确”这类表述。这一关含糊过去，后面所有棒都在做无效功，上线了也要全部推翻重来。
PM gate必须在设计和研发前卡住。 这次做站，路由合约在PRD阶段就固定了：哪些是静态页、哪些要接API、对比表的字段定义、结果页的几种状态。这件事没有定，设计稿就是一次性的。前端接了再改字段，要动API、动组件、动设计，每一层都要返工。路由合约签完之后，设计才启动，前端才接任务。这个顺序看起来慢，但它省掉的是最贵的那部分——已经做出来的东西被推翻。
QA不能缺席，也不能提前。 QA阶段覆盖6类检查：功能逻辑对不对、异常态有没有兜底（空状态、超长内容、网络断开）、移动端是否跑偏、canonical和sitemap是否正确生成、合规文本是否与法务稿保持一致、埋点事件是否真实触发并携带正确参数。每一类都要有截图存档，逐项打勾，不是“大体没问题”。“大体没问题”这四个字，上线后会变成GSC收录问题、Clarity热图空白、转化漏斗断层。任何一项缺席，上线之后就是黑盒。
数据接管不能只看脚本有没有粘贴进去。 GSC、Bing、GA4、Plausible、Clarity，每一个工具都要走四个验证状态：未配置 → 已配置无数据 → 有数据不可归因 → 有数据可归因。这四态之间的跨度可以是几小时，也可以是几天，取决于流量体量和工具本身的采样机制。有脚本不等于有数据，有数据不等于能做决策。不提前按状态逐步对账，D7复盘时面对的就是一堆猜测，复盘等于没做。
05 9个硬闸门
每个阶段能拦下的问题，都要拦在代价最小的时候。
- Keyword gate — 关键词竞争度、搜索意图、变&现路径，三项同时成立才进PRD。只有搜索量没有转化意图，是最浪费时间的方向，比直接做错还难发现。
- Route contract — 页面列表、URL结构、数据状态、canonical规则、sitemap收录逻辑，PRD完成后立刻锁定，设计和前端共同签字确认，后续不允许单方面改。
- SEO-Copy Freeze — SEO关键词矩阵和文案草稿冻结后，设计才开始排版，前端才接内容。文案改一次，设计稿废一版，前端改一轮，这是三倍代价，必须在这一关拦住。
- Content-fit matrix — 每个页面都要能回答：为什么存在、目标用户是谁、他们来了之后要做什么。答不上来的页面，做出来也没人看，SEO也不会收录。
- Data Contract — 埋点事件名、参数结构、口径定义、四态验收标准，在前端开发前写清楚，QA按合同逐项验，不是上线后发现缺口再补救。
- PM gate — 产品验收必须覆盖所有页面状态，包括空态、异常态、边界值，通过后才进大规模实现，不允许“先做完再补产品文档”。
- QA / SEO / Compliance GO — 三者独立给出结论，同时通过，才算准备上线。任何一个NO-GO，整个流程暂停，不允许带着问题上线“先看看效果”。
- Analytics四态验证 — 逐步确认，每一态截图存档。可归因才能做决策，之前的所有状态都是过渡态，不算接管完成。
- D7 / D14 / D30复盘 — 上线不是结束。D7看收录和首批流量来源，D14看关键词排名变化，D30做完整的转化和收入复盘。没有这三个节点，上线等于扔出去不管了。
06 给想复制的人
不要上来就追速度。
先从一个站把13个阶段完整跑一遍。不求快，求每一棒都能被接住。每个阶段只要求4件事：清楚的输入、明确的输出、可验证的证据、允许BLOCKED的暂停条件。这4件事到位了，哪个Agent跑慢了、哪个阶段需要人工介入、在哪里卡住，都有地方可查。
这套流程真正发挥作用的时刻，往往是你最想跳过某一关的时候。市场研究打出BLOCKED，你已经想好了站名、想好了页面结构，甚至规划好了上线时间——但闸门不开。这种时候被拦下，代价最小。绕过去继续推，代价在后面，而且越到后面越贵。
aicodingpricing.com这次，市场研究和SEO两棒都GO之后才进PRD，路由合约锁定之后文案和设计才同步推进，QA三项全部GO之后才上线。每一棒都有明确的交出物，下一棒才有东西可以接。节奏不乱，靠的是闸门，靠的是每一棒都有人接。
AI编程接下来会越来越强。 强工具只会放大原来的流程。流程清楚，它放大交付；流程混乱，它放大混乱。
工具已经够快了。现在该补的，是闸门。
