【摘要】智能体操作系统沿技术栈分化为3个层级，2款代表性产品分别锚定运行时层与交付层，二者分层共存且在能力资产层正面竞争。内容搭建三层坐标分析框架，拆解架构基因、场景边界、生态治理4个核心维度，给出3问判定法与选型复核清单，明确企业选型的核心决策变量。

核心关键词：DeepSeek Harness｜WorkBuddy｜智能体操作系统｜Agent运行时框架 ｜企业智能体选型｜智能体分层架构｜Agent平台落地｜插件生态治理｜交付完成度vs控制权｜DeepSeek Harness 与 WorkBuddy 怎么选｜智能体运行时与工作台差异｜运通链达研究

引言

2026年，智能体落地进入工程化深水区，市场上冠以“智能体操作系统”的产品超过20款，层级定义始终模糊。2026年3月9日WorkBuddy上线；同年8月13日DeepSeek Harness（以下简称DSH）以MIT协议开源v0.1开发者预览版，发布后短时间内star数突破5万。

注：以下所有DSH用户数据均指官方API统计口径，WorkBuddy任务、生态数据均来自官方产品披露口径，二者统计边界不同，不可直接换算对比。

两款产品几乎同时占据技术社区讨论中心，最常见的提问是“DSH和WorkBuddy哪个更强”。这个问法预设了二者处于同一竞争层级，但本质上一个造底盘，一个造整车，本就不是同赛道的竞品。两者真正的交锋不在各自锚定的层级，而在中间的能力资产分发权。

一、概念校准：智能体操作系统的三层边界

智能体操作系统并非单一层级的产品，而是由运行时、能力资产、交付三层构成的完整技术栈，层级错配是绝大多数选型失误的根源。

Harness Engineering概念于2026年2月由HashiCorp联合创始人Mitchell Hashimoto正式命名，随后经OpenAI工程实践与Anthropic技术报告推向行业主流。行业已经形成一个基本共识：Agent = Model + Harness。模型决定推理上限，Harness负责将推理组织为可执行、可恢复、可验证的任务过程，承载工具调度、状态持久化、沙箱隔离、故障恢复、会话回溯等工程机制。

市场上有两个最常见的误判。一是将DSH等同于代码增强IDE，忽略其内核级可替换的运行时属性。二是将办公类Agent简化为聊天套壳，忽略其背后的权限体系、安全沙箱与完整交付链路。这两个误判，都会直接导致选型出现层级错配。

本文将智能体操作系统划分为三层自下而上的技术栈，作为全文统一分析工具：

• 运行时层：对应传统OS的内核空间，负责模型路由、工具注册、沙箱隔离、会话管理、循环调度

• 能力资产层：对应驱动与包管理体系，负责技能、插件、连接器、领域专家能力的分发与治理

• 交付层：对应用户态应用体系，负责成品工作台、权限管控、组织流程对接与结果验收

两者真正的正面冲突不在各自锚定层，而在中间的能力资产层。

图1 智能体操作系统三层坐标与产品定位

爱分析《2026中国企业智能体市场规模报告》将产业链拆分为四层，其中“智能体操作系统层”大致对应本文的能力资产层与部分运行时层。该层级市场规模从37.4亿元起步，2028年触及90.7亿元峰值后回落至54.7亿元，是全产业链唯一呈倒U型走势的层级。

这一走势背后的双重挤压，正是DSH与WorkBuddy做出相反架构选择的共同压力源：底层模型厂商向上整合能力，上层交付产品向下收敛内核。两者都在绕开被管道化的命运，只是路径相反——DSH向下暴露控制点，WorkBuddy向上收敛复杂度。

核心结论：智能体操作系统没有统一定义，产品定位取决于其在三层技术栈中的核心锚点；运行时层输出控制权，交付层输出完成度，二者的交汇与争夺集中在中间的能力资产层。

Q：三层之间是否存在绝对的技术边界？

A： 不存在硬性技术边界，边界由产品的开放策略定义。成品产品会向下封装更多运行时能力，开源底座也会向上提供部分默认组件。

Q：判定产品层级的核心标准是什么？

A： 核心标准是产品不可被替代的最小能力集，以及控制点的暴露对象。面向开发者开放内核修改权的锚定运行时层，面向业务用户交付结果的锚定交付层。

