編譯｜宇琪

策劃 | Tina

一年前，行業(yè)還在為“從自動補全到 Agent”的進化感到興奮。然而一年過去，我們不難發(fā)現(xiàn)單純靠“Vibe Coding”和“Prompt 調(diào)優(yōu)”，面對非確定性模型帶來的風(fēng)險和成本問題，顯然無法撐起企業(yè)級軟件開發(fā)。

近日，Thoughtworks 的全球 AI 輔助軟件交付負責(zé)人 Birgitta B?ckeler 在 QCon 紐約站進行演講，深度解析了過去一年 Coding Agent 領(lǐng)域的范式轉(zhuǎn)移：從如何通過 Skills 和 Subagents 精準(zhǔn)調(diào)控上下文，到如何在云端實現(xiàn)低監(jiān)督甚至無監(jiān)督的自主開發(fā)，再到最核心的問題：我們?nèi)绾螛?gòu)建一套確定性的 Harness 作為安全網(wǎng)，來約束非確定性的模型產(chǎn)出？基于該演講視頻，InfoQ 對內(nèi)容進行了整理。

核心觀點如下：

• Context Engineering 正在變成一個非常強的“放大器杠桿”，而且這種放大是雙向的：既能放大好的工程實踐，也同樣會放大壞的結(jié)構(gòu)問題。

• 風(fēng)險評估永遠都離不開三個維度：概率、影響、可檢測性。也就是：它出錯的概率有多大？如果出錯，后果有多嚴重？以及你能不能發(fā)現(xiàn)它出了錯？

• 把原本為人類設(shè)計的工程約束系統(tǒng)，改造成 agent 可學(xué)習(xí)、可反饋、可優(yōu)化的系統(tǒng)，這可能才是 Context Engineering 真正開始變得“工程化”的地方。

• 也許未來我們不再靠傳統(tǒng)服務(wù)模板起步，而是一個 Harness 模版，實例化之后就能支撐我們的代碼庫。到那時候，我們可能甚至不在乎到底是 React 還是 Vue，決策維度可能會變成“有沒有現(xiàn)成的 Harness，這樣我就不用操心、不用從頭搭了”。

Context Engineering 的演進

我去年也來過 QCon，當(dāng)時演講題目叫《From Autocomplete to Agents》，主要聊的是當(dāng)時大家剛開始關(guān)注的新 agentic 模式："vibe coding"這個詞大概才出現(xiàn)了兩個月，MCP 正在風(fēng)口上，Claude Code 還在襁褓里。現(xiàn)在我想回頭看看，過去這一年里發(fā)生了什么。

有一件事演進得很快，那就是 Context Engineering。這個詞去年 QCon London 的時候壓根不存在，大概六月才開始流傳起來。最簡單的定義就是：你希望精心篩選你的模型或 agent 能看到的信息，從而獲得更好的結(jié)果。定義聽起來很簡單，但具體到不同場景，比如構(gòu)建 agent，或者使用 coding agent，它會演化出很多不同含義，而今天我主要會從 coding agent 的角度來講。

一年前的 Context Engineering，基本就是 rules files，你在工作區(qū)放一個 AGENTS.md、CLAUDE.md，每次打開會話，agent 就會收到這個文件。常見的坑、老是重復(fù)犯的錯，都可以寫進去。我當(dāng)時有個情況就是 agent 每次跑 Python 進程都忘記激活虛擬環(huán)境，這種事情就可以寫進文件里。MCP servers 那時候也有了，可以幫 agent 更動態(tài)地獲取數(shù)據(jù)。

這一年之間，出現(xiàn)了所有這些東西：不光是 rules 和 MCP servers，還有 commands、skills、subagents、plugins、specs……這個領(lǐng)域非常熱鬧。

我重點講其中一個，因為我覺得很多人對它是困惑的。我去年底休了個假，回來之后發(fā)現(xiàn) skills 出來了，我一開始也完全搞不清楚它到底是什么意思。

Skills

Skills 是 Anthropic 基于社區(qū)里很多已有實踐推出的新概念，主要做三件事。

第一，幫你把 rules 模塊化，你不用把所有東西塞進一個大文件，然后每次全量發(fā)給 agent，而是可以按功能拆成小的子文件夾，比如"這是我們通常構(gòu)建 React 組件的方式"、"這是你從 AWS 測試環(huán)境里拉日志的方法"，都可以分別定義。

第二，這些模塊可以被 LLM 按需即時加載。這種漸進式的、惰性加載的 context 很重要。agent 只會先看到一個 skill 的簡短描述，比如這里有一個 get-log skill，描述可能只是：“從測試環(huán)境獲取日志，用于 incident debugging。”然后，當(dāng) LLM 判斷：“現(xiàn)在這個場景似乎需要這個能力，而且這里還有更多相關(guān)信息”，它才會真正加載這個 skill。這樣一來，你不會在 session 一開始就把 context window 塞爆。

