ATH 专为渐进式采用而设计。服务和代理平台可以在三个级别上采用，每个级别都保留可信握手机制。

​
级别 1：网关模式（零服务变更）

Agent → ATH Gateway → OAuth Bridge → Service Provider
方面详情
应用侧授权ATH 网关根据其注册表检查代理
用户侧授权通过网关的 OAuth 桥接进行标准 OAuth
服务提供商工作量无
最适合立即部署、概念验证
OAuth 桥接是一种实现选择。实现方可以使用任何 OAuth 2.0 客户端库或多提供商集成平台。

​
级别 2：代理感知 OAuth（最小服务变更）

服务扩展其现有的 OAuth 客户端注册以包含 ATH 代理元数据： 
{
  "client_name": "TravelBot",
  "grant_types": ["authorization_code"],
  "ath_agent_id": "https://travel-agent.example.com/.well-known/agent.json",
  "ath_agent_type": "autonomous",
  "ath_capabilities_requested": ["mail:read"]
}
方面详情
应用侧授权服务通过现有开发者控制台 + 代理元数据审核代理
用户侧授权标准 OAuth，同意页面显示代理上下文
服务提供商工作量在客户端注册中添加 ath_* 字段，更新同意页面
最适合希望更严格控制代理访问的热门服务

​
级别 3：原生 ATH（完整实现）

服务直接实现 ATH 端点：
  • .well-known/ath-app.json 发现
  • 带有能力级别批准的代理注册
  • 范围交集执行
  • 显示可信握手状态的代理感知同意页面
同意页面：
┌─────────────────────────────────────────┐
│  TravelBot 想要访问你的邮件             │
│                                         │
│  ✅ 读取邮件                            │
│    （服务已为此代理批准）               │
│                                         │
│  ⚠️  发送邮件                           │
│    （未为此代理批准）                   │
│                                         │
│  [允许已选项]    [拒绝全部]             │
└─────────────────────────────────────────┘
方面详情
应用侧授权完整的按代理、按能力批准，支持范围交集
用户侧授权增强的同意页面，显示服务已批准哪些能力
服务提供商工作量完整的 ATH 实现
最适合主要平台的长期目标

​
选择你的级别

级别 1

从这里开始。部署网关，立即保护现有服务。

级别 2

当你希望服务端能够查看代理注册信息时升级。

级别 3

完整的原生支持，实现最高安全性和用户透明度。