多 Agent 协作
子 Agent 调度、Worker Thread、并行 vs 串行执行策略
本页解决的问题
先给结论「多 Agent 协作」要解决的关键问题是什么？
子 Agent 调度、Worker Thread、并行 vs 串行执行策略
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
单 Agent = 一个人干所有事
多 Agent = 一个团队，各有专长
子 Agent 运行在独立 Worker Thread
隔离内存，互不干扰
父级可随时中止子级
subagent_start → 子 Agent 启动
subagent_chunk → 流式返回中
subagent_end → 子 Agent 完成
「场景 · Agent 团队」怎样变成可执行的指令
「子 Agent 调度、Worker Thread、并行 vs 串行执行策略」强调的不是某句神奇咒语，而是信息是否足够让模型判断“为谁做、要完成什么、什么结果算合格”。
背景决定方向，限制决定边界
从「子 Agent 调度、Worker Thread、并行 vs 串行执行策略」可以看出，一个有效请求至少要把任务、受众、输入材料、输出形式和限制条件分开。少了背景，模型只能猜；少了验收标准，即使文字流畅也无法判断是否完成任务。
继续加字不一定继续变好
把「子 Agent 调度、Worker Thread、并行 vs 串行执行策略」变成一个小练习：只改背景、要求、限制中的一项，保留其他内容不动，观察哪一层真正改变了结果。
从「场景 · Agent 团队」走到「核心概念」
「场景 · Agent 团队」先把问题落在「用户指令 「帮我重构这个项目的用户认证模块」 主 Agent · 协调员 🔍 调研员 💻 开发者 🧪 测试员 🔍 调研员 只读 分析当前认证模块的代码结构和依赖 read_file search_files grep 待分配 💻 开发者 可读写 重写认证中间件，改用 JWT read_file edit_file run_command 待分配 🧪 测试员 可读 + 运行 编写并运行认证模块的单元测试 r…」上；到了「核心概念」，讨论继续推进到「类比理解 单 Agent = 一个人干所有事 多 Agent = 一个团队，各有专长 技术原理 子 Agent 运行在独立 Worker Thread 隔离内存，互不干扰 父级可随时中止子级 事件通信 subagent_start → 子 Agent 启动 subagent_chunk → 流式返回中 subagent_end → 子 Agent 完成」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
写请求时也应逐层补齐：先说任务和受众，再给材料和输出要求，最后加上限制与验收方式；一次只改变一层，才能知道哪项信息起了作用。
- 「场景 · Agent 团队」：用户指令 「帮我重构这个项目的用户认证模块」 主 Agent · 协调员 🔍 调研员 💻 开发者 🧪 测试员 🔍 调研员 只读 分析当前认证模块的代码结构和依赖 read_file search_files grep 待分配 💻 开发者 可读写 重写认证中间件，改用 JWT read_file edit_file run_command 待分配 🧪 测试员 可读 + 运行 编写并运行认证模块的单元测试 r…
- 「核心概念」：类比理解 单 Agent = 一个人干所有事 多 Agent = 一个团队，各有专长 技术原理 子 Agent 运行在独立 Worker Thread 隔离内存，互不干扰 父级可随时中止子级 事件通信 subagent_start → 子 Agent 启动 subagent_chunk → 流式返回中 subagent_end → 子 Agent 完成
- 「产品决策」：Takeaway 复杂任务不靠一个 Agent 硬撑，而是拆成多个专职子 Agent：调研员负责读代码、开发者负责改代码、测试员负责验证。只读任务并行加速，写入任务串行保安全。这就是 Agent 世界的团队协作
最后的「产品决策」把讨论落到「Takeaway 复杂任务不靠一个 Agent 硬撑，而是拆成多个专职子 Agent：调研员负责读代码、开发者负责改代码、测试员负责验证。只读任务并行加速，写入任务串行保安全。这就是 Agent 世界的团队协作」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。