六类Agent架构怎么选：评测维度与边界

一、评测概述：评测什么，读者能得到什么判断

本文的评测对象是六类常见Agent架构模式：ReAct、Workflow、Planner-Executor、Multi-Agent、中心化监督式Supervisor、去中心化群集式Swarm。原始标题将Supervisor/Swarm并列，本文为了便于评测，将其拆分为“中心化监督”和“去中心化群集”两类观察，因此合计六类。本文不评测某一具体厂商产品，也不对某个固定实现给出排名，而是回答一个更通用的问题：面对不同任务复杂度、确定性要求、协作规模、运维能力和成本约束，应该如何建立评测框架，验证某类Agent架构是否适合业务。

本文适合开发者、系统架构师、技术负责人、运维人员和需要做技术选型的企业团队阅读。读者可以获得三方面判断：第一，理解六类架构分别补什么短板，不要被“越复杂越先进”的错觉带偏；第二，掌握从功能、准确性、性能、稳定性、安全、可观测性、可维护性和成本等维度设计评测的方法；第三，学会解读评测结果，明确结论适用于什么条件、不适用于什么条件。

Agent架构选型不是简单判断“好不好”，而是判断“匹配不匹配”。同样一套架构，在短链路工具调用任务中可能足够，在长链路规划、异构角色协作和高并发生产系统中则可能暴露不同问题。因此，评测应围绕业务目标、任务特征、系统规模、使用成本和长期维护需求展开，而不是只看演示效果。

二、六类架构的评测对象说明

六类架构可以看作对LLM能力边界的逐层补强：ReAct补“不会行动”，Workflow补“流程确定性与约束”，Planner-Executor补“复杂目标拆解与重规划”，Multi-Agent补“单一模型能力边界有限”，Supervisor补“多角色协作中的中心调度与审计”，Swarm补“去中心化并行探索与弹性协作”。每一类架构都有明确适用条件，也有新的复杂度成本。

架构模式	核心机制	主要解决的问题	评测重点	主要风险
ReAct	思考、行动、观察循环迭代	让模型调用工具并依据结果推进任务	工具选择正确性、观察解析、循环终止、错误恢复	死循环、工具误用、上下文膨胀
Workflow	预定义步骤、分支和回退流程	将稳定业务流程结构化	流程覆盖、条件分支、异常回退、可维护性	灵活性不足、流程变更成本高
Planner-Executor	规划器拆解任务，执行器逐步完成	复杂目标拆解、依赖排序、重规划	计划合理性、依赖关系、执行反馈、重规划质量	计划偏离、执行反馈失真、规划成本高
Multi-Agent	多角色分工协作	异构能力组合与并行处理	角色边界、通信协议、冲突消解、协作成本	错误传播、通信开销、责任不清
Supervisor	中心节点调度多个执行单元	统一分派、监督、审计和收敛	调度策略、单点瓶颈、审计完整性、超时控制	中心节点成为瓶颈、调度偏差
Swarm	去中心化群集协作	并行探索、弹性分工、局部自治	收敛性、一致性、通信开销、容错能力	结果不稳定、治理困难、成本放大

需要强调的是，六类架构不是完全互斥。实际系统可能是Workflow中嵌入ReAct步骤，Planner-Executor调用多个执行角色，Supervisor管理多个执行单元。评测时应先明确被评测的是“主架构模式”，再识别其中嵌套的子模式，避免把复杂系统中的所有问题都归因于单一架构。

三、评测目标与维度设计

1. 功能完整性：是否覆盖典型任务链路

功能完整性评测要回答：该架构是否覆盖业务中的典型流程，包括单步工具调用、多步任务推进、条件分支、异常处理、人工接管、结果汇总和审计记录。对于ReAct，要验证是否能在工具返回异常时继续推理或终止；对于Workflow，要验证分支条件和回退路径是否完整；对于Planner-Executor，要验证计划拆解、执行反馈和重规划是否形成闭环；对于多Agent和群集式架构，要验证角色分工、消息传递、冲突处理和最终收敛是否可观察。

功能完整性不能只看“能否跑通一个成功案例”，还要看失败路径是否可解释。例如工具不可用、输入缺失、依赖超时、权限不足时，系统是否能给出明确状态，而不是静默失败或无限重试。

2. 准确性与有效性：结果是否符合预期

准确性评测需要围绕任务目标建立判定标准。对于工具调用型任务，可观察工具选择是否正确、参数是否完整、观察结果是否被正确解析；对于规划型任务，可观察计划是否覆盖目标、步骤顺序是否合理、依赖关系是否成立；对于协作型任务，可观察各角色输出是否互补、是否存在重复劳动或相互矛盾。

结果解读要避免只看最终答案。应同时记录中间过程：计划步骤数、工具调用次数、无效调用比例、人工干预次数、重试次数和终止原因。若最终答案正确但中间大量无效调用，说明效率或稳定性可能不足；若中间过程合理但最终结果偏差，则要检查汇总逻辑和判定标准。

3. 性能表现：响应、吞吐与资源消耗

