深度 · 小互解读

LangChain 开源自家四个编码 Agent：本地写码、云端开 PR、自动审查、仓库文档

LangChain 说自家上周光从 Slack 就触发了近 1000 次云端编码任务。代码都能下载下来读，包括审查 Agent 判断 bug 的完整判据。
一分钟速览
  • 真实的工程工作不在终端里开始：bug 报在 Slack、需求躺在 Linear、审查发生在 GitHub。LangChain 按这几个入口各做了一个 Agent，四个全部开源，共用同一块自研的 Agent 地基 Deep Agents。
  • 云端那个 OpenSWE 在自家用得最重，上周光从 Slack 就被触发近 1000 次，每个任务跑在自己的云端临时机器里，干完直接提交一份待审的改动提案。
  • 审查 Agent 最硬的机制藏在代码里：报 bug 必须锚定到这次改动过的那一行，锚不上的工具层直接拒收，另有一份写死的「不许报」清单挡掉改名、猜测和架构意见。
  • 它的审查口味会自己长：先爬仓库历史 PR 学这个团队认什么，再每晚根据自己提的意见最后被采纳还是被驳回，回头改自己的提示词。
  • OpenWiki 管的是让文档跟着代码走。把它自己那份 wiki 拉下来对代码一行行核，会看到它指向了一个不存在的函数、留着一个已经删掉的模型接入方式。
⚑这四个工具都是 LangChain 自家产品，使用量、跑分和效果描述均为官方口径。本文的机制细节来自公开源码，跑分数字本站去公开榜单核对过，核对结果写在正文里。
问题在哪

一个 bug 从 Slack 被人提起，到有人动手改，中间要转多少手

2026 年 7 月 18 日，LangChain 把自家内部在用的四个软件工程 Agent 一次性公开，四个全部开源。

先看一件具体的工作。周二下午，客服在 Slack 里贴了一张截图：登录页在 Safari 上白屏。这条消息现在要走完这么一段路，才轮到有人真正动手：有人看见它，判断这是个真 bug，去 Linear 建一张卡片，卡片进了排期，某个工程师某天上午认领，打开电脑，拉最新代码，读一遍相关文件，才开始改。改完推上去，等另一个人有空来审这个 PR，审完合并。

写代码这个动作本身，只占中间很小一段。前面全是转手，后面全是等待。四个工具对应的就是这条路上四个不同的位置。

dcode 守着终端，OpenSWE 守着 Slack 和 Linear，OpenSWE Review 守着 GitHub 的 PR 页，OpenWiki 守着仓库里那份给 AI 看的说明书。
◆Stripe、Ramp、Coinbase 这几家都造过自己的内部编码 Agent，但只发博客不给代码，外人想学只能照着文章猜它怎么搭的。这一次架构本身被完整开源了，能下载到的两个仓库都用 MIT 协议，随便改随便商用。连审查 Agent 判断一个 bug 该不该报的完整判据，都是能逐条读、逐条改的明文提示词。
全景

四个工具各守一个入口

四个工具分工不重叠，底下踩的是同一块板子。

工作从哪来 终端 Slack ・ Linear GitHub 的 PR 仓库本身 dcode 本地交互写码 你在旁边看着 OpenSWE 云端后台干活 干完开草稿 PR OpenSWE Review 只读，不改代码 只挑 bug OpenWiki 维护仓库文档 给人也给 AI 看 Deep Agents 同一套 Agent 底座：读写文件、跑命令、开子 Agent、中间件 四个工具共用底座，所以底座的改进四个一起吃到 LangSmith 四个工具的运行轨迹都往这里汇（这一层是收费的托管服务）
四个入口、四个 Agent、一块共用底座。底部那层是 LangChain 的商业产品，四个开源工具本身不强制用它。
工具跑在哪你怎么叫它它交付什么
dcode你自己的电脑终端里敲 dcode直接改本地仓库的文件
OpenSWE云端沙箱Slack、Linear、GitHub 里 @ 它，或者网页端一个草稿 PR
OpenSWE Review云端沙箱PR 开出来自动触发PR 上的行内评论
OpenWiki你的电脑或 CI命令行，或每天定时跑仓库里一个 openwiki/ 文档目录

