dcode 相关的核心要点是什么？

本文围绕 dcode、Deep Agents、LangChain、Claude Code、Codex CLI、AI Coding Agent 展开，拆解 LangChain 开源终端编码 Agent dcode 与 Claude Code、Codex CLI 的差异与选型建议。详细解读见正文。

dcode 深度对比：LangChain 的终端编码 Agent 凭什么不一样

2026-10-16T23:30:00+08:00

dcodeDeep AgentsLangChainClaude CodeCodex CLIAI Coding Agent

终端编码 Agent 已经卷成一团——dcode 的赌注是：harness 归你，模型也归你。

先说结论：如果你把 Claude Code、Codex CLI、Gemini CLI、OpenCode 摆一排，会发现它们长得越来越像——一个 REPl、一堆文件工具、一个权限弹窗、一个 while 循环。差别藏在更里面：谁拥有那个循环，谁能换模型，谁能在别人的机器上执行工具。

LangChain 在 2026 年 8 月放出了 dcode（Deep Agents Code），官方主页的 slogan 就一句：「The coding agent you own」。它没有去卷 benchmark 分数，而是把赌注压在两件事上：开源可改的 harness，和完全模型无关。这篇文章不讲虚的，把 dcode 和主流终端编码 Agent 逐项拆开对比，告诉你它到底哪里不一样、哪里一样、以及哪些场景它并不占优。

本文提纲

dcode 是什么：它不是又一个套壳 REPl
快速上手：一条 curl 命令
差异一：模型无关，harness 自持
差异二：sandbox-as-tool，工具调用跑在远端
差异三：审批三模式与 Auto 分类复核
差异四：Goals 与 Rubrics，把验收标准写进循环
差异五：Agent 记忆、Skills 与可扩展内核
横向对比表：dcode vs Claude Code vs Codex CLI vs OpenCode
失效边界：它不占优的地方
什么时候该选它

dcode 是什么：它不是又一个套壳 REPl

dcode 是 LangChain 开源的终端编码 Agent，构建在自家 Deep Agents SDK 之上，MIT 许可证。仓库在 github.com/langchain-ai/deepagents，代码位于 monorepo 的 libs/code/ 目录，PyPI 包名 deepagents-code。

先把最容易误解的地方说清楚：dcode 和「给某个 CLI 套一层壳」不是一回事。它的底层是 Deep Agents SDK——一套已经装好上下文压缩、subagent 派发、长期记忆、human-in-the-loop 的 agent harness。dcode 是在这套 harness 上再包一层终端交互界面。

官方 README 里有一句非常诚实的致谢：

This project was primarily inspired by Claude Code, and initially was largely an attempt to see what made Claude Code general purpose, and make it even more so.

翻译过来就是：它是照着 Claude Code 的经验反推出来的，目标是搞清楚「Claude Code 为什么能通用」，然后让它更通用。这句话很关键——它解释了后面所有差异的由来。作者不是在造一个更好的 Claude Code，而是在问：如果把这个能力从 Anthropic 的模型和闭源外壳里解耦出来，会发生什么。

截至 PyPI 2026-08-19 的校验数据，仓库约 27,990 star、3,917 fork；包版本 0.1.58，标注 Development Status 4 - Beta，要求 Python >=3.12,<4.0。Beta 这两个字别忽略，后面「失效边界」会展开。

快速上手：一条 curl 命令

安装方式也是它跟其他工具的一个差异点——单命令脚本安装，不依赖 npm 全局包：

curl -LsSf https://langch.in/dcode | bash
dcode

可选加装 provider 和沙箱扩展：

export DEEPAGENTS_CODE_EXTRAS="nvidia,ollama"

跑起来之后，交互模式里是一套斜杠命令。和 Claude Code 的 / 命令类似但覆盖更细，挑几个有代表性的：/model 换模型、/effort 调推理强度、/goal <objective> 设目标、/rubric 设评分标准、/remember 存记忆、/skill-creator 现场造技能、/offload（别名 /compact）压缩上下文、/mcp 管理 MCP server、/trace 看 LangSmith 追踪。Shell 模式用 ! 前缀。

非交互（headless）模式对 CI 很友好：

dcode -n "fix the failing test in tests/test_api.py" --max-turns 20 --timeout 300

--max-turns 超限返回 exit 124，--timeout 同理。注意非交互模式默认禁用 shell 执行，要用 -S/--shell-allow-list 显式放行（"pytest,git,make"、recommended 或 all）。

差异一：模型无关，harness 自持

这是 dcode 最大的差异化，也是它「凭什么不一样」的核心答案。

