Harness工程：從上下文管理到Agent系統構建

2026年讀完的第三十三本書，這本書寫得非常棒，有關於分析以及講解AI Harness的書籍，目前（2026年上半年）相關的書籍在市面上確實沒有多少，願意對其分析總結和“佈道”的工程師更是少見。 這本書真的值得一讀，我花了幾乎11個小時纔讀完它。書裏面除了介紹AI Harness的概念之外，還利用代碼帶着讀者領略AI Harness的風采。這本書的作者跟我之前讀過的書給AI Harness總結的一致，AI Agent=LLM+AI Harness（本書論點），這幾乎就是AI Harness最貼切的總結了，更有甚者某些網友更是把它形容爲“狗鏈”確實是形象又有趣。但是，我後面通過使用多Agent集羣完成了兩個軟件的開發以後，我對AI Harness又有了不一樣的理解，我現在覺得AI Harness=LLM+AI Agent，Harness作爲工程手段，應該不止於作爲構建單個Agent的核心指導原則，它更應該抽象爲一種具有集合、組織、構建和統籌Multiple AI Agent Group和Multiple LLM Group的工程學原則。 這本書我很早就讀完了，爲什麼現在才把讀後評價寫出來？這是因爲我最近一直在雲服務器跟我搭建的OpenClaw鬥智鬥勇，在消耗了上億的Token後，我對AI Agent和AI Harness有更深刻的認識。特別是我最近把這4個Openclaw放入了同一個Agent Group裏面分派任務讓他們各自執行我分派的各種任務，之前單Agent出現的Context污染再也沒有出現，只是目前最苦惱的是雲服務器的資源喫緊，4個Agent同時工作時對服務器的壓力確實大。 回到這本書的主題上，這本書寫得確實好，除了有概念原理解釋之外，還有豐富的動手實踐環節，裏面案例中的代碼也恰到時宜地添加了幫助讀者理解的註釋。從LLM的提示詞工程，進步到更具有結構化的上下文工程，再發展到集Function Call,MCP,上下文工程，思維架構工程（如深度思考，ReACT），Skill，任務調度工程，記憶工程(RAG)等各種部件大成的AI Agent，圍繞着AI生態的行業發展真的日新月異、風雲變幻。但是我始終都認爲，在駕駛AI這一艘“大船”的過程中，始終要Keep human in Loop，人類作爲船長掌舵着主要的方向，LLM是船的動力裝置，而AI Agent是船體，AI Harness一方面除了在物理上是船的操控系統之外，另外一方面在邏輯上像是船前往目的地的執行方案。 我一直都覺得，多讀書多學習多思考對人生是非常之有幫助的，特別是這本書中居然把我之前讀過和學習過的知識給串聯了起來，讓我在學習這本書的知識中如虎添翼，使我學會AI Harness的核心知識更是水到渠成。例如書中介紹，AI Agent在構建RAG中，向量數據庫可以低成本地持久化存儲，它解決語義的相似性問題；而對於思維工程中最重要的記憶關聯追蹤邏輯鏈以及Agent的任務調度實施上，圖數據庫（Graph Database）作爲重要的基石，把思維鏈、思維圖或者是Agent任務編排和調度執行中最重要的DAG(有向無環圖)進行有效的（數據結構中的Graph）存儲和高效能低成本地使用。總體上來講，這本書真是不錯。

這本書還是非常不錯了，推薦讀一讀，它基本上涵蓋了Agent的Harness工程實踐中常見設計範式和解決方案。 目前Harness工程主流應用場景有兩個：AI編程以及類似OpenClaw（龍蝦）這類Agent工具性場景，另外就是融合到各類細分業務的場景中的解決方案。 大多數軟件開發者是不具備訓練、調試模型的能力和機會的，但對於基於LLM + Harness工程實現Agent的架構與治理入門門檻相對就低很多。 然而，很顯然，具有此類能力的人才目前還是斷層的，大多數開發者還是基於傳統的“編程語言+編程思想+技術框架”的經驗或方案來設計和實現業務功能的設計+開發。 AI編程工具已經將軟件工程的流程進行改寫，重點不再是編程語言、代碼實現，而是如何能夠基於AI編程工具來改造現有的編程流程，比如從產品的PRD開始可能就要考慮如何能夠讓AI更好的理解，更好的生成執行Plan，更好的測試驗證以及迭代。 同時，在業務的具體解決方案中，也從傳統的100%確定的硬編碼，變成了在允許幻覺出現的情況下，讓AI來自動化的進行處理。讓渡了準確性，來獲得更大的能力邊界與靈活性。