共用底座这件事不只是省代码。Deep Agents 提供的是那些每个编码 Agent 都要重写一遍的东西：读写文件、跑命令、开子 Agent 并行干活、用待办清单管住多步任务，以及一套叫中间件的机制，专门用来做那些不能指望 AI 自觉的事。

本地

本地那个 dcode 长什么样

dcode 是装在自己电脑上的终端编码 Agent，交互式，你在旁边看着它干。

装 dcode 并启动
curl -LsSf https://langch.in/dcode | bash
dcode
官方文档里的 dcode 演示，不到 16 秒：敲 dcode 启动，它自报一遍能干什么。这段演示只到自我介绍为止，没有展示改代码的过程。注意右下角状态栏写的是 fireworks:glm-5p2 max，跑的是开源模型 GLM-5.2。来源：LangChain 官方文档
dcode 启动界面
推文里那张 dcode 启动图，版本 v0.1.28。中间四行是启动自检：LangSmith 轨迹已接上、加载了 14 个 MCP 工具、还有 3 个 MCP 服务需要登录。左下角 manual 是当前的审批模式，右下角这次跑的是 openai:gpt-5.5。来源：Brace Sproul 推文

它的能力里有两项值得单挑出来。一是可以给它设「目标和评分标准」，让它自己检查工作到底做完没有，这跟后面审查 Agent 那套判据是同一个思路的两次出现。二是上下文压缩：老消息摘要掉，原始内容卸到存储里，免得聊长了撑爆。另外它虽然装在你自己电脑上，也能把工具调用甩到远端沙箱去跑，这一点和下面云端那个是同源设计。

模型不绑定。演示视频跑的是 Fireworks 上的 GLM-5.2，推文截图跑的是 GPT-5.5，换一个 provider 就换一个模型。

云端

一句 Slack 消息怎么变成一个 PR

OpenSWE 是这套里在 LangChain 自家用得最重的一个，它要解决的是「任务来了但没人有空开电脑」。

近 1000 次
上周仅从 Slack 触发的任务数，不含 Linear 和网页端（LangChain 官方数字）
6 条
审查 Agent 一次最多发几条意见，代码里的默认上限

回到开头那个 Safari 白屏。用 OpenSWE 的话，这条 Slack 消息底下直接 @ 一下机器人，后面的事就自动了，一共五步：

1 你在 Slack 里 @openswe 「登录页在 Safari 上白屏，看一下 repo:acme/web」 2 它甩一个 👀 表情，表示接到了 这一步纯粹是给人看的，让你知道消息没掉 3 开一台云沙箱，把仓库克隆进去 整条 Slack 对话历史一并塞给它当背景，不用它自己一点点问 4 在沙箱里查、改、跑测试 这期间你在 Slack 里补一句，它下一步之前会读到 5 自己提交、推分支、开草稿 PR，回 Slack 贴链接 草稿状态，等人看；PR 里 @ 它还能继续改
这个 Safari 白屏的例子是本站为讲解搭的示意场景。这五步的机制来自 open-swe 仓库的公开说明。

沙箱这一层为什么重要

沙箱就是一台临时开的云端 Linux 机器，仓库克隆进去，Agent 在里面权限全开，可以随便跑命令、装依赖、改文件。它值钱的地方在于：因为搞砸了也只砸这一台临时机器，所以里面就不需要每一步都停下来问你「我可以执行这条命令吗」。

打个比方

与其让实习生在正在跑的生产环境里束手束脚、每动一下都要签字，不如给他一间完全一样的样板间，钥匙全给他，砸了就重开一间。

沙箱可以接 Modal、Daytona、Runloop、E2B、LangSmith 几家，也能自己写一个接进去。一次对话固定用同一台，下次接着这个对话还用它，掉线了会自动重建。

跑到一半还能插话

这是个容易被忽略但日常很实用的机制。Agent 干活时你想起一句「顺便看看 iOS 上是不是也这样」，直接在 Slack 里发出去，一个叫 check_message_queue_before_model 的中间件会在它下一次调用模型之前，把这条新消息塞进上下文。

中间件是这套设计里反复出现的手法：那些不能指望 AI 自觉的事，就用固定代码在模型调用前后强制执行。除了插话，还有到达模型调用上限时主动去 Slack 报一声（免得你干等）、工具报错时兜住、沙箱连续失败时熔断、跑满 45 分钟往上下文里插一句提醒要求收尾别再开新调查。仓库里这样的中间件有 22 个。