jevbooks

← 全部项目

opencode-jev-orchestrator

aaronshaf/opencode-jev-orchestrator

沿固定提交追踪路由 hook、置信度分支和子会话工具,弄清 release 与“近乎完整上下文”实际做了什么。

分类与路由0.98次选分类: Agent 决策漏斗恒温器

源码导读

OpenCode orchestrator 源码导读:固定父模型与显式委派

Jev 给用户回合分类,策略保持配置中的父模型,并可建议调用专家工具。这个边界很关键:升级提示不等于子任务已经执行,保留父模型也不等于已测得缓存节省。

源码核验 未完成完整项目实跑固定源码 ffe76fed

1. Hook 看到的是有限文本,不是整个仓库

插件入口读取配置并建立 hook。chat.message 跳过内部子会话和已关闭自动路由的会话;不在管理范围内的固定模型保持原样。对受管理模型,它提取非 synthetic 的用户文本,默认最多 16 KiB,并检查模型目录及可用档位。

askJev 发送请求文本、当前父模型档位、上下文 token 数和可用档位。一个 Choice 选 fast/balanced/strong/long,三个 Score 分别记录任务、推理和工具复杂度。路由状态里只有上下文 token 数,没有父会话全文或源文件。只有附件或没有可用文本时,会跳过这条路由。

2. Stay、escalate、release 取决于已有状态

默认置信度阈值是 0.3;达到阈值的 strong/long 判断会建议升级。没有活跃强子代理时,Jev 缺失、标签无效或低置信度都让父模型继续;已有强子代理时,明确简单则释放,明确困难则继续升级,Jev 不可用或不确定也释放。显式模型覆盖和并行意图规则优先于这些分支。

Hook 把受管理请求设为配置中的固定父模型,再附加升级提示。父模型必须实际调用 jev_escalate;如果没调用,后续回合会记录漏掉提示。用户显式指定模型是可以修改父模型的出口。release 调用 clearStrongStreak,清除本地子代理跟踪和并发占位,并没有删除或中止服务器上的会话。

3. 子代理实际收到了什么、返回什么

jev_escalate 选择可用的 strong 模型,再新建或恢复子会话。第一次委派最多读取 200 条父会话消息,在默认 200,000 字节预算内格式化,超出时先移除旧消息。附件只留下名称,工具输出截到 400 字符,synthetic 或 ignored 文本被排除。它是筛选后的对话文本,不是完整仓库快照。

恢复强子代理时,按上次委派记录的消息数提取增量。工具发送任务,等待 idle(默认子任务超时 300 秒),再返回最后一条助手文本及 child/model/context 元数据。并行子代理使用 fast 档,不可用时退到父模型档,默认最多三个并发。采用前应检查长会话的上下文完整性及增量行为。

4. 错误出口与版本声明

Jev 默认配置为 SDK 超时 1,500 ms、重试一次、3,000 ms 发出中止信号。缺少凭证、调用异常或 model_tier 答案格式错误会返回 null,再进入前述依赖状态的分支。模型目录失败或没有可用固定父模型时,当前请求保持原样。创建子会话、发送任务或等待失败会返回工具错误文本,不能当作专家已完成的答案。

该提交声明包版本 0.2.1、Node ≥22、SDK ^0.6.0、开发依赖 plugin 1.18.31,以及可选 peer 范围 ≥1.0.0。这些声明不证明范围内所有宿主都兼容。askJev 没有在请求中固定 Jev 模型,也没有在结果中保留实际服务模型字段。验证版本相关主张时,应记录解析后的依赖锁文件、宿主版本与实际 API 模型。

采用这种模式前,要测什么

有价值的本地检查是用 mock 返回“困难且高置信度”“简单且高置信度”“低置信度”和 null,再分别搭配有、无活跃强子代理。另行验证父模型是否遵从提示、子代理是否拿到必要上下文,以及委派失败后能否恢复。缓存读取 token、总 token、质量和完成任务成本,需要在宿主中做对照;保留模型本身不能证明省钱。

2026-11-02 核对 README;2026-11-03 新增这份固定提交的源码导读。本站未在 OpenCode 中运行插件,未为本次核对调用 Jev,也未复现缓存或成本收益。值得迁移的是:类型化判断驱动明确的状态机,并让委派过程可观察。

README 自动摘要

根据 README 自动整理于 2026年9月20日,不是本站运行记录。上方编辑说明另行核对来源;旧摘要可能遗漏限制,请以导读标注的证据范围理解。

这是什么

一个面向 OpenCode Go 用户的 OpenCode 编排插件,让父会话保持在廉价的粘性模型上以保持缓存热度,并将更困难的轮次委托给临时的更强子代理。

它怎么用 Jev

Jev 将每一轮标记为困难、简单或不确定。父模型调用 jev_escalate 将接近完整的上下文发送给强子代理,或调用 jev_parallel 启动最多 3 个廉价子代理。结果通过工具返回合并;恢复时仅发送增量上下文。

用到的原语:choice

值得抄的做法

保持父模型固定以维持缓存热度;仅用难度标记将困难轮次路由到临时子代理。

怎么试

opencode plugin opencode-jev-orchestrator -g,添加 JEV_KEY,重启 OpenCode,检查 /jev-status。

去 GitHub 看

开始使用 Jev:API key 与第一个请求 →

README 片段的模型判断

项目信号使用仓库元信息、已有摘要与 README 前 700 个字符;没有通读完整项目。“未检出”仅表示这些材料中未检出,并不证明项目没有该能力。这里保留原始判断与实际记录的模型、日期,不是源码审计或运行验收。

模型与判定日期

收录门禁
jev-1.13.0
项目信号
jev-1.13.0
项目分类
jev-1.13.0
模式标签
jev-1.13.0

证据

这些信号只读取仓库元信息、已有摘要与清理后的 README 前 700 字符。≥ 0.60 表示片段中有提及,≤ 0.40 表示未检出,中间为未判定;都不是源码审查或运行结果。「可运行工具」题排除了研究实验,「推荐」题筛的是学习案例 Top 10,不是内容质量合格与否。

  • Jev 是项目的核心在材料中检出0.79
  • 展示了 System One 用法未判定0.54
  • 写了怎么处理不确定片段中未检出0.14
  • 给出了实测数字片段中未检出0.05
  • 是能跑起来的工具在材料中检出0.98
  • 学习案例 Top 10 候选信号未判定0.43
  • 是模型本身的复刻片段中未检出0.04
  • 解决的问题够普遍(0–2)按 0–2 打分1.03 / 2
  • 与 Jev 相关在材料中检出0.98
信号
Jev 是项目的核心0.79展示了 System One 用法0.54写了怎么处理不确定0.14给出了实测数字0.05是能跑起来的工具0.98学习案例 Top 10 候选信号0.43是模型本身的复刻0.0400.51解决的问题够普遍(0–2)1.03 / 2012

无判定区(0.40–0.60)

设计模式
恒温器0.87漏斗0.81常开常闭0.39代笔0.2800.51

无判定区(0.40–0.60)

各阶段的 Jev 模型与判定日期见上方记录。简介由 DeepSeek V4.1 Flash 于 2026年9月20日 读 README 写成。