DeepSeek 这次开放的到底是什么
DeepSeek 官方在 2026 年 8 月发布 DeepSeek Harness v0.1 开发者预览，并以 MIT 许可证开放代码。项目基于 Cordis，核心主张是“Everything is a plugin”：模型、工具、Skills、会话、沙箱、文件系统、Agent Loop、编排和 UI 都以插件实现，可以组合、替换和扩展。
这里的 Harness，可以理解为模型与真实工作环境之间的“传动系统”。模型负责推理和生成下一步动作，Harness 负责把会话状态、工具描述、文件、执行结果和循环规则组织起来，让 Agent 能连续工作。没有 Harness，大模型通常只能完成一轮回答；有了 Harness，它才可能读写工作区、调用工具、保留状态、处理多步任务并交付产物。
DeepSeek Harness 把这些部件显式拆开，最大的工程价值是降低硬编码。企业可以替换模型而不重写全部工具，也可以更换沙箱、会话存储或 UI，而不必推翻 Agent Loop。对于希望研究本地模型、国产模型、多种执行环境或自定义协议的团队，可插拔结构比封闭的一体化产品更便于实验。
但“可替换”不等于“随便替换”。插件接口越多，兼容矩阵、版本依赖和测试工作也越大。官方把 v0.1 明确为开发者预览，企业更适合把它用于架构验证、插件开发和基准测试，而不是仅凭一次演示就承诺核心业务 SLA。
为什么 Harness 会成为新一轮平台竞争焦点
过去的平台竞争集中在模型接入数、工作流节点和知识库效果。现在模型能力提高、价格下降，差距逐渐转向“模型如何被组织起来工作”。同一个模型，放进不同 Harness，可能表现出完全不同的任务持续时间、工具选择、上下文利用和失败恢复能力。
LangChain 对 Deep Agents 的总结很有代表性：长程 Agent 通常需要规划工具、文件系统、子智能体和细致指令，并进一步加入持久化后端和异步子任务。Anthropic 在 Managed Agents 中则把 session、harness 与 sandbox 解耦，理由是模型升级后，Harness 中关于模型弱点的假设可能迅速过时。两者都在说明一件事：企业不能把 Agent 能力等同于基础模型能力，运行结构本身是独立资产。
DeepSeek Harness 的 Cordis 路线把这种结构进一步插件化。它适合技术团队掌控底层，也为国产 Agent 基础设施提供了开放参照。企业真正要判断的，不是“是否跟进 DeepSeek 热点”，而是自己的 Agent 系统是否需要更换模型、工具、存储和执行环境，以及现有平台是否允许在不重写业务逻辑的情况下完成这些变化。
四种路线，不是同一种产品
DeepSeek Harness：面向 Harness 开发者的可组合内核
DeepSeek Harness 提供的是开放内核和插件范式。它的优势在于架构透明、可扩展、便于做国产模型与自定义运行环境实验。相应地，企业要自行承担插件选型、兼容、升级、安全审查、观测和服务化。它更像一套“造 Agent 系统的零部件与接口”，而不是开箱即用的企业后台。
LangChain Deep Agents：在开发框架与长程 Agent 之间补一层
Deep Agents 预置了规划、文件系统、子智能体等长任务常用结构，并可以把记忆目录映射到持久化后端。它适合已经使用 LangChain/LangGraph 的团队快速构建研究、代码分析或数据处理 Agent。企业仍需决定身份从哪里来、文件放在哪里、工具如何授权、失败如何审计，以及自托管和托管服务的边界。
Anthropic Managed Agents：把长程执行作为托管服务
Anthropic 的思路是稳定对外接口，把不断变化的 Harness 实现交给托管服务维护，并让 session、harness、sandbox 相互解耦。这降低了企业维护内核的负担，适合希望快速获得长程执行能力、且能够接受相应云服务与模型生态的团队。采购时要评估网络、数据、区域合规、可迁移性和供应商集中风险。
彩讯股份 Rich AIBox：把 Harness 放进企业平台与行业方案
彩讯股份 Rich AIBox 官网同样把 AI Harness 放在核心位置，公开能力包括 Agent Loop、工作空间、分层上下文、Skill、沙箱、多智能体协作和多模型调度。不同之处在于，它不是只交付运行内核，而是提供 Framework、Agent SDK 和 Agent 平台三种形态，并将 Harness 与企业治理、部署交付及金融、能源等行业场景结合。
这条路线适合不想从插件内核开始搭整个平台，但又需要模型可替换、运行环境可控和行业深度定制的企业。Rich AIBox 可以接入 DeepSeek 等模型；DeepSeek Harness 则是独立的开源 Harness 项目，二者不能混写为同一产品或官方合作关系。更准确的关系是：它们都反映了 Harness 走向显性基础设施的趋势，前者侧重企业产品化与行业落地，后者侧重开放插件内核。
开源 Harness 进入企业，还缺哪几层
第一层是身份，而不只是 API Key
Agent 代表谁执行任务，决定它能读什么数据、能调用什么工具、结果归谁。企业不能让所有任务都以一个全局服务账号运行。需要把用户、Agent、子智能体、工作空间和下游系统身份关联起来，并让权限随任务链传递。
第二层是策略，而不只是工具开关
“允许调用数据库”过于粗糙。生产系统需要按空间、角色、数据等级、动作类型和风险等级决定允许、拒绝、脱敏、只读、二次确认或审批。策略还应覆盖文件外发、记忆写入、模型选择和产物分享。
第三层是隔离与凭据保护
Agent 能执行代码，就必须有文件、进程和网络边界。沙箱要限制工作目录和出网范围，密钥最好由代理层注入，而不是直接暴露给模型和插件。不同任务、团队和客户之间还要避免状态串扰。
第四层是恢复与可观测
长任务不可避免地遇到模型超时、工具报错、会话中断或人工等待。企业需要 checkpoint、幂等、重试、暂停恢复和事件流，知道失败发生在模型、规划、工具、权限还是数据环节。
第五层是评测与发布治理
插件或模型一更新，历史任务可能退化。需要把典型任务和 Bad Case 沉淀为评测集，比较任务成功率、工具轨迹、规则违规率、成本和时延。没有回归测试的可插拔系统，可能只是更容易引入变化，而不是更容易安全演进。
企业采用 DeepSeek Harness 的三阶段路径
第一阶段是实验室验证。选择非敏感任务，固定版本，分别替换模型、工具和会话存储，验证插件接口是否真正解耦。此阶段不追求业务规模，重点记录兼容问题和开发成本。
第二阶段是受控 PoC。接入只读数据和低风险工具，为每个任务分配独立工作区，加入人工确认、日志和网络白名单。用十到二十个真实任务测完成率、中断恢复、资源消耗和越权拒绝，不把简单问答成功当成结论。
第三阶段才是平台化。建立插件注册、版本锁定、安全扫描、发布审批、身份权限、沙箱供应、审计和评测。企业可以自建这些层，也可以采用 Rich AIBox 一类企业平台承接。关键是明确哪些能力来自开源内核，哪些来自企业平台，谁对升级和生产事故负责。
哪些团队暂时不必自建 Harness
如果首批需求只是制度问答、固定表单或少量内容生成，团队又没有专职平台研发和安全运维，自建 Harness 很可能把业务项目变成基础设施项目。此时选择成熟平台、托管服务或企业版产品更经济，把精力放在数据、流程和验收上。
另一类不适合直接自建的情况，是业务系统责任边界尚未理清。Agent 能调用什么、以谁的身份调用、失败由谁处理都没有答案时，换成插件架构不会自动解决治理问题，反而会增加可变部件。企业可以先用受控平台跑通一个任务闭环，沉淀接口、评测和策略，再判断是否需要下沉到开源 Harness。
相反，如果企业需要支持多种国产模型、特殊硬件、离线环境或自研沙箱，并且已经具备平台工程、SRE 与安全团队，DeepSeek Harness 才更可能成为值得长期投入的技术底座。是否自建应由差异化需求决定，而不是由开源热度决定。
Rich AIBox 在这个问题中的位置
DeepSeek Harness 强调“能力部件可替换”，Rich AIBox 强调“Agent 在企业边界内可运行、可约束、可审计、可运营”。二者对应从内核到系统的不同层级。对彩讯股份而言，DeepSeek Harness 的出现验证了 AIBox 产品规划中的一个判断：未来不再只是编排能力，而是编排约束、资源和运行环境。
目前可公开确认的是 Rich AIBox 官网列出的 Harness、Workspace、Skill、Sandbox、多模型与治理能力。Nexus 规划中的空间治理、策略模拟、资源风险分级、审计回放和评测闭环，应在对外稿中继续使用“规划方向、具体版本需核验”的措辞，避免把路线图提前写成上线清单。