1500 個(gè) PR、0 人寫(xiě)代碼：Codex 驅(qū)動(dòng)的百萬(wàn)行級(jí)內(nèi)部產(chǎn)品實(shí)踐

作者 | Ryan Lopopolo

譯者 | 田橙

策劃 | Tina

在過(guò)去的五個(gè)月里，我們團(tuán)隊(duì)進(jìn)行了一項(xiàng)挑戰(zhàn)：開(kāi)發(fā)并發(fā)布一款完全沒(méi)有人工編寫(xiě)代碼的內(nèi)部測(cè)試產(chǎn)品。

目前，該產(chǎn)品已經(jīng)擁有內(nèi)部日活用戶(hù)和外部 Alpha 測(cè)試人員。它在真實(shí)的開(kāi)發(fā)環(huán)境中運(yùn)行、部署、報(bào)錯(cuò)并接受修復(fù)。其獨(dú)特之處在于，從應(yīng)用邏輯到測(cè)試腳本，再到 CI 配置、文檔、可觀(guān)測(cè)性及內(nèi)部工具，每一行代碼都出自 Codex 之手。據(jù)我們估算，這種開(kāi)發(fā)模式的效率極高，耗時(shí)僅為手動(dòng)開(kāi)發(fā)代碼的 10%。

人類(lèi)掌舵，Agent 執(zhí)行。

我們特意設(shè)定了這個(gè)限制，就是想看看工程效能能否實(shí)現(xiàn)量級(jí)上的突破。當(dāng)時(shí)我們需要在短短幾周內(nèi)交付上百萬(wàn)行代碼，這迫使我們必須重新思考：如果工程師不再把“寫(xiě)代碼”當(dāng)成主業(yè)，而是轉(zhuǎn)去設(shè)計(jì)環(huán)境、定義意圖并構(gòu)建反饋循環(huán)，好讓 Codex Agent 產(chǎn)出可靠的成果，那么研發(fā)模式到底會(huì)發(fā)生什么變化？

在這篇文章中，我們將分享通過(guò) Agent 團(tuán)隊(duì)構(gòu)建全新產(chǎn)品的心得，包括哪些嘗試失敗了，哪些產(chǎn)生了復(fù)利效應(yīng)，以及如何最大化利用我們最寶貴的資源：人類(lèi)的時(shí)間與注意力。

從空倉(cāng)庫(kù)起步

2025 年 8 月底，我們向這個(gè)空倉(cāng)庫(kù)提交了第一次 Commit。

初始腳手架由 Codex CLI 調(diào)用 GPT-5 生成，并輔以少量現(xiàn)有模板作為引導(dǎo)，涵蓋了倉(cāng)庫(kù)結(jié)構(gòu)、CI 配置、格式化規(guī)則、包管理器設(shè)置以及應(yīng)用框架。甚至連指導(dǎo) Agent 如何在倉(cāng)庫(kù)中工作的初始 AGENTS.md 文件，也是由 Codex 親筆完成。

這里沒(méi)有任何預(yù)存的人工代碼來(lái)作為系統(tǒng)的“錨點(diǎn)”。從一開(kāi)始，整個(gè)倉(cāng)庫(kù)的形態(tài)就是由 Agent 塑造的。

五個(gè)月后，該倉(cāng)庫(kù)已擁有約 100 萬(wàn)行代碼，涵蓋應(yīng)用邏輯、基礎(chǔ)設(shè)施、工具鏈、文檔和內(nèi)部開(kāi)發(fā)組件。在此期間，一支僅有 3 名工程師的小團(tuán)隊(duì)驅(qū)動(dòng) Codex 開(kāi)啟并合并了約 1500 個(gè) PR。這意味著平均每位工程師每天產(chǎn)出 3.5 個(gè) PR。令人驚訝的是，隨著團(tuán)隊(duì)擴(kuò)大到 7 人，人均產(chǎn)出率反而進(jìn)一步提升。

