设计或评审多 Agent 系统、判断该用单 Agent 还是多 Agent 时使用——选择对等/管理者/去中心化协作拓扑、决定上下文是否共享、设计 Agent 间通信与共享文件系统、诊断多 Agent 失败模式（并发冲突、错误级联、同质趋同、互相扯皮、循环失控）。
覆盖协作架构选择依据、多 Agent 优于单 Agent 的新信息判据、控制平面四原语与虚拟文件系统四类区域的设计检查表。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
| 任务特征 | 选择 |
|---|---|
| 2-3 个角色，需要互相反馈、多轮迭代提质 | 对等协作（起草者/评论者、提议者/审核者） |
| 子任务多、需要动态调度、子任务间有复杂依赖 | 管理者模式（Manager 规划 + 子 Agent 执行） |
| 需职责对等的角色自主决定与谁沟通，或管理者不能成为单点故障 | 去中心化模式（handoff / 消息池订阅） |
| 开放搜索空间，需要广覆盖与多样化发现路径 | 多 Agent 并行（用更高 token 预算换覆盖） |
对等协作实现复杂度最低：定义好两个 Agent 的角色、通信机制和迭代终止条件即可跑起来。
transfer_to_agent / 替换 system prompt | Skill | |
|---|---|---|
| 工具可见性 | 只暴露当前角色工具 | 通常固定暴露全集 |
| 前缀缓存 | 每次切换改变请求前缀，缓存从变化点起失效 | 静态前缀不变，Skill 内容追加到末尾轨迹，前缀可复用 |
| 约束能力 | 强：越界工具在 schema 层不可见 | 弱：Skill 是行为指令，硬权限仍需 Harness 门 |
判据：角色差异主要来自知识、流程、写作风格 → 用 Skill；涉及权限、工具隔离、合规边界、需运行时强制禁止某类动作 → 用独立 Agent 或 transfer_to_agent，并在 Harness 层用代码限制。
| 区域 | 可见性 | 生命周期 | 读写 | 并发控制 |
|---|---|---|---|---|
| Agent 专属工作区（Scratchpad） | 仅该 Agent | 随实例销毁 | 读写 | 不需要 |
| 多 Agent 共享空间（Shared Workspace） | 所有协作 Agent + 用户 | 随任务持续，需持久化 | 读写 | 需要（乐观锁 / worktree） |
| 外部挂载资源 | 视外部授权而定 | 由外部源决定 | 多为只读，写需谨慎 | 由外部源负责 |
| 系统内置资源（Skills 等） | 所有 Agent | 跨会话稳定 | 只读 | 不需要 |
要点：隔离 scratchpad 既避免临时文件互相覆盖，也保持主上下文精简（子 Agent 只把最终产物提交到共享空间）；外部挂载需显式处理权限约束、弱一致性与"按需只读"；相当一部分并发冲突与信息泄露源于把本应隔离的区域混置。
task_assigned/status_update/result/terminate、JSON 负载）。统一信封使链路可追溯——这是多 Agent 调试的关键。get_status。更自然的是消息传递（问一句"进展如何"）或共享文件系统（约定 progress.md，子 Agent 每完成一项更新一次）。用 progress.md 最后修改时间超过 N 分钟无变化来判定卡住并触发超时兜底。轨迹持久化（JSONL）适合读全貌，但不宜作为主要传递方式——数万 token 还得自己提炼。terminate 信号，子 Agent 在安全点清理资源后 ack）为首选，强制终止为兜底。终止沿创建关系向下级联，杜绝孤儿 Agent；确需长期后台 Agent 则从新的生命周期树起步。handoff = {task_id, sender, recipient, goal, constraints,
accepted_facts, artifact_refs, remaining_budget, visited_agents}
接收方读任务包和引用、按需取证；预算、访问链与环检测由运行时保留，任何 Agent 不能自行删除。recipient 已在 visited_agents 中则拒绝（防 A→B→A 空转），预算耗尽则停止并上报。
"多个实例"不等于"多种思路"。模型、上下文、脚手架高度相似时，不同 Agent 会做出相同选择。要获得多样性需主动区分模型、上下文、工具、可见证据或职责，并让各 Agent 先独立判断、再汇总结果。
chapter10/multi-role-transfer/ — 同一共享轨迹下"替换 system prompt"与"加载 Skill"两种角色切换的受控对比chapter10/staged-system-prompt/ — 分阶段切换 system prompt + 工具集的归档实验（需求→实现→评审回环）chapter10/book-translation/ — 管理者模式四 Agent（Glossary/Translation/Proofreading/Manager），验证 Manager 上下文不随书厚增长chapter10/parallel-web-research/ — Manager 动态启动 N 个同构 worker、消息总线、第一个已验证命中的级联终止与资源清理chapter10/autonomous-phone-registration/ — 电话 + 电脑双 Agent 点对点协作，模型自主决定是否派生 Phone Agentchapter10/talkact-reproduction/ — 固定拓扑快慢双 Agent 与单模型基线的对照chapter10/voice-werewolf/ — 多 Agent 语音狼人杀：私有/公共记忆隔离与代码驱动的只读 Judgechapter10/generative-agents/ — 25 角色斯坦福 AI 小镇复现，反思机制与信息扩散的对照实验book/chapter10.md「多 Agent 协作的分类框架」book/chapter10.md「多 Agent 何时真正优于单 Agent」book/chapter10.md「共享上下文的多 Agent 协作」book/chapter10.md「不共享上下文的多 Agent 协作」book/chapter10.md「多 Agent 协作的失败模式」まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
为 Agent 建立或改进评估体系时使用——设计评估指标（Pass@k/Pass^k/成本）、搭建可重复运行的评估环境、选择确定性验证器或 LLM-as-a-Judge 及各自适用边界、编写 Rubric、做失败归因与回归任务、评估驱动的模型选型、判断统计显著性、建设可观测性与内部评估基础设施（消融、AB 测试、特性开关、提示词回归）、从 Benchmark 报告走到系统改进。
日本語の概要は準備中です。原文の説明を表示しています。
让 Agent 从运行经验中持续学习、构建自进化闭环时使用——涵盖从运行轨迹提取学习信号（三层轨迹验证）、四种进化方式（经验知识库、Prompt/Skill、程序/Harness、模型参数）的适用边界与选择依据、Prompt 自动优化、轨迹编译为程序、Agent 自我修改与安全门禁、睡眠学习与长期分层评估。触发词：持续进化、自进化、经验学习、轨迹验证器、自我修改、进化闭环。
日本語の概要は準備中です。原文の説明を表示しています。
Agent 陷入无限循环、数不清工具调用次数、遗忘 TODO 或目标偏离、长任务中思考 token 持续膨胀时使用——Agent 状态栏机制、作为 user 消息注入末尾的 KV Cache 理由、每轮替换与持久追加两种实现及成本模型、五种状态栏技术（时间戳、工具计数器、TODO、详细错误、系统状态）与维护铁律。
日本語の概要は準備中です。原文の説明を表示しています。
中文文案去「AI 味」检查清单，由用户纠正反馈持续提炼而来
日本語の概要は準備中です。原文の説明を表示しています。
构建异步/事件驱动 Agent，或让 Agent 响应外部事件（新邮件、webhook 回调、IM 消息、定时器、系统告警）、 处理工具执行期间的用户打断与多任务并发时使用。覆盖事件循环与安全点、三类事件触发工具、用户沟通与多渠道召回、 虚拟身份与隔离执行环境、队列式/取消式/并行式三种事件处理策略及紧急度判定，以及模型原生异步与同步接口兼容两条路线。 触发词：异步 Agent、事件驱动、event-driven、webhook、定时器、心跳、任务句柄、打断、steering、并行工具执行。
日本語の概要は準備中です。原文の説明を表示しています。
把生产 bad case / 失败轨迹转成训练数据时使用——从失败归因、轨迹前缀截取、DPO 偏好对构造、LoRA 训练到边界集与保留集双集验证的完整链路；也用于判断某类问题该走 SFT、DPO、RL 还是先修 Harness/工具/tokenizer，以及如何从运行轨迹中提取带证据的结构化学习信号。触发词：bad case、失败归因、DPO、偏好对、轨迹前缀、拒绝采样、过度矫正、边界集、保留集、过早结束、reward hacking、LoRA 微调、训练评估隔离。
日本語の概要は準備中です。原文の説明を表示しています。