这道题其实在问一个根本问题:你是想一个人干所有事,还是组个团队分工协作。两种思路没有绝对好坏,关键看任务本身。
先说单[[智能体]]。它的核心是 [[ReAct]] 循环,思考、行动、观察,再思考,这个闭环里可以嵌套 [[Chain-of-Thought]] 或者树状推理。记忆层面一般分两层:短期工作记忆和长期向量记忆,用来存对话历史或者领域知识。单智能体适合什么场景呢?任务边界特别清晰,工具调用链可控,不需要外部协作的闭环任务,比如个人助手、代码生成这些。
[[多智能体]]就复杂一些。常见有三种拓扑。一种是集中式,一个管理者统一调度,各个智能体专精执行,比如 MetaGPT 那种,项目经理分任务给开发、测试。一种是分布式,没有中心节点,智能体之间 peer-to-peer 协商,像 AutoGen。还有混合式,分层管理,局部集中加全局分布,比如 CrewAI。
对比几个关键维度。通信方面,单智能体是内部状态流转,没外部开销。多智能体要么直接消息传递,要么走消息总线,或者用共享内存的黑板架构。任务分解上,单智能体靠大模型自我规划,子任务串行或并行执行。多智能体可以预定义角色分工,比如 PM 拆完需求分给 Dev,Dev 写完交给 QA,也可以动态拍卖任务。冲突解决最有趣,单智能体简单,做 [[Self-Consistency]] 或者投票就行;多智能体就得显式投票、仲裁者节点,或者基于信誉的协商。
举个例子,软件开发全流程。如果只是生成一个函数,单智能体加工具调用就够了。但要写一整个微服务,从需求分析到测试上线,单智能体基本搞不定,它可能规划得挺好,但执行时上下文一长就迷失,而且没法同时干多个事。这时候多智能体的角色分工就有优势了,但注意,前提是任务能清晰拆解,否则智能体之间来回扯皮,效率还不如一个人干。常见失败场景就是角色定义模糊,导致两个智能体抢同一个任务,或者互相等对方输出。
所以落地时我更倾向混合架构。核心流程用多智能体协作,但每个智能体内部又是单智能体模式,处理自己的子任务。这样既发挥团队优势,又保持单体可控。真正上线我会特别关注通信延迟和冲突解决,如果消息队列扛不住,或者投票机制设计得不好,系统可能比单智能体还慢。
有个延伸点值得讨论:多智能体协作的 [[幻觉]]传播 问题。如果一个智能体产生了 Hallucination,错误信息会像谣言一样在团队里扩散,而且越传越真。这个问题在面试里经常被问到,我自己倾向于引入一个独立的验证智能体,或者用 [[Self-RAG]] 让每个智能体先自我校验再输出。
总结一下,单智能体简单可控,但能力有天花板;多智能体扩展性强,但引入协调成本和通信开销。我更倾向先评估任务复杂度,能用单智能体解决就不用多智能体,非用不可就选混合架构,并且把冲突解决和幻觉防控作为设计重点。