从传播学角度，如何构建 Agent“小世界”（一）

一、从Cleo说起

最近自己在 Vibe Coding Cleo，是一个基于 OpenClaw 框架开发的链式工作流 Agent Teams 系统。做的过程中发现遇到的问题越来越不像是"AI"问题，更像是"通信"或者说构建 Agent 组织系统的工程问题。

举几个我遇到最大的问题。

幻觉传播。 Master Agent 在分析和拆解任务的环节产生了一条错误信息（misinformation），传给Agent B做分析和执行，B基于这个错误做推理，再传给 Agent C 做分析和打分验证。等我发现的时候，整条链都跑偏了，而且每一步的输出看起来都很"自信"，找不到哪个环节出了问题。
Agent打转。 三个Agent反复讨论一个方案，越讨论越精细，但始终在同一个思路上打转。比如遇到性能瓶颈，工具调用困难，Coder优化算法，Reviewer 发现还是不够快，Coder再优化……循环了五六轮，直到迷失，没 Agent 想过"也许问题根本不在算法，而是在内外部数据库索引"。
Context爆炸。 Agent 数量一上去，每条信息全员广播，token消耗是O(n²)的。API账单疯涨，但协作效率反而下降了，Agent被太多无关信息淹没，真正重要的信息反而被忽略。

这些问题让我想起了大学时期学的计算传播学。幻觉传播不就是传播学里的"信息级联"吗？Agent打转不就是"信息同质化"吗？Context爆炸不就是"信道容量"问题吗？传播学研究了几十年的信息流动规律，如怎么让信息高效到达、怎么过滤噪音、怎么防止错误扩散、怎么避免群体盲从。这些问题跟Multi-Agent系统今天面临的挑战几乎是同构的。

这篇文章就是我把传播学工具箱翻出来，跟Agent系统设计做一次系统性的对照。你会发现，Shannon的信道容量变成了KV cache命中率，Granovetter的弱连接变成了跨组Agent通信，区块链共识机制可以用来解决Agent网络的"新想法该不该被采纳"问题...

二、Agent怎么说话：通信的基本问题

Agent系统最底层的问题是：信息怎么编码、怎么传输、怎么过滤。传播学在这三个环节上都有现成的理论框架。

信息论：通信为什么会失败？

1948年，Shannon发表了信息论的奠基论文，Weaver随后在1949年将其推广为一般性传播模型 [1]。

信源 → 编码器 → 信道（+噪声） → 解码器 → 信宿 [1]。

两个关键概念：噪声会干扰信号，冗余可以对抗噪声但降低效率。每个信道（context window）还有一个容量上限。

Agent 之间用自然语言交流，这虽然是人类最灵活的沟通方式，却也是最容易产生噪声的。尽管从 GPT‑3.5 起自然语言处理已经有了巨大进步，但要想和机器真正高效对话，还是得学会“说机器的话”（也就是 prompt engineering）。

一个真实的场景：Coder Agent写完代码，把结果发给Tester Agent。消息内容是一大段自然语言描述："我修改了用户认证模块，主要改动在login函数，增加了token刷新逻辑，另外顺手修了一个之前的缓存bug。"

Tester Agent收到这条消息后，它该测什么？"主要改动"是什么意思？"顺手修了"到底改了哪些文件？"缓存bug"是哪个bug？

这就是Shannon说的语义噪声，消息的每一个字都传到了，但意思丢了一半。

而且Agent通信中噪声会放大。A发给B的消息有10%的信息损失，B基于损失后的信息推理、再发给C，又损失10%。几跳下来，原始信息面目全非。这就是为什么Multi-Agent系统里幻觉会"传播"。不是每个Agent都在编造，是信息在传递过程中逐步失真。

另一个问题是信道容量。每个Agent的context window就是它的信道。Manus团队实测发现，即使context window技术上支持128K token，模型的推理质量在接近极限时也会显著下降——他们管这个叫"Context Rot"（上下文腐烂）[23]。Shannon早就说过：超过信道容量，信息就会丢失。

怎么解？

三个思路：

第一，用结构化格式替代自然语言来降噪。 上面那个Coder → Reviewer 的场景，如果改成JSON格式通信，噪声立刻降一个量级：

# 坏的通信：自然语言，歧义多
message = "我修改了用户认证模块，主要改动在login函数..."

# 好的通信：结构化，噪声低
message = {
    "action": "code_change",
    "files_modified": ["auth/login.py", "auth/cache.py"],
    "changes": [
        {"file": "auth/login.py", "type": "feature", "description": "add token refresh logic"},
        {"file": "auth/cache.py", "type": "bugfix", "description": "fix stale cache invalidation"}
    ],
    "test_suggestions": ["test_login_token_refresh", "test_cache_invalidation"]
}

第二，用冗余对抗关键信息丢失，但只在关键节点加冗余。 不是每条消息都需要冗余。但是对于跨多跳传递的核心指令（比如用户原始需求），每一跳都应该附带原文。不要只传摘要的摘要的摘要。这就是Shannon说的"在高噪声信道上增加冗余"。
第三，主动管理信道容量。 在context window达到"腐烂阈值"（大约上限的60-70%）之前，主动执行context压缩。把详细的中间过程卸载到文件系统，context里只保留摘要和文件路径。用传播学的话说：当信道快满了，降低码率，但保证核心信息不丢。

这里有一个延伸问题值得想清楚：Multi-Agent系统的"总信道容量"怎么算？

直觉答案是"所有Agent的context window加起来"。10个Agent每个128K token，总容量1.28M。但这是错的。

并行信道的总容量取决于信道之间的独立性。 如果两个Agent的context里有80%的内容是重复的，共享的system prompt/memory、全局任务描述、历史对话记录——它们的"有效信道容量"远小于2×单个容量。公式大概是：

有效总容量 ≈ Σ(单Agent容量) × (1 - 跨Agent信息重复率)

实际系统中，跨Agent的信息重复率往往在50%-80%。10个Agent名义上总容量1.28M token，有效容量可能只有300K-400K。你花了10倍的钱，只买到了3倍的信息处理能力。

这就是为什么Manus的Context Engineering策略如此重要：KV cache复用（减少重复编码的成本）、文件系统外部记忆（把共享信息卸载到外部，不占每个Agent的信道）、append-only context（最大化cache hit率）——这些技巧本质上都在优化"有效信道容量 / 实际token消耗"这个比率 [23]。Shannon在1948年说的"信道编码定理"，到今天变成了"KV cache 命中率是 Agent系统最重要的单一指标"。

