DeepSeek Harness 带来的 B 端 AI 落地思考

最近 DeepSeek 发布了 DeepSeek Harness （dsh），dsh 既是一个可以直接运行的 Coding Agent ，也是一套 Agent 开发框架，核心思想就是一切皆插件。

有这样一个底座，在 AI 高速发展的今天，不至于过快被淘汰。

就像 dify 刚出来的时候很火，有可视化工作流的配置，但节点是固定的、流程配置是固定的。后来 skill 流行之后，这种方式就有点落后了。

目前很多的 B 端 AI Agent 平台，大多数都是要创建一个 xxx ，xxx 可能是应用、Agent 、AI 员工 等，然后进行一通配置，授权给用户使用，用户进入系统以后，选择一个 xxx，进入聊天窗口，向它提问。

本质上就是给企业做了很多个可以调用工具的聊天机器人。离“真正替企业完成工作”，还是差点意思。

从“回答问题”到“完成工作”

过去几年，ToB AI 的典型场景基本没有太大变化：

• 问数
• 知识库
• 智能客服
• 智能填单
• 合同审核
• 报表生成

这些能力当然有价值，但它们通常只负责一个局部环节，一个单点能力。问数负责查询数据，知识库负责找资料，合同审核负责给出风险意见。

用户真正要完成的工作，却往往是这样的：

检查本月应回款但还没有回款的合同，分析原因，整理负责人，生成 Excel，并通知相关人员持续跟进。

这不是一次问数，也不是一次文档生成，它是一项完整工作，里面可能包含：

1
2

理解目标→ 查询数据→ 识别异常→ 分析原因→ 生成产物→ 提出业务操作→ 人工审批→ 执行通知
→ 验证结果→ 持续跟进

用户并不关心背后调用了几个 Agent、多少个 Tool、哪一个模型。

用户关心的是：

这件事完成了没有？

C 端的 AI 产品基本都这这种，一个或多个入口，将自己的目标描述清楚就可以。

因此，我现在的思路就是：

企业级 AI 产品的核心，不是对话、不是 Agent ，而应该是 Work。

7 个层级

按照以 Work 为核心，从上往下，可以分为 7 个层级

第一层：多入口接入 

用户在哪里，就从哪里把工作接入进来。Web、企业微信、钉钉、飞书、API、定时任务都可以是入口，聊天框只是入口而非产品本身。用户可在 IM 里提问，也可在 Web 工作台创建任务。所有入口最终都归一为同一个 Work，进入同一个 Work Runtime，这一层解决的是"工作从哪里进来"。

第二层：用户工作层 

用户看到的不是 Agent，而是"我的工作"。员工端可以有 AI 工作台、我的工作、待我确认、工作产物等；管理端有企业上下文、能力中心、组织与权限、运行与治理、平台设置等。

第三层：工作应用层 

把"聊天"真正变成一项工作。核心对象有四个：

• Work 是要完成的事；
• WorkRun 是某一次真实执行；
• Artifact 是交付物（Excel、Word、PPT、报告、SQL、方案）；
• Approval 是审批——改 CRM、发邮件、建任务、提交报销等都不能直接执行，必须人确认。

这一层把一句自然语言变成有状态、有产物、有审批、有结果的企业工作对象，和普通聊天系统已是两回事了。

第四层：Work Runtime 

这是系统真正的核心，决定 AI 能否从"回答问题"走向"完成工作"。Runtime 负责理解目标、制定计划、拆步骤、执行、调工具、处理异常、请求审批、失败重试、生成产物、验证结果，整个过程可暂停、恢复、重试。

第五层：Enterprise Harness 

决定工作使用什么样的 AI 运行环境，包括 Model Provider、Agent Loop、Context Provider、Tool/Skill Provider、Memory、Session、Sandbox、Storage、Scheduler、Channel Adapter 等。

同一个 Work，简单场景一个模型加一次问数即可，复杂场景走 Plan→Execute→Verify，甚至多 Agent 协作。

Model、Loop、Context、Tool 都可组合替换，但原则是"可自组合，不可自授权"，权限边界不能失控，这是 ToB 平台的底限。

第六层：Enterprise Context 

这是企业 AI 与 C 端 AI 最大的区别，也是 ToB 壁垒所在。通用 AI 很强，但不知道企业的项目、应收、风险是什么；谁能看什么范围的数据；什么操作必须审批。

平台必须有业务模型、文档知识、指标规则、记忆、组织信息、权限语义，再连接 CRM、ERP、MES、OA、数据库、低代码平台等系统。

