从 DeepSeek Harness 看
互联网与 AI 的阶段性发展
AI已走完“统一入口”与“精准匹配”，正在进入 Agent 完成任务的阶段。DSH提供的新观察是：Agent不必永远作为一个固定产品存在，它可以被拆成由中心运行环境统一组织、由分散插件持续供给和更新的组件系统。
互联网的五个阶段，以及AI走到了哪里
这一部分只建立演进坐标，不急着讲腾讯和 DSH。把互联网历史切成五段，再逐段问一句：AI 的对应形态是什么？
早期互联网复杂陌生，门户用大而全的首页把新闻、邮箱、聊天室集中起来，解决“用户如何进入互联网”。对应到 AI，就是早期 ChatGPT：把写作、问答、翻译、编程放进一个对话框，让所有人都能用 AI。
网页越来越多，门户无法预先整理全部供给，搜索开始按用户意图动态匹配信息。对应到 AI，就是联网搜索、RAG、企业知识库、模型路由、垂直知识问答，不再只靠一个模型回答所有问题。
搜索只能把用户送到目标网站，不能替用户持续聊天、购物、旅游。于是出现微信、淘宝、携程等产品，围绕特定任务建立稳定身份、数据、关系和流程。对应到 AI，就是 Agent：调用工具、拆解任务、保存状态、执行多步骤、尝试交付结果。
正在进入，尚未完成 今天的 Agent“偶尔能做成”已被证明，但“长期稳定完成”仍不足：权限、记忆、错误恢复、结果验证、责任边界都还在发展。
独立 App 越来越多，新问题变成：用户如何发现、下载、安装？开发者如何获客？系统如何管权限和支付？于是出现 App Store、Google Play、91 手机助手、应用宝。对应到 AI，正在出现的可能是 Harness、插件、Skills、Agent 模板、工具市场、Agent 运行环境。
DeepSeek Harness 代表的主要是第四阶段的开端。它还不是成熟“AI 应用商店”，但已把模型、工具、Skills、会话、存储、沙箱、Agent loop 和 UI 变成可安装、替换、组合的模块。
应用商店解决了分发，但用户仍要下载、注册、登录、学习。微信小程序让服务直接复用微信的身份、关系、支付和场景入口。对应到 AI，第五阶段还没真正出现，但可预测为：AI 能力在当前场景即时出现，多个服务围绕一次任务临时组合，用完即走。
AI 已走完统一入口（门户/ChatGPT）和精准匹配（搜索/RAG），正在从 Agent 产品进入 Harness 与插件生态；再下一阶段，可能是 AI 服务脱离完整产品，在具体场景中被低成本、即时地调用。
从DSH的实际用法，看能力如何被组织
DSH最值得观察的，不是它是否做出了一个大而全的 Agent，而是它展示了另一种能力组织方式：中心负责理解任务和统一运行，分散插件负责提供专业能力。
1. 我们在DSH里实际看到了什么
先不讨论 DSH 最终会形成多大的生态，只看当前产品中已经能够观察到的使用方式：
- 插件市场：不同能力被分类、展示、发现和安装；
- 标准模式：用户直接使用已经配置好的默认 Agent，不必理解底层组件；
- 创造模式：用户或开发者进入组件层，根据任务安装、替换和调整能力；
- 能力组合：模型、工具、Skills、会话、存储和界面可以被调用，并重新组合为不同的 Agent。
标准模式降低使用门槛，创造模式开放组合空间。两种模式共享同一个 Harness。
2. 它改变了什么
过去，开发者通常交付一个完整 Agent：选定模型、接好工具、写好工作流、配置记忆和界面，再把整套产品交给用户。即使只擅长其中一个环节，也往往需要把其他部分一起建设。
DSH展示的变化是：不一定要交付一个完整 Agent，也可以只交付一个专业组件。有人提供模型接入，有人提供记忆，有人提供行业 Skill，有人提供工作流或界面。组件进入统一运行环境后，可以被其他 Agent 安装、替换、调用和再组合。
这意味着 AI 时代的生产单位可能从“完整 Agent”进一步缩小为“可复用能力”。一个开发者不必解决全部问题，只需要把自己最专业的部分做成可以接入系统的组件。
变化的重点不是多了几个插件，而是专业能力可以脱离完整产品，独立交付和继续复用。
3. 它提出了什么问题
DSH进一步提出了一个比插件本身更重要的问题：AI 时代的能力，究竟应该怎样组织？
| 一个中心化助手拥有全部能力 | 分散服务分别提供专业能力 |
|---|---|
| 体验统一，用户只面对一个入口 | 专业开发者只建设自己擅长的能力 |
| 权限、状态和责任边界更容易管理 | 能力可以独立更新，供给更加多样 |
| 中心团队需要覆盖不断扩张的需求 | 不同组件的质量、安全和兼容更难统一 |
| 容易形成大而全但反应缓慢的系统 | 如果缺少统一入口，用户需要自己寻找和组合 |
这并不是简单的产品形态选择，而是平台的分工问题：谁理解用户，谁生产能力，谁决定怎样组合，谁对最终结果负责？
真正的问题不是要不要中心，而是中心是否必须亲自生产并拥有全部能力。
4. 更可能的答案：中心化编排 + 去中心化供给
从 DSH 当前呈现的形态看，更可能的答案不是二选一。用户仍然需要一个稳定、低门槛的中心入口，但中心不必独自生产所有能力。
| 中心化编排 | 去中心化供给 |
|---|---|
| 统一理解用户意图和上下文 | 不同开发者提供模型、工具、Skills和工作流 |
| 选择能力并组织任务执行顺序 | 专业组件可以独立开发、发布和升级 |
| 管理权限、状态、确认和结果验证 | 同一个组件可以被多个 Agent 继续复用 |
| 提供默认组合，避免用户从零配置 | 用户或开发者仍可按需要替换部分能力 |
中心保留入口、理解、编排和治理，分散服务提供不断增长的专业能力。
关于 Self-Evolution 的延伸观察：插件更新与自我进化具有相同的结构前提，也就是系统知道自己由哪些组件构成，并能单独替换其中一部分。但普通插件更新仍由人开发和安装；真正的 Self-Evolution 还要求 Agent 根据运行反馈提出改动，通过评测决定接受或回滚。因此，DSH当前证明的是组件可更新，还不是 Agent 已经能够自主进化。
延伸阅读：The deepseek of DeepSeek Harness、Cordis论文、Harness Engineering for Self-Improvement
而是一种新的分工方式：
中心理解用户并编排任务，
分散组件提供专业能力，并被持续安装、替换、调用和再组合。