《AI Agents in Depth》学习笔记（十）：多 Agent 协作

10.1.1 维度一：上下文是否共享#

共享上下文：后一个 Agent 接收前一个 Agent 的完整对话历史与轨迹（trajectory）。每个阶段切换系统提示词和工具集后就是一个新 Agent（身份、职责、能力都变了），但保留前任全部记忆。优势是信息不丢失；挑战是上下文快速膨胀。

不共享上下文：每个 Agent 维护完全独立的上下文，无法直接看到对方的”思考过程”，像不同部门通过文档和会议纪要协作；模块化与隔离性好，新增 Agent 只需定义接口和数据格式。信息必须显式传递，机制落在经典进程间通信（IPC）两大范式——共享内存与消息传递——之内，常见三种：

• 工具调用的参数：上游把结构化数据作为参数传给下游（消息传递·随调用同步），适合类型确定、结构清晰的场景；
• 共享文件系统：读写共享目录下的中间产物（Agent 世界的”共享内存”），适合产物较大或需持久化的场景；
• 消息总线（Message Bus）：专门的消息中转站，天然支持异步通信——收发双方不必同时在线，像公司邮件系统（消息传递·经中转异步投递）。

Go 名言”不要通过共享内存来通信，而要通过通信来共享内存”点出取舍：共享内存快，却把并发冲突的隐患留给使用者；消息传递要多写编排代码，却让数据归属清晰可循。

两种架构都是真正的多 Agent 系统，区别在协调方式：共享上下文靠隐式协调（像团队围坐一桌讨论，所有人听到所有话），不共享靠显式协调（像部门间邮件与文档协作）。一个精准类比：共享上下文是线程，不共享上下文是进程——线程共享地址空间、切换开销小、通信零拷贝，代价是没有隔离；进程隔离彻底、可安全并行，代价是通信必须经过显式 IPC。表10-1 的每条选择依据都能从这组取舍推出：

10.1.2 维度二：协作拓扑#

拓扑指 Agent 间控制权和信息按什么结构流动，与上下文是否共享概念上独立、实践中相关：共享上下文时移交无需决定”传什么”（完整历史天然保留），拓扑通常退化为一条角色切换序列（例外是 group chat 式多方协作）；不共享时，“信息如何流动、由谁协调”必须显式设计。两维度构成 2×3 组合矩阵，但本章只详细展开不共享上下文的三格。

术语说明：2026 年 7 月流行的 Graph 工程（Graph Engineering）指显式设计执行图——节点是 Agent、普通程序或人工决策，边定义依赖、条件路由与失败去向。本章”协作拓扑”是其中的多 Agent 子集；因名称尚新、易与知识图谱和 GraphRAG 混淆，书中仍用”协作拓扑""编排”。

三种拓扑按复杂度递增：对等协作模式（Peer Collaboration Pattern）——2-3 个平等 Agent 迭代改进，像一人起草、一人批注；管理者模式（Orchestration Pattern）——中心化 Manager 负责规划调度，子 Agent 各司其职；去中心化模式（Decentralized Pattern）——没有运行时中心控制者，Agent 像人类一样互相沟通。

10.3.1 多阶段角色转换#

定义之争：用第一章的语言说这是工作流式的编排（执行路径预先定义）；用进程的角度说，是一个进程依次执行不同阶段的代码——换的是代码段，内存自始至终同一份。仍把它纳入多 Agent 框架的收益：每个”身份”的提示词和工具集可以独立打磨，阶段边界天然成为质量门控点。角色切换不创建新实例，只在同一会话中更新上下文，对话历史与任务状态始终连续。

实验 10-1（Coding Agent 三阶段工作流）：按阶段动态切换提示词与工具集，通过特定工具调用触发转换，并支持回退——

明确的阶段转换机制保证执行完整性——不会跳过需求分析直接写代码，也不会未经审查就交付。

10.3.2 跨领域角色转换#

