Claude Code 和 Codex 用於改進 AI 代理的工程實踐

標題：Claude Code 和 Codex 用於改進 AI 代理的工程實踐

作者：Andrew Jesson | 2026年4月24日

編碼代理在被要求改進 AI 代理時，會執行常見的工程實踐。它們是否會取代用於故障模式分析、評估和提示優化的專用工具？

給一個編碼代理一個模擬的代理應用、一百條基線軌跡和一個要優化的指標，它就會交付改進。Claude Code 和 Codex 都能做到這一點。我感興趣的是觀察它們在這個過程中具體做了什麼。

實驗設置：我提示 Claude Code 和 Codex 優化了五個模擬的代理應用，僅在容器中更換了代理 CLI。對於每個應用，我使用初始提示和模型（gpt-5.4-mini）在多達100個不同任務上運行基線代理。生成的軌跡通過應用特定的反饋進行評分。優化任務是通過修改基線代理提示和/或選擇不同但價格相近的模型來提出改進。優化器代理（Claude Code 或 Codex）被放入一個容器中，可以訪問這些軌跡、反饋、基線配置副本和一個描述任務的技能文件。它分析軌跡和反饋，寫入一個或多個新的模型-提示變體到代理配置中，然後退出。驗證表明，兩個編碼代理都在每個應用上交付了匹配或超越基線的新變體。

它們使用了哪些工程實踐？兩個編碼代理使用相同的技能文件，只包含應用名稱、指標、可用模型、數據佈局和一些效率方法，以及一個四要點方法論：調查→添加變體→測試→迭代。技能文件對如何抽象故障模式或如何驗證改進保持沉默。兩個代理填補了這一空白。它們讀取基線軌跡和反饋，從原始行中抽象出一些故障模式，編寫兩到四個提示變體，運行一些推理，分析新輸出，然後退出。

故障模式分析：從推理和反饋數據集出發，識別出“模型過度抽取雜項，因為它將其視為一個綜合類”這樣的模式。技能文件將這兩個先決條件留給代理：從 JSONL 中投影失敗行，然後將它們抽象為命名模式。兩個代理都採用了相同的配方：從反饋中 grep 出失敗的 target_id，然後將每個 ID 對應到推理行並取最後一行。在獲得失敗行後，兩個代理都可以跨多個軌跡進行抽象。例如，在命名實體識別任務中，代理識別出過度抽取、實體邊界混淆、錯誤分類等故障模式。

此外，編碼代理還會發現錯誤——不僅是“模型在這一類上出錯”，而是“模擬器在測試時行為異常”等深層問題。

這些觀察讓我重新考慮專用工具在代理優化日益自動化背景下的作用和形態。這也是我啓動一個名為“harness attribution”的項目的原因；本文是其首次探索。