harness 和模型是一回事吗？

不是。模型把文本变成更多文本，它没有关于昨天的记忆，没有文件访问能力，也不能运行任何东西。harness 是它外面那个程序，决定模型看到什么、执行它要的工具、把结果喂回去，并在活干完时停下循环。

agent harness 就是包了一层的 API 调用吗？

单次调用不构成 harness。决定性的特征是循环：harness 调模型、执行模型请求的工具、把结果加进对话、再调一次，直到满足停止条件。harness 里所有困难的东西——上下文管理、权限、会话持久化、错误恢复——都是因为这个循环才存在的。

harness 和 agent 框架有什么区别？

框架是你用来构建应用的库；harness 是你直接用的可运行程序。框架把零件给你、把决策留给你，而 harness 已经做完了那些决策并把它们作为默认值交付。当一个 harness 异常可配置时，这条线会变模糊——DeepSeek Harness 正是如此。

agent harness 会取代 MCP 吗？

不会，它们回答的是不同的问题。MCP 是描述工具或数据源如何向 agent 暴露自己的协议，而 harness 是跑循环、并决定某个工具究竟要不要被调用的那个程序。harness 可以充当 MCP 客户端，所以两者是互补而非竞争。

DeepSeek Harness 在一众 harness 里特别在哪？

特别在它「一切皆插件」的设计。模型、工具、skill、会话、沙箱、文件系统、循环、编排和界面全都是插件，加载进共享的 Cordis 运行时，通过一份 cordis.yml 组装。于是大多数工具视为固定内部结构的那些部分，在这里都是可替换的包。

什么是 agent harness？

agent harness 是包在语言模型外面的那层运行时，它把一个文本生成器变成能干活的东西。它跑循环、把工具递给模型、决定什么进上下文、把会话存到可靠的地方，并约束这个 agent 被允许碰什么。模型提供判断力，其余一切由 harness 提供。

harness 到底做什么

把一个 agent 拆到底，剩下五项职责，没有一项是模型自己能承担的。

循环。一次模型调用返回一次就停了。而 agent 会一直往下走：调模型、执行它要的工具、把结果追加进去、再调一次，直到任务完成或撞上限制。这个循环是 harness 的核心工作，而不同 harness 之间的大部分差别——怎么重试、什么时候放弃、能不能并行跑步骤——都是关于循环的决策。

工具。读文件、执行命令、搜网页。harness 负责声明有哪些工具可用、校验模型给出的参数、执行调用，再把结果整理成模型读得懂的形式。

上下文。每个模型的窗口都是有限的，而真实任务一定会溢出。哪些留下、哪些做摘要、哪些按需重新取回，是 harness 的职责——也是用户感受最直接的一项：agent 忘了自己在干什么的时候。

会话。跨越数小时、跨越重启的工作总得存在某个地方：对话记录、中间状态、恢复的能力。没有持久化，你手上的是一个聊天窗口，不是 agent。

权限。能执行 shell 命令的 agent 就是一个安全面。审批提示、白名单、沙箱和文件系统边界全都住在 harness 里，因为模型既不能被信任来管住自己，当初也不是为此设计的。

harness 不是什么

它不是模型。换模型会改变 agent 推理得多好，但不会改变会话能不能恢复、某条命令要不要审批。那些是 harness 的属性——这也是为什么同一个模型在一个工具里显得能干，在另一个里却显得笨拙。

它也不是 IDE 插件，尽管两者容易混淆，因为你往往是通过编辑器认识 harness 的。编辑器扩展是一个界面：它收集你的请求、展示输出。而 harness 是拥有循环、工具执行和状态的那一方。一个造得好的 harness 能在同一个会话上驱动多个界面——CLI、网页、编辑器——这是判断你面对的是 harness 还是前端的好办法。

DeepSeek Harness 是怎么实现的

DeepSeek Harness——dsh——由 DeepSeek AI 于 2026 年 8 月 13 日以 MIT 协议发布，它对上面这一切采取了一种异常字面的立场：一切皆插件。模型、工具、skill、会话、沙箱、文件系统、循环本身、编排和用户界面，全都是加载进同一个共享运行时的插件。