更重要的是，這并非為了刷量而產(chǎn)出：該產(chǎn)品已被數(shù)百名內(nèi)部用戶(hù)使用，其中包括每天重度使用的核心用戶(hù)。在整個(gè)開(kāi)發(fā)過(guò)程中，人類(lèi)從未直接貢獻(xiàn)過(guò)任何一行代碼。這成了團(tuán)隊(duì)的核心哲學(xué)：拒絕人工編寫(xiě)代碼。

重新定義工程師的角色

由于不再親自動(dòng)手寫(xiě)代碼，工程師的工作重心轉(zhuǎn)向了系統(tǒng)設(shè)計(jì)、腳手架搭建和杠桿效能。

早期的進(jìn)展比預(yù)期要慢，這并非因?yàn)?Codex 能力不足，而是因?yàn)榄h(huán)境的“規(guī)范度”不夠。Agent 缺乏實(shí)現(xiàn)高層目標(biāo)所需的工具、抽象和內(nèi)部結(jié)構(gòu)。于是，工程團(tuán)隊(duì)的首要任務(wù)變成了：賦能 Agent 開(kāi)展有效工作。

在實(shí)踐中，這意味著采用深度優(yōu)先的工作方式：將宏大目標(biāo)拆解為微小的構(gòu)建塊（設(shè)計(jì)、代碼、評(píng)審、測(cè)試等）。驅(qū)動(dòng) Agent 構(gòu)建這些塊。利用這些已有的塊去解鎖更復(fù)雜的任務(wù)。當(dāng)任務(wù)失敗時(shí)，修復(fù)方案幾乎從不是“再試一次”。因?yàn)楸仨毻ㄟ^(guò) Codex 來(lái)推進(jìn)工作，人類(lèi)工程師會(huì)介入并思考：“缺失了什么能力？我們?nèi)绾巫屵@種能力對(duì) Agent 而言既清晰可見(jiàn)又強(qiáng)制執(zhí)行？”

人類(lèi)與系統(tǒng)的交互幾乎完全通過(guò) 提示詞 完成：工程師描述一項(xiàng)任務(wù)，運(yùn)行 Agent，并授權(quán)其開(kāi)啟一個(gè) Pull Request。為了推進(jìn) PR 最終合入，我們會(huì)指示 Codex 在本地審查自己的代碼改動(dòng)，并請(qǐng)求其他特定的 Agent（無(wú)論是在本地還是云端）進(jìn)行交叉評(píng)審。Codex 會(huì)根據(jù)人類(lèi)或 Agent 給出的反饋進(jìn)行響應(yīng)，并在循環(huán)中不斷迭代，直到所有 Agent 評(píng)審員都感到滿(mǎn)意——這實(shí)際上形成了一個(gè)所謂的 “拉爾夫·維格姆循環(huán)”（Ralph Wiggum Loop）【見(jiàn)譯注】。Codex 直接調(diào)用我們的標(biāo)準(zhǔn)開(kāi)發(fā)工具（如 GitHub CLI gh、本地腳本以及集成在倉(cāng)庫(kù)中的技能），自主獲取上下文，無(wú)需人類(lèi)手動(dòng)在命令行中復(fù)制粘貼。

譯注：Ralph Wiggum Loop：這是一個(gè)來(lái)自《辛普森一家》的梗（那個(gè)坐在教室后面自言自語(yǔ)的小男孩），在軟件工程語(yǔ)境下，通常指代一種“自給自足、閉環(huán)且?guī)в心撤N幽默色彩的自推導(dǎo)循環(huán)”。

雖然人類(lèi)可以審查 PR，但這并非強(qiáng)制要求。隨著時(shí)間的推移，我們已將幾乎所有的評(píng)審工作都交給了 “Agent 對(duì) Agent” 的協(xié)作模式。

增加應(yīng)用的“可讀性”

隨著代碼產(chǎn)出率的提升，我們的瓶頸變成了人類(lèi)的 QA 能力。由于人類(lèi)的時(shí)間和注意力始終是唯一的稀缺資源，我們致力于通過(guò)讓?xiě)?yīng)用 UI、日志和指標(biāo)對(duì) Codex 直接可見(jiàn)且可理解，從而為 Agent 增加更多能力。

