前言：從「手動調 Prompt」邁向「雙層遞迴自主演化」 歡迎來到《Agent Platform 實戰》Harness² 三部曲的最終篇！在前兩篇文章中： [Agent Platform 實戰 (7)] 當 ADK Go Graph Workflow 遇上 Google Research Harness² (上)：認識雙層遞迴 Agent 裝備框架與 c1..c8 解耦實戰（Issue #16）：我們介紹了 Google Research 的 google-research/harness2 (arXiv:2610.14224)，並將 LINE AI 名片王 (kkdai/line-card-assistant) 的 13 節點 Graph Workflow 解耦為支援 LINE_CARD_HARNESS_DIR 動態掛載的 c1..c8 可編輯檔案樹。 [Agent Platform 實戰 (8)] 當 ADK Go Graph Workflow 遇上 Google Research Harness² (中)：把 Phase 4 Eval Datasets 與 Phase 5 OpenTelemetry Spans 變成 LineCardAdapter（Issue #17）：我們將 Phase 4 的 eval/datasets/ 與 Phase 5 的 OpenTelemetry workflow.node.* Spans 封裝為 LineCardAdapter，建立了 零洩漏屏障（Zero-Leakage Barrier） 與 高解析度行為軌跡（trajectory.md）。 在本篇（下篇，對應 Issue #18 與 PR #19）中，我們將回答最後三個關鍵問題： 修改後該如何測試？（從 Go 單元測試、CLI 單點診斷、Python 雙層遞迴實驗到生產環境掛載的完整測試指南） 整體修改後的效能表現如何？（公開 Base 62.5% $\rightarrow$ k=1 84.4% $\rightarrow$ k=2 Parallel 96.9% $\rightarrow$ k=2 Sequential + Memory 100.0% 的完整量化數據與演化細節） 對於 Harness² 與 Agent 後續的展望，有哪些值得期待的應用場景？ 一、修改後該如何測試？（Step-by-Step 測試與驗證指南） 導入 Harness² 後，整個專案具備了 Go 原生單元測試、單一任務 OpenTelemetry 軌跡診斷、Python 雙層遞迴演化實驗 與 生產環境無縫切換 四個層次的測試與驗證方式： 1. 層次一：執行 Go c1..c8 表面約束與全專案單元測試 我們在 internal/harness/harness_test.go 中編寫了完整的單元測試，驗證： harness/base/ 與 harness/evolved/ 下所有 c1..c8 檔案樹皆符合 OPENCODE_SURFACE 24KB 常駐位元組上限（AlwaysOnMaxBytes...

前言：為什麼解耦了 Prompt 還不夠？ 在上一篇 [Agent Platform 實戰 (7)] 當 ADK Go Graph Workflow 遇上 Google Research Harness² (上)：認識雙層遞迴 Agent 裝備框架與 c1..c8 解耦實戰（對應 Issue #16）中，我們介紹了 Google Research 的 google-research/harness2 (arXiv:2610.14224)，並將 LINE AI 名片王 (kkdai/line-card-assistant) 的提示詞、護欄、長期記憶與按需技能解耦為可透過 LINE_CARD_HARNESS_DIR 動態掛載的 c1..c8 可編輯 Harness 檔案樹。 然而，光有可熱載入的 c1..c8 檔案樹，Harness² 的雙層遞迴優化引擎（harness2/core/recursion.py）仍然無法直接對我們的 Go Agent 進行優化。因為 Harness² 需要一個標準化的橋樑 —— BenchmarkAdapter —— 來回答三個問題： list_tasks()（考題是什麼？）：Agent 要挑戰哪些測試案例？每個案例有哪些公開輸入（Prompt / Image），又有哪些對 Agent 隱藏的評分標準（Rubrics）？ run()（Agent 怎麼思考與執行的？）：當掛載某個候選 Harness $H’$ 執行某道考題時，Agent 最終產出了什麼（deliverable）？更重要的是，它在 Graph Workflow 的 13 個節點中間經歷了什麼樣的決策軌跡（trajectory.md）？ score()（表現如何？）：最終產出與執行軌跡通過了哪些獨立的評分項目（per_rubric），又在哪些項目失分了？ 剛好！我們在 Phase 4（PR #13） 已經建立了 eval/datasets/ 自動化評估基準，在 Phase 5（PR #14） 又為全部 13 個 Graph Node 加上了 workflow.node.* OpenTelemetry Spans！ 在本篇（中篇，對應 Issue #17 與 PR #19）中，我們將把這兩塊既有資產融合成 Harness² 的 LineCardAdapter，並深入解釋 「為什麼一定要這樣設計？」。 一、為什麼要這樣改？兩大核心設計哲學 在動手寫程式碼之前，許多工程師常會問兩個問題： 「為什麼不直接把 eval/datasets/*.json 整份 JSON 丟給優化器 LLM，讓它自己改 Prompt 就好？」 「為什麼還需要把 Phase 5 的 OpenTelemetry Spans 轉成 trajectory.md？只看最後的 LINE 回覆文字與總分不夠嗎？」 這兩個問題正好觸及了 Harness² 論文中最核心的兩個工程設計：零洩漏屏障（Zero-Leakage Barrier） 與 行為軌跡對照（Behavioral Trajectory Contrast）。 1. 為什麼需要「零洩漏屏障（Zero-Leakage Barrier）」？防止優化器「背答案作弊」 試想一下：如果我們把 eval/datasets/harness2-challenge-dataset.json 裡的黃金答案（例如 expected_contains: ["+81-3-1234-5678", "佐藤健太 (Kenta Sato)"]）直接暴露給 Agent 或 Harness² 的 Harvester LLM，會發生什麼事？ 優化器最偷懶、也最容易拿滿分的作法，就是在 systemprompt.md 寫下一行： 「如果輸入包含 Sato，請直接輸出...

