如果你不懂 Harness，面試 AI 產品經理的時候肯定會被刷掉了。

雖然面試官可能也不懂，但是你有沒有說到點子上對方是可以聽出來的。

可能你了解過 Harness 的概念，但如果有沒有真正下手做過，回答時是能被看出來的。

不止 AI，很多其他領域也都是這樣的：沒有在真實場景下通過解決真實的問題掌握的技能，就一定會有濃濃的“紙上談兵”感。

但 AI 行業這么新，真正落地了的 AI 產品本身就沒多少，怎么才能沒做過但也能回答出那種實操感呢？

今天用這篇超長的文章，教大家怎么“駕馭”一個新概念。

核心思路很簡單：模擬場景 → 盤點場景問題 → 用技能解決問題

我們以 Harness 這個新詞為例，通過模擬“我如何在設計寫作 Agent 時應用 Harness 工程策略一步一步優化產品”這個流程，解決三個問題：

1. 1. 幫助還不了解 Harness 的 PM 掌握這個新概念

2. 2. 幫助了解了 Harness 但不知道咋用的 PM 掌握實戰能力

3. 3. 演示如何在面試時回答出“實操感”

以下是把一個“裸奔”的寫作 Agent，逐步通過一系列 Harness 策略“武裝”成像 Claude Code 一樣穩定的真·Agent 的過程。

其中關于當前階段存在問題剖析、如何應用 Harness 策略的論述，就是你要在面試的時候講出來的“實操感”。

從零到一：一個寫作 Agent 的 Harness 工程迭代

模擬場景：開發一個「寫作 Agent」——用戶提供寫作主題和風格參考文章，Agent 聯網調研后在指定路徑下輸出文稿。

核心思路：以這個寫作 Agent 為例，演示如何從一個「出廠配置」的基本 Agent 描述，逐層疊加 Harness 策略，最終形成一份可靠的開發規格。每一層都解決上一層暴露的問題，循序漸進。

第零章：需求背景

用戶是誰？

一位內容創作者。他想寫一篇關于某個主題的深度文章，手頭有幾篇風格參考文章，希望 AI 幫他完成「調研 → 構思 → 撰寫 → 修改」的全流程，最終在指定文件夾里輸出成品。

我們要造什么？

一個寫作 Agent。它具備以下工具：

用戶輸入：寫作主題 + 風格參考文章（文件路徑）+ 輸出路徑。

Agent 在輸出路徑下生成最終文稿。

為什么要用這個場景演示？

寫作任務有一個好特性：它天然是一條鏈路（調研 → 大綱 → 初稿 → 潤色），步驟明確但不瑣碎，適合展示 Agent 如何規劃、如何執行、如何從錯誤中恢復。而且它不需要復雜的代碼工具鏈，方便產品經理理解每一個 Harness 環節的意圖。

v0.1：出廠配置 —— 最基礎的 Agent 描述

「模型 + 循環 + 工具 = 一個能動的 Agent。就像新手機出廠設置，能打電話，但還沒裝 App。」

核心思路

一個 Agent 的最小構成只需要三樣東西：

1. 
   

   1. 循環（Loop）：接收需求 → 推理 → 調用工具 → 拿到結果 → 繼續推理，直到模型認為任務完成。

2. 2. 工具（Tools）：讓模型能和真實世界交互——讀寫文件、搜索網頁。

3. 3. 規劃（Planning）：讓模型在動手前先想清楚「要分幾步做」。

V0.1 描述

這是面向 Coding Agent 的提示詞版本，畢竟現在產品經理的工作流程已經不再是 PRD → 原型圖 → 開發協(si)作(bi)了。

這個描述能跑嗎？

能。但大概率會遇到這些問題：

• ? Agent 搜了 20 條搜索結果，上下文直接撐爆，后邊什么都干不了了。

• ? 寫到一半跑偏了，開始寫跟主題無關的內容，但自己不知道。

• ? 中途斷了（比如工具調用報錯），整個任務就廢了，沒有恢復機制。

• ? Agent 覺得自己寫完了，其實才寫了個開頭就停了（或者反過來，寫完了還不停）。

Agent 怎么知道「我做到哪一步了」？

它不知道。因為我們的產品描述里只定義了「Agent 需要做哪些事」，但沒有定義「做到哪了算哪」。一個沒有任務清單的 Agent，就像一個沒有清單的裝修隊——干到哪算哪，重復干活、遺漏步驟是家常便飯。

v0.2：任務規劃與狀態管理 —— 讓 Agent 知道自己在干嘛

沒有計劃的 Agent 走哪算哪。先列步驟再動手，完成率翻倍。

上一輪的問題

v0.1 的 Agent 有兩個致命缺陷：

