上周三晚上，我照例刷 GitHub Trending，发现一个项目从零冲到了五万多星——DeepSeek Harness，一夜之间登顶 Hacker News。说实话，我第一反应是"又一个 Agent 框架"。但仔细看完架构文档，又花了大半天实际跑了一遍之后，我觉得这玩意儿跟市面上的确不太一样。

Agent 框架的战国时代，缺的不是"另一个"

先说说背景。过去一年多的 Agent 框架，我用过的不少。LangChain 最早抢了坑位，但实在太重了——为了调一个 OpenAI 的 API，你得装一堆用不上的依赖。AutoGPT 火了一阵，但实用性存疑，跑个正经任务经常卡住。CrewAI 做多 Agent 协作还行，但学习曲线不算低。后来 Claude Code 和 Codex 把"代码 Agent"这个场景做通了，可惜闭源——你想改个行为？没门。

所以当 DeepSeek 打出"一切皆插件"这个口号的时候，我第一反应是：又来画饼？但仔细看了 Harness 的实现方式之后，发现他们确实找到了一条跟前面所有框架都不一样的路。

Harness 的"一切皆插件"到底是个啥？

官方给了一个很简洁的公式：

Model + Harness = Agent

模型负责思考推理，Harness 负责干活。但真正有意思的，是它怎么干活的。

传统 Agent 框架通常把模型、工具、记忆、调度这些能力写死在代码里。你想换一个模型？改代码。想加一个工具？改代码。想做点定制？改代码。Harness 的做法是反过来——所有东西都是插件。模型是插件，工具是插件，会话管理是插件，存储是插件，连 Agent 主循环本身都是插件。你不需要改框架，只需要装插拔插件。

这套设计基于 Cordis 元框架。Cordis 本身只负责一件事：插件的加载与生命周期管理。它不关心你跑的是什么模型、用什么工具——它只提供一个"插槽"标准，让不同的插件能互相协作。你可以在一个 Harness 实例里跑 GPT-5 做推理，用 DeepSeek 做代码补全，再用 Claude 做安全审查——三个模型各司其职，插拔自如。

我实际跑了一下，安装确实简单：

npm install @deepseek/dsh

然后启动一个代码 Agent：

dsh start --mode code

本地会拉起一个 Web UI，能看到它实时操作文件系统、执行终端命令、读取代码库。第一次看到它自己改了代码、跑测试、测试挂了又回头改代码的时候，说实话有点毛骨悚然——不是因为它多聪明，而是因为它真的在"干活"，而不是在"生成文字"。

四种模式，各有各的适用场景

Harness 内置了四种运行模式，我每个都试了一遍：

Standard 模式：像是一个"带监督的实习生"。每做一个操作之前会问你"确认执行吗？"，适合做代码审查或者单文件重构。我试了让它重构一个两百行的 Python 模块，拆得还挺干净，就是每一步都要确认，流程有点慢。

PTC 模式（Plan-Test-Code）：这个模式比较激进。它会先写测试用例，再写实现代码，让测试驱动整个开发过程。我试了个"给现有代码库加一个新功能模块"的场景，它先写了一组单元测试，然后逐个实现，最后跑测试全部通过——说实话，这个工作流已经很接近资深工程师的节奏了。

极简模式：不挂载任何额外插件，只保留最核心的模型交互能力。适合你只想快速问个问题或者跑个脚本，不想要任何"智能体"那些花里胡哨的东西。

创造模式：自由度最高，适合实验性场景。你可以自由组合各种插件，甚至写自己的插件来扩展 Harness 的能力。

v0.1 的坑，我也想说说

毕竟是预览版，问题不少。

最大的问题是长任务稳定性。我试了一个稍微复杂的场景——让它在现有代码库里加一个新功能模块，涉及文件结构修改、路由配置、数据库迁移、API 接口四个步骤。结果它改到第三步的时候把自己绕晕了，上下文窗口塞满之后开始胡言乱语，把之前改过的文件又改了一遍，直接导致代码冲突。Harness 的上下文管理机制目前还比较初级，长任务场景下容易"失忆"。

插件生态还比较薄。官方插件目前大概十几个，社区贡献的也就二十来个，跟 npm 的千万级生态比起来差距很大。不过 DeepSeek 选了 MIT 协议，插件接口设计得确实干净——我花了一个小时看懂接口文档，又花了一个小时写了一个自定义插件，开发体验比 LangChain 的插件系统好不少。

还有个小问题：文档不够完善。官方 README 只说清楚了怎么装和怎么跑，但插件开发指南、架构设计文档、常见问题基本没有。社区里已经开始有人自己写 Wiki 了，但官方文档的更新速度跟不上社区的讨论热度。

对开发者的建议

如果你现在想上手 Harness，我建议从 Standard 模式开始，拿它做代码审查或者单文件重构——这两个场景它完成得比较稳，而且每一步都有确认，不容易翻车。

等你对插件机制熟悉了，可以试试 PTC 模式。我个人的经验是：对写测试比较规范的项目，PTC 模式的效果明显更好——因为测试用例本身就是一种"需求文档"，模型理解起来比自然语言更准确。

对于团队来说，Harness 的"一切皆插件"意味着你可以把内部的代码规范、部署流程、甚至代码审查规则都封装成插件，让 Agent 直接用。这一点比 Claude Code 的闭源生态要灵活得多，毕竟你不需要依赖 Anthropic 来决定什么时候支持你们的内部工具链。

不过也别指望它能马上替代你手下的工程师。v0.1 离"生产可用"还有距离——长任务场景的稳定性、插件生态的丰富度、文档的完善程度，这些都需要时间。但方向是对的。

最后

我比较好奇的是，这种"一切皆插件"的 Agent 架构，会不会成为 Agent 领域的"安卓时刻"？还是说，插件化带来的灵活性，最终会被"需要自己组装"的高门槛抵消掉？

你觉得呢？欢迎评论区聊聊。