Nx Polygraph 盯住 AI 代理卡點
4 個重點看 Nx Polygraph 如何找出 AI 寫碼代理在 monorepo 變慢的原因，並判斷該先補觀測、驗證還是工作流。
Nx Polygraph 用來找出 AI 寫碼代理在 monorepo 裡卡住的地方。
這份清單看完，你可以更快判斷 4 件事：代理到底卡在上下文、依賴路徑、驗證，還是工作流設計。對已經在多語言、多套件倉庫裡試 AI 寫碼的團隊來說，這比單純換模型更實際。
| 項目 | 看什麼 | 適合誰 |
|---|---|---|
| Polygraph | 代理在 monorepo 的瓶頸位置 | 大型代碼庫團隊 |
| Nx | 任務圖與工作區編排 | 平台工程與多套件團隊 |
| OpenTelemetry | 追蹤與可觀測性訊號 | 想量化代理行為的團隊 |
| Agent harnesses | 執行與驗證迴圈 | 在做代理工作流的人 |
| Synthetic monorepos | 可控的測試倉庫 | 要先做實驗再上線的團隊 |
1. Polygraph 先把卡點畫出來
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
Polygraph 的重點不是再講一次 AI 會寫程式，而是把代理進到真實倉庫後，究竟在哪一步變慢、迷路或失去上下文，直接攤開來看。它把問題從「模型不夠強」改寫成「倉庫結構哪裡讓代理不好做事」。
這對團隊很重要，因為代理失敗常常不是單點錯誤，而是資料夾層級、依賴關係、檔案選擇和驗證流程一起造成的。
- 標出代理最常停住的區域
- 找出依賴密集、上下文切換多的路徑
- 看驗證在哪些步驟失效
2. Nx 把 monorepo 關係變成可讀圖譜
Polygraph 背後的基礎是 Nx，它本來就擅長理解 monorepo 的任務圖、套件關係和工作區編排。這讓它不只是看程式碼，而是看改動會牽動哪些 app、library 和 test。
如果你的團隊已經在管理很多套件，Nx 的價值在於把隱性的變更成本變成可討論的規格，讓你知道代理到底是卡在能力，還是卡在倉庫太複雜。
- 任務圖能顯示變更波及範圍
- 工作區依賴關係可直接追蹤
- build、test、lint 可一起編排
3. OpenTelemetry 讓代理行為可追蹤
文章真正指向的下一步，是把代理行為當成可以觀測的系統。這時 OpenTelemetry 這類工具就很有價值，因為它能把代理走過哪些步驟、在哪裡耗時、哪個檢查失敗記錄下來。
對工程團隊來說，這比事後猜測可靠得多。當代理在某個 repo pattern 上反覆失敗，trace 和 span 可以直接告訴你問題出在檔案探索、依賴掃描，還是測試驗證。
trace: agent_start -> file_discovery -> dependency_scan -> edit -> test -> verify4. Agent harnesses 決定代理能不能收斂
單靠提示詞，代理很難在複雜倉庫裡穩定完成多步驟任務。Agent harnesses 指的是包住代理的執行規則、測試、檢查和回饋機制，目的是讓它在真實系統裡不亂跑。
這也是這篇內容最實用的地方：瓶頸正在從「生成能力」轉向「受控執行」。如果沒有 harness，再強的模型也可能在大型代碼庫裡做出看似合理、實際不可驗證的改動。
- 每次改動後自動跑測試
- 先查檔案層，再查倉庫層依賴
- 驗證失敗就阻擋合併
5. Synthetic monorepos 適合先做實驗
Polygraph 也暗示了一種更安全的測試方式：先用 synthetic monorepos 做實驗。這種控制過的倉庫結構，能讓團隊觀察代理在哪些語言混搭、依賴圖或目錄形狀上最容易出問題。
對平台工程和開發工具團隊來說，這像一個可重複的實驗台。你可以先比較不同 repo 形狀下的代理表現，再決定要不要把流程推進到正式代碼庫。
- 倉庫結構可控
- 測試結果可重跑
- 方便比較不同工作流
怎麼挑
如果你已經在大型 monorepo 裡試 AI 寫碼，先看 Nx 和 Polygraph，因為它們最直接回答「卡在哪」。如果你更在意量化問題，OpenTelemetry 式追蹤更適合先上。若你正在設計代理流程，先補 harness，再用 synthetic monorepos 做壓力測試。
最實際的順序是：先畫出倉庫與依賴，再加驗證，最後才談擴大代理使用範圍。這樣你比較能判斷，問題是模型、環境，還是流程本身。