Skip to content

Add Wave Terminal (waveterm) as a magpie agent plugin - #938

Open
atttmin wants to merge 1 commit into
magpie-community:mainfrom
atttmin:main
Open

atttmin wants to merge 1 commit into
magpie-community:mainfrom
atttmin:main

Conversation

@atttmin

@atttmin atttmin commented Nov 10, 2026

Copy link
Copy Markdown

为 magpie 增加 Wave Terminal(waveterm)作为受管 agent。

magpie 本身没有 Wave 的接线;用这个 agent 插件,Wave 会出现在 Agents 页,和 Claude Code、Codex 一样,从同一个列表里挑任意 magpie 的模型。

工作原理

Wave 的 AI 模式在 ~/.config/waveterm/waveai.json。插件给 Wave 一个固定的模式 magpie,由 magpie 管理:

  • agent.model → magpie.ai:model:选中的目录 id,原样写入(Wave 直接发给网关)
  • connect → magpie.ai:endpoint(网关 /v1/chat/completions)、magpie.ai:apitype(openai-chat)、magpie.ai:apitoken(magpie 为 Wave 保留的 key)、magpie.ai:capabilities(["tools"])

magpie 会把用户原来在这些键下的值先存起来,断开时原样还原;插件只声明「配置在哪、写什么键」,所有写入与回滚都由 magpie 完成。

使用:在 Wave AI 的模式下拉框里选一次 Magpie(或在 ~/.config/waveterm/settings.json 里设 "waveai:defaultmode": "magpie")。

改动

  • packages/wave/ — 新增 agent 插件包(@magpie-community/agent-wave)
  • registry.json — 新增一条 "kind": "agent" 条目

测试

bun test packages/wave/wave.test.mjs — 3 通过 / 0 失败(agent 描述、icon 一致性、connect 输出)。

备注

  • 探测用 Wave 的配置目录 ~/.config/waveterm(Wave 的二进制不在 PATH)。
  • 包没有 main / exports:agent 插件跑在 magpie 自己的进程(moejs),不是 Bun host。

Adds Wave Terminal as a magpie-managed agent.

Wave has no setup of its own in magpie; with this agent plugin it gets a
row on the Agents page, so you can pick any of magpie's models for it
from the same list as Claude Code, Codex and the rest.

How it works

Wave keeps its AI modes in ~/.config/waveterm/waveai.json. The plugin
gives Wave one fixed mode, magpie, and lets magpie manage it:

  • agent.model → magpie.ai:model — the picked catalog id, written
    as-is, since Wave sends it straight to the gateway
  • connect → magpie.ai:endpoint (gateway /v1/chat/completions),
    magpie.ai:apitype (openai-chat), magpie.ai:apitoken (the key
    magpie keeps for Wave) and magpie.ai:capabilities (["tools"])

magpie stashes whatever the user had under those keys and puts it back on
Disconnect, so the plugin only declares where things go — all writes and
rollback are magpie's.

To use it, pick Magpie in Wave AI's mode dropdown once (or set
"waveai:defaultmode": "magpie" in ~/.config/waveterm/settings.json).

Changes

  • packages/wave/ — new agent plugin package (@magpie-community/agent-wave)
  • registry.json — one new "kind": "agent" entry

Test

bun test packages/wave/wave.test.mjs — 3 pass / 0 fail (agent
descriptor, icon consistency, connect output).

Notes

  • Detection uses Wave's config directory ~/.config/waveterm (Wave's
    binary is not on PATH).
  • The package has no main / exports: an agent plugin runs in magpie's
    own process (moejs), not the Bun host.

Gives Wave its own row on magpie's Agents page: pick one of magpie's
models and magpie writes it into ~/.config/waveterm/waveai.json (mode
"magpie"), with the gateway endpoint, api type, key and capabilities;
switching it off puts the config back.

@yetone yetone left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this. Wave as a magpie agent is welcome, and most of the wiring checks out against Wave's own source: the full /chat/completions URL for ai:endpoint (it is not a base URL), openai-chat, ai:apitoken sent as a Bearer token, the key names in AIModeConfigType, and the package and registry fields matching the Kilo and Junie agents. bun test packages/wave passes (3/3) and goes red when the endpoint is broken by hand. scripts/check.mjs is green.

Two things need changing before merge, both in connect (packages/wave/wave.agent.js:21-28):

  1. No display:name. Wave's schema/waveai.json requires it. Without it, the dropdown (getModeDisplayName in frontend/app/aipanel/ai-utils.ts) shows <model id> (custom), not "Magpie", so the README's "pick Magpie" (README.md:29) doesn't hold. Wave's config editor also flags the mode.

  2. Switching off leaves an empty mode. magpie stashes and restores only the leaf keys it wrote, so after a disconnect waveai.json still holds "magpie": {}. Wave then lists a ghost mode, "unknown (custom)", and picking it fails with "no ai:endpoint configured". I ran magpie's real config writer (internal/edit) on a waveai.json that also had a user's own ollama mode, and saw this.

    The fix that works with magpie today is the one Kilo uses: have connect return the whole mode object, and keep model: "magpie.ai:model":

    connect: ({ gateway, key, model }) => ({
      magpie: {
        "display:name": "Magpie",
        "ai:model": model.id,
        "ai:endpoint": gateway.v1 + "/chat/completions",
        "ai:apitype": "openai-chat",
        "ai:apitoken": key,
        "ai:capabilities": model.images ? ["tools", "images"] : ["tools"],
      },
    })

    Through the same writer, connecting writes the full mode, and disconnecting removes magpie entirely and leaves the user's own modes as they were.

Smaller things, optional:

  • ai:capabilities can add "images" when model.images is true (shown above). Wave says custom modes must declare it.
  • Wave watches its config dir (pkg/wconfig/filewatcher.go), so the notice about reopening or restarting is probably unnecessary.
  • The README could note that Wave also reads $XDG_CONFIG_HOME/waveterm, WAVETERM_CONFIG_HOME and the legacy ~/.waveterm/config. The plugin targets the default ~/.config/waveterm, which is right for most users.
  • The registry.json entry is multi-line; every other entry is one line.
  • Please add a test that the connect output carries display:name and is a single magpie object.

Not tried on our side: a real Wave run (it's an Electron app, and we couldn't run it headless). If you can, please confirm in the real app after the change that "Magpie" appears in the mode dropdown and chats through magpie, and that no mode is left behind after switching it off in magpie.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants