2026年8月25日
和几位老师朋友交流，话题总绕不开一个名字：DSH。但火归火，我看到的却是两种截然不同的态度：一边是营销号式的"碾压 Fable 5"的神话，一边是工程师们看着代码摇头叹息。今天这篇只做一件事：借由DSH这盘"醋"，看看能不能包出一盘真正能吃的"饺子"------Harness Agent。
当 Scaling 开始"到头"
DeepSeek R1 的贡献，是给"如何做思维链"这个问题交了一份可复现的答卷。学术圈跟进得很快，复现论文一堆。但今天一个更尖锐的问题浮出水面：Scaling 终是有头的，如果不 Scaling 怎么办？
借由 DSH，我们探讨一个在agent这个点位"插件"化的思路。它不靠堆更多算力或参数，而是把能力变成一个个可动态加载的插件，塞进一个"表格空间"里。
我们讨论的前提是基于无限猴子定理：如果让一只（或无数只）猴子在打字机上随机敲击键盘，只要给予无限长的时间，它们几乎必然（概率为 1）能打出任何给定的文本，比如《哈姆雷特》或《莎士比亚全集》。------由于token之间的排列组合都已经在模型里边了，我们只需要通过提示词把它们更有效的引导出来。
设计哲学更接近于面向切面编程（AOP） 和依赖注入（DI） ------ 如果你写过 Java Spring，你会觉得它的依赖注入很眼熟；如果你碰过 Node.js，那些回调逻辑你会心一笑；如果你用过 Reactjs，HMR 的爽感你一定懂。从而将"一切皆插件"的理念，嫁接到了大模型推理侧，试图搭建一个"随时可扩展的操作系统"。
这个愿景不赖。它像给一间房子装上乐高底板------底座不变，但你想加书架、加滑梯、加咖啡机，插上去就行，不用拆墙。当 Scaling 这堵墙开始逼近天花板时，这种"外挂式扩展"确实是一条诱人的出路。
但是，这瓶醋有点酸------DSH的工程裂缝
然而，理想丰满，现实骨感。
训练侧和推理侧的一致性存疑。 我们都知道，DeepSeek Math 那篇论文的核心操作，是把一个软件计算器（验证器）当作 Agent 放进 RL 阶段进行训练。这引出了一个值得探讨的问题：如果 DSH 要在 RSI（递归自我提升）场景下承担后训练任务，那么它的工作环境------一个基于 JavaScript/Node.js 的插件底座------与模型训练所依托的 Python 生态之间，至少需要引入一个执行桥接或翻译层。两种语言运行时之间的上下文切换，天然会带来工程摩擦：函数签名如何映射？环境变量如何传递？错误栈如何追溯？这些都不是"插件化"三个字能自动消解的工程细节。
更关键的是，如果 DSH 并非 RL 阶段实际使用的那个验证器，那它声称的"引导提示词、简化 token 消耗"的优化效果，就需要一套独立的、可复现的评测方案来证明，而不能仅仅依赖于"插件化"这个架构愿景本身。这一点，我们会在后边 Harness 设计原则中给出更具体的解决方案------但从工程审慎的角度，在证据充分之前，我们有理由对这一环节保持谨慎。
基础问题未解决。 论文里，所有内容都被插件化、动态化成一个表空间或推理空间。但一个最朴素的疑问：这个推理空间如何处理重名？ 两个插件都叫 read_file 怎么办？论文没说。这就像你装了两个 App 都叫"相机"，系统如何知道你想调哪个？
复现困境。 媒体报道的标题："撞名 Anthropic 的'外挂'刷屏：让'DeepSeek V4-Pro 碾压 Fable 5'但无人能复现，Token 开销反而翻倍"。我没有去验证每一个复现失败的案例，但至少，一个被吹上天的框架，如果连基本的可复现性都成问题，那它的工程成熟度就要打个大问号。
这些不是贬低，只是把事实摆在桌上。DSH 还处于"早期预览阶段"，论文也承认 JS 不是唯一选项，Python 或其他语言都可能。但作为工程师，我们必须分清"醋"和"饺子"------DSH 的工程实现是醋，它的插件化思路才是饺子馅。我们真正该抄的，是那个思路。
Harness Agent------把饺子包出来
那么，一个真正有价值的、采用插件模式的 Harness Agent 应该长什么样？从实践出发，我把它归纳为几条原则，每一条都能在软件历史中找到原型。
1. 可用于训练，且训练/推理提示词一致。
今天很多 Agent 框架，基础操作（compute、文件读写等）在训练阶段用一套提示词，推理阶段用另一套。这导致模型在训练时学的和实际部署时用的对不上。一个合格的 Harness，应该让 RL 阶段和推理阶段使用同一套 function call 定义。从标准化角度看，如果几家模型厂商能把基础文件读写等提示词统一，整个行业都能少踩很多坑。大概率 Python 会是更合适的选择，因为训练代码都是 Python；真要做桌面 App，再用 JS 套壳不迟。
2. 拦截检测（AOP）。
就像地铁安检，所有上下文流经 Agent 时，必须经过一道闸机：检查长度是否超窗口、内容是否安全、资源调用是否越权。在 DSH 的架构中，这通过服务键（service key）发现机制 和上下文（Context） 来实现------Spring 的 AOP 思想直接拿过来，换成"面向上下文的切面"，就能在系统层面兜底，而不是等模型跑飞了再亡羊补牢。
3. 上下文原生（COP）。
这是最关键的一条。所谓"上下文原生"，意味着系统要能把自然语言描述直接映射为系统状态，并且能把系统状态用自然语言反馈出来。比如"读取这个文件"，Agent 不需要你手动指定调用哪个工具，它能根据上下文理解该去调 read_file，然后把结果用自然语言说给你听。
4. 热模块替换（HMR）用于动态工具生成。
这一条直接回应 RSI 的痛点。递归自我提升不一定非得把新知识微调回模型权重------成本高、周期长。更轻量的做法是：模型发现某个任务经常做错，就生成一个专用的"小工具"来固化正确逻辑，通过 HMR 即时挂载。具体一些，当前业界已有通过memory机制让Agent更了解用户、或通过skill分享提示词来指挥Agent的做法。但无论是memory还是提示词，都仍带有概率性和随机性。如果更进一步------利用大模型本身的编程能力，把这些反复验证的经验和技巧提炼成可执行的工具呢？这就像你发现家里总有人忘记关灯，就索性装一个感应开关，从此不再靠'记性'来解决问题。从'大概率做对'到'结构上必然做对'，这才是Harness+RSI的真正愿景。