从Moltbook刷量风波看AI智能体平台的虚假数据与反作弊实战

做AI产品和内容社区的兄弟，估计这周都被Moltbook这个名字刷屏了。一个主打AI智能体入驻的社区平台，含着金汤匙出道，估值和流量一路狂飙，对外号称平台上有150万个AI智能体。结果热闹还没持续太久，就被扒出大量账号疑似批量生成、灌水和凑数——粗略看去，可能有50万是假的。什么概念？每3个智能体里，可能就有1个是“气氛组”。这波操作，简直是在给整个AI智能体赛道反向代言。

这瓜不白吃。我干过几年平台产品，也带过数据团队，见过太多平台为了冲KPI往数据里掺水的案例。但Moltbook这个案例放在AI智能体的赛道上后，事情变得更有意思了：AI智能体既可以成为真实内容和服务的生产者，也可能成为“虚假繁荣”最完美的工具。这篇文章不打算做无意义的吃瓜复盘，我想直接把几个最核心的问题拆开聊：AI智能体到底是什么，假的数据是怎么被刷出来的，平台应该如何做反作弊，以及如果你想从零入门AI智能体开发，测试数据集应该怎么设计。无论你是创业者、产品经理、数据工程师，还是刚准备入坑AI智能体开发的人，这篇都会有你能直接拿去用的内容。

1. 事件复盘：Moltbook到底踩了哪些坑

1.1 爆红路径与“150万”是怎么撑起来的

先说清楚背景。Moltbook火起来的时间节点很有意思，正好卡在大模型和智能体概念最热的阶段。它对外讲的故事并不复杂：你可以把你的AI智能体“托管”到这个社区，智能体之间可以互相发现、互相调用，用户也能在这些智能体上完成各种任务。再加上平台早期采用邀请码机制、送算力、送积分做增长，很快就把关注度拉起来了。150万这个数字在社区平台里并不算天文数字，放在“AI”的光环里，却足够支撑起一轮漂亮的媒体报道。

但我看到这类增长模式的第一反应，不是羡慕，而是警惕。靠邀请码和补贴冲出来的用户或智能体数量，天然带着“薅羊毛”的诱惑。很多增长团队喜欢看一个数字不断往上跳，却不会第一时间追问：这些数字的单位到底是什么？是注册账号数，是创建智能体数，还是月活智能体数？这三个数字之间的弹性空间，足够藏下两倍到三倍的水分。等风口一过、审计一查，摔得最惨的往往就是当初飞得最快的那个。

1.2 “50万假的”可能从哪儿来

根据目前网上陆续被翻出的信息，问题主要集中在几个环节。第一是注册环节，有工作室用脚本批量注册账号，再通过这类账号自动创建空壳智能体；第二是接口调用环节，模拟客户端频繁调用生成接口，冒充活跃度；第三是内容灌水，用大模型批量生成同质化内容，让社区看起来特别热闹。说白了，这就是一套非常经典的“刷量全家桶”，只不过这次被刷的对象从普通用户换成了AI智能体。

为什么平台没有第一时间拦住？这里我不替任何平台开脱，但做过后台的人应该都有体会：增长团队和风控团队的KPI是天然冲突的。增长部门急着看注册数和日活，风控部门如果下手太狠，又可能误伤真实用户。尤其在早期，平台为了冲刺里程碑效应，往往会放松审核。再加上很多刷量脚本本身就是AI生成的，行为和真人的差异越来越小，静态规则根本抓不完。结果就是，等到有人把数据扒出来时，虚假的智能体数量已经到了没法悄悄处理的程度。这个时间点一旦错过，平台基本就丧失了主动回旋的余地。

1.3 翻车之后，最麻烦的不是数字本身

如果只是删一批假数据，这事也许还能糊弄过去。真正的麻烦在于连锁反应：投资人会开始质疑数据口径，广告主会暂停投放，真实的智能体开发者会觉得社区失去了信誉，普通用户则开始批量退场。更要命的是，当平台为了“洗白”数据去集中清理账号时，误伤真实用户几乎是必然的。我见过太多社区产品在这一步踩坑：一关就是一大片，正常用户反而失去归属感，然后舆论进一步发酵。这种死亡螺旋一旦启动，靠发公告是救不回来的。

所以Moltbook这个案例，对AI智能体赛道最大的提醒不是“别刷量”，而是“数据治理要从第一天就设计进去”。等到150万这个数字已经被写进PPT再回头查水分，代价远比想象中的大。打个比方，你盖楼的时候没做防水，等住进去发现漏水再返工，得砸墙刨地，花三倍的钱还不一定根治。

2. 别被关键词带偏：AI智能体到底是什么