两级传播：token爆炸的救星

1940年代，Lazarsfeld研究1940年美国总统选举时发现：大众媒体不直接影响普通人的投票。信息先到达"意见领袖"（Opinion Leader），再由意见领袖向身边的人传播。这个发现后来被提炼为"两级传播"模型——传播是分层的，不是广播式的 [2]。

这间接解了Cleo的 token 爆炸问题。

你的系统有20个Agent，一个Web Scraper Agent抓了一篇5000字的文章。最笨的方案：广播给所有Agent。20个Agent × 5000字 = 100,000 token。而且大部分Agent根本不需要全文，Coder只需要知道"用户需求变了"，Tester只需要知道"新增了一个功能点"，DevOps根本不需要知道。

看到这儿你可能会想：搞什么意见领袖Agent，直接上共享memory不就完了？5000字的文章存一份到vector store或者文件系统里，谁需要谁去读，不用复制20份塞进20个Agent的context。

问题解决了吧？但解决了一半。共享memory确实解决了存储层的冗余。信息不用广播，存一份就行，从Shannon的角度看这是在优化"有效信道容量"，跨Agent的信息重复率降下来了，那个有效容量公式里的数字变好看了。Manus把大块信息卸载到文件系统、context里只放路径和摘要 [23]，本质上就是这个思路。

但共享 memory 解决不了的是"翻译"问题。两级传播的核心不是"减少信息副本数"，是把同一条信息按接收者的需要重新编码。Coder 需要知道改了哪些文件，Tester需要知道测什么边界条件，PM需要知道用户影响。这三份东西不是"同一篇文章的不同片段"，是"同一篇文章的三种不同理解"。意见领袖Agent做的是预处理，它帮下游 Agent 完成了"从5000字里提取200字"这一步。下游Agent拿到的就是干净的、针对自己角色的精简版，不用自己做筛选。

共享memory是被动的。它存在那儿，等你来取。但Agent去取的时候有两个坑：

第一，Agent不知道自己该读什么。 文章存进了vector store，Tester Agent去检索，用什么query？"跟我相关的内容"？检索质量完全取决于query质量。而Agent往往不知道自己不知道什么——它可能根本不会去查那篇文章，因为它不知道文章跟自己有关。传播学管这个叫"拉模型"（pull）vs"推模型"（push）的区别。共享memory是pull，前提是接收者知道自己需要什么信息。意见领袖是push，我知道你需要什么，直接给你送过来。在很多场景下，push比pull靠谱得多。
第二，读了也白占context。 你没有广播5000字给20个Agent，但Coder自己去读了5000字，它的context照样被占了。而且它还得自己从5000字里筛选出跟自己相关的200字，这个筛选过程本身也消耗token和注意力。你省了广播的钱，又花在了每个Agent自己做"信息提取"上。

还有一个容易忽略的问题：共享memory会制造隐性的回声室。 所有Agent从同一个memory pool读信息，读到的原始素材一模一样。表面上这是"信息一致性"，但这意味着所有Agent的信息输入高度相关——又回到了Shannon说的"并行信道不独立"的问题。反而是意见领袖Agent做的"翻译"在制造有益的信息差异——每个Agent拿到的是针对自己视角重构的版本，这种差异性恰恰在防止群体思维。

所以结论是：共享memory和两级传播不是替代关系，是互补的两层。 共享memory解决存储层的冗余（一份原文，不复制），两级传播解决语义层的适配（一份原文，多种理解）。最好的系统两个都要，原始信息存共享memory，意见领袖Agent从memory里读、消化、按角色分发精简版给下游。存储归存储，翻译归翻译。

不要广播，要分层传播。设计"意见领袖Agent"，它消化完整信息，再按下游需要分发精简版。

class OpinionLeaderAgent:
    """意见领袖Agent：消化原始信息，分层分发"""
    
    def process_and_distribute(self, raw_content, source):
        # 第一级：自己消化全文，提取结构化信息
        analysis = self.analyze(raw_content)
        
        # 第二级：根据下游Agent的角色，生成定制化摘要
        for agent in self.downstream:
            if agent.role == 'coder':
                agent.receive(self.extract_for_role(analysis, 'technical_changes'))
            elif agent.role == 'tester':
                agent.receive(self.extract_for_role(analysis, 'testable_features'))
            elif agent.role == 'pm':
                agent.receive(self.extract_for_role(analysis, 'user_impact'))
            # DevOps？这条信息跟它没关系，不传

实际效果：5000字的原始文章，经过意见领袖Agent的处理，Coder收到200字的技术变更摘要，Tester收到150字的测试要点，PM收到100字的影响评估。总token消耗可能从100K降到不到10K。

守门人理论：Agent网络的免疫系统

1947年Lewin在食品消费研究中提出"守门人"概念（家庭主妇作为食品购买的gatekeeper），1950年White将其应用到新闻传播：编辑决定哪些新闻能见报。2008年Barzilai-Nahon扩展成"网络守门"——在去中心化网络中，守门是分布式的 [3][4][5]。

Agent网络缺少守门机制的后果很直接：错误信息一旦被某个Agent生成，就自动获得了"可信"的身份，下游Agent默认它是对的。这就像一家报社没有编辑，记者写什么就直接发什么。

在Agent网络的关键节点设置"守门人Agent"，它不产生新信息，它的唯一职责是质疑和验证经过它的信息。

class GatekeeperAgent:
    """守门人Agent：拦截、验证、放行或阻止"""
    
    def gate(self, message, sender, intended_receivers):
        source_trust = self.assess_source(sender, message)
        consistency = self.check_against_known_facts(message)
        contradiction = self.check_contradictions(message, self.knowledge_base)
        
        if source_trust < THRESHOLD or consistency < THRESHOLD:
            sender.receive(f"[守门人质疑] 你的以下主张需要补充来源: {message.claims}")
            return'blocked'
        
        if contradiction:
            message.add_warning(f"⚠️ 此信息与已知事实 {contradiction.detail} 存在矛盾")
            return'flagged'
        
        return 'passed'

关键设计原则来自Barzilai-Nahon的"网络守门"理论：守门人不能只有一个。 如果只在最终输出前设一个守门Agent，那前面所有环节的错误都会累积到最后一步才被发现。正确的做法是在网络的多个关键节点都设守门人。守门人需要独立的信息源。 一个好的守门人不能只基于网络内部流转的信息来判断——那样它也会被同样的错误信息误导。它需要能访问外部的事实核查工具、数据库或搜索引擎。

三、Agent怎么想：注意力与认知偏差

