模式矩阵 /模式白皮书/C4

ADPS Agent 设计模式白皮书

C4 · Handoff Chain · 交接链

把一个长流程拆成 N 个职责清晰的 agent,前一棒处理完后通过结构化 HandoffPacket(不是裸文本)把关键状态传给下一棒,每一棒只擅长一件事。

版本
v0.3
状态
公开评审稿
发布日期
2026-07-13
分类
协作 Collaboration × 链式 Chain(传)
目录地位
核心模式
许可
CC BY 4.0

文档状态:本页为公开评审稿。模式定义与分类可供讨论和引用;未附来源链接的数字与应用示例只用于说明机制,不作为行业基准。

坐标 协作 Collaboration × 链式 Chain(传)
成本 中(每次交接加一次 LLM 调用)
模式组 协作模式
模式简介 把一个长流程拆成 N 个职责清晰的 agent,前一棒处理完后通过结构化 HandoffPacket(不是裸文本)把关键状态传给下一棒,每一棒只擅长一件事。

问题

多 agent 系统翻车,很多时候不是因为单个 agent 不够强,是因为交接掉了棒。一线 agent 拿到客户的全部信息,转给二线时只传"客户上一句话的原文",二线接手就像一个刚走进来的同事——对客户是谁、为什么烦、已经说过什么完全无知,于是又问一遍。

交接链解决的是任务在多个 agent 之间顺序传递时,每次交接信息无损、责任明确、失败可追溯。它的设计重心藏在一个命名判断里:handoff 译"交接"不是"接力"——接力是动作(跑),交接是状态(交班)。Agent 之间真正传递的不是跑的动作,而是上一棒完成的状态,这个状态必须显式 schema 化才不会丢。人类客服中心 30 年前就解决过这个问题,叫 warm handoff:交接前几秒前一个客服跟接手的客服把事情说清楚,再把电话切过去。

分类依据:协作 × 链式

  • 纵轴 · 协作:上一个 agent 的输出就是下一个 agent 的输入,接力式的多 agent 协作。每一棒都是职责清晰的 peer,没有 supervisor 作为稳定锚点——这是它跟层级委派最大的区别。
  • 横轴 · 链式:N 个 agent 严格按顺序传递,不并行也不循环。区别于扇出聚合的 N 个 worker 同时干,也区别于对抗评审的来回辩论。顺序敏感是它的硬特征。

解决方案与机制

一次交接由三件事保证不掉棒:

  1. 职责切分:长流程拆成 N 个职责清晰的 agent,每一棒只擅长一件事、不需要懂整个流程。
  2. 结构化打包:前一棒处理完,把关键状态打包成 HandoffPacket 传给下一棒——不是 dump 对话历史,而是 schema 化的结构。这是它跟单 agent 多 prompt 串联最大的区别:后者 context 自然延续,交接链跨 agent 跨 session,state 必须显式 schema 化。
  3. 受控移交:交接前有权限闸判断这次交接合不合理,有链长上限防止无限传递,每次交接落 audit log。

HandoffPacket 建议至少五层 schema:

内容
Goal 客户根本诉求 + 当前未解决的具体问题
Artifacts 已完成的产出(查过的 KB、跑过的脚本、抄过的 ticket)
Decisions 决策含 what / why / evidence——最容易丢的一层
Rejected Paths 已尝试失败的方向,下一棒不要重复
Next Required 显式的下一步动作,不允许"看着办"

适用条件

  • 分级客户支持:L1 分诊、L2 技术、L3 工程、Director 升级,模型逐级增强、工具权限逐级放开、SLA 逐级升级。
  • 专业分工的审批流程:医疗的分诊护士到全科到专科到主任、法律的 paralegal 到 associate 到 partner、销售的 SDR 到 AE 到 CSM 到 VP。
  • 执行型 agent 的控制权回交:当一个 agent 完成自己职责需要把控制权交还给上层时(详见企业落地一例)。

四个条件要同时满足:专业分工明确、顺序可定、state 可结构化、SLA 升级机制是业务核心。

已知失效方式

  • 冷转接:只传"用户最后一句话"给下一棒,下一棒没拿到任何前面的上下文。识别信号是客户在交接后立刻被问已回答过的问题、情绪从 calm 转 frustrated 的转折点跟交接时点重合。修法是 HandoffPacket 必须含至少五层 schema。
  • 决策溯源丢失:Artifacts 都传过去了,但决策的 why 没传——下一棒看着一堆产出却不知道前任凭什么走这条路,于是重走流程或推翻前任决策。"Artifacts survive handoff, decisions don't",除非给 decisions 单独留一个 schema 字段。
  • 震荡循环:同一对 agent 反复来回交接,L2 觉得该 L1 处理踢回去,L1 又踢回来,跑了 8 跳还在原地。修法是设链长硬上限(3-4 棒,超过强制升人工)、显式约束 can_handoff_to(L2 不能交回 L1)、记录 visited set。
  • 过度交接:LLM 默认有 over-handoff 倾向,碰到稍微难的事就想踢给下一个 agent。可以在交接前加一道 classifier 审视"这次交接合理吗,是不是该自己做完"。
  • 短任务或无清晰角色误用:整体 30 秒能搞定的任务、"通用助理"这种本质单 agent 的场景、实时对话延迟敏感的场景,交接的开销反而是负担。Loop 风险高的场景应该用层级委派让 supervisor 当锚点。