低代码平台这时就很有用了，可以提供一套 CLI 供 AI 使用，使用代码平台落地的业务，它天然掌握业务模型与流程，稍加梳理，便可做为 AI 的上下文。

第七层：Enterprise Trust Kernel 

非常关键的一层，包括：身份、授权、策略、密钥、审计、数据安全。AI 可以越来越自主，但企业必须始终知道它是谁、能看什么、能做什么、做了什么，出了问题能找到责任链。

DeepSeek Harness 带来的另一层启发

DeepSeek Harness 把 Agent 的运行环境拆得非常彻底。

模型、工具、文件系统、沙箱、会话存储、Subagent、UI，甚至 Agent Loop 本身，都是插件。插件可以通过配置组合，卸载时撤销相应注册和副作用。

生态如果能跟上，想象空间很大。

它背后的 Cordis 又提出了“时空可组合性”的概念：

• 时间可组合性：组件被移除时，可以完整撤销此前产生的副作用。
• 空间可组合性：组件声明自己依赖哪些服务，并能够随着依赖的出现或消失动态调整状态。

换句话说，一个组件依赖的能力暂时不存在时，不会让整个程序崩溃。可以等新的提供者出现后再恢复工作。

这件事对企业 AI 平台很有启发。

我们过去做 AI 应用、Agent ，随着业务不断变化，慢慢会变成越来越大的固化的程序。更合理的方式，是把这一层理解成一份可组合的 Profile：它不再是巨大程序，而是"谁来干"的配置，至于具体怎么运行，交给底层 Harness 组装。

而且，不管技术发展多快，底座是稳定的，上面各层组件可以随意替换，这样就可以做的比较长久，不会说我刚实现了一个很牛的功能，一发布，就被更好的技术给取代了。也不用担心能力会受到约束，因为可以替换，所以是可以与时俱进的。

五个重点概念

在这套体系下，我认为企业智能工作平台至少需要明确区分五个概念。

一、Work：要干什么

Work 是一次真实工作。

例如：

• 检查异常回款
• 生成项目周报
• 审核采购合同
• 分析项目风险
• 处理报销申请
• 生成低代码脚本

Work 应该有自己的目标、状态、执行计划、步骤、产物、审批、异常、验收标准和最终结果。目标和验收标准是最重要的，这是使用 Codex 的 goal 时得到的经验。

二、AI 员工：谁来干

AI 员工不再是一个长期运行的程序，而是一份员工 Profile。

它定义：

• 岗位职责
• 业务边界
• 可使用的能力
• 可访问的上下文
• 工作策略
• 沟通方式
• 审批规则
• 权限范围

同一个 CRM 专员，可以负责很多不同的 Work。同一个 Work，也可能由多个 AI 员工协同完成。

三、能力：靠什么干

问数、Excel 处理、PDF 生成、合同审核、图表生成、MCP、SKILL，都应该下沉为能力。

以前我们可能把“问数”当成一个 AI 员工。

现在更合理的定位是：

问数是 AI 员工完成工作时可以调用的一项能力。

这意味着过去做的问数、知识库、智能填单并没有失去价值，只是它们不应该继续占据产品最上层，而变成一项基础能力了。

四、上下文：基于什么干

企业 Agent 真正的壁垒，不只是会调用数据库，而是理解企业业务。

它需要知道：

• 什么叫客户
• 什么叫项目
• 什么叫合同
• 什么叫应收
• 什么叫风险
• 这些对象之间有什么关系
• 哪些人可以访问
• 哪些操作可以执行

因此，业务模型、关系模型、指标规则、文档知识和数据权限应该统一成为 Enterprise Context。

通用 Agent 可以访问文件和网页，但企业自己的平台掌握着业务对象、组织权限、流程规则和可执行动作。

五、运行时：以什么方式干

模型只是运行时的一个部分。完整的运行时还应包括：

简单问答可以使用单 Agent Loop；复杂项目分析可以使用 Plan-Execute-Verify；跨领域任务可以使用 Manager-Worker 或多 Agent 协作。

Work 不变，底层 Runtime 可以替换。

什么情况不能替换

虽然 DeepSeek Harness 的插件化思想很有吸引力，但 ToB 平台不能简单照搬“一切皆可替换”。不可替换的一部分就是这上面 7 个层级中的最后一层。

企业级平台必须坚持一个原则：可以自主编排，不可以自我授权。Agent 决定"怎么做"，但企业必须始终掌握"能不能做、能做到什么程度"。

例如：Agent 可以根据任务需要提出：

我需要增加 CRM 查询能力。

但它不能自己决定：

CRM 写权限挡着我，我把权限模块卸载掉。

最后

一点思考，不一定对。