智能体经典范式：从规划到记忆的系统构建与工程实践

1. 智能体经典范式：为什么值得系统构建

智能体（Agent）这个概念在AI圈子里已经被聊烂了，但大多数人聊的是“效果”，很少聊“结构”。我见过太多人拿到一个大模型API，写一个while循环，让模型反复调用工具，就声称自己做了个智能体。跑通一个Demo不难，难的是这个Demo能不能稳定迭代、能不能换场景复现、能不能在线上扛住真实流量。这就是为什么要把“经典范式”单独拎出来讲——它不是某个模型的能力，也不是某个框架的特性，而是一套被反复验证过的架构模式。

所谓经典范式，核心就是“感知—规划—行动—记忆”这个循环。你给智能体一个目标，它把目标拆成子任务，调用外部工具获取信息或执行操作，再把结果写回记忆，然后继续下一步。这个循环看起来简单，但每一层都有大量的设计取舍。什么时候该重新规划？工具调用结果不可信怎么办？短期记忆和长期记忆怎么切分？这些细节决定了你的智能体是玩具还是生产力工具。

这篇文章适合正在做Agent应用、想把Demo往生产环境推的开发者。我会从范式结构、核心环节、最小闭环实操、高频踩坑四个维度展开，尽量把我实际验证过的东西讲透，包括每一步的取舍逻辑和参数依据。

我最早接触这套范式是在做一个客服工单分析项目，当时直接用大模型做意图识别加信息抽取，效果很一般，因为单次调用根本Hold不住多轮信息关联。后来我把它改成了标准的三层结构：规划层负责拆解工单处理流程，执行层对接工单系统API，记忆层保存会话上下文和客户历史记录，整个系统马上就稳了。这不是模型变强了，而是结构变对了。

2. 核心环节拆解与设计取舍

2.1 规划层：任务分解的两种粒度

规划层是整个范式的“大脑”，它决定了一个大目标如何拆成可执行的小步骤。目前主流做法有两条路线：一种是ReAct风格，让模型边想边做，每一步都基于当前观察结果决定下一步动作；另一种是Plan-and-Execute风格，先让模型一次性生成完整计划，再逐步执行。

我两个方案都试过，直接说结论：如果你的任务链条相对固定，比如“查订单→核对库存→发起退款”，用Plan-and-Execute更稳，因为每一步的输入输出边界清晰，不容易跑偏。但如果是探索型任务，比如“帮我研究一下这个行业最近有什么变化”，你根本没法预先列计划，这时候ReAct才有优势，因为它能根据检索到的信息动态调整方向。

很多人在这一步犯的错是：希望模型“一步到位”生成完美计划。实际上规划也需要迭代。我常用的做法是给规划层一个“允许修正”的机制，在执行过程中如果发现某个子任务的结果和预期偏差超过阈值，就回到规划层重新生成后续计划。实现方式不复杂，就是在循环里加一个条件判断：当前结果置信度低，或者工具返回了明确的错误标记时，暂停执行，重新调用规划模型。

2.2 行动层：工具调用的接口规范

行动层是智能体和外部世界交互的桥梁，也是我认为整个范式里最需要工程规范的部分。一个常见的坑是：模型输出了工具调用意图，但参数格式不标准，导致下游系统解析失败。你可能会说“大模型不是支持JSON输出吗”，但JSON输出和“稳定可用的JSON”之间隔着十万八千里——字段缺失、类型错误、嵌套层级不对，什么问题都可能出现。

解决方案是建立严格的工具描述规范。每个工具必须有三个部分：功能描述、参数Schema、返回结果Schema。参数Schema我建议用JSON Schema标准来定义，因为它能直接传给模型作为约束，同时也能在后端做运行时校验。返回结果Schema同样重要，因为智能体依赖工具返回结果来决定下一步行动，如果返回结构不稳定，规划层很容易被误导。

我自己在实际项目里总结了一个小技巧：所有工具返回结果统一包一层状态字段，比如success或者error_code。这样智能体可以在行动层直接判断本次调用是否可信，不需要让大模型去“猜测”返回内容是否正常。这个设计对提升多步任务的稳定性帮助极大。

2.3 记忆层：短期上下文与长期知识

记忆层是经典范式中最容易被低估的环节。很多初版智能体其实就是把所有历史对话全部塞进上下文，跑几轮之后上下文爆炸，模型开始胡言乱语。记忆至少应该拆成两层：短期记忆保存当前任务相关的中间状态，长期记忆保存跨会话的知识和用户偏好。

短期记忆的管理方式建议直接和任务绑定。也就是说，每次规划生成子任务清单之后，短期记忆就应该围绕这些子任务组织，而不是无脑保留全部对话记录。当一个子任务完成，它的中间过程就可以归档压缩，腾出空间给后续步骤。

