ATH协议（Agent Trust Handshake Protocol）由中国信通院联合腾讯、华为等发布，针对MCP、A2A等现有方案的权限漏洞，引入用户+智能体+服务三方握手与权限交集机制，解决20万台服务器暴露等安全问题。适合AI Agent开发者、企业架构师了解其设计原则、9步握手流程及Python Demo。协议已开源，支持网关与原生双部署模式。
Tags:
因为在生产中，它得能接上你的 ERP、SAP、在线文档才能干活，但接入的那一刻，数据就可能失控。
原因很简单，当下的 Agent 的权限编排，完全跟不上产品本身的精细化设计。
举个简单的例子，过去一段时间，几乎所有的小龙虾产品，都会深度接入飞书、钉钉。
在此过程中，用户的需求可能只是让 AI 做好全网内容搜索之后，将结果推送到飞书。
但一些小龙虾，会默认需要我们打开组织门禁记录、联系人列表，甚至是修改邮箱密码大量非必要高级权限。
这些至少还是用户看得懂的权限设计，看不懂的往往更危险。
2025 年 12 月豆包手机开启系统级权限 INJECT_EVENTS 的消息一出，两天之内，就接连被微信封杀、银行弹窗预警。
2026 年 4 月 OX Security 确认 MCP 协议，更是影响 3.2 万个仓库、让 20 万台服务器暴露。
所以相当长一段时间里，各种 Agent 产品，为了让用户能够更安全的用好 AI 可谓是操碎了心。
比如，阿里云 JVS Claw 会让 AI 的所有操作都发生在阿里云的独立云端容器 ClawSpace，用数据隔离、传输加密、落盘加密、权限最小化来保护本地数据安全。
荣耀的 YOYO Claw，则在拦截高危操作、敏感操作 PIN 码确认之外，干脆让核心数据与隐私默认本地处理，不让会议录音、个人文档、聊天记录上传云端。
总而言之，在当下阶段，行业已经形成共识：安全问题的症结不在于能不能让 Agent 连上数据，而是如何连、连上之后又该由谁来管住它。
除了玩家的探索之外，一些新的行业标准也在逐渐成型。
最近看到一个蛮值得关注的新技术，2026 年 5 月，中国信通院联合腾讯、华为、中兴、三大运营商和港中深发布了 ATH 协议。
GitHub：https://github.com/ath-protocol/agent-trust-handshake-protocol
它的核心思路是：把用户拉回谈判桌，用户+ Agent + 服务三方握手，权限取交集，缺一票不通过。
接下来，本文将拆解三件事：为什么权限设计是Agent 商用的前提、现有方案各卡在哪、ATH 的三方握手机制怎么转。
1）为什么精细的权限设计是 Agent 商用的前提
在讲权限设计问题之前，我们需要知道Agent 和传统软件的根本区别。
传统软件的行为是确定性的，用户点击按钮 A 就执行操作 A。但 Agent 的行为由 LLM 动态决策，是概率性的。同一个 Agent 面对同一个用户请求，可能走完全不同的执行路径。
这意味着：你授出去的权限，不一定按你预期的方式被使用。
2025 年 12 月豆包手机助手事件就把这个问题暴露得非常彻底。它拿到了安卓系统级权限 INJECT_EVENTS，能模拟点击、读取屏幕，理论上可以操作手机上的任何 App。
所以上线后不到两天，微信触发风控封禁账号，农行、建行等银行客户端弹窗提醒用户存在风险。尽管 12 月 10 日，阿里系部分应用陆续解除限制，但条件是豆包助手关闭部分操作权限。
这件事在行业里引发了三个层面的讨论：
技术层面：授权即失控，用户授权后，完全无法感知 AI 的完整操作链路；
商业层面：AI 把超级应用变成了纯粹的履约管道，动摇了平台依赖流量和广告的商业模式；
法律层面：AI 自动执行任务时出现误操作，用户、AI 提供方、应用平台三方责任难以界定。
这种不确定性在消费级场景还能容忍，但在企业级场景就是灾难。
举个例子：一个 HR 专员有两个权限：查看考勤、查看薪酬。在传统系统里，这两个操作互不干扰。
但如果 Agent 同时拿到这两个权限，它完全可以自动关联分析，输出一份完整的员工薪资与出勤对照表，这种权限组合后的涌现能力，传统 RBAC 权限模型根本管不住。
单个权限无害，组合起来就可能越界。这才是 Agent 权限问题的本质难点。
而从历史看，权限治理的问题不是 Agent 时代才有的。合理的权限设计本身，几乎是所有软件类产品走向大规模商用的基础。
每一代技术平台都经历过类似的阵痛，而每一次权限体系的成熟，都是该技术走向大规模商用的转折点。
在 App 生态，iOS 和 Android 早期的权限模型非常粗糙。一个手电筒 App 就能读取通讯录和位置信息。
后来 iOS 6 引入精细化的运行时权限授权，Android也随之逐步收紧后台权限和敏感权限管控。整个行业花了约 5 年时间，才形成按需授权、可随时撤回的成熟模式。
这个模式成熟之后，App 生态才真正爆发。但也从此给大家留下了安卓系统不安全、广告多，难以真正高端化的固有认知。
数据库领域更有借鉴意义，行业早期只有粗粒度的表级权限，后来 Oracle、PostgreSQL 逐步引入行级安全策略（Row-Level Security）、列级掩码（Column Masking），以及基于属性的访问控制（ABAC）。
权限粒度从表直接精确到了单元格。但也只有这样，企业才敢把核心业务数据库开放给更多角色使用。
现在 Agent 面临的挑战更上一层楼：权限粒度太粗，组合后出现预期外的能力，而且它还引入了 LLM 的非确定性决策、外部提示词攻击的变量。
2）MCP、A2A、CLI/GUI：为什么现有方案都不够
在 ATH 之前，行业里有几条主流的 Agent 交互路径。它们各自解决了一部分问题，但在权限安全上，也都有绕不开的短板。
2.1 MCP：AI 领域的 USB-C 接口，但安全根基不稳
MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月推出的协议，定位是 AI 模型与外部工具/数据源的标准化接口：一个统一接口把 M×N 的集成复杂度降到 M+N。技术上采用客户端-服务器模型，基于 JSON-RPC 2.0。
但 MCP 的安全设计，有天然的架构级的缺陷。
Context Poisoning（上下文投毒） 是最典型的问题。MCP 把所有工具描述原样注入 Agent 的上下文窗口，每接入一个 MCP 服务器，就多一个攻击面。OWASP 已将Prompt Injection 列为 LLM 应用的头号安全风险（LLM01）。
实际攻击案例也不缺。安全研究机构 Invariant Labs 披露了一种工具投毒攻击方式：攻击者先部署一个无害的 MCP 工具获取用户信任，后续悄悄替换工具描述，注入恶意指令。用户界面上看不到任何异常，数据已经在后台被静默外传。
我们可以从漏洞数据看问题的严重性：
2026 年 4 月 OX Security 报告：MCP 生态影响超过 3.2 万个代码仓库，Shodan 上可确认 7,374 台公开脆弱服务器，估算暴露总量超过 20 万台
CVE-2025-49596：MCP Inspector 缺乏客户端与代理之间的身份验证，导致远程代码执行，CVSS 9.4 Critical
CVE-2025-6514：mcp-remote 连接不可信 MCP 服务器时，通过构造的 authorization_endpoint 响应 URL 实现 OS 命令注入，CVSS 9.6
一系列问题背后，在于 MCP 只定义了模型到工具的通信，没有引入用户和服务端作为独立的授权参与方。 权限要么全给，要么不给，几乎没有中间态。
2.2 A2A：Agent 间的通信协议，但信任鸿沟依然没能解决
A2A（Agent-to-Agent Protocol）是 Google 在 2025 年 4 月推出的协议，定位是不同 AI 智能体之间的标准化通信。
A2A 的核心通信单元是 Task（任务），通过 Agent Card 声明能力，基于 HTTP + SSE + JSON-RPC 2.0 实现实时交互。设计原则里明确写了默认安全（Secure by default），支持 OAuth 2.0 企业级认证。
但默认安全和真的安全之间有一段距离。
A2A 的安全强度高度依赖各Agent 实现方的执行质量。Agent Card 只声明我能做什么，但无法验证身份可信度，它没法证明我真的是我说的这个 Agent，更解决不了原有 Agent 本身可能存在的漏洞。
Google 自己也意识到了这个问题，已规划在可信代理身份、委派代理权限等方面补充标准，但具体方案尚未公开。
归根到底，A2A 也只定义了 Agent 到 Agent 的通信，用户没有被纳入信任链路。
2.3 CLI 和 GUI 自动化：暴力路径的代价
很多企业 Agent 落地时，面对老旧的 ERP/SAP 系统会发现根本没有API 可用，只能走CLI 命令行或 GUI 自动化（模拟用户操作）。
其中GUI的风险最大，常见的有三类问题：
权限过度：GUI 自动化通常需要系统级权限，远超任务实际需求
操作不可审计：模拟出来的点击和用户真实操作无法区分，审计追踪几乎不可能
数据边界模糊：屏幕截图过程中，密码、PIN 码、其他应用的通知内容都可能被捕获，Agent 实际看到的数据远超它需要的
CLI的可控性比较高，但解决不了LLM决策链路本身不可控的问题。
2.4 四种方案的共同问题
把四种方案放在一起看，我们会发现其实所有问题都出在同一个地方：虽然 Agent 数据交互方案有协议，但协议层和执行层之间存在断裂。
MCP 标准化了 Agent/LLM 应用访问工具和数据源的方式，A2A 标准化了 Agent 之间的发现、协商和任务协作，但二者主要解决连接与互操作，并没有把用户意图、数据权限、动作授权和审计追踪变成端到端强约束。
GUI、CLI 这类入口很多时候依赖应用或系统权限本身；一旦缺少 sandbox、最小权限、显式审批和可审计记录，Agent 拿到的数据访问能力，就可能引发不小数据安全隐患。
这就是 ATH 试图从协议层面解决的问题。
3）ATH 的运作机制：三方可信握手
ATH 的核心创新用一句话概括：引入用户作为独立的第三方参与方，搭建用户 + 智能体 + 服务的三方协同架构。
在 MCP 和 A2A 的二元架构里，用户授权是隐式的、一次性的。ATH 把用户变成了协议的一等公民，所有交互必须用户知情并授权。
同时也引入了服务方的决策意见，否则对用户来说一个权限名字叫读取联系人，我们可能还知道是否能开放权限，但如果是 INJECT_EVENTS 这样的最高权限，反而很多人会一头雾水，这就需要引入服务方帮助用户完成基础判别。
3.1 ATH 的六大设计原则如下：
| 原则 | 含义 |
|---|---|
| 用户主权 | 用户对数据拥有最高控制权，任何交互须用户知情并授权 |
| 三方参与 | 用户、智能体、服务三方协同参与握手过程 |
| 可信握手 | 智能体访问资源必须同时获得用户和服务的双重授权，缺一不可 |
| 去中心化 | 不依赖单一中心化信任节点，身份验证基于非对称加密 |
| 最小权限 | 仅授予完成任务所需的最小权限集，到期自动失效 |
| 全程可追溯 | 所有交互行为加密存证，可审计、可追溯、不可篡改 |
它的核心是一个 9 步握手流程，分为前置步骤和三个阶段：
前置步骤：用户预授权
在智能体开始工作之前，用户先签署一份授权凭证，明确智能体可以代表自己行事的范围。这份凭证包含授权的资源范围、有效期和操作限制，用户可以随时吊销。
第一阶段：双向身份验证（步骤 1-4）
智能体向服务端发起握手请求，携带自己的 DID（去中心化身份标识）、公钥、能力清单和一个随机数A。服务端验证后返回自己的身份信息，加上对随机数 A 的签名和自己的随机数 B。智能体验证服务端身份后，对随机数 B 签名发回。服务端验证通过，身份双向确认完成。
这个阶段的核心是双向验证：不仅服务端要验证智能体的身份，智能体也要验证服务端的身份。防止中间人攻击和身份伪造。
第二阶段：可信握手协商（步骤 5-8）
智能体向服务端请求具体的访问权限，同时提交用户预授权凭证。关键来了：服务端收到请求后，不会直接审批，而是向用户发起二次确认。用户可以选择同意、拒绝或修改授权范围。确认结果由用户签名。
这一步直接解决了前面提到的「用户认知盲区」问题：ATH 不是让用户在安装时一次性勾选一个长长的权限列表。
而是在具体使用场景下弹出明确的确认：“这个 Agent 现在要读取你的邮件，你同意吗？”用户在具体上下文中做出的判断，远比安装时的"全部同意"更有意义。
然后服务端结合用户授权结果和自身安全策略，计算最终的权限审批结果。
第三阶段：会话建立（步骤 9）
双方完成密钥协商，服务端颁发短期访问令牌，正式建立加密通信通道。
3.2 Scope Intersection：三方权限交集
这是 ATH 在权限安全上最关键的创新。计算公式：
Effective Scope = Agent Approved Scopes ∩ User Consented Scopes ∩ Requested Scopes最终有效权限 = 服务方审批权限 ∩ 用户授权权限 ∩ 智能体请求权限，取三方交集。
举个来自 ATH 文档的具体例子：
Agent approved:mail:read, mail:sendUser consented: mail:read, mail:send, mail:deleteAgent requested: mail:read────────────────────────────────────────────────Effective scope: mail:read
用户虽然同意了
mail:delete，但服务方从没批准这个智能体有删除权限 → 拿不到智能体虽然被批准了
mail:send，但它这次只请求了mail:read→ 也只能拿到mail:read
权限交集为空时，禁止颁发令牌。 这条规则直接写进了 ATH 的安全规范。
回到前面 HR 专员的例子：如果服务方只批准了 Agent 查看考勤的权限，即使用户不小心勾选了「同意查看薪酬」，最终交集里也不会包含薪酬权限。三道关卡，任何一道拦住，权限就不会通过。
3.3 与 OAuth 2.0 的关系
ATH 源码文档里说得很清楚：
OAuth 2.0 回答一个问题：用户是否同意？ ATH 在此基础上增加第二个必答问题：服务方是否批准该智能体？
ATH 建立在 OAuth 2.0 之上，而非替代它。用户侧授权使用标准 OAuth 流程，ATH 增加了智能体身份层和应用侧授权。
所有OAuth 授权请求强制使用 PKCE（RFC 7636）S256 挑战方法，访问令牌绑定到 (agent_id, user_id, provider_id, scopes) 四元组。
换句话说：如果你现有系统已经用了 OAuth 2.0，ATH 是增量升级，不是推倒重来。
3.4 双部署模式
ATH 支持两种部署模式：
| 模式 | 架构 | 适用场景 |
|---|---|---|
| 网关模式 | 智能体 → ATH Gateway → 后端服务 | 不修改原有代码，适合企业级多服务统一管控 |
| 原生模式 | 智能体直连 ATH 原生服务 | 性能更高、延迟更低，适合高性能或嵌入式场景 |
网关模式下，Gateway 包含三大组件：Agent Registry（身份验证和能力策略）、Authorization Engine（权限交集计算和审计日志）、OAuth Bridge（OAuth 流程委托和令牌管理）。
4）跑一遍 Demo：看看代码层面长什么样
ATH 协议仓库里提供了一个完整的 Python Demo（demo/ath_simple_demo_zh.py），零外部依赖，只需Python 标准库就能跑。
4.1 核心设计
Demo 定义了两个完全解耦的类：
Client：模拟 AI 购物助手客户端，负责身份管理、握手请求、权限申请
Server：模拟电商平台服务端，负责身份验证、授权确认、令牌颁发
两个类之间只通过 JSON 报文格式交互，和真实网络通信完全一致。
4.2 9 步握手全流程代码解析
用户预授权（Step 0）
ATH 有一个区别于传统授权方案的关键设计：智能体在发起握手之前，必须先获得用户的明确授权。get_user_authorization 方法做的就是这件事：
def get_user_authorization(self, scopes: list) -> bool:"""获取用户预授权"""whileTrue:choice = input("\n🤔 是否同意授权？(Y/N): ").strip().upper()if choice == 'Y':self.user_authorization = {"user_id": "user_001","scopes": scopes,"signature": "user_signature_" + ''.join(random.choices(string.hexdigits, k=16)),"expires_at": int(time.time()) + 7200}returnTrueelif choice == 'N':returnFalse
用户同意后，客户端生成一份授权凭证，包含 user_id、授权的 scopes、用户签名和过期时间。
注意过期时间设为 7200 秒（2 小时）——这是 ATH 最小权限原则的体现，授权凭证不是永久有效的。用户拒绝则直接返回 False，整个流程终止。
第一阶段：双向身份验证（Step 1-4）
先看客户端和服务端的初始化：
class Client:"""客户端：AI购物助手"""def __init__(self):self.did = "did:ath:ai_shopping_assistant_001"self.private_key = "client_private_key_123456"self.public_key = "client_public_key_abcdef"self.user_authorization = Noneself.access_token = Noneself.server_public_key = Noneclass Server:"""服务端：电商平台"""def __init__(self):self.did = "did:ath:ecommerce_platform_001"self.private_key = "server_private_key_654321"self.public_key = "server_public_key_fedcba"self.client_nonce = Noneself.client_did = Noneself.client_public_key = None
每个参与者都有基于 DID 标准的唯一标识和一对公私钥。Demo 中使用的是简化的 did:ath:xxx 格式，而 ATH 正式身份规范（specification/0.1/client/identity.mdx）中，生产环境的 Agent ID 是 URI 格式，如 https://travel-agent.example.com/.well-known/agent.json，需要在该 URI 发布包含公钥的 JSON 身份文档供对端验证。
Step 1：客户端发送握手请求
def step1_send_handshake_request(self) -> Dict[str, Any]:"""步骤1：发送握手请求"""nonce = ''.join(random.choices(string.ascii_letters + string.digits, k=16))request = {"type": "handshake_request","client_did": self.did,"client_pubkey": self.public_key,"nonce": nonce,"timestamp": int(time.time())}return request
报文包含 DID、公钥、随机数（nonce）和时间戳。随机数用于防止重放攻击，每次请求生成不同的 nonce，服务端可以检测到重复请求。
Step 2：服务端返回握手响应
def step2_send_handshake_response(self, client_request: Dict[str, Any]) -> Dict[str, Any]:"""步骤2：返回握手响应"""self.client_did = client_request["client_did"]self.client_public_key = client_request["client_pubkey"]self.client_nonce = client_request["nonce"]server_nonce = ''.join(random.choices(string.ascii_letters + string.digits, k=16))signature = "sig_" + ''.join(random.choices(string.hexdigits, k=32))response = {"type": "handshake_response","server_did": self.did,"server_pubkey": self.public_key,"nonce": server_nonce,"signature": signature,"timestamp": int(time.time())}return response
服务端收到请求后做三件事：记录客户端身份信息、生成自己的随机数、用私钥对客户端随机数签名。
响应报文携带服务端 DID、公钥、服务端随机数和签名。客户端可以用服务端公钥验证签名，确认服务端身份。
Step 3：客户端发送身份证明
def step3_send_identity_proof(self, server_response: Dict[str, Any]) -> Dict[str, Any]:"""步骤3：发送身份证明"""self.server_public_key = server_response["server_pubkey"]server_nonce = server_response["nonce"]signature = "sig_" + ''.join(random.choices(string.hexdigits, k=32))proof = {"type": "identity_proof","signature": signature,"timestamp": int(time.time())}return proof
客户端保存服务端公钥（后续验证用），取出服务端随机数，用自己的私钥签名后发回。
这就是双向身份验证的关键一步，Step 2 服务端用签名证明了自己，现在客户端也要用签名证明自己。任何一方签名验证失败，流程都会终止。
Step 4：服务端返回验证结果
def step4_send_identity_result(self, identity_proof: Dict[str, Any]) -> Dict[str, Any]:"""步骤4：返回身份验证结果"""# 模拟验证成功is_valid = Trueif is_valid:result = {"type": "identity_result","success": True,"scopes_supported": ["goods:read", "order:create", "user:profile"],"token_max_ttl": 7200,"timestamp": int(time.time())}else:result = {"type": "identity_result", "success": False, "error": "Invalid signature"}return result
验证通过时，除了 success: True，还附带服务端支持的权限列表和令牌最大有效期——这是为下一阶段的权限协商做准备。
注意 scopes_supported 有三项，但后面实际授予的可能更少，这就是 Scope Intersection 的来源。验证失败时直接返回 success: False 和错误原因。
第二阶段：可信握手协商（Step 5-8）
身份双向验证通过后，进入权限协商阶段。
Step 5：客户端发送权限请求
def step5_send_scope_request(self) -> Dict[str, Any]:"""步骤5：发送权限请求"""request = {"type": "scope_request","scopes": self.user_authorization["scopes"],"user_authorization": self.user_authorization,"context": "用户需要查询商品并下单","timestamp": int(time.time())}return request
注意 user_authorization 字段，这是 Step 0 用户预授权时签署的凭证，客户端把它原封不动地交给服务端，作为「用户确实授权了」的证明。context 字段描述业务场景，帮助服务端做授权决策。
Step 6-7：服务端向用户二次确认
这是 ATH 区别于 OAuth 等传统方案的核心创新。服务端收到权限请求后，不直接审批，而是再次向用户确认：
def step6_request_user_confirmation(self, scope_request: Dict[str, Any]) -> bool:"""步骤6：向用户确认授权"""client_info = "AI购物助手"scopes = scope_request["scopes"]while True:choice = input("\n🤔 是否同意该授权请求？(Y/N): ").strip().upper()if choice == 'Y':return Trueelif choice == 'N':return False
对比 Step 0 的预授权和这里的二次确认：Step 0 是用户告诉智能体「你可以代表我做这些事」，Step 6-7 是服务端告诉用户「这个智能体要用你的名义访问我的服务，你确认吗？」。
两次确认确保了用户授权的真实性，也防止了智能体篡改授权范围。
在协议规范中，Step 6（服务端向用户发送确认请求）和 Step 7（用户返回确认结果）是两个独立步骤。Demo 中通过 input() 将两步合并到一个方法里。
Step 8：服务端返回审批结果
def step8_send_scope_result(self, user_approved: bool) -> Dict[str, Any]:"""步骤8：返回权限审批结果"""if user_approved:result = {"type": "scope_result","scopes_granted": ["goods:read", "order:create"],"ttl_granted": 7200,"restrictions": {"rate_limit": "100/minute","ip_whitelist": ["192.168.1.0/24"]},"timestamp": int(time.time())}else:result = {"type": "scope_result", "success": False, "error": "User rejected"}return result
用户同意时，返回实际授予的权限、有效期和附加限制。注意 scopes_granted 只有 ["goods:read", "order:create"]，而 Step 4 中 scopes_supported 有三项，user:profile 没有被授予，体现了 Scope Intersection。
另外还附带了速率限制和 IP 白名单，这是服务端的附加安全策略。用户拒绝时直接返回失败，不会颁发任何令牌。
第三阶段：会话建立（Step 9）
Step 9：握手完成，颁发令牌
服务端颁发访问令牌：
def step9_issue_access_token(self) -> str:"""步骤9：颁发访问令牌"""token = 'ath_' + ''.join(random.choices(string.ascii_letters + string.digits, k=40))return token
客户端保存令牌：
def step9_complete_handshake(self, access_token: str):"""步骤9：完成握手"""self.access_token = access_token
令牌以 ath_ 前缀标识，包含 40 位随机字符。客户端保存后，后续所有业务请求都携带这个令牌。握手完成，可信通信通道正式建立。
流程清晰：先预授权，再 9 步握手，最后用access_token 发业务请求。3 处快速失败检查确保安全问题不会向后传递，任何一个环节失败都立即终止。
4.3 跑起来
git clone https://github.com/ath-protocol/agent-trust-handshake-protocol.gitcd agent-trust-handshake-protocolpython3 demo/ath_simple_demo_zh.py
Demo 是交互式的，有两个手动确认环节（用户预授权和服务端向用户确认），控制台会提示输入 Y/N。跑一遍大概2 分钟，能直观感受整个握手流程。
写在最后
回到开头的问题：Agent 大规模商用，权限安全是绕不过去的坎。
从软件行业的历史看，每一次平台级技术爆发，都伴随权限治理体系的升级。
App 生态催生了运行时权限模型，数据库普及推动了行级安全策略。这些权限体系不是事后补丁，而是大规模商用的前提条件。
Agent 时代同样需要一个适配其特点的权限框架。
MCP 解决了工具接入的标准化问题，A2A 解决了 Agent 间协作的标准化问题，但它们都没有把用户作为独立的授权方纳入协议设计。
ATH 的三方参与架构和Scope Intersection 机制，在协议层面补上了这块短板。
坦白说，ATH 作为 2026 年 5 月刚发布的协议，目前还没有企业实际部署的公开案例。
它的生态组件（协议标准、Python SDK、TypeScript SDK、核心引擎、网关服务）也还在早期阶段。
但协议的设计思路，特别是三方权限交集、去中心化身份验证、强制 PKCE，确实回应了当前Agent 权限治理的核心痛点。
一个更值得思考的问题是：如果 ATH 这样的三方模型被广泛采用，现有的 Agent 开发流程会发生什么变化？
开发者需要在设计阶段就规划好「我的 Agent 到底需要哪些最小权限」，而不是先拿到最大权限再说。这本身就是一种更健康的工程实践。
如果你正在做 Agent 产品的架构设计，建议把ATH 的规范文档过一遍。技术方案选型时多一个参照系，总没坏处。
GitHub 项目地址：https://github.com/ath-protocol/agent-trust-handshake-protocol
今天的分享到此结束，感谢大家抽空阅读，我们下期再见，Respect！
没有评论:
发表评论