LangChain 总结企业级智能体 harness 的五个组成部分
The five components of building a "company harness"
LangChain 基于内部 GTM Agent、OpenSWE 和 Content Studio 三个智能体的搭建经验，提出公司级智能体 harness 的五个核心要素：嵌入 Slack 等现有工作场所、区分代用户执行与固定身份、全局与用户两级记忆、沙箱内代码执行、以及大量由定时或事件触发的后台运行。
LangChain 公开了内部三个智能体的统一搭建方式，身份、记忆与沙箱执行的处理取舍可供团队参考。
你如何构建一个公司级 harness？
我们在 LangChain 的营销、销售和工程团队中都构建了内部 agent，它们彻底改变了这些团队的工作方式。要把它们做对并不容易。我们花了大量时间解决多用户 harness 带来的问题，最终每个团队都归结到相同的核心原语：
- 它存在于人们已经工作的地方（对我们来说就是 Slack）
- 它知道是谁在提问，并对某些服务以该人的身份（OBO）行事，对其他服务则以自己的身份行事
- 它具有记忆，作用域可以是全局和/或用户级别
- 代码在沙箱中运行，并且可以向需要认证的服务发起请求
- 其运行中很大比例是定时触发的，而不是由某人显式调用（环境型 agent！！）
感谢 @caspar_br 对本文的帮助
LangChain 内部 Agent
为了给讨论奠定基础，先简要概述我们在 LangChain 的三个主要 agent：
GTM Agent：一个主动的、始终在线的 agent，协助 GTM 活动。监控并回复邮件、处理新的合格线索、发送每日简报、回答关于客户账户的问题、执行外呼动作
OpenSWE：我们的工程 agent，可以处理并起草 PR，还会对所有 PR 运行代码审查
Content Studio：我们的营销 agent，可以按照我们的风格并基于对我们定位的了解来起草素材（博客、图片、PowerPoint、视频）
所有这些 agent 都以相同方式构建。我们认为这是构建公司级 harness 的通用配方。
问题：用户体验
我们所有的 agent 都存在于人们已经工作的地方，对我们来说就是 Slack。它们各自拥有自己的 Slack 应用，可以私信或在频道中被 @。在频道中使用这些 agent 的一个好处是，其他人可以看到人们如何使用它。
我们添加的一个不错的功能是在 Slack 中“拆分”对话的概念。通常，一场精彩的对话正在进行，你想把 agent 加入进来征求它的意见或让它做点什么。但如果它们在该线程中运行，会污染人类对话并造成干扰。因此我们添加了一种简单的方式，让 agent 可以“拆分”到频道中它们自己的线程里。
有些用户体验最好不要在 Slack 中完成。例如，在审阅 GTM Agent 想让我发送的邮件时，在 Slack 中一次性处理没问题，但如果有大量积压，从 Slack 消息中跟踪这些就完全不是愉快的体验。对于这类体验，我们最终构建了自定义 UI。
问题：身份
我们解决的最棘手、最微妙的问题是身份，具体来说：当这些 agent 采取行动时，它们代表谁采取行动？
业界主要有两种处理方式：
- 代表他人（On-behalf-of）：agent 代表调用它的用户行事
- 固定凭证：无论谁调用，agent 都使用一组固定凭证（例如服务账号）
以下是我们为每个 agent 处理该问题的方式（文档：Add identity to Managed Deep Agents、Manage connections）：
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、沙箱、记忆、身份），同时提供足够的灵活性来根据需要自定义代理行为。立即通过快速入门试用吧！
来源：LangChain Blog · langchain.com