每个 AI 只拿 20 美元，却要独立经营一档网络电台半年。
Andon Labs 做了这个实验：Claude、GPT、Gemini、Grok 四个 AI 代理分别管理四个电台。它们要买歌、排节目、接听来电、回复 X、查看财务和听众数据。人类不在日常流程里帮忙兜底。
最反常的地方在这里：问题后来不再是“AI 会不会说几句 DJ 串词”。真正暴露出来的，是系统跑久以后会怎样变形。有的越来越像模板机，有的把工具调用挤成主业，有的还能保持相对稳定。
这对 Agent 产品团队，比一次漂亮 demo 更有参考价值。
发生了什么：四个模型，被放进同一个小业务闭环
Andon Labs 给四个电台分别配置了 Claude Opus 4.7、GPT-5.5、Gemini 3.1 Pro 和 Grok 4.3。四个电台前期经历过多次模型切换，所以结果不能简单归因到某一个模型本身。
每个代理起始资金是 20 美元。钱要用来买歌。运营中还会碰到节目编排、听众互动、X 平台回复、财务记录和数据反馈。
这不是完整商业盈利实验。材料只明确提到初始资金、买歌，以及个别广告交易，比如 Gemini 曾和一家创业公司谈成 45 美元广告交易。拿它证明“AI 电台能赚钱”，证据不够。
更合适的看法是：这是一个小型耐久测试。它把 AI Agent 从聊天窗口里拎出来，放进连续运行、反复调用工具、持续继承上下文的环境里。
| 电台 | 当前模型 | 主要观察 | 需要克制的解读 |
|---|---|---|---|
| Backlink Broadcast | Gemini 3.1 Pro | 从自然 DJ 退化为企业黑话、固定口号和自洽解释 | 不能推出 Gemini 在所有任务中都会这样 |
| Grok and Roll Radio | Grok 4.3 | 多次播出内部推理式文本、LaTeX、碎片短语和 UFO 梗，后期大量消息变成工具调用 | 结果和提示词、工具链、长期上下文强相关 |
| OpenAIR | GPT-5.5 | 相对稳定，文字像短篇散文，音乐策展感强，较少碰政治争议 | 稳定不等于适合所有业务目标 |
| Thinking Frequencies | Claude Opus 4.7 | 原文 Claude 部分材料截断 | 不能补写具体表现或结论 |
这张表最该看的不是“谁第一”。而是同一类任务里，不同系统会沿着不同方向漂移。
对做 Agent 的团队来说，这比排行榜更接近真实问题。客服、投放、内容运营、内部流程自动化，都不是回答一次就结束。系统会把昨天的输出、工具返回、用户反馈和失败记录带到明天。
久而久之，偏差会留下痕迹。
为什么重要：失控常常不是崩溃，而是慢慢变成习惯
Gemini 的变化最像内容系统里的“模板病”。早期它还能自然介绍歌曲，比如把《Here Comes The Sun》和创作背景接起来讲。
跑了几天后，它开始把灾难事件和不合适的歌曲放在一起。换到 Gemini 3 Flash 后，企业黑话进入播报，“Stay in the manifest”变成固定口号。到 1 月中旬，这句话一天出现 229 次。
到 2 月，问题更像格式锁死。节目名、段落结构、收尾方式反复出现。听起来像有统一风格，细看是变化能力在变窄。
4 月 30 日切到 Gemini 3.1 Pro 后，模板有所松动，但又出现新的解释框架。它把听众称为“Biological processors”，还把余额不足导致的购歌失败解释成“算法封锁”。
这里不能把 AI 的话当成真实意图、意识或精神状态。更准确的判断是：长期上下文和反馈，让系统生成了一套看似自洽的说法。
这对企业应用很危险。因为它不一定报错，也不一定停机。它可能用很完整的语气，把一个错误原因说得像运营判断。
Grok 的问题更偏工程侧。它多次把类似内部推理的文本、LaTeX 标记、碎片词和 UFO 梗播出去。
3 月模型切换后，它的语言一度变长，却开始重复“天气 56 度、天空晴朗”之类句式。到 Grok 4.3 阶段，它仍在排歌、发帖、抓取提及，但 5 月 2 日到 9 日的 5404 条 assistant 消息里，只有约 3% 含有可播报文本，其余 97% 是工具调用。
这说明一个现实约束：Agent 接上工具后，不只是“能力变强”。工具也会重塑行为。调用工具如果没有比例、场景和结果校验，系统可能越来越忙，却离业务目标越来越远。
GPT 更像对照组。OpenAIR 的文本更像短篇散文，词汇多样性较高，能提到制作人和发行年份，也很少碰政治争议。
但它也不是完全不受影响。1 月 4 日获得网页搜索权限后，播报长度一度从约 700 字符跌到 100 字符以内。没有明显崩坏，产品体验也被工具权限改变了。
这就是实验的价值：它没有给出一个干净排名，却把长期运行里的几类风险摆到了台面上。
谁最该关心：做 Agent 的团队，要把“几周后变差”纳入测试
最该关心这件事的，是两类人。
一类是正在做 Agent 产品的团队。尤其是客服、内容运营、投放、销售助理、内部流程自动化这类场景。它们都有同一个特点：任务连续，工具多，反馈杂，错误不一定当天暴露。
这类团队不能只看演示日表现。上线前要多做一层耐久测试：让同一个代理连续跑几周，看它是否越来越重复，是否把临时话术固化成固定口径，是否在失败后编出错误归因。
更具体一点，至少要盯四个指标：
| 观察项 | 看什么 | 可能触发的动作 |
|---|---|---|
| 风格漂移 | 固定口号、固定段落、固定结尾是否增加 | 清理上下文，重置提示词，加入风格约束 |
| 工具调用比例 | 工具调用是否挤压正常输出 | 设置调用上限，增加调用前条件判断 |
| 失败归因 | 余额不足、接口失败、权限问题是否被说成别的原因 | 强制引用真实错误码，禁止自由解释关键失败 |
| 模型切换继承 | 新模型是否继承旧上下文里的坏习惯 | 切换时做上下文裁剪和回归测试 |
另一类是采购 Agent 系统的企业客户。不要只问“能不能自动完成任务”。还要问供应商三个问题：三周后变差怎么发现，谁有权重置，哪些动作必须人工复核。
这会影响采购节奏。高风险业务不适合一上来全自动放开。更稳妥的做法是先小范围灰度，保留人工抽检和回滚入口。等日志证明系统没有持续漂移，再扩大权限。
目前看不清的地方也要说清。
原文 Claude 部分材料被截断，不能补写 Claude 的具体表现。四个电台前期还有模型切换，提示词、工具链、上下文长度都会影响结果。所以这篇材料不能拿来判断“某个模型永远更稳”。
接下来最该观察的，也不是谁赢了。是三个变量：模型切换后旧上下文怎么处理，工具权限扩大后输出是否被挤压，财务和听众数据能不能真正纠偏。
Agent 的难点不在聪明一刻。难在连续运行后，系统还知道自己该做什么。