LangChain：搭一个公司级 Agent harness，绕不开这五个组件

Agent 从「你叫它才动」到「它自己在公司里干活」，中间隔着五个具体的工程问题。

10 月 24 日，Harrison Chase（LangChain CEO）和 Caspar Broekhuizen 发了篇短文，复盘他们在市场、销售、工程三条线上跑的内部 Agent，结论是三个团队各自踩坑，最后收敛出同一套原语。配套的开源底座 deepagents 在 GitHub 上 30.7k stars，工程 Agent OpenSWE 11.1k stars。

文章不长，但信息密度高。它真正的价值是给「公司级 harness」这个还没有标准答案的方向画了张最小可行架构图。这篇我不只翻译，会逐个组件讲清楚为什么是它、坑在哪，以及国内团队用飞书/企微落地时怎么映射。

本文提纲

1. 先分清：个人 harness 和公司 harness 不是一回事
2. LangChain 的三个内部 Agent
3. 组件一：住在人们已经工作的地方
4. 组件二：身份，最棘手的问题
5. 组件三：两层记忆，最未被探索的一环
6. 组件四：沙箱里跑代码，密钥怎么进去
7. 组件五：大部分运行是定时的，不是人喊的
8. 五组件全景与我的补充
9. 国内团队怎么映射

先分清：个人 harness 和公司 harness 不是一回事

过去半年我们聊 harness，语境基本是个人工具：Claude Code、Codex 这类 CLI，一个人、一套凭据、一个本地环境，Agent 拿到的权限边界就是你本人的权限边界。这个模型简单，因为身份问题不存在（Agent 就是你），记忆问题不尖锐（上下文在本地），执行环境也不敏感（你的机器你负责）。

公司 harness 是另一个物种：多人共用一个 Agent，它在 Slack 频道里被 30 个人同时 @，要按叫它的人的身份去查 Salesforce、发邮件、提 PR，还要在没人叫它的时候自己定时跑。单人 harness 里被「你即系统」绕过去的所有问题，在多人场景里全部变成必答题。LangChain 这篇文章的五个组件，本质就是这五道必答题。

LangChain 的三个内部 Agent

• GTM Agent：销售向，常驻型。盯邮件、响应新合格线索、每天发简报、回答客户账户问题、能自主跑外联动作。
• OpenSWE：工程向，开源项目（langchain-ai/open-swe，Python，11.1k stars）。能写代码提 PR，更关键的是它对所有 PR 跑代码审查，这是个后台常驻行为。
• Content Studio：市场向，按公司风格和定位草稿博客、图片、PPT、视频。

三个 Agent 面向完全不同的职能，技术实现却收敛到同一套结构。这也是 Chase 认为这套原语具有通用性的依据。

组件一：住在人们已经工作的地方

三个 Agent 全部以独立 Slack App 的形式存在，可以私聊 DM，也可以在频道里 @。这个选择的理由不光是少装一个 App 的便利。频道里使用有个隐形收益：其他人能围观 Agent 怎么被使用，使用方式本身成了团队里的活教程，新用户照着别人的提问学就行。

他们做了一个值得抄的交互细节叫 breakout。场景是这样：频道里两个人类正在讨论，你想把 Agent 拉进来问一嘴，但如果 Agent 直接在原 thread 里回复，它的中间过程会把人类对话冲散。解法是一键让 Agent「破」到频道里一个独立 thread 里干活，结论再带回主讨论。围观的好处保留了，污染没了。

但 Chase 也明确承认 IM 不是万能界面。比如 GTM Agent 帮你审待发邮件，一封两封在 Slack 里点按钮没问题；积压了几十封要逐封审，在聊天消息流里翻就是灾难。这类「批量、列表态、需要并排比较」的工作流，他们最终还是写了独立 Web UI。

我的判断：入口和工作台要分开设计。IM 负责唤起、通知、轻量确认；任何超过 5 个对象的批处理，老老实实做独立页面。判断标准就一条——这个界面里用户需不需要「列表」，需要，聊天框就兜不住。

组件二：身份，最棘手的问题

这是 Chase 原话里「最棘手、最微妙」（thorniest and trickiest）的问题，也是单人 harness 里完全不存在、多人 harness 里排第一的坑。Agent 执行动作时，到底以谁的身份？

业界两种基本做法：

• On-behalf-of（OBO，代表用户）：谁叫它，它就用谁的权限。提的 PR 挂你的 GitHub handle，发的邮件是你发的。权限、审计、责任都天然清晰。
• Fixed credentials（固定凭据）：Agent 拿一个服务账号，不管谁调用都用这套凭据。好处是不用每个人都去接一遍 OAuth，坏处是权限边界要自己重新造。

LangChain 三个 Agent 给出了三种混合配方，这部分是全文最有实操价值的内容：

OpenSWE 按触发方式分：你主动私聊让它干活，它以你的身份行动（PR 挂你的名字）；它在后台被事件触发时（比如自动审 PR），用自己的 GitHub App 身份。同一个 Agent，前台是人，后台是机器人，凭据随触发上下文切换。

