Pi

subagentやplan modeを本体へ積まず、4つの基本ツールから必要なワークフローを組み立てる

Piのcoding agentは、既定でread、write、edit、bashの4ツールだけをモデルへ提供します。READMEではsub agentsやplan modeのような機能をあえて標準搭載せず、必要ならPi自身にExtensionを作らせるか、既存のPi Packageを導入する方針が説明されています。対話UIにはsessionのbranching、compaction、model切り替えなど開発作業に必要な基礎機能を持たせつつ、チーム固有の承認、レビュー、外部連携などは上位の拡張として分離する設計です。

出典：[2]

ExtensionsでTool・Command・UI・Providerまで差し替え、Pi自体を自分用の開発環境へ変える

TypeScript Extensionはagent lifecycleのeventを受け取り、tool callを止めたり書き換えたり、独自Toolやslash commandを登録したり、TUIへ独自UIを追加できます。同名Toolを登録して標準Toolを置き換えることもできるため、監査ログ、書き込み先保護、Git checkpoint、独自permission gateなどをPi本体のforkなしで実装できます。さらにpi-agent-coreやpi-aiをSDKとして使えば、Piのagent runtimeやmulti-provider LLM APIを別アプリへ埋め込むこともできます。

出典：[1][3]

AIコーディング環境を既製品の作法へ合わせるより、自分の開発ルールをコード化したい人へ

特定のcoding agentが用意したworkflowへチームを合わせるのではなく、既存の開発規約、社内Tool、承認フロー、独自model providerをagent側へ組み込みたい開発者に向きます。interactive CLIとしてそのまま使うだけでなく、print/JSON、RPC、SDKの各modeがあるため、CIや社内ツールから呼び出すagent runtimeとして採用したい場合にも比較しやすい構成です。多数のproviderを同じ操作系で切り替えたい場合や、モデルを替えても自作Extensionを維持したい場合にも相性があります。

出典：[2][1]

自由度の代わりに権限制御は利用者側の責任で、既定では起動ユーザーと同じ権限で動く

Pi本体にはfilesystem、process、network、credentialへのアクセスを制限するbuilt-in permission systemがありません。既定ではPiを起動したユーザー／processと同じ権限でToolが動き、ExtensionもPi processと同じ場所・権限で任意コードを実行できます。信頼できない入力や強い隔離が必要な環境では、公式ドキュメントが案内するGondolin、Docker、OpenShell、Docker Sandboxesなどを使い、Pi全体またはTool実行を隔離する設計が必要です。

また、Piは『必要な機能を自分で足す』思想なので、subagent、plan mode、組織向けpermission UIなどが最初から揃った製品を求める場合は追加実装やPackage選定が必要です。拡張性を重視する分、導入チーム自身がどのExtensionを信頼するか、どのToolを有効にするかを管理する必要があります。本体ライセンスはMITです。

出典：[1][2][3][4][5]