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

四种模式把 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 提供的环境。

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

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

▲ 先做同任务、同模型、同预算的受控对照，再决定是否进入小规模试验。

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

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

它用了哪套 Harness。

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

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

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