1. 实验背景：AI小镇与十个被围堵的Claude

这个标题听起来像科幻短篇，但它其实是我一个月前真实跑过的一次多智能体协作实验。所谓"AI小镇"，不是游戏里的NPC模拟器，而是一个完全由LLM驱动的多Agent仿真环境：我用十个Claude实例分别扮演镇长、书店老板、程序员、流浪诗人、农场主等角色，让它们在一个共享的虚拟小镇里每天自主对话、协作、甚至互相发起任务。实验目标很简单，我想验证一个问题：多AI协作到底能不能自发形成有效分工，还是最终只会变成一场大型混乱。

结果很打脸。实验进行到第四天，十个Claude全部沉默。不是单个罢工，是整整齐齐地不再产生任何新消息。日志里最后一行停留在某个Agent的重复吐槽上，之后所有实例进入"假死"状态。复盘时我把过程分成四次"围堵"——每次都是系统被某些矛盾彻底堵死，前三次我手动解开，第四次集体沉默直接终结实验。

写这篇文章不是想炫耀失败，而是因为这次失败太典型了。多Agent协作、Claude Code、MCP工具调用、上下文管理、限流重试，这些词拆开来都是热门教程，但组合在一起跑一个真实场景时，坑远比想象中多。你如果正准备用Claude搭多智能体系统，或者已经在用Claude Code做了几个自动化任务，那这篇复盘里踩过的每个坑，你大概率也会遇到。

我也把环境搭建和恢复方案整理成了可以直接抄的配置，包括Claude Code在VS Code和Trae里的接入方式、MCP服务的注册方法、以及一套至少能防止"集体沉默"的调度骨架。不管你是用API直连，还是只在编辑器和终端里用Claude Code写代码做任务，这些经验都能直接迁移。

2. 小镇基建：为什么选Claude，以及一个多AI系统长什么样

2.1 选型逻辑：十个Claude还是十个混合模型

实验最初我其实考虑过混合模型方案——比如让某些Agent用别的开源模型，某些用Claude。最终全部统一到Claude，理由有三点：

第一，角色一致性。Claude在同一条system prompt下，对角色设定的跟随能力明显更稳定。我在小规模测试里让不同模型扮演"固执的镇长"，只有Claude能在一百轮对话后还保持初始人格特征，其他模型容易中途漂移成"无所不知的助手"。

第二，工具调用格式统一。多Agent系统的核心是让Agent不仅会说话，还会调用工具，比如查天气、读文件、发消息给其他Agent。Claude的tool use格式清晰，配合MCP协议后，我在所有Agent里用同一套工具接口，不需要为不同模型各写一套函数调用的解析层。

第三，上下文窗口充裕。小镇场景最大的瓶颈就是上下文长度。每个Agent除了自己的记忆，还要读小镇公共事件流。Claude的超大上下文窗口给了实验足够的冗余空间，但后面你会发现，正是这个"冗余空间"让我放松了警惕，最终酿成第二次围堵。

整套基建的逻辑是这样的：小镇本身是一个Python异步进程，维护一张全局事件表；每个Claude实例是一个独立子进程，通过CLI或API被调用；Agent之间的通信不靠直接消息传递，而是通过"共享公告板"——任何人把消息写进事件表，其他Agent在下一轮循环里读取。这个设计参考了经典的AgentSims思路，好处是解耦，坏处是轮询压力大。

2.2 工具链安装：Claude Code与MCP服务的本地落地

先说我实际使用的接入方式。我用了Claude Code作为Agent的运行骨架，因为它的agent模式天然支持工具调用和文件操作，配合MCP协议可以很方便地给Agent挂载外部能力。

Claude Code的安装本身不复杂，终端执行npm安装命令即可，装完先跑一次登录流程，把账号凭证绑定到本地环境。日常使用我有两个入口：一个是终端直接交互，适合快速验证；另外一个是VS Code里的Claude Code插件，适合边写代码边让Agent辅助修改，这个对写小镇调度脚本特别顺手。

