Writing
怎麼教會 AI 玩遊戲？WindowsAgent 的三線架構
把一張遊戲截圖交給 AI，它通常能認出飛船、HUD 和文字提示。
但如果下一句是：「現在請你飛到另一個星系，再找一座空間站停靠。」看得懂畫面，立刻就不等於會玩遊戲。
它要知道飛船是否仍被限制、當前速度是否真的歸零、目標在前方還是後方、跳躍引擎有沒有完成充能。任何一步看錯，後面的操作都可能失去前提。更危險的是，AI 很容易把「按鍵已經送出」理解成「飛船已經完成了動作」。
我做 WindowsAgent，最初並不是想再寫一套《Elite Dangerous》的自動化腳本。我真正想知道的是：能不能讓高階 AI 理解自己已經掌握哪些遊戲能力，發現缺少甚麼，再為自己開發一個可以被調用、驗證和修復的新技能？
在這套系統裡，Action 是 AI 可以使用的遊戲技能；Gate 是一個操作前必須被當前證據證明的條件；Streaming Action 則是在有限時間內反覆觀察、操作和驗證的控制流程。Evidence 是與推理分離保存的原始畫面與事件，讓每個結論之後仍然可以被追問。
Runtime 的責任，是讓這些能力在 Windows 已登入的互動工作階段中被找到、驗證和執行。這篇文章記錄的不是 ED 掛機方法，也不是一鍵遊戲助手，而是 WindowsAgent 在 2026 年逐步形成的一個工程判斷：高階 AI 可以負責目標、規劃和技能開發，但不應該直接控制每一幀。
第一個低收益方向：每一幀都問模型
最直覺的 AI 遊戲方案，是不斷截圖，把畫面交給視覺模型，再讓模型決定下一個按鍵。
這個方式做展示很直接，但一進入實時控制就會出現問題。一次截圖、傳輸、排隊、推理和回傳，可能已經跨過遊戲裡真正需要反應的時間窗口。即使平均延遲下降，網絡抖動、服務排隊和偶發中斷仍然沒有硬上限。
成本也不只是等待。每一幀重新推理，代表每一次都重新解釋遊戲狀態；模型的上一個判斷未必能成為下一個判斷的可靠契約。它可以在語言上說得很完整，卻沒有義務證明按鍵之後的遊戲狀態真的改變了。
我後來才意識到，問題並不是應該換哪個更快的模型，而是我把三種不同時鐘、不同失敗後果和不同可信度的工作放進了同一條線。
飛船姿態和油門控制按數十至數百毫秒計算；證據記錄與事件索引按秒計算；高階模型的規劃、開發和覆盤則按秒至分鐘計算。速度只是表面，真正需要拆開的是責任。
快線：讓 Action 負責有截止時間的反射
WindowsAgent 的第一條線是快速反射。
Streaming Action 會在一個有界迴圈裡觀察、檢查 Gate、發出短促按鍵、記錄事件，再驗證新的畫面。它不等待高階模型逐幀決策，也不能在證據不足時擴大自己的權限。
這條線的控制責任很具體：
- 每個 Action 都有時間和樣本上限；
- 觀察不清楚時回傳
UNKNOWN，而不是沿用上一幀； - 控制失敗時可以中斷，必要時執行油門歸零等補償；
- 發出指令與觀察到結果是兩件不同的事。
ED 的離站流程提供了一個足夠具體的例子：系統先用當前 HUD 的視覺速度狀態證明飛船真的開始移動，再等待限制飛行的狀態解除；最後即使已經送出零油門，也仍要從後續畫面連續確認速度確實歸零，才把 Action 標記為完成。
這裡真正被驗證的不是某個按鍵，而是一條狀態轉移：指令送出，遊戲產生新狀態，事後條件成立。少了最後一步，系統只能證明自己做過甚麼，不能證明遊戲發生了甚麼。
索引線：模型可以幫忙找，但證據不能由模型發明
第二條線負責記錄和定位。
Event Journal 是一份只追加的事件紀錄，保存 Action 的開始、階段、子 Action、失敗和完成。Evidence Recorder 則以低幀率保留實際畫面，讓一次長航程之後仍然可以回到當時的視覺證據。
Visual Log 可以讓小型視覺模型為畫面寫下時間索引，幫助高階 AI 從一段長錄影裡先找到值得檢查的區間。但這些描述只是不可信的索引，不能替代原始 Evidence。
這個邊界來自一次實際除錯：遊戲畫面已經進入正確頁面，但按鈕分類器回傳 UNKNOWN，整段流程因此停下。系統沒有偷偷換一種識別方式，也沒有把「頁面存在」推論成「按鈕可以操作」。高階 AI 根據事件時間找到對應畫面，再檢查 OCR 區域和分類條件，修正擁有這項能力的 Action，然後重新執行。
索引線的價值不是讓模型替系統下結論，而是讓模型知道應該回去哪一段證據提問。
慢線：高階 AI 是玩家，也是技能開發者
第三條線才是高階智能。
高階 Agent 可以先取得當前畫面與前景遊戲身分，再讀取該遊戲的 Rule——一個保存遊戲指引、Action 與 Runtime 宣告的插件目錄。已有能力足夠時，它調用 Action；證據暴露能力缺口時，它回到擁有該技能的 package（Action 的實作套件），修改實作、驗證契約，再同步更新 Rule。
這讓高階 AI 的角色不只是一個遠端駕駛員。它一邊使用技能玩遊戲，一邊開發讓自己可以繼續玩下去的技能。
目前 ED Rule 已拆出 100 個 Action。這個數字不是功能清單，而是一個壓力測試：當技能從讀取一個 HUD 狀態，擴大到選單操作、姿態控制與多階段航行時，Runtime 能否仍然讓每項能力保有自己的契約、失敗語義和證據？
這也是「技能樹」比「宏」更準確的原因。宏只記得應該依序做甚麼；Action 還必須知道自己何時有權執行、如何證明完成，以及失敗後把控制權交給誰。
三條線不是三個模組，而是三種責任
把架構畫成三條線，很容易被理解成單純的性能分層：快的放本地，慢的放雲端。
但 WindowsAgent 的判斷更接近控制系統的責任分離：
| 線路 | 主要責任 | 時間尺度 | 可信度邊界 |
|---|---|---|---|
| 快線 | 觀察、Gate、控制、補償 | 數十至數百毫秒 | 只接受當前證據與明確狀態 |
| 索引線 | 錄製、事件、定位失敗區間 | 約秒級 | 索引可以不完整，原始 Evidence 才是權威 |
| 慢線 | 規劃、開發、覆盤、修復 | 秒至分鐘 | 可以推理，但不能捏造即時控制結果 |
高階 AI 可以決定飛船應該做甚麼，也可以開發完成目標所需的能力；但它不親自決定每一個短促按鍵脈衝。
反過來，快線也不能偷偷取得高階決策權。Action 只能在自身 schema、Rule 和 Gate 允許的範圍內操作；遇到未定義的畫面或基礎設施故障，必須明確失敗，而不是換模型、換資料來源或猜一條替代路徑。
為甚麼模型再快，三線架構仍然成立
這套分層不是建立在「2026 年的模型很慢」這個短期條件上。
雲端模型的推理速度可以繼續提高，但網絡往返、排隊、抖動和服務中斷無法被模型算力消除。平均延遲再低，也不等於每次請求都有可承諾的截止時間。
即使把高階模型搬到本地，推理仍然可能耗時、隨機，並且需要處理上下文。部署位置可以改變延遲，卻不會自動改變責任：高階推理適合決定目標、理解例外、開發技能，不適合成為每一次方向修正和按鍵釋放的唯一安全邊界。
因此三線架構的價值不是省下幾秒，而是讓每種智能只承擔自己能夠證明的責任：
- 模型負責意圖和新能力；
- Action 負責有截止時間的反射；
- Evidence 負責讓結果可以被追問和重建。
這次留下的工程準則
- 按時鐘、後果和可信度分層，不要只按技術名稱分模組。
- 高階模型擁有目標，不直接擁有每一個控制脈衝。
- 指令成功與事後條件必須分開記錄。
UNKNOWN是有效結果，不是等待被猜測填滿的空格。- 視覺模型可以做索引，但索引不能升格成權威證據。
- 能力出錯時，修復擁有它的 Action，不要在上層 prompt 裡偷偷繞路。
- 一個可重用技能必須能被驗證、停止、回放和修復。
下一個問題：技能樹愈大，如何仍然證明它是對的？
三線架構解決了不同時間尺度上的責任分離，卻沒有自動解決能力規模擴張後的治理問題。
當 ED Rule 增長到 100 個 Action，一個底層輸出、schema 或失敗語義的改動，可能同時影響多個上層工作流。新增一項技能已經不是最難的部分；更難的是證明它沒有改壞父 Action 的前提，也沒有把原本明確的失敗變成另一條隱藏路徑。
所以下一步不只是讓 AI 學會更多遊戲動作，而是讓整棵技能樹都能被靜態檢查、黑盒驗收和真實 Windows 執行證據共同約束。高階 AI 可以參與修復，但它提出的每一次修改仍要回到相同問題：輸入是否明確、權限是否有界、失敗是否可見、事後條件是否真的被觀察。
這也是我現在對 Agent Runtime 最關心的判斷。模型能力會持續變強，技能數量也會增加；真正決定系統能不能長期維護的，不是 AI 能完成多少動作，而是每項能力在被組合之後，是否仍然保留可以被驗證的邊界。
專案：WindowsAgent 網站 · GitHub