前言

Day 28 我們整理了 README、專案架構與執行方式。

到這裡，這個 Agent Testing Platform 已經可以做到：

• 執行 Agent。
• 記錄 Trace。
• 儲存執行紀錄。
• 批次跑 evaluation。
• 自動評分。
• 分析 failure type。
• 使用 prompt version 比較結果。
• 對 JSON 格式錯誤 retry。
• 使用 JSON schema guardrail。
• 使用 tool permission guardrail。
• 記錄 latency、LLM call count、token usage 和 estimated cost。
• 用 dashboard 觀察 reliability。

這些功能已經構成一個完整 MVP。

但完成 MVP 不代表系統已經 production-ready。

Day 29 改從另一個角度檢查這套平台：

誠實整理目前系統的限制、風險，以及下一階段可以怎麼改進。

盤點限制不會否定前面的成果，目的是把系統邊界說清楚。

這篇要完成什麼？

內容分成幾個部分：

1. 整理目前 MVP 的限制。
2. 說明 rule-based evaluator 的風險。
3. 說明 eval dataset 規模不足的問題。
4. 說明 Gemini 單一模型實驗的限制。
5. 說明 token / cost estimation 的限制。
6. 說明 dashboard 與 experiment tracking 還缺什麼。
7. 整理 production-grade AgentOps 還需要哪些能力。
8. 新增 docs/limitations-and-future-work.md。
9. 把未來工作分成短期、中期、長期。

這次先不做：

• 不急著新增功能。
• 不把所有限制都立刻修掉。
• 不引入大型框架。
• 不做 OpenTelemetry。
• 不做完整 LLM-as-a-Judge。

先遵守一個原則：

先把問題說清楚，再決定下一步要解哪個問題。

為什麼要專門寫限制？

很多技術專案容易只展示成功路徑。

例如：

這次 success rate 提升到 86.7%
JSON format error 從 3 降到 0
dashboard 可以看到 latency 和 cost

這些結果是有價值的。

但如果只停在這裡，還有幾個問題沒有回答：

這組 dataset 夠大嗎？
evaluator 判錯的情況多嗎？
Gemini 的結果能代表其他模型嗎？
token cost 是真實費用嗎？
dashboard 能支援長期實驗管理嗎？

這些問題會決定系統能不能從教學 MVP 往更可靠的工程工具前進。

Day 29 不是附帶補充。可驗證系統除了記錄成功，也得交代自己還不能驗證什麼。

限制一：rule-based evaluator 太字面

目前 evaluator 主要是 rule-based。

例如：

• exact_match
• contains
• json_exact

這種方式的優點很明確：

但缺點也很明顯。

Day 27 我們看到幾個例子。

數字格式問題

期待答案是：

3780

模型輸出：

135 * 28 = **3,780**

人看得懂這是正確答案。

但 contains 找不到 3780，因為輸出是 3,780。

所以 evaluator 判錯。

這不是 Agent 算錯。

這是評分規則太字面。

同義詞問題

期待關鍵字是：

任務

模型可能輸出：

目標

期待關鍵字是：

可靠

模型可能輸出：

穩定、安全、準確

這些語意接近，但 rule-based evaluator 不理解語意。

所以會出現：

人覺得可以接受
evaluator 判 failed

這是目前系統最大的評測風險之一。

可以怎麼改善 evaluator？

短期可以先做 normalization。

例如針對數字答案：

3,780 -> 3780
**3,780** -> 3780

也可以針對中文關鍵字提供多個可接受答案。

例如：

{
  "expected_keywords": ["任務", "目標", "工作"]
}

中期可以加入 rubric-based evaluator。

例如 general QA 不只看單一關鍵字，而是看幾個條件：

是否說明 Agent 會自主執行？
是否提到任務或目標？
是否在一句話內完成？

長期可以加入 LLM-as-a-Judge。

但 LLM-as-a-Judge 不是免費解法。

它會帶來新的問題：

