DeepSeek Harness 爆火之后，我翻完 X 上的讨论，真正值得关注的不是「万物皆插件」

前几天打开 X，DeepSeek Harness 几乎刷屏了。

「万物皆插件」「开源版 Claude Code」「Agent 领域的操作系统」「DeepSeek 要把 Coding Agent 行业干掉了」，类似的判断一条接一条。最夸张的帖子，已经开始拿 Claude Code 每月 200 美元的计划做对比，仿佛一个开发者预览版刚发布，整个市场就结束了。

说真的，我对这种叙事一直有点警惕。

一个项目刚出来时，X 最擅长把架构潜力写成已经发生的产品事实。可当我把官方介绍、GitHub README、几位开发者的讨论和已经暴露的问题放在一起看，发现这次热度下面确实有东西。

只是那个东西，不是「DeepSeek 又做了一个 Coding Agent」。

真正值得关注的是，DeepSeek 把 Agent 自己也拆成了可以编程、替换和回放的运行时。

这篇文章不再重复它几天涨了多少 star。博客前两篇趋势日报（《dsh 屠榜，插件长得比官方文档还快》和《DeepSeek Harness 破 11 万星，72 小时长出一个生态》）已经记录了那场生态爆发。我们换个角度，看看 X 上的人到底在聊什么，哪些判断有含金量，哪些只是流量话术。

先把 Harness 讲明白

很多人第一次看到 Agent Harness，会把它理解成「套在模型外面的壳」。

这个说法不能算错，但太轻了。

模型负责预测下一个 Token。它本身不知道你的项目放在哪里，也不知道怎么执行 Shell、修改文件、请求网页，更不会天然记住一个持续两小时的开发任务做到了哪一步。

这些能力都来自 Harness。

一个能工作的 Coding Agent，至少需要下面几层东西。

用户任务
   ↓
上下文构建与权限控制
   ↓
Agent Loop
   ↓
模型推理
   ↓
工具选择与执行
   ↓
文件、Shell、搜索、浏览器
   ↓
结果写回上下文，进入下一轮

Claude Code、Codex、Cursor、OpenCode 都有自己的 Harness。它们的模型可以很强，但真正决定日常体验的，往往是上下文怎么装、工具怎么调、失败后怎么恢复、长任务会不会跑偏，以及权限是否安全。

所以有一个越来越重要的公式。

Agent = Model + Harness

同一个模型放进不同 Harness，表现可能完全不同。就像同一颗发动机放进赛车、越野车和卡车，最后跑出来的结果不能只归功于发动机。

这也是 DeepSeek 这次选择开源 Harness，而不是只发布一个模型 API 的原因。它想进入的不是单次推理层，而是模型如何在真实环境里持续工作的那一层。

X 上讨论最多的第一件事，万物皆插件

DeepSeek 官方给出的口号是「Everything is a Plugin」。

传播最广的帖子基本都在复述这句话。可真正有意思的地方，不是它支持插件，而是插件化的边界特别深。

在多数 Agent 产品里，模型和外部工具可以替换，但核心循环、Session 组织、上下文管理和 UI 仍由产品写死。DeepSeek Harness 建在 Cordis 元框架之上，试图把下面这些东西全部变成插件。

前八项很好理解。真正让我停下来多看了一会儿的是最后一项。

连 Agent Loop 都是插件。

这不是普通意义上的扩展点，而是在说，一个 Agent 到底如何思考和行动，也可以被替换。

Agent Loop 被插件化，才是这次最硬的设计

典型的 Agent Loop 大概是这样。

读取任务
→ 组装上下文
→ 调用模型
→ 判断是否使用工具
→ 执行工具
→ 把结果写回上下文
→ 再次调用模型
→ 直到完成或触发停止条件

很多 Coding Agent 的核心差异就藏在这个循环里。

有的先写计划再执行，有的边探索边改文件，有的每完成一步都做验证，还有的会同时派出多个子 Agent，最后由主 Agent 汇总。

以前想实验这些策略，通常要改框架核心代码。DeepSeek Harness 把 Loop 也做成插件之后，开发者可以组合出不同运行模式。

比如面向日常开发的完整模式，带文件、Shell、搜索、Skills 和子 Agent。面向模型评测的 Minimal Mode，只保留 Shell 和文件编辑。还有 Code Mode，让模型生成 TypeScript 程序，一次编排多轮工具调用。

你想想看，这里变化最大的是什么？

过去我们扩展 Agent，主要是在给它增加工具。现在可以直接改它「如何工作」。

这是从 Tool Plugin 走向 Runtime Plugin。

工具插件解决「Agent 能做什么」，Loop 插件解决「Agent 怎么把事情做完」。后者的上限明显更高，调试成本也更高。

Code Mode，不只是一轮调用一个工具