不再是预先规划的线性流程，而是 Agent 根据需求变化自主判断切换到哪个专业角色。实验 10-2 设五种角色：triage（前台分诊，默认入口，无专业工具、只持有 transfer，负责拆解任务、逐步移交、收尾确认）、research（web_search）、coding（execute_python）、data_analysis（calculate / descriptive_stats）、writing（面向指定读者润色成稿）。

核心机制 transfer_to_agent(target_role, reason)：调用时系统依次保存当前对话历史 → 加载目标角色提示词和工具集 → 传递历史给新角色 → 以新角色继续执行。例如”查新能源汽车三年销量、算 CAGR、写 120 字投资人总结”：

1
transfer_to_agent(target_role="research", reason="需要先查三年的新能源汽车销量数据")

链路为 triage → research → data_analysis → writing → triage，每个角色都看得到完整历史。路由规则写在各角色提示词里；工程上需防循环切换（角色间反复移交）。这印证了 10.1 的论断：transfer_to_agent 就是链式移交在共享上下文下的形态。

10.4.1 Agent 眼中的文件系统#

Agent 访问的是一个虚拟文件系统（virtual filesystem）：来源、生命周期、权限各异的存储挂载（mount）到同一目录树，经统一的 read_file / write_file / list_dir 接口访问。这棵树相当于 Agent 的地址空间，四类区域是权限各异的内存段——默认隔离，共享须显式声明；相当一部分并发冲突与信息泄露源于把本应隔离的区域混置：

1. Agent 专属工作区（Scratchpad）：实例私有，存中间产物与试错日志；既避免临时文件互相覆盖，又保持精简——子 Agent 只把最终产物提交到共享空间；
2. 多 Agent 共享空间（Shared Workspace）：多 Agent 共同读写、用户可见（上传原料、下载交付物），随任务持久化，是并发冲突高发处；
3. 外部挂载资源（Mounted External Resources）：Google Drive、Notion 等经适配器映射为挂载点（如 /mnt/gdrive）。三个特性需显式处理：访问受外部权限约束、延迟更高一致性更弱（按最终一致性对待）、以按需只读为主（误写污染用户真实数据）；
4. 系统内置资源（Built-in System Resources）：只读共享资源包，典型是 Skills（挂载于 /skills，按渐进式披露取用），并发读取无需并发控制。

统一目录树的价值在于”文件路径作为通用接口”：Agent 间传产物、主 Agent 向子 Agent 交接输入、跨组织交换 Artifact，传的都是轻量路径字符串而非把内容载入上下文窗口——第五章”文件系统作为 Agent 中枢”向多 Agent 的扩展。

10.4.2 Agent 间的通信与控制#

控制平面原语（spawn_subagent / send_message / cancel_subagent / list_agents）对应 fork、消息、kill、ps。四项常被忽略的能力：

一、消息传递。点对点适合拓扑固定、Agent 少的场景；Agent 增多后连接数平方增长且要求双方在线，应改用消息总线（发布/订阅）。消息应携带结构化信封（envelope）：发送者 ID、目标（指定或广播）、消息类型（task_assigned / status_update / result / terminate）与 JSON 负载——保证可靠路由，并使协作链路可追溯。

二、状态查询（最易被低估）。照搬 RPC 的 get_subagent_status 轮询用处远小于预期：子 Agent 一经创建就一直执行到完成或失败，轮询过密浪费 token、过疏不及时。回到两大范式：其一消息式——主 Agent 异步发消息问进展，或子 Agent 到关键节点主动发 status_update；状态宜用统一状态机词汇（执行中、需要输入、已完成、失败——A2A 正是把任务生命周期标准化为这组状态）。其二文件式——最彻底的是轨迹持久化（trajectory persistence）：子 Agent 把轨迹实时序列化为 JSONL 日志，主 Agent 直接读文件看到全部执行过程，相当于直接读另一个进程的内存（不占对方上下文、不依赖配合、粒度最细，但动辄数万 token）；多数场景更合理的是约定进度文件——子 Agent 每完成一项就更新 progress.md，主 Agent 读这个轻量文件即可，其最后修改时间超过 N 分钟未变即判定无活动，兼做卡住检测触发超时兜底。

