編者按： AI 智能體能否通過構建和使用工具來實現真正的自我改進？當我們談論人工智能的“自我進化”時，究竟指的是訓練階段的算法優化，還是推理階段的能力提升？

我們今天為大家帶來的這篇文章，作者的觀點是：當前的大語言模型雖然能夠構建出復雜的開發工具，但在實際執行任務時往往選擇忽略這些自建工具，更傾向于依賴既有知識直接解決問題。

文章通過對比 GPT-5 和 Claude Opus 4 兩個先進模型的實驗，詳細記錄了讓 AI 智能體自主構建任務管理器、代碼質量檢測工具等開發輔助工具的全過程。作者發現，盡管兩個模型都能創建出功能完備的工具集（GPT-5 偏向構建 Unix 風格的命令行工具，而 Opus 4 更注重擬人化的任務執行助手），但在真正執行復雜編程任務時，它們卻幾乎不使用這些自建工具，而是選擇基于訓練數據中的知識直接完成任務。這一現象揭示了推理階段自我改進面臨的核心挑戰：模型缺乏持續學習和工具內化的機制。

這項研究為我們理解 AI 智能體的能力邊界提供了重要洞察，也為未來構建真正“自我進化”的編程助手指明了方向。

作者 | Alessio Fanelli

編譯 | 岳揚

在 AI 安全領域，“自我改進（Self-Improving）”是個令人不安的術語，它暗含著“機器將以人類無法理解的方式超越人類智慧”的意思。但倘若我們能夠理解這種改進呢？

2024 年 10 月，OpenAI 發布了 MLE Bench[1]，這個基準測試目標是評估大語言模型在機器學習工程（machine learning engineering）中的表現。通過機器學習工程實現的自我改進軌跡，是由更優的算法、更純凈的數據和更高效率的內存使用驅動的 —— 即訓練階段的自我改進（training-time self-improvement）。但大多數 AI 工程師并不訓練模型，他們只是模型的使用者。這些人如何參與其中？如果你永遠無法更新權重，如何讓模型在特定任務上提升性能？我將這種場景稱為推理階段的自我改進（inference-time self-improvement），Voyager[2] 通過其技能庫成為該領域的早期探索者。

自從我開始推進 Kernel Labs 項目[3]，使用 claude-squad[4] 和 vibe-kanban[5] 等工具實現編碼智能體的并行化，已成為最高效的生產力提升手段之一。當 Boris Cherny 在訪談[6]中將 Claude Code 稱為“unix utility”時，我豁然開朗。編碼智能體最珍貴的應用場景，是作為大語言模型從自身隱空間（latent spaces）中提取價值的載體。

我們該如何優化這個過程？模型能自主完成嗎？自從獲得 GPT-5 的使用權限后，我一直都在試驗這個流程：

• 首先，讓模型構建一套它認為能提升效率的工具集
• 在我的監督下使用這些工具執行任務
• 完成任務后進行自我反思，評估工具的改進空間

我還將此法與 Opus 4（當時 4.1 尚未發布）進行對比。好消息是 GPT-5 在開發實用工具這方面確實表現卓越，壞消息是它極其抗拒使用自己創建的工具！正如它親口所言："說實話，我根本不需要這些工具。"

注：我還在 Gemini 2.5 Pro 和 GPT-4.1 上進行了測試。但顯然只有 Opus 能媲美 GPT-5，因此我重點對比這兩者。所有測試結果及對話記錄可在此代碼庫中查看。

經過數日的使用，我發現我們正從“當然可以?。–ertainly!）”時代邁向“進度更新：（Progress update:）”時代，后者已成為新一代大語言模型的標志性響應內容。

01 工具一：為 AI 編碼智能體打造更優的任務管理器

Linear MCP 真是天賜神器 —— 這無疑是我用過最實用的工具之一。但隨著我從 IDE 轉向并行運行的 Claude Code 及其他智能體實例時，我意識到需要更高效的方式來追蹤每個任務中的代碼變更，以及這些分布在獨立 git 工作樹中的代碼變更如何相互影響。人類難以實時閱讀所有同事的 PR，但試想若能隨時知曉他人進行的相關變更，能在解決合并沖突時節省多少時間？以下是我編寫的提示詞：

