辩论/竞争模式(Debate & Competition)
多个 Agent 对同一问题各自作答、互相质证,通过多轮辩论逼近更可靠答案的协作模式。
根据任务特征选择最合适的 Agent 设计模式,避免过度设计或能力不足
内容摘要
按场景选型,就是在动手开发 Agent 之前,先搞清楚你的任务到底需要什么能力,然后选择"刚好够用"的设计模式。
按场景选型,就是在动手开发 Agent 之前,先搞清楚你的任务到底需要什么能力,然后选择"刚好够用"的设计模式。
这个概念之所以重要,是因为 Agent 设计模式从简单到复杂有很多层级:最简单的是一次 LLM 调用(Direct Model Call,直接模型调用),复杂的可以是十几个 Agent 协同工作的多智能体系统。选错了模式,要么过度设计——花了三个月搭建多 Agent 架构,结果一个提示链(Prompt Chaining)就能搞定;要么能力不足——用单次调用去处理需要多轮迭代的代码生成任务,效果惨不忍睹。
Anthropic 在其 Building Effective Agents 指南中明确建议:"先找最简单的方案,只在必要时才增加复杂度。" Microsoft Azure 架构中心也把复杂度分成三级:直接模型调用 → 单 Agent + 工具 → 多 Agent 编排,强调"用最低复杂度满足需求"。这个原则是按场景选型的核心。
选型决策围绕三个维度展开:
| 维度 | 关键问题 | 影响 |
|---|---|---|
| 任务可分解性 | 任务能否拆成固定步骤?还是步骤本身需要动态决定? | 决定用 Workflow(工作流)还是 Agent(自主智能体) |
| 并行度 | 子任务之间是否独立、可以同时处理? | 决定是串行管道还是并行扇出 |
| 迭代需求 | 输出需不需要"生成→评估→改进"的反复打磨? | 决定是否引入反思(Reflection)循环 |
这是最关键的判断。如果任务步骤是固定的、可预测的(比如"翻译→校对→排版"),用 Workflow 就够了——你提前把路径写死,每一步该干什么都确定。如果步骤本身需要 LLM 自己决定(比如"研究一个开放课题"),就需要 Agent 来动态规划。
有些任务的子步骤互不依赖。比如审核一篇文章,可以同时检查"事实准确性""语法""政策合规性",三路并行再汇总结果。并行处理能显著降低延迟,但需要一个汇聚机制来合并结果。
代码生成、文学翻译这类任务,一次输出往往不够好。需要一个评估器打分、给反馈,然后生成器据此改进,循环往复直到达标。这种"评估者-优化者"(Evaluator-Optimizer)模式会增加 2-3 倍的 Token 消耗,只有在迭代确实能带来可衡量的质量提升时才值得用。
按场景选型的核心逻辑是一棵决策树,从最简单的方案开始,逐步升级:
每升一级,都会增加协调开销、延迟和成本。所以选型的原则不是"越高级越好",而是"在当前层级能解决就不要升级"。
图解说明:
下面用伪代码展示选型逻辑的核心思路:
def select_pattern(task):
"""根据任务特征选择 Agent 设计模式"""
# 第一关:能不能一次搞定
if task.is_single_step:
return "direct_model_call"
# 第二关:步骤是否固定
if task.steps_are_predictable:
if task.steps_are_independent:
return "parallelization" # 并行化
else:
return "prompt_chaining" # 提示链
# 第三关:需要多少个 Agent
if task.single_domain and task.tool_count < 10:
return "single_agent_with_tools" # 单 Agent + 工具
# 第四关:多 Agent 的协作方式
if task.subtasks_need_discussion:
return "group_chat" # 群聊协作
else:
return "orchestrator_workers" # 编排者-工作者
这段伪代码对应决策树的判断逻辑,实际选型时需要综合考虑延迟、成本和可靠性等约束。
| 概念 | 与按场景选型的区别 | 更适合关注的重点 |
|---|---|---|
| 模式对比(Pattern Comparison) | 模式对比聚焦"两个模式之间有什么不同",是横向比较;按场景选型聚焦"我的任务该用哪个",是纵向匹配 | 已经缩小到两个候选模式时,用对比做最终决定 |
| 技术选型(Tech Stack Selection) | 技术选型选的是具体框架和工具(LangChain vs CrewAI);按场景选型选的是抽象模式(提示链 vs 编排者-工作者) | 先定模式,再选框架——模式是"设计",框架是"实现" |
| 复杂度评估(Complexity Assessment) | 复杂度评估只回答"这个任务有多复杂",不回答"该用什么模式";按场景选型把复杂度评估作为输入之一 | 作为选型的第一步,判断任务在复杂度光谱上的位置 |
核心区别:
| 常见误区 | 正确理解 |
|---|---|
| 越复杂的模式效果越好 | 研究表明多 Agent 系统在并行任务上能提升 81% 性能,但在串行任务上反而会下降高达 70%。复杂度错配会适得其反 |
| 所有 Agent 都需要反思(Reflection) | 反思循环会增加 2-3 倍 Token 消耗。只有在"迭代确实能提升质量"的场景(如代码生成、文学翻译)才值得用。客服问答不需要 Agent 自己评价回答质量 |
| 先选框架再定模式 | 正确顺序是:分析任务 → 选定模式 → 再选框架。先看了 LangGraph 的文档就决定用多 Agent 编排,是本末倒置 |
| 单 Agent 不够就直接上多 Agent | 中间还有很多选项:优化 Prompt、精简工具集、引入 RAG、加路由分流。Azure 架构指南指出"单 Agent + 工具"往往是企业场景的正确默认选择 |
参考答案:
Workflow(工作流)通过预定义的代码路径来编排 LLM 和工具,步骤是固定的、可预测的;Agent(自主智能体)由 LLM 动态决定自己的处理流程和工具使用,步骤是不确定的。简单说:Workflow 是"你告诉它怎么走",Agent 是"它自己决定怎么走"。
参考答案:
应该选并行化(Parallelization)模式,具体是"分段"(Sectioning)变体。理由:三个检查维度互相独立、不需要串行依赖,可以同时执行以降低延迟;最后用汇聚逻辑(任意一项不通过 → 拦截)合并结果。不需要多 Agent 编排,因为每个检查任务是固定的、不需要动态规划。如果三个检查结果可能冲突需要讨论,才考虑群聊模式,但这里是简单的"与"逻辑,并行化足够了。
参考答案:
有两种升级路径,取决于"不确定性"的程度:
(1)如果可以用规则判断(比如"合同类文档一律做合规检查"),在现有提示链中加一个路由(Routing)节点即可——先分类文档类型,再走不同的后续链路。这保持了 Workflow 的可预测性,改动最小。
(2)如果判断本身需要 LLM 理解文档内容后才能决定(比如"包含敏感条款的才做合规检查"),就需要把分类步骤升级为一个有工具访问能力的单 Agent,由它动态决定是否触发合规检查。这引入了 Agent 层的灵活性,但也增加了调试复杂度。
优先尝试方案 1,因为路由模式仍然是 Workflow,比引入 Agent 更可控。
优先展示同分类且标签更接近的内容,方便继续串联学习。
多个 Agent 对同一问题各自作答、互相质证,通过多轮辩论逼近更可靠答案的协作模式。
多层级 Agent 树状组织,通过逐层委托实现大规模任务的分解与协调。
多个 Agent 按固定顺序依次处理,前一个的输出作为后一个的输入,形成单向流水线。