作爲程序員，我讀完這本書最大的感受是：寫代碼不再是單純敲命令，而是搭積木。先把上下文搞清楚，再讓AI幫你拼裝。書中把“意圖識別—計劃—執行—反思”四步講得賊明白，讓我意識到真正的工程化纔是王道。別再靠一兩條prompt耍花拳繡腿，得把狀態、記憶、工具都串成閉環，這樣才能跑長時間任務而不翻車。一句話總結：懂上下文，會搭循環，AI才能成事，"代碼是寫給人看的，但讓AI跑得順，纔是真正的編程藝術。"

從今年四月下旬的這一輪的大模型升級（gpt5.5、oups4.7）之後，真是又驚喜又恐懼。效果好到令人髮指，基本上指哪兒打哪兒甚至都不需要指得太清楚，大模型自己能通過上下文了解你的意圖。原本費勁吧啦地告訴他各種注意事項，都不需要了，他自己都能最小單位精準領會和執行你的訴求。 在我們這個行業，以前的大模型，斬斷的是新人鍛鍊學習的機會。現在的大模型已經開始砍老玩家了。因爲它已經聰明到可以把智力活動，降級成另一種廉價體力活動。倒逼所有人不得不完成一次能力上的躍遷，向更上層高價值領域去探索。如果不參與，其他人形成的競爭優勢就自然淘汰後來者。這甚至都不只是是個體之間的競爭，甚至公司、國家，一場多層次立體的“囚徒困境”式博弈。 最好的情況是所有人往上爬之後，真的在上面發現了更大的“蛋糕”。但如果無法創造應有的新價值，可能這場升級到最後就變成一場創造出“無用階級”的轉折點。

1.本書一共7章，可分爲三個部分，第1-3章講述上下文工程概念與案例，4-5章講述Agent的記憶和Skill，6-7章講述Claude Code和Claw，上下文的構建貫穿全書，這些並不能組成完整的Harness，與書名Harness工程有一些偏差； 2. 本書每章有概念和案例，是一個亮點，有助於對概念有具象的認識，但對於部分概念講述的深度不略有不足，如果想深入實踐DeepResearch、Claude Code或者Claw，需要再進行深入瞭解； 3. 書裏提出上下文工程包括感知（意圖識別）、規劃、執行、反思和人機協作，綜合了ReAct、PlanExecute、Reflexion，實際也是Agent的架構組成，構建Agentic loop，不斷迭代，最終完成任務。

