DeepSeek Harness 开源后，Graph Engineering 该换个讲法了

AI 发展快有一个好处。你还没学会的东西，可能很快就不用学了。

前段时间大家还在讨论 Loop Engineering，转头又冒出 Graph Engineering。很多人顺着这条线追问，Loop 和 Graph 到底是什么关系。

DeepSeek Harness 开源以后，这场争论突然显得有些窄。

DeepSeek 官方把 Agent Harness 做成了开源项目，首页先给出一条很短的公式。

Agent = Model + Harness

这句话把眼下的变化讲得更准。

模型负责理解、判断和生成。Harness 负责把模型放进一个能工作的环境里，给它工具、状态、权限、日志、沙箱和恢复机制。Loop 怎么跑，Graph 怎么连，都在这一层发生。

DeepSeek Harness 没给 AI 圈添一个悬空的新词。它把模型之外那套经常藏在产品内部的东西，完整摆到了桌面上。

Harness 到底管什么

只把模型接上搜索和终端，很容易做出一个看起来会干活的 Demo。

让它连续工作几个小时，问题就会变得具体。对话太长以后该保留什么，工具执行之前谁检查权限，进程中断后从哪里恢复，子 Agent 的结果怎样返回，失败操作能不能重试，用户怎样知道模型究竟看过什么。

这些问题都不属于底座模型，却会直接决定 Agent 能不能用。

DeepSeek Harness 给出的范围很大。模型适配器、工具、Skills、会话、沙箱、存储、Agent Loop、调度、用户界面，全都由插件组成，也都可以替换和重新组合。

项目底层使用 Cordis。它只处理插件的加载、卸载和依赖关系，具体能力留在插件里。开发者可以通过配置选择能力，或者用新的实现替换旧实现，不需要先去改一块拥有特殊地位的核心代码。

这套设计传达了一个很明确的判断。模型参数只决定一部分 Agent 能力，模型被怎样包起来也会改写结果。

Agent Loop 在这里也只是一个插件

过去一段时间的讨论，很容易把 Loop、Graph 和 Harness 排成三代技术。

放进 DeepSeek Harness 的架构里，它们更像三个不同尺度的东西。

Loop 管一次局部执行。模型读取上下文，发起工具调用，拿回结果，再决定是否继续。DeepSeek 的架构文档把一次模型请求及其工具调用称为 Step，把由零个或多个 Step 组成的一轮用户交互称为 Turn。

Graph 管执行单元之间的关系。哪些任务并行，结果在哪里汇合，失败后回到哪一步，发布之前是否等待人工批准，都可以画成图。

Harness 管模型运行时所遵守的整套约定。Loop 驱动器是插件，工具注册表是插件，模型适配器和会话日志也都是插件。Graph 可以出现在工作流和调度里，但它只占其中一部分。

这样再看，Graph 没有接替 Loop，Harness 也没有接替 Graph。Agent Loop 本来就可以被放进更大的流程，流程还要接上权限、状态、工具和持久化，才能长期运行。

DeepSeek Harness 有一处设计很大胆，连 Agent Loop 自己都没有被写成不可替换的核心。

四种模式把 Harness 的差别摆了出来

DeepSeek Harness 当前提供四种模式。

Standard 是完整的编码 Agent，包含文件编辑、终端、搜索、Skills、计划、目标、子 Agent 和工作流。

PTC 也叫 Code Mode。模型可以把多步工具操作组合成一段 TypeScript 程序，在一次执行中完成。

Minimal 只保留持久化 Bash 和文本替换编辑器，主要用于尽量精简的评测环境。

Creator 在 Standard 之上开放运行时检查和插件实验，允许开发者直接观察、修改 Cordis 插件环境，并创建自己的预设。

这四种模式用的是同一个项目，给模型的工作条件却完全不同。工具数量、上下文组织、执行方式和运行时能力一变，同一个底座模型表现出来的行为也会变。

2026 年 5 月发布的 Harness-Bench 做过一次更系统的测量。主实验把 6 种可配置 Harness 与 8 个模型后端交叉组合，在 106 个离线任务上得到 5088 条运行轨迹。研究者又把 Codex 作为模型绑定的编码 Agent 单独评测了 106 次，总计 5194 条。在任务、预算、超时和评估方式固定的条件下，六种可配置 Harness 的汇总得分相差 23.8 个百分点。

这个数字不适合拿来证明某一种 Harness 永远更强。论文的任务是离线的，部分过程质量也依赖模型辅助评分。它能支持的判断更克制。谈 Agent 能力时，模型和 Harness 应该被当作一个组合，单报模型名称已经不够。

