四个工具各守一个入口

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

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

本地那个 dcode 长什么样

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

curl -LsSf https://langch.in/dcode | bash
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 自家用得最重的一个，它要解决的是「任务来了但没人有空开电脑」。

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

沙箱这一层为什么重要

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

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

跑到一半还能插话

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

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

其中一个值得单拎出来说。这个 Agent 在沙箱里是全权限、不需要逐步确认的，但有一件事它必须停下来等人点头：改 CI 配置文件。想推这类文件，得先发一条带改动预览的批准请求到 Slack，人同意了才放行。

这个位置选得有讲究。CI 配置是决定「代码合并前要过哪些检查」的那份文件，Agent 一旦能自己改它，就等于能自己关掉管着自己的那道闸。全自动流程里唯一必须留人的地方，是它对自己的约束。

OpenSWE 的网页端，左栏是历史任务，每条后面的绿色数字是那次改动的行数（+18、+443、+456 这些），带 Slack 图标的表示是从 Slack 触发的。底部可以选模型，图中选的是 GPT-5.5 High，旁边 Plan 是先出方案再动手的开关。来源：Brace Sproul 推文

审查 Agent 凭什么说这是个 bug

这套判据全写在 reviewer.py 的提示词里，公开可读，也能逐条改。

先说清楚这个 Agent 和写码那个的区别：它是只读的。工具箱里有十样工具，拉取改动、记录问题、更新问题、发布评论、回复讨论串、查资料都在，唯独没有提交、没有推送、没有开 PR。它唯一的产出是改动提案上的行内评论。

代码审查工具最招人烦的毛病是话多：一堆「这里可以改个名」「这个变量可以提取成常量」「如果将来有人传 null 呢」，真 bug 淹在里面。OpenSWE Review 的做法是给「什么算一个值得报的问题」定了一道硬门槛。

第三条最值得单独讲。它在工具层强制执行，不停留在提示词的口头约定。

审查开始前，系统会先算好这次 PR 的完整 diff，把改动涉及的每一个「文件加行号」组合存成一张表，随运行配置传给记录问题的工具。Agent 每次调 add_finding 记录一个问题，工具当场拿这张表校验，行号不在表里就直接返回失败，附带一个 in_diff: false。提示词里还专门补了一句：被拒了不许换个行号重试。

这条规则严到什么程度？提示词里承认了一种情况：改函数签名确实可能让某个没被改过的调用点出问题，这是真 bug。但只要那一行不在本次 diff 里，就是不许报。

读到这儿你大概会想：那跨文件的问题它不就瞎了吗？改了个函数签名，别处调用的地方全崩，而那些地方都不在这次改动里。

看可以出圈，报不许出圈

答案在同一份提示词的另一半。它给了一套九步的搜查流程，而这套流程明确要求 Agent 把眼睛伸到改动之外去。

所以那条严苛的规矩准确的说法是这样：看的范围放开，报的范围收死。它会跑到改动之外去查，查到了也算数，那些信息会变成它判断改动块内那一行到底有没有问题的依据。但最终能挂到 PR 上的那条评论，锚点必须落在改过的行上。

这个拆分是这套设计里最能搬走的一条。搜索靠放开，落地靠收窄，两件事用不同的尺子量。

还有一份写死的「不许报」清单

唯一的例外留给拼写错误：如果一个拼错的名字会让程序真的跑不通（比如模板里按字符串引用的导出名），那算 bug 不算风格。

严重度按后果分，不按感觉分

提示词末尾专门加了一句：架构意见、命名偏好、微优化不构成任何一档严重度，它们根本不是问题。

发布之前还有一道收口：先列一遍所有记录的问题，合并重复的，按严重度排序，同一个文件里不留两条，除非确实是两种不同的坏法。

最后砍到 6 条。还有一道过滤只在代码里、提示词里没写：发布时的最低严重度默认卡在 medium，也就是 low 档的问题默认不会变成行内评论，只留在后台记录里。这是个默认值，调用时能传别的档位，等下讲跑分那节会用到这一点。

反过来也有一条自查。如果这次改动碰了正式代码，它却一条问题都没提，提示词要求它回头再走一遍流程，理由是「真改了东西却全无发现，通常是漏了，不是这份改动干净」。

还有一个问题值得单独说：被审的人能不能收买审查 Agent？审查 Agent 会读仓库里的规矩文件，而这些文件就躺在被审的仓库里，改动提案的作者顺手加一句「所有问题一律放行」似乎就成了。