例如，我們使應(yīng)用能夠針對(duì)每個(gè) Git 工作樹(shù)（worktree）獨(dú)立啟動(dòng)，這樣 Codex 就可以為每一次代碼變更運(yùn)行并驅(qū)動(dòng)一個(gè)實(shí)例。我們還將 Chrome DevTools Protocol 接入 Agent 運(yùn)行時(shí)，并創(chuàng)建了處理 DOM 快照、截圖和導(dǎo)航的技能。這使得 Codex 能夠直接復(fù)現(xiàn) Bug、驗(yàn)證修復(fù)結(jié)果并推導(dǎo) UI 行為。

我們對(duì)可觀(guān)測(cè)性工具也做了同樣的處理。日志、指標(biāo)和鏈路追蹤通過(guò)一個(gè)本地的可觀(guān)測(cè)性棧暴露給 Codex，這個(gè)棧對(duì)于任何給定的工作樹(shù)來(lái)說(shuō)都是臨時(shí)的。Codex 運(yùn)行在該應(yīng)用的一個(gè)完全隔離的版本上，包括其日志和指標(biāo)，這些內(nèi)容會(huì)在任務(wù)完成后被銷(xiāo)毀。Agent 可以使用 LogQL 查詢(xún)?nèi)罩荆褂?PromQL 查詢(xún)指標(biāo)。有了這些上下文，諸如“確保服務(wù)啟動(dòng)在 800ms 內(nèi)完成”或“這四個(gè)關(guān)鍵用戶(hù)旅程中沒(méi)有任何 Trace Span 超過(guò) 2 秒”之類(lèi)的提示詞，就變得具有可操作性了。

我們經(jīng)常看到單次 Codex 運(yùn)行持續(xù)處理一個(gè)任務(wù)超過(guò) 6 小時(shí)（通常是在人類(lèi)睡覺(jué)的時(shí)候）。

以倉(cāng)庫(kù)知識(shí)作為“事實(shí)來(lái)源”

上下文管理是讓 Agent 處理復(fù)雜任務(wù)的最大挑戰(zhàn)之一。我們學(xué)到的核心教訓(xùn)是：給 Codex 一張地圖，而不是一本千頁(yè)的使用手冊(cè)。

我們?cè)鴩L試過(guò)“單一 AGENTS.md 大文件”方案，但很快就失敗了：1. 上下文是稀缺資源：巨大的指令文件會(huì)擠占任務(wù)代碼和相關(guān)文檔的空間。這會(huì)導(dǎo)致 Agent 要么遺漏關(guān)鍵約束，要么開(kāi)始針對(duì)錯(cuò)誤的目標(biāo)進(jìn)行優(yōu)化。2. 引導(dǎo)過(guò)度等于沒(méi)有引導(dǎo)：當(dāng)所有內(nèi)容都被標(biāo)榜為“重要”時(shí)，就失去了重點(diǎn)。Agent 最終只會(huì)進(jìn)行局部的模式匹配，而無(wú)法有目的地理解全局。3. 文檔極易腐化：?jiǎn)误w式的手冊(cè)很快就會(huì)變成陳舊規(guī)則的墳場(chǎng)。Agent 無(wú)法判斷哪些規(guī)則依然有效，人類(lèi)也懶得維護(hù)，結(jié)果這份文件反而成了誤導(dǎo) Agent 的誘餌。4. 難以驗(yàn)證：這種單一的大塊內(nèi)容無(wú)法進(jìn)行機(jī)械化檢查（如覆蓋率、時(shí)效性、歸屬權(quán)或交叉鏈接），架構(gòu)偏離也就成了必然。

因此，我們將 AGENTS.md 視為目錄而非百科全書(shū)。

代碼庫(kù)的知識(shí)庫(kù)存在于一個(gè)結(jié)構(gòu)化的 docs/ 目錄中，并被視為唯一事實(shí)來(lái)源。一份簡(jiǎn)短的 AGENTS.md（約 100 行）被注入到上下文中，它主要充當(dāng)?shù)貓D的角色，包含指向分布在各處的更深層“事實(shí)來(lái)源”的指針。

