pi2.nvim 推出 v1.5.0 子會話功能：開發者說明為何在 Neovim 裡另做一套 subagents 機制

一名帳號為 zgs225（yuez）的開發者近日在 V2EX「分享創造」版發文，說明其維護的 Neovim 外掛 pi2.nvim 已釋出 v1.5.0 版本，完成「子會話」功能。該文發布約一天內獲得近 560 次瀏覽，截至檢視時尚無留言回覆。綜合原帖與 GitHub 儲存庫公開資料，事件輪廓如下。

背景：pi.nvim 的分支，而非新的 agent

原帖開頭即聲明定位，避免誤解。pi2.nvim 是 pi 這個 coding agent 的 Neovim 前端，在 alex35mil 的 pi.nvim 基礎上修改而來，並非重新打造的 agent 本體。作者稱此次「折騰了好一段時間」完成子會話功能後發布 v1.5.0，並在帖子中說明其與既有做法的差異。

所謂 subagents，是指在主要對話之外另開輔助的 agent 程序，把子任務分派出去執行。此概念在多個 coding agent 框架中已存在，差別在於管理方式與生命週期設計。

作者指出的三種既有做法

依原帖整理，想在 Neovim 裡並行使用多個 agent，現有方案大致有幾種途徑，作者認為各有不便。

其一，一個分頁（tab）開一個對話，等於使用者自己充當調度員，手動在多個分頁間複製上下文、盯守結果。其二，使用框架內建的 sub-agent，此類通常是無頭（headless）的一次性工作程序，執行過程屬黑盒，跑完即消失，難以接續上次的子任務進度。其三，須預先配置多個 subagent 模板或角色才能開工，作者以「配置稅」形容這種前置成本。

pi2.nvim 子會話的四項設計

針對上述痛點，作者的思路是「需要時現造、用完不扔、想看能看、想管能管」，並列出四項特點。

第一，現用現造、零預配置。需要第二或第三個 agent 時，以一句話當場建立，每個子會話為獨立程序、獨立 session，可各自指定模型與思考檔位，沒有先註冊模板的門檻。

第二，用完不扔、可復用。子會話完成任務後進入休眠（dormant）狀態而非刪除。下次要它再做事，直接對同一個子會話發送訊息，宿主自動拉起程序，歷史與上下文保留，可接續先前進度。父子關係寫入 manifest，作者稱執行 /new、重啟 Neovim 或 resume 都不會打散這層關係。

第三，隨時圍觀、也能插嘴。想查看某個子會話的執行情況，按鍵即可開啟只讀浮窗，即時串流顯示它正在思考什麼、呼叫什麼工具，底部標示 context 用量、模型與思考檔位。若判斷方向偏離，可切換進去接管對話、修正指示，再返回父會話，兩邊互不幹擾。

第四，多數情境無需人工管理。父 agent 被注入調度紀律：先檢查有無可復用的舊子會話，能復用就不新建；需要並行時整批派出，按 batch_id 統一收回結果。作者描述日常運作是由 agent 自身擔任調度員，前述手動操作屬備援，並非主流程。

環境需求為 Neovim 0.10 以上、pi 版本 0.65.2 以上。專案原始碼位於 github.com/zgs225/pi2.nvim，詳細設計文件在其 doc/sessions.md，作者於文末開放交流意見。

「重造輪子」的說法與脈絡

標題中「又造了個 subagents 的輪子」是作者的自嘲式說法，指 subagents 概念已有諸多實作，此番再寫一套。此類表述在開發者社羣常見，與先前流傳於技術社羣、回顧既有規約與事故教訓的長文（如讀《阿裏巴巴Java開發手冊》五年一文）同屬開發者自述實作經驗的內容樣態。

從訊源角度，目前關於此功能的說明均出自作者本人帖子與儲存庫文件，屬單一訊源，實際運作表現尚待使用者回饋驗證。原帖瀏覽量近 560，但無留言，外部討論與第三方評測至檢視時未見。pi.nvim 原專案的維護狀態、pi2.nvim 與上遊的同步策略，也未在帖中詳述。

後續觀察

pi2.nvim 屬個人維護的開源分支專案，v1.5.0 的子會話機制能否穩定運作、休眠與喚醒流程在長期使用下的表現，有待後續版本與 issue 追蹤。對在 Neovim 內使用 coding agent 的開發者而言，此一實作提供了「持久化子會話」的另一種路徑，與框架內建 sub-agent 的一次性模式形成對照。本臺將視社羣回饋與版本更新情形，持續整理相關資訊。