为什么多 Agent 平台不能一步到位，而要分四阶段长出来
从单 Agent 到多 Agent 平台的四阶段演进，及交接、共享、聚合三类新成本。
立靶：你以为的「多 Agent」，和它真实的代价
很多团队一拍脑袋就要做「多 Agent 平台」。理由听起来很美：一套底座养无数个数字员工，招聘的、保险的、教育的全塞进去，边际成本趋近于零。
于是工程上常见两种翻车姿势：
第一种是阶段跳跃。手上明明只有一个跑通的单 Agent，却直接照着「多租户、自动路由、行业模板库」的终态去搭架子。结果是：还没有第二个真实业务跑起来，就先背上了一堆为「想象中的规模」付出的抽象成本——注册表、路由层、隔离层全做了，但没有一条真实流量来验证它们是否设计对了。
第二种是低估隐性成本。单 Agent 时代，系统里只有一个主体，数据、配置、链路都是「单数」的。一旦变成多 Agent，系统里凭空多出三类原本不存在的成本：
- 交接成本（handoff）：一通请求该路由给哪个 Agent？入口、规则、worker 之间的映射，谁来维护？
- 共享成本（sharing）：哪些能力是所有 Agent 通用的（链路、runtime、后处理），哪些必须各自定制？切错了边界，要么重复造轮子，要么强行复用导致耦合。
- 聚合成本（aggregation）：监控、审计、计费，原本看一个数字，现在要按 Agent 维度切分再聚合，否则一锅粥。
这三类成本不会因为你「上了平台」就消失，它们只会从隐性变显性。问题不是要不要付，而是按什么顺序、在哪个阶段付。 这正是分四阶段演进的意义：每一阶段只解锁必要的能力，把对应的成本在它真正出现时才付清。
框架：从单 Agent 到平台的四阶段演进
核心前提有三条：架构向后兼容（现有单 Agent 系统是第一阶段的起点，不推倒重来）、递进式扩展（每阶段解锁一组新能力，做完一阶段能停下来用）、通用层复用（底层链路、runtime 抽象、后处理 pipeline 可跨 Agent 共享，是省工作量的来源）。
四个阶段对应前面三类成本的逐步显性化：
| 阶段 | 核心特征 | 适用时机（何时进） | 主要风险 |
|---|---|---|---|
| A · 多实例化 | 让系统支持多个独立 Agent，各有自己的 manifest、目录、worker name；数据/配置按 Agent 隔离 | 已有一个跑通的单 Agent，且确实出现了第二个真实业务需求 | 路径硬编码改参数化，改不彻底会留隐性耦合；此阶段尚无路由、无隔离保障 |
| B · 路由层 | 不同入口自动路由到对应 Agent 的 worker，共用同一资源池，统计独立——交接成本在此付清 | 已有 2-3 个 Agent 需要并行对外服务，手工切流量已成瓶颈 | 入口↔Agent↔worker 的映射表是新的单点，维护错就串线 |
| C · 多租户隔离 | 数据库强制按 Agent 过滤、存储隔离、API 鉴权按 Agent scope——聚合与合规成本在此付清 | 要做生产级、面向外部租户，数据绝不能串 | 任一查询漏掉过滤条件即越权；隔离不彻底等于没做 |
| D · 模板库 | 沉淀行业模板，新 Agent 从「完全定制」压缩到「拷模板改配置」 | 已有 3+ 同构 Agent，新行业上线频繁，定制成本成为新瓶颈 | 模板抽象过早会僵化；抽象太晚则错过复用红利 |
注意一个关键判断：A 和 B 之间的门槛是「有没有第二个真实业务」，B 和 C 之间的门槛是「要不要对外/合规」，C 和 D 之间的门槛是「上线频率高不高」。 不是按时间推进，而是按瓶颈推进——当前阶段的能力不再是瓶颈，下一阶段才有意义。
case：一个招聘语音 Agent 想长成「数字员工平台」
某团队有一个跑通的蓝领招聘语音 Agent（单 Agent、单入口、单一业务），想扩展成「按行业卖开箱即用数字员工」的平台，候选行业是保险、教育。他们没有直接照终态搭架子，而是做了一次诚实的存量盘点，把现有能力分成三档：
- 开箱即用（可直接共享）：通话链路、双 runtime 抽象、ASR/TTS 客户端、统一 worker 入口、后处理录音与转录——这些和具体业务零耦合，任何同类 Agent 都能用。
- 小改造能复用：manifest 与目录结构（路径硬编码需参数化）、数据库查询（需补按 Agent 过滤的条件）——属于 A 到 C 阶段逐步改造的对象。
- 完全缺失需新建：Agent 注册表、入口池路由、按 Agent 的审计链路、行业模板库——这些正是交接/聚合成本变显性后才需要的件。
不同行业的 Agent 差异有多大，直接影响「哪些能共享、哪些必须各自定制」：
| 维度 | 招聘 Agent | 保险 Agent | 教育 Agent |
|---|---|---|---|
| 对话阶段数 | 14 | 18-20 | 12 |
| 平均通话时长 | 3-8 分钟 | 8-15 分钟 | 5-10 分钟 |
| 核心工具 | 查岗位/存摘要/转人工 | 查保单/算保费/核资格 | 列课程/查排期/提交报名 |
| 客户画像字段 | 工种/薪资/地区/班次 | 年龄/健康/家庭/资产/保单 | 年级/成绩/兴趣/家长预期 |
| 合规约束 | 不歧视 | 监管「不夸大」 | 不得承诺升学 |
可以看到：链路和 runtime 是共享的，但人设、阶段、工具、合规话术是必须各自定制的——这条边界，就是「共享成本」要切准的地方。切错了，要么把通用层做窄、要么把专有逻辑硬塞进通用层。最终的账：从零自研一个多 Agent 平台，估算需要数月加一笔可观预算；而基于现有架构按四阶段演进，所需工期与资源是前者的零头。差距的来源不是写得快，而是没有为想象中的规模提前付成本——每一分抽象都对应一个已经出现的真实瓶颈。
可操作做法：判断你现在该在哪一阶段
第一步：确认当前阶段（自检清单）
- 系统里只有一个 Agent，数据和配置都是「单数」结构 → 你在 A 之前，别急着碰平台。
- 多个 Agent 已能并存，但靠手工切流量/手工指定 → 你在 A。
- 入口能自动路由到正确 Agent，统计能按 Agent 分开看 → 你在 B。
- 数据库查询强制按 Agent 过滤、存储与鉴权都隔离、通过越权审计 → 你在 C。
- 新 Agent 能靠拷模板改配置在 1-2 天上线 → 你在 D。
第二步：判断该不该进下一阶段（门槛即触发条件）
- 进 A 的条件：出现了第二个真实业务（不是「将来可能有」）。只有一个业务就停在单 Agent。
- 进 B 的条件：已有 2-3 个 Agent，手工切流量成了瓶颈。Agent 还少时手工切完全够用，别提前建路由。
- 进 C 的条件：要对外服务或触碰合规红线，数据串线会出事故。纯内部、低敏场景可以缓。
- 进 D 的条件：新 Agent 上线频率高到定制成本成为瓶颈。少于 3 个同构 Agent 时，模板是过早抽象。
第三步：每进一阶段，先回答它对应的成本归谁付。 进 B 前想清交接成本（映射表谁维护、出错怎么排查）；进 C 前想清聚合成本（监控/审计/计费如何按 Agent 切分再聚合）；全程盯住共享成本（每加一个 Agent，先问「这能力是通用层该提供的，还是它专有的」）。
反模式速记： 只有一个业务就搭多租户架子（为想象中的规模提前付费）；把行业专有逻辑硬塞进通用层（共享边界切错，通用层被污染）；加 Agent 时不动监控继续看聚合后的单一数字（聚合成本没付，问题被掩盖）；按时间表而非按瓶颈推进阶段（在没出现瓶颈的地方付了成本）。
收口
多 Agent 平台不是搭出来的，是长出来的：每一阶段只解锁当下瓶颈所需的能力，把交接、共享、聚合三类成本在它真正出现时才付清——按瓶颈推进，而不是按想象推进。