核心要点
- Agent 授权的核心问题是：工具调用时，agent 到底以谁的身份认证。
- 一种模式是 on-behalf-of，使用最终用户自己的权限。
- 另一种模式是 fixed credentials，由 agent 持有固定身份或专门服务账号。
- 不同授权模式会影响共享方式、渠道支持和 HITL 安全策略。
原文链接 English Original — LangChain Blog, by LangChain Team
这篇文章讨论的是 agent 系统里一个非常基础、但经常被忽略的设计选择：agent 到底以谁的身份做事？ 当 agent 去调用 Slack、Notion、Rippling 之类的工具时，它认证成谁，决定了它能看见什么、能做什么，也决定了整个系统的安全边界。 作者把主流授权模式分成两类。第一类是 on-behalf-of：agent 代表当前终端用户行动。Alice 使用 agent 时，agent 只能访问 Alice 本人有权限看到的数据；Bob 来用时，也只能看到 Bob 自己的数据。这个模式最接近大家最熟悉的“个人助理”逻辑，但前提是系统必须知道当前是谁在使用 agent，并在运行时把这个人的身份映射到具体凭据。 第二类是 fixed credentials：agent 使用自己固定的一套凭据行动。文章用 OpenClaw 的场景来解释这一点：Alice 可以创建一个 agent，并通过 Slack、邮件或其他渠道让别人也能与它交互。但这个 agent 不一定要用终端用户自己的权限，更常见的是为它单独准备一个专用服务账号，让所有人都在这套受控权限边界内使用它。这样更利于控制 agent 能访问哪些系统和资料。 LangSmith Fleet 在产品上把这两类模式具象化为两种 agent：Assistants 使用终端用户自己的权限，Claws 则拥有自己的固定凭据。与此同时，文章也指出，授权模式会反过来影响渠道支持与分享机制。比如 on-behalf-of 需要在渠道里识别并映射最终用户身份，因此不是每个渠道都天然好做。 这篇文章的安全启发很强：一旦 agent 被共享到多个渠道，它就不再只是“会不会做事”的问题，而是“做事时到底拿谁的钥匙”。而当它持有固定凭据并具备敏感操作能力时，人类在环（HITL）就不是可选项，而是很自然的保护层。