DeepSeek 首页把两者写成加法，工程里的关系其实更接近配对。同一个模型换一套 Harness，结果可能就是另一种产品。

运行有迹可循，比多画几个节点重要

整套设计里，最值得借鉴的是那本只追加、不回写的会话账本。

系统提示词、模型推理、工具调用与结果、子 Agent 调度、上下文注入，只要模型看到了，就会写进同一条事件流。恢复、分叉、搜索和回放都从这条事件流派生。

官方架构文档把这个原则概括为模型可见即已记录。

它解决的是 Agent 工程里一个很普通、也很难绕开的麻烦。模型给出错误结果时，团队需要知道它当时收到了什么上下文，调用了哪个工具，工具返回了什么，以及错误从哪一步开始出现。

一张流程图只能说明设计者希望系统怎样运行。事件流留下的是系统实际上怎样运行。

如果只有节点和连线，没有可恢复状态、完整日志和统一事件语义，Graph 只是画得更漂亮的流程。每一步都能被重建，长任务才有办法调试。

权限和沙箱不能只写在提示词里

Agent 一旦拿到终端和文件权限，安全边界就不能靠一句请谨慎操作。

DeepSeek Harness 为工具调用设计了完整管线。调用先写入日志，再经过执行前钩子、权限检查、沙箱和审批。允许以后才会执行，结果冻结后再写回事件流。拒绝或无法完成审批时，工具本体不会运行。

它的审批服务使用一次性授权。授权只对应当前操作，其他结果一律按拒绝处理。审批服务不可用时也会关闭执行通道。这是一种失败时收紧权限的做法。

沙箱目前提供只读、工作区可写和完全访问三种模式，并针对不同操作系统使用不同后端。官方文档也明确写出边界。这里的沙箱主要约束文件系统影响，网络访问和进程可见性不在这套通用规则的覆盖范围内。

这句限制比一句安全沙箱更重要。它提醒开发者，启用某个模式不等于风险已经消失。

Creator 模式的边界还要更高。官方预设直接提醒，挂载运行时的能力会执行模型生成的 JavaScript，并接触正在运行的插件环境。使用 Creator 会话时，应当把它视为给出了终端级权限。

这些细节补全了 Harness 的职责。它让模型做事，也规定模型在哪些地方必须停下来。

Graph Engineering 该怎样重写

如果还想保留 Graph Engineering 这个说法，可以把它放回合适的位置。

Loop 是局部迭代。它回答模型怎样继续做下一步。

Graph 是关系和路由。它回答多个执行单元怎样连接。

Harness 是模型外的运行系统。它决定上下文怎样组装，工具怎样暴露，权限怎样检查，状态怎样保存，失败怎样恢复，Loop 和 Graph 又怎样被加载。

因此，Graph Engineering 可以成为 Harness Engineering 的一部分。它适合处理复杂任务里的拆分、并行、汇合和审批，却无法单独解决可观测性、权限、沙箱和持久化。

团队需要设计一份可执行的运行契约，复杂的图只是其中一种表达方式。

模型能看到什么，能调用什么，什么操作必须审批，什么状态可以恢复，完成条件由谁验证，出了问题怎样重放。这些答案凑在一起，才是 Agent 产品的工程边界。

现在值得用吗

值得看，也值得做小规模试验。暂时不适合因为一次演示顺利，就直接押到生产系统上。

DeepSeek 官方把它标为开发者预览版，仓库也明确提醒后续会有不兼容改动。它当前采用 MIT 许可证，源码、架构文档和预设配置都已经公开。

如果你在做 Agent 基础设施、评测平台、编码 Agent 或内部自动化，可以先选同一个模型、同一个任务和同一份预算，分别用 Minimal 与 Standard 跑一遍。

比较最终产物、工具调用次数、失败位置、恢复过程和总消耗。这样才能看见性能究竟来自模型，还是来自 Harness 提供的环境。

官方给出的快速启动命令很短。

npx @deepseek-ai/dsh web

这行命令只是启动入口。真要试用，还需要自行准备支持的模型凭据，检查实际权限和沙箱配置，并接受预览版可能发生的不兼容改动。

模型名字后面，还少了半句

以前选 Agent 产品，大家常问它用了哪个模型。以后这个问题至少要多半句。

它用了哪套 Harness。

工具、上下文、预算、权限、日志、恢复和评测方式不同，模型名称相同也不能说明能力相同。Loop Engineering 可能会退潮，Graph Engineering 也可能换名字，模型之外的工程不会跟着消失。

下次看到一个 Agent 榜单，我会先找那行经常被省掉的小字。模型后面接了哪套 Harness，开了哪些工具，给了多少预算，失败以后有没有机会重来。

找不到，就先别把分数都算在模型头上。