《Spring AI 2.0实战》第16招 五种Agent模式
最近团队在做技术选型，需要一份关于开源 API 网关的调研报告。我是老李，起初把任务丢给一个模型，让它一次生成。报告很快出来了，但问题也多：官网链接已经 404，GitHub 的 star 数与实际页面不一致，论文部分只摘了摘要没有结论。最要命的是，模型自己并不觉得有问题，也不会主动回去修改。我们需要的不是更长的输出，而是把任务拆成可检查、可回退、可组合的步骤。今天就用“生成技术调研报告”这个真实场景，聊聊五种协作模式到底怎么落地。 ## 01、痛点 单次生成技术调研报告，通常会遇到四类问题。 第一，信息源单一。模型倾向于从训练数据中拼凑答案，而不是实时访问官网、代码仓库和论文数据库，导致版本、许可证、维护状态等关键信息失真。比如有一份报告里写着“最近版本为 3.3”，实际上项目仓库已经发布了 4.0。 第二，任务边界不清。一份调研报告同时包含背景梳理、社区活跃度评估、性能对比、风险判断，混在一个生成过程里，哪个环节出错很难定位。我们曾遇到报告结构完整，但性能对比部分完全缺失，因为模型把注意力放在了功能列表上。 第三，没有校验闭环。输出完就结束，缺乏“检查—发现问题—重新生成”的机制。模型不会自己质疑自己，尤其当错误藏在细节里时，读的人往往最后才发现。 第四，节点越多越容易失控。很多团队一开始就画一个复杂流程图，结果状态传递混乱，调用成本高，效果反而不如直接生成。这不是说不要拆分，而是说拆分必须有明确边界。 ## 02、是什么 这五种协作模式分别解决不同问题。 链式（Chain）把任务切成前后依赖的步骤，前一步输出作为下一步输入，例如先搜索再摘要最后格式化引用。适合流程天然线性、后一步强依赖前一步的场景。 并行（Parallelization）用于相互独立的子任务，例如同时查官网、GitHub 和论文，最后由合并步骤汇总。适合数据源不同、彼此没有依赖的场景。 路由（Routing）根据输入特征把任务交给专用处理器，例如先判断主题是软件选型还是学术综述，再走不同分支。适合入口多样、不同输入需要不同模板的场景。 编排—执行（Orchestrator-Workers）由一个编排者动态拆解任务，分派给多个执行者，再回收结果并整合。适合任务边界不预先固定、需要按情况拆解的场景。 评估—优化（Evaluator-Optimizer）先由生成者产出初稿，再由评估者指出缺陷，生成者根据反馈修改，形成循环。适合质量要求高、需要多轮校正的场景。 它们不是五个孤立工具，而是一组可以组合的过程控制手段。 ## 03、为什么 现在模型能力虽然强，但复杂任务仍然不能靠一次调用解决。技术调研报告对事实准确性要求高，涉及多个异构数据源，单一模型容易产生幻觉和信息滞后。五种模式的可贵之处在于，它们不改变模型本身，而是改变任务的组织方式。把过程拆开后，我们可以在任意节点插入人工确认、日志、缓存和重试，成本可控。对于技术团队，这意味着从“祈祷模型一次答对”转向“用流程保证结果可验证”。特别是在数据会变化的场景里，单次生成得到的是一份静态快照，而协作流水线得到的是可以持续更新的报告。 ## 04、架构 整体流程可以抽象为六个阶段：入口先经过路由识别主题，然后交给编排者拆解，编排者把子任务分派给官网、代码仓库、论文三个执行者，三者并行工作；结果合并后交给评估者检查，通过则输出报告，不通过则发回对应执行者或重新拆解。 路由节点接收“开源网关选型调研”，判断主题为“开源软件评估”，选择评估模板。编排者拆解三个子任务：官网调研、代码仓库调研、论文调研。三个执行者并行执行，各自返回结构化片段。编排者合并片段，处理冲突。评估者检查数据一致性、信息时效、维度完整性，给每个子任务打分。低于阈值就送回对应节点重做，直到通过。 状态上需要维护任务清单、上下文快照、版本号和重试计数。每个节点只负责自己那一段，输入输出保持结构化，避免把上一节点的自然语言直接透传给下一节点。比如官网执行者只接收项目名称和官网地址，返回许可证、最新版本、维护者三个字段；代码仓库执行者只接收仓库地址，返回 star 数、open issues 数、最近提交时间。 ## 05、实战 以“生成技术调研报告”为例，任务输入是：“调研开源 API 网关项目，产出选型建议”。 第一步，路由判断主题。路由节点根据关键词和项目上下文，输出 task_type = software_evaluation，并选择对应模板。如果没有路由，这份任务可能会被套用学术论文模板，漏掉社区活跃度。 第二步，编排者拆解。拆成三个子任务： - 官网调研：许可证、维护者、架构特性、最近发布版本。 - 代码仓库调研：star 趋势、PR 合并周期、issue 活跃度、最近提交。 - 论文调研：性能对比、安全分析、相关学术结论。 每个子任务都有明确的数据来源和返回字段，避免重复和遗漏。 第三步，并行执行。三个执行者各自调用外部检索工具，返回结构化 JSON 片段。例如官网执行者返回 license、latest_version、maintainer；代码仓库执行者返回 stars、open_issues、last_commit；论文执行者返回 performance_comparison、security_notes。 第四步，编排者汇总。把三份片段合并成初稿，若发现矛盾（例如官网称最近版本为 3.2，代码仓库 tag 最新为 3.1），先保留双方来源并标记冲突，而不是擅自丢弃一方。 第五步，评估者检查。检查维度包括：数据源是否更新到最近 30 天？GitHub 数据是否与页面一致？是否遗漏许可证、安全漏洞、替代方案？是否给出了可复现的性能对比？若未通过，生成一条反馈，比如“补充 Apache 2.0 许可证说明，重新抓取 GitHub 最新 release”，然后发回给编排者或对应执行者。 在一次实际运行中，官网调研节点返回了过期链接，评估者发现后没有直接通过，而是发回“官网链接 404，请从项目 README 或文档站重新获取许可证信息”。执行者重做后，报告才被放行。这个回退过程只重做官网一个节点，不会牵连代码仓库和论文部分。 ## 06、洞见 回到那个问题：是不是节点越多效果越好？ 答案是否定的。五种模式的真正成本来自模型调用次数、状态复杂度和不可预测性。每增加一个执行节点，就多一次输入输出、多一份状态要维护、多一个可能出错的位置。以调研报告为例，官网、代码仓库、论文三个节点是合理的，因为数据源不同、无法互相替代；但如果再把代码仓库拆成 star 调研和 issue 调研两个节点，往往收益很低，因为两者可以从同一个页面一起获取。 可以用一句话衡量：节点价值 = 减少的返工成本 - 新增的调用与状态成本。如果一个节点不能替下游省下返工，或者不能补上不可替代的事实来源，就应该合并。好的编排不是图越复杂越牛，而是每个节点都像流水线上的质检工位，有明确的拦截清单。 ## 07、行动 建议先小后大，不要一上来就画大一统流程图。 第一步，把链式、并行、路由、编排—执行、评估—优化各写一个最小 Demo。链式最小 Demo 可以串三个步骤：搜索、摘要、引用格式化。并行最小 Demo 可以同时调用三个独立接口，最后合并。路由最小 Demo 用规则或分类模型把输入分到两个模板。编排最小 Demo 用一个编排者拆出两个执行者。评估最小 Demo 对初稿打分并修改一轮。 第二步，分别跑通五个最小闭环，确认各自能独立运行。 第三步，再组合到技术调研报告场景。组合时先固定数据格式和状态结构，避免节点间字段混乱。 第四步，给每个节点记录调用次数、耗时、失败率，数据不达标就合并或删除节点。验收标准可以简单：报告中的每个关键事实都能追溯到具体来源；任何节点失败都能单独重试；每次重做不需要重跑整个流程。 ## 08、小结 技术调研报告不是一个简单问答，而是一条需要多源采集、交叉校验、回退修正的流水线。链式解决顺序依赖，并行解决独立子任务，路由解决入口分流，编排—执行解决动态拆解，评估—优化解决质量闭环。五种模式组合起来，不是为了把图画得复杂，而是为了让每一步都可控、可回放、可修正。节点不是越多越好，每个节点都必须有明确价值。 ## 09、链接与概念说明 本文涉及的五个概念： - 链式：串行处理，前一步输出作为后一步输入。 - 并行：独立任务同时执行，最后合并。 - 路由：根据输入特征选择专用处理分支。 - 编排—执行：编排者动态拆解任务并分派执行者，回收结果。 - 评估—优化：生成与评估循环，直到满足质量条件。 进一步阅读可参考 Anthropic 官网关于多步骤协作模式的公开技术文档，以及模型 API 文档中的函数调用和结构化输出部分。也可以搜索“多阶段推理”和“结构化生成”等资料，但本文的核心价值在于：先拆成最小闭环，再按价值决定是否增加节点。
