責(zé)編 | 夢依丹

出品 | CSDN（ID：CSDNnews）

在 AI 輔助編程風(fēng)靡全球的今天，許多開發(fā)者都經(jīng)歷過 Vibe Coding 帶來的驚艷：輸入一行 Prompt，AI 迅速生成一個精美的 Demo。然而，當技術(shù)團隊試圖將這些工具引入復(fù)雜的、百萬行級代碼的企業(yè)級生產(chǎn)系統(tǒng)時，往往會面臨“硬著陸”的尷尬：

• 每次開啟新會話，AI 就會忘記項目既定的技術(shù)棧和代碼規(guī)范；

• 長對話進行到后期，AI 因為上下文污染和“注意力漂移”變得越來越糊涂，甚至開始原地打轉(zhuǎn)；

• 自動生成的代碼因為隱藏的邏輯缺陷或依賴引入，導(dǎo)致 PR 被多次退回。

這些痛點說明了一個嚴峻的事實：Demo 驚艷不等于產(chǎn)線可用。AI 編程的瓶頸，已經(jīng)不再是模型本身的智力，而是工程化能力。

近日，新加坡科技研究局高性能計算研究所 AI 研究員、知名技術(shù)作家黃佳（咖哥）走進 CSDN 「AI 進化論」欄目，深入拆解了如何將 Claude Code 從 Demo 推進到產(chǎn)線的完整方法論。

黃佳指出：“2025 年我們都在玩 Vibe Coding，而 2026 年，企業(yè)真正需要的是 Harness Engineering。”

本文基于黃佳老師的分享內(nèi)容，整理了將 Agent 推向生產(chǎn)環(huán)境必須跨越的“八道 關(guān)卡”及對應(yīng)的工程設(shè)計模式，以饗讀者。

核心共識：Agent = Model + Harness

在系統(tǒng)拆解之前，我們需要厘清一個核心公式：

Agent=Model+Harness

Harness 一詞的原意為“馬具”（套在馬身上的挽具、韁繩等）。馬匹雖然力大無窮，但若沒有馬具的控制與牽引，便無法拉動車輛。大語言模型也是如此，它本 身只是一個具備理解與生成能力的“智力引擎”，而 Harness 則是包裹在模型外層的一切工程化基礎(chǔ)設(shè)施（包括上下文管理、工具調(diào)度、事件攔截、狀態(tài)持久化等）。

截圖自黃佳老師 PPT

近期，多項行業(yè)實測證實了一個關(guān)鍵規(guī)律：

• “同一模型在不同 Harness 下的表現(xiàn)差異，遠大于不同模型在同一 Harness 下的差距。”

• 在 TerminalBench 基準測試中，僅通過對 Harness 層的優(yōu)化，就使同一個模型的能力從基線以下躍升至 Top 5；

• Vercel 團隊發(fā)現(xiàn)，主動剔除 80% 的 Agent 工具后，流程更精簡，Token 消耗驟降，響應(yīng)速度反而更快。

因此，調(diào)教 Harness 才是釋放 AI 真實工程效能的真正變量。

第一關(guān)：如何讓 AI 讀懂（巨型）代碼庫？

痛點：AI 記不住項目規(guī)范，大庫讀不完

每次新建會話都要重新給 AI 解釋項目背景，且由于上下文窗口的限制，面對百萬行級別的代碼大庫，AI 常常面臨“讀不完”或“讀了后面忘前面”的窘境。

解法：五層記憶體系 + 上下文分診

1. 建立分層的記憶架構(gòu)

不能把所有的規(guī)范都塞進同一個配置文件里。黃佳老師提出，應(yīng)該構(gòu)建一個五層記憶體系：

• Enterprise 級：企業(yè)全局 CLAUDE.md，寫入不可繞過的安全與合規(guī)策略（如：嚴禁將代碼發(fā)送至外部 API、禁止硬編碼密鑰等）。

• User 級： 存放個人的編碼偏好（如：交流語言、快捷指令映射）。

• Project 級： 團隊共享的項目級規(guī)范（如：明確規(guī)定使用 Fastify 框架和 pnpm 包管理）。Anthropic 官方硬指標要求該文件控制在 200~300 行以內(nèi)，它不是文檔夾，而是始終在線的 P0 槽，每一行都應(yīng)是真金白銀的規(guī)則。

