如果你让聊天机器人“帮我修一下这个项目”，它通常会给出一段代码，或者告诉你应该怎么改。但真正的工作并没有因此结束：它还要找到相关文件，理解项目结构，执行修改，运行测试，处理报错，再把结果整理出来。
聊天机器人擅长回答问题，工作系统则必须把事情做完。两者之间差的，不只是一个更大的模型，而是一整套围绕模型搭建的运行环境。
DeepSeek 最近开源的 DeepSeek Harness，正好提供了一个观察这个变化的样本。它的核心说法很简单：一切皆插件。模型只是 Agent 的一部分，工具、技能、会话、沙箱、存储、循环、调度和界面，都可以被替换或重新组合。官方介绍甚至把关系写成了“Agent = Model + Harness”。
这意味着，开源 Agent 的竞争重点，正在从“谁的模型回答得更像人”，转向“谁能把模型稳定地放进真实工作里”。
模型会思考，但不会自动拥有一份工作
把大模型直接接到一个输入框里，得到的是问答产品。用户输入一句话，模型生成一段文字，任务通常就结束了。
但工作不是这样发生的。一个程序员修复 Bug，要先看代码，再判断影响范围，修改文件，运行测试，遇到失败时回到上一步。一个研究者整理资料，也要保存中间结果，区分已经确认的事实和仍需核验的猜测。只生成一段文字，无法覆盖这些动作。
所谓 Harness，可以理解为把模型接入现实环境的那一层系统。它负责决定模型什么时候调用工具、工具能访问什么、上下文如何保存、任务何时停止，以及出错后能不能继续。模型提供推理能力，Harness 负责把推理变成连续行动。
模型只是中心部件，真正让 Agent 开始工作的，是周围那些负责工具、文件、记忆、循环和人工确认的模块。
一篇近期的 Agent 工程研究也采用了类似定义：Agent 不只是模型，而是模型加上循环、工具、上下文管理、安全控制、任务编排和扩展机制。研究者据此判断，Coding Agent 正从一个命令行工具转向一个平台。相关研究的价值，不在于又发明了一个新名词，而在于它提醒我们：决定 Agent 是否好用的，常常是模型之外的工程部分。
“一切皆插件”改变了什么
传统软件通常有一个比较稳定的核心，其他功能围绕核心添加。DeepSeek Harness 选择了更彻底的拆分方式：连模型、工具和 Agent 循环都不是永远固定的内置能力。
比如，同一个工作环境可以换掉模型提供商，也可以更换文件工具、命令执行工具或浏览器工具；可以给 Agent 加入新的技能，让它知道怎样做代码审查，也可以更换会话和存储方式。开发者通过配置选择这些能力，不必为了每次调整都修改 Harness 的主代码。
这种设计解决的是一个很实际的问题：Agent 的工作方式还没有定型。今天大家需要的是代码编辑和测试，明天可能需要浏览器操作、团队审批或本地知识库。如果所有功能都写死在核心里，系统会越来越臃肿；如果能力都能以插件形式挂载，变化就可以被隔离在更小的模块里。
DeepSeek Harness 使用的 Cordis 内核，提供了插件加载、依赖和事件协作等机制。对普通用户来说，不必先理解这些抽象概念。可以把它看成一个可插拔的工作台：模型是其中一个部件，工具是另一些部件，工作流决定它们以什么顺序协作。
真正重要的不是“能调用工具”，而是能把过程留下来
很多 Agent 演示看起来很聪明：它能打开网页、写文件、运行命令，最后给出一个漂亮结果。但只要中途出了问题，用户往往不知道它做过什么，也不知道应该从哪一步恢复。
DeepSeek Harness 把每次运行记录在追加式会话日志里，记录内容包括模型看到的上下文、工具调用、工具结果、子 Agent 调度和上下文注入。官方页面还提供了轨迹查看、继续、分叉、搜索和回放能力。
这和普通聊天记录不太一样。聊天记录主要用于回看“说过什么”，工作系统的日志则要回答“做过什么、为什么这样做、哪一步出了问题、能不能从这里重新开始”。当 Agent 开始修改代码、处理文件或调用外部服务时，这种可追踪性就不再是锦上添花，而是基本要求。
一次运行被拆成连续事件后，用户才能定位问题，也才能从某个检查点继续、分叉或回放，而不是每次都从头再问一遍。
它也带来一个容易被忽略的变化：一次任务不一定只有一个最终答案。用户可以从某个中间状态分叉出另一条路径，比较不同工具或不同提示的结果。对开发者来说，这让 Agent 更接近一个可以调试的程序，而不是一个只能重新提问的黑箱。
它能做什么，不能做什么
DeepSeek Harness 的标准模式，面向的是完整的编码工作：文件编辑、Shell、文件和网页搜索、技能、规划、目标、子 Agent 和工作流都可以参与进来。对于一个本地代码项目，用户可以让它先理解目录，再修改指定文件，运行测试，最后给出变更说明。
如果要研究 Agent 本身，可以使用更精简的模式，只保留 Shell 和文件编辑，用来观察一个模型在少量工具下能完成什么；如果要设计自己的 Agent 工作台，则可以进入 Creator 模式，查看运行时并测试插件组合。这几种模式说明，项目的目标不只是做一个聊天界面，而是提供一套可以被重新组装的运行环境。
不过，它还远没有成熟到可以放心交出所有权限。项目安全说明明确写着：DeepSeek Harness 仍是实验性的开发者预览版，没有完成安全审计，也不应被当作安全或生产就绪的软件。它可以执行模型生成的代码和命令，加载第三方插件，访问网络、进程、凭据和用户授权的文件。错误配置、恶意输入或不可信插件，都可能修改文件、泄露数据，甚至损坏主机。
所以，开源并不等于安全，插件化也不等于隔离。更稳妥的做法是用最小权限运行，先放在一次性虚拟机、容器或专用环境里，使用没有敏感信息的测试目录，审查插件和命令，并保留可恢复的备份。项目本身也提醒用户，不要把它当成不可信任务的唯一安全控制。
安全边界不是一个开关，而是权限、人工确认、隔离环境、备份和审计记录共同组成的一层防护。
开源 Agent 的下一站，不是替你聊天，而是替你承担一段流程
DeepSeek Harness 值得关注，不是因为它已经证明了某种最终架构，而是因为它把一个趋势说得很清楚：模型能力只是起点，真正的 Agent 还需要工具、记忆、权限、日志、任务循环和可替换的扩展机制。
这也解释了为什么越来越多开源项目开始围绕技能、插件、知识库和工作流展开。用户需要的不是一个更会写答案的聊天窗口，而是一个能在边界内持续推进任务、留下过程、允许人随时接管的系统。
如果只是想体验，第一步不应该是把私人文件交给它，而是准备 Node.js，在空目录或隔离环境中运行官方提供的 npx @deepseek-ai/dsh web，先观察它如何调用工具、记录会话和处理权限。等你看清楚它做了什么，再决定哪些工作适合交给它。
聊天机器人回答完一句话就结束了。工作系统则要面对下一步、再下一步，以及每一步留下的后果。开源 Agent 真正的变化，正发生在这段“回答之后”的流程里。