Claude Code 只能用 Anthropic 的模型，Gemini CLI 绑定 Google，Codex CLI 依赖 OpenAI 的 GPT 系列。dcode 理论上可以用任何支持 tool-calling 的 LLM——它的 extra 列表里躺着一长串 provider：anthropic、openai、google-genai、bedrock、vertex、mistralai、deepseek、groq、ollama、nvidia、xai、openrouter、litellm、huggingface、together、fireworks、baseten、cohere、perplexity、ibm、meta……

这件事的意义不只是「省钱」。它意味着：你的 harness 不绑定某个厂商，你的模型也不绑定。今天用 Claude，明天用本地 Ollama 跑一个开源模型，后天换 Nvidia 的 Nemotron 做私有部署——工具链、记忆、Skills、配置文件全部原地不动。对需要数据不出内网、或者想规避单一供应商风险的团队，这是 Claude Code 给不了的。

官方文档里那句 slogan「you own」，落点就在这：harness 在你自己机器上跑，模型你自己选，代码 MIT 随便改。

graph LR
    subgraph DC["dcode"]
        H["Own Harness"]
    end
    subgraph Models["Any Tool-Calling LLM"]
        M1["Anthropic"]
        M2["OpenAI"]
        M3["Google"]
        M4["Ollama Local"]
        M5["Nvidia Nemotron"]
        M6["100 plus providers"]
    end
    H --> M1
    H --> M2
    H --> M3
    H --> M4
    H --> M5
    H --> M6

对比之下，Claude Code 是「厂商模型 + 厂商 harness」的垂直整合，dcode 是「任意模型 + 自有 harness」的横向解耦。这两种路线没有绝对高下——垂直整合换来的是开箱即用的体验和调优到极致的 prompt，解耦换来的是自由度和可替换性。要看你更怕哪一种锁定。

差异二：sandbox-as-tool，工具调用跑在远端

多数终端 Agent 的执行模型是这样的：Agent 进程跑在你的机器上，文件读写和命令执行也在你的机器上。沙箱（如果有）是把整个 Agent 关进去。

dcode 的远程沙箱走的是另一条路，官方文档叫 sandbox-as-tool 模式：dcode 进程本身（LLM 循环、记忆、工具分发）留在本地，但工具调用被转发到远端沙箱执行。read_file、write_file、execute 这些动作实际发生在远端机器上。

好处很直接：你可以在自己的笔记本上跟 Agent 对话，而所有危险操作（改文件、跑命令、装依赖）都发生在一个隔离环境里。官方内置了一批 provider：

LangSmith（默认内含，工作目录 /root）
AgentCore（/tmp）
Daytona（/home/daytona）
Modal（/workspace）
Runloop（/home/user）
Vercel（/vercel/sandbox）
第三方 E2B（/home/user，走 langchain-e2b 包）

启动方式：

dcode --sandbox daytona

甚至支持三种来源的 provider：内置、第三方 entry-point（deepagents_code.sandbox_providers）、以及 config 声明（[sandboxes.providers.<name>]，带 class_path、working_dir、params）。优先级是 config > 第三方 > 内置。

这跟 Claude Code 的模型差别在哪？Claude Code 也有沙箱，但它的沙箱是「把 Agent 整个搬进去」；dcode 是「Agent 留在原地，手伸进沙箱」。对需要保留本地文件上下文、又想让执行环境干净可抛弃的场景，后者更顺手。官方在 libs/code/THREAT_MODEL.md 里也写明了安全立场：默认信任当前运行目录，不受信任的仓库建议上远端沙箱。

差异三：审批三模式与 Auto 分类复核

每个编码 Agent 都有权限弹窗，但 dcode 的三档设计值得单独说：

Manual（默认）：每个 gated action 都弹窗问你。
Auto（dcode -y）：例行操作自动放行；对不确定的动作，用一个分类模型复核后再决定；如果连续被拒，自动回退到人工。
YOLO（dcode --yolo）：完全无审核，需要一次性风险确认。

gated actions 包括 write_file、edit_file、delete、execute、web_search、fetch_url、task；而只读工具（ls、read_file、glob、grep）永远不弹窗。这个「只读不拦、写入才拦」的划分，比一刀切拦所有操作要合理得多。

Auto 模式里那个分类模型是亮点，默认配置：Anthropic → anthropic:claude-sonnet-5、Google AI → google_genai:gemini-3.8-flash、OpenAI → openai:gpt-5.6-luna。它做的事情是：对高风险动作再判一次。但官方明确说 Auto 不是安全边界——它只是降低打断频率的便利层，真正的隔离要靠沙箱。