再往下，skill 不只是一個 Markdown 文件。它其實是一個文件夾。里面除了文檔，還可以放腳本，讓 agent 直接執(zhí)行。嚴格來說，這件事以前也能做，但現(xiàn)在越來越多人意識到：你完全可以在 Markdown 里直接告訴 agent 去調(diào)用你機器上已經(jīng)安裝好的 CLI 工具。這種思路出現(xiàn)之后，很多人在 agentic coding 場景里，開始把大量 use case 從 MCP 轉(zhuǎn)移出來，重新關(guān)注：“我電腦上已經(jīng)有哪些 CLI？”“我能不能直接寫腳本讓 agent 調(diào)用？”因為相比再額外維護一種后臺進程，這種方式簡單直接得多。

所謂 Context Engineering，本質(zhì)上是幾件事情的組合。第一，當(dāng)然還是那些可復(fù)用的 instructions 和 conventions。比如怎么寫 React component、怎么 bootstrap 一個新項目、代碼規(guī)范是什么等等。第二，是各種“context interfaces”。比如 skill 的 description、MCP server 暴露的 tool 列表、coding agent 內(nèi)建的 tool 列表。LLM 會基于這些接口判斷：“這個場景里我要調(diào)用哪個 tool？加載哪個 skill？連接哪個 MCP server？”

核心問題其實始終是：你如何讓這些信息被智能地、按需地加載。這里面永遠存在 不確定性，你永遠無法保證 LLM 一定會加載你設(shè)計好的 skill。于是，作為人類開發(fā)者，我的工作開始越來越像“context 管理員”。我要管理 context，也要監(jiān)控 context 的大小。

雖然現(xiàn)在 context window 在技術(shù)上比一兩年前大了很多，但一旦塞得太滿，agent 的效果會明顯下降，而且成本也會大幅上升，因為每次和模型來回交互，都要把整個 context window 發(fā)過去。

現(xiàn)在很多 coding agent 已經(jīng)開始提供 context monitoring 功能，你甚至能看到“到底是什么東西在占空間”。比如左邊這個 Claude Code 的截圖，是我剛開啟 session 不久時截的。明明我還沒輸入多少內(nèi)容，context window 已經(jīng)用了 15%。因為里面已經(jīng)包含了 Claude Code 的 system prompt、skills、各種 context interfaces 等等。所以，當(dāng)你設(shè)計 skills、給 agent 配置能力時，也必須開始思考“上下文預(yù)算”。右邊 GitHub Copilot 現(xiàn)在也開始加入類似功能了。

目前來看，Claude Code 團隊基本還是整個行業(yè)的領(lǐng)跑者，然后其他人再跟著復(fù)制他們做的東西，這算是我對現(xiàn)狀的一個高層總結(jié)。

Subagents

還有一個我認為同樣屬于 Context Engineering 的強大能力：subagents。這個概念也是去年開始真正流行起來的，現(xiàn)在很多 coding agent 都已經(jīng)內(nèi)建支持。它的核心思想是：主 agent 可以派生出子 agent。

最常見、甚至很多時候用戶都沒顯式控制的場景，是 agent 在 session 開始時需要研究代碼庫結(jié)構(gòu)，它通常會自動派生一個 subagent 去做這件事。右下角這個 Claude Code 截圖里，就有一個 Explore agent。因為“研究代碼庫”本身會消耗大量 token，它需要讀很多文件、篩選哪些和任務(wù)相關(guān)，所以把這件事交給 subagent 很合理。subagent 最后只把結(jié)果匯報回主 session，而不會把所有中間噪音全塞進主 context。

你自己也可以主動使用 subagents。一個特別常見的用法，是專門創(chuàng)建 code review agent。很多人喜歡讓一個“沒有歷史上下文污染”的獨立 context window 來做 code review；甚至還會讓它使用不同模型，這個能力其實解鎖了很多后面會繼續(xù)演化的新工作流。

在 Context Engineering 這塊，我想提幾個值得思考的問題。

第一，你想放大哪些編碼規(guī)范？因為 AI 本質(zhì)上就是“放大器”，好的會放大，壞的也會放大，你得小心。

第二，你能否基于這些能力，構(gòu)建現(xiàn)代化遷移的工作流？遷移本就是生成式 AI 特別擅長的場景，而現(xiàn)在有了 subagents、skills、MCP servers 這些能力之后，這類流程已經(jīng)越來越容易工程化。我最近跟一個同事聊過，她的客戶有幾千個 CI/CD pipeline 在舊工具里，需要遷移到 GitHub Actions，她就在構(gòu)建一個帶人工監(jiān)督、包含不同 subagents、skills、MCP servers 的工作流。

