Pi agent harness：用於 LLM 代理的 TypeScript monorepo
Pi 在 TypeScript 工具包中結合了提供者中立的 LLM API、代理循環、終端介面和編碼 CLI。
秒懂
- 它是什麼？
- README 描述了三個套件：統一 LLM API、代理執行環境和編碼代理 CLI，外加一個 TUI 程式庫，並附有容器化指導和供應鏈加固說明。
- 適合誰用？
- Pi 是一個 MIT 授權的 TypeScript monorepo，其 README 重點介紹套件結構、容器化選項、建置步驟和供應鏈控制。API 細節、受支援的平台以及沙箱模式的安全屬性在 README 中未涉及，需要對照 pi.dev 上的文件進行核實。
- 可以商用嗎？
- 可以。MIT 是寬鬆授權：你可以使用、修改並販售以它為基礎的軟體，只需保留著作權與授權聲明。
- 還在維護嗎？
- 有在維護。儲存庫在最近一天內有新的提交。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
組成 Pi 的各個套件
README 將該儲存庫描述為 Pi agent harness 專案的主目錄，核心是一個可自我擴充的編碼代理。它列出了三個已發佈的套件：@earendil-works/pi-ai，一個統一的多供應商 LLM API，涵蓋 OpenAI、Anthropic、Google 等；@earendil-works/pi-agent-core，負責工具呼叫和狀態管理的代理執行環境；以及 @earendil-works/pi-coding-agent，互動式編碼代理 CLI。第四個套件 @earendil-works/pi-tui 提供了具備差異渲染的終端 UI 程式庫。README 沒有給出這些套件的 API 細節或用法範例，因此需要對照 pi.dev/docs/latest 上的文件或套件原始碼進行核實。
在 earendil-works/pi 的第 1 個檢查面向，應把專案名稱、README 提到的具體入口與可觀察結果放在一起理解。先確認目前分支 main 的檔案位置，再依文件中的命令或範例執行；若輸入格式、作業系統、編譯器、供應商服務或憑證條件不同，結果就不能直接互相比較。記錄成功輸出、錯誤訊息和程序是否正常結束，才能分辨是功能限制、環境差異還是文件未涵蓋的情況。這個步驟針對 pi 本身，不代表 README 對未描述的使用場景作出保證。還要把實際使用的版本、設定值和輸入樣本留下，否則之後無法說明同一個命令為何得到不同輸出。對照輸入與輸出時，應特別查看專案列出的檔案名稱、參數名稱、佇列或資料欄位，並把可重現的差異寫下來。若 README 沒有描述錯誤處理、併發順序或平台支援，就只能記錄觀察結果，不能補成保證。
權限留給宿主系統
README 明確說明了 Pi 不做什麼：它沒有內建的權限系統來限制檔案系統、程序、網路或憑證存取。預設情況下，代理以啟動它的使用者和程序的權限執行。如需更強的邊界，專案指向容器化或沙箱化，並記錄了三種模式：Gondolin 擴充，將 pi 和供應商認證保留在宿主機上，同時把內建工具路由到本機 Linux 微虛擬機器；普通 Docker，將整個 pi 程序放在本機容器中實現簡單隔離；以及 OpenShell，在策略控制的沙箱中執行整個 pi 程序。README 沒有聲稱這些模式具備何種安全屬性。
在 earendil-works/pi 的第 2 個檢查面向，應把專案名稱、README 提到的具體入口與可觀察結果放在一起理解。先確認目前分支 main 的檔案位置，再依文件中的命令或範例執行；若輸入格式、作業系統、編譯器、供應商服務或憑證條件不同，結果就不能直接互相比較。記錄成功輸出、錯誤訊息和程序是否正常結束，才能分辨是功能限制、環境差異還是文件未涵蓋的情況。這個步驟針對 pi 本身，不代表 README 對未描述的使用場景作出保證。還要把實際使用的版本、設定值和輸入樣本留下，否則之後無法說明同一個命令為何得到不同輸出。對照輸入與輸出時，應特別查看專案列出的檔案名稱、參數名稱、佇列或資料欄位，並把可重現的差異寫下來。若 README 沒有描述錯誤處理、併發順序或平台支援，就只能記錄觀察結果，不能補成保證。
開發腳本
在 monorepo 中開發時，首先執行 npm install --ignore-scripts 以跳過生命週期指令碼，然後執行 npm run build，它會重新整理模型資料並建置所有套件。npm run build:offline 使用現有模型資料在無網路的情況下重新建置。npm run check 執行 lint、格式化和型別檢查。測試透過 ./test.sh 執行，在沒有 API 金鑰時會跳過依賴 LLM 的測試；./pi-test.sh 可從任意目錄從原始碼執行 pi。README 未說明具體使用的測試框架，也未詳細描述目錄結構。
在 earendil-works/pi 的第 3 個檢查面向，應把專案名稱、README 提到的具體入口與可觀察結果放在一起理解。先確認目前分支 main 的檔案位置，再依文件中的命令或範例執行；若輸入格式、作業系統、編譯器、供應商服務或憑證條件不同，結果就不能直接互相比較。記錄成功輸出、錯誤訊息和程序是否正常結束，才能分辨是功能限制、環境差異還是文件未涵蓋的情況。這個步驟針對 pi 本身，不代表 README 對未描述的使用場景作出保證。還要把實際使用的版本、設定值和輸入樣本留下，否則之後無法說明同一個命令為何得到不同輸出。對照輸入與輸出時，應特別查看專案列出的檔案名稱、參數名稱、佇列或資料欄位，並把可重現的差異寫下來。若 README 沒有描述錯誤處理、併發順序或平台支援，就只能記錄觀察結果，不能補成保證。
從發佈原始碼建置獨立二進制
GitHub 發佈包含一個帶版本號的原始碼歸檔，由該發佈的 SHA256SUMS 檔案覆蓋。README 記錄了建置獨立二進制的步驟：解壓歸檔並執行 ./scripts/build-binaries.sh --offline-model-data --platform linux-x64 --out "$PWD/out"。--offline-model-data 旗標使用原始碼歸檔中自帶的產生供應商模型資料建置，而不是從線上供應商目錄重新整理。該指令碼會安裝依賴、建置 monorepo、編譯 Bun 可執行檔並暫存執行時期資產。自行提供依賴的套件維護者可傳 --skip-install --skip-deps。README 未列出其他受支援的平台，也未說明暫存資產的具體內容。
在 earendil-works/pi 的第 4 個檢查面向，應把專案名稱、README 提到的具體入口與可觀察結果放在一起理解。先確認目前分支 main 的檔案位置，再依文件中的命令或範例執行；若輸入格式、作業系統、編譯器、供應商服務或憑證條件不同，結果就不能直接互相比較。記錄成功輸出、錯誤訊息和程序是否正常結束，才能分辨是功能限制、環境差異還是文件未涵蓋的情況。這個步驟針對 pi 本身，不代表 README 對未描述的使用場景作出保證。還要把實際使用的版本、設定值和輸入樣本留下，否則之後無法說明同一個命令為何得到不同輸出。對照輸入與輸出時，應特別查看專案列出的檔案名稱、參數名稱、佇列或資料欄位，並把可重現的差異寫下來。若 README 沒有描述錯誤處理、併發順序或平台支援，就只能記錄觀察結果，不能補成保證。
供應鏈加固措施
專案將 npm 依賴變更視為需要審查的程式碼變更。直接外部依賴被固定到精確版本，內部工作區套件保持版本範圍。.npmrc 設定了 save-exact=true 和 min-release-age=2，以避免在 npm 解析時遇到當天發佈的依賴。package-lock.json 是依賴的真實來源，預先提交鉤子會阻止意外提交鎖檔案，除非設定 PI_ALLOW_LOCKFILE_CHANGE=1。npm run check 驗證固定的直接依賴、原生 TypeScript 匯入相容性以及產生的 coding-agent shrinkwrap。已發佈的 CLI 套件包含 npm-shrinkwrap.json，用於為 npm 使用者固定傳遞依賴。CI 使用 npm ci --ignore-scripts 安裝，一個排定工作流程執行 npm audit --omit=dev 和 npm audit signatures --omit=dev。shrinkwrap 產生對依賴生命週期指令碼有明確的允許清單。README 未說明稽核工作流程的執行頻率。
在 earendil-works/pi 的第 5 個檢查面向，應把專案名稱、README 提到的具體入口與可觀察結果放在一起理解。先確認目前分支 main 的檔案位置，再依文件中的命令或範例執行；若輸入格式、作業系統、編譯器、供應商服務或憑證條件不同，結果就不能直接互相比較。記錄成功輸出、錯誤訊息和程序是否正常結束，才能分辨是功能限制、環境差異還是文件未涵蓋的情況。這個步驟針對 pi 本身，不代表 README 對未描述的使用場景作出保證。還要把實際使用的版本、設定值和輸入樣本留下，否則之後無法說明同一個命令為何得到不同輸出。對照輸入與輸出時，應特別查看專案列出的檔案名稱、參數名稱、佇列或資料欄位，並把可重現的差異寫下來。若 README 沒有描述錯誤處理、併發順序或平台支援，就只能記錄觀察結果，不能補成保證。
貢獻流程與工作階段分享
來自新貢獻者的新 issue 和拉取請求預設會自動關閉，維護者每日審查自動關閉的 issue。貢獻指南位於 CONTRIBUTING.md，AGENTS.md 包含面向人類和代理的專案專屬規則。長期計劃透過 rfc.earendil.com/keyword/pi/ 上的 RFC 追蹤。README 還要求使用者分享其開源編碼代理工作階段；發佈工作階段的工具是 badlogic/pi-share-hf，需要 Hugging Face 帳戶、Hugging Face CLI 和 pi-share-hf 本身。README 連結了範例發佈工作階段，但沒有描述工作階段資料格式。
在 earendil-works/pi 的第 6 個檢查面向，應把專案名稱、README 提到的具體入口與可觀察結果放在一起理解。先確認目前分支 main 的檔案位置，再依文件中的命令或範例執行；若輸入格式、作業系統、編譯器、供應商服務或憑證條件不同，結果就不能直接互相比較。記錄成功輸出、錯誤訊息和程序是否正常結束，才能分辨是功能限制、環境差異還是文件未涵蓋的情況。這個步驟針對 pi 本身，不代表 README 對未描述的使用場景作出保證。還要把實際使用的版本、設定值和輸入樣本留下，否則之後無法說明同一個命令為何得到不同輸出。對照輸入與輸出時，應特別查看專案列出的檔案名稱、參數名稱、佇列或資料欄位，並把可重現的差異寫下來。若 README 沒有描述錯誤處理、併發順序或平台支援，就只能記錄觀察結果，不能補成保證。
授權
Pi 採用 MIT 授權，版權歸 Mario Zechner，2025 年。該授權授予使用、複製、修改、合併、發佈、分發、再授權和出售軟體副本的權利，條件是所有副本或實質部分必須包含版權聲明和授權聲明。軟體按原樣提供，不作任何形式的擔保，授權文字對支援、安全保證或維護承諾隻字未提。README 也未說明 pi.dev 上的文件是否適用同一授權。
在 earendil-works/pi 的第 7 個檢查面向，應把專案名稱、README 提到的具體入口與可觀察結果放在一起理解。先確認目前分支 main 的檔案位置，再依文件中的命令或範例執行；若輸入格式、作業系統、編譯器、供應商服務或憑證條件不同，結果就不能直接互相比較。記錄成功輸出、錯誤訊息和程序是否正常結束，才能分辨是功能限制、環境差異還是文件未涵蓋的情況。這個步驟針對 pi 本身，不代表 README 對未描述的使用場景作出保證。還要把實際使用的版本、設定值和輸入樣本留下，否則之後無法說明同一個命令為何得到不同輸出。對照輸入與輸出時，應特別查看專案列出的檔案名稱、參數名稱、佇列或資料欄位，並把可重現的差異寫下來。若 README 沒有描述錯誤處理、併發順序或平台支援，就只能記錄觀察結果，不能補成保證。
編輯結論
Pi 是一個 MIT 授權的 TypeScript monorepo，其 README 重點介紹套件結構、容器化選項、建置步驟和供應鏈控制。API 細節、受支援的平台以及沙箱模式的安全屬性在 README 中未涉及，需要對照 pi.dev 上的文件進行核實。 採用前請先依照 README 中的具體命令與檔案驗證，並把未說明的部分視為未知。
社群筆記