这个运行时是 Cordis，一个专职加载和接线插件的元框架；@deepseek-ai/cordis 是每个 harness 包的 peer dependency。组装发生在一份 cordis.yml 加载器配置里，它列出要启动的插件及其参数；--profile 参数则在面向不同场景的 bundle 之间切换——自带的 profile 包括 headless。

结果是，在 dsh 里应用和它的扩展之间没有一条有意义的界线。换掉沙箱，在结构上和加一个工具是同一件事。这就是为什么插件目录对它比对大多数 agent 工具更重要：能力住在包里，不在内核里。我们目前收录了 7900 个挂着 dsh 相关标签的仓库，其中 3942 个有真实的插件接线——你可以浏览它们，也可以按分类逐个看过去。有一点值得重复：dsh 是开发者预览版，README 警告破坏兼容性的变更即将到来，所以这里描述的加载器格式是一张快照，不是一份契约。

harness 与 agent 框架

agent 框架是你用来构建应用的库。它递给你循环原语、工具抽象和记忆助手，把产品决策留给你——程序是你写的，交付出去的东西也是你的。

harness 已经替你做完了那些决策。你装上它，它就能跑：有默认的循环、默认的一组工具、默认的权限模型、恢复昨天会话的办法。这是库与产品之间那种常见的权衡——更少的控制权，也更少要自己造的东西。

dsh 在这条线上的位置很有意思。它是一个装上就能跑的 harness，但因为它的每一部分都是通用框架之上的插件，一个足够执着的用户可以替换掉大多数 harness 视为固定内核的部分。这个区分依然成立——你不写一行代码也能用 dsh——但边界比通常更软。

harness 与 MCP

MCP，即 Model Context Protocol，常和 harness 被一起提起，但两者解决的是不同问题。MCP 是一个协议：它规定一个工具或数据源如何描述自己、如何响应调用，使得写一次的服务器能被任何懂这个协议的客户端使用。它回答的是「agent 怎么够到这个东西」。

harness 回答的是「谁在跑循环，以及那个工具究竟什么时候才会被调用」。它管理上下文、权限和会话，而 MCP 对这些都没有主张。harness 可以充当 MCP 客户端，这时 MCP 服务器就成了它众多工具来源中的一个。如果你想看这件事在 dsh 生态里的具体形态，本目录的 MCP 与工具分类收集了坐在这个交界上的插件。

常见问题

harness 和模型是一回事吗？: 不是。模型把文本变成更多文本，它没有关于昨天的记忆，没有文件访问能力，也不能运行任何东西。harness 是它外面那个程序，决定模型看到什么、执行它要的工具、把结果喂回去，并在活干完时停下循环。
agent harness 就是包了一层的 API 调用吗？: 单次调用不构成 harness。决定性的特征是循环：harness 调模型、执行模型请求的工具、把结果加进对话、再调一次，直到满足停止条件。harness 里所有困难的东西——上下文管理、权限、会话持久化、错误恢复——都是因为这个循环才存在的。
harness 和 agent 框架有什么区别？: 框架是你用来构建应用的库；harness 是你直接用的可运行程序。框架把零件给你、把决策留给你，而 harness 已经做完了那些决策并把它们作为默认值交付。当一个 harness 异常可配置时，这条线会变模糊——DeepSeek Harness 正是如此。
agent harness 会取代 MCP 吗？: 不会，它们回答的是不同的问题。MCP 是描述工具或数据源如何向 agent 暴露自己的协议，而 harness 是跑循环、并决定某个工具究竟要不要被调用的那个程序。harness 可以充当 MCP 客户端，所以两者是互补而非竞争。
DeepSeek Harness 在一众 harness 里特别在哪？: 特别在它「一切皆插件」的设计。模型、工具、skill、会话、沙箱、文件系统、循环、编排和界面全都是插件，加载进共享的 Cordis 运行时，通过一份 cordis.yml 组装。于是大多数工具视为固定内部结构的那些部分，在这里都是可替换的包。

继续读

想把上面这些想法看成运行中的软件，就去安装 dsh——一条 npx 命令就能在 http://127.0.0.1:3080 得到一个 Web UI。想知道一个「一切皆插件」的 harness 和一个成熟的闭源产品比起来如何，可以读我们对 dsh 与 Claude Code 的早期对比。