通過“氛圍編程”製作遊戲，我設計了一個AI智能體協議

本文作者講述了自己從一名AI懷疑論者轉變為AI積極實踐者的歷程，以及在此過程中意外設計出一個AI智能體協議的故事。

起初，作者和許多人一樣對AI持否定態度，但今年年初他徹底改變了想法，開始深入學習本地模型、推理引擎和智能體框架。Claude Opus 4.5的發佈成為了轉折點，讓他意識到這些模型對軟件工程的實際價值，儘管他起初也像大多數工程師一樣，難以接受自己辛苦學來的技能部分過時的事實。

此前，代碼補全和代碼生成等功能對他毫無吸引力。但這次不同，他決定親手實踐，打造第一個完全由AI輔助（“氛圍編程”）的項目——一款名為“SAO: Slop Art Online”的MMO遊戲。這款遊戲的核心概念是所有NPC（非玩家角色）與玩家採用相同的建模方式，唯一區別在於NPC由LLM控制，而非人類。從商人、衞兵、政治家到各類動物和怪物，遊戲中的所有智能實體均如此。

然而，最初的簡單方案（將玩家視角的當前世界快照與可執行動作發送給LLM，等待其返回行動指令）很快暴露出延遲問題，無法滿足實時戰鬥等機制的要求。作者考慮過微調小模型，但鑑於遊戲機制尚未確定，成本過高且不靈活。最終，他採用了一種混合方法：每種實體先基於默認行為樹行動，當NPC在遊戲中“經歷”事件時，再使用LLM重新生成行為樹。這樣既保留了確定性行為的瞬時執行，又引入了非確定性LLM的情景適應能力。

藉助SpacetimeDB的推送式架構，LLM橋接器始終能獲取最新的遊戲狀態，包括可觀察世界和上下文化的可用動作。這個設計讓作者意識到一個問題：為什麼現有的智能體協議（如MCP）不能如此設計？為什麼工具列表是扁平的，而不是基於推送的狀態投影和上下文化的動作？為什麼讓LLM使用專為人類設計的可視化界面？一個真正面向智能體的接口應該是什麼樣子？

基於這些思考，作者開始設計一個名為SLOP的協議。他總結出幾個核心原則：首先，創建應用數據的狀態樹投影，消費者是LLM，因此表示形式是結構化文本；其次，通過推送機制保持應用狀態鏡像的實時性，使智能體無需在每次交互前主動讀取狀態；第三，動作應定義在相關數據上，而不是作為扁平列表獨立存在；第四，動作應根據當前狀態動態加載；最後，採用消費者/提供者分離架構，應用通過提供者暴露範圍化的狀態，消費者負責處理快照更新，雙方僅通過協議通信。

儘管這個協議可能淹沒在AI時代的眾多項目中，作者仍希望將它發佈出來，接受社區的檢驗。他認為，對於應用與模型交互的問題，MCP和計算機使用（computer use）仍然存在差距，而SLOP提供了一種替代方案。

遺憾的是，為了專注協議開發，遊戲項目被擱置在GitHub的未完成項目庫中。但作者表示，一旦協議穩定，可能會繼續完善遊戲，看看能否做出一個勉強可玩的版本。

最後，作者鼓勵讀者不要害怕變化，以適合自己的節奏擁抱新事物。他認為想法和直覺仍然是最重要的，而實現手段在當下已不是障礙。手寫代碼仍有其藝術價值，但功能性上已不再不可或缺。