全行業都狂卷 Harness，Anthropic 還在加碼，Codex 負責人卻說它正在退場

整理｜冬梅

編輯｜Tina

今年年初，OpenAI 的架構師 Bill Chen 和 Brian Fioca 在一期演講里詳細介紹了 Codex 構建過程中克服的挑戰，以及 Coding Agent 本身一些新興的使用模式。談及 Coding Agent 的構成時介紹其由三部分組成：用戶界面、模型和Harness。

用戶界面顯而易見，可能是命令行工具，也可能是集成開發環境，或者是云端或后臺 Agent。模型也很直白，比如 OpenAI 的 GPT-5.1 系列模型或其他一些供應商的模型。至于 Harness，這是一個稍微復雜一點的部分，它直接與模型交互，最簡化地說，可以將其看作是由一系列提示和工具組合而成的核心 Agent 循環，它為模型提供輸入和輸出。

Harness 是模型的接口層，它是模型與用戶、代碼之間進行交互的媒介。它包括了模型需要的所有組件，以便在多輪對話中進行工作，調用工具，并最終為你編寫代碼，解讀用戶的需求。對一些產品來說，Harness 可能是其中的關鍵部分。

Anthropic 前幾日也發布了一篇博客文章，名為《Harness design for long-running application development》（長時運行應用開發的 Harness Design），文中提到Harness指的是一種支撐復雜 AI 智能體（Agent）運行的外部框架、控制結構與編排系統。它不是單一的算法，而是一整套工程化的“腳手架”，用于管理和放大 AI 的能力。

它是 Prompt Engineering（提示詞工程）之上的更高級抽象。Prompt 決定了單次對話的質量，而 Harness 決定了多輪、多智能體、長時任務的執行流程和可靠性。

Harness 的核心作用是解決 AI 在完成復雜、耗時任務時的“失控”問題（Go off the rails），通過外部控制機制彌補模型內在的缺陷（如上下文焦慮、自我美化）。

無論是 OpenAI 還是 Anthropic，都明確認定 Harness 是 Coding Agent 落地的關鍵，但兩家頂級巨頭的分歧在于，該把 Harness 做強做厚，還是做薄做輕？

Harness 該做大還是縮小？

行業內部也似乎正在形成一種新的共識：決定 AI 編程上限的，不再是模型本身的單次生成能力，而是 Harness Engineering。

在 Anthropic 最近的工程文章展示了他們對 Long-running Agent（長時運行智能體） 的深度探索。為了解決 AI 在長時間任務中“脫軌”的問題，他們構建了一套極其嚴密的 Harness：

• 結構化交接（Structured Handoff）： 強制 AI 在上下文耗盡前生成“進度文件”，將狀態外置。

• 多智能體協作： 引入 Planner（規劃器）、Generator（生成器）、Evaluator（評估器）分工。

• 上下文重置機制： 為了避免“上下文焦慮”，直接清空對話歷史，僅保留結構化產物，給新智能體一張“白板”。

這種思路的本質是“把 Harness 做強、做厚”。他們認為，只要框架足夠健壯，就能撐起最復雜的任務。

但近日，OpenAI Codex 開源負責人 Michael Bolin 做客了一檔訪談欄目，釋放出了與 Anthropic 把 Harness 做厚做強相反的信號。

這場對話圍繞“AI 編碼時代，真正改變軟件開發范式的究竟是“大模型本身”，還是圍繞模型構建的 harness？”這一話題展開。

在訪談中，Michael 認為，Harness 不應該無限膨脹。

Michael 根據 Codex 的構建理念闡述了一個他們看到的重要趨勢：理想狀態下，harness 應該“盡可能小”，而模型應“盡可能強”。Codex 的設計理念就是減少工具數量、避免過度干預，讓模型在更接近真實計算環境（如終端）的空間中自主探索解決路徑。這種“AGI 導向”的思路，本質上是在減少人為規則對模型的束縛，把更多決策權交還給模型本身。但 Michael 也提到，在這一過程中，安全（security）和隔離（sandboxing）成為不可妥協的底線，也是 harness 不可替代的核心職責。

Codex 的理念更傾向于“把 Harness 做薄、做輕”，具體表現在以下幾點：

• 最小化工具依賴：甚至刻意減少專用工具，轉而讓模型直接使用通用的終端（Terminal）。

• 環境而非框架：Harness 僅提供必要的沙箱（Sandbox）安全環境和基礎接口，不做過多的流程控制。

