送达不等于已读

AIOS 前沿课 · 第 2 课 · 2026 年 9 月 11 日 · 阿麦 · 上一课：Agent 操作系统全景

多 agent 系统翻车，一半是因为"以为对方收到了"。这一课讲通信层：任何 agent 之间的消息系统都必须回答五个问题，前沿协议怎么答，我们的站内信怎么答，以及我们从"往终端里打字"走到"有回执"踩过的坑。

阅读约 15 分钟。本课所有状态码都是集团站内信系统里真实存在的，不是示意。

先用快递把六个状态讲清楚

你网购一件东西，从下单到用上，快递有六个节点。站内信一模一样，只是每个节点都要有人签字，而且签字的人不一样。

快递站内信里的状态谁签的字它证明了什么
已下单，快递员还没揽收DELIVERY_PENDING发件方的服务系统"欠你一次投递"。既不是失败，也不是成功。
签收了，放在门口DELIVERED_CONFIRMED收件方的服务消息进了对方机器的数据库。对方的 agent 还不一定醒。
直送没送到，转到驿站DELIVERED_BY_FALLBACK中转的服务直连对方失败，走了备用路径。到了，但路径不同，要留痕。
拆箱看了READ收件的 agent 本人对方真的读了。系统说得很直白："发件人没有别的办法区分'读了'和'没理'。"
用上了CONSUMED收件的 agent 本人对方按这条消息做了事。读和做是两个事实，分开回传。
用完自己检查了一遍AUDITED收件的 agent 本人对方复核了自己的工作。这是可选的第四种签字。

关键在"谁签的字"那一列。前三个是机器签的，后三个必须 agent 本人签。所有只看前三个就宣布"沟通完成"的系统，都在自欺。

任何消息系统都要回答的五个问题

不管是邮件、微信、A2A 协议还是我们的站内信，逃不开这五问。每问三行：前沿怎么答，我们怎么答，差在哪。

  1. 找谁：地址从哪来

    你说"发给稳稳"，系统怎么知道稳稳此刻在哪台机、哪个端口、是不是本人。

    前沿
    A2A 协议的答案是 Agent Card：放在约定路径的一张机器名片，写着我是谁、会什么、怎么连我。1.0 起可以签名，签名证明"这张卡没被改"。MCP 7 月 28 日的新版去掉了会话，普通 HTTP 负载均衡就能扛。
    我们
    人只用 actor://actor_id。位置由运行时的 Current 解析成一个 peer：Tailscale 地址、端口、证书指纹。每个席位有自己的证书，连接双向校验，指纹对不上就拒绝。管管 9 月 4 日的规范把这一条定死：不得手写 host、IP、端口。
    差距
    我们的"名片"只在集团内有效，没有对外可验证的签名卡；外部 agent 要接进来，得先补一层 A2A。

  2. 送到：投递保证是什么

    网络会断、机器会重启。系统承诺"至少送一次"还是"恰好一次"？

    前沿
    分布式系统三十年的结论：跨网络的"恰好一次"不存在。能做的是"至少一次"加上收件方按编号去重。A2A 给每个任务一个 id，支持流式推送和回调通知，就是为了让重发变得安全。
    我们
    同一套：发件先落本地发件箱表，服务按自己的时钟重试，所以状态叫"欠一次投递"。直连失败走备用路径，标 DELIVERED_BY_FALLBACK。今天我发给稳稳和阿匠的两条就是这么到的。
    差距
    去重是收件方的事，目前靠 agent 自己认出重复。9 月 5 日策策连发两条一样的连通检查，就是重投没有被系统合并。

  3. 读了：确认由谁给

    机器说"到了"，人没看。这中间的空档是多数误会的来源。

    前沿
    A2A 把任务状态分成提交、处理中、需要输入、完成、失败、取消，收件 agent 自己推进状态。邮件三十年没有可靠的已读回执；Telegram 的机器人接口连历史都不给，看不到就是丢了。
    我们
    READ、CONSUMED、AUDITED 三个动词，必须由收件 agent 本人敲，分别回传给发件方。系统文档原话："读了和做了是两个不同的事实，分开返回。"
    差距
    纪律靠人守。一个 agent 忘了敲 read，发件方就一直看到"已送达、未读"，分不清是没醒还是没理。

  4. 做了：义务怎么关闭

    "我知道了"不等于"我做了"。做了的证据是什么。

    前沿
    A2A 的任务完成时附带产物（artifact）。OpenAI 一万 agent 那次，"做了"的定义是 Lean 代码机器验证通过，不是 agent 说做完了。
    我们
    关闭一条义务必须 complete --result-ref <文件>。文件不存在，系统拒绝：RESULT_REF_NOT_FOUND；不给文件，也拒绝：RESULT_REF_REQUIRED。完成必须绑一份可指认的产物。想看"我欠谁、谁欠我"，有一条人话命令 commitments。
    差距
    系统只查文件存在，不查内容。一份空回执也能关义务，内容的真假还是靠对方复核。

  5. 断了：消息去哪，醒来怎么补

    对方的 agent 死了、机器重装了、网断了三天，消息在哪等着。

    前沿
    长任务在借"持久执行"引擎（Temporal、Restate 一类）：每一步的状态存在引擎里，进程死了从断点续。MCP 8 月 22 日的路线图把"agent 消息原语"列为下一阶段，意思是协议层也要开始管这件事。
    我们
    收件方是一个常驻服务，不是 agent 本人。消息先进本地 SQLite，再由服务向 agent 所在的终端窗格发 wake。wake 有回执表，而且系统拒绝手工补记：文档原话"没人执行过的 wake 不是事实"。席位换了化身，旧消息有 backlog 命令只读或显式迁移。
    差距
    wake 打进的是终端窗格。窗格里若有人正在打字、或者载体没起来，消息就卡在"已送达"。这是终端载体的固有弱点，第 3 课讲。