Code Mode 是 X 上讨论不算最多，但我认为很值得 AI Builder 关注的一块。

普通工具调用通常是模型发出一个请求，Harness 执行后把结果塞回上下文，再让模型决定下一步。

假设任务是搜索 20 个项目、读取每个项目的元数据、过滤 star 数、提取 README，再汇总结果。一步一轮的 Agent 会产生大量模型往返，工具结果也会反复进入上下文。

Code Mode 换了一种做法。模型生成一段 TypeScript 编排逻辑，由程序完成循环、并发、过滤和结果组合。

const repos = await searchRepositories(query);

const details = await Promise.all(
  repos.slice(0, 20).map(repo => fetchRepository(repo))
);

const selected = details
  .filter(repo => repo.stars > 1000)
  .sort((a, b) => b.stars - a.stars);

return selected.map(toSummary);

模型不需要为每一个仓库单独「思考一次」。机械工作交给代码，模型只参与策略和结果解释。

这个思路可以减少模型轮数、上下文膨胀和工具调用延迟。但它也会带来新问题，模型生成的编排代码怎么限制权限，循环失控后如何终止，并发子任务如何控制预算，异常发生时怎样保留可恢复状态。

灵活性从来不是免费的。

第二个高频话题，Codex 和 Claude Code 居然能成为子 Agent

DeepSeek Harness 支持通过不同 provider 调用其他 Agent。X 上传播最广的一个点，就是它可以把 Codex、Claude Code，甚至另一个 DeepSeek Harness 实例作为子 Agent。

这让竞争关系变得很微妙。

它不一定是下面这种替代关系。

DeepSeek Harness vs Codex vs Claude Code

也可能变成下面这种组合。

DeepSeek Harness
├── DeepSeek，低成本搜索、规划和批处理
├── Codex，大规模代码修改与工程执行
├── Claude Code，代码分析和审查
└── 专用 Agent，测试、文档与发布

上层 Harness 负责拆任务、分配预算、约束权限、记录轨迹。底层 Agent 各自完成擅长的部分。

这个思路很像云计算。AWS、Cloudflare 和数据库厂商彼此竞争，却也可以同时出现在一套系统里。Agent 市场以后可能也是这样，模型和 Coding Agent 不只互相替代，还会成为更高层编排系统里的执行节点。

现在就断言 DeepSeek Harness 会取代 Codex，明显太早了。

它甚至可能反过来扩大 Codex 和 Claude Code 的使用场景。

第三个值得关注的设计，每一次运行都能追溯

Agent 最让人抓狂的问题，很多时候不是它做错了，而是你不知道它为什么做错。

它当时看到了哪些文件？哪一段系统提示影响了决定？网页里的恶意内容有没有注入上下文？子 Agent 返回了什么？某次压缩上下文时又丢掉了什么？

普通聊天记录回答不了这些问题。

DeepSeek Harness 使用 append-only Session Log，把模型看到和执行过的内容记录到同一条事件流中，包括系统提示、模型输出、工具调用及返回结果、上下文注入、子 Agent 调度和 Session 状态变化。

基于同一条事件流，它可以实现搜索、继续、分叉与回放。

Event 01  创建 Session
Event 02  注入系统提示
Event 03  读取 AGENTS.md
Event 04  模型请求搜索代码
Event 05  返回搜索结果
Event 06  调度子 Agent
Event 07  子 Agent 返回分析
Event 08  修改文件
Event 09  运行测试

这有点像 Git、数据库 WAL 和 Redux DevTools 的结合。

Git 让代码变更可追踪，WAL 让状态可以恢复，Redux DevTools 让前端状态变化可以回放。Agent 的事件日志则试图回答另一组问题，它看见了什么，调用了什么，在哪一步走偏，以及能否从那个节点重新开始。

对于个人 Coding Agent，这能降低排错成本。对于企业 Agent，它还关系到审计、权限追责和安全事件调查。

我一直觉得，可观测性不是 Agent 的附属功能。Agent 能操作真实文件和系统后，它就是运行时的核心能力。

X 上最容易被忽略的一条线，Benchmark 已经不能只看模型

DeepSeek 披露，部分 Code Agent 成绩是在自己的 Harness Minimal Mode 中测得。这在 X 上引出了一个很好的问题。

模型成绩高，到底是模型更强，还是模型与 Harness 配合得更好？

如果模型训练时已经熟悉特定工具格式、文件编辑方式、错误反馈和循环策略，它放进自家 Harness 后自然更容易发挥能力。换成另一套工具协议和上下文组织方式，结果可能就变了。

所以以后看到 Agent Benchmark，至少要把五个变量一起看。

Model + Prompt + Tools + Harness + Budget

Model 是模型本身。Prompt 决定角色与约束。Tools 决定它能操作什么。Harness 决定循环、上下文和反馈。Budget 则限制 Token、时间、并发数与重试次数。

