AI Agent 可能是近年最容易出現新工程名詞的領域。
我們才剛學會 Prompt Engineering，接著又出現：
乍看之下，它們很像只是把同一件事換成不同名稱。
但這些概念並不是為了創造新名詞。
每一種 Engineering，背後其實都對應到一種新的系統問題。
當 AI 應用從單輪問答，逐漸發展成可以使用工具、修改資料、持續執行任務的 Agent，工程團隊所需要控制的範圍也不斷擴大。
整個演進可以簡化成一條路徑：
Prompt → Context → Harness → Loop → Graph
這不一定是一條嚴格的成熟度階梯，也不是每個系統都需要走到最後。
它更像是五個不同層次的工程視角。
最早期的 LLM 應用，主要問題通常是輸出品質不穩定。
模型可能：
因此，我們開始研究 Prompt Engineering。
Prompt Engineering 關心的是：
我要怎麼描述任務，才能讓模型產生更好的結果？
常見方法包括：
例如，與其只對模型說：
幫我分析這份報告。
我們可能會改成：
請以資深資料分析師的角度，整理這份報告的三項主要發現、支持證據、限制，以及下一步建議。
這時候，主要控制點仍然在一段輸入文字裡。
模型收到 Prompt，產生結果，任務就結束了。
但當系統開始加入檔案、搜尋結果、歷史訊息與記憶後，問題就不再只是「怎麼問」。
隨著 AI 應用變得更複雜，輸入模型的內容也越來越多。
除了使用者的問題，Context 裡可能還包含：
這時候，真正困難的問題變成：
在目前這一步，模型到底需要看到哪些資訊？
Context 並不是放得越多越好。
過多或不相關的資訊可能造成：
因此，Context Engineering 關心的不只是如何取得資料，也包括：
Prompt Engineering 是設計指令。
Context Engineering 則是在管理模型每一刻所能看見的世界。
即使 Prompt 寫得很好，如果放入了錯誤、過時或互相矛盾的 Context，模型仍然很難做出正確決策。
當模型不再只是回答問題，而是開始呼叫工具後，系統進入了另一個階段。
Agent 可能會：
這時候，問題已經不只是輸出品質。
而是：
我們如何讓模型安全、可靠地在真實系統中執行操作？
Harness 可以理解成包覆在模型外面的執行控制層。
它通常負責：
例如，一個 Agent 具備「寄送 Email」的工具，不代表它可以直接寄出任何信件。
系統還需要判斷：
Prompt 裡寫一句「請小心使用工具」無法取代這些控制。
模型能力越強，越需要清楚的執行邊界。
Harness Engineering 的核心不是讓 Agent 更聰明，而是讓它的行為變得可控、可觀察，而且可以被中止。
單次 Tool Calling 通常只能完成簡單任務。
真正的 Agent 往往需要反覆執行：
這就是 Agent Loop。
Loop Engineering 關心的是：
如何讓 Agent 不需要人類每一步修正，也能持續朝目標前進？
一個最簡單的 Agent Loop 可能只是：
思考 → 使用工具 → 讀取結果 → 再思考
但實際上，Loop 很容易出現問題：
因此，Loop Engineering 通常需要設計：
Loop Engineering 的目的，不是讓 Agent 永遠執行下去。
而是讓它知道什麼時候應該繼續、什麼時候應該重新規劃，以及什麼時候應該停止。
當 Agent Loop 變得更複雜，團隊常會遇到另一個問題。
如果每一個步驟都讓模型決定：
整個系統可能變得：
很多決策其實是穩定、可預期，而且已經被業務規則定義好的。
這些決策未必需要每次都交給模型重新推理。
Graph Engineering 關心的是：
哪些流程應該固定在程式中，哪些節點才真的需要模型判斷？
例如一個退款流程可能是：
這些主要步驟可以直接寫成 Graph。
模型只需要處理其中不確定的部分，例如：
固定流程由程式控制，模糊判斷交給模型。
這可以降低模型的決策負擔，也讓整個系統更容易：
Graph Engineering 並不是要消除模型。
它是把模型留在真正需要語意理解與不確定性判斷的地方。
這些概念之間有關聯，但它們解決的是不同問題。
解決：
任務應該怎麼描述？
解決：
模型目前應該看到哪些資訊？
解決：
模型可以執行哪些操作，系統如何限制與觀察它？
解決：
Agent 如何反覆執行，直到任務完成或安全停止？
解決：
哪些決策應該固定在程式裡，而不是每次都讓模型決定？
好的 Prompt 無法取代權限系統。
完整的 Context 無法阻止 Agent 無限重試。
強大的 Harness 無法保證 Agent 會選擇正確的任務路徑。
Agent Loop 也不代表每個流程都應該由模型動態決策。
它們不是互相競爭的技術，而是不同層次的工程控制。
早期的 LLM 工程主要在問：
我們應該怎麼問模型？
當系統逐漸進入正式環境後，問題開始改變：
模型現在需要知道什麼？
接著是：
模型被允許做什麼？
它要怎麼持續執行？
最後則是：
哪些事情根本不應該再讓模型決定？
這可能是 AI Agent 工程最重要的演進。
我們不再只是想辦法讓模型做更多決策。
我們開始辨認哪些決策具有高不確定性，值得交給模型；哪些決策其實穩定、重複而且可以被程式化。
Agent 系統的品質，不只取決於模型有多強。
也取決於我們是否知道：
什麼時候應該使用模型，以及什麼時候不應該使用模型。
Prompt、Context、Harness、Loop 與 Graph Engineering，並不是為了把 AI Agent 說得更複雜。
它們反映的是 Agent 從文字生成工具，逐漸變成真實執行系統後，工程團隊必須解決的不同問題。
整個過程可以整理成：
AI Agent Engineering 的核心問題，也從：
How should we ask the model?
逐漸變成：
What should we stop asking the model to decide?
真正成熟的 Agent 架構，不是把所有事情都交給模型。
而是清楚區分哪些工作需要模型的彈性，哪些工作需要程式的確定性。
如果你想更有系統地理解 AI Agent 架構，我最近也把 Awesome Agent Architecture 整理成 30 天 iT 邦幫忙鐵人賽系列。
這個系列會依照 repo 的內容，從最小可運作的 Agent Loop 開始，逐章拆解工具使用、Context、Memory、Planning、Multi-Agent、Harness 與 Graph Engineering，並搭配 Python 範例。
系列入口：《30 天從零拆解 AI Agent：從 Tool Calling 到多 Agent 協作》
本文整理自我建立的開源專案 Awesome Agent Architecture。專案從最小 Agent Loop 開始，逐步拆解工具、Context、Memory、Planning、Harness、Multi-Agent 與 Graph Engineering，並提供可執行的 Python 範例。
GitHub：https://github.com/hardness1020/awesome-agent-architecture
hardness1020
iThome鐵人賽
看影片追技術