HMR

Cordis：DeepSeek Harness 为什么把 Agent 运行时重写成一套"可逆的组件系统" 核心问题：为什么 DeepSeek Harness 选择 Cordis？它解决了传统 Agent Harness 的什么问题？它是否代表了 Agent Runtime 的一种新架构？ 本文基于源码级研究：deepseek-ai/deepseek-harness、cordiverse/cordis（v4.x）、论文 arXiv:2608.25512。所有关键结论标注来源性质：【源码事实】（可直接从仓库代码/文档证明）、【论文观点】（来自论文摘要与 README 原文）、【研究推论】（本文作者基于前两者的判断）。论文 HTML 全文在本次研究中不可得，涉及论文细节均只引用摘要原文。 1. 开头：为什么 Agent 需要 Runtime 大多数 Agent 框架解决的是两个问题：下一轮对话模型看见什么（Prompt Composition），以及进程之间怎么调用（MCP 之类的工具协议）。但只要一个 Agent 活得足够久——长会话、热改工具、动态挂载能力——第三个问题就会浮出水面： 同一个进程里的能力，如何动态地出现、消失、替换，而不影响其他组件？ 传统答案是"重启进程"。但对一个跑着 30 个会话、持有浏览器连接、缓存着向量索引、正在执行长任务的 Agent Harness 来说，重启意味着一切归零。这不是 Prompt 层的问题，也不是进程层的问题，而是运行时层的问题。 DeepSeek 的 Harness 项目给出的答案是一个叫 Cordis 的框架。README 里一句话点明了架构【源码事实，deepseek-harness/README.md:7】： It is built on an everything-is-a-plugin architecture and powered by Cordis, whose design is described in A Programming Paradigm for Spatiotemporal Composability. ...