LangChain 的 Harrison Chase 和 Caspar Broekhuizen 分享了公司内部三个 Agent 的搭建经验，从员工怎样使用它们，到身份、记忆、代码执行和后台任务如何配合，以下是全文翻译。
怎样搭建一套企业级 Agent 运行框架（company harness）？
我们在 LangChain 内部为营销、销售和研发团队搭建了 Agent，它们彻底改变了这些团队的工作方式。不过，要把它们做好并不容易。我们花了很多时间，解决多人使用同一套运行框架时遇到的问题。最后，每个团队都用到了相同的几个核心组件：
-
它出现在大家原本就在工作的地方，对我们来说就是 Slack。 -
它知道是谁在发出请求：访问一些服务时代表这位用户操作，访问另一些服务时则使用自己的身份。 -
它有记忆，作用范围可以是全局、单个用户，或同时包含两者。 -
代码在沙箱中运行，也能请求需要身份认证的服务。 -
很大一部分运行由定时任务触发，而不是由某个人明确发起——也就是在后台主动工作的 Agent（ambient agents）！
感谢 @caspar_br 对本文的帮助。
LangChain 内部的 Agent
先简单介绍一下 LangChain 内部的三个主要 Agent，让后面的讨论有个具体参照：
GTM Agent：一个主动、持续运行的 Agent，协助开展市场拓展工作。它会监测并回复邮件、跟进新出现的合格销售线索、发送每日简报、回答客户相关问题，也能主动开展拓客。
OpenSWE：我们的研发 Agent。它可以处理开发任务、起草 PR，还会对所有 PR 进行代码评审。
Content Studio：我们的营销 Agent。它了解我们的品牌定位，能够按照我们的风格起草博客、图片、PowerPoint 演示文稿和视频等内容。
这些 Agent 都采用相同的方式构建。我们认为，这是一套搭建企业级 Agent 运行框架的通用做法。
用户体验
我们的所有 Agent 都出现在大家原本就在工作的地方，也就是 Slack。它们各自有对应的 Slack 应用，既可以接收私信，也可以在频道中被 @。在频道里与 Agent 协作还有一个好处：其他人能看到大家是怎样使用它的。
我们加了一个挺好用的功能：把 Slack 对话“分出去”。很多时候，大家正在进行一场很有价值的讨论，你想把 Agent 拉进来，听听它的意见，或者让它做点事。但如果它直接在当前话题线程中运行，就会打乱大家的对话，让人分心。因此，我们提供了一种简单的方式，让 Agent 在同一频道里另开一个独立的话题线程。
有些交互确实不适合放在 Slack 里。比如，GTM Agent 希望我发送一些邮件，需要我先审阅。偶尔在 Slack 里处理一封没问题，但如果积压了很多待审邮件，再从一条条 Slack 消息里追踪，就很难用了。对于这类场景，我们最终还是专门做了一个界面。
身份
我们遇到的最棘手、最复杂的问题是身份。具体来说：这些 Agent 执行操作时，究竟代表谁？
目前业内主要有两种处理方式：
-
代表用户（on-behalf-of）：Agent 代表调用它的用户执行操作。 -
固定凭据：无论是谁调用，Agent 都使用一套固定的凭据，比如服务账号。
我们为每个 Agent 做了如下安排，相关文档是《为 Managed Deep Agents 添加身份》和《管理连接》：
OpenSWE
-
你给它发消息时，它代表你操作，比如使用你的 GitHub 账号创建 PR。 -
它在后台运行时，比如进行代码评审，就使用自己的身份，也就是 GitHub App。
GTM Agent
-
有些工具使用固定身份，比如访问 Salesforce，这样就不必让每个人都登录一遍。 -
另一些工具，比如邮件工具，则代表调用 Agent 的用户操作。这些工具只在私聊中可用，在共享频道里不可用。
Content Studio
-
有些工具，比如 Notion，代表调用 Agent 的用户操作。 -
另一些工具，比如 Twitter，使用一套固定凭据，这里对应的是我们公司的 Twitter 账号。不过，只有白名单内的用户才能调用其中某些操作。比如，不是所有人都能发推文，有些人可能只能读取或起草。
记忆
所有 Agent 都有两层记忆：
-
全局记忆：适用于所有用户的记忆。 -
用户记忆：只适用于某个特定用户的记忆。
Agent 自己决定要记住哪些事实，以及把它们放在哪一层记忆里。
这可能是我们目前探索得最少的部分，还有很多工作想做！
代码执行
我们的三个 Agent 都能编写和执行代码，而且经常需要这样做才能完成任务。它们采用相同的方式：Agent 本身运行在沙箱外，连接沙箱，并在沙箱中执行代码。三个 Agent 使用的基础镜像略有不同，安装的依赖也不同。OpenSWE 最侧重编程，它会根据频道或用户，智能选择要启动的基础镜像。它们都利用 LangSmith Sandboxes 的密钥代理（secret proxy），让 Agent 能够从沙箱内部安全地连接外部服务。相关说明还可参阅《为 Managed Deep Agents 添加沙箱》。
定时运行
很大一部分运行是定时执行，或者由后台事件触发，而不是由用户直接发起。
其中一些由 Agent 的开发者设置。比如，OpenSWE 会监听 PR，一旦有新的 PR 创建，就开始评审。
另一些则是用户让 Agent 设置的。比如，我让 GTM Agent 每天给我发一份简报，它就自己创建了一个 cron 定时任务。
都基于 Managed Deep Agents 构建
这些 Agent 都基于 Managed Deep Agents 构建，而 Managed Deep Agents 又建立在开源的 Deep Agents 运行框架之上。它提供了处理上述问题所需的基础设施，包括通信渠道、定时任务、沙箱、记忆和身份，同时保留足够的灵活性，让你按需定制 Agent 的行为。现在就可以跟着快速入门指南试一试！
参考链接
-
原文：https://www.langchain.com/blog/components-building-company-harness -
@caspar_br：https://x.com/@caspar_br -
Slack apps：https://docs.langchain.com/langsmith/python/managed-deep-agents-channels-slack -
Add identity to Managed Deep Agents：https://docs.langchain.com/langsmith/python/managed-deep-agents-identity -
Manage connections：https://docs.langchain.com/langsmith/python/managed-deep-agents-connections -
two tiers of memory：https://docs.langchain.com/langsmith/python/managed-deep-agents-memory -
secret proxy：https://docs.langchain.com/langsmith/sandbox-auth-proxy -
LangSmith Sandboxes：https://docs.langchain.com/langsmith/sandboxes -
Add a sandbox to Managed Deep Agents：https://docs.langchain.com/langsmith/python/managed-deep-agents-sandboxes -
cron：https://docs.langchain.com/langsmith/python/managed-deep-agents-schedules -
Managed Deep Agents：https://docs.langchain.com/langsmith/python/managed-deep-agents-overview -
Deep Agents：https://docs.langchain.com/oss/python/deepagents/overview -
quickstart：https://docs.langchain.com/langsmith/python/managed-deep-agents-quickstart