13个AI智能体组队：自动开发客户，人工审批才发送

一位开发者在 Reddit 上分享了他为 Olano AI 搭建的多智能体（multi-agent）系统，用一个真实的销售拓客工作流，展示了当下多智能体协作的一种务实做法。这不是又一篇泛泛而谈的"AI 智能体是未来"的宣言，而是一套每天早上 7:30 自动运行、并在关键节点交回人类决策的完整流程。

13个智能体各司其职

这套系统目前有 13 个活跃智能体，每个都有明确的角色定位，颇像一支真实的公司团队：

• Aurelius：团队负责人（team lead）
• Maria：市场营销
• Sally：销售
• Soledad：解决方案
• Sebas：安全
• Curtis：客户成功
• Grantie：负责新加坡的补助与机会信息
• AgentFather：负责创建和管理整个智能体团队
• Composio、Zoho Email、Navi：工具与集成类智能体

值得关注的是 AgentFather 这个"元智能体"——它不直接干活，而是负责组建和管理其他智能体，相当于一个团队的组织者。这种"智能体管理智能体"的分层设计，是多智能体系统走向规模化时常见的思路。

多智能体系统（Multi-Agent System，MAS）是指由多个能够独立感知环境、做出决策并相互通信的AI智能体共同完成复杂任务的架构。与单一大模型相比，MAS的优势在于"分而治之"：将一个复杂任务拆解成子任务，交给经过专门提示词（system prompt）定制的智能体处理，各自维护独立的上下文窗口，避免单一模型因任务过重导致注意力稀释或上下文溢出。AgentFather这类"元智能体"（meta-agent）的概念来源于元编程思想——一个程序负责生成和管理其他程序。在LLM时代，元智能体通常拥有创建新智能体所需的完整权限，包括定义其角色、工具访问范围和通信协议，使系统能够在运行时动态扩展团队规模，而无需人工介入架构层的修改。

每天早上 7:30 自动跑的拓客流程

作者描述了一个每天定时触发的工作流，完整还原了一次销售线索开发的过程：

1. 找到 3-5 家存在明显工作流问题的企业
2. 收集公开证据佐证这些问题
3. 核实企业的公开联系方式
4. 引入市场和销售智能体提供输入
5. 准备一封个性化的 Zoho 邮件草稿
6. 停下来，等待人工审批

整个链路里，智能体之间可以互相对话，并在需要时把另一个专家智能体拉进来协作。比如销售智能体在起草邮件时，可以调用市场智能体来优化措辞和定位。这种"按需召唤专家"的协作模式，比单一大模型硬扛所有任务更接近真实团队的运作方式。

核心实验：自主性与控制的平衡

作者明确指出，这套系统真正在探索的问题，是自主性（autonomy）与控制（control）之间的平衡。

他的原则很清晰：让智能体自己完成有价值的工作，但任何有后果的动作都必须经过人类决策。所以在这套流程里，没有任何邮件是自动发送的——所有对外输出都停在草稿阶段，把最终的"发送键"留给人。

这其实点中了当前 AI Agent 落地的关键痛点。全自动的智能体听起来很酷，但一旦涉及对外沟通、资金操作或不可逆动作，出错的代价往往难以承受。把"人工审批闸门（human approval gate）"设在最后一步，是一种在生产环境里相对稳妥的折中：前面的研究、验证、起草都交给 AI 提效，最终判断权仍在人手里。

人工审批闸门（Human-in-the-Loop，HITL）是AI系统安全性设计中的重要概念，指在自动化流程的关键节点强制引入人类判断，以防止不可逆错误扩散。HITL的位置选择在工程上有明确权衡：过早介入会削弱自动化收益，过晚则可能让错误累积到难以纠正的程度。在AI Agent领域，OpenAI、Anthropic等机构的安全研究均建议，凡涉及"现实世界副作用"（real-world side effects）的动作——如发送通信、执行支付、修改生产数据——都应设置HITL节点。这也是为什么该系统将"发送邮件"这一看似简单的操作设计为必须人工触发：一旦发出，召回成本极高，且可能影响客户关系，属于典型的不可逆动作。

抛给社区的几个真问题

作者并没有把这当成成品炫耀，而是向其他构建多智能体系统的人抛出了几个值得深入讨论的工程问题：

• 智能体之间如何通信？ 是采用一个管理者智能体统一调度，还是点对点（peer-to-peer）的对等委派？
• 人工审批闸门应该放在哪里？ 放太早会拖慢效率，放太晚又可能失控。
• 在生产环境里，究竟给智能体多少自主权？

这几个问题恰恰是多智能体架构设计的分水岭。管理者模式（manager agent）便于统一编排和责任追踪，但容易成为瓶颈；对等委派更灵活，却更难调试和保证一致性。作者的方案里，Aurelius 作为 team lead 加上 AgentFather 的存在，明显偏向管理者模式，但同时保留了智能体互相拉人协作的对等能力，算是一种混合思路。

管理者模式（Orchestrator/Manager Pattern）与对等委派（Peer-to-Peer Delegation）是多智能体通信拓扑的两种主流范式。管理者模式中存在一个中央调度智能体（orchestrator），负责任务分解、下发指令并汇总结果，类似微服务架构中的API网关；其优点是调用链路清晰、易于日志追踪和错误定位，缺点是管理者本身成为单点瓶颈，且推理成本集中。对等委派中智能体之间可直接互相调用，更接近事件驱动架构，灵活性更高，但一致性保证和循环调用防护（避免A→B→A的死循环）是显著的工程挑战。目前主流的智能体框架（如LangGraph、AutoGen、CrewAI）均提供对这两种模式的不同程度支持，开发者需根据任务耦合度和容错要求选择合适的拓扑结构。

对构建者的启示

这个案例的价值不在于智能体数量多（13 个），而在于它给出了一个可复制的落地范式：

用拟人化的角色分工让系统职责清晰，用元智能体管理团队复杂度，用定时触发实现无人值守的持续产出，最后用人工审批锁住风险敞口。对于正在把 AI Agent 推向真实业务的团队来说，"AI 做前 90%，人做最后 10% 的关键决策"这条经验，比追求 100% 自动化更值得借鉴。

作者也表示愿意进一步分享架构、记忆机制、审批设计和工具接入的细节，感兴趣的开发者可以从这套 Olano AI 的实践中找到不少可迁移的设计思路。