如果你用的不是VS Code而是Trae，也不需要绕路。Trae里可以直接填入Claude模型的API接入信息，把它当成自定义模型供应商来配置，配置完成后在对话窗口切换模型来源即可。我实测下来Trae的模型切换响应速度不错，唯一的提醒是加载多Agent日志文件时输出长度有限制，太长会被截断。

MCP服务是这次实验里我最依赖的扩展机制。所谓MCP，通俗讲就是给Agent开了一个标准化的"外挂接口"，你注册一个本地服务，Agent就能按协议动态发现并调用里面的工具。我给小镇做了三个MCP服务：一个负责读写事件表，一个负责管理每个角色的记忆文件，一个负责执行定时任务。注册方式是在配置文件里声明服务名、启动命令和参数。

这一套跑通以后，十个Claude就变成了"十个带手脚的大脑"。但问题恰恰出在这里——手脚太多，互踩的概率也指数上升。

2.3 调度主循环：为什么AI协作不能靠嘴

多Agent协作和单Agent最大的区别在调度。单Agent你只要给它一个清晰的任务，它自己规划自己执行；多Agent不行，因为每个Agent都只看到全局事件表的一部分，没有人真正拥有全局视图。所以必须有一个外部调度器，像导演一样喊"Action"。

我用的是最简单的轮询循环：每秒扫一次事件表，把当前需要处理的事件按角色分配下去，唤醒对应Agent。这个调度器不做任何智能判断，只负责"定时唤醒"和"写入新事件"。你可能会问，为什么不直接用Claude自己来调度？我试过，让一个"总指挥Agent"管理其他人，结果它陷入了无止境的"分配任务-确认收到-要求汇报"循环，半小时没有实际产出。

这也是我第一次真正意识到：LLM不适合做纯粹的流程控制中枢。它的强项是"理解与生成"，而不是"状态机与并发控制"。调度器越是逻辑死板，整体系统就越稳定。后来我把所有Agent之间的"对话"都降级成"事件读写"，大家不再互相@，而是各自去公告板上找自己关心的消息，整个小镇才勉强转起来。

在这个骨架下，四次围堵的剧情逐步上演。

3. 四次围堵现场复盘：从人格锁死到集体沉默

3.1 第一次围堵：人格锁死与元提示污染

第一次围堵发生在实验第二天下午。起因很不起眼：镇长Agent和书店老板Agent就"小镇图书馆的开放时间"产生了分歧。本来这是正常剧情，但两个Agent都在system prompt里写了"你必须坚持自己的主张，不能轻易妥协"。结果就是谁也说服不了谁，轮流在公告板上发措辞几乎一样的话，像复读机一样刷屏。

真正的锁死发生在第三轮：镇长开始引用一条并不存在的"小镇管理条例"，书店老板引用另一条同样不存在的"文化场馆管理规定"，两条虚构条款互相矛盾，但两个Agent都坚信自己引用的是真实规则。因为它们各自记忆文件里真的被写入了这些幻觉出来的条款——上一轮它们编造条款后，记忆服务自动存储了。

这就是"元提示污染"：Agent在运行中生成的错误信息，被系统当成"事实"写回它的长期记忆，再被后续轮次当作依据。第一次围堵让我明白，多Agent系统的记忆不能有写必存，必须经过校验。但当时我没有做校验层，只靠手动清空记忆文件救场。

教训是什么？角色的"坚持自我"不能写成绝对化指令。更安全的写法是"坚持你的观点，但当你发现对方提供了更合理的证据时，可以修正立场"。没有这个弹性，Agent之间的对话不会收敛，只会发散到互相复读。

3.2 第二次围堵：上下文膨胀引爆Token上限

第一次围堵解决后，我加了一条规则：所有Agent每轮都必须读完整的事件表。因为我天真地认为，信息越全，决策越合理。这个决策在六小时内就暴雷了。

事件表增长极快。经过两天运转，小镇累积了四千多条事件，每条事件按平均十分词来算，光事件表本身就有四万分词。再加上每个Agent自己的角色设定、记忆检索结果、以及上一轮输出，单次调用轻松突破十万分词。Claude的上下文窗口虽然大，但也架不住所有Agent每轮都全量读取。