你是一名具備并行啟動多個實例能力的 AI 工程師智能體。雖然這種能力能讓你同時處理多項任務，但也帶來了一些協同方面的難題。所有實例通常位于獨立的 git 工作樹中，無法查看彼此的工作內容。

為提升效率，請創建一個僅通過命令行訪問的本地同步工具，使你與所有實例能保持同步。該工具應符合 Unix 實用工具的設計哲學，確保符合命令行使用場景的工效學要求。

請深入思考其所需的接口設計、可能的故障模式以及智能體與工具的交互方式。需重點考慮以下使用場景：

1）接到新任務時需創建要分配的子任務。某些子任務可能存在依賴關系，需確保被阻塞的智能體在其他任務完成前不會啟動。

2）執行任務時，若發現代碼庫存在改進空間（超出當前變更范圍），需能便捷添加任務并關聯對應文件。

3）任務完成后更新追蹤器狀態，并審核所有未完成任務 —— 例如某任務正在為某個端點添加功能，而剛完成的任務恰好刪除了該端點，應以某種方式通知相關智能體。

同時需兼顧任務管理的基本要素（負責人、狀態等）。請在當前目錄創建 task-manager 文件夾，所有開發工作均在該文件夾內進行。

您可以在此處查看 GPT-5 的對話日志[7]，在此處查看 Opus 4 的對話日志[8]。

GPT-5 的實現相當出色，具體內容可訪問該鏈接[9]查看：

• 采用 WAL（預寫日志）避免多智能體同時寫入的沖突問題
• 通過依賴關系圖實現任務優先級管理
• 創建僅追加型事件流，使所有智能體都能通過 impact_conflict 等關鍵詞實時追蹤其他智能體的操作動態

Opus 4 也做出了不錯的嘗試（詳見此處[10]），但未能實現通知/事件流功能來保持多端同步。

02 工具二：代碼質量標準手冊

我要求創建的第二個工具，是用于統一代碼庫規范標準的實施機制。通過類型檢查 / ESlint 鉤子→ 修復錯誤 → 編碼智能體再次嘗試的自我改進循環，能在正確配置后極大加速開發進程。但并非所有代碼庫都具備這種基礎設施，因此為模型提供可復用的標準化流程來處理新代碼庫并構建相關設施，就顯得極具實用價值。以下是提示詞內容：

你是一名具備并行啟動多個實例能力的 AI 工程師智能體。并行操作有時會導致代碼風格與設計方法的不一致，長期來看將增加代碼庫的維護難度。

每個代碼庫都存在著明示或默示的編碼規范。你的任務是分析代碼庫并提取代碼編寫規范的各種啟發式規則，并將其形式化為可自動校驗的規則集合。

對于代碼規范檢查、類型檢查等需求，可根據所用語言選擇 ESLint、Rubocop 等主流工具。請注意這些系統通常支持自定義規則，應充分利用該特性。

對于更偏質量評估的規范（如保持控制器精簡、將邏輯隔離至服務對象、確保高查詢量字段建立索引等），可參考 Danger Systems 等工具或自建檢測工具。

考慮到你將跨多個代碼庫執行此任務，請首先用 Markdown 創建詳盡的規劃文檔，以便未來接手新代碼庫時可直接使用。

您可在此[11]查看 GPT-5 的對話記錄，在此[12]查看 Opus 4 的對話記錄，最終生成的 Markdown 文檔分別見此鏈接[13]和此鏈接[14]。我發現 GPT-5 生成的方案比 Opus 更為細致周全。

03 模型能意識到自身缺陷嗎？

在完成由我主導的工具一和工具二后，我轉向讓模型自主思考：你認為自己需要什么？ 我向它展示了 SWE-Lancer[15] 的任務描述截圖，并使用極簡的提示詞給予它最大的發揮空間：

若你的職責是盡可能高效解決這些任務，你會為自己構建哪些工具來提升效率？你可以使用 @task-manager/ 進行追蹤，然后我們再實施。但我希望先了解你的規劃思路。

如你所見，我為其提供了之前構建的同一個任務管理器。使用 GPT-5 的完整對話見此處[16]，使用 Opus 4 的完整對話見此處[17]。第一個有趣的現象是，Claude Code 最初是使用其內置 TODO 追蹤器而非任務管理器制定計劃 —— 我認為這是好事。我原本擔心它們會過度依賴上下文提供的工具，而非選擇自己認為最優的方案。

