十几种Agent范式一次讲透，附真实项目落地方案

大家好，我是武哥。这里是 AI实战小课堂 - Agent专题。

做 Agent 时，大家可能都有过这个疑问：框架托管工具调用、ReAct、计划执行、反思、多智能体、长期记忆……名字听了不少，但轮到自己做项目，还是不知道该选哪一种。

比如做一个旅游规划助手：能查景点、查酒店，再生成一份行程，是不是就够了？如果行程超预算，谁来发现？发现之后，谁来修改？第二次修改的时候，会不会又犯同样的错误？

选 Agent 的实现方式，要从这些具体问题出发。

这期用视频 + 文字的形式，把十几种做法背后的工具循环、计划、反馈、协作、搜索和记忆串起来，再结合我的实战项目，看看它们怎样组合成一个能运行、能检查、能停止的系统。先看一下视频：观看视频

多次调用模型，就一定是 Agent 吗？

先看一个简单任务：提取数据，生成摘要，再整理报告。

如果这个顺序已经由代码定好，模型只是负责完成每一步，那通常属于链式工作流。先识别意图再进入预设分支，是路由；固定几个任务同时执行，再汇总结果，是并行工作流。它们都可以调用模型，也可以调用工具。但下一步怎么走，可能始终是代码事先安排好的。

Agent 的关键在于：在约束范围内，根据执行结果决定下一步。

比如查完排课资源发现冲突，它需要继续查，或者调整方案。查到的资料不足以回答问题，它需要换个问法再检索。执行结果会影响后续动作。

所以，步骤能提前确定的任务，可以先用工作流。需要根据结果改变路径时，再考虑引入 Agent。

工具调用有三种做法，区别在于谁管理循环

我们先把最常见的工具调用看明白。

框架托管工具调用：把工具交给框架，循环由框架管理。

以排课为例，把查资源、查规则、校验和写入等方法注册成工具。模型选择工具，框架解析请求并执行，再把结果交回模型。发现冲突，就继续调用；不再请求工具，才输出结果。

看起来外面只调用了一次，里面可能已经走了好几轮。在我的《智能教务排课与教学质量分析系统》中，就有这种实现。

数据库驱动 ReAct：这次允许调用哪些工具，先从注册表里确定。

工具的名称、参数和启用状态保存在表里。请求进来后，程序筛出可用工具，构建回调，再让模型选择动作、执行查询、读取结果。

比如导诊时先查科室，再查可预约时段。某个工具下线，下一次请求就不再把它提供给模型。《智慧医院智能导诊就诊系统》使用了这类结构。

这里的执行器仍然按白名单分发，不能让模型执行数据库里的任意代码。工具表叫 MCP，也不代表已经实现了 MCP 协议。

手写 Function Calling：工具循环放进自己的业务代码。

程序检查模型有没有返回工具调用，校验名称和参数，执行函数，再把请求与结果追加到消息里。下一轮，模型继续决定调用还是回答。

这样能自己控制日志、协议和异常，但重复写入、取消和次数上限，也要自己处理。《智能商城导购与运营增长系统》中有对应实现。

这三种方式都涉及工具循环，主要区别是框架托管、工具动态配置，以及业务代码的控制程度。

任务长了，先拆计划；结果不对，再加反馈

接着看三个很容易混在一起的概念。

Plan-and-Execute，重点是先拆出计划。

比如分析销售下降的原因，可以先查分组数据，再比较变化、核对异常，最后整理结论。模型拆出结构化步骤，程序校验步骤类型，再按依赖执行，保存状态与结果。

我的《数据分析平台》有这类实现。每一步可以交给固定子流程，不一定都要再放一个 Agent。执行中需要重新规划，也得明确接上状态更新和重新规划逻辑。

Reflection，重点是对当前结果提出具体反馈，再修改。

报告漏了统计范围，就指出哪里缺失；修改后继续检查，满足要求或达到上限就停止。只说“再想一遍”，很可能只是让模型换个说法。

Reflexion，多了一步：把失败反馈整理成教训，带到下一次尝试里。

回到旅游规划的例子。第一版行程超预算，程序根据行程明细校验，把超支位置和修改要求保存下来。第二版读取这些教训，再交给内部工具 Agent 修改。

《旅游行程智能规划平台》就是把内部工具执行和外部校验、反思记录组合起来。保存教训是在管理状态，并没有训练模型参数；这些记录保留在哪个任务、能否跨会话使用，都要自己设计。

生成和验收也可以分成两个角色，形成评估—优化环。但无论谁来评价，模型说“通过”都不能代替实际业务校验。

知识库检索一次不够，怎么办？

普通检索链路是：查资料，再回答。

