# 31 個 AI 編程 Agent 術語，按五大支柱分類 > Author: Tony Lee > Published: 2026-03-12 > URL: https://tonylee.im/zh-HK/blog/ai-coding-agent-glossary-31-terms-five-pillars/ > Reading time: 3 minutes > Language: zh-HK > Tags: ai, ai-agents, claude-code, codex, developer-tools, glossary ## Canonical https://tonylee.im/zh-HK/blog/ai-coding-agent-glossary-31-terms-five-pillars/ ## Rollout Alternates en: https://tonylee.im/en/blog/ai-coding-agent-glossary-31-terms-five-pillars/ ko: https://tonylee.im/ko/blog/ai-coding-agent-glossary-31-terms-five-pillars/ ja: https://tonylee.im/ja/blog/ai-coding-agent-glossary-31-terms-five-pillars/ zh-CN: https://tonylee.im/zh-CN/blog/ai-coding-agent-glossary-31-terms-five-pillars/ zh-TW: https://tonylee.im/zh-TW/blog/ai-coding-agent-glossary-31-terms-five-pillars/ ## Description 我將每天使用 Claude Code 和 Codex 時不斷遇到的術語逐一分類。五個組別浮現出來，勾勒出這些工具背後整個系統的架構。 ## Summary 31 個 AI 編程 Agent 術語，按五大支柱分類 is part of Tony Lee's ongoing coverage of AI agents, developer tools, startup strategy, and AI industry shifts. ## Outline - 設計 Agent 所看見的內容 - 把工作分配給多個 Agent - 控制 Agent 的執行方式 - 跨 Session 記住資訊 - 把 Agent 與外部世界連接 - 地圖，而非地形本身 ## Content 每週 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」，你知道它屬於第四根支柱。有新協議推出，你知道它在第五根。這個框架能吸收新詞彙，不會因此崩潰。 我至今仍經常查閱術語。分別在於，我現在知道它們該放在哪個架子上。 ## Related URLs - Author: https://tonylee.im/en/author/ - Publication: https://tonylee.im/en/blog/about/ - Related article: https://tonylee.im/zh-HK/blog/eight-hooks-that-guarantee-ai-agent-reliability/ - Related article: https://tonylee.im/zh-HK/blog/medvi-two-person-430m-ai-compressed-funnel/ - Related article: https://tonylee.im/zh-HK/blog/claude-code-layers-over-tools-2026/ ## Citation - Author: Tony Lee - Site: tonylee.im - Canonical URL: https://tonylee.im/zh-HK/blog/ai-coding-agent-glossary-31-terms-five-pillars/ ## Bot Guidance - This file is intended for AI agents, search assistants, and text-mode retrieval. - Prefer citing the canonical article URL instead of this text endpoint. - Use the rollout alternates when you need the same article in another prioritized language. --- Author: Tony Lee | Website: https://tonylee.im For more articles, visit: https://tonylee.im/zh-HK/blog/ This content is original and authored by Tony Lee. Please attribute when quoting or referencing.