在探讨大语言模型（LLM）的工程落地时，“写一段 Prompt 调一次 API”与“交付一个能在复杂真实环境中自主作业的 Agent 系统”，中间隔着一道巨大的工程鸿沟。

很多初学者容易将 Agent 框架想象为一个封装了 LLM SDK 的轮询脚本。但一旦将这样的脚本放进生产环境，就会立刻面临状态丢失、失控死循环、高危指令无法拦截、多端适配混乱等一系列问题。

DeepSeek Harness（简称 DSH）所提出的解决方案，正是构建一个现代化的 Agent Harness（挽具运行时）。

一、为什么叫做“Harness”？

在工程术语中，“Harness”有两层经典含义：

1. 马具与缰绳：套在烈马身上，用于引导方向、约束奔跑节奏并随时刹车。
2. 线束与测试装配架（Wiring Harness / Test Harness）：在汽车与航天工程中，它是连接各种传感器与执行机构的标准电缆总线；在软件测试中，它是驱动待测单元运行的外围脚手架。

将这一概念引入 Agent 领域，Harness 的角色便非常清晰：它不是模型本身，而是负责驯服模型、为模型提供确定性输入输出、拦截越界行为、维持持久状态并安全驱动现实副作用的控制平面。

  flowchart TD
  subgraph Uncontrolled ["不稳定的模型决策面"]
    LLM["LLM 概率性输出 (不可控 / 存在幻觉)"]
  end

  subgraph DSH_Harness ["DSH 控制平面 (Harness)"]
    Context["共享 Context 服务树"]
    Policy["单调安全策略拦截"]
    Log["追加式 Session Log 事实源"]
    Loop["Agent Loop 状态机推进"]
  end

  subgraph World ["确定的现实执行面"]
    Tools["文件系统 / Shell / 远程 API / 数据库"]
  end

  LLM --> Context
  Context --> Policy
  Policy --> Loop
  Loop --> Log
  Loop --> Tools
  

二、DSH 最核心的架构判断：不存在特权内核

在传统的插件化软件（如 VS Code、Linux 内核或很多早期的 Agent 框架）中，无论插件生态多么丰富，系统底座始终保留着一个绝对特权内核（Privileged Kernel）。

在传统架构下：

• 你可以通过 Hook 扩展一个新工具，但你无法更换工具的执行管线；
• 你可以挂载一个新的数据库插件，但你无法修改会话历史如何被裁剪并送入模型；
• 你可以定制 Prompt，但你无法重构驱动整个任务前进的 Agent 核心循环。

DSH 将解耦推到了极致：在 DSH 中，不存在任何不可替换的特权内核。

所有关键能力——从底层模型适配器（ctx.llm）、工具注册表（ctx.tools）、持久化事件日志（ctx.sessions），一直到驱动任务推进的 Agent Loop 本身（ctx.agentLoop），在代码架构上全部都是地位平等的 Cordis 插件。

1
2
3
4
5
6

// DSH 的世界观：没有任何组件拥有与生俱来的特权地位
// AgentLoop 本身也只是 Context 树上的一个标准服务提供者
ctx.provide('agentLoop', new StandardAgentLoop(ctx));

// 如果你想试验一个基于多智能体博弈或树搜索的新调度算法，只需卸载并重新提供服务：
ctx.provide('agentLoop', new TreeSearchAgentLoop(ctx));

所谓“一切皆插件”，并不是在炫耀插件数量多，而是确立了一条铁律：组件的重要性不再自动带来不可替换的特权。 框架开发者和第三方二次开发者面对的是同一套上下文注入与服务契约。

三、Harness 要解答的五类工程问题

为了支撑复杂的工业级 Agent，DSH 将系统抽象为五条独立解耦的能力接缝（Seams）：

这种设计确保了系统中的任何一个横切关注点（Cross-cutting Concern），都拥有其独立的生命周期边界，绝不会让代码腐化成一个数万行的单体控制器。

四、三个思维实验：为什么必须解耦？

为了更直观地理解无特权微内核的价值，我们可以做三个思维实验：

1. 协议持续演进的挑战

如果大模型的请求参数、流式协议以及工具调用规范写死在核心控制器里，当模型厂商从原先的单步 Tool Call 升级为混合思维链（Thinking Process）、多模态或流式异步调用时，整个系统就必须做开胸手术。DSH 将这些协议全部隔离在 ctx.llm 适配器中，控制循环（Agent Loop）只感知统一词汇表。

2. 产品形态无法提前穷举

一个 Agent 既可能在终端以交互式 CLI 运行，也可能在 Web 页面以富文本卡片展示，还可能以无头（Headless）批处理模式在 CI/CD 中巡检代码。如果为每种形态写一套代码，很快就会造成逻辑分叉。DSH 让不同产品形态仅仅成为 Profile 配置清单的差异组合，底层事件源与工具执行逻辑完全复用。

3. 个性化治理不应等待官方发版

企业客户可能需要定制一套审计系统：只要模型调用 Shell 工具，就必须将命令异步发送至内部安全审计平台，并在检测到敏感命令时立即熔断。在传统硬编码系统中，这必须向官方提 PR 修改核心主循环；而在 DSH 中，只需编写一个监听 tools/pre-execute 的独立插件即可无缝切入。

五、这是过度设计吗？

答案很实在：如果你只是想做一个简单的文档问答小助手，或者只需要调用两次搜索工具，那么 DSH 确实是过度设计。

对于一次性问答、简单的 MCP（Model Context Protocol）工具转发，直接基于原厂 SDK 编写几百行 Python 或 Node.js 脚本，改配置后重启服务，成本显然更低。

DSH 的真正工程价值，只有在面对以下苛刻场景时才会体现出来：

1. 需要进程内带状态组件的动态平滑演进：无法轻易重启整个服务进程。
2. 需要精确控制执行流与强行打断能力：用户可能随时在任务进行中插话、纠正目标。
3. 需要严格的安全审计与事后追溯：必须通过不可篡改的事实源重演每一步的决策逻辑。

可替换性极大拓宽了系统的工程上限，但同时也引入了依赖解析、生命周期管理、事件拓扑排查等认知成本。在后续章节中，我们将深入其微内核底座 Cordis，探寻它是如何在运行时托住这份复杂度的。