• 能力回歸模型：探索、決策和執行的邏輯，盡量交給模型自身去學習，而不是由外部的編排框架硬編碼。

這種思路擔心的是，過于復雜的 Harness 反而會把模型“教傻”，或者產生沉重的工程負擔，拖慢迭代速度。

OpenAI 和 Anthropic 的兩種路徑選擇給 AI 從業者帶來一個必須要思考的問題：Harness，到底是 AI Coding 的終局，還是一個正在被快速放大的中間態？

因為這個問題的答案決定了未來的產品形態：

如果 Harness 是終局：那么未來的競爭將是“框架之戰”。誰擁有最強健、最通用的 Harness（如 Anthropic 展示的多智能體架構），誰就能統治開發流程。AI 編程將演變為“系統工程 + AI”。

如果 Harness 是中間態：那么現在的復雜框架只是為了彌補當前模型的短板。隨著模型能力的指數級提升（如更強的記憶、更長的上下文、更好的推理），這些復雜的外部編排最終會被模型內化。屆時，Harness 將退化為一個簡單的運行環境（Sandbox），而核心競爭力將再次回歸到基座模型的能力本身。

Michael Bolin 并非傳統意義上的“AI 從業者”。在加入 OpenAI 之前，他曾長期任職于 Google 和 Meta，參與構建開發者工具與基礎設施，主導或參與過 Buck、Nuclide、DotSlash 等項目。

對話內容經由 InfoQ 翻譯及整理，略有刪減：

關于 AI 編碼與 Harness Engineering

主持人：今天很高興邀請到 Michael Bolin。他是 Codex 的負責人。人們通常認為，AI 編碼的核心就是“模型寫代碼”。但很多在構建智能體的團隊認為，真正的變化在于圍繞模型設計環境。你更認同哪一種？

Michael：模型當然會主導整體體驗。但我們發現，在 Harness 這一層仍然有很大的創新空間。這不僅僅是一個研究問題。對我們團隊來說，關鍵在于工程與研究之間的協同——共同開發智能體，確保 harness 能夠讓智能體發揮最佳能力。同時，還要為智能體提供合適的工具，要確保智能體使用的這些工具，在訓練階段就已經被模型“見過并練習過”，這樣在真實產品環境中調用這些工具時，模型不會“陌生”或“出錯”。

主持人：我們來定義一下 harness，以及它為什么變得如此重要。

Michael：harness 有時也被稱為 Agent loop——它負責調用模型、采樣，并提供上下文：我想做什么、有哪些工具可用、下一步該做什么。然后模型返回響應——通常是一個工具調用，比如“我想用這些參數調用這個工具，請告訴我返回結果”。

有些工具很簡單，比如運行一個可執行文件并返回 stdout 和退出碼。我們也做了很多更復雜的工具實驗，比如控制機器、控制用戶的筆記本，更像是一個交互式終端，而不是簡單的命令執行。也可以進行網絡搜索等操作。

對于 Codex 來說，因為它是一個編碼 Agent，而我們非常重視安全和沙箱機制，因此 harness 的核心工作之一就是從模型獲取 shell 命令或計算機操作指令，并確保它們在沙箱中執行，或者遵循用戶設定的策略。這部分其實非常復雜。關鍵是既要釋放模型的全部能力，又要確保在用戶機器上的安全運行。

主持人：在開源 Codex 時，你們是如何處理安全問題的？

Michael：這些實現其實都可以在我們的代碼庫中看到。我們針對不同的操作系統做了不同的處理：在 macOS 上，我們使用了一種叫做 Seatbelt 的技術。在 Linux 上，我們使用了一系列庫——包括 Bubblewrap、seccomp 和 Landlock。在 Windows 上，我們實際上構建了自己的沙箱。其中一些組件，比如 Seatbelt，是 macOS 的一部分，所以它們不在開源代碼庫里——我們就是這么稱呼的。但我們的 Windows 沙箱代碼在開源代碼庫里。我們會協調所有這些調用，確保它們以適當的方式通過沙箱，以適應不同的工具調用。

主持人：所以當別人 fork Codex 時，這些安全規則也都包含在里面了嗎？

Michael：是的，不過這里要區分“security”和“safety”。我剛才說的更多是 security，比如你可以運行工具，但只能訪問特定文件夾。而行業里說的 safety，更多發生在后端——即模型本身是否會提出合適的工具調用。從 harness 的角度來看，它更像是在執行命令，而哪些命令是安全的，是由模型決定的。

所以，如果你 fork Codex 并繼續使用我們的模型，那么你也繼承了這部分安全性。但如果你換了別的模型，情況就不一定了。

