我是安徽最忧郁程序员无隅
很多人第一次接触 Agent 时，会把它理解成"一个更会调用工具的大模型"。这个说法不算错，但还不够准确。
模型负责理解指令、分析问题和生成下一步动作；真正让它能够读文件、执行命令、管理上下文、持续完成任务的，是模型之外的运行时系统。这个系统通常被称为 Harness。
本文不把 DeepSeek Harness 当成一个单纯的产品教程，而是沿着一条主线理解它：为什么需要 Harness，它如何组织 Agent 的能力，以及我们该如何选择不同的运行模式。
一、为什么需要 Harness
DeepSeek 对 Agent 的概括很直接：
text
Agent = Model + HarnessModel，也就是大模型，主要解决三个问题：理解用户意图、进行推理、生成文本或结构化结果。
但一个真实的开发任务往往不是"回答一个问题"这么简单。它可能要求 Agent 先扫描项目，再搜索相关代码，修改多个文件，执行测试，读取报错，继续修复，最后给出变更说明。
这些动作并不是模型单独完成的。它需要工具调用协议、文件系统、Shell、权限控制、上下文压缩、任务循环和状态保存等一整套基础设施。
这就是 Harness 的职责：把模型的推理能力连接到真实的执行环境中。
Claude Code、Codex、Workbuddy 等产品的差异，也不只来自底层模型。它们都在模型之上构建了不同的 Harness，决定了 Agent 能调用什么工具、如何管理上下文、怎样处理失败，以及是否支持子 Agent 和工作流。
因此，一个更完整的理解是：模型决定"能不能想明白"，Harness 决定"能不能把事情做完"。
二、DeepSeek Harness 的核心设计：一切皆插件
传统 Agent 产品通常会把工具、界面、会话和模型配置写进一个固定的应用中。用户能用什么能力，取决于官方预先提供了什么。
DeepSeek Harness 采用的是另一种思路：一切皆插件。
工具可以是插件，界面可以是插件，模型适配可以是插件，自动化流程也可以是插件。产品本身提供基础运行环境，具体能力通过插件组合出来。
底层 Cordis 内核主要负责插件的加载、卸载和依赖管理。它不需要理解每个插件的业务细节，而是负责把插件组织到同一个运行环境中。
这种设计有两个关键特性。
**时间可组合性（Temporal Composability）**关注插件在生命周期上的影响。一个插件加载后可能注册工具、修改界面或创建状态；当它被卸载时，这些副作用也应该被完整清理。
**空间可组合性（Spatial Composability）**关注插件之间的依赖关系。如果插件 A 依赖插件 B，那么 B 出现、消失或变化时，系统要能够动态调整，而不必重启整个 Agent。
最终效果是：Agent 的能力不再是启动时一次性确定的。它可以在运行过程中增加工具、替换组件、移除不再需要的能力，同时保持当前任务状态。
这也是 DeepSeek Harness 与普通"工具集合"的区别。它提供的不是一组固定按钮，而是一套可以持续组装的运行时。
三、快速上手 DeepSeek Harness
根据文章中的使用方式，可以先通过下面的命令启动 Web 版本：
bash
npx @deepseek-ai/dsh web启动后，系统会打开一个本地 Web 地址。第一次使用通常需要完成三步配置：
- 配置 DeepSeek API；
- 选择一个工作区目录；
- 选择模型和运行模式。
工作区可以理解为 Agent 的操作边界。Agent 能够读取和修改哪些文件，通常由这个目录决定。把工作区限制在具体项目中，有助于控制权限范围，也方便复现任务。
API Key 建议通过环境变量或本地配置管理，不要把密钥直接写入代码仓库、截图或公开文章。
DeepSeek Harness 也没有把模型完全锁死在 DeepSeek 上。除了目录中已有的模型提供方，还可以配置自定义模型提供方，包括：
- 模型名称；
- Base URL；
- 通信协议；
- 模型列表。
因此，兼容接口的其他模型也可以接入 Harness。这样，模型和运行时就形成了相对独立的两层：模型可以替换，工具、上下文和工作流能力可以复用。
四、四种运行模式有什么区别
DeepSeek Harness 提供了四种运行模式。它们不是简单的"能力高低档位"，而是对工具集合、上下文和 Agent 行为的不同取舍。
| 模式 | 核心能力 | 适用场景 |
|---|---|---|
| 标准模式 | 完整工具、文件、Shell、Skills、计划和子 Agent | 日常开发与复杂任务 |
| PTC 模式 | 通过代码批量编排工具调用 | 多步骤、并行化、结构化任务 |
| 极简模式 | 只保留 Bash 和文件编辑器 | 基准测试与最小环境 |
| 创造模式 | 检查并创建新的 Agent 或插件能力 | Agent 自扩展与实验研究 |
标准模式适合第一次使用，也适合大多数日常开发任务。它拥有完整的工具链，可以读取项目、执行 Shell、搜索代码、制定计划、调用 Skills 和创建子 Agent。
PTC 模式可以理解为代码化的工具调用方式。普通模式下，模型可能需要多次经历"调用工具、等待返回、再决定下一步"的往返；PTC 模式让模型生成 TypeScript 程序，通过 Code Mode SDK 在一次程序中组合多个操作。
例如，一个任务需要读取多个文件、筛选结果并并行执行检查时，PTC 可以减少上下文往返，让调用过程更接近一个小型工作流。代价是模型需要具备更稳定的代码生成和调试能力。
极简模式只保留持久化 Bash 和文件编辑器，其他复杂能力被移除。它适合做最小环境下的模型能力对比，也适合在需要严格控制变量时使用。
创造模式是最具实验性的模式。Agent 可以检查当前 Cordis 环境，了解已有插件和能力，然后创建新的插件并接入当前流程。
例如，可以让 Agent 创建一个"只允许读取代码、不允许修改文件"的安全审计模式，也可以让它创建一个连接内部搜索系统的研究插件。
换句话说，标准模式是在使用已有能力，创造模式则允许 Agent 参与构建自己的运行环境。
五、插件生态与事件日志
插件系统的价值，最终要通过具体生态体现出来。原文提到的社区插件包括：
dsh-at-file：在输入框中快速引用文件；dsh-genui：生成图表、表格、表单、Diff 和 Mermaid 等内容；dsh-automation：补充自动化能力；DSH-better-sidebar：增强文件管理、终端、Git 和任务管理；ModLens：为文本模型增加视觉理解能力。
这些插件说明，Harness 不只是一个聊天窗口，而是一个可以被持续改造的工作台。
除了插件，事件日志也是 Harness 的重要组成部分。一次完整的 Agent 执行过程，可以被记录成一串追加事件：
text
系统提示词 -> 用户消息 -> 模型推理 -> 工具调用
-> 工具返回 -> 权限变化 -> 子 Agent 调度 -> 最终输出事件日志的价值在于，它让 Agent 的运行过程变得可观察：
- 可以看到 Agent 到底执行了什么；
- 可以定位任务失败在哪一步；
- 可以审计高风险工具调用；
- 可以复现一段完整运行过程；
- 可以为 Agent 研究提供数据。
很多 Agent 失败之后，我们只能看到"任务失败了"，却不知道它是理解错了、工具选错了，还是在某一步进入了错误循环。事件日志把这个黑盒过程变成了可以检查的轨迹。
六、评价与总结
DeepSeek Harness 的优势比较清晰：模型与运行时解耦，支持多种模型接入；插件机制让工具和界面能够扩展；多种运行模式适配不同任务；事件日志增强了可观察性和可复现性。
对于开发者和 Agent 研究者来说，这种设计非常有吸引力。它让人们可以从"使用一个 Agent 产品"进一步走向"研究和改造 Agent 运行时"。
但它也有明显门槛。插件、模型、工作区、运行模式和权限配置，都要求用户具备一定的开发背景。对于只想直接使用 Agent 的普通用户来说，配置项过多可能会增加学习成本。
因此，DeepSeek Harness 更像是一个面向开发者的 Agent 平台，而不是一个完全开箱即用的消费级应用。
最后再回到最核心的公式：
Agent = Model + Harness
模型负责思考，Harness 负责执行。工具、上下文、工作流、权限、插件和事件日志，共同决定了模型能不能持续完成真实任务。
未来 Agent 的竞争，可能不只是比较谁的模型推理能力更强，也要比较谁能构建出更灵活、更稳定、更容易扩展的 Harness。