如何构建公司级 harness？

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

  • ‍它存在于人们已经在工作的地方（对我们来说是 Slack）
  • 它知道是谁在提问，并对某些服务以该用户的身份（OBO）行事，对其他服务则以自己的身份行事
  • 它有记忆，作用域可以是全局和/或用户级别
  • 代码在沙箱中运行，并且可以向需要认证的服务发起请求
  • 其运行中有很大比例是定时触发的，而不是由某人显式调用（环境智能体！！）

感谢@caspar_br对这篇博客的帮助

LangChain 内部智能体

为给讨论提供背景，先简要概述我们在 LangChain 的三个主要智能体：

GTM Agent：一个主动、始终在线的智能体，协助 GTM 活动。监控并回复邮件、处理新的合格线索、发送每日简报、回答关于客户账户的问题、执行外呼动作

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

Content Studio：我们的营销智能体，可以按照我们的风格并基于对我们定位的了解来起草素材（博客、图片、PowerPoint、视频）

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

问题：用户体验

我们所有的智能体都存在于人们已经在工作的地方，对我们来说就是 Slack。它们各自拥有自己的Slack 应用，可以被私信或在频道中被 @ 提及。在频道中与这些智能体协作的一个好处是，其他人可以看到人们是如何使用它的。

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

有些用户体验最好**不要**在 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 添加沙箱）让智能体能够从沙箱内部以安全可靠的方式连接到各项服务。

‍

问题：定时运行

很大一部分运行是定时的，或由事件在后台触发的，而不是由用户直接启动的。

其中一些是由智能体的开发者设置的。例如：OpenSWE 会监听 PR，当有新 PR 创建时就会进行审查。

另一些则是由用户要求智能体这样做而设置的。例如：我让 GTM 智能体每天给我发送一份简报，它就自己创建了一个cron来实现这一点。

全部构建于 Managed Deep Agents 之上

所有这些智能体都构建于Managed Deep Agents之上，后者位于开源Deep Agents框架之上。它提供了解决所有这些问题的所需基础设施（频道、cron、沙箱、记忆、身份），同时提供了足够的灵活性，以便按需定制智能体行为。今天就通过快速入门来试用吧！