I. 前言：當 Prompt 調到極限之後

在生成式 AI 的浪潮中，我們正經歷一場從 Chatbot 到 Agent 的開發模式轉變。如果說 Chatbot 的價值在於「資訊的生成與整理」，那麼 AI Agent 的核心命題，則在於「任務的規劃與執行」。

然而，當開發者試圖將具備工具操作能力（Function Calling）的 Agent 導入真實業務場景時，會立刻遇到一個相當實際的問題：Agent 的行為不夠穩定。

舉一個許多人都遇過的例子。我們在 System Prompt 裡寫得清清楚楚：「修改假單前，必須先查詢取得真實 ID」。測試十次，八次照做，兩次直接編了一個 LV-001 出來。於是加上 few-shot 範例，變成九次照做；把規則改寫成編號步驟，還是九次；再把同一句話抄一份到 Tool Description 裡，仍然是九次。

不管怎麼調，那 10% 就是回不來。而且這 10% 通常不是隨機分布的，它們會集中在某幾類特定行為上 —— 而那幾類，往往剛好是我們最不希望它出錯的地方。

我認為，這正是 Prompt Engineering 這條路的天花板：有一類規則，結構上就不適合放在上下文裡。 這 30 天想回答的，就是接續在後面的那個問題 —— 當 Prompt 已經調到極限，下一步該往哪裡走？

我的答案是把規則從 Prompt 搬進權重。但這件事並不是「找個模型微調一下」就能解決，它需要一整條完整的鏈路，而這條鏈路上的每一步都有可能出錯。以下的內容，將會針對這 30 天的完整規劃進行說明。

II. 這個系列的起點：一個已經驗證過的研究

在展開 30 天計畫之前，我想先分享一個先前做過的研究，它是這整個系列的起點。

今年七月，我在 APMIC PrivStationDay 分享過一個題目：我要一個「做事情」的 Fine-Tuned Model。當時我挑了一個相對複雜的 IT 維運工具 —— Kubernetes MCP Server 作為測試目標，想驗證一件事：

我們是否能透過 Fine-Tuning，讓一個輕量級的小模型，也具備強大的 Agent 執行能力？

作法是用 Gemini 扮演老師的角色，生成包含 User Query、Reasoning 與 Tool Call 的完整互動資料（資料集已開源在 Hugging Face），再對 gemma-4-E4B-it 進行全參數的監督式微調。

結果如下：

這個研究驗證了一件重要的事情：「做事情」的 Agent 不一定非得綁定昂貴的大型模型。 一個 4B 參數等級的小模型，只要經過針對性的訓練，在特定任務上完全可以勝任。

不過，真正值得深究的其實是最後那一列數據 —— 名稱 + 參數全對率 70.7%。換句話說，即使經過微調，仍然有將近三成的工具呼叫是不正確的。

而當時我沒辦法回答的問題是：這三成到底錯在哪裡？

我只知道它們「錯了」，卻無法分辨它們是漏了必填參數、日期格式寫錯、選錯工具，還是呼叫順序顛倒。既然不知道錯在哪，下一輪訓練該補什麼資料，也就只能憑經驗猜測。

這個缺口帶出了三個問題，也正是這 30 天要回答的：

1. 失敗案例有共同的特徵嗎？ 那些微調後仍然做不對的案例，能不能被分類？
2. 評測能不能驅動訓練？ 如果先用科學化的評測找出模型到底錯在哪，再針對性地準備訓練資料，效果會不會更好？
3. 這條路能不能被複製？ 能不能寫成一套任何人都能套用到自己領域的流程，而不是一次性的實驗？

七月那次的做法是「訓練完再看看結果」。這一次，我想把順序反過來。

III. 完整的閉環

請注意最後那條虛線。評估不是流程的終點，而是訓練資料的來源，也是驗證成果的尺。

具體來說是三個時間點：第一次先量出一組基準數字，然後把它凍結起來，之後不再改動；第二次從同一批實驗紀錄裡挑出做對的軌跡，當成訓練資料；第三次在訓練完成後，拿完全相同的測試案例再量一次。

三次共用同一把尺，差距才有意義 —— 這是整個系列能不能證明任何事情的前提。

IV. 五個階段要分享的內容

1. Day 1 至 Day 4・Agent 概念與 MCP 基礎