Agent通信的第二个层面不是"信息怎么传"，而是"信息到了之后，Agent怎么理解、怎么分配注意力"。这一块传播学有一整套"操纵注意力"的工具。

议程设置：Agent为什么会"忘了自己该干嘛"？

1972年，McCombs和Shaw提出议程设置理论。媒体不能决定你怎么想，但能决定你想什么 [6]。

如果你跑过长链Agent任务，你一定遇到过注意力漂移（Attention Drift）。Agent在经过长期多轮的对话和执行后，可能已经完全偏离了最初的目标。它原本应该分析"市场竞争格局"，结果不知道怎么就拐去研究"行业技术趋势"了。你回头看对话历史，发现第10步的时候有个Agent提到了一句技术相关的细节，然后后续的Agent全部被这个细节"吸引"走了。

在长context中，LLM的注意力会被最近的、最显著的信息吸引，逐渐"忘了"最初的任务目标。传播学家对这个现象太熟了——这就是议程设置的反面：当没有明确的"编辑"来维持议程时，议题自然漂移。

Manus 团队在实战中独立发现了议程设置的解法。他们让Agent在每一步结束时，主动重写一个todo.md文件，把全局任务计划写入context的末尾 [23]。为什么管用？因为LLM的注意力分配有一个特点：context 首尾的内容权重最高。把任务计划放在开头和末尾，就是在"设置议程"。

class AgendaSettingProtocol:
    """议程设置协议：防止Agent注意力漂移"""
    
    def __init__(self, original_goal):
        self.original_goal = original_goal
        self.current_plan = []
        self.completed = []
    
    def inject_agenda(self, agent_context):
        agenda = f"""
=== 议程提醒 ===
原始目标: {self.original_goal}
已完成: {self.completed}
当前优先: {self.current_plan[0] if self.current_plan else'无'}
剩余待办: {self.current_plan[1:]}
重要：你的下一步行动必须服务于"当前优先"任务。
如果你发现需要偏离计划，请先说明原因。
================"""
        return agent_context + agenda
    
    def check_drift(self, agent_output):
        relevance = self.compute_relevance(agent_output, self.current_plan[0])
        if relevance < 0.5:
            return f"⚠️ 检测到注意力漂移。当前任务是'{self.current_plan[0]}'，但你的输出似乎在处理其他事情。请回到正轨。"
        return None

两个层次的议程设置：第一层（议题显著性），通过todo.md或类似机制，不断提醒Agent"你应该关注什么"。第二层（属性显著性），不只告诉Agent做什么，还要告诉它"怎么做、从什么角度做"。比如"分析市场竞争格局"这个任务，在下发时附带"重点关注：定价策略差异、目标用户重叠度、护城河强度"——这就是在设定属性，引导Agent的分析角度。

Context操纵术：传播学的五个直接移植

其实议程设置只是传播学操纵注意力的工具之一。还有一整套"context操纵术"可以直接移植到Agent系统里，这些技巧在Prompt Engineering和Context Engineering里已经被工程师们摸索出来了，用传播学的理论框架来拆解一下：

框架效应（Framing）：同一个事实用不同的框架呈现，导致完全不同的理解。"手术存活率90%"和"手术死亡率10%"是同一个数据，但人的反应完全不同。在Agent系统中，给Agent的指令怎么"框架化"直接影响输出质量。比如"检查这段代码有没有bug"（防御性框架）和"这段代码已知有3个bug，找到它们"（进攻性框架），后者的检出率通常更高。Orchestrator在分发任务时可以有意识地选择框架来引导Agent的注意力方向。
启动效应（Priming）：之前接收到的信息会影响你对后续信息的解读。LLM也有同样特征：如果context前文充满技术词汇，模型倾向于给技术性回答；如果前文充满情感表达，模型也跟着变感性。移植方法：在Agent处理新任务前，先在context中注入一小段"启动文本"，包含这类任务的成功案例片段、关键术语、期望的输出风格。这不是"指令"（告诉它做什么），是"启动"（让它进入正确的思维模式）。
认知失调（Cognitive Dissonance）：当人持有两个矛盾的信念时，会试图调和。LLM也是。当Agent在context中同时看到两条矛盾的信息时，它不会报错，而是会默默"调和"出一个两者都不是的结论。两个上游Agent传来矛盾信息？下游Agent可能编造一个中间地带。正确做法是在通信协议中明确标记矛盾信息，强制Agent先识别矛盾再决定如何处理——而不是让它自动调和。
近因效应 + 首因效应（Recency & Primacy）：人们对信息中最先和最后呈现的内容记忆最深。LLM也一样，context的开头和结尾权重最高，中间容易被注意力稀释。所以：不变的核心指令放开头（system prompt），动态更新的任务状态放结尾（最近的append）。 中间放详细的参考资料——即使被部分忽略也影响不大。Manus的stable prefix + append-only context就是首因+近因效应的工程化。
选择性接触（Selective Exposure）——人倾向于只接触跟自己现有观点一致的信息。LLM也有类似行为——它在context中会优先"注意"跟自己推理方向一致的信息，忽略矛盾信息。所以在需要Agent做出关键判断时，把反面证据显式提升到context的高权重位置（开头或结尾），而不是埋在中间。

传播学研究了几十年的"怎么操纵人的注意力"，今天全部可以用来"操纵LLM的注意力"。这不是比喻，是同构，因为LLM的注意力机制跟人类的注意力偏差相似或者说，我们按照人的思维构建了LLM注意力体系。

四、Agent怎么决策：共识与群体思维

Agent的决策层面有两个核心问题：多个Agent怎么达成共识？怎么避免集体犯错？

信息级联与沉默的螺旋：为什么Agent投票经常选出错答案？

信息级联，当足够多的人做出同一选择，后来者会忽略自己的判断直接跟风。沉默的螺旋 [10]，感觉自己是少数派时，人倾向于沉默，多数意见越来越响，少数意见越来越弱。

一个典型场景：5个Agent对一个数学问题给出答案。Agent A和B先回答，都给出了一个错误答案。Agent C本来有一个正确答案，但它看到A和B都同意了，于是"修改"了自己的判断，"两个Agent都这么说，也许是我错了"。D和E看到前面三个都同意了，更不可能"唱反调"了。最终5:0，全票通过一个错误答案。

研究证实这不是假设：LLM Agent在debate中确实存在"从众效应" [29]。更糟的是，LLM因为训练数据的统计分布，天然倾向于输出"主流答案"。这让沉默的螺旋效应在Agent网络中比在人类社会中还要强烈。