性能评测应关注端到端响应时间、单任务平均步骤数、并发处理能力、资源消耗和扩展趋势。Agent架构往往涉及多次模型调用、工具调用和消息传递，性能问题可能来自模型推理、网络链路、工具依赖、并发模型或上下文长度增长。评测时应在相同资源配额、相同工具权限、相同超时设置和相近数据规模下对比，避免环境差异污染结论。

不能编造具体数值，但可以建立观察指标：任务步骤增加时响应时间是否线性增长；并发提高时错误率和超时率是否明显上升；多Agent通信是否带来额外开销；Planner反复重规划是否导致成本放大。若某架构在高并发下错误率上升明显，应进一步检查队列、限流、重试和依赖服务容量。

4. 稳定性：异常输入与长时间运行

稳定性评测要覆盖异常输入、网络波动、依赖服务异常、资源紧张和长时间运行。对于ReAct，要观察是否出现死循环、重复调用和上下文膨胀；对于Workflow，要观察异常分支是否可达、回退是否有效；对于Planner-Executor，要观察计划失败后是否能重规划而不是反复执行同一错误步骤；对于多Agent、Supervisor和Swarm，要观察消息丢失、角色阻塞、中心节点过载和收敛失败。

稳定性结论应条件化表达。例如“在依赖服务短暂不可用的条件下，若系统能通过有限重试和降级返回明确状态，则稳定性较好；若错误在多个角色间传播并导致整体超时，则需要加强隔离和熔断”。

5. 易用性与可维护性：接入、调试和升级成本

易用性包括接入流程、配置复杂度、文档清晰度、调试便利性和开发改造成本。可维护性包括版本升级、配置管理、故障排查、容量规划和持续优化成本。Workflow通常流程清晰但变更需要改流程；ReAct灵活但调试依赖日志；Planner-Executor需要同时维护规划策略和执行器；多Agent和Swarm的通信协议、角色边界和状态管理更复杂，维护成本更高。

评测时可建立检查清单：配置是否可版本化；任务状态是否可恢复；失败点是否可定位；新增工具或角色是否影响既有流程；日志是否包含关键决策依据；权限变更是否可审计。对于复杂架构，若可观测性不足，即使演示效果较好，也不适合直接进入生产。

6. 安全、兼容性与可观测性

安全评测应关注身份认证、权限控制、数据隔离、传输加密、日志审计和敏感信息保护。Agent会调用工具和访问数据，必须验证最小权限、工具白名单、敏感参数脱敏和操作审计。多Agent和群集式架构还要关注角色间消息是否越权、共享上下文是否泄露敏感信息。

兼容性评测要关注与现有系统、数据格式、接口规范、运行环境和运维流程的适配程度。可观测性评测要关注日志、指标、监控、告警、链路追踪和问题定位能力。Agent架构的决策链路较长，若没有记录思考步骤、工具调用、观察结果和最终动作，故障排查会非常困难。

7. 成本结构与场景适配度

成本包括资源成本、人力成本、迁移成本、运维成本和长期使用成本。Agent架构越复杂，模型调用次数、工具调用次数、消息传递次数和人工维护成本通常越高。评测时不应只看单次调用成本，还要看任务成功率、重试率和人工干预率。若一个简单架构能稳定完成任务，引入复杂协作可能只增加成本而不增加收益。

场景适配度要结合业务特点判断：确定性流程优先关注可维护和审计；开放任务优先关注规划和重规划；异构能力组合优先关注角色边界和通信；高并发生产系统优先关注限流、隔离、可观测和容错。

四、评测环境与前提

评测前需要明确环境条件：模型服务配置、工具权限、数据规模、调用方式、网络条件、资源配额、超时设置和并发规模。应保证不同架构在尽量一致的条件下运行，避免因为资源配额不同导致结论失真。测试数据应覆盖正常输入、边界输入、缺失输入、恶意输入和依赖异常。对于涉及敏感数据的场景，应使用脱敏样本，并限制日志中的敏感信息。

评测边界也要说明：本次评测覆盖哪些任务类型、哪些工具、哪些并发规模、哪些异常条件；不覆盖哪些极端规模、哪些跨地域网络条件、哪些长期运行场景。只有明确边界，评测结论才可被正确使用。

五、评测方法：样本设计、基线与过程记录

1. 设计代表性样本

建议按任务复杂度分层设计样本：单步工具调用、多步串行任务、带条件分支流程、模糊目标拆解、多角色协作、并行子任务、异常依赖和超时场景。每类样本都要有明确输入、预期结果和失败判定标准。样本不宜只选成功案例，否则无法观察异常恢复和边界行为。

样本类型	目的	观察重点
单步工具调用	验证基础行动能力	工具选择、参数完整性、结果解析
多步串行任务	验证状态推进	步骤顺序、上下文保持、终止条件
条件分支流程	验证流程控制	分支判定、回退路径、异常处理
模糊目标拆解	验证规划能力	计划覆盖度、依赖排序、重规划
多角色协作	验证分工与通信	角色边界、冲突消解、汇总质量
并行与异常场景	验证稳定与容错	超时、重试、隔离、收敛