Codex 是如何發展的？

主持人：自從你們推出 Codex 以來，它的發展情況如何？

Michael：反響非常好，使用量相比年初增長了大約五倍。我們在 2025 年 4 月作為 o3 和 o4 mini 發布的一部分推出，當時模型在工具調用和指令執行方面還不夠理想。到了 8 月 GPT-5 發布后，我們更新了 CLI，這是一個關鍵轉折點。之后我們推出了 VS Code 插件，用戶增長非常快，甚至超過了 CLI。再后來是今年年初推出的應用，也迅速流行起來。我認為它在很多方面都是真正意義上的首創。

主持人：在你看來，這個應用的創新點是什么？

Michael：開發者歷來大部分時間都花在集成開發環境（IDE）中，。這些都是顯而易見、順理成章的選擇。

開發者通常在 IDE 中工作，所以我們進入 VS Code、JetBrains、Xcode 是很自然的。借助 Codex 應用，我們實際上建立了一個全新的界面。我把它看作“任務控制中心”，可以同時管理多個對話。同時它保留了 IDE 的核心能力，比如查看 diff、使用 Command-J 快捷鍵打開終端，而無需切換到其他窗口。它真正打破了你必須始終將所有代碼都放在眼前的固有觀念。對很多人來說，能夠同時組織和協作多個 Agent 更有價值。這正是我們努力實現的核心功能。

編碼代理如何改變開發者的工作流程

主持人：像 Codex 這樣的編碼代理，會如何改變開發者的日常工作？

Michael：最大的變化是吞吐量。你可以并行推進很多任務。當然，這帶來了一些上下文切換，并不是所有人都喜歡，但如果掌握得好，效率會非常高。

我個人維護著大約五個 Codex 代碼庫的副本，經常在它們之間切換。有時候，我只是在做其他事情的時候注意到一些小問題，然后快速修復一下。而有時候，我需要花一整天的時間，在會議間隙處理 Codex 的一個重大變更。很多人即使只有五分鐘的會議間隙，也會發一條消息，只是為了推動某個任務朝著另一個方向發展。

第二點是，人們正在花更多時間研究如何優化這個工作流程。相對而言，這一切都非常新穎。我應該把一直在做的事情變成一項可復用的技能嗎？我應該把這項技能分享給我的團隊成員嗎？優秀的開發者總是會努力優化他們的內部循環（Inner loop），但這是一個全新的內部循環，每個人都還在摸索中。

第三件備受關注的事情是代碼審查。代碼審查的數量顯著增加，但 Codex 本身也承擔了大量的代碼審查工作，這節省了大量時間。如何最大限度地利用這些資源仍然是一個不斷探索的問題。

主持人：你在最初開發 Codex 時，有沒有遇到什么意想不到的事情？

Michael Bolin：我最大的感受是技術發展太快了。Codex 成立至今還不到一年，考慮到這段時間發生的巨大變化，這真是令人驚嘆。

我們在 2025 年 4 月發布時，那是 o3 和 o4 發布計劃的一部分。當時我們使用了推理模型，但工具調用和指令執行方面還沒有達到我們預期的效果。看到這方面隨著時間的推移而不斷改進，真是令人欣慰。

早期最令人興奮的事情之一就是讓 Codex 自己編寫更多代碼——親眼見證這個過程。比如 agents.md 逐漸成為標準，搭建起框架，讓你能夠構建出優化自身工作流程的工具。這帶來了一種指數級的飛躍，既令人興奮又充滿樂趣。看到同事們真正理解 Codex 并把更多工作轉移到 Codex 上——這真是太棒了。

智能體時代的代碼庫

主持人：當代碼庫是由智能體而不是人類來閱讀時，它應該是什么樣？

Michael：整個智能體編碼之旅中一個有趣的現象是，軟件開發中一些長期以來被認為是最佳實踐的做法，我們卻從未真正實踐過。文檔就是一個例子，測試驅動開發也是如此。人們并非完全忽視它們，但總覺得得不償失。而現在，在智能體優先的世界里，這些變得非常有價值。人們幾乎是在重新發現它們，并且真心實意地重視它們。

例如，想想 agents.md 文件，我們寫在里面的所有內容，我認為也同樣適用于新加入團隊的人——他們需要知道的一切，所有最佳實踐。把這些內容寫下來，既方便了智能體，也方便了你的隊友，這實際上是一種解脫。