• 成本增加。
• latency 增加。
• judge 本身也可能不穩定。
• 需要設計 judge prompt。
• 需要防止 judge 過度寬鬆或過度嚴格。

所以比較務實的順序是：

normalization
  -> 多關鍵字 / rubric
  -> LLM-as-a-Judge

不要一開始就跳到最複雜的方案。

限制二：eval dataset 太小

目前 final experiment 使用 15 筆 cases。

這對 30 天 MVP 很適合。

它足夠展示完整流程：

dataset -> runner -> evaluator -> failure analysis -> dashboard -> experiment

但它不夠支撐很強的統計結論。

例如：

json_strict / no retry: 13 passed
json_strict / retry: 12 passed

這看起來前者比較好。

但只有 15 題時，差 1 題很可能只是 LLM 回覆波動。

不能因此說：

開 retry 一定比較差。

比較保守的說法應該是：

在目前這組小型 eval dataset 上，json_strict / no retry 表現最好。

如果要讓結論更穩定，需要擴充 dataset。

dataset 可以怎麼擴充？

可以從兩個方向擴充。

1. 增加每個 task type 的題數

目前 task type 包含：

未來可以讓每個 task type 至少有 20 到 50 題。

這樣比較不同設定時，結果會更穩定。

2. 增加困難案例

目前 cases 偏簡單。

未來可以加入：

• 輸出格式更嚴格的 JSON。
• 多欄位 schema。
• 不該使用工具的題目。
• 工具權限衝突題。
• 指令遵循邊界題。
• 故意模糊的 user task。
• 多步驟計算。

這些 cases 能更接近真實 Agent 會遇到的情境。

限制三：單次 run 容易受 LLM 非確定性影響

LLM 回覆不是完全 deterministic。

就算 prompt、dataset、provider 都一樣，不同時間跑也可能有細微差異。

Day 27 的 json_strict / retry 就是一個例子。

它沒有真的觸發 retry：

Total LLM calls = 15

但結果比 json_strict / no retry 少通過一題。

這不代表 retry 讓結果變差。

更合理的解讀是：

同一組設定下，LLM 回覆本身仍有波動。

如果要降低這個影響，可以做 repeated runs。

例如每組設定跑 3 次：

baseline / no retry run 1
baseline / no retry run 2
baseline / no retry run 3

然後看平均 success rate，而不是只看單次結果。

但這會增加 API cost 和時間。

所以 MVP 階段先不做。

限制四：Gemini 結果不代表所有模型

目前真實 LLM provider 使用 Gemini。

這很適合作為 MVP。

但要注意：

Gemini 上有效的 prompt，不一定對其他模型同樣有效。

不同模型可能在幾個地方表現不同：

• JSON 格式遵守程度。
• 指令遵循能力。
• 工具呼叫傾向。
• 回答長度。
• 對中文 prompt 的反應。
• 對 retry prompt 的修正能力。

所以 Day 27 的結論應該限定在：

目前 dataset + 目前 evaluator + Gemini provider

如果要擴大結論，需要加入多模型比較。

例如：

但多模型比較也會讓系統複雜度增加。

所以它適合放在未來工作，而不是 Day 29 直接實作。

限制五：token 和 cost 是估算

Day 23 加入了：

• input_tokens
• output_tokens
• total_tokens
• estimated_cost

但目前 token count 是估算。

也就是：

len(text) // 4

這不是模型實際 tokenizer。

而 estimated cost 也是根據環境變數推估：

INPUT_COST_PER_1K_TOKENS
OUTPUT_COST_PER_1K_TOKENS

如果沒有設定，成本就是：

0.00000000

所以目前不能把它解讀成真實帳單。

比較準確的說法是：

這些欄位可以用來比較不同 run 的相對代價。

不是：

這就是 provider 實際收費。

未來可以改善成：

• 從 provider response 讀取真實 usage。
• 針對不同模型設定不同價格。
• 記錄 prompt tokens 和 completion tokens。
• 在 dashboard 顯示 cost model 版本。

限制六：目前還沒有完整 experiment tracking