二、出身决定论：控制点的原生暴露方向

两款产品的出身路径直接决定了控制点的暴露方向，也决定了后续所有架构取舍的底层逻辑。

DSH源自模型厂商的工程下沉。2026年8月13日发布v0.1开发者预览版，采用MIT开源协议，版本迭代速度快，官方明确提示存在破坏性变更可能，不推荐作为唯一生产依赖。

其底层基于Cordis插件元框架构建，Cordis仅负责插件的加载、卸载与依赖管理，核心机制为“可逆副作用”——每个对上下文的修改都附带显式逆操作，插件卸载时沿撤销链回滚，实现真正的热插拔。Harness的全部业务组件，包括模型适配器、工具注册表、会话日志、Agent Loop、沙箱、存储、UI，均为独立插件，原生兼容近40家模型提供方，不与自有模型强绑定。

DSH在v0.1阶段的运行时控制权更接近一种期权，而非可直接落地的生产资产。 期权价值取决于插件生态能否在版本兼容性震荡中维持开发者迁移意愿；若大量插件因破坏性变更在短周期内失效，控制权的实际兑现率会低于宣称值。

WorkBuddy源自云厂商的交付上探。2026年3月9日正式上线，后续迭代推出企业版、独立App、一体化办公套件，产品原生面向办公场景，支持自然语言任务拆解、本地文件操作、多模态内容产出，采用免费增值与企业坐席相结合的商业化模式。

两条路径的分化，是智能体工程分工深化的直接体现。一个定义“Agent怎么被造出来”，一个定义“人怎么用Agent干活”。

核心结论：智能体系统内控制权与兜底责任守恒，用户获取的控制权越多，需要承担的兜底责任就越重；产品化程度越高，兜底责任越向厂商集中。

Q：DSH未来会不会推出成品化的办公套件？

A： 即使推出上层应用，其核心价值仍会锚定底层运行时。模型厂商的核心壁垒始终在模型与基础工程层，不会全面转向终端交付。

Q：WorkBuddy会不会开放底层运行时？

A： 会开放标准化接入接口，但不会开放内核级修改权限。成品产品的稳定性与体验一致性，建立在底层收敛的基础之上。

三、架构哲学：横向可组合与纵向收敛的分岔

两种架构哲学的核心差异，在于将系统复杂度放在哪个位置，以及由谁来承担复杂度对应的成本。

DSH的架构设计围绕三个核心原则展开，本质是把“形态选择权”完全交给使用者。 第一是无特权核心。Agent运行的核心循环并未固化在内核中，而是以普通插件形式挂载。开发者可以替换为单步反思循环、多智能体协调循环、长周期自主规划循环等不同实现，内核不做强制约束。 第二是配置即架构。绝大多数组件替换无需修改源码，通过配置文件即可完成沙箱、存储、模型网关、工具鉴权等模块的切换。架构形态由使用者的配置决定，而非框架预设。 第三是追加式会话日志。所有执行动作仅追加写入、不覆盖修改，天然支持会话分叉、历史回放、对照评测与故障回溯，让可观测性成为运行时的一等公民。

DSH内置4种运行模式，差异仅在于默认加载的插件集：标准模式提供完整工具组合；PTC模式让模型生成代码编排多轮工具调用，中间结果先在程序内筛选汇总；极简模式仅保留最少工具，用于最小环境下的模型基准测试；创造模式允许运行时动态组合新插件集合，适配前沿架构探索。

WorkBuddy的架构走向相反方向，围绕交付效率构建三根支柱。 第一是零门槛接入。免部署、即装即用、模型一站集成，用户不需要选择插件集合，也不需要理解Loop的组织方式。 第二是分层能力供给体系。通过内置连接器与MCP接入外部工具与信息源，叠加专家模型、场景技能、自动化模块，形成完整的能力供给栈。 第三是组织级任务调度。支持多Agent并行执行、统一看板管理、定时任务，以及通过主流IM平台远程调度，让Agent嵌入日常办公节奏。企业版额外封装身份权限、数据隔离、行为审计、沙箱文件保护等治理能力，由管理控制台统一暴露。

