Handoff 与责任交割

状态：参考设计。 本页说明可复用的交接语义与实施边界；它不是已冻结的生产对象、开放 API 契约或自动承接承诺。

Handoff 用于 AI、系统或服务网络不能独立完成下一步时，把最小可行动上下文、授权、责任与回执要求交给合适的执行者。

Reference evidence chain

一次需求提交，如何成为可解释的交接与回执。

入口不等于完成。每次继续都要说明责任、披露边界和可复核证据，才能从咨询进入正式 Handoff。

参考设计

Entry to receipt

先建立事实，再交给下一位执行者。

01
入口留下上下文
谁负责
入口方 / 调用方
可见范围
网站、Widget 或系统只提交完成当前目的所需的公开输入。
证据锚点
来源、时间、channel_id 或业务请求引用。
形成可审阅的请求，而不是直接承诺服务完成。
02
受控 Intake
谁负责
平台
可见范围
平台按授权与边界整理目标、约束、证据与不确定项。
证据锚点
request_id、trace_id、授权状态与输入摘要。
判断是否可继续匹配、补充信息或停止转接。
03
脱敏机会判断
谁负责
平台与候选承接方
可见范围
候选方先看到与能力匹配相关的最小信息，不默认取得联系方式或敏感数据。
证据锚点
能力匹配理由、候选状态、拒绝或超时原因。
承接方明确接受前，不形成已交付或已联系事实。
04
正式 Handoff
谁负责
发起方、平台与承接方
可见范围
只有在授权与正式流程允许后，交付最小可行动的目标、约束、证据、责任和回执要求。
证据锚点
handoff 引用、接受范围、责任主体与有效期。
承接方接受、拒绝或要求补充；沉默不等于完成。
05
承接与回执
谁负责
承接方
可见范围
承接方只在获授权范围内执行，并回传自身可确认的状态与证据。
证据锚点
接受 / 处理中 / 完成 / 失败状态、证据引用与下一步。
结果回写原始请求和交接记录，保持可追溯。
06
恢复与回流
谁负责
责任主体与平台
可见范围
拒绝、超时、证据不足、执行失败或授权撤销时停止扩大披露。
证据锚点
失败阶段、原因、已执行动作与升级记录。
重新匹配、补充证据、人工决策或交还发起方。

01
入口留下上下文
谁负责：入口方 / 调用方
可见范围：网站、Widget 或系统只提交完成当前目的所需的公开输入。
证据锚点：来源、时间、channel_id 或业务请求引用。
形成可审阅的请求，而不是直接承诺服务完成。
02
受控 Intake
谁负责：平台
可见范围：平台按授权与边界整理目标、约束、证据与不确定项。
证据锚点：request_id、trace_id、授权状态与输入摘要。
判断是否可继续匹配、补充信息或停止转接。
03
脱敏机会判断
谁负责：平台与候选承接方
可见范围：候选方先看到与能力匹配相关的最小信息，不默认取得联系方式或敏感数据。
证据锚点：能力匹配理由、候选状态、拒绝或超时原因。
承接方明确接受前，不形成已交付或已联系事实。
04
正式 Handoff
谁负责：发起方、平台与承接方
可见范围：只有在授权与正式流程允许后，交付最小可行动的目标、约束、证据、责任和回执要求。
证据锚点：handoff 引用、接受范围、责任主体与有效期。
承接方接受、拒绝或要求补充；沉默不等于完成。
05
承接与回执
谁负责：承接方
可见范围：承接方只在获授权范围内执行，并回传自身可确认的状态与证据。
证据锚点：接受 / 处理中 / 完成 / 失败状态、证据引用与下一步。
结果回写原始请求和交接记录，保持可追溯。
06
恢复与回流
谁负责：责任主体与平台
可见范围：拒绝、超时、证据不足、执行失败或授权撤销时停止扩大披露。
证据锚点：失败阶段、原因、已执行动作与升级记录。
重新匹配、补充证据、人工决策或交还发起方。

Reference handoff design

把下一步真正需要的上下文与责任交出去。

Handoff 是可行动任务包，不是聊天记录转发。它让下一位执行者在明确授权与约束下决定是否承接，并把结果带回协议主链。

参考设计

Minimum actionable package

七字段交接包

参考设计

目标

任务目标、完成条件与优先级，让承接方知道要达成什么。

参考设计

授权

允许动作、有效期、撤销与人工确认条件，明确可做与不可做。

参考设计

约束

时间、地域、预算、隐私、合规与安全限制，防止上下文被错误扩大。

参考设计

证据

事件摘要、来源、时间、引用与置信度，支撑下一步判断。

参考设计

不确定项

待确认问题、冲突事实与缺失材料，避免承接方把猜测写成事实。

参考设计

责任

发起方、承接方、升级主体与状态所有者，明确谁对哪一段事实响应。

参考设计

回执

承接、处理、完成或失败状态及证据引用，把结果带回协议主链。

Acceptance lifecycle

承接不是瞬间发生，而是可回溯的状态变化。

H A R C任一终端都应明确承接、拒绝或回执。

准备交接

整理目标、授权、约束与已有证据。

待承接

向合适的执行终端发出可审阅的任务包。

已承接

承接方明确接受范围、时效与责任。

执行中

在授权和约束内推进动作并更新状态。

已回执

写回结果、证据、异常和下一步建议。

Recovery paths

失败不是静默终止，而是下一次可解释的交接。

拒绝承接

保留拒绝原因，不把未接受写成已执行。

返回匹配或人工重新决策。

承接超时

承接方沉默不等于完成，必须保留超时事实。

按授权重新匹配或升级责任主体。

证据不足

现有材料无法支撑判断或行动。

回到发起方或采集主体补充信息。

执行失败

记录失败阶段、原因与已执行动作。

写回下一步建议并交给升级主体。

授权失效或撤销

授权到期、撤销或不再满足人工确认条件。

停止后续操作并交还给责任主体。

Responsibility boundaries

责任归属必须和状态一样可见。

主体	负责的事实	不应被暗示负责的事实
发起方	目标、授权来源、输入事实与可接受的升级规则。	承接方的实际履约结果。
承接方	是否接受、执行状态、回执与自身提供的证据。	未获授权的数据或超出能力的承诺。
平台	路由、状态传递、审计与公开流程边界。	代替客户作高责任决定、自动保证交付或结算。

紧急、医疗、安防和其他高责任场景，必须由客户 SOP、当地法规、具备资质的人工主体与正式平台流程决定；本页不构成自动处置承诺。

Illustrative shape

最小对象形态

{
  "goal": "确认现场状态并回传结果",
  "authorization": { "allowed_actions": ["review", "respond"], "expires_at": "…" },
  "evidence": [{ "source": "event", "reference": "…", "confidence": "…" }],
  "responsibility": { "initiator": "…", "acceptor": "…", "escalate_to": "…" },
  "receipt": { "status": "accepted | completed | failed", "evidence_refs": ["…"] }
}

A handoff carries minimum actionable context, not a raw conversation transcript or unrestricted data transfer. 正式生产字段与版本以公开规范资产和正式契约为准。