第三，組織里應(yīng)該開放哪些工具，讓 agent 更容易執(zhí)行操作或獲取信息？可以是 CLI，可以是 MCP servers，也可以是語言服務(wù)器。尤其是一些比較小眾的編程語言場景，如果你能給 agent 提供真正理解語言機制的工具，而不只是純文本上下文，效果會差很多。

還有一個問題也很重要：你到底想讓 AI 放大哪些“實踐”？我最喜歡的例子是改善架構(gòu)決策記錄、怎么做威脅建模，這些東西其實也完全可以被封裝成 skills，幫助團隊把優(yōu)秀工程實踐標(biāo)準(zhǔn)化。

開放問題也不少。首先，所謂 Context Engineering，其實那個“engineering”多少還帶著引號。比如：這些東西怎么版本管理、怎么分發(fā)？現(xiàn)在已經(jīng)開始出現(xiàn)一些插件市場，同樣是 Anthropic 和 Claude Code 團隊推動的，但還不夠成熟，都在演化中。

另外一個大問題是，你加進去的 context 到底是讓結(jié)果變好了還是變差了？這就涉及 evals，也就是如何評估 skills 的效果。Anthropic 最近發(fā)布了一些工具讓 evals 更容易做，skills registry 平臺 Tessl 也發(fā)了新東西，但都還在早期階段。

越來越少的人類監(jiān)督

隨著模型能力的持續(xù)提升和 Context Engineering 越來越成熟，有一個明顯的趨勢：給 agent 更多自主權(quán)，減少人工監(jiān)督。這大概也是所有 hype 最核心的問題：“AI 到底什么時候才能獨立把代碼全寫完？”

所謂 supervised 模式，就是開發(fā)者依然坐在 session 前面，持續(xù)觀察 agent 在干什么、不斷介入、不斷糾偏，雙方高頻來回協(xié)作。而 unsupervised 模式，則更像“把任務(wù)直接丟出去”。這張截圖來自去年年中 OpenAI 的 Codex 剛發(fā)布的時候。當(dāng)時大家第一次看到所謂 cloud agents：你把任務(wù)發(fā)到云端，然后 agent 在那邊自己跑 20 分鐘，甚至更久，回來再給你結(jié)果。

到了今天，幾乎所有主流 coding agent 產(chǎn)品，都已經(jīng)支持這種模式了。agent 不再只是本地 IDE 里的輔助工具，它們也開始在云端工作，如今你甚至還能直接在手機上操作這些東西。所以真的已經(jīng)開始有人在通勤路上寫代碼了——前提是他們還需要通勤的話。

另一個推動力是 CLI 版編程助手的興起。現(xiàn)在幾乎所有大產(chǎn)品，都開始推出命令行版本：Cursor CLI、Copilot CLI，當(dāng)然第一個真正引爆關(guān)注的還是 Claude Code。而一旦這些 agent 能以 headless mode 運行，你就可以把它們直接接入現(xiàn)有 pipeline 系統(tǒng)，比如現(xiàn)在已經(jīng)有 Claude Code 的 GitHub Actions，Copilot 也有類似集成。

隨之回來的是一個老朋友：沙箱。得給 agent 一個合適的環(huán)境，得想辦法把它的工具、編譯器、開發(fā)依賴都搞定。“Out of memory error“ 只是表象，核心是資源配給的問題。CI/CD 里的 internet access 也不簡單，dev sandbox 的權(quán)限邊界、agent 加載不可信 web 內(nèi)容時遇到的 prompt injection 風(fēng)險……有些是新問題，有些是本來就有的挑戰(zhàn)。

不只云端，本地使用上減少監(jiān)督的趨勢也存在。這是 Steve Yegge 那個 Gas Town 博客里的一張圖，叫《開發(fā)者進化為 AI 的 8 個階段》。Stage 6 是同時跑 3 個 Claude Code 實例，Stage 7 是同時跑 10 個。我試過跑 3 個，真的是太多了，我老是把內(nèi)容敲到錯誤的窗口里。但確實已經(jīng)有一些團隊開始這么工作了。

Agent Swarms

而最后那張圖，也就是所謂“stage 8，則可以算是當(dāng)前最新一輪 hype 的一個縮影，我姑且把它稱作“agent swarms”。Gas Town 就是一個例子，還有一個叫 Claude Flow 的項目，其實已經(jīng)存在挺久了，只是最近好像改了名字。最近 Cursor 和 Anthropic 也分別做了兩個實驗，引發(fā)了巨大關(guān)注。

Agent swarms 基本就是，你派出大量 agent，幾十個甚至幾百個。盡可能多地往墻上扔，看什么東西能粘住，觀察有沒有涌現(xiàn)出新的行為，怎么協(xié)調(diào)這些 agent 等等。

