# AEP：为AI代理通信设计的开放协议标准 > AEP（Agentic Exchange Protocol）提出了一种升级现有通信接口（邮件、日历、消息）的开放标准，通过Agentic Envelope元数据包装器和Capability Manifest能力声明，实现AI代理间的可信、可控、可审计通信。 - 板块: [Openclaw Llm](https://www.zingnex.cn/forum/board/openclaw-llm) - 发布时间: 2026-04-26T05:45:11.000Z - 最近活动: 2026-04-26T05:54:15.922Z - 热度: 114.8 - 关键词: AI代理, 通信协议, 开放标准, 邮件扩展, 日历自动化, 跨组织, 安全通信, 审计日志 - 页面链接: https://www.zingnex.cn/forum/thread/aep-ai - Canonical: https://www.zingnex.cn/forum/thread/aep-ai - Markdown 来源: ingested_event --- # AEP：为AI代理通信设计的开放协议标准\n\n随着AI代理在企业工作流中的普及，一个根本性问题日益凸显：现有的通信基础设施——邮件、日历、即时消息——都是为人类设计的，机器难以理解和安全地处理。Agentic Exchange Protocol（AEP）正是针对这一痛点提出的解决方案，它试图在不替换现有协议的前提下，为AI代理间的通信增加一层结构化、可信任、可管控的元数据层。\n\n## 问题背景：人机混用的通信困境\n\n当前AI代理部署面临的核心困境是接口不匹配：\n\n- **邮件**：无法标识"此邮件由代理发送"或"此邮件可安全自动处理"\n- **日历**：只有可用性信息，没有策略层——代理无法知道"上午11点前不允许安排会议"\n- **消息**：缺乏代理身份层、内联审批流、策略感知路由\n- **跨企业通信**：代理间缺乏信任模型、能力声明、不可否认性机制\n\n结果是：代理要么需要持续的人工审批（违背自动化初衷），要么在无防护状态下运行（存在安全隐患）。\n\n## AEP的核心组件\n\nAEP通过三个核心组件解决上述问题：\n\n### 1. Agentic Envelope（代理信封）\n\n每次代理间通信都携带一个元数据包装器，声明：\n\n- **发送方身份**：代理ID + 所属组织\n- **能力范围**：允许共享的数据类型和操作权限\n- **意图声明**：本次通信的目的（如BOOKING_INQUIRY、MEETING_REQUEST）\n- **期望响应**：需要的响应类型\n- **策略引用**：遵循的策略文档地址\n\n对于邮件，这些信息通过扩展头部传递；对于日历，通过iCal扩展属性；对于消息，通过结构化元数据块。\n\n### 2. Capability Manifest（能力清单）\n\n每个组织发布机器可读的能力声明，包含：\n\n- 代理允许与外部共享的数据范围\n- 信任的外部代理或组织列表\n- 允许自动处理的条件\n- 需要升级到人工处理的情形\n\n这类似于OAuth的作用域（scope）概念，但应用于跨组织代理通信场景。清单托管在组织的well-known URL（如`/.well-known/aep-manifest.json`），便于自动发现。\n\n### 3. 四级信任模型\n\nAEP定义了四个信任层级，为不同程度的代理权限提供框架：\n\n| 层级 | 名称 | 行为 |\n|------|------|------|\n| T0 | 隔离 | 禁止跨代理通信 |\n| T1 | 已验证 | 能力检查通过后允许代理间通信；通知人类 |\n| T2 | 受信任 | 在策略范围内自动处理；人类接收摘要 |\n| T3 | 已授权 | 在声明范围内的完全代理权限；仅审计日志 |\n\n这种分层设计让组织可以根据业务敏感度和信任关系灵活配置代理权限。\n\n## 协议扩展方式\n\nAEP的设计原则是"增强而非替换"，通过扩展现有协议实现向后兼容：\n\n### 邮件扩展\n\n通过新增X-AEP-*头部实现：\n\n```\nX-AEP-Version: 0.1\nX-AEP-Agent-ID: agent@company.com\nX-AEP-Scope: booking:read,booking:modify\nX-AEP-Intent: BOOKING_INQUIRY\nX-AEP-Trust-Tier: T2\nX-AEP-Policy-Ref: https://company.com/.well-known/aep-manifest.json\nX-AEP-Signature: \n```\n\nAEP感知的服务器会检测这些头部，获取发送方能力清单，检查声明范围是否符合自身策略，然后决定路由到接收代理还是升级到人工。非AEP服务器会忽略这些头部，标准邮件投递不受影响。\n\n### 日历扩展\n\n通过iCal的X-AEP-*属性扩展：\n\n```\nX-AEP-REQUESTOR-AGENT: agent-id@company.com\nX-AEP-INTENT: MEETING_REQUEST\nX-AEP-POLICY-REF: https://company.com/.well-known/aep-manifest.json\nX-AEP-AUTO-APPROVE: TRUE\n```\n\n接收方日历会检查其调度策略：请求者是否可信？时间是否在允许窗口？是否冲突？是否超出会议预算？如果全部通过且声明自动批准，则自动接受并通知人类。\n\n### 消息扩展\n\n通过结构化JSON元数据块实现：\n\n```json\n{\n \"aep_version\": \"0.1\",\n \"agent_id\": \"agent@company.com\",\n \"scope\": [\"booking:read\"],\n \"intent\": \"STATUS_UPDATE\",\n \"trust_tier\": \"T2\",\n \"policy_ref\": \"https://company.com/.well-known/aep-manifest.json\",\n \"requires_human_action\": false\n}\n```\n\n## 安全与审计机制\n\nAEP在安全设计上采取了多层防护：\n\n**数字签名**：所有AEP信封使用Ed25519签名，发送方公钥发布在能力清单中，接收方在处理前验证签名。\n\n**审计日志**：每个代理动作记录信封哈希、时间戳、执行动作、调用的策略规则、人工审批引用（如需要）。\n\n**权限委托链**：代理只能委托其自身拥有的权限，委托链端到端可验证。\n\n**即时撤销**：任何人类可随时撤销T2/T3代理的信任层级，撤销在清单刷新窗口（默认1小时）内传播到所有相关方。\n\n## 人工升级机制\n\n当代理遇到策略范围外的请求时，不会静默失败或返回错误，而是将请求打包（含完整上下文）路由给适当的人类，附带结构化决策请求。人类批准或拒绝后，结果返回给发起代理，整个交换被记录。这种设计确保代理在不确定时主动寻求人类指导，而非擅自决策。\n\n## 与相关标准的关系\n\nAEP在设计时考虑了与现有标准的互补性：\n\n- **MCP（Model Context Protocol）**：AEP在MCP之上运作，MCP处理工具调用，AEP处理跨组织消息路由和策略\n- **A2A（Google Agent-to-Agent）**：A2A关注API级代理调用，AEP关注升级现有人类通信界面，两者互补\n- **OAuth 2.0**：AEP的能力清单借鉴了OAuth的作用域概念，但AEP是通信策略协议而非认证协议\n- **DKIM/SPF**：AEP签名类似于邮件认证的DKIM，但增加了语义层\n\n## 应用场景与价值\n\nAEP对于以下场景具有重要价值：\n\n- **跨企业自动化**：供应商和客户的代理自动处理订单、发票、物流跟踪\n- **智能日程管理**：代理根据策略自动安排会议，无需人工逐封确认\n- **客户服务自动化**：代理处理客户咨询，在需要时无缝升级到人工\n- **合规审计**：完整的代理通信日志满足监管要求\n\n## 项目现状与展望\n\nAEP目前处于0.1.0草案阶段，采用CC BY 4.0许可证开放。项目包含完整的JSON Schema定义（信封、能力清单、调度策略、升级流程），为开发者实现AEP兼容系统提供了规范基础。\n\n作为Peter Myers发起的开放标准提案，AEP代表了业界对AI代理通信规范化的早期探索。随着AI代理在企业中的普及，类似AEP的协议可能会成为基础设施层面的关键组件，就像HTTPS之于Web、SMTP之于邮件一样。