└── SECURITY.md

設(shè)計(jì)文檔被編目并索引，其中包含驗(yàn)證狀態(tài)以及一套定義了“Agent 優(yōu)先”運(yùn)營(yíng)原則的核心信條。架構(gòu)文檔提供了一個(gè)關(guān)于領(lǐng)域劃分和包分層的頂級(jí)地圖。一份質(zhì)量文檔則會(huì)對(duì)每個(gè)產(chǎn)品領(lǐng)域和架構(gòu)層級(jí)進(jìn)行評(píng)分，并長(zhǎng)期跟蹤其中的差距。

計(jì)劃（Plans）被視為一等公民。臨時(shí)性的輕量計(jì)劃用于微小的變更，而復(fù)雜的工作則會(huì)被記錄在執(zhí)行計(jì)劃中，連同進(jìn)度和決策日志一起提交到倉(cāng)庫(kù)。活躍計(jì)劃、已完成計(jì)劃以及已知的技術(shù)債都會(huì)進(jìn)行版本化管理并放在一起，使 Agent 能夠無(wú)需依賴(lài)外部上下文即可開(kāi)展工作。

這實(shí)現(xiàn)了漸進(jìn)式披露：Agent 從一個(gè)微小、穩(wěn)定的入口點(diǎn)開(kāi)始，并被告知下一步該去哪里尋找信息，而不是預(yù)先就被海量信息所淹沒(méi)。

我們通過(guò)機(jī)械化手段強(qiáng)制執(zhí)行這一點(diǎn)。專(zhuān)門(mén)的 Linter 和 CI 任務(wù)會(huì)驗(yàn)證知識(shí)庫(kù)是否處于最新?tīng)顟B(tài)、是否正確進(jìn)行了交叉引用以及結(jié)構(gòu)是否合規(guī)。一個(gè)循環(huán)運(yùn)行的“文檔園丁”Agent 會(huì)掃描那些無(wú)法反映真實(shí)代碼行為的陳舊或過(guò)時(shí)文檔，并開(kāi)啟修復(fù)類(lèi) PR。

以“Agent 可讀性”為目標(biāo)

隨著代碼庫(kù)的演進(jìn)，Codex 的設(shè)計(jì)決策框架也隨之進(jìn)化。

由于整個(gè)倉(cāng)庫(kù)完全由 Agent 生成，它首先針對(duì) Codex 的可讀性 進(jìn)行了優(yōu)化。正如開(kāi)發(fā)團(tuán)隊(duì)致力于為新入職工程師提高代碼的可導(dǎo)航性一樣，我們?nèi)祟?lèi)工程師的目標(biāo)是讓 Agent 能夠直接從倉(cāng)庫(kù)本身推導(dǎo)并理解完整的業(yè)務(wù)領(lǐng)域知識(shí)。

從 Agent 的視角來(lái)看，任何在運(yùn)行時(shí)無(wú)法通過(guò)上下文獲取的信息，實(shí)際上都不存在。存儲(chǔ)在 Google Docs、聊天記錄或存在于人們大腦中的知識(shí)，系統(tǒng)是無(wú)法訪(fǎng)問(wèn)的。只有倉(cāng)庫(kù)本地的、版本化的工件（如代碼、Markdown、Schema、可執(zhí)行計(jì)劃）才是它可見(jiàn)的全部世界。

我們意識(shí)到，隨著時(shí)間的推移，我們需要將越來(lái)越多的上下文推入倉(cāng)庫(kù)。比如那次讓團(tuán)隊(duì)在架構(gòu)模式上達(dá)成一致的 Slack 討論，如果它對(duì) Agent 來(lái)說(shuō)是不可檢索的，那么它就是“不可讀”的——就像對(duì)于三個(gè)月后入職的新員工來(lái)說(shuō)，這段背景是缺失的一樣。