Day 25 和 Day 26 用了：

• evals/final_experiment_plan.json
• evals/final_experiment_runs.md
• data/eval_runs/eval_run_*.json

這對 MVP 夠用。

但如果實驗變多，會遇到幾個問題：

哪個 run 屬於哪個 experiment？
哪個 run 是 invalid？
哪個 run 有 429？
哪個 run 使用哪份 dataset？
哪個 run 使用哪版程式碼？

目前有些資訊要靠人工記錄。

比較完整的 experiment tracking 應該把這些 metadata 寫進 eval run：

{
  "experiment_id": "gemini_json_strict_no_retry",
  "dataset_version": "cases_v1",
  "code_version": "git_commit_hash",
  "usable_for_analysis": true,
  "notes": "no 429"
}

這樣 dashboard 才能過濾：

只顯示 final experiment runs
排除 invalid runs
依 experiment group 比較

這會是後續很值得做的方向。

限制七：429 和外部 API 狀態會污染結果

前面實作過程中遇到 Gemini 429。

這是一個很實際的問題。

如果某次 eval run 有大量：

execution_error
429

那它不一定代表 Agent 變差。

它可能只是 API quota 或 rate limit 問題。

目前我們用幾個方式降低影響：

• EVAL_DELAY_SECONDS
• fake provider local validation
• 標記 invalid run
• 不把 429 run 拿來做 final comparison

但這還不是完整解法。

更完整的做法包含：

• exponential backoff。
• request queue。
• resume failed cases。
• per-case retry for API error。
• provider status logging。
• rate limit aware scheduler。

這些會讓 eval runner 更接近 production 工具。

但也會讓 Day 29 的範圍太大。

因此這一版只把它列為未來工作。

限制八：dashboard 目前偏觀察，不是實驗管理平台

Day 24 的 Reliability Dashboard 已經可以看：

• success rate
• failure type
• failed cases
• latency
• tokens
• estimated cost
• prompt version comparison

但它還不是完整的 experiment management system。

目前缺少：

• experiment filter。
• run tagging。
• invalid run 標記。
• dataset version filter。
• prompt version 趨勢圖。
• 多次 repeated runs 的平均與標準差。
• case-level history。
• 直接連到 Trace Viewer 的深層連結。

這些功能有用，但不是第一版 MVP 的必要條件。

目前 dashboard 的定位是：

幫助我們觀察 eval run，而不是管理所有實驗生命週期。

production-grade AgentOps 還需要什麼？

目前這套平台是學習用 MVP。

如果要往 production-grade AgentOps 靠近，還需要更多能力。

可以分成幾類。

1. Observability

目前 Trace 是自訂格式。

未來可以考慮：

• OpenTelemetry。
• 分散式 trace。
• request id / user id。
• span-level latency。
• tool latency。
• model latency。
• error rate monitoring。

2. Evaluation

目前 evaluation 是小型離線 batch。

未來可以考慮：

• 更大的 eval dataset。
• dataset versioning。
• regression test。
• repeated runs。
• LLM-as-a-Judge。
• human review workflow。
• production sampling。

3. Guardrails

目前 guardrails 包含：

• JSON schema。
• tool permission。

未來可以考慮：

• PII detection。
• prompt injection detection。
• forbidden tool call detection。
• response policy checking。
• output redaction。
• groundedness validation。

4. Operations

目前 runner 是手動執行。

未來可以考慮：

• CI integration。
• scheduled eval。
• failed case replay。
• experiment registry。
• dashboard deployment。
• alerting。

Day 29 不會實作這些項目，這份清單只是標出 Agent testing 的涵蓋範圍：

Agent testing 涵蓋的是一整套工程流程。

新增限制與未來工作文件

Day 28 已經在 README 放了短版 limitations。

這裡新增一份較完整的文件。

新增 docs/limitations-and-future-work.md：

# Limitations and Future Work

This project is an MVP for learning and experimenting with AI Agent testing.

It is not a production-ready AgentOps platform.