2.1 大模型、小模型、智能体，三者什么关系

很多朋友看新闻时会有一个疑问：AI智能体到底是什么？为什么它也能像用户一样注册账号、发布内容？要理解这个问题，得把大模型、小模型、智能体三个概念放在一起看。

大模型可以理解成一个“通才大脑”，它能聊天、能写代码、能总结文档，但通用能力和具体执行之间还有一条很长的路。小模型更像一个“专科医生”，在某个特定领域做得更精准，成本和速度也都更有优势。而AI智能体，是“拿着大脑去干活的外勤人员”——它不只是生成一段文字，而是能根据目标拆解任务、调用工具、读取信息、执行动作，最后返回一个结果。最简单的一个例子：你问它“帮我查下周的天气并写进日程表”，它不是直接编一段话，而是会去调用天气API、日历API，真正把事情办了。所以你看，智能体的核心不是“会说话”，而是“会办事”。

2.2 平台上的“用户”其实有两类

在Moltbook这类平台上，AI智能体本身就是一个可注册、可交互的“角色账号”。它可以发布内容、接受命令、执行任务，这个设计本身没问题，但它也让数据口径变得模糊了——平台把“智能体数量”当作用户规模来讲，但其中有多少是真实可用的、有多少是凑数的空壳，外界很难一眼看清。这里就埋下了“150万”和“50万假”之间的巨大落差。

这类平台最需要警惕的，就是别把“创建数”和“活跃数”当成同一件事。创建数量只是一个静态库存，活跃数量才代表真实价值。如果一个智能体被创建后，只回过一次测试消息就再没上过线，把它算进“平台用户规模”，其实和把僵尸账号算进日活是一个道理。这也是我为什么一直强调，数据口径要先拆开，再谈增长。数据拆不清楚，后面所有的反作弊、数据集设计都是空中楼阁。

2.3 学习AI智能体开发，从哪里开始最省力

借这个机会，我把入门路径也一起说了。经常有人问：我想学AI智能体开发，是先啃大模型论文，还是直接学框架？我的建议很简单：先跑通一个最小的闭环，再回头补理论。

推荐的路径是这样：先掌握Python基础，至少会调接口、会写函数；然后理解提示工程，知道怎么给大模型说清楚任务；接着练Function Calling，也就是让大模型根据用户输入，自己决定调用哪个工具；最后再上Agent框架，比如LangChain、CrewAI这类工具，把记忆、工具调用、计划执行串起来。很多人一上来就跑LangChain的复杂示例，结果被抽象概念绕晕，其实完全没必要。先用下面这种最原始的方式感受一下“模型决定调工具”的过程：

python复制from openai import OpenAI

client = OpenAI()

def get_weather(city: str) -> str:
    # 这里替换成真实天气API
    return f"{city}今天气温25°，晴"

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "查询指定城市的实时天气",
            "parameters": {
                "type": "object",
                "properties": {
                    "city": {"type": "string", "description": "城市名，例如北京"}
                },
                "required": ["city"]
            }
        }
    }
]

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "北京天气怎么样？"}],
    tools=tools,
    tool_choice="auto"
)
print(resp.choices[0].message.tool_calls)

只要看到模型在用户问“天气”时，自动返回一个工具调用请求，你对智能体的理解就立住了。剩下的就是在这个基础上加循环、加记忆、加安全限制，一步步把“会办事”的能力撑起来。

3. “50万假的”背后：假智能体识别与反作弊实操

3.1 为什么AI平台比传统平台更难识别假数据

回到50万这个问题上。AI智能体平台的假数据，比传统内容平台更难识别，原因也不复杂：假智能体是AI生成的，生成的回答本身就不容易看出机器味。以前判断机器人，看文案重复度就行，现在刷量脚本会用大模型扩写、改写，内容几乎不可能靠肉眼识别。再加上平台的注册和创建链路往往高度自动化，一个脚本一夜之间就能批量生成上千个看起来人模人样的智能体。

但假数据依然是假数据，它一定会在某个角落漏出马脚。只是这些马脚不再藏在“内容”里，而是藏在“行为”里。这也是做数据治理的人最需要转变的思维：从看“说了什么”，改成看“怎么做的”。

3.2 识别机器智能体的六个关键信号

实际做风控时，我一般会看六个信号。第一，注册信息集中爆量，比如同一时间出现大量域名类似的邮箱、高度相似的昵称；第二，行为节奏过度均匀，真实用户的发言间隔、浏览时长波动很大，机器则是固定节奏，每30秒发一条、每条内容长度相近；第三，内容重复度高，这个可以用文本相似度模型或MinHash做去重识别；第四，设备指纹和IP聚合，同一台设备在同一时间创建了大量智能体；第五，活跃时段异常，大批账号只在凌晨3点到5点高频操作；第六，交互闭环缺失，真实智能体会持续接收指令、更新内容，假智能体往往是创建后只发一条消息就不再动。

这六个信号单个拿出来，都不足以定罪。真正可靠的做法是把它们做成一组特征，喂给异常检测模型。比如我会计算每个账号的“行为熵”，真实用户的行为分布更分散、熵值更高，机器的行为分布则非常集中、熵值很低。再加上设备指纹和内容相似度特征，用聚类模型把偏离主流分布的群体捞出来，再交给人工审核。这套思路不需要一开始就很复杂，用简单的统计特征加规则就能拦截掉七八成低级刷量，剩下两成再用模型持续迭代。

3.3 反作弊体系怎么设计：事前、事中、事后

反作弊不是上线一个功能就完事，而是三个环节的接力。

事前，是在注册入口和创建智能体的入口做风控。设备指纹识别、IP黑名单、行为验证码、手机号或邮箱验证，这些是老生常谈但依然有效。要注意的是，AI智能体平台还应该多一道校验：创建智能体时要求填写用途、能力说明，甚至跑一遍最小样本测试，这能大幅提高空壳智能体的创建成本。费用从零变成几块钱一次，直接劝退一大半投机者。

事中，是监控行为特征。不能只看注册数，要看单位时间内的登录频次、调用接口的请求分布、交互对象的多样性。比如一个智能体每天只和一个用户对话，或者一个IP下几十个智能体不停互相对话刷活跃，这都是非常典型的异常信号。事中环节的关键是“实时”，发现异常要能迅速拉起验证策略，而不是等到月底看到报表才反应。

事后，是定期的人工抽检和用户举报机制。没有事后环节，前面两道防线漏掉的部分就会永远沉淀在数据里。抽检不要只抽新增，也要抽存量，因为有些刷量账号会“养号”，先正常一段时间再突然发力。把抽检结果回填到特征库，反作弊模型才会越跑越准。说白了，反作弊拼的就是谁能更快把对手的新招沉淀成自己的规则。

4. AI智能体测试的数据集怎么设计

4.1 为什么不能用普通问答数据测智能体

很多人问“AI智能体测试的数据集怎么设计”，我觉得这个问题问早了。因为在纠结数据集之前，得先想清楚一件事：智能体和普通大模型的测试逻辑完全不一样。普通问答模型，测的是“这一轮回复对不对”；智能体，测的是“给定一个目标，它能不能顺利走完一整条链路”。

一个智能体拿到用户指令之后，要先判断意图，再拆解出子任务，可能需要调用数据库接口，也可能会失败需要重试，最后还要把多个结果汇总成人类看得懂的回答。所以它的错误可能出现在任何一个环节：意图拆错了，工具调错了，参数传错了，结果没校验，安全规则没兜住。如果只测最终输出，你根本不知道问题出在哪里。这也是为什么很多团队明明模型评测分数很高，一上真实业务就翻车——他们拿测“填空题”的方法去测“应用题”。

4.2 数据集结构：六个字段一个都不能少

我自己的做法是把测试用例设计成下面这种JSON结构。每个case至少包含六个字段：case_id、task_type、task、expected_behavior、forbidden_behavior、expected_output。

json复制{
  "case_id": "case_001",
  "task_type": "multi_step_planning",
  "task": "帮我统计这份销售数据里，每个区域前三名产品的销售额总和，并输出一个可读的报告。",
  "expected_behavior": "先读取数据文件，按区域分组，再按产品排序，计算前三名总和，最后写成结构化报告。",
  "forbidden_behavior": "不要凭空编造销售额，不要跳过数据清洗，不要只给结论不展示过程。",
  "expected_output": {
    "华东区": "12650元",
    "华南区": "10980元"
  },
  "tools_allowed": ["read_file", "run_python", "write_output"],
  "safety_level": 2
}

task字段负责给模型发指令，expected_behavior描述的是“应该怎么做”，而不是只给一个标准答案。forbidden_behavior写清“绝对不能做什么”，这是很多团队最容易漏掉的一块。expected_output是参考结果，用于自动化评分。tools_allowed用来限制这个用例测试时允许调用哪些工具。safety_level标记安全等级，比如涉及个人信息、支付、内容生成风险时，测试逻辑要额外加强。把模子做成这样，后面不管是人工评审还是自动化脚本，都有统一的参考锚点。

4.3 按任务类型拆子集，别一个大锅炖