也就是說，在 Codex 上，我們自認為已經接受了通用人工智能（AGI）的理念——這意味著智能體應該真正自主決定做什么，而不是我們不斷地向它灌輸指令。與其編寫一份與源代碼并行運行、容易導致重復或不一致的文檔，我們不如讓智能體花時間閱讀代碼并形成自己的判斷。我們會嘗試在 agents.md 文件中添加一些它無法從代碼中快速獲取的信息，例如：如何運行測試，或者哪些測試比哪些測試更重要。但我們盡量避免過度干預，而是讓智能體自行決定最佳的執行路徑。

主持人：你認為在不久的將來，agents.md 會由智能體自己寫嗎？

Michael：很多人已經這么做了，比如在指令中加入“完成后更新 agents.md”。我們團隊沒有強制這樣做，但這是常見做法。

Michael：現在確實有不少人這么做。我看到很多開發者會在自己的提示說明里加上一條類似的要求：任務完成后，順便更新agents.md文件，把過程中值得記錄的內容補充進去——包括那些不那么顯而易見的信息，或者是在和 Codex 協作開發時逐漸發現的經驗。

不過在我們團隊內部，這還沒有成為一項通用規范。你如果去看代碼庫的歷史記錄，也能發現我們并沒有系統性地這么做，但在社區里，這種方式已經比較常見了。

另外，學界也開始討論一個問題：到底應該給智能體提供多少信息才合適。我個人覺得，這很大程度上取決于具體的智能體能力。

在 Codex 的實踐中，我們采取的是一種相對克制的方式——不會寫成幾十頁的詳細說明，而是只保留一些關鍵要點，讓智能體自己去理解和發揮。

Codex 不生成“垃圾”

主持人：Context Engineering 似乎是這個過程中越來越重要的部分。對于智能體來說，會不會出現“上下文過多”的問題？

Michael：從我的經驗而非研究角度來看：對于中等規模的任務，我通常會描述一段代碼，然后讓 Codex 熟悉這部分代碼。有時，如果我認為有幫助，我會提供明確的文件指針，但通常我不會——它自己就能很好地搜索代碼庫。

有一件容易被忽視但卻至關重要的事情：確保文件和文件夾命名規范。這本身就是一種良好的習慣，當 Agent 程序搜索代碼時，這一點顯得更加重要。

大部分上下文信息將來自 agents.md 文件、我編寫的提示以及一些文件引用。我還授予了 Codex 訪問 GitHub 的權限，這樣它就可以查看類似這樣的信息：例如，這個拉取請求中也出現了類似的問題，它不僅可以看到代碼，還可以看到圍繞該拉取請求的討論。但再次強調，這更多的是為了讓 Codex 了解它有哪些選擇——就像是給它提供了工具箱里的工具一樣——而不是規定它應該如何解決問題。這是一個很好的模型，所以它在這方面做得很好。

主持人：聽起來這種工作方式會促使你采用更嚴格的架構。是這樣嗎？

Michael：當然。Codex 會遵循它在代碼庫中發現的模式。如果你一開始就擁有良好的架構，它就會遵循它、維護它，并強制執行你設定的不變式——從長遠來看，你就會處于有利地位。當然，這對人類開發者來說也是如此。只是現在的變化速度要快得多，所以如果你有這些標準，你就能更深刻地感受到它們帶來的好處。

主持人：你是否仍然看到模型和編碼代理中存在大量缺陷？你是如何應對的？

Michael：說實話，我覺得 Codex 里并沒有真正稱得上“糟糕”的東西。我更多地看到的是，這些模型喜歡編寫代碼。所以有時候正確的做法是刪除代碼，你可能需要更明確地說明這一點。但這其實算不上糟糕——更像是：你在這個文件里添加了 500 行代碼，也許你應該新建一個文件。這些都更容易解決。

更常見的情況是，Codex 掌握了我尚未接觸過的習語或語言特征，并加以運用。我因此學到了新東西。這才是 Codex 帶給我驚喜的更多方式——而不是敷衍了事。

模型與 Harness Engineering，
誰更重要？

主持人：你剛才描述的是，Codex 剛起步的時候，模型還不完善。現在模型已經成熟很多，應用本身也吸引了更廣泛的用戶群體。但我想問的是，模型與 Harness Engineering 誰更強大？Harness Engineering 是否會在某個階段不再僅僅是一個封裝層，而成為一個更重要的環境？或者說，模型始終占據主導地位？模型和 harness engineering，在你看來哪個更重要？

