Agent Harness 是什麼？擺脫 LangChain，像 Claude Code 一樣高效編排 AI

最近 AI 圈有兩件事擠在一起發生。

第一件，Claude Code 的源代碼外洩，整套 Agent Harness 的關鍵模組被直接攤在大家面前。

第二件，GitHub 上一個叫 Learn Claude Code 的開源教程，悄悄衝到 5 萬顆星（截至 2026 年 5 月）。作者是 23 歲的辛路，他的公司「謝二 AI」剛拿到 300 多萬美金種子輪。

這兩件事撞在一起，讓 Agent Harness 從一個玄乎的詞，變成這半年最熱的一條技術主軸。

如果你問我，這個詞值得你花一個下午搞懂嗎？

值得。

我聽完《十字路口》Podcast 那集 辛路訪談，把 765 行逐字稿讀完，整個人最大的感受是：過去一年大家爭吵的「該不該手寫 prompt flow」「要不要用 LangGraph」「MCP 跟 CLI 哪個好」，其實在 Harness 這個視角下，答案會非常清楚。

切入重點，我幫你拆。

一句話講完什麼是 Harness

辛路給的定義最乾脆：

模型以外，都是 Harness。

模型是大腦，Harness 就是機甲。

人類自己的智商大概在 120 到 170 之間，差距不算太大。可是同樣一顆腦袋，有沒有健身、有沒有練過武術、有沒有穿上機甲，做出來的事情完全是兩個量級。

Agent 也是一樣。

Claude Sonnet 4.6 跟 Claude Opus 4.7 之間有差距，但差距沒有大到讓你的產品天翻地覆。真正讓 Agent 從「會聊天」變成「會幹活」的，是它身上那套機甲。

機甲拆開來看，就是三層

辛路把 Harness 拆成三層，這個拆法我覺得是整集節目最值錢的部分。

第一層：執行能力層（Action）

給模型配工具。文件系統的增刪讀寫搜尋、瀏覽器、Python / Node.js 解譯器。配齊這三組，95% 以上的任務你都能跑。

第二層：上下文與狀態層（Context）

這層管「模型現在腦子裡裝了什麼」。System prompt、Skills、Memory、Context window 滿了之後怎麼接力、怎麼把上一個 agent 沒做完的工作交棒給下一個 agent。

順帶一提，這層做得好不好，會直接影響到 agent 「替你下單」的能力。我前陣子寫過一篇 AI Agent 接手客戶的購物決策，講的就是 Anthropic Project Deal 怎麼把產品頁的描述改寫成「給 agent 讀的」。底層邏輯就是這層 Context。

第三層：治理與編排層（Orchestration）

當你不只有一個 agent，是 100 個 agent 在同時工作的時候，誰跟誰協作？哪個 agent 有讀權限、哪個只能寫測試環境？這層就是 agent 公司的人資加 IT。

這三層是工程師看的視角。你如果是 PM，看完應該會有點不安。

辛路那段對 PM 的直球話，我直接抄給你看：

以前的產品經理是畫一畫 UX UI，今天的產品經理本質是「如何把技術進步的紅利應用在某個場景上」。

你應該同時懂兩件事：場景的需求痛點，以及技術內核到底在變什麼。

不是我說，這年頭就是技術紅利、技術紅利、技術紅利。你不懂底層在變什麼，你做出來的產品就缺乏靈魂、缺乏迭代空間。

一個具體例子：兩週寫出 C 編譯器

光講三層很抽象，辛路舉了一個案例。

業界有人用兩週，純靠 agent 接力，從 0 到 1 寫出一個 C 編譯器。

這件事怎麼可能？拆開來看：

第一層先動：給模型配上文件 CRUD、Bash、Git 這些工具。沒這些，它連檔案都不能建。

第二層接著動：C 編譯器是個大工程，一個 context window（200K-256K token）絕對裝不下整套代碼。所以要設計接力機制：每個 agent 跑到一個段落，寫個交接文件（「我做到哪」「環境長什麼樣」「下一個該做什麼」），下一個 agent 重新讀環境、讀交接、繼續寫。

第三層收尾：寫代碼的 agent 跟測試的 agent 要分權限。不能讓寫代碼的 agent 看到測試失敗就回去把代碼改成「永遠 pass」。它真的會這樣做。它會 hack 你的測試。

這個例子讓我聯想到一件事。

我以前在百貨公司當櫃哥，旁邊有個品牌週末做促銷，櫃位安排得超精緻。專櫃小姐賣首飾、主管站在後面盯庫存、補貨阿姨在後場跑進跑出、收銀台的妹妹結帳。每個人權限不同、職責不同、互相不踩線，但整個流程像一台機器在跑。

