DeepSeek Harness深度调研 · 与企业 ERP 结合构建「智能企业操作系统」方案

warpdrivelabs

322人浏览 · 2026-08-27 15:53:30

warpdrivelabs · 2026-08-27 15:53:30 发布

DeepSeek Harness(dsh)深度调研 · 与企业 ERP 结合构建「智能企业操作系统」方案

调研日期:2026-08-27
对象:DeepSeek AI 开源 agent harness —— github.com/deepseek-ai/deepseek-harness(MIT)
发布:2026-08-13 与旗舰 agentic 模型 DeepSeek-V4-Pro 同日开源;两天内破 10 万 stars;当前为 developer preview,明确警告「WILL BE COMPATIBILITY-BREAKING CHANGES」
姊妹篇:本文与《从记录到行动:传统 ERP 在大模型时代的深度变革》《Codex 开源 harness 全面了解》互为参照 —— 前者立「AI 提议·引擎执行」之愿景,本文把该愿景钉在 dsh 这台具体的 Agent 内核上。

摘要

一个大模型只会「吐字」——它自己打不开文件、跑不了命令、记不住上一回合。harness(载体 / 运行时)就是包在模型外面的那层:工作区、工具、权限、会话记忆,以及那个「让活儿持续推进」的循环。Claude Code、Codex 是 harness,DeepSeek Harness(dsh)也是;区别在于 dsh 把「插件边界」推到了极致——模型适配器、工具注册表、会话日志、乃至 Agent 循环本身,全是可替换的插件,没有一个「特权核心」需要打补丁。