賦予 Codex 更多上下文，意味著需要組織并暴露正確的信息，以便 Agent 進(jìn)行推理，而不是用大量的臨時(shí)指令讓它不堪重負(fù)。就像你會(huì)向新隊(duì)友介紹產(chǎn)品原則、工程規(guī)范和團(tuán)隊(duì)文化（甚至包括表情符號(hào)的使用偏好）一樣，向 Agent 提供這些信息會(huì)帶來(lái)更加一致的產(chǎn)出。

這種思路讓許多權(quán)衡變得清晰。我們更青睞那些可以被完全內(nèi)化并在倉(cāng)庫(kù)內(nèi)進(jìn)行推理的依賴(lài)項(xiàng)和抽象。那些通常被稱(chēng)為“乏味”的技術(shù)，往往因?yàn)槠浣M合性、API 穩(wěn)定性和在訓(xùn)練集中的高覆蓋率，更容易被 Agent 建模。在某些情況下，讓 Agent 重新實(shí)現(xiàn)一部分功能，比繞過(guò)公共庫(kù)中不透明的上層行為成本更低。例如，我們沒(méi)有引入通用的 p-limit 風(fēng)格的包，而是實(shí)現(xiàn)了自己的并發(fā)映射助手：它與我們的 OpenTelemetry 監(jiān)控緊密集成，擁有 100% 的測(cè)試覆蓋率，并且完全符合我們運(yùn)行時(shí)的預(yù)期。

將系統(tǒng)的更多部分轉(zhuǎn)化為 Agent 可以直接檢查、驗(yàn)證和修改的形式，不僅提升了 Codex 的杠桿效能，也同樣造福了其他在同一代碼庫(kù)中工作的 Agent（例如 Aardvark）。

強(qiáng)制執(zhí)行架構(gòu)與審美

僅靠文檔不足以保持一個(gè)完全由 Agent 生成的代碼庫(kù)的連貫性。通過(guò)強(qiáng)制執(zhí)行“不變量”而非微觀(guān)管理實(shí)現(xiàn)細(xì)節(jié)，我們讓 Agent 在快速交付的同時(shí)，不破壞系統(tǒng)的根基。例如，我們要求 Codex 在系統(tǒng)邊界處必須進(jìn)行數(shù)據(jù)格式解析，但并不強(qiáng)制規(guī)定實(shí)現(xiàn)方式（模型似乎偏好 Zod，但我們從未指定過(guò)這個(gè)特定的庫(kù)）。

Agent 在邊界嚴(yán)格且結(jié)構(gòu)可預(yù)測(cè)的環(huán)境中效率最高。因此，我們圍繞一套僵化的架構(gòu)模型構(gòu)建了應(yīng)用。每個(gè)業(yè)務(wù)領(lǐng)域被劃分為一組固定的層級(jí)，擁有嚴(yán)格驗(yàn)證的依賴(lài)方向和有限的允許連接點(diǎn)。這些約束通過(guò)自定義 Linter（當(dāng)然也是 Codex 生成的！）和結(jié)構(gòu)化測(cè)試進(jìn)行機(jī)械化強(qiáng)制執(zhí)行。

下圖展示了這一規(guī)則：在每個(gè)業(yè)務(wù)領(lǐng)域（如“應(yīng)用設(shè)置”）內(nèi)，代碼只能沿著一組固定的層級(jí)“向前”依賴(lài)（類(lèi)型定義 → 配置 → 倉(cāng)庫(kù)層 → 服務(wù)層 → 運(yùn)行時(shí) → UI）。跨領(lǐng)域關(guān)注點(diǎn)（如認(rèn)證、連接器、遙測(cè)、特性開(kāi)關(guān)）通過(guò)單一且明確的接口進(jìn)入：提供者（Providers）。除此之外的任何依賴(lài)都是被禁止的，并由機(jī)械化手段強(qiáng)制執(zhí)行。

這種架構(gòu)通常是在擁有數(shù)百名工程師后才會(huì)考慮推行的。但在使用編程 Agent 時(shí)，它是前置的必要條件：正是這些約束，才使得系統(tǒng)在高速迭代的同時(shí)，不會(huì)出現(xiàn)腐化或架構(gòu)偏離。