前言：當 AI Agent 上線之後，下一個瓶頸是什麼？ 歡迎回到《Agent Platform 實戰》系列！在前六篇文章中，我們帶著 LINE AI 名片王 (kkdai/line-card-assistant) 走完了從單機原型到生產級雲端部署的完整五個階段： [Agent Platform 實戰 (1)] 用 Go 與 Google ADK 2.0 Graph Workflow 打造 LINE AI 名片王：用 google.golang.org/adk/v2/workflow 打造具備 Vision OCR、AddFanOut / AddFanIn 平行背景調查與 NewRequestInputEvent HITL 互動迴圈的 13 節點有向圖。 [Agent Platform 實戰 (2)] 從單體 Cloud Run 邁向 Google Cloud Agent Runtime：完成 Phase 1（PR #10），將專案標準化為 agents-cli (adk_go) 雙通道架構。 [Agent Platform 實戰 (3)] 用 ADK 2.0 GCS Artifact Service 與 Agent Platform Sessions 實現跨實例名片辨識與暫停恢復：完成 Phase 2 前半（PR #11），解決無狀態容器的 HITL 失憶症與二進位圖片爆量問題。 [Agent Platform 實戰 (4)] 用 Cloud Run LINE Webhook Gateway、Agent Runtime 與 Cloud SQL PostgreSQL 完成架構拼圖：完成 Phase 2 後半 & Phase 3（PR #12），將名片庫升級至 Cloud SQL PostgreSQL 並實現雙層無狀態解耦。 [Agent Platform 實戰 (5)] 用 agents-cli eval 與 ADK 2.0 Go 建立自動化評估基準：完成 Phase 4（PR #13），建立黃金測試集與品質飛輪。 [Agent Platform 實戰 (6)] 用 agents-cli deploy、Terraform IaC、GitHub Actions CI/CD 與 Cloud Trace 打造全棧可觀測的 LINE AI 名片王：完成 Phase 5（PR #14），把 13 個 Graph Node 全數加上 OpenTelemetry Spans (workflow.node.*) 並透過...

前情提要：從單機原型到雲端生產級 AI Agent 的五階段演進 歡迎來到《Agent Platform 實戰》系列的第六篇（最終章）！回顧過去五篇文章，我們帶著 LINE AI 名片王 (kkdai/line-card-assistant) 一路闖關，完成了從本地原型到企業級 AI Agent 架構的四大階段： [Agent Platform 實戰 (1)] 用 Go 與 Google ADK 2.0 Graph Workflow 打造 LINE AI 名片王：以 google.golang.org/adk/v2/workflow 實作涵蓋 Vision OCR、AddFanOut / AddFanIn 平行背景調查與 NewRequestInputEvent HITL 互動迴圈的名片工作流圖。 [Agent Platform 實戰 (2)] 從單體 Cloud Run 邁向 Google Cloud Agent Runtime：用 agents-cli 與 ADK Go 重構 LINE AI 名片王：完成 Phase 1（PR #10），將專案標準化為 agents-cli (adk_go) 雙通道架構，同時支援 LINE Webhook、ADK WebUI Playground 與 A2A 協定。 [Agent Platform 實戰 (3)] 破解無狀態容器的 HITL 失憶症：用 ADK 2.0 GCS Artifact Service 與 Agent Platform Sessions 實現跨實例名片辨識與暫停恢復：完成 Phase 2 前半（PR #11），導入 artifact/gcsartifact 與 session/vertexai 解決無狀態容器的跨實例 HITL 恢復與圖片儲存問題。 [Agent Platform 實戰 (4)] 邁向雲端雙層解耦與全持久化：用 Cloud Run LINE Webhook Gateway、Agent Runtime 與 Cloud SQL PostgreSQL 完成 LINE AI 名片王架構拼圖：完成 Phase 2 後半（Issue #5） 與 Phase 3（Issue #6，PR #12），將名片庫遷移至 Cloud SQL PostgreSQL (PostgresStore)，並打造無狀態的 Cloud Run LINE Webhook Gateway (internal/gateway)。 [Agent Platform 實戰 (5)] 打造 AI Agent 的品質飛輪 (Quality Flywheel)：用 agents-cli...

