282 個提交，公開日誌上的第一個週末

真正關鍵的提交是 C API：從執行環境擁有穩定公開介面的那一刻起，兩股由代理人執筆的工作流就不再互相絆腳。這就是 AI 原生執行環境在迴圈運轉起來時的樣子。

上週六我開立了一疊議題，把一個自主程式撰寫代理人指向佇列。到了週日傍晚，我坐在廚房餐桌前、在週一之前最後一次打開筆電時，執行環境儲存庫已經落地了 282 個提交。其中只有一小部分作者是我。其餘大多數的作者是一個自主程式撰寫代理人。

這個數字看起來像一整個衝刺週的工作量，原因是工作在我不在鍵盤前的時候持續進行。我週末才在鍵盤前。代理人沒有日間正職。產出就是這種安排自然掉出來的東西。

佇列怎麼運作

週六早上是開立日。我端著咖啡坐下來寫 GitHub 議題。每一個都是引擎接下來需要的一件範圍鋒利的工作。形式大致是：

• 一個議題只涵蓋一個子系統或一個功能
• 一個代理人可以自我檢核的明確驗收標準
• 指向相關文件、規格，以及這項工作應該觸及的既有檔案的指引
• 一個明確的「agent-queue」標籤

還有一個夜間工作流程（本週末是執行環境儲存庫的議題 #37），確保佇列裡開放的代理人議題永遠不少於十五個。一旦低於，工作流程就從路線圖起草佔位任務。代理人讀取佇列、挑選下一個它能做的、開啟草稿 PR、反覆修改，最後把自己標記為可供審查。

週六到週日我負責審查與合併。代理人做錯的地方，我關閉 PR、把議題磨利、重新開立。代理人做對的地方，PR 落地、議題關閉。節奏是：週末一開始開立議題、兩天全程審查、週日晚上闔上筆電時留下一條補滿的佇列。我回去上日間正職時，代理人繼續磨佇列。

這就是工作流程。它一點也不精巧。值得寫下來的原因是：它有效。

蓋出了什麼

282 個提交的重點摘要：

• 一個真正的執行環境主迴圈，不只是骨架
• 一個量測從感測器輸入到渲染的端對端時間的延遲追蹤器
• 一個具可設定門檻與定期回報的記憶體用量監視器
• 一個具 INFO／WARNING／ERROR 等級、主控台與檔案輸出的日誌子系統
• 帶有訊號處理器、可優雅關機的錯誤處理
• 一個對外暴露執行環境的 C API，讓 SDK 可以連結
• C API 裡供 SDK 整合的模組／代理人管理系統
• 執行環境的並行模型：任務佇列與工作執行緒
• 一套完整的測試工具
• ABI 驗證與 SDK 連結檢驗
• AR1+ 智慧眼鏡規格定案為產品目標

這些沒有一項光鮮亮麗。但這些全是 AR 執行環境在任何有趣的東西能蓋在上面之前所需要的。

回頭看，最重要的提交是 C API 的暴露。從執行環境擁有 SDK 可連結的穩定公開介面的那一刻起，執行環境的工作和 SDK 的工作就不再互相絆腳。在那個提交之前，一個儲存庫的每次變更都得小心翼翼地和另一個同步。之後，它們解耦了。兩股由代理人執筆的工作流可以平行推進而不產生合併衝突。

令我意外的事

三件。

代理人做無聊的基礎設施比我快。 遙測、日誌、錯誤處理、測試工具。這類任務人類容易分心，因為工作不光鮮。代理人不會分心。它就是把差異落地。

代理人在架構上很保守。 給它一個寫著「實作一個量測感測器到渲染時間的延遲追蹤器」的議題，它就精準地蓋出那個東西。它不會為延遲的意義發明一套形上學，也不會提議另一種 API 形狀。這很好。架構是我的工作。實作是代理人的工作。

補滿佇列是瓶頸。 當代理人一天出貨十五個 PR、傍晚佇列就空了的時候，吞吐量的關鍵就不再是代理人做得多快，而是我能多快把下一批任務講清楚。這重塑了我的週六早晨。第一個小時就是開立議題。

壞了什麼

兩件事，都不致命。

CMake 建置壞了兩次，原因是代理人落地的程式碼單獨編譯沒問題，卻無法和執行環境其餘部分連結。兩次的解法一樣：代理人目前還看不到專案完整的連結期關係圖。解法在議題的框架裡。從現在起，每個觸及某個函式庫的議題都要明確寫出還有哪些函式庫會連結它。

測試工具是在這一輪後期才加入的，立刻在先前的 PR 裡揪出四個 bug——那些 PR 通過了手動冒煙測試，卻沒通過新的測試工具。教訓是最不性感的那種：把測試當作功能的一部分來寫，而不是事後補課。議題有寫，代理人就會做。議題沒寫，它就不做。那就讓議題永遠都寫。

我想讓夥伴和開發者知道的事

這個引擎的形狀此刻正在成形。到下個月底，大多數基礎性的決策都會底定。如果你在模型實驗室、對 AI 層應該怎麼接入有想法，現在正是意見便宜好採納的窗口。如果你是考慮 Unity 或 Unreal 整合的開發者，SDK 就在這個週末成形，繫結反映著執行環境的能力。我寧願在第六週聽到你的聲音，而不是第六十週。

執行環境儲存庫是開放的。SDK 儲存庫是開放的。開放議題的佇列是開放的。即時看著這一切發生，正是重點所在。

282 個提交，公開日誌上的第一個週末。週日入帳。週一再會。