先講結論：
Anthropic 的〈Code execution with MCP〉
LangChain × Manus 的 Context Engineering（YouTube）指向同一件事：
「Agent 真正的能力，不在大 context window，而在你怎麼設計 外部世界：檔案系統、CLI、MCP、code sandbox。」
一、兩套「新範式」在講什麼？
1. Context Engineering（LangChain × Manus）
這邊主題是：Agent 為什麼會「失憶、變笨」？要怎麼救？
核心問題：
- context window 就像工作記憶，一直往裡塞： 歷史對話 工具輸出 系統指令
- 塞到一個臨界點，就開始 context rot：模型變慢、變笨，忘記一開始要幹嘛。
於是 Manus 提出一套「Context Engineering」心法，幾個關鍵概念：
- Compaction vs Summarization Compaction（壓實 / 外部化）： 工具回傳一大坨資料（比如 web search），不要全塞進 context。 把完整結果寫到外部檔案，只在 context 裡留一行：「result_01.txt 裡有剛剛的搜尋結果」。 完全可逆：日後需要再打開檔案看。 Summarization（摘要）： 當 context 真的太肥了，就用另一個模型幫你「讀歷史、做摘要」，是不可逆的壓縮，要慎用。
- Isolation：多 Agent 怎麼分工 Communicating： 像 PM 派任務：「請幫我找出這份報告的所有 bug」，子 agent 只看到這個任務上下文，做完回結果。 Sharing Context： 像顧問加入專案，要讀所有歷史紀錄才能給建議；子 agent 分享到主 agent 的完整 context。
- Layered Action Space（三層行動空間） 這裡就是你說的 CLI 做法 所在的那一層：
- Layer 1：Core function calling 只給少量核心工具（< 10）： read file write file execute shell command search … 這是 agent 最基本的「反射」。
- Layer 2：Environment / Sandbox Utilities（CLI 層） 在 sandbox 裡事先裝好一堆 CLI / 小工具。 模型用「執行 shell command」這個核心 function，自己去探索環境： ls 看檔案 grep 搜尋 跑自己的 mcp-cli 或其他 domain CLI。 這一層的精神是： 不要把所有工具定義塞進 prompt，而是給模型一台「有工具的電腦」，讓它用 CLI 自己去查、自己去試。
- Layer 3：Packages & APIs（程式碼層） 模型可以寫 Python / 其他語言，呼叫各種 library / API。
整體來看，這套做法是在說：
「context 不是垃圾桶，而是一個指向外面世界的索引層；真正的資料與能力留在檔案系統 / CLI / 程式碼裡。」
2. Anthropic：Code execution with MCP
Anthropic 的文章則是從 MCP agent 爆 context 這個實務問題切入。
問題 1：工具太多，定義塞爆 context
- MCP world 很多 server，一個 agent 可以接上幾十甚至上百個 MCP server。
- 傳統用法：啟動 agent 時把「所有工具定義」都丟進模型。
- 結果：還沒開始工作，context 已經用了大半。
問題 2：中間結果也一直回灌進 context
- 典型例子： 「從 Google Drive 抓會議逐字稿，貼到 Salesforce lead」： gdrive.getDocument → 把整份 transcript 塞進 context。 模型 call salesforce.updateRecord 時，又得在 prompt 裡再寫一次那整份 transcript。
- 一個兩小時會議就可能是 +50k token，而且寫兩次。更大的文件會直接炸掉 context。
他們的解法：用 code execution 把 MCP 當「程式庫」，不是「直接 tool call」
關鍵 idea：
- 在 sandbox 裡，把 MCP server 變成一棵檔案樹：
servers
├── google-drive
│ ├── getDocument.ts
│ └── index.ts
├── salesforce
│ ├── updateRecord.ts
│ └── index.ts
- 每個 tool 對應一個 .ts 檔，裡面是型別清楚的函式：
/* Read a document from Google Drive */
export async function getDocument(input: GetDocumentInput): Promise<GetDocumentResponse> {
return callMCPTool<GetDocumentResponse>('google_drive__get_document', input);
}
``` [oai_citation:15‡Anthropic](https://www.anthropic.com/engineering/code-execution-with-mcp)
- 模型不再「直接 tool call」，而是： 用 readdir、readFile 探索 ./servers，了解有哪些 tool。 然後 寫 TypeScript 腳本 來 orchestrate MCP 工具：
const transcript = (await gdrive.getDocument({ documentId: 'abc123' })).content;
await salesforce.updateRecord({
objectType: 'SalesMeeting',
recordId: '00Q5f000001abcXYZ',
data: { Notes: transcript }
});
- 腳本在 sandbox 跑完之後，只把 小量的 log / 摘要 / sample 傳回模型。 他們舉例，token 從 150k 降到約 2k，省了 98.7%。
- 延伸好處： Progressive disclosure： 模型只在需要時打開少數 tool 檔案，不再一次讀完所有定義。 Context-efficient results： 10,000 rows 的試算表先在 code 裡 filter / aggregate，再只 log 前幾筆。 更強的 control flow： 迴圈、錯誤處理、retry、polling（例如等 Slack 發「deployment complete」）都交給程式碼。 隱私 / 資料流控： 中間資料留在 sandbox；MCP client 可以在資料進模型前先 token 化 PII。 狀態與 Skills： 把中間結果寫檔、把常用腳本存成 ./skills/，加 SKILL.md 變成可重用技能。
二、CLI 做法 vs MCP Code Execution：兩種「窄腰」設計
如果要用一句話對比：
- CLI 派（LangChain × Manus）： 「以 CLI 當窄腰，模型用 shell 指令去操作一個工具豐富的 sandbox。」
- MCP Code Execution 派（Anthropic）： 「以 程式碼 API 當窄腰，模型寫 code 呼叫一個充滿 MCP server 的函式庫世界。」
來拆幾個維度比較：
1. 窄腰抽象（Narrow Waist）
- CLI 模式： Layer 1 的核心 tool 其實只有幾個（read/write file、exec shell、search）。 其他東西（git、mcp-cli、自家 CLI 工具）都「躲」在 shell 裡。 對模型來說，世界長這樣： 「我只會執行指令，但指令背後什麼都有。」
- MCP code execution： 窄腰變成：型別明確的程式庫（TS 函式）。 每個 MCP tool 對應一個有 interface / 註解的 .ts 檔。 對模型來說，世界變成： 「我會 import 函式、看註解、照型別呼叫它們。」
2. 工具探索（Tool Discovery）
- CLI： 用 ls、cat README、--help、mcp-cli list 去「人工 style」地探索工具。 很像把模型當成工程師，教它在陌生專案資料夾裡摸索。
- MCP： 用 filesystem 的目錄結構 (./servers) + search_tools API，依名稱 / 描述 / schema 搜尋工具，還可以控制 detail level。
3. 大量資料處理（Big Data in / out）
- CLI： 可以先讓 CLI 做部分處理：比如 grep / jq / 自家 CLI 的 filter。 但很多 CLI 預設輸出是 unstructured text，模型還得再 parse 一次。
- MCP code execution： 一開始就鼓勵你在程式碼裡處理：filter、join、aggregate、取前 N 筆 sample。 跟工具溝通也是 structured objects（TS 型別），更適合模型。
4. 安全與資料流控
- CLI： 要 sandbox 一個完整 shell 環境，攻擊面很大。 很難在字串層級做細緻的「欄位級」資料流控（例如：Email 只能從 A 系統流到 B 系統）。
- MCP code execution： MCP client 是你自己寫的，可以在所有工具 call 前後做： PII tokenization / untokenization 欄位白名單 / 黑名單規則 中間結果預設待在 sandbox，不進模型，風險更可控。
5. 可維護性與抽象層級
- CLI： 直接 reuse 既有 CLI 生態（POSIX 工具、雲端 CLI…）。 但指令介面不是 strongly typed，錯誤訊息風格各自為政，很「人類友善，機器痛苦」。
- MCP code execution： 一開始需要寫一層「wrapper 生成器」把 MCP 轉成程式庫。 但一旦有了這層，模型看到的世界是： 乾淨的函式 有註解、有型別 行為一致
6. 開發與營運成本
- CLI 模式： Infra 比較簡單：給一個 docker/sandbox + 一堆你熟悉的 CLI 即可。 適合 DevOps / 資料工程這類已經有 CLI 工具庫的場景。
- MCP code execution： 需要： code sandbox（資源限制、監控、沙箱安全） MCP client + wrapper generator 資料流控與 tokenization 基礎設施 但對於 大量工具 + 敏感資料 + 需要型別安全 的場景，長期投資值得。
三、把兩者合在一起：Context engineering 的「新範式」
其實這兩篇（影片＋文章）是在拼同一張圖，只是從不同角度切。
1. Context 不只是「文字」，而是一整個運行環境
兩邊不約而同地在說：
- context window 是工作記憶，不是硬碟。
- 真正的資料、歷史、工具庫應該放在： 檔案系統（compaction / workspace） CLI 工具 MCP servers 程式碼與 skill 目錄
context 的角色是：
「一個精簡的導覽索引：指引模型去外部世界拿自己需要的東西。」
2. 新範式的幾條設計原則
綜合兩邊，我會這樣歸納「Context engineering 的新範式」：
- 最小化「活在 context 裡的 token」，最大化「可隨取的外部狀態」 用 compaction 把巨量輸出外部化，只留下檔名 / 索引。 用 code execution 在 sandbox 裡先處理完，再把結果縮到最小。
- 讓模型「寫程式 / 下指令」來自己管理 context CLI 派：模型用 ls、grep、自家 CLI 去探索與搬運資料。 MCP 派：模型寫 TS code orchestrate MCP tools，並決定哪些東西要 log 回來。
- 工具不是硬塞進 prompt 的清單，而是可探索的環境 Layered action space：先給少量 core tools（read/write/exec/search），再給一個充滿 utilities 的 sandbox。 MCP filesystem pattern：工具變成可以 readdir / readFile 的程式庫樹。
- 把「安全與資料治理」下沉到 runtime，而不是塞在 prompt 政策裡 MCP pattern：在 client 端實作 PII tokenization、資料流規則。 CLI pattern：可以透過檔案權限、sandbox 網路權限、指令白名單控制行為。
- 把常用路徑變成 skill / script，讓 agent 自己長出 muscle memory Manus / LangChain：compaction + isolation 組合成可以重複套用的 context flows。 Anthropic：把常用腳本存進 ./skills/ + SKILL.md，變成 Claude 可以重用的技能。
四、實務選擇：到底該用 CLI，還是 MCP code execution？
如果你今天要做設計決策，大概可以這樣想：
什麼場景偏向
CLI context engineering
比較爽？
- 你 already 有一堆 CLI： kubectl、aws、gcloud、公司內部自家 CLI…
- 團隊本來就很 UNIX 腦，懂 grep、jq、make 這些 pattern。
- 主要工作是infra / devops / data pipeline 自動化，安全邊界可以靠 container / namespace 做到。
這時候：
「給模型一個乾淨的 shell + 一堆 CLI，就等於給它一個超強工具箱。」
什麼場景偏向
MCP code execution
更合理？
- 你已經在用 MCP（Claude Desktop、各種 MCP server）。
- 工具數量非常多（幾十個系統、上百個 tool）。
- 有嚴格的隱私 / 合規需求，需要欄位級別的資料流控制與 audit。
- 你想要強型別、可觀察、可測試的 agent 行為（像在維護一個微服務，而不是 prompt spaghetti）。
這時候：
「把 MCP 變成程式庫，讓模型寫 code，而不是在 prompt 裡拼出一條條工具呼叫。」
五、從 Prompt Engineering 到 Context Engineering
如果把時間拉長來看，這其實是一條演化路線：
- Prompt engineering： 調 system / user prompt，想辦法塞更多東西進去。
- Retrieval + memory： 開始有 RAG、長期記憶、搜尋工具。
- Tool-calling / MCP / 函數調用： 模型可以動手「做事」，但 context 很快被工具定義 + 輸出塞滿。
- Context engineering（你現在看的這兩篇）： 把「上下文」從單一 prompt 提升到一個 可設計的 runtime： 檔案系統 CLI 生態 MCP server code execution sandbox 模型不只是在 prompt 裡思考，而是靠 程式碼 / 指令 去管理自己的記憶與工具。