自适应检索 Agent 会多保存一些状态：当前问题、候选资料、评价结果和尝试次数。检索后判断资料是否相关，不够相关就改写问题再查；资料够了，再生成回答，并检查结论有没有依据。

《Agentic RAG高级知识库平台》中有这类结构，通过状态图和条件边，把评价结果转换成下一步。

它的价值是允许根据证据情况调整路径。 但资料一直不足时，要说明无法确认；超过调用预算时，要停止。模型评分也会出错，仍然需要拿真实问题做评测。

多智能体，重点看控制权怎么走

多个 Agent 放在一起，并不只有一种协作方式。

Supervisor：子 Agent 做完，回到主管。

主管根据当前进度决定派给谁，再决定继续还是结束。

我的《长租公寓智能合租匹配平台》把租客画像、房源筛选和匹配审查分成不同职责，由主管调度。

Handoff：当前 Agent 把控制权交给另一个 Agent。

比如售前发现用户要退款，就把必要的订单上下文交给售后，接下来由售后继续。调度器要校验目标角色，避免互相踢皮球，也不能因为移交就自动增加权限。

多智能体辩论：从不同职责出发比较方案。

比如采购看交期，财务看成本，风险角色检查合规。先独立判断，再带着证据讨论分歧，最后按规则汇总。多个模型意见一致，也可能同时犯错。

编排器—工作者：根据目标动态拆出子任务。

比如研究竞争产品，任务维度不是固定写死的，而是这次根据目标生成，再创建工作者、控制并发、汇总和补查。

选择时，要看自己需要中心调度、职责移交、观点比较，还是动态拆任务。角色数量增加以后，各自能看什么、能改什么，也要跟着明确。

搜索和记忆，分别补哪种能力？

如果任务存在很多种组合，而且能判断候选结果好坏，可以考虑树搜索。

比如资源调度，先展开几种排法，剪掉不满足约束的分支，保留较好的继续探索。走不通时，回到之前的状态尝试另一条路。

程序需要保存候选树、父节点、评价和搜索预算。ToT 侧重候选推理搜索，LATS 还结合行动与环境反馈，两者不能直接画等号。分支越多，成本越高，宽度、深度和调用次数都要限制。

长期记忆则解决另一件事：换个会话，确认过的事实和偏好还能不能接着用？

《智能记账与个人财务管家》中，执行前会按用户和问题检索相关记忆，执行后再提炼值得保留的新事实。写入前要检查来源、冲突和确认要求，并支持更新或遗忘。

不能把全部聊天记录直接当成可靠记忆。用户纠正了分类，后面就不应该继续使用旧值；不同用户的记忆，也必须隔离。

我的实战项目里，分别用了哪些方式？

视频中有具体实现的项目，整理如下：

实现方式	对应实战项目
框架托管工具调用	《智能教务排课与教学质量分析系统》
数据库驱动 ReAct	《智慧医院智能导诊就诊系统》
手写 Function Calling	《智能商城导购与运营增长系统》
Plan-and-Execute	《数据分析平台》
自适应检索 Agent	《Aegentic RAG高级知识库平台》
Reflexion	s》
Supervisor	《长租公寓智能合租匹配平台》
长期记忆增强	《智能记账与个人财务管家》

实际项目往往会组合使用。旅游规划是工具执行加校验和教训；记账是工具循环加长期记忆；高级知识库则把检索、改写、生成和依据检查放进状态图。

这些能力解决的问题不同，没有必要强行把它们分成只能选一个的方案。

自己的项目怎么选？先问三个问题

第一，谁决定下一步？

步骤能提前确定，优先工作流。下一步依赖执行结果，再考虑工具 Agent。任务长、依赖多，加计划；证据不足需要换路径，加自适应检索。

第二，执行结果保存在哪里？

工具结果、步骤状态、失败原因和修改版本，需要有明确记录。要复用失败教训，加反思记忆；要跨会话使用偏好，再设计长期记忆。

第三，满足什么条件才算完成？

模型说完成了，还要反查业务结果。调用次数、超时和成本要有上限；涉及高风险写入或外部动作，在执行前加入校验与必要审批。

MCP 负责标准化工具接入，人工介入负责审批和接管，它们也能参与系统设计，但不是另外两种决策范式。

我们可以先用最简单的方式跑通，再根据真实失败增加规划、反馈、协作或记忆。把这三个问题看清楚，Agent 就不再只是一串英文名。

真正能落地，要做到动作执行得对、过程查得清、失败收得住。

欢迎看完视频和文章后，拿自己的项目对照一下：现在最缺的是工具循环，还是计划、验收和状态管理？

如果这篇文章帮你理清了 Agent 的实现思路，也欢迎分享给正在做 AI 应用的朋友，点赞、在看、关注支持一下。我是武哥，我们下期见！