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

AI领域的发展节奏极快，很多技术讨论还没来得及形成共识，就被新的热点取代。前段时间业界还在热炒Loop Engineering，紧接着Graph Engineering又成为热门话题。当DeepSeek Harness正式开源后，这些争论突然显得格局小了。DeepSeek官方在项目首页给出了一条简洁的公式：Agent = Model + Harness。这句话精准地概括了当前AI Agent架构的核心变化。

Harness的核心职责：超越Demo级别的工程能力

模型负责理解、判断和生成，而Harness则负责将模型置于一个完整可用的工作环境中。这个运行环境包含工具、状态、权限、日志、沙箱和恢复机制。Loop如何运行、Graph如何连接，都在这一层得到统一管理。DeepSeek Harness并没有创造一个虚无缥缈的新概念，而是将过去散落在产品内部的那套运行环境体系，完整地呈现在开发者面前。

插件化架构：Harness的本质设计

将模型简单对接搜索和终端接口，很容易做出一个看起来能工作的演示demo。但如果要求系统连续稳定运行数小时，问题就会变得具体而棘手：对话过长时应该保留哪些上下文？工具执行前由谁检查权限？进程中断后从哪里恢复？子Agent的结果如何正确返回？失败操作能否自动重试？用户如何追溯模型究竟看过什么？这些工程问题都不属于底层模型的能力范畴，却直接决定了Agent能否真正投入生产使用。

Loop、Graph与Harness：三个不同维度而非三代技术

DeepSeek Harness定义的运行范围相当广泛：模型适配器、工具、Skills、会话管理、沙箱、存储、Agent Loop、任务调度、用户界面等，全部由插件组成且均可替换和重新组合。项目底层采用Cordis框架，仅负责插件的加载、卸载和依赖关系管理，具体能力实现全部留在插件内部。这种设计的深层含义是：模型参数只决定一部分Agent能力，模型被如何封装、如何配置，同样会显著影响最终表现。

四种运行模式：同一模型的不同表现

过去一段时间的讨论容易将Loop、Graph和Harness描述为三代递进的技术。放在DeepSeek Harness的架构视角下，它们更像是三个不同尺度的概念：Loop负责局部迭代，回答模型如何执行下一步；Graph负责执行单元之间的关系，回答多个组件如何连接协作；Harness则管理模型运行时所遵守的整套约定，包括上下文组装、工具暴露、权限检查、状态保存和失败恢复。从这个角度看，Graph并没有接替Loop，Harness也没有接替Graph——它们各有分工，共同构成完整的Agent工程体系。

如有侵权，请联系删除。