解读吴恩达来信：“多智能体协作”

今天继续聊吴恩达教授提到的四种AI智能体设计模式中的最后一个——多智能体协作。这个概念其实很有意思，也很直观：让多个AI智能体像人类团队一样分工合作，每个智能体扮演特定角色，通过讨论、辩论、分配任务，最终给出的方案往往比单个智能体更靠谱。

不妨想象一个软件开发项目：有的智能体扮演CEO，负责定战略；有的当软件工程师，埋头写代码；还有的做测试工程师，专门负责挑毛病。各司其职，共同推进。

多智能体协作的核心特点

每个智能体都有明确的职责。这就像在公司里，每个人都有自己的岗位，不会出现谁的活儿谁干、谁都去干的混乱局面。

这些智能体不是各玩各的，而是通过持续沟通来推进任务。它们可以一起讨论项目进展、协商解决遇到的问题，共同优化方案。

协作的一个重要价值在于可以不断迭代。比如说，一个智能体先拿出初步的软件设计，另一个智能体对它进行评审和反馈，然后根据反馈进一步优化。这个循环可以反复进行，直到结果令人满意。

每个智能体专注自己的任务，整个系统响应更快、输出质量更高。这跟人类团队分工协作的道理是一样的——专人干专事，效率自然上去。

这种模式特别适合那些需要多种专业知识和技能的复杂任务。通过不同领域智能体的协作，可以整合更广泛的知识，产生更有创意的解决方案。

吴恩达教授的几个关键观点

为什么多智能体这个概念值得关注？理由其实很充分。

许多团队的实际应用已经证明了这一点。自动消融研究（比如AutoGen那篇论文）表明，多智能体方案比单一智能体性能更好。

虽然现在有些大语言模型能够接受很长的输入上下文（Gemini 1.5 Pro可以处理100万个token），但它们在真正理解长而复杂输入方面的表现并不总是靠谱。而在多智能体工作流中，每个LLM只专注一件事，性能反而更好。比如提示它“你是编写清晰、高效代码的专家”，它就会知道在这个子任务里什么最重要是清晰和高效，而不是可扩展或高安全性。把大任务拆成子任务，每个子任务都可以更精细化地优化。

就像在写单机代码时，我们会把程序分解成不同的进程或线程。多智能体设计模式给我们提供了一个将复杂任务分解为子任务的框架——这是程序员们再熟悉不过的思路。不妨把每个智能体看作一个“虚拟员工”，它们有各自的工作流、有自己的记忆（对了，记忆本身是智能体技术中一个快速发展的领域：智能体到底要记住多少历史交互，才能在下一轮交互中表现更好？），还可以向其他智能体求助。它们还能参与规划和工具使用。当然，这会导致复杂的LLM调用和智能体间的消息传递，工作流会变得相当复杂。

好消息是，尽管管好这些“AI员工”并不容易，但犯错成本远低于管理人类员工。这给了我们很大的试错空间。

目前，像AutoGen、Crew AI、LangGraph这些新兴框架，已经为构建多智能体解决方案提供了丰富的工具。如果对这个领域感兴趣，可以去了解一下ChatDev——这是一组运营一家虚拟软件公司的智能体的开源实现。可以在GitHub上找到它的仓库，甚至可以克隆下来自己跑一遍。虽然它不一定总能产出理想的结果，但大概率会让你感到惊讶。

话又说回来，多智能体协作的输出质量确实很难预测，尤其是当允许智能体自由交互，还给它们配备多种工具的时候。相比之下，更成熟的反思模式和工具使用模式会可靠得多。但无论如何，这些智能体设计模式值得花时间研究和尝试。

图片说明：