还有个细节：Auto 只在交互式、非沙箱会话可用；一旦你用 --sandbox，会强制回退到 Manual。非交互模式下 -y/--yolo 被忽略。这些约束背后是同一个逻辑——别让自动化在无人值守时放开手脚。

差异四：Goals 与 Rubrics，把验收标准写进循环

这是我认为 dcode 最不像「其他编码 Agent」的地方。

大多数 Agent 的终止条件很朴素：模型觉得干完了就停。dcode 引入了一套显式的目标与评分机制：

/goal

你给一个客观目标，Agent 会自己起草验收标准，然后这个目标跨越多个轮次持续存在，直到达成或你手动清除。配套命令有 /goal amend|pause|resume|show|clear，还能 /goal model 和 /goal max-iterations 调整。

评分侧是 /rubric set|next|file：你把「什么叫做好」写成 rubric，Agent 用它对每个产出打分，不达标就继续迭代。非交互模式对应 --rubric、--rubric @file、--rubric-model、--rubric-max-iterations。

把「验收标准」显式写进循环，和「让模型自己判断」是两种完全不同的工程哲学。前者适合有明确判定标准的任务（比如「所有测试通过」「这个重构不改变公开 API」），能让 Agent 自己知道自己还没做完。Claude Code 的 TodoWrite 更偏任务清单，dcode 的 goal + rubric 更接近一套轻量的自动评估回路。官方博客提到，dcode 被用作 NVIDIA NemoClaw 治理蓝图的一部分，跑在 Nemotron 3 Ultra 上——这类「可证明做对了」的场景，正是 rubric 机制的用武之地。

差异五：Agent 记忆、Skills 与可扩展内核

dcode 的 profile 目录默认在 ~/.deepagents/，里面放着 config.toml、hooks.json、.mcp.json、.env 等。这套配置体系有几个值得注意的点：

分层配置：优先级是 managed_config.toml（管理员）> DEEPAGENTS_CODE_ 前缀环境变量 > 规范环境变量 > ~/.deepagents/config.toml > 内置默认。企业可以下发强制配置。
Python extensions：可以写 Python 扩展直接改 Agent 行为，这是「开源可改」的落地方式。
Skills：/skill:<name> 调用，/skill-creator 现场创建，遵循开放的 Agent Skills 标准。
记忆：/remember [context] 存跨会话记忆，基于 AGENTS.md 这类文件格式。
MCP 工具：/mcp 管理 server，和 Claude Code、Codex CLI 一样支持。
LangSmith tracing：/auth 加 key 后，下一次启动起所有 agent 调用和 shell 命令都有 trace；还能用 DEEPAGENTS_CODE_LANGSMITH_PROJECT 分开 agent trace 与 shell trace。

安全上有个细节做得比较克制：环境变量封锁清单明确禁止 dotenv 设置 DEEPAGENTS_HOME、DYLD_INSERT_LIBRARIES、NODE_OPTIONS、PATH、PYTHONPATH、GIT_* 等敏感项。DEEPAGENTS_HOME 被视为信任边界，只能在继承的 shell 环境里设置，不能由 .env 更改。这种「默认防注入」的设计，比很多同类工具考虑得更细。

对比来看：Claude Code 的扩展靠 MCP 和 hooks，Codex CLI 是开源的但更偏「OpenAI 的参考实现」，OpenCode 走 TypeScript/Bun 的客户端-服务器架构。dcode 走的是 Python 内核 + 可编程扩展 + 开放 Skills 标准这条路，扩展深度更接近「在 framework 上二次开发」。

横向对比表：dcode vs Claude Code vs Codex CLI vs OpenCode

把主流终端编码 Agent 摆在一起。请注意：下表竞品信息部分来自第三方行业综述（见文末来源），非官方数据，仅作方向性参考；dcode 一列基于官方文档。

维度	dcode	Claude Code	Codex CLI	OpenCode
维护方	LangChain	Anthropic	OpenAI	SST / Anomaly
许可证	MIT（开源）	本体闭源	开源（Apache-2.0）	MIT（开源）
模型	任意 tool-calling LLM，100+ provider	仅 Anthropic	绑定 OpenAI GPT 系列	75+ provider
harness	开源可改（Python extensions / hooks / managed config）	闭源	开源（Rust）	开源（TypeScript/Bun）
执行模型	sandbox-as-tool：Agent 本地、工具远端	Agent 跑在沙箱内	云端沙箱、异步 PR	客户端-服务器
沙箱 provider	LangSmith / Daytona / Modal / Runloop / Vercel / AgentCore / E2B	内置	内置云端	依配置
审批模式	Manual / Auto（分类复核）/ YOLO 三档	多档权限模式	审批流程	权限确认
目标与验收	Goal + Rubric（LLM 打分迭代）	TodoWrite 任务清单	无显式 rubric	无显式 rubric
追踪	LangSmith 原生	内置	内置	可接第三方
本地模型	支持（Ollama 等）	不支持	不支持	支持
平台	macOS / Linux（Windows 需 WSL）	多平台	多平台	多平台
成熟度	Beta（0.1.x）	生产级	较成熟	活跃