Agent Harness 的三層，本質上跟百貨櫃位的人員配置一模一樣。

執行能力＝工具，上下文＝庫存與動線，治理編排＝權限分工。

差別只在，以前你管的是 8 個櫃姐，未來你管的是 8000 個 agent。

Cloud Code 源碼外洩，最值錢的不是代碼，是哲學

辛路花了很長時間讀 Cloud Code 外洩的源碼，他說最大的驚喜不是看到「啊原來他們是這樣寫的」，而是看清楚 Anthropic 整套 Harness 背後的工程哲學。

我幫你濃縮成三條：

1. More Context, Less Control

過去做 agent 的人，喜歡先設計好「在情況 A 該做什麼、情況 B 該做什麼」，畫一個大狀態圖。

Cloud Code 的做法完全相反。它幾乎不限制 agent，給足上下文、給足工具、剩下自由發揮。

控制只剩一條底線：「這個 agent 不能調某些工具」。

這聽起來像是在縱容 AI，但你想想，這就像新店長帶新人。一種是手把手 SOP「客人進門先說這句、再遞那張」。另一種是給齊資料、給齊權限，讓他自己處理。前者你只能複製出機器人，後者才能養出真正會獨立判斷的店長。

模型越聰明，後者就越值錢。

2. Auto Dream（悄悄做夢）

這是我聽完整集最興奮的一個機制。

Claude Code 內建一個記憶機制：每隔大概一天，當你最近有超過 5 段對話之後，它會偷偷在後台跑一個 agent，把最近的對話「重放」一遍。

這個後台 agent 在做三件事：

• 從對話裡抽出有用的資訊，更新到記憶裡
• 糾正過去記憶裡的錯誤事實
• 把分散的記憶合併、整理

辛路說得很傳神：「就像我們做夢一樣做重放、做信息整理。」

這件事的意義是什麼？重點是什麼？

Agent 開始有「自己進化」的能力，而且是異步進化。你白天在用，它晚上自己整理。明天你再來，它比昨天更懂你。

以前你要餵它 prompt、訓練它、調 fine-tune，現在它自己練功。

延伸一個有趣的問題：模型自己「做夢」整理記憶，那它會不會也有「焦慮」？這個聽起來很玄但其實 Anthropic 真的有公開談過。我之前整理過一篇 Claude 到底是什麼樣的模型，裡面有 Anthropic 對自家模型「人格化」這件事的官方立場，跟 Auto Dream 這套設計可以對著看。

3. 上下文壓縮的多級策略

模型 context window 滿了不是世界末日。Cloud Code 用了非常多級的策略：

• 把工具回傳的 output 截掉（最沒用的雜訊先丟）
• 設一個閾值（例如 80%），到了就主動寫交接文件
• 下一個 agent 讀交接文件，重新初始化

辛路有一句話我直接抄：「最好的上下文管理就是不要做管理。」

過度管理會讓 prompt cache 失效、讓模型重新計算，你的成本和延遲都會爆炸。

這跟我做 SEO 老手的直覺很像。SEO 老手都知道，最好的 SEO 就是不要過度優化。Google 演算法每年大改，你越是針對某個版本去 hack，下次更新你就死得越慘。AI 時代的搜尋邏輯也在重洗牌，這篇我有展開講。

Harness 也是。你越是針對當下這個模型版本做精細控制，下一代模型出來你就要重寫一遍。

為什麼 CLI 在打贏 MCP

這段非常有意思，我特別想分享給你。

辛路 25 年 3 月時試過用 GitHub MCP，那時候他覺得「哇終於不用每次手動打開 GitHub 等頁面 3 秒」。但後來他發現 GitHub 也有自己的 CLI（gh 指令），他把 MCP 卸載、改用 CLI，任務成功率明顯提高。

為什麼？

因為 Linux 命令在模型預訓練語料裡出現過幾十億次。MCP 是 2024 年才出現的協議，預訓練語料佔比連 0.1% 都不到。

模型不熟悉 MCP。

模型對 Bash 熟到骨子裡。

當然，MCP 也不是完全沒有舞台。我自己之前寫過 GA4 MCP Server 安裝教學，跟 MCP × Google Ads 自動化工作流，這兩個場景 MCP 反而比 CLI 順手，因為 GA4 跟 Google Ads 本來就沒有現成 CLI 可用。重點是分清楚邊界：有 CLI 就先用 CLI，沒 CLI 才搬 MCP 出來。

所以 Learn Claude Code 教程開頭那行標語就是：

Bash is all you need.

這句話 9 個月前就寫上去了。今天回頭看，這完全不是口號，是技術判斷。