GTM Agent 按工具分：Salesforce 这类全员都要查的系统用固定服务身份，省去每个人登录；邮件这类强个人属性的工具走 OBO，而且只在 DM 里可用，共享频道里直接禁用。最后这条是关键设计：频道是半公开场合，一句「帮我回了那封邮件」如果在 20 个人的频道里以你的身份发出去，既尴尬又危险，所以环境本身成为权限开关。

Content Studio 按工具加白名单分：Notion 走 OBO（动你的文档用你的身份）；Twitter 用公司账号的固定凭据，但再叠一层用户白名单——不是谁都能发，多数人只能读和起草，发推权限只给少数人。固定身份解决「接入一次全员可用」，白名单解决「服务账号权限过大」。

我的点评：身份设计没有默认答案，但有一条原则——能用 OBO 就别用 fixed，fixed 是为接入成本和后台无人场景付出的代价，付出之后必须用白名单和环境限制把权限收回来。GTM 那个「OBO 工具只在 DM 可用」的约束尤其值得抄，它把权限模型做进了交互位置，用户不需要理解 RBAC 就能自然地待在安全边界里。

组件三：两层记忆，最未被探索的一环

三个 Agent 的记忆都是两层：global memory（全公司共享）和 user memory（只属于具体用户）。Agent 自己决定一条事实该记到哪一层。举例：「我们公司产品定价采用年费制」进 global；「这个销售习惯晚上 9 点处理简报」进 user。

Chase 自己承认这是目前探索最浅的部分，他们还有大量工作要做。这个坦白很重要，因为市面上不少产品已经把「Agent 记忆」包装成解决了的问题。真实难点不在存取，在分层判断：一条客户偏好算全公司知识还是这个销售的个人语境？记错层级，轻则回答串味，重则把个人信息泄露给无权的同事——记忆层级在多人场景里同时是权限问题。

工程上还有个麻烦：两层记忆在召回时如何混合、冲突时谁优先、global 记忆谁有权写入，都需要策略。LangChain 把这套做成了 Managed Deep Agents 的托管能力（memory 文档），开源 deepagents 只提供原语，说明他们也认为这部分更适合作为服务迭代，而不是一次性设计。

组件四：沙箱里跑代码，密钥怎么进去

三个 Agent 都要写代码、执行代码。统一模式是：Agent 主体跑在沙箱外，需要执行时代入沙箱，三个 Agent 各有不同依赖的 base image，OpenSWE 最精细，会根据渠道和用户动态选择 base image。

真正的难点是个看似琐碎的问题：沙箱里的代码要访问需要鉴权的服务（GitHub、Salesforce、内部 API），密钥怎么给？最直觉的做法是把密钥注入沙箱环境变量，但这等于把凭据复制进了一个要跑模型生成代码的环境，沙箱逃逸或 prompt injection 拿到代码执行权时，密钥就是直接战利品。

LangChain 的解法是 secret proxy（密钥代理）：沙箱内不持有任何长期凭据，代码要访问服务时向沙箱外的代理发请求，代理持有凭据、完成鉴权请求、只把结果返回沙箱。配合前面的身份模型，代理还能按「当前是哪个用户触发的」决定放什么权限。这样即使生成的代码是恶意的，它能碰到的只是一个受审计、权限随上下文收缩的请求通道，而不是裸密钥。

这是五个组件里安全设计含量最高的一个，也是自研团队最容易偷懒跳过的一个。判断你们的沙箱方案合不合格，就问一句：沙箱文件系统被打包拷走后，里面有没有能直接用的凭据。答案是有，方案就得重来。

组件五：大部分运行是定时的，不是人喊的

文章里最该划重点的一句：很大比例的运行（large % of runs）是定时或后台事件触发，而非用户直接发起。Chase 直接把这类叫做 ambient agents。

触发源分两类：

• 开发者预设的：OpenSWE 监听 PR 事件，新 PR 一出现就自动审查，不需要任何人叫它。
• 用户自己创建的：Chase 让 GTM Agent 每天给他发一份简报，Agent 自己创建了一条 cron 来兑现这个承诺，而不是由开发者预先写死功能。

第二类是范式变化：定时任务从「开发者要排期实现的功能」变成「Agent 听懂自然语言后自己创建的资源」。这意味着 Agent harness 必须把 cron 这种基础设施能力作为工具暴露给模型，并且配套解决权限（谁能让 Agent 建定时任务）、可见性（这些任务在哪看、怎么取消）和失控防护（一个 Agent 被诱导建了 1000 个 cron 怎么办）。

这也是 ambient agent 和传统 chatbot 的分界线：chatbot 的价值和使用次数线性相关，有人问才有价值；ambient agent 的价值产生在无人注视时，它把人从「记得去做」里解放出来。PR 审查、日报、线索跟进这类工作的共同点是「触发条件明确、错过有代价、人工执行纯靠记性」，它们是 ambient 化的第一批目标。

五组件全景与我的补充