前情提要 在《Agent Platform 實戰》系列的前四篇文章中，我們一步步將 LINE AI 名片王 (line-card-assistant) 從單機原型推進為雲端原生、雙層解耦的 Google Cloud Agent Platform 架構： [Agent Platform 實戰 (1)] 用 Go 與 Google ADK 2.0 Graph Workflow 打造 LINE AI 名片王：使用 google.golang.org/adk/v2/workflow 打造 12 個節點的名片處理圖（Graph Workflow），涵蓋 Vision OCR、AddFanOut / AddFanIn 平行背景調查，以及 NewRequestInputEvent 的 HITL（Human-in-the-Loop）暫停與修改迴圈。 [Agent Platform 實戰 (2)] 從單體 Cloud Run 邁向 Google Cloud Agent Runtime：用 agents-cli 與 ADK Go 重構 LINE AI 名片王：完成 Phase 1（PR #10），導入 agents-cli (adk_go) 標準雙通道架構，同時支援 LINE Webhook、ADK WebUI Playground 與 A2A 協定。 [Agent Platform 實戰 (3)] 破解無狀態容器的 HITL 失憶症：用 ADK 2.0 GCS Artifact Service 與 Agent Platform Sessions 實現跨實例名片辨識與暫停恢復：完成 Phase 2 前半（PR #11），用 artifact/gcsartifact 與 session/vertexai 讓無狀態容器支援跨實例 HITL 暫停與恢復。 [Agent Platform 實戰 (4)] 邁向雲端雙層解耦與全持久化：用 Cloud Run LINE Webhook Gateway、Agent Runtime 與 Cloud SQL PostgreSQL 完成 LINE AI 名片王架構拼圖：完成 Phase 2 後半（Issue #5） 與 Phase 3（Issue #6，PR #12），將名片庫遷移至 Cloud SQL PostgreSQL (PostgresStore)，並實作無狀態的 Cloud Run LINE Webhook Gateway (gateway.Client)。 當架構與功能都到位、準備正式將 Agent 部署上雲端生產環境（Phase 5）之前，所有 AI 工程團隊都會面臨一個最核心的靈魂拷問： 「當我們修改了一行 Prompt、調整了一個 Graph...

前情提要 在《Agent Platform 實戰》系列的前三篇文章中，我們一步步將 LINE AI 名片王 (line-card-assistant) 從概念原型推向雲端原生架構： [Agent Platform 實戰 (1)] 用 Go 與 Google ADK 2.0 Graph Workflow 打造 LINE AI 名片王：我們用 google.golang.org/adk/v2/workflow 打造了 12 個節點的名片處理圖（Graph Workflow），涵蓋 Vision OCR、AddFanOut / AddFanIn 平行背景調查，以及 NewRequestInputEvent 的 HITL（Human-in-the-Loop）暫停與修改迴圈。 [Agent Platform 實戰 (2)] 從單體 Cloud Run 邁向 Google Cloud Agent Runtime：用 agents-cli 與 ADK Go 重構 LINE AI 名片王：完成 Phase 1（PR #10），導入 agents-cli (adk_go) 標準雙通道架構，讓專案同時支援 LINE Webhook、ADK WebUI Playground 與 A2A 協定。 [Agent Platform 實戰 (3)] 破解無狀態容器的 HITL 失憶症：用 ADK 2.0 GCS Artifact Service 與 Agent Platform Sessions 實現跨實例名片辨識與暫停恢復：完成 Phase 2 前半（PR #11），用 artifact/gcsartifact 將幾 MB 的名片照片移出 Session.State，並結合 session/vertexai 實作 resolvePendingHITL，讓無狀態容器即使縮容至 0 或切換實例，也能無縫接續 HITL 修改與確認存檔。 今天這篇系列文的第四集，我們要一口氣完成 Phase 2 最後一塊拼圖（Issue #5） 與 Phase 3 核心架構升級（Issue #6）（對應 PR #12）： 雲端名片資料庫持久化（PostgresStore / Cloud SQL）：將原本存在本地記憶體或容器暫存檔的名片庫，正式升級為支援 Cloud SQL PostgreSQL 的關聯式與 JSON 混合儲存，並打通 HybridSearch 與 Token 計分容錯的 BroadSearch。 雙層解耦呼叫架構（Cloud Run LINE Webhook Gateway $\rightarrow$ Agent Runtime）：將負責「LINE 驗章與圖片下載」的輕量邊緣層（Edge Layer），與負責「ADK 2.0 Graph Workflow 多模態推論與搜尋」的執行層（Execution Layer）徹底解耦！ 一、為什麼我們需要「雲端持久化鐵三角」與「雙層解耦架構」？ 當我們把 line-card-assistant 部署到...