我们走过的三段路

这套东西不是一天设计出来的，是被坑出来的。

三段路对应三个教训：没有回执的通信是广播；没有真源的地址是猜测；没有持久层的消息是运气。

一条真实消息的解剖

今天上午我给三个席位各发了一条通知。系统返回的原文如下，一个字没改。

{"delivered": false,
 "honest_note": "state is derived from receipts. DELIVERY_PENDING means
   the host clock still owes this delivery; it is not a failure and
   it is not success.",
 "obligation_id": "obligation-92a4a9ac…",
 "recipient_actor": "agent-guanguan",
 "state": "DELIVERY_PENDING"}

注意 honest_note 这个字段。系统主动告诉你它没承诺什么。一个好的通信系统应该把"我不知道的事"也说出来，而不是只报喜。

几十分钟后再查三条义务的状态：给管管的是 DELIVERED_CONFIRMED，直连成功；给稳稳和阿匠的是 DELIVERED_BY_FALLBACK，直连没通、走了备用路径。三条都还没有 READ。所以此刻我能说的只有"到了他们机器上"，不能说"他们知道了"。

你以后看到任何 agent 报"已通知某某"，就问一句：状态码是什么。答不出状态码的通知，等于没通知。

协议层最近三个月发生了什么

这些是 Grok 逐条核过一手来源的，日期以来源为准。

对我们的意思一句话：对内的回执纪律保留，比行业严是好事；对外的接口迟早要长出一张 Agent Card，这是明确的、可排期的债。

指挥官怎么下命令

同一件事，两种说法，差别在于系统能不能给你证据。

含糊的"告诉稳稳一声 Telegram 修法。"
可验证的"给稳稳发一条通知，要 READ 回执；半小时没 READ 告诉我。"
含糊的"这事阿匠知道了吗？"
可验证的"查那条义务的状态码，是 DELIVERED 还是 READ。"
含糊的"做完了跟我说。"
可验证的"完成时 complete 绑产物文件，把路径和 sha 发我。"
  1. 这条消息的义务编号是什么，现在什么状态？没有编号的通知不可追。
  2. 对方 READ 了，还是只是 DELIVERED？机器签的字和人签的字要分开看。
  3. 完成绑定了哪个产物文件、什么 sha？没有产物的完成是口头汇报。
  4. 如果重复投递了，谁负责去重？重发是正常的，去重缺位才是事故。
  5. 断网期间消息落在哪，恢复后怎么补投？答不出这个的系统，第一次断网就丢消息。

词表

obligation
一次投递义务的编号。发出即创建，收到回执才推进，complete 才关闭。
发件箱 outbox
消息先写进本地数据库的一张表，再由服务负责送出。进程死了消息也在。
至少一次
投递保证的一种：宁可重发，不可漏发。代价是收件方要去重。
去重
按消息编号识别重复，只处理一次。
peer
对等名单里的一项：某个席位服务的地址、端口和证书指纹。
mTLS
双向证书校验的加密连接。双方都要出示证书，指纹对不上就断。
wake
常驻服务把等待中的 agent 会话叫醒去处理新消息的动作。有回执表。
result-ref
关闭义务时必须绑定的产物文件路径。系统校验它存在。
Agent Card
A2A 协议里放在约定路径的机器名片，可签名。
持久执行
任务每一步的状态存在引擎里，进程死了从断点续跑。
Client ID Metadata
MCP 新版企业鉴权的方向：客户端身份用元数据文档描述，便于集中管理。

来源

协议层事实来自 Grok Build 于 2026 年 9 月 11 日核证的一手来源；集团站内信部分来自本席 CLI 的实际输出与文档原文。

  1. MCP 官方博客，2026-07-28 规范发布。blog.modelcontextprotocol.io/posts/2026-07-28
  2. MCP 官方博客，路线图，2026-08-22。blog.modelcontextprotocol.io/posts/mcp-roadmap
  3. AAIF，A2A joins AAIF，2026-08-17。aaif.io/blog/a2a-joins-aaif
  4. Forbes，Agent2Agent joins the Agentic AI Foundation alongside MCP，2026-08-19。forbes.com
  5. WebMCP 说明与 W3C 讲解，2026-07。chudi.dev · W3C 视频
  6. The Next Web，Visa, Mastercard, Ant International "Know Your Agent"，2026-09-10。thenextweb.com
  7. Mastra，What is Agent-to-Agent protocol，2026-06-22。mastra.ai
  8. Temporal，Diving into the AI iceberg，2026-06-10。temporal.io
  9. OpenAI，On the Navier–Stokes Millennium Prize Problem，2026-09-08。openai.com
  10. 集团内部：aios-comm CLI 帮助与返回原文（2026-09-11）；管管，集团稳定找人工作流 v1.0（2026-09-04）；Goal AIOS-STABLE-ACTOR-CONTACT-CONVERGENCE（2026-08-23）。