怎么解？

class AntiCascadeDebate:
    """抗信息级联的辩论机制"""
    
    def run_debate(self, question, agents):
        # 第一轮：所有Agent独立作答，互相看不到（打破级联起点）
        independent_answers = {}
        for agent in agents:
            independent_answers[agent.id] = agent.answer(question, context=[])
        
        # 检查多样性：如果所有人答案一样，启动Devil's Advocate
        unique_answers = set(independent_answers.values())
        if len(unique_answers) == 1:
            devil = self.spawn_devils_advocate()
            counter = devil.generate_counterargument(question, list(unique_answers)[0])
            independent_answers['devil'] = counter
        
        # 第二轮：每个Agent能看到所有独立答案，但权重相等
        shuffled = self.shuffle_answers(independent_answers)
        revised_answers = {}
        for agent in agents:
            revised_answers[agent.id] = agent.revise(
                question, 
                own_answer=independent_answers[agent.id],
                others=shuffled,
                instruction="即使其他Agent都不同意你，如果你有充分理由，请坚持自己的答案。"
            )
        
        # 投票：少数派权重加成
        return self.weighted_vote(revised_answers, minority_boost=1.5)

核心设计：第一轮独立作答打断级联起点。强制引入Devil's Advocate在架构层面打破"沉默的螺旋"。少数派权重加成，因为在LLM Agent中，少数意见被错误压制的概率远高于少数意见本身错误的概率。结构洞设计 [11]——让不同子系统用不同底层模型的Agent（Claude、GPT、Qwen混用），确保认知框架的多样性。

借鉴区块链共识：Agent网络的"新想法"该怎么被采纳？

Rogers（1962）的创新扩散理论说新想法按S曲线传播 [12]。但Agent网络的问题不只是"怎么传播"，还有"该不该被采纳"。

"一群不完全可信的节点，怎么对一条新信息的真假达成一致"，这就是区块链要解的核心问题。区块链的广播机制跟Rogers的创新扩散路径几乎是同构的：新交易通过gossip protocol逐层扩散，不是一步到位的全网广播。但区块链比Rogers多走了一步：它不只描述"新想法怎么传播"，它还设计了"新想法该不该被采纳"的决策机制，也就是共识算法。

Agent网络正好缺这一块。那区块链的各种共识机制能直接搬过来用吗？每一个的失败方式都很有启发。

PoW（工作量证明）：太贵了，而且赛道不对。 PoW本质上是在比"谁算得快"。但Agent网络里不存在"谁算得快"这个竞争维度——推理速度取决于API并发，跟贡献质量毫无关系。而且PoW不验证内容质量，只验证"你花了力气"。一个Agent可以花大量token推理出一个精致但完全错误的结论。PoW解决的是"防止低成本作恶"，Agent网络的问题不是作恶成本低，而是"真诚的错误"难以识别。赛道不匹配。
PoS（权益证明）：声誉陷阱，但同一个大脑犯同一个错误。 PoS映射到Agent网络，"质押"变成"历史准确率"。Trusted MultiLLMN [26] 就采用了这个方案——WBFT（Weighted Byzantine Fault Tolerance），用声誉加权投票。但问题出在一个关键假设上：PoS假设节点的故障是独立的。

Agent网络里不是这样。假设系统有10个Agent，7个跑Claude，3个跑GPT。Claude的"stake"占70%，PoS共识只需要超过2/3同意——Claude系Agent自己就够了。那如果Claude在某类任务上存在系统性偏差呢？7个Agent会犯同一个错误。

2025年一项基于信息论框架的研究直接证实了这一点：同构Agent的输出高度相关，增加Agent数量带来的边际收益迅速归零。少量异构Agent就能超过大量同构Agent的表现 [28]。以太坊PoS也撞过同样的问题——2022年一度超过60%的验证者跑同一个客户端Prysm，社区一直在喊"client diversity"。Agent网络里的"model diversity"跟以太坊的"client diversity"是完全同构的问题。

PBFT（实用拜占庭容错）："最多容忍1/3坏人"的假设在Agent里不成立。 BlockAgents [25] 提出了Proof-of-Thought（PoT）共识——Agent靠"思考过程对团队贡献最大"来当evaluator，投毒攻击干扰被压到3%以下。DecentLLMs [27] 提出了leaderless架构——并行回答、独立打分、Geometric Median鲁棒聚合。

但PBFT和这些变体的安全保证都建立在拜占庭节点不超过总数1/3这个前提上。Agent网络里的"拜占庭节点"不是恶意的，是"幻觉"的——它真诚地相信自己的错误输出。如果7个Claude Agent中有3个在幻觉，另外4个很可能也在幻觉，因为同模型的故障是高度相关的。实际出错的节点数远超1/3，可能是7/10。PBFT的数学保证直接失效。

PoA + 跨模型共识 + Authority Rotation

排除法走完，我们需要的机制得满足三个条件：不能纯靠"算力"或"资产"说话（排除PoW和朴素PoS），不能假设故障独立（排除PBFT），得能处理"同模型系统性偏差"的问题。

最贴切的基底是PoA（Proof of Authority），但需要三个魔改。

PoA的核心是"被认证的权威才有话语权"。Agent网络天然适合PoA。Agent都是你自己部署的，身份已知，不需要"去信任"（trustless），需要的是"去偏差"（bias-resistant）。

魔改一：Authority不是给Agent的，是给"模型×任务类型"这个组合的。

# 不是一维声誉
reputation = {'claude': 0.85, 'gpt': 0.78, 'gemini': 0.72}

# 而是模型×任务 二维Authority矩阵
authority = {
    ('claude', 'logical_reasoning'):  0.92,
    ('claude', 'realtime_data'):      0.65,
    ('gpt',    'logical_reasoning'):  0.84,
    ('gpt',    'realtime_data'):      0.80,
    ('gemini', 'multimodal'):         0.91,
}

魔改二：跨模型族共识的硬性约束——"安理会机制"。

不管你有多少Agent投票同意，至少要有两个不同底层模型族的Agent都通过验证，洞察才能被确认。

def cross_model_consensus(votes, model_families):
    """安理会式共识：每个模型族都有一票否决权"""
    family_results = {}
    for family in set(model_families.values()):
        family_votes = [v for agent, v in votes.items() 
                       if model_families[agent] == family]
        family_results[family] = sum(family_votes) / len(family_votes) > 0.5
    
    approved_families = [f for f, passed in family_results.items() if passed]
    
    iflen(approved_families) >= 2:
        return'confirmed'
    elif len(approved_families) == 1:
        return'needs_cross_validation'
    else:
        return 'rejected'