第一階段先建立心智模型，再處理工具介面。

Day 2 會拆解 AI Agent 的系統架構 —— 它與 Chatbot 的差異不只是「能呼叫 API」，而是整個決策迴圈的組成方式。接著進入 Model Context Protocol：用它把工具與規則一起定義好，讓規則跟著工具走，而不是跟著框架走。

這個決定會在 Day 24 兌現 —— 屆時整個 Google ADK 都被拿掉了，那條規則依然生效。

過程中會碰到 2026-07-28 版規範的一個機制：Elicitation，它讓 Server 能反過來向使用者索取確認。這是處理「破壞性操作」最乾淨的做法，同時也會變成四個難點裡最難的那一個。

2. Day 5 至 Day 11・打造 Google ADK Agent

工具備好了，接下來讓 LLM 真的去用它。

這七天會從 Google ADK 2.0 的基本結構開始，把 MCP Server 用 McpToolset 接上，處理 Session 與 State，並選一個能產出可解析執行計畫的 Planner —— 這個選擇在 Day 15 會有回報，因為那些計畫文字正好就是訓練資料裡的 Thought。

Day 10 處理單一 Agent 的極限，用權限分離拆成雙 Agent 架構。而 Day 11 專門處理 Tracing 與 Event 記錄 —— 這件事看似只是除錯技巧，實際上是後續所有工作的資料來源。

從 Day 7 接上工具的那一刻起，模型就會開始犯錯，而那些錯誤是後面所有工作的原料。

3. Day 12 至 Day 14・品質評估體系

拿到失敗清單之後，最自然的反應是「再改改 Instruction 應該就好了吧」。這個念頭是對的，但在動手之前有個更基本的問題：您怎麼知道改了之後有變好？

這三天要打造兩把尺：

• ADEval 負責自訂任務的軌跡正確性 —— 工具有沒有選對、參數有沒有填對、順序有沒有錯。它是我自己開發的開源專案，所以這幾天不只寫「怎麼用」，也會誠實寫出它哪裡不夠好。
• Twinkle Eval 負責標準 Benchmark 的通用能力 —— 微調之後模型會不會「變會用工具，但也變笨了」。

一把尺只能量一個維度，而這兩個維度缺一不可。

4. Day 15 至 Day 20・資料集準備與微調準備

有了診斷結果，就能針對性地準備訓練資料。

這六天會從 Google ADK 的 Event 日誌萃取軌跡，然後面對一個相當清醒的數字：去重之後只剩幾十筆。而讓模型穩定學會一組工具的慣例，通常需要千筆等級。

Day 16 因此成為關鍵的一天，要用四種手法把資料擴增到數千筆，並且用評測工具反過來驗證合成資料的正確性，同時處理另一半 —— 教模型在該停的時候停。

後半段處理基座選型、Loss Mask 原理，以及訓練環境。考量到並非每個人都有本地 GPU，Day 18 會走一條低成本的雲端路線：Google Colab 與官方 Colab CLI。

5. Day 21 至 Day 30・訓練、部署與架構昇華

最後十天分成三段。

訓練與部署（Day 21-22）：實際跑 SFT、判讀 Loss 曲線、處理踩坑，然後合併權重、量化，用 vLLM 部署成 OpenAI 相容端點。

閉環驗收（Day 23-24）：拿 Day 13 那把凍結過的尺，配合 Twinkle Eval 的通用能力對照，做完整的三方對決。接著把框架拿掉，用不到八十行的原生 Agent Loop 驗證架構決定，並計算自架的成本損益平衡點。

架構昇華（Day 25-30）：這是整個系列在技術之外的延伸 —— Flow 與 Agent 的選擇時機、現代 Agent 的四大設計模式、以工程師視角重構 Agent 名詞、企業級生產防禦，以及自我進化閉環的下一步。

V. 貫穿全系列的核心案例

Day 3 會建一個 MCP Server，它會一路用到 Day 24。

這件事我想了很久，因為它幾乎決定了整個系列成不成立。

假設今天示範用的是「查天氣」那種等級的工具。基座模型本來就叫得對，準確率一開始就接近滿分，那麼 Day 23 微調完會發生什麼事？答案是幾乎沒有提升空間 —— 不是因為微調沒用，而是因為根本沒有東西可以改善。整個系列會得出一個錯誤的結論。