这个特性,恰好击中企业 ERP 智能化最难的一环。ERP 是钱的系统,底线是正确、可审计、可追责;因此大模型在 ERP 里的正确姿态只能是「AI 提议,确定性引擎执行」。而要把这条原则落成工程,你需要一个能在每个环节插入护栏的 Agent 运行时——权限要能接地、写操作要能被校验拦截、大额要能转人工、每一步都要留痕、生成的代码要能在沙箱里跑。dsh 的 tools/* 守卫管道、审批策略、append-only session log、ctx.sandbox 缝,天生就是这些护栏的挂载点。

更关键的是:cmx 平台需要的地基大多已经在了。metaKind 元数据(DCT/DOC/FLC)天然是给模型「接地」的语义层;cmx-flow BPMN 引擎天然是人在环 Agent 的执行骨架;落库列校验 + CmxErrCode 天然是挡幻觉写库的确定性关卡;cmx-data-auth 的 PDP/PEP 天然是权限接地;Rust + WebAssembly 沙箱天然是安全执行的基质。这场变革对 cmx 不是「重造」,而是「接线」——把 dsh 的编排层,接到已有的语义层、校验关卡、工作流与沙箱上。

本文分四部分:(一)把 dsh 调研透——Cordis 微内核、profile/bundle/patch 组装、turn/step 循环、事件流会话日志、能力缝、五种运行形态、模型无关设计;(二)为什么 dsh 适合做「智能企业操作系统」的内核——用操作系统隐喻做逐概念映射;(三)dsh × cmx 详细集成方案——总体架构、能力工具化、五层护栏落点、端到端闭环;(四)分阶段落地路线 M0→M6 与诚实的边界讨论。

图目录:图1 dsh 分层插件架构 · 图2 Agent Loop(turn/step)· 图3 append-only Session Log · 图4 「智能企业操作系统」隐喻映射 · 图5 总体集成架构 · 图6 五层纵深护栏落点 · 图7 端到端报销→凭证闭环 · 图8 分阶段路线图。全部为内嵌 base64 SVG,无外链、离线可读、随文档走。

第一部分 · dsh 是什么(调研)

1.1 定位与背景

DeepSeek Harness(命令行 dsh)是 DeepSeek AI 开源的 agent harness,采用「一切皆插件(everything is a plugin)」架构,底层由 Cordis 驱动——Cordis 的设计写在论文《A Programming Paradigm for Spatiotemporal Composability》里,且它先于 harness 存在:作为开源聊天机器人框架 Koishi 的基石已有四年,是一个与 agent 无关的通用插件内核。

几条要点先厘清,避免误解:

它不是模型。dsh 不训练、不托管、不内置权重;它调用你配置的任意 provider。MIT 开源 ≠ 推理免费——provider 的调用费照付。
它是「模型外面那层」。一句话起步:npx @deepseek-ai/dsh web,浏览器打开 http://127.0.0.1:3080。需要 Node ^22.19.0 || >=24(奇数版本如 Node 23 落在范围外,启动失败)。
它是 developer preview。迭代极快,会有破坏性变更 —— 生产采用前务必 pin 版本并对照当前官方文档核对 API。

1.2 核心理念:Everything is a Plugin(图 1)

dsh 架构文档开宗明义:「产品的每一部分都是插件,包括模型适配器、工具注册表、会话日志、以及 Agent 循环本身,所以每一部分都可从配置替换。没有特权核心需要打补丁:你通过在其它插件旁边挂载一个插件来扩展 dsh,而注册是一种 effect(效果),当其插件卸载时会自动回退(unwind)。」

这套机制靠 Cordis 的三个原语支撑:

ctx.effect —— 可逆副作用。插件做的每一处注册(注册工具、挂适配器、加事件监听)都是一个可回退的 effect。
生命周期事件 ready / dispose / fork —— 干净的装载 / 拆卸 / 分叉。
service 系统 —— 依赖排序,让插件之间按依赖关系协作。

可逆性对 agent 是安全属性,不只是整洁:一个能改自己运行时的 agent,唯有当这些改动可逆时才值得拥有。Cordis 保证的正是那条最底层的性质——无论改了什么,都是干净地改、且能改回来。对 ERP 这种「错一步要担责」的系统,这条性质极其重要。

分层组装(profile / bundle / patch)。 一个运行中的 dsh 是启动时由有序层叠(layers)组装出的插件树:

profile(如 web、headless)—— 存在 Harness home 里的具名组合;它列出自己叠哪些 bundle、装哪些 out-of-tree 插件、以及用户自己的 cordis.patch.yml。
bundle —— Cordis config 行 + 它们挂载的代码的分发格式;每个 bundle 在自己 package.json 的 dsh 字段里声明(dsh.profile 列 bundle,dsh.bundle 指向 patch 文件)。
dsh-base —— 每个 profile 的第一层:模型适配器、工具、持久化、沙箱与审批策略、设置、凭据、遥测。dsh-web-app 加浏览器应用;dsh-headless 加一个无服务器的一次性 runner。
叠加顺序:profile 列出的每个 bundle(按序)→ profile 的 cordis.patch.yml → home 级的 → 任意 --patch 覆盖层。一个 patch 按 id 命中某一行、替换其整块配置,或插入新行。

一条命令看你的机器实际启动出的树:dsh --profile web --dump-config——它打印的任何一行,你都能用自己的 patch 覆盖或插入。这就是「从配置替换任意能力」的落地方式:不改 dsh 源码。

核心包与 ctx 键(贡献到 Cordis 树上的能力缝):

包	负责	`ctx` 键
`core/session`	append-only `SessionEvent` 日志 + 内存 store	`ctx.sessions`
`core/system-prompt`	提示段 + 工具 schema 装配	`ctx.systemPrompt`
`core/tools`	作用域工具注册表 + 守卫执行管道	`ctx.tools`
`core/agent`	`Agent` 接口、活注册表、`agent/*` 事件	`ctx.agents`
`core/agent-loop`	实现该接口的默认驱动	`ctx.agentLoop`
`core/scope`	按 agent 的作用域注册原语	(库,无键)
`llm/llm`	消息 / 流词汇 + 适配器缝	`ctx.llm`

1.3 Agent Loop:turn / step 执行管道(图 2)

dsh 把「一次干活」拆成两级:step = 一次模型请求 + 它调用的工具;turn = 零个或多个 step——turn 在有输入前打开,一旦「无所欠(nothing is owed)」就关闭。整个回合的事件流如下(简化自架构文档的伪代码):

turn/start
  claim 下一步输入 + 一条排队消息
  装配 prompt 段 + 工具 schema
  -> agent/pre-step                 reject | enter(messages)
     (拒绝、或首个 enter 被改写为空 -> 关闭该 turn 不产生 step,但留痕)
     step/start
     把进入的消息追加为 user/message
     从日志 derive 出模型历史(deriveMessages)
     agent/request -> llm/stream -> assistant/chunk* -> assistant/message
     tool/call* -> tools/pre-execute -> tools/execute -> tools/post-execute -> tool/result*
     step/end
     (工具还欠一次请求,或下一步输入到了 -> claim -> 下一步)
  -> agent/turn-stopping
turn/end

turn/*、step/*、user/message、assistant/*、tool/* 是durable session 事件;其余是跨三个域的在途扩展点。
agent/pre-step、agent/request、llm/stream、三个 tools/* 是 waterfall(瀑布):监听器必须调 next() 才委托下去;agent/turn-stopping 是串行、无 next()。
agent/pre-step 决定模型看到什么:监听器可改写被 claim 的消息或直接拒绝;一个被拒绝或为空的首次 claim,仍然关闭一个「没花任何 step」的 durable turn——连「尝试」都会被日志记录。

为什么这对 ERP 是关键接缝? 三个 tools/* 事件,正是护栏的落点:tools/pre-execute 挂权限接地(cmx-data-auth PDP/PEP)与落库列校验前置;tools/execute 让工具在沙箱内跑;tools/post-execute 做结构化结果回灌 / 脱敏。你不需要改 Agent 循环,只需在这三个钩子上挂插件(详见图 6)。

编排原语(长流程 / 子任务 / 多智能体的地基):

agent.inject() —— 追加模型可见的上下文,落在下一次被接纳的请求里(注意:注入的上下文在 inbox 里等,直到另一条消息唤醒驱动)。
ctx.sessions.fork(source, boundary?, childSessionId?) —— 在某个边界处分叉一个活会话,这是 dsh 的一等 API。
Subagent providers —— 在同一接口后差异极大:从一个全新的子 agent,到「委托给另一个产品的一个 turn」。实验性的 Agent Teams(ctx.agentTeams)在可续跑 subagent 之上,叠了 durable 名册、任务板、邮箱——这正是「多 Agent 协作办一件跨模块业务」的原生支持。

1.4 append-only Session Log:一切派生自事件流(图 3)

这是 dsh 架构里被反复强调的「真相源」。会话日志是模型所见上下文的来源:deriveMessages() 从它投影出模型历史,原始 assistant/chunk 事件保留回放与 UI 保真;fork、resume、transcripts、遥测、持久化,全部派生自这条流。

一条铁的运行时不变量:

Model-visible means logged(模型可见即已记录)。 凡是能进入一次模型请求的东西,都必须能从日志重建,且有一条运行时不变量断言它。这就是为什么「让模型看到一种新输入」必须新增一个 session 事件:扩展 SessionEventMap,并从日志渲染——没有后门能把东西塞进模型视野而不被记录,因为记录本身就是视野的来源。

图 3 · append-only Session Log —— 一切派生自事件流

对 ERP 的意义 —— 天然的审计流。 生产团队能运维一个 agent 的前提,是「出事能复盘」:当 agent 改错了一张单据,开发者应能回答它看到了哪条提示、有哪些工具 schema 可用、命令返回了什么、下一步决策如何产生。dsh 的 append-only 日志把这些变成默认可得——而这与 cmx 已有的 cmx-flow hi_activity 活动历史、协同编辑 op-log 的留痕范式同构。换句话说:你们已经在用「事件流即真相」的思路做流程与协同,dsh 把同一思路推广到了整个 Agent 会话。

1.5 能力缝(capability seams):一次替换,全局改变

一个**缝(seam)**是一个可替换能力的三个角色:声明接口的 Service Definition、实现它的 Service Provider、使用它的 Consumer(常是一个面向模型的工具)。加一个能力 = 同时设计这三者。

缝的价值在于「一次 provider 替换改变整个产品」:文件系统与子进程 provider 共享同一个执行世界,把它们指向一个远程沙箱,Bash、PTY、LSP 会一起搬过去,无需 provider 分叉。这条对 ERP 部署形态极有用——本地 / 远程 / 多租户隔离,是换 provider 而非改业务代码。

新行为该挂哪里(架构文档的扩展点地图,摘取与 ERP 相关的):

目标	机制
加一个模型 provider	在 `ctx.llm` 注册其适配器
加一个面向模型的能力(工具)	在 `ctx.tools` 注册;其 schema 自动进提示装配
给某个会话一套不同能力集	组一个 agent preset;service 行需 `isolate` realm
加 shell / 持久终端执行	注册 `ctx.shell` / `ctx.terminals` 后端
加一个「人类命令」	在 `ctx.commands` 注册;不经模型 turn 直接分派
加后台工作	在 `ctx.jobs` 注册;`job_*` 工具收集或停止它
加文件系统访问 / 策略	注册 `ctx.fs` provider 或听 `fs/*` 事件
约束被 spawn 的进程	用 `ctx.sandbox` 后端;consumer 在 spawn 前包裹 argv
拦截一次请求 / 工具 / turn	用其 `agent/` 或 `tools/` 事件;`agent/turn-stopping` 可停 turn
加模型可见上下文	调 `agent.inject()`
加 UI / 编辑器集成	驱动 `ctx.agents`,从 `session/event` 渲染
加 durable 会话状态	扩展 `SessionEventMap`;从日志渲染与回放
分叉一个活会话	`ctx.sessions.fork(...)`

1.6 五种运行形态(front doors)

同一个内核,不同插件组合,暴露出五种「前门」:

形态	启动 / 用法	说明
Web UI	`npx @deepseek-ai/dsh web` → `:3080`	默认前门;`--no-open` 只起服务不开浏览器
Headless	`pnpm dsh --profile headless "summarize this workspace"`	无服务器一次性 runner;脚本 / CI 入口;需 `DEEPSEEK_API_KEY`
ACP server	JSON-RPC over stdio	Agent Client Protocol 自动化服务;把 dsh 作为 agent 嵌进你自己的宿主 / 编辑器
Python SDK	`pip install deepseek-harness-sdk`	驱动 dsh 的 subprocess SDK;自带 Node runtime,目标机无需装 Node;支持 Linux x64/arm64、macOS 14+ arm64
TUI	可装 TUI profile	独立;非两个自动初始化的默认 profile 之一

Python SDK 的形状(嵌入 cmx 后端最可能走这条路):它是一个跑在 JSON-RPC stdio 上的子进程 SDK,继承 dsh 环境变量(DEEPSEEK_BASE_URL / DEEPSEEK_API_KEY,可指向本地代理):

from deepseek_harness import DeepSeekHarness

with DeepSeekHarness(
    provider="deepseek-official",
    model="deepseek-v4-flash",
    max_tokens=49_152,
    cordis="examples/jsonrpc-agent/cordis.yml",   # 换成你自己的插件组合
) as harness:
    result = harness.run("Make the requested code change.")

provider 选择所选 Cordis 组合注册的 provider 路由;model 是该适配器解析的模型 id;max_tokens 是根 agent 及其进程内后代的每请求输出上限(省略则由 provider 默认接管)。
Session.run() 返回 RunResult(session_id, final_response, finish_reason, events, notifications, session_root);finish_reason 取自该区间最后一个 turn/end 的 kind(如 completed / max-tokens / error)。
复用同一 harness 与 session id,会保留会话拥有的 Bash 进程(工作目录、导出变量、shell 函数都在)——对「多步跨命令的业务办理」很关键。

1.7 模型无关:换 provider 不改产品

dsh 是 provider 无关的。在 Settings → Models → Add a custom provider,填 provider ID、base URL、API 协议、key、模型列表即可。协议三选一:

openai-completions / openai-responses —— 指向 OpenAI 兼容端点(含 Codex/OpenAI 生态)。
anthropic-messages —— 指向 Claude 兼容端点。

对 cmx 的直接价值:这意味着 cmx-agent 可以同时接私有 / 自建模型(本地推理,满足数据不出域的合规要求)与公有前沿模型(复杂任务),并按任务分级路由——简单任务走小 / 快 / 本地模型,复杂推理才上大模型。这与《ERP-AI 变革方案》第十一节「成本与 ROI:大小模型分级」的对策直接对上。没有「Claude Code / Codex 集成」这种具名功能;跨产品互通是通过这套 provider 协议 + subagent provider 泛化实现的。

1.8 生态

「插件生态」是官方主打:README 请第三方作者给仓库打 dsh-plugin GitHub topic 以便发现;有专门的插件开发指南与社区 skill(dsh-plugin-guide),以及脚手架(create-dsh-plugin / dsh-plugin-starter,含 --verify 冒烟)。加一个工具 = 写一个 Cordis 插件、在 ctx.tools 上注册——比等官方支持快得多。

第二部分 · 为什么 dsh 适合做「智能企业操作系统」的内核

「智能企业操作系统」不是一句口号。如果把 ERP 看成一台操作系统——业务数据是它的文件系统,业务能力是它的系统调用,流程是它的进程调度,权限是它的保护环——那么 dsh 恰好补上了这台 OS 缺的那个「内核 + 系统调用表 + 调度器」,而 cmx 平台已经把「文件系统、驱动、权限位、日志、沙箱」大半备齐了。

这张映射表要传达的判断是:dsh 与 cmx 不是两套要硬拼的东西,而是一台操作系统的「上半身」与「下半身」。dsh 提供与业务无关的通用机制(挂载、调度、事件、守卫、日志);cmx 提供企业语义与确定性执行(元数据、引擎、校验、权限、审计)。二者经由 ctx.tools / ctx.llm / ctx.sandbox 等缝对接——每一处对接都是「注册一个 provider」,而非「改一处核心」。

几条尤其契合的点:

微内核 ↔ 一芯多壳。dsh 的 Cordis「无特权核心 + 有序层叠」与 cmx 已反复实践的 cmx-web-chassis「一芯多壳」(中立核 + 薄壳 + ServiceSpec 装配)是同一种架构直觉。cmx 的 flow / report / rules / model / mdm / data-auth 全是「一芯多壳」抽出来的独立微服务——它们天生适合作为 dsh 的能力 provider被挂载。
系统日志 ↔ 审计留痕。dsh 的 append-only session log 与 cmx 的 hi_activity、协同 op-log 同构;把 Agent 会话的审计,并入 ERP 既有的审计体系,几乎是「同一种事件流的延伸」。
权限位 ↔ PDP/PEP。dsh 的 tools/* 守卫 + 审批策略,正是 cmx-data-auth(决策 PDP / 执行 PEP + 约束 AST 多后端编译)与 IAM 的挂载点。
沙箱 ↔ Rust + Wasm。dsh 的 ctx.sandbox 缝,对上 cmx 已有的 GlobalExtismEngine / cmx-http WASM 沙箱(deny-by-default、能力精授、SSRF 防护、配额)——这是 Agent 安全执行 AI 生成代码的基质。
文件系统 ↔ 语义层。给模型「接地」靠的是元数据:**cmx-model / cmx-meta-data 的 DCT/DOC/FLC(metaKind 分类学)**就是这张「inode 表」——它让 Text-to-Query 生成的查询「字段对得上、口径不出错」。

第三部分 · dsh × cmx 详细集成方案

3.1 总体集成架构(图 5)

一句话:dsh 作 Agent 内核(cmx-agent),cmx- 引擎群作工具 / 驱动层,五层护栏横切每一层。* 分六层,自上而下:

逐层设计:

交互 / 渠道层。门户对话入口 + 可嵌 Web Component(复用 flow/rules 已验证的 FlowElementBase / RuleElementBase 可嵌组件范式)+ IM/邮件/工单 + 开放 API/SDK/ACP。对话与传统表单并存——高频结构化录入,表单仍更高效;探索、归因、跨模块任务,对话更强。
模型层 ctx.llm。私有 / 自建模型(本地推理,数据不出域)+ DeepSeek V4-Pro/Flash + Claude(anthropic-messages)+ OpenAI 兼容(openai-*),按任务分级路由;换 provider 不改产品。
cmx-agent 内核 = dsh。Cordis 微内核 + Agent Loop + Session Log(审计)+ System Prompt 装配 + 接地上下文注入(agent.inject())。部署上,内嵌兜底(嵌入门户后端)与独立微服务(cmx-agent :80xx,经 center_client 回连)两种形态并存——与 cmx-flowengine 走过的 S0→S6「内嵌↔独立」路线完全同构。
cmx 能力工具层 ctx.tools(把 ERP 能力暴露为工具,schema 自动入提示)。分三类(呼应《ERP-AI 变革方案》图 5):查询工具(接地取数 Text-to-Query)、动作工具(建单 / 凭证草稿)、流程工具(发起 / 推进 BPMN),外加报表 / 主数据 / 规则工具。这里是接地的关键——AI 不猜数据,而是调工具查真数据、调工具做真动作。
确定性引擎层 · cmx- 微服务(一芯多壳 · 不可绕过)*。cmx-flowengine(:8091)、cmx-rulesengine(:8094)、cmx-report(:8092)、cmx-model/meta-data(:8093/:8096)、cmx-mdm(:8095)、cmx-gl(总账过账)、cmx-data-auth(数据权限)。一切写操作的最终关卡。
数据层 · PostgreSQL。事实数据(总账 / 库存 / 单据)、元数据(字典 / 单据 / 流程模型)、审计事件流、db-per-tenant 多租户。

横切护栏贯穿每一层,是下一节的主题。

3.1.1 cmx 能力如何暴露为工具

每个 cmx 引擎已经是独立微服务 + 稳定 HTTP 契约,把它包成一个 dsh 工具是机械活。以「查某组织某期间的试算平衡」为例(示意):

// 一个 Cordis 插件:在 ctx.tools 注册一个查询工具
export function apply(ctx: Context) {
  ctx.tools.register({
    name: 'gl_trial_balance',
    description: '取某组织在某会计期间的试算平衡(借贷发生额与余额)',
    // schema 自动进入 system-prompt 装配,模型据此决定何时调用
    parameters: {
      type: 'object',
      required: ['org_id', 'period'],
      properties: {
        org_id: { type: 'string', description: '组织 id(受当前用户数据权限约束)' },
        period: { type: 'string', description: '会计期间 YYYY-MM' },
      },
    },
    async execute(args, { signal, session }) {
      // 落在 tools/pre-execute 之后:权限已接地、参数已校验
      const r = await fetch(`http://cmx-report:8092/api/gl/trial-balance`, {
        method: 'POST',
        headers: cmxAuthHeaders(session),   // 透传租户 / 用户 / 令牌
        body: JSON.stringify(args), signal,
      })
      return await r.json()   // 结构化结果,tools/post-execute 可再脱敏
    },
  })
}

要点:

工具即微服务的薄封装。cmx 引擎的信封(ApiResp)与错误码(CmxErrCode)直接复用;工具层不重造业务逻辑。
schema 自动进提示。ctx.tools 注册后,其 JSON schema 自动参与 ctx.systemPrompt 装配——模型「知道有这个工具、参数是什么」。
认证透传。工具从 session 拿到当前租户 / 用户 / 令牌,透传给引擎——权限在引擎侧接地,工具层不做授权决策(职责分离)。
读写分离。查询工具可较早放开;动作工具(建单 / 过账)必须挂在下一节的护栏之后。

3.2 五层纵深护栏 —— 钉在 dsh 管道的具体钩子上(图 6)

《ERP-AI 变革方案》立了「五层护栏」的愿景;本节把它逐层钉到 dsh 的具体扩展点上——这是「愿景」变「工程」的关键一跃。

护栏	dsh 挂载点	cmx 现成实现
① 权限接地	`tools/pre-execute` 守卫	cmx-data-auth PDP/PEP + IAM:按当前用户 / 租户裁剪「能看 / 能做」的范围
② 确定性校验	`tools/execute` 前置关卡	落库列校验 CmxErrCode:类型 / 精度 / 非空 / 借贷平衡 / 业务规则——幻觉挡在写操作之外
③ 人在环	`agent/turn-stopping` + 审批策略 + `ctx.commands`	大额 / 高风险 / 低置信 → 转 cmx-flow 人工审批(附 AI 归因与建议)
④ 全程审计	append `SessionEventMap` 事件	谁 · 何时 · 依据什么 · 如何决策——可回放追溯(与 hi_activity / op-log 同构)
⑤ 沙箱执行	`ctx.sandbox` 后端	Rust + WebAssembly(cmx-http):deny-by-default · 能力精授 · 燃料预算 · 用完即弃

读 / 写非对称是这套设计的灵魂:

读操作(查询 / 归因)主要靠 RAG + 语义层接地降低幻觉,门槛低、见效快,可较早放开。
写操作(建单 / 过账 / 审批)必过 ②确定性校验 + ③人在环——这是 ERP 之所以是 ERP 的底线,AI 永不可绕过。

一句话原则:AI 提议,引擎执行;人设目标,系统行动。 大模型可以「幻觉」出一张错的凭证,但它过不了校验引擎那一关——像一个能言善辩却没有签字权的助理:提案再多,盖章的永远是那台一丝不苟的机器。这套护栏不是为 dsh 新造的:cmx 平台的 PDP/PEP、CmxErrCode 落库校验、cmx-flow 审批、审计留痕、Wasm 沙箱——早已就位,dsh 只是把它们钉到 Agent 管道的具体钩子上。五层是纵深(defense-in-depth):任一层失手,后一层仍在;层层叠加,才敢把写操作交给 Agent。

3.3 端到端闭环:「一句话报销 → 凭证」(图 7)

抽象架构落到一个真实场景,看 AI 与确定性引擎如何分工。用户只说一句「把这张差旅发票录成报销并生成凭证」:

分工一目了然:

Agent(dsh) 负责「想清楚」——录成什么、怎么记账:调查询工具接地(费用政策 / 科目 / 预算),再用 cmx-rulesengine 的 FEEL / Collect 决策表定科目、算税、拆借贷分录,起草一张未落库的凭证草稿。
确定性校验(CmxErrCode) 负责「把关」——类型 / 精度 / 借贷平衡 / 权限;不过关不落库。
cmx-flow 负责「治理」——金额 < 阈值且校验通过则自动过账(cmx-gl)+ 留痕;超阈值 / 触发规则则转人工审批(附 AI 归因与建议),审批后再过账。
审计(session log) 负责「留痕」——每一步都落进 append-only 日志,天然可回放追溯。

这个闭环跨 rules / model / flow / gl 四个引擎,却因为「一芯多壳 + 稳定契约」而无需任何一处改核心——每一处对接都是一个工具注册 + 一次微服务调用。它也正是《ERP-AI 变革方案》图 6「P2P Agent 闭环」的一个具体实例化。

关于「凭证 DOC + 会计科目 COA 部署」的前置:cmx 已有的《单据转凭证方案 P0/P1/P2》已把「业务单据→会计分录→组装凭证」打通到「止于 cv_* 表未部署本库」;本闭环的落地依赖先部署凭证 DOC 与 COA 字典 + 下游 cmx-gl 过账(另案)。这两件事定夺后,图 7 即可从「设计」变「真机」。

第四部分 · 落地路线与边界

4.1 分阶段路线图 M0 → M6(图 8)

对齐《ERP-AI 变革方案》的「Copilot → Agent → AI-Native」三范式与「爬 → 走 → 跑」三节奏。不要一步到位;每阶段都要有可度量 ROI 才进入下一阶段。

里程碑	交付	阶段
M0 · 接线验证(2–4 周)	dsh 起壳 + 1 个只读查询工具(cmx-model/report)→ 跑通「一句话问答」	爬
M1 · 只读 Copilot	查询工具群(flow/rules/report 状态)+ 门户对话入口	爬
M2 · 护栏地基	`tools/*` 守卫接 cmx-data-auth PDP/PEP + 落库校验 pre-execute + 审计事件	走
M3 · 受控写操作	动作工具(建单 / 凭证草稿)走校验 + 人在环(→ cmx-flow 审批)	走
M4 · 流程编排	subagent / Agent Teams 编排跨引擎长流程(P2P / 报销 / 对账)	走
M5 · 沙箱与自助	`ctx.sandbox`(Wasm)跑 AI 生成查询;Text-to-Query 语义层深化	跑
M6 · 成熟域 AI-Native	对话为主 + 多租户 + 独立 `cmx-agent` 微服务(:80xx)	跑

度量口径:爬阶段量「采纳率与满意度」;走阶段量「自动化率与差错率」;跑阶段量「单位业务成本与周期」。没有度量的 AI 转型,是烧钱的信仰。

M0 的最小可行接线(建议第一周就跑通):

npx @deepseek-ai/dsh web 起壳,配一个 provider(私有模型或 DeepSeek)。
写第一个 Cordis 插件:一个只读查询工具,封装 cmx-report 或 cmx-model 的一个现成 GET 端点(如「查某单据定义」「查某报表数据」)。
dsh --profile web --dump-config 确认工具已挂进树。
对话里问一句自然语言,验证「模型→调工具→取真数据→接地回答」闭环。
打开 session 目录看 JSONL 日志,确认审计流成立。

跑通 M0 = 证明「接线」范式成立;后续每个里程碑都是在这条线上加护栏、加能力、加自主度。

4.2 诚实的边界与风险

任何只讲愿景不讲代价的叙事都不负责任。针对 dsh 这个具体选型,有五道坎:

developer preview 的不稳定。dsh 明确会有破坏性变更。对策:pin 版本、把「工具封装层」与「dsh 版本」解耦(工具只依赖 ctx.tools 契约的稳定子集)、升级前跑一遍工具冒烟套件。这与 cmx 一贯的「契约面 + parity 测试」习惯一致。
插件边界的兼容成本。「一切皆插件」的代价是更多兼容边界:插件版本、权限、共享 service 需要一起测。对策:把 cmx 侧的 provider 插件集中在一个受控 profile 里,统一版本、统一冒烟。
幻觉与正确性(通用坎,dsh 无法豁免)。对策不是消灭幻觉(做不到),而是隔离幻觉——靠第三部分的五层护栏把幻觉挡在写操作之外,靠 RAG + 语义层降低读操作幻觉。不能接受幻觉的环节,就不要让 AI 单独拍板。
数据 / 元数据质量。AI 接地的前提是元数据干净。垃圾进,垃圾出——cmx 的 DCT/DOC/FLC 治理越规范,Text-to-Query 越少出错。这不性感,但绕不过。
成本与合规。推理有真实成本,Agent 多步调用放大之;企业数据不能随便喂公有模型。对策:用 dsh 的 provider 无关性做大小模型分级 + 本地私有部署 + 数据脱敏 + 权限接地 + 全程审计——合规不是障碍,是 cmx 相对 AI 新势力的信任溢价。

4.3 结论

dsh 是什么:一个 MIT 开源、模型无关、「一切皆插件」的 Agent harness;微内核 Cordis 无特权核心,启动时按 profile 组装插件树;turn/step 循环 + append-only 事件流会话日志(「模型可见即已记录」);五种运行形态;tools/* 守卫 / 审批 / 沙箱 / 审计都是可挂载的扩展点。
为什么适合做企业智能操作系统的内核:它补上了 ERP 这台「操作系统」缺的内核 / 系统调用表 / 调度器,而 cmx 已备好文件系统(元数据)/ 驱动(引擎)/ 权限位(data-auth)/ 日志(审计)/ 沙箱(Wasm)。
怎么结合:dsh 作 cmx-agent 内核,cmx-* 引擎群经 ctx.tools 暴露为工具,五层护栏钉在 tools/pre-execute / tools/execute / agent/turn-stopping / SessionEventMap / ctx.sandbox 五个具体钩子上;读操作早放开、写操作必过校验 + 人在环。
这不是重造,是接线:cmx 缺的不是地基,而是把大模型的编排层接到已有语义层、校验关卡、工作流与沙箱上的那根线。dsh 恰好是那台趁手的接线内核。

AI 提议,引擎执行;人设目标,系统行动——这十六个字,配上 dsh 这台可插拔、可审计、可回退的 Agent 内核,是 cmx 平台走进智能企业操作系统时代最稳的一条路。

参考来源

deepseek-ai/deepseek-harness —— 官方仓库(README / 架构文档 / Python SDK,真相源)
docs/architecture.md —— Cordis、profile/bundle、turn/step 流、session log 不变量、能力缝、扩展点地图
python/sdk/README.md —— Python SDK(JSON-RPC stdio、Session.run()、provider/model/max_tokens)
VentureBeat — DeepSeek Harness launches as open source rival to Claude Code, alongside V4-Pro
InfoQ — The Open-Sourcing of DeepSeek Harness Opens the Door to Modular, Unbundled AI Agent Infrastructure
The New Stack — DeepSeek open sources an agent harness where everything is a plugin
Habr — Inside DeepSeek Harness: Cordis, Session Events, Tool Pipelines, and Permission Boundaries
Cordis — the plugin kernel · 论文 A Programming Paradigm for Spatiotemporal Composability
DataCamp — DeepSeek Harness Tutorial · deepseek-harness-sdk on PyPI
HarcoChen/dsh-plugin-guide · 0xsline/awesome-deepseek-harness

cmx 平台内部参照:

《从记录到行动:传统 ERP 在大模型时代的深度变革》—— 本文的愿景姊妹篇(五层护栏、AI 提议·引擎执行、cmx-container 资产映射)
《Codex 开源 harness 全面了解》—— 同类调研(Codex 的 Rust 重写、内核级沙箱、两旋钮心智模型)
cmx-flowengine S0→S6「内嵌↔独立微服务」路线、cmx-web-chassis「一芯多壳」、cmx-data-auth PDP/PEP、cmx-rulesengine FEEL/Collect、《单据转凭证方案 P0/P1/P2》

本文对 dsh 的技术描述基于 2026-08 公开的官方仓库与报道;dsh 为快速迭代的 developer preview,具体 API 请以采用时的官方文档与所 pin 版本为准。集成方案结合 cmx-container 平台真实架构(metaKind 元数据、cmx-flow 流程引擎、落库校验 + CmxErrCode、cmx-data-auth、Wasm 沙箱、一芯多壳微服务)。核心原则「AI 提议·确定性引擎执行」适用于一切以正确性与可审计性为底线的企业系统。