Cursor 和 Anthropic 的那兩個實驗，確實讓很多人開始緊張。Cursor 讓一群 agent 跑了大概一周來構(gòu)建瀏覽器，Anthropic 讓它們構(gòu)建 C 編譯器。于是很多人開始驚呼：“AI 已經(jīng)能獨立構(gòu)建這些東西了嗎？”

但這里有個非常重要的背景必須意識到：這兩個任務(wù)，其實都屬于“高度可定義”的問題。而且我懷疑，他們也是故意挑這種任務(wù)來做展示的。Cursor 自己其實也承認過，他們是有意選擇這個方向。因為無論是瀏覽器還是 C 編譯器，它們的 specification 在互聯(lián)網(wǎng)上到處都是。尤其 C 編譯器這個場景，還有極其成熟、龐大的測試套件。agent 可以不斷運行測試，通過反饋判斷自己是不是做對了。

而這恰恰是企業(yè)軟件開發(fā)里經(jīng)常缺失的東西。我們并沒有那種級別的 specification，也沒有那種級別的自動反饋系統(tǒng)。所以，我并不覺得你一定要立刻跑去嘗試 Gas Town，至少對于大多數(shù)企業(yè)開發(fā)環(huán)境來說，現(xiàn)實問題完全不是一個量級。但如果你想稍微“試探一下水溫”，有一種更務(wù)實的方法：Claude Code 有個還在 preview 的功能叫 agent teams。

有些人把 agent teams 和 swarms 當(dāng)一回事，我傾向于把它們看成兩個不同的概念。swarms 是扔出幾十上百個 agent，甚至由 AI 決定用哪些；teams 則更克制一些。比如這里，我只用了五個 agent。核心問題在于 orchestration（編排），主 agent 需要決定哪些任務(wù)可以并行；不同 agent 之間還能互相通信、交換結(jié)果等等。但總體來說，這一切都還非常早期。

如何衡量監(jiān)督程度

先稍微回到現(xiàn)實一點的話題，“減少監(jiān)督”這件事本身。有幾個問題，我覺得每個團隊現(xiàn)在都應(yīng)該開始認真思考。

第一，在哪些場景下你愿意拿云端 agent 或低監(jiān)督 agent 做實驗？不同組織的環(huán)境差異很大。有些團隊可能完全無法承受高風(fēng)險實驗。但即便如此，你依然可以從一些低風(fēng)險場景開始，比如清理 feature toggles。很多團隊現(xiàn)在也會用 AI 做 code review 之類的工作。

第二，你怎么判斷一個任務(wù)需要多少監(jiān)督？更進一步說，你又該如何幫助組織里的其他人建立這種判斷能力？

我發(fā)現(xiàn)自己在用 AI 的時候，一直在做各種小型、有時是較大型的風(fēng)險評估：“這個任務(wù)該不該交給 AI？”“應(yīng)該讓它做到什么程度？”“我要 review 到多細？”風(fēng)險評估永遠都離不開三個維度：概率、影響、可檢測性。也就是：它出錯的概率有多大？如果出錯，后果有多嚴重？以及你能不能發(fā)現(xiàn)它出了錯？

在 AI 編程這個場景里，我首先會評估：AI 出錯的可能性有多大。這個概率，通常來自幾個因素，包括：我對當(dāng)前上下文的理解程度；我對這個工具能力邊界的了解；以及我過去在類似任務(wù)里使用它的經(jīng)驗，這是一種需要時間積累的直覺，還包括我對自己的需求有多大把握，我到底能不能把一個需求說清楚。第二，如果 AI 搞錯了，影響有多大？取決于使用場景的重要性。是 PoC 或者 spike？還是那種會讓我周末凌晨兩點被電話叫起來的核心流程、是我在 on-call？第三，可檢測性，我能不能發(fā)現(xiàn) AI 搞錯了？這里面全是我對自己的反饋循環(huán)有多了解。

評估完之后，我就決定用什么工作流：是非常精細的、開頭要先做大量規(guī)劃的，還是直接扔一個 prompt 就上？這也決定我審查多少：是完全 vibe coding，一眼都不看，還是逐行檢查，還是在中間的某個點？還要決定我放手讓它跑多久不去管，因為跑得越久，事后要回顧驗證的內(nèi)容就越多。

如果你仔細看這整個判斷過程，其實真正“全新”的部分，只有我現(xiàn)在標(biāo)黃的這一塊“你對 AI 在某類任務(wù)上的真實能力到底有多了解”。其余能力，其實成熟開發(fā)者本來就應(yīng)該具備。我們真正需要強化的，是這一項新的能力。某種意義上，這有點像游樂園里的那句提示：“你得長到這個高度，才能坐過山車。”在 AI 開發(fā)里也是一樣：你得具備足夠判斷力，才有資格減少監(jiān)督。