一、先把書名翻譯一下：Harness 到底是什麼意思 Harness 本意是馬具——繮繩、鞍、護具那一套。作者沿用了業內那個挺形象的比喻：大模型是匹千里馬，Prompt Engineering 是教馬聽懂人話，Context Engineering 是給馬配地圖和糧草，Harness Engineering 則是把繮繩、馬鞍、賽道護欄、紅綠燈、調度員、質檢員、安全員全套配齊，讓馬能按指定路線跑完長途複雜賽程，而不是撒歡跑偏。 這話聽着像營銷類比，但落到實處其實指向一個挺硬的論斷：模型能力再漲，系統設計的瓶頸也不會消失，只會從"模型不夠聰明"換成"Harness 沒套好"。書裏反覆論證一件事——很多團隊把 Agent 投到 10 步以上的複雜任務就翻車，第一反應是換更大模型，其實是上下文腐壞、架構漂移、無狀態恢復這些工程件沒跟上。馬沒問題，繮繩沒勒住。 作者把 AI 工程化切成三代： • 第一代 Prompt Engineering（2022-2023）：Few-shot、CoT、ReAct，靠提示詞榨模型 • 第二代 Context Engineering（2023-2024）：RAG、向量檢索、上下文壓縮，開始管信息注入 • 第三代 Harness Engineering（2024-至今）：狀態外部化、約束系統、評估層、可恢復調度——書的主場 ------ 二、全書 7 章的骨架，按作者的真實意圖重新排 作者邢雲陽之前寫過 Coze 那本和 MCP+A2A+LangGraph 那本，這本的定位明顯往上抬了一檔：不再教你怎麼搭 Bot，而是假設你已經過了"Hello World Agent"階段，卡在"爲什麼跑不長、跑不穩、跑不出生產"這道坎上。 第1-2章：上下文工程的理論底座 + 五大能力的工程化 這兩章是把"上下文"從 Prompt 的附屬品裏拎出來單獨當一門學問講。作者給了一個挺實在的判斷：Prompt 只是 Context 的一小塊，真正決定 Agent 行爲的是系統提示、工具定義、對話歷史、記憶、檢索文檔、工具結果、用戶消息這七大件，每一件的特性和管理策略都不一樣。 然後拆出五個"元能力"挨個做工程化落地： • 意圖識別：Arch-Router + 小模型微調兜底這套 • 計劃模式：簡單計劃（旅遊攻略類）和複雜計劃（通用拆解）兩種打法 • 反思模式：讓 Agent "思考自己的思考"，運維場景做樣例 • CodeAct：代碼即工具，圖表生成助手做樣例 • 人機協作：Human-in-the-loop，別讓 Agent 全程自動駕駛 這一段最有用的不是五個案例本身，是作者反覆在糾正的那個直覺偏差——很多人以爲上下文越多越好，錯了。OpenAI 自己從巨大指令文件遷移到分層漸進披露，就是因爲往 Agent 裏塞一堆 MCP 工具、冗長文檔、累積對話，不會讓它更聰明，會把它灌傻。書裏給了一條經驗公式：上下文利用率保持在 40% 以下。超過這條線，模型開始進入"Dumb Zone"。 第3-4章：兩個典型案例——DeepResearch 和記憶工程 第3章用 Sequential Thinking 方案把 DeepResearch 從頭到尾碼一遍，第4章講長短期記憶系統，分佈式部署方案給到。這兩章是承上啓下：前面講了零件，這裏給兩個能跑的完整車。記憶工程那章尤其值錢，因爲"記憶"在大多數書裏是提一句 RAG 就過去了，這本書把長短期分層、Mem0 這類方案、分佈式狀態存儲、checkpoint 恢復串起來了。 第5章：Skills——上下文卸載的藝術 這一章是全書我個人最看重的一章，因爲講了個反直覺的東西：不是所有能力都要常駐加載，可以按需掛載。作者用 OpenClaw 的 Skills 機制做例子——默認不加載技能詳情，先掃技能列表（只看名字和描述），判斷要哪個再去讀對應的 SKILL.md。這其實是把"漸進式披露"從 UI 思路搬到了 Agent 的上下文管理上。 然後用釦子搭"運維巡檢 Skill"、用 OpenClaw 測一遍，走通"上下文卸載 → 漸進加載 → 節省窗口"這條鏈路。對做過長上下文 Agent 的人，這一章比前面都對症。 第6-7章：走向 Harness——復現 Claude Code + 構建 OpenClaw 類產品 這兩章是作者真正想寫的乾貨。第6章拆 Claude Code 的幾個核心設計模式：Agent Loop（讓 Agent 能長時間工作的心跳）、SubAgent（分離上下文窗口）、Skills（漸進加載）、Compact（多級上下文壓縮）、Todo（計劃模式）、Task System（持久化任務系統）、後臺任務（慢操作異步）。第7章把前面這些零件拼起來，講怎麼搞一個 OpenClaw 類產品的完整設計模式。 讀完這兩章你基本能明白一件事：Claude Code 這類產品爲啥能跑長任務不崩，不是模型特別，是 Harness 套得特別——Agent Loop + 狀態外部化 + 上下文壓縮 + 子 Agent 分上下文窗 + 持久化任務系統，這幾件套缺一不可。 ------ 三、Harness 這套東西的真正命門，書裏講了但容易滑過去的 作者畢竟是架構師出身，書裏零散塞了不少真東西，我幫你篩幾條最扛用的： 第一條：上下文是稀缺預算，不是垃圾桶。 給上下文窗口設 token 額度，分塊分配——系統提示佔多少、工具定義佔多少、檢索文檔佔多少、歷史佔多少。爆了不是加窗口，是做壓縮和卸載。 第二條：Agent 專業化優於通才。 Carlini 做 C 編譯器項目時把 16 個 Agent 分成編譯器核心、去重、性能優化、文檔四類，每個專家因爲只帶自己領域的信息，天然跑在 Smart Zone。這不是組織問題，是上下文管理問題。 第三條：持久化記憶放文件系統，不放上下文窗口。 Anthropic 的做法是每個新會話啓動，Agent 先讀 git 日誌和進度文件，搞清楚之前做到哪，再挑優先級最高的繼續。有個細節：JSON 追蹤狀態比 Markdown 靠譜，因爲 Agent 不太會亂改結構化數據。 第四條：約束即賦能，不是約束即限制。 這是 Harness 跟傳統提示工程最不一樣的地方——不是告訴 Agent "寫好代碼"，是用 Linter、結構測試、pre-commit hook、LLM 審計器機械地強制執行。當 Agent 可以生成任何東西時它會浪費 token 探索死衚衕，當你把邊界畫清楚，它反而收斂得快。 第五條：熵管理是被低估的那塊。 AI 生成的代碼庫會積累熵——文檔脫節、命名分歧、死代碼、架構漂移。Agent 複製反模式的速度是十倍的，所以得有"垃圾回收"機制：定期掃描過期文檔、讓 Agent 給自己提清理 PR、架構 lint 強制依賴方向。 ------ 四、實戰裏的幾顆暗雷，書裏點到但沒展開透 跟前幾本筆記一樣，摻點我自己（和業內幾個踩過坑的人）的判斷，這些是區分 Demo 和生產的地方： 第一，Remediation Loop 可能不收斂。 Agent 修完 → review 又發現問題 → Agent 再修 → 又冒兩個高危。這種無限 loop 是真實現象，書裏沒提 max retry 和 circuit breaker，但生產環境你必須加。否則半夜跑批把配額燒光還算輕的。 第二，上下文腐壞是慢性中毒。 長任務跑兩小時，CLAUDE.md 說用 ESLint，第5輪工具結果顯示項目實際用 Biome，第8輪用戶說"用我們的 linter 檢查一下"——模型會困惑。書裏提了"最近信息覆蓋舊信息"的原則，但真實項目裏矛盾信息比你想的多，得有 Harness 層主動標註和更新。 第三，LLM 審 LLM 有天花板。 評估層用另一個模型當裁判，短期能跑通，長期會漂移。真上生產的團隊最後都得補人工抽檢 + 規則校驗雙軌。 第四，eval 比訓練難。 這句話在前一本《複合型AI Agent》裏也出現過，這本書從工程側再印證了一遍：你沒法用準確率衡量一個助手，得做任務完成度、路徑效率、工具調用準確率、抗干擾這套多維框架，而且還得 Human-in-the-loop。 第五，架構漂移是最隱蔽的債。 Agent 寫代碼很快，但沒人盯着的時候它會抄反模式、破依賴方向、把 util 寫成垃圾場。解決方式不是換更聰明的模型，是 ArchUnit 類結構測試 + pre-commit hook + CI gate 三件套，全是二十年前的老技術，AI 時代反而成了最硬的護城河。 ------ 五、這本書跟前幾本怎麼擺、適合誰 跟這個系列裏前幾本做個對照你就清楚該翻哪本了： • 想零代碼搭個 Bot 玩 → 翻《釦子》那本 • 想搞懂 Agent 的規劃/記憶/工具/評估這套理論架構 → 翻《複合型AI Agent》 • 想看二十年後的指數狂想 → 翻《奇點更近》 • 想解決"我的 Agent 爲啥跑不長、跑不穩、跑不出生產"→ 翻這本《Harness工程》 這本書最適合的人是：有開發/架構背景，被長任務 Agent 坑過，或者正在想把 Agent 從原型推到生產那段。作者本身是聯通雲 AI 與容器那邊的架構師，書裏代碼和案例都帶雲原生味，不飄。 不適合的人有兩種：一種是隻想拖拽搭 Bot 的，這本對你太重，回 Coze 那本；另一種是期待"看完就能造 AGI"的，這本講的是繮繩不是馬，馬還是得你自己挑。 ------ 六、合上書的一句話 這本書教的本質上不是 Agent 怎麼寫，是當模型足夠聰明之後，工程側的瓶頸從"怎麼讓它回答對"切換到"怎麼讓它跑完、跑穩、跑不偏、跑可追責"。Prompt 管說什麼，Context 管給什麼，Harness 管怎麼轉——三層裏前兩層前兩年的書講透了，第三層是這本的增量。 作者反覆在書裏透的一個態度我挺認同：Agent-first 的世界裏，軟件工程的本質不再是"寫代碼"，而是構建一個讓 Agent 能穩定、高質量完成任務的系統環境。這話聽着玄，落到地上就是——狀態外部化、約束系統、評估層、可恢復調度、架構 lint、熵管理，這幾件套你湊不齊，模型再聰明也白搭。 說白了，前幾年大家忙着馴馬，現在得有人忙着做馬鞍和護欄了。這本乾的就是後者。