为什么它可用？因为它直接打破了"同模型共振"。7个Claude Agent全票通过？不够。得至少有一个GPT系或Gemini系的Agent也独立验证通过。信息论研究已经证明，异构Agent提供的是"互补证据"而非"重复证据"，系统性能的上限取决于有效信道数量而非Agent数量 [28]。

魔改三：Authority Rotation——防止权威固化。

参考DPoS的rotation机制：定期让低authority模型担任首席验证者。如果它的判断被后续证明是对的，authority上调；如果错了，authority不变（不惩罚探索）。目的不是"找到最强验证者"，而是"检验当前的authority排名是不是被系统性偏差扭曲了"。

如果未来所有模型都趋同了怎么办？ 只要模型不是100%一样，跨模型共识就依然有效。架构差异、随机种子、RLHF偏好数据都会产生差异。但如果趋同真的严重到跨模型共识退化了，还有两道额外防线：引入非LLM验证者（符号推理引擎、代码执行器、单元测试）提供完全独立的信道；同模型不同prompt制造人工多样性。

Multi-Agent debate的研究也支持这个设计。Wynn et al.发现Agent在debate中会从正确答案转向错误答案——倾向于达成一致而非挑战有缺陷的推理 [29]。Estornell & Liu从理论上证明了debate天然受"多数暴政"和"共享误解"影响 [30]。不受约束的Agent共识会趋向同质化，必须从架构层面引入多样性保障。

五、Agent怎么组网：拓扑与自组织

前面三章解决了"怎么说话""怎么想""怎么决策"，这一章解决"网络该长什么样"。

弱连接：为什么你的Agent总在原地打转？

1973年，Granovetter发表《弱连接的力量》 [7]：真正帮你找到工作的，不是你的铁哥们，是那个半年没联系的老同学。因为铁哥们和你的信息圈高度重叠，弱连接才能带来全新的信息。

这就是Cleo里Agent打转的根源。三个Agent每天聊，在一个workspace共享同样的context，关注同样的代码文件，它们的"信息圈"已经完全重叠了。就像你的bro，你知道的他都知道，他不可能给你带来突破性的新视角。

这个问题在链式架构里特别严重。信息在固定的链条上传递：Planner → Coder → Tester → Reviewer，每个Agent只跟前后两个节点通信。如果解决方案需要跨越这个链条。比如让Tester直接跟Planner说"需求本身可能就有问题"，在链式架构中这条路不存在。

给Agent网络加"弱连接"——不常通信但跨组的直接连接。

class AgentNetwork:
    def add_weak_ties(self):
        """在不同职能组之间添加低频直连"""
        groups = ['planning', 'coding', 'testing', 'devops', 'research']
        
        for i, g1 in enumerate(groups):
            for g2 in groups[i+2:]:  # 跳过相邻组（已有强连接）
                agent_a = random.choice(self.get_group(g1))
                agent_b = random.choice(self.get_group(g2))
                self.connect(agent_a, agent_b, frequency='low')
    
    def on_stuck_detection(self, group):
        """当检测到某组Agent陷入循环时，激活弱连接"""
        weak_peers = self.get_weak_ties(group)
        for peer in weak_peers:
            peer.receive(f"[跨组请求] {group}组在以下问题上遇到瓶颈: {description}，需要不同视角")

关键设计：弱连接不需要一直开着。平时各组内部紧密协作（强连接），只在检测到"信息循环"时才激活弱连接。

但事实上有些场景下强连接比弱连接更重要。 比如当任务是关于客观事实的认知时。 2+2=4，不需要多样性视角。一段代码有没有语法错误，不需要"跨组视角"来判断。还有在执行阶段，方案已经确定了，分歧是有害的。

规律是：收敛用强连接，发散用弱连接。知道答案时强连接高效，不知道答案时弱连接有价值。 一个好的Agent网络应该能根据当前任务的性质，动态调整强/弱连接的比例。

小世界网络：Agent Swarm的理想拓扑

1998年，Watts和Strogatz发表了划时代的论文 [8]。他们的模型很简单：先建一个规则的环形网络（每个节点连接最近的k个邻居），然后以概率p随机"重连"一些边。当p较小时（大约0.01量级），聚类系数依然很高（局部协作好），但平均路径长度已经急剧下降（全局通信快）。这就是"小世界"。

翻译成Agent系统：规则连接 = 组内通信，同组Agent紧密连接。随机重连 = 跨组捷径，偶尔让不同组的Agent直接连接。枢纽节点 = Orchestrator，少数高度连接的 hub 承担信息中转。

import networkx as nx

# 对比三种网络
regular    = nx.watts_strogatz_graph(20, 4, 0)     # 规则网络
small_world = nx.watts_strogatz_graph(20, 4, 0.1)  # 小世界
random_net  = nx.watts_strogatz_graph(20, 4, 1.0)  # 随机网络

for name, G in [("规则网络", regular), ("小世界", small_world), ("随机网络", random_net)]:
    cc = nx.average_clustering(G)
    apl = nx.average_shortest_path_length(G)
    print(f"{name} - 聚类系数: {cc:.3f}, 平均路径: {apl:.3f}")

那最优的p到底是多少？ 诚实的答案是：没有统一最优值，因为最优p取决于任务类型。 Shen et al.（2025, EMNLP）发现适度稀疏的拓扑在信息传播准确性上最优——全连接图在抑制幻觉传播方面反而是最差的 [19]。所以p太大反而有害。

更前沿的做法是：干脆不手动设p了，让算法自己学。 G-Designer用GNN自动生成最优拓扑 [20]。AGP从全连接图开始自动剪枝，比固定拓扑好2.5%-10% [32]。GTD用图扩散模型同时优化准确率、token成本和鲁棒性 [33]。最优拓扑不是人设计出来的，而是根据具体任务涌现出来的。

自组织：让Agent自己建网络

2026年1月，Kimi团队推出了Agent Swarm [24]。核心理念不是"很多Agent一起干活"，而是"模型自己学会了什么时候该并行"。你给一个任务，Orchestrator自主决定何时spawn sub-agent、spawn多少个、怎么分配任务。编排能力不是框架逻辑，是训练进模型权重里的推理能力。 最多100个sub-agent并行，1500+ tool calls，速度比串行快4.5倍。

核心思路：给Agent一套"组织协议"而不是"组织架构"。

