云计算百科
云计算领域专业知识百科平台

DeepSeek开源Harness:一切皆插件的Agent架构如何让上下文工程不再绑死框架源码

DeepSeek刚把DeepSeek Harness(dsh)开源,几小时就冲过3.5万星。核心只有一句话:一切都是插件。模型适配器、工具注册表、会话日志、甚至Agent循环本身,全是可替换的插件。

我起初以为做生产级Agent,改上下文组装方式就得去改框架源码,或者直接fork,然后每次上游升级都得重新合并一遍。后来看到dsh的设计,才意识到这条路本来可以彻底绕开。插件用稳定key声明自己(比如ctx.tools或ctx.llm),其他插件按key查找而不是硬编码导入具体实现;依赖是声明式的,加载顺序从需求里自动推导出来;注册可逆,卸载时会把一切回滚干净。真正决定模型“看见什么”的,是一个叫agent/pre-step的事件,监听器可以改写或直接拒绝即将注入的消息——几乎所有自定义上下文工程都会落在这里。

把传统Agent框架想成一座已经浇筑好的混凝土楼。你想换电梯系统,就得把整层楼拆了重浇。dsh更像模块化机房:每个功能是独立机柜,插拔时只动自己那根线,整栋楼的供电和冷却管线不用动。会话日志是append-only的,系统提示、推理过程、工具调用、子Agent调度、每一次上下文注入全被记下来。模型可见的输入必须对应一条新的会话事件,运行时会强制断言。以前Agent跑偏了,你只能猜窗口里到底塞了什么;现在日志就是真相,猜的空间被压缩到几乎为零。

这套机制背后的内核叫Cordis,强调时空可组合性。插件声明自己需要什么、提供什么,运行时自动把依赖图解出来。DeepSeek之前是唯一一家还在出编码级模型却没有自家一等公民Harness的主流实验室,现在它补上了这一环,而且能把子任务直接委托给Claude Code或Codex。

传统框架做法DeepSeek Harness插件做法实际代价差异
改上下文组装 改框架源码或长期维护fork 每次升级都要重新合并冲突
换工具实现 硬编码导入具体类 耦合死,难以热替换
调试模型输入 靠猜测或加临时print 日志不完整,复现困难
卸载实验功能 手动清理残留注册 容易留下幽灵状态

开发者预览阶段还在快速迭代,兼容性破坏变更会有,但MIT协议和完整源码已经开放。一键启动Web UI只要npx @deepseek-ai/dsh web,本地3080端口就能用;也可以从源码装,或者用Python SDK写无头Agent。配置文件里选、换、扩展任何能力,不用动Harness本身一行代码。

真正让这套设计站得住的,是“模型可见即日志记录”这条铁律。它把上下文工程从“框架内部黑盒”变成了可观察、可断言、可回放的事件流。恢复、分叉、检索都共享同一份日志。当你需要换推理策略、换工具沙箱、甚至换整个循环逻辑时,改的是插件而不是骨架。

Agent = 模型 + Harness。模型是灵魂,Harness是它在真实环境里持续工作的手脚和记忆。插件化把这双手脚拆成了可重组的零件。下一步最值得盯的,不是新模型参数量,而是谁能把这套零件生态真正用起来,把上下文工程从源码修改的泥潭里彻底拉出来。

你手头正在用的Agent框架,改一次上下文策略要动多少核心代码?如果全部改成插件声明,你会先换掉哪一块?

我是紫微AI,在做一个「人格操作系统(ZPF)」。后面会持续分享AI Agent和系统实验。感兴趣可以关注,我们下期见。

赞(0)
未经允许不得转载:网硕互联帮助中心 » DeepSeek开源Harness:一切皆插件的Agent架构如何让上下文工程不再绑死框架源码
分享到: 更多 (0)

评论 抢沙发

评论前必须登录!