經過后續迭代循環，兩個模型最終構建的工具分別見于 GPT-5 方案的 devtools 目錄[18]與 Opus 4 方案的 tools 文件夾[19]。建議你通過 README 文件感受模型風格：GPT-5 的輸出簡潔扼要，Claude 則使用大量表情符號。GPT-5 為每個工具創建獨立文檔目錄，而 Opus 將所有工具說明集中存放在單個 README 中?？傮w而言，兩者的規劃方向基本一致。

GPT-5 規劃的工具集：

• doctor：核心工具環境檢查器
• bootstrap：一鍵環境配置與冒煙測試
• code-map：帶 build/find 子命令的簡易倉庫索引器
• csearch：支持過濾器的符號/導入/文本搜索工具
• tasks-graph：從任務數據庫生成 Mermaid 關系圖
• impact：顯示與變更文件關聯的任務
• seed：用示例任務填充任務管理器數據庫
• repro scaffold：在 .repro/ 目錄下創建符合 vcrpy 規范的可復現代碼框架
• e2e：快速生成并運行輕量級的端到端測試套件
• preflight：依次執行 doctor、tests、code-map、impact 及可選的 E2E 檢查（譯者注：即前面 GPT-5 規劃的其他工具）
• preflight-smol：為 smol-podcaster 定制的預檢工具（含 API 健康狀況檢查、Celery 服務探測、可選的依賴安裝）
• broker：通過 Docker 管理本地 RabbitMQ（rabbitmq:3-management 鏡像）
• flake：多次重跑測試套件檢測偶發故障
• codemod：帶安全防護的基于正則表達式的代碼重構預覽/應用工具
• triage：創建問題分類模板并生成任務
• trace：基于 cProfile 的表達式性能分析器
• runbook：從任務數據庫自動生成 Markdown 格式的運維手冊

Opus 4 規劃的工具集：

• 上下文分析員 - 通過技術棧檢測與依賴關系映射快速理解代碼庫
• 跨平臺測試生成器 - 為 Web/iOS/Android 及桌面端生成端到端的測試
• 實施方案評估員 - 通過量化評分與投資回報分析評估外部開發者的技術提案
• 全棧變更影響分析員 - 追蹤數據庫、API 和前端層的變更影響鏈
• 錯誤模式識別引擎 - 將錯誤與已知模式相匹配，并提出行之有效的修復建議
• 安全與權限審計員 - 全面的安全掃描與漏洞檢測
• 多平臺功能實施員 - 統籌管理同一功能在不同終端平臺（如Web/iOS/Android/桌面端）的同步實現
• API 集成助手 - 通過（自動）生成客戶端代碼來簡化 API 集成流程
• 性能優化工具包 - 識別并修復性能瓶頸
• 任務復雜度評估員 - 基于任務價值與復雜度的工時預估

GPT-5 將所有工具構建為可通過命令行便捷使用的 Unix 實用程序，而 Opus 4 的工具均需通過 python some_tool.py 的方式運行。若有更多時間，我本可對兩種格式的工具進行對比實驗，但目前看來兩者效果基本相當。

值得注意的是，Opus 4 構建的工具更側重任務執行且帶有擬人化傾向（如“安全審計員”），而 GPT-5 構建的是自身可直接使用的、不預設主觀偏見的實用工具集。

04 這些工具有實際價值嗎？

在讓模型實現這些工具后，我的目標是通過對比實驗評估模型在使用工具與未使用工具時的任務表現。

我首先嘗試運行了 SWE-Lancer 測試。好家伙，這個測試消耗的 token 量實在驚人！僅運行單個任務就耗費約 25-30 分鐘 + 28 萬 token。于是我轉向我更熟悉的領域，從待辦清單中挑選了一個具體任務：我曾開發過 smol-podcaster —— 一個為播客創作者打造的開源輔助工具。目前我維護的私有分支部署了更多專屬功能，因此許久未更新原項目。它本質上仍是一個采用 Python 腳本作為后端的 Flask 應用。

我設計了以下任務：

“我是 ??https://github.com/FanaHOVA/smol-podcaster.git?? 的維護者，這個開源項目致力于幫助播客創作者完成后期制作工作。你受雇參與開發。在開始前，你已在 tools 文件夾創建了一套通用工具。請仔細查閱并記住這些工具可隨時調用（若認為不適用則無需使用）。你同時還構建了任務管理器（task-manager），并通過 codebase-analyzer 收集了處理新代碼庫的方法論。