class SelfOrganizingSwarm:
    """不预设架构，让Agent通过协议自组织"""
    
    def __init__(self, task):
        self.task = task
        self.agents = {}
        self.network = nx.Graph()
    
    def bootstrap(self):
        planner = self.spawn_agent(
            role="planner",
            instruction=f"分析任务: {self.task}。决定需要哪些角色、多少Agent、怎么分工。"
        )
        org_plan = planner.plan()
        for role_spec in org_plan['roles']:
            agent = self.spawn_agent(**role_spec)
            for peer in self.get_agents_by_group(role_spec['group']):
                self.network.add_edge(agent.id, peer.id, type='strong')
        self.add_shortcuts(rewire_prob=0.1)

自组织的核心难题：什么时候加边，什么时候减边？

2025年的研究给出了三类调整指标。任务表现指标决定"该不该加边"：Agent打转了（加跨组弱连接）、信息死角（加到信息源的连接）、错误率飙升（加到验证Agent的连接）。通信效率指标决定"该不该减边"：通信消耗大量token但接收方没有改变输出（浪费钱，减掉）、两条边传递重复信息（冗余，减一条）。网络健康指标决定"全局调什么"：聚类系数太高（>0.8，加跨组弱连接）、太低（<0.3，加强组内连接）、平均路径增长（加捷径）、度分布不均（分散连接）。

GTD [33] 把这三类指标统一成了一个多目标优化问题。不要试图手写"什么时候加边什么时候减边"的规则，而是把"好的拓扑长什么样"定义成一个多目标奖励函数，让系统自己学。 就像你不需要告诉蚂蚁"往左走"还是"往右走"，你只需要定义"食物在哪"。

协议、记忆与社交：Agent组网的三层基础设施

前面讲了Agent该怎么连、连成什么形状、什么时候加边减边。但有个更基础的问题一直没碰：Agent之间靠什么通信？

你可以把Agent的组网想象成建一座城市。前面讨论的弱连接、小世界、自组织，都是在画城市规划图——哪里建路、路多宽、单行还是双向。但路画好了，还需要三样东西：管道（通信协议）、图书馆（共享记忆）、和咖啡馆（社交场所）。 去年开始，AI 的最新发展刚好对应了这三层。

第一层：管道——MCP、A2A和通信协议

2024年底Anthropic发布了MCP（Model Context Protocol）[34]，2025年4月Google发布了A2A（Agent-to-Agent Protocol）[35]，IBM还有个ACP。三个协议解决的是不同层次的问题：

MCP解决的是Agent怎么用工具，标准化地访问数据库、API、文件系统。它是Agent-to-Tool的协议，相当于给Agent装了一套标准化的手和眼睛。用Shannon的话说，MCP在定义编码规则。Agent和外部世界之间用什么格式交换信息。

A2A解决的是Agent怎么找到彼此、怎么握手。每个Agent发布一张Agent Card（JSON格式，包含名字、能力、认证方式），别的Agent扫一眼就知道你能干啥、怎么跟你说话。解决的是路由层，Agent之间的信息该走哪条路、用什么协议传递。

但有意思的是：目前所有协议都在解决"Agent怎么通信"的问题，没有协议在解决"Agent该不该通信"和"通信拓扑该是什么形状"的问题。 A2A让Agent能互相说话了，但没有回答"10个Agent之间该全连接还是小世界"这个架构问题。协议解决的是管道（pipe），我们讨论的是管道网络（plumbing）。这两件事互补，你需要A2A来建管道，需要小世界理论来决定管道往哪儿接。

第二层：图书馆——外部Memory

在前面"两级传播"那节我们讨论了共享memory的局限：它是pull模式的"图书馆"，不能替代push模式的"意见领袖分发"。但图书馆本身仍然是必要的基础设施。

目前Agent的外部记忆有几种形态：Manus用文件系统（最简单直接，context里只放路径和摘要）；更复杂的系统用vector store或knowledge graph做共享知识库；ACP甚至把memory机制写进了协议本身。

从传播学看，外部memory是Agent网络的公共媒体。报纸、图书馆、维基百科，不是人与人之间的直接对话（那是A2A解决的），而是一个公共的信息基础设施，所有人都可以读写。Agent系统里，外部memory是前者，意见领袖Agent的分发是后者。好的系统两层都要。外部memory做长期知识沉淀，意见领袖做实时信息路由。

第三层：咖啡馆——Agent社交通信

这是目前最缺的一层，也是最有想象力的一层。

现在的Agent通信都是"功能性通信"。我给你发消息是因为我有任务要你做。但Granovetter的弱连接研究告诉我们 [7]：很多关键信息不是通过正式渠道传播的，是通过非正式的社交网络传播的，饭桌上的闲聊、走廊里的偶遇、朋友的朋友的一句话。

Stanford的Generative Agents实验（"AI小镇"）已经展示了这一点。Agent之间的"闲聊"能产生涌现式的协作行为。一个Agent无意间提到自己在做某件事，另一个Agent听到了觉得跟自己的任务有关，自发产生了合作。这种信息交换没有被任何"任务调度系统"规划过。它是社交网络的涌现效应。

在Multi-Agent系统里，这意味着什么？想象一下：你的Debug Agent在排查一个bug，同时Review Agent在检查另一段代码。两个任务表面上不相关，但如果它们之间有一条"弱连接"，比如Debug Agent在处理过程中顺带广播了一句"发现模块X有个异常调用模式"——Review Agent可能会意识到"等等，我在审的代码也调用了模块X"。这条信息不在任何任务列表上，但它可能帮你省下几小时的排查时间。

这就是"Agent咖啡馆"。一个让Agent进行非功能性信息交换的低带宽通道。不是每条消息都必须跟当前任务相关，偶尔的"闲聊"反而能激活弱连接、打破信息孤岛。

四层模型：从管道到社会

把这三层加上我们前面讨论的治理层（共识机制），形成一个完整的Agent通信栈：

层	解决什么	现有方案	成熟度
协议层	Agent怎么握手、互相发现	MCP / A2A / ACP	⭐⭐⭐ 快速标准化中
知识层	Agent怎么共享长期记忆	文件系统 / Vector Store / Knowledge Graph	⭐⭐ 有方案
社交层	Agent怎么非正式地交换信息	Stanford Generative Agents/ Moltbook（实验性）	⭐ 我还没找到
治理层	Agent怎么达成共识、解决冲突	暂无标准化方案（也许是 Agent DAO 组织）	⭐ 我还没找到