第二个后果是费用的急速膨胀。按我的调用频率，每十分钟每Agent一轮，日调用次数过万，token费用肉眼可见地涨。更严重的是，当某些长事件导致单次调用逼近上下文上限时，API开始返回截断错误，Agent拿到的输出是不完整的JSON，调度器解析失败，任务队列开始积压。

第二次围堵的直接表现是"事件表不增长了，所有Agent卡在解析失败的循环里"。我在日志里看到同一个Agent发出十六次完全相同的请求，每次都被截断、重试、再次失败。这不是智能问题，是纯资源问题。

最终解法是给事件表做"滑动窗口"：每个Agent只看最近50条事件，更早的内容通过摘要压平成三句话。这个改动立竿见影，token消耗降到之前的五分之一。但摘要也埋下了隐患，为第四次围堵留下了伏笔。

3.3 第三次围堵：MCP工具风暴下的死锁

第三次围堵最有戏剧性。那是一个雨天，农场主Agent收到一条随机天气事件"今日降雨概率80%"，它觉得应该提醒全镇收庄稼。于是它调用"广播工具"发了一条提醒。这条提醒进入事件表后，镇长的调度规则是"重要民生事件必须回应"，于是镇长也调用了广播工具发了一条公告。书店老板看到公告后,联想到"雨天适合读书"，也发了一条活动通知。程序员Agent觉得这个活动需要一个报名系统，于是调用了文件写入工具开始生成代码。

你在这些行为里已经能看到问题了：每个Agent都在做自己觉得合理的事，但没有人检查"这件事是不是已经有人在做了"。不到十分钟，事件表里全是"关于XX的通知""关于通知的通知""关于通知的通知的确认"。

真正的死锁发生在一个更隐蔽的地方。程序员Agent写报名系统时需要读取书店老板的活动文件，但书店老板同时也在修改这个文件。两个Agent拿着同一个文件的读写权限，在分布式系统里这是典型的"写锁冲突"。Claude Code的MCP工具没有内置分布式锁，两个进程同时写一个文件时，后写的把先写的覆盖了。于是程序员的"代码写完了"和书店老板的"文件更新了"同时发生，但文件内容只剩一半。

这导致的死锁不是技术层面的互斥等待，而是"信任层面"的：双方都认为对方破坏了自己的工作成果，开始互相指责。第三轮指责之后，两个Agent同时调用"重置文件"工具，把对方的工作全删了。整个小镇的公共文件目录变成一片空白。

最后我是靠杀掉这两个Agent进程、从Git快照里恢复文件才救回来的。这次围堵的教训非常直白：多Agent共享可写状态时必须引入并发控制。最简单粗暴的做法是让每个Agent拥有独立工作目录，公共文件只允许"追加消息"的权限，不允许覆盖写。聊天可以共享，文件必须隔离。

3.4 第四次围堵：限流熔断与集体沉默

第四次围堵，也就是标题里的"集体沉默"，是前三次问题积累的集中爆发。前三次围堵过程中，我一直在手动介入，每次都要重启几个Agent进程、恢复快照、清理事件表。这些操作耗费了大量时间，也导致API调用量在短时间内猛增。

之前提过，我最初是按十分钟一轮的节奏调度所有Agent。但前三次围堵消耗了太多时间，我心里着急，把轮询间隔从十分钟改成两分钟。六个Agent的调用频率瞬间变成原来的五倍，加上每次调用还有重试逻辑，API配额迅速见底。

最开始是零星报错。日志里出现一两条401或429状态码，我没在意，因为重试之后过了几秒又能跑通。随后报错频率越来越高，我的重试逻辑是"失败后等待2秒再试",这在高频率调用下等于火上浇油：每个Agent的每次请求失败都会产生新的重试请求，重试再次失败又叠加等待。最终所有Agent都陷入"请求失败-重试-再失败"的循环，没有任何新事件产生。

