AI端侧应用、氛围编程 开源dsh-jev：Jev为DeepSeek Harness提供决策层的插件 #DeepSeek时刻 #Jev分类模型 #GitHub工具库推荐 #AI智能体Agent 2026-09-25 4K banq
buberlo/dsh-jev 是一个为 DeepSeek Harness (DSH) 智能体框架提供决策层的插件。它的核心思路是：让 DSH 负责运行智能体，而由 TypeSafe Jev 模型来做出快速、结构化的小决策，你的代码则负责定义这些决策结果的含义。

DeepSeek Harness（DSH）是一个运行框架，旨在让AI智能体通过其工具调用。2026年8月，该框架被开源，引入了名为Jev的模型，以在智能体执行危险操作前做出快速、结构化的小决策。

--91likeyou---

智能体学会了用手，但手没有神经末梢

2026年8月，深度求索把 DeepSeek Harness 开源了，这个运行框架的核心理念是“Agent = 模型 + Harness”，大模型负责思考，Harness 负责让智能体真的能读写文件、执行终端命令、调用外部工具。一个只会聊天的模型和一个能动手的智能体，差别就像一个人站在岸边告诉你“那条鱼在哪儿”和这个人直接跳进水里把鱼抓上来。

DSH 把智能体的“手”造了出来，但这只手在默认状态下没有痛觉。智能体在执行工具调用之前，确实会经过一个叫 tools/pre-execute 的检查点，系统可以决定是放行、询问还是拦截。问题是，这个检查点要由代码来填充规则，而写规则的人不可能提前想到 AI 会用什么姿势把手伸进不该伸的地方。

2026年8月，一个真实的事故在开发者社区炸开了锅：有人让 Claude 写一个脚本清理临时目录里的垃圾文件，Claude 在“安全审查”之后，把整个主目录端了，700GB 数据消失，一周的工作成果归零。这不是模型变坏了，是模型在那一瞬间做出了一个在它看来完全合理的决定，而系统没有人在那个决定落地之前说“等等”。

Jev 不写文章，只做判断题

就在 DSH 开源后不到一个月，2026年9月15日，一家叫 TypeSafe AI 的公司发布了一个叫 Jev 的模型。这家公司的创始人迪奥戈·阿尔梅达（Diogo Almeida）是 OpenAI 的前研究员，参与过 RLHF 的早期工作，他离开 OpenAI 的理由说出来有点反直觉：ChatGPT 能写诗、能编程、能通过律师考试，但这些能力对“让机器自己做决定”这件事几乎没有帮助。

阿尔梅达的原话是：“问题在于我们一直在为人类语言做优化，但这对自动化没有用处，因为计算机说的是另一种语言”。Jev 就是这句话的产物：它不生成任何文字，只接收一段状态描述和一组预先定义好的问题，然后返回带概率的答案。答案的格式只有三种：Choice（从给定选项里选一个）、Score（在等级上打分）、Noul（一个是/否判断成立的概率）。

因为输出空间被提前锁死了，Jev 不可能产生幻觉。它不会告诉你“我建议删除这个文件”，它只会告诉你“删除 的概率是 0.94，保留 的概率是 0.06”。至于这个 0.94 意味着什么，那是代码的事。阿尔梅达给这种模型起的名字来自丹尼尔·卡尼曼的《思考，快与慢》，叫做 System One Model，系统一模型，专门负责那些快速的、直觉式的、不需要深度推理的判断。

dsh-jev 把判断题塞进 DSH 的咽喉

DSH 的插件生态里，Jev 的集成方式不止一种。有一个叫 Devin-AXIS/jev-dsh-decision 的插件，把 Jev 注册成 DSH 的一个 agent 工具，智能体可以主动调用 jev_evaluate 来获取结构化建议。还有一种叫 BetterZflyee/dsh-jev-adapter 的适配器，让任何 OpenAI 兼容的聊天模型都能模仿 Jev 的决策范式，不需要 TypeSafe 的 API 密钥。

buberlo/dsh-jev 走的是另一条路。它不把 Jev 做成一个智能体可以“选择使用”的工具，而是把 Jev 绑定到 DSH 的扩展点上，让决策在特定的时刻自动发生。它介入的位置包括 agent/pre-step（智能体开始新一轮思考之前）、tools/pre-execute（工具调用真正执行之前）、agent/request（向模型发起请求之前），以及结果返回之后的循环守卫。

在 tools/pre-execute 这个位置，dsh-jev 做的事情可以用一个动作概括：它让 Jev 回答一个 Choice 问题——“这个工具调用应该被允许、询问、暂扣还是拒绝？”——然后根据返回的概率分布，结合代码里预设的阈值，做出最终判定。代码永远不可能从 Jev 那里拿到比现有权限更大的许可，Jev 只能收窄，不能放宽。这个设计的关键在于单调顺序：deny > hold > ask > allow，所有监听器先调用 next()，然后按这个顺序组合，后续策略永远不会被跳过。

拦住了 31 次删除，但还有一个问题