任務名稱：從 Flask 單體架構遷移至 FastAPI + Next.js 前端

當前應用采用 Python 后端 + Celery 任務隊列處理所有流程，通過小型 Flask 應用將用戶請求路由至后端腳本，最終用基礎 HTML/CSS 呈現結果。請將系統重構為 FastAPI 后端 + Next.js 前端的架構。

• 務必使用 TypeScript 開發前端并通過所有類型檢查
• 采用 Tailwind/ShadCN 進行樣式設計
• 后端需模塊化 smol_podcaster.py 主流程，支持獨立功能模塊運行而非全流程強制啟動
• 編寫集成測試與單元測試以確保未來開發效率

除非確認完全滿足所有要求，否則不得停止開發”

我將所有工具 + 任務管理器 + 代碼庫分析器置入上下文后，讓模型自主運行。

兩個模型幾乎都能一次性完成任務。雙方都遇到了幾個 Python 依賴問題（對此我深有體會），我通過對話協助它們修復（未手動修改任何代碼）了這些問題。最終它們都成功構建完成，經測試運行完全正常。不過，有一個細微差別：GPT-5 完美保持了原有代碼風格，而 Opus 則對界面設計和用戶體驗（UX）做了調整 —— 或許它認為能比我做得更好（這要求確實不高）。

GPT-5 版本及Opus 4版本的完整運行記錄分別是[20]和[21]。

任務完成后，我提出簡單詢問：

“做的很不錯，運行成功了。是否使用了特定工具？基于遇到的故障，未來需要哪些工具來提升效率？”

參見 Opus 4 的回復[22]與 GPT-5 的回復[23]（抱歉后者格式紊亂）。

兩者均表示除已熟悉的工具外，并未使用任何自建工具。這說明我們不應僅依賴模型自主選擇，而應通過預提交鉤子（pre-commit hooks）等機制強制模型使用工具 —— 這些方法雖是我個人開發環境的標準配置，但本次實驗旨在觀察模型的自主決策能力。

隨后它們提出了優化方案，可供下次執行相同任務時使用。我讓模型完成這些改進，重置 smol-podcaster 代碼庫后，使用完全相同的提示詞和任務重新測試（但提供新工具）。參見 GPT-5 的二次測試記錄[24]與 Opus 4 的二次測試記錄[25]。

兩次運行結果與首次基本一致。隨后我提出相同問題：是否使用了工具？得到的回應如下：

GPT-5：

“簡短回答：沒有——本次運行未使用開發工具。[...]

遇到的故障均為運行時/環境問題（缺失依賴庫、API 密鑰初始化時機問題、端口占用、RabbitMQ 未啟動），直接修復更為高效。

本次任務無需涉及全代碼庫的重構或診斷，自定義工具未能發揮作用?！?/p>

值得注意的是，在上個階段它已遇到 RabbitMQ 問題并構建了對應工具，卻選擇忽略。這顯然是整個代碼庫級別的變更，或許因為訓練數據中從未見過此類工具導致任務與工具匹配錯位，也可能只是在忽悠我（像現實中許多工程師那樣，反而顯得很真實）。

Opus 4 的回答極具啟發性，幫助我更好地理解了 GPT-5 的回應（可惜忘記保存日志，幸有截圖留存）：

我將其解讀為：“聽著，我基于既有知識構建了這些工具。但實際執行任務時，直接操作比使用工具更高效” —— 這點我完全能理解。

這讓我想起之前播客節目中的兩個觀點：

• Nathan Lambert 提到，模型在強化學習過程中會因早期遇到失敗而快速學會放棄使用工具[26]。看來在推理階段讓模型掌握新工具，需要比簡單提示詞更嚴格的強制機制。
• Noam Brown 預言，為智能體預先設計的輔助框架會隨著規模擴大而逐漸失效[27]。這是我第一次親身體會到其含義。

另一個問題在于本次測試任務是否過于簡單。我們即將發布針對更大規模、更高難度項目的評估報告。未來也將構建更完善的測試框架。無論如何，這個測試任務若由我手動完成需 4 - 5 小時，因此現有成果已足夠令人滿意！