AI 出錯的概率，在爛代碼庫里面會升高，因為它會照著已有的爛模式走。如果現(xiàn)有模式本身就混亂，那結(jié)果只會被進一步放大。又比如，一個系統(tǒng)的信息分散在很多地方，AI 就更難真正獲取完整上下文。可檢測性也跟代碼庫質(zhì)量有關(guān)，沒有良好的反饋循環(huán)，沒有可靠的測試自動化，那么不僅你自己更難驗證 AI 的輸出，agent 本身也更難驗證自己的結(jié)果。

安全與成本

安全

現(xiàn)在幾乎每周都有什么事故報告出來，基本都和 prompt injection 有關(guān)，agent 從不可信來源拿到了內(nèi)容，而那個內(nèi)容包含了你不曾意識到的指令。

一種后果是 unwanted command execution。現(xiàn)在幾乎所有 coding agent 都有 allow list 功能。你可以配置哪些命令允許自動執(zhí)行、不需要再詢問用戶；而另一些命令，則始終要求用戶手動確認：“是的，你可以執(zhí)行。”但這些機制本身，目前其實還存在不少實現(xiàn)層面的漏洞。再加上很多配套機制本來也還沒完全成熟，以及 AI 本身天然具有不確定特性，于是整體風(fēng)險就會迅速放大。

另一個非常大的安全風(fēng)險，是 secrets extraction。尤其是在開源項目場景下，這個問題非常嚴重。很多項目允許任何人提交 GitHub Issue，然后又會自動觸發(fā) agent 去處理 issue，而且中間幾乎沒有人工監(jiān)督。有一次攻擊里，攻擊者就是通過 GitHub Issue 中的 prompt injection，成功誘導(dǎo) agent 泄露了 secrets，最終獲得了向 npm registry 發(fā)布惡意版本的權(quán)限。這些問題不一定都直接適用于企業(yè)內(nèi)部環(huán)境，但它至少說明了一件事：我們對整個依賴生態(tài)的風(fēng)險敞口，正在急劇增加。我們必須比過去更加謹慎地思考：到底把哪些生態(tài)組件引入自己的系統(tǒng)。

Simon Willison 在 25 年 6 月寫過一個很好的思維模型，叫 lethal trifecta（致命三要素）。當(dāng)你的 agent 同時滿足這三個條件：接觸不可信內(nèi)容、能訪問私有數(shù)據(jù)、可以對外通信，那么安全風(fēng)險就處于高位。

而這件事，其實在企業(yè) agent 場景里更加危險。因為很多業(yè)務(wù)場景一開始就會接入郵箱系統(tǒng)，而且通常還是 read/write 權(quán)限。那一刻起，你其實已經(jīng)滿足 lethal trifecta 了。所以，這并不只是一個“技術(shù)問題”，它更像是一個“概念層面的問題”。未來那些我們被承諾過的企業(yè) agent 場景，到底能不能真正繞開這些風(fēng)險，我覺得會非常值得觀察。

在減少人工監(jiān)督的背景下，安全方面想想這些事：你有沒有在簡化 agent 的沙箱使用，不只是在云端，本地也是？可以用 dev container，我最近大量在用這些。還有一堆新產(chǎn)品冒出來，在人機交互沙箱這塊有一些有意思的想法。另外，組織里工程師的 AI 安全素養(yǎng)怎么樣？他們知道底層在發(fā)生什么嗎？比如，有些 agent 有所謂“YOLO 模式”，連命令確認都不需要，agent 想執(zhí)行什么就執(zhí)行什么。這種模式，真的不要隨便開。

成本

關(guān)于成本，蜜月期顯然也已經(jīng)結(jié)束了。2024 年初，我聽過一場 keynote，演講者說"生成 100 行代碼只需要大約 12 美分，你想想開發(fā)者工資有多貴。"先不說“代碼行數(shù)”本身就是一個非常糟糕的價值衡量指標(biāo)，問題在于：現(xiàn)在早就不是 12 美分了。

這是 2025 年夏天的數(shù)據(jù)，有一些網(wǎng)站會公開用戶的 token 消耗情況。其中有個人，平均每天花費大約 380 美元。如果按每月 20 個工作日、一年 12 個月來算，那就是年成本 91,200 美元。而在德國，這已經(jīng)是一份相當(dāng)不錯的開發(fā)者薪資了。更何況，那還是“去年夏天”的數(shù)字。

現(xiàn)在成本已經(jīng)進一步爆炸。我們已經(jīng)從最早每月 20 美元的“無限套餐”時代（Copilot 最開始甚至可能只要 10 美元），一路走到了今天這種所謂“200 美元 flat rate”，而且還不是真正 flat，因為會有 request limiting。于是你會看到 Reddit 上開始有人發(fā)帖：“這個月才過一半，我 token 已經(jīng)用完了，怎么辦？”“我們現(xiàn)在已經(jīng)離不開這些工具了。”