验证指标

  • 链长跳数(健康区 ≤ 4):单条 chain 经过的交接次数。超过 4 跳要强制升人工,这是防震荡循环失控的关键防线。
  • 交接后重复提问率(健康区接近 0):客户在交接后被问已回答过问题的比例。这是冷转接最直接的症状。
  • 决策保留率(健康区高):前一棒的决策被完整传给下一棒的比例。低说明 HandoffPacket 退化成了 raw history dump。
  • SLA 达成率(按分级核算):各级 agent 在自己 SLA 窗口内完成的比例,配合 sentiment carry over 监控升级链路里的客户情绪变化。

参考实现

HandoffChain.execute(request, initial_agent, max_hops=4):
    current, prev_packet = initial_agent, None
    for sequence in 1..max_hops:
        output = run_agent(current, prev_packet)   # 输入是结构化 packet 不是 raw history
        packet = build_packet(prev_packet, output) # 累积式继承 artifacts/decisions/rejected
        audit(packet)
        if output.complete: return result
        next = output.handoff_to
        if next not in current.can_handoff_to:      # 权限闸:防越级 + 防 oscillation
            return escalate_to_human()
        prev_packet, current = packet, next
    return escalate_to_human()                      # 超 max_hops 升人工

HandoffPacket: 五层 schema(Goal / Artifacts / Decisions / Rejected Paths / Next Required)

四个工程要点:每棒的 system prompt 和 tool 权限严格分级(一线不能给退款权限);can_handoff_to 显式列允许的下一棒;max_hops 设 3-4 超过强制升人工;audit log 满足跨棒数据流转的合规留档。

应用示例

某中型 SaaS 公司用 LangGraph 部署了一套 L1/L2/L3/Director 四级客户支持 Agent,6 月上线 10 月被砍,导火索是一张被转了 1.8 万次的截图:客户说"webhook 收不到事件,2 万订单卡着",一线转给二线,二线开口又问"请问遇到什么问题""请问您的账户邮箱",客户回"我刚才说了""上面已经有了"。根因分析的结论是:四级架构每个交接环节都是重新开一个 session,前一棒只传客户上一句话的原文。这不是技术 bug,是设计选择,当初觉得"前面处理过的下一个不需要看了,省 token"。修法是给每次交接打包五层 HandoffPacket:客户诉求、已查过的 KB 和跑过的脚本、做过的决策含 why、已排除的方向、下一步动作,配合模型分级(一线 Haiku 跑量、工程层 Opus 处理复杂)、工具权限渐进(一线只读、Director 才能批退款)、链长上限 4 棒超过升人工。另一个值得引用的落地是执行型 Agent 的控制权回交:当一个 ReAct agent 判断当前决策类型是 plan(或 Skill 契约约定为 PlanExecute)时,它不自己往下执行,而是通过 handoff 把控制权交回 orchestrator,由 orchestrator 决定后续编排——这把交接链用在了 agent 内部的控制流移交上,不只是面向用户的分级支持。

相关模式

  • Prompt Chaining(行动模块):同源对偶。Prompt Chaining 是单 agent 多 prompt 串联(context 自然延续),交接链是多 agent 跨 session 显式 state 传递(必须 schema 化)。关键差别在 context 是否需要显式 schema 化。
  • 层级委派(C1):交接链没有主管、每一棒都是 peer,层级委派有 supervisor 作为稳定锚点。Loop 风险高时回到层级委派让 supervisor 当锚点反而更稳。
  • 扇出聚合(C2):交接链是 N 个 agent 顺序干,扇出是 N 个 worker 同时干。
  • 子代理隔离(C5):交接链关注跨棒的 state 显式传递,子代理隔离关注 sub-agent 的 context 边界,两者关注点不同但都涉及 agent 间的信息流设计。

设计结论

交接链的工程本质不是数据传递,是把企业里已经存在 30 年的人类组织流程 schema 化成 agent 能执行的工程结构——赢面在五层 schema 都被工程化的场景,输面在只 dump 对话历史还假装那叫交接的场景。

企业证据

当前没有与本模式绑定的公开评审案例。模式定义不因此视为已经获得企业验证。

案例收录要求说明业务约束、实现结构、已知失败和迁移边界。参见 贡献与评审规则

引用建议:ADPS,《C4 交接链》,Agent 设计模式白皮书 v0.3,2026-07-13。

模式目录 · 参考实现 · CC BY 4.0