一句话读这张表：如果你要的是「开箱即用的最强单体体验」，Claude Code 仍然领先；如果你要的是「harness 归我、模型归我、能塞进自己的治理体系」，dcode 是目前最彻底的选择。

失效边界：它不占优的地方

诚实地讲 dcode 的短板，否则就是软文了。

第一，Beta 状态。 0.1.x 版本号意味着 API 和行为都可能变，PyPI 上明确标着 Development Status 4 - Beta。把它放进关键生产链路之前，先在自己的场景里压测。

第二，Windows 非官方支持。 官方说法是 Windows 需要 WSL。如果你是纯 Windows 团队，这层额外的适配成本要算进去。

第三，模型无关是双刃剑。 换个模型就能用，不代表换个模型效果一样好。Claude Code 把 prompt 和工具描述针对 Opus/Sonnet 调到极致，dcode 要面对「同一个 harness 喂给不同模型，效果参差」的现实。用它跑非 Anthropic 模型时，做好调 prompt 和试错的准备。

第四，「原创性」的争议。 官方自己承认「primarily inspired by Claude Code」。这不是缺点，但它意味着 dcode 的很多设计你已经在 Claude Code 里见过——它的差异主要集中在模型无关、sandbox-as-tool、rubric 这几处，而不是整个体验的颠覆。

第五，远端沙箱有成本。 Daytona、Modal、Runloop 这些都是按用量计费的服务。sandbox-as-tool 很优雅，但每一次工具调用都过一次网络，延迟和账单都要考虑。纯本地任务其实用不上。

什么时候该选它

给几个具体判断：

选 dcode，如果你——

需要在多个模型之间切换，或要用本地/私有模型（数据不出内网）
想把编码 Agent 塞进自己的治理体系（managed config、LangSmith trace、Python 扩展）
需要远端沙箱跑不受信任的代码，又不想把整个 Agent 搬过去
有明确验收标准、想让 Agent 自己迭代到达标（Goal + Rubric）
团队有 Python 能力，愿意在开源 harness 上做二次开发

继续用 Claude Code，如果你——

要的是最省心的开箱体验，不想折腾模型和配置
团队以 Anthropic 模型为核心，垂直整合的调优更有价值
不想承担 Beta 版本的不确定性

继续用 Codex CLI / OpenCode，如果你——

已经深度绑定 OpenAI 生态（Codex），或者偏好 TypeScript 技术栈（OpenCode）

想快速建立体感，最快的路径是：curl -LsSf https://langch.in/dcode | bash 装上，跑起来，然后做三件事——用 /model 换一次模型，用 /goal 设一个验收目标，再用 --sandbox daytona 起一次远端沙箱。三个动作做完，dcode 和别的编码 Agent 的差异你就有手感了。

参考文档与链接

dcode 官方主页 — 「The coding agent you own」定位
dcode Overview — 能力卡片与定位
dcode Quickstart — 安装、斜杠命令、非交互 flags
dcode Configuration — 配置层级、环境变量、主题、自动更新
dcode Remote Sandboxes — sandbox-as-tool 与 provider 矩阵
dcode Goals and Rubrics — /goal 与 /rubric 完整命令
dcode Approval Modes — Manual / Auto / YOLO 与分类模型
Deep Agents vs. Claude Agent SDK — 官方横向对比表
PyPI: deepagents-code — 版本、许可证、依赖与仓库信息
GitHub: langchain-ai/deepagents — 源码仓库（代码在 libs/code/）
dcode THREAT_MODEL.md — 官方安全模型与信任边界
LangChain × NVIDIA NemoClaw 蓝图 — dcode 作为治理蓝图的落地
2026 May Coding Agents Landscape — 竞品数据第三方来源（Claude Code / Codex CLI / OpenCode / Pi 等）

你的团队现在用哪个终端编码 Agent？最看重的是模型自由、开源可改，还是开箱即用？评论区聊聊你的选型理由，觉得有用点个赞让更多人看到。

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

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