“让三个 Agent 分别想一遍”听起来更稳，但它会多出三份上下文、几次模型调用和一次汇总。任务如果只有一个明确答案，多 Agent 往往只增加等待与检查工作；当工作能拆成互不依赖的几块、每块都能单独验收时，并行才可能值得。
先分清 OpenClaw 里的两种做法：子 Agent是当前 Agent 临时委派的后台任务，完成后把结果交回给它；多 Agent 路由是长期配置多个彼此隔离的 Agent，各自有工作区、状态和会话记录，再按聊天渠道或账号把消息路由到对应 Agent。OpenClaw 子 Agent 文档 · 多 Agent 路由文档
先看工作能不能拆开
| 任务形态 | 例子 | 建议 |
|---|---|---|
| 一问一答、短而清楚 | 从菜单里查拿铁售价 | 一个 Agent 直接查并回答 |
| 先做完 A 才能开始 B | 先定活动日期，再按日期查场地 | 一个 Agent 按顺序完成，避免无效等待 |
| 几项资料彼此独立 | 分别核对场地、餐饮、流程，再汇总活动卡 | 可委派子 Agent 并行核对 |
| 长期分属不同身份或工作区 | 家庭助理与工作助理使用不同资料、账号和会话 | 配置多个 Agent，并用路由绑定区分 |
| 多人同时改同一份文件 | 几个 Agent 一起编辑同一份报价单 | 先让一个 Agent 负责写，其余只审阅；避免覆盖和冲突 |
是否值得拆分，可以用三问判断：
- 子任务能独立开始吗？ 如果后一个问题必须等前一个答案，拆开通常没有并行收益。
- 每个结果能单独验收吗？ 给每个子任务限定资料范围、要回答的字段和格式；“去研究一下”太宽。
- 节省的等待是否值得额外调用？ 每个子 Agent 都有自己的上下文和 token 用量。短任务或低价值任务，先让一个 Agent 做完。
OpenClaw 会把子 Agent 作为独立会话运行，默认在完成后把结果交回请求者；主 Agent 仍需检查并整合。官方文档也提醒，每个子 Agent 默认拥有自己的上下文和 token 用量，可以给重复、简单的子任务配置更便宜的模型。OpenClaw 子 Agent 文档
子 Agent 和多个常驻 Agent 不一样
如果只是想把一份长任务拆成“核资料、检查计算、汇总”，通常从子 Agent 开始。它们服务于一次任务，完成后主 Agent 再统一交付。
如果你要让不同来信长期进入不同工作区，例如一个 Agent 只能看家庭资料，另一个 Agent 处理工作渠道，才考虑多 Agent 路由。OpenClaw 的路由绑定会依据渠道、账号或会话对象选择 Agent；不同 Agent 的工作区、身份和会话记录彼此分开。不要仅仅为了让一个任务看起来“团队化”就创建一组常驻 Agent。
本地实测：同一组资料，一个还是三个
我用 OpenClaw 2026.10.1、Ollama 0.35.1 和三份虚构活动资料，要求提取场地人数、咖啡供应时段、讲者到场时间、签到时间和正式议程。单 Agent 基线使用 Qwen3.8-27B，正确输出全部 5 个字段，用时 111.7 秒，读文件 3 次，OpenClaw 报告总用量 21,493 tokens。
并行尝试由 Qwen3.8-27B 主 Agent 委派 3 个 Gemma4-E2B 子任务。主 Agent 花了 186.6 秒、报告 47,706 tokens 后让出控制权；三个子结果都没有通过核对：有的字段返回未知或占位内容，有的没找到可用的文件读取工具。之后改用 Qwen 子 Agent 并收紧工具 profile，仍遇到 read 工具名无法直接解析的问题；这轮没有得到可验收的汇总结果，因此不报告它的准确率或完整耗时。
这不是模型排行榜，也不能据此断言多 Agent 一定更慢。它说明了本例中的短任务已经由一个 Agent 正确完成，而并行收益尚未兑现。若工具目录采用动态发现，子 Agent 需要先用 tool_search 找出可用工具，再按返回的精确 ID 检查和调用；不能假定文档里的工具名称就是当前会话可直接调用的 ID。OpenClaw 的工具权限由 profile、allow/deny 和子 Agent 限制共同决定，子 Agent allowlist 只能继续缩小已获权限，无法补回被 profile 排除的工具。工具搜索说明 · 子 Agent 工具策略
因此，本练习对这 5 个短字段的实际选择是先用单 Agent。只有当任务块彼此独立、输出能分别验收，而且工具权限经过预检后，才值得再测并行组。所有输入、标准答案和用量记录都在[练习包](files/s164/AI百宝箱多 Agent 协作练习包.zip)。本地 Ollama 的 API cost 显示为 0，不代表设备、电力或等待时间没有成本。
最小配置：主 Agent 协调，子 Agent 只读
先选包含文件与 session 工具的 profile，再用 allow/deny 和子 Agent 限制进一步收窄权限。下面的例子仅开放读取和 session 编排，禁止写入、命令执行、浏览器及对外消息。tools.subagents.tools.allow 是最终过滤器，不能把 profile 已排除的工具重新加回来。模型配置也必须先用一项小任务验证工具调用，再用于批量委派。
{
tools: {
profile: "coding",
allow: ["read", "group:sessions"],
deny: ["exec", "write", "edit", "apply_patch", "browser", "web_fetch", "web_search", "message"],
subagents: { tools: { allow: ["read"] } },
},
agents: {
defaults: {
model: { primary: "ollama/qwen3.8-27b:latest" },
subagents: {
model: "ollama/qwen3.8-27b:latest",
maxConcurrent: 3,
maxSpawnDepth: 1,
},
},
},
}然后给主 Agent 一份有边界的任务说明。先确认 profile 中有 read，并要求子 Agent 从工具目录里发现精确工具 ID，例如：
把场地、餐饮、流程三份资料分成 3 个互不依赖的只读核对任务，并行委派。
每个子 Agent 先用 tool_search 找出文件读取工具，按返回的精确 ID 查看参数，再读取指定文件。
每个子 Agent 只返回指定字段；等所有结果完成后，由你逐项对照原文再汇总。
不得写入文件、访问网页或向外发送消息。遇到缺字段就写“资料未说明”，不要猜。在工具列表里确认 sessions_spawn 可用。coding profile 包含文件和 session 工具；无论选择哪个 profile，都要核对有效权限，并按工作区做最小授权。若任务涉及写入，先指定唯一写入者和文件范围，其余 Agent 只返回审查意见。工具配置说明
**不要默认把并发数调到最大。**按同一父 Agent 下同时运行的子任务数设置 maxConcurrent，并检查本机模型服务能否并行处理。每个子 Agent 都可能重复携带 system prompt 和任务资料；若本机显存不足，或者提供方把请求排队，并行调度未必能缩短总等待。
验收结果，不验收“团队感”
给每个子 Agent 一条验收规则：字段必须能在指定资料中找到；格式一致；缺失时明确返回未知。主 Agent 汇总时重新检查这些条件，并标明冲突和缺失项。复杂的工作流最好保留每个子任务的输入、模型、结果、用量和耗时，方便比较单 Agent 基线。
当工作流程稳定后，再试着给子 Agent 换小模型、缩短上下文或降低并发。只要正确率下降，节省的 token 就不算收益。对短问答、强依赖链、共同编辑同一文件，先用一个 Agent；对独立资料核查、并行假设排查和有明确交付物的长任务，再按实测决定是否委派。
本次仅测试本机 Ollama 与 OpenClaw profile；本地 reported API cost 不包含设备、电力和等待时间。没有接入微信、邮箱、支付、生产文件或外部 API。封面背景由本机 ComfyUI / Z-Image-Turbo 生成，标题由脚本排版。