2. 建立基线并控制变量

基线可以是简单ReAct或固定Workflow在相同样本上的表现。控制变量包括相同模型配置、相同工具集合、相同超时、相同资源配额和相同数据规模。记录指标包括任务成功率、平均步骤数、工具调用错误次数、人工干预次数、端到端响应时间、超时率、重试率、资源消耗趋势、日志完整度和异常恢复情况。不得编造具体数值，应以实际记录为准。

3. 分维度验证与过程记录

功能验证按样本逐项执行；性能验证通过逐步提高并发和任务长度观察趋势；稳定性验证通过异常注入和长时间运行观察；安全验证通过越权请求、敏感参数和审计检查；易用性验证通过接入、配置、调试和升级演练观察；可维护性验证通过故障注入和恢复流程观察。

示意性伪代码如下：

cases = build_cases([
    "single_tool", "multi_step", "branch_flow",
    "fuzzy_goal", "multi_role", "parallel_and_error"
])
for arch in architectures:
    for case in cases:
        run = execute_case(arch, case, same_config)
        record(run.logs, run.tool_calls, run.errors,
               run.latency, run.resources, run.manual_interventions)
    report[arch] = summarize(records)
compare_with_baseline(report)
analyze_boundaries(report)

4. 结果解读方法

任务成功率高且重复运行波动小，说明有效性较稳定；若成功率尚可但人工干预率和重试率高，说明自动化闭环不足。工具调用错误集中出现，可能来自工具描述不清、参数约束不足或观察解析不稳；计划步骤明显冗余，可能来自规划粒度不当；多角色消息量过大但产出提升有限，可能来自角色边界不清或通信开销过高；Supervisor调度延迟集中，可能存在中心节点瓶颈；Swarm收敛不稳定，可能需要增加约束、终止条件或一致性检查。

结果解读必须结合技术原因。性能差异可能来自资源配置、缓存策略、网络链路、数据规模、并发模型或依赖组件差异；稳定性差异可能来自重试策略、超时设置、隔离机制和状态管理。不能把单一指标当作绝对结论。

六、六类架构的选型对比与适用场景

架构模式	更适合的场景	应重点关注的评测项	不建议直接使用的条件
ReAct	工具调用明确、任务链路较短、需要一定灵活性	工具选择、循环终止、异常恢复	长链路高风险操作且缺少审计与终止约束
Workflow	流程稳定、规则明确、需要审计和回退	流程覆盖、分支回退、可维护性	任务高度开放且流程频繁变化
Planner-Executor	目标模糊、需要拆解、依赖关系复杂	计划质量、重规划、执行反馈	任务简单且固定，规划成本大于收益
Multi-Agent	需要异构能力组合、角色分工明显	角色边界、通信协议、冲突消解	角色职责不清、共享上下文安全难控
Supervisor	需要中心调度、统一审计和收敛控制	调度策略、单点瓶颈、审计完整性	高并发下中心节点易成瓶颈且缺少扩展方案
Swarm	并行探索、局部自治、弹性分工	收敛性、一致性、通信开销、容错	结果一致性要求高且治理能力不足

总体选型建议是从简单到复杂增量演进：先用ReAct或Workflow验证任务可行性和工具边界；当目标拆解难成为瓶颈时引入Planner-Executor；当能力边界和角色分工成为主要矛盾时再考虑Multi-Agent或Supervisor；只有在并行探索收益明确、治理和观测能力具备时，才谨慎评估Swarm。复杂度应服务于明确问题，而不是替代匹配度判断。

七、风险与限制

评测可能受到样本偏差、环境差异、数据质量、资源限制和长期运行不确定性的影响。短周期测试难以覆盖长期上下文膨胀、依赖服务漂移和容量增长问题；多Agent和群集式架构的错误传播、通信开销和成本放大也容易在单次演示中被低估。安全评测若只覆盖正常路径，可能遗漏越权调用、敏感信息泄露和审计缺口。

因此，评测结论应写明适用条件，例如“在固定工具集合、受控并发和脱敏数据条件下，该架构表现出较好的任务闭环能力；在更高并发、更复杂依赖和更严格审计要求下，仍需补充压测、异常注入和长期观察”。

八、总结

六类Agent架构的核心差异不在于谁更复杂，而在于分别补什么短板、引入什么成本。评测时应围绕功能完整性、准确性、性能、稳定性、安全、兼容性、易用性、可观测性、可维护性、成本和场景适配度建立框架，通过代表性样本、基线对比、控制变量和过程记录验证效果，再结合业务目标解读结果。ReAct适合从行动能力起步，Workflow适合确定性流程，Planner-Executor适合复杂目标拆解，Multi-Agent适合异构协作，Supervisor适合中心调度与审计，Swarm适合受控的并行探索。选型的关键不是追求架构堆叠，而是用可验证的评测证明：当前复杂度确实解决了当前问题，并且风险、成本和维护边界可控。