終於有機會玩玩 @karpathy 的 LLM Council。 我把它作為 Claude Code 內部的一個插件來構建。 將其與 OpenRouter 連接以獲取模型。 AskUserQuestion 工具在選擇委員會和主席時派上了用場。 這是我的第一次測試，但我同意 Karpathy 的看法，LLM 集合的概念可以用於超越提供有趣問題觀點的模型。 我覺得這在代理編碼中可能會有非常酷的應用。稍後會有更多相關內容。 我把這個作為插件構建，所以接下來我將探索其他與代理編碼相關的用例，比如評估、工具構建、設計和研究。 如果有足夠的興趣，我會整理一下並將其作為開放插件推出。

AI 編碼代理實際上會寫測試嗎？ 測試對於軟體的正確性和可維護性至關重要。隨著自主代理越來越多地提交拉取請求，了解它們的測試行為變得至關重要。 這項新研究分析了 AIDev 數據集，以研究代理生成的拉取請求中的測試包含模式。 他們檢查了測試出現的頻率、在 PR 生命週期中何時引入測試，以及包含測試的 PR 與不包含測試的 PR 之間的差異。 研究結果揭示了有趣的模式。隨著時間的推移，包含測試的 PR 在各代理中變得越來越普遍，這表明測試行為有所改善。但這些 PR 通常比不包含測試的 PR 更大，且完成所需的時間更長。 無論測試是否包含，合併率基本保持相似。這引發了關於審核者是否重視代理生成的測試，或僅僅不懲罰其缺失的問題。 這項工作揭示了不同代理之間的顯著變化。一些代理的測試採用率高於其他代理。包含測試的 PR 中測試代碼與生產代碼的平衡也因代理而異。 這表明測試能力在代理編碼工具中並不是均勻發展的。有些工具在遵循測試慣例方面表現更好。 隨著公司採用 AI 編碼代理，了解它們的測試行為對於代碼質量至關重要。跳過測試或編寫不充分測試的代理會產生技術負債。這一實證基礎有助於識別哪些代理符合良好的軟體工程實踐，以及在哪些方面需要改進。 論文： 在我們的學院學習如何構建有效的 AI 代理：

代理工具的時代正式來臨！ 這意味著你可以期待許多開發者在編寫自己的 Cursor 時感到興奮。 但它不需要是一個 IDE 或完整的 CLI 工具。 一個簡單的 Ralph Wiggum 插件在 Claude Code 中就能給你帶來巨大的優勢。 或者如果你想更好地控制代理的行為，可以構建一個訪問 MCP 驅動的看板的編碼代理。 你會看到許多類似概念的版本在 X 上流傳。 誰能構建出最好的代理工具正在競爭，從中將會出現新的產品和新穎的代理協調器。 但有一件事很重要。使用可自定義和靈活的工具來構建。不要害怕在構建過程中演變你的工作流程和工具。並在過程中記錄所有的知識（即，建立技能和插件）。代理喜歡記憶和上下文，這一點不會很快改變。 感覺事情發展得太快，但這並不重要。更重要的是你要不斷實驗和構建符合你需求的體驗/工作流程。