当一个自动化流程越来越复杂时，很多人会下意识把所有规则、工具和判断都塞进一个 AI Agent 里。
一开始这确实方便：一个 Agent 负责读消息、查数据、判断问题、调用工具、输出结果。但随着场景变多，它很快会出现几个典型问题：
- 上下文越来越长，Agent 容易抓不住重点。
- 系统提示词越来越厚，维护成本上升。
- 工具越来越多，调用错误更难排查。
- 一个环节改动，可能影响整个工作流。
Make 在 2026 年 7 月发布的 AI Sub-Agents，解决的正是这个问题：让一个主 Make AI Agent 可以把其他 Make AI Agent 当作工具调用，从而形成“一个调度者 + 多个专家”的 Agent 编排结构。
图 1：一个主 Agent 负责调度，多个专家 Agent 负责具体任务
一句话理解 Make AI Sub-Agents
Make AI Sub-Agents 可以理解成：一个主 Agent 接收用户任务，然后根据任务类型，把具体工作交给不同的专家 Agent 处理，最后再汇总成一个结果返回。
原帖里给出的核心变化是：你现在可以把 Make AI Agents 添加为另一个 Make AI Agent 的工具。主 Agent 负责判断该找谁，子 Agent 负责完成某个专业任务。
这和传统“写死流程路径”的区别在于，主 Agent 不需要每次都走同一条固定路线。它可以根据请求内容，实时选择更合适的专家 Agent。
为什么一个 Agent 不够用
在简单场景里，一个 Agent 已经够了。
比如用户发来一句：“帮我把这封邮件整理成待办。”这种任务不复杂，一个 Agent 读取邮件、提取事项、写入工具即可。
但如果用户请求变成：
“客户说发票金额不对，还要求退款，你帮我查一下订单、核对合同、判断是否符合退款政策，并回复一封邮件。”
这时一个 Agent 要同时处理客户支持、订单查询、财务核对、退款政策、邮件撰写。它不是做不到，而是很容易变得臃肿。
更好的拆法是：
- 主 Agent：判断问题类型，决定调用哪个专家。
- 账户查询 Agent：查客户、订单、历史记录。
- 发票核对 Agent：检查发票、合同和金额。
- 退款处理 Agent：判断政策、准备审批材料。
- 人工升级 Agent：遇到边界问题时转人工。
这样每个 Agent 的职责都更清楚，测试和维护也更容易。
Make 这次更新带来了什么
根据 Make Community 的产品更新，这次 AI Sub-Agents 主要带来四个能力。
1. 实时 Agent 编排
主 Make AI Agent 可以根据请求内容，选择合适的专家 Agent，而不是每次都按固定路径执行。
这意味着同一个入口可以处理多类问题：有的请求走账户查询，有的请求走退款处理，有的请求走发票审核。
2. 构建更专注的专家 Agent
每个子 Agent 都可以有自己的工具、系统提示词和任务边界。
例如：
- CRM 查询 Agent 只负责查客户资料。
- 退款 Agent 只负责判断退款规则。
- 发票审核 Agent 只负责核对票据和金额。
这类拆分的价值在于：你不用让一个 Agent 背所有知识，也不用让它连接所有工具。
3. 单独测试和优化
子 Agent 可以一个个调试。
如果退款 Agent 输出不稳定，你可以只调退款 Agent，不影响账户查询 Agent。等它稳定后，再接回主 Agent 的编排流程。
这对实际运营很重要。因为很多自动化翻车，不是大流程错了，而是某个局部判断不够稳。
4. 跨场景复用专家 Agent
一个调好的专家 Agent，可以被多个主 Agent 复用。
比如“发票审核 Agent”不仅能用于客户支持，也能用于财务审批、供应商对账、内部报销检查。只要它的输入和输出设计得清楚，就可以成为一个可复用能力模块。
典型使用场景
Make 原帖提到了三个典型方向，放到国内用户语境里，可以这样理解。
客服流程
主 Agent 读取客户消息，判断问题属于哪一类：
- 账户问题，交给账户查询 Agent。
- 退款问题，交给退款处理 Agent。
- 复杂投诉，交给人工升级 Agent。
最后主 Agent 汇总结果，生成给客户的回复。
这种结构适合电商、SaaS、课程社群、会员服务等场景。
财务运营
主 Agent 处理进入队列的财务请求，然后把不同任务交给专家 Agent：
- 文档检查 Agent 负责看附件是否齐全。
- 发票匹配 Agent 负责核对金额、抬头、订单。
- 审批准备 Agent 负责整理摘要和风险点。
最后输出一份清晰的审批建议，而不是让财务同事自己翻一堆表和附件。
内部服务台
员工发起一个请求，比如“我需要开通某个系统权限”。
主 Agent 可以先判断请求类型，再调用：
- 权限检查 Agent。
- 政策问答 Agent。
- 工单创建 Agent。
员工看到的是一个统一入口，背后则是多个子 Agent 协同。
怎么创建 Make AI Sub-Agents
原帖给出的创建方式并不复杂，可以拆成四步。
- 在 Make 场景中添加一个 Make AI Agent，这个 Agent 就是调度者。
- 在这个调度者 Agent 里点击添加工具，找到 Make AI Agents。
- 把另一个 Make AI Agent 配置成工具并添加，它就会作为 Sub-Agent 连接到主 Agent。
- 重复这个动作，为不同任务添加多个专家 Agent。
Make 官方帮助文档也补充了一个关键点：父 Agent 使用子 Agent 的名称和描述来判断它能做什么，但不会直接看到子 Agent 内部的 instructions 和 tools。
这意味着子 Agent 的工具名称和描述非常重要。写得太泛，主 Agent 就不知道什么时候该调用它；写得太窄，又可能导致该用的时候没用上。
当前限制：只支持一层嵌套
这次更新有一个明确限制：Sub-Agents 目前只支持一层嵌套。
也就是说，你可以把其他 Make AI Agent 加到一个主 Agent 里，但不能再给子 Agent 继续添加子 Agent。
可以理解成：
可以：
主 Agent
- 子 Agent A
- 子 Agent B
- 子 Agent C
暂不支持：
主 Agent
- 子 Agent A
- 孙 Agent A1
这个限制反而有利于早期使用。因为多层 Agent 编排虽然听起来强大，但排查问题会更复杂。先把一层主从结构做好，已经能覆盖大多数运营和客服自动化场景。
它和“调用一个带 AI Agent 的场景”有什么不同
Make 社区评论区有人提出了一个很关键的问题：和“调用一个内部本身包含 AI Agent 的场景”相比，Sub-Agents 的优势到底在哪里？
从产品思路看，两者都能实现拆分，但侧重点不同。
调用场景更像是把一段固定工作流封装起来。它适合流程明确、输入输出稳定的任务，比如“查表、写库、发通知”。
Sub-Agent 更像是把一个专家判断能力封装起来。它适合需要理解语义、选择工具、处理边界情况的任务，比如“判断退款是否合理”“从客户描述里识别真正问题”“把一堆财务材料整理成审批建议”。
简单说：
| 方式 | 更适合 |
|---|---|
| 调用场景 | 固定流程、多步骤动作、稳定输入输出 |
| 调用 Sub-Agent | 专家判断、语义理解、动态选择工具 |
实际使用时，两者可以组合：子 Agent 负责判断，场景工具负责执行确定性动作。
图 2：固定流程适合场景工具，专家判断适合 Sub-Agent
对 AIHELPU 用户的启发
这次 Make AI Sub-Agents 更新，其实和我们之前讨论 Skill 的思路很像：不要把所有能力塞进一个大而全的东西里，而是拆成更小、更明确、更容易复用的模块。
对于内容运营、增长、客服和财务团队来说，可以先从这几个方向试：
- 一个“内容调度 Agent”调用选题 Agent、改稿 Agent、发布检查 Agent。
- 一个“客服调度 Agent”调用订单 Agent、退款 Agent、工单 Agent。
- 一个“财务调度 Agent”调用发票 Agent、合同 Agent、审批摘要 Agent。
- 一个“社群运营 Agent”调用用户画像 Agent、活动提醒 Agent、违规检查 Agent。
重点不是堆很多 Agent，而是让每个 Agent 有清晰边界。
搭建前的自查清单
在正式做 Sub-Agents 之前，可以先问自己 8 个问题：
- 主 Agent 负责判断和汇总，还是也承担了太多具体任务？
- 每个子 Agent 是否只有一个明确职责？
- 子 Agent 的名称和描述是否足够清楚？
- 子 Agent 是否有独立工具和独立测试样例？
- 哪些情况需要转人工？
- 子 Agent 输出是否方便主 Agent 汇总？
- 是否存在多个 Agent 都能处理同一任务的冲突？
- 是否记录了测试案例和失败样例？
如果这些问题没有想清楚，就不要急着堆 Agent。先把一个场景跑顺，再拆第二个专家。
小结
Make AI Sub-Agents 的价值，不是让自动化流程看起来更复杂，而是让复杂流程更容易维护。
一个主 Agent 负责理解请求和编排任务，多个专家 Agent 负责处理具体领域。这样既能减少单个 Agent 的上下文压力，也能让工具、提示词和测试边界更清楚。
对 AIHELPU 读者来说，这类能力很适合作为“Agent 编排实战”的入口案例：它不只是一个产品更新，也代表了一种更实用的搭建思路。