DeepSeek Harness 最近突然火起来，表面看是因为 DeepSeek 推了一个新的开源 agent harness；但更深一层，它火的不是“又一个 Agent”，而是大家终于开始意识到：Agent 真正难的部分，不是让模型会调用工具，而是给它一个可持续工作的运行环境。
这件事听起来有点绕。过去一年，我们谈 Agent，重点通常放在 loop 上：模型接收任务，规划下一步，调用工具，观察结果，再继续执行。这个定义没错，但它更像是在描述“一个智能体怎么思考”。DeepSeek Harness 关注的是另一个问题：这个智能体到底运行在哪里？它能拿到哪些工具？谁来记录状态？能力如何替换？出错后如何恢复？不同界面和运行模式如何共享同一套能力？
换句话说，Agent 是“演员”，Harness 是“剧场、道具、灯光、调度和后台系统”。以前我们总盯着演员演技，现在终于有人开始认真修剧场了。
DeepSeek Harness 是什么
根据官方 README，DeepSeek Harness，简称 dsh，是 DeepSeek AI 开发的开源 agent harness，目前处于 developer preview 阶段。它的核心口号是：Everything is a Plugin。
这不是一句营销话。官方架构文档里明确写到，dsh 的每一部分都是插件：模型适配器、工具注册表、会话日志、agent loop 本身，甚至 Web 应用和 headless runner 都通过 profile 与 bundle 组合出来。底层框架是 Cordis，它强调服务容器、类型化事件和可逆副作用：插件不是把代码硬塞进内核，而是向共享上下文贡献服务、监听事件，并在卸载时撤销自己的注册。
这带来一个重要变化：dsh 里不存在一个必须打补丁的“神圣内核”。如果你想换模型提供方，注册新的 ctx.llm 适配器；想换文件系统或沙箱，替换对应 seam；想改变一个 agent 会话的工具集合，组装新的 preset 或 profile。它不是“框架给你几个 hook”，而是把产品本身拆成可组合的插件树。
和以前的 Agent 概念有什么不同
以前的 Agent 框架，大多以“智能循环”为中心：
任务 → 模型推理 → 工具调用 → 结果观察 → 下一轮推理这个循环解决的是“Agent 如何行动”。DeepSeek Harness 更像是把问题推进了一层：
Profile / Plugins / Tools / Session Log / Sandbox / UI / SDK → Agent Loop它解决的是“Agent 如何被装配、运行、观察和治理”。
两者的差异可以用三句话概括：
- Agent 关注行为，Harness 关注环境。 过去我们问模型会不会规划、会不会调用工具；现在要问工具从哪里来、权限怎么控、状态怎么存、失败怎么回放。
- Agent 框架关注单个循环，Harness 关注可替换系统。 dsh 把 LLM、tools、session、subagent、workflow、sandbox、settings、credentials 都做成服务或 seam，替换一层能力不需要 fork 整个产品。
- Agent 输出结果，Harness 记录过程。 dsh 的会话日志是追加式事件流，turn、step、user message、assistant chunk、tool call、tool result 都是可回放事实。模型可见的东西必须能从日志重建，这比“对话存在内存里”严肃得多。
这也是为什么它和之前讨论的 Harness Engineering 一脉相承：Prompt Engineering 解决“怎么说”，Context Engineering 解决“给什么信息”，Harness Engineering 解决“怎样搭一个系统，让 Agent 能长期、可靠、可验证地工作”。DeepSeek Harness 则是在把这套思想做成一个可运行的开源产品。
它真正带来了什么
第一，把扩展点从 hook 升级为插件拓扑
很多框架也有插件，但常见模式是：核心框架固定，插件围着核心转。dsh 的激进之处在于，连 agent loop、系统提示词、工具执行管线、持久化和 UI 都是组合出来的。Profile 叠加 bundle，再叠加 patch overlay，最终形成一棵实际运行的 Cordis 插件树。
这意味着“扩展”不再只是加一个工具函数，而是可以替换能力提供方。例如文件系统和进程执行共享同一个执行世界，把它们指向远程沙箱，就等于 Bash、PTY、LSP 一起搬过去；subagent 也可以在同一接口之后接不同实现。
第二，把 Agent 的过程变成工程资产
Agent 最大的问题不是不会干活，而是干活过程太像黑箱。dsh 的 turn / step 生命周期把一次模型请求、工具调用、结果返回都落到事件日志里。SDK 可以消费 session/event 做 transcript、回放和 UI；实时协调则通过 agent/* 事件处理 inbox、状态、pre-step、request、错误恢复。
这让 Agent 从“会话里的魔法”变成“可以审计的系统”。当一个任务失败，你不只是看到一句“抱歉我失败了”，而是能追踪模型看到了什么、调用了什么工具、哪个工具返回了什么、失败发生在哪个 step。
第三，把“工具调用”变成“能力治理”
传统 tool calling 的问题是太扁平：给模型一堆工具 schema，然后祈祷它别乱用。dsh 的工具和能力被放进更完整的治理结构里：工具注册表、执行流水线、审批策略、沙箱、凭据、遥测、持久化会话都在同一个架构里协作。
这对生产环境很关键。一个真正有用的 Agent，必须同时回答这些问题：哪些工具可用？谁批准危险操作？凭据如何注入？shell 跑在哪里？文件系统边界在哪里？任务中断后如何恢复？DeepSeek Harness 的价值，不是发明了这些问题，而是把它们放进了同一个可组合的 runtime。
第四，可能催生插件生态
官方 README 鼓励社区给插件仓库打上 dsh-plugin topic。GitHub 上也已经出现了插件精选列表和桌面端项目。这个信号很重要：Agent 平台的竞争，可能会从“谁的 agent loop 更聪明”，转向“谁的插件生态更丰富，谁的运行时更可靠”。
这有点像浏览器和 VS Code。真正让平台变强的，不只是内核能力，而是扩展生态。DeepSeek Harness 如果能把插件接口、profile 组合和能力 seam 稳下来，它就可能成为 Agent 时代的“可插拔工作台”。
但它还不是终局
需要冷静的一点是：DeepSeek Harness 目前仍是 developer preview，官方也明确提醒未来会有破坏性变更。它的架构很强，但复杂度也不低。对于只想写一个简单客服 bot 或 workflow 脚本的人来说，直接上 dsh 可能有点像用航母买菜。
它更适合这些场景：你要构建长期运行的 coding agent、内部自动化平台、多模型工具工作台、可审计的 agent 产品，或者你希望不同 UI、SDK、headless runner 共享同一套能力边界。
我的判断
DeepSeek Harness 的意义，不是“Agent 又进化了一代”，而是Agent 工程化开始从 prompt 和 loop，走向 runtime 和 ecosystem。
以前我们把 Agent 当成一个聪明的函数：输入目标，输出结果。DeepSeek Harness 提醒我们，真正的 Agent 产品更像一个操作系统：有服务、有事件、有权限、有日志、有插件、有沙箱，也有可以被替换的能力边界。
如果说 2025 年大家在问“模型能不能自己干活”，那么 2026 年更重要的问题会是：我们有没有给模型搭好一个适合干活的世界？
DeepSeek Harness 火起来，正是因为它踩中了这个转折点。