长期记忆则要考虑结构化存储。我通常的做法是把关键信息抽取成结构化条目，比如用户的偏好、项目的状态、历史决策的原因，然后按需检索注入到上下文中。这里有个要点：注入时机比存储方式更重要。你得在规划开始前注入一次，在关键决策点再根据相关性动态补充，而不是一股脑全部塞进去。

2.4 反思与自我修正机制

经典范式的高级形态是加入反思层。这个反思不是让模型随机“检查一下”，而是要有具体的评估指标。比如客服智能体，反思的内容可以是：这条回复是否解决了用户的核心诉求？是否有信息遗漏？语气是否合适？然后把反思结果作为下一步行动的修正输入。

我试过用“自我批判”生成改进建议再让模型重写答案，也试过用外部规则做硬性校验。结论是：外部规则校验的性价比远高于模型自我反思，因为模型自我反思容易陷入“反复确认但改不出实质内容”的鬼打墙。建议把反思层设计成两层：第一层用规则引擎做硬校验，比如必填字段是否齐全、工具返回码是否正常；第二层才用模型做软评估，比如回答的完整度、逻辑连贯性。

3. 实操：搭建一个最小闭环Demo

3.1 场景定义与任务目标

我们用一个具体的模拟场景来演示经典范式的完整搭建流程：做一个库存查询智能体，用户可以用自然语言询问某个商品的库存状态，智能体需要查库存系统、判断是否低于安全阈值，并结合订单报表生成一个简短的建议。

这个场景虽然简单，但涵盖了范式的所有核心环节：意图解析（规划）、系统查询（行动）、上下文保持（记忆）、结果评估（反思）。更重要的是，它的业务逻辑足够清晰，方便我们观察每一步的输入输出。

开始之前先明确定义工具接口。我们需要两个虚拟工具：一个是query_inventory，输入商品ID和仓库代码，返回当前库存数量；另一个是get_order_stats，输入商品ID，返回近期订单量。安全阈值这个逻辑我建议做成纯规则，放在工具内部，不交给模型计算，因为这种属于确定性逻辑，不需要“智能”。

3.2 核心循环代码实现

主循环我用一个Agent类来封装，核心逻辑如下：

class Agent: def __init__(self, planner, executor, memory): self.planner = planner self.executor = executor self.memory = memory def run(self, user_query): # 注入长期记忆中的相关条目 self.memory.inject_context(user_query) # 规划：生成子任务清单 plan = self.planner.create_plan(user_query, self.memory.short_term) # 执行循环 for step in plan.steps: result = self.executor.execute(step) self.memory.update(step, result) # 校验是否通过，未通过则触发重新规划 if not self.executor.validate(result): plan = self.planner.revise_plan(step, result) continue # 暂存本步结果，用于最终汇总 self.memory.observations.append(result) # 汇总生成最终回复 final_answer = self.planner.summarize( user_query, self.memory.observations ) return final_answer

这段代码的核心不是循环本身，而是三个设计细节。第一，每一步执行后都要调validate做结果校验，这是防止智能体在错误路径上越走越远的保险丝。第二，memory.short_term存的是任务中间状态，每次查询后都会更新，这样即使模型上下文长度有限，也能通过外部记忆“记住”关键信息。第三，planner.summarize单独生成最终回复，而不是让执行步骤直接输出给用户，这样能够保证最终答案的完整性和可读性。

3.3 提示词模板的构造要点

规划层的提示词是整个Demo的灵魂。我的模板结构包含四个区块：角色定义、可用工具清单、任务拆解要求、输出格式约束。

角色定义要明确“你是负责处理库存查询的助手，你只能使用提供的工具获取数据，不要猜测或编造结果”。工具清单部分我会把工具的JSON Schema直接贴在提示词里，让模型生成符合Schema的调用参数。任务拆解要求强调“每一步只做一件事”，因为经验表明多任务合并的步骤容易遗漏错误处理。输出格式约束我会给定一个明确的JSON结构模板，包括步骤名、工具名、参数、预期结果。

还有一个容易被忽略的点：给模型提供“未知”的选项。很多失败场景是因为模型遇到无法处理的问题时强行作答。我在模板里显式写了“如果任务涉及的信息不完整，请回复UNKNOWN并说明缺失项”，这样智能体至少不会输出编造的库存数据。

3.4 经验参数：温度与步数上限

实操中两个参数值得单独说。温度参数我建议规划层设0.2以下，保证任务分解的稳定性；而总结生成阶段可以适当调高到0.5，让最终回复稍微自然一点。步数上限这个参数特别重要，经典范式的死循环问题很多时候不是逻辑错了，而是模型在不确定的状态下反复尝试。我一般设上限为任务规模×2加3，超过上限就强制结束并返回“当前任务复杂度超出处理能力”。