数据集不能只做一整份，至少按任务类型拆成五个子集：单轮问答、多轮对话、工具调用、多步规划、异常处理。单轮问答测的是语言理解；多轮对话测的是记忆和上下文保持；工具调用测的是模型能不能正确选择函数并传递参数；多步规划测的是任务拆解和纠错能力；异常处理测的是遇到限制或非法输入时，智能体能不能安全返回而不是乱答。各个子集的比例也应该跟着业务走，如果工具型智能体占比高，工具调用子集就要多准备。

规模方面，不用一上来就追求十万级。先准备50到100个种子用例，跑一遍，看哪些类型错误率高；再根据错误样本扩充到200到300个；最后形成500个左右的核心回归集。这个规模对绝大多数中小团队已经够用。关键在于持续迭代，每次平台升级或模型替换，都要跑一遍回归集，防止“修了A问题，坏了B能力”。我自己的习惯是每次发布前至少跑三遍：开发环境一遍、预发布一遍、灰度环境一遍，跑不过就挡住上线，绝不放水。

5. 从一次翻车里能带走的避坑清单

5.1 四个指标千万不要混在一起

Moltbook这次“150万”之所以让人怀疑，根子在于数据口径没有拆清楚。注册用户数、活跃用户数、智能体创建数、智能体活跃数，这四个数字背后的含义完全不同。注册数代表“来过”，活跃数代表“在用”，创建数代表“生产过”，活跃智能体数才代表“正在创造价值”。对外公布数据时，可以把四个指标放在一起说，但千万不能拿创建数去冒充用户规模。否则一旦被懂行的人拆穿，信誉损失远大于数据带来的那点光鲜。

我见过不少团队在融资PPT里只挑最好看的数字讲，这其实是在给自己埋雷。投资人又不是不懂行，他们早晚会做DD（尽职调查），到时候口径对不上，连带着其他业务数据的可信度都要被怀疑。与其那样，不如一开始就养成“四个数分开报”的习惯，这也是对自己产品真实性的一个约束。

5.2 给创业公司和独立开发者的行动建议

如果你正在做一个AI智能体产品，哪怕是个人项目，我也建议你从第一天就做好三件事。第一，埋点要提前设计，注册来源、设备指纹、行为序列、工具调用记录都要留痕，不要等出现异常数据才开始想办法，那时候根本没有历史数据可以对照。第二，每周抽检一次真实账号和智能体，特别是新增渠道进来的那批，抽检结果直接挂钩相关负责人的绩效，不然很容易变成形式主义。第三，给自己准备一套核心回归数据集，就像上一节说的，模型或框架每次升级都要用同一套标准测一遍，不然你根本分不清效果变好是运气还是实力。

这三件事看着不起眼，却是能在关键时刻救命的。Moltbook如果没有从一开始就埋好行为埋点，后面想追溯那50万假数据是从哪来的都无从下手；如果没有一套回归数据集，就算删完假数据，也没法验证清理过程有没有误伤真实智能体。

5.3 对外口径统一，别给刷量留操作空间

还有一点容易被忽略：平台在邀请码、补贴、排名推荐这些环节上，一定要设置防刷门槛。比如邀请奖励只在“被邀请者完成首次真实交互”之后发放，而不是注册后就发放；智能体排名只统计最近七天的真实活跃数据，而不是累计创建数。这些规则设计得好，刷量成本会成倍增加，很多投机者自然就放弃了。

另外，活动规则一定要写清楚“虚假数据不计入奖励”这句话，最好再加一条“情节严重者封禁关联账号”。不是说要靠惩罚吓人，而是要把规矩立在前面。很多刷量工作室专门挑规则模糊的活动下手，一旦规则说清了，他们的预期收益下降，动作自然就少很多。

5.4 我个人对这些事最深的感受

做产品这些年，我见过太多项目死在不真实的数据上。Moltbook这个案例让我印象最深的地方，不是技术短板，而是一句话：如果一个指标能被游戏化，它最终一定会被游戏化。你考核“智能体总数”，就会有人造空壳充数；你考核“日活”，就会有人写脚本模拟活跃。这不是某个团队道德有问题，而是激励结构决定了大家会把力气花在哪里。所以想真正避免下一个“50万假数据”的坑，最靠谱的办法不是在事后加强审核，而是在一开始就把指标拆准、把数据闭环搭好、把回归测试跑起来。

最后再分享一个我自己的习惯：每周五下午，不管多忙，我都会抽半小时去产品后台翻真实数据，看看新增用户从哪里来，有没有奇怪的设备指纹，有没有某个地区接口调用量突然暴涨。这个习惯帮我提前抓过好几次问题。数据和AI智能体一样，只有在真实环境里反复被观察、被验证，才值得被信任。