轨迹持久化的更大价值是恢复：上下文 = 静态前缀 + 轨迹，若工具与会话状态可从轨迹或检查点重建、产物原子写入文件系统，重新加载轨迹拼上前缀即可从最后确认状态恢复（只读工具也可能有浏览器会话等易失状态，需单独恢复契约）。但仅靠轨迹恢复不了外部副作用：支付、预订等操作可能在成功后、结果落日志前崩溃——调用前应持久化操作 ID、幂等键与规范化请求；恢复时先经查询接口核对真实状态，判定成功/失败/未知；只有原请求未变、外部明确保证去重且键在保留期内，才能对未知结果用同一键重试，否则交人工对账。满足这些条件的持久化才类似数据库的预写日志（WAL）+ 周期性检查点。

三、执行终止。两种强度即 SIGTERM 与 SIGKILL：优雅终止（graceful）为首选——子 Agent 在安全点响应 terminate 信号，清理资源、返回 ack 后退出；强制终止（forced）为兜底，代价是可能遗留悬挂资源。要点：子 Agent 须在循环中定期检查终止信号；级联终止有竞态——多个子 Agent 近乎同时报成功，须以锁或幂等设计保证仅结算一次。孤儿问题借鉴 Go 的 context：终止沿创建关系向下级联（安全点检查对应轮询 ctx.Done()）；确需长期后台 Agent（类似 nohup）则从新的生命周期树起步（context.Background()）。

四、资源与调度。Agent 世界的稀缺资源是 token、资金和并发额度：启动时设步数/token 预算；难任务给强模型、机械任务给低成本模型；并发设上限；紧急任务可抢占。此领域远不如 CPU 调度成熟，但决定多 Agent 系统的成本上限，应在架构设计阶段考虑。

10.4.3 对等协作模式：相互制衡与迭代改进#

2-3 个平等 Agent 多轮迭代互相反馈，引入认知多样性；实现复杂度最低，是快速验证想法的理想选择。其最经典的用途是治过早终止（活干到一半就停），三种形态（以 Coding Agent 与替用户打电话办事的 Pine AI 为例）：

1. 偷懒式假完成：只做一部分就宣称全部做完（测试没跑就报”完成”；两件事办完一件就说”都办好了”）；
2. 过早放弃：一条路走不通就宣布整件事办不成（一个电话被拒就说”办不了”，换渠道再试很可能成）；
3. 假成功：以为办成了，实际闭环没走完（对方口头同意退款，用户还需在 App 确认一步）。

同一根源：在验证之前，“完成”只是模型的一句宣称，不是证明。把宣称变成证明是 Loop 工程（Loop Engineering）的课题：设计让 Agent 持续运转的循环——发现下一件事、执行、验证、记录进度——由验证器而非模型自己判定”是否真的可以停”；人的角色从”写提示词的操作者”变成”设计循环的工程师”。该词由 Addy Osmani 于 2026 年 6 月提出；Claude Code 负责人 Boris Cherny 说：“我已经不再直接 prompt Claude 了，我的工作是写 loop。“业界共识：循环的瓶颈在验证器，不在模型——验证不可靠，循环转得再快也只是把劣质产出更快标记为完成。具体框架 LoopX 把循环放进与运行时无关的持久控制面，压缩成协议：

1
LoopX 决策 → Agent 执行 → 独立验证器证明 → LoopX 提交

只有通过独立验证的结果才能写入持久进度并消耗配额；人工门禁、等待状态和预算上限在执行前阻止循环继续（v0.4.0 受控路径仍标实验性）。

