31 個 AI 編程 Agent 術語，整理成五大支柱

每個禮拜我的動態消息裡都會冒出新術語。Context engineering、Harness engineering、RLM、Progressive disclosure。我每天都在用 AI 編程 agent，但詞彙量的成長速度遠超我對這些概念的理解。

所以我停下來，把累積的 31 個術語全部分組整理。五大支柱浮現了，當我看清楚這個結構，Claude Code 和 Codex 這類工具的整體架構對我來說第一次真正說得通。

這五大支柱遵循一個邏輯順序：你設計 agent 看到的內容、你把工作分配給多個 agent、你控制它們的執行方式、你幫助它們跨 session 記住資訊、你把它們連接到外部世界。

設計。分配。控制。記憶。連接。

設計 Agent 看到的內容

AI 模型處理的東西只有一樣：它的 context window。每個 system prompt、使用者指令、附加檔案、對話歷史記錄、memory block 和載入的 skill，都會被串接成一條 token 流。那條流就是模型的整個宇宙。AGENTS.md——很多團隊用來設定 agent 行為的檔案——也只是那條流裡的一個片段。

Prompt 是你給模型的直接指令。Prompt engineering 是設計這些指令的實踐，包括範例和輸出格式，目的是獲得穩定可預期的結果。這兩個術語已經很成熟，但它們只涵蓋進入模型的內容的一小部分。

Context 是模型能夠參考的一切：system prompt、對話歷史、附加檔案、memory、skill 以及工具輸出的組合。Context engineering 是決定什麼要放進去、什麼要排除、以及以什麼順序排列的學問。這個差異很重要。我曾經看過完全相同的 prompt，只因為一個 2,000 行的檔案放在指令前面還是後面，就產生截然不同的結果。順序不是裝飾性的。

Intent 是使用者真正的目標，這可能和他們實際打的字不一樣。當你寫「修好那些測試」，intent 可能是「讓 CI 變綠」或「把測試套件重構成符合新 API」。Agent routing 從這裡開始，搞錯 intent 會讓所有下游的事情都跟著出問題。

Skill 是一個可重複使用的專家指令組合，在被呼叫時載入 context。把它想成是 prompt 的函式。與其每次想要特定行為時就貼上同樣的 200 行指令，你呼叫 /refactor-clean，skill 的內容就會在需要時進入 context window。

Progressive disclosure 是一種設計模式，你不會一次把所有 skill 都載入 context，而是讓 agent 只在當下需要的時候載入對應的 skill。Anthropic 在他們的 skills 部落格文章裡發表了這個方法。這很重要，因為 context window 的空間是有限的。一開始就載入 40 個 skill 會在模型還沒開始工作之前就燒掉大量 token。Progressive disclosure 讓 window 保持精簡，讓模型保持專注。

我在早期反覆碰到的失敗模式：把太多東西塞進 context，然後疑惑為什麼模型的輸出品質下降。200K context window 是理論上的最大值。實際上，一旦計入 system prompt、MCP server 定義和對話歷史，可用空間可能降到 70K 以下。Context engineering 就是學習如何尊重這個限制。

把工作分配給多個 Agent

一個 agent 處理所有事情聽起來很簡單，直到 context window 填滿、輸出品質下降為止。這就是多 agent 架構存在的原因。

Subagent 是主 agent 委派工作的子行程。主 agent 透過把專門的任務卸載出去，保持自己的 context 乾淨。在 Claude Code 裡，當你啟動一個背景研究任務，那就是一個 subagent 在自己的 context window 裡運作，最後只回傳結果。

Swarm 是一種模式，多個 agent 並行處理同一個問題的不同部分。如果你需要同時分析五個檔案，swarm 讓五個 agent 各自處理一個檔案，而不是讓一個 agent 依序處理。

Fleet 是你正在運行的 agent 的操作視角。這是一個管理術語，不是架構術語。當你有三個 subagent 和兩個 background agent 在運作，那個集合就是你的 fleet。

Handoff 是工作從一個 agent（或一個人）轉移到另一個的過程。在循序工作流程裡，Agent A 完成它的階段後交棒給 Agent B。重要的細節是轉移了什麼：只有輸出，還是完整的 context？大多數 handoff 只傳遞摘要，這意味著資訊損失是可能發生的，應該要納入考量。

Background agent 在沒有使用者互動的情況下非同步執行。GitHub 的 Copilot Workspace 和 Anthropic 的 Claude Code 都支援這個模式。你描述一個任務、闔上筆電，agent 獨立運作。你回來的時候結果就在那裡。

我曾掉入的陷阱：太早把工作拆分給太多 agent。一個有良好設計 context 的單一 agent，在 80% 的任務上表現都比協調不當的多 agent 設定來得好。只有在你有證據顯示單一 agent 碰到 context 限制或輸出品質下降時，才去做拆分。

控制 Agent 的執行方式

一個能產生正確程式碼的 agent，如果它同時悄悄呼叫危險的工具或修改不該碰的檔案，就毫無用處。控制是第三個支柱，也是大多數團隊投入最不足的一個。

Harness 是包裹 agent 執行、驗證和生命週期的操作框架。它包括從權限檢查到輸出驗證到重試邏輯的一切。Harness engineering 是在那個框架內設計限制和回饋迴路。OpenAI 在發表 Codex 如何透過結構化 harness 模式產生超過一百萬行程式碼時，讓這個術語進入了主流。