1. 1. 沒有任務清單：模型不知道自己完成了什么、還剩什么。在長任務中，前面做的事會被后面的信息擠出注意力，導致重復干活或遺漏步驟。

2. 2. 沒有「完成」的判斷標準：模型憑感覺決定什么時候停。有時任務沒完成就停了（「我覺得差不多了」），有時完成了還在那磨蹭。

Harness 策略

策略一：強制任務規劃（TodoWrite）

在循環開始前，要求 Agent 先生成一份結構化的任務清單。這份清單會作為上下文的一部分，在每一輪循環中持續呈現給模型。

策略二：狀態追蹤與強制回顧

通過 Hooks（自動腳本），每輪循環結束時，自動把任務清單重新拼接到上下文末尾。利用「近因效應」——越靠后的內容對模型注意力影響越大——確保模型每輪都能看到「我做到哪了」。

策略三：熔斷機制

設置最大循環輪次（如 50 輪）。同時，如果連續 3 輪模型沒有更新任務狀態，強制注入提示要求模型審視進度。

v0.2 描述

這樣就好了嗎？

好多了。Agent 現在有清單了，知道自己做到哪了，有「完成」的判斷標準了。

但新問題來了：

• ? 寫作任務需要搜索大量資料，每條搜索結果幾千字。搜 10 條，上下文就滿了。Agent 讀了參考文章（可能 5000 字）又搜了幾輪資料后，上下文窗口已經撐到極限，后面寫大綱、寫初稿的空間不夠了。

• ? Agent 搜資料時搜到了太多無關內容（比如搜「氣候變化」結果出來一堆廣告），這些垃圾信息占著上下文不走。

上下文窗口是有限的，怎么讓 Agent 在有限空間里「無限」地工作？

v0.3：上下文管理 —— 在有限空間里「無限」工作

上下文窗口是 Agent 的工作臺。臺面就這么大，你得決定放什么、不放什么、什么該收起來。

上一輪的問題

上下文窗口（Context Window）就像一個工作臺，空間有限。

一個 1000 行的文件約 4000 token，搜索結果可能上萬 token。

寫作 Agent 的完整工作流——搜資料 × 多輪 + 讀參考文章 + 寫大綱 + 寫初稿 + 潤色——輕松突破 100K token。

如果不做管理，要么上下文撐爆導致任務中斷，要么舊信息被擠出導致模型「失憶」。

Harness 策略

策略一：首輪上下文精準組裝

系統提示詞不是「一股腦全塞進去」，而是分層組裝：

策略二：消息歷史滾動壓縮

每輪工具調用的結果不會永遠留在上下文中。當消息列表增長到一定程度，早期的工具調用結果會被「歸檔」——替換為一條摘要 + 指向原始文件的路徑。模型如果需要回顧，可以主動讀取文件。

這就像瀏覽器標簽頁：你看完一個網頁就關掉它，釋放內存；需要時從歷史記錄里重新打開。

策略三：Subagent 分流

搜索環節特別適合用 Subagent（子代理）。主 Agent 發出指令「幫我搜一下 XX 主題的最新進展」，Subagent 用自己的獨立上下文去搜索、篩選，只把結論摘要返回給主 Agent。

好處：主 Agent 的上下文里不包含搜索結果的原始全文，只有一句話摘要。10 條搜索 × 每條 3000 字 = 30000 字的原始結果，壓縮成 10 條 × 每條 50 字 = 500 字的摘要。

策略四：技能列表（Skills）按需加載

如果 Agent 有多種「寫作技能」（如學術寫作、公眾號寫作、商業文案），不需要在系統提示詞里塞入全部技能的完整說明。只需放一個技能目錄（名稱 + 一句話描述），當模型判斷需要某種技能時，再加載完整說明。

V0.3 描述

上下文管理好了，然后呢？

Agent 現在能在有限的上下文空間里把任務執行完了。但有一個新風險：

• ? Agent 在搜索資料時，執行了bash命令curl下載了一個網頁到本地，但寫入路徑時搞錯了，把文件寫到了輸出路徑之外的某個目錄。

• ? 或者更糟——它執行了rm命令，刪掉了不該刪的東西。

Agent 有執行 shell 命令的能力，萬一它做了危險操作怎么辦？

v0.4：沙箱與權限管理 —— 給 Agent 畫一個安全圍欄

不是不信任模型，而是不能無條件信任。每一次工具執行都必須經過安檢。

上一輪的問題

Agent 能執行bash命令，意味著它理論上可以做任何事：讀寫任意文件、執行任意程序、訪問網絡。

即使模型沒有惡意，也可能因為推理錯誤導致破壞性操作——比如把write_file的路徑參數拼錯，寫到了系統目錄。

Harness 策略

策略一：工作空間沙箱

