# 31 個 AI 編程 Agent 術語，整理成五大支柱 > Author: Tony Lee > Published: 2026-03-12 > URL: https://tonylee.im/zh-TW/blog/ai-coding-agent-glossary-31-terms-five-pillars/ > Reading time: 3 minutes > Language: zh-TW > Tags: ai, ai-agents, claude-code, codex, developer-tools, glossary ## Canonical https://tonylee.im/zh-TW/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 每個禮拜我的動態消息裡都會冒出新術語。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」，你知道它屬於第四個支柱。當一個新協定發布，你知道它在第五個。這個框架能夠吸收新詞彙而不崩潰。 我現在還是會定期查術語。差別是，我現在知道它們應該放在哪個架上了。 ## Related URLs - Author: https://tonylee.im/zh-TW/author/ - Publication: https://tonylee.im/zh-TW/blog/about/ - Related article: https://tonylee.im/zh-TW/blog/eight-hooks-that-guarantee-ai-agent-reliability/ - Related article: https://tonylee.im/zh-TW/blog/medvi-two-person-430m-ai-compressed-funnel/ - Related article: https://tonylee.im/zh-TW/blog/claude-code-layers-over-tools-2026/ ## Citation - Author: Tony Lee - Site: tonylee.im - Canonical URL: https://tonylee.im/zh-TW/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-TW/blog/ This content is original and authored by Tony Lee. Please attribute when quoting or referencing.