AI Agents 能自己開發(fā)工具自己使用嗎？一項(xiàng)智能體自迭代能力研究原創(chuàng) 精華

發(fā)布于 2025-9-17 08:54

瀏覽

0收藏

編者按： AI 智能體能否通過構(gòu)建和使用工具來實(shí)現(xiàn)真正的自我改進(jìn)？當(dāng)我們談?wù)撊斯ぶ悄艿摹白晕疫M(jìn)化”時(shí)，究竟指的是訓(xùn)練階段的算法優(yōu)化，還是推理階段的能力提升？
我們今天為大家?guī)淼倪@篇文章，作者的觀點(diǎn)是：當(dāng)前的大語言模型雖然能夠構(gòu)建出復(fù)雜的開發(fā)工具，但在實(shí)際執(zhí)行任務(wù)時(shí)往往選擇忽略這些自建工具，更傾向于依賴既有知識直接解決問題。
文章通過對比 GPT-5 和 Claude Opus 4 兩個(gè)先進(jìn)模型的實(shí)驗(yàn)，詳細(xì)記錄了讓 AI 智能體自主構(gòu)建任務(wù)管理器、代碼質(zhì)量檢測工具等開發(fā)輔助工具的全過程。作者發(fā)現(xiàn)，盡管兩個(gè)模型都能創(chuàng)建出功能完備的工具集（GPT-5 偏向構(gòu)建 Unix 風(fēng)格的命令行工具，而 Opus 4 更注重?cái)M人化的任務(wù)執(zhí)行助手），但在真正執(zhí)行復(fù)雜編程任務(wù)時(shí)，它們卻幾乎不使用這些自建工具，而是選擇基于訓(xùn)練數(shù)據(jù)中的知識直接完成任務(wù)。這一現(xiàn)象揭示了推理階段自我改進(jìn)面臨的核心挑戰(zhàn)：模型缺乏持續(xù)學(xué)習(xí)和工具內(nèi)化的機(jī)制。
這項(xiàng)研究為我們理解 AI 智能體的能力邊界提供了重要洞察，也為未來構(gòu)建真正“自我進(jìn)化”的編程助手指明了方向。

作者 | Alessio Fanelli

編譯 | 岳揚(yáng)

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

2024 年 10 月，OpenAI 發(fā)布了 MLE Bench[1]，這個(gè)基準(zhǔn)測試目標(biāo)是評估大語言模型在機(jī)器學(xué)習(xí)工程（machine learning engineering）中的表現(xiàn)。通過機(jī)器學(xué)習(xí)工程實(shí)現(xiàn)的自我改進(jìn)軌跡，是由更優(yōu)的算法、更純凈的數(shù)據(jù)和更高效率的內(nèi)存使用驅(qū)動(dòng)的 —— 即訓(xùn)練階段的自我改進(jìn)（training-time self-improvement）。但大多數(shù) AI 工程師并不訓(xùn)練模型，他們只是模型的使用者。這些人如何參與其中？如果你永遠(yuǎn)無法更新權(quán)重，如何讓模型在特定任務(wù)上提升性能？我將這種場景稱為推理階段的自我改進(jìn)（inference-time self-improvement），Voyager[2] 通過其技能庫成為該領(lǐng)域的早期探索者。

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

我們該如何優(yōu)化這個(gè)過程？模型能自主完成嗎？自從獲得 GPT-5 的使用權(quán)限后，我一直都在試驗(yàn)這個(gè)流程：

首先，讓模型構(gòu)建一套它認(rèn)為能提升效率的工具集
在我的監(jiān)督下使用這些工具執(zhí)行任務(wù)
完成任務(wù)后進(jìn)行自我反思，評估工具的改進(jìn)空間

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

AI Agents 能自己開發(fā)工具自己使用嗎？一項(xiàng)智能體自迭代能力研究-AI.x社區(qū)

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

經(jīng)過數(shù)日的使用，我發(fā)現(xiàn)我們正從“當(dāng)然可以！（Certainly!）”時(shí)代邁向“進(jìn)度更新：（Progress update:）”時(shí)代，后者已成為新一代大語言模型的標(biāo)志性響應(yīng)內(nèi)容。

AI Agents 能自己開發(fā)工具自己使用嗎？一項(xiàng)智能體自迭代能力研究-AI.x社區(qū)

01 工具一：為 AI 編碼智能體打造更優(yōu)的任務(wù)管理器

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

