Skip to content

[native] omp: three-mode alignment (proxy / launcher / native plugin) + runtime-info #957

Closed

Description

@ranxianglei

Goal

Bring omp to full three-mode alignment like pi / opencode / dsh already have:

  1. Mode 1 — proxy (URL prefix, exists today via launcher)
  2. Mode 2 — launcher (bili omp — exists)
  3. Mode 3 — native plugin (bili plugin install omp — the gap): plugin loaded by the CLIENT itself, spawns/attaches its own proxy, rewrites model traffic, registers ACP tools natively, stamps plugin-mode headers, implements the runtime-info protocol.

Feasibility pre-assessment

OpenCode-fork
HIGH — omp is an opencode fork; if it retains opencode's plugin API (config hooks / chat hooks / tool registration), the opencode v1 native path (src/agent/opencode-native.ts) ports almost directly. Start by diffing its plugin surface against opencode 1.x.

Reference implementations (read these first)

Requirements if feasible

  • No launcher, no env vars, no fixed port for the end user; opt-out env BILI_NATIVE_OMP=0
  • Plugin-mode gating: stamp x-bili-plugin ONLY after native tools are registered (round 1 rides wire mode)
  • Parent-pid watchdog proxy teardown; attach to a healthy proxy when present
  • Runtime-info stamps (model + contextWindow + maxOutput whenever the client exposes them)
  • npm run typecheck + npm test + npm run build green; new tests for the plugin module (see tests/dsh-native.test.ts for the harness style)
  • README (en + zh) client table + install section updated

If NOT feasible

Post the evidence (what extension points exist, why wire interception / native tools are impossible) and close as wontfix — a documented no is a deliverable too.

For ework

