"能跑"不等于"敢交付"。当 Agent 系统从演示走向生产，从单个模型走向多智能体团队，从黑盒执行走向可审计可控，我们需要的不是更强的模型，而是一个真正的 Agent 操作系统。
前天（8月13日），DeepSeek 正式发布、开源了DeepSeek Harness（dsh），一个 MIT 许可的 Agent 驾驭框架。这不是又一个"大模型 + 工具列表"，而是一套系统化的工程基础设施，旨在让 Agent 从"能跑"进化为"可控、可验收、可持续"——这正是我们所说的从"能跑"到"敢交付"的转变。
1. 行业的痛点已经暴露
- 40% 的 agentic AI 项目：在 2027 年底前面临被取消或下线的风险，主因不是模型能力不足，而是治理缺口
这些都指向一个核心问题：模型解决"能不能做到"，但系统必须解决"敢不敢交付"。2. 技术对标从"模型能力"转向"执行可靠性"
DeepSeek 的策略转变很聪明：与其和 OpenAI/Anthropic 比模型参数和推理能力（这场比赛很难赢），不如把竞争维度移到"执行系统的可控性、可观测性、可治理性"这些企业更在乎的指标上。- Claude Code 和 Codex 的会话是黑盒私有的，无法外部审计
- DeepSeek Harness 把会话变成类型化事件日志，支持 keyless 重放、快照回归、全文检索
这一步转变，从"谁的模型更聪明"变成"谁的系统更可信"。3. 开源 = 快速验证 + 生态共建 + 技术标准化
DeepSeek 选择 MIT 许可并快速开源（v0.1 时就发布），目的很明确：- 闭环加速：在社区中暴露缺口，迭代速度远快于单独商业化
- 降低采用门槛：企业更愿意集成开源基础设施而非被技术锁定
- 争夺标准：如同 Linux 之于操作系统，DeepSeek Harness 想成为 Agent 系统的"事实标准"
创新 1：会"改写自己"的运行时（Self-modifying Runtime）
痛点：传统 agent 框架的能力是静态的。模型只能"调用"工具，框架本身无法演进。DeepSeek 的答案：通过Typert 类型反射 + Cordis 动态加载，让 Agent 能：- dsh-tool-cordis：模型可见的运行时检视工具
- cordis-host-runner：node:vm 隔离 + 请求-运行往返
- 风险受控：生命周期守卫 + 权限隔离，"可改写"不等于"失控改写"
其他 Agent 框架只允许模型"调用"工具。DeepSeek 让 Agent改变自己的工具集—— 这是从"静态框架"向"动态自进化系统"的质的飞跃。实际效果：Agent 可以在运行时识别自己的缺陷（"我缺少某个能力"），然后自己生成、验证、加载新能力，而不必等待人工干预。
创新 2：事件溯源 + 可重放会话
痛点：Agent 最恐怖的生产灾难不是单次失败，而是失败后无法复盘。Claude Code 的会话是私有的，你看不到 Agent 到底做了什么无法重放意味着无法审计、无法定位根因、无法验证修复DeepSeek 的答案：把Session 设计为一等公民：- 会话 =类型化、版本化的事件日志（SessionEventMap）
- 系统状态来自日志的折叠和投影（类似数据库的事务日志）
- 支持JSONL/zstd + SQLite 双持久后端，效率与可靠性兼顾
- Keyless重放：无需原始API Key，从日志重放任何历史会话
- 快照回归测试：可以对不同版本的Agent逻辑做对比测试
- 全文检索 + 血缘追踪：SQLite FTS5+关系查询，快速定位某个错误决策是在第几步做的
传统日志是"发生了什么"的记录。DeepSeek 让日志变成"系统完整的决定论重建"——给定同一份日志，任何人、任何时间都能得到相同的行为轨迹。- 可复现：Bug 复现不再靠"描述"，而是靠"重放"
创新 3：异构子Agent协议
痛点：企业环境中通常有多个 Agent 产品和工具链。如何让它们互相调用、协作？ACP（Agent Client Protocol）：自动化专用，面向任务编排dsh-sdk：JSON-RPC进程外驱动，更通用可以把 Claude Code、Codex 当作"sub-agent"委派任务不同 Agent 实现可以互相调用，形成异构智能体网络- 五种sub-agent后端：in-process spawn、in-process fork、ACP、Claude Code、Codex
大多数 Agent 系统是单体架构（"我就是唯一的 Agent"）。DeepSeek 承认现实：企业有多个 Agent 和工具链，系统应该支持它们协议化、可替换的互操作。这就像 OS 的"进程通信"——不同厂商的应用也能通过标准协议通信。
创新 4：可移植沙箱+"fail-closed"设计
痛点：Agent 执行高风险操作（改文件、运行命令、访问网络）时，如何保证不越权？- Linux：Landlock（内核能力隔离）+ bwrap（namespace）
- macOS：Seatbelt（App Sandbox）
- 原生 C11 实现：native/landlock-run，自限制后 exec（不依赖外部工具）
- Fail-closed exit 125：当内核无法强制隔离时，直接失败而非偷偷放开
- 双重机制：沙箱隔离 + 权限策略（sandbox-policy）分级控制
沙箱很多系统都有，但 DeepSeek 的创新是：- 跨平台一致：同一份策略，Windows/macOS/Linux 行为一致
- "安全失败"是第一原则：宁可功能受限，也不偷偷放开权限
- 原生底层：C11 Landlock 实现意味着零依赖、最小化攻击面
这体现了一个工程哲学：治理不是在应用层的 prompt 里祈祷，而是在基础设施层被机制强制执行。
创新 5：把"可靠性"当作工程纪律
痛点：很多 Agent 系统把可靠性寄托在 prompt 调优、温度参数、或"模型自我反思"上。这都是概率性的，无法保证。DeepSeek 的答案：建立一套机器强制的工程门禁：- 自动化快照回归测试（snapshot tests）
- 死代码检测（knip）、复制代码检测（jscpd）
- Agent Notes： ~680 条决策记录（为什么这样设计、为什么放弃另一个方案）
- Postmortem：事故复盘（发生了什么、为什么发生、怎么防止再发生）
- 这些知识可以被持续迭代利用
- config-catalog：自动生成所有配置选项的文档
- tool-catalog：所有模型工具的 schema 自动列举
- persistence-catalog：所有持久化事件类型的目录
- 双语文档体系：.md + .zh.md + .i18n.yaml 三元组，词条一致性强制
可靠性 = 工程化，而不是靠 prompt 调优。这是 DeepSeek Harness 与一线 Agent 产品（Claude Code/Codex）的本质区别。前者把可靠性看作可优化的指标（覆盖率、测试通过率、不变量成立率）；后者依赖不可量化的因素（模型"有没有想对"、prompt 有没有足够清晰）。
三、与 Claude Code/Codex的对比
关键差异：DeepSeek Harness 不是"更强的 Agent"，而是把 Agent 变成可控、可审计、可扩展的基础设施。
四、Harness Engineering最新趋势
从DeepSeek Harness的设计，我们能看到Harness Engineering（驾驭工程）的三个最新发展趋势：1. 从"框架能力"走向"可治理运行时"
自改写运行时、沙箱与 fail-closed，让框架具备工程演进能力治理不是静态的策略配置，而是动态的、可观测的、可降级的决策引擎2. 从"日志"走向"事件-可重放-可审计"
这是可规模化交付的前提：必须能解释"为什么 Agent 做了这个决策"3. 从"调参/自评"走向"工程纪律与自动化守门"
可靠性不靠运气，而靠门禁、覆盖、不变量、postmortem、资产新鲜度管理这标志着 Agent 工程从"科研探索"向"工程规范"的转变
五、给企业的启示
如果企业正在评估 Agent 系统，DeepSeek Harness 给出的信号是：一个 Agent 会不会跑，和一个 Agent 能不能被企业安全地部署，是两回事。前者看模型能力，后者看系统底座。如果你的 Agent 系统无法完整重放某个历史行为，那它就无法被审计、无法被修复、无法被学习。不要依赖 prompt 来约束 Agent 的行为。使用沙箱、权限策略、审批流等机制在系统层强制执行。闭源产品再好，你也被锁定在厂商的技术选择上。开源 Agent OS 意味着你可以定制、可以审计、可以主导自己的 AI 战略。
结语
从"能跑"到"敢交付"，不是模型更强就能做到的。需要的是一个真正的操作系统——把编排、验证、记忆、治理统一成闭环，让 Agent 进入生产流程且可控、可追溯、可持续。
DeepSeek Harness v0.1 的发布，标志着 Agent 工程不再是"工程师 + 好的 prompt"，而是一个系统化的驾驭工程学科。五大创新（自改写运行时、事件溯源、异构协议、可移植沙箱、工程纪律）合在一起，形成了一个闭环：
粤ICP备14082021号
免费POC，
零成本试错
