前几篇文章中，我们讲了Agent的基本结构、工具调用、上下文与记忆。
如果把一个Agent看作一个能围绕目标做事的“数字员工”，那么接下来的问题就很自然：
一个数字员工够不够？
多数时候，不够。
现实中的复杂工作，很少由一个人从头做到尾。写一份研究报告，需要有人查资料，有人整理数据，有人写初稿，有人审校，有人负责排版。开发一个软件，需要产品经理、架构师、程序员、测试人员和项目经理。药物发现更不用说，靶点、分子、结构、实验、毒理、专利，每一步都不是一个角色能吞下的。
AI Agent也是如此。
一个Agent可以做一些事情，但当任务变复杂，它就会开始力不从心：既要规划，又要检索；既要写代码，又要审查；既要生成结果，又要判断风险。于是，多智能体系统出现了。
多个Agent分工协作，不是因为我们喜欢热闹，而是因为复杂任务本来就需要分工。
今天这篇文章，我们介绍10个多智能体系统相关的基础术语：
Multi-Agent System、Sub-Agent、Handoff、Agent Collaboration、Agent-to-Agent Protocol、Agent Card、Swarm、Debate、Critic Agent、Evaluator Agent。
它们共同回答一个问题：
AI如何从一个会办事的个体，变成一支能协作的队伍？
一、Multi-Agent System / 多智能体系统：不是一个Agent包打天下
它指的是多个Agent通过分工、通信、协作、交接或竞争，共同完成复杂任务的系统。
生活中可以想象一家报社。
一篇好报道不是一个人凭空写出来的。记者负责采访，编辑负责筛选材料，主编负责把关方向，校对负责检查文字，摄影负责图片，法务负责风险。每个人都有职责，最后才形成一篇能发布的文章。
多智能体系统也是类似。
一个系统里可以有：
规划Agent；
检索Agent；
代码Agent；
数据分析Agent；
报告生成Agent；
审查Agent；
评估Agent；
工具调用Agent；
人机交互Agent。
在开源和工业界项目中，这种思想已经有很多体现。例如，AutoGen曾是微软研究院推出的多智能体框架，强调多个Agent之间的对话和协作；CrewAI强调角色化Agent协作；MetaGPT则把软件公司的流程抽象成产品经理、架构师、工程师等角色；ChatDev把软件开发过程组织成多个沟通型Agent参与的流程。
这些项目虽然实现方式不同，但共同说明了一件事：复杂任务不能总靠一个Agent硬扛。
多智能体系统不是为了让AI显得热闹。
它是承认复杂工作需要分工。
一个人既当医生又当药师又当审计员，听起来全能，实际上危险。
二、Sub-Agent / 子智能体：把专业任务交给专业角色
它指的是面向特定任务或特定领域的专业Agent。主Agent或上层调度器可以把某个子任务交给它完成。
生活中可以想象一个公司里的专业岗位。
总经理不需要亲自写代码、做财务、跑采购。他需要知道什么时候该找技术负责人，什么时候该找财务，什么时候该找法务。
在Agent系统中，Sub-Agent就是这些专业岗位。
例如：
文献检索Agent；
数据分析Agent；
代码生成Agent；
图表生成Agent；
报告写作Agent；
事实核查Agent；
合规审查Agent；
AIDD中的靶点分析Agent、分子设计Agent、对接Agent。
Sub-Agent的价值在于专业化。
一个通用Agent什么都懂一点，但未必每件事都做得深。子智能体可以围绕某类任务配置专门工具、专门提示、专门知识库、专门输出格式。
例如，在AIDD场景中：
文献检索Agent负责找证据；
结构分析Agent负责看蛋白口袋；
分子筛选Agent负责算性质和过滤；
报告Agent负责把结果写成人能读的材料；
Critic Agent负责检查逻辑和风险。
Sub-Agent像一个小部门。
部门太少，事情无人承接；
部门太多，又会互相推诿。
真正重要的不是分得越细越好，而是分工是否服务于任务。
三、Handoff / 任务交接：把事情交给更合适的Agent
它指的是一个Agent将任务转交给另一个更适合的Agent处理。
生活中可以想象医院分诊。
一个病人先去了普通门诊，医生发现问题可能属于心内科，于是转给心内科医生。如果涉及手术，还可能进一步转给外科团队。转诊不是推卸责任，而是让更专业的人接手。
Agent中的Handoff也是如此。
比如用户问：
请帮我分析这个分子的对接结果，并形成报告。
一个主Agent可能先判断任务需要结构分析，于是把对接结果交给结构分析Agent；结构分析Agent完成界面解释后，再把结果交给报告生成Agent；最后审查Agent检查表达是否过度。
OpenAI Agents SDK中也将handoff设计为一种让Agent把任务委派给另一个Agent的机制，尤其适合不同Agent各自专长不同的场景。
Handoff的关键不只是“转给谁”，还包括：
交接什么上下文；
保留哪些历史信息；
隐藏哪些无关信息；
交接后谁负责最终结果；
是否需要返回原Agent；
是否需要人工确认。
一个糟糕的任务交接，会让后续Agent像接到一张缺页的病历。它知道自己要做事，却不知道前因后果。
Handoff不是把包袱甩出去。
好的交接，是把任务、背景、证据、边界一起交出去。
否则，所谓协作，不过是互相制造麻烦。
四、Agent Collaboration / 智能体协作：多个Agent如何一起做事
它指的是多个Agent通过消息、共享状态、任务队列、工具结果或协议接口，共同推进任务。
生活中可以想象一次项目会。
产品经理提出需求，技术负责人评估架构，工程师估算开发量，测试人员指出风险，项目经理协调时间。大家不是各说各话，而是围绕同一个目标逐步收敛。
智能体协作也是这样。
常见协作方式包括：
顺序协作：一个Agent完成后交给下一个；
并行协作：多个Agent同时处理不同子任务；
主从协作：一个主Agent调度多个子Agent；
评审协作：一个Agent生成，一个Agent审查；
辩论协作：多个Agent提出不同观点，再收敛结论；
共享状态协作：多个Agent读取和更新同一个任务状态。
在LangGraph这类框架中，开发者可以用图结构来定义Agent之间的节点、边、状态和转移，从而更精细地控制协作流程。CrewAI则更强调角色化Agent组成团队，共同完成任务。
在AIDD中，智能体协作可以表现为：
检索Agent找文献；
结构Agent分析蛋白；
分子Agent生成候选物；
筛选Agent做ADMET过滤；
审查Agent检查结论；
报告Agent生成最终材料。
协作的难点在于：Agent之间会互相影响。一个Agent的错误可能被另一个Agent继承；一个Agent的幻觉可能被下游Agent包装成结论。
多Agent不是天然更可靠。
有时，一个Agent胡说只是一个人的问题；多个Agent相互附和，就变成了会议纪要。
所以，协作必须有证据、有状态、有审查、有停止条件。
五、Agent-to-Agent Protocol / A2A协议：让不同Agent能彼此说话
它关注的是不同Agent之间如何互相发现、通信、交换信息和协调行动。
生活中可以想象不同公司的系统要合作。
如果每家公司都用自己的语言、自己的表格、自己的接口，合作就很困难。于是需要标准协议，让大家知道怎么传消息，怎么认证身份，怎么描述能力，怎么处理任务状态。
A2A协议就是面向Agent之间互操作的一类标准化尝试。
Google在2025年发布Agent2Agent协议，目标是让不同厂商、不同框架构建的Agent能够安全通信、交换信息并协调行动。A2A强调的是Agent之间的协作，而不是单纯把一个工具暴露给模型使用。
这和MCP这类“模型连接工具与上下文”的协议关注点不完全一样。简单说，MCP更像“Agent如何接工具”，A2A更像“Agent如何找另一个Agent帮忙”。
在未来企业场景中，A2A的意义可能很大。
比如一个企业内部有人力Agent、财务Agent、合同Agent、采购Agent、研发Agent。它们不一定来自同一个系统。如果没有协议，就只能靠临时集成；有了协议，Agent之间可以用更统一的方式交流。
在AIDD场景中，也可以想象：
实验室Agent向文献Agent询问背景；
分子设计Agent向结构Agent请求口袋约束；
报告Agent向验证Agent请求结果摘要；
项目管理Agent协调所有Agent的进度。
A2A协议像Agent世界的通用语言。
没有语言，各自聪明也只是各说各话。
有了语言，才有可能协作；但语言本身并不保证真话。
六、Agent Card / 智能体卡片：Agent的能力说明书
它是A2A体系中用于描述一个Agent能力、入口、认证方式和交互模式的元数据。可以把它理解为Agent的“能力说明书”或“数字名片”。
生活中，你要找人合作，不能只知道他叫张三。你要知道他会什么、负责什么、怎么联系、需要什么权限、能交付什么、不适合做什么。
Agent Card也是类似。
一个Agent Card可能包含：
Agent名称；
描述；
能力范围；
可用技能；
服务入口；
认证方式；
支持的输入输出格式；
交互模式；
版本信息；
提供方信息；
安全要求。
在A2A规范中，Agent Card用于Agent发现。客户端可以通过它判断某个Agent是否适合当前任务，以及应该如何与它通信。
例如，一个“分子性质分析Agent”的Agent Card可能说明：
它支持SMILES输入；
可以计算分子描述符；
可以返回JSON或表格；
不支持蛋白结构预测；
需要API Key认证；
每次最多处理1000个分子。
Agent Card的质量会影响系统协作。
写得太少，其他Agent不知道它能做什么；
写得太夸张，其他Agent会错误依赖它；
写得不安全，可能暴露敏感信息；
写进恶意提示，还可能污染调用方上下文。
Agent Card像一张名片。
名片可以介绍能力，也可以包装身份。
所以看名片还不够，还要验证它。
七、Swarm / 智能体群：松散并行的探索队伍
它指的是多个Agent以较松散的方式并行探索、协作或竞争，常用于复杂问题求解。
生活中可以想象一群侦查员同时寻找线索。
一个人去查文献，一个人去问专家，一个人去看现场，一个人去分析数据。大家不一定严格按固定流程前后接力，而是并行探索，最后汇总发现。
Swarm强调的是群体探索，而不是严格流水线。
在Agent项目中，OpenAI曾推出Swarm作为一个轻量级、教育性质的多Agent编排示例，核心概念包括Agent和handoffs，重点在于让开发者理解多Agent之间如何交接和协作。
Swarm思想适合一些开放性问题：
头脑风暴；
方案探索；
多路径搜索；
复杂问题求解；
多假设验证；
多候选方案比较。
在AIDD中，Swarm可以用于：
多个Agent并行探索不同靶点证据；
多个分子生成Agent提出不同骨架；
多个验证Agent从对接、ADMET、文献证据等角度独立评分；
多个策略Agent提出不同项目路线。
但Swarm也有风险。
松散并行容易产生重复工作；
多个Agent可能互相冲突；
如果没有收敛机制，结果会像一地碎片；
如果没有评估者，群体只会制造更多候选，而不是更好结论。
Swarm像一群鸟。
飞得开，能探索更大空间；
没有方向，也可能只是乱飞。
八、Debate / 辩论机制：让Agent之间互相质疑
它指的是多个Agent从不同角度提出观点、相互质疑，最后由裁判Agent或人类收敛结论。
生活中可以想象论文答辩。
学生提出观点，评委提出质疑。一个观点能不能站住，不是看它说得是否漂亮，而是看它能否经受追问。
Agent辩论也是类似。
一个Agent给出方案，另一个Agent指出问题，第三个Agent提出替代解释，最后由评估者综合判断。
Debate机制适合处理：
复杂决策；
多方案比较；
风险分析；
事实核查；
伦理合规；
策略选择；
项目评审。
例如，在AIDD靶点评估中：
支持方Agent认为该靶点疾病相关性强；
反对方Agent指出选择性风险和结构不可成药问题；
证据Agent负责列出文献依据；
裁判Agent根据证据强度给出综合判断。
辩论机制的价值在于减少单一Agent的盲点。一个Agent容易顺着自己的初始思路走下去，多Agent互相质疑可以迫使系统暴露假设、证据和漏洞。
但辩论也不是万能。
两个错误Agent可以吵得很热闹，却仍然错；
一个强势错误观点可能说服其他Agent；
如果没有事实来源，辩论会变成修辞比赛；
如果没有裁判标准，最后只剩下谁说得像真的。
辩论不是为了热闹。
辩论是为了让结论受苦。
能受苦而不倒的结论，才稍微值得相信。
九、Critic Agent / 批判者智能体：专门挑毛病的Agent
它专门检查输出质量、逻辑漏洞、事实错误、风险和合规问题。
生活中可以想象一个严厉的编辑。
作者写稿时常常觉得自己很清楚，但编辑会指出：这里证据不足，那里逻辑跳跃，这句话太绝对，这个结论可能误导读者。编辑不是来讨人喜欢的，他的价值正在于不轻易鼓掌。
Critic Agent也是如此。
它可以检查：
事实是否正确；
结论是否过度；
引用是否支持观点；
逻辑是否连贯；
工具结果是否被误解；
是否存在安全风险；
是否违反合规要求；
是否遗漏关键前提；
表达是否过于自信。
在代码任务中，Critic Agent可以审查代码质量和潜在bug。
在写作任务中，它可以审查结构和论证。
在AIDD任务中，它可以检查药物发现结论是否把预测当事实、是否忽略实验验证、是否夸大模型能力。
Critic Agent在多智能体系统中很重要，因为生成型Agent往往擅长产出，但不一定擅长自我怀疑。
批判者智能体像一根刺。
它让系统不舒服，却也让系统不至于睡着。
一个没有Critic的多Agent系统，很容易变成一群互相鼓掌的幻觉制造机。
十、Evaluator Agent / 评估智能体：给输出打分和验收
它负责对Agent输出进行打分、验收或自动评测，常用于质量控制、回归测试和流程验收。
Critic Agent偏向指出问题，Evaluator Agent更偏向按标准进行评价。
生活中可以想象考试评分员。
老师不只是说“这篇作文不好”，还要根据评分标准给出结构、内容、语言、逻辑、规范性等维度的分数。
Evaluator Agent也是类似。
它可以根据预设标准判断：
任务是否完成；
输出是否符合格式；
事实准确性如何；
是否满足用户要求；
是否遗漏关键内容；
是否调用了正确工具；
代码是否通过测试；
报告是否达到发布标准；
多轮任务是否稳定。
在Agent工程中，Evaluator Agent常用于自动化测试和回归评估。因为Agent系统不是写完就完了，它需要持续迭代。每次改提示词、换模型、加工具，都可能影响输出质量。Evaluator Agent可以帮助开发者比较版本变化，发现退化问题。
在AIDD中，Evaluator Agent可以检查：
候选分子筛选表是否字段完整；
靶点报告是否覆盖疾病证据、结构、药物进展和风险；
对接分析是否包含关键相互作用；
结论是否明确区分预测和实验事实；
报告是否符合模板。
Evaluator Agent像验收员。
它不负责创造，但负责说：这东西能不能交付。
没有评估，多智能体系统就像没有质检的流水线。
产品源源不断出来，坏的也一起出来。
结合几个代表项目看多智能体系统
现在，我们把这些术语和实际项目联系起来。
AutoGen代表了较早一批面向多Agent对话和协作的框架实践。它把多个Agent之间的通信、工具使用和人类参与组织起来，适合理解多智能体系统如何通过消息流协作。不过，开源框架会不断迭代，某些旧仓库或版本进入维护状态并不罕见，学习时应区分概念价值和当前工程选型。
OpenAI Agents SDK更适合理解handoff这类机制。它把Agent、工具和handoff组织在一个框架中，让不同专业Agent之间可以进行任务委派。对初学者来说，handoff是理解“主Agent如何把任务交给子Agent”的关键概念。
Google A2A协议则把问题推进到更开放的层面：不同框架、不同厂商、不同平台上的Agent如何互相发现和通信。Agent Card就是这种互操作中的重要元数据形式，类似Agent的能力说明书。
CrewAI适合理解角色化协作。它强调让多个具有不同角色的Agent组成团队，共同完成复杂任务。它的直觉很像公司里的角色分工：研究员、分析师、写作者、审查者。
LangGraph适合理解状态化、图结构的Agent编排。它不只是让Agent聊天，而是把节点、边、状态、转移和恢复机制显式组织起来，适合构建更可控的多步骤、多Agent工作流。
MetaGPT适合理解“把人类组织流程编码进多Agent系统”。它的典型思想是把软件公司中的产品经理、架构师、工程师等角色放进Agent团队，并强调SOP对协作质量的重要性。
ChatDev则把多Agent协作用在软件开发流程中，让不同角色Agent围绕设计、编码、测试等阶段进行沟通。它说明了多Agent并不只是多个机器人聊天，而是可以模拟一套工作流。
OpenAI Swarm则适合作为教育性样例理解Agent和handoff的最小概念。它提醒我们，多Agent系统不一定一开始就要复杂，先理解Agent之间如何转交任务，也很重要。
这些项目的共同启发是：
多智能体系统真正的难点，不是把多个Agent放在一起。
而是让它们知道谁该做什么、什么时候交接、如何沟通、如何审查、如何收敛。
把十个人关进会议室，不叫组织。
让十个人围绕目标有秩序地完成工作，才叫组织。
把这10个概念串起来：多智能体系统如何完成复杂任务？
假设我们要构建一个AIDD项目分析系统，目标是：
评估一个靶点是否适合开展小分子药物发现，并形成项目建议。
如果用多智能体系统，可以这样组织。
首先，一个主Agent接收用户目标。它不是亲自完成所有事，而是调用多个Sub-Agent。
文献检索Agent查找靶点与疾病关系。
结构分析Agent查找蛋白结构和结合口袋。
药物进展Agent检索已有药物和临床项目。
分子设计Agent提出候选策略。
Critic Agent检查证据是否充分、结论是否过度。
Evaluator Agent根据报告模板和评分标准验收结果。
如果文献Agent发现问题属于结构分析，它可以通过Handoff交给结构Agent。多个Agent之间通过Agent Collaboration共享状态和任务结果。
如果这些Agent来自不同系统，未来可能通过A2A协议通信。每个Agent通过Agent Card暴露自己的能力、入口和认证方式，让其他Agent知道它能做什么。
如果任务很开放，可以使用Swarm式方式让多个Agent并行探索不同路线。对于关键结论，可以引入Debate机制，让支持方、反对方和裁判方共同收敛判断。
最后，Evaluator Agent验收输出，确保报告完整、格式正确、证据充分。
这条流程可以概括为：
多Agent分工 → 子Agent专业执行 → 任务交接 → 协作通信 → 协议互操作 → 能力发现 → 群体探索 → 辩论质疑 → 批判审查 → 自动评估。
这就是多智能体系统从“多个模型”走向“协作组织”的基本逻辑。
结语：多Agent不是开会，而是组织
多智能体系统听起来热闹，但真正重要的不是“多”，而是“系统”。
Multi-Agent System让多个Agent协作完成复杂任务；
Sub-Agent让专业任务交给专业角色；
Handoff让任务可以转交给更合适的Agent；
Agent Collaboration让多个Agent围绕共同目标协作；
A2A协议让不同系统中的Agent有机会互操作；
Agent Card让Agent能力可以被发现和理解；
Swarm让多个Agent并行探索复杂问题；
Debate让不同观点相互质疑；
Critic Agent负责发现漏洞和风险；
Evaluator Agent负责打分、验收和质量控制。
这些概念共同构成了多智能体系统的基本语言。
但我们仍要保持清醒。
多个Agent不会自动带来智慧。
多一个Agent，也可能只是多一个犯错的嘴。
多一次协作，也可能只是多一次误解。
多一层评估，也可能只是把错误包装得更像流程。
真正可靠的多智能体系统，需要清晰分工、明确边界、可追踪状态、可信工具、严格评估和必要的人类监督。
否则，多智能体不过是把一个模型的幻觉，变成一群模型的合唱。
鲁迅式地说，热闹是热闹的，系统什么也没有。
我们要的不是热闹，而是秩序；不是一群Agent围着任务说话，而是一套机制让任务真正被推进、被检查、被交付。
Agent时代的下一步，不是让AI越来越像一个孤独天才。
而是让AI开始像一支有分工、有纪律、有审查、有交付的队伍。
这支队伍若训练得好，能帮人类做许多事。
若训练不好，也不过是把混乱自动化罢了。