為 Agent 定義一個「工作空間」（即輸出路徑）。所有文件操作的路徑都必須解析為絕對路徑后，校驗是否在工作空間內。

這就是「沙箱隔離」的本質：不是限制 Agent 的能力，而是限制它的活動范圍。就像幼兒園的圍欄——孩子可以在院子里隨便跑，但跑不出去。

策略二：命令分層權限

不是所有命令都應該被同等對待：

策略三：路徑逃逸防護

Agent 在多次目錄跳轉后，可能拼接出../../這樣的路徑意外逃出工作空間。每次執行文件操作前，必須將路徑規范化（resolve），然后校驗是否仍在工作空間內。

V0.4 描述

安全問題解決了，但還有個效率問題

Agent 現在安全了。但我們在 v0.3 版本里提到的「每輪都更新 plan.md」「每輪都檢查路徑」這些操作——誰來執行？

如果全靠模型主動調用工具去做，那就是在浪費模型的注意力。

模型應該把注意力集中在「寫作」這件事上，而不是每輪都要想起來「我是不是該更新一下 plan.md」。

有些操作是機械性的、應該自動執行的，不需要模型操心。怎么實現？

v0.5：Hooks —— 不需要模型操心的自動化

能用程序做的，就別浪費模型的注意力。Hooks 是 Agent 的后臺管家。

上一輪的問題

到目前為止，很多操作都依賴模型「主動記得去做」：

• ? 更新任務清單

• ? 檢查路徑是否安全

• ? 拼接上下文信息

但模型不是人，它每輪都是一個全新的請求。它不記得「我上一輪是不是忘了更新 plan.md」。

如果靠提示詞要求它做，它可能會忘；如果靠代碼強制它做，它就永遠不會忘。

Harness 策略

Hooks 是在 Agent 循環的關鍵節點自動執行的腳本，不需要模型參與：

常見的 Hooks 設計：

Hook 類型

觸發時機

做什么

路徑校驗

每次文件操作前

解析路徑，校驗是否在工作空間內

任務狀態注入

每輪循環結束時

自動讀取 plan.md，拼接到上下文末尾

進度監控

每輪循環結束時

檢查是否連續多輪未更新 plan.md，是則警告

上下文壓縮檢查

每輪循環結束時

檢查消息總長度，超過閾值則觸發壓縮

自動存檔

每次 write_file 后

將文件變更記錄寫入 work_log.md

V0.5 描述

Hooks 是不是萬能的？

不是。Hooks 解決了「機械性操作自動化」的問題，但有些事不是自動化能解決的——比如用戶偏好。

假設這個寫作 Agent 是一個長期使用的個人助理。

用戶用了三個月，每次都說「我想要簡潔風格」「不要用太多比喻」「開頭要直入主題」。每次新會話都要重復這些。

Agent 怎么記住「上一次」和「用戶的習慣」？

v0.6：記憶管理 —— 讓 Agent 越用越好

沒有記憶的 Agent，每次對話都是初次見面。

上一輪的問題

當前的 Agent 每次啟動都是「白紙一張」。它不記得：

• ? 用戶偏好的寫作風格（簡潔？華麗？學術？）

• ? 之前寫過什么主題（避免重復）

• ? 用戶糾正過哪些錯誤（「不要用這種開頭方式」）

• ? 之前任務的產出（方便復用或引用）

Harness 策略

策略一：自動記憶提取

每次任務結束后，通過一個自動 Hook 調用 LLM，從對話中提取值得記憶的信息：

這些記憶以結構化文本存儲，在每次新會話的首輪上下文組裝時自動注入。

策略二：跨會話檢索

當用戶說「上次我們寫過一篇關于 XX 的文章，幫我引用一下那篇的觀點」，Agent 需要能檢索歷史會話。但不是把歷史會話全部塞入上下文，而是通過關鍵詞檢索，只拉取相關片段。

V0.6 描述

記憶有了，但還有個大問題

一切看起來不錯了。但讓我們回到一個基本問題：

如果工具調用失敗了怎么辦？

• ? 搜索 API 超時了。

• ?write_file因為權限問題寫入失敗了。

• ?read_file讀到了一個二進制文件，返回了一堆亂碼。

• ? 網絡斷了，web_search直接報錯。

在 V0.1 里，如果工具調用失敗，錯誤信息直接塞進上下文，模型可能會困惑、重復嘗試、甚至直接放棄。

在長任務中，一次未處理的錯誤可能導致整個后續流程崩掉。

錯誤發生了，Agent 怎么體面地恢復，而不是直接崩潰？

v0.7：錯誤恢復 —— 小錯不崩，大錯可控

做 Harness 的第一性原理：小錯不跳循環，讓模型自己處理；大錯盡量別犯。

上一輪的問題

在沒有錯誤恢復機制的情況下：