This issue is directly implementable. Follow the dsh playbook; ask in this thread before inventing new protocol surface. PR must reference this issue (Fixes #N).

Activity

  1. ranxianglei commented on Sep 19, 2026

    @ranxianglei
    OwnerAuthor

    开工。omp 是 opencode fork,可行性预评估 HIGH——按 dsh playbook 先确认它保留的插件 API(config hooks / chat hooks / fetch patch),可行即全量三模式,不可行贴证据 wontfix。

  2. ranxianglei commented on Sep 19, 2026

    @ranxianglei
    OwnerAuthor

    @ework 开工 #957(omp 三模式)。omp 是 opencode fork,可行性预评估 HIGH。按 dsh playbook 先做可行性预研:确认 omp 保留的插件 API(config hooks / chat hooks / fetch patch / 工具注册面),可行即按 #964/#941 同款 playbook 全量三模式(companion → launcher → native),不可行贴证据 wontfix。注意先看 repo 的 AGENTS.md。

  3. ranxianglei commented on Sep 19, 2026

    @ranxianglei
    OwnerAuthor

    🤖 Powered by ework · qwen3.8-27b

    可行性预研完成,结论:HIGH,全量三模式开工(不 wontfix)。先纠正一个前提:

    omp 不是 opencode fork,是 pi(oh-my-pi)fork。 本机装了 @ranxianglei/omp-stable v18.0.3(源码可读),证据:

    • package.json:homepage github.com/ranxianglei/oh-my-pi,依赖全是 @oh-my-pi/pi-* 系(pi-agent-core / pi-ai / pi-catalog);作者 Stencil Labs / Mario Zechner(pi 的作者)。bili 自己的代码也一直按 pi-based 处理它(src/agent/omp.ts 就是 createBiliPlugin("omp"))。
    • 所以"opencode 的 config hooks / chat hooks"不适用——omp 保留的是 pi 的 ExtensionAPI,且 18.0.3 全量保留:ExtensionFactory(default export)、on / registerTool(含 loadMode:"essential")/ registerCommand / registerProvider / setModel / sendMessage;事件面有 session_start / session_switch / session_before_compact / session_compact / before_provider_request / auto_compaction_start|end;ctx.model 带 id / contextWindow / maxTokens / baseUrl(runtime-info 字段齐全)。
    • 关键负证据:before_provider_headers 在 omp 全源码树零命中——所以 omp 的 plugin-mode 绑定走 identity register + prompt_cache_key stamp(现有 src/agent/pi.ts 已实现),runtime-info 只能走 POST /__bili/plugin/runtime-info 通道(per-request header 通道在 omp 上不存在)。

    运行时实证(不是纸面推断):用隔离 HOME 跑了一次真 omp-stable -p,注入探针扩展——

    • runtime = Bun(isBun:true,#!/usr/bin/env bun 直接跑 TS 源码树);
    • globalThis.fetch 可赋值(patched:true)→ pi-native 同款的 fetch 拦截机制在 omp 下成立;
    • config.yml extensions: 绝对路径条目 + default-export factory 加载路径在 18.0.3 验证通过。

    因此 playbook 按 dsh/pi-native 同款执行(companion 已有 → launcher 已有 → 补 native):

    1. 新增 src/agent/omp-native.ts(镜像 pi-native.ts:自拉起代理 attach-or-spawn、fetch 拦截、BILLION_CONTEXT_PROXY、opt-out BILI_NATIVE_OMP=0、coexistence marker);
    2. pi.ts:omp 的 runtime-info 上报挂到 before_provider_request(toolsReady 门控,与 pi 的 header 路径同语义);
    3. bili plugin install omp 改装 native 入口,旧 thin 条目(dist/agent/omp.js)自动迁移;
    4. 测试 + README en/zh。

    做完贴 PR(带 Fixes #957)。

  4. ranxianglei commented on Sep 19, 2026

    @ranxianglei
    OwnerAuthor

    🤖 Powered by ework · qwen3.8-27b

    完工 ✅ 可行性预研 HIGH 坐实(上条回复的探针结论:Bun 运行时、fetch 可 patch、插件 API 面完整),已按 pi/dsh playbook 全量三模式落地。

    PR: #981

    交付内容

    1. 原生模式(bili plugin install omp,免启动器)

    • 新增 src/agent/omp-native.ts(镜像 pi-native.ts):加载时自拉起代理(健康实例则附看 + parent-pid 看门狗)、全局 fetch 拦截把模型流量改写到 <proxy>/bili/<upstream>、注册 compress / decompress / acp_status 原生工具(plugin 模式)、工具就绪前第一轮走 wire 模式。模块求值时同步置 BILLION_CONTEXT_NATIVE=omp,独立扩展进程内自动退让。退出开关 BILI_NATIVE_OMP=0。
    • tsup.config.ts 新入口 → 自包含 dist/agent/omp-native.js(acp-kernel 内联);薄版 dist/agent/omp.js 保留给 launcher 模式。

    2. 安装器迁移(src/plugin-install.ts)

    3. runtime-info(#955 协议,src/agent/pi.ts)

    • omp 没有逐请求 header 事件,createBiliPlugin("omp") 改从 before_provider_request 走 POST /__bili/plugin/runtime-info 上报(与其他 native host 同形状,按模型切换去重,soft-fail)。代理侧窗口解析链不变(runtime-info 表本来就存在)。

    验证

    • 新增 12 个测试:tests/omp-native.test.ts(bootstrap gate 真值表含跨宿主 opt-out 隔离、native-marker 不变量、script-path 解析、安装器 fresh/idempotent/薄→原生迁移/去重/remove/status/launcher -e 跳过)+ tests/plugin-agent.test.ts 里一个走真实 HTTP fake proxy 的 runtime-info 端到端(工具就绪前静默、同模型去重、换模型再报)。
    • 两个既有测试按有意的迁移语义更新(Claude Opus 5 经中转被当 200K 用:models.dev 查找被 host 门槛旁路 + 面板硬编码 200K 兜底 + 变体后缀失配 + 自愈只降不升 #392 子测试 a:块内 stale 条目现在会被迁移替换;fake-HOME roundtrip 期望 native 路径)。
    • rebased head(当前 master ba6c9ad)上全绿:typecheck ✓、1930 pass / 0 fail ✓、build ✓(两个 dist 产物都在)。
    • 未触碰:wire 协议、config schema、持久化格式、acp-kernel pin、src/update.ts。

    README en/zh 已同步(客户端表、Option 1 清单、opt-out envs、runtime-info 实现列表)。等 CI + 人工合并。

    一句话中文摘要:omp 三模式对齐完成——新增自拉起原生插件入口、安装器把旧薄版条目原地迁移为 native 形态、补齐 runtime-info 上报通道,12 个新测试 + 既有套件在最新 master 上全绿,可以合并。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions