通过“氛围编程”制作游戏，我设计了一个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的未完成项目库中。但作者表示，一旦协议稳定，可能会继续完善游戏，看看能否做出一个勉强可玩的版本。

最后，作者鼓励读者不要害怕变化，以适合自己的节奏拥抱新事物。他认为想法和直觉仍然是最重要的，而实现手段在当下已不是障碍。手写代码仍有其艺术价值，但功能性上已不再不可或缺。