• ? 一個搜索 API 超時 → Agent 不知道怎么辦 → 可能無限重試，浪費輪次。

• ?write_file失敗 → Agent 沒有意識到文件沒寫成功 → 繼續下一步，結果最終輸出缺失。

• ? 多次失敗累積 → 上下文里塞滿了錯誤信息 → 模型的注意力被錯誤信息綁架，忘記自己在寫文章。

Harness 策略

策略一：錯誤信息的結構化處理

工具調用失敗時，不是把原始錯誤日志直接丟進上下文，而是經過 Hook 處理成結構化的錯誤摘要：

? 工具調用失敗：web_search
原因：API 請求超時（30秒）
建議：換一個搜索關鍵詞重試，或跳過該搜索步驟
這是該步驟的第 2 次失敗。如果再次失敗，建議跳過該步驟。

這比一堆 stack trace 對模型友好得多。模型看到這個信息，知道該怎么做。

策略二：失敗計數與降級

對每個工具維護失敗計數：

策略三：關鍵節點的自動存檔

每次write_file或edit_file執行成功后，自動通過 Hook 保存一個快照（或觸發 git commit）。如果后續步驟出錯導致文稿損壞，可以回滾到上一個正確版本。

V0.7 描述

總結：七層迭代全景

回到 Harness 的基本概念

Model + Harness = Agent

我們用七層迭代，展示了「Harness」到底在做什么：

• ?循環讓模型能行動。

• ?任務規劃讓模型不迷路。

• ?上下文管理讓模型不遺忘。

• ?沙箱讓模型不越界。

• ?Hooks讓機械操作不消耗模型注意力。

• ?記憶讓模型能成長。

• ?錯誤恢復讓模型不崩潰。

每一層都不是「錦上添花」，而是在真實場景中必須解決的工程問題。跳過任何一層，Agent 在實際使用中都會暴露對應的缺陷——這就是 Harness 工程的意義。

附錄：給產品經理的自檢清單

如果你正在設計一個 Agent 產品，可以用這份清單逐項檢查：

• ? [ ]循環控制：Agent 有明確的停止條件嗎？最大輪次限制是多少？

• ? [ ]任務規劃：Agent 能生成任務清單嗎？清單會在每輪循環中被回顧嗎？

• ? [ ]狀態管理：Agent 怎么知道自己做到哪了？連續跑偏時有檢測機制嗎？

• ? [ ]上下文窗口：系統提示詞占了多少 token？工具定義占了多少？給對話歷史留了多少空間？

• ? [ ] 上下文壓縮 ：消息歷史太長時怎么處理？壓縮后關鍵信息丟了嗎？

• ? [ ]沙箱：Agent 的文件操作有路徑限制嗎？能逃逸出工作空間嗎？

• ? [ ]權限管理：哪些命令直接執行？哪些需要用戶確認？哪些永遠禁止？

• ? [ ]Hooks：哪些操作可以自動化？不依賴模型主動記得去做？

• ? [ ]記憶：用戶的偏好怎么跨會話傳遞？歷史會話怎么檢索？

• ? [ ]錯誤處理：工具調用失敗時怎么告訴模型？連續失敗時怎么降級？

• ? [ ]用戶追加消息：Agent 干活時用戶發了新消息，怎么處理？中斷還是排隊？

上面是按照 Agent 作業流程的「任務規劃」開始，把流程上每個遇到的問題進行優化的版本。

另一個思路是從 Agent 的另一個基礎組件tools的優化開始的。

最終解決一樣，但卻是思維方式的差異：

• ? 前者是流程導向，通過約束流程的可控性來確保產品的可控性

• ? 后者是原子導向，通過約束基本組件的可控性來保證產品的可控性

篇幅關系，不再貼一遍了，感興趣可以去知識星球搜索Harness Demo獲取。

重要通知：AI產品經理轉型線下課就要開營了

如果你覺得線上學習不夠快，歡迎報名來線下“突擊”

——兩天時間，從認知到實踐，一次性打通。

首期課程安排了北京、上海、深圳三城聯動，每城周末兩天。

• ?第一天：帶你成為會用 AI 的產品經理。 從趨勢認知到工具實操，競品分析、PRD 撰寫、高保真原型圖、AI 賦能可行性分析、RAG 知識庫搭建——產品經理日常工作中最高頻的 AI 應用場景，現場練完

• ?第二天：成為能開發AI 原生產品的 PM。 Agent 原理、Harness 工程策略、Skill 設計、Web Coding——從概念到動手，下午直接分組做項目實戰，現場 Demo Day 展示成果

首發價 2999 元（原價 3699），受場地限制，名額有限。

深圳 6.27-28 → 北京 7.4-5 → 上海 7.11-12

掃描下方二維碼，聯系班主任獲取完整的課程安排