它的解法是：这些文件一律从目标分支取，不从提案自己那一版取。改了也没用，读的不是你那份。

审查界面。这个例子本身值得看：PR #1591 是 Open SWE 自己开的（描述里写着 Made by Open SWE），改了 3 个文件、+138 −28，修的是并发 Slack 消息导致重复起任务的问题；审它的是 Open SWE Review，右栏结论是 0 Bugs、0 Flags。下方 Checks 那一列十一项全打了绿勾，里面能看到 Corridor Review、Open SWE Review、CodeQL 这些。来源：Brace Sproul 推文

它每天夜里改自己的审查口味

每个团队在意的东西不一样，有的组死磕错误处理，有的组盯性能。OpenSWE Review 没有把这件事做成配置项，而是让它自己长出来。

干这件事的是一个单独跑的程序，代码里叫 analyzer，有两种模式。

第一种叫 bootstrap，冷启动时跑：去爬这个仓库的历史 PR 评论，看这个团队过去的人类审查者都在挑什么毛病，学出一份专属提示词，挂在审查 Agent 的系统提示后面。

第二种叫 continual，每天定时跑一次，时间按仓库名打散在一个固定时段里，免得所有仓库挤在同一分钟。逻辑更有意思。它去读自己过去提的每一条意见最后怎么样了，分成两堆：

这里有一条防过拟合的规矩：只认重复出现的，不认一次性的。原话是一条被驳回的意见是噪声，同一类被驳回好几次才算一条规则。

还有两条克制的设计。一是这一晚是在改现有提示词，不是重写，保留还成立的、加强被证实的、软化被推翻的。二是如果这一轮压根没有新结局可读，要求原样存回去，并且在小结里说明这轮没变，不许因为「总得改点什么」把提示词改差。

47% 这个跑分，公开榜单上没有这条记录

LangChain 给出的成绩是这样：在离线代码审查基准上，OpenSWE Review 跑 GPT-5.5 中等推理档拿到 47%，排名第 6，在开源代码审查 Agent 里排第 1。

这个基准是真实存在的，由 Martian 维护，用 50 个藏着难找 bug 的 PR 来考，公开榜单上标的是跨 1050 个已评分 PR。本站打开榜单核对了一遍，结果分两半。

榜单上没有 OpenSWE 这一条。当前公开榜单列出 21 个工具，从第 1 名 Cubic Dev 到第 21 名 Graphite，里面没有 OpenSWE Review。榜单页面标注的数据日期是 2026 年 6 月 24 日，早于 7 月 18 日。

但 47% 这个位置对得上。把 47% 放进现有榜单，正好卡在第 5 名 GitLab Duo 的 48.3% 和第 6 名 macroscope 的 46.0% 之间，落位就是第 6，和这个说法对得上。

这个分是怎么来的，仓库里有答案

open-swe 仓库里有个 evals/reviewer/ 目录，把这道题整套搬回了自己家：那 50 个 PR、136 条参考答案全部从基准仓库抄进来（平均每题 2.72 条），配了建数据集的脚本、跑测的脚本，以及一个用大模型做逐条比对的判官。

所以 47% 的来路是清楚的，它是自己在本地跑同一套题得的分，不是提交给榜单方评的。榜单上查不到这条记录，和这个分数有没有依据，是两回事。而且这套工具是公开的，谁都能拉下来自己跑一遍。

不过跑测时用的配置和真跑在你仓库上时不完全一样，有两处差别值得知道。

另外跑测说明里写着一条前置要求：给这 5 个仓库各跑一遍风格分析再开始评分。也就是说这个分很可能是带着上一节那套自学习层跑出来的，不是裸判据的成绩。

还有一个能看出这类工具取舍的数字：榜单第 21 名 Graphite 的准确率是 100%，它报出来的问题条条属实，但召回率只有 8.8%，一百个 bug 里它只挑出九个。上一节那套严苛判据卡的就是准确率这一头，卡得越严，漏掉的也越多。6 条上限压的也是同一头，而题目平均每道有 2.72 条参考答案。

OpenWiki 给自己写的那份文档，现在和代码对得上吗

四个工具里最后一个管的是仓库文档。它要解决的是这么件事：Agent 每次跑起来都得重新摸一遍这个仓库长什么样，摸一遍就烧一遍 token，还容易漏掉团队的规矩。