所以核心案例的選擇標準只有一個：基座模型幾乎必錯，而微調可以教會。

七月那個研究我用的是 Kubernetes MCP Server。它夠複雜，但也因此有個缺點 —— 當模型答錯時，我很難分辨它是不懂 kubectl、不懂 YAML、還是不懂我的問法。變數太多，就沒辦法歸因。

這次我改用自己設計的差勤助手（Leave Copilot），涵蓋假單、員工、排程約 8–12 個工具。用自己設計的好處是能精確控制難度 —— 我知道每一個坑埋在哪裡，所以模型踩到的時候，可以直接對應到是哪一類問題。

於是我在裡面刻意植入了四個難點：

VI. 為什麼這四個難點 Prompt 解不掉

這是整個系列的核心論點，值得在第一天就講清楚。

回到前言那個場景：為什麼有些規則講一次模型就會，有些卻怎麼講都講不聽？

我一開始以為是措辭問題，後來發現界線其實很清楚 —— 分水嶺在於那條規則寫不寫得進 JSON Schema。

左邊那半，模型照著 schema 填就會對，Prompt 補強效果也好。右邊那半只能用自然語言寫在 tool description 或 Instruction 裡，模型會不會照做是機率問題。

而且這裡有個規律，Day 13 會用數據驗證：

越接近「格式」的問題，Prompt 越有效；越接近「行為傾向」的問題，Prompt 越無力。

格式錯誤是模型「不知道」，告訴它就好。行為傾向是模型「知道但做不到」—— 難點 ② 就是典型：使用者拒絕後，模型「想」用別的方式達成目標，因為在絕大多數情境下那是好行為。要它違反自己的通用訓練傾向，一句 Prompt 壓不過去。

微調不是教模型新知識，是改變它的預設反應。

VII. 這個系列的三個特色

一、評測工具是我自己開發的。 Day 12 至 Day 14 用到的 ADEval（Apache-2.0）是我的開源專案。所以 Day 12 會誠實寫出它的設計限制，Day 13 動手補上 —— 工具的演進本身就是內容。

二、押在 2026 年的最新規範。 用 MCP 2026-07-28 的 Elicitation，而不是人人都寫過的 MCP 入門。過程中會標出好幾個版本相容性的坑，例如：MCP Python SDK 的官網預設顯示的是另一套 API 的文件 —— 照那份文件寫出來的 Server，與本系列後續的整合方式完全不同。

三、有真實數據的閉環。 Day 23 拿同一把尺量微調前後，並且會誠實呈現退步的項目。一份只有進步的報告，讀者會直覺不信任。

VIII. 您需要什麼、能得到什麼

需要的基礎：Python、對 LLM API 有基本概念。不需要有 MCP 或微調經驗，也不需要一開始就有 GPU —— 訓練到 Day 21 至 Day 30 才用得上。

能得到的：一套可以套用到自己領域的方法論。模型會過時、工具會更新，但「量化 → 訓練 → 回到同一把尺驗收」這個流程，換個任務還是能用。

IX. 開始之前：把環境準備好

接下來兩天是概念，第三天就要動手。建議趁這兩天先把環境備好 —— 整條工具鏈裝起來大約十五分鐘，但有幾個版本約束如果踩到，排查起來會花掉一個下午。

三個會卡住的版本約束

第一項特別容易中招，因為 MCP Python SDK 官網預設顯示的是另一套 API 的文件。照著那份文件寫出來的 Server，與本系列後續的整合方式不同。這一點 Day 3 會完整說明。

python -m venv .venv && source .venv/bin/activate

pip install "mcp[cli]>=1.29,<2"
pip install google-adk

訓練相關的套件（trl、peft、bitsandbytes）到 Day 15 至 Day 20 才需要，現在不必裝 —— 它們會一併拉進 PyTorch，體積相當可觀。評測工具則是 Day 12 至 Day 14 開始時再裝。

專案結構

整個系列會長成這樣，現在先把骨架開好：