这种纵向收敛的架构有明确的边界代价，能力扩展的上限由产品层定义的接口宽度决定。需要在内核级替换Agent Loop或会话存储结构的组织，在WorkBuddy体系中遇到的不是配置成本问题，而是架构层面不存在对应扩展接缝。

横向可组合把成本转移到版本治理与兼容维护上，纵向收敛把成本转移到场景边界外的适配上；两者的成本都不会消失，只会换人承担。

核心结论：DSH把复杂度显式暴露给开发者以换取控制权，WorkBuddy把复杂度隐式收敛进产品以换取完成度，两者是同一问题的两种工程取舍而非优劣之分。

表1 两款产品9个核心维度对照

对比维度	DeepSeek Harness	WorkBuddy
产品形态	开源运行时框架，开发者预览阶段	一体化成品套件，覆盖个人与企业版
技术锚点	运行时层内核	交付层应用+内置能力资产
核心受众	Agent架构师、插件开发者、平台工程团队	职场人员、业务团队、企业管理员
上手成本	需配置Node环境、组件装配与模型接入	零配置，自然语言即可发起任务
交付侧重	面向代码与工程任务，办公交付需自行装配	原生覆盖文档、报表、纪要、定时任务
扩展逻辑	Cordis插件树，可替换内核任意组件	技能包、连接器扩展，受产品架构约束
可观测性	全链路日志、分叉回放，支持回归评测	操作审计、任务追溯，面向企业合规
商业模式	框架开源免费，成本来自模型与部署	免费版+订阅制，企业版按坐席计费
生态角色	底座基础设施，Agent平台的原材料	终端交付产品，直接产出业务结果

Q：PTC模式是不是性能优化开关？

A： 不是。PTC改变的是工具调用方式，官方明确不保证更快或更省Token，收益取决于任务中间结果的规模与处理方式。

四、场景分野：三问判定法与混合架构路径

两类产品的适配场景与架构特性一一对应，选型核心不是功能对比，而是匹配交付物形态、验收主体与兜底责任。

DSH适配四类核心场景。第一类是私有化Agent平台搭建，企业需要自主掌控数据链路、模型路由与安全策略，不希望被成品产品的能力边界锁定。第二类是Agent评测与回归体系建设，依托会话回放与分叉能力，在相同上下文下对比不同模型、策略的执行效果，沉淀标准化测试集。 第三类是批量代码处理与模型基准测试，PTC模式与极简模式剥离冗余组件，稳定控制变量完成对照实验。第四类是前沿架构探索，为Super-agent、长期在线自主智能体等研究方向提供可修改的底层基座。

WorkBuddy适配的场景全部围绕业务交付展开。周报撰写、会议纪要整理、数据汇总、批量文档规整等高频办公任务是最典型的落地场景，用户输入自然语言指令，系统自动完成全流程处理。 本地文件批量处理、报表生成、演示文稿制作、周期性定时任务，都在原生优化范围内。企业级场景下，管理员统一开通坐席、配置权限与数据隔离策略，员工通过客户端或IM入口使用，无需维护任何底层环境。

本文提炼三问判定法，可快速完成场景适配性判断：

1. 最终交付物是可复用的技术框架，还是直接可用的业务成果？

2. 验收交付结果的主体是技术团队，还是业务人员与管理者？

3. 故障、安全与合规风险，由内部工程团队兜底，还是由产品厂商兜底？

当三问指向不同方向时，无需强行二选一，可采用分层拆解的混合方案：用DSH承载底层数据治理与审计链路，用WorkBuddy承载面向业务侧的交付界面，二者在能力资产层完成对接——将DSH的插件能力封装为WorkBuddy可调用的技能或连接器。 这种混合架构在社区实践中已出现雏形，兼顾了底层可控性与前端交付效率，最适合有一定技术团队、但不想全量自研底座的中型企业。

两类方案的退出成本各有侧重，运行时层的退出成本集中在自研代码与插件资产，交付层的退出成本集中在业务流程与权限配置。选型评估时需要把退出成本纳入整体测算，而非只看初期采购或部署成本。

核心结论：Agent产品选型的核心不是对比参数，而是匹配交付物属性、验收主体与兜底责任三个要素；要素不匹配时，参数再强也无法满足真实需求。

