2026.1 簡單 AI Agent 是如何被實作的？以 PM 視角理解 AI Agent 的工程輪廓
怎麼實作一個「Claude Code (AI Agent)」?
前陣子某位前輩問我了這個問題，開啟了我對這條路的研究，身為產品經理我也想知道做一個在自己產品上的智慧客服回答也好、能替你計劃與執行的 Agent 也好，究竟有什麼細節是可能要知道的。
備註：這篇文純粹目前知識與經驗，此類技術演進速度極快，許多細節未來可能由框架與平台直接封裝，因此內容重點放在結構與思考方式。我目前不認為這些知識「必須要知道」
什麼情境需要 AI Agent？
其實我認為需求包含下列特徵，就可以考慮 Agent 形式來輔助產品服務
任務需要拆解多個步驟
過程中需要查詢外部資料或系統
任務狀態需要在多輪互動中持續維持
我所有對 AI 應用服務製作的核心法則是 Bottom-up
先滿足單一明確需求，再逐層擴充能力。過去做過客服 AI RAG (回答能含有獨有知識) 或其他 AI 應用，很容易一開始想得太美好，一次想到位，反而造成使用者更多困擾，然後就被罵（？）。
下面提到的，都非常建議透過關鍵字去 Vibe Coding 完成一個 Agent 看看，我的分享會著重在關鍵字跟結構上
以技術構成來說，什麼是 AI Agent
基礎就是一個大語言模型 (LLM) + 迴圈 (思考與計劃) + 工具調用（查資料、執行）
Press enter or click to view image in full size
圖片是我目前對於實作一個 AI Agent 他的基礎區塊，每個區塊都有很多人討論最佳實踐方式（Best Practice)，大家有興趣可以再深入查
一、基礎建設 (Agentic Loop + Tools)
我先查了「ReAct (Reason → Act → Observe)」方法論，它提供了對於需要深度計劃的問題一個基礎步驟：Reason (思考) > Act (行動) > Observe (觀察結果) > 回到第一步；而所謂的「行動」其實就是工具調用 (Function Calling/Tool Use)，包含網路查資料、電腦操作、查會員資料…等
流程可能就會長這樣：
使用者問問題
把問題與 tool 資訊丟給語言模型 (GPT, Claude, Gemini, … 基本上都支援 tools 參數) ，它會穩定地給你一個 JSON 格式，並決定本輪選擇什麼 Tool
調用 Tool，LLM 本身無法直接執行，它只能輸出『我想調用什麼工具』，並把上述 2. 交給程式負責執行；這些 tool 其實很多變，你可以將你想做的事都客製化在這
拿到 Tool 執行的結果，回到 1. 重複
這裡可能會產生思考：
任務何時結束？
— 成本導向：限制迴圈次數或 Token 消耗
— 任務導向：目標完成即結束
— 模型導向：由模型判斷任務是否完成
二、加入任務分配者 (Task Router)
這邊你會遇到一個問題，就是每個問題，都要跑很多次 ReAct，你會覺得「我只是想問簡單問題而已，可以不要想這麼久嗎？」，這時候你就可以自訂這個任務分配者，它概念很簡單例如：
切成「簡單」跟「困難」，你可以
規則判斷：先用文字過濾，例如如果提示詞包含「規劃」、「思考」等字眼，就直接分配到困難，這好處是你不用花費任何 Token用
輕量模型判斷：再來透過 LLM 判斷，這裡也可以用比較便宜的模型去處理
將判斷的參數帶到 Agentic Loop，例如簡單任務，那你就是不要 tool-use 或者只跑一次迴圈等，這邊都可以做設計
三、產品化前需補齊的環節
到這步，你的 Agent 已經能跑了。但如果要真正用在產品上，
還有幾個環節值得考慮：
上下文本控制 Context Engineering: 你會遇到 AI Agent 好像越問越笨，解決能力越差。這時就會想到「每次問問題，要打包多少 Context」，關鍵字就是 Context Engineering，設計方法例如：Sliding Window (只保留最近 N 輪)、對話摘要、向量化檢索（將歷史對話儲存相量資料庫）
監控過程 Observability：非常建議一開始就把中間每個過程的 Input, Ouput 記錄成 Logs，身為產品經理，你看 Log 你就會知道 AI 在哪一步開始失焦或者卡最久，你也能掌握「成本分佈」在哪
安全防護 Guardrails & Safety：這本質就是「限制 Agent」能做什麼，例如某些 Tool 的權限、操作確認（要刪除嗎）…等
成本控制：當 Agent 具備多輪推理與工具調用後，成本主要來自推理深度與模型使用時機。常見做法是將 Agent 拆為不同角色，而非所有請求都進入完整 Agentic Loop，利如有 Planner, Executor, Sub-agent 等。
在產品層面，成本控制等同於「哪些能力在什麼條件下被啟用」的設計問題。
Tool-Based 設計
最後分享一個對我幫助很大的設計方式：Tool-Based，其實就是把一切都當成 Tool。例如：
終止迴圈：做一個 end_loop 之類的 tool，明確地讓 LLM 判斷要不要調用，並統一穩定
RAG 查詢：中途可能要查內部資料，就把它設計在 tool 層級
與人互動：這也可以是 tool，當根據你的產品系統提示詞， LLM 判斷這問題需要更嚴謹的互動，它也可以設計在 tool 裡面去實作
對工程師而言這些 tool 是不同的 function，對產品角色而言：
值得思考定義需要哪些能力、每個能力授權範圍為何、觸發條件為何。
最後，這篇文其實我認為時效性很快就過了，寫這篇目的也是與大家一起好奇這世界的發展步驟，如果有麼想交流或指正也歡迎 Linkedin 與我分享！
50
作者：DopplerKuo