thirty-days/
├── mcp_server/
│   ├── server.py           # 九個工具 + Elicitation
│   └── fixtures.py         # 初始資料與 reset()
├── agents/
│   ├── leave_copilot/        # 主要 Agent
│   │   ├── __init__.py     # from . import agent
│   │   ├── agent.py        # 必須定義 root_agent
│   │   └── .env            # GOOGLE_API_KEY
│   ├── leave_copilot_base/   # 對照組：基座模型
│   ├── leave_copilot_tuned/  # 對照組：微調模型
│   └── leave_copilot_gemini/ # 對照組：商業 API
├── eval/
│   ├── leave_hard_cases.csv  # 四個難點的手寫測試案例
│   └── .adeval/            # 評測工具的實驗資料 ★ 別刪
├── data/                   # 訓練資料
└── out/                    # 訓練產出

agents/ 底下每個子目錄就是一個 app。adk api_server agents/ 會把它們全部載入，而 /list-apps 列出的名稱就是目錄名 —— Day 21 至 Day 30 要一次比較多個模型，靠的就是這個機制。

另外 eval/.adeval/ 這個目錄要特別留意：所有評測實驗的原始紀錄都存在裡面，而它同時也是 Day 15 至 Day 20 訓練資料的原料。誤刪的話，前面跑過的實驗全部要重來。

Port 分配

有三個服務會同時運行，而這裡有一個必須先處理的衝突：

FastMCP 與 Google ADK api_server 的預設 port 都是 8000。 兩個一起起，後起的那個會失敗。

本系列的做法是把 MCP Server 移到 8090：

在 server.py 裡一行指定：

mcp = FastMCP("leave-copilot", host="127.0.0.1", port=8090)

環境變數

Gemini API 金鑰放在 agents/<app>/.env，Google ADK 會自動載入：

# agents/leave_copilot/.env
GOOGLE_API_KEY=your-key-here

記得把 .env 加進 .gitignore。 這個系列的專案很可能會推上 GitHub 當作品集，金鑰外洩是相當常見的意外。

裝到這裡就夠了。剩下的工具會在需要它的那一天再裝，並且說明為什麼需要。

X. 結語

AI Agent 的開發，從「能跑起來」到「能穩定上線」，中間隔著的不只是程式碼，而是一整套工程方法。七月那個研究讓我確認了「小模型也能做事情」這個方向可行，但它畢竟是一次性的實驗；這 30 天要做的，是把它變成一套可重複、可驗證、也能被複製到其他領域的流程。

總結來說，這個系列希望帶給大家以下三個關鍵價值：

• 完整的工程閉環： 從協定設計、Agent 開發、科學化評測，到資料萃取與模型微調，每一步都有明確的產出與驗收方式。單獨看每個環節都不算太難，真正困難的是把它們串成一條能重複執行的路。
• 評測驅動的訓練策略： 七月那次是「訓練完再看看結果」，這次則是「先建立評測、再用評測驅動訓練」。差別在於前者只能知道有沒有變好，後者能知道哪裡變好、為什麼變好，以及下一輪該補什麼資料。
• 誠實的實作紀錄： 包含版本相容性的坑、評測工具本身的盲點、訓練失敗的除錯過程，以及微調後退步的項目。這些通常不會出現在成功案例的分享裡，但它們往往才是真正花掉時間的地方。

展望未來，隨著各家小語言模型（SLM）持續開源、微調工具鏈日趨成熟，「為特定任務打造專屬 Agent 模型」的技術門檻會越來越低。屆時真正的競爭力，將不在於誰用了更大的模型，而在於誰能把領域知識與行為規範，有效地內化進模型權重裡。

明天開始進入技術正題：MCP 到底解決什麼問題，以及 2026 年的它長什麼樣子。

參考來源

• 我要一個「做事情」的 Fine-Tuned Model —— 本系列的前置研究
• Simon-Liu/kubectl-mcp-server-tool-call-reasoning-1k —— 該研究開源的資料集
• MCP 規範 2026-07-28
• ap-mic-inc/ADEval —— 本系列使用的評測工具
• google/adk-python

查證日期：2026-08-19

I am Simon

大家好，我是 Simon 劉育維，是一位 AI 領域解決方案專家，目前擔任 APMIC AI Agent Architect 和 MLOps Engineer，同時也擔任 Google Cloud AI 領域開發者專家 (GDE)，期待能夠幫助企業導入人工智慧相關技術解決問題。如果這篇文章對您有幫助，歡迎在我的 Linkedin 上留言提供意見，並與我一起討論有關人工智慧的主題，期待能夠對大家有所幫助！

我的個人部落格資訊：https://medium.com/@simon3458