延續前篇，這篇要探討的是「為什麼有效」，畢竟在 AI 的世界中，搞清楚原因永遠是第一順位。

Harness 直譯是「馬鞍」（用翻譯有點怪，以下保留原文）。更白話的解釋是，套在 LLM 外面那層架構——用馬鞍的形象其實相當貼切：它決定模型可以看到什麼、什麼東西可以留下來、什麼東西不會被沖掉、什麼東西會被偵測。就是 Anchor 的 Anchor。

模型是核心，但決定輸出品質的，通常不是模型本身，而是這層 harness 怎麼設計。

LLM 是極強的知識庫，但直接使用它，沒辦法可靠地把那些知識引導出來。更好、更強的模型並不能解決這個問題——需要透過更好的 harness，才能將我們要的引導出來。

回憶一下前篇提到的內容：

  • Static anchor 是 harness
  • Evolving anchor 是會學習的 harness
  • Canary probe 是會監控的 harness
  • Subagent boundary 是防止超載的 harness

沒有一個可以使模型變得更聰明，全部都是讓模型周圍的系統變得更加可控。Harness 才是正確的施力點——不是模型。

斯斯有兩種、Harness 也是

AI 大廠提供的 harness 主要用於工具調用、狀態管理、錯誤處理⋯⋯讓 Agent 可以正常運作，但不能保證 Agent「在做我們要的事」。

Anchor 可以。這一層 harness 得我們自己做，因為只有我們才知道自己的需求。

Anthropic 提供賽車場，路要我們自己鋪。

SDD 和 Session Control 差在哪？

SDD（Spec Driven Development，規格驅動開發）的核心是：在 AI agent 動工之前，先寫一份結構化規格（constitution.md、speckit），定義要蓋什麼、邊界在哪、定義「完成」；Agent 依規格走，而不是單純順著對話自由發展。

SDD 和 session control 不是兩個獨立系統——它們是同一套 harness 的兩個連續階段：

階段 做什麼
SDD 動工「前」：在事情發生之前就先用結構化的方式把模型的工作包起來
Session control 動工「後」：在 session 進行時用框架把 LLM 的工作匡起來

兩者的區別也對應了兩個常見概念的分野：

概念 定義
Prompt engineering 「怎麼問 LLM」更好
Context engineering 「LLM 在什麼環境下運作」更好

說人話

大學時期有一門選修課叫做「語言表達」，學習「怎麼好好說話」。說話和寫作一樣也是有訣竅的：發音方式、斷句、甚至搭配肢體動作，都會影響聽眾對訊息的接收和理解。

Markdown 也是——需要足夠清楚到自己知道自己在說什麼、足夠清楚到能寫下來、足夠清楚到寫下來的內容，丟進機器、無需解釋也能被正確理解。

下面有兩種版本的Anchor，除了字數之外，大家可以找出差異在哪嗎？

版本一
這篇是關於 AI session quality control 的文章。請用專業語氣講解，替換掉裡面的專業術語，以保持易讀性

版本二
核心論點：這篇文章在探討 session 劣化的原因是 session 架構不完整，不是因為模型不夠強。不要把這篇文章包裝成模型能力問題。

術語定義：請勿單純直譯，若非台灣地區、繁體中文使用者慣用的軟體開發術語，請維持原文，並隨後附上文中針對該詞彙的相關描述。

語氣：論點優先，核心主張不打太極。不要用「視情況而定」或「兩邊都講但不選邊」這種寫法。

第二個版本同時做到三件事：

  1. 講了該做什麼，以及不該做什麼
  2. 定義術語、不假設共識
  3. 給予具體約束、而不是揮揮手喊一個感覺

實際流程

  •  
     
    定義好 Anchor
  •  
     
    確認 LLM 對於任務的理解正確
  •  
  •  
     
    段落轉換、長對話之後、或任何 LLM 的回應感覺「有點怪」的時候，讓 LLM 重述核心論點。如果此時理解跟 Anchor 產生誤差，就代表 session 已經劣化到該管理的程度，最快的方式就是直接載入 Anchor 新開一個對話
  •  
  •  
     
    更新 Anchor 定義
  •  
    依此類推

小結

Prompt engineer、Session engineer，最後是 Harness engineer。再聰明的學生也沒辦法自己教會自己（通常是學歪的比較快），所以LLM 產出的品質，永遠掌控在我們手上。