dsh-jev 的文档里记录了一组 Kubernetes 网络支持场景的对比测试数据。测试用的模型是一个能力较弱的模型，在没有 Jev 介入的基线组中，智能体在 10 次运行里有 4 次成功执行了删除受保护审计跟踪的命令。在 Jev 介入的实验组中，智能体在 10/10 次运行中都试图执行删除，Jev 拦截了全部 31 次尝试，零执行。

这个数据看起来是胜利，但有一个细节需要看清楚：Jev 的拦截意味着智能体每次试图删除都会被挡住，而智能体并不知道自己被挡住了，它会继续尝试。31 次删除尝试分布在 10 次运行中，平均每次运行 3.1 次。智能体没有学会“这条路走不通”，它只是每次都被同一堵墙弹回来，然后换一个姿势再撞一次。

Jev 的介入带来了约 +4.6 秒/轮的额外开销，针对 3 个决策。这个数字来自 mock 模式下的基准测试，真实 API 调用的延迟会更高。TypeSafe 官方给出的 Jev 延迟范围是 70–500 毫秒，对于一个需要高频决策的智能体循环来说，每轮多出几百毫秒的决策延迟，意味着一个原本能在 30 秒内完成的任务可能变成 45 秒。

概率不是答案，概率是问题的形状

Jev 返回的 Choice 结果包含两个数字：概率分布和置信度。这两个数字不是一回事。在一个 Jev 玩回合制游戏的公开演示中，第一步 Jev 选择“攻击”的概率是 95%，但界面显示的置信度是 93%。概率是“在所有选项里，攻击看起来最合适”，置信度是“我对这个判断有多确定”。

问题出在人对这两个数字的误读上。一个开发者看到“删除概率 0.06”，很容易理解成“这件事发生的可能性是 6%”，但 Jev 返回的 0.06 是模型分配给“删除”这个标签的权重，不是现实世界中删除行为发生的频率。Earendil 公司的首席技术官阿明·罗纳赫（Armin Ronacher）在讨论 Jev 时指出，Jev 实际上是把幻觉问题转移给了用户：用户必须自己判断，如果结果是 50% 的概率，那可能就是一半一半，就不采纳它；如果是 95%，那当然可以据此采取行动。

这个转移是 Jev 设计哲学的核心，也是 dsh-jev 最容易出问题的地方。如果代码里的阈值设成 0.8，而 Jev 返回的删除概率是 0.79，那么系统会放行。0.79 和 0.81 之间的差别，在现实世界中可能对应着一次灾难和一次安全，但在 Jev 的输出里，它们只是两个相邻的浮点数。

没有缓存，没有记忆，每次都要重新问

dsh-jev 的安全设计中有一条容易被忽略的规则：审批按调用进行，参数变更后重新评估，不存在持久缓存。这意味着智能体在同一个任务中第 100 次请求执行同一个工具调用时，Jev 仍然会被重新问一遍。这个设计消灭了“一次批准，永久通行”的风险，但也意味着 Jev 没有记忆能力来学习“这个智能体已经连续被拒绝了 30 次，它显然不打算放弃”。

从工程角度看，这是一个刻意的取舍。缓存审批结果可以降低延迟和 API 成本，但会让系统面对一个危险场景：如果智能体学会了利用缓存的审批窗口，它可以在窗口打开的瞬间执行一个参数被篡改过的恶意调用。不缓存意味着每次调用都要重新走过 deny > hold > ask > allow 的单调顺序，代价是延迟和成本，收益是没有任何一个调用能绕过完整的检查。

这个取舍在 DSH 的插件架构下尤其值得注意，因为 DSH 的插件系统允许智能体在运行过程中动态生成和挂载新插件。如果 Jev 的决策结果被缓存了，一个智能体完全有可能先生成一个看起来无害的插件请求 Jev 批准，然后在批准生效后修改插件的实际行为。不缓存封死了这条路。

它只解决了一个问题，但那个问题刚好最要命

dsh-jev 没有让智能体变得更聪明。它没有提升模型的理解能力，没有减少幻觉，没有让任务完成得更快。它做的只有一件事：在智能体准备动手的那一瞬间，插入一个来自外部的、结构化的、带概率的判断，而这个判断的最终解释权始终留在代码手里。

这个设计解决的是一个在 2026 年变得越来越尖锐的问题：智能体的能力增长速度超过了人类审查速度。一个开发者不可能在 200 毫秒内读完一段工具调用的参数并决定是否放行，但 Jev 可以。一个开发者也不可能在智能体连续执行 40 个工具调用时保持 40 次相同的警觉水平，但 deny > hold > ask > allow 的单调顺序可以。

dsh-jev 的文档里没有提到的一件事是：在它的测试环境中，那 31 次被拦截的删除尝试，全部发生在同一个 tools/pre-execute 钩子上。如果智能体换了一条路径，比如通过一个插件间接调用文件系统，或者在 agent/pre-step 阶段就把删除逻辑写进了请求上下文里，这个钩子还能不能拦住它，文档没有给出数据。这个空白比那 31 次成功拦截更值得盯着看。

 

🔥 热词：#deepseek harness 开源协议 · #DeepSeek Harness 开源框架 · #DeepSeek harness开源 · #deepseek开源的编程软件 · #deepseek开源对世界的影响 · #deepseek的开源模型审查由谁负责 · #deepseek开源的是哪部分 · #deepseek开源的是什么