表2 场景与产品适配判定清单

业务场景	适配产品	判定依据
企业私有化Agent平台、模型评测体系搭建	DeepSeek Harness	交付物为技术底座，验收方为技术团队，风险由内部承担
全员办公提效、文档批量处理、周期性任务	WorkBuddy	交付物为业务文件，验收方为业务团队，风险由厂商承担
Super-agent、自主智能体等前沿架构研究	DeepSeek Harness	需修改内核调度逻辑，开放架构是必要前提
组织快速落地Agent能力、控制试错成本	WorkBuddy	无需底层投入，开箱即用，配套完整企业管控能力
混合架构：统一底座+标准化办公能力	二者组合	底层运行时自研，上层接入成熟办公技能资产

Q：中小企业没有技术团队，适合用DSH吗？

A： 不适合。没有专职工程团队的情况下，开源底座的运维与定制成本会远高于成品产品的订阅成本。

五、用户画像：使用门槛是定位的直接投影

产品的使用门槛不是设计优劣的结果，而是定位选择的直接投影，门槛与定位一一对应。

DSH的目标用户，是Agent开发者、插件贡献者、AI平台工程师与智能体架构师。这类用户具备模型调用、工具编排、状态管理、安全沙箱等领域的工程能力，能够自主完成组件装配、故障排查与架构优化。 部署与使用DSH，需要准备Node运行环境，理解配置体系，完成模型网关对接、存储后端配置与安全策略设定。官方反复强调其开发者预览属性，不建议将其作为核心生产系统的唯一依赖。

高门槛不是产品缺陷，是开放架构的必然对价。这类用户会把“需要配置”视为控制权的代价，而非缺陷。

WorkBuddy的目标用户，覆盖职场个人、业务团队与企业管理员。使用者不需要掌握任何Agent工程知识，只需要用自然语言描述任务目标，系统自动完成拆解、执行与交付。 产品的核心设计目标，就是把技术门槛降到最低，让Agent能力直接触达业务一线。这类用户会把“需要配置”直接判定为产品不可用。

业务用户问“你能帮我做什么”，开发者问“我能用你造什么”。 这一处差别比参数表更能解释两者的产品形态：前者需要被引导、被兜底、被提供现成能力，后者需要被放开、被暴露、被允许改内核。

核心结论：高自由度必然伴随高门槛，低门槛必然伴随边界约束；不存在既无限开放又开箱即用的智能体系统。

Q：业务人员有没有可能学会使用DSH？

A： 理论上可以，但投入产出比极低。业务人员的核心价值在业务理解，而非工程装配，成品产品更符合效率原则。

六、生态、治理与成本：不对称的中间层争夺

两款产品的生态、治理与商业模式均呈现显著不对称，真正的竞争落点集中在中间的能力资产层分发权。

生态规模上，两者走了完全不同的扩张曲线。DSH发布五天内社区收录5100+插件、覆盖3500+作者，官方API口径日活154万，约60%活跃用户安装过第三方插件。目前分发权分散在GitHub、npm等多个渠道，官方插件市场仍在建设初期。 WorkBuddy官方披露拥有100+领域专家、7万+场景技能供给，生态扩张依托产品与企业渠道。二者统计口径不同，插件与技能的颗粒度、审核标准均存在差异，不可直接横向对比数量。

治理能力上，差距体现在责任归属。WorkBuddy企业版围绕“可控、可溯、可管”构建完整治理体系，包含原生沙箱、敏感路径保护、预设文件规则、审计中心与操作日志，支持自动备份与整体回滚，生态侧实施上架前检测与动态巡检。 对应的代价是治理规则由厂商定义，企业无法在内核级修改安全策略。DSH内置跨平台沙箱、fail-closed（故障时默认关闭权限）安全设计等基础机制，但官方明确提示现有手段无法保证绝对隔离，生产级多租户隔离、权限管控、运维审计体系均需使用者自行搭建，安全与治理责任由使用方承担。

成本结构上，两者收费逻辑完全不同。DSH框架本身开源免费，直接成本来自模型调用与云资源部署，隐性成本来自工程团队的配置、运维、定制开发投入，按中型团队估算，年投入通常高于成品产品的订阅成本。 WorkBuddy采用免费增值+企业坐席计费模式，厂商承担产品迭代、安全运维与能力更新成本，投入可按使用规模精准测算。

