LangChain 总结公司级 Agent harness 五件套

Company Harness 五件套：把公司级 Agent 做成可多人协作的基础设施

@LangChain 用自家 GTM / 工程 / 营销三套内部 Agent 总结出「公司级 harness」的五块共性底座：住在人已在用的协作入口、身份（OBO vs 服务账号）分工具落地、全局/用户双层记忆、沙箱内跑代码并经 secret proxy 访问鉴权服务、大量任务是定时或事件触发的 ambient agent，并都建在 Managed Deep Agents（叠在开源 Deep Agents harness 之上）上。 https://t.co/Iorrbv51uY

背景：三套内部 Agent 同一套配方 LangChain 写这篇文章，是因为他们在营销、销售、工程里都跑起了内部 Agent，且「多人共用的 harness」踩过不少坑后，各团队收敛到同一组原语。用来落地讨论的三例： · GTM Agent：始终在线的增长助手，盯邮件与合格线索、发 daily brief、答账户问题、跑 outbound。 · OpenSWE：工程 Agent，可改代码、起草 PR，并对所有 PR 做 code review。 · Content Studio：营销 Agent，按公司风格与定位起草博客、图、PPT、视频等资产。

LangChain 认为这不只是内部特例，而是 company harness 的通用配方。

问题一：体验——人在哪工作，Agent 就住哪 三套 Agent 都以 Slack 为入口：各自独立 Slack App，可私聊或在频道里 @。频道协作的好处是同事能看见别人怎么用。

一个具体产品细节：breakout（拆出子线程）。人类讨论正酣时想拉 Agent 进来做事或给意见，若直接在原线程跑会污染对话；于是做成「一键拆到频道里单独线程」，把 Agent 作业与人际讨论隔开。

也承认 Slack 并非万能：例如 GTM Agent 审待发邮件，零星可以在 Slack 里点，积压一多就很难跟；这类体验他们最终补了 自定义 UI。

问题二：身份——最难、最刺的一块 核心问句：Agent 采取行动时，代表谁？业界常见两条路： 1. On-behalf-of（OBO）：以唤起该 Agent 的用户身份行动。 2. 固定凭证：无论谁唤起，都用同一套凭据（如服务账号）。

他们按 Agent、甚至按工具拆开（文中指向 Managed Deep Agents 的 identity / connections 文档）： · OpenSWE：你消息它时 OBO 你（例如用你的 GitHub handle 开 PR）；后台跑（如 code review）则用 自己的身份（GitHub App）。 · GTM Agent：Salesforce 等用 固定身份（不必人人登录）；邮件等 OBO 唤起者——且这类工具 只在 DM 可用，共享频道关闭，避免在公开场合代人发信。 · Content Studio：Notion 等 OBO；发 Twitter 等用 公司账号固定凭据，并对高危操作做白名单（例如并非人人能发推，可能只能读/起草）。

问题三：记忆——全局层 + 用户层 所有 Agent 都有两档记忆：全局记忆（对所有用户生效）与 用户记忆（仅对该用户）。由 Agent 自行决定哪些事实写进哪一层。LangChain 认为这是目前探索最少的一块，后续还要大力做。

问题四：代码执行——进程在外、代码在沙箱 三套都能写代码、跑代码。模式一致：Agent 本体在沙箱外运行，连上沙箱在里面执行；各自有略不同的 base image / 依赖。OpenSWE 还会按频道/用户智能选择起哪套镜像。安全面靠 LangSmith Sandboxes 的 secret proxy：让沙箱内代码能安全连到需要鉴权的服务（文中链到「给 Managed Deep Agents 加 sandbox」一类文档）。

问题五：定时与事件——大量跑次不是人点的 很大比例的 run 是 调度或后台事件触发，而非用户当场唤起（文中强调 ambient agents）。两类来源： · 开发者预置：如 OpenSWE 监听新 PR 并自动 review。 · 用户口述后自建：如 LangChain 让 GTM Agent 每天 brief，它自己建了 cron。

收尾：Managed Deep Agents 上述通道、cron、sandbox、memory、identity 都由 Managed Deep Agents 提供（叠在开源 Deep Agents harness 上），同时保留定制 Agent 行为的空间；文末导向 quickstart。