Codex Micro 讓控制面板變安全

以前我把 agent 當成一個會寫程式的工具；現在我把它當成一個要被分層管住的流程。

我用 agentic coding 工具一陣子了，越用越煩。模型會寫、會改、會講得頭頭是道，但一碰到「幫我跑一下」這種事，我就開始不安。問題從來不是它會不會寫，而是它要在哪裡寫、在哪裡跑、誰能按下那個執行鍵。它一旦跟我的真工作環境混在一起，我不是盯太緊，就是放太鬆，兩邊都很累。

這次把我拉回來的是 The New Stack 這篇 OpenAI Codex Micro macropad，裡面提到 OpenAI 的第一個小裝置，售價 $230。我不是在看一個桌面玩具，我是在看一個很誠實的訊號：agent 工作流開始需要物理邊界了。這件事聽起來很小，實際上很要命，因為它直接碰到我最在意的東西：誰在控制執行權。

原始來源是 The New Stack 的文章，作者頁可看 The New Stack staff，文章本體在 thenewstack.io/openai-codex-micro-macropad。我下面拆的是它背後的工作法，不是照抄產品介紹。

我先不看硬體，我先看它逼你承認的事

OpenAI’s first gadget is the $230 Codex Micro macropad.

翻譯一下就是：真正值得注意的不是這塊小板子長什麼樣，而是它逼你把 agent 工作流從「腦內流程」變成「可按、可停、可切換的流程」。很多人做 agent 工具，最後都卡在同一個地方：所有動作都藏在 prompt、側欄、終端機和快捷鍵裡，像一坨沒人整理的線。看起來很強，實際上很容易出事。

我以前也幹過這種事。把「生成」、「測試」、「提交」、「切 sandbox」全部塞進一套快捷鍵，結果每次切環境都像在猜自己現在是哪個模式。工具沒壞，是我把控制面板做得太隱形。Codex Micro 這個想法厲害的地方，不是它多神，而是它把「控制」這件事拉到桌面上，讓你不能再假裝自己很清楚。

實操上，我現在會先列出五個最常用的 agent 動作，再看哪些值得放到實體按鍵上。不要一開始就想做全套，太貪會死。先做最常見、最容易出錯、最需要停下來確認的那幾個。

• 生成草稿
• 跑本地驗證
• 切到 sandbox
• 送人類審核
• 緊急停止

按鍵不是重點，讓流程變得可見才是。你看得到狀態，才有機會管住它。

按鍵有用，是因為它逼你把信任拆開

我對 agent 最不爽的一點，就是它常常把「會做」和「能做」混在一起。模型會產生答案，不代表它有資格直接碰你的機器。很多 demo 都喜歡把這件事包裝得很順，結果大家看完只記得「哇，好快」，忘了問「它到底碰了哪些東西」。

這就是實體控制有價值的地方。按一下鍵，比在 prompt 裡打一句「請幫我執行」更像一次承諾。那個微小的摩擦很討厭，但它是好事。因為你會開始把不同風險分開：哪個鍵只是產生建議，哪個鍵只是預覽，哪個鍵才真的允許執行。

我之前試過一套本地 agent 流程，搭 OpenAI Codex 類型的工作方式，再配幾個 terminal shortcut。功能上沒問題，心理上很糟。因為我根本分不清現在是在安全模式還是危險模式。那種「應該沒事吧」的感覺最可怕，因為它通常就是出事前最後一句話。

實操寫法很簡單：把生成和執行拆成兩個明確動作，別讓同一個鍵同時做兩件事。少一點炫技，多一點笨規矩，通常比較活得久。

• 綠鍵：生成或摘要
• 黃鍵：預覽或暫存
• 紅鍵：只允許 sandbox 執行
• 長按：取消、撤權、清掉狀態

這不是漂亮設計，這是把風險講人話。

WebAssembly 會被提到，因為它補的是執行邊界

這篇內容也把 WebAssembly 拉進來，我覺得這很合理。因為 agent 真正危險的地方，不是它會寫 code，而是它會寫完就跑，還跑在你沒收好的地方。WebAssembly 的吸引力在於，它比「直接在 host 上跑」更容易收斂執行範圍，至少邊界清楚很多。

翻譯一下就是：控制面板負責表達意圖，執行層負責關住手腳。這兩層分開，才有機會做出像樣的 agent 流程。很多團隊喜歡把 Docker 當護身符，覺得有容器就安全了。我看過太多這種自我安慰：掛太多 volume、網路權限太大、把 host 檔案系統一起送進去，最後只是把風險包裝得比較整齊。

WebAssembly 不是萬靈丹，但它會逼你想清楚「這段程式到底應該看到什麼」。這一點很重要，因為 agent 的問題常常不是能力，而是權限太鬆。

實操寫法可以直接拆成三層：

• 輸入層：按鍵、命令、prompt，只負責表達意圖
• 政策層：審核、驗證、路由，只負責決定可不可以做
• 執行層：WebAssembly、鎖權限容器、受限 runtime，只負責真的跑

