你應該為你的專案選擇哪個AI代理？

上週，我看到有人讓他們的前端代理「建立一個生成影象的優秀提示」。代理做到了。但效果很糟糕。它產生了一些前端開發人員會寫的東西：元件形狀、模糊的視覺效果，缺少提示工程師對光照術語、相機詞彙和負提示的瞭解。

沒有人注意到，因為失敗是無聲的。代理不會說「這不是我的工作」。它只是做了別人工作的平庸版本。

這就是選擇錯誤代理的真正代價。不是錯誤，而是看似輸出的平庸。

人物就是產品

一個 AI 代理是一個模型加上一個系統提示。相同的模型，不同的系統提示，產生不同的結果。這就是整個竅門，而且並不簡單。

QA 代理不會「更努力地尋找錯誤」。它的人物告訴它要不信任快樂路徑，列舉邊緣情況，並在修復之前編寫重現步驟。安全代理讀取與全棧代理相同的身份驗證程式碼，但看到會話固定，而全棧代理則看到一個正常的登入。 AgentsRoom 中的 14 個內建角色 存在的原因是這些框架確實改變了相同模型的輸出。

所以「我應該使用哪個代理」並不是表面問題。它決定了在完成任務時哪些本能被啟用。

匹配任務，而不是習慣

習慣：將所有內容傳送到已經開啟的代理。通常是全棧開發人員，因為那是你在週一開啟的。

匹配：閱讀你的任務並命名它所屬的專業。

一些真實的例子，以及誰應該實際處理它們：

• 「撰寫啟動部落格文章」：市場專家，而不是你的全棧開發人員。定位和文案是一個專業，兩個段落內就能體現出來。
• 「這個測試每五次執行失敗一次」：QA 代理。間歇性測試是一門學科：隔離、時序、夾具。開發代理通常只會重新執行直到透過。
• 「收緊登入流程」：安全代理。它會在沒有被告知的情況下檢查令牌輪換、會話失效和速率限制。
• 「為影象生成建立提示」：來自目錄的提示工程師。這正是引言中的工作，也是完全適合的代理。
• 「儀表板很慢」：查詢的後端代理，渲染效能的前端代理。如果你還不能判斷哪一方有罪，那首先是一個效能分析任務。

如果任務命名了一個現實世界專家會負責的交付物，就把它交給那個專家。你在 目錄中有 260 多個專家，還有你自己的自定義代理。將通才用於所有事情就像是在為一個長椅付費卻只讓一個人上場。

當你不知道時：說出來

這是改變我工作方式的部分。你不必知道。

AgentsRoom 有一個 代理建議 顧問，正是為這個時刻而設。點選代理搜尋旁邊的閃光，輸入你會大聲說的任務（「撰寫啟動部落格文章」，「稽核登入流程」），它會回答最適合該工作的代理、一個簡短的理由和兩個替代方案。已經空閒在你房間裡的代理會被標記，因此顧問會告訴你先重用，再告訴你新增。

然後一鍵分配任務：如果需要，代理會被新增，它的終端會開啟，你輸入的確切文字會作為草稿出現在創作器中。你已經描述了一次任務。這個描述成為第一個提示。

排名規則很重要：適合優先，便利其次。顧問不會因為前端開發人員空閒就把你的影象提示工作交給前端開發人員。我們在真實的失誤中調整了這一點。

重用優先於新增

一個有十二個半用代理的房間就是它自己的失敗模式。有兩個規則保持其理智。

適合的空閒代理：重用它。沒有正在進行的任務且專業合適的代理是每次的最佳選擇。顧問會自動應用這個規則。

專業合適但忙碌：新增一個新的，而不是排隊。代理是廉價的座位。等待你的一個 QA 代理完成，而三條錯誤堆積起來，是你自己創造的瓶頸。

當任務在會話中性質發生變化時（「實際上，現在為你建置的內容編寫文件」），你根本不需要一個新的代理：代理變形 會將正在執行的代理轉變為另一個專業，保持其上下文不變。

一項任務，多個專家

有些任務並不是一個專業。「發布支付功能」是一個後端工作，然後是 QA 工作，接著可能是安全審查。選擇一個代理來處理它意味著其他兩個專業會默默地不發生。

這就是 團隊 的用途：將代理串聯起來，使工作流程從開發到 QA 再到審查，每個座位由合適的人物擔任。選擇問題變成了「誰在流程中」，而不是「誰得到所有」。

五秒版本

命名任務所屬的專業。如果你房間裡有一個空閒代理負責它，就使用他們。如果沒有，新增角色或目錄中的專家。如果你無法命名專業，描述任務並讓顧問命名。

一旦正確的代理承擔了工作，確保它不會在每個會話中從零開始重新學習你的程式碼庫：那是一個 記憶體問題，這是下一個值得修復的事情。