4. 实战踩坑：五个高频问题与排查速查表

4.1 多轮对话后智能体“失忆”

这是最常见的问题，症状是前几轮还能记住用户提到的约束条件，几轮之后就开始遗忘。排查思路要看记忆层是不是只依赖模型上下文。正确做法是把用户提供的所有约束条件在进入执行流程前就抽取出来，写入短期记忆的结构化字段，比如restrictions列表。这样即使上下文被截断，也能在每一步执行前重新注入。

我还发现一个规律：很多“失忆”是提示词结构导致的，把用户约束写在长对话中间，模型注意力会被后面的内容稀释。解决办法是每轮系统提示词末尾都主动带上“请记住，用户特别要求：{关键约束}”，效果立竿见影。

4.2 工具调用参数幻觉

模型生成工具调用时，编造了一个不存在的参数值，这是另一个高频坑。比如用户只提到“华东仓”，但工具要求传准确的仓库代码，模型可能直接猜一个“HZ01”，而实际上仓库代码是“CN-HZ-01”。

我的解决方案是三层防御。第一层，工具描述里提供参数取值示例，减少模型猜测空间；第二层，后端做参数格式校验，匹配不上就返回明确错误信息，包括当前可用值的枚举列表；第三层，规划层拿到错误信息后重新规划，而不是把错误原样回给用户。实测这三层加完后，参数错误导致的失败率从接近30%降到了5%以下。

4.3 死循环与重复调用

模型在某个步骤失败后反复重试同一个工具，不换策略。这通常是因为规划层的“修正”逻辑没有生效。我建议在循环执行器里加一个快速失败机制：同一个工具连续失败两次，不再返回给规划层，而是直接标记该任务为失败，跳转到兜底策略。

兜底策略可以设计成“降级回复加人工介入”。比如给出模板化的“当前系统无法完成该查询，请稍后再试或联系客服”，同时把失败上下文记录到长期记忆中，方便事后分析。死循环消耗的成本是token和延迟，越早放弃越省钱。

4.4 上下文注入导致幻觉加剧

记忆层设计不合理反而会毒化模型输出。我踩过的坑是把所有历史记录一股脑注入，结果模型被无关信息带偏。比如用户之前问过A商品，这次问B商品，历史记录里A商品的细节大量注入后，模型回答B商品时混入了A的信息。

解决办法是为记忆注入设一个相关性阈值。我采用的方法很简单，先做一次轻量的向量检索，只注入相似度排前五的记录，并且每条记录带时间戳，防止过时信息干扰当前决策。对大多数中小规模项目来说，不需要复杂的记忆管理中间件，一个向量库加阈值过滤就足够了。

4.5 经典范式问题排查速查表

这张表是我回顾多个项目的共性总结，虽然场景各不相同，但根因高度集中在规划粒度和记忆管理这两个环节上。

5. 范式扩展：从单智能体到复合体系

经典范式跑通之后，很多人会自然想往复杂方向扩展。我觉得有两个扩展方向价值最高：一个是把“反思”从可选项变成必选项，建一个独立的评估模型来审查主模型的每一步输出；另一个是引入多智能体协作，让不同智能体分别承担规划、执行、审查的角色。

先说反思评估模型。主模型负责干活，评估模型负责挑刺，两个模型分工明确，比让同一个模型边干活边检查要可靠得多。评估模型不看完整历史，只看当前步骤的输入输出和预期目标，输出“通过”“需修正”“需重规划”三分类判断。这个设计还有一个额外好处：评估系统的规则升级不需要动主模型逻辑，改评估模型本身的提示词或训练数据就行。

再说多智能体协作。我这里说的不是那种花哨的多角色扮演，而是务实的分层协作。比如一个智能体专门做任务拆解，拆解结果交给多个执行型智能体并行处理，再由一个汇总型智能体合并结果。核心难点在于执行型智能体之间的状态同步，我建议用共享的短期记忆库来解决，每个执行智能体只读写自己的键空间，汇总型智能体统一读取所有键空间做整合。

从工程角度看，扩展的前提是单智能体闭环已经足够稳定。如果基础循环还会死循环、还会幻觉参数，千万不要急着上多智能体——复杂度的提升会让问题排查难度成倍增加。先把手头这套经典范式压榨到极限，再考虑向上扩张，这才是务实的路径。

我个人在实际操作中最深的体会是：范式的作用不是限制思路，而是提供一套已经验证过的骨架，让我们的精力能聚焦在业务逻辑和场景细节上。经典范式之所以经典，是因为它在无数次失败中兜住了底，让每个后入场的人不用从头趟一遍所有的坑。先把这套东西吃透，再谈超越它也不迟。