Deep Agents

构建"公司级护栏"的五个组件

Harrison Chase、Caspar Broekhuizen，2026 年 10 月 24 日，6 分钟阅读。返回博客

如何构建公司级护栏？

我们在 LangChain 的市场、销售和工程团队内部构建了内部智能体，它们彻底改变了这些团队的工作方式。要把它们做对并不容易。我们花了大量时间解决多用户护栏（multiplayer harness）带来的问题，最终每个团队都归结到同一套核心基础能力：

它存在于人们原本就在工作的地方（对我们来说是 Slack）
它知道提问者是谁，并在某些服务上以该用户的身份（OBO，on-behalf-of）行事，在其他服务上则使用自己的身份
它拥有记忆，作用域可以是全局和/或用户级
代码在沙箱中运行，并且可以向需要认证的服务发起请求
很大一部分运行是由调度触发的，而不是由某个人显式调用（环境型智能体 ambient agents！！）

感谢@caspar_br对本文的帮助

LangChain 内部智能体

为便于讨论，先简要介绍我们在 LangChain 的三个主要智能体：

GTM Agent：一个主动、常驻的智能体，协助 GTM（go-to-market，市场进入）活动。它会监控并回复邮件、处理新的合格线索、发送每日简报、回答有关客户账户的问题，并能执行外呼动作。

OpenSWE：我们的工程智能体，可以处理并起草 PR，同时也会对所有 PR 运行代码审查。

Content Studio：我们的营销智能体，可以按我们的风格、结合我们对自身定位的了解起草素材（博客、图片、PowerPoint、视频）。

所有这些智能体都以相同方式构建。我们认为这是构建公司级护栏的通用配方。

问题：用户体验

我们所有智能体都存在于人们原本就在工作的地方，对我们来说就是 Slack。每个智能体都有自己的 Slack 应用，可以私信（DM）或在频道中 @ 它们。在频道中使用这些智能体的一个好处是，其他人可以看到人们是如何使用它的。

我们增加的一个不错特性是，在 Slack 中把对话"拆出"（breakout）的概念。通常，一段精彩的对话正在进行，你想把智能体加入进来征求它的意见或让它做点什么。但如果它在该线程中运行，就会污染人类对话并造成干扰。因此我们增加了一种简单的方式，让智能体"拆出"到频道中它们自己的线程里。

有些用户体验最好不要在 Slack 中完成。例如，在审阅 GTM Agent 想让我发送的邮件时，在 Slack 中一次性处理没问题，但如果积压很多，从 Slack 消息里逐条跟踪就完全不愉快了。对于这类体验，我们最终还是构建了自定义 UI。

问题：身份

我们处理过的最棘手、最微妙的问题就是身份，具体来说：当这些智能体采取行动时，它们代表谁行动？

业界主要有两种处理方式：

以用户身份代行（on-behalf-of）：智能体代表调用它的用户行事
固定凭证：无论谁调用，智能体都使用一组固定凭证（例如服务账号）

以下是我们针对每个智能体的处理方式（文档：为 Managed Deep Agents 添加身份、管理连接）：

OpenSWE：

当你给它发消息时，它代表你行事（例如会用你的 GitHub 账号名创建 PR）
当它在后台运行时（例如作为代码审查智能体），它使用自己的身份（GitHub 应用）行事

GTM Agent：

它有一些工具（例如 Salesforce 访问）使用固定身份，这样不必每个人都登录
它有一些工具（例如邮件）以调用智能体的用户身份行事。这些工具仅在私信中可用。在共享频道中不可用

Content Studio：

它有一些工具（例如 Notion）以调用智能体的用户身份行事
它有一些工具（例如 Twitter）使用固定凭证，在此例中是我们公司的 Twitter 账号。不过，只有白名单用户才能调用这里的某些操作。例如，并非每个人都能发推（他们可能只能读取/起草）

问题：记忆

所有智能体都有两级记忆：

全局记忆：适用于所有用户的记忆
用户记忆：仅适用于特定用户的记忆

智能体自行决定哪些事实要记到哪一级记忆中。

这可能是目前探索最少的一个领域——我们在这方面还有很多工作要做！

问题：代码执行

我们三个智能体都能编写并执行代码，而且为了完成任务经常需要这样做。它们都遵循相同的模式：在沙箱外运行，但连接到沙箱并在其中执行代码。它们的基础镜像略有不同，依赖也各不相同。OpenSWE（与编码关联最紧密的智能体）会智能地选择要启动哪个基础镜像（根据频道/用户不同）。它们都利用了 LangSmith Sandboxes 上的密钥代理（另见为 Managed Deep Agents 添加沙箱），让智能体能够在沙箱内部以安全可靠的方式连接各项服务。