責編 | 夢依丹

出品 | CSDN（ID：CSDNnews）

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

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

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

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

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

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

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

本文基于黃佳老師的分享內容，整理了將 Agent 推向生產環境必須跨越的“八道 關卡”及對應的工程設計模式，以饗讀者。

核心共識：Agent = Model + Harness

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

Agent=Model+Harness

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

截圖自黃佳老師 PPT

近期，多項行業實測證實了一個關鍵規律：

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

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

• Vercel 團隊發現，主動剔除 80% 的 Agent 工具后，流程更精簡，Token 消耗驟降，響應速度反而更快。

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

第一關：如何讓 AI 讀懂（巨型）代碼庫？

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

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

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

1. 建立分層的記憶架構

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

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

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

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

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

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

2. 上下文分診：類比操作系統調度

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

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

截圖自黃佳老師PPT

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

第二關：如何控制 AI 的幻覺？

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

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

解法：結構化上下文 + Hooks 質量門禁

1. 結構化輸入，注入而非生成

減少幻覺的關鍵在于讓 AI 基于已有的代碼進行“注入修改”，而不是讓其“憑空創造”。在向 AI 下達任務時，盡量避免“幫我優化這個函數”等模糊表達，而是要提供結構化信息：

• 反例：幫我優化這個函數。

• 正例：優化 src/utils/parser.ts 的 parseConfig 函數，瓶頸在第 42 行的循環。

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

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

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

}

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

第三關：如何實現經驗復用？

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

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

解法：從 Prompt 到聲明式 Skill

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

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

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

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

• 執行階段： 只有在真正需要動作時，才動態調用掛載的 bundled 腳本/外部資源。

通過這種“只在翻開書的對應章節時才看內容”的設計，在運行多 Skill 系統時，Token 空間可節省達 98% 左右。

第四關：算力貴、用量不透明？探尋 Token 經濟學

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

解法：反向選型、多層路由與 Talker-Reasoner 架構

1. 建立模型選擇矩陣

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

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

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

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

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

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

黃佳老師強調，此時模式的選擇才是設計的核心：

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

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

3. Talker-Reasoner 雙系統

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

借鑒 Kahneman 雙系統理論，可將架構重構為 Talker-Reasoner 協同模型：

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

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

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

第五關：約束與放手

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

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

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

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

合理的工程約束應該放置在動作發生、產生副作用（不可逆操作）的地方：

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

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

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

第六關：復雜的編排載體該如何抉擇？

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

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

在 Harness 設計中，這四種編排載體并不是競爭關系，而是分別映射了現實世界中的四種工作實體：

• Skill = 崗位操作手冊：是靜態的、跨任務復用的知識包與 SOP 模板，代表了 Agent 的職業能力。

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

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

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

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

第七關：如何防止長任務狀態漂移？

痛點：復雜的長任務跑著跑著就偏離了目標

解法：三平面分立架構 + 草稿紙看板

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

其核心解法是推行三權分立的狀態平面管理：

執行調度平面：采用 DAG結構，只記錄任務狀態與執行流，不摻雜任何自然語言敘事與業務參數。

機械參數平面：嚴格鍵值的結構化字典，是業務 API 入參的唯一可審計來源。

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

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

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

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

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

第八關：從 Demo 到產線，如何合規治理？

痛點：能寫代碼不等于能交付系統，誰來對 AI 的生產出錯負責？

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

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

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

兩條鐵的紀律：

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

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

從 Vibe Coding 的熱鬧，走到 Harness Engineering 的嚴謹，這是 Agent 工業化落地的必經之路。

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

如果您對將 AI 真正引入生產系統、優化研發效能、打通 Harness 工程設計感興趣，歡迎添加 CSDN 福利官，領取黃佳老師本次分享的 PPT 與直播回放視頻。