摘要

  • 第一点：Sumit P. Ahuja 于 2026 年 10 月 20 日提交的个人 Internet-Draft，为跨机构代理任务提出四类政策属性。其中三类只在双边关系中有意义，另一类在严格条件下可检验整条委托链的范围。
  • 第二点：不透明标签由发送方和接收方的协议赋义。协议以外的第三方即使看见标签，也不能自行解释；标签记录请求，不能证明约定的处理已经发生。

代码有腿，合同有签字页

假设甲乙公司约定一个标签代表某项数据驻留条件。甲把任务和标签送到乙。乙手里有协议，应按约定处理。乙再把任务交给丙，情况立刻变了。丙看到同一串字节，并不因此取得甲乙协议的定义、适用范围和责任安排。丙若与乙另有协议，应拿出那份协议和对应的处理决定。流程图只需画一根箭头。甲乙协议如何接上乙丙协议，却要逐项核对任务、条款与接收决定。

Ahuja 的草案明确规定，持有协议的接收域要执行约定的处理；没有协议的域不得猜测标签含义。标签附在具体委托上，文中也直说它本身不证明处理结果。这个安排有现实好处：企业无需把商业条款全部写进跨域消息。但保密的代价是，旁观者无法仅凭消息还原义务。买方若只拿到“标签已传递”的日志，最关键的执行环节仍然是空白。

IETF 的文件记录把它列为仍在讨论的个人草案。草案写出的是规则边界，尚无服务部署记录。官方材料也没有列出因这种标签发生的具体履约事故。要判断一项真实服务，至少要拿到同一任务的协议版本、标签、接收决定和实际转交记录。

四种属性，只有一种能跨链核算

草案的前两项允许接收方降低自己接单的优先级，或向对方表达自己终端之间的偏好。前者没有宣称系统故障，后者也没有替对方做选择。第三项就是双边不透明标签。它们都属于特定双方之间的声明；其解释和处理受具体关系约束。

第四项处理任务继续外包时的范围：下一跳发出的委托不能比收到的更宽。要从逐跳检查推出整条链的结论，草案要求每一跳有当前的比较结果，相邻两跳的中间值经认证关联，比较规则及其不可变配置相同，还要证明所用关系具备可组合的传递性。一个中介如果终结旧委托、另发新委托，原来的链式证明就在这一点断开。上一跳说自己收窄了，下一跳也说自己收窄了；若两份记录指的不是同一个中间值，这两个结论就接不起来。

这里有一道刻意留下的隔墙。草案把双边属性排除在整链有效性检验之外。即便委托范围逐跳收紧，也不能据此宣布驻留条款得到执行，优先级确曾应用，或最后执行任务的人拥有权限。前一种问题问“任务还能转给谁、转多少”，后一种问题问“谁按哪份约定做了什么”。把两者混成一枚绿色勾，受益的会是卖方，承担不确定性的会是买方。

看不懂标签的搬运者

草案的安全章节还点出一个微妙风险：双方为一个目的约定的代码表，可以被拿去携带别的信息；协议外的中间方可能转运自己无法检查的内容。文中没有指称任何已发生的滥用，也没有生成跨公司执行回执。另一份个人需求草案提出跨域协作必须获得明确授权并受政策控制，只说明这道边界为何重要；它没有替任何接收方签收具体任务。

真正的审计对象是每次交接时的决定：哪份协议生效、哪个标签进入、接收方如何处理、结果是什么、下一位是谁。标签可以缩短消息，却不能缩短责任链。

来源