北京
每10个AI代理项目，有7个在对接第三方服务时栽在权限设计上。这不是技术债，是架构债——而且越拖越贵。
传统SaaS用OAuth用了十几年，团队以为"登录即授权"是 solved problem（已解决问题）。但AI代理不是传统应用：它是动态的、多步骤的、有时自主运行的，而且卡在用户、第三方服务、其他应用三者之间。这层关系彻底改写了权限模型的形状。
设计不当，只有两个结局：要么用户被权限请求轰炸到麻木，全部点"允许"；要么平台为了安全过度收缩，代理什么都干不了。两种结果都是产品死亡。
第一层：身份层——你是谁
用户登录平台，比如Kaeso。这层只回答一个问题：你是谁，你能访问平台的哪些部分。
注意，这和"你能访问GitHub吗"完全无关。很多团队在这里就开始混淆，把平台身份和服务授权揉成一团，后面每一步都是补丁。
身份层只管平台内部的资源边界。用户能看到哪些项目、能创建哪些代理、能邀请哪些成员——这些在这里定。一旦涉及到Slack、Notion、Stripe，立刻移交下一层。
这层的设计陷阱是过度收集。有些平台为了"方便"，在注册时就问你要GitHub权限，理由是"以后可能用到"。用户还没看懂产品是干什么的，就已经在授权了。转化率暴跌不说，信任从第一步就崩了。
第二层：服务连接层——平台能替你敲门
用户主动连接GitHub、Slack、Google Drive。平台拿到各服务商的OAuth令牌，安全存储。
关键认知：此时用户只授权了平台"代为敲门"的能力，并没有授权平台里的某个具体应用使用这些服务。这是大多数人漏掉的分界点。
举个例子：你在Kaeso连了GitHub，意味着Kaeso可以代表你去GitHub办事。但Kaeso上的某个代码审查代理、某个自动提PR的插件、某个第三方集成——它们能不能用，是另一回事。
如果把这层和下一层合并，就会出现"连接即授权"的灾难。用户连了Slack，结果平台上20个应用都能发消息，每个都声称"你已经授权过了"。撤销权限时更崩溃：用户想关掉某个烦人的机器人，发现只能断开整个Slack连接，其他正常应用一起陪葬。
这层的设计要点是：令牌存储要隔离，元数据要丰富。平台要知道这个GitHub连接有哪些scope（权限范围），是只读还是读写，是个人账户还是组织账户。这些信息在第三层做决策时至关重要。
第三层：应用授权层——具体谁能干什么
现在Kaeso上的某个应用、代理或集成请求访问特定能力。它不应该直接拿到原始的GitHub令牌，而是向平台申请平台级的权限。
平台检查：用户有没有连过GitHub？scope够不够？如果够，用户只需批准"这个应用可以用你的GitHub"；如果不够，平台引导用户先补全连接，再谈授权。
这层是AI代理场景最复杂的战场。传统应用通常是静态的：一个GitHub客户端要的就是那些权限，一次授权管一辈子。但代理是动态的：
一个"自动修复Bug"的代理，今天可能只需要读代码，明天发现Bug后要提PR，后天可能要触发CI。权限需求在变，但用户不可能每一步都在线点"允许"。
Kaeso的做法是把权限声明前置。应用上架时就要声明它可能需要的全部能力，用户一次性看清"这个代理最坏情况下能做什么"。运行时如果超出声明范围，直接拒绝，而不是临时弹窗。
这牺牲了一定的灵活性，换来了可预测性。用户知道边界在哪里，平台知道审计日志该记什么，开发者也知道哪些操作会被拦截。
为什么三层比一层好
单层的权限系统面对AI代理会迅速腐烂。用户连接了10个服务，平台上有50个应用，每个应用都想组合这些服务做自动化——权限矩阵爆炸到没人能看懂。
三层模型把复杂度切开：身份层管平台内部，服务层管"有没有钥匙"，应用层管"谁能用哪把钥匙开哪扇门"。每层只做一件事，每层都可以独立审计、独立撤销。
一个具体场景：用户想撤销某个恶意应用的权限。在单层模型里，你可能要翻遍所有服务连接去找它用了哪些令牌。在三层模型里，直接在应用层禁用，平台自动切断它的所有访问路径，其他应用不受影响。
另一个场景：用户换工作了，GitHub从个人账户切换到组织账户。服务层更新令牌，应用层完全无感知——它们只跟平台打交道，不关心GitHub那边是谁的账号。
AI代理的OAuth设计，本质上是在做权限的"分层解耦"。不是让用户少点几次"允许"，而是让每一次授权都有明确的语义和可撤销的边界。
目前大部分Agent平台还在用传统SaaS的OAuth方案凑合。结果是：要么权限粒度粗到可怕，一个代理能读你所有邮件；要么细到每个API调用都要用户确认，代理变成交互式玩具。
三层模型不是唯一答案，但它提供了一个可验证的框架：你的系统能不能清晰回答"谁在什么场景下以什么身份访问了什么资源"？如果回答这个问题需要查三个数据库、问两个工程师，权限设计就已经病了。
Kaeso的早期用户里，有个团队之前自建代理系统，权限逻辑散落在7个微服务里。迁移到三层模型后，他们的安全审计从两周缩短到两小时。不是代码变少了，是责任边界变清了。
OAuth for AI agents的核心洞察是：代理不是用户在操作，是代理在代理用户操作。这层间接性让传统的"用户授权应用"模型不够用，需要在平台和应用之间再加一层中介。
做这层设计时，有个检验标准：假设你的平台明天被攻破，攻击者能做什么？如果答案是"拿到所有用户的所有服务令牌"，你的分层就失败了。正确的答案是："只能做到平台层能做的事，应用层的权限需要额外的用户批准才能激活。"
AI代理的权限设计还在早期。今天选错架构，明年重构的成本可能是现在的十倍。三层模型至少保证你在正确的方向上欠债。
你的代理系统现在是怎么处理跨服务授权的？是让用户一次点完所有权限，还是每次调用都确认——或者，你已经找到了第三种方式？
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
