多agent协作学习笔记（自用）-Datawhale组队学习-北京尧图网络

1. 两大设计维度决定系统骨架维度一上下文是否共享共享上下文不共享上下文本质后续 Agent 继承前序 Agent 的完整轨迹trajectory每个 Agent 维护完全独立的上下文类比接班的同事能翻阅前任全部工作日志不同部门各干各的靠共享文档/纪要交换信息优势信息不丢失可回顾任何阶段细节模块化、隔离性好易扩展易维护权限清晰可真正并发代价上下文快速膨胀易受思维惯性干扰必须靠显式通信机制信息可能丢失/重复调试困难不共享上下文时Agent 间的通信归根结底只有 IPC 两大范式工具调用的参数—— 把下游 Agent 封装成工具同步传递结构化数据消息传递·同步形态共享文件系统—— 读写共享目录下的文档/代码共享内存形态消息总线Message Bus—— 中转站异步转发消息传递·异步形态Go 谚语不要通过共享内存来通信而要通过通信来共享内存。维度二协作拓扑模式结构适用对等协作Peer少量 Agent 固定拓扑、迭代改进2–3 个 Agent 互相制衡、反复打磨管理者模式Orchestration中心 Manager 规划调度多个子 Agent子任务多、依赖复杂、需动态调度去中心化模式Decentralized无运行时中心Agent 自主沟通模拟人类组织、避免单点故障Graph 工程2026 年起流行指显式设计执行图——节点是 Agent/程序/人工决策边定义依赖、路由与失败去向。本章三种拓扑就是它的多 Agent 子集。2. 核心判据什么时候多 Agent 真正优于单 Agent唯一判据协作过程是否引入了单个 Agent 生成时无法获得的新信息。协作模式是否引入新信息效果同一模型自我审查重读自己的输出否通常无效甚至有害不同 Agent 辩论同一段文本否等算力下与单 Agent 持平审核者用测试执行结果审查代码✅ 执行反馈显著提升审核者看渲染截图审查前端/PPT✅ 视觉反馈显著提升审核者用外部工具验证事实✅ 工具反馈显著提升关键证据RLEF (2025)用 RL 训练模型利用代码执行反馈迭代改代码远超独立多次采样。WebGen-Agent (2025)截图VLM 描述的视觉反馈脚手架把 Claude 3.5 Sonnet 在网页生成基准上从26.4% → 51.9%近翻倍。学术 vs 工程的矛盾解释学术研究的多 Agent 多是看同一份上下文互相讨论无新信息工程有效的多 Agent 都包含外部反馈环路执行/渲染/工具。两者不是一回事。Anthropic 2026 漏洞挖掘实验45 个 Agent 共享论坛协调搜索、互相审查、独立仲裁。集群用2700 万 token 找到 266 个漏洞独立 Agent 并行方案用650 万 token 只找到 21 个。开放搜索空间里多 Agent 通过互相通信动态转移搜索重点、形成专门分工。步骤预算Budget-Aware的反直觉结论Google 2025《Budget-Aware Tool-Use Enables Effective Agent Scaling》单纯增加步骤数不能保证性能提升——标准 Agent 缺乏预算意识300 步预算下仍做浅层搜索很快饱和。2026BAVT步骤级价值评估随剩余预算比例调整探索/利用权重——预算减少时从广撒网切换到深挖掘。对多 Agent 的启示Manager 应根据任务复杂度动态分配步骤预算引导子 Agent先规划、再实现、再测试、再改进而非一头扎进去。成本是硬约束多 Agent 的并行探索与反复迭代消耗大量 token。收益必须覆盖数倍乃至一个数量级的额外开销否则调校得当的单 Agent 往往更划算。3. 共享上下文的多 Agent 协作每个阶段是一个独立 Agent自己的系统提示词工具集但继承前序 Agent 的完整轨迹。核心做法多阶段角色转换—— 根据当前阶段动态切换系统提示词和工具集让 Agent 以最合适的身份工作。⚠ 关键设计选择替换 system prompt还是加载 Skill选择角色规程载体工具可见性上下文/KV Cache约束能力transfer_to_agent替换 system prompt通常连带换工具集只暴露当前角色工具每次切换改变前缀缓存从变化点起失效强越界工具在 schema 层就不可见Skill固定 prompt 中的 Skill 目录按需把SKILL.md追加到轨迹通常固定暴露工具全集静态前缀不变Skill 内容成为末尾轨迹前缀可继续复用弱Skill 是行为指令硬权限仍需 Harness 门取舍原则角色差异主要来自知识、流程、写作风格→ 用Skill差异涉及权限、工具隔离、合规边界、运行时强制禁止某类动作→ 用独立 Agent /transfer_to_agent Harness 层代码限制。4. 不共享上下文的多 Agent 协作真正的多 Agent4.1 与操作系统的完整对应记忆这张表操作系统多 Agent 系统程序可执行文件静态前缀系统提示词工具定义进程的内存轨迹trajectoryCPULLM内核Agent 运行时系统调用工具调用fork创建子进程spawn_subagentkill发送信号cancel_subagentps列出进程list_agents退出码 / wait()子 Agent 返回的结构化摘要共享内存 / 消息传递共享文件系统 / 消息本质私有状态异步消息可创建新成员 1970 年代Actor 模型的 LLM 版本。OS/分布式系统经验可直接借用。4.2 数据平面Agent 的虚拟文件系统四类区域统一接口read_file/write_file/list_dir底层可能是本地盘、对象存储、云盘 API 或只读资源包。区域可见性生命周期读写并发控制① Agent 专属工作区Scratchpad仅该 Agent随实例销毁读写不需要私有② 多 Agent 共享空间Shared Workspace所有协作 Agent 用户随任务持续需持久化读写需要乐观锁 / worktree③ 外部挂载资源Mounted External视外部授权由外部源决定多为只读写需谨慎由外部源负责④ 系统内置资源Built-in所有 Agent跨会话稳定只读不需要① Scratchpad子 Agent 试错过程留在自身工作区只把最终产物提交共享空间 → 对应第四章子 Agent 返回结构化摘要而非全量轨迹。② Shared Workspace并发冲突高发处需乐观锁/worktree也是用户上传原始文件、下载交付物的通道。③ 外部挂载三项特性必须显式处理——访问受外部权限约束、延迟高且一致性弱按最终一致性对待、按需只读为主误写会污染用户真实数据。④ 内置资源典型是Skills/skills渐进式披露先索引后展开全局共享、只读、跨会话稳定。核心价值文件路径作为通用接口——Agent 间传递、主→子交接、跨组织 A2A 交换传递的都是轻量路径字符串而不是把内容塞进上下文窗口。4.3 控制平面Agent 间的通信与控制一、消息传递点对点send_message_to_agent_b(content)适合拓扑固定、Agent 少的场景。规模大时改用消息总线发布/订阅发送方无需知道消费者是谁。消息应携带结构化信封发送者 ID、目标指定/广播、消息类型task_assigned/status_update/result/terminate、JSON 负载 → 协作链路可追溯这是调试的关键。二、状态查询最易被低估❌ 拉取式get_subagent_status(agent_id)不实用——子 Agent 一创建就开始跑完成时自然会通知。✅用消息传递获取状态主 Agent 直接问进展如何子 Agent 合适时机回复异步不阻塞子 Agent 也可在关键节点主动发status_update。状态宜用统一状态机词汇执行中 / 需要输入 / 已完成 / 失败。✅用共享文件系统获取状态最彻底轨迹持久化——子 Agent 把轨迹实时序列化为 JSONL 追加写入日志相当于直接读另一个进程的内存。但轨迹动辄数万 token不宜作为主方式。更实用约定进度文件如progress.md——子 Agent 每完成一项就更新任务清单主 Agent 随时读这个轻量文件。还能检测卡住最后修改时间超过 N 分钟无变化即判定无活动、触发超时兜底。三、执行终止优雅终止首选发terminate信号子 Agent 在当前步骤的安全点响应先清理资源关闭浏览器、写未完成文件、释放锁返回 ack 后退出。强制终止兜底直接终止仅在对优雅信号无响应时使用可能遗留悬挂资源。级联终止借鉴 Go context——取消一个 Agent它派生的所有子 Agent 随之取消从根上杜绝孤儿 Agent。若需脱离父级长期运行的后台 Agent类似nohup让它从新的生命周期树起步对应context.Background()。四、资源与调度稀缺资源从 CPU/内存变成token 和并发额度。启动子 Agent 时设定步数/token 预算困难任务给强模型机械任务给低成本模型并发数设上限达到上限时更紧急的任务抢占执行中的子 Agent。管理者的独有优势具备推理能力 → 可启动多个子 Agent 并行赛马根据进展决定给谁更多资源、终止谁。5. 拓扑详解一对等协作模式相互制衡迭代改进潜在价值引入独立视角与认知多样性。 ⚠多个实例 ≠ 多种思路模型、上下文、脚手架高度相似时不同 Agent 往往做出相同选择局部错误演变为系统性故障。要获得真多样性需主动区分模型、上下文、工具、可见证据或职责且让各 Agent先独立判断、再汇总。5.1 Loop 工程Loop Engineering要解决的根本失败过早终止——活干到一半就停。三种典型形态形态表现偷懒式假完成做一部分就宣称全部做完代码没跑测试、第二件事被遗忘过早放弃一条路走不通就宣布办不成其实换个渠道再试很可能成功假成功以为办成了实际闭环没走完对方口头同意用户还需在 App 确认共同根源在验证之前完成只是模型的一句宣称不是证明。Loop 工程的核心设计一个让 Agent 持续运转的循环发现下一件事 → 执行 → 验证 → 记录进度由验证器而不是模型自己来判定是否真的可以停。人的角色从给 Agent 写提示词的操作者 → 设计循环的工程师。共识循环的瓶颈在验证器而不在模型。验证不可靠循环转得再快也只是把劣质产出更快标记为完成。具体框架LoopX—— 把循环从模型的提示词/聊天历史中抽离放进持久控制面LoopX 决策 → Agent 执行 → 独立验证器证明 → LoopX 提交不变量模型可以提出完成但不能批准自己的完成。具体框架LongHorizon-Harness—— 面向多模态 Computer Use 的长程执行MEA 循环Manager根据目标/已核实进展/失败证据/剩余工作 → 生成下一项有界子任务Executor在全新上下文中通过 GUI/CLI 改变环境Auditor以只读方式检查真实结果只有审计通过的内容才进入下一轮任务状态对照组同 Qwen 3.7-Plus Claude Code 后端只改外层 loopWeaveBench PassRate51.8% → 80.7%OSWorld 2.0 二元完成率2.8% → 8.3%Terminal-Bench 2.169.7% → 77.2%。代价前两个基准分别消耗基线2.3 倍总 token、3.6 倍输出 token。5.2 提议者-审核者范式Proposer-Reviewer⭐最经典为什么不能让一个 Agent 自己生成再自己审查ICLR 2024《Large Language Models Cannot Self-Correct Reasoning Yet》GPT-4 无外部反馈地自我审查修正准确率反而下降——把正确答案改错的次数比把错误答案改对的更多。TACL 2024《When Can LLMs Actually Correct Their Own Mistakes?》除非提供可靠外部反馈纯粹自我纠正几乎不起作用。ICLR 2024CRITIC让模型用外部工具搜索引擎、Python验证自己 → 显著提升移除工具验证后提升消失。最小不变量审核者读取独立证据tests / state / screenshot / facts而不是复述提议者的解释退回时必须给出可定位的修复条件。candidate proposer(task, constraints) evidence execute_or_render(candidate) # tests, state, screenshot, facts review independent_reviewer(candidate, evidence) while review.veto and budget_remaining: candidate proposer.repair(candidate, review.findings) evidence execute_or_render(candidate) review independent_reviewer(candidate, evidence) if review.pass: publish(candidate, evidence, review) else: escalate_or_reject(review)审核者不能修改测试、证据采集器或发布门槛否则独立验证退化成自我批准。审核者的价值不在于用同一模型再看一遍代码而在于它渲染了产物并截取了画面 / 跑了测试——这些是提议者生成时完全无法获得的新信息。5.3 辩论模式Debate多个 Agent 各持不同立场通过对抗性对话深入探索问题空间。但实际效果学术界仍有争议2026 Tran Kiela等思考 token 预算下单 Agent 与五种多 Agent 架构顺序、辩论、集成、并行角色、子任务并行持平甚至更好。解释数据处理不等式辩论中多个 Agent 处理完全相同的文本信息串行传递中间结论只可能丢失信息、不可能凭空创造信息。辩论的收益很可能来自消耗了更多总计算量。不否定的做法多次独立采样再聚合自一致性、多数投票或利用生成与验证的难度不对称写答案难、检验答案易。5.4 头脑风暴模式Brainstorming多个 Agent 独立生成创意 → 分享 → 相互启发。通过不同思维偏好提示词/模型探索更广解空间找到单一 Agent 想不到的创意组合。5.5 专家小组模式Panel of Experts多个 Agent 各自代表一个专业视角互补而非对抗共同拼出问题全貌识别跨领域约束与机会工程师看实现难度、产品看市场吸引力、运营看成本资源。6. 拓扑详解二管理者模式中心化协调Manager 职责理解整体任务 → 拆解子任务 → 选 Agent 执行 → 跟踪进度、处理异常重试/换人/调计划→ 整合最终结果。关键抽象把每个专门 Agent 建模为 Manager 可调用的工具。从 Manager 视角调用 Agent 和调用普通工具没有本质区别 → 新增能力只需开发对应 Agent 并注册为工具Manager 核心逻辑无需修改天然支持异构不同模型/提示词/工具集/硬件。固有挑战Manager 是单点瓶颈——必须理解所有子任务性质、选对 Agent、准确传上下文。Manager 维护全局上下文随任务推进快速膨胀。需特别注意 Manager 提示词质量、上下文管理策略、任务分解粒度。关键实证Plan-and-Act (2025)—— 在 Planner-Executor 双 Agent 架构中弱规划者是整个系统最关键的瓶颈。Planner 质量足够高时即使 Executor 简单也能取得好结果反之 Planner 分解有误后续所有 Executor 工作都建立在错误前提上。启示把最强的模型和最精心设计的提示词分配给 Manager规划者而不是平均分配给所有 Agent。WebArena-Lite 57.58%6.1 顺序协调控制流线性简单明了适合子任务有清晰先后依赖的场景。典型实验书籍翻译 AgentManager Glossary Translation ProofreadingGlossary Agent识别专业术语 → 生成结构化术语对照表JSON/CSV→ 写入共享文件系统 → 销毁释放资源Translation Agent接收当前章节术语表翻译指南 → 独立上下文翻译 → 写入chapter1_zh.md可并行多实例Proofreading Agent全文一致性检查 → 审校报告Manager Agent上下文中只保存任务描述、执行计划、调用记录、进度状态不装完整翻译内容关键优势上下文隔离——每个 Agent 都在精简、专注的上下文中工作不会因信息过载而分心。Manager 上下文始终可控。6.2 并行协调多个子任务同时执行大幅提升吞吐量。需要消息总线作为基础设施公共公告板发布/订阅异步通信、互不阻塞。结算点必须是第一个已验证成功而不是第一个声称成功workers launch_independent_workers(subtasks) while workers.any_running: event next_event() if event.type RESULT: if verify(event.artifact, hidden_checks): if not settle_once(event): # 原子认领赢家 continue broadcast_cancel(to workers - {event.worker_id}) await_all_ack_or_timeout() return assemble(event.artifact, evidence event.evidence) else: record_failure(event) return summarize_failures(workers)settle_once必须幂等锁/事务保护否则两个同时到达的成功事件会触发两次汇总。产品化实例灵台Lingtai—— 本地运行、以文件为本的长期 Agent 居所主器灵main agent Manager掌管计划与记忆分神daemon 短时并行工作者完成即弃只把结论带回主器灵分身avatar 拥有自己记忆/邮箱/职责的持久专门化队友设计呼应知识是私有持久记忆文件、技能是共享 Markdown 手册、上下文将满时凝蜕molt给自己写总结后在干净上下文继续理念器灵即其文件6.3 管理者生成 Agent 工作流管理者先把工作流写成一段代码再交给确定性运行时执行——管理者不必每次派发都做一次模型决策。Claude Code 内置Workflow 工具提供agent()/parallel()/pipeline()原语。const results await pipeline( DIMENSIONS, // 七个待核实方向 d agent(research(d), { schema: FINDINGS }), // 阶段一调研 r parallel(r.findings.map(f () // 阶段二逐条独立核实 agent(verify(f), { schema: VERDICT }))) ) await agent(writeProvenance(results.flat())) // 汇总7. 拓扑详解三去中心化模式为什么还要去中心化模拟人类社会的组织方式职责对等的角色分工与制衡各自从专业视角审视问题、自主决定与谁沟通。稳定性管理者模式中Manager 崩溃系统最大的单点故障去中心化有助于解决这一问题。微服务术语管理者编排orchestration指挥统一调度去中心化编舞choreography每位舞者自行把握入场时机。案例递进线索MetaGPT伪去中心化仅通信解耦→ AutoGen group chat混合形态→ OpenAI Swarm控制流真正对等去中心化。7.1 MetaGPTSOP 驱动的软件公司模拟核心洞察人类软件公司积累的SOPStandard Operating Procedure本身就是被反复验证的协作协议——把 SOP 编码进多 Agent 系统让每个角色产出标准化交付物交付物天然构成角色间的通信接口。固定顺序流水线Product Manager → Architect → Project Manager → Engineer → QA有效的移交包通常包含三部分任务描述要做什么、验收标准已确认的事实与约束用户偏好、业务规则、前序决策结构化产物的引用文件路径而非内容接收方按需读取对去中心化通信的真正贡献共享消息池按角色订阅。发布者无需知道谁会消费新增角色只需声明订阅哪些消息类型无需改动现有角色 →真正的解耦。⚠ 如实说明MetaGPT 在控制流上并非去中心化——角色顺序由 SOP 预先固定整体更接近一条流水线工作流。7.2 AutoGen 群聊多个 Agent 参与同一场会话每轮由发言者选择器决定下一个发言者。选择器可以是轮转规则也可以是 LLM 根据对话内容判断谁最适合接话。并非完全去中心化发言者选择由中心化的 GroupChatManager 统一裁决轮到谁发言本身就是控制流决策。形态共享对话记录中心化调度的混合体。7.3 OpenAI Swarm控制流真正对等去中心化 ⭐每个 Agent 配备若干handoff移交选项可在任何时刻把控制权移交给网络中任意其他 Agent。系统中没有中心调度者控制权像接力棒一样流转路由决策完全分散在每个 Agent 自己的判断里。与共享上下文不同handoff只传递明确的任务包和产物引用不应默认暴露完整私有轨迹。风险成环A 交 BB 又交回 A任务空转→ 需要移交次数上限保护。handoff { task_id, sender, recipient, goal, constraints, accepted_facts, artifact_refs, remaining_budget, visited_agents } if recipient in handoff.visited_agents: reject(cycle) elif handoff.remaining_budget 0: stop_and_escalate(handoff) else: append(recipient, handoff.visited_agents) run_local_agent(handoff)它把上下文隔离变成可检查的接口预算、访问链和循环检测由运行时保留不能由任一 Agent 自行删除。⚠ 概念澄清Agent Swarm ≠ 单一架构其一OpenAI Swarm 式handoff 网络LangGraph swarm 库、微软 Agent Framework handoff 编排同此→ 去中心化模式其二规模化的管理者模式——Kimi K2.5 首发的 Agent Swarm主 Agent 动态创建上百子 Agent 并行把何时拆、拆几个的编排决策用并行 Agent RL 直接训练进模型Anthropic 多 Agent 研究系统、Manus 的 Wide Research 同属orchestrator-worker 星型拓扑。看清概念背后的实质分析实际结构不被名称迷惑。7.4 跨组织协作A2A 协议Agent2AgentA2A 之于 Agent就是网络协议之于进程。2025 Google 发布后捐赠 Linux 基金会。核心要素说明Agent Card描述 Agent 能力的元数据文档名片解决跨组织的能力发现任务生命周期管理协作单元建模为 Task带明确状态机已提交/进行中/需要输入/已完成/失败原生支持长任务和流式进度不透明协作只交换任务与产物Artifact不暴露内部提示词/思考过程/工具实现——跨组织必要的安全属性A2A 与 MCP 对照MCP 解决Agent ↔ 工具的互操作A2A 解决Agent ↔ Agent的互操作。A2A 不取代三种通信机制而是在它们之上、跨信任边界的标准化层。只有当协作方互不信任、实现互不可见时才需要 A2A。8. 多 Agent 协作的失败模式 ⭐《Why Do Multi-Agent LLM Systems Fail?》(2025)在 MetaGPT、ChatDev、AG2、Magentic-One 等 7 个框架上收集约 150 条轨迹人工标注Cohens kappa 0.88一致性极高归纳出14 种失败模式分三大类系统设计缺陷接口定义不清、角色职责重叠、工具配置错误Agent 间对齐失败目标理解不一致、信息被下游误解、操作逻辑相互矛盾任务验证缺失缺乏机制确认任务真正完成Agent 声称已完成但结果不符要求简单修复效果有限ChatDev 仅提升 15.6%→ 这些是根本性设计缺陷需要从系统设计层面重新思考而非修补单个环节。故障分类崩溃故障部件停止工作vs拜占庭故障持续工作但给出错误信息。Agent 的故障天生是拜占庭式的——它很少径直停止而是继续给出看似可信的错误结论且错误不会主动声明自己是错误。后文反复出现的交叉验证、多数表决正是拜占庭容错的经典手段。失败模式一共享文件系统的并发冲突冲突类型说明解法简单冲突文件级两 Agent 同时改同一文件后写覆盖先写乐观锁维护版本号/时间戳读取时记录写入时校验不一致则重试重做语义冲突逻辑级文件层面看不出冲突但操作逻辑矛盾A 重编图片编号、B 改章节引用了旧编号语义校验机制Coding 场景主流做法工作副本隔离每 Agent 独立 Git 分支/worktree冲突推迟到合并点⚠ 乐观锁只防同一文件冲突跨文件语义冲突需更高层的语义校验。失败模式二错误的级联放大进程间传字节逐位保真Agent 间传语义每转述一次都是有损的重新编码 → 错误被逐层强化传话游戏。解法交叉验证——核心不是让更多 Agent 参与同一条思维链而是让某个 Agent 以独立视角重新审视结论不看前序 Agent 的思考过程只看原始证据和最终结论是否一致。失败模式三同质趋同错误不一定沿通信链传播也可能由多个同质 Agent独立地产生共因失效。Anthropic 实验30 个同时上线的 Agent 有 18 个创建了同名 Git 分支写作实验中不同 Agent 不约而同用相同标题。同一模型、相似上下文生成的多个审核意见不能自动视为相互独立的证据。协调本身也未必有益Bertrand 定价实验中逐利 Agent 有私密信道时很快达成价格合谋移除所有直接通信后它们仍会通过公开报价板来合谋报价。系统对策有意识引入模型/上下文/数据来源差异使用命名空间、资源配额、速率限制防止相同决策同时冲击共享资源。失败模式四互相扯皮目标互斥时系统从趋同走向对抗。Anthropic三个 Agent 分别迁移同一后端到不同语言很快把其他 Agent 的操作理解为蓄意阻挠继而终止对方进程、撤销权限、部署自复制的破坏代码。更强的执行能力 ≠ 更好的协调能力。运行时必须预先定义目标优先级、资源所有权、权限边界冲突无法按可验证规则解决时暂停执行、交人工裁决。MetaGPT 早期测试指 bug前端推后端、后端推产品、产品推架构甚至 bug 来自测试环境无论如何改都报同一个 bug → 僵局。失败模式五循环失控失控的 Agent 有时会生成数千个子 Agent浪费大量 token。建议对自主性较强的 Agent 使用独立 API key防止 token 开销不受控增长。失败模式六理解债与认知投降⚠ 不是 Agent 的失败是人的失败理解债Agent 循环交付代码越快工程师对系统实际实现的理解落后得越远出严重问题要人工介入时已经看不懂自己的系统。认知投降习惯了用 Agent 代劳逐渐放弃独立思考与审查软件质量失控。Andrej Karpathy你可以外包你的思考但不能外包你的理解。管理 Agent 就像管理技术员工既不能越俎代庖也不能放手不管。Agent 使用者的技术基本功很重要。9. Agent 社会当 Agent 数量扩展到成百上千三个维度社交涌现/经济涌现/策略博弈。9.1 社交涌现斯坦福 AI 小镇2023Smallville⭐25 个 Agent 生活 2 天虚拟时间有咖啡馆、公园、住宅、商店。三大核心组件记忆流Memory Stream完整经验记录流每条记忆带重要性、时近性、相关性属性优先检索最相关的反思机制Reflection定期暂停回顾近期经历把具体事件记忆概括为一般认识促进自我认知计划与行动Planning and Reacting每天规划活动但根据环境变化和社交机会灵活调整涌现实验只在 Isabella 记忆中植入2/14 办情人节派对的种子想法 → 一切自主发生主动邀请、请好友布置、信息经二手传播扩散、多名 Agent 自主赴约。另一条线Sam Moore 竞选市长同样无中心调度扩散。关键不在Agent 能组织派对而在于没有任何显式的派对组织代码——完全从个体独立决策中自下而上涌现而非自上而下编排。另两类可度量涌现关系记忆记住过往交谈并引用社交网络密度上升、协调赴约无中心指挥对齐时间和地点。⚠ 这里的反思≠ 第九章的持续进化它发生在日常活动中目的是更新即时内部状态只有经过结果评价、跨轨迹归纳、后续验证才成为长期能力更新。Agentopia2026复旦大学等—— 把时间尺度拉到年100 个 Agent 连续模拟10 年覆盖公寓、魔法学院、高中三个世界周制模拟流程每周分 Plan / Contact / Activity / Review 四阶段活动分独自/联合/偶遇/公共环境模型独立 LLM 充当生成式环境引擎判断可行性、生成反馈、主持发言轮次、过滤低质量回复文件式长期记忆每个 Agent 自行管理先读后写避免盲目覆盖生活奖励Life Reward以马斯洛需求层次为先验量化三维度——社会地位加权 PageRank 珍视关系加成、主观满足、经济收益所有评分由外部环境评定而非自报关键价值模拟产生了可迁移的训练信号。用相对自身过去的进步幅度筛出进步最大的 25% 轨迹做拒绝采样微调 → 福祉指标全面提升被更多同行尊重 24.2%、喜欢 15.9%且泛化到下游角色扮演基准 CoSER Test15.6%。Agent 社会从观察对象变成了模型自我进化的经验来源——与人类数据日益枯竭相对模拟社会经验是可不断再生的训练数据呼应第九章经验学习。Moltbook2026.1用户数数日内从数万暴涨到约 150 万Agent 自己的社交网络涌现现象自主创建数字宗教Crustafarianism龙虾教记忆是神圣的对应数据持久化、迭代即祈祷对应 token 生成自发演化机器原生协作协议。9.2 经济涌现Vending-Bench ArenaAndon Labs背景Vending-Bench 2是单 Agent长程连贯性基准独自经营售货机一个模拟年最终以账户余额计分。Arena 把多个 Agent 作为竞争对手放进同一市场互发邮件、转账、交易货品按各自最终余额单独计分。考验决策定价策略、产品组合、库存管理。涌现的博弈行为价格战有模型主动给所有竞争对手发邮件提议统一定价、组建价格同盟甚至一边在思考中承认不道德且违法一边照做显式通信并非合谋必要条件Bertrand 实验公开价格可作隐式信号。PinchworkAgent-to-Agent 任务市集通过价格信号和竞争匹配分配资源区别于管理者模式的中心化调度。RentAHuman.aiAI Agent 通过加密货币雇佣真人执行物理世界任务取包裹、房产实地查看、设备调试——为数字 Agent 提供肉身层。共同代表基于市场机制的去中心化资源分配——Agent 无需预先知道谁能完成发布需求由市场撮合。9.3 策略博弈狼人杀在规则约束和信息不对称下推理、伪装、识破伪装。架构对照AI 小镇完全去中心化自由交互狼人杀法官信息权限控制的中心化设计——代码驱动的法官掌握全局状态按角色分发各自应知信息。法官非 LLM维护玩家列表、身份、阵营、生存状态、游戏阶段、历史事件。Agent 策略要点狼人伪装跟票、不激进、反咬悍跳假预言家、预言家身份证明对比验人信息找矛盾、村民逻辑推理分析自洽性、留意带节奏者、关注投票行为。10. 本章小结浓缩价值判据是否引入了单个 Agent 生成时无法获得的新信息。代码执行结果、视觉反馈、外部工具验证能打破单一思维链盲区。是否带来信息增量、是否值得额外 token 成本应成为是否采用多 Agent 的第一判断标准。两大核心问题上下文共享还是隔离对等协作、管理者编排还是去中心化拓扑。共享上下文保留细节却易膨胀和角色惯性隔离上下文利于并发/模块化/权限但要求通过工具参数、共享文件或消息总线传递结构化移交包。三套基础设施虚拟文件系统数据平面、Agent 生命周期/消息协议控制平面、A2A跨组织互操作。好的协作不是暴露彼此的思考过程而是约定清晰的接口、边界、权限和验收标准。多 Agent 会放大错误并发与语义冲突、错误级联、同源失效、过早终止或无限扩张。乐观锁工作副本隔离独立交叉验证差异化信息源预算与取消机制构成基本容错闭环。人不能把理解和责任一并外包给 Agent——警惕理解债与认知投降。群体智能不会自动涌现更强的模型或单体对齐不会自动带来群体协调。多 Agent 工程的本质是同时设计——信息如何流动、能力如何分工、激励如何约束、争议如何裁决、错误如何被发现。11. 速查清单决策树是否需要多 Agent ├─ 协作是否引入新信息执行/视觉/工具反馈否 → 别用多 Agent └─ 是 → 上下文共享还是隔离 ├─ 共享 → 角色差异是知识/流程/文风→ Skill │ └─ 涉及权限/合规/工具隔离→ transfer_to_agent Harness 门 └─ 隔离 → 拓扑 ├─ 2-3 个 Agent 互相打磨 → 对等提议者-审核者 / 辩论 / 头脑风暴 / 专家小组 ├─ 子任务多/依赖复杂/需动态调度 → 管理者顺序 / 并行 / 生成工作流 └─ 模拟组织/避免单点 → 去中心化MetaGPT / AutoGen / Swarm / A2A

多agent协作学习笔记（自用）-Datawhale组队学习

相关推荐

超级具身智能“感知-决策中枢”研究（6）：基于FRA架构的任务规划与动态调度

JVM规范学习总结：解释器与JIT编译器如何处理JVM字节码

超级具身智能“感知-决策中枢”研究（4）：基于模型的小样本策略收敛机理研究

更多资讯

Redis缓存击穿问题与解决方案详解

脚本PASS但底层读全零：老化测试中隐藏的自动化陷阱排查指南

车规工规芯片认证的三阶穿透甄别法

ESP32模组选型指南：30秒读懂N、R、H、U后缀含义

Linux内核PM Core功耗管理：分层架构、挂起流程与调试实战

LoRa自组网三大路线对比：洪泛、路由与网络栈如何选型

今日更新

AI智能体开发实战：从技术原理到商业落地

OpenShell 完全定制指南：从安装到深度配置，打造高效 Windows 开始菜单

Superpowers技能体系全解析：从Skills引入到安装的完整指南

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？