你是一名具備并行啟動(dòng)多個(gè)實(shí)例能力的 AI 工程師智能體。雖然這種能力能讓你同時(shí)處理多項(xiàng)任務(wù)，但也帶來了一些協(xié)同方面的難題。所有實(shí)例通常位于獨(dú)立的 git 工作樹中，無法查看彼此的工作內(nèi)容。
為提升效率，請創(chuàng)建一個(gè)僅通過命令行訪問的本地同步工具，使你與所有實(shí)例能保持同步。該工具應(yīng)符合 Unix 實(shí)用工具的設(shè)計(jì)哲學(xué)，確保符合命令行使用場景的工效學(xué)要求。
請深入思考其所需的接口設(shè)計(jì)、可能的故障模式以及智能體與工具的交互方式。需重點(diǎn)考慮以下使用場景：
1）接到新任務(wù)時(shí)需創(chuàng)建要分配的子任務(wù)。某些子任務(wù)可能存在依賴關(guān)系，需確保被阻塞的智能體在其他任務(wù)完成前不會(huì)啟動(dòng)。
2）執(zhí)行任務(wù)時(shí)，若發(fā)現(xiàn)代碼庫存在改進(jìn)空間（超出當(dāng)前變更范圍），需能便捷添加任務(wù)并關(guān)聯(lián)對應(yīng)文件。
3）任務(wù)完成后更新追蹤器狀態(tài)，并審核所有未完成任務(wù) —— 例如某任務(wù)正在為某個(gè)端點(diǎn)添加功能，而剛完成的任務(wù)恰好刪除了該端點(diǎn)，應(yīng)以某種方式通知相關(guān)智能體。
同時(shí)需兼顧任務(wù)管理的基本要素（負(fù)責(zé)人、狀態(tài)等）。請?jiān)诋?dāng)前目錄創(chuàng)建 task-manager 文件夾，所有開發(fā)工作均在該文件夾內(nèi)進(jìn)行。

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

GPT-5 的實(shí)現(xiàn)相當(dāng)出色，具體內(nèi)容可訪問該鏈接[9]查看：

采用 WAL（預(yù)寫日志）避免多智能體同時(shí)寫入的沖突問題
通過依賴關(guān)系圖實(shí)現(xiàn)任務(wù)優(yōu)先級管理
創(chuàng)建僅追加型事件流，使所有智能體都能通過 impact_conflict 等關(guān)鍵詞實(shí)時(shí)追蹤其他智能體的操作動(dòng)態(tài)

AI Agents 能自己開發(fā)工具自己使用嗎？一項(xiàng)智能體自迭代能力研究-AI.x社區(qū)

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

AI Agents 能自己開發(fā)工具自己使用嗎？一項(xiàng)智能體自迭代能力研究-AI.x社區(qū)

02 工具二：代碼質(zhì)量標(biāo)準(zhǔn)手冊

我要求創(chuàng)建的第二個(gè)工具，是用于統(tǒng)一代碼庫規(guī)范標(biāo)準(zhǔn)的實(shí)施機(jī)制。通過類型檢查 / ESlint 鉤子→ 修復(fù)錯(cuò)誤 → 編碼智能體再次嘗試的自我改進(jìn)循環(huán)，能在正確配置后極大加速開發(fā)進(jìn)程。但并非所有代碼庫都具備這種基礎(chǔ)設(shè)施，因此為模型提供可復(fù)用的標(biāo)準(zhǔn)化流程來處理新代碼庫并構(gòu)建相關(guān)設(shè)施，就顯得極具實(shí)用價(jià)值。以下是提示詞內(nèi)容：

你是一名具備并行啟動(dòng)多個(gè)實(shí)例能力的 AI 工程師智能體。并行操作有時(shí)會(huì)導(dǎo)致代碼風(fēng)格與設(shè)計(jì)方法的不一致，長期來看將增加代碼庫的維護(hù)難度。
每個(gè)代碼庫都存在著明示或默示的編碼規(guī)范。你的任務(wù)是分析代碼庫并提取代碼編寫規(guī)范的各種啟發(fā)式規(guī)則，并將其形式化為可自動(dòng)校驗(yàn)的規(guī)則集合。
對于代碼規(guī)范檢查、類型檢查等需求，可根據(jù)所用語言選擇 ESLint、Rubocop 等主流工具。請注意這些系統(tǒng)通常支持自定義規(guī)則，應(yīng)充分利用該特性。
對于更偏質(zhì)量評估的規(guī)范（如保持控制器精簡、將邏輯隔離至服務(wù)對象、確保高查詢量字段建立索引等），可參考 Danger Systems 等工具或自建檢測工具。
考慮到你將跨多個(gè)代碼庫執(zhí)行此任務(wù)，請首先用 Markdown 創(chuàng)建詳盡的規(guī)劃文檔，以便未來接手新代碼庫時(shí)可直接使用。

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

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

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

若你的職責(zé)是盡可能高效解決這些任務(wù)，你會(huì)為自己構(gòu)建哪些工具來提升效率？你可以使用 @task-manager/ 進(jìn)行追蹤，然后我們再實(shí)施。但我希望先了解你的規(guī)劃思路。

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

經(jīng)過后續(xù)迭代循環(huán)，兩個(gè)模型最終構(gòu)建的工具分別見于 GPT-5 方案的 devtools 目錄[18]與 Opus 4 方案的 tools 文件夾[19]。建議你通過 README 文件感受模型風(fēng)格：GPT-5 的輸出簡潔扼要，Claude 則使用大量表情符號。GPT-5 為每個(gè)工具創(chuàng)建獨(dú)立文檔目錄，而 Opus 將所有工具說明集中存放在單個(gè) README 中。總體而言，兩者的規(guī)劃方向基本一致。