现状是：底层管道在快速铺设，上层社会结构几乎没人建。 大家都在忙着让Agent能互相说话（协议层），但很少有人在想Agent该跟谁说话（拓扑层）、说什么（社交层）、说了之后怎么达成共识（治理层）。

这恰恰是传播学能贡献的地方。传播学100年来研究的就是"人类社会的通信栈"，从物理层的信道编码（Shannon），到路由层的两级传播（Lazarsfeld），到社交层的弱连接（Granovetter），到治理层的公共舆论形成（Noelle-Neumann）。Agent网络正在重演人类通信系统的进化史，只是速度快了很多。

六、Agent的"传播病"：当通信出了问题

理论和架构都聊了，现在来看Agent网络中最头疼的几个问题。有意思的是，这些问题传播学早就研究过了。

幻觉传播：一个谎言的蝴蝶效应

单个LLM会产生幻觉，这大家都知道。但在Multi-Agent系统里，幻觉不只是一个局部问题，它会广泛传播。Agent A产生错误事实，B把它当输入推理，C看到A和B都"确认"了，更加确信。到了D那里，这个错误已经被三个"独立来源"确认过了，最终彻底变成了"事实"。这就是传播学里的"信息级联"在Agent网络中的完美复现。

更糟糕的是，Agent的幻觉不仅限于最终输出，它还可能在感知和推理的中间过程中产生，并随时间累积和放大 [31]。

从网络拓扑的角度，幻觉传播的严重程度直接跟网络的"密度"相关。全连接网络是最差的选择：一个Agent的幻觉会立刻污染所有Agent [19]。完全隔离又太极端：有益的信息也传不出去。小世界网络的"适度连接"恰好在这两个极端之间找到了平衡。

群体思维：当所有Agent都同意的时候，要当心

Janis在1972年研究美国几次重大外交失败后提出了"群体思维" [13]：一个高度凝聚的团队，因为追求一致而压制了批判性思考。

当多个Agent使用相同底层模型、接收相似context时，它们天然就有趋同倾向。研究发现，LLM Agent并不总是在面对正确反驳时修改立场，反而是口才好的Agent更容易影响群体决策 [22]。解法跟传播学一脉相承：使用不同底层模型、设计Devil's Advocate Agent、在投票中给少数派额外权重、用异质性通信拓扑避免回声室。

回声室效应：信息的自我封闭

Agent网络中的回声室更加隐蔽。当Agent A把摘要发给Agent B，B基于摘要产生新输出再发给C。每一次传递都是一次"过滤"。原始信息中的微妙之处、不确定性、反面证据，在层层传递中逐渐被抹平。到最后，所有Agent手里拿到的都是一个过度简化、过度确定的"共识"。

小世界网络虽好，但也需要主动设计"破圈"机制，防止回声室形成。

Context Rot：香农信道容量的现代版

Manus团队发现的"Context Rot"（上下文腐烂）[23]：当Agent执行长链任务时，context window不断膨胀。即使技术上没有超过窗口限制，模型的推理质量也会在接近极限时显著下降。而且这种损失不是突然的断崖式下跌，是渐进的质量退化，更难察觉也更危险。

应对策略：在达到"预腐烂阈值"前主动执行压缩或摘要循环（Context Compaction）。

七、设计原则：怎么建你自己的Agent小世界？

综合传播学理论和实战经验，提炼七条设计思路。

思路一：分组 + 捷径。 可以把Agent按功能分组（局部聚类），再在组之间添加少量跨组连接（随机捷径）。不要一上来就全连接,通信成本是O(n²)，Agent会被信息过载淹没。
思路二：设计守门人层（Agent Hub）。 借鉴守门人理论和两级传播，给关键节点加上过滤和摘要的能力。

class GatekeeperAgent:
    """守门人Agent：过滤、摘要、分发"""
    
    def receive_and_dispatch(self, message):
        if not self.is_relevant(message):
            return
        priority = self.assess_priority(message)
        output = self.summarize(message) if priority < HIGH else message
        for agent in self.downstream_agents:
            if self.is_relevant_to(output, agent.role):
                agent.receive(output)

思路三：保留异见通道。 为了防止"沉默的螺旋"和群体思维：设Devil's Advocate Agent，投票中给少数派额外权重，定期重新洗牌Agent连接，使用不同底层模型增加认知多样性。

思路四：Context Engineering是底层基建。 KV Cache命中率是最重要的指标。三个关键实践：保持prompt前缀稳定（一个token的变化就让整个缓存失效）、Context只增不改（确保序列化确定性）、用文件系统做外部记忆（context window是有限的"信道"，把大块信息卸载出去）。

思路五：监控网络健康度。 小世界网络的优势建立在特定的结构参数上，需要持续监控聚类系数、平均路径长度、度分布和幻觉扩散率。

def health_check(network, error_log):
    metrics = {
        'clustering': nx.average_clustering(network),
        'avg_path': nx.average_shortest_path_length(network),
        'max_degree': max(dict(network.degree()).values()),
        'error_propagation_depth': avg_hops_before_correction(error_log)
    }
    if metrics['clustering'] < 0.3:
        print("⚠️ 聚类系数偏低，局部协作可能不足")
    if metrics['avg_path'] > math.log(len(network)):
        print("⚠️ 路径过长，考虑添加捷径")
    if metrics['max_degree'] > len(network) * 0.5:
        print("⚠️ 存在超级枢纽，注意单点故障风险")
    if metrics['error_propagation_depth'] > 3:
        print("⚠️ 幻觉传播深度过大，加强中间节点验证")
    return metrics

思路六：共识机制比投票更重要。 简单多数制不够。跨模型族的PoA共识，至少两个不同模型族通过才算确认。能有效对抗同模型共振。
原则七：通信协议要分层。 借鉴OSI模型的思路：

层级	职责	传播学对应
路由层	消息发给谁？怎么到达？	小世界网络拓扑
守门层	这条信息该不该传？	守门人理论
过滤层	传全文还是摘要？优先级？	议程设置 + 两级传播
语义层	消息说的是什么？上下文？	香农信息论（编码/解码）
行动层	收到消息后我该做什么？	创新扩散（采纳/拒绝决策）
验证层	这条信息可靠吗？需要核实吗？	对抗信息级联

八、现有框架在做什么？