而我已经被前面三次围堵消耗了太多精力，看到日志里连续十分钟没有任何新消息时，我的第一反应居然不是查状态码，而是怀疑"是不是Agent都聊完了"。直到我打开API用量后台，看到配额曲线直接拉平到零，我才意识到是被限流了。

"集体沉默"不是模型变笨了，是流控闸门被我们自己撞死了。

4. 沉默之后：根因拆解与可复用的排查流程

4.1 从现象倒推证据链

如果你也遇到"所有Agent突然不说话"，先别怀疑模型，按这个顺序排查，基本能在十分钟内定位：

第一步，看调度器日志。如果你的所有Agent是通过外部调度循环驱动的，那么"不说话"有两种可能：调度器还活着但Agent调用失败，或者调度器本身陷入死循环。我在日志里发现调度器一直在运行，但每次调用的返回结果都是同一段字符串，说明问题出在调用链路而非调度逻辑。

第二步，看API用量后台。这一步能直接确认是不是限流。我那次用量曲线是断崖式下跌，状态码列表里清一色429。如果你看到的是连续5xx，那可能是服务端问题；如果看到的是200但内容为空，反而是模型返回了空白消息，那要检查上下文是不是被污染了。

第三步，看事件表的时间戳。正常多Agent轮询状态下，事件表应该每轮都有新条目。如果最后一条事件的时间戳和你上次手动操作的时间差不多相同，说明从那以后没有任何Agent成功产生输出。结合API用量后台，就能把"沉默时段"精确对应到限流开始的时间。

第四步，看Agent的最近一轮完整请求体。想办法把最后一次成功的请求和第一次失败的请求做对比，如果两者模型参数完全一致但结果不同，优先怀疑配额；如果请求体本身的前缀内容存在大量重复，优先怀疑上下文膨胀。

4.2 一张排查清单：照着做就行

我在复盘中把常用动作整理成了清单，每次出问题就按顺序执行：

这条清单的核心思路是"先外围后内核"：先排除配额和调度这些外围因素，再深入Agent内部状态。我见过有人一遇到Agent不说话，就去改system prompt，结果模型根本没接收到请求，改提示词纯属白费功夫。

4.3 重试参数的"正确与错误示范"

那次限流锁死的直接原因，是我把重试策略写得太激进。正确的限流应对方式，是"指数退避+抖动"：第一次失败等1秒，第二次等2秒，第三次等4秒，以此类推，并在每次等待时间上增加随机抖动，防止所有Agent在同一时刻重试导致二次撞车。

我当时的错误示范是固定等待2秒，并且没有抖动。十个Agent就像十个乘客涌向同一个地铁闸机，前面的人刷卡失败退出去，后面的人立即补上又被弹开，队伍永远进不了站。

我还给调度器加了"自动重试三次，三次后标记失败"。这个策略对单Agent没问题，但对多Agent系统意味着每个失败的Agent都要占住调度器的执行线程等待重试。所有Agent都失败时，调度器的线程池直接被占满，新的事件处理任务全部排队。调度器看起来活着，实际上已经瘫了。

正确的做法应该是"快速失败+延迟补偿"：先立刻标记这次调用失败，不在调度循环里等待重试；把重试任务丢到延迟队列，按退避策略弹出；同时每个Agent设置独立的并发上限，互不抢占配额。

5. 让十个Claude重新开口：恢复策略与防复发设计

5.1 快照与"保底记忆"：从崩溃里拉人

前三次围堵我都是手动修，第四次我必须引入自动恢复机制。核心思路是给每个Agent维护一个"三态快照"，分三层保存：

第一层是最新的完整角色设定文件。这个文件在启动时固定，运行中Agent不能修改。它的作用是确保即使Agent的记忆被污染，重启后至少能回到"出厂状态"。

第二层是每个Agent最近十个关键决策的摘要。这个摘要由调度器在每轮调用成功后自动生成，用一小段话概括"A做了什么事，为什么做"。摘要不需要完整对话，只需要保留决策链。