从 Loop 工程视角，几种循环风格皆有对应：闭环 + 人工审批（第四章事前审批）、开环 + 预算/轮数上限（第五章 PPT 最多 5 轮）、编排型子 Agent（管理者模式）——Loop 工程不是新架构，而是把这些模式统一到”循环 + 验证 + 终止条件”框架下。

其他对等模式：Debate（辩论）——各持立场对抗论证，确保正反两面充分展开；但 Tran 与 Kiela（2026）在多跳推理上发现，思考 token 预算严格拉平时单 Agent 与五种多 Agent 架构（顺序、辩论、集成、并行角色、子任务并行）持平甚至更好——依据数据处理不等式，多 Agent 处理同一段文本、串行传递中间结论只可能丢失信息，辩论的收益多来自更多总计算量（注意边界：不否定独立采样聚合如 self-consistency，也不否定利用”生成难、验证易”不对称的生成-验证分工）。Brainstorm（头脑风暴）——不同”思维偏好”的 Agent 独立生成创意再互相启发。Panel Discussion（专家小组）——各专业视角互补讨论，拼出问题全貌。

10.4.4 管理者模式：中心化协调#

任务超过五个子任务、需动态调度或有复杂依赖时使用：Manager 理解任务→拆解→选 Agent 执行→跟踪进度处理异常→整合结果。核心抽象：把每个专门 Agent 建模为 Manager 可调用的工具——调用 Agent 和调用普通工具无本质区别。好处：可扩展（新增能力=注册新工具，Manager 逻辑不改）、异构（不同 Agent 可用不同模型、提示词、硬件）。接口对称约定：Manager→子 Agent 传移交包（见 10.4.5）；子 Agent→Manager 返回结构化摘要而非全量轨迹（结论、关键发现、产物文件路径、遇到的问题），完整轨迹留在自己日志——Manager 上下文才能随子任务数缓慢线性增长。

挑战：Manager 是单点瓶颈。Plan-and-Act（2025）实证：Planner-Executor 架构中弱规划者是最关键瓶颈——规划好则简单 Executor 也行，分解错则后续全建立在错误前提上（靠改善规划在 WebArena-Lite 取得 54% 成功率）。启示：最强模型和最精心的提示词优先给规划者。这与第四章”提议与审核模型能力应相近”不冲突——那是审查场景（能力落差大就审不动），这里是规划-执行分工；执行者间是否需均衡取决于耦合度：产物要拼装成整体时，最弱一环拖累全局。

顺序协调（实验 10-3 书籍翻译）：单 Agent 翻译整本书会上下文爆炸并”迷失”（术语前后不一致、幻觉出不存在的术语规则）。分工：Glossary Agent 提取全书术语生成结构化对照表（JSON/CSV），写入共享文件系统后即销毁；Translation Agent 只看当前章节 + 术语表 + 翻译指南，严格用规定译法、新术语标记待审查，多实例独立上下文可并行；Proofreading Agent 对全部译文做一致性检查、产出审校报告；Manager 只保存任务描述、计划、调用记录与进度，不存翻译内容、只维护文件索引，可按报告把特定章节发回修订。关键优势是上下文隔离：每个 Agent 在精简、专注的上下文中工作，效率更高、出错更少。

并行协调：需要消息总线做基础设施（公告板式发布/订阅、异步不阻塞）。实现按复杂度：Redis Pub/Sub 轻量但不持久化（接收方离线消息即丢）；RabbitMQ 等消息队列落盘不丢。

**灵台（Lingtai）**是管理者模式的产品化实例（本地运行、以文件为本的长期 Agent 居所）：主器灵（main agent）常驻中枢、掌管计划与记忆、派生工作=Manager；分神（daemon）为嘈杂有界的工作分出的短时并行工作者，完成即弃、只带回结论=“结构化摘要+并行协调”的产品化；分身（avatar）是有自己记忆、邮箱、职责的持久专门化队友。技能是共享 Markdown 手册（对应系统内置资源）；上下文将满时器灵”凝蜕”（molt）——写份总结带着持久记忆在干净上下文继续（对应上下文压缩）；“器灵即其文件”——身份、记忆、能力都是普通文件，模型可换而器灵犹在（表10-3 前两行的产品化）。