Trace 是 agent 每一個步驟和決策的執行日誌。我是在發現一個 agent 每個任務呼叫網路搜尋工具 14 次——而它其實只需要那個資訊一次——之後，才開始認真對待 trace。沒有 trace，我會以為那個 agent 運作得很有效率。Trace 是最接近 AI agent 除錯工具的東西。

Diff 是 agent 修改前後程式碼的比對。和 trace 一起，diff 構成了驗證的骨幹。你無法審查你看不見的東西，而 diff 讓 agent 的變更變得可以審查，就像 pull request 讓人類的變更變得可以審查一樣。

Guardrails 是防止危險輸出的規則和驗證檢查。可以簡單到「永遠不要執行包含 rm -rf 的 shell 指令」，也可以複雜到阻止敏感資料出現在輸出中的內容分類器。

Sandbox 是一個有受限權限的隔離執行環境。Codex 在 Docker sandbox 裡運行，agent 可以寫程式碼和跑測試，但無法存取網路或修改宿主系統。這就是「agent 犯了一個錯誤」和「agent 犯了一個影響到正式環境的錯誤」之間的差別。

CLI（command-line interface）在 agent 時代正在復興。透過終端機執行工具，結果比透過協定層路由更省 token。當每個 token 都要花錢又佔用 context 空間，CLI 的直接性就很重要。

REPL（read-eval-print loop）是一個可以立即執行程式碼的互動環境。Agent 用 REPL 來測試假設、驗證中間結果，並在不先把檔案寫入磁碟的情況下迭代解決方案。

跨 Session 記憶資訊

大型語言模型有一個硬性限制：context window。當它填滿，較舊的內容就會被驅逐。對於跨越數小時或數天的任務，這造成了真實的問題。

Memory 是任何在單一 context window 以外儲存對話歷史和任務狀態的系統。Memory hierarchy 把這些儲存系統組織成層次，通常是短期（當前對話）、中期（最近的 session）和長期（持久知識）。這個設計和 CPU 快取層次結構如出一轍，原因相同：不同的存取模式需要不同的儲存策略。

Embeddings 把文字轉換成捕捉語義含義的數值向量。它們是 RAG（retrieval-augmented generation）的基礎，agent 搜尋向量資料庫，把相關資訊拉進它的 context window。當你的 agent「記得」上一個 session 的某件事，通常就是在執行基於 embedding 的相似度搜尋。

Long-running agent 在多個 context window 之間維持狀態，處理比單一 session 更長的任務。這需要外部的狀態管理，因為模型本身沒有持久記憶。

Ralph Loop 由 Geoffrey Huntley 創建，是一個以務實方式解決記憶問題的自主編程迴路。每次迭代都啟動一個全新的 agent 實例，但進度透過 git commit 和進度檔案持久保存。新實例讀取 git 歷史和進度備註來了解已完成的工作，然後從那裡繼續。它透過反覆迭代最大化 test-time scaling，每個迴路都受益於儲存庫本身累積的 context。

RLM（Recursive Language Model） 採取了根本不同的方法。它不是把長輸入直接餵給模型（那樣會超過 context window），而是把原始資料儲存在 REPL 變數裡，讓模型透過寫程式碼來探索。模型透過遞迴函式呼叫，對儲存的資料發出有針對性的查詢。因為原始資料從不進入 context window，資訊不會因為截斷而遺失。作者聲稱這個方法可以處理相當於正常 context window 100 倍大小的輸入。

這兩種方法承認相同的限制，但用不同的方式解決。Ralph Loop 透過外部持久性與 context window 的限制共存。RLM 透過把資料保持在 context window 之外完全繞過它。沒有哪個普遍更好；正確的選擇取決於你的瓶頸是任務連續性（Ralph Loop）還是輸入大小（RLM）。

把 Agent 連接到外部世界

一個無法連接外部工具、API 或服務的 agent，只能做文字生成。各種協定解決了整合問題。

MCP（Model Context Protocol） 標準化了模型連接外部工具的方式。沒有 MCP，把 N 個模型與 M 個工具整合需要 N x M 個客製化實作。有了 MCP，每個模型和每個工具只需要實作一次協定，把整合成本降低到 N + M。這和讓 USB 成功的原則相同：對一個介面達成共識，所有東西都能連接。

ACP（Agent Communication Protocol） 標準化了編輯器和編程 agent 之間的通訊。Zed 和 JetBrains 正在主導其開發。它解決的問題和 MCP 類似，但在不同的層次：不是模型對工具，而是編輯器對 agent。

LSP（Language Server Protocol） 是編輯器與程式碼分析伺服器通訊的既有標準。它是協定標準化在開發者工具中可行的原始證明。一個用 grep 要 30 秒的參考搜尋，透過 LSP 在 50ms 內完成。Token 用量從 2,000 以上降到約 500，因為 LSP 回傳的是結構化、精確的結果，而不是原始檔案內容。LSP 也是 ACP 設計的參考模型，這很合理：問題的形狀幾乎完全相同。

這三個協定在不同層次運作，但共享相同的架構洞見。客製化的點對點整合無法擴展。標準介面可以。

地圖，不是領土

這些術語大多數在六個月前都還不存在。如果你對它們感到陌生，這很正常。詞彙在成長，因為這個領域在成長，而新概念需要名字。

這五大支柱的價值不在於背誦定義。而在於擁有一個心智框架，讓你在遇到新術語的那一刻就知道它屬於哪裡。當有人提到「agent memory」，你知道它屬於第四個支柱。當一個新協定發布，你知道它在第五個。這個框架能夠吸收新詞彙而不崩潰。

我現在還是會定期查術語。差別是，我現在知道它們應該放在哪個架上了。