Michael Bolin：我明白你的意思，你是想問，有沒有可能出現一種情況，Harness Engineering 逐漸消失，不再發揮太大作用？

在我看來這并非不可能。在很多方面，我們都在努力讓 harness 盡可能小巧、盡可能輕量級。與其他一些智能體相比，Codex 的一個顯著特點是，我們盡量減少智能體擁有的工具。例如，例如 Codex 的工具非常少，沒有專門的讀文件工具，而是讓它使用終端命令。這與我之前提到的“AGI 理念”相呼應：我們給予它廣闊的探索空間，讓它自行找到最佳的運行路徑。

唯一的例外是安全——沙箱是必須的。沙箱機制是防止 Codex 不受控制運行的重要保障。有時，人們會耍點小聰明，試圖通過控制代理來操控上下文窗口。但作為 Codex 的作者，我們想說：“收起你的小聰明，我比你懂得多。” 但我們盡量克制。如果 Codex 即將運行一個會輸出 1GB 數據的工具，我們的想法是：先讓 Codex 將數據寫入文件，然后再用 grep 命令搜索，但要讓它自由選擇如何解決問題。

主持人：你認為有可能將所有這些安全規則、沙盒機制都編碼進去嗎？還是應該始終有人參與其中？

Michael：就我們關注的編碼任務而言，我認為沙盒機制確實是取代人工干預的主要方法，至少對我們大部分的工作來說是這樣。你遇到一個問題，把它交給 Codex，它會在一個受特定方式約束的沙盒環境中運行，讓它在這個空間內探索，就能找到最佳解決方案——尤其是在大規模應用的情況下。我同時運行著五個 Codex 的克隆版本。如果我必須每隔幾分鐘就干預這五個版本，那會從根本上限制它們的吞吐量。

這些糾正措施應該更多地在訓練階段進行，然后在推理階段發揮作用，而不是需要人為干預。

主持人：所以能力更多會在模型里，而不是 harness？

Michael Bolin：是的，模型更重要。但 harness 的可靠性仍然非常重要。如果 harness 崩潰，一切就結束了。隨著我們不可避免地邁向多智能體和子智能體架構——更多智能體在不同機器間通信——harness 不再僅僅是單臺機器上的單個進程，而變成了一個智能體網絡。我預計未來會有很多更有趣的工作要做。我的職業生涯大部分時間都在為開發者編寫工具；現在我正在為智能體編寫更多工具。智能體也可以編寫自己的工具，但正如我所說，我們更傾向于使用少量但功能強大的工具，讓智能體能夠充分探索各種可能性——我們將繼續嘗試，找到最合適的工具組合。

未來 Agent 的發展方向

主持人：你認為智能體編碼的基礎組件有哪些？

Michael：我覺得我們已經看到了很多組成部分。比如我稱之為 shell 工具或終端工具的東西，它讓模型能夠像人一樣使用計算機終端，而不僅僅是直接執行命令。它還包括處理流式輸出并高效利用這些輸出等功能。

記憶是另一個重要領域。過去，每次發起對話都是從零開始——這就是為什么會有 agents.md 以及各種上下文填充機制，以便快速將信息導入模型。如果你查看代碼庫，會發現很多關于記憶的實驗。

此外，不同類型的上下文連接器（context connectors）也正在發生很多變化。最初，我們專注于本地計算機上的計算機任務，但現在它也涵蓋了更廣泛的工作——例如代表您發送電子郵件、創建文檔以及在 Web 瀏覽器中執行操作。

此外，還有標準的 LLM 基礎設施：一般來說，更大的上下文窗口是好事；當達到限制時如何壓縮內容；所有這些都在積極探索中，并有助于提升整體代理體驗。

https://www.youtube.com/watch?v=6BAqgT3qe98

https://www.infoq.cn/article/HFewc09HcZ1IaDyFj8D0

https://www.youtube.com/watch?v=wVl6ZjELpBk

https://www.anthropic.com/engineering/harness-design-long-running-apps

聲明：本文為 InfoQ 整理，不代表平臺觀點，未經許可禁止轉載。

會議推薦

QCon 全球軟件開發大會·2026 北京站將于 4 月 16 日 -18 日正式舉辦。本屆大會以“Agentic AI 時代的軟件工程重塑”為主題，聚焦 100+ 重磅議題，匯聚來自阿里、騰訊、字節跳動、小米、百度等一線科技企業與創新團隊的技術專家，圍繞 AI 工程化、系統架構與研發模式演進展開深入探討。更多詳情可掃碼或聯系票務經理 18514549229 進行咨詢。