## Current Limitations

### 1. Small Eval Dataset

The current eval dataset is small and should not be used to make broad claims about model quality.

Future work:

- Add more cases per task type.
- Add harder edge cases.
- Version the dataset.

### 2. Rule-based Evaluator

The evaluator is explainable and cheap, but it is strict about string matching.

Known issues:

- `3780` and `3,780` may be treated differently.
- Synonyms may be marked as wrong.
- Semantic equivalence is not handled.

Future work:

- Add normalization.
- Support multiple acceptable keywords.
- Add rubric-based grading.
- Explore LLM-as-a-Judge.

### 3. Single Real LLM Provider

The current real provider is Gemini.

Results should not be generalized to all models.

Future work:

- Add more providers.
- Compare model behavior across providers.
- Track provider and model versions.

### 4. Estimated Token and Cost

Token usage and cost are estimated.

They should not be treated as actual billing data.

Future work:

- Read provider usage metadata.
- Track prompt and completion tokens separately.
- Add model-specific pricing configuration.

### 5. Limited Experiment Tracking

Experiment metadata is partially tracked by files and manual notes.

Future work:

- Add `experiment_id` to eval run metadata.
- Track dataset version.
- Track code version.
- Mark invalid runs.

### 6. API Rate Limits

Gemini API may return 429 errors during repeated eval runs.

Future work:

- Add exponential backoff.
- Add failed case resume.
- Add rate-limit-aware scheduling.

### 7. Dashboard Scope

The dashboard is for observation, not full experiment management.

Future work:

- Add experiment filters.
- Add run tags.
- Add trend charts.
- Link failed cases to trace sessions.

## Suggested Roadmap

### Short-term

- Improve evaluator normalization.
- Add experiment metadata.
- Add dataset version field.
- Improve README and setup instructions.

### Mid-term

- Expand eval dataset.
- Add repeated runs.
- Add better dashboard filtering.
- Add API error retry and resume.

### Long-term

- Add LLM-as-a-Judge.
- Add multi-model comparison.
- Add RAG evaluation.
- Add OpenTelemetry-compatible tracing.
- Add CI-based regression evaluation.

這份文件的用途是：

把限制從文章內容變成專案文件。

這樣 README 可以保持簡潔。

更完整的風險和未來方向則放在 docs/。

未來工作的優先順序

未來工作很多。

但不應該全部同時做。

可以用影響和成本來排優先順序。

短期：最值得先做

短期目標是：

讓目前平台的比較結果更可信。

中期：讓 eval 更穩定

中期目標是：

讓實驗可以重複執行，並且比較結果更穩定。

長期：往 AgentOps 靠近

長期目標是：

讓平台從教學 MVP 走向更完整的 Agent evaluation workflow。

限制整理

這一篇沒有新增功能，處理的是限制與風險盤點。

目前這個 MVP 的主要限制包含：

• rule-based evaluator 太字面。
• eval dataset 太小。
• 單次 run 容易受 LLM 非確定性影響。
• Gemini 結果不代表所有模型。
• token 和 cost 是估算。
• experiment tracking 還不完整。
• API 429 會污染實驗結果。
• dashboard 偏觀察，不是完整實驗管理平台。

這些限制不會抹去前面的成果，也讓下一階段該做什麼更清楚。

最後留下一個判讀原則：

好的 eval 系統不只告訴你哪些 case 通過，也要告訴你目前的結論有多可信。

下一步

Day 30 會做最後總結。

我們會回顧整個系列從 Day 1 到 Day 29 做了什麼，整理出一條完整的 Agent testing workflow：

Trace
  -> Eval
  -> Failure Analysis
  -> Prompt Improvement
  -> Retry
  -> Guardrails
  -> Metrics
  -> Dashboard
  -> Experiment
  -> Limitations

最後一天不會宣稱做出完美平台，而是整理這 30 天累積的方法：

讓 Agent 從黑盒，變成可以被觀察、測試、分析與持續改善的工程系統。