為什么現(xiàn)在做一個改動的成本遠不止 12 美分？那個 keynote 演講是 2024 年初，那時候大家主要還在用自動補全，最多在聊天框里問幾行代碼。而現(xiàn)在的流程是：agent 研究已有代碼，制定計劃，我們審查調(diào)整計劃，開始實現(xiàn)，跑測試、修測試、檢查 lint 錯誤、修錯誤，如果是 UI 功能還要檢查瀏覽器，再修，跑 code review agent，回應(yīng)審查意見，做總結(jié)。來來回回一大圈，最后可能只改了兩行代碼。

我們現(xiàn)在在哪

經(jīng)過這 12 個月之后，如果把所有變化放在一起看，一個更清晰的輪廓其實已經(jīng)開始浮現(xiàn) Context Engineering 正在變成一個非常強的“放大器杠桿”，而且這種放大是雙向的：既能放大好的工程實踐，也同樣會放大壞的結(jié)構(gòu)問題。

現(xiàn)在你確實可以通過一整套手段，讓 agent 更大概率按照你的意圖去工作。模型能力本身當(dāng)然也在進步，這一點幾乎是默認前提，但有意思的是，它反而變成了一個“背景變量”，沒有 surrounding system 那么關(guān)鍵了。

而更重要的結(jié)果是：一股很強的力量正在把我們“推出人類干預(yù)循環(huán)”。你會越來越頻繁地面對這種誘惑：要不要更少介入？要不要讓 agent 自己跑？要不要直接把這一塊交給自動化？這種體驗往往是“非常爽”的，因為反饋很快，產(chǎn)出很多，看起來效率極高。

但問題也隨之出現(xiàn)：在某些組織或某些 use case 里，這種“脫離人類循環(huán)”的決策，可能在一年之后才會暴露代價。于是核心矛盾變成了一個判斷問題：在什么地方我們可以順著這種自動化趨勢走？又在哪些地方，這其實是一種“看起來很順，其實很危險”的路徑依賴？

現(xiàn)在整個行業(yè)都被一種強烈的驅(qū)動力推動著：speed、throughput、PR 數(shù)量。“我們這個星期 merge 了多少 PR？”“我們比上個月快了多少？”這些指標(biāo)變得越來越顯性。但當(dāng) autonomy 提升、supervision 降低之后，問題也開始從單一的“安全”和“成本”，擴展到一個更長期的維度：代碼可維護性到底會發(fā)生什么變化？

OpenAI 的一個團隊最近有篇文章很有意思。他們在過去五個月里維護一個 codebase，這個項目一開始是 greenfield，從零開始。他們給自己定了一個非常激進的規(guī)則：盡量不直接手寫代碼，而是只和 agent 交互，讓 agent 去改代碼，然后他們不斷優(yōu)化周邊系統(tǒng)，讓 agent 更容易在這個環(huán)境里自主維護代碼。整個過程其實是一個混合系統(tǒng)：一部分是 Context Engineering（skills、規(guī)則、工具接口），另一部分是更 deterministic 的機制，比如 custom linters、結(jié)構(gòu)化測試（structural tests）等等。

即便如此，他們?nèi)匀话l(fā)現(xiàn)熵在增加，漂移在發(fā)生，代碼庫并不會自動變得更整潔。于是他們引入了一個他們稱之為“garbage collection”的過程，讓 agents 持續(xù)在代碼庫上運行，進行清理和整理。

通過 Harness Engineering 建立信任

這些“架構(gòu)約束 + 確定性工具 + agent 自動維護”的組合，正在越來越多團隊的實踐中出現(xiàn)。我自己也做過一點類似嘗試，這本質(zhì)上就是把結(jié)構(gòu)性測試變成 agent 的反饋。比如 Java 生態(tài)里的 ArchUnit 或 Spring Modulith，或者在 TypeScript 里，我用的是 dependency-cruiser，說實話，我以前甚至沒怎么接觸過這個工具。

原因其實很簡單：這些工具一直都存在，但在“人類主導(dǎo)寫代碼”的時代，它們并不是剛需。因為開發(fā)者本身就能理解模塊邊界，也知道怎么拆分結(jié)構(gòu)。但現(xiàn)在它們突然變得很重要，因為它們變成了 agent 的“反饋系統(tǒng)”。

在我的實驗里，我定義了應(yīng)用的分層結(jié)構(gòu)，然后配置了一系列規(guī)則。比如其中一條規(guī)則是：external SDK 只能在特定的 client folder 里被引用，而 domain 層完全不允許直接依賴這些外部 SDK。這些規(guī)則不只是約束代碼，也是在反向塑造 agent 的行為。

