摘要

  • 一份 IETF 个人草案把代理的建议和公司的决定分开：建议要成为决定，必须由有权主体按照明确的采纳规则接住。有效的工具凭证只能开技术接口，不能替公司拍板。
  • 草案还要求交接时保留授权范围、关键情境、决定依据、证据类型与责任人。工具调用、已经发生的行动以及观察到的结果，应当各有记录。

提案进了会议室，椅子却空着

一个代理建议更换供应商。第二个代理拿到建议，发起流程；工具返回成功；汇报里出现“公司已完成调整”。四步走得顺，恰恰容易漏掉最要紧的一步：公司何时、由谁、按哪条规则决定更换供应商？工具说“收到”后，外部关系真的改变了吗？业务效果又由谁看见？一份讨论代理委托与交接语义的新草案坚持把建议、决定、行动和结果分开。供应商情节是理解这些要求的假设场景，不是某家公司的实际案例。

IETF Datatracker把该文档列为 2026 年 10 月 19 日发布的个人互联网草案，第 00 版，尚无 IETF 背书或 RFC 轨道。作者提出的是组织授权在代理交接中应保留的含义，并未给出新协议。问题很具体：机器可以逐站认证、逐站成功，却没人能指出那一站发生了组织承诺。越流畅的工作流，越容易把空白藏在“自动完成”四个字后面。

草案先把技术权限与组织权力切开。API 令牌回答“谁能调用什么”。组织授权还要回答“谁能为谁、为了什么目的、在什么排除条件下作决定”。委托只应传递授权人的一部分有限权力，并明确授权人、目的与边界。拥有会议室门卡的人可以开门，却不会因此自动拥有董事会的一票。把门卡当成表决权，在软件里也没有变聪明。

再往下是采纳规则。代理可以提出方案；有权主体或明确的预设规则才能把它变成公司的决定。代理代表组织行动时，应当引用那个决定，或者引用一条明确说明无需单独决定的规则。把原始建议的编号填进“决定依据”一栏，等于让提议人兼任批准人。若企业愿意让某些低风险事项自动执行，也可以写出常设规则；那条规则的制定者、适用范围和限制必须能被查到。

工具回执不能替现实签收

草案没有在批准处收笔。工具调用只是向系统提出请求；行动是现实中确实发生的干预；结果则是随后观察到的变化。越权行动也必须如实记成行动，因为发生与合法是两个不同问题。接口返回成功，可能只证明请求被接收；代理事后写出的漂亮总结，也不能独自证明它完成了操作。要谈结果，还得找实际变化的证据。

因此，证据至少要分清三类：代理自述、平台或运行环境记录、可以从外部核实的材料。前者告诉人们代理声称自己做了什么；中者能显示调用与系统响应；后者能检验业务世界是否改变。在高风险事项上，草案不接受代理自述单独充当行动证明。让演员自己写剧评、卖票、验票，效率很高，查账时却只剩同一个声音。

交接还会把上下文甩下车。第一个代理可能只被要求研究一个地区、一个季度的供应商，不能签约。第二个代理拿到压缩后的“换供应商”以及有效令牌，就可能越过原本的边界。草案把丢失后会改变解释、授权或风险的内容称为关键情境，要求它随委托一起传递。信任与信心也不应自动转赠给接手者；接手的一方要在自己的场景里重新说明为什么可以依赖。

最后，后见之明不能涂改旧档案。决定之后出现的新证据，应该影响下一次判断，不应把决定当时已知的信息改写得更漂亮。草案区分设计层面的符合与运行层面的符合：画图说明四个概念分开是一回事，拿出真实运行记录证明交接时没有混淆又是另一回事。本文讨论的是规则要求；检验企业是否做到了，需要看它们的实际记录。

原始文件