有時候，你就是得讓代理自己發揮。
Mika 對上一家市值數十億美元的公司，還有一隻很蠢的小型桌面寵物。
當 OpenAI 在 2026 年 5 月推出 Codex Pets 時，他們想替你的程式開發代理加上一張臉。這些寵物會以覆蓋層的形式漂浮在 Windows 和 macOS 上，顯示 Codex 正在做什麼的即時狀態更新，並且在任務完成或代理需要輸入時通知使用者。這項功能隨附八隻內建寵物，以及一種能根據使用者圖片生成自訂 AI 動畫寵物的方法。
在我繼續之前，先說個前提：這其實算不上公平對決。Codex Pets 只是附加在一個被數百萬人使用的程式開發代理上的小功能，而且背後團隊有能力在第一天就同時支援兩種作業系統。Mochi 則只是我一個人做的、僅支援 Linux 的 alpha 版。兩者並不是在競爭同一件事；如果你在意的是「哪個產品更精緻、使用者更多」，那 Codex Pets 很輕鬆就贏了。它們共有的只有一個點——一隻住在你螢幕上的小生物——而這篇文章要看的，就是把同樣的點子往前推，並且拒絕停在「可愛的狀態燈」時，會發生什麼事。
這是個聰明的點子。但在可愛的外表底下，它某種程度上也幾乎什麼都不是。把精靈圖拿掉之後，一隻 Codex Pet 就只是有尾巴的狀態燈：等待你回應時顯示紅色時鐘，完成時顯示綠色勾勾。可愛，沒錯；但稱不上令人驚豔。所以我做了我真正想要的版本：Mochi，一個開源的 Linux 桌面夥伴，擁有真正的狀態機、真正的記憶，以及真正存在的理由，而不只是某個應用程式的通知串流。
Codex Pets 到底是什麼
從功能上來說，Codex Pet 只綁定一件事：某個 Codex agent thread 的狀態。它是一個像素風動畫夥伴，在 Codex 寫程式時浮在桌面上方，會對滑鼠互動與 Codex 狀態做出反應——思考時抓抓頭，任務完成時冒出對話泡泡。自訂寵物就只是把一個 manifest 檔和一張 spritesheet 丟進資料夾裡。除了「代理現在正在做什麼」之外，沒有持久化的內部狀態，沒有跨工作階段的記憶，也沒有任何最終不是反映 Codex 自身狀態的行為。
公平地說，這正是這項工作所需的正確工程量。單看就能理解的代理狀態小工具不需要狀態機；它需要的是可愛、讓人一眼看懂，且方便社群重製。OpenAI 把這個需求做得很好。但它終究只是個需求，而且還是很窄的需求——這隻寵物不會活得比它正在監看的 thread 更久。
Mochi 則是什麼
Mochi 不會回報任何外部事物。它不是某個其他工具的狀態燈——它的目標是讓人感覺它就住在你的桌面上，就這樣，獨立於你此刻開了哪個應用程式。這是個不同、也更難的問題，而這一點會直接反映在架構上。
在底層，Mochi 依靠一個單一的權威行為狀態機運作，用來調解數十個彼此競爭的系統——點擊、拖曳、睡眠、輸入偵測、媒體播放、情境化的應用程式感知等等——在任一時刻都必須對同一個問題達成一致：Mochi 目前由誰「擁有」，以及它接下來可以做什麼？而這還只是開始，甚至還沒算上 Codex Pet 完全沒有對應功能的那些系統：
- AmbiSense——一個本地、基於規則的環境感知層，會把桌面活動（輸入、影片播放、檔案瀏覽、目前使用中的應用程式）壓縮成隱私安全的語意訊號。不是 LLM，不是雲端服務，而且設計上絕不會看到實際按鍵、檔名或視窗標題。
- Bond progression——一個緩慢、刻意不帶懲罰性的關係系統。沒有連續登入獎勵，沒有衰減，沒有漏掉一天就被懲罰。XP 會從輸入時間與餵食中累積，而升級會觸發自己的展示流程。
- Focus sessions——一套完整的 Pomodoro 式領域模型，帶有自己的時鐘，即使視覺效果因為拖曳或點擊被打斷，時鐘仍會持續運作。Mochi 看起來是什麼，與背景中實際真實的是什麼，是刻意被分開的兩件事。
- 表情目錄（Emote Catalogue），帶有需要 bond 解鎖的機制與稀有度等級，所以 Mochi 能做的事，真的會隨著你擁有它的時間變長而增加。
- GNOME Shell helper，透過 D-Bus 接入真實桌面情境——輸入脈衝、閒置/使用中狀態、應用程式類別、影片焦點——同樣被轉換成粗粒度的語意訊號，而不是原始資料。
flowchart TD
Desktop["Linux 桌面"]
GNOME["GNOME Shell Helper<br/>D-Bus"]
Ambi["AmbiSense<br/>本機規則式情境層"]
Desktop --> GNOME
GNOME -->|"粗粒度語意訊號"| Ambi
Ambi --> Typing["輸入活動"]
Ambi --> Video["影片 / 媒體焦點"]
Ambi --> Apps["應用程式類別"]
Ambi --> Idle["閒置 / 使用中狀態"]
Ambi --> Files["檔案瀏覽活動"]
User["使用者"]
Click["點擊"]
Drag["拖曳 / 抱起"]
Feed["餵食"]
Media["媒體控制"]
User --> Click
User --> Drag
User --> Feed
User --> Media
State["權威的<br/>行為狀態機"]
Typing --> State
Video --> State
Apps --> State
Idle --> State
Files --> State
Click --> State
Drag --> State
Media --> State
Sleep["睡眠系統"]
Context["情境化應用程式行為"]
Animation["動畫 / 表情播放"]
Sleep --> State
Context --> State
State -->|"誰擁有 Mochi？"| Animation
State -->|"接下來允許什麼？"| Sleep
State -->|"允許的反應"| Context
Bond["Bond 進程<br/>XP · 等級 · 無衰減"]
Focus["專注時段<br/>獨立的 Pomodoro 時鐘"]
Catalogue["表情目錄<br/>稀有度 + Bond 解鎖"]
Feed --> Bond
Typing --> Bond
Bond --> Catalogue
Catalogue --> State
User --> Focus
Focus --> State
State -. "視覺狀態可能被中斷" .-> Focus
Focus -. "工作階段真實狀態持續運作" .-> State
Presentation["Mochi 呈現層<br/>動畫 · 移動 · 表情"]
Animation --> Presentation
Sleep --> Presentation
Context --> Presentation
State --> PresentationMochi 的架構把「真正成立的狀態」與「目前看得見的狀態」分開。桌面情境、使用者互動、成長進度、專注狀態與自主行為，都會匯聚到單一的行為狀態機，由它決定誰目前「擁有」Mochi，以及哪些轉換是合法的。
這些都不是裝飾。Mochi 的大部分程式碼庫手冊都在講生命週期與所有權：確保一個過時的動畫回呼不會在某個功能被中斷後還被觸發；確保視覺上關閉的內容選單不會留下看不見的輸入攔截；確保復原時總是重新評估當下的即時情境，而不是不管三七二十一，把中斷前正在發生的事重新播放一遍。這種問題，只有在一個系統的可動元件夠多、真的開始互相碰撞時才會出現——而這正是 Codex Pet 小到不會遇到的那種問題。
真正的差別
這裡講實話，不只是炫耀：Codex Pet 本來就應該很薄。它是附加在程式開發代理上的功能，目的就是讓人幾分鐘內寫出來，一眼就能看懂。要把 Mochi 的架構塞進去，對它本來的用途來說根本是大材小用。
但這也正是重點。OpenAI 為他們的產品做了一個吉祥物；而我做的是一個產品，它的全部工作就是成為那個吉祥物——一個具備持久性、情境感知、不依賴任何單一應用程式的照護機制，以及足夠穩健、能在被拖來拖去、中斷、晾在一旁一週後還活下來的狀態機。Codex Pets 是一項漂亮的功能，搭著一個市值數十億美元的程式開發代理一起飛；Mochi 本身就是那個東西，由一個只想把這件事認真做到位的人做出來。
我知道我比較想維護哪一個。
本文中關於 Codex Pets 的細節，來自公開報導與文件，而不是內部資訊。Mochi 是開源專案——你可以瀏覽程式碼、回報 issue，或只是來跟這個小傢伙打聲招呼。
原文出處：https://dev.to/mikachu/i-built-a-better-codex-pet-than-openai-did-eib
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
