三个 Agent 干同一个活，边界该划在哪
拆多 Agent 的时候，大部分人纠结的是"分几个"。
我的看法是：分几个是最不重要的决定。重要的是按什么维度分。
维度错了，分三个和分一个一样糟，还多两处路由失败点。
这篇给一个能落地的判定方法，以及拆完之后必须补的那个洞。
一、一个失败的拆法
先看反面例子。有人按「功能」拆：
- 推荐 Agent：根据肤质推荐产品
- 报价 Agent：查价格和库存
- 物流 Agent：查订单和快递
看起来职责清晰。实际跑起来：
推荐 Agent 推荐完，客户问"多少钱"，路由到报价 Agent。报价 Agent 不知道刚才推荐了哪款，只能再问一遍。客户又答一遍。
更麻烦的是知识重复。三个 Agent 都得懂产品------报价要听懂"那款积雪草"，物流要听懂"上周那单"。同一套产品知识存三份，改一次要改三处。
这就是按功能拆的典型症状：知识重复、上下文反复重建、体验像被转接了三次电话。
二、一个检验：能不能同时成立
拆分的核心问题是维度，我给一个可操作的检验：
拆出来的两个 Agent，能不能同时是「用户当前的处境」？
能同时成立，说明这个维度错了。
拿"推荐 / 报价 / 物流"试：
| 问题 | 能同时成立？ |
|---|---|
| 用户既在问推荐、又在问价格？ | 能。「推荐个三百以内的」两件事都在 |
| 用户既在挑产品、又在查物流？ | 能。「上次那个到哪了，再给我推荐个新的」 |
能同时成立 → 维度错。
拿"售前 / 售后"试：
| 问题 | 能同时成立？ |
|---|---|
| 用户既在决策前、又在决策后？ | 不能。他要么还没买，要么已经买了 |
不能同时成立 → 维度对。
这个检验之所以成立，是因为一个语言事实：
功能是动词，阶段是状态。动词可以任意组合出现在同一句话里，状态是互斥的。
「推荐」「报价」「查单」都是动词，一句话里可以全有。「决策前」「决策后」是状态，一个人不可能同时处在两个。
互斥才能拆干净。
三个能过检验的维度：
| 维度 | 两侧 | 为什么互斥 |
|---|---|---|
| 阶段 | 售前 / 售后 | 买没买，是状态 |
| 风险 | 低风险咨询 / 高风险管理 | 一句话要么只是咨询，要么已经进入纠纷 |
| 自主权 | 能自己答 / 必须转人 | 要么在权限内，要么不在 |
三、反方观点：按阶段拆会不会切断话题
按阶段拆有一个明显的反驳，值得正面回应。
反驳： 用户的问题经常横跨两个阶段。比如"这款用完过敏了，还能继续用吗"------既是产品咨询（能不能用），又是售后（过敏了）。
按阶段拆，这个问题落在售后，导购视角就丢了。
回应： 这类问题看起来跨界，实际上只有一个正确答案。
"用完过敏还能继续用吗"------答案只有"停用，然后处理过敏和退货"。它不需要导购视角参与。如果导购 Agent 也来发表意见（"这款对敏感肌也很友好"），那恰恰是灾难。
也就是说：表面上的跨阶段，本质是同一个阶段内的两个动作。 只有当一个问题的正确答案真的需要两种立场同时存在时，才说明维度错了。
这种情况存在吗？我想过一个：用户问"我预算三百，但家里那瓶还剩一半，该现在买还是等等"。
这个问题需要"促单"和"劝阻"两种立场。但这不是多 Agent 该解决的，这是一个 Agent 内部分析权衡该解决的------它甚至在同一个阶段（售前）内。
所以反驳成立的范围很窄，不影响结论。
四、两个可量化的信号
除了互斥性检验，还有两个数字能反映拆分是否合理。
工具重合度
两个 Agent 挂的工具集，交集占并集的比例。
css
重合度 = |A 的工具 ∩ B 的工具| / |A 的工具 ∪ B 的工具|| 重合度 | 判断 |
|---|---|
| < 30% | 合理，两个角色确实在干不同的事 |
| 30% ~ 50% | 需要看，可能有共用能力该抽成公共服务 |
| > 50% | 拆分有问题，大概率是同一个角色的两种说法 |
售前要产品库、库存、成分表；售后要订单、退款流程、工单系统。重合度接近 0，正常。
如果两个 Agent 都要挂"查产品"，那"查产品"应该抽成一个公共工具集，两边都注册，而不是各自实现一份。
System prompt 重复度
把两段 prompt 按句子切开，算重复句子的占比。
| 重复度 | 判断 |
|---|---|
| < 40% | 合理，共同身份少，差异大 |
| > 70% | 不该拆，重复的部分就是共同身份 |
70% 这个数字不是拍的。重复度超过七成，说明两个 Agent 的核心设定几乎一样，只是结尾多了一段"另外你还要处理退货"。这种情况下拆开，维护成本翻倍，收益只是语气更统一。
五、拆完之后的洞：上下文断裂
维度对了，还有第二个问题。
客户在导购那里聊了四轮，第五轮改口说"我上次买的那个面霜用了有点刺痛，能退吗"。
路由判对了，派给售后。但售后没见过前四轮，它不知道"那个面霜"是哪个。
它的回答是："请问您要退哪一款？"
对客户来说，刚才聊了四轮，你现在问"哪一款"------这不叫专业，这叫失忆。
路由解决"谁来答"，解决不了"它知不知道上文"。
六、上下文的三种传法
我三种都试过。
做法一：传完整对话历史
把上一个 Agent 的几轮对话原样塞进新 Agent 的第一条消息。
两个问题：
上下文膨胀。 四轮对话五六百 token，每轮重发。多切两次边界，上下文就吃掉了大半预算。
历史带毒。 这是更麻烦的那个。对话里带着上一个 Agent 的语气、立场、承诺。售后读到导购说的"这款超适合您"，会潜移到自己也该推销，人设就串了。
我实测过这个：售后 Agent 拿到完整历史之后，客户说"过敏了"，它第一句是"非常理解您的心情，同时我们的积雪草精华对敏感肌也很友好"。
在客诉里推销。
做法二：什么都不传
每个 Agent 各管各的，跨边界等于重新进线。
这就是"您要退哪一款"。
做法三：传结构化事实
这是我现在用的。
在会话层维护一份槽位，切换 Agent 时把槽位渲染成文本注入。
python
SESSION_SLOTS = {
"skin_type": None, # 肤质
"consulted": [], # 咨询过的产品
"purchased": [], # 买过的产品
"issue": None, # 当前售后问题
}
def render_slots(session):
"""只传事实，不传对话。"""
parts = []
if session.get("skin_type"):
parts.append(f"肤质：{session['skin_type']}")
if session.get("consulted"):
parts.append(f"咨询过：{'、'.join(session['consulted'])}")
if session.get("purchased"):
parts.append(f"购买过：{'、'.join(session['purchased'])}")
return "\n".join(f"- {p}" for p in parts)渲染出来是这样：
diff
用户背景：
- 肤质：敏感，容易泛红
- 咨询过：积雪草舒缓精华（398 元）
- 购买过：玻尿酸保湿霜（上月下单）
- 当前问题：保湿霜使用后有刺痛，要求退货四条，二十来个字。比四轮对话短得多，而且不带任何立场。
核心判断：传事实，不传对话。对话带人设，事实只带信息。
这条可以推广：任何跨 Agent、跨会话、跨流程的状态传递，都应该传结构化的最小事实集，而不是原始文本。
七、槽位谁来填
不让 Agent 自己总结，那样多一次调用，而且不稳定。
我的做法是跟路由合并。
路由本来就要读用户这句话，读的时候顺便抽槽。规则层能匹配的（"敏感肌"→ skin_type）直接填，匹配不到的交给 LLM 路由那一次调用一起返回 JSON。
python
ROUTE_PROMPT = """你是意图路由器，同时负责抽取会话信息。
判断意图：sales（咨询/推荐/价格）或 after_sales（退换/过敏/物流/投诉）
只输出 JSON，不要解释：
{"intent": "sales", "skin_type": null, "product": null, "issue": null}
"""合并之后省一次模型往返。代价是输出格式不稳定------模型有时会在 JSON 前加一句"好的，分析如下"。所以解析必须包 try，失败退回默认值，不能让整个路由挂掉。
槽位必须是预定义的固定键，不能用自由文本。固定键的好处是不会漏、不会膨胀。自由文本摘要跑一个月，会变成一篇越来越长的小作文。
八、什么时候别拆
多 Agent 不是免费的。每拆一个，就多一个路由失败点、多一处上下文传递、多一套人设维护。
判断标准很土但有效：数 system prompt 里的条件分支。
text
如果是产品咨询，按导购方式回答；
如果是退换货，走售后流程；
如果是物流问题，让客户提供订单号；
如果是投诉，先安抚再转人工。四个分支 → 应该拆。因为一个 Agent 要在四种语气间切换，它一定会在某个时刻切错。
一两个分支 → 别拆。拆完要维护两个 Agent、一套路由、一套槽位，收益只是"语气统一一点"。
经验值：条件分支三个以上才考虑拆。
九、结论
四句话：
- 分几个不重要，按什么维度分才重要。 检验标准：拆出来的两个能不能同时是用户当前的处境。
- 功能是动词，阶段是状态。 动词能组合，状态互斥。所以阶段能拆干净，功能不能。
- 拆完之后必须补上下文传递。 传事实不传对话------对话带人设，会污染下一个 Agent 的立场。
- 三个分支是拆分的门槛。 不到就别拆，拆了是负债。
最后一个判断：如果你的多 Agent 系统里，几个 Agent 的回答风格几乎一样，那基本可以确认拆分没带来价值。真正的拆分，应该让两个 Agent 说出来的话明显不像同一个人。
像同一个人，说明你只是把一个 Agent 的文件拆成了三个，运行时还是同一个。