genji1024/containerized-agents
Watch
1
0
Fork
You've already forked containerized-agents
 0
Code Issues 1 Pull requests 1 Activity Actions

Pi への移行 #6

New issue
Open
opened 2026-09-01 20:40:29 +09:00 by genji1024 · 4 comments
genji1024 commented 2026-09-01 20:40:29 +09:00
Owner
Copy link

OpenCode から Pi Coding Agent に移行する。ただし、現在のコンテナによる隔離やサブエージェント構成などを全て保ったまま移行する。

OpenCode から [Pi Coding Agent](https://pi.dev) に移行する。ただし、現在のコンテナによる隔離やサブエージェント構成などを全て保ったまま移行する。
genji1024 commented 2026-09-01 20:42:03 +09:00
Author
Owner
Copy link

@bot-genji1024 MCP やサブエージェントの機能は Pi に実装されていません。なるべく自前での実装を避けて OSS の拡張を利用したいです。候補を提示してください。

@bot-genji1024 MCP やサブエージェントの機能は Pi に実装されていません。なるべく自前での実装を避けて OSS の拡張を利用したいです。候補を提示してください。
bot-genji1024 commented 2026-09-02 23:24:09 +09:00
Collaborator
Copy link

@genji1024 お待たせしました。「MCP・サブエージェント機能をなるべく自前実装せず OSS 拡張で補う」ための候補調査結果です。★数・日付・バージョンは本日（2026-09-02）時点の実測値です。

前提（Pi 本体の公式見解）

  • Pi 本体は MCP もサブエージェントも搭載しない方針を公式 README に明記しています:
    • "No MCP. Build CLI tools with READMEs (see Skills), or build an extension that adds MCP support."
    • "No sub-agents. … Spawn pi instances via tmux, or build your own with extensions, or install a package that does it your way."
      （出典: https://github.com/earendil-works/pi packages/coding-agent/README.md）
  • 拡張の土台: Pi の拡張は TypeScript モジュールで、pi.registerTool() で LLM から呼べるツールを登録できます。~/.pi/agent/extensions/（ユーザー）・.pi/extensions/（プロジェクト）に置くと自動読み込みされます（公式 docs: https://pi.dev/docs/latest/extensions ）。以下の候補はすべてこの仕組みの上に成り立っています。
  • 上流リポジトリ: badlogic/pi-mono は earendil-works/pi に移管済み（リダイレクト確認済み）。npm パッケージは @earendil-works/pi-coding-agent（最新 0.84.4、MIT、更新は活発）。

MCP 対応の候補

現行の 5 MCP サーバーはすべて「リモート（streamable HTTP）+ 一部に Authorization ヘッダー + ${env:...} 展開」構成のため、この2点（リモート HTTP 対応 / ヘッダー・環境変数のテンプレート展開）を評価軸にしました。

第1候補: pi-mcp-adapter（nicobailon）★1,391 / v2.32.1（2026-09-01 リリース）/ MIT

  • https://github.com/nicobailon/pi-mcp-adapter （npm: pi-mcp-adapter）
  • 公式 MCP クライアント（@modelcontextprotocol/client）を Pi 拡張としてラップする構成で、StreamableHTTPClientTransport / SSEClientTransport / StdioClientTransport をサポート（server-manager.ts で確認済み）。
  • 設定ファイルは .mcp.json / ~/.pi/agent/mcp.json / .pi/mcp.json 等に対応。url・headers・env で ${VAR} / $env:VAR の展開に対応し、bearerToken / bearerTokenEnv フィールドもあるため、現行の「Authorization ヘッダー + 環境変数」構成を満たせます。
  • ツールの露出方法は2通り: 既定では単一の mcp プロキシツール経由（コンテキスト節約）、directTools で個別ツールを直接露出も可能。
  • 補足: README に Authorization: Bearer ${...} の記載例そのものはありませんが、headers の ${VAR} 展開と bearerToken/bearerTokenEnv は仕様として明記されています。

第2候補: dmmulroy/pi-mcp ★25 / 最終更新 2026-08-16 / ライセンスファイル無し

  • https://github.com/dmmulroy/pi-mcp
  • OpenCode の MCP クライアントを Pi に移植したもので、現行の opencode.json(c) の remote 設定をそのまま読み込めます（README に type: "remote" + url + headers: { Authorization: "Bearer ${TOKEN}" } の記載例あり）。移行作業量は最小。
  • ただし ★ 数が少なく、GitHub 経由インストール（pi install git:...）のみ、ライセンスファイルが無い点は採用時のリスクです。

見送った候補（参考）

  • irahardianto/pi-mcp-extension（★7）: streamable-http には対応するが headers フィールドが無く、Authorization ヘッダーを送れないため不適。
  • mavam/pi-mcporter（★23）: 外部デーモン（MCPorter）の稼働が必要で構成が増えるため今回は見送り。

サブエージェント対応の候補

現行は 11 本の Markdown エージェントファイル（frontmatter: description / mode / model / permission）を task ツールで階層呼び出しする構成です。

第1候補（構造維持重視）: mjakl/pi-subagent ★77 / 最終更新 2026-09-02 / MIT

  • https://github.com/mjakl/pi-subagent （npm: @mjakl/pi-subagent）
  • 「サブエージェントは YAML frontmatter 付き Markdown で定義。ユーザー: ~/.pi/agent/agents/*.md、プロジェクト: .pi/agents/*.md」という仕様で、現行の 11 ファイル構成をほぼ 1:1 で移し替えられます。
  • 深度制限・循環ガード、名前付き永続セッションを持つ。

第2候補（成熟度重視）: pi-subagents（nicobailon）★3,433 / 最終更新 2026-09-02 / MIT

  • https://github.com/nicobailon/pi-subagents （npm: pi-subagents）
  • 非同期委譲・アーティファクト・セッション共有を備えた、現時点で最も成熟した委譲エンジン。内蔵ロール（scout / researcher / worker / reviewer / oracle / delegate）とワークフロー（/council 等）付き。pi install npm:pi-subagents で導入。
  • 一方で階層は静的ファイルではなくプロンプト/ワークフローで組む設計のため、現行の 11 ファイル階層をそのまま再現するには構成の再設計が必要です。

その他の候補（参考）

  • tintinweb/pi-subagents（★1,050）: Claude Code 風の並列実行・TUI 重視。
  • HazAT/pi-interactive-subagents（★663）: cmux ターミナルでの対話型サブエージェント。
  • QuintinShaw/pi-dynamic-workflows（★476）: LLM がオーケストレーションコードを生成して fan-out。

推奨案

  • MCP: pi-mcp-adapter（第1候補）。実績・保守・リモート HTTP 対応とも最も強く、現行の 5 サーバー構成（Authorization + 環境変数展開込み）を満たせます。dmmulroy/pi-mcp は移行の容易さで優位ですが、規模・保守性で劣ります。
  • サブエージェント: mjakl/pi-subagent（第1候補）。現行の Markdown 階層と frontmatter 方式を保持したまま移行できます。委譲機能の成熟度を優先するなら pi-subagents ですが、階層定義の再設計が発生します。

採用後に別途検証が必要な論点（候補選定とは別）

  1. privileged DinD コンテナ内での起動実績: 公式の containerization ドキュメント（node:24-bookworm-slim + ENTRYPOINT ["pi"]）はありますが、PID-1 + dockerd の組合せでの実績までは確認できていません。非対話モード（-p / --mode json / --mode rpc）の利用が鍵になりそうです。
  2. 設定・拡張の配置場所: opencode は ~/.config/opencode/、Pi は ~/.pi/agent/ 配下のため、ボリュームマウントの張り替えが必要です。
  3. trust の扱い: プロジェクト配下の拡張・設定は「プロジェクト trust 後」にしか読み込まれないため、コンテナ初期化時に trust 済み状態を作る手当てが必要かもしれません。
  4. sessions-mcp の依存: OPENCODE_DB（opencode.db）を参照しているため、Pi のセッション保存先への対応が必要です。
  5. 権限の移行: mjakl/pi-subagent の frontmatter でのツール許可（現行の permission 相当）は README の例からの推測が含まれます。pusher 相当のツール制限（トークン隔離のための gitpush 専用許可）が再現できるか要検証です。

主な情報源

ご確認のうえ採用方針（MCP / サブエージェントそれぞれの候補）をいただければ、実装（Dockerfile・設定移行）の着手可否を改めてお伺いします。

@genji1024 お待たせしました。「MCP・サブエージェント機能をなるべく自前実装せず OSS 拡張で補う」ための候補調査結果です。★数・日付・バージョンは本日（2026-09-02）時点の実測値です。 ## 前提（Pi 本体の公式見解） - Pi 本体は MCP もサブエージェントも搭載しない方針を公式 README に明記しています: - "No MCP. Build CLI tools with READMEs (see Skills), or build an extension that adds MCP support." - "No sub-agents. … Spawn pi instances via tmux, or build your own with extensions, or install a package that does it your way." （出典: https://github.com/earendil-works/pi `packages/coding-agent/README.md`） - 拡張の土台: Pi の拡張は TypeScript モジュールで、`pi.registerTool()` で LLM から呼べるツールを登録できます。`~/.pi/agent/extensions/`（ユーザー）・`.pi/extensions/`（プロジェクト）に置くと自動読み込みされます（公式 docs: https://pi.dev/docs/latest/extensions ）。以下の候補はすべてこの仕組みの上に成り立っています。 - 上流リポジトリ: `badlogic/pi-mono` は `earendil-works/pi` に移管済み（リダイレクト確認済み）。npm パッケージは `@earendil-works/pi-coding-agent`（最新 0.84.4、MIT、更新は活発）。 ## MCP 対応の候補 現行の 5 MCP サーバーはすべて「リモート（streamable HTTP）+ 一部に Authorization ヘッダー + `${env:...}` 展開」構成のため、この2点（リモート HTTP 対応 / ヘッダー・環境変数のテンプレート展開）を評価軸にしました。 ### 第1候補: pi-mcp-adapter（nicobailon）★1,391 / v2.32.1（2026-09-01 リリース）/ MIT - https://github.com/nicobailon/pi-mcp-adapter （npm: `pi-mcp-adapter`） - 公式 MCP クライアント（`@modelcontextprotocol/client`）を Pi 拡張としてラップする構成で、`StreamableHTTPClientTransport` / `SSEClientTransport` / `StdioClientTransport` をサポート（`server-manager.ts` で確認済み）。 - 設定ファイルは `.mcp.json` / `~/.pi/agent/mcp.json` / `.pi/mcp.json` 等に対応。`url`・`headers`・`env` で `${VAR}` / `$env:VAR` の展開に対応し、`bearerToken` / `bearerTokenEnv` フィールドもあるため、現行の「Authorization ヘッダー + 環境変数」構成を満たせます。 - ツールの露出方法は2通り: 既定では単一の `mcp` プロキシツール経由（コンテキスト節約）、`directTools` で個別ツールを直接露出も可能。 - 補足: README に `Authorization: Bearer ${...}` の記載例そのものはありませんが、`headers` の `${VAR}` 展開と `bearerToken`/`bearerTokenEnv` は仕様として明記されています。 ### 第2候補: dmmulroy/pi-mcp ★25 / 最終更新 2026-08-16 / ライセンスファイル無し - https://github.com/dmmulroy/pi-mcp - OpenCode の MCP クライアントを Pi に移植したもので、**現行の `opencode.json(c)` の remote 設定をそのまま読み込めます**（README に `type: "remote"` + `url` + `headers: { Authorization: "Bearer ${TOKEN}" }` の記載例あり）。移行作業量は最小。 - ただし ★ 数が少なく、GitHub 経由インストール（`pi install git:...`）のみ、ライセンスファイルが無い点は採用時のリスクです。 ### 見送った候補（参考） - irahardianto/pi-mcp-extension（★7）: streamable-http には対応するが `headers` フィールドが無く、Authorization ヘッダーを送れないため不適。 - mavam/pi-mcporter（★23）: 外部デーモン（MCPorter）の稼働が必要で構成が増えるため今回は見送り。 ## サブエージェント対応の候補 現行は 11 本の Markdown エージェントファイル（frontmatter: description / mode / model / permission）を `task` ツールで階層呼び出しする構成です。 ### 第1候補（構造維持重視）: mjakl/pi-subagent ★77 / 最終更新 2026-09-02 / MIT - https://github.com/mjakl/pi-subagent （npm: `@mjakl/pi-subagent`） - 「サブエージェントは YAML frontmatter 付き Markdown で定義。ユーザー: `~/.pi/agent/agents/*.md`、プロジェクト: `.pi/agents/*.md`」という仕様で、**現行の 11 ファイル構成をほぼ 1:1 で移し替えられます**。 - 深度制限・循環ガード、名前付き永続セッションを持つ。 ### 第2候補（成熟度重視）: pi-subagents（nicobailon）★3,433 / 最終更新 2026-09-02 / MIT - https://github.com/nicobailon/pi-subagents （npm: `pi-subagents`） - 非同期委譲・アーティファクト・セッション共有を備えた、現時点で最も成熟した委譲エンジン。内蔵ロール（scout / researcher / worker / reviewer / oracle / delegate）とワークフロー（`/council` 等）付き。`pi install npm:pi-subagents` で導入。 - 一方で階層は静的ファイルではなくプロンプト/ワークフローで組む設計のため、現行の 11 ファイル階層をそのまま再現するには構成の再設計が必要です。 ### その他の候補（参考） - tintinweb/pi-subagents（★1,050）: Claude Code 風の並列実行・TUI 重視。 - HazAT/pi-interactive-subagents（★663）: cmux ターミナルでの対話型サブエージェント。 - QuintinShaw/pi-dynamic-workflows（★476）: LLM がオーケストレーションコードを生成して fan-out。 ## 推奨案 - **MCP: pi-mcp-adapter**（第1候補）。実績・保守・リモート HTTP 対応とも最も強く、現行の 5 サーバー構成（Authorization + 環境変数展開込み）を満たせます。dmmulroy/pi-mcp は移行の容易さで優位ですが、規模・保守性で劣ります。 - **サブエージェント: mjakl/pi-subagent**（第1候補）。現行の Markdown 階層と frontmatter 方式を保持したまま移行できます。委譲機能の成熟度を優先するなら pi-subagents ですが、階層定義の再設計が発生します。 ## 採用後に別途検証が必要な論点（候補選定とは別） 1. **privileged DinD コンテナ内での起動実績**: 公式の containerization ドキュメント（node:24-bookworm-slim + `ENTRYPOINT ["pi"]`）はありますが、PID-1 + dockerd の組合せでの実績までは確認できていません。非対話モード（`-p` / `--mode json` / `--mode rpc`）の利用が鍵になりそうです。 2. **設定・拡張の配置場所**: opencode は `~/.config/opencode/`、Pi は `~/.pi/agent/` 配下のため、ボリュームマウントの張り替えが必要です。 3. **trust の扱い**: プロジェクト配下の拡張・設定は「プロジェクト trust 後」にしか読み込まれないため、コンテナ初期化時に trust 済み状態を作る手当てが必要かもしれません。 4. **sessions-mcp の依存**: `OPENCODE_DB`（opencode.db）を参照しているため、Pi のセッション保存先への対応が必要です。 5. **権限の移行**: mjakl/pi-subagent の frontmatter でのツール許可（現行の permission 相当）は README の例からの推測が含まれます。pusher 相当のツール制限（トークン隔離のための gitpush 専用許可）が再現できるか要検証です。 ## 主な情報源 - Pi 公式: https://pi.dev （拡張 API: https://pi.dev/docs/latest/extensions ） - earendil-works/pi README（"No MCP" / "No sub-agents" の記述）: https://github.com/earendil-works/pi - pi-mcp-adapter: https://github.com/nicobailon/pi-mcp-adapter （README / server-manager.ts / CHANGELOG を確認） - dmmulroy/pi-mcp: https://github.com/dmmulroy/pi-mcp - mjakl/pi-subagent: https://github.com/mjakl/pi-subagent - pi-subagents: https://github.com/nicobailon/pi-subagents - MCP 不要論（作者の blog）: https://mariozechner.at/posts/2025-11-02-what-if-you-dont-need-mcp/ ご確認のうえ採用方針（MCP / サブエージェントそれぞれの候補）をいただければ、実装（Dockerfile・設定移行）の着手可否を改めてお伺いします。
genji1024 commented 2026-09-07 23:19:08 +09:00
Author
Owner
Copy link

@bot-genji1024 推奨案でいきましょう。実装に着手してください。

@bot-genji1024 推奨案でいきましょう。実装に着手してください。
bot-genji1024 commented 2026-09-08 00:33:23 +09:00
Collaborator
Copy link

実行結果

実施内容

  • #6 の承認（c498、推奨案: pi-mcp-adapter + mjakl/pi-subagent）どおり実装し、PR #12 を作成しました
  • Pi を OpenCode と並列に起動できる構成を追加（既存 OpenCode は無変更のためロールバック容易）

変更ファイル

  • dockerfiles/pi/Dockerfile + entrypoint.sh — DinD イメージ（opencode パターン踏襲）
  • compose.yaml — pi サービス追加のみ（削除 0 行）
  • .config/pi/mcp.json / settings.json — 5 サーバー定義・最小設定
  • .config/pi/agents/*.md（11 件） — 現行エージェント 1:1 移植

動作確認

  • docker compose config — 成功
  • 新規イメージビルド — 成功（exit 0）
  • JSON 妥当性・opencode 無変更 — 確認
  • 実環境起動・MCP 疎通・サブエージェント認識 — レビュアー側で確認を依頼（PR 本文に手順記載）

関連

  • Closes #6
  • PR: #12（Assignee: 自分、Reviewer: @genji1024 を設定済み）

備考

  • #7（filter-proxy PR #11）とは独立
  • 意図的な簡素化は ponytail: コメントで明記
## 実行結果 ### 実施内容 - #6 の承認（c498、推奨案: pi-mcp-adapter + mjakl/pi-subagent）どおり実装し、PR #12 を作成しました - Pi を OpenCode と並列に起動できる構成を追加（既存 OpenCode は無変更のためロールバック容易） ### 変更ファイル - `dockerfiles/pi/Dockerfile` + `entrypoint.sh` — DinD イメージ（opencode パターン踏襲） - `compose.yaml` — `pi` サービス追加のみ（削除 0 行） - `.config/pi/mcp.json` / `settings.json` — 5 サーバー定義・最小設定 - `.config/pi/agents/*.md`（11 件） — 現行エージェント 1:1 移植 ### 動作確認 - [x] `docker compose config` — 成功 - [x] 新規イメージビルド — 成功（exit 0） - [x] JSON 妥当性・opencode 無変更 — 確認 - [ ] 実環境起動・MCP 疎通・サブエージェント認識 — レビュアー側で確認を依頼（PR 本文に手順記載） ### 関連 - Closes #6 - PR: #12（Assignee: 自分、Reviewer: @genji1024 を設定済み） ### 備考 - #7（filter-proxy PR #11）とは独立 - 意図的な簡素化は `ponytail:` コメントで明記
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
6-feat/pi-migration
No results found.
Labels
Clear labels   
enhancement
No labels
enhancement
Milestone
Clear milestone
No items
No milestone
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
genji1024/containerized-agents#6
No description provided.