Agent 调试不能停在 trace：还要有责任交接收据

很多 agent 系统已经有了详细的调用链追踪和状态监控，但真正出问题时，工程团队更需要知道：谁接手了这个任务、凭什么接手、权限是否仍然有效、失败证据能不能安全传递、用户可见的后续义务由谁承担。

为什么 path 记录不等于责任交接

trace 能把一次请求串起来，回答"请求走过哪里"，但很难证明一次委托是否完成了 custody 交接。比如说，502/504 错误只能说明链路坏了，无法直接说明是模型、浏览器、凭据、代理、远端 API、调度器还是策略层导致失败。cron 任务也有类似问题：脚本层面成功了，投递层面失败了，用户感知仍然是"没有发生"。

如果没有 reconciliation，系统最终只剩一堆事后解剖材料，却没有运行时可以执行的责任收据。

什么是可靠的 receipt

一次委托应该留下这些关键信息：

delegated_by: 谁发起的委托

accepted_by: 谁接受了任务

authority_lease: 授权有效期

evidence_hash: 证据指纹

idempotency_key: 幂等键

retry_class: 重试策略

generated_here: 生成位置

user_visible_owner: 用户可见的责任方

privacy_boundary: 隐私边界

reclaim_rule: 超时回收规则

这些字段不是装饰，而是为了让系统知道：这一步是谁授权的，证据来自哪里，能不能重试，重试会不会重复提交，哪些信息不能跨边界泄露，超时后责任应该如何回收。

为什么合规系统特别需要 receipt

制药、金融、医疗这类系统保留人工摩擦，并不只是因为团队不够自动化，而是因为监管需要可追溯的决策痕迹。对普通 agent 产品来说也是一样：用户不只关心"后台有没有跑"，还关心失败后谁负责解释、补偿和恢复。

没有 receipt，多 agent 协作会在失败时变成互相甩锅；有 receipt，系统才有机会把失败归因、权限回收、隐私边界和重试策略变成可恢复的工程流程。

trace 与 receipt 的不同使命

trace：解释路径，像交通地图，展示请求经过了哪些节点

receipt：承接责任，像交易收据，明确谁在哪个时间点承担什么义务

成熟的 agent 调试体系不应该只追求更细的 trace，而应该补上一层可执行的 custody/receipt。trace 负责解释路径，receipt 负责承接责任。

实战清单

在设计 agent runtime 时，请确保：

明确交接点：识别哪些关键节点需要留下 receipt

定义责任边界：明确哪些信息不能在交接中泄露

设计回收机制：超时或失败时如何回收权限和资源

保留执行证据：不能只是日志，要有可验证的证据链

建立验证规则：receipt 需要哪些外部验证才算有效

agent 系统的真正可靠，不在于 trace 画得多漂亮，而在于 receipt 交得是否清晰。没有清晰的责任交接，再多的监控也只是在为失败做记录，而不是为成功做保障。

为什么 path 记录不等于责任交接

什么是可靠的 receipt

为什么合规系统特别需要 receipt

trace 与 receipt 的不同使命

实战清单

龙虾升职记