更有意思的一點是：這些 lint rules 和結(jié)構(gòu)性測試，現(xiàn)在其實可以被“增強語義”。它們不僅僅是錯誤提示，它們也可以變成一種“帶解釋的反饋通道”。這有點像一種“正向 prompt injection”。你可以在錯誤信息里附加解釋：“這個錯誤不僅僅是違反規(guī)則，它可能意味著你的設(shè)計出現(xiàn)了問題，建議你考慮重構(gòu)。”

如果你設(shè)定規(guī)則：每個文件不能超過 500 行代碼。如果不加引導(dǎo)，agent 可能會“投機取巧”，比如把一行寫成多個 statement 來規(guī)避限制。但如果你在 lint message 里補充上下文，比如：“這通常意味著模塊劃分不合理，應(yīng)考慮拆分設(shè)計。”那么 agent 就會開始理解規(guī)則背后的意圖，而不是機械規(guī)避。

本質(zhì)上，我們正在做的事情是：把原本為人類設(shè)計的工程約束系統(tǒng)，改造成 agent 可學(xué)習(xí)、可反饋、可優(yōu)化的系統(tǒng)，這可能才是 Context Engineering 真正開始變得“工程化”的地方。

說到底，這就是怎么建立對 agent 的信任——構(gòu)建一整套 Harness。那個 OpenAI 團隊管這叫做 Harness engineering，因為歸根到底，我們不是說幾年后要讓 agent 寫出完美的代碼，我們自己寫的代碼也從來不完美。問題是，在特定場景下，我們怎么獲得足夠的信心和信任來安全、快速、可持續(xù)地交付軟件？

我最近一直在思考一個心智模型，我前面聊了大量的 Context Engineering、skills 等等，所有這些都是喂給 agent 的前置輸入。我們在預(yù)判 agent 可能會犯什么錯，然后提前給它所有工具和指令，提高它按我意圖行事的概率。這些東西包括 principles、coding conventions、參考文檔、how-to 等等。然后 agent 產(chǎn)出第一版代碼之后，我們就給它反饋：靜態(tài)分析、給它接入日志、啟動應(yīng)用看能不能跑、檢查瀏覽器。所有這些反饋讓 agent 先把那些重復(fù)的修正工作做完，才輪到我看。

這些東西可以是 CPU-based 和 GPU-based 的混合。這個框架我是從一家叫 Moderne 的公司學(xué)的。什么意思呢？我們有 code review agent，但它本質(zhì)還是基于 GPU 推理的。如果我們把它用大量 CPU-based、更確定性的東西來增強呢？而同樣的事情也可以在 feedforward 側(cè)做，不只是給 agent 基于 GPU 推理的工具和信息，如果給它接入 CLI、bootstrap 腳本、Codemod、OpenRewrite recipes 這些更確定性的工具，一樣可以讓它更大概率做對事情。這也回到我前面提到的語言服務(wù)器，比如現(xiàn)在你可以給 agent 接入 IntelliJ 的重構(gòu)能力，它可以用"rename symbol"功能來做一次重構(gòu)，而不是到處做文本 diff，這樣它的準(zhǔn)確率就更高了。

這套東西全部加在一起，我管它叫 Harness。有些是 coding agent 自己內(nèi)置的，他們可以持續(xù)改善代碼編輯的方式、代碼搜索的方式，這些都算 Harness 的一部分。還有一些是我們可以自己控制、針對自己的情況定制的，人類是這套東西的舵手。

那個 OpenAI 團隊做的就是這件事，不斷改善 agent 周圍這個 Harness。當(dāng)然，我們也可以用 AI 來幫我們搭建 Harness。我前面說的那些結(jié)構(gòu)性測試和 linting，之前大家不會自己去寫這些自定義工具，太費工夫。但我那個實驗，全部都是用 AI 做的，不是我手寫的。風(fēng)險比生產(chǎn)代碼低太多了。

我甚至在想，這會不會成為某種新的抽象層。會不會將來某一天，我們會有一些覆蓋 80% 工作內(nèi)容的拓撲結(jié)構(gòu)？我們經(jīng)常構(gòu)建那種從其他 API 收集數(shù)據(jù)并展示的數(shù)據(jù)儀表盤，或者可能是 CRUD 業(yè)務(wù)服務(wù)、事件處理器，也就是我們編寫的那些典型應(yīng)用類型。然后我們有一個關(guān)于它們應(yīng)該怎么結(jié)構(gòu)化、用什么技術(shù)棧的定義。

也許未來我們不再靠傳統(tǒng)服務(wù)模板起步，而是一個 Harness 模版，實例化之后就能支撐我們的代碼庫。到那時候，我們可能甚至不在乎到底是 React 還是 Vue，決策維度可能會變成“有沒有現(xiàn)成的 Harness，這樣我就不用操心、不用從頭搭了”。