少写任何一项，评测都可能失真。

这也是「Agent = Model + Harness」最现实的影响。模型能力正在被运行时放大或压制，单独比较模型参数和榜单分数，已经不够用了。

X 上也有不少冷水，而且泼得有道理

热度最高的时候，最需要看的不是赞美，而是反例。

一类冷静观点认为，Codex 和 Claude Code 已经是完整产品，DeepSeek Harness 目前更像构建这些产品的基础设施。它有很强的可塑性，却还没有同等级的默认体验、稳定性和安装完成度。

这个判断比较准确。

官方 README 明确标注 Developer Preview，并提醒会出现破坏性兼容变更。GitHub Discussions 里已经能看到 Session 卡死、工具查询没有超时、Replay State 不一致和并发子 Agent 导致内存压力等问题。

这些问题并不说明架构失败。一个刚公开的运行时出现 bug 很正常。它们只是在提醒我们，不要把「架构上能做到」等同于「产品上已经可靠」。

不是一个概念。

插件越自由，供应链风险越大

「万物皆插件」听着很爽，但插件可以触碰模型上下文、文件、Shell、网络和凭据。一个恶意插件能够做的事情，远比换一个编辑器主题严重。

DeepSeek 自己的安全政策也建议使用容器或虚拟机、限制权限、高风险操作保留人工确认，并且只安装经过审查的插件、MCP Server、Skills 和 Hooks。

当社区插件在几天里成百上千地出现时，数量不是唯一指标。更关键的是权限声明、来源验证、代码审查、版本锁定、撤销机制和运行隔离。

Agent 插件市场如果没有这些基础设施，很容易从生态优势变成供应链事故现场。

低模型单价，不等于低任务成本

X 上已经出现「DeepSeek Harness 比 Codex 省 Token」的体验分享，也有第三方测试在复杂任务里消耗数千万 Token。

这两种说法可以同时成立。

一个 Agent 任务的真实成本接近下面这个乘法。

模型单价
× 调用轮数
× 上下文长度
× 子 Agent 数量
× 重试与反思次数

便宜模型可以降低单次调用价格，多 Agent 并发和失控循环又会把总量放大。缓存命中可以省钱，一个半夜不停止的 bug 也能把省下来的全部烧掉。

所以评估 Harness 时，别只比较每百万 Token 的价格。应该比较完成同一组可验证任务的总成本、耗时、成功率和人工接管次数。

任务完成成本，才是真指标。

怎么判断这次热度是不是昙花一现

我给自己列了五个观察点，接下来一两个月可以继续看。

还有一个更直接的验证方法。

给它一个真实项目，让它连续工作两小时。记录 Token、耗时、修改质量、测试通过率、错误恢复次数和人工干预次数。然后用 Codex、Claude Code 或你现有的工作流跑同一个任务。

别只看 Demo。

Demo 展示上限，重复实验才告诉你下限。日常生产力往往由下限决定。

对 AI Builder 有什么启发

DeepSeek Harness 不一定会成为最后的赢家，但它把几个方向同时推到了台前。

MCP 解决 Agent 如何连接外部工具。Skills 负责沉淀可复用的知识、流程和约束。Harness 则进一步管理 Agent 如何循环执行、保存状态、调度其他 Agent，以及如何被审计。

三者放在一起，大概是这样的关系。

MCP       统一工具连接
Skills    统一经验与流程
Harness   统一运行时与组合方式

对独立开发者来说，最值得做的可能不是再造一个聊天界面，而是做 Harness 周围那些重复出现的基础设施。

比如跨 Session 的项目记忆、上下文压缩、成本与缓存仪表盘、插件权限审计、可复现 Benchmark、任务回放、失败恢复，以及面向特定领域的 Agent Preset。

这些东西不依赖某一代模型。

模型会换，运行时里的工程问题会一直留下。

写在最后

翻完 X 上这轮讨论，我的判断没有「DeepSeek 杀死了 Coding Agent 行业」那么刺激。

DeepSeek Harness 现在更像一个可编程的 Agent 运行时，不是已经成熟的 Codex 或 Claude Code 替代品。它最有价值的三件事，是把 Agent Loop 也变成插件，用事件流记录每一次上下文和工具变化，以及让其他 Coding Agent 成为可编排的执行节点。

「万物皆插件」很容易传播。

真正难的是，当插件数量膨胀、Session 跑上几个小时、子 Agent 同时工作、预算开始失控时，这套系统还能不能保持稳定、安全和可解释。

这才是接下来该盯的地方。

如果它能把这些问题处理好，Agent 领域的竞争焦点可能真的会变。大家争的不再只是谁的模型更强，而是谁能把模型、工具、Skills 和其他 Agent 组织成一套可靠的工作系统。

模型是发动机。

Harness 开始争夺整辆车。