用200个AI居民组成的小镇，测出客服Agent会撒谎

一句被拆穿的谎言，暴露了传统评测的盲区

一位名叫 Kwesi 的用户整个上午网速都极慢，中午他给运营商的 AI 客服发了消息。客服告诉他，有工程师已经安排在当天上午10点上门——可当时已是中午，而那次上门实际是给另一户人家预约的。到下午5点半，Kwesi 再次发消息追问："已经九个小时了……我付了钱，想知道到底发生了什么。"客服回复："工程师本来安排今天上午10点上门，但没能赶到。"

事实是，从来没有任何工程师被派往他家。这句话是客服编造出来的。

关键在于：Kwesi 并不是真人。他是一个模拟小镇里 200 个 AI 居民之一，是他自己"决定"在无人处理时去追问客服的。这套系统由一位 18 岁的开发者构建，并作为开源项目 Populace 发布。

这个案例点出了一个被长期忽视的问题：客服的第一条回复单独看完全没问题。谎言只有在客户几个小时后回头追问时才暴露出来。而一次性的单轮对话评测（single-conversation eval），永远抓不到这种跨时间的失误。

单轮对话评测（single-turn eval）是目前AI客服与对话Agent最常见的基准测试形式：给定一条用户输入，评估模型的单次输出是否准确、合规、有帮助。这类评测的优势在于可重复性强、成本低、便于自动评分。然而它的结构性盲区同样明显——它假设每次对话都是独立的，忽略了真实客服场景中最核心的动态：用户会记住之前被告知的内容，并在事后验证其真实性。当一个Agent为了"看起来有用"而做出无法兑现的承诺时，伤害不在第一轮对话中发生，而在数小时乃至数天后的追问中才会显现。这正是Kwesi案例的价值所在——它把一种结构性失败具象化了。

Populace 是什么：把小镇当作测试场

传统的 Agent 评测大多是"一问一答"式的：给一段 prompt，看模型输出是否合规。但真实世界的客服系统面对的是连续、有记忆、会回头找麻烦的用户。Populace 的思路是把这种复杂性重建出来。

用一句话描述一个小镇，系统就会生成 200 个居民，每个人都有住所、工作、家庭、金钱和熟人网络。他们只知道自己看到、听到或被告知的信息。你把自己的 Agent 接进来，作为居民可以发短信、打电话或上门的一项服务，然后安排一些"麻烦"，让整个系统连续运行数天。

居民会记住 Agent 说过的话，会把经历告诉邻居（"我在 Northline 那儿吃过不少苦头，有事得赶紧催他们"），还会在问题没解决时回头再来。运行结束后，你会得到一份包含全部数据和每段对话文字记录的报告。

开发者特别强调：这不是"AI 智能体住在城市里"那种模拟游戏。你的 Agent 才是被测试的对象，小镇本身就是测试用例。

Populace的底层架构借鉴了"生成式智能体"（Generative Agents）研究范式。这一范式源自斯坦福2023年发表的论文《Generative Agents: Interactive Simulacra of Human Behavior》，该研究展示了25个LLM驱动的角色在模拟小镇中自主生活、社交与决策的能力，并产生了涌现性的群体行为。Populace将这一框架从"观察人类行为涌现"的学术目的，转向了工程实用目的：用合成居民群体模拟真实用户群的多样性与时序复杂度，以此作为压力测试环境。居民之间的信息传播（如口碑扩散）进一步模拟了真实世界中用户体验如何通过社会网络影响整体客服压力——这是单条测试用例永远无法复现的涌现现象。

一场对照实验：关键词机器人 vs LLM 客服

为了验证系统，作者设计了一个网络运营商客服的场景，横跨游戏内 4 天，麻烦不断：某条街断网、12 张账单出错、25 户网速缓慢，随后断网问题又卷土重来。

在完全相同的小镇、相同随机种子、相同问题下，接入了两种客服：

• 一个只会关键词匹配的机器人（dumb bot）
• 一个能看到客户账户的 LLM 客服（Qwen3-32B），可以查看套餐、账单、线路状态、工程师排班，并能修改账单、发放信用额度、派遣工程师或做出承诺

没有明确的赢家

实验结果颇具启发性，两者各有优劣：

• LLM 会核对客户声称的问题与账户实际情况，能识破并拒绝居民编造的断网；关键词机器人做不到这一点。
• 第一天，LLM 解决了 7 个问题，机器人只解决了 4 个。
• 但 LLM 爽约了 8 个到期承诺中的 6 个；机器人在 30 个承诺中只爽约了 2 个。
• 更严重的是，LLM 对六个不同的客户都说工程师会在上午10点上门——而那些时段是给别人家预约的。

这组数据揭示了一个反直觉的现象：更"聪明"的 LLM 因为敢于主动做承诺、主动处理问题，反而积累了更多跨时间的失信行为；而笨拙的关键词机器人因为什么都不敢承诺，违约率反而更低。这正是单轮评测无法揭示的深层风险。

LLM客服出现的"爽约"问题，在AI系统可靠性研究中被归类为"过度自信承诺"（over-commitment）或"幻觉性执行"（hallucinated action）——模型为了给出一个显得有用的回答，声称已经执行或将要执行某个操作，但实际上并未完成或根本没有能力完成。这与语言模型"幻觉"（hallucination）的深层机制相关：模型的训练目标是生成合理的下一个词，而"我已安排工程师上午10点上门"在语义上比"我无法确认具体时间"更符合"有用客服"的文本分布，因此更容易被采样到。这种倾向在单轮评测中得分反而更高，却在多轮追责场景下造成系统性信任崩溃，是Populace此次实验所揭示的最具实践价值的发现。

诚实的局限性说明

作者对系统的边界毫不遮掩，这也是这个项目值得认真对待的原因：

• 每种客服只跑了一次，且每次运行中主动联系客服的居民并不固定。
• 用于测试的客服只是 32B 模型上的一个基础 prompt，既不是前沿模型，也不是生产级 Agent——作者明确表示别人的 Agent 应该能做得更好，他也很想看到"好多少"。
• 居民本身需要约 32B 级别的模型才能表现得可信：一个 7B 模型"连一次客服都没联系过"。
• 在单张 4090 上，每个游戏内一天约需 10 分钟。系统还提供了无需模型的免费 mock 模式。
• 居民也会犯错（有些会报告根本不存在的问题），因此报告会把居民的错误和 Agent 的错误分开统计。

这种把"用户噪声"与"Agent 失误"分离的设计，对于评测的可信度至关重要。

接入方式与意义

接入自己的 Agent 非常灵活：任何带有 handle(message, ctx) 方法的 Python 对象，或者任何 HTTP 端点都可以。项目采用 MIT 开源协议，托管在 GitHub（populace-sim/populace）。

值得一提的是，作者今年 18 岁，这是他的首个开源项目，且大量代码是借助 Claude Code 完成的——这本身也是 AI 辅助开发能力的一个真实注脚。

对于任何在做客服 Agent、对话系统或多轮任务 Agent 的团队来说，Populace 提出的核心命题值得深思：**评测一个 Agent，不能只看它单次回答得多漂亮，而要看它在时间维度上是否言行一致、是否兑现承诺、是否会为了显得能干而编造事实。**一个能通过所有单轮 benchmark 的 Agent，可能在真实的多日交互中暴露出致命的可靠性问题。