Gemini Spark 很強，但你的 agent log 在哪？
Google I/O 發完 Gemini Spark，討論大多集中在「這是不是 OpenAI Operator 的對手」「有沒有超過 Claude」之類的。
我比較在意的問題是：它的 log 在哪？
說穿了，Gemini Spark 的架構就是 Google 幫你跑一台 24/7 的 Cloud VM，接上 Workspace + MCP，然後設了些高風險操作的二次確認機制。對一般使用者很方便。對我這種在公司跑基礎建設的人來說，第一反應是：這台 VM 我看得到 metrics 嗎？出錯了能重放那個操作嗎？
這不是在酸 Google，是兩種產品定位開始變得很清晰。
可控性的差距
我目前在公司的 Kubernetes cluster 裡跑了幾個 agent job，都是用 OpenClaw 接著內部工具。最大的運維收穫是：agent 的行為必須是 deterministic 或者 auditable，不能兩者都不是。
舉個具體的例子。我們有一個自動化的 infra review agent，每次 PR 進來會掃 Terraform 差異然後給建議。剛開始跑的時候它偶爾會給出矛盾的結果——同一個 resource 上週說要加 prevent_destroy，這週說不用。
查了半天，問題出在 context window 截斷，加上 system prompt 版本沒有 pin。
# agent job spec（簡化版）
env:
AGENT_MODEL: "claude-sonnet-4-5"
AGENT_PROMPT_HASH: "sha256:a1b2c3..." # pin prompt version
MAX_CONTEXT_TOKENS: "8192"
那個 AGENT_PROMPT_HASH 是後來加的。沒有它之前，我完全無法重現某次給出奇怪建議的原因。這種問題在 local agent 你至少有能力修，在雲端 agent 你能調的旋鈕就少得多了。
Gemini Spark 給你多少這種程度的控制？目前看起來不多。The Verge 的報導說高風險操作有二次確認，但那是 Google 定義的「高風險」，不是你定義的。
可營運性更難解
可控性還只是第一層。可營運性是：出問題了你能多快恢復，以及你的成本透明嗎？
雲端 agent 服務最難說清楚的就是成本。Google Cloud VM 費用加上 Gemini API 推論費用，24/7 跑下來要多少？根本沒有標價。AI Ultra 月費 $249.99，但那是打包定價，你不清楚 Spark 佔了多少比例。
反過來看自己跑的 agent，成本是可以精確算的。我公司現在用 Bedrock 跑推論，每個 agent run 都有 requestId 可以回溯：
aws bedrock-runtime get-invocation \
--invocation-id <requestId> \
--query 'inputTokenCount,outputTokenCount'
這個數字會進我們的 cost dashboard，每週報告給工程 lead。這種透明度在 SaaS agent 裡基本上拿不到。
分化點在哪裡
我觀察到一個趨勢：雲端 agent 產品（Gemini Spark、Operator 那個方向）在往「更無縫、更自動」走，local-first 的工具在往「更可稽核、更可控」走。
這不是優劣問題，是使用場景的分化：
- 個人生產力 → 雲端 agent 贏，你不在意 log，你在意有沒有幫你做到事
- 企業 infra / 自動化流水線 → local agent 贏，你需要 audit trail、cost attribution、rollback 機制
Gemini Spark 是在搶「個人助理」的市場。OpenClaw 這類工具要想清楚：是要跟 Google 打「更聰明的助理」，還是要把「可營運性」做成護城河？
我個人看法是後者更有機會。Google 能把模型做得比你好，但它沒辦法知道你公司的 internal SLA 是什麼、你的 incident runbook 長什麼樣子、你的 on-call rotation 是誰。那些跟自己 infra 深度整合的部分，只有 self-hosted 才能做到。
一個還沒解決的坑
最後講一個我還沒想清楚的問題。
長時間運行的 agent（24/7 那種）有個 context drift 的問題：跑了幾個小時之後，早期的 context 開始被壓縮或遺忘，
行為慢慢飄移。Gemini Spark 怎麼處理這個我不知道，Google 起碼有足夠工程資源去做 session state management。
自己跑的話，這個問題目前沒有標準解法。我試過幾種 workaround——定期 checkpoint + summarize、用 external memory 存 key state——但都不完美。有人在 production 跑過長時間 agent 有比較成熟的做法，想聽聽。
作者：CtrlC