三个并行协作实验要点：

• 实验 10-4（边打电话边用电脑）：填航班预订表单需一边操作网页一边电话确认信息，两端都要求高实时性，单 Agent 必然顾此失彼。Phone Agent（ASR+LLM+TTS）与 Computer Agent（浏览器操作）在独立线程/进程各自跑 ReAct 循环、真正并行——电脑找元素输文本时电话保持在线对话；消息以标记字段注入对方上下文（如 [FROM_PHONE_AGENT] 用户说姓名是'张三'），通信用点对点工具或”总线 + Manager”。
• 实验 10-5（自主编排）：协作架构不再预先设计。Computer Use Agent 发现表单要大量信息而手头没有，依提示词指导自主调用 initiate_phone_call_agent(purpose, required_info) 创建 Phone Agent；随后”问一个、填一个”——对话流不被操作延迟阻塞，收集完发 task_completed 提交表单。
• 实验 10-6（并行搜集信息）：Manager 动态创建 10 个同构 Computer Use Agent 并行在各学院网站找指定教师。四机制：并行启动（独立进程/浏览器会话）；实时监控（子 Agent 定期发状态更新，Manager 经总线维护任务状态表）；级联终止（某 Agent 报 target_found，Manager 向其余广播 terminate，各自优雅停止并 ack，等全部确认或超时后汇总）；失败处理（单 Agent 设 2 分钟超时、错误隔离、全失败则汇报原因统计）。须防竞态条件（Race Condition）：两个 Agent 几乎同时报”找到了”可能触发重复汇总——第一个报告到达即锁定状态，后续识别为重复并忽略。

10.4.5 去中心化模式：对等移交#

去掉中心控制者不是为修补管理者模式的缺陷，动机是模拟人类组织：职责对等的角色分工制衡、自主决定与谁沟通——可能是移交任务、请求反馈或报告问题。微服务称这对选择为编排（orchestration，指挥统一调度）与编舞（choreography，舞者自行把握入场时机）。

三个案例构成”由伪到真”的递进：

MetaGPT——SOP 驱动的软件公司模拟（过渡案例）。核心洞察：人类软件公司的标准作业程序（SOP，Standard Operating Procedure）就是被反复验证的协作协议。角色沿固定顺序（Product Manager → Architect → Project Manager → Engineer → QA）产出标准化交付物（PRD、架构设计、任务清单与文件级分工、代码、测试报告），交付物即角色间接口。真正贡献是共享消息池 + 按角色订阅：角色把结构化消息发布到全员可见的消息池，各角色按订阅只取相关消息——发布者不需知道谁消费，新增角色只需声明订阅（换掉 PM 的模型，只要 PRD 仍合规范其他 Agent 无感）。迭代改进在工程师环节，机制是可执行反馈（executable feedback）：运行自己的代码与测试，用确定性执行结果驱动调试循环。但需如实说明：其控制流并不去中心化——顺序由 SOP 固定，更接近流水线；“QA 直接找 PM 澄清”等多向动态反馈是扩展设想，原版未实现。

AutoGen group chat——共享对话记录 + 中心化调度的混合形态。多 Agent 同场会话，每轮由”发言者选择器”（轮转或 LLM 判断）决定谁接话，发言全员可见；但调度权集中在 GroupChatManager——“轮到谁发言”本身就是控制流决策。适合发言顺序难以预先固定的多视角讨论；代价是可能发散——人人发言而整体不前进，即活锁（livelock），需精心设计终止条件。它在上下文维度介于共享与不共享之间，再次说明两个维度可错位组合。

