Empryo 評測：以符號圖譜為核心的 AI 編碼代理，以及它不打算解決的事
Empryo issue tracker + SoulForge (v2). Empryo is the graph-powered AI coding agent that edits symbols, not strings: AST surgery, full LSP, a live code genome. Get it at https://empryo.com
秒懂
- 它是什麼？
- Empryo（前身 SoulForge）用 tree-sitter 建出整份 repo 的符號圖譜，再讓代理透過 AST 動刀，而非比對字串。本文整理它實際的機制、安裝路徑、可驗證的邊界，以及什麼情況下你該改用別的方案。
- 適合誰用？
- Empryo 適合的對象是：在 30 種以上語言的中大型 repo 工作、已經有一套自己的模型金鑰、且願意接受「安裝腳本從官網抓、不走套件管理器」這種供應鏈模式的團隊。不適合的是：需要可審計的開源授權、需要從原始碼自行編譯、或工作內容以單檔小專案為主的人。
- 可以商用嗎？
- 請先確認。這個儲存庫使用的授權不在我們自動分類的範圍內，商用前請閱讀儲存庫中的 LICENSE 檔案。
- 還在維護嗎？
- 有在維護。儲存庫最近一次提交在 5 天前。
- 用什麼語言寫的？
- 主要是 TypeScript（依據 GitHub 的語言統計）。
以上回答依據專案的 GitHub 資料（最近同步於 2026年9月15日）與我們的分析，不構成法律意見。
開源專案深度解析
Empryo 想修的是字串補丁的盲區
多數編碼代理的動作迴圈是這樣：grep 找關鍵字、整檔讀進來、把新內容當字串貼回去。這個流程對單檔腳本沒問題，但在一份有依賴關係的程式庫裡，它對「我剛剛改的這個函式被誰呼叫」一無所知。README 對這個問題的敘述很直白：這些代理「never know what depends on the code they just changed」。
Empryo 的目標讀者因此有明確輪廓：手上是跨檔、跨模組、有型別系統的程式庫，而且改動經常牽動呼叫端。若你的日常是寫獨立腳本或設定檔，這套圖譜建置只是額外開銷。
要注意的是，這個 repo 本身不是產品原始碼。README 寫明這裡是 Empryo 的公開 issue 與 discussion 首頁，SoulForge 的原始碼則以既有授權封存於此。也就是說，你從這個 GitHub 頁面拿到的是問題追蹤與討論，不是可編譯的代理本體。
啟動時先建圖，查詢不燒 token
Empryo 的機制可以拆成兩段。第一段是索引：啟動時 tree-sitter 把 repo 解析成一份活的圖譜，節點涵蓋每個符號、import 與呼叫點，並以 PageRank 加上 git co-change 做排序。README 的說法是「It maps before it reads」。這一步的產出是圖查詢能在毫秒級回答，且不消耗任何 LLM token。
第二段是編輯。代理不產生字串補丁，而是走 AST 層的符號操作。README 列出 65 種以上的符號級操作，支援 30 種以上語言的結構化編輯，批次以原子方式套用，失敗時整體回滾，並以型別檢查作為關卡。它對外的說法是「Nothing breaks on whitespace」，講的是縮排與換行不再能讓一次編輯失敗。
這兩段之間靠 blast radius 串起來：改動前先看誰 import 這個檔案、這個檔案歷史上跟誰一起變動、影響往外擴散多遠。這個查詢發生在第一次按鍵之前，而不是等編譯器報錯之後。
架構上還有一層多代理設計。README 描述平行 explore 與 edit 代理共用一份 I/O 快取，便宜模型負責偵查、強模型負責寫入。任務路由器提供十個可指派角色，README 列出的名稱包括 brain、spark（scout）、ember（code）、explore、verify（review）、goal review、desloppify、summarize、compact、web search。這些角色可依分頁、依設定、依專案分別指定模型。
安裝不走套件管理器，這件事本身就是一個決策
README 給的安裝路徑是官網腳本，而不是 Homebrew、WinGet 或 npm。macOS 與 Linux 用 curl 管線進 bash，Windows 用 PowerShell 的 irm 管線進 iex。README 明確寫著「Do not download Empryo binaries from GitHub Releases or third-party package managers」。
裝完之後的設定指令是 `empryo --set-key anthropic sk-ant-...`。若不想用雲端模型，README 說可以搭配 Ollama 在本機執行，不需要金鑰。桌面應用與預編譯執行檔則從 empryo.com/download 取得，平台涵蓋 macOS、Linux 與 Windows。
值得注意的是舊版路徑仍然存在。SoulForge 可用 `brew tap proxysoul/tap && brew install soulforge`，或用 `bun install -g @proxysoul/soulforge` 安裝。README 說明 SoulForge 仍可下載安裝，並持續收到錯誤與重大問題的修正，但新功能與主要開發已經移到 Empryo。
供應鏈的角度值得直接講清楚：從官網抓腳本再管線進 shell，等於把信任集中在單一網域，換來的是不受套件管理器審核流程的延遲。這對某些團隊是加分，對另一些團隊是紅線。README 只給了做法，沒有提供校驗和或簽章資訊，這點在 repo 首頁無法確認。
授權狀態是這份 repo 最需要你自己去查的一格
GitHub 上的授權標示是 NOASSERTION，意思是平台無法從檔案自動判定出標準授權。README 的敘述是 SoulForge 原始碼「remains archived here under its existing license」，並指向 LICENSE 檔案。這兩者放在一起，代表授權條款確實存在於某個檔案裡，但無法從這份素材判斷是哪一種。
對打算在商業環境導入的團隊，這是第一個要自己打開來看的檔案。NOASSERTION 不是「沒有授權」，也不是「開源」，它只是「平台沒認出來」。把這個狀態當成寬鬆授權來用是錯的，當成專有軟體來用也未必對。
另一個容易混淆的點是產品與 repo 的關係。Empryo 本體透過官網散布，這個 GitHub repo 承載的是 issue tracker 與封存的 SoulForge 原始碼。README 說 Empryo 免費使用、沒有 per-seat 費用，但免費使用與原始碼授權是兩件事，前者不等於後者。素材中沒有任何一句把 Empryo 本體描述為開源。
官方數字來自自家 benchmark，且對手是自家另一個專案
README 的效能段落是兩輪對照，對手是 pi，條件標示為「same models, same repositories, same tasks」。第一輪是 3 個 bug 乘 3 個模型，Empryo 修好 8/9，pi 修好 7/9；成本 1.13 對 1.58 美元；牆鐘時間 4 分 16 秒對 10 分；輸入 token 1.09M 對 6.21M。第二輪用 hono、zod、ky 的 5 個真實 bug，Empryo 7/10 對 pi 6/10，成本 7.08 對 9.19 美元，時間 22 分 30 秒對 32 分 55 秒，步驟數 274 對 382。
方法論上 README 有交代幾件事：第二輪取自合併 PR 的真實 bug、時間點在訓練截止之後、歷史紀錄經過清除、每次執行後注入回歸測試。完整方法論與逐字稿指向 empryo.com/benchmarks，重現用的 repo 是 proxysoul/pi-vs-empryo-bench。
這裡的判讀重點是對手的身份。pi 與 Empryo 同屬 proxysoul 這個帳號，benchmark 由專案方自行設計與執行。這不代表數字有問題，但代表它是一份內部對照，不是第三方複核。要當成採購依據，至少得先看過那份逐字稿，確認任務選擇與評分方式。
另外，README 沒有把這些數字與其他主流代理並列。所以這份 benchmark 能回答「Empryo 相對 pi 如何」，不能回答「Empryo 相對你現在用的工具如何」。
三個介面共用一份 genome，代價是維護面變寬
README 用「one genome, three phenotypes」描述它的介面策略：原生桌面應用、完整終端機 TUI、以及供腳本與 CI 用的 headless CLI。三者共用同一份圖譜，因此索引邏輯只需要維護一套。
周邊整合也走既有標準。LSP 部分透過 Mason 取得 576 種以上的語言伺服器，MCP 部分可接任何 MCP server，另有 13 個生命週期掛鉤。對已經在 Neovim 或既有 MCP 生態裡投資的團隊，這代表不需要換掉工具鏈。
另外兩個機制值得單獨點出。其一是 time machine：每一次 prompt 都是一個 git checkpoint，程式碼與對話可以一起回溯到任一輪。其二是 free compaction：結構化上下文壓縮不呼叫 LLM，README 的說法是長 session 因此能維持低成本。第二項與第一項的圖譜是同一套資料的不同用途。
維護成本的輪廓因此比較清楚：這個專案同時維護桌面、TUI、CLI 三個前端，加上 22 家供應商的模型接線、30 種以上語言的 tree-sitter 語法與 AST 操作、以及 576 種以上語言伺服器的整合路徑。版本節奏也反映這件事，近期釋出集中在 2026 年 7 月，v2.20.23 到 v2.20.25 之間相隔數天。這種節奏對使用者是好事，對想自行 fork 的人是負擔。
什麼情況下 Empryo 是錯的工具
第一種情況是 repo 很小。圖譜的價值來自依賴密度，單檔專案或剛起步的專案沒有足夠的呼叫關係讓 PageRank 排序產生意義，索引成本換不到導航收益。
第二種情況是語言不在支援清單內。README 說 30 種以上語言，但沒有列出完整名單。若你的主力語言落在邊界外，AST 操作與結構化編輯就無從發揮，剩下的價值只有圖查詢。這一項在 repo 首頁無法確認，必須實際查。
第三種情況是團隊需要可審計的散布路徑。不經 Homebrew、WinGet、npm，也不從 GitHub Releases 取得二進位檔，代表既有的套件審核與鏡像流程都派不上用場。金融、醫療或政府環境若要求所有工具鏈可追溯，這個安裝模型會直接卡住。
第四種情況是授權必須先確定才能評估。NOASSERTION 的狀態讓法務無法在第一步放行，而 README 也沒有提供替代的授權說明。
最後一種情況與 benchmark 有關：如果你的決策依據是「與我現有工具相比能省多少」，這份素材完全沒有提供。它只有 Empryo 對 pi 的兩輪數字。
替代方案上，若你的核心需求是符號層級的程式碼理解而非代理寫入，Sourcegraph 走的是另一條路：它建立跨 repo 的程式碼索引與查詢層，供人或既有工具查詢，本身不負責改寫程式碼。差異在於主導權，Empryo 讓代理依圖譜自行決定改哪裡，Sourcegraph 把圖譜交回給人。若你的痛點是「找不到定義與引用」而不是「代理改錯地方」，後者的路線更直接。
採用前該驗的三件事
第一，打開 LICENSE 檔案。NOASSERTION 只說明平台沒認出條款，不說明條款內容。這件事在寫任何導入計畫之前就該完成。
第二，走一遍 empryo.com/benchmarks，把第二輪的逐字稿看完，特別是任務選擇與評分方式。若你的工作型態與 hono、zod、ky 這類程式庫差異很大，那組數字的參考價值會下降。重現用的 proxysoul/pi-vs-empryo-bench 也值得對照。
第三，確認你要用的模型供應商在 22 家名單內。README 點名的是 Anthropic、OpenAI、Google、Groq、DeepSeek、Bedrock，其餘 16 家未列出。若你打算走 Ollama 或 LM Studio 全本機路線，這條路 README 有明說可行，但沒有給出硬體需求。
至於 issue tracker 本身，這個 repo 同時是 Empryo 的 bug 回報與討論入口，也是 SoulForge 原始碼的封存處。兩件事混在同一個 repo 裡，搜尋歷史問題時要留意你找到的是哪一個時期的討論。
編輯結論
Empryo 適合的對象是：在 30 種以上語言的中大型 repo 工作、已經有一套自己的模型金鑰、且願意接受「安裝腳本從官網抓、不走套件管理器」這種供應鏈模式的團隊。不適合的是：需要可審計的開源授權、需要從原始碼自行編譯、或工作內容以單檔小專案為主的人。採用前務必先確認三件事：LICENSE 檔案的實際內容（repo 標示為 NOASSERTION，README 只說 SoulForge 原始碼依既有授權封存於此），empryo.com/benchmarks 上那兩輪對照的完整方法論與逐字稿，以及 22 家供應商中你實際要用的那一家是否在列。這三項在 repo 首頁都無法直接驗證。
社群筆記