Harness 不是又一个 Agent 框架——‘一切皆插件‘到底意味着什么

最新推荐文章于 2026-08-22 14:57:21 发布

原创最新推荐文章于 2026-08-22 14:57:21 发布 · 213 阅读

3 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

人工智能

上周三晚上，我照例刷 GitHub Trending，发现一个陌生仓库跟坐了火箭似的往上窜——不到两小时 Star 破了两万，凌晨冲上 Hacker News 榜首。不是新模型，是个叫 DeepSeek Harness 的 Agent 框架，MIT 协议全开源。截至写这篇文章，13 万星，GitHub 历史上涨星最快的项目之一，没有"之一"。

我第一反应跟很多人一样：又一个 Agent 框架？LangChain 还没凉透，AutoGen 还在迭代，CrewAI 刚融完资，Claude Code 和 Codex 已经把"代码 Agent"这个场景做得挺好了——这市场真的缺"另一个"吗？

但仔细看完架构文档，又花了大半天实际跑了一遍之后，我改主意了。它不是一个"又一个"——它走了一条跟前面所有框架都不一样的路。

先说说 Agent 框架的战国时代

过去一年半，我折腾过的 Agent 框架不算少。

LangChain 最早抢了坑位，但实在太重了。为了调一个 OpenAI 的 API，你得装一堆用不上的依赖。AutoGPT 火了一阵，想法挺好，但实用性存疑——跑个正经任务经常卡在半路，你也不知道它到底在想什么。CrewAI 做多 Agent 协作还行，但学习曲线不算低。后来 Claude Code 和 Codex 把"代码 Agent"这个场景做通了，终端体验打磨得不错，可惜闭源——你想改个行为？没门，等官方更新吧。

所有这些框架有一个共同的底层设计：它们都有一个"核心"。核心负责调度、上下文管理、工具调用，其他模块围绕这个核心转。你能扩展的是核心外围的东西，但核心本身是锁死的。就像你买了一台品牌电脑，主板焊死了，能换的只有内存和硬盘。

DeepSeek Harness 选了一条完全相反的路。

"一切皆插件"不是营销口号

官方给了一个很简洁的公式：Model + Harness = Agent。模型负责思考推理，Harness 负责干活。但真正有意思的，是它怎么干活的。

传统框架有一个不可动摇的"核心"。Harness 说：不，我们不需要核心。模型是插件，工具是插件，技能是插件，会话管理是插件，存储是插件，Agent 主循环本身是插件，连 UI 都是插件。没有一个是"核心"，所有东西都可以插拔替换。

你可能会想：这不就是"插件化"吗？VS Code 也有插件系统啊。

区别在于：VS Code 有一个不可替换的核心（编辑器本身），插件是在核心外面扩展。Harness 是连核心本身都是插件。它的 Agent 循环——那个决定"模型什么时候思考、什么时候调用工具、什么时候输出结果"的循环——也是一个插件，你可以换掉它。

底层驱动这套架构的是 Cordis 元框架。你可能没听过 Cordis，但如果你用过 Koishi（那个 Node.js 聊天机器人框架），应该知道它。Cordis 已经在 Koishi 生态里跑了四年，它只做一件事：插件的加载、卸载和依赖管理。DeepSeek 把它搬过来，在上面搭了一层 Agent 的语义。

这意味着什么？意味着你写一个插件，就能给 Harness 加一个能力，不需要改任何核心代码。就像 VS Code 的扩展系统——没有人会为了加一个语法高亮去改 VS Code 的源码，对吧？

四种模式，本质是四种插件组合

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

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

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

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

Creative 模式自由度最高，你可以自由组合各种插件，甚至写自己的插件来扩展 Harness 的能力。

但这里有个关键点你可能没注意到：这四种模式不是写死的功能，而是四种不同的插件组合。 你可以把它们当起点，自己拼一个出来。因为"一切皆插件"，连模式本身也是。

诚实地说说 v0.1 的坑

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

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

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

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

还有一个事情官方自己也不避讳：v0.1 之后会改 API，会破坏兼容性。 所以生产环境要谨慎，但学习和尝鲜完全没问题。

那它跟 Claude Code / Codex 到底有什么不一样？

这个问题我想了很久，最后发现一个比较准确的概括：

Claude Code 是个产品，DeepSeek Harness 是个平台。

Claude Code 的终端体验打磨了快一年，该有的都有。你装上去就能用，不需要配置，不需要写插件。但它是闭源的，你没法改它的行为逻辑——Anthropic 决定什么时候支持什么功能，你就什么时候用。

Codex 虽然也是开源的（Apache 2.0，Rust 写的），但它的架构是传统的"核心+插件"模式，没有 Harness 这么激进地"一切皆插件"。

有个数据挺能说明问题。Composio 做过一组对照测试，把同一个 DeepSeek V4-Flash 模型分别接入 8 套不同 Agent 框架，跑同一批 30 个真实多步任务。结果最好的框架和最差的框架，任务完成率差了将近一倍。同一个模型，不同的 Harness，效果天差地别。这说明 Harness 本身正在成为比模型更重要的变量。

所以结论很清晰：如果你想要一个"开箱即用"的工具，Claude Code 更适合你。如果你想要一个"能自己拼"的平台，想自己定义 Agent 的行为、想私有化部署、想接入自己的工具链——Harness 值得你花时间。