← 返回概念解读

Concept Fable精修版

交接

Handoff · Coordination pattern

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

夜班没有接住的半封急信

山城邮驿分早晚两班。白班驿卒接到急信,已经查过收件人、问过路况、换好了马,只差夜里过关送出。交班时,他只说一句:这封信很急。

夜班驿卒拿到信,却不知道为什么急、谁确认过地址、哪些路不能走、下一步该先找谁。他怕耽误,重新查了一遍,天亮前仍没出城。

站长先要求交班时多说几句。可人一忙,就有人漏讲;有人讲了很多背景,夜班仍分不清哪些是事实、哪些是猜测、哪些是待办。

一次更糟,白班把客户的抱怨、内部限制和下一步动作混在口头交代里。夜班把抱怨当成授权,差点越权退费。

站长明白,交接不是把任务扔给下一个人,也不是把全部历史倒过去。交接要转移所有权,同时保留足够上下文和明确下一步。

他设计了交接单:当前目标、已完成动作、关键事实、未验证假设、权限边界、风险、下一步、失败时找谁。接收人必须确认能继续执行。

后来急信再到夜里,夜班不用重做白班工作,也不会把客户原话当成命令。他知道自己接手的是哪一段任务,而不是一团旧聊天。

邮驿还规定,高风险交接要留下记录,必要时升级给站长;低风险交接则保持轻量,避免流程压垮速度。站长说:真正的交接,是让下一位接手者从正确的位置继续,而不是从混乱里重新开始。后来站长抽查交接单,发现真正省下的不是几句话,而是下一班不再重做上一班的摸索,也不把未证实的猜测当成命令。交接单也会随任务轻重变化。普通信只写三行,急信写全套,涉银票的还要双人确认。形式服务继续执行,不是为了堆纸。从那以后,急信过夜不再靠运气。

揭示

这个故事讲的是:交接

Handoff 是任务所有权、上下文和下一步动作从一个 Agent、工作流、系统或人转移给另一个执行者的过程。在企业 Agent 中,交接常发生在多智能体协作、人工升级、客服转专家、自动流程转人工审批等场景。可靠 handoff 需要明确当前状态、已做动作、未完成事项、权限边界、风险、证据来源和接收确认,避免重复劳动、上下文丢失或越权行动。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 白班和夜班:两个 Agent、系统或人类角色
  • 只说这封信很急:缺少结构化上下文的交接
  • 重新查一遍:handoff 失败导致重复工作
  • 把抱怨当授权:交接中指令、事实和风险混淆
  • 交接单:handoff payload 或 transition summary
  • 接收人确认:任务所有权正式转移
  • 最后洞察:Handoff 的核心是让接手方带着足够状态继续执行

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

orchestrationmulti-agent systemhuman-in-the-loopescalationsupervisor agent