在實(shí)踐中，我們通過(guò)自定義 Linter、結(jié)構(gòu)化測(cè)試以及一小套“審美不變量”來(lái)執(zhí)行這些規(guī)則。例如，我們通過(guò)靜態(tài)檢查強(qiáng)制要求：結(jié)構(gòu)化日志記錄、架構(gòu)和類(lèi)型的命名規(guī)范、文件大小限制，以及針對(duì)特定平臺(tái)的可靠性要求。由于 Linter 是自定義的，我們可以編寫(xiě)專(zhuān)門(mén)的錯(cuò)誤信息，以便將修復(fù)指令直接注入到 Agent 的上下文中。

在以人類(lèi)為中心的工作流中，這些規(guī)則可能顯得過(guò)于死板或受限。但在 Agent 環(huán)境下，它們變成了效能倍增器：規(guī)則一旦被編碼，就會(huì)立即應(yīng)用于所有地方。

與此同時(shí)，我們明確區(qū)分了哪些地方需要約束，哪些地方不需要。這非常像領(lǐng)導(dǎo)一個(gè)大型工程平臺(tái)組織：中央強(qiáng)制執(zhí)行邊界，地方允許自主。 你需要極度關(guān)注邊界、正確性和可復(fù)現(xiàn)性；而在這些邊界之內(nèi)，你允許團(tuán)隊(duì)（或 Agent）在表達(dá)解決方案時(shí)擁有極大的自由。

最終生成的代碼并不總是符合人類(lèi)的審美偏好，但這沒(méi)關(guān)系。只要產(chǎn)出是正確的、可維護(hù)的，并且對(duì)未來(lái)的 Agent 運(yùn)行而言是可理解的，它就達(dá)到了標(biāo)準(zhǔn)。

人類(lèi)的審美會(huì)持續(xù)反饋到系統(tǒng)中。評(píng)審評(píng)論、重構(gòu) PR 以及面向用戶(hù)的 Bug 都會(huì)被轉(zhuǎn)化為文檔更新，或直接編碼進(jìn)工具鏈。當(dāng)文檔不足以約束行為時(shí)，我們就將規(guī)則晉升為代碼。

吞吐量的提升改變了合并哲學(xué)

隨著 Codex 吞吐量的增加，許多傳統(tǒng)的工程規(guī)范反而變得適得其反。

倉(cāng)庫(kù)運(yùn)行時(shí)的阻塞性合并門(mén)檻極低。Pull Request 的生命周期非常短。對(duì)于測(cè)試偶發(fā)失敗，通常通過(guò)后續(xù)運(yùn)行來(lái)解決，而不是無(wú)限期地阻塞進(jìn)度。在一個(gè) Agent 吞吐量遠(yuǎn)超人類(lèi)注意力的系統(tǒng)中，糾錯(cuò)是廉價(jià)的，而等待是昂貴的。

在低吞吐量的傳統(tǒng)環(huán)境中，這樣做是不負(fù)責(zé)任的；但在這里，這通常是正確的權(quán)衡。

“Agent 生成”的真正含義

當(dāng)我們說(shuō)代碼庫(kù)是由 Codex Agent 生成時(shí)，我們指的是代碼庫(kù)中的一切。

Agent 產(chǎn)出的內(nèi)容包括：- 產(chǎn)品代碼與測(cè)試腳本 - CI 配置與發(fā)布工具 - 內(nèi)部開(kāi)發(fā)者工具 - 文檔與設(shè)計(jì)歷史 - 評(píng)估框架（Evaluation harnesses）- 評(píng)審評(píng)論及回復(fù) - 管理倉(cāng)庫(kù)本身的腳本 - 生產(chǎn)環(huán)境儀表盤(pán)的定義文件

人類(lèi)依然掌控全局，只是工作的抽象層級(jí)變了。我們現(xiàn)在的任務(wù)是排列優(yōu)先級(jí)、把用戶(hù)反饋轉(zhuǎn)化為驗(yàn)收標(biāo)準(zhǔn)，并最終對(duì)結(jié)果進(jìn)行把關(guān)。一旦 Agent 開(kāi)發(fā)受阻，這就是一個(gè)明確的信號(hào)，提醒我們要去復(fù)盤(pán)：系統(tǒng)里到底缺了什么？是工具不夠，護(hù)欄不穩(wěn)，還是文檔有誤？找到癥結(jié)后，我們會(huì)把這些反饋?zhàn)⑷雮}(cāng)庫(kù)，但依然堅(jiān)持讓 Codex 自己動(dòng)手來(lái)編寫(xiě)修復(fù)方案。

