今天是這個系列的最後一天。
30 天前，我們從一個很簡單的問題開始：
AI Agent 回答了問題，但我們真的知道它中間發生什麼事嗎？
一開始的 Agent 幾乎是黑盒。
我們只看得到：
user input
final answer
但看不到：
它有沒有呼叫工具？
工具輸入是什麼？
工具結果是什麼？
哪一步失敗？
為什麼 evaluator 判錯？
改 prompt 之後有沒有變好？
retry 增加了多少成本？
guardrail 擋下了什麼？
這 30 天的工作，是逐步讓這些問題可以被觀察、測試和比較。
最後一天不新增功能。
最後整理出的是：
一套讓 Agent 從黑盒變成可驗證工程系統的流程。
這個系列最後完成的是一個輕量版 Agent Testing Platform。
它不是 production-ready AgentOps 平台。
它也不是一個很強的 Agent。
它的重點是建立一套方法：
Trace
-> Eval
-> Failure Analysis
-> Prompt Improvement
-> Retry
-> Guardrails
-> Metrics
-> Dashboard
-> Experiment
-> Limitations
透過這條流程，我們可以回答幾個具體問題。
| 問題 | 對應能力 |
|---|---|
| Agent 做了什麼？ | Trace |
| Agent 有沒有完成任務？ | Eval |
| 為什麼失敗？ | Failure type |
| 改 prompt 有沒有用？ | Prompt versioning |
| retry 值不值得？ | Retry metrics |
| 輸出格式是否合格？ | JSON schema guardrail |
| 工具呼叫是否安全？ | Tool guardrail |
| 改善可靠性花了多少代價？ | Cost / latency metrics |
| 結果怎麼觀察？ | Reliability Dashboard |
| 結論可信嗎？ | Limitations and future work |
這個系列最後留下的，是一條可重複的工程流程，而不是某個單一功能。
第一週的重點是 Trace。
我們先建立最小 Agent Runner，讓系統可以接收任務、呼叫 LLM，並回傳答案。
接著加入 calculator tool，讓 Agent 可以使用工具完成明確任務，不再只產生文字。
開始記錄 Trace 後，開發方式才出現明顯轉折。
Trace 讓我們不只看 final answer，而是看到：
第一週最後，我們把 Trace 存進 SQLite，並建立 Trace Viewer。
這時看到的已經不只是：
輸入 -> 輸出
而是變成：
輸入 -> 每一步執行紀錄 -> 輸出
後面的 eval 和 guardrails 都建立在這份 Trace 上。
如果沒有 Trace，失敗只能靠猜。
有了 Trace，失敗才有證據可以分析。
第二週的重點是 Evaluation。
我們先定義 test case 格式：
{
"id": "case_001",
"input": "請計算 135 * 28",
"expected": "3780",
"grading_method": "contains",
"task_type": "calculation"
}
接著建立第一組 eval dataset，包含：
然後實作 Batch Evaluation Runner。
Runner 負責：
讀取 cases
逐筆呼叫 Agent
儲存 trace
自動評分
輸出 eval run JSON
第二週我們也加入了最小 evaluator：
這些 evaluator 很簡單，但足夠讓系統從「手動看答案」進化成「批次測試與自動評分」。
第二週最後，我們產生第一份 Agent 評測報告。
那時候平台已經可以回答：
這次跑了幾題？
通過幾題？
失敗幾題？
每題為什麼失敗？
第三週的重點是把系統接到真實 LLM，然後開始改善。
Day 15 從 fake provider 接到 Gemini。
fake provider 適合驗證流程，卻不能代表真實模型行為，因此這一步必須接上 Gemini。
接上 Gemini 後，我們開始看到更真實的問題：
接著 Day 16 定義 failure type。
失敗也從單一的：
passed = false
而是更細地分成：
format_error
wrong_answer
instruction_error
tool_error
execution_error
Day 17 建立 Failure Dashboard。
Day 18 加入 prompt versioning，讓每次 eval run 都記錄：
{
"prompt_version": "baseline"
}
Day 19 加入 retry。
Day 20 加入 JSON schema guardrail。
Day 21 做第三週回顧。
第三週整理出一個做法：
真實 LLM 的問題不能只靠感覺修，要用 eval run 和 failure type 找出最值得處理的失敗類型。
第四週的重點是 Guardrails、Metrics、Dashboard 和 Experiment。
Day 22 加入 Tool Guardrail。
Agent 可以使用工具，但不是每個任務都應該允許它使用每個工具。
所以我們在 test case 裡加入：
{
"allowed_tools": ["calculator"]
}
並在工具執行前檢查權限。
Day 23 加入成本與延遲紀錄。
每筆 result 開始記錄：
latency_ms
llm_call_count
input_tokens
output_tokens
total_tokens
estimated_cost
這讓我們不只看：
有沒有通過？
也開始看：
花了多久？
呼叫幾次？
估計成本是多少？
Day 24 把 Failure Dashboard 擴充成 Reliability Dashboard。
Dashboard 開始能比較：
Day 25 設計 final experiment。
Day 26 執行 final experiment。
Day 27 分析實驗結果。
Day 28 整理 README。
Day 29 整理限制與未來工作。
第四週讓整個系統從「可以評分」進一步變成：
可以比較不同改善策略，並且看見可靠性背後的代價。
整理後，專案大致長這樣：
agent-testing-platform/
app.py
trace_viewer_app.py
failure_dashboard_app.py
agents/
client_factory.py
fake_llm.py
gemini_llm.py
prompts.py
simple_agent.py
tools/
calculator.py
tracing/
models.py
storage/
database.py
schema.sql
evals/
cases.json
evaluators.py
runner.py
final_experiment_plan.json
final_experiment_runs.md
analyze_final_runs.py
guardrails/
json_schema.py
tool_permissions.py
metrics/
cost.py
ui/
trace_viewer.py
failure_dashboard.py
tests/
test_json_schema_guardrail.py
test_tool_permissions_guardrail.py
這個架構對應到幾個責任邊界。
| 模組 | 負責內容 |
|---|---|
agents/ |
Agent 執行、LLM provider、prompt version |
tools/ |
Agent 可呼叫工具 |
tracing/ |
Trace 資料結構 |
storage/ |
SQLite 儲存 |
evals/ |
test cases、runner、evaluator、experiment |
guardrails/ |
JSON schema、tool permission |
metrics/ |
token / cost estimation |
ui/ |
Trace Viewer、Reliability Dashboard |
tests/ |
guardrail tests |
這不是大型架構。
但對一個 MVP 來說，它已經有清楚的分工。
整個系統可以分成兩條線。
第一條是 Agent 執行線：
User Task
-> SimpleAgent
-> LLM Client
-> Tool Call
-> Tool Guardrail
-> Tool Execution
-> Trace
-> SQLite
第二條是 Evaluation 線：
Eval Cases
-> Eval Runner
-> Agent
-> JSON Schema Guardrail
-> Evaluator
-> Eval Run JSON
-> Reliability Dashboard
這兩條線會交會在 Agent 和 Trace。
Agent 是被測試的對象。
Trace 是理解 Agent 行為的證據。
Eval run 則是把多次 Agent 執行整理成可比較資料。
Day 26 和 Day 27 的 final experiment 使用同一份 eval dataset，比較四組設定。
| experiment | passed | failed | success rate | LLM calls | total latency |
|---|---|---|---|---|---|
| baseline / no retry | 10 | 5 | 66.7% | 15 | 88262.05 ms |
| json_strict / no retry | 13 | 2 | 86.7% | 15 | 80131.38 ms |
| baseline / retry | 11 | 4 | 73.3% | 18 | 105118.41 ms |
| json_strict / retry | 12 | 3 | 80.0% | 15 | 79742.16 ms |
這次結果支持的結論是：
在目前這組 eval dataset 上，json_strict / no retry 是最值得保留的設定。
理由如下。
第一，success rate 最高。
13 / 15 = 86.7%
第二，它把 JSON format error 從 3 降到 0。
第三，它沒有增加 LLM calls。
相比之下，baseline + retry 也能修正 JSON format error，但它多了 3 次 LLM call。
所以這次比較後，比較務實的設定是：
預設使用 json_strict prompt。
保留 retry 作為格式錯誤的備援。
這不是通用定理。
它只是在目前 dataset、目前 evaluator、目前 Gemini provider 下的結論。
這個系列反覆出現一件事：
只看 success rate 會漏掉很多重要資訊。
例如：
baseline / retry 的 success rate 比 baseline 高。
但它也讓：
LLM calls: 15 -> 18
latency: 88262.05 ms -> 105118.41 ms
retry 確實有用，但會增加呼叫次數與延遲。
再例如，有些 wrong_answer 不一定是 Agent 真的錯。
3780 和 3,780 的差異，對人來說是格式差異。
對 contains evaluator 來說卻是 failed。
評測結果同時受 Agent 能力與 evaluator 設計影響。
所以比較完整的觀察方式應該是：
success rate
+ failure type
+ trace
+ latency
+ cost
+ evaluator limitation
這是整個系列反覆驗證的判讀方式。
Day 29 已經整理過限制。
這裡再濃縮一次。
目前系統仍有幾個限制：
這些限制沒有推翻 MVP 的結果，反而指出下一步該補強的地方。
如果要繼續往前，應先處理以下項目：
改善 evaluator
擴充 dataset
加入 experiment metadata
支援 repeated runs
改善 API error handling
這些會直接提升評測結果的可信度。
這個專案之後可以往幾個方向延伸。
短期可以做：
長期可以加入：
可以擴充：
可以加入：
experiment_id
dataset_version
code_version
usable_for_analysis
可以加入：
這些都不是 30 天 MVP 必須完成的事情。
這份清單可以當成下一階段的路線。
完成這個系列後，遇到一個新的 Agent，不需要只靠直覺調 prompt。
可以按照這條流程來做：
這套流程不只適用於這個 toy project。
任何需要被驗證的 Agent，都可以從這個流程開始。
Day 1 問的是：
為什麼 AI Agent 需要被測試？
30 天後，我們可以給出比較完整的回答。
因為 Agent 的問題通常不是單純的「答對或答錯」。
它可能是：
如果沒有 Trace、Eval、Guardrails 和 Dashboard，這些問題很容易被混在一起。
最後只剩一句：
模型好像不太穩。
但有了這套平台後，我們可以更精準地說：
哪一類任務不穩。
失敗原因是什麼。
哪個改善策略有效。
改善策略的成本是多少。
目前結論有哪些限制。
這些具體紀錄，就是從黑盒走向可驗證後的差別。
這 30 天沒有做出完美 Agent，也不是完整的 AgentOps 平台。完成的是一套可以逐步落地的 Agent engineering workflow。
它從最小 Agent 開始，逐步加入：
每一步都不大，串起來後便形成一個能觀察、測試、分析和改善的系統。
最後可以用一句話收束：
不要只問 Agent 答得好不好，而是建立一套流程，讓你能知道它怎麼答、為什麼錯、怎麼改，以及改了之後是否真的更好。
Agent 從 demo 走向工程系統時，缺的往往就是這套驗證流程。
iThome鐵人賽
看影片追技術