noteModel Harness AgentDeepSeek Harness 采取“一切皆插件”的设计思路。采用插件式开放架构来构建 Agent Harness模型、工具、技能、会话、沙箱、存储、循环、调度、UI 等所有 Agent 能力均由插件组合而成可自由替换、灵活重组。文章目录note一、一切皆插件二、多种运行模式三、DeepSeek Harness和Kimi Code CLI区别四、值得看的地方Reference一、一切皆插件DeepSeek Harness 基于具有时空可组合性的 Cordis 插件系统构建。Cordis 元框架只负责插件的加载与卸载以及依赖关系Agent Harness 的所有具体组件都是不同的 Cordis 插件。插件通过 Cordis 服务与事件彼此协作并可以在配置层自由组合。开发者无需改动 DeepSeek Harness 的源码本身就能以插件的方式独立选择、替换或扩展其中的任一能力。这就是 DeepSeek Harness 最重要的设计原则一切皆插件。二、多种运行模式针对不同的使用场景DeepSeek Harness 提供四种模式每种模式会默认加载不同的插件集合标准模式提供完整的工具组合PTC 模式程序化工具调用Programmatic Tool Calling由模型生成的一段代码来组合多轮工具调用极简模式仅保留一个 shell 工具与一个文件编辑工具用于最小环境下的模型基准测试创造模式可以检查当前运行时、在内存中试验 Cordis 插件并据此组合和创作新的模式。eepseek-harness/├── apps/cliapps/web 命令行与浏览器入口 ├── packages/bootbundle Profile 与插件树组装 ├── packages/core/│ ├── agent-loop Turn/Step 驱动 │ ├── session 追加式事件日志 │ ├── tools 工具注册与执行 │ └── system-prompt Prompt 片段组装 ├── packages/preset 每会话 Agent 组合 ├── packages/llm DeepSeek 与多 Provider 适配 ├── packages/fssandbox 可替换执行能力 ├── packages/code-runtime PTC/Code Mode └── vendor/cordis 插件生命周期底层三、DeepSeek Harness和Kimi Code CLI区别维度DeepSeek HarnessKimi Code CLI官方定位可重新组装的 Agent runtime开箱即用的终端 coding agent主要入口Web、Headless、Python SDK、ACPTUI、-p、ACP、Web扩展方式Cordis Plugin、Preset、Patch、Skills、Hooks、MCPPlugins、Skills、Hooks、MCP、SubagentsAgent Loop作为插件注册架构上可替换v2 DI 中的 Agent-scope Service源码开放但属于固定引擎主干默认模型DeepSeek另有 pi-ai 多 ProviderKimi支持兼容 Provider默认工具标准模式约 25 项含文件、Shell、任务、子代理、工作流、网页Read、Write、Edit、Grep、Glob、Bash、Web、Todo、Task / Subagent 等权限read-only / workspace-write / danger-full-access常规审批、yolo、auto可观测性Session Event、Trajectory、token / cache、可编程投影stream-json、session export、kimi vis安装形态npm 需要 Node 22.19官方单文件分发无需 Nodenpm 安装另需 Node四、值得看的地方DSH 把 loop、session、provider、工具和 UI 都摊在能核对的源码里。需要领域 Agent 的团队值得做小实验。先复制 minimal / standard preset再删工具、换 provider比迁移整套工作流更容易验证收益。模型评测人员可以用 minimal composition。同时锁定模型版本、推理档位、endpoint 和外部验收。只想找日常编码工具的人可以先观望。Kimi Code、Claude Code、Codex 等产品在终端体验、桌面入口、IDE 集成和默认工作流上更成熟。生产接入要自己补治理。插件来源、配置 diff、凭证边界、Windows 验收、日志保留和数据外发都得部署方承担。如果团队正在设计自己的 Harness还可以带走三个问题。运行时最终加载了什么能不能一条命令打印出来模型实际看见了什么能不能从日志完整重建换掉文件系统、沙箱或模型提供方时有多少工具必须跟着改这三个问题DSH 已经给出能跑、能核对的答法。默认产品、插件质量和治理能不能追上这套结构是下一阶段的事。Reference[1] DeepSeek Harness 开发者预览版一切皆插件[2] DeepSeek Harness 实测模型之外的那一半到底带来了什么[3] https://github.com/deepseek-ai/deepseek-harness[4] DeepSeek Harness 首发实测 入门教程 【Agent】DeepSeek Harness：一切皆插件
noteModel Harness AgentDeepSeek Harness 采取“一切皆插件”的设计思路。采用插件式开放架构来构建 Agent Harness模型、工具、技能、会话、沙箱、存储、循环、调度、UI 等所有 Agent 能力均由插件组合而成可自由替换、灵活重组。文章目录note一、一切皆插件二、多种运行模式三、DeepSeek Harness和Kimi Code CLI区别四、值得看的地方Reference一、一切皆插件DeepSeek Harness 基于具有时空可组合性的 Cordis 插件系统构建。Cordis 元框架只负责插件的加载与卸载以及依赖关系Agent Harness 的所有具体组件都是不同的 Cordis 插件。插件通过 Cordis 服务与事件彼此协作并可以在配置层自由组合。开发者无需改动 DeepSeek Harness 的源码本身就能以插件的方式独立选择、替换或扩展其中的任一能力。这就是 DeepSeek Harness 最重要的设计原则一切皆插件。二、多种运行模式针对不同的使用场景DeepSeek Harness 提供四种模式每种模式会默认加载不同的插件集合标准模式提供完整的工具组合PTC 模式程序化工具调用Programmatic Tool Calling由模型生成的一段代码来组合多轮工具调用极简模式仅保留一个 shell 工具与一个文件编辑工具用于最小环境下的模型基准测试创造模式可以检查当前运行时、在内存中试验 Cordis 插件并据此组合和创作新的模式。eepseek-harness/├── apps/cliapps/web 命令行与浏览器入口 ├── packages/bootbundle Profile 与插件树组装 ├── packages/core/│ ├── agent-loop Turn/Step 驱动 │ ├── session 追加式事件日志 │ ├── tools 工具注册与执行 │ └── system-prompt Prompt 片段组装 ├── packages/preset 每会话 Agent 组合 ├── packages/llm DeepSeek 与多 Provider 适配 ├── packages/fssandbox 可替换执行能力 ├── packages/code-runtime PTC/Code Mode └── vendor/cordis 插件生命周期底层三、DeepSeek Harness和Kimi Code CLI区别维度DeepSeek HarnessKimi Code CLI官方定位可重新组装的 Agent runtime开箱即用的终端 coding agent主要入口Web、Headless、Python SDK、ACPTUI、-p、ACP、Web扩展方式Cordis Plugin、Preset、Patch、Skills、Hooks、MCPPlugins、Skills、Hooks、MCP、SubagentsAgent Loop作为插件注册架构上可替换v2 DI 中的 Agent-scope Service源码开放但属于固定引擎主干默认模型DeepSeek另有 pi-ai 多 ProviderKimi支持兼容 Provider默认工具标准模式约 25 项含文件、Shell、任务、子代理、工作流、网页Read、Write、Edit、Grep、Glob、Bash、Web、Todo、Task / Subagent 等权限read-only / workspace-write / danger-full-access常规审批、yolo、auto可观测性Session Event、Trajectory、token / cache、可编程投影stream-json、session export、kimi vis安装形态npm 需要 Node 22.19官方单文件分发无需 Nodenpm 安装另需 Node四、值得看的地方DSH 把 loop、session、provider、工具和 UI 都摊在能核对的源码里。需要领域 Agent 的团队值得做小实验。先复制 minimal / standard preset再删工具、换 provider比迁移整套工作流更容易验证收益。模型评测人员可以用 minimal composition。同时锁定模型版本、推理档位、endpoint 和外部验收。只想找日常编码工具的人可以先观望。Kimi Code、Claude Code、Codex 等产品在终端体验、桌面入口、IDE 集成和默认工作流上更成熟。生产接入要自己补治理。插件来源、配置 diff、凭证边界、Windows 验收、日志保留和数据外发都得部署方承担。如果团队正在设计自己的 Harness还可以带走三个问题。运行时最终加载了什么能不能一条命令打印出来模型实际看见了什么能不能从日志完整重建换掉文件系统、沙箱或模型提供方时有多少工具必须跟着改这三个问题DSH 已经给出能跑、能核对的答法。默认产品、插件质量和治理能不能追上这套结构是下一阶段的事。Reference[1] DeepSeek Harness 开发者预览版一切皆插件[2] DeepSeek Harness 实测模型之外的那一半到底带来了什么[3] https://github.com/deepseek-ai/deepseek-harness[4] DeepSeek Harness 首发实测 入门教程