• Rules 級： 將細分領(lǐng)域的規(guī)范（如前端組件規(guī)范、數(shù)據(jù)庫遷移規(guī)范、測試策略）拆解為獨立文件。利用 YAML Frontmatter 的 paths 字段聲明 Glob 模式進行條件化加載。例如：只有當 AI 操作 tests/** 路徑時，才會激活測試規(guī)范，實現(xiàn)按需取用。

• Local 級：存放個人的臨時備忘，該文件自動被納入 .gitignore，不提交到代碼庫。

2. 上下文分診：類比操作系統(tǒng)調(diào)度

黃佳老師給出了一個精妙的隱喻：在大模型時代，LLM 是 CPU，Context 是內(nèi)存，文件系統(tǒng)則是磁盤。

我們無法把磁盤一股腦堆進內(nèi)存中，這就需要引入類似 OS 虛擬內(nèi)存管理器的“上下文分診”機制，將候選信息分為四個等級（P0 ~ P3）：

截圖自黃佳老師PPT

通過這種分診調(diào)度，例如在排查“訂單扣款失敗”問題時，AI 僅調(diào)入 3 段核心日志（P0/P1）與 5 段歷史工單句柄（P3），將上下文體積從 18K 壓縮至 2K Token，信噪比大幅提升，定位問題的準確度反而更高。

第二關(guān)：如何控制 AI 的幻覺？

痛點：AI 給出看起來對、實際是錯的代碼

在長會話中，Claude Code 在 95% 容量時會自動觸發(fā)上下文壓縮。如果它把一段 487-token 的“連接池耗盡”錯誤堆棧壓縮成了一句簡單的 a database error occurred，AI 就丟失了原本的反饋回路，接下來可能會花費數(shù)小時重試那些早已被堆棧排除掉的錯誤方案，在原地打轉(zhuǎn)。

解法：結(jié)構(gòu)化上下文 + Hooks 質(zhì)量門禁

1. 結(jié)構(gòu)化輸入，注入而非生成

減少幻覺的關(guān)鍵在于讓 AI 基于已有的代碼進行“注入修改”，而不是讓其“憑空創(chuàng)造”。在向 AI 下達任務(wù)時，盡量避免“幫我優(yōu)化這個函數(shù)”等模糊表達，而是要提供結(jié)構(gòu)化信息：

• 反例：幫我優(yōu)化這個函數(shù)。

• 正例：優(yōu)化 src/utils/parser.ts 的 parseConfig 函數(shù)，瓶頸在第 42 行的循環(huán)。

2. Stop Hook 作為契約：將控制交回確定性工程

“Prompt 是請求，Hook 是契約。”我們不需要在 Prompt 里一遍遍地哀求 AI “請不要胡思亂想”，而是要用確定性的 Hook 門禁把不靠譜的產(chǎn)出擋在門外。

通過在擴展層配置 Stop Hook（在 AI 完成響應(yīng)并生成完代碼之后、準備交付之前觸發(fā)），讓系統(tǒng)自動靜默運行單元測試與代碼靜態(tài)檢查：

}

如果測試未通過，系統(tǒng)直接阻斷本次提交并報錯，把結(jié)果喂回給 AI，讓其自己修改，直到自愈通過后再交付。

第三關(guān)：如何實現(xiàn)經(jīng)驗復(fù)用？

痛點：好 Prompt 鎖在個人腦子里，無法團隊共享

每個開發(fā)者都在自己的終端里重復(fù)寫著類似的代碼審查、測試生成等 Prompt，新人上手慢，全隊重復(fù)造輪子。

解法：從 Prompt 到聲明式 Skill

在 Claude Code 的設(shè)計中，支持將好用的 Prompt 封裝為 .claude/skills/ 目錄下的 Skill 資產(chǎn)，并通過 Git 進行版本控制。如此一來，新人克隆代碼庫時就 能瞬間繼承整個團隊沉淀的 AI 編程能力。

一個 Skill 實質(zhì)上是一個包含 SKILL.md 的目錄。為了節(jié)省 Token，Claude 采用了漸進式披露的設(shè)計：

• 啟動階段： 僅加載每個 Skill 頂部的 name 和 description（約 100 tokens 的元數(shù)據(jù)）。

• 匹配階段： 當用戶的輸入命中該 Skill 的語義（如提到“審查代碼”），系統(tǒng)才會展開完整的 SKILL.md 主文件。

• 執(zhí)行階段： 只有在真正需要動作時，才動態(tài)調(diào)用掛載的 bundled 腳本/外部資源。

通過這種“只在翻開書的對應(yīng)章節(jié)時才看內(nèi)容”的設(shè)計，在運行多 Skill 系統(tǒng)時，Token 空間可節(jié)省達 98% 左右。

第四關(guān)：算力貴、用量不透明？探尋 Token 經(jīng)濟學(xué)

痛點：一次任務(wù)燒了多少錢說不清，長對話越到后面越貴

解法：反向選型、多層路由與 Talker-Reasoner 架構(gòu)

1. 建立模型選擇矩陣

在企業(yè)實際部署中，全跑高檔的 Opus 往往會造成極大的資金浪費。經(jīng)過對真實業(yè)務(wù)復(fù)雜度分布的統(tǒng)計發(fā)現(xiàn)，多達 41% 的查詢只是簡單的 SQL 模板填空， 只需要最便宜的 Haiku 模型即可勝任。

通過在 Harness 中配置三層路由機制：

• Haiku (60%)→Sonnet (30%)→Opus (10%)

在保障產(chǎn)出質(zhì)量的前提下，月賬單可以從 48 萬驟降至 12 萬，綜合成本下降達 65%~75%。

2. 反向選型：在受限模型下選擇“模式”

當預(yù)算和部署環(huán)境是硬約束，只能在本地部署開源便宜模型（如 Qwen-32B）時，該如何提升準確率？

黃佳老師強調(diào)，此時模式的選擇才是設(shè)計的核心：

• 單次調(diào)用 Opus： 價格高昂，面對邊緣 case 依然可能出錯。

• Haiku 便宜模型 + 迭代自愈： 讓 Haiku 寫代碼，另一個 Haiku 做 Code Review，循環(huán)迭代 2 輪。其綜合算力成本依然遠低于單次調(diào)用頂級模型，但最終產(chǎn)出質(zhì)量反而實現(xiàn)了反超。

3. Talker-Reasoner 雙系統(tǒng)

針對實時對話/Voice 等高頻交互場景，長時間的思考延遲（如 reasoning 模型動輒等待 24 秒）會導(dǎo)致用戶以為系統(tǒng)卡死。

借鑒 Kahneman 雙系統(tǒng)理論，可將架構(gòu)重構(gòu)為 Talker-Reasoner 協(xié)同模型：

• Talker：采用 200ms 的極速便宜模型（如 Haiku），負責(zé)立即回復(fù)用戶、邊聊邊等；

• Reasoner：采用慢速但聰明的模型（如 Opus/ reasoning），在后臺進行深度推理，將推理出的 belief state（信念狀態(tài)）源源不斷地供給給 Talker。

這樣成功 地把思考延遲在用戶的感知里“藏”了起來。

第五關(guān)：約束與放手

痛點：AI 改對了 Bug，卻順手改了三處不該改的安全邏輯

解法：約束行動而不是約束思考，引入 HITL 人工審核

在治理 AI 的行動邊界時，很多技術(shù)負責(zé)人會陷入一個誤區(qū)：試圖在 Prompt 里細化 AI 的每一個思考步驟。這反而會束縛模型的推理自由。

“約束限定的是行動的邊界，而不是思考的自由。約束不是能力的保障，而是能力的容器。”

合理的工程約束應(yīng)該放置在動作發(fā)生、產(chǎn)生副作用（不可逆操作）的地方：

• 只讀/低爆炸半徑操作（如查代碼、看文檔）： 自動放行，不中斷流程。

• 可寫/中等影響操作： 留痕放行，記錄全鏈路的 Keyed log，事后支持完整 replay 溯源。

• 高爆炸半徑/不可逆操作： 強制觸發(fā)阻斷，并在控制臺彈出 HITL 人工審核面板，人手點下確認后，AI 才能繼續(xù)往下執(zhí)行。

第六關(guān)：復(fù)雜的編排載體該如何抉擇？

痛點：SubAgent、Skill、Workflow、Agent Team 概念混淆，不知道怎么組織

解法：一張四方圖厘清邊界

在 Harness 設(shè)計中，這四種編排載體并不是競爭關(guān)系，而是分別映射了現(xiàn)實世界中的四種工作實體：

• Skill = 崗位操作手冊：是靜態(tài)的、跨任務(wù)復(fù)用的知識包與 SOP 模板，代表了 Agent 的職業(yè)能力。

• SubAgent = 專職員工：具備獨立的、被隔離的上下文空間，執(zhí)行完特定任務(wù)（如跑個測試、搜個關(guān)鍵字）后即刻銷毀，實現(xiàn)防污染。

• Workflow = SOP 流程圖：將控制流顯式、確定性地凍結(jié)在代碼或腳本中，適用于多步、有著明確目標的長期自動化流程（如 nightly build 代碼自動修復(fù)）。

• Agent Team = 持續(xù)協(xié)作的虛擬團隊：維持長期的、多人的對話交互，各個 Mate 角色擁有持久化 Session。

在成熟的企業(yè)項目中，這四者通常是互補、嵌套使用的，共同組合為一套業(yè)務(wù)流水線。

第七關(guān)：如何防止長任務(wù)狀態(tài)漂移？

痛點：復(fù)雜的長任務(wù)跑著跑著就偏離了目標

解法：三平面分立架構(gòu) + 草稿紙看板

針對這個問題，黃佳老師引述了團隊核心共創(chuàng)者梁博老師在金融級 SaaS 智能體落地中的實踐經(jīng)驗。當一個 Agent 需要操作多套系統(tǒng)并維持長周期任務(wù)時，傳統(tǒng)的混沌上下文極易導(dǎo)致“狀態(tài)漂移”。

其核心解法是推行三權(quán)分立的狀態(tài)平面管理：

執(zhí)行調(diào)度平面：采用 DAG結(jié)構(gòu)，只記錄任務(wù)狀態(tài)與執(zhí)行流，不摻雜任何自然語言敘事與業(yè)務(wù)參數(shù)。

機械參數(shù)平面：嚴格鍵值的結(jié)構(gòu)化字典，是業(yè)務(wù) API 入?yún)⒌奈ㄒ豢蓪徲媮碓础?/p>

敘事對齊平面：采用自然語言記錄“目標與進展”，它是防漂移的“防波堤”，包含三個核心：

• 錨（Anchor）：鎖定用戶的原始最終目標，無論中間跳轉(zhuǎn)多少輪，均以此進行校準，防漂移。

• 賬（Ledger）：里程碑臺賬，結(jié)構(gòu)化地紀要“做到了哪一步”、“確認了什么”。

• 集（Collection）：投影工作集。由于全量狀態(tài)過大，每一步只給 AI 投影當前該看的、最小的上下文集合，降低檢索開銷。

此外，引入草稿紙看板設(shè)計，將 AI 內(nèi)部的思考流外化成一塊可讀、可審計、可隨時恢復(fù)的物理看板，落盤保存。即使某一輪因意外故障導(dǎo)致崩潰，系統(tǒng)也能根據(jù)草稿紙記錄瞬間恢復(fù)狀態(tài)并繼續(xù)運行。

第八關(guān)：從 Demo 到產(chǎn)線，如何合規(guī)治理？

痛點：能寫代碼不等于能交付系統(tǒng)，誰來對 AI 的生產(chǎn)出錯負責(zé)？

解法：可觀測性 + 來源坐標 + 團隊的兩條紀律

AI 本身作為概率性模型，無法承擔(dān)最終的生產(chǎn)安全責(zé)任。“背鍋”和負責(zé)的永遠是人。因此，走向生產(chǎn)環(huán)境的最后一步是構(gòu)筑一套可觀測與安全追溯的防線：

Provenance 來源坐標體系：對系統(tǒng)中的每一個機械參數(shù)進行嚴格的鏈路追蹤（哪個工具產(chǎn)生、從響應(yīng)的哪條路徑抽取、處于哪一步 turn、由哪個用戶輸入發(fā)起），出事能精準回溯到源頭。

兩條鐵的紀律：

• 紀律一： 角色規(guī)則前置，別等出事再通過 Prompt 去補，必須寫進 Skill 或 agent.md。

• 紀律二： 實行 Pre-task gating。在 AI 動手寫代碼前，強迫其先進行評估，說出“要做好這件事，我還需要補充什么信息、明確哪些問題”。不評估，不準寫代碼。

從 Vibe Coding 的熱鬧，走到 Harness Engineering 的嚴謹，這是 Agent 工業(yè)化落地的必經(jīng)之路。

為了不讓這些踩坑得來的經(jīng)驗重新回到封閉的個人腦海里，黃佳老師聯(lián)合業(yè)內(nèi)在軟件工程、長程多智能體編排以及企業(yè)級落地有著豐富經(jīng)驗的資深專家（茹炳晟、姜寧、梁博），共同發(fā)起了 Agent 設(shè)計模式共同體（Agent Design Patterns Society, 簡稱 ADPS）。

如果您對將 AI 真正引入生產(chǎn)系統(tǒng)、優(yōu)化研發(fā)效能、打通 Harness 工程設(shè)計感興趣，歡迎添加 CSDN 福利官，領(lǐng)取黃佳老師本次分享的 PPT 與直播回放視頻。