夜雨聆风
OpenClaw 多智能体协作终于搞明白了:不是会聊天,而是会指挥别的 Agent 干活
很多人刚接触 OpenClaw 时，第一反应往往是：这不就是一个能聊天、能回答问题的 AI 智能体吗？
但真正把它接进飞书、接进工作流、接进自己的知识库和工具系统之后，你会发现，OpenClaw 更有价值的地方，并不是让一个 Agent 单独回答问题，而是让一个 Agent 去调度其他 Agent，一起完成更复杂的任务。
这时候，OpenClaw 就不再只是一个“问一句答一句”的机器人，而更像是一个可以协作的数字团队。
你在飞书里对主智能体说一句话，它可以把任务拆开，分配给不同的智能体去执行。有的负责查资料，有的负责分析信息，有的负责写文案，有的负责润色表达，最后再由主智能体统一汇总结果，回复给你。
这才是多智能体系统真正有意思的地方。
而要让这套机制跑起来，OpenClaw 里有一个很关键的配置能力：sessions，以及 agent-to-agent 权限配置。
很多人用 OpenClaw 卡住，不是模型不行，也不是工具不行，而是这些权限配置没有理解清楚。
一个智能体指挥另一个智能体，本质上是在做任务分工
所谓“一个智能体指挥其他智能体”，听起来很玄，其实可以理解成一种任务分工机制。
主智能体负责接收任务、理解需求、拆解步骤、调度其他 Agent，并最终汇总结果。其他智能体则各自负责特定能力范围内的执行工作。
比如你在飞书里对主智能体说：
帮我整理一篇关于 OpenClaw 多智能体协作的公众号文章。
如果只是单智能体模式，它可能会自己直接生成一篇文章。
但如果是多智能体协作模式，它完全可以换一种方式工作：先让擅长信息整理的 Agent 去梳理文档和配置项，再让擅长技术表达的 Agent 提炼结构，然后让内容润色 Agent 把它改成更适合公众号阅读的版本，最后由主智能体统一整合、检查并输出。
这时候，主智能体的角色就不再是“自己干完所有事”，而是像一个项目负责人，把任务拆给不同成员去做。
OpenClaw 里这类协作通常会涉及几个能力：sessions_list、sessions_history、sessions_send、sessions_spawn，以及 tools.agentToAgent。
这些名字看起来有点技术化，但真正理解之后并不复杂。核心问题只有一个：
当前这个智能体，能不能看到其他 session，能不能创建新 session，能不能给其他 Agent 发任务。
真正关键的配置，通常长这样
如果你想通过飞书让一个主智能体调度其他智能体，一个常见配置大概会长这样：
{
"tools": {
"profile": "full",
"sessions": {
"visibility": "all"
},
"agentToAgent": {
"enabled": true,
"allow": ["informationmaster"]
}
}
}
这段配置的意思不是“简单粗暴地全开权限”，而是给当前智能体提供一种有条件的多智能体协作能力。
它里面有几个非常容易混淆的地方：profile 是基础工具权限，sessions.visibility 是 session 可见范围，agentToAgent.enabled 是跨 Agent 协作开关，agentToAgent.allow 则是目标 Agent 白名单。
很多人踩坑，就是因为把这些字段混在一起理解了。
profile 决定基础工具范围，不是越复杂越好
先看 tools.profile。
这一项可以理解成当前智能体的基础工具权限范围。OpenClaw 里常见的 profile 包括 minimal、coding、messaging、full 等。
minimal 权限最少，适合非常受限的场景。coding 更偏向代码相关能力，messaging 更偏向消息通信能力，而 full 则表示基础工具限制比较少。
所以很多人在排查问题时，会直接写：
"profile": "full"
这样确实最省事，也最不容易因为基础权限不够导致某些工具不可用。
但要注意，full 不是唯一正确答案，它只是最适合排查和快速验证的方案。如果你的场景比较明确，也可以用其他 profile，再配合 tools.allow 或 tools.deny 做更细的权限控制。
所以这里真正要理解的是：profile 不是多智能体协作本身，它只是决定当前智能体有没有足够基础能力去使用相关工具。
如果 profile 太窄，后面的 sessions 和 agent-to-agent 配了也可能表现不正常。
sessions.visibility 控制的是“看见多大范围”，不是“拥有全部权限”
再看 sessions.visibility。
"sessions": {
"visibility": "all"
}
这一项控制的是当前智能体可以看到多大范围的 session。
常见范围大概可以理解为：self 只能看当前 session，tree 可以看当前 session 以及它派生出来的子 session，agent 可以看当前 Agent 下的 session，all 则可以访问更广范围的 session。
这里最容易误解的一点是：
visibility = “all” 并不等于当前智能体就可以随便调用所有 Agent。
它只是扩大了 session 的可见范围，让当前智能体“看得更远”。但能不能跨 Agent 调用，还要看 agentToAgent 是否开启，以及目标 Agent 是否在允许名单里。
如果你的场景只是让当前智能体管理自己 spawn 出来的子智能体，那么 tree 有时候就已经够了，未必一定要用 all。
只有当你确实需要跨 Agent、跨更大范围调度任务时，visibility: "all" 才更有必要。
这也是很多人配置时容易踩坑的地方：以为 session 可见范围开大了，就等于跨 Agent 权限也开了。实际上，这两件事不是一回事。
agentToAgent.enabled 才是跨智能体协作的关键开关
如果说 sessions.visibility 解决的是“看不看得见”，那么 agentToAgent.enabled 解决的就是“能不能访问其他 Agent”。
"agentToAgent": {
"enabled": true
}
这个开关不开，跨 Agent 协作就很难真正生效。
也就是说，主智能体能不能调度其他智能体，关键不只是它能不能看到 session，而是你有没有明确允许它进行 agent-to-agent 调用。
这也是为什么很多人升级 OpenClaw 后会遇到一种很奇怪的情况：机器人还活着，飞书里还能回复，也能做基础问答，但一涉及复杂任务，比如调度其他智能体、调用原本应该可用的工具，就突然不行了。
这种情况往往不是模型能力退化，而是权限没开对。
最容易混淆的，是两个 allow
OpenClaw 里有两个看起来很像、但含义完全不同的 allow。
第一个是：
"agentToAgent": {
"enabled": true,
"allow": ["informationmaster"]
}
这个 allow 控制的是：当前智能体允许访问哪些目标 Agent。
比如这里写了 informationmaster，意思就是当前智能体可以访问 informationmaster 这个 Agent，但不能访问不在名单里的其他 Agent。
它是目标 Agent 白名单。
第二个是：
"tools": {
"allow": ["sessions_list", "sessions_send"]
}
这个 allow 控制的是：当前智能体允许使用哪些工具。
比如这里只允许 sessions_list 和 sessions_send，那么其他工具就可能被限制掉。
它是工具白名单。
这两个字段名字都叫 allow，但一个限制“能访问谁”，一个限制“能用什么工具”。
很多配置问题就出在这里。
你以为自己是在允许访问某个 Agent，结果写到了工具白名单里，导致其他工具能力被锁死。或者你以为自己开放了工具权限，结果只是放开了目标 Agent 名单，真正需要的 sessions 工具仍然不可用。
所以一定要记住：
tools.agentToAgent.allow 管的是目标 Agent。tools.allow 管的是工具集合。
这两个一旦混了，智能体就很容易进入一种“看起来能聊天，但就是干不了活”的状态。
升级后机器人突然变笨，先别急着怪模型
我自己就遇到过一个很典型的问题。
升级 OpenClaw 之后，机器人表面上还正常。飞书消息能收，基础问题能答，简单对话也没问题。
但一旦让它做更复杂的事，就明显不对了。它不能自己配置，不能调度其他智能体，也不能调用原本应该能用的工具。整个状态就像从一个“会干活的 Agent”，退化成了一个“只会回答问题的聊天机器人”。
一开始很容易误判成模型不行、系统不稳定，或者新版功能退化。
后来排查才发现，真正的问题不是模型，而是工具权限配置发生了变化。
这类问题最迷惑的地方在于，它不是彻底坏掉。如果机器人完全不回复，你很快就知道是系统故障。但它还能回复，只是复杂能力消失了，这就很容易让人误以为是智能体变笨了。
实际上，很多时候不是它不会做，而是它没有被允许去做。
排查智能体“变笨”，优先看这几个地方
如果你的 OpenClaw 智能体突然从“能干活”变成“只会聊天”，不要第一时间怀疑模型，先检查权限配置。
首先看 tools.profile 是否过窄。如果基础 profile 限制太多，很多工具能力会直接缺失。排查时可以先用 full 验证是不是权限范围导致的问题。
然后看 tools.agentToAgent.enabled 有没有开启。如果你想让一个智能体访问其他智能体，这个开关必须明确打开。
再看 tools.sessions.visibility 是否符合你的场景。如果只是管理当前会话树里的子 session，tree 可能够用；如果要跨 Agent 做更大范围调度，就需要考虑 all。
接着重点检查两个 allow 有没有写错。tools.agentToAgent.allow 限制的是可访问的目标 Agent，tools.allow 限制的是可使用的工具。它们看起来相似，但作用完全不同。
最后还要检查有没有 deny 把能力挡掉。尤其是同时配置了 allow 和 deny 的时候，有些工具可能明明在逻辑上应该能用，但被 deny 规则拦住了。
这几个地方排完，很多所谓“智能体变笨”的问题，基本都能定位到原因。
多智能体协作最适合什么场景？
一个智能体调度多个智能体，最适合的不是简单问答，而是多步骤、强分工、需要持续处理的工作流。
比如内容创作场景。主智能体可以负责接收主题和最终把关，信息整理 Agent 负责查资料，结构 Agent 负责搭框架，写作 Agent 负责成文，润色 Agent 负责改成公众号、小红书、飞书公告等不同版本。
再比如信息处理场景。一个 Agent 负责抓取数据，一个 Agent 负责分类分析，一个 Agent 负责提炼结论，一个 Agent 负责生成日报或周报，主智能体负责统一调度和输出。
还有自动化运营场景。监控 Agent 负责盯消息和数据变化，分析 Agent 负责判断风险和机会，执行 Agent 负责生成建议动作，主智能体负责决定下一步该让谁处理。
这种模式的价值不只是“更智能”，而是把一个单点智能体，升级成一个可分工、可协作、可扩展的系统。
这才是 OpenClaw 真正值得关注的地方。
OpenClaw 的核心价值，不只是会聊天，而是会协作
很多人用 AI，最先感受到的是“它回答得像人”。
但真正进入工作流之后，更重要的问题会变成：它能不能调用工具，能不能拆任务，能不能管理 session，能不能把一个复杂任务交给不同 Agent 分头完成，能不能最后把结果整合回来。
OpenClaw 的价值恰恰在这里。
它不是单纯给你一个会说话的机器人，而是让你开始搭建一个可调度的智能体系统。
这两者的差别非常大。
聊天机器人解决的是“问答”。 智能体系统解决的是“协作”。 而多智能体协作，解决的是“复杂任务的组织和执行”。
所以，当你通过飞书接入 OpenClaw，让一个主智能体可以调度其他智能体时，本质上你搭建的已经不是一个普通机器人，而是一个数字工作团队的雏形。
最后，把这套配置再讲清楚
如果你想让一个智能体通过飞书去调度其他智能体，常见配置可以从下面这个结构开始：
{
"tools": {
"profile": "full",
"sessions": {
"visibility": "all"
},
"agentToAgent": {
"enabled": true,
"allow": ["informationmaster"]
}
}
}
但一定要理解它背后的含义。
profile: "full" 是最省事的排查起点，不是唯一解。它主要解决基础工具权限不够的问题。
sessions.visibility: "all" 是扩大 session 可见范围，不等于自动拥有跨 Agent 全权限。跨 Agent 调用仍然要靠 agentToAgent 配合。
agentToAgent.enabled: true 才是允许智能体访问其他智能体的关键开关。
agentToAgent.allow 控制的是能访问哪些目标 Agent，而 tools.allow 控制的是能使用哪些工具。两个字段名字相似，但含义完全不同。
如果升级后智能体突然“变笨”，不要先怪模型，也不要急着怀疑 OpenClaw 不稳定。
先回头看配置。
因为很多时候，不是它不会，而是它没有权限去做。 OpenClaw 真正强的地方，也正是在这里：它不是让一个 Agent 单打独斗，而是让多个 Agent 通过 session 和权限配置组织起来，变成一个真正可以协作的系统。