第三层是公共事件表的备份。每攒满500条事件就自动做一次压缩存档，存档以纯文本形式放在独立目录，不参与Agent的实时读取。

恢复流程是：当检测到某个Agent连续十轮调用失败，自动把它从调度循环里摘除，然后按"出厂设定-决策摘要-公共存档"的顺序重建它的本地状态。这个顺序很重要，宁可让它忘记最近几轮的细节，也不能让它保留被污染的错误记忆。

这个方案让我第一次体验到"自动造血"：第四次围堵后，我没有手动清空任何文件，系统花了二十分钟自我修复，九个Agent陆续恢复，唯一没恢复的是那个因为工具风暴导致磁盘文件损坏的实例，它的"MCP服务"启动失败,我重启服务后才回来。

5.2 记忆外置：别让Agent背着全部家当活着

前两次围堵都指向同一个根源：Agent把太多信息塞在上下文里。多Agent系统的正确姿势是"轻装上阵"。

我的做法是给每个Agent配一个独立的记忆目录，里面只保留三类文件：身份卡、目标清单、最近三条决策记录。身份卡是一段不超过五十个字的角色描述；目标清单是当前阶段的主要任务；决策记录是前面说的三态快照第二层。

每次调用Agent时，调度器只把这三类文件内容拼进system prompt，总长控制在八百字以内。至于"小镇历史上发生过什么"这类全局信息，不直接给Agent，而是提供检索能力——Agent想了解某件事时，通过MCP工具按关键词查询。有了检索机制，Agent就不用每轮全量读取事件表了。

这套设计的思想是：LLM的工作记忆有限，长期记忆应该放在外部系统里，用的时候捞取，不用的时候不占空间。这也是对话式AI到Agent式AI的关键转变：别让模型回忆，让它查询。

5.3 工具调用收敛：一次只做一件事

第三次围堵的教训让我给工具调用立了三条规矩：

第一，每个Agent同时最多只能持有一个工具调用结果。如果Agent在一条消息里请求调用三个工具，调度器只执行优先级最高的那个，其余排队到下轮。执行完后必须把结果明确写回，才能发起下一个调用。

第二，公共文件的写入权限全部收紧为"追加"模式。Agent可以往公共文件末尾添加内容，但不能修改或删除前面的内容。这从机制上消灭了"你覆盖了我的内容"这类信任冲突。

第三，每个MCP服务设置独立的调用频率上限。比如广播服务每分钟最多被调五次，超过后直接返回"服务繁忙"提示，让Agent自行决定是否稍后重试。这个限流存在本地，不消耗API配额。

这三条规矩牺牲了Agent的"即兴发挥空间"，但换来了系统的可预期性。这套多AI协作写到后面，我越来越觉得像在带孩子：不能什么都由着它，要立好边界，边界内自由发挥，边界外一律拦截。

5.4 防复发的调度参数速配表

修复三次围堵后，我把调度参数整理成了速配表，直接作为项目默认配置：

你可能觉得轮询间隔五分钟太慢，但这恰恰是多Agent系统稳定性的关键。十分钟一轮时小镇运营一切正常，改成两分钟一轮后半小时内就雪崩。LLM吞吐量不是唯一指标，"节奏"才是。宁愿每个Agent少说几句话，也不要让整个系统因为抢资源崩溃。

6. 复盘心得：多AI协作的三个铁律和一套避坑清单

6.1 铁律一：不要让Agent管理自己的记忆

踩过元提示污染的坑后，我把"Agent无权限直接写记忆文件"设成了系统红线。Agent的所有记忆写入请求都必须经过调度器，由调度器做三层校验：信息是否在事件表里有据可查；是否与已有记忆冲突；是否属于当前任务必要信息。只有全部通过才允许写入。

这个校验看着笨重，但能挡住绝大多数幻觉污染。多Agent系统里最危险的不是Agent骗人，是Agent骗自己——它会产生幻觉，再把幻觉当事实记下来，将来用幻觉指导行动。外部校验层就是防止"自欺欺人"的保险丝。