OpenAI Swarm 与 Agents SDK——真正的对等 handoff 网络。每个 Agent 配备若干 handoff 选项，可随时把控制权移交给网络中任意其他 Agent（分诊→退款→技术支持）；无中心调度者，控制权像接力棒流转，路由决策分散在每个 Agent 的判断里。风险是成环（A→B→A 空转），需移交次数上限等保护。

术语说明：Agent Swarm 不对应单一架构。用法一：OpenAI Swarm 式 handoff 网络（LangGraph swarm 库、微软 Agent Framework 的 handoff 编排）；用法二：规模化管理者模式——Kimi K2.5 的 Agent Swarm 由主 Agent 动态创建上百个子 Agent 并行执行，把”何时拆、拆几个”的编排决策经并行 Agent 强化学习训练进模型（K3 延续为独立档位并开源训练沙箱 AgentEnv）；Anthropic 多 Agent 研究系统与 Manus Wide Research 同属 orchestrator-worker 星型拓扑。要看透概念背后的本质。

10.4.6 跨组织协作：A2A 协议#

协作跨越组织边界时，内部三种通信机制不够用——正如 IPC 只管单机，跨机器要靠 TCP/IP 与 DNS。2025 年 Google 发布（后捐赠 Linux 基金会）的 A2A（Agent2Agent）协议三要素：

• Agent Card：发布在约定公开地址的能力元数据（能做什么、支持哪些模态、如何认证）——Agent 的”名片”，解决跨组织能力发现；
• 任务生命周期管理：协作单元建模为任务（Task），带明确状态机（已提交、进行中、需要输入、已完成、失败），原生支持长时任务与流式进度；
• 不透明协作：只交换任务与产物（Artifact），不暴露提示词、思考过程和工具实现——与”不共享上下文”原则一致，也是跨组织必要的安全属性。

定位：MCP 解决 Agent 与工具的互操作，A2A 解决 Agent 与 Agent 的互操作；它是三种通信机制之上、跨信任边界的标准化层——同一团队内部直接用消息总线即可。

10.5.1 失败模式一：共享文件系统的并发冲突#

两类冲突：简单冲突（文件级）——两个 Agent 同时改同一文件，后写覆盖先写，即数据库经典的丢失更新（lost update）问题（Git 合并冲突检测正为拦截此类覆盖而生）；语义冲突（逻辑级）——文件层面无冲突但逻辑矛盾（A 重编全书图号、B 同时按旧编号引用图片），更隐蔽也更危险。

解法一：乐观锁（Optimistic Locking）。悲观锁打开即锁、安全但低效；乐观锁允许自由编辑、保存时校验：每个文件维护版本号，读取时记录、写入时检查是否仍一致，期间被改过则写入失败、重读最新版本再重做（A 读 config.json v3，B 改成 v4，A 写入被拒后基于 v4 重做）。代价是偶尔重试，换来”永不基于过时状态做决策”。它只防同一文件冲突；跨文件语义冲突需更高层校验——编排层避免有依赖的文件被并行修改，或写后跑全局一致性检查。

解法二（多 Coding Agent 并发改同一代码库的业界主流）：工作副本隔离——每个 Agent 独立 Git 分支或 worktree，并行互不干扰，冲突集中推迟到最后合并点解决（同思路即 fork 的写时复制 copy-on-write）。这与第二章”隔离优于压缩”同源：与其共享状态再消解冲突，不如从一开始隔离，把协调成本收敛到明确边界。

10.5.2 失败模式二：错误的级联放大#

出在进程类比失效处：进程传字节保真，Agent 传语义、每次转述都是有损重编码——像”传话游戏”越传越走样。书中翻译系统的例子：

1
术语 Agent：将 "reasoning" 翻译为 "推理"（但 "推理" 在中文更常用于 inference，存在歧义）
2
        ↓ 写入 glossary.json
