摘要： 开源仅数日，DeepSeek Harness GitHub Star 突破 18.8 万，Fork 超过 2 万。它为何能够迅速引爆 AI Agent 开发者社区？
答案可以浓缩成六个字：一切皆可插件。
它不再试图打造一个功能固定、边界明确的黑盒 Agent 产品，而是将自己定位成一套可以自由组装、自由扩展、自由改造的 Agent 基础设施。
当模型、工具、记忆、Agent Loop、沙箱、文件系统甚至 UI 都可以被替换时，Agent 就不再只是一个“软件”，而更像是一套可以由开发者重新定义的 AI 操作系统。
一、为什么是 DeepSeek Harness？
如果你深度使用过各种 AI Agent，大概率都会遇到一个共同的问题：
功能越来越多，但自由度却越来越低。
很多 Agent 产品看起来非常强大，集成了代码执行、文件操作、浏览器、搜索、记忆、工具调用等能力，但这些能力往往已经被开发者提前设计好了。
模型是什么、工具怎么注册、任务怎么执行、上下文如何管理、Agent 如何循环、数据如何保存，甚至 UI 怎么展示，通常都有一套固定的实现。
用户可以“使用”它，却很难真正“改造”它。
DeepSeek Harness 试图从底层改变这种模式。
在其底层 Cordis 架构中，核心设计理念可以概括为：
Everything is a Plugin。
也就是：
一切皆可插件。
模型适配器可以是插件，工具可以是插件，Session 管理可以是插件，Agent Loop 可以是插件，沙箱环境可以是插件，文件系统甚至 UI 层也可以通过插件机制进行扩展。
这意味着 DeepSeek Harness 交付给开发者的，并不是一个已经设计好的“成品 Agent”。
它更像是一盒 AI Agent 乐高积木。
你可以：
- 更换底层模型
- 自定义工具
- 重组工具链
- 修改 Agent Loop
- 替换 Session 管理方式
- 接入自己的开发环境
- 接入浏览器、手机、模拟器等外部设备
- 自定义 UI
- 甚至重新定义 Agent 的运行方式
这也是它最值得关注的地方。
它真正提供的并不是某一个具体功能，而是一套构建 Agent 的底层基础设施。
二、快速上手：本地部署 DeepSeek Harness
需要注意的是，项目目前仍处于 Developer Preview 阶段，迭代速度非常快。
因此，实际使用过程中可能会遇到 API 调整、依赖变化以及破坏性更新。
1. 环境准备
首先确保本地已经安装：
- Node.js LTS
- pnpm
- Git
可以通过下面的命令检查 pnpm 是否安装成功：
pnpm -v
如果能够正常输出版本号，就可以继续下一步。
2. 克隆项目并安装依赖
进入项目目录后执行：
pnpm install
安装完成后，根据项目当前版本的要求进行构建。
例如：
git init
git add .
git commit -m "initial commit"
pnpm run build
随后启动 WebUI：
pnpm dsh web
正常情况下，服务启动后可以通过浏览器访问：
http://127.0.0.1:3080
如果浏览器没有自动打开，也可以手动复制地址访问。
注意： 由于项目处于快速迭代阶段，实际命令可能会随着版本更新发生变化。部署时建议以项目当前版本的官方 README 和 CLI 提示为准。
三、接入模型：云端 API 与本地模型
DeepSeek Harness 的另一个优势，是模型本身并不是被锁死的。
你可以根据实际需求选择不同的模型来源。
云端模型
如果希望获得更快的响应速度以及更强的推理能力，可以接入云端 API。
对于开发者来说，OpenAI Compatible API 已经成为目前比较成熟的模型接入标准。
因此，可以根据自己的需求接入不同的模型服务，甚至通过模型聚合平台进行统一管理。
这样做最大的优势是：
Agent 框架和模型彻底解耦。
今天可以使用一个模型，明天换成另一个模型，而不需要重新设计整个 Agent。
本地模型
如果更关注隐私、成本以及长期运行能力，也可以使用本地模型。
例如可以结合：
- Ollama
- Jan
- vLLM
- llama.cpp
等本地推理框架。
以 Jan 为例，在本地启动 API Server 后，可以让 Agent 直接调用本地模型。
典型的本地 API 地址类似：
http://127.0.0.1:1337/v1
如果本地拥有足够的 GPU 显存，这种组合会非常有意思。
传统 AI 应用的成本通常是：
Token 消耗 → API 费用 → 持续付费
而本地模型则更接近：
一次性硬件成本 + 电费
与此同时，数据可以始终留在自己的机器上。
当然，本地模型目前在复杂推理、工具调用稳定性以及整体执行效率方面，仍然可能与顶级闭源模型存在差距。
但对于一些可以异步执行数小时甚至更长时间的任务来说，这种差距并没有想象中那么致命。
如果任务不要求实时响应，那么：
让本地模型慢慢跑一晚上，可能比持续支付云端 Token 费用更划算。
四、真正的突破：Agent 本身也可以被拆解
DeepSeek Harness 最值得关注的地方，并不是 WebUI，也不是某一个具体工具。
而是它尝试改变了一个非常重要的概念：
Agent 不应该是黑盒。
传统 Agent 的基本结构通常可以理解为：
Prompt → Model → Tool → Result
开发者可以调整 Prompt，可以增加工具，可以更换模型，但真正控制 Agent 内部运行机制的空间并不大。
而在 Cordis 这种插件化架构下，Agent 的内部组件也可以被重新组织。
插件可以向共享 Context 注册 Service、事件以及可撤销 Effect，不同插件之间通过相对稳定的接口进行协作。
这意味着很多原本属于 Agent “内部实现”的东西，现在都有机会被开发者介入。
例如：
工具调用机制
开发者可以自定义工具注册、发现以及调用逻辑。
Session 管理
可以根据实际场景决定对话状态、任务状态以及历史数据如何保存。
Agent Loop
这是最有想象力的一部分。
传统 Agent 往往有固定的：
思考 → 调用工具 → 获取结果 → 再思考
循环。
而如果 Agent Loop 本身也可以通过插件机制进行扩展，那么开发者就可以尝试针对不同任务设计不同的 Agent 执行策略。
组件通信
不同能力之间不再需要全部写死在核心代码中，而是通过插件和服务进行组合。
UI
甚至连用户看到的界面，也可以成为可扩展的一部分。
这使 DeepSeek Harness 看起来越来越不像一个普通的 AI 编程助手。
它更接近一种：
Agent Operating System（Agent 操作系统）
的雏形。
五、WebUI：看似简单，却非常实用
很多开发者第一次看到 DeepSeek Harness 的 WebUI 时，可能会产生一个疑问：
为什么 Agent 又要做一个 WebUI？
但真正运行长任务之后，就会发现 WebUI 的价值其实非常直接。
假设一个 Agent 任务需要运行 3 小时。
如果只能通过终端操作，那么你可能需要一直盯着终端窗口，或者通过 SSH 连接服务器查看执行状态。
但如果 Agent Runtime 和 WebUI 分离，就可以把 Agent 部署在：
- Windows
- Linux
- NAS
- 家用服务器
- 云服务器
- GPU 服务器
然后通过浏览器访问。
这对于长时间运行的任务尤其重要。
例如：
晚上下班之前启动一个任务。
Agent 开始自动：
分析需求 → 编写代码 → 执行测试 → 修复 Bug → 再次测试
然后你直接离开电脑。
几个小时之后，重新打开浏览器，就可以查看任务执行到了哪一步。
这其实也是 WebUI 最大的价值：
它不是为了炫技，而是为了让 Agent 真正具备持续运行的能力。
简单，有时候反而是最强大的生产力。
六、社区实践：从 FPS 游戏到 iOS 自动化
一个真正有生命力的开源项目，最终的上限往往不是由官方决定的。
而是由社区决定的。
DeepSeek Harness 最值得关注的地方之一，就是它开始出现越来越多围绕插件机制构建的实践案例。
案例一：本地模型从零构建 FPS 游戏
社区中出现过一个非常有代表性的实践：
开发者使用本地模型，让 Agent 长时间自主完成一个第一人称射击游戏。
整个过程包含大量工具调用和代码修改。
据相关实践记录：
- 操作步骤：约 687 步
- 输入 Token：约 8790 万
- 输出 Token：约 82.2 万
- 模型运行时间：超过 5 小时
最终生成的游戏并不是一个简单的 Demo，而是包含了：
- 敌人生成
- 枪械系统
- 武器后坐力
- 动态光影
- 太阳轨迹
- 游戏场景
- 交互逻辑
等多个完整机制。
这个案例真正值得关注的并不是“AI 写出了一个 FPS”。
而是：
AI 开始能够连续执行一个大型软件工程任务。
过去我们更多把 AI 当成：
“程序员的副驾驶。”
现在则开始出现另一种模式：
“让 AI 自己完成一个项目。”
这两者之间存在非常大的区别。
当任务可以异步执行时，本地模型“慢”的缺点也会被明显削弱。
例如一个模型只有 60 Token/s。
如果让它连续运行一整晚，那么速度慢并不一定意味着效率低。
相反，如果云端模型需要持续按照 Token 计费，那么长时间运行大型任务的成本可能会迅速增加。
因此：
本地模型 + Agent + 长任务
可能会成为未来非常重要的一种组合。
七、案例二：iOS 全链路自动化
另一个非常有意思的方向，是移动端自动化。
社区已经出现针对 iOS 开发环境的插件，可以让 Agent 与 iOS 模拟器甚至真实设备进行交互。
例如可以通过类似下面的命令安装相关插件：
dsh plugin --profile web add @zseven-w/dsh-ios@latest
dsh web
在这种模式下，Agent 不再只是“写代码”。
它可以进一步参与整个开发流程：
编码 → 构建 → 启动 → 操作设备 → 测试 → 分析问题 → 修改代码 → 再次构建
这就形成了一个真正意义上的闭环。
如果进一步接入：
- 浏览器
- Android
- iOS
- 模拟器
- 真机
- Git
- CI/CD
- Docker
- 云服务器
那么 Agent 的活动范围就不再局限于代码编辑器。
它开始具备：
操作开发环境的能力。
而插件机制恰恰为这种扩展提供了一个非常自然的入口。
八、“一切皆插件”意味着什么？
如果把这件事情放大来看，DeepSeek Harness 真正有价值的地方其实不是“插件很多”。
而是它正在尝试改变：
Agent 到底是什么？
过去，我们理解 Agent 往往是一个完整的软件产品。
例如：
模型 + Prompt + 工具 + UI + Memory + Agent Loop
全部被封装在一起。
用户拿到的是一个完整产品。
而插件化架构则试图把它拆开：
Agent
│
┌──────────┼──────────┐
│ │ │
Model Tools Memory
│ │ │
Plugin Plugin Plugin
│ │ │
└──────────┼──────────┘
│
Agent Loop
│
Plugin
│
┌────────┴────────┐
│ │
Sandbox FileSystem
│ │
Plugin Plugin
当这些组件都可以被替换的时候，Agent 就从一个“固定产品”变成了一个“可组合系统”。
这其实和早期操作系统、浏览器扩展、Linux 软件生态以及现代 Web 开发框架的发展逻辑非常相似。
核心只负责提供基础设施，具体能力交给生态。
九、真正值得关注的，是 Agent 生态的变化
过去两年，AI Agent 的发展路径其实非常明显。
第一阶段：
聊天机器人
用户提出问题，模型生成答案。
第二阶段：
AI Copilot
模型开始进入 IDE、办公软件以及各种开发工具，辅助人类完成任务。
第三阶段：
AI Agent
模型开始主动调用工具、执行代码、访问文件以及完成多步骤任务。
而现在正在出现第四阶段：
Agent Infrastructure
开发者开始不满足于“使用 Agent”。
他们开始研究：
如何构建 Agent？
如何修改 Agent？
如何让 Agent 接入更多环境？
如何让多个 Agent 协同？
如何让 Agent 长时间自主运行？
这也是 DeepSeek Harness 这类项目真正值得关注的原因。
它解决的已经不只是：
“AI 能不能帮我写代码？”
而是：
“我能不能定义一个属于自己的 Agent？”
十、18.8 万 Star 只是开始
从聊天机器人到 Copilot，再到 Agent，我们已经看到 AI 软件形态发生了明显变化。
过去的软件通常是：
开发者定义功能 → 用户使用功能。
而未来的 Agent 更可能变成：
开发者提供基础设施 → 用户自由组合能力。
这意味着软件的边界开始发生变化。
模型可以更换。
工具可以插拔。
Skills 可以扩展。
Memory 可以替换。
Agent Loop 可以重写。
开发环境可以接入。
手机可以接入。
浏览器可以接入。
甚至现实世界中的设备，也可能最终成为 Agent 可以调用的工具。
这也是“Everything is a Plugin”最值得关注的地方。
它不是简单地把软件做成插件系统，而是在尝试把 Agent 本身变成一个开放的基础设施。
18.8 万 Star 只是这个故事目前最显眼的数字。
真正值得观察的，是未来一年里会有多少开发者开始基于这种架构构建自己的 Agent。
也许几年之后，我们回头再看今天，会发现 AI Agent 真正发生变化的节点，并不是某一个模型发布的那一天。
而是：
Agent 从一个“产品”，开始变成一种“平台”。
而当模型、工具、Skills、开发环境、浏览器、移动设备以及各种执行环境都可以通过插件方式连接起来时，我们看到的就不再只是一个新的 Agent 框架。
而可能是一套正在形成的：
Agent 生态系统。