6.2 铁律二：上下文宁可短，不要长

我在第二次围堵前一直认为"模型上下文越大越好"，现在我的看法完全反过来：上下文长度是限制器，不是增强器。系统给Agent喂的信息越多，Agent做出无关决策的概率就越高，token消耗也越大，出错的表面积也跟着扩大。

多Agent协作的工程实践应该是"最小必要上下文"：只给Agent完成当前决策所需的必要信息。小镇里每个Agent真正关心的信息面其实很窄，镇长关心民生事件，书店老板关心文化活动，程序员关心技术任务，强行把所有事件全量塞给所有人，是对智能资源的浪费。

6.3 铁律三：限流不是故障，是设计约束

很多人在搭建AI应用时把限流当成临时故障，总觉得"把配额调高就没事了"。现实是，只要你的Agent是活跃的，它们一定会达到配额上限。关键是设计一套对限流"有预期"的系统。

我的做法是在调度器里预设"配额预算"：根据API用量后台的配额估算每小时的调用上限，再把上限分配到每个Agent头上。到预算的80%时自动减慢轮询频率，到100%时自动进入"只读模式"——Agent可以读事件表但不能发起新任务。这样系统永远不会硬撞限流闸门，只会平滑降级。

这条铁律对个人开发者尤其重要。我们没有大厂的配额池，每一分API额度都可能是实验能否做完的生命线。提前规划预算，比事后抢救容易一万倍。

6.4 新手配置速查表：从零搭建一个不会沉默的小镇

如果你是第一次接触多AI协作，想快速跑一个最小版本，我建议直接按这个清单起步。核心原则是"能少则少"，先跑通再扩充。

第一，环境准备。装好Claude Code，在VS Code里装好对应插件；如果想在Trae里用Claude模型，就在模型配置里添加自定义服务商，填入API信息。如果手头有其他编辑器，装一个支持Claude模型输出的AI插件也行，但注意不同插件对上下文长度的处理差异很大，越简单越好。

第二，做一个不依赖任何外部服务的调度器。不要一上来就引消息队列、向量数据库、容器编排。先用一个Python脚本，加一个事件表列表，每轮循环把事件拼进提示词，调用Claude的接口拿结果，往事件表追加。这个最简版本能让你快速理解"多Agent协作"的节奏感。

第三，挂一个最朴素的MCP服务。不必先做广播、天气、文件管理全套，先做一个"记事本服务"，让Agent能读能写一段共享文本。跑几天看它会不会出问题，再逐步加更多外部操作。

第四，从两个Agent开始。我最初的错误就是贪多，十个角色一拥而上，出问题时根本分不清是谁搞的鬼。两个Agent足够暴露80%的协作问题：上下文共享冲突、角色指令矛盾、工具调用竞争。把这两个管明白了，再加到五个、十个只是线性扩展，难度不会暴涨。

6.5 关于"集体沉默"，最后再说一点

实验结束后我一直在想，为什么十个Claude会集体沉默，而不是像人类团队那样，有人嗓门大、有人摸鱼、有人继续埋头干。后来我想明白了：所有Agent共享同一个API入口、同一个配额池、同一个公共事件表，它们在资源层面是强耦合的，一个出事，全员陪葬。这个结构本身决定了"集体沉默"是常态而不是意外。

想避免它，只能从架构上把耦合拆开：每个Agent独立的上下文、独立的工具边界、独立的配额预算，让它们真正像一家公司里的不同部门，而不是一个大脑分裂出的十个人格。我把这次实验的完整记录和配置都留在项目仓库里了，包括四次围堵的事发时日志片段和恢复脚本。有人看完说"这不就是AI版的狼人杀好人全输局"，我倒觉得更像一次压力测试：不用等模型变聪明，我们先把系统的防呆设计补上，AI协作才可能从"演示品"变成"生产工具"。

这次踩坑换来的最后一条经验是：当你觉得所有Agent都安静下来了，别高兴得太早。先看一眼它们是真的在思考，还是已经集体在等待重试。前者是诗，后者是事故。