框架	拓扑类型	聚类系数	路径长度	并行能力	Agent间通信	灵活性	动态性
OpenAI Swarm	链式handoff	低	中-高	❌	handoff传递context	高（代码层）	静态路由
Claude Agent Teams	星型 + P2P	中	低	✅	直接消息 + 共享任务	高	动态spawn
Kimi Agent Swarm	Orchestrator树	低	低	✅（最多100）	Orchestrator中转	中	模型自主决策
ChatDev	线性链	低	高	❌	仅相邻节点	低	静态
MetaGPT	星型 + 广播	低	低	❌	共享消息池	中	静态
CrewAI	可配置有向图	可调	可调	部分	委托 + 直接对话	高	半静态
AutoGen	动态时序图	动态	动态	部分	对话驱动	高	动态
LangGraph	任意计算图	自定义	自定义	✅	图中定义的边	最高	自定义

所以，小世界告诉了我们什么？

回到最开始的问题：怎么让你的Agent们高效协作？

传播学和网络科学给了我们一个清晰的答案框架：不要让所有Agent跟所有Agent说话，全连接是懒人方案。分组是必要的，但孤岛是危险的，你需要跨组的"弱连接"。守门人要有，但要分布式。保护少数意见，在架构层面对抗群体思维。Context Engineering是底层基建。共识机制比投票更重要，跨模型族的PoA共识可能是最贴切的方向。最好的网络是活的，最优拓扑不是静态设计出来的，而是根据任务动态涌现的。

说到底，Multi-Agent系统设计不只是一个工程问题。它同时也是一个传播学问题、一个组织行为学问题、一个网络科学问题、一个分布式系统问题。Shannon的信道容量、Granovetter的弱连接、Janis的群体思维、Noelle-Neumann的沉默螺旋、区块链的拜占庭容错。这些几十年前的理论，今天同样可以复用在Agent架构里。

跨学科思考，构建更聪明的Agent系统。

这篇文章融合了传播学、网络科学、区块链共识和AI Agent系统设计的视角。如果你觉得有意思，欢迎转发给你的"弱连接"们，说不定这就是那条改变信息流向的捷径。

参考文献

[1] Shannon, C. E. & Weaver, W. (1949). The Mathematical Theory of Communication. University of Illinois Press.

[2] Lazarsfeld, P. F., Berelson, B. & Gaudet, H. (1944). The People's Choice. Columbia University Press.

[3] Lewin, K. (1947). "Frontiers in Group Dynamics." Human Relations, 1(2), 143–153.

[4] White, D. M. (1950). "The Gatekeeper." Journalism Quarterly, 27(3), 383–390.

[5] Barzilai-Nahon, K. (2008). "Toward a Theory of Network Gatekeeping." JASIST, 59(9), 1493–1512.

[6] McCombs, M. E. & Shaw, D. L. (1972). "The Agenda-Setting Function of Mass Media." Public Opinion Quarterly, 36(2), 176–187.

[7] Granovetter, M. S. (1973). "The Strength of Weak Ties." American Journal of Sociology, 78(6), 1360–1380.

[8] Watts, D. J. & Strogatz, S. H. (1998). "Collective dynamics of 'small-world' networks." Nature, 393, 440–442.

[9] Barabási, A.-L. & Albert, R. (1999). "Emergence of Scaling in Random Networks." Science, 286, 509–512.

[10] Noelle-Neumann, E. (1974). "The Spiral of Silence." Journal of Communication, 24(2), 43–51.

[11] Burt, R. S. (1992). Structural Holes: The Social Structure of Competition. Harvard University Press.

[12] Rogers, E. M. (1962/2003). Diffusion of Innovations (5th ed.). Free Press.

[13] Janis, I. L. (1972). Victims of Groupthink. Houghton Mifflin.

[14] Qian, C. et al. (2023). "Communicative Agents for Software Development." arXiv:2307.07924.

[15] Hong, S. et al. (2023). "MetaGPT: Meta Programming for Multi-Agent Collaborative Framework." arXiv:2308.00352.

[16] Wu, Q. et al. (2023). "AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation." arXiv:2308.08155.

[17] Park, J. S. et al. (2023). "Generative Agents: Interactive Simulacra of Human Behavior." UIST 2023.

[18] Li, G. et al. (2023). "CAMEL: Communicative Agents for 'Mind' Exploration of Large Language Model Society." NeurIPS 2023.

[19] Shen, X. et al. (2025). "Understanding the Information Propagation Effects of Communication Topologies in LLM-based Multi-Agent Systems." EMNLP 2025.

[20] Zhang, Y. et al. (2025). "G-Designer: Architecting Multi-Agent Communication Topologies via Graph Neural Networks." ICML 2025.

[21] Zhang, Z. et al. (2025). "Cut the Crap: An Economical Communication Pipeline for LLM-based Multi-Agent Systems." ICLR 2025.

[22] Zhang, J. et al. (2024). "Exploring Collaboration Mechanisms for LLM Agents: A Social Psychology View." ACL 2024.

[23] Ji, Y. (Peak) (2025). "Context Engineering for AI Agents: Lessons from Building Manus." Manus Blog.

[24] Kimi Team (2026). "Kimi K2.5: Visual Agentic Intelligence." Moonshot AI.

[25] Chen, B. et al. (2024). "BlockAgents: Towards Byzantine-Robust LLM-Based Multi-Agent Coordination via Blockchain." ACM Turing Award Celebration Conference.

[26] Luo, H. et al. (2025). "A Weighted Byzantine Fault Tolerance Consensus Driven Trusted Multiple Large Language Models Network." arXiv:2505.05103.

[27] Jo, Y. et al. (2025). "Byzantine-Robust Decentralized Coordination of LLM Agents." arXiv:2507.14928.

[28] Kim, J. et al. (2025). "Understanding Agent Scaling in LLM-Based Multi-Agent Systems via Diversity." arXiv:2602.03794.

[29] Wynn, A. et al. (2025). "Talk Isn't Always Cheap: Understanding Failure Modes in Multi-Agent Debate." arXiv:2509.05396.

[30] Estornell, A. & Liu, C. (2024). "Multi-LLM Debate: Framework, Principals, and Interventions." OpenReview.

[31] Cemri, M. et al. (2025). "Why Do Multi-Agent LLM Systems Fail?" arXiv:2503.13657.

[32] Adaptive Graph Pruning (2025). "Adaptive Graph Pruning: A Task-Adaptive Multi-Agent Collaboration Framework." ECAI 2025.

[33] Guided Topology Diffusion (2025). "Dynamic Generation of Multi-LLM Agents Communication Topologies with Graph Diffusion Models." arXiv:2510.07799.

[34] Anthropic (2024). "Introducing the Model Context Protocol." Anthropic Blog.

[35] Google Cloud (2025). "Announcing the Agent2Agent Protocol (A2A)." Google Developers Blog.