公司级 agent 难的不是模型，而是「多人共用」。 LangChain 内部有三个 agent：GTM Agent 做销售，OpenSWE 做工程，Con… · @ClorisSignal · TwKit

@ClorisSignal

公司级 agent 难的不是模型，而是「多人共用」。 LangChain 内部有三个 agent：GTM Agent 做销售，OpenSWE 做工程，Content Studio 做营销。三个团队各自做下来，最后落到了同一套五块底座上： 1. 入口： agent 放在大家已经在用的地方，他们用的是 Slack，可以私聊，也可以在频道里 @ 它。积压的待审邮件在 Slack 里处理太痛苦，他们最后专门做了一个 UI。 2. 身份： 这是“最棘手”的一块，核心是 agent 替谁动手。 - OpenSWE 开 PR 用你本人的 GitHub 账号，这叫 OBO（on-behalf-of）；在后台做 code review 时，用的是它自己的 GitHub App。 - GTM 连 Salesforce 用固定身份，这样不用人人都登录；发邮件则是 OBO，而且只在私聊里开放。 - Content Studio 连 Notion 用 OBO；公司 X 账号用固定凭证，只有白名单里的人能用来发帖。 3. 记忆： 分全局和用户两层，由 agent 自己决定一条事实记在哪一层。这是目前探索最少的一块。 4. 代码执行： agent 本身跑在 sandbox 外面，连进沙箱里去执行代码。沙箱里的代码要访问需要鉴权的服务时，通过 LangSmith Sandboxes 的 secret proxy 来接。 5. 定时和事件： 很大比例的运行是定时或者被事件触发的，也就是 ambient agents（后台常驻 agent）。比如 OpenSWE 会盯着新 PR 自动做 review。让 GTM agent 每天发一份简报，它就自己建了一个 cron（定时任务）。 搭建企业agent时，我们可以这样做： - 列一张工具身份表。 每个工具标清楚是「代表发起人」还是「固定账号」。 - 先从一个入口上线，别新做 App。 agent 接进团队已经在用的通讯工具。 - 上线前抽查全局记忆。 agent 自己决定记在哪一层，个人信息就有可能混进全员可见的全局层。 - 定时任务单独管。 先数一数日志里有多少次运行是定时或事件触发的。 - 凭证别进沙箱。 学他们的 secret proxy 思路：代码在沙箱里跑，密钥留在沙箱外，由代理统一接入，沙箱里看不到明文密钥。

曝光 265 · 评论 0 · 点赞 4 · 书签 4