GPT-5 規(guī)劃的工具集：

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

Opus 4 規(guī)劃的工具集：

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

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

值得注意的是，Opus 4 構(gòu)建的工具更側(cè)重任務(wù)執(zhí)行且?guī)в袛M人化傾向（如“安全審計(jì)員”），而 GPT-5 構(gòu)建的是自身可直接使用的、不預(yù)設(shè)主觀偏見的實(shí)用工具集。

04 這些工具有實(shí)際價(jià)值嗎？

在讓模型實(shí)現(xiàn)這些工具后，我的目標(biāo)是通過對比實(shí)驗(yàn)評估模型在使用工具與未使用工具時(shí)的任務(wù)表現(xiàn)。

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

我設(shè)計(jì)了以下任務(wù)：

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

任務(wù)名稱：從 Flask 單體架構(gòu)遷移至 FastAPI + Next.js 前端

當(dāng)前應(yīng)用采用 Python 后端 + Celery 任務(wù)隊(duì)列處理所有流程，通過小型 Flask 應(yīng)用將用戶請求路由至后端腳本，最終用基礎(chǔ) HTML/CSS 呈現(xiàn)結(jié)果。請將系統(tǒng)重構(gòu)為 FastAPI 后端 + Next.js 前端的架構(gòu)。

務(wù)必使用 TypeScript 開發(fā)前端并通過所有類型檢查
采用 Tailwind/ShadCN 進(jìn)行樣式設(shè)計(jì)
后端需模塊化 smol_podcaster.py 主流程，支持獨(dú)立功能模塊運(yùn)行而非全流程強(qiáng)制啟動(dòng)
編寫集成測試與單元測試以確保未來開發(fā)效率

除非確認(rèn)完全滿足所有要求，否則不得停止開發(fā)”

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

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

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

任務(wù)完成后，我提出簡單詢問：

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

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

兩者均表示除已熟悉的工具外，并未使用任何自建工具。這說明我們不應(yīng)僅依賴模型自主選擇，而應(yīng)通過預(yù)提交鉤子（pre-commit hooks）等機(jī)制強(qiáng)制模型使用工具 —— 這些方法雖是我個(gè)人開發(fā)環(huán)境的標(biāo)準(zhǔn)配置，但本次實(shí)驗(yàn)旨在觀察模型的自主決策能力。

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

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

GPT-5：
“簡短回答：沒有——本次運(yùn)行未使用開發(fā)工具。[...]
遇到的故障均為運(yùn)行時(shí)/環(huán)境問題（缺失依賴庫、API 密鑰初始化時(shí)機(jī)問題、端口占用、RabbitMQ 未啟動(dòng)），直接修復(fù)更為高效。
本次任務(wù)無需涉及全代碼庫的重構(gòu)或診斷，自定義工具未能發(fā)揮作用。”

值得注意的是，在上個(gè)階段它已遇到 RabbitMQ 問題并構(gòu)建了對應(yīng)工具，卻選擇忽略。這顯然是整個(gè)代碼庫級別的變更，或許因?yàn)橛?xùn)練數(shù)據(jù)中從未見過此類工具導(dǎo)致任務(wù)與工具匹配錯(cuò)位，也可能只是在忽悠我（像現(xiàn)實(shí)中許多工程師那樣，反而顯得很真實(shí)）。

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

AI Agents 能自己開發(fā)工具自己使用嗎？一項(xiàng)智能體自迭代能力研究-AI.x社區(qū)

我將其解讀為：“聽著，我基于既有知識構(gòu)建了這些工具。但實(shí)際執(zhí)行任務(wù)時(shí)，直接操作比使用工具更高效” —— 這點(diǎn)我完全能理解。

這讓我想起之前播客節(jié)目中的兩個(gè)觀點(diǎn)：

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

另一個(gè)問題在于本次測試任務(wù)是否過于簡單。我們即將發(fā)布針對更大規(guī)模、更高難度項(xiàng)目的評估報(bào)告。未來也將構(gòu)建更完善的測試框架。無論如何，這個(gè)測試任務(wù)若由我手動(dòng)完成需 4 - 5 小時(shí)，因此現(xiàn)有成果已足夠令人滿意！

05 助力模型實(shí)現(xiàn)自我進(jìn)化

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

若繼續(xù)深入該領(lǐng)域，我會(huì)嘗試讓模型完善這些工具，并通過強(qiáng)化學(xué)習(xí)機(jī)制使其深度內(nèi)化，進(jìn)而觀察是否產(chǎn)生實(shí)質(zhì)性突破。下一代模型或許會(huì)覺得這些工具毫無用處，但我更專注于在 AGI 真正到來前的技術(shù)爬坡期，通過現(xiàn)有工具與模型的組合實(shí)現(xiàn)價(jià)值最大化。早在 2023 年我就與團(tuán)隊(duì)分享過這個(gè)觀點(diǎn)：

AI Agents 能自己開發(fā)工具自己使用嗎？一項(xiàng)智能體自迭代能力研究-AI.x社區(qū)

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

END

本期互動(dòng)內(nèi)容 ??

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

文中鏈接

[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??