本页要点：单智能体适合做单点任务，而多智能体靠分工协作与上下文隔离来解决复杂问题。至于"自我进化"，这里必须强调一个前提：进化必须带评测闸门，否则所谓的自进化，就变成了自漂移——越进化越不可控。
这是一场全链路教程：方法、安全约束、评测体系、工程实践一网打尽。对做工程的人，价值在于它把"怎么做多智能体"从论文层面拉到了"怎么落地"层面——包括评测怎么做、安全怎么约束、生产怎么跑。
把协同与博弈理论带到物理世界：集群机器人、对抗场景、群体决策。这一场提醒我们，多智能体不只在软件里，也正在进入具身（机器人）场景。
用 Harness 编排推理与证据链，让医学决策可追溯、可复核。这说明多智能体的价值不止于"更快"，更在于"更可信"——每一步推理都有证据链，可以被人审。
用强化学习训练 Agent 的规划与工具使用，研究模型、记忆、技能与工作流的持续演化。这是"自进化"最核心的一场——但也是我最想提醒大家谨慎对待的一场。
很多人问：单智能体也能做很多事，为什么非要拆成多个？核心有三点好处：
Claude Code 把多智能体做成了最容易被工程团队复制的模式：用 .claude/agents/<name>.md 定义子代理——frontmatter 里声明名字、用途和工具白名单，正文写角色指令；主代理按需委派，结果带回。看一个例子：
这里有两个关键点：description 要写清楚"什么时候用"——这能帮助主代理正确判断该不该委派给这个子代理；tools 要收窄权限——能力即边界，不给它不必要的工具，也就封住了它越权的可能。
多智能体之间怎么协作？主流有四种编排模式，各有适用场景：
| 模式 | 做法 | 适用 |
|---|---|---|
| 编排者-工作者 | 主代理拆任务、派活、聚合 | 多数工程任务 |
| 共享记忆/黑板 | 子代理共读写任务状态 | 状态需跨代理同步 |
| 流水线 | A 输出是 B 输入 | 步骤强依赖 |
| 竞争/评审 | 多候选打分择优 | 方案选型 |
无论用哪种模式，有三件事是必做的：结果聚合（要定义统一的返回结构）、冲突处理（用文件锁或职责分区避免互相踩）、协作评测（要测"协作之后整体的成功率和成本"，而不是只看单点）。
最后讲"自我进化"。工程上它是一个闭环：执行任务 → 收集失败 → 反思 → 更新资产（技能库/工作流/记忆/提示词，可版本化）→ 评测闸门。
其中最关键的是最后一道评测闸门：在固定的评测集上，如果这次更新没有带来提升、甚至回退了，就拒绝合并。否则系统会一路"进化"到失控。另外要理解分层：RL 负责参数级学习（改模型权重），Harness/记忆负责系统级学习（改工具、改流程、改记忆），两者是互补的，不是二选一。
通过 → 合并并回到①；未通过 → 回退旧版本。评测闸门防止"自漂移"