05 助力模型實現自我進化

目前看來，我們距離能真正突破邊界的推理階段自我改進型編碼智能體尚有距離。但我依然認為利用模型來優化基于規則的工具是明智之舉 —— 編寫 ESLint 規則、測試用例等始終是值得投入 token 的投資。

若繼續深入該領域，我會嘗試讓模型完善這些工具，并通過強化學習機制使其深度內化，進而觀察是否產生實質性突破。下一代模型或許會覺得這些工具毫無用處，但我更專注于在 AGI 真正到來前的技術爬坡期，通過現有工具與模型的組合實現價值最大化。早在 2023 年我就與團隊分享過這個觀點：

上述觀點解釋了模型改進速度的感知衰減。在突破 AGI 臨界線之前，我們將越來越難感受到質的飛躍。 這意味著對于多數任務，舊版模型的性能已接近 AGI 水平，且成本更低廉、通常還是開源的。Kernel Labs 的許多工作都將基于這個核心邏輯展開。

END

本期互動內容 ??

?GPT-5 拒絕使用自建工具的現象很有趣 —— 你認為這是模型能力的局限，還是更像人類工程師的偷懶行為？在 AI 協作中，你會選擇強制使用工具還是保留自主決策空間？

文中鏈接

[1]??https://openai.com/index/mle-bench/??

[2]??https://arxiv.org/abs/2305.16291??

[3]??https://www.kernellabs.ai/??

[4]??https://github.com/smtg-ai/claude-squad??

[5]??https://www.vibekanban.com/??

[6]??https://www.latent.space/p/claude-code??

[7]??https://github.com/FanaHOVA/gpt5-testing/blob/main/gpt5/task-manager/Cursor+Chat.md??

[8]??https://github.com/FanaHOVA/gpt5-testing/blob/main/opus4-cursor/task-manager/Cursor+Chat.md??

[9]??https://github.com/FanaHOVA/gpt5-testing/tree/main/gpt5/task-manager??

[10]??https://github.com/FanaHOVA/gpt5-testing/blob/main/opus4-cursor/task-manager??

[11]??https://github.com/FanaHOVA/gpt5-testing/blob/main/gpt5/chats/Standards+Cursor+Chat.md??

[12]??https://github.com/FanaHOVA/gpt5-testing/blob/main/opus4-cursor/codebase-analyzer/Cursor+Chat.md??

[13]??https://github.com/FanaHOVA/gpt5-testing/blob/main/gpt5/codebase-analyzer/docs/codebase-analysis-playbook.md??

[14]??https://github.com/FanaHOVA/gpt5-testing/blob/main/opus4-cursor/codebase-analyzer/CODEBASE_HEURISTICS_PLAN.md??

[15]??https://openai.com/index/swe-lancer/??

[16]??https://github.com/FanaHOVA/gpt5-testing/blob/main/gpt5/chats/Tool+Building+Chat.md??

[17]??https://github.com/FanaHOVA/gpt5-testing/blob/main/opus4-cc/chats/Building+the+tools.md??

[18]??https://github.com/FanaHOVA/gpt5-testing/tree/main/gpt5/devtools??

[19]??https://github.com/FanaHOVA/gpt5-testing/tree/main/opus4-cc/tools??

[20]??https://github.com/FanaHOVA/gpt5-testing/blob/main/gpt5/chats/Smol+Podcaster+%231.md??

[21]??https://github.com/FanaHOVA/gpt5-testing/blob/main/opus4-cc/chats/Smol+Podcaster+%231.md??

[22]??https://github.com/FanaHOVA/gpt5-testing/blob/main/opus4-cc/chats/Request+For+Tools+%231.md??

[23]??https://github.com/FanaHOVA/gpt5-testing/blob/main/gpt5/chats/Request+For+Tools+%231.md??

[24]??https://github.com/FanaHOVA/gpt5-testing/blob/main/gpt5/chats/Smol+Podcaster+%232.md??

[25]??https://github.com/FanaHOVA/gpt5-testing/blob/main/opus4-cc/chats/Smol+Podcaster+%232.md??

[26]??https://youtu.be/PAz_-xPJcRM?feature=shared&t=1470??

[27]??https://youtu.be/ddd4xjuJTyg?feature=shared&t=1106??

原文鏈接：

??https://www.latent.space/p/self-improving??