前情提要 在 上一篇 Managed Agents API 全解析 裡，我做了一隻開源的 LINE 研究規劃師 Bot：kkdai/line-research-bot。 它的玩法很簡單： 在 LINE 傳「研究 SOTA 開源向量資料庫的選型」，Bot 會依序跑 PLAN → SEARCH_COMPARE → WRITE_REPORT 三個階段：先設計 4～8 組搜尋關鍵字，再用 Google Search + URL Context 讀真實網頁並交叉比對出「共識 / 分歧 / 缺口」，最後寫成一份有 footnote 引用的繁體中文 Markdown 報告。 報告由 Cloud Run 渲染成 HTML 丟上 Cloud Storage，LINE 收到一張附摘要、主要來源與「閱讀完整報告」按鈕的 Flex 卡片。 之後再傳「第 2 章再深一點，加日文來源」，Bot 會在同一份報告上深化、版本號 +1，舊版自動存成 snapshot。 第一版是 Python 3.11 + FastAPI + google-genai（enterprise=True） 打 Pre-GA 的 Managed Agents API，靠的是官方沙箱的 持久化 filesystem：/workspace/plan.json、/workspace/sources.json、/workspace/report.md 在同一個 environment_id 底下跨回合存活，深化時 Agent 自己去讀檔。 它很好玩，但跑了一陣子之後，有幾件事一直讓我不太放心： Pre-GA，沒有 SLA：base_agent: antigravity-preview-05-2026 這種名字一看就知道哪天會變。 沙箱裡的 gsutil 是 mock 的（上一篇的踩坑二），結果 Agent 寫完報告還是得把整份 Markdown 塞回 JSON 給 Cloud Run 上傳。沙箱 filesystem 的價值其實只剩「跨回合記住三個檔案」。 一定要 background=True + 自己寫 polling 迴圈，Stage 2/3 一慢就要調 timeout（我曾經從 240 秒一路調到 600 秒）。 於是這次我決定：把整個服務改寫成 Go，所有跟 Agent 有關的事情改用 Google 官方的 ADK for Go（google.golang.org/adk v1.9.0）來做，並且部署回原本的 Cloud Run 服務、沿用一模一樣的環境變數。 整個過程我都記錄在原 repo 的 Issue #1。 改寫完成後，我把 Go 版獨立成一個新的 repo，讓上一篇文章引用的 Python 版維持原樣，兩個版本可以直接對照： Repo 內容 kkdai/line-research-bot 原本的 Python 3.11 + FastAPI + Managed Agents 版（上一篇文章的範例），以及這次遷移的 Issue #1 紀錄...

前情提要 我有一個自己每天重度使用的主力 LINE Bot：kkdai/linebot-helper-python。 最初它只是一個「丟網址進去、回傳繁體中文摘要」的小工具，但過去一年半裡，我陸續往裡面塞進了各式各樣的 Gemini 新能力： 多來源內容載入與文件轉檔：網頁三層爬蟲 Fallback Chain（HTTP $\rightarrow$ Firecrawl $\rightarrow$ SingleFile Headless Chromium）、YouTube 影片摘要、PDF / Word / PPT / Excel / EPUB 自動轉 Markdown，以及一鍵產出 FB / LinkedIn / Threads 社群爆款文案 Carousel。 書籤與 Grounding 深度研究報告：/save、/list、/search 書籤管理，點擊卡片上的「📄 詳細研究報告」就會結合 Google Search Grounding 寫出一份完整 Markdown 報告，渲染成獨立 HTML 網頁（/reports/{id}）並永久保存在 Cloud Firestore。 Google Maps Grounding 與 Gemini Batch API 美食大數據分析：傳送 LINE 位置座標搜尋附近加油站、停車場與餐廳，還能針對特定餐廳抓出 50+ 則最新評論，丟進 Gemini Batch API（享 50% 成本折扣）跑深度招牌菜與雷點分析，透過 Webhook 或背景輪詢推播回 LINE。 Agentic Vision 視覺標註：上傳圖片後讓 gemini-3-flash-preview 寫 Python Code 畫出標註框（Bounding Box），轉存成圖片推回聊天室。 LINE 語音訊息 TTS 與 LIFF 即時雙向語音助手：語音訊息自動轉錄並搭配 gemini-3.1-flash-tts-preview + ffmpeg 產生 M4A 語音朗讀；打開 LIFF 還能透過 WebSocket 雙向串流 gemini-3.1-flash-live-preview，支援免持 VAD、Barge-in 打斷與 Live Tool Calling。 功能很爽，但代價也很明顯：Python + FastAPI + 一大票文件解析與 AI 套件的常駐記憶體越來越高，為了讓背景任務與多併發不卡頓，這台 Cloud Run 服務不知不覺已經開到了 4 vCPU / 4 GiB Memory（且開啟 --no-cpu-throttling）。 身為一個長期寫 Go 的人，看著一台個人日常助理吃掉 4 vCPU / 4 GiB 實在有點忍不下去了。於是決定動手做一件事：把整套 linebot-helper-python 100% 改寫成 Go 1.26 最新版（kkdai/linebot-helper-go），直接部署到同一個 GCP 專案的 Cloud Run 上，並且做到與舊版共享 Firestore 資料、隨時可零停機切換。 一、改寫前先立規矩：用 GitHub Issues 拆解 11 個里程碑 把一個將近 90KB main.py 外加十幾個模組的 Python...

前言：從「手動調 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...