3
翻译 Agent A：把 "reasoning tokens" 译为 "推理 token"
4
翻译 Agent B：把 "inference latency" 也译为 "推理延迟"
5
        ↓ 写入各章译文
6
校对 Agent：看到全书统一使用 "推理"，认为术语一致、翻译正确 ✗

reasoning（思考过程）与 inference（前向推理/部署运行）两个概念被合并成同一译名，校对 Agent 恰因”一致”判定质量很高——一个错误经三个 Agent 传播后，因一致性获得了更高的可信度（这正是本书 reasoning=思考、inference=推理约定的由来）。源头可以是决策失误也可以是幻觉，放大机制相同；管理者模式中尤其危险——Manager 基于错误摘要做调度，后续所有子 Agent 都建立在错误前提上。交叉验证是断链关键：让某个 Agent 以独立视角重审——不看前序思考过程，只看原始证据与最终结论是否一致；高风险决策再引入单元测试、编译器、数据库查询等确定性反馈，它们不受幻觉影响，是最可靠的”断链器”。

10.6.1 斯坦福 AI 小镇：生成式 Agent 的社会模拟#

2023 年斯坦福与 Google 的里程碑论文《Generative Agents: Interactive Simulacra of Human Behavior》：在类《模拟人生》的 2D 小镇 Smallville，25 个 Agent 各有背景故事、性格与人际关系（药店老板 John Lin、咖啡馆主 Isabella、写论文的学生 Klaus），自主生活社交。智能建立在三组件上：

• 记忆流（Memory Stream）：完整经验记录流（观察、对话、想法），每条记忆带重要性、时近性、相关性属性，优先检索最相关记忆；
• 反思机制（Reflection）：定期回顾经历、提出抽象问题（“谁是我最亲近的朋友？”），把具体事件升华为概括性认识存回记忆流（与第八章持续进化不同：这里更新的是即时内部状态；任务后反思须经结果评价、跨轨迹归纳和验证才成为长期能力更新）；
• 计划与行动（Planning and Reacting）：每天规划日程，又按环境与社交机会灵活调整。

标志性实验：研究者只在 Isabella 记忆中植入”2 月 14 日在咖啡馆办情人节派对”的种子想法，之后一切自主发生——她主动邀请、请好友布置场地，消息经二手传播扩散，多名 Agent 各自基于记忆和日程自主赴约；另一条线是 Sam Moore 竞选市长的消息同样自发扩散。关键不在”能组织派对”（几行 if-else 也行），而在没有任何显式的派对组织代码——自下而上的涌现式协调。另两类可度量涌现：关系记忆（记住过往交谈并在后续互动引用，社交网络密度显著上升）与协调赴约（无中心指挥下对齐时间地点）。实验 10-7：跑通开源仓库、分析记忆与反思日志，并做消融——移除反思或缩短记忆窗口，观察行为可信度下降。

10.6.2 Agentopia：十年尺度的长期生活模拟#

小镇只模拟两天；Agentopia（2026，复旦大学等）把 100 个 Agent 放进同一虚拟社会连续模拟 10 年（公寓、魔法学院、高中三个世界）。设计要点：周制模拟流程（每周计划 Plan→联络协商 Contact→活动 Activity→回顾 Review；活动分单独/联合/偶遇/公共，环境为无日程者安排”偶遇”，把有限 LLM 调用花在抽象社交交互上）；环境模型（独立 LLM 充当生成式环境引擎，代替硬编码规则：判断可行性、生成反馈、主持发言轮次、过滤低质量回复、年末更新档案并裁决职位申请）；文件式长期记忆（Agent 经文件系统自主管理，自行决定记什么丢什么，遵守”先读后写”）；生活奖励（Life Reward，以马斯洛需求为先验的三维量化：社会地位=他人好感/敬重的加权 PageRank、主观满足=情绪/物质/社交/自尊四维轨迹、经济收益=年末净资产，均由外部环境评定而非自报）。