三層混在一起，你就不是在做系統，你是在賭運氣。

這東西本質上是在做狀態管理

很多人看到 macropad 會先想到「快捷鍵變多了」，我看到的是另一件事：它其實是在幫你管理狀態。agent 工作流最容易亂掉的地方，不是輸入不夠快，是狀態不夠清楚。你到底現在是在 drafting、testing、reviewing，還是已經進了 blocked 狀態？如果這些只能存在你腦子裡，那就很容易忘。

我現在會把這種工具當成一個可摸到的 state machine。每一個按鍵都不是單純觸發 script，而是推動系統從一個狀態走到另一個狀態。這個想法對資深開發者特別有用，因為我們真正缺的通常不是自動化，而是少出錯。自動化太多，狀態太少，最後只會把錯誤跑得更快。

我自己遇過最常見的坑，就是「我以為自己在 review，結果其實已經在 execute」。這種事如果只靠介面顏色和腦內記憶，遲早翻車。你需要的是一個能把模式講清楚的控制面板。

實操寫法：先定義狀態，再決定按鍵。不要反過來。

• Idle
• Drafting
• Testing
• Sandbox execution
• Human review
• Blocked

接著列出允許的狀態轉移。按鍵要改變狀態，不只是觸發動作。狀態沒變，按鍵多半就是多餘的。

先寫政策，再買硬體，不然你只是把混亂變快

這是我最想吐槽的一點。很多人看到這種小裝置，第一反應是「我也要買一個」。我懂，桌上放個有燈的東西很爽。但如果你還沒寫 policy，硬體只會幫你更有效率地做錯事。我不是沒做過這種事，dashboard、bot、IDE plugin，我都見過同樣的劇本。

政策要先回答幾個很煩但很必要的問題：agent 可以碰什麼？可以跑什麼？什麼要記錄？什麼要先批准？什麼預設擋掉？這些不先定，按鍵只會把模糊的權限變成更快的模糊權限。

所以我現在看 Codex Micro，不是把它當產品，而是把它當設計提示。它提醒我，問題不是「怎麼讓 agent 看起來很神」，而是「怎麼讓 agent 可控」。這個問題雖然不帥，但比較能讓你平安下班。

實操寫法：先用白話寫 policy，再去配 key mapping。文字要短，短到別人不用開會就看得懂。

• 只允許指定環境
• 只允許指定命令
• 碰網路前要批准
• 不能寫 host filesystem
• 每一步都要記錄

政策寫不清楚，硬體再貴也沒救。

可抄的模板

# Agent control deck template for a macropad workflow

## 目標
用一個 macropad 管 AI coding agent，讓生成、驗證、執行分層。

## 三層結構
1. Intent input：按鍵、熱鍵、命令列，只負責表達意圖。
2. Policy gate：批准、驗證、路由，只負責決定可不可以做。
3. Execution sandbox：WebAssembly、受限容器、鎖權限 runtime，只負責執行。
4. Audit trail：所有動作與狀態變更都要記錄。

## 狀態模型
- Idle
- Drafting
- Previewing
- Testing
- Sandbox execution
- Human review
- Blocked

## 按鍵配置
- Button 1：Generate draft
- Button 2：Run local validation
- Button 3：Execute in sandbox
- Button 4：Send to human review
- Button 5：Abort and revoke permissions

## 安全規則
- 不要讓同一個鍵同時負責生成和執行。
- 預設不要在 host 上直接跑 agent 輸出。
- 任何網路存取都要先批准。
- 每次 promotion 都要有明確的狀態變更。
- 每個 transition 都要記錄 timestamp、environment、actor。

## 可直接貼上的 policy
When the agent is active, it may only operate inside approved sandboxed environments. Any action that changes files, runs commands, or accesses the network must be explicitly mapped to a dedicated control and recorded in the audit log. Human approval is required before promotion to production or access to sensitive resources.

## 實作清單
- [ ] 列出最常見的五個 agent 動作
- [ ] 每個動作綁一個實體控制
- [ ] 把 generation 和 execution 分開
- [ ] 加一個可視化狀態指示
- [ ] 把執行導到 sandbox
- [ ] 危險轉移要要求批准
- [ ] 每一步都保留 audit log

## 範例 key mapping
- Tap：generate
- Double tap：preview
- Hold：run sandbox
- Shift + tap：review
- Long hold：emergency stop

這段不是要你照抄 OpenAI 的硬體，而是要你把同一套紀律塞進你現有的工具裡。你可以用 Stream Deck、便宜 macropad、鍵盤 layer，甚至 terminal alias，只要狀態清楚就行。

我不會說硬體能解決 agent 風險，不能。可是它能逼你把流程變得不那麼散，不那麼靠直覺。這就夠用了。你如果想要自動化的方便，又不想把整台機器的鑰匙交出去，先從可見的狀態、窄權限、和一個會讓你停一下的控制面板開始。

原始拆解來源是 The New Stack 的這篇文章；上面這份模板是我根據它延伸出來的工作法，原創部分是我自己整理的流程、狀態與 policy 寫法。