前情提要 這陣子陸續把幾個日常主力服務從 Python 改寫成 Go，這回輪到我平常整理名片的 LINE 機器人：kkdai/linebot-namecard-python。 這隻機器人過去已經演進了好幾輪：從最初的 Gemini Vision 辨識 + vCard QR Code 匯入通訊錄、搬上 Vertex AI 擺脫配額限制、導入 Python 版 ADK 動態閉包 Tools，一路加上 Structured Output 與消歧義清單 和 正反雙面名片合併辨識。 但這次重構成 Go 版（kkdai/linebot-namecard-go），我想挑戰一個不太一樣的工作流：先把架構改寫與單元測試丟給 Google Antigravity 的 Remote Agent 在雲端自動跑完，等我回到電腦前，再由本機的 agy CLI 接手部署到 Cloud Run 並切換 LINE Webhook。 實際跑過一輪之後，成果很驚豔——Remote Agent 在雲端 17 分鐘就把整套 Go 1.27 + google.golang.org/adk + Firestore 架構與測試寫完推上 GitHub；但同時也實地驗證了一個非常關鍵的邊界限制：你可以用 agy 呼叫 Remote Agent，卻「無法」把同一個 Remote Agent 對話切換成本地 Agent 繼續。 這篇文章上半部先把 Antigravity Remote Agents 的用法、雲地隔離原因與兩種實務解法一次講清楚；下半部再完整拆解這次 linebot-namecard-python → linebot-namecard-go 的系統架構升級與實際交接部署踩坑紀錄。 一、認識 Antigravity Remote Agents：把重活交給雲端隔離 VM 依據 Google Antigravity 官方文件（Remote Agents），Remote Agents 的核心概念是把自主開發任務從你本機的筆電，搬到 Google 代管的雲端隔離虛擬機（Cloud Sandbox VM） 裡執行。 這對長時間重構、大範圍測試或跨語言改寫非常有用： 非同步離線執行：任務在雲端 VM 跑，就算你闔上筆電、電腦休眠或斷網，Agent 依然會繼續寫扣、跑測試與改檔案。 跨裝置監看與解鎖：你可以在桌機或 CLI 派工後出門，中途用手機瀏覽器打開 antigravity.google.com 看進度、批准權限或補充指令，最後直接拿到一個完整的 GitHub Commit / PR。 雲端資源掛載（Remote Resources）：因為 Agent 跑在雲端隔離沙盒，存取檔案透過三種方式掛載： GitHub Repositories：透過 OAuth 授權後自動 clone 並掛載進遠端專案環境。 Google Drive：可直接在對話中讀取 Google Docs、Sheets、Slides、PDF 與資料夾。 上傳本地檔案：直接把檔案傳到遠端專案（單檔上限 8 MiB、每個專案最多 50 檔 / 100 MiB、帳號總上限 2 GiB），檔案會持久掛載在 /home/antigravity/upload。 1. 可以用 agy CLI 呼叫 Remote Agent 嗎？ 可以。 依據 Remote Agents 官方文件，使用前須符合兩個條件： CLI 版本：agy CLI...

flowchart LR subgraph BEFORE["Before：Go + ADK for Go（一個 container）"] direction TB B_HOOK["LINE Webhook / Cloud Tasks"] --> B_WK["worker（Go）"] B_WK -->|"runner.Run()<br/>同一個行程"| B_ADK["ADK llmagent × 3<br/>OutputSchema<br/>Session State"] B_ADK -->|"GoogleSearch + url_context"| B_GM["Vertex AI<br/>Gemini"] end subgraph AFTER["After：TypeScript + DeepSeek Harness（app + sidecar）"] direction TB A_HOOK["LINE Webhook / Cloud Tasks"] --> A_WK["worker（TypeScript）"] A_WK -->|"dsh-sdk-client<br/>stdio JSON-RPC"| A_DSH["dsh runtime 子程序<br/>sdk-minimal + patch<br/>submit_* / web_research 工具"] A_DSH -->|"Anthropic /v1/messages"| A_LL["LiteLLM sidecar"] A_LL --> A_GM["Vertex AI<br/>Gemini"] A_DSH -->|"web_research：<br/>googleSearch + urlContext"| A_GM end BEFORE ==>|"只換 Agent 層<br/>LINE / Firestore / GCS / Cloud Tasks 不變"| AFTER   Before（ADK for Go） After（DeepSeek Harness） Agent 跑在哪 同一個 Go 行程 每個 stage 一個 dsh 子程序 怎麼接 Gemini 直連 Vertex AI DSH（Messages 協定）→ LiteLLM sidecar → Vertex AI 結構化輸出 OutputSchema submit_* 工具 + 讀 session 事件 Google Search ADK 內建 geminitool 自寫 web_research 工具 Cloud Run 1 個 container 2 個 container（app + LiteLLM），一樣可以縮到 0 前情提要 在 前前篇 裡，我把 LINE 研究規劃師 Bot 從...

flowchart LR subgraph H2["Google Research Harness²：改「裝備的內容」"] direction TB OPT["雙層遞迴優化器（Python）<br/>Propose → Probe → Compose<br/>Experience Reflector"] TREE["c1..c8 裝備檔案樹<br/>systemprompt / guardrails /<br/>LongTermMEMORY / skills…"] OPT -->|"產生下一代 H^(k)"| TREE end subgraph DSH["DeepSeek Harness：負責「把 Agent 組起來跑」"] direction TB PROF["Profile = bundle + YAML patch"] RT["dsh runtime<br/>agent loop / ctx.tools / ctx.llm /<br/>session 事件"] PROF -->|"Cordis 組裝外掛"| RT end TREE -.->|"裝備被某個執行環境載入"| RT RT -.->|"執行軌跡 / 分數"| OPT   DeepSeek Harness（DSH） Google Research Harness² 一句話 Agent 的執行環境 Agent 裝備的自動優化器 「Harness」指的是 跑 Agent 的那套 runtime 包在模型外面的提示詞、護欄、記憶、技能 你會改的東西 Profile、YAML patch、外掛 c1..c8 檔案樹（但通常是 Harness² 自己改） 這個系列裡用在哪 LINE 研究 Bot 的 Agent 層 LINE AI 名片王的自我演化 前言：兩個 Harness，一週內碰到兩次 前幾天的 Harness² 三部曲（上、中、下），我把 Google Research 的 google-research/harness2 接上 LINE AI 名片王，讓它讀 OpenTelemetry 軌跡、自己長出技能檔，準確率從 62.5% 一路爬到 100.0%。 這週又剛好碰到 DeepSeek 開源的 deepseek-ai/dsh-superagent-prototype，它建在 DeepSeek Harness（DSH） 上。我把 LINE 研究 Bot 的 Agent 層從 ADK for Go 換成了 DSH，做成 kkdai/line-research-bot-dsh，目前已經在線上跑了。 兩個都叫 Harness，我一開始也以為是同一類東西。實際用過之後才發現： DSH 是「馬具怎麼組裝、怎麼套在馬身上跑」；Harness² 是「自動調整馬具上的每一條皮帶」。 兩個在不同層，甚至可以接在一起用。 因為內容太多，這次拆成兩篇： 本篇：DSH 框架到底是什麼（附框架圖），以及它跟 Google Harness² 的逐項比較。 下一篇：實際怎麼把 LINE 研究 Bot 從 ADK...

前情提要 在 上一篇 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...