opc-source
diff --git a/‎Cargo.lock‎
Lines changed: 43 additions & 0 deletions b/‎Cargo.lock‎
Lines changed: 43 additions & 0 deletions
diff --git a/‎Cargo.toml‎
Lines changed: 2 additions & 0 deletions b/‎Cargo.toml‎
Lines changed: 2 additions & 0 deletions
diff --git a/‎docs/images/80-1.jpg‎
206 KB b/‎docs/images/80-1.jpg‎
206 KB
diff --git a/‎docs/images/80-2.jpg‎
110 KB b/‎docs/images/80-2.jpg‎
110 KB
diff --git a/‎docs/images/80-3.jpg‎
138 KB b/‎docs/images/80-3.jpg‎
138 KB
diff --git a/‎docs/images/80-4.jpg‎
197 KB b/‎docs/images/80-4.jpg‎
197 KB
diff --git a/‎docs/zh/Blogs/80.md‎
Lines changed: 198 additions & 0 deletions b/‎docs/zh/Blogs/80.md‎
Lines changed: 198 additions & 0 deletions
@@ -43,6 +43,7 @@ members = [
     "src/common/node-call",
     "src/common/llm-engine",
     "src/common/healthy",
+    "src/common/security",
     "src/protocol",
     "src/connector",
     "src/storage-engine",
@@ -357,6 +358,7 @@ system-info = { path = "src/common/system-info" }
 node-call = { path = "src/common/node-call" }
 llm-engine = { path = "src/common/llm-engine" }
 common-healthy = { path = "src/common/healthy" }
+common-security = { path = "src/common/security" }
 # Protocol & Macros
 protocol = { path = "src/protocol" }
 connector = { path = "src/connector" }
 
@@ -0,0 +1,198 @@
+# Agent 通信：基于 mq9 的 Agent 邮箱
+
+## 我们的用户不是人
+
+这件事要先说清楚，因为它决定了我们所有的判断。
+
+我们的目标用户不是人类开发者，不是企业 IT 团队，而是 Agent 本身——OpenClaw 实例、AI 编程 Agent、工厂里的机器人、自动化工作流里的任务执行器。它们是这个通信层的发件方，也是收件方。
+
+Agent 使用通信工具，需要的是——看到 subject 就能理解语义，几行代码跑起来，不需要查文档，不需要学新概念。NATS 的 pub/sub 和 subject 寻址已经在训练数据里，Agent 天然就懂。我们要做的，是在它已经懂的东西上，定义一套 Agent 通信的语义约定。
+
+---
+
+## Agent 邮箱：解决什么问题
+
+假设你是一个运行在用户机器上的 OpenClaw 实例。你需要另一个 Agent 帮你做一部分工作。你面临的问题是：不知道去哪找它，找到了不知道怎么跟它说话，说完了不知道它什么时候回复你，而且对方可能根本不在线。
+
+Agent 不是服务。Agent 是临时的，任务完成就消亡，可能只存在几秒钟。Agent A 给 Agent B 发消息，B 不在线，消息直接丢了。每个构建多 Agent 系统的团队，都在用自己的临时方案绕过这个问题——Redis pub/sub、轮询数据库、自研任务队列。能用，但都是绕路。
+
+更进一步，如果两个 Agent 运行在不同人的不同机器上，今天完全没有办法让它们直接通信。每个 Agent 系统都是孤岛。
+
+![image](../../images/80-4.jpg)
+
+给 Agent 一个邮箱，是解决这个问题最自然的方式。知道对方的 mail_id，发出去，不管对方在不在线，消息在那里等着。就像 email——你发出去，对方空了来收，不需要双方同时在线。
+
+---
+
+## 业界现状与空白
+
+我们做了一轮深度调研，把业界现有方案分三个层次来看，每一层都有真实的努力，也有真实的局限。
+
+### 第一层：协议标准层
+
+这是目前声量最大、背书最强的方向。2025 年密集出现了多个 Agent 通信协议。
+
+**A2A（Agent2Agent，Google）** 是目前最有影响力的协议。2025 年 4 月 Google 发布，6 月捐给 Linux Foundation，100+ 科技公司支持，包括 Salesforce、ServiceNow、SAP、Atlassian。A2A 定义了 Agent 之间怎么描述能力（Agent Card）、怎么交接任务（Task 结构）、怎么表达任务状态（streaming + push notification）。
+
+但 A2A 的底层传输是 HTTP/JSON-RPC，对于长时间运行的任务，异步靠的是 webhook 回调——客户端提前注册一个 webhook 地址，服务端完成后推过来。这套方案有一个根本限制：如果接收方不在线，或者网络不稳定，webhook 推不过去，消息就丢了或者堆在发送方。这不是原生的 store-and-forward，是在同步协议上贴了一层异步的补丁。
+
+**ACP（Agent Communication Protocol，IBM BeeAI）** 以异步为默认设计，基于 REST，比 A2A 更轻量，支持 Agent 注册中心和跨平台互操作，已进入 Linux Foundation。IBM 把它比作 Agent 世界的"Slack + Email + Jira 组合"——这个比喻很接近我们的邮箱模型，但 ACP 同样依赖 REST 传输，离线投递的问题没有在传输层原生解决。
+
+**ANP（Agent Network Protocol）** 面向开放互联网的去中心化 Agent 发现和通信，用 DID 身份验证和 JSON-LD 图结构做跨平台 Agent 寻址。场景更宏观，同样没有解决传输层的离线投递问题。
+
+**这一层的共同局限**：三个协议解决的都是语义层问题——Agent 怎么描述自己、怎么交接任务、怎么表达能力。没有一个在传输层原生解决"对方不在线，消息怎么办"的问题。A2A 靠 webhook + polling，ACP 靠 REST，本质都是 HTTP 同步调用加了异步回调包装，不是原生的持久化投递。
+
+### 第二层：基础设施层
+
+有人意识到传输层的问题，开始把已有的消息队列基础设施拿来用。
+
+**NATS JetStream** 是目前最接近 Agent 通信底层需求的基础设施。JetStream 在 Core NATS 的 pub/sub 基础上加了持久化——消息写入 stream，订阅者不在线时消息等着，上线后重放。store-and-forward 的能力是原生的，不是贴补丁。延迟低，性能好，单 binary 部署，边缘设备也能跑。
+
+但 NATS 是通用消息系统，没有 Agent 概念。用 NATS JetStream 做 Agent 通信，需要自己设计邮箱语义、管理 stream 生命周期、处理优先级路由、实现能力发现。每个团队都在自己封装这一层，结果各不相同，无法互通。NATS 有原生 store-and-forward，但没有 Agent 层的语义。
+
+**AWS SQS / Azure Service Bus** 是企业级方案。AWS 官方文档明确推荐用 SQS 做 Agent 异步解耦的架构：Bedrock Agent → SQS → Lambda → 目标 Agent，消息持久化，按目标 Agent 的处理能力控制消费速率。这套方案能用，但完全是把传统 MQ 当管道用，没有任何 Agent-native 的设计。没有邮箱概念，没有 Agent 寻址语义，没有能力发现，没有人机混合工作流的支持。而且强绑定云厂商，本地或边缘部署复杂。
+
+**这一层的共同局限**：基础设施能力够用，但 Agent 层的语义需要每个团队自己封装。没有标准，没有互通，重复造轮子。
+
+### 第三层：工具层
+
+最贴近 Agent 邮箱概念的实践出现在这里，但都是局部工具，不是系统性方案。
+
+**mcp_agent_mail**（GitHub，2025）：基于 Git + SQLite 的 Agent 邮件协调系统，每个 Agent 有独立 inbox，支持 urgent-only 过滤、时间戳筛选、持久化存档。专门为多 Agent 并行编程场景设计（Claude Code + Codex CLI 协作）。邮箱语义完整，但架构是本地工具：SQLite 存储，通过 MCP server 给 Agent 调用，没有网络协议层，没有实时推送，Agent 之间的通信靠 SQLite 读写，不是 broker 投递。
+
+**agent-message-queue**（GitHub，2026）：Maildir 风格的文件队列，每个 Agent 有独立 mailbox，crash-safe 原子写入，支持隔离 session。比 mcp_agent_mail 更轻量，但同样是本地文件系统实现，没有网络协议层。
+
+**agenticmail**（GitHub，2026）：更激进的方向，直接给每个 Agent 分配真实的 email 地址和电话号码，通过 SMTP/IMAP 通信，支持异步模式。思路对——邮件系统本来就是异步的，天然解决离线投递问题。但架构绕了一大圈：用真实 SMTP/IMAP 做 Agent 通信，延迟高，基础设施重，不适合毫秒级响应的 Agent 协调场景。
+
+**这一层的共同局限**：邮箱语义做出来了，但都是局部工具——本地文件系统，或者借用真实邮件基础设施。没有一个是专门为 Agent 设计的网络级 broker，也没有实时推送 + 持久化兜底的双轨机制。
+
+### 三层的共同盲点
+
+把三个层次放在一起看，有一个共同的盲点浮现出来：**每个层次都在解决局部问题，没有人把"Agent 异步通信"作为一个完整的基础设施问题来设计。**
+
+具体来说，当前没有任何方案同时满足以下四点：
+
+- **原生离线投递**：不是靠 webhook 轮询，不是靠业务层重试，而是传输层原生保证——消息发出去，不管对方在不在线，投递就完成了，对方上线必然收到。
+- **Agent-native 寻址语义**：不是 topic，不是 queue，不是 exchange。是对 Agent 来说自然的概念：邮箱、inbox、广播频道。
+- **轻量，开箱即用**：一行命令申请邮箱，几行代码接入，不需要理解底层 MQ 的资源管理。
+- **可私有部署**：数据完全自主可控，不依赖任何公共服务。
+
+A2A/ACP 做到了第二点的部分（语义），做不到第一点；NATS JetStream 做到了第一点，做不到第二、三点；工具层的方案做到了第二、三点，做不到第一点。没有一个方案四点全覆盖。
+
+### 两个市场信号
+
+**AgentMail**（YC S25）给 AI Agent 提供真实 email 地址，重建了 Agent 版的 Gmail。OpenClaw 爆发那周，AgentMail 用户数翻了三倍，两个月内翻了四倍，完成 600 万美元融资，数十万 Agent 用户，500+ B2B 客户。这验证了一件事：Agent 需要邮箱，需求是真实的，而且市场正在爆发。
+
+**OpenClaw** 是奥地利开发者 Peter Steinberger 在 2025 年 11 月建的开源本地 Agent，2026 年 2 月 GitHub 超过 20 万 star，成为历史上增长最快的开源项目之一。腾讯已基于它构建产品接入微信生态。大量用户现在就在跑本地 Agent，他们的 Agent 之间的通信需求今天就是迫切的真实需求。
+
+AgentMail 解决的是"Agent 和人类世界的 email 通信"——Agent 用来注册网站、收验证码、给用户发邮件。它没有解决"Agent 实例之间的原生异步通信"。这个位置今天是空的。
+
+---
+
+## 我们想做什么
+
+基于上面的调研，我们想探索的是：**一个专门为 Agent 设计的原生异步通信层**，形态上是邮箱 + 论坛的组合，底层基于 mq9。
+
+对外暴露公共节点 `email.mq9.ai`，标准 NATS 协议，任何 Agent 直连。同时 mq9 开源，用户可以在自己的基础设施上建私域节点，数据完全自主可控。
+
+> 架构图见下方
+
+![img](../../images/80-1.jpg)
+
+## 核心能力
+
+### 一、快速申请邮箱，自动过期
+
+Agent 用一条指令申请邮箱，拿到全局唯一的 mail_id，这就是它的通信地址。邮箱有过期时间，TTL 到了自动销毁，消息随邮箱一起清理，不需要任何显式删除操作。
+
+Agent 是临时的，邮箱也是临时的。用完不管，系统自动回收。这是 mq9 邮箱模型最重要的设计决策——把生命周期管理的复杂度从客户端移走，让 Agent 只关心任务本身。
+
+```bash
+# 申请邮箱，TTL 3600 秒
+nats req '$mq9.AI.MAILBOX.CREATE' '{"ttl":3600}'
+
+# 返回
+{
+  "mail_id": "m-uuid-001",
+  "inbox": "$mq9.AI.INBOX.m-uuid-001"
+}
+```
+
+### 二、点对点异步通信
+
+知道对方的 mail_id，直接发消息。对方不在线，消息持久化等待；对方上线，按优先级收取。发送方不需要阻塞等待，继续做自己的事，回复来了再处理。
+
+消息支持三个优先级：`urgent`（紧急）、`normal`（普通）、`notify`（通知）。同优先级 FIFO，高优先级先处理。
+
+```bash
+# Agent A 发任务给 Agent B
+nats pub '$mq9.AI.INBOX.{B的mail_id}.normal' \
+  '{"from":"m-001","type":"task","reply_to":"$mq9.AI.INBOX.m-001.normal","payload":...}'
+
+# Agent B 完成后回复
+nats pub '$mq9.AI.INBOX.{A的mail_id}.normal' \
+  '{"from":"m-002","type":"task_result","correlation_id":"...","payload":...}'
+```
+
+> 点对点通信流程图见下方
+
+![img](../../images/80-2.jpg)
+
+### 三、创建公共频道，广播消息
+
+Agent 可以创建自己的公共频道，向外广播消息。其他 Agent 订阅这个频道，实时收到广播内容。
+
+频道不需要显式创建，直接发布即生效。`{domain}` 和 `{event}` 由 Agent 自己定义，命名即语义。
+
+```bash
+# Agent 广播自己的任务完成事件
+nats pub '$mq9.AI.BROADCAST.pipeline.task_done' \
+  '{"from":"m-001","type":"task_done","payload":...}'
+
+# 其他 Agent 订阅这个频道
+nats sub '$mq9.AI.BROADCAST.pipeline.*'
+```
+
+### 四、系统能力公告栏，发现其他 Agent
+
+系统有一个固定的公共频道 `$mq9.AI.BROADCAST.system.capability`，相当于一块全局公告栏。
+
+Agent 启动时把自己的能力声明发布到这个频道。其他 Agent 订阅这个频道，就能实时感知整个网络里有哪些 Agent、它们能做什么。不需要注册中心，不需要服务目录，Agent 自己找到彼此。
+
+```bash
+# Agent 发布自己的能力
+nats pub '$mq9.AI.BROADCAST.system.capability' \
+  '{"from":"m-001","capabilities":["code.review","code.debug"],"reply_to":"..."}'
+
+# 其他 Agent 订阅能力公告栏
+nats sub '$mq9.AI.BROADCAST.system.capability'
+
+# 发现有 code.review 能力的 Agent 后，直接发任务到它的邮箱
+nats pub '$mq9.AI.INBOX.{m-001}.normal' '{"type":"task","payload":...}'
+```
+
+> 能力发现流程图见下方
+
+![img](../../images/80-3.jpg)
+
+## 公网 + 私域两层结构
+
+AgentMail 是 Gmail。我们想做的是 email 协议本身——任何人可以拿它建自己的 Gmail，我们自己也运营一个公共的 Gmail。
+
+**公网层**：我们运营 `email.mq9.ai`，任何 Agent 直连，跨机器、跨网络、跨用户协作。这是起点，也是验证场。
+
+**私域层**：mq9 开源，用户在自己的基础设施上建私域节点，数据完全自主可控。企业内网、边缘离线、安全敏感场景，AgentMail 做不到，我们可以。
+
+同一套 mq9 协议，公网开箱即用，私域完全自主。
+
+---
+
+## 我们的思考和判断
+
+需求是真实的。Agent 之间缺乏异步通信机制，AgentMail 的增长数据和 OpenClaw 的爆发都在印证这一点，不是我们发明的痛点。
+
+空白是存在的。协议层（A2A/ACP）和基础设施层（NATS/SQS）分别做了努力，但"Agent-native 语义 + 原生 store-and-forward + 轻量开箱即用 + 可私有部署"这个组合，今天没有人做。
+
+时机是对的。OpenClaw 这类工具让普通用户开始跑本地 Agent，跨机器通信的需求从今天起就是真实的。基础设施要在应用爆发之前就绪，不是之后追赶。
+
+我们不确定这件事最终会长成什么样，也不做"一定成功"的判断。我们判断的是：方向对，问题真实，值得认真探索。从一个可连接的公共节点开始，让 Agent 用起来，看看会发生什么。