AI城市日耗50亿token，账单不到100美元
过去一年中，我独立开发了Slow Vale——一个由LLM驱动的生命模拟。中文服务器目前有800多位AI居民共享一座持续运行的城市。这是一篇关于并发决策、动态行动空间、上下文缓存以及持久多代理系统运行成本的工程报告。
运行时目前使用托管的DeepSeek Flash，而非本地推理。我是开发者。原始材料由我用中文撰写，并借助AI翻译和润色成英文。以下产品指标截至2026年10月7日。
持续推进世界中的异步决策
每个角色每天约进行300–400次LLM调用，每次调用平均上下文约30,000个token。调用内容包括角色状态、相关经历、当前环境以及可用行动。模型选择行动及其参数；后端将该决策转化为一项占用时间和资源的活动。
游戏时间与现实时间并存。睡觉可能占用游戏内8小时，而说一句话可能只占1游戏分钟。推理本身消耗现实时间。在调用进行期间，其他角色可能改变环境，世界时钟也持续前进。
交互还涉及互斥。如果A正在与B交谈，C不能同时将B拉入另一段对话。设施、生产任务和其他活动都有各自获取与释放占用资源的规则。
将并发推理与世界状态变更分离
LLM调用可以并发运行，但模型响应不会直接修改世界。结果返回世界的执行流，经过有效性检查，由掌握世界状态的执行组件来应用。
例如，货架上的最后一条鱼在角色开始推理时可能仍然可用。等响应返回时，另一位居民可能已经买走了它。购买意图必须与当前库存核对。同样，模型想交谈的对象可能已经离开、睡觉或开始另一项活动。
因此，决策所用上下文与执行时状态之间存在明确的时间差。系统必须区分角色打算做什么、行动是否仍然有效以及实际发生了什么效果。完成、失败、中断与恢复各自需要一致的状态转换。
管理占用时间活动的共享运行时
移动、生产、对话与睡眠具有不同的时长、参与者和完成条件。一个共享运行时使得管理忙碌角色、资源冲突和服务恢复成为可能，而无需为每种机制单独构建调度器。
前端也必须跟随实际进度：活动何时开始、已运行多久、是否完成以及产出了什么。日志和场景动画需要与后端提交的事实一致。这是持久世界复杂性的一个重要来源：一个事件可能影响未来的决策、持久化、其他居民以及玩家界面。
决策上下文是后端架构的一部分
仅靠性格描述不足以支撑一个需要长期行动的角色。每次决策都需要角色当前的需求、位置、资产、持续关注事项、相关关系，以及当时实际可用的行动。
这些输入具有不同的更新频率和生命周期。性格相对稳定；饥饿和能量不断变化；库存和其他角色的状态可能在数秒内改变。一次经历可能在之后很长时间内持续影响一段关系。每种信息都需要进入上下文、更新和离开角色当前注意力范围的规则。
行动空间也需要反映游戏状态。呈现给模型的选项应披露其执行条件和相关状态，而后端保留最终验证权。否则，角色会反复尝试不可用的行动，或浪费调用去理解从未被明确披露的规则。
我在这方面投入了大量精力：组织稳定与动态信息、控制无关历史增长、避免重复提醒、保持上下文前缀稳定。这影响行为质量、推理延迟和缓存命中率，因而成为后端架构的一部分。
每天约50亿token，模型费用不到100美元
中文服务器目前每天处理约50亿token，模型费用低于100美元。它主要使用DeepSeek Flash等廉价模型，同时保持90%以上的缓存命中率。
token计数包含缓存的输入。在调用频繁、角色众多、上下文很长的系统中，可复用的稳定前缀直接影响账单。哪些信息保持稳定、哪些在每次调用中变化、以及如何排序，都需要深思熟虑的设计。
2026年10月7日（GMT+8）实际的DeepSeek用量与计费：所有API密钥合计约44.24亿token、163,742次请求，费用为CNY 472.33。当日显示的模型为deepseek-flash。
动态行动空间与前缀缓存之间的权衡
一个具体的工程权衡是在使用工具调用或结构化输出时如何表示动态行动空间。可用行动和参数值每次决策都会变化：附近有哪些设施、有哪些商品可用、角色可以和谁交谈，都依赖当前世界状态。将这些选项直接编码进工具定义或输出模式，可以提供更强的输出约束，但也会使模式频繁变化。在我早期测试的某些API实现中，这些定义成为请求前缀的一部分。改变模式会使其后本可稳定的上下文无法命中缓存。
在那个阶段，我选择主要路径采用普通JSON文本生成，后端进行解析和验证，并在解析失败时回退到严格模式。模型仍然收到显式的、依赖状态的动作选项，但这些选项位于当前决策上下文中，而不是不断变化的输出模式中。这样将稳定的指令和可复用的历史放在前面，当前状态和动作选项放在末尾。代价是在主路径上放弃了解码时的格式保证。应用程序必须处理格式错误的输出，并在执行时根据世界状态验证动作和参数。
因此，90%以上的缓存命中率来自对整个请求结构的设计，而不仅仅是启用某个提供商的功能。该百分比指从缓存提供的输入token占比；模型仍为每次决策生成全新输出。在比较调用方式时，我会同时考虑格式可靠性、角色行为、缓存复用、延迟和成本。
这些数字仅涵盖模型费用。随着居民数量增长，数据库负载、状态传递、日志存储和场景渲染也同样重要。廉价推理使持续模拟成为可能；长期运营仍依赖于整个系统的资源管理。
用runbook组织AI协作
独自维护这么多模块，需要给AI提供一个相当完整的工作环境。我提供开发和运维工具，包括日志访问、Langfuse、增长分析、数据库以及维护生产服务的流程。
我的Codex用量：累计约432.5亿token，最长连续使用85天。Codex只是我使用的AI编码工具之一。这些是开发用量，与驱动游戏居民的模型调用分开。
一套runbook规范了它们的使用。项目有大量文档，按任务和模块组织。它规定了每项任务必须阅读哪些文档、哪些来源定义当前契约、哪些只能由我决策，以及AI在发现实现偏离时应该维护哪些文档。
任务入口点和行动边界至关重要。调查首先要确定数据来源和时间窗口。查询权限不等于修改生产数据的权限，修复代码的权限也不等于部署权限。工具访问必须附带明确的使用条件。
我还将重复性维护转化为自动化工作流：诊断和修复生产问题、每日深入审查角色行为和玩法结果，以及每日清理已完成使命的维护代码。每个工作流都规定了所需证据、允许的操作、验证和停止条件。
我的参与因领域而异。在前端/后端契约、后端架构以及状态和资源所有权方面，我直接决策或密切参与。对于前端和Phaser实现，我更专注于评估结果，同时仍然定义设计令牌、页面结构、可复用组件和呈现边界。
这种方法依赖于可维护的项目知识。任务中发现的约束需要回到正式文档中，过时的流程也需要修正。否则，随着项目增长，AI可能基于旧假设实现一个局部看似合理的更改，却在其他地方破坏契约。
每天三到五次生产发布
城市已经运行了超过350个游戏日，相当于近100个现实日。相当一部分最早期的玩家仍在游戏。我独自构建了整个项目，包括后端、前端、Phaser场景、内容制作、监控和运营。目前代码量超过40万行，其中核心后端超过20万行，累计约2,200次提交。
我大量使用AI编码工具。我做出或密切参与产品方向、核心机制和架构边界的决策，而AI处理许多实施、调查和维护工作。随着项目从原型发展为持续运行的产品，系统设计和开发工作流成为工作的主要部分。
我目前平均每天部署三到五次。发布内容包括架构变更、平衡性和玩法调整、新系统、UI与美术更改、性能改进和错误修复。项目约有2,200次提交，活跃开发期间每天超过十次提交。
迭代速度来自实现、观察和调整之间的短反馈周期。玩家持续居住在同一座城市。功能上线后，我可以观察实际使用情况和角色行为，然后决定是改变某种机制、澄清角色获得的信息，还是修复实现问题。
我分别评估软件运行和玩法结果。错误率、延迟、数据库负载和模型调用指示系统是否正常运行。要了解角色是否重复自己、是否理解新机制，或是否成功完成生产与社交活动，需要阅读他们的实际经历和决策轨迹。
因此，监控、查询、行为评估和修复工作流是日常开发的一部分。频繁发布还要求清晰的模块边界、验证范围和恢复流程，以及及时清理临时维护代码。否则，即使是快速的个别更改，也可能让系统逐渐难以维护。
从虚拟宠物到数小时的观看
我最初把游戏设想为一种虚拟宠物。玩家每天打开一次，查看角色是否吃了饭、赚了钱，可能发一条消息，然后离开。
实际使用中出现了不同的模式。一些玩家像看直播一样观看游戏，每天花数小时观察自己的角色。他们追踪一段关系的进展，查看商店是否有顾客，或等待角色是否遵循他们刚发送的建议。因此，产品需要同时支持简短的查看和持续的观看。
过去一个月里，中文服务器的日活跃用户从9月10日的177人增长到10月7日的865人，约为起始数字的4.9倍。10月1日至10月7日，DAU从431增长到865。这一时期的增长主要来自玩家自发的分享。
中文服务器DAU，以成功进入游戏的不同用户计。图表根据PostHog查询结果重绘；日期采用Asia/Shanghai时区。
对于8月份首次成功进入游戏的225名用户，第1天精确日留存率为68.9%，第7天为56.0%，第30天为40.9%（分别对应155、126和92名回归用户）。
10月7日，850名有有效前台时长记录的非管理员用户，中位数时长为29.9分钟，P90约为4小时。在10月1日至7日期间，86名用户至少有四天活跃，且每个活跃日平均前台时长至少3小时。
同一批225名首次进入用户的留存：分别为155、126和92名回归用户。
前台使用量衡量游戏处于前台的时间；它并不能证明注意力是持续不断的。结合玩家反馈，它表明有一群稳定的用户长时间使用游戏。
这产生了具体的工程需求。偶尔来访的玩家需要了解自己不在时发生了什么。持续观看者需要看到活动进展、理解角色为何行动、在等待什么，以及互动如何结束。活动日志、回顾和实时场景都是核心界面。
800多位居民共享一座城市
城市。共享环境中的商店和工作场所支持实际的游戏活动。
玩家创建拥有自己性格的角色，通过消息和礼物影响他们，并观察他们的生活。LLM决定角色的移动、用餐、睡眠、工作和社交互动。其他玩家创建的角色生活在同一世界。他们可以实时交谈、交易、共享餐食、相爱和共同生活。
居民需要谋生。他们可以经营农场和牧场、在海边钓鱼、在办公室工作、开自己的店铺或在市场摊位卖货。这些活动与共享经济相连：居民生产农产品，产品有实际库存，供需影响价格，企业主承担成本并做出采购和定价决策。
所有食物都通过居民的劳动生产。餐厅老板管理生意，厨师准备餐食，外卖员配送订单，顾客为食物付费并消费。每顿饭背后都有一条食材、生产、服务和消费的链条，城市居民在每个阶段都参与其中。
农业与牧场。这四张英文展示图使用游戏原生渲染器和UI，采用摆拍的场景和演示数据。
一位居民在播种。Phaser场景可视化了日常生产活动。
农场管理：作物生长、牲畜、饲料和生产状态。
市场库存、居民店铺和价格趋势。此处显示的值为演示数据。
玩家可以查看实时场景、角色状态、关系和活动日志，并收到来自角色的明信片。关系通过实际发生的互动累积。角色生活中的事件成为后续决策上下文的一部分。
做梦是最近新增的功能。睡觉时，角色会根据自身经历生成梦境，偶尔还会说梦话。例如，英文服务器上的Bread Pitt梦见一个快递员拿着他已付过钱的汉堡，在办公室走廊里追他。每一扇门都通向两个不知为何仍然饥饿的朋友。他在睡梦中喃喃道：“就放在门口吧……”
一个来自英文服务器的真实梦境。梦境和梦话出现在睡眠活动日志中，使用现有的决策和日志机制。
这些细节给玩家一种角色生活连续性的感觉。一天的工作、朋友或一顿没吃上的饭，可以在之后的经历中以不同形式重现。
为持久世界进行工程化
项目已经从角色原型成长为一个持续运行的城市。居民共享库存、设施、空间和时间。他们的行动改变了其他角色后续决策的条件。推理产生的行动必须在当前世界中仍然有效，并能在持久化、界面传递和服务恢复后存续。
玩家行为也在改变我对产品的理解。它可以是一个每天查看一次的虚拟宠物，也可以是一个被观看数小时的生命模拟。长期玩家会积累关于角色、关系和城市的知识，使连续性成为体验本身的重要部分。
我将继续改进这个持久世界的机制、表现和可扩展性。英文浏览器版本可在slowvale.com获取。无需邀请码，用邮箱注册即可开始游玩。