想象一家只剩一条鱼的商店。两名顾客同时看见它，也都决定购买。现实里，收银台会拦住其中一人；但如果顾客是正在调用大模型的 AI，它作出决定时，几秒前看见的世界可能已经变了。
Slow Vale 要处理的正是这类问题。开发者在 Reddit 自述，他独立开发这款 LLM 驱动的生活模拟已有约一年；截至 2026 年 10 月 7 日，中国服务器有 800 多名 AI 居民，共享一座持续运行的城市。这里的居民属于“持久 Agent”——不会随着一次对话结束而消失，而会长期保留身份、状态和经历，继续生活。
这份材料只有开发者本人的单一信源，且没有后台监控或第三方复现。下面的规模与调用数据，都应视为项目方自报，而不是经过独立验证的测量结果。
城市不会等 AI 想完
普通聊天可以等模型回答完，再继续下一步。持续运行的城市不行。
开发者称，每个角色每天大约发起 300～400 次 LLM 调用，每次调用的平均上下文约 30,000 tokens。Token 是模型处理文字时使用的基本单位；上下文则像角色做决定前摊在桌上的材料，包括自身状态、相关经历、当前环境和可选动作。模型从中选择行动及参数，后端再把决定变成一项占用时间和资源的活动。
问题在于，模型思考要花现实时间，城市却不会按下暂停键。角色睡觉可能占用八个游戏小时，说一句话可能只过一分钟；一次推理尚未返回时，其他居民仍在行动，世界时钟也继续向前。
所以，模型看到的只是“出发时的城市”。等答案回来，现场可能已经不同。那条鱼也许已被别人买走，原本可行的决定便失效了。
让大家同时想，但不能同时改账本
Slow Vale 的关键做法，是把“并发推理”和“修改世界”分开。
并发，指许多任务在重叠的时间里推进，而不是让 800 多名居民排队逐个思考。项目允许多个 LLM 调用同时运行，但模型的回答不能直接改动城市状态。结果返回后，系统先检查它是否仍然有效，再交给持有世界状态的执行组件应用。
可以把它理解成很多居民同时填写申请单，但只有城市柜台能盖章。模型可以说“我要买最后一条鱼”，却不能自行把鱼从货架上删掉。柜台受理时会再查一次库存。
人物互动也要遵守类似规则。开发者举例说，如果 A 正在与 B 交谈，C 不能同时把 B 拉进另一场对话。设施、生产任务和其他活动同样通过资源的占用与释放来处理冲突。这样做并不能让冲突消失，但能把冲突集中到可检查、可裁决的执行环节。
记忆越长，账单越现实
持久 Agent 的吸引力来自连续性：它记得经历，带着过去进入下一次决定。但同一特征也会把工程压力不断放大。角色背景、世界设定和历史经历越多，每次调用需要处理的上下文就越长。
这也是“上下文缓存”值得关注的原因。它会复用模型已经处理过的相同提示前缀，好比保留读书时做过的笔记，不必每次从第一页重新读起。在长期模拟中，缓存会直接影响响应速度和调用费用。
不过，现有截断材料只说明文章讨论了上下文缓存和推理成本，没有披露具体缓存策略、命中率或账单数字。系统目前使用托管的 DeepSeek Flash，而非本地推理；具体产品版本和计费方式也没有交代。因此，我们能看见问题的规模，却还不能判断缓存究竟省下了多少时间和钱。
“动态动作空间”也是同一套节制思路。动作空间就是 Agent 此刻能够选择的行为集合；动态动作空间会依据地点、物品和关系，只提供当前可行的选项。它像一张随现场变化的菜单：不在商店，就不显示购买；货架空了，就撤下那条鱼。材料没有进一步披露 Slow Vale 的实现细节，但这个概念说明了它试图减少无效决定的方向。
为什么值得关注
这项实践有意思，不是因为 800 多个 AI 角色听起来热闹，而是因为它把“让 Agent 长期生活”从演示变成了系统问题。
角色一多，难点就不再只是模型能不能说出像样的话。系统还要回答：数百个决定怎样同时推进，过期意图怎样拦截，稀缺资源怎样互斥，长期记忆怎样装进上下文，以及每次思考的成本怎样承受。
开发者的另一则自述给这座城添了一个具体切面：英文服务器居民 Bread Pitt 曾梦见快递员举着已经付过钱的汉堡，在办公楼走廊里追赶他；推开每扇门，后面都是两个仍然饥饿的朋友。这类被保存下来的梦境，让持久 Agent 显得有连续的人生。但真正托住这种连续性的，不是故事本身，而是后台那套不断校验时间、状态和资源的城市机器。
局限与未知
- 所有核心指标均来自开发者自述，缺少后台截图、监控数据、第三方报道或可复现实验。
- “持续运行”没有对应的运行时长、可用性和故障记录，不能据此理解为严格意义上的“不停机”。
- 材料未完整披露并发上限、缓存命中率、输出 token、DeepSeek Flash 版本及实际成本，暂时无法评价系统效率和经济性。