graph TB
    U["Users in Slack channels and DMs"] --> CX["Component 1: Channel UX with breakout threads"]
    CX --> ID["Component 2: Identity layer OBO plus fixed credentials"]
    ID --> AG["Agent runtime: GTM, OpenSWE, Content Studio"]
    AG --> MEM["Component 3: Two-tier memory global and user"]
    AG --> SB["Component 4: Sandbox with secret proxy"]
    AG --> CR["Component 5: Schedules and event triggers"]
    CR --> AG
    SB --> SP["Secret proxy holds credentials outside sandbox"]
    SP --> SVC["GitHub, Salesforce, Email, Notion"]

    style CX fill:#FF6B6B,color:#000000
    style ID fill:#4ECDC4,color:#000000
    style MEM fill:#45B7D1,color:#000000
    style SB fill:#96CEB4,color:#000000
    style CR fill:#FFEAA7,color:#000000
    style AG fill:#DDA0DD,color:#000000
    linkStyle default stroke:#764ba2

五个组件解决的其实是同一个转变的五个侧面：从「一个人和一个 Agent」到「一个组织和一群常驻 Agent」。Chase 这套清单我基本认同，但站在落地者角度，它还缺三块：

第一是评测与回归。Agent 行为散在定时任务、频道对话、后台事件里，一次 prompt 或模型升级可能同时改坏几十个无人盯的运行，没有离线评测集和线上轨迹采样，公司不敢升级。LangChain 自己是用 LangSmith 补这一块，所以博文里没单列，但自研团队千万别漏。

第二是成本治理。ambient 模式天然放大调用量：以前是人点一次花一次钱，现在 cron 和事件自己跑，一个错误订阅可能一晚烧掉预算。定时任务的预算上限、异常调用量熔断，要和第五个组件一起上线，不能后补。

第三是人机协同的审批边界。文章里只有「白名单」粗粒度控制，实际生产里更常见的是按动作风险分级：读操作自动、写操作建草稿、发邮件/发推/合并 PR 必须人点确认。OpenSWE 是「起草 PR」而不是「合并 PR」，这个克制本身就是答案。

国内团队怎么映射

这套架构生长在 Slack + GitHub + Salesforce 栈上，搬到国内，组件映射比工具替换更要紧：

• 组件一，Slack 换成飞书/企业微信/钉钉。飞书的机器人+群话题、卡片交互和审批流对 breakout、动作确认的支撑其实更顺；「频道围观」同样成立。独立 UI 的判断标准不变，批量工作流出 IM。
• 组件二，国内 SaaS 的 OBO 生态比欧美弱，很多企业系统只有一个 admin token，这会逼着你大量使用 fixed credentials，那么白名单、环境限制（群 vs 单聊）、动作审批这三道防线一道都不能省，而且要更严。
• 组件四，沙箱和密钥代理在等保/金融合规环境里反而是加分项，立项时把「沙箱内无持久化凭据」写进方案，安全评审会顺很多。
• 组件五，飞书多维表格的自动化、钉钉宜搭这类触发器可以先承担事件源，不必一开始就让模型自建 cron；但权限和可取消性要按生产标准做。
• 底座选型上，开源 deepagents 提供 harness 原语（子 Agent、文件系统、规划），Managed Deep Agents 把五组件做成托管服务但绑定 LangSmith 云。数据不出内网的团队基本只能拿开源部分自建，渠道、身份、定时这三块都要自己填，工作量要有预期。

五个组件里，我建议的落地顺序是身份先行：它是唯一一个做错了要事后重做、还可能出事的组件；渠道和沙箱可以迭代，记忆可以简陋，定时可以后加，身份模型一旦有几十个用户和几百条权限规则跑起来，再换就是伤筋动骨。

参考文档与链接

• The five components of building a "company harness" — LangChain Blog — 本文主要依据，Harrison Chase & Casper Broekhuizen，2026-10-24
• Managed Deep Agents 概述 — 五组件的托管实现总览
• Managed Deep Agents：Slack Channels — 组件一，Slack App 接入文档
• Managed Deep Agents：Identity — 组件二，OBO 与固定身份配置
• Managed Deep Agents：Connections — 组件二，各服务连接管理
• Managed Deep Agents：Memory — 组件三，两层记忆 API
• Managed Deep Agents：Sandboxes — 组件四，沙箱接入
• LangSmith Sandbox Auth Proxy（secret proxy） — 组件四核心，沙箱外密钥代理
• Managed Deep Agents：Schedules（cron） — 组件五，Agent 自建定时任务
• Managed Deep Agents Quickstart — 上手入口
• GitHub: langchain-ai/deepagents — 开源 harness 底座，Python，30k+ stars
• GitHub: langchain-ai/open-swe — 文中的工程 Agent，异步编码与 PR 审查，11k+ stars
• Deep Agents 开源文档 — 自研究者的原语层文档
• 相关文章：Agent harness 七层模型 — 本站对个人 harness 分层的拆解
• 相关文章：从 prompt 到 harness engineering — harness 工程化的来龙去脉
• 相关文章：Deep Agents 架构深挖 — deepagents 内部结构的早期分析

你们公司内部跑起来的第一个 ambient Agent 会是干什么的？评论区聊聊。觉得五组件清单有漏的，也欢迎补充。

---

作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

本文首发于 AI人工智能时代，转载请注明出处。