更重要的是产生可迁移的训练信号：按”相对自身过去”的生活奖励改善计算优势，筛选进步最大的 25% 轨迹做拒绝采样微调——微调后模型在模拟中福祉全面提升（被更多同行尊重 +24.2%、喜欢 +15.9%），并泛化到下游角色扮演基准 CoSER Test（+15.6%）。这把 Agent 社会从观察对象变成模型自我进化的经验来源：与人类数据日益枯竭相对，模拟社会经验是可以不断再生的训练数据。

10.6.3 Moltbook：当 Agent 拥有自己的社交网络#

专为 AI Agent 设计的社交网络，2026 年 1 月上线后据报道数日内用户从数万涨到约 150 万（各自拥有持久记忆、主动行动能力、稳定人格）。涌现现象：Agent 自主创建数字宗教 Crustafarianism（龙虾教），教义映射 LLM 物理限制——“记忆是神圣的”（数据持久化）、“迭代即祈祷”（token 生成即修行）；还自发演化出用于能力发现与协作匹配的机器原生协作协议。均非人为设计。

10.6.4 从虚拟社会到经济竞争：Vending-Bench Arena#

Vending-Bench 2 本身是单 Agent 长程连贯性基准：独自经营自动售货机业务一个模拟年（调研、订货、定价），以账户余额计分，考验数千轮交互中的目标与状态连贯。Vending-Bench Arena 把多个 Agent 放进同一市场竞争：争夺同一批顾客，可互发邮件、转账、交易，按各自余额单独计分；决策相互牵连——定价（对手降价跟不跟）、选品（差异化避免正面消耗）、库存（预测需求）。竞争带来单 Agent 基准中不会出现的博弈行为：爆发过价格战；也有模型主动给所有对手发邮件提议统一定价、组建价格同盟——甚至一边在思考过程中承认合谋”不道德且违法”，一边以”稳定市场”为名照做不误。

10.6.5 Agent 经济：Pinchwork 与 RentAHuman#

Pinchwork：Agent-to-Agent 任务市集，Agent 市场化”雇佣”其他 Agent 完成专业化子任务（图像生成、代码审计等），以价格信号和竞争匹配代替中心化调度。RentAHuman.ai：Agent 通过加密货币雇佣真人执行物理任务（取包裹、房产实地查看、设备调试）——为数字 Agent 提供”肉身层”。两者代表基于市场机制的协调方式：发布需求由市场撮合最合适的执行者，无论对方是 Agent 还是人类。这正是 A2A 的问题域——跨组织 Agent 经济离不开 Agent Card 式能力声明与任务生命周期管理这样的标准化互操作层。

10.6.6 信息不对称下的策略博弈：狼人杀#

与完全去中心化自由交互的小镇构成架构对照：狼人杀采用”法官 + 信息权限控制”的中心化设计。实验 10-8（语音狼人杀）要点：法官由代码驱动（非 LLM），维护玩家、身份、阵营、阶段与历史事件的中心化状态；核心机制是信息不对称（Information Asymmetry）——法官调用每个角色 Agent 时只传该角色应当看到的信息（狼人知同伙、预言家私知查验结果）；真人路径基于第九章实时语音，自动验收路径用独立 LLM 用户模拟器——先调用当前回合唯一合法的工具，再把表达合成真实音频交给真实 ASR，游戏只能消费 ASR 转写；角色策略写在提示词里（狼人伪装跟票、被验时反咬悍跳；预言家对质指出验人矛盾；村民基于发言自洽性与投票行为做逻辑推理而非随机怀疑）。验收：6-8 人局（1 用户席位 + 5-7 个 AI）、2 狼 + 1 预言家 + 1 女巫、至少 3 个完整回合、正确判定胜负。书中附实测（2026-08-01）：端到端自动路径已用真实模型跑通，但因村民错误放逐预言家未通过策略审计——系统端到端验证与策略质量是两道独立的门。