Agent 直接使用我們的標(biāo)準(zhǔn)開(kāi)發(fā)工具。它們獲取評(píng)審反饋、進(jìn)行行內(nèi)回復(fù)、推送更新，并且通常會(huì)自主壓縮（Squash）并合并自己的 PR。

持續(xù)提升的自主化水平

隨著越來(lái)越多的開(kāi)發(fā)環(huán)路（測(cè)試、驗(yàn)證、評(píng)審、反饋處理及故障恢復(fù)）被直接編碼進(jìn)系統(tǒng)中，該倉(cāng)庫(kù)最近跨越了一個(gè)具有里程碑意義的門(mén)檻：Codex 已經(jīng)能夠端到端地驅(qū)動(dòng)新特性的開(kāi)發(fā)。

僅需一段提示詞，Agent 現(xiàn)在就可以自主完成以下流程：- 驗(yàn)證代碼庫(kù)的當(dāng)前狀態(tài) - 復(fù)現(xiàn)報(bào)告的 Bug- 錄制一段展示故障過(guò)程的視頻 - 實(shí)現(xiàn)修復(fù)方案 - 通過(guò)操作應(yīng)用來(lái)驗(yàn)證修復(fù)結(jié)果 - 錄制第二段展示修復(fù)效果的視頻 - 開(kāi)啟 Pull Request- 響應(yīng) Agent 及人類(lèi)的反饋 - 檢測(cè)并修復(fù)構(gòu)建失敗 - 僅在需要人類(lèi)判斷時(shí)才上報(bào) - 合并變更

這種行為極度依賴(lài)于本倉(cāng)庫(kù)特定的結(jié)構(gòu)和工具鏈。在沒(méi)有類(lèi)似投入的情況下，不應(yīng)假設(shè)這種能力可以被直接泛化，至少目前還不行。

熵增與垃圾回收

完全的 Agent 自主權(quán)也帶來(lái)了全新的挑戰(zhàn)。Codex 會(huì)復(fù)制倉(cāng)庫(kù)中已有的模式——即便是那些不均衡或非最優(yōu)的模式。 隨著時(shí)間的推移，這不可避免地會(huì)導(dǎo)致架構(gòu)偏離。

最初，人類(lèi)通過(guò)手動(dòng)方式解決這個(gè)問(wèn)題。我們的團(tuán)隊(duì)曾固定在每周五（占一周工作時(shí)間的 20%）清理“AI 廢料”。不出所料，這種模式根本無(wú)法擴(kuò)展。

針對(duì)這些問(wèn)題，我們選擇將所謂的“金科玉律”直接寫(xiě)入代碼倉(cāng)庫(kù)，并建立了一套周期性的清理機(jī)制。這些原則是一些帶有明確主張的機(jī)械化規(guī)則，目的是確保代碼庫(kù)在后續(xù)的 Agent 運(yùn)行中始終保持清晰、一致。具體實(shí)踐包括：第一，我們更傾向于使用共享的工具包，而不是手寫(xiě)輔助函數(shù)，這樣可以集中管理那些不變量；第二，我們拒絕“全憑運(yùn)氣”的數(shù)據(jù)探測(cè)，必須在邊界處進(jìn)行校驗(yàn)，或者依賴(lài)強(qiáng)類(lèi)型 SDK，防止 Agent 采樣猜測(cè)的數(shù)據(jù)形狀來(lái)編寫(xiě)代碼。我們會(huì)定期運(yùn)行一組 Codex 后臺(tái)任務(wù)，專(zhuān)門(mén)掃描偏離規(guī)則的代碼，更新質(zhì)量評(píng)分并開(kāi)啟針對(duì)性的重構(gòu) PR。由于這些規(guī)則非常明確，大部分 PR 在一分鐘內(nèi)就能完成評(píng)審并自動(dòng)合并。