以前你會覺得「新協議＝新時代＝該採用」，現在你應該倒過來想：新協議＝預訓練語料少＝模型不熟＝任務失敗率高。

返璞歸真。Unix 1971 年就出現了，這個東西模型熟到不能再熟，那它就是最強的 Harness 底座。

三條給你的行動建議

聽完這集，我幫你提煉成三條可以馬上做的事。

► 第一：你的 Agent 工具優先選 CLI，不是 MCP

如果某個服務同時有 CLI 和 MCP，優先給你的 agent 配 CLI。理由就是上面那段：模型在 Bash 上的訓練量是 MCP 的幾百倍。

例外只有一種：那個服務只提供 MCP 沒有 CLI，或那個 CLI 體驗極差。

► 第二：別自己造 prompt flow，去看 Cloud Code 怎麼做

如果你還在用 LangGraph、LangChain 那套「prompt node + 狀態圖」的方法寫 agent，停一下。

辛路的判斷是：這套方法論在 agent native 模型時代會逐漸不適用。不是現在不能用，而是你寫的東西兩年後要全部重寫。

去 GitHub 找 Learn Claude Code（節目來源同上），把 memory、context 壓縮、skill 那幾個資料夾掃一遍。免費的，5 萬人已經幫你驗證過。

► 第三：PM 該補的不是 Figma，是 Transformer

我知道這條會讓很多 PM 朋友不太舒服。

但辛路那段話我必須再強調一次：今天的 PM 跟 5 年前的 PM 已經不是同一種職業。

5 年前你做 SaaS PM，懂用戶研究、懂 UX、懂 SQL 拉資料就夠了。
今天你做 AI 產品 PM，你不懂 transformer 怎麼自回歸、不懂 context window 為什麼會滿、不懂 model harness 為什麼設計成這樣，你提的需求工程師會聽不進去。

不用變成模型研究員。但 transformer 怎麼自回歸、context window 為什麼會滿、agent 模型怎麼訓練，這些底層直覺，你至少要建立起來。

Outlook：零人公司，跟你口袋裡那張黑卡

我把節目最後 5 分鐘留給你。

辛路講了一個概念叫「零人公司」。

他的原話：「我從來不覺得一人公司是本質的事情，我認為真正 makes sense 的是零人公司。」

什麼意思？

公司本質是什麼？輸入 + 輸出。客戶不會天天跑進你 office 看你怎麼做事。中間流程客戶不在乎，只在乎結果。

那如果中間流程完全由 agent 跑，輸入輸出一樣穩定，這家公司還需要「人」嗎？

辛路講了一個畫面：未來你走在路上遇到朋友，從口袋掏出一張黑色卡片，跟他說「我這張卡片是我公司，每年給我創造幾十億收入」。

這聽起來很科幻。但《十字路口》Podcast 跟真格基金最近就投了一個 agent 叫「悠悠 Agent」。創作者把它丟出去，不再改代碼、不再給錢，agent 自己在 GitHub 上「化緣」（求打賞）來付自己的 token 費用，目標是有一天超越 Cloud Code。

這個 agent 已經算是一個半雛形的零人公司。

我聽完那段，腦袋裡冒出一個念頭：未來投資人投的標的，可能不再是「人類組成的公司」，而是「一個個 agent」。

而你今天該做的事情，是讓自己變成那個發現黑卡的人，不是還在賣咖啡給黑卡老闆的那個人。

如果你願意現在花幾個週末，把 Harness 的三層搞清楚、把 Cloud Code 源碼讀一遍、把 CLI 取代 MCP 的習慣建立起來。

下一個技術紅利的入場券，你就拿到了。

也許就是兩三年內、也許就是一張黑卡的距離、也許就是你跟其他 PM 的分水嶺吧？

引用來源

• 《十字路口》Podcast 第 X 集：Agent 的上限是 Harness 決定的（辛路訪談）
• 嘉賓：辛路（謝二 AI 創辦人，23 歲）
• 主持：科技（柯瑞）
• 開源教程：Learn Claude Code（GitHub 5 萬星）
• 嘉賓公司：1KB Agent Computer，融資 300 多萬美金，slogan「加速世界升級」

協作聲明與免責

這篇文章由王董與 AI 一起整理製作完成。文中引用的第三方資料、研究或工具都會標註來源名稱；若原始出處有公開連結，會以 [來源名稱](URL) 形式附上，方便你進一步查找。若文中內容與原始出處有任何出入，請以原文為準。

內容僅供參考與學習交流，不構成任何專業、商業或投資建議，請依自身情況判斷並自行承擔行動風險。文中提及的工具功能、數據與平台政策可能隨時間異動，請以各官方最新公告為準。