31 個 AI 編程 Agent 術語，按五大支柱分類

每週 feed 裡都會出現新術語。Context engineering、harness engineering、RLM、progressive disclosure。我每天都在用 AI coding agent，但詞彙增長的速度遠超過我對它的理解。

於是我停下來，把收集到的 31 個術語逐一分組。五大支柱由此浮現，當我看清它們的輪廓，Claude Code 和 Codex 這類工具的整體架構終於變得清晰。

五大支柱有其邏輯順序：你設計 agent 所看見的內容，你把工作分配給多個 agent，你控制它們的執行方式，你幫助它們跨 session 記住資訊，最後你把它們與外部世界連接起來。

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

設計 Agent 所看見的內容

AI model 只處理一件事：它的 context window。每個 system prompt、用戶指令、附加檔案、對話歷史記錄、memory block 和載入的 skill，都會串接成一條 token 串流。那條串流就是 model 的整個宇宙。許多團隊用來配置 agent 行為的 AGENTS.md 檔案，不過是那條串流裡的另一片段。

Prompt 是你直接給 model 的指令。Prompt engineering 是設計這些指令的方法，包括範例和輸出格式，目的是取得穩定的結果。這兩個術語已相當普及，但它們只涵蓋實際進入 model 的一小部分。

Context 是 model 能夠參考的一切：system prompts、對話歷史、附加檔案、memory、skills 和 tool 輸出的總和。Context engineering 是一門學問，決定什麼放進去、什麼排除在外、以及排列順序。當中的分別相當重要。我見過完全相同的 prompt，只因為一個 2,000 行的檔案放在指令之前還是之後，就產生截然不同的結果。順序絕非表面功夫。

Intent 是用戶真正的目標，可能與他們實際輸入的文字有所出入。當你寫下「fix the tests」，背後的 intent 可能是「讓 CI 變綠」或「重構 test suite 以配合新的 API」。Agent routing 從這裡開始，搞錯 intent 會一路影響下游的每一步。

Skill 是一個可重用的專家指令包，呼叫時會載入 context。把它想成 prompt 的函數。與其每次想要某個特定行為時都貼上同一段 200 行指令，你只需呼叫 /refactor-clean，skill 的內容就會按需進入 context window。

Progressive disclosure 是一種設計模式，不會一次把所有 skill 載入 context，而是讓 agent 在需要時才載入對應的 skill。Anthropic 在他們的 skills blog post 中介紹了這個做法。這很重要，因為 context window 空間有限。一開始就載入 40 個 skill 會在 model 開始工作之前已燃燒大量 token。Progressive disclosure 讓 context window 保持精簡，model 也更專注。

我早期反覆碰壁的情況：把太多內容塞進 context，然後納悶為何 model 的輸出質量下降。200K context window 是理論上限，實際上一旦計及 system prompts、MCP server 定義和對話歷史，可用空間可以跌至 70K 甚至更少。Context engineering 的本質是尊重這個限制。

把工作分配給多個 Agent

單一 agent 處理所有事情聽起來簡單，但 context window 填滿後輸出質量就會下降。這正是 multi-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% 的任務上表現好過協調不佳的 multi-agent 設置。只有在有證據顯示單一 agent 遇到 context 限制或輸出質量下降時，才值得拆分。

控制 Agent 的執行方式

一個能生成正確代碼的 agent，如果同時靜悄悄地呼叫危險工具或修改不應碰的檔案，那就毫無用處。控制是第三根支柱，也是大多數團隊投入最不足的一環。

Harness 是包裹 agent 執行、驗證和生命週期的操作框架，涵蓋從權限檢查、輸出驗證到重試邏輯的一切。Harness engineering 是在這個框架內設計約束和反饋循環。OpenAI 發表了 Codex 如何通過結構化 harness 模式生成逾百萬行代碼後，這個術語才廣為人知。

Trace 是 agent 每一個步驟和決策的執行日誌。我開始認真對待 trace，是在發現某個 agent 每個任務呼叫了 14 次 web search tool，明明只需要那資訊一次。沒有 trace，我根本不會發現問題所在，只會以為 agent 運作效率正常。Trace 是最接近 AI agent debugging 的工具。

