DeepSeek Harness 的价值不在 Loop，而在运行时组合

在 AI Agent 的开发实践中，许多团队习惯将注意力集中在 Loop 的实现上——组装 prompt、调用模型、执行工具、回填结果，这套四步循环看似简单明了。然而，当 Agent 从概念验证走向产品化时，真正的复杂度往往不在 Loop 本身，而在于：哪些能力在当前会话中生效？依赖关系如何？何时启动？谁负责清理？这些问题指向了 Agent 运行时架构设计的核心命题。

运行时组合的三大支柱

DeepSeek Harness（以下简称 DSH）的核心贡献，在于将 Agent 的组合关系系统化为运行时能力。其架构由三大组件构成：Cordis 负责管理当前系统的能力拓扑，Session Log 负责记录已发生的事实，Agent Loop 则在这两者之间执行推理和工具调用。这种分层设计将「系统现在由什么组成」与「系统刚才做过什么」清晰分离，为复杂 Agent 场景提供了可追溯、可管理的运行时基础。

Session Log 的设计哲学

Cordis 是横向事实面，它回答「系统当下由哪些组件构成」。DSH 启动时会将多层配置装配成插件树，而非简单地将静态配置读入内存。通过 Bundle（分发配置和插件代码）、Runtime Profile（决定进程堆叠哪些 Bundle）、Patch（按配置行覆盖或插入能力）和 Agent Preset（在会话作用域组合工具、提示词和局部能力）等机制，Cordis 让 Provider 替换从「开发期改代码」变为「部署期装配能力」，前提是系统具备清晰的能力边界：Service Definition、Provider、Consumer 三者职责分明。

生命周期所有权：被忽视的关键

Session Log 采用「先保存事实，再投影上下文」的设计思路。它记录 turn、step、用户消息、模型流、工具调用和工具结果，而下一轮模型看到的是 deriveMessages() 投影出的 model-visible history，而非完整日志。这种设计避免了流式 chunk 与最终输出的重复进入模型历史，同时保留了审计信息却不污染上下文。更重要的是，UI、恢复、分叉、重放都可以从同一日志派生，避免多份状态互相漂移。核心原则可以概括为：model-visible means logged。

Harness 改善的是什么

评估 Harness 时，最常见的误区是将「执行完整性」与「模型判断质量」混为一谈。DSH 改善的是前者，而非后者。具体而言，它关注五个维度：工具是否按正确策略调用、跨轮上下文是否保持、超时和取消是否处理、结构化终态是否解析成功、失败能否归因。当问题出现在工具调用失败、上下文溢出、终态解析失败时，Harness 的价值才能体现。但若问题是模型本身的判断错误，则应优先改进模型、prompt 或领域策略。

如有侵权，请联系删除。