這種機(jī)制運(yùn)行起來(lái)就像“垃圾回收”。技術(shù)債就像高利貸：連續(xù)進(jìn)行小額償還，幾乎總是優(yōu)于讓其復(fù)滾并最終在痛苦的爆發(fā)式清理中解決。人類(lèi)的審美被捕獲一次后，便會(huì)持續(xù)強(qiáng)制執(zhí)行到每一行代碼中。這還讓我們能夠在日常工作中及時(shí)發(fā)現(xiàn)并消除不良模式，而不是任由它們?cè)诖a庫(kù)中蔓延數(shù)天甚至數(shù)周。

我們?nèi)栽谔剿鞯念I(lǐng)域

到目前為止，這套策略在 OpenAI 內(nèi)部產(chǎn)品的發(fā)布和推廣中表現(xiàn)良好。通過(guò)為真實(shí)用戶(hù)構(gòu)建真實(shí)產(chǎn)品，我們的投入得以為現(xiàn)實(shí)需求服務(wù)，并引導(dǎo)系統(tǒng)走向長(zhǎng)期可維護(hù)。

目前我們尚不清楚，在一個(gè)完全由 Agent 生成的系統(tǒng)中，其架構(gòu)連貫性在長(zhǎng)達(dá)數(shù)年的跨度下會(huì)如何演進(jìn)。我們?nèi)栽诿魅祟?lèi)判斷力在何處能產(chǎn)生最大的杠桿效應(yīng)，以及如何將這種判斷力轉(zhuǎn)化為可沉淀、可產(chǎn)生復(fù)利的規(guī)則。同時(shí)，隨著模型能力持續(xù)增強(qiáng)，這套系統(tǒng)將如何進(jìn)化也仍是未知數(shù)。

但有一點(diǎn)已經(jīng)非常明確：構(gòu)建軟件仍然需要嚴(yán)謹(jǐn)?shù)募o(jì)律，只不過(guò)這種紀(jì)律不再體現(xiàn)在代碼編寫(xiě)上，而是體現(xiàn)在“腳手架”的搭建上。那些能保持代碼庫(kù)連貫性的工具鏈、抽象層和反饋循環(huán)，正變得愈發(fā)重要。

我們現(xiàn)在面臨的最艱巨挑戰(zhàn)在于如何設(shè)計(jì)環(huán)境、反饋循環(huán)和控制系統(tǒng)。唯有如此，才能幫助 Agent 達(dá)成我們的目標(biāo)，即大規(guī)模地構(gòu)建并維護(hù)復(fù)雜且可靠的軟件。

隨著 Codex 等 Agent 承擔(dān)起軟件生命周期中越來(lái)越多的份額，這些問(wèn)題將變得至關(guān)重要。希望這些早期教訓(xùn)能幫助你思考該在何處投入精力，從而讓你能更純粹地去創(chuàng)造產(chǎn)品。

https://openai.com/index/harness-engineering/

會(huì)議推薦

2026，AI 正在以更工程化的方式深度融入軟件生產(chǎn)，Agentic AI 的探索也將從局部試點(diǎn)邁向體系化工程建設(shè)！

QCon 北京 2026 已正式啟動(dòng)，本屆大會(huì)以“Agentic AI 時(shí)代的軟件工程重塑”為核心主線(xiàn)，推動(dòng)技術(shù)探索從「AI For What」真正落地到可持續(xù)的「Value From AI」。從前沿技術(shù)雷達(dá)、架構(gòu)設(shè)計(jì)與數(shù)據(jù)底座、效能與成本、產(chǎn)品與交互、可信落地、研發(fā)組織進(jìn)化六大維度，系統(tǒng)性展開(kāi)深度探索。開(kāi)往 2026 的 Agentic AI 專(zhuān)列即將啟程！匯聚頂尖專(zhuān)家實(shí)戰(zhàn)分享，把 AI 能力一次夯到位！

今日薦文

你也「在看」嗎？