如何建造公司发电机？
我们在 LangChain 的营销、销售和工程部门都构建了内部代理，它们彻底改变了这些团队的运作方式。这些代理并非容易实现。我们花了大量时间解决多玩家框架带来的问题，最终每个团队都得出了相同的核心原理：
- 它存在于人们已经工作的地方（对我们来说就是 Slack）
- 它知道是谁在请求，对于某些服务会以自己身份行事，而对于其他请求则保持自己的特征
- 它具有内存，可在全局或用户级别范围内使用
- 代码在沙箱环境中运行，可以向需要身份验证的服务发起请求
- 其大部分运行是通过计划机制进行的，而非由特定人明确调用（环境代理！！）
感谢 @caspar_br在本博客上的帮助
LangChain 内部代理
为了展开讨论，以下是对 LangChain 中三个主要组件的简单概述：
GTM Agent: 一个主动的、始终在线的代理，用于协助 GTM 活动。它会监控并回复电子邮件，处理新的合格线索，发送每日简报，能够回答关于账户的问题，并能执行外部操作。
OpenSWE：我们的工程代理可以处理并起草 PR，同时还会对所有 PR 进行代码审查。
Content Studio: 我们的营销代理，能够按照我们的风格并基于我们对定位的理解来创作各种素材（博客、图片、PowerPoint、视频）
所有这些设备都是以相同的方式制造的。我们认为这是制造公司设备的一般方法。
问题：用户体验
我们的所有代理都位于人们工作的地方，对我们来说就是 Slack。每个代理都有自己的 Slack 应用，可以在频道中通过私信或标签联系它们。在频道中使用这些代理的一个好处是，其他用户可以看到人们是如何使用它的。
我们添加的一个好功能就是“在 Slack 中分离对话”的概念。很多时候，会有一场精彩的对话正在进行中，你希望让智能体加入进来，以获取他们的意见或指示他们做某件事。但如果让它们参与当前线程，就会污染人之间的对话，还会分散注意力。因此，我们添加了一种简单的方法，让智能体能够在频道中创建自己的独立线程。
有些用户体验在 Slack 上就不适合进行。例如，在查看 GTM Agent 要求我发送的邮件时，一次性在 Slack 中处理是没问题的；但如果任务量很大，从 Slack 消息中跟踪这些任务就非常麻烦了。对于这类情况，我们最终还是开发了一个自定义界面。
问题：身份
我们面临的最棘手、最复杂的问题是身份问题，具体来说就是：当这些代理采取行动时，他们是以谁的名义行动的？
行业中有两种主要的处理方式：
- 代表：代理代表调用该代理的用户行事
- 修正了凭据: 存在一组固定的凭据，无论谁调用该代理（例如服务账户）都会使用这些凭据。
这就是我们针对每个智能体处理该问题的方式（文档：为管理型深度智能体添加身份，管理连接）：
OpenSWE：
- 当您发送消息时，它会代表您行事（例如会用您的 GitHub 账号打开 PR）
- 当它在后台运行时（例如作为代码审查代理），它会以自身的身份运作（GitHub 应用）
GTM 代理：
- 它有一些工具（例如 Salesforce 访问工具），在这些工具中会使用固定的身份，所以并非所有人都需要登录
- 它有一些工具（如电子邮件），这些工具以调用代理的用户的名义执行操作。这些工具仅可在私信中使用。在共享频道中则无法使用。
内容工作室：
- 它有一些工具（如 Notion），可以在调用代理时代表用户执行操作
- 它有一些工具（如 Twitter），这些工具使用固定的凭证，在本例中就是我们公司的 Twitter 账户。不过只有被列入白名单的用户才能执行某些操作。例如，并非所有人都能在 Twitter 上发布内容（他们可能只能阅读/编辑）。
问题：内存
所有代理都有两层内存：
- 全局内存：适用于所有用户的内存
- 用户内存：仅适用于特定用户的内存
代理决定要将哪些事实记住到哪个记忆层级。
这可能是目前最未被探索的区域——我们还有很多工作需要在这里完成！
问题：代码执行
我们的三个代理都能够编写并执行代码，通常也需要这样做以完成任务。它们都遵循在沙箱外部运行、但又能连接到沙箱并在此处执行代码的模式。它们都有略有不同的基础镜像和不同的依赖项。OpenSWE（与编码相关的代理）能够智能地选择要启动的基础镜像（该选择依据渠道/用户而有所不同）。它们都利用 秘密代理 在 LangSmith Sandboxes 中（另见 在 Managed Deep Agents 中添加沙箱），从而使代理能够从沙箱内部安全、可靠地连接到服务。
问题：计划运行
很大比例的运行是通过事件在后台被安排或触发，而不是由用户直接启动。
其中一些是由代理开发者设置的。例如：OpenSWE 会监听 PR 请求，当新请求出现时就会对其进行审查。
其他情况是由用户要求代理执行。例如：我让 GTM 代理向我发送每日简报，它便设置了自带的 cron 来完成此任务。
所有内容均基于管理型深度代理
所有这些代理都基于管理式深度代理构建，该机制建立在开源的深度代理基础之上。它提供了解决所有问题的基础设施（如通道、Cron、沙箱、内存、身份管理），同时具备足够的灵活性，以便根据需求定制代理行为。今天就使用快速启动指南来试试吧！