我目前工作的機器是 16 GB 記憶體的 M4 MacBook Air。系統裝了 Ollama client，但檢查時沒有執行中的 Ollama instance，也沒有可引用的本機模型清單。這次撰寫與實作使用雲端模型，repository、CLI、瀏覽器控制與部分工具則在我的 Mac 上執行；匿名化的歷史聚合資料沒有記錄每個 turn 的模型位置。
所以我不會把這套環境叫作「全離線 AI」。它比較準確的描述是：模型可以在遠端，但哪些檔案送進 context、哪些指令能執行、變更如何驗證，仍由本機的工作區與操作規則控制。
這篇用一份匿名化快照檢查這個說法。資料涵蓋 1,447 個 threads、3,615 個 turns，時間約從 2026 年 8 月 7 日到 9 月 4 日。統計只讀取狀態、item type 與聚合後的工具名稱，沒有擷取對話、檔案路徑、工具參數或結果。
3,489 個 completed，不能寫成 96.5% 成功率
快照中的 turn 狀態如下：
| 狀態 | Turns | 這個數字能說明什麼 |
|---|---|---|
completed | 3,489 | 執行流程正常結束 |
interrupted | 106 | 執行被中止 |
failed | 14 | runtime 記錄為失敗 |
inProgress | 6 | 快照當下仍在執行 |
completed 是 process state，不是 product state。Agent 回完訊息、指令離開 process，或 subagent 結束工作，都可能被記成 completed；這不表示需求符合、測試通過、畫面正確，更不表示已部署。因此我沒有把 3,489 除以 3,615 寫成「任務成功率」。
同一份資料的 item type 更能看出本機 harness 實際承擔的工作：
| Item type | 數量 | 代表的執行面 |
|---|---|---|
commandExecution | 32,856 | shell、檢查與本機程式 |
mcpToolCall | 3,269 | 連接外部或本機服務的工具呼叫 |
subAgentActivity | 3,196 | 子任務生命週期活動 |
collabAgentToolCall | 2,752 | Agent 協作操作 |
webSearch | 868 | 外部資料查找 |
這五列也不能相加成任務量。一次 turn 可能執行多個 command、呼叫 MCP，再派出 subagent；同一工作會同時落進幾個維度。它們能支持的結論很有限：這套 Agent 不是單純的聊天介面，而是一個會協調本機工具與外部資料來源的執行層。
完整 SQL、匿名化規則與限制記在 repository 的研究紀錄；正文只保留會影響判斷的數字。
我用四道邊界定義「本機」
把本機直接等同於模型權重放在哪裡，會漏掉大多數工程風險。我現在把問題拆成四道邊界：
| 邊界 | 我會問的問題 | 能留下的證據 |
|---|---|---|
| 資料選取 | 哪些檔案、片段與 metadata 會進入模型 context？ | 讀取範圍、去識別規則、來源清單 |
| 工具執行 | 指令、MCP、瀏覽器與外部 API 在哪裡執行？ | tool log、工作目錄、網路路徑 |
| 權限 | Agent 技術上能做什麼，哪些動作要詢問人？ | sandbox、approval policy、帳號權限 |
| 驗收 | 誰判定變更可以合併或發布？ | diff、測試、畫面、CI 與部署結果 |
這四列刻意沒有「模型品牌」。同一個模型換到不同 sandbox、工作目錄或 service account，風險就會變；同一台 Mac 改用本機模型，也不會自動讓 MCP、瀏覽器或 production database 變成本機資源。
OpenAI 的 Codex 安全文件也把 sandbox 與 approval policy 分開：sandbox 限制 Agent 技術上能做的事，approval policy 決定何時要詢問使用者。文件另外說明 command network proxy 不涵蓋 web search、apps/connectors、MCP、browser/computer use 與 cloud tasks。替 shell 設好 allowlist，沒有順便封住其他資料路徑。
這次任務怎麼走過四道邊界
這篇文章本身就是一個可檢查的案例。需求除了寫文案，還包含替 GitHub 連結加入 SVG icon，以及新增文章分享功能。
先讀 repository，再決定要改哪裡
工作開始時，working tree 是乾淨的，main 與 origin/main 都在 ad6dd85。我先讀 repository 的 AGENTS.md、內容規格、架構文件與 ADR，再搜尋既有 GitHub、RSS、外部連結與 icon 寫法。
這一步找出一個很省事的事實：首頁、About 與 Footer 已經有 inline SVG 的 GitHub 與 RSS icon。缺口只有文章 footer 的 repository 連結，以及專案卡片 dialog 裡的 GitHub 連結。若沒有先做 inventory，很容易新增一套 icon helper 或安裝套件，最後只是替兩個既有連結包更多結構。
分享功能也不需要後端。X、LinkedIn、Facebook 都能用帶參數的連結開啟分享頁；只有「複製連結」需要少量 Clipboard API。這讓功能保持純靜態，也沒有把 Astro 頁面變成 hydrated component。
一次失敗讀取，比錯改檔案便宜
我一開始按常見 Astro 專案結構尋找 src/styles/tokens.css，讀取直接失敗。實際的 token source 在 repository 根目錄 tokens.css。
這是很小的失誤，但剛好說明本機 Agent 的價值不在「永遠猜對」。工具回傳的檔案系統事實能在改動前推翻假設。若提示詞只要求 Agent 自信地完成，而沒有要求先讀檔、查 caller 與檢查 git status，錯誤路徑很可能被包成另一套重複 CSS。
同樣地，設定檔寫著什麼也不等於某次 session 實際拿到什麼權限。可引用的結論必須來自當次 sandbox、approval 與工具結果；查不到就標成未知。
把驗收留在模型之外
這次的接受條件不是「文章寫完」四個字。內容要通過 policy、Astro check、測試與 production build；分享按鈕要在桌面與 320 px、淺色與深色都能讀；複製連結需要成功與失敗訊息；最後還要確認 GitHub Actions 和正式網址。
這些 gate 的共同點是輸出可由另一個系統重跑。模型可以建議測試，也可以解讀失敗，卻不該自行把「我看起來完成了」升級成「產品已驗收」。這和本站先前整理的多 Agent 工作台相同：process 停止，只能進入 review queue。
哪些東西值得留在本機
我的判準現在很務實。以下工作通常留在本機 harness：
- repository 與未提交 diff，因為範圍、歷史與回復方式都清楚；
- secrets 的注入與權限判斷，模型只取得完成當下任務所需的能力；
- 指令執行、測試與瀏覽器驗收，讓結果能對應同一份 working tree；
- 最後的 commit、push、部署與人工接管點，避免把高影響操作藏進長鏈自動化。
可以送往遠端模型的內容則應先做選取。提示詞裡寫「不要洩漏機密」不夠；檔案範圍、工具參數與 connector 權限，應該在模型呼叫前就縮小。
若需求確實要求模型也在本機執行，才進入另一組問題：checkpoint、量化、常駐記憶體、context 與 runtime 穩定性。本站的本機 Qwen 部署文章處理的是那條路；本文這台 16 GB Mac 與未啟動的 Ollama，沒有提供本機推論的證據。
我目前會保留的最小流程
如果現在重做一次，我會先保留這五件事，不先架新的 Agent 平台：
- 我會先寫清楚 Agent 可以讀取與修改的目錄，排除 secrets、私密資料與產出目錄。
- shell、MCP、browser、web search 會分開列，逐一確認網路與帳號邊界。
- sandbox 管技術能力，approval policy 保留高影響動作。
- 每個任務至少要留下 diff、測試或畫面證據；只有文字版完成宣告不算驗收。
- 聚合紀錄只回答它能回答的問題。Turn status 不冒充成功率，tool items 不冒充任務數。
如果工作量開始需要多台機器、隔離 checkout 與持久 session，再延伸到多 Agent 控制平面；如果重點是個人知識與開發任務如何互相餵資料，可參考Claude 與 Obsidian 的迴圈。
對我而言，「本機 AI Agent」留下的是一組能被指出位置、重跑與撤回的邊界。模型在哪裡推論仍然重要，但它只是整條執行路徑中的一格。