大多是概念堆砌，停留在表面，簡單看一下就可以了。現在的智能體，像claude code 和codex已經提供了很完善的框架，只把傻瓜式的skill設計留給了用戶，而skill設計的過程用自然語言對話就可以調動智能體自動完成了。想要剖開智能體和大模型的本質，需要有大量的知識儲備與架構學習，這纔是學習大模型最重要的點，理解了原理應用才能可控。

沒有任何看的必要，對於核心問題(如模型演進對harness的影響)視若不見，對於具體的場景閉口不談(全都是什麼旅遊計劃這種虛的不得了的)，deepsearch講了半天就講了個聯網搜索，中間那個什麼計劃模式的代碼更是令人啼笑皆非，問題太多了不一一列舉。 基本都是過時很久的東西東拼西湊胡亂歸納出一些點，按概念分個章節，然後用ai生成的。 實用價值沒有，懂一點的人不用看，不懂的人又看不懂，很符合我對國內這種書籍的刻板印象

一句話概括 + 閱讀定位一句話概括：本書把"如何用好大模型"從寫提示詞的技巧，升維成一套"爲AI套上馬具"（Harness）的工程方法論——上下文工程負責把信息"喂對"，Harness工程負責把環境"造好"，讓 Agent 在真實世界裏可控、可驗、可靠地幹活。 適合誰讀：有開發背景、已走出 Prompt 階段、開始構建 Agent 系統的工程師 / 架構師 / 技術管理者 解決什麼真問題："會調 API 卻建不出可靠 Agent"——上下文失控、狀態難維持、工具鏈不閉環 閱讀層級：基礎（概念認知）→ 進階（設計模式）→ 應用（生產級部署） 知識體系地圖全書以"從單 Agent 到多 Agent"爲敘事主線，七章分三層遞進： 基礎層 · 第1章 從提示詞到上下文工程：建立"上下文工程"認知——核心思想、系統結構、Agent 技術路線圖。 進階層 · 第2章 五大核心能力工程化：意圖識別、計劃、反思、CodeAct、人機協作逐一落地。 應用層 · 第3章 DeepResearch 案例：DeepSearch 引擎 + Sequential Thinking 代碼實現。 應用層 · 第4章 記憶工程：短期/長期記憶、Mem0 標準化、分佈式高可用部署。 進階層 · 第5章 Skills：上下文卸載：把領域知識/流程外置爲可加載技能。 高階 · 第6章 復現 Claude Code：Agent Loop、上下文壓縮、持久化與異步、多 Agent Teams。 高階 · 第7章 Claw 類產品設計：類 OpenClaw 產品核心架構與 NanoClaw 實踐。 核心概念釋義（術語小詞典）上下文工程：程序化、系統化地採集/過濾/組合信息餵給模型的範式。"上下文"是輸入模型的核心語義載體，"工程"是動態構建與持續優化——不是潤色提示詞，是編排信息。 Harness工程：爲 AI 構建運行環境與反饋機制（原意"馬具/駕馭裝置"）。重心從"優化模型本身"轉向"優化模型運行的環境"。 Agent：具備理解、計劃、反思、行動（調用工具/執行代碼）能力的自主系統，區別於一次性問答的 chatbot。 ReAct：Reasoning+Acting 交替的純提示詞範式，零訓練依賴。"思考→行動→觀察→再思考"循環。易混點：它是"思想範式"，FC 是實現"行動"的手段，二者可分離。 CodeAct：以"生成並執行代碼"爲核心決策手段的 Agent 範式。≠ Cursor/Claude Code 等 Coding Agent（輔助人寫代碼的工具）。 Function Calling：模型原生輸出結構化工具調用的能力。ReAct 在工程實踐中常借它承載"行動"，但非概念上的硬依賴。 記憶系統（Mem0）：Agent 記憶層的標準化實現。短期記憶≈內存（會話結束清空），長期記憶≈硬盤（獨立於模型之外永久留存）。 Skills：上下文卸載技術。把特定領域知識/流程外置爲可加載模塊，按需注入，爲主上下文"瘦身"。 核心知識點深挖01 上下文工程 ≠ 提示詞工程（購車案例） 原理：上下文工程的本質，是一套對信息進行系統化採集、過濾與組合的技術範式。"上下文"是輸入模型的核心語義載體，"工程"是程序化、系統化的動態構建與持續優化。提示詞工程是人寫死的靜態話術；上下文工程是系統按場景動態拼裝的信息流。 書中論證：熱門劃線"通過這個購車案例，可以透視上下文工程的本質：它並非單純的提示詞潤色，而是一套對信息進行系統化採集、過濾與組合的技術範式"。書友想法中多人質疑"還是提示詞優化"，作者點破：區別在於程序化、系統化、動態構建。 示例說明：用戶說"想買20萬左右省油安全的家用SUV"。提示詞工程：你寫"請推薦SUV"。上下文工程：系統自動採集用戶畫像（家庭人口/通勤距離/預算上限/城市補貼）、歷史交互（曾看混動）、知識檢索（在售車型參數/碰撞成績）、工具調用（實時報價），組合成"增強上下文"再問模型——結果相關、準確、安全。 現實映射：提示詞是寫死的，上下文工程是動態拼的；需求模糊時，上下文工程還能反向讓 AI 反問澄清（意圖識別），這是靜態提示詞做不到的。別再把"上下文工程"矮化爲"提示詞優化"。 02 AI開發的兩條路徑：深耕LLM vs 專注Harness 原理：AI 開發的脈絡只有兩條——要麼深入研究 LLM 本身（提升推理、降本），要麼專注 Harness，讓模型在真實世界做更多有價值的事。當模型能力差距縮小，同一模型配不同 Harness，表現天差地別——環境工程纔是下一階段的勝負手。 書中論證：熱門劃線"爲其配套不同的Harness，其表現卻天差地別。這也解釋了爲什麼在AI編程領域，越來越多的程序員開始告別IDE類軟件，轉而擁抱Claude Code這類看似不習慣的命令行工具"。 示例說明：同一個開源大模型，套上 Claude Code 式 Harness（約束規則+驗證迴路+反饋機制）與裸 IDE 插件相比，寫代碼、改 bug 的可靠度與可調試性完全兩樣——前者"我做好了"背後有測試退出碼背書，後者只是自我感覺良好。 現實映射：多數工程落地問題（幻覺、越權、不可驗）靠 Harness 解決，而非換更大模型。把瓶頸都歸咎"模型不夠強"是常見誤區，先問"我的馬具套對了嗎"。 03 五大核心能力工程化：感知-規劃-執行-反思 原理：上下文工程的核心邏輯圍繞感知、規劃、執行、反思四大模塊。第2章把意圖識別、計劃模式、反思模式、CodeAct、人機協作五大能力逐一工程化。其中意圖識別尤其關鍵——成熟 Agent 必須融合對話上下文+用戶畫像+歷史記錄，推斷表層語句背後的深層需求。 書中論證：熱門劃線"一個成熟的Agent系統必須融合當前對話上下文、用戶畫像、歷史交互記錄等多維信號，對深層需求進行精準推斷"。書友以"泰斯勒定律（複雜度守恆定律）"點出：開發者不消化複雜度，就會被轉嫁給用戶。 示例說明：用戶說"幫我寫個腳本"。表層意圖=寫腳本；深層可能=每天凌晨3點備份數據庫並壓縮上傳OSS、失敗告警。意圖識別需反問澄清→計劃模式拆子任務→CodeAct 生成代碼運行→反思校驗結果→必要時 Human-in-the-loop 確認。 現實映射：別要求用戶"寫清需求、自帶上下文"。Agent 的價值在於主動消化複雜度。意圖識別不準，後面全錯——它是整個流水線的第一道閘門。 04 高配規劃 / 低配執行的異構模型策略 原理：用強模型做複雜問題拆解（規劃），用弱/小模型做具體動作執行。既保障拆解質量，又控制整體推理成本——生產環境常見實踐。 書中論證：熱門劃線"這種高配規劃與低配執行的異構模型策略，既能保障複雜問題的拆解質量，又能有效控制整體推理成本，是生產環境中常見的工程實踐之一"。 示例說明：plan-executor 模式——大模型（如 GPT-4 級）產出 CUA 執行計劃，小模型/輕量 RPA 執行點擊、輸入等原子動作。書友實戰過此模式，戲稱"勞心者治人，勞力者治於人""避免大炮打蚊子"。 現實映射：反例——所有環節都用最貴模型→成本爆炸；多輪反思循環燒光 token。異構策略是工程性價比的核心槓桿。 05 記憶工程：短期≈內存，長期≈硬盤 原理：短期記憶是會話內上下文，隨進程結束清空（≈內存）；長期記憶通過獨立於模型的存儲介質實現信息永久留存（≈硬盤）。需標準化存取、更新、檢索。 書中論證：熱門劃線"短期記憶類似於計算機的內存…長期記憶則等同於硬盤"；第4章給出 Mem0 標準化實現 + 容器化高可用分佈式記憶系統部署方案。 示例說明：用戶連續三天讓 Agent 寫週報。短期記憶=本次會話上下文（內存，結束清空）；長期記憶=把"用戶偏好表格呈現、常用數據源、彙報對象"持久化到數據庫（硬盤）。下次自動錶格化，無需重述背景。 現實映射：不做長期記憶→"金魚記憶"：跨會話失憶、長任務因上下文超限而質量崩塌。需狀態持久化 + 主動重啓（Token 超閾值如70%時存檔開新會話）。 06 多Agent系統與上下文污染（SubAgent隔離） 原理：單一 Agent 上下文越堆越長→噪聲累積→幻覺。MAS"分而治之、協同作戰"：leader 把子任務派給 subagent 獨立處理，只回傳結果，自身上下文保持乾淨。從上下文工程視角看，MAS 的本質就是解決上下文污染問題。 書中論證：熱門劃線"若從上下文工程的視角重新審視，MAS的本質在於解決上下文污染問題"；書友總結"leader只使用sub的結果，保持了自身上下文的'乾淨'"。 示例說明：讓一個 Agent 既寫代碼、又做評審、又寫文檔、又跑測試——上下文塞滿，後期開始胡說。改爲：主 Agent 只做調度，subagent A 寫碼、B 評審、C 寫文檔，各自獨立上下文，主 Agent 只匯總結果。 現實映射：書友擔憂"多Agent像版本陷阱，燒光token"。MAS 不是銀彈——需配合上下文隔離與成本預算，否則照樣失控。先在單 Agent 把上下文管住，再談拆分。 模型與框架提煉框架一 · 三階段演進（全書認知主線）：Prompt 工程（表達）→ Context 工程（信息）→ Harness 工程（執行/駕馭）。回答"我們到底在優化什麼"。類比爲：對野馬喊話 → 給野馬遞小抄 → 給野馬套上完整馬具。 框架二 · 感知-規劃-執行-反思（Agent系統結構）：對應第2章五大能力的工程抓手。 感知：採集意圖+上下文、匹配模型（意圖識別、用戶畫像） 規劃：把任務拆成子任務（計劃模式、異構模型） 執行：調用工具/代碼（Function Calling、CodeAct、Skills） 反思：校驗結果、自我修正（反思模式、驗證迴路、Human-in-the-loop） 難點解讀難點一：ReAct 到底要不要依賴 Function Calling？ 原文："ReAct的核心優勢在於其零訓練依賴……僅通過精心設計的提示詞即可引導LLM交替執行思考與行動。" 逐句拆解：ReAct 原論文定義的是文本循環，純靠提示詞模板，不需改模型權重（零訓練依賴）。但工程落地"行動"需調真實工具，FC 是模型原生結構化輸出工具調用的能力——於是讀者爭論"React也依賴模型的fc能力"。 類比/示例：概念上 ReAct 可由純文本解析實現（模型輸出"Action: search(query)"，程序解析執行），不強制 FC；現實中常借 FC 更穩，但那只是更省事，不是必須。 破解：ReAct 是"思考-行動交替"的範式（思想），FC 是實現"行動"的手段（技術），二者可分離。作者說"零訓練依賴"指不微調，不是指不碰 FC。 難點二：聯網搜索 = DeepSearch？ 原文："聯網搜索的本質是LLM通過理解用戶意圖……調用搜索引擎API……最終生成帶有來源參考的回答。這一功能也被稱爲DeepSearch。" 逐句拆解：前半句描述"聯網搜索/基礎RAG"機制，是對的；但把整個功能直接叫 DeepSearch 略片面。書友 anacleto 長評正指出這點。 類比/示例：真正 DeepSearch 核心是"深度"——第一次搜完，據結果自主決定要不要二次搜；面對衝突信息做交叉驗證；專門處理需要長閱讀、對比分析的複雜問題。普通聯網搜索是"搜一次就總結"。 破解：把 DeepSearch 理解爲"會自己多輪搜、會交叉驗證的研究員"，而非"搜一次就總結的助理"。 難點三：Code Agent ≠ Coding Agent 原文："Code Agent並不是Cursor或Claude Code等AI輔助編程工具（Coding Agent），而是一種以生成並執行代碼爲核心決策手段的Agent範式。" 逐句拆解：Code Agent 把"寫代碼並運行代碼"當作核心決策方式；Cursor/Claude Code 是輔助人寫代碼的工具，決策權仍在人。 類比/示例：書友一語道破邊界——"Code agent是用LLM直接生成能處理問題的代碼，運行後解決問題；如果問題本身就是輸出特定要求的代碼，那就成了類似Claude Code的編程AI工具"。Code Agent 是範式，Coding Agent 是產品。 破解：區別在於"決策主體"——Code Agent 自主用代碼達成目標；Coding Agent 在人的指揮下生成代碼。 行動指南把項目規則固化進環境（立刻能做）：用 AGENTS.md / CLAUDE.md 寫死編碼規範、禁止事項，每次啓動自動加載，避免 AI 自由發揮。 用"高配規劃+低配執行"降本（立刻能做）：複雜拆解交給強模型，原子動作交給小模型/RPA，控制整體推理成本。 長任務狀態持久化（立刻能做）：用 PROGRESS.md 或數據庫記錄進度/斷點；上下文超閾值（如70%）主動存檔開新會話，防質量崩塌。 建可觀測"行車記錄儀"（長期建設）：全鏈路記錄每步操作、工具調用、Token 消耗、決策依據，讓 Agent 從黑盒變玻璃盒。 用 SubAgent 隔離上下文污染（長期建設）：複雜任務分派子 Agent 獨立上下文，主 Agent 只匯總結果；先在單 Agent 把上下文管住，再談拆分。 把可複用領域知識外置爲 Skills（長期建設）：特定流程/知識做成可加載技能，按需注入，減少主上下文噪音、提升複用。 評測時"換 Harness 而非只換模型"（長期建設）：同一任務對比"同一模型+不同 Harness"的效果，定位瓶頸在模型還是工程。 延伸書單《AI Agent 開發實戰：MCP+A2A+LangGraph 驅動的智能體全流程開發》——邢雲陽（同作者）。框架/LangGraph 層補全，與本書形成"原理→框架實戰"閉環。 Building Effective Agents（Anthropic 官方博客）——Agent 設計模式經典參考，釐清 Workflows 與 Agents 邊界。 LLM Powered Autonomous Agents（Lilian Weng 技術長文）——背景理論奠基：規劃、記憶、工具使用、強化學習四大支柱。 Mem0 官方文檔與論文——記憶工程落地權威參考，配合本書第4章實操部署。 結語 / 個人研判爲其配套不同的Harness，其表現卻天差地別。 這句話是全書的錨點，也是我最觸動的判斷：模型能力差距在縮小，工程能力（Harness）纔是下一階段的核心競爭力。 結合我的售前/雲架構視角，Harness 工程的精髓，恰是"底表思維"的工程化表達——底層模型能力（業務邏輯）未經確認不動，而在其外層構建約束、驗證、反饋迴路，纔是系統可控性的真正來源。下一階段 AI 應用的競爭，不在"誰的模型更大"，而在"誰的環境更會駕馭"。對人類掌舵、智能體執行，是治理，也是藝術。

介紹了harness工程建設的方方面面的內容，內容很全面，美中不足的是代碼的排版是混亂的，基本無法閱讀。