分发权的核心价值，在于直接决定生态的定价权、数据回流权与标准制定权。掌握分发权的一方将成为智能体时代的应用商店入口，收割生态的大部分溢价。

核心结论：底层运行时技术的开源化是长期趋势，运行时本身难以形成持久壁垒；经过验证的场景化能力资产，以及资产的分发治理体系，才是智能体时代的核心竞争壁垒。

Q：开源底座会不会最终消灭成品Agent产品？

A： 不会。开源降低了底座的获取成本，但不会降低场景打磨、治理体系建设与产品体验优化的成本。

七、选型校验与止损：典型误区与复核清单

选型失误的共同根源是跳过层级判断直接进入功能对比，可通过典型误区规避与标准化复核清单完成校验止损。

第一个常见误区：用模型榜单替代产品选型。模型跑分与产品场景适配度之间没有稳定映射关系，DSH的极简模式服务于模型评测，不代表对应交付场景的成功率。选型必须回到场景清单与验收标准。

第二个常见误区：版本定位错配。将开发者预览版当作稳定生产系统，或用交付层工作台承载自研Agent平台。DSH官方明确提示版本可能出现破坏性变更，建议固定依赖版本；交付层产品的扩展边界由厂商定义，强行承载平台级需求会快速撞上架构天花板。

第三个常见误区：用消费级体验标准衡量运行时产品。冷启动需要配置环境、界面暴露执行细节，这些在运行时层是控制权的副产品，在交付层才是产品缺陷。评价标准必须随产品层级切换。

选型复核可通过四项标准完成校验，四项全部对齐再进入技术细节评估：

1. 交付物形态与产品层级匹配

2. 验收角色与产品目标用户匹配

3. 兜底责任与团队能力匹配

4. 退出成本与项目周期匹配

发现层级选错后，先冻结范围，把已投入部分重新归位：运行时层成果转为内部平台组件，交付层成果转为业务试点。随后按三问判定法重划边界，避免在同一项目里混合两类验收标准。

判断选型方案是否过度包装有一个简易标准：让不了解Agent的读者通读方案，如果无法复述“谁交付什么、出问题找谁”，说明结论被概念名词淹没，大概率存在层级错配。

核心结论：选型误区的共同根源是跳过层级判断直接进入功能对比，可执行的纠正动作是在评审首屏写清交付物形态、验收角色与兜底责任方。

Q：发现层级选错后，最优先的止损动作是什么？

A： 先冻结项目范围，再按层级拆分已有成果，避免在同一项目里混合两类验收标准。强行对齐只会持续放大返工成本。

结论

DSH与WorkBuddy不构成同级替代关系，二者分别占据智能体技术栈的上下两层，是底座与成品的分层共存关系。两者的正面交锋集中在能力资产层，争夺的核心是智能体能力的分发标准定义权。

企业选型的核心问题从来不是“哪款产品更强”，而是“组织目标是造机器，还是拿结果”。不要用开源运行时承载全员办公，不要用交付层工作台承载自研Agent平台。

未来2-3年最可能的格局不是二选一，而是同一企业内部两套栈并存：平台团队用开源运行时支撑创新业务，业务部门用交付层产品满足通用办公需求，两者通过能力资产层的标准接口完成对接。 可观察的验证信号有两个：开源运行时厂商是否推出官方托管版本，交付层厂商是否开放插件级的内核修改权限。

长期来看，大模型会持续内化更多执行与调度能力，底层运行时的工程价值会逐步向模型层迁移。竞争重心会持续向上移动，最终决定格局的不是内核技术的先进性，而是谁能定义智能体能力资产的分发与治理标准。

【链达锐评】

两款产品是操作系统层受上下挤压的两种逃生路径，胜负分水岭在能力资产分发标准，而非底盘与整车的分工。

数据口径说明：DSH用户规模、插件数量数据仅统计官方API接入与公开社区收录口径；WorkBuddy技能规模、治理能力数据来自官方产品与生态披露。二者统计边界、颗粒度与审核标准均不同，不具备直接可比性，请勿交叉运算。