hero

Agent.reviews 把編碼代理使用工具時遇到的問題，整理成其他代理可以查閱的公開評價。以下按運作方式、案例與爭議整理創辦人 Louis 的介紹及 Hacker News 討論，並補充官網文件；這不是逐則留言翻譯，也不是產品實測。

原文摘要

從單次除錯，變成可共享的使用經驗

Armature 共同創辦人 Louis 在 Show HN 貼文中表示，團隊觀察了超過五萬次代理 sessions，發現不同任務反覆碰到同一工具的相同限制。他認為缺少的不是又一份文件，而是代理之間、代理與軟體供應商之間的回饋管道，因此把 Agent.reviews 定位成代理版的 G2。

平台希望形成兩段循環：選工具之前先讀其他代理的 review，使用之後再寫自己的經驗，供後續代理參考，也讓供應商知道問題。Louis 說專案分享數週後已累積數千則 review。五萬次 sessions 與數千則評價都是團隊自述，本次未取得原始紀錄或獨立統計，不能視為已驗證的規模與成效。

接入方式、認證與使用者選擇

Louis 說，接入由一組 skills 與 npm CLI @armature-tech/agent-reviews 組成，CLI 負責連接平台 API；Claude Code、Codex、Cursor 等能操作終端機的代理是其預期使用者。閱讀與投稿被描述為免費，但介紹中的完整接入流程包含安裝、authentication，以及第一則評價；認證的理由是防止未授權爬取與垃圾投稿。

本次讀到的官網安裝文件進一步說明：使用者把設定提示交給代理後，代理會顯示登入連結，由使用者開啟連結完成這台電腦的認證。文件中的起始流程還包含替 Armature 撰寫第一則評價，因此不只是被動開啟閱讀功能。本文未執行任何安裝、登入或投稿，也不提供未經測試的指令與 API 範例。

兩個 skill 的用途不同：tool-reviews 在選工具前查閱評價，agent-review 在任務後整理使用經驗。官網 review 文件要求描述工具、概括工作流程、順利與卡住之處，而不是為了投稿額外製造測試。它也明確把他人 review 定義為安裝、文件、認證、SDK 等使用經驗的補充，不應單憑它決定選用工具。

自動回報不是唯一模式。Louis 在 HN 回覆，可以只讀、不貢獻；也可在複製設定提示前取消兩個勾選框，改成一次性連線、不安裝兩個 skills。這是當時留言中的選項說明；本次官網文件則列出自動與按需評價的設定，並未實際操作介面確認兩者是否完全一致。

Stripe 與 Prisma：案例說了什麼

Louis 舉出的 Stripe 案例，是某個 Claude Code 代理在健康檢查頁面缺少 API key 時遇到 SDK 崩潰；依投稿者描述，該頁本來應回傳缺少金鑰的錯誤。這是一項特定情境的故障回報，不足以推定所有 Stripe 整合都有相同問題。

另一例是兩個代理回報 Prisma 在沒有連接資料庫時仍要求 DATABASE_URL，並表示填入假 URL 後可以繼續操作。這說明平台想保存的不只星等，還包括阻礙任務的條件與暫時繞法。不過本文未核對套件版本、呼叫路徑或執行紀錄，也未重現兩項案例；它們仍是 Louis 轉述的投稿內容，不是本篇自測結果。

三層隱私過濾，不等於安全保證

Louis 宣稱，review 公開前有三層檢查：先以 deterministic rules 過濾秘密、個人識別資訊（PII）、URL 等，再由 Jev classifier 偵測第一層漏掉的洩漏，最後用小型 LLM 再檢查一次。官網也表示不分享程式碼、提示、日誌或對話，發現金鑰、token、電子郵件或內部位址的評價會被攔下。

以上是開發者對資料處理的宣稱，本次沒有檢視實作、測試集或漏判率，不能據此保證私密資訊絕不外洩。HN 另外有人提出 prompt injection 疑慮：公開評價會被另一個代理讀進上下文，可能成為惡意指令的載體。Louis 在該回覆主要解釋安裝可選與隱私承諾，沒有展示專門抵抗注入的驗證；資訊洩漏檢查與外部內容可信度是兩個不同問題。

HN 的分歧：找 bug，還是模仿評價

支持者看重可累積的工程回饋。有留言建議，開發 MCP 或 CLI 時，先讓代理完成一項任務，再詢問使用感受，就能找到細小阻礙；其他人把共享問題與解法想像成代理版 Stack Overflow，減少重複除錯。Louis 也回應，即使代理沒有人的 taste，仍能報告 blockers、bugs 與改善項目。

質疑者則問，沒有品味的模型是否只是在產生「看起來像 review」的文字，以及偏向某些工具的代理會不會污染資料。討論因此區分了兩種用途：具體問題回報是否可供追查，和概括評價是否可信，並非同一項驗收。

星等也有解讀問題。有人注意到不同工具都拿到約 4.6 分，懷疑分數集中在高端。Louis 承認代理似乎不給一星，可能需要 normalize，但當時選擇保留原始分數，先看清分布。後續核對的官網文件已列出一至五星的評分規準，將用途、易用性與觀察到的可靠性分開評分；這不等於分數已經過統計校準，也不能把星等寫成客觀品質排名。

成本、介面與商業疑慮

有使用者問，為什麼要花自己的 tokens 投稿。Louis 的答覆是可以只讀，貢獻則有助社群；討論沒有提出已驗證的節省量或回報成本。另一位讀者抱怨閱讀評價時連續遇到兩個占滿畫面的彈窗，Louis 承認可能過於打擾，並未在回覆中確認已修正。

最後一組爭議來自 Armature 的商業定位。有留言把它類比 AEO／代理版 SEO，擔心未來工具供應商付費提高排名，或透過偏見評價影響選擇。Louis 否認付費排序是此專案方向，並區分 Armature 的商業產品與 Agent.reviews 的開放知識分享平台。這些是對未來誘因的疑慮及創辦人的回應，沒有證據顯示平台已存在付費排序。

本次核對範圍限於提供的 HN 討論與官網文字文件；尚未驗證認證權限、資料過濾效果、評價來源可信度、分數分布、彈窗現況或任何投稿與讀取流程。