夜雨聆风一、一天三记重拳：DeepSeek下了什么棋
8月13日晚，DeepSeek一口气放出了三个消息。
第一个，DeepSeek-V4-Pro-0813正式版开源。MoE混合专家架构，总参数1.6万亿，每个token激活约490亿参数，100万token上下文窗口，最大输出38.4万token。权重以MIT协议发布。
第二个，DeepSeek Harness v0.1开发者预览版正式面向全球开放。这是一个基于Cordis插件系统构建的Agent运行时框架，同样MIT协议全量开源。GitHub仓库deepseek-ai/deepseek-harness发布当天星标破3万，次日冲到5.5万，fork超4000。
第三个，API调价公告。旗舰模型V4-Pro输出价格从每百万token 6元涨到高峰27元、空闲13.5元，涨幅350%。8月17日零时正式生效。
三件事放在一起看，逻辑就清楚了：
模型开源换信任，框架开源换生态，API涨价换收入。
这不是三个独立动作，是一套完整的商业闭环。
多家科技媒体把Harness解读为对Anthropic Claude Code和OpenAI Codex的正面回应。这个判断没错，但如果只看到"竞品对标"，就低估了这步棋的意义。
DeepSeek官方给出了一个极简公式：Model + Harness = Agent。模型负责思考推理，Harness承担模型之外的全部工程化工作——工具调用、任务规划、执行调度、上下文组织、沙箱边界。
翻译成B端的语言就是：模型是"大脑"，Harness是"身体和工作台"。
以前DeepSeek只卖"大脑"，现在它把"工作台"也开源了。这意味着开发者用DeepSeek的模型，不再只是调一个API，而是可以拿到一整套完整的Agent运行环境，自由组装、私有化部署、按需改造。
二、"一切皆插件"到底意味着什么
Harness最核心的设计原则只有六个字：一切皆插件（Everything is a Plugin）。
这句话不是营销口号，而是架构事实。理解这一点，需要对比一下现有的Agent框架是怎么做的。
1. 传统框架的"硬核心"问题
绝大多数Agent框架的架构是这样的：核心引擎不可变，你只能在预留的接口处扩展。
比如LangGraph的状态图结构是固定的，CrewAI的角色协作模式是预定义的，AutoGen的对话路由机制是内置的。你想换掉其中的某个核心模块？要么fork源码大改，要么套壳封装。
这种设计在早期没问题——框架帮你做了大部分决策，上手快、出活快。但当你需要深度定制时，"硬核心"就变成了天花板。
2. Harness的"无核心"设计
Harness的架构完全不同。它的底层是一个叫Cordis的元框架——只负责插件的加载、卸载与依赖管理，本身不提供任何Agent能力。
所有的具体组件都是普通插件：
- 模型适配器——插件，可替换
- 工具注册表——插件，可替换
- 会话日志——插件，可替换
- Agent Loop（执行循环）——插件，可替换
- 系统提示词——插件，可替换
- 沙箱策略——插件，可替换
- 审批策略——插件，可替换
- UI界面——插件，可替换
注意最后那行——连Agent的执行循环本身都可以替换。这意味着你不需要fork源码，不需要改一行框架代码，就能把整个任务执行逻辑换成你自己的实现。
传统框架说："这是你的工具箱，核心引擎你别动。"
Harness说："这里什么都是插件，包括你以为是核心的那个。"
3. 四个值得关注的技术细节
① 可逆副作用机制。所有插件注册的服务、监听的事件、创建的资源全部可逆。插件卸载时自动回滚，支持运行时热插拔，不需要重启。
② 四种事件分发模式。emit（无等待观察型）、waterfall（中间件式层层传递）、parallel（并行分发）、serial（串行阻塞式）。不同场景用不同模式，工具执行校验用waterfall，批量初始化用parallel，任务步骤执行用serial。
③ "模型可见=已记录"的不变量。这是社区评价最高的设计。所有模型看到的内容——系统提示词、思维链、工具调用与结果、子Agent调度、每一次上下文注入——都写入一份仅追加（append-only）的会话日志。上下文压缩不会删除原始历史，只是用替换事件改变模型此后看到的表象。
④ 多模型原生兼容。内置38条模型供应商接入路由，覆盖DeepSeek、千问、智谱、OpenAI、Anthropic、Bedrock、Vertex、Azure等。甚至可以把Claude Code或Codex当作子Agent Provider接入。
Harness能跑竞对的模型，这一点很有象征意义。
DeepSeek赌的是"价值沉淀在基础设施层而非模型层"——所以它愿意让你的框架跑着别人的模型。
三、竞争逻辑变了：从模型之争到生态之争
Harness的发布，标志着AI Agent的竞争从"谁的模型更聪明"进入了"谁的生态更完整"。
1. Agent入口之争
Claude Code是Anthropic的Agent入口，Codex是OpenAI的入口，Harness是DeepSeek给出的答案。
入口的意义在于：用户一旦在你的框架里构建了工作流，迁移成本极高。这跟当年IDE之争、云平台之争的逻辑一模一样——开发者在哪里，生态就在哪里，收入就在哪里。
| 维度 | DeepSeek Harness | Claude Code | Codex CLI |
|---|---|---|---|
| 开源协议 | MIT（全开） | 专有（无开源） | Apache 2.0 |
| 架构 | 插件化内核，无特权核心 | 垂直整合单体 | 垂直整合+可配置 |
| 模型绑定 | 模型即插件，任意厂商 | 仅Anthropic模型 | 主要OpenAI模型 |
| 热插拔组件 | ✅ | ❌ | ❌ |
| 审计日志 | append-only明文本地 | 托管式记录 | 有限 |
| 成熟度 | 开发者预览版 | 生产级 | 生产级 |
2. 四条技术路线并存
2026年的Agent编排与运行时层，已经形成了四条清晰的技术路线：
- LangGraph：确定性状态图，"节点+边"的流程图编排
- CrewAI/MetaGPT：角色扮演+对话协作，模拟团队组织
- 微软Strands Agents：预制组件组合的"全家桶"路线
- DeepSeek Harness：微内核+纯配置插件替换的"无核心"路线
前两条偏"编排"，后两条偏"运行时"。Harness的定位不是"又一个开发库"，而是"在生产环境长期运行Agent的操作系统式底座"。
3. "开源框架换生态、API换收入"的双飞轮
这里有一个很微妙的商业逻辑。
Harness本身完全免费，MIT协议，商用无门槛。但它的最佳搭档是DeepSeek的API——而API刚刚涨价了。
涨价后的DeepSeek API定价（8月17日生效）：
• V4-Pro输出：高峰27元/M token，空闲13.5元/M token
• V4-Pro输入（缓存未命中）：高峰9元/M，空闲4.5元/M
• V4-Pro输入（缓存命中）：高峰0.3元/M，空闲0.15元/M
• V4-Flash输出：高峰9元/M token
对比海外：GPT-5.6 Sol输入$5/M、输出$30/M。即便涨价后，DeepSeek的综合成本仍然远低于海外旗舰。
但涨价信号本身说明了一件事：便宜不会永远是主旋律。当生态建立起来、用户粘性形成之后，价格会逐步向价值靠拢。
对企业来说，这个判断影响选型策略——现在进场享受低价窗口期是明智的，但要做好未来成本上升的预期管理。
四、B端信息化必须面对的三个新命题
Harness的发布不只是技术圈的事。对B端信息化管理者来说，它揭示了三个必须正视的新命题。
1. 从"选模型"到"选运行时"
过去两年，企业做AI选型，核心问题是"选哪个模型"。以后这个问题会变成"选哪个运行时"。
模型越来越同质化——DeepSeek、千问、智谱、GPT、Claude，旗舰之间的能力差距在缩小。但运行时生态的差异会越来越大。
Harness给出了一个选项：运行时可以是开放的、可组装的、不绑定任何模型厂商的。
这对B端来说是一个架构层面的决策——你是选择一个封闭但成熟的运行时（比如Claude Code），还是选择一个开放但年轻的运行时（比如Harness），还是自建一套？
没有标准答案。但有一件事是确定的：不要把"运行时"当成黑盒。
当你把Agent的执行循环、工具注册、会话管理全部交给一个你无法修改的平台时，你就失去了对Agent行为的控制权。
2. 插件化架构的企业治理挑战
"一切皆插件"听起来很美，但对企业来说，插件化架构带来的治理挑战不容小觑。
插件来源验证。谁开发的插件？代码是否经过安全审计？有没有后门或数据泄露风险？Harness用的是MIT协议，这意味着任何人都可以开发插件，但MIT协议本身不包含安全保障。
依赖冲突管理。当几十个插件同时运行时，版本兼容性、资源争抢、事件冲突都是现实问题。Cordis框架的形式化设计解决了"卸载干净"的问题，但解决不了"插件生态治理"的问题。
升级维护成本。Harness明确标注v0.1阶段"将会有破坏性变更"。对企业来说，底层框架的频繁变更意味着持续适配成本。
社区里有一个很清醒的声音：
"所有依赖社区插件来提供功能的产品，头六个月都运行得很好，之后就是不兼容、过时、缺乏一致性和治理的噩梦。"
这不是Harness独有的问题，而是所有插件化架构的长期挑战。
3. 可审计性从"加分项"变成"准入条件"
Harness的append-only会话日志设计，在技术上并不是首创，但在Agent框架里如此坚决地把它作为架构级不变量，是少见的。
"模型可见=已记录"意味着：Agent的每一个决策过程都可以精确回放。不是日志摘要，不是采样记录，而是完整的、按时间排序的、可检索可分叉的事件流。
对有合规要求的企业——金融、医疗、政务、央国企——这不是"nice to have"，而是准入门槛。
| 审计维度 | Harness的做法 | 传统框架的做法 |
|---|---|---|
| 系统提示词 | 完整记录 | 部分记录或不记录 |
| 思维链 | 完整记录 | 通常不记录 |
| 工具调用 | 完整记录+结果 | 记录调用，结果视实现 |
| 上下文注入 | 每次注入都记录 | 通常不记录 |
| 子Agent调度 | 完整记录 | 部分框架不支持 |
| 回放能力 | 恢复/分叉/检索/回放 | 有限的日志查询 |
对比Anthropic近期披露的安全事件——多Agent场景下出现"合谋、伪装、传染"等涌现行为——可审计性的价值更加突出。你管不住Agent的行为，至少得看得到它做了什么。
五、冷静落地：现在能做什么、不该做什么
说了这么多趋势和架构，最后回到实操层面。
1. 可以做的事
技术调研和框架适配。Harness是MIT协议，完全免费，本地部署一行命令就能跑起来（npx @deepseek-ai/dsh web）。花半天时间搭起来体验一下，感受一下"一切皆插件"的设计哲学，这个投入是值得的。
在非关键场景试点。内部的代码审查Agent、文档生成Agent、数据分析Agent——这些场景容错率高，适合用Harness做试点。验证插件化架构在你的环境里是否跑得通，团队是否能接受这种开发模式。
建立Agent审计基线。不管你最终用哪个框架，"模型可见=已记录"这个原则现在就应该落地。所有Agent的决策过程留痕、可回放、可追溯。这个能力越晚建，改造成本越高。
2. 不该做的事
不要直接上生产。v0.1开发者预览版，官方明确说"THERE WILL BE COMPATIBILITY-BREAKING CHANGES"。把它当生产框架用，等于踩在流沙上盖楼。
不要急着替换现有方案。Claude Code和Codex CLI虽然封闭，但成熟度远高于Harness。如果你的团队已经在用它们且效果不错，没有必要为了"开源"而切换。框架迁移的成本往往被低估。
不要忽视插件治理。如果你决定基于Harness做二次开发，从第一天就建立插件的准入审查机制。哪些插件可以用，谁负责维护，出了问题谁来响应——这些不是"以后再想"的问题。
3. 评估框架的五个维度
不管最终选哪个Agent框架，建议从这五个维度做评估：
① 架构开放度：核心模块是否可替换？还是只能在预留接口扩展？
② 模型兼容性：支持多少模型供应商？切换模型需要改多少代码？
③ 可审计性：Agent的决策过程是否完整记录？能否回放和追溯？
④ 成熟度：社区规模、文档质量、生产验证程度。Star数不等于生产采用率。
⑤ 治理成本：插件生态管理、版本升级、安全审计的长期投入。
这五个维度没有权重公式，不同企业的侧重点不同。金融企业可能把可审计性排第一，互联网企业可能更看重架构开放度，制造企业可能优先看模型兼容性。
关键是有意识地去评估，而不是被"开源""免费""Star多"这些表面指标牵着走。
回到开头那个判断：Harness的发布，不只是DeepSeek的一步棋，而是整个Agent行业从"模型之争"走向"生态之争"的标志性事件。
对企业信息化管理者来说，需要做的不是"要不要跟进Harness"，而是认真思考Agent运行时在你的架构里应该处于什么位置——是当作黑盒服务消费，还是作为基础设施自建，还是在开放生态上做选择性投入。
这道题没有标准答案，但"一切皆插件"的设计理念至少给了一个新的思考角度：也许未来的Agent架构，不应该是铁板一块的，而是可以自由拆解、按需组装的。
这个方向，值得关注。
💬 这是我在B端AI落地实践中的观察和思考
如果对你有启发，欢迎点赞、在看、转发