LangSmith Fleet 的两种智能体授权模式

指南LangChain2026年3月23日3 分钟阅读
LangSmith Fleet 的两种智能体授权模式
LangSmith Fleet 推出两种智能体授权类型:Assistants 使用终端用户凭证,Claws 使用固定凭证。这解决了智能体在调用 Slack 等工具时,以谁的身份进行认证的问题。

上周我们发布了 LangSmith Fleet,这是一个用于构建、使用和管理智能体(Agent)的平台。发布中的一个关键部分是引入了两种不同的智能体授权(Agent Authorization)类型。

智能体授权指的是智能体被授权执行哪些操作。当智能体调用 Slack 工具时,它在拉取数据之前,是以谁的身份进行认证(Authenticate)的?

代表用户模式(On-behalf-of)

直到最近,大多数人认为智能体是以“代表用户”的方式运作的。

假设有一个入职代理(Onboarding Agent),它有权访问 Notion 和 Rippling。当 Alice 与它交互时,它应该能查看 Rippling 中关于 Alice 的信息,以及 Notion 中 Alice 有权访问的所有页面。Alice 不应该能用这个入职代理查看 Rippling 中 Bob 的任何私人信息,或看到 Bob 可能有的任何私人 Notion 页面。当 Bob 使用这个入职代理时,他应该能访问 Rippling 中他的所有信息和 Notion 中他的所有私人页面,但不能访问 Alice 的。

为了实现这一点,你需要几样东西:你需要知道谁在使用智能体——是 Alice 还是 Bob?然后你需要将这些用户 ID 映射到运行时传入工具的某些认证凭证(Auth Credentials)。

OpenClaw 的出现

在 OpenClaw 出现之前,“代表用户”是人们对智能体的主要思考方式。使用 OpenClaw,Alice 会创建一个智能体。也许只有她自己会使用这个智能体(在这种情况下,这种授权区别不太重要)。但也许她会通过不同的渠道(如短信、电子邮件或 Twitter)向其他人开放这个智能体。

当其他人与该智能体交互时,它不使用终端用户的凭证——它使用 Alice 赋予它的授权。

有时这可能是 Alice 自己的凭证,但这可能并不理想。如果智能体拥有 Alice 的凭证,它可以查看 Notion 中 Alice 有权访问的任何内容。这可能包括她可能不希望其他人通过智能体询问的私人文档。

这导致人们专门为智能体在 Notion、Rippling 等中创建专用账户,以便控制智能体有权访问的内容。每个与该智能体交互的人实际上都将使用同一组凭证。

LangSmith Fleet 的解决方案

在发布 LangSmith Fleet 时,我们看到人们需要这两种类型的智能体。有时他们想创建一个智能体,并让他人使用自己的凭证;其他时候,他们希望智能体拥有自己固定的凭证集。我们添加了两种不同类型的智能体,它们映射到这两种授权类型:

  • Assistants:以“代表用户”的方式运作
  • Claws:拥有自己固定的凭证

Agent identity

我们还引入了渠道(Channels)的概念(从 Slack、Gmail、Outlook 和 Teams 开始)以及智能体的共享。Assistants 和 Claws 支持不同的渠道。为了让 Assistants 能够共享,我们必须将渠道中的终端用户(例如他们的 Slack 用户 ID)映射到他们的 LangSmith ID。所以目前 Assistants 仅在我们支持这种映射的部分渠道中可用。

渠道和这些不同的授权类型也凸显了人机协同(Human-in-the-Loop)的必要性。如果你创建一个拥有固定凭证集的智能体,并通过渠道公开它,你就是在开放它以各种方式被使用。如果该智能体可以执行可能危险或敏感的操作,你可能需要使用一些“人机协同”的安全护栏(Guardrails)来确保这些操作受到控制。

实例说明

为了让这一点更具体,让我们看看我们创建的一些真实智能体及其授权类型。

入职代理(Onboarding Agent):Assistant。有权访问 Slack 和 Notion,并在 Slack 中公开。使用终端用户的 Slack 和 Notion 凭证。

邮件代理(Email Agent):Claw。该代理响应收到的电子邮件。无论谁发送邮件,该代理都会查看我的日历以确定会议可用性,并尝试代表我回复。发送电子邮件和日历邀请受人机协同安全护栏的控制。

产品代理(Product Agent):Claw。该代理监控竞争对手并帮助处理产品问题和路线图。它拥有自己的 Notion 账户,并通过自定义 Slack 机器人公开。

未来展望

我们很高兴在 LangSmith Fleet 中推出这两种不同的智能体类型。然而,我们认为这只是智能体授权的开始。阅读 WorkOS 的这篇博客,了解一些潜在的未来方向。

我们还期待跟进这项工作,实现更细粒度的内存权限(Memory Permissions)。根据智能体类型(Assistants 或 Claws),你可能希望以不同的方式处理内存。例如,你可能不希望一个助理记住关于 Alice 的敏感信息,并在与 Bob 的聊天中使用。目前,我们通过访问权限来管理这一点。当你共享一个智能体时,你选择其他用户是否可以编辑它,包括其内存。未来,我们将引入用户特定的内存。

立即试用 LangSmith Fleet

本文编译自 Two different types of agent authorization,版权归原作者所有。

觉得有用?分享给更多人

获取每周 AI 工具精选

工具推荐、实战教程和生态洞察,每周更新。

相关文章

pgEdge 推出开源 MCP Server for Postgres,支持 AI 智能体通过模型上下文协议(MCP)而非传统 API 方式访问数据库。服务强调数据源无关性、完整模式自省和 token 优化,适用于 Claude Code、Cursor 等主流 AI 开发工具。

指南The New Stack·4月2日·4 分钟

Google 推出 Flex 和 Priority 两个新的推理层级,帮助开发者平衡成本与可靠性。Flex 是成本优化层级,适合后台任务,价格便宜一半;Priority 是最高保障层级,适合用户交互型应用。两者都通过同步接口调用,简化了架构管理。

指南·4月2日·3 分钟

评论