第四部｜走向 Production · 第 8 章
測試、Observability 與安全邊界
用 deterministic fixtures 與 run events 提升成功率，同時劃清 MCP、sandbox 與多租戶責任。
一句話掌握本章核心：將 Agent 推向 Production 需要三類工程防線——測試金字塔驗證已定義的 contract 並累積可重現信心。可觀測性（Observability）量化成本、延遲與失敗。安全邊界與執行膠囊（Execution Capsule）則由部署層限制不可信程式能觸及的資源。tiny-agent 四語言 CLI 本身仍是普通 host process，沒有內建 container、cgroup 或 egress sandbox。
Agent 測試金字塔：三個層級的驗證
建立 Agent 測試體系時，切忌將所有測試都綁定在高昂且不穩定的真實 LLM API 上：
| 測試層級 | 驗證核心目標 | 是否消耗真實 API 額度？ | 在 CI/CD 中的角色 |
|---|---|---|---|
| 1. Unit & Contract | Provider 正規化、Pure Reducer 狀態重組、Pure Planner 決策 | ❌ 否（純離線） | Release Gate 核心門檻：PR 必須通過目前定義的 assertions。通過不等於證明未涵蓋情境也正確 |
| 2. Conformance & Integration | 以共享 schema/fixtures 與各語言測試追求 TS/Go/Python/Rust 行為等價。MCP 使用本機 fixture | ❌ 否（使用 Mock Server） | 偵測實作漂移。目前不是單一 runner 對四語言逐 event transcript 做完全同構證明 |
| 3. Capability Eval | 驗證 Agent 能否自主修復真實 Bug 或重構程式碼 | ✅ 是（呼叫真實 Model） | 定期評測與模型升級時的品質衡量標準 |
評估原則：Outcome 是客觀分數，Trace 是診斷解釋
在 Capability Eval 中，成績判定必須依賴客觀的外部驗證器（Hidden Verifier），而非由模型自我宣稱：
1. 初始化隔離環境 ──→ 將評測程式碼複製至暫存目錄 (Temp Workspace)
↓
2. 啟動 Tiny-Agent ──→ 執行修復任務 (記錄 Token, Latency, Tool 次數)
↓
3. 執行隱藏測試 ──→ verifier.mjs 或 test.sh
↓
4. 判定客觀結果 ──→ 未 timeout AND agent exit 0 AND verifier exit 0 才是 PASS結構化日誌（Structured Run Events）與 Prompt Cache 監控
生產環境中的 Agent 應提供機器可讀輸出（如 tiny-ts --json "任務"）。tiny-agent 會輸出 JSONL run events。若要接入 OpenTelemetry Logs 或 Prometheus，仍需另寫 adapter/exporter 與資料治理設定：
// 欄位節錄。實際每筆 event 另含 timestamp，run events 還有 endpoint/session/usage 等欄位
{"type":"run.started","sessionId":"019...","model":"<provider-model-id>"}
{"type":"model.completed","durationMs":1250.4,"usage":{"input":150,"output":40,"cacheRead":1800,"cacheHitRate":92.3}}
{"type":"tool.started","toolCallId":"call_1","tool":"read"}
{"type":"tool.completed","toolCallId":"call_1","tool":"read","durationMs":8.2,"ok":true}
{"type":"run.completed","result":{"status":"succeeded","answer":"已成功修復檔案。"}}| 監控維度 | 關鍵指標 (Metrics) | 異常排查與警示 |
|---|---|---|
| Prompt Cache 命中率 | cacheHitRate (%) | 命中率驟降是診斷訊號。可能原因包含 prefix 改變、TTL、最低快取長度、provider/model routing、cache eligibility 或 usage 欄位缺失，不能由單一指標直接斷定根因。 |
| Tool 呼叫延遲 | durationMs | 監控外部 MCP 或 Bash 指令是否發生長尾延遲或卡死。 |
| 資料隱私保護 | Payload 分類與脫敏 | Tool events 不含完整 args/result，可降低監控 payload。但 run.completed.result.answer、failure message 與 metadata 仍可能敏感。Production 仍需 redaction、access control、retention 與 tenant binding。 |
安全邊界矩陣：誰信任誰？
在計算機系統安全中，永遠不要信任未經驗證的輸入：
| 系統元件 | 信任等級 | 職責與安全邊界 |
|---|---|---|
| Agent 核心程式碼 | 🛡️ Trusted（部署假設） | 信任來自 pinned artifact、code review、tests、supply-chain controls 與受控 runtime image，不是因使用某種語言便自動可信。 |
| LLM 模型輸出 | ⚠️ Untrusted | Tool arguments 視為外部輸入。Built-in tools 在 Host 逐欄 guard。MCP adapter 目前只先確認 args 是 object，remote inputSchema 的完整驗證責任仍由 MCP server 承擔。 |
| 外部 Repository 程式碼 | ⚠️ Untrusted | 專案中的依賴腳本或測試指令可能包含惡意程式碼，嚴禁在宿主機直接裸跑。 |
MCP 與 --plugin | 🔧 Tool Adapter | 僅作為能力選擇器，絕不能當作多租戶授權（ACL）或安全沙盒。 |
多租戶隔離：Execution Capsule（執行膠囊）
若產品為不同客戶執行不可信 repository 與指令，單靠應用層路徑檢查不足以形成 tenant boundary。這是部署層責任。tiny-agent repo 未建立下列 Execution Capsule：
- 資源配額：以 cgroup v2 限制 CPU、memory、I/O 與 process count。writable bytes/inodes 另由 bounded volume、filesystem/project quota 或 overlay 配額限制，不能把 inode quota 當成 cgroup controller。
- 網路出站防護（Egress & SSRF）：deny by default，阻斷 loopback、private、link-local、metadata（例如 AWS IMDS
169.254.169.254）與未授權內網目的地，並重新驗證 DNS 與 redirect。 - 生命週期終止：停止新權限並撤銷 credentials，送 TERM、等待固定 grace period、使用 cgroup kill，最後驗證 cgroup 為空。單靠對某個 PID 送 TERM→KILL 不保證沒有逃逸 descendants。
動手驗證 (Hands-on Lab)
在可信的開發 checkout 執行 repo 離線驗證。這些命令會執行專案程式碼。不要把它們直接套用到未隔離的敵對 repository：
# 1. 執行全專案四語言離線單元測試與程式碼檢查
make test
make check
# 2. 驗證教科書靜態網站建置與測試
npm --prefix book run build
npm --prefix book test
# 3. 檢視 Eval Runner 的客觀驗證器實作
cat eval/tasks/config-loader/verify.mjs-
第一部｜最小閉環
無壓力環境・建立標準 Loop 與正規化
-
第二部｜能力邊界
能力壓力・Tool 守衛與 Skill 漸進載入
-
第三部｜可靠執行
失敗壓力・Durable WAL、復原與雙切點壓縮
-
第四部｜走向 Production
觀測與信任壓力・測試金字塔與執行膠囊
全書完結：一個小而深的 Agent Loop 核心，加上一份具明確 framing、復原語意與內部一致性檢查的 Durable Session——你已具備檢視現代 AI Agent 核心工程取捨的可追溯基礎。production isolation、authorization、audit 與 retention 仍由具體部署負責。