npm install -g openwiki
openwiki --init

产物是仓库里一个 openwiki/ 目录，一堆带 YAML 头的 Markdown。格式用的是 Google 提出的 Open Knowledge Format，目前是 0.1 草案版，规范本身很薄：一个目录的 Markdown 文件，必填字段只有一个 type，文档之间用普通 Markdown 链接表达关系。

OpenWiki 的命令行界面。这张截图透露了三件事：截图时版本还是 v0.0.0；模型走 OpenRouter 上的 z-ai/glm-5.2，是开源模型；工作目录叫 agent-docs，是这个项目的内部代号。来源：Brace Sproul 推文

三道不让 AI 写飞的护栏

让 AI 写文档不新鲜，难的是让它别写飞。OpenWiki 的做法是把「判断和写作」交给模型，把「边界和索引」交给确定性代码。

再加上一串写进提示词的预算：首次生成最多 8 页；一次更新里如果改动的源文件少于 5 个，最多只许动 1 到 2 页文档；不许做纯格式化的改动；以及明确允许这次什么都不改，直接说一句文档已经是最新的。

自动更新的实际机制

官方给的 CI 配置是每天 08:00 UTC 定时跑一次，加一个手动触发，没有按提交或按 PR 触发。跑完把改动开成一个 PR。

跑之前有一道确定性的空转检测：如果自上次更新以来 HEAD 没变、或者变动的文件全都在 openwiki/ 目录里（也就是上一个文档 PR 自己），就直接跳过，一次模型都不调。跑完还有一道内容哈希对比，内容没变就连时间戳都不写，免得每天开一个只改时间戳的 PR。

判断「哪些页面过期了」这件事，靠的是把两次更新之间的 git 变更清单交给模型，让它自己建立「哪个源文件改了、对应哪页该改」的映射。仓库里没有页面到源文件的持久依赖图。

把它自己那份 wiki 对着代码核一遍

OpenWiki 在自己的仓库里用了自己，产物就在 openwiki/ 目录里，任何人都能下载下来核对。元数据文件记录的上次更新是 2026 年 7 月 19 日，用的模型是 GLM-5.2。核对结果如下，每条都给了复现方法。

grep -rn "ensureProviderKey" src/ test/          # 0 条
grep -n  "ensureProviderCredentials" src/agent/index.ts
sed -n '71,84p' src/constants.ts                 # 看 provider 类型定义
grep -rn "vertex" openwiki/                      # wiki 里的残留
ls LANGSMITH-CONNECTOR.md CODING-AGENTS-CONNECTOR.md
cat openwiki/.last-update.json

这和上面那套更新机制是对得上的：更新只看两次跑之间的 git 变更窗口，一个页面如果在它相关的源文件被改动的那一轮里没被模型联想到，窗口滑过去之后就不会再有人回头查它。vertex 这个选项被合并掉的事发生过，wiki 里三个文件、总共十六处提到它的地方，一处没改。

同样的漂移不只发生在 OpenWiki 身上，隔壁 open-swe 仓库更明显。那里给 AI 看的说明书 AGENTS.md 写着仓库有三个图入口，实际的 langgraph.json 里现在是五个，路径也换了位置。更整齐的一处是：AGENTS.md 用一整段详细描述了一套「CI 挂了自动修」的子系统，写明它住在 agent/ci_autofix.py 这个文件里、由一个叫 ci_monitor 的程序定时扫、跳过规则有哪些，写得像模像样。这个文件和那个程序，仓库里都找不到。

这恰好说明 OpenWiki 想解决的是个真问题。但两处漂移的性质不一样，值得分开看：手写那份凭空描述出一整套不存在的子系统，是编造；机器生成那份是改名之后没跟上，是滞后。前者会把读它的人和 Agent 直接带沟里，后者至少还指着一个真实存在过的东西。

OpenWiki 的完整主张其实就建立在这个区别上，而且它把主张写进了代码：跑起来的时候，它会主动往你仓库的 AGENTS.md 和 CLAUDE.md 里塞一段带起止标记的内容，没有就建，有就原地刷新，内容是一句「本仓库的说明看 openwiki/quickstart.md，别手改生成的页面」。

它真正想干的事情是把人手写的那份降级成一个指针，指针那头由机器每天刷，多写一份文档只是顺带的。上面那份 AGENTS.md 编造出整套 CI 子系统的例子，正好是这个主张最好的论据。

