以 DeepSeek Harness 为对象的架构解析、二次开发路径与跨框架兼容层设计报告日期：2026年10月7日文章大纲摘要1. Harness 成为 Agent 竞争的新主场：概念界定与生态格局1.1 从裸模型到运行系统：Agent = Model + Harness 的含义1.2 全网主流 Harness 的技术路线分化1.3 三家"行业常用智能体"深度横剖：Pi、OpenCode、GitHub Copilot1.3.1 Pi：极简内核 + 自扩展，"把决定权全部交还用户"1.3.2 OpenCode：厂商中立 + 进程内插件，商业化跑通了1.3.3 GitHub Copilot / Agent HQ：不做 harness，做 harness 的调度台1.3.4 三家与 DSH 的取舍对照2. 为什么现在都是插件流：动因、收益与代价2.1 三大动因：模型能力见顶、企业资产要保留、生态要脱离主仓库2.2 插件化的六维收益2.3 插件化的代价：组合组件膨胀与供应链治理成本3. DeepSeek Harness 深度解析：Cordis 内核与"一切皆插件"3.1 项目定位：无特权核心的开源 Agent 运行时3.2 Cordis 内核：时空可组合性的三个理论支点支点一：时间可组合性 = 可逆效应支点二：空间可组合性 = 响应式余效应支点三：合流性3.3 三层组装架构与四种运行模式3.4 Context Key、三类事件域与 Seam 机制4. 二次开发路径：从配置到源码的四层切入点4.1 开发入口选择与上手成本4.2 插件编写规范：三种形式、依赖注入与事件分发4.3 扩展点速查：十九类需求的落点4.4 发布与分发：插件生态已经跑通5. 兼容所有 Harness 客户端：跨框架兼容层设计5.1 协议分工：MCP 管工具、ACP 管控制、A2A 管协作5.2 三层兼容架构：协议适配、语义映射、安全凭证代理5.3 现成参考实现与 DSH 的跨框架实践5.4 五阶段实施路线图6. 风险清单与落地建议6.1 五项确定性风险6.2 给我们的行动建议核心参考文献摘要Harness（运行时框架）才是产品，插件化是让它可以被替换和治理的唯一办法。模型能力见顶后，差异化落到运行时控制层——上下文怎么管、工具怎么组织、权限怎么控、失败怎么恢复；企业又必须把自有沙箱、审批、凭证、遥测接进去。两股压力叠加，结论只有一个：运行时必须可拆解、可替换、可独立演进。DeepSeek Harness 的真正独特之处不是"支持插件"，而是无特权核心——连 Agent Loop 本身都是可替换插件。Claude Agent SDK 是"固定内核 + 向外开放扩展点"，DSH 是"没有内核，全是组合"。敢这么做的底气是 Cordis 的合流性定理：不管怎么装卸插件，只要最终配置相同，系统状态就等价——这才让 Agent 可以试错着改自己的框架而不污染运行时。传统插件系统卸载留残留（VSCode 前 100 扩展中 87 个无法运行时单独卸载），根本不敢开这个口子。兼容所有 harness 客户端的核心不是写一堆 adapter，而是分清协议方向：MCP 管工具（垂直面，九家框架唯一全部支持的协议，押它风险最低）、ACP 管控制（驱动会话）、A2A 管协作（Agent 互相发现与委派）。拿 MCP 去承担控制面职责是最常见的错——它不定义会话生命周期和取消语义。一个必须记住的现实约束：ACP v1 不暴露 model-step 边界、无 mid-turn steering、无工具过滤 API。所以现在的兼容层能"驱动完整会话"，做不了"精细过程控