Agentics：智能体身份是个真正棘手的难题
想赚个盆满钵满？那就去解决智能体身份问题吧。据我所知，目前还没人真正搞定这件事。这是一个巨大的难题，正在阻碍 AI 智能体（agent）在企业界和全球经济中的普及。
智能体身份要回答的其实是个很简单的问题：“这个智能体在代表谁行动？”你可以把它理解为归属和权限范围的结合。如果一个智能体提交了一个 PR（代码合并请求），这个 PR 算谁的？如果一个智能体接到一个任务，它能访问哪些资源？如果一个智能体捅了大篓子——比如幻觉出一份合同里的条款、泄露大量健康数据、或者试图接管世界——谁来担责、谁被开除、谁吃官司？
人类的身份认证，我们也只是刚刚勉强搞明白。现在大多数人可以通过 Google、Apple 等平台的单点登录（SSO），无缝登录各种第三方服务，而且通常能比较精确地控制你授予了哪些访问权限。
有意思的是，SSO 和 OAuth 的出现，恰恰是被 Meta 这类公司的劣迹倒逼出来的。大概 2007 年前后，Facebook 鼓励用户关联自己的邮箱和 Yahoo 账号等等。他们的做法是直接让用户交出用户名和密码，然后拿着这些凭证去抓取一切能抓到的东西。太阳底下无新事，死过的东西也从未真正消亡。今天，人们用 computer use 智能体的时候，干的就是同一件事——把用户名和密码交给智能体，让它去爬别的账号，看看能捞到什么！
显然，我们需要更好的智能体身份方案。但这个问题很难，因为大家并不清楚这个身份到底该怎么运作。
Nori 做的是云端智能体基础设施。我们和几十个团队在 AI 基础设施上合作过，也在客户身上花了很多时间思考身份问题。到目前为止，我们见过三种解决智能体身份的尝试，但它们都有各自的问题。
1. 给 Agent 一个单一身份，让它能访问所有东西
也就是“先跑起来再说”。这种做法基本上就是完全无视问题，直接给 Agent 开放所有权限。速度最重要，那就冲吧。
这在过去两年成立的创业公司和小团队里最常见。这些人没有大量现有收入依赖于某些安全认证，比如“我团队里的随便什么人都不能访问敏感数据”。通常，需要身份的工具会给 Agent 单独分配一个身份，比如它自己的 GitHub 访问令牌和它自己的邮箱地址。
好处是共享变得非常非常容易。坏处是任何 PR 都由这个机器人身份创建和拥有，所以其他任何人都可以“审查”这个 PR 并合并它。哎呀。
2. 按人继承身份
在这个模型中，Agent 以发起对话的人的身份行事。从某种意义上说这很好，因为非常容易推理。如果我（Amol）有生产数据访问权限，那么 Agent 就有生产数据访问权限。这也让审计和问责变得很简单。如果 Agent 做错了什么，那就是我做错了什么。
但问题也在这里。如果你把 Agent 当工具用，人在环路中紧密盯着，给 Agent 拴上短绳，这个模型运行得很好。但如果你想用云端的 Agent 跑定时任务、Webhook，或者只是想并行运行大量 Agent 让它们更自主地工作，这就完全行不通了。如果 Agent 干了蠢事我要担责，那我可不会让 Agent 放手去干！
另外，有时候我可能不想让 Agent 继承我的所有权限范围。我可能在做一些相当危险的事情，我希望模型处于只读模式，即使我个人有更大的权限。而且这种方案的操作体验也很痛苦——你得想办法把每个人的个人凭证都弄进系统里。
3. 给每个 Agent 一个独立身份
这种模式是：公司创建一批不同的 Agent 身份，每个身份绑定一组权限范围（scope），外加一份可用用户白名单。每个 Agent 相当于一名独立员工，通常由各个团队自己管理。比如客户成功团队可以有一个 Agent，只有销售和客户体验（CX）团队的人能跟它对话，它能访问 Salesforce，但不能访问 git。工程团队也可以有一个 Agent，只有 IT 和技术人员能跟它对话，它能访问 git，但不能访问 linear。
这套做法效果还不错，Nori 的默认方案就是这样，但它仍然只是折中。大型企业最后会搞出一大堆 Agent 身份，每个权限范围都略有差别。而且“归属权”仍然落在 Agent 身上，没有落到任何一组能承担责任的人身上。
现有的认证方案都有点问题，因为它们都假设“Agent”是一个前后一致的认证身份。可实际上并不是。你每次调用一个 Agent，想让它做的事可能完全不同。
真正的身份层应该放在会话这一层。你和 Claude 或 Codex 开的每一次对话，都应该决定这个 Agent 在这次对话里需要哪些权限。理想情况下，还应该留一条通道，让 Agent 在对话过程中可以申请更多权限。
我之所以特别关注这件事，是因为我们正在为 Nori 的云基础设施打造更顺畅的 Agent 身份体验。接下来我们会在这条线上投入更多精力。