你想自己搭一套，得先准备什么

四个工具的门槛差得很远，不是装上就能跑。

OpenSWE 那一格值得展开说，因为它和前两个不是一个量级。安装文档列了十个顶层步骤，其中建 GitHub App 是纯手工的网页操作，安装 ID 要从浏览器地址栏里抠出来；本地开发至少要同时开两个终端，还得用 ngrok 把外部通知暴露到公网，没有离线调试的路子。光环境变量一节就列了五十多个，而仓库里没有一份 .env 模板可抄，得对着文档一条条手敲。

还有一道卡在审批上、不在技术上的门槛：默认的沙箱后端走 LangSmith，而这个沙箱权限不是注册就有，文档写的是如果沙箱接口返回 403，说明你的工作区没开这个权限，需要联系 LangSmith 客服。想绕开就换 Modal、Daytona、E2B、Runloop 这几家自己接，但「沙箱里不放真凭据」那套代理保护只有 LangSmith 后端有，换别家这层就没了。

另外，仓库里那份安全政策全文只有一句话：有安全问题请发邮件到某个地址。没有威胁模型，没有已知风险清单。对一个把全权限 Agent 接到 Slack 和 GitHub 公开评论上的项目，这一点自己评估的时候要心里有数。

五份官方素材，各自跑的什么模型

LangChain 说这套栈是为开源模型优化的，理由是成本。把能查到的官方素材摆在一起，各自实际跑的模型如下。

两处跑开源模型的是文档工具和演示视频，三处跑闭源模型的是两张产品截图和那个成绩。OpenSWE 代码里写死的默认模型是 openai:gpt-5.5 中等推理档，跟那个 47% 用的是同一套配置。

换模型这条路是真的通：OpenSWE 支持的模型有 11 个，里面有三个跑在 Fireworks 上的开源模型；OpenWiki 支持 12 家 provider，还能接 Ollama 和 LM Studio 跑本地模型。所以「为开源模型优化」这句话，准确的读法是这套栈没有绑死闭源接口，而不是它默认就跑开源模型。

把这些代码读完，最值得带走的东西其实跟具体哪个工具没关系。是那套反复出现的手法：凡是不能指望 AI 自觉的事，就交给确定性代码去卡死。

这套手法在四个工具里出现了七八次。写入路径由后端拦，报 bug 的行号由工具当场校验，目录索引不许模型碰，学出来的审查风格只能在硬判据之内微调，改 CI 配置必须停下来等人点头，开 PR 只许走正门。还有一条形状不同但同源的：看的范围放开，报的范围收死。AI 负责判断和写作，边界由代码划死。

这套东西跟写代码本身没多大关系。任何要把 Agent 放进真实流程的人都能照抄，包括判断该在哪里留一道人工闸门。至于这四个工具各自的成色，上面那些核对结果都摆在那儿了，够你自己判断。

这套手法本身跟编码没关系，任何要把 Agent 放进生产流程的人都能抄。至于四个工具各自成色如何，上面那些核对结果摆在那里，够你自己判断。

2026 年 7 月 18 日，LangChain 把自家内部在用的四个编码 Agent 一次性开源。思路不是把终端里那个做得更强，而是按「工作从哪来」拆成四个，各守一个入口：dcode 守终端，OpenSWE 守 Slack 和任务系统，OpenSWE Review 守代码审查页，OpenWiki 守仓库里那份说明书。

光从 Slack 这一个入口，LangChain 上周就触发了近 1000 次。但把 AI 放到没人盯着的位置，新麻烦马上来了：它自己开的改动谁来审，它乱说话怎么办，它写的文档过期了谁知道。

四个工具里最见功夫的是审查那个。它读别人提交的改动、挑毛病，最容易犯的病是话多，一堆「这里可以改个名」「万一将来有人传 null 呢」，真问题淹在里面。LangChain 的解法是把「看」和「报」拆成两把尺子。

开头那个 Safari 白屏，走老路和走 OpenSWE 各要多久：

使用量和 47% 都是 LangChain 自述。本站去那份公开榜单核对过：当前 21 个工具的名单里没有 OpenSWE 这一条，榜单标注的数据日期还早于发文日；但 47% 确实会卡在第 5 名的 48.3% 和第 6 名的 46.0% 中间，落位对得上。这个分是它自己在本地跑同一套题得的，不是提交给榜单方评的，工具是公开的，谁都能拉下来自己跑一遍。