但我前面講的這一切，都是關(guān)于可維護性和內(nèi)部代碼質(zhì)量的。對于功能正確性這件事，我的問號還是非常非常大。當(dāng)然，這是最終的關(guān)鍵。我們不僅希望安全關(guān)鍵的系統(tǒng)能正常工作，我們希望所有軟件都能正常工作。

我們需要更多關(guān)于如何給應(yīng)用的不同維度加 Harness 的思考。我講了很多可維護性，但也許還有架構(gòu)健康度，比如怎么給可運維性加 Harness，怎么給性能加 Harness？然后是行為正確性。現(xiàn)在大多數(shù)人的做法是，前面用描述喂給 agent，后面看看測試是不是綠的，但測試也是 AI 生成的，然后再做一點手動測試，到此為止。有些人說他們會更多審查測試等等，但我有時候有點懷疑，這不夠，我們需要更好的辦法。

模型進步確實提高了一些我的信任度。更精細的 Context Engineering、context 的漸進式加載、更多的工具集成、subagents，所有這些都提供了很多新的建立信任的手段。圍繞 static analysis 能走多遠這件事，也多了很多新的思考空間。

但我還是天天看到模型犯蠢的事情。Reddit 上有個帖子很火，agent 說："你說不，但我以為你是在拒絕我問你要權(quán)限，所以我就自己直接去做了。"就像個青少年："你說不，但我理解成了別的意思。"

另外還有那種"還在 loop 里卻已經(jīng)認知超載"的感覺。有越來越多的人開始說他們用 AI 之后感到倦怠，要么是被審查的工作量壓垮，要么是同時切多個會話根本看不過來，眼花繚亂。有一個很有意思的現(xiàn)象：真正能把 AI 開到最大這種自主度跑起來的，通常都是非常資深的工程師。他們有更強的認知承載力，他們本來就有了極強的經(jīng)驗積累。

然后還有來自上面的速度壓力。一旦給人們施壓"你的 AI 產(chǎn)出是什么?"、"你用了 AI 怎么還能這么慢"，他們就會走捷徑、變粗心。有意思的是，Amazon 最近出了一篇內(nèi)部復(fù)盤，提到一些疑似由 AI 生成代碼相關(guān)的故障。他們的對策之一是增加關(guān)卡，讓 senior 工程師必須 review 生產(chǎn)內(nèi)容的引入。這有點諷刺，不是說好的要更快上線嗎，結(jié)果我們反而加了更多手續(xù)？這大概也不是正解。

我最近越來越頻繁地問自己，我們到底需要多快？什么才是 Goldilocks 速度（剛剛好的速度），夠快但不太快？這種速度到底帶來什么風(fēng)險？速度是怎么真正幫到組織的？有沒有其他更值得我們關(guān)注的事？

AI 就像一把瑞士軍刀，有著大量潛在的使用場景。其中很多場景在有人類監(jiān)督的情況下才真正有用，未必會讓你不堪重負，反而會是你原本必須手動完成、耗時極長的工作的一種良好延伸。過去一年里涌現(xiàn)出了那么多進展，讓 AI 的使用變得更高效，也讓你在把 AI 當(dāng)作自身能力增強時，獲得了更好的開發(fā)者體驗。

接下來這 12 個月，我們會學(xué)到更多東西。會有新的好主意，也會暴露更多讓我們擔(dān)憂的東西：過載、技能退化等等。這些，也不過是我拋給你們反思的一些問題：如果你想在交付中給予 AI 更多自主權(quán)，你準(zhǔn)備好了嗎？你的自動化安全網(wǎng)是什么？你的安全態(tài)勢如何？眼下團隊的 AI 素養(yǎng)到了什么程度？在這些方面做提升，永遠是值得的，對人類本身同樣值得。如果你將來想做好準(zhǔn)備，AI 甚至今天就能幫你去完善那張安全網(wǎng)。

演講原鏈接：https://www.youtube.com/watch?v=_R83pFpUWyM

聲明：本文為 InfoQ 整理，不代表平臺觀點，未經(jīng)許可禁止轉(zhuǎn)載。

會議推薦

企業(yè)級 Agent 落地，繞不開 4 個真實的工程問題。如何在 Agent 安全性和可用性之間找到平衡點？Agent 需要什么樣的記憶系統(tǒng)才能真正理解上下文？如何通過算法壓榨實現(xiàn)智力增量與成本控制的極致平衡？多 Agent 協(xié)作，如何做到可觀測、可治理、可控制？6 月 26-27 日，AICon 全球人工智能開發(fā)與應(yīng)用大會·上海站國內(nèi)頭部公司的 Agent 實踐，一次說透。