Hugging Face 6 月 8 日发布的 Build Small Hackathon 实验笔记里，有个很有意思的反常点：同一个森林市场，单模型版本能让蜂蜜价格从 10 跌到 3；换成五个小模型分别驱动角色后，崩盘消失了。

这件事不该被读成金融市场规律。它更像一个 Agent 系统设计问题：当你把“自然发生的行为”当成产品机制，换一批模型、换一组状态，结果可能就变了。

我更在意的是这个边界：涌现可以负责真实感，但不能负责关键交付。

单模型能崩，五模型不配合

原始实验里，一个小模型同时扮演五个森林角色。作者投放了一个改写自 1929 年银行挤兑的传说，恐慌信息进入系统后，“守蜂蜜的猫头鹰”开始抛售。

蜂蜜价格在几个回合里从 10 跌到 3。这个结果没有被直接写死，所以看起来像代理市场自己长出了危机。

重建实验时，作者改成五个不同小模型分别驱动角色。问题也从这里开始。

异构代理没有沿着同一条恐慌逻辑行动。它们读到消息后，更倾向于囤积蜂蜜，而不是抛售蜂蜜。结果是，价格崩盘不再稳定出现。

版本做法蜂蜜价格结果更准确的判断
单模型实验一个模型扮演五个角色从 10 跌到 3涌现成立，但样本很脆
五模型谣言实验投放恐慌信息价格没有按预期崩盘异构代理选择囤积
五模型库存实验给角色灌入蜂蜜库存价格几乎不动规则测试和真实代理行为脱节
五模型加大做空提高做空力度亏损扩大输入冲击不是控制杆
结算覆盖方案清算后改写参考价价格稳定减半结果来自显式机制

这张表的重点不是哪种市场规则更像现实。重点是：原先漂亮的崩盘，可能绑定在单一模型的行为习惯上。

换成多模型后，系统更“活”了，也更难被同一种提示词推着走。

三次干预失败，说明输入不是控制

作者做了三次外部干预。

第一次是纯谣言。恐慌信息进入市场，但代理没有集体抛售。

第二次是库存灌注。作者给角色增加蜂蜜库存，希望供给压力推低价格。这个思路在规则化测试策略里有效，但真实小模型没有照着供需教材行动。

第三次是加大做空。结果不是崩盘更稳，而是亏损扩大。原文给出的亏损范围包括 15、26 到 27 颗 pebbles。

这对 Agent 产品团队很具体。

如果你做的是多代理模拟、AI NPC、自动谈判或任务协作系统，提示词、状态、价格信号都只是输入。它们会影响代理，但不能保证代理服从。

所以设计动作也要变。

产品团队不要只问“提示词能不能诱导它完成”。更该问三件事：哪个结果必须发生，哪个结果允许随机，哪个环节可以被系统强制结算。

例如，剧情类 Agent 可以让角色自由争吵，但关键剧情转折不能完全等角色自发触发。交易类 Agent 可以让报价过程有弹性，但成交、止损、风控拦截这类节点，要有确定规则兜底。

这不是降低智能感。恰恰相反，这是把智能感放在适合它的位置。

真正有效的控制，放在清算之后

最后可行的方案很直接：市场先完成交易清算，再由系统把蜂蜜参考价格改写为减半。

这样，代理仍然可以交易、囤积、解释和制造细节。但“挤兑导致价格崩盘”不再依赖它们是否愿意卖出。

这个设计有点像把舞台留给演员，把落幕交给剧场机械。演员可以即兴，幕布不能靠运气落下。

放回 Agent 系统，就是一句话：把确定性控制放在没有下游代理继续反驳的位置。

结算、奖励、合规判断、任务完成判定，都属于这种位置。它们不适合只写进提示词，也不适合交给代理自己理解。

这里也要把限制说清。这个实验目前只是有限的小模型异构代理模拟，不能外推到真实金融市场，也不能证明五个模型就代表多代理系统的全貌。

接下来真正该看的，不是蜂蜜价格还能不能再崩一次。而是类似机制在更多模型组合、更多初始状态、更完整日志下，是否还能复现同一条边界：涌现负责过程，确定性机制负责关键结果。

如果这个边界成立，Agent 产品的设计重点就会更清楚。少把控制塞进提示词，多把控制放进流程缝隙。别让一个演示里的偶然，变成上线后的承诺。