Cloud Agent vs Localhost Agent
Cloud Agent vs Localhost Agent 是 coding agent 部署與協作模式的選型問題。AIHAO 這篇文章回顧「localhost 已死」論述後指出，雲端 agent 的強項是組織級委派與標準化環境，但開發者仍常把 agent 留在本機，原因是 repo、祕密金鑰、內部服務、除錯工具與個人工作流很難完整交給外部平台。
差異
| 面向 | Cloud agent | Localhost agent |
|---|---|---|
| 主要模式 | 委派：PM、設計、support 可從 Slack / Jira / issue 觸發任務 | 配對：開發者在自己的 repo、shell、IDE 與瀏覽器旁邊引導 agent |
| 環境 | 雲端標準化、可平行、容易接 CI/CD | 貼近真實開發環境、內部服務與個人工具鏈 |
| 風險 | 權限、資料外流、環境漂移、平台鎖定 | 本機資源限制、難以多人共享、背景任務規模有限 |
| 適合任務 | 已標準化、可用測試驗收、低上下文私密性的任務 | 需要即時理解系統、調試、祕密狀態或高度互動的任務 |
判斷規則
這篇文章的重點不是宣判 cloud 或 localhost 誰勝出，而是把 agent-framework-selection 往部署環境延伸：任務如果能被清楚規格化、測試化、權限切小，cloud agent 才容易成為真正的 delegation layer；如果任務依賴開發者腦中 context、本機祕密、臨時除錯與高頻互動，localhost agent 仍是較低摩擦的起點。
對 harness-engineering-for-ai-coding 來說，環境選擇會改變 sensors 和 gates。Cloud agent 需要更嚴格的 sandbox、secret policy、PR review 與 audit trail；localhost agent 則需要限制破壞性操作、保留可重播紀錄，並用 ai-code-validation-bottleneck 的驗證流程避免本機快速產碼變成 review debt。
近期例子
BusinessNext 2026-07-08 的 Claude Cowork 更新把 cloud agent 往「持續 session」推了一步：網頁與手機可以啟動、監控並續接同一個遠端 session，背景排程把長任務從單一裝置解耦；但本機檔案讀寫、瀏覽器操作與 Computer use 仍留在 Claude Desktop App。這表示 cloud delegation 的採用門檻正在下降，但 agent-sandbox-architecture 與 agent-experience 提醒的高權限、本機資料與工具邊界，仍需要 model-harness-fit 來鎖住。
BusinessNext 2026-07-30 的 Claude Cowork 五種場景更清楚地展示 localhost agent 的價值：一般使用者可以在 GUI 中授權特定資料夾，讓 agent 直接整理檔案、讀取 PDF、清洗 CSV、產出簡報或處理收據，而不必反覆上傳與下載。這不是 cloud agent 已經被淘汰，而是任務若依賴本機資料、檔案成果與高頻人工核准，localhost 仍有較低的 context transfer 成本；web／mobile beta 比較適合啟動、查看或接續狀態，完整本機操作仍以桌面環境為主。
BusinessNext 2026-08-14 對 ChatGPT Work 的整理把這條邊界延伸到一般職場 agent：cloud 模式在 OpenAI 雲端電腦執行，可跨手機、網頁與桌面接續，筆電關機仍能跑，但碰不到本機檔案與桌面軟體；local 模式則在桌面 app 執行，可讀寫本機檔案、操作桌面軟體與瀏覽器，代價是電腦關機任務就停止。兩邊都能排程，但 cloud 不依賴本機開機，local 需要桌面 app、電腦與原專案持續可用；技能也分成 Codex 本機資料夾的 standalone skills，以及包在 plugin 中、可跨網頁／桌面／行動 Chat 與 Work 使用的 skills。
這個案例也把「多 agent 工作空間」校正成多個 Work 視窗並行，而不是官方多 agent 協作；因此選型時應先看任務需要哪種 context locality、background continuity、artifact delivery 與權限範圍，再決定 cloud delegation 或 localhost pairing。Gmail／Notion 查詢、草稿與低風險回信可先作 cloud 試跑；涉及本機密碼、桌面軟體、standalone skill 或不可逆外部行動，則應接上 agent-sandbox-architecture、agent-skills 與人工核准 gate，並以 agent-experience 驗收狀態、產物與接手點。
BusinessNext 2026-08-17 的同 ID 修訂版補上 14 項功能的明確清單、使用限制與 FAQ，並把採用順序收斂成「先做低風險、可驗收任務，再逐步擴大工具與權限」。這讓 cloud／local 比較不只是在比連續性，也要檢查 artifact 是否可驗收、Skills 的封裝範圍、瀏覽器與登入狀態，以及人工 review gate；產品功能與作者實測仍是來源 attribution。
Portable Computer：local-first agent 的資料出口 gate
BusinessNext 2026-08-26 報導 Perplexity Portable Computer 把 Perplexity Computer 的 orchestrator LLM、subagent LLM、agent harness、工具與 sandbox 打包成可安裝在使用者硬體上的軟體；第一波支援 NVIDIA DGX Spark，後續才規劃至少 24GB VRAM 的 RTX PC。這是 cloud agent／localhost agent 比較中的另一種形狀：不是把任務委派給遠端工作環境，而是先把整個 runtime 放在本機，再按任務需要升級到雲端。
它的可重用判準不是「local 就永不上雲」，而是 context locality → egress inspection → per-step consent → sandbox boundary：本地任務的協調、工具呼叫、排程與搜尋索引先在裝置端執行；需要即時資訊、瀏覽器或雲端模型時，先用 PII classifier 列出會離開本機的內容，再逐步要求同意。若作業系統層級 sandbox 無法啟用，工具直接停用而不是降級到未保護執行；這把 agent-ready-data-governance、agent-sandbox-architecture、model-harness-fit 與 edge-ai-harness 接到同一個 local-first adoption gate。產品功能與 Perplexity 的評測數字仍屬來源 attribution，不是獨立隱私或效能 benchmark。
Browser runtime：local、cloud 與既有 Chrome
BusinessNext 2026-08-27 把瀏覽器再拆成三條執行路徑：桌面 App 的內建瀏覽器跑在本機，使用獨立 profile；雲端瀏覽器跑在 OpenAI 伺服器，以獨立登入流程承接背景任務；Chrome extension 則跑在既有 Chrome，沿用目前的 profile 與分頁。這不是單純的功能清單，而是 context locality、登入資料、background continuity 與人工接手 的選型差異。
若任務需要人邊看邊改、現有分頁或本機環境，localhost browser 的摩擦較低，但電腦關閉會中斷；若任務要在使用者不在場時完成，cloud browser 的連續性較好，但不能假設它看得到本機分頁、密碼或檔案。Chrome extension 適合非得接上既有瀏覽器環境的工作，代價是現有登入狀態與分頁成為新的權限邊界。選型仍應接上 agent-experience、agent-sandbox-architecture 與 agent-ready-data-governance，先從低風險、可驗收任務開始，再擴大登入與外部 action 權限。
Claude Cowork Scheduled Tasks：遠端連續性與本機資料二選一
Anthropic Help Center 說明，Claude Cowork Scheduled tasks 可按週期或按需建立，每次是獨立 session，並可使用 connectors、skills 與 installed plugins；遠端任務即使電腦睡眠或 Desktop 關閉仍可執行。這是 cloud delegation 的連續性優勢，但不能解讀成 cloud agent 自動取得本機檔案。
官方文件同時指出，一般排程使用 Claude 帳號檔案與 connectors，不能綁定電腦資料夾；手動設定若需要本機檔案或應用程式，就只在本機執行。選型因此應先問 context locality → runtime → background continuity → result review：要遠端常駐就整理可授權的帳號／connector context，要處理 localhost 資料就接受本機開機與 app 狀態限制，兩者都不能省略權限與人工驗收。
Claude Cowork browser runtime：獨立瀏覽器不等於 cloud browser
Anthropic 的 Claude Cowork 內建瀏覽器把網站操作放進 desktop app 側邊欄，使用與個人瀏覽器分離的 browser identity；它適合把不依賴目前分頁的網站任務交給 Cowork，Claude in Chrome 則適合操作使用者已開啟、已登入的頁面。這補上 cloud／localhost 比較中的第三條路徑：本機執行的獨立 browser，它隔離原有分頁與密碼，但仍受桌面 app 與本機連線狀態約束。
web／手機端只有在桌面 app 開啟且連線時才能遠端驅動這個瀏覽器；若桌面 app 未啟動，web 端不能把它當成獨立 cloud browser 使用。選型要再加上 browser identity → runtime availability → login scope → untrusted page → outbound action：低摩擦不應掩蓋逐站登入、敏感網站預設排除、prompt injection 與人工核准邊界。這些產品能力與 rollout 仍是 Anthropic／BusinessNext attribution，不代表 browser agent 已證明可靠或安全。
ChatGPT Work cloud browser：登入後的遠端連續性
ChatGPT Work 的 cloud browser 把 cloud agent 的邊界推進到 authenticated websites：任務在遠端電腦執行，使用者以安全登入表單完成帳密與雙重驗證，登入後 session 不依賴本機瀏覽器，且可在離開對話或關閉裝置後繼續。這比 localhost browser 更適合背景委派，但網站覆蓋、登入流程與自動化阻擋仍由網站與當期產品支援決定。
選型不能只看背景連續性：要同時檢查 session／credential scope → site access permission → untrusted page → consequential action confirmation → human takeover → result review。安全登入不代表 agent 看不到敏感網站內容，也不代表付款、預約或法律／帳戶承諾可自動放行；OpenAI Help Center 的產品聲明與 BusinessNext 的 19 項範例不等於獨立成功率或安全 benchmark。
OpenClaw Cloud Session：遠端執行與 Gateway-owned context
OpenClaw 2.0 提供一個不同於「把整個任務交給雲端平台」的形狀：Cloud Session 仍是同一個 session，Gateway 持有對話、transcript、provider credentials、placement records 與最後同步的 workspace，遠端機器只執行命令、檔案編輯與工具工作。這讓 background continuity 與 context ownership 保留在控制面，但不代表遠端工作天然具備 tenant isolation 或完整可用性。
因此比較 cloud／localhost 時要再加上 context owner → execution host → credential locality → workspace reconciliation → trust boundary。本機 agent 的優勢仍是貼近 repo、桌面與臨時除錯；Cloud Session 的優勢是可把工作移到 paired device／cloud worker 並保留 session continuity。若多人共享同一 Gateway，官方把它視為 trusted-team collaboration；互不信任的租戶仍需分開 Gateway／OS user／host，而不能只依賴 session role 或 sidebar filter。
對 AI Ark 的用法
AI Ark watch / ingest loop 暫時不需要升級成 cloud-agent 平台。單一 repo、少量來源、明確 raw / page / index / log gate 用本機 Hermes 執行就夠；只有當多位成員同時委派、queue 長期堆積、或需要在隔離環境平行跑驗證時，才考慮 cloud delegation。