Diff 是比較 agent 修改前後代碼的方式。Diff 連同 trace，構成了驗證的骨幹。看不見的東西無法審查，而 diff 讓 agent 的修改變得可審查，就如 pull request 讓人類的修改變得可審查一樣。

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

Sandbox 是一個權限受限的隔離執行環境。Codex 在 Docker sandbox 內運行，agent 可以寫代碼和跑測試，但無法存取網絡或修改宿主機系統。這就是「agent 犯了錯」和「agent 犯了錯而影響到 production」之間的分別。

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 cache hierarchy 的原理如出一轍：不同的存取模式需要不同的儲存策略。

Embeddings 把文字轉換成能捕捉語意的數值向量，是 RAG（retrieval-augmented generation）的基礎，讓 agent 可以搜索向量資料庫，把相關資訊拉入 context window。當你的 agent「記得」上一個 session 的某件事，背後通常是進行了一次基於 embedding 的相似度搜索。

Long-running agent 跨越多個 context window 維持狀態，處理超過單一 session 時長的任務。這需要外部狀態管理，因為 model 本身沒有持久記憶。

Ralph Loop 由 Geoffrey Huntley 創建，是一個用實用方式解決記憶問題的自主編程循環。每次迭代都啟動一個全新的 agent 實例，但進度通過 git commit 和進度檔案持久保存。新實例讀取 git 歷史和進度筆記，了解已完成的工作後從那裡繼續。它通過反覆迭代最大化 test-time scaling，每次循環都從 repository 裡積累的 context 中受益。

RLM（Recursive Language Model） 採取了根本不同的做法。它不把長輸入直接餵給 model（否則會超出 context window），而是把原始資料儲存在 REPL 變數中，讓 model 寫代碼去探索它。Model 通過遞歸函數呼叫對儲存的資料發出精準查詢。由於原始資料從不進入 context window，資訊就不會因截斷而丟失。作者聲稱這個方法能處理相當於正常 context window 100 倍的輸入量。

兩種方法面對的是同一個限制，但解法不同。Ralph Loop 通過外部持久化與 context window 的限制共存；RLM 把資料置於 context window 之外，完全繞過它。沒有哪個更好，選擇取決於你的瓶頸是任務連續性（Ralph Loop）還是輸入大小（RLM）。

把 Agent 與外部世界連接

一個無法連接外部工具、API 或服務的 agent，只局限於生成文字。協議解決了整合問題。

MCP（Model Context Protocol） 標準化了 model 連接外部工具的方式。沒有 MCP，整合 N 個 model 和 M 個工具需要 N x M 個自訂實作。有了 MCP，每個 model 和每個工具只需實作協議一次，把整合成本降至 N + M。這和 USB 成功的原理一樣：大家同意一個介面，所有東西就能互相連接。

ACP（Agent Communication Protocol） 標準化了編輯器與 coding agent 之間的通訊。Zed 和 JetBrains 正在主導其開發。它解決的問題與 MCP 相似，但處於不同層面：不是 model 對 tool，而是編輯器對 agent。

LSP（Language Server Protocol） 是編輯器與代碼分析服務器通訊的成熟標準，也是協議標準化在開發工具中行得通的原始證明。一個用 grep 需要 30 秒的引用搜索，通過 LSP 在 50ms 內完成。Token 用量從 2,000+ 降至約 500，因為 LSP 返回結構化的精準結果，而非原始檔案內容。LSP 亦是 ACP 設計的參考模型，這說得通：兩個問題的形狀幾乎一樣。

這三個協議運作於不同層面，但共享同一個架構洞見。自訂點對點整合無法擴展，標準介面才行。

地圖，而非地形本身

這些術語大多數在六個月前根本不存在。如果感覺陌生，這很正常。詞彙在增長，因為這個領域在增長，新概念需要名字。

這五大支柱的價值不在於死記定義，而在於建立一個心智框架，讓你一遇到新術語就知道它屬於哪裡。有人提到「agent memory」，你知道它屬於第四根支柱。有新協議推出，你知道它在第五根。這個框架能吸收新詞彙，不會因此崩潰。

我至今仍經常查閱術語。分別在於，我現在知道它們該放在哪個架子上。