大模型能写诗、能答题、能陪你聊天但真让它去订一张机票、改一段代码、跑一轮数据分析十有八九会卡在某个环节上——不是忘了上一步干了什么就是拿着工具不知道怎么下手。这个落差就是懂回答和会干活之间的距离。Agent 智能体架构要解决的正是这段距离。我做了几个 Agent 项目之后最大的感受是模型本身的能力只是地基真正决定一个智能体能不能干活的是它外面那套 Planning、Memory、工具调用和执行的骨架。这篇就围绕 Agent 智能体架构把 Planning 和 Memory 这两块最核心的机制拆开讲顺带把工具编排、执行循环、常见坑都过一遍。不管你是刚接触智能体开发还是已经用 LangGraph、Dify 这类框架搭过东西应该都能从里面找到能直接抄的配置和能避开的坑。1. 从懂回答到会干活Agent 到底多了什么先把最基础的问题说清楚一个普通的大模型调用和一个 Agent本质区别在哪。普通调用是输入一段文本输出一段文本模型是无状态的它不知道上一轮发生了什么也没法主动去查资料、跑代码、调接口。你问它今天北京天气怎么样它只能根据训练数据里的旧信息瞎猜或者干脆说我无法获取实时信息。而 Agent 是输入一个目标输出一串动作和最终结果它能在中间自己决定下一步做什么、调用什么工具、要不要回头修正。这个差别落到架构上就是几个关键组件的叠加。我习惯把它拆成四层来看Planning规划负责把大目标拆成可执行的小步骤Memory记忆负责记住做过什么、知道什么Tool Use工具调用负责和外部世界交互Execution Loop执行循环负责把上面这些串起来反复跑直到任务完成或判定失败。这四层里Planning 和 Memory 是最容易被低估、也最容易出问题的两块。很多人搭 Agent 的时候把精力全花在接工具上结果跑起来发现模型规划得乱七八糟或者聊到第五轮就把前面说过的约束忘光了。为什么 Planning 这么关键因为大模型天生是一步到位的思维模式你给它一个复杂任务它倾向于直接给一个看起来完整的答案而不是老老实实分步推理。但真实任务往往需要多步而且后一步依赖前一步的结果。Planning 机制就是强行把这个一步到位掰成一步一步来。常见的做法有几种一种是ReAct 模式让模型在每一步先输出思考Thought再输出动作Action然后观察结果Observation循环推进另一种是Plan-and-Execute 模式先让模型一次性生成完整计划再逐步执行执行中允许调整还有Tree of Thoughts这类更重的搜索式规划适合需要探索多条路径的场景。选哪种取决于你的任务复杂度和对延迟的容忍度。Memory 则是另一个维度的东西。它要解决的是上下文窗口有限和任务需要长期状态之间的矛盾。一个销售智能体要记住客户上次聊到哪、偏好是什么一个代码智能体要记住项目结构、之前改过哪些文件。这些信息不可能全塞进 prompt 里所以需要分层管理短期记忆放当前对话长期记忆放跨会话的知识工作记忆放当前任务中间结果。后面我会专门用一节讲 Memory 的分层设计和 A-MemGuard 这类防护思路。提示如果你现在搭的 Agent 只能完成单轮、无状态的任务那它本质上还是个带工具调用的问答别急着叫它智能体。判断标准很简单——把任务拆成三步以上、中间需要记住状态它还能不能跑通。2. Planning 机制拆解ReAct、Plan-and-Execute 与 LangGraph 的 planning 模式Planning 是 Agent 的大脑前额叶负责决策和拆解。这一节把主流方案讲透重点说清楚每种方案适合什么场景、坑在哪。2.1 ReAct最朴素也最通用的规划循环ReAct 的核心就一句话让模型在每一步显式地想一下再动手。它的循环结构是 Thought → Action → Observation → Thought → ...直到模型认为可以给出最终答案。这个模式的好处是通用、实现简单、对模型能力要求相对低。你甚至不需要框架手写一个 while 循环加正则解析就能跑起来。但 ReAct 的坑也很明显。第一它容易绕圈——模型可能反复调用同一个工具或者在一个死胡同里打转因为它没有全局计划只看眼前一步。第二它对 prompt 的格式稳定性要求高一旦模型输出的 Action 格式解析失败整个循环就断了。第三步数一多上下文迅速膨胀成本和延迟都上去了。我实测下来ReAct 适合步骤数在 3 到 8 步、每步动作相对独立的任务比如查资料→总结→写邮件这种。超过这个复杂度就该考虑 Plan-and-Execute 了。2.2 Plan-and-Execute先谋后动适合长链路任务Plan-and-Execute 把规划拆成两个阶段Planner 先产出一个完整的步骤列表Executor 再逐步执行每执行完一步可以把结果反馈给 Planner 决定要不要调整后续计划。这个模式的最大优势是全局视野——模型在动手之前就知道总共要干几件事不容易跑偏。对于分析一份财报并生成报告这种十几步的任务它比 ReAct 稳得多。代价是灵活性下降。如果执行到一半发现计划本身有问题比如某个假设不成立需要额外的 replan 机制来修正否则就会沿着错误的路一路走到黑。我的经验是Planner 用能力强的模型Executor 可以用便宜快的模型这样既保证规划质量又控制成本。另外计划不要生成得太细细到每一步都写死反而失去应变能力一般拆到可独立执行的动作这一层就够了。2.3 LangGraph 的 planning 模式把规划变成状态图LangGraph 这类框架的思路和上面两种不太一样它把 Agent 的执行过程建模成一张状态图State Graph节点是动作边是转移条件Planning 就体现在从当前节点该走哪条边上。这种做法的好处是可控性极强——你可以显式定义如果工具调用失败就回到重试节点如果任务完成就走向结束节点而不是全靠模型自由发挥。用 LangGraph 做 planning核心是设计好 state 的结构和条件边。state 里通常放当前任务、已完成步骤、中间结果、重试次数。条件边则根据 state 的内容决定下一步。我踩过的一个坑是state 设计得太随意导致节点之间传递信息时丢字段。建议一开始就把 state 的 schema 定死用 TypedDict 或 Pydantic 模型约束别用裸 dict 到处传。另一个坑是条件边的判断逻辑写得太复杂最后调试起来比写业务逻辑还累能简单就简单。规划模式适合任务主要优势主要坑点ReAct3-8 步、动作独立实现简单、通用易绕圈、上下文膨胀Plan-and-Execute长链路、多步依赖全局视野、不易跑偏灵活性差、需 replanLangGraph 状态图流程可控、需分支可控性强、可调试state 设计易出错2.4 规划失败的三种典型表现和应对规划这块我见过太多翻车现场总结下来无非三类。第一类是规划过粗模型只给一句先分析再总结等于没规划执行时还是抓瞎。应对办法是在 prompt 里强制要求每步必须是一个可执行的具体动作包含调用的工具和参数。第二类是规划幻觉模型规划出根本不存在的工具或能力比如让它调一个你没提供的接口。应对办法是把可用工具清单明确写进 prompt并在执行前做一次工具名校验。第三类是规划僵化计划定死了不会变遇到意外就卡住。应对办法是引入 replan 触发条件比如连续两次工具调用失败就重新规划。注意规划质量高度依赖模型能力。同一个 prompt能力弱的模型规划出来的步骤可能完全没法执行。如果预算允许Planner 这一环别省模型。3. Memory 架构短期、长期、工作记忆怎么分层Memory 是 Agent 里最像工程问题的一块因为它直接对应到存储、检索、更新这些实打实的技术选型。很多人一上来就想搞向量数据库 RAG其实 Memory 远不止这一种形态。3.1 三层记忆的分工我把 Agent 的 Memory 分成三层。短期记忆Short-term Memory就是当前会话的对话历史通常直接放在上下文里或者用一个滑动窗口截断。工作记忆Working Memory是当前任务执行过程中的中间状态比如已经查到的数据、已经生成的草稿它跟着任务生命周期走任务结束就可以丢。长期记忆Long-term Memory是跨会话、跨任务保留的知识比如用户偏好、历史交互摘要、领域知识库一般落到外部存储里需要时检索回来。这三层的更新频率和存储介质完全不同。短期记忆每轮都变放内存或 Redis 就行工作记忆跟着任务走可以放任务上下文对象里长期记忆更新慢但要求持久通常用向量库或关系库。分清楚这三层很多设计问题就迎刃而解了——比如为什么我的 Agent 记不住用户偏好答案往往是偏好信息没被写进长期记忆而不是模型不行。3.2 长期记忆的写入与检索策略长期记忆最难的不是存是决定什么时候写、写什么、什么时候读。写得太勤记忆库全是噪音写得太少关键信息丢失。我的做法是在任务结束时做一次记忆提炼让模型把这次交互里值得长期保留的信息总结成几条结构化记录再写入。比如销售场景里提炼出客户关注价格、预算在 X 区间、下次跟进时间这样的字段而不是把整段对话原样存进去。检索这块纯向量相似度检索经常召回不相关的内容。更稳的做法是混合检索向量相似度 关键词匹配 时间衰减。时间衰减很重要——三个月前的偏好可能已经过时了给旧记忆打个折。另外检索回来的记忆不要一股脑塞进 prompt要做一次相关性过滤和压缩否则上下文很快就被记忆占满了。3.3 A-MemGuard 思路给记忆加一道主动防线热词里提到的 A-MemGuard 这类面向 LLM Agent 记忆的主动防御框架思路值得借鉴。核心问题是长期记忆一旦被污染比如用户诱导写入错误信息或者检索到过时/矛盾的内容会持续影响后续所有决策。防御的做法包括写入前做一致性校验检测新记忆和已有记忆是否冲突检索时做可信度打分对来源可疑的记忆降权定期做记忆清理和过期淘汰。这套思路落到实操上就是给记忆的写入和读取都加一层守门人。写入时用一个轻量模型判断这条信息是否值得存、是否和已有信息矛盾读取时除了相关性还要看这条记忆的时效性和来源可信度。听起来麻烦但对于长期运行的 Agent这层防护能省掉大量越跑越傻的排查时间。3.4 记忆膨胀与上下文超限的实战处理跑长任务的 Agent 一定会遇到上下文超限报错信息里常见的就是各种 out of memory 或者 token 超限。处理办法有几个层次。第一层是截断保留最近 N 轮对话简单粗暴但会丢信息。第二层是摘要压缩把久远的对话用模型总结成一段话保留要点。第三层是外置把中间结果写到外部存储上下文里只留一个引用 ID需要时再取回来。我一般组合使用近期对话保留原文中期做摘要远期和大量中间数据外置。提示别等到报错才处理上下文。在设计阶段就估算一下单轮对话平均多少 token、任务平均多少轮、工具返回结果多大。算出来超过模型窗口的 70%就该上压缩或外置了。4. 工具调用与执行循环让规划真正落地规划和记忆是想和记工具调用和执行循环是做。这一节讲怎么把前面两层接到真实世界上。4.1 工具描述的质量决定调用成功率工具调用失败十有八九不是模型笨是工具描述写得烂。模型只能通过你给的描述来理解这个工具是干嘛的、参数怎么填。描述里必须包含工具的功能、每个参数的含义和格式、什么情况下该用、什么情况下不该用。我见过有人只写一句查询数据模型根本不知道查什么数据、参数怎么传调用失败是必然的。参数设计也有讲究。能用枚举就别用自由文本能限定格式就限定格式。比如日期参数明确写格式 YYYY-MM-DD比让模型自由发挥强得多。另外工具返回结果也要规范最好返回结构化数据加一句自然语言说明方便模型理解。4.2 执行循环的终止条件与错误处理执行循环最怕两件事停不下来和错得没边。停不下来是指模型一直循环调用工具永远不给最终答案。解决办法是设硬性上限——最大步数、最大工具调用次数、最大耗时任一超限就强制终止并返回当前结果。错得没边是指工具报错后模型不知道怎么处理要么忽略错误继续瞎跑要么直接崩溃。我的做法是给每类错误定义处理策略可重试错误网络超时自动重试 N 次参数错误把错误信息回传给模型让它修正参数不可恢复错误权限不足直接终止并报告。这套策略写进执行循环里比指望模型自己判断靠谱得多。热词里那个agent execution terminated due to error就是典型的没处理好错误导致的。4.3 多工具编排的顺序与依赖复杂任务往往要调多个工具而且有依赖关系——先查数据再算指标最后生成报告。编排的时候要明确哪些能并行、哪些必须串行。并行能省时间但要注意工具之间有没有共享状态。串行则要保证前一步的输出格式正好是后一步的输入格式中间最好加一层格式转换别指望模型每次都自动对齐。错误类型典型场景处理策略可重试错误网络超时、限流自动重试指数退避参数错误格式不对、缺字段回传错误让模型修正不可恢复错误权限不足、资源不存在终止并报告5. 踩坑实录Agent 跑不起来时的排查链路这一节讲几个我真实踩过的坑重点不是给答案而是把排查思路完整呈现出来方便你遇到类似问题时复现。5.1 现象Agent 反复调用同一个工具第一次遇到这个现象时我以为是模型的问题换了个更强的模型还是绕圈。于是开始排查先看日志发现模型每次调用的参数几乎一样说明它没意识到这个工具已经调过了。再回头看 prompt发现我根本没把已执行步骤告诉模型。根因是工作记忆没回传——执行循环里没有把历史动作写回上下文。修复很简单每轮把已执行的动作和结果追加到 prompt 里。这个坑让我明白Agent 的记忆不是自动的得你手动喂。5.2 现象规划出来的步骤无法执行有一次 Planner 规划出调用内部 API 获取用户画像但我根本没提供这个工具。排查发现Planner 的 prompt 里只说了任务目标没说可用工具清单。模型就按常识想象了一个工具。根因是规划阶段和执行阶段的工具信息不一致。修复办法是把工具清单同时喂给 Planner 和 Executor并在规划后加一道校验过滤掉不存在的工具。5.3 现象长任务跑到一半上下文爆炸一个分析任务跑到第七八轮时开始报 token 超限。排查发现每轮工具返回的原始数据都原样留在上下文里累积起来非常快。根因是中间结果没有外置。修复方案是把工具返回的大块数据写到临时存储上下文里只留摘要和引用 ID。改完之后同样的任务能跑到二十轮以上。5.4 现象记忆污染导致越跑越傻一个长期运行的客服 Agent跑了一周后开始给出明显错误的回答。排查记忆库发现里面混进了几条用户故意输入的误导信息被当成事实存了下来。根因是记忆写入没有校验。修复方案是加一层写入前的可信度判断并对已有记忆做定期清理。这就是前面提到的 A-MemGuard 思路的实际价值。注意Agent 的问题往往不在模型而在架构。排查时先看数据流——信息有没有正确传递、状态有没有正确保存比盯着模型调参有效得多。6. 框架选型与落地建议LangGraph、Dify 还是自己写最后聊聊选型。市面上的 Agent 框架很多LangGraph、Dify、还有各种开源的 agent 框架各有适用场景。LangGraph适合需要精细控制流程的场景它的状态图模型对复杂分支和循环支持很好但学习曲线陡state 设计要花心思。Dify这类平台适合快速搭建和可视化编排上手快但深度定制受限复杂逻辑会别扭。自己写适合对性能和可控性要求极高的场景好处是没有框架黑盒坏处是什么轮子都得自己造。我的建议是先用框架快速验证跑通之后再决定要不要下沉到自己实现。很多团队一上来就自己写结果在状态管理、错误处理这些通用问题上耗了大量时间。反过来如果业务逻辑特别复杂、框架的表达能力不够用那就果断自己写别硬套。选型时重点看几个维度状态管理能力、工具调用支持、是否支持人工介入human-in-the-loop、可观测性日志、追踪、以及社区活跃度。可观测性尤其重要——Agent 出问题时没有详细的执行日志排查基本靠猜。关于模型选择Planner 和 Executor 可以分开选。规划用能力强的执行用快而便宜的这是控制成本最有效的手段之一。本地部署的话注意显存和内存的配置训练和推理对硬件的要求差别很大别拿训练卡的思路去配推理环境。Agent 智能体架构这件事说到底是在模型能力之上补一层工程骨架。Planning 让它会拆解Memory 让它记得住工具调用让它够得着执行循环让它跑得完。这四块任何一块偷懒Agent 就会在某个环节掉链子。我自己做下来最深的体会是别指望模型自己搞定一切把架构设计好比反复调 prompt 有用得多。
Agent智能体架构实战：Planning与Memory机制拆解及避坑指南
大模型能写诗、能答题、能陪你聊天但真让它去订一张机票、改一段代码、跑一轮数据分析十有八九会卡在某个环节上——不是忘了上一步干了什么就是拿着工具不知道怎么下手。这个落差就是懂回答和会干活之间的距离。Agent 智能体架构要解决的正是这段距离。我做了几个 Agent 项目之后最大的感受是模型本身的能力只是地基真正决定一个智能体能不能干活的是它外面那套 Planning、Memory、工具调用和执行的骨架。这篇就围绕 Agent 智能体架构把 Planning 和 Memory 这两块最核心的机制拆开讲顺带把工具编排、执行循环、常见坑都过一遍。不管你是刚接触智能体开发还是已经用 LangGraph、Dify 这类框架搭过东西应该都能从里面找到能直接抄的配置和能避开的坑。1. 从懂回答到会干活Agent 到底多了什么先把最基础的问题说清楚一个普通的大模型调用和一个 Agent本质区别在哪。普通调用是输入一段文本输出一段文本模型是无状态的它不知道上一轮发生了什么也没法主动去查资料、跑代码、调接口。你问它今天北京天气怎么样它只能根据训练数据里的旧信息瞎猜或者干脆说我无法获取实时信息。而 Agent 是输入一个目标输出一串动作和最终结果它能在中间自己决定下一步做什么、调用什么工具、要不要回头修正。这个差别落到架构上就是几个关键组件的叠加。我习惯把它拆成四层来看Planning规划负责把大目标拆成可执行的小步骤Memory记忆负责记住做过什么、知道什么Tool Use工具调用负责和外部世界交互Execution Loop执行循环负责把上面这些串起来反复跑直到任务完成或判定失败。这四层里Planning 和 Memory 是最容易被低估、也最容易出问题的两块。很多人搭 Agent 的时候把精力全花在接工具上结果跑起来发现模型规划得乱七八糟或者聊到第五轮就把前面说过的约束忘光了。为什么 Planning 这么关键因为大模型天生是一步到位的思维模式你给它一个复杂任务它倾向于直接给一个看起来完整的答案而不是老老实实分步推理。但真实任务往往需要多步而且后一步依赖前一步的结果。Planning 机制就是强行把这个一步到位掰成一步一步来。常见的做法有几种一种是ReAct 模式让模型在每一步先输出思考Thought再输出动作Action然后观察结果Observation循环推进另一种是Plan-and-Execute 模式先让模型一次性生成完整计划再逐步执行执行中允许调整还有Tree of Thoughts这类更重的搜索式规划适合需要探索多条路径的场景。选哪种取决于你的任务复杂度和对延迟的容忍度。Memory 则是另一个维度的东西。它要解决的是上下文窗口有限和任务需要长期状态之间的矛盾。一个销售智能体要记住客户上次聊到哪、偏好是什么一个代码智能体要记住项目结构、之前改过哪些文件。这些信息不可能全塞进 prompt 里所以需要分层管理短期记忆放当前对话长期记忆放跨会话的知识工作记忆放当前任务中间结果。后面我会专门用一节讲 Memory 的分层设计和 A-MemGuard 这类防护思路。提示如果你现在搭的 Agent 只能完成单轮、无状态的任务那它本质上还是个带工具调用的问答别急着叫它智能体。判断标准很简单——把任务拆成三步以上、中间需要记住状态它还能不能跑通。2. Planning 机制拆解ReAct、Plan-and-Execute 与 LangGraph 的 planning 模式Planning 是 Agent 的大脑前额叶负责决策和拆解。这一节把主流方案讲透重点说清楚每种方案适合什么场景、坑在哪。2.1 ReAct最朴素也最通用的规划循环ReAct 的核心就一句话让模型在每一步显式地想一下再动手。它的循环结构是 Thought → Action → Observation → Thought → ...直到模型认为可以给出最终答案。这个模式的好处是通用、实现简单、对模型能力要求相对低。你甚至不需要框架手写一个 while 循环加正则解析就能跑起来。但 ReAct 的坑也很明显。第一它容易绕圈——模型可能反复调用同一个工具或者在一个死胡同里打转因为它没有全局计划只看眼前一步。第二它对 prompt 的格式稳定性要求高一旦模型输出的 Action 格式解析失败整个循环就断了。第三步数一多上下文迅速膨胀成本和延迟都上去了。我实测下来ReAct 适合步骤数在 3 到 8 步、每步动作相对独立的任务比如查资料→总结→写邮件这种。超过这个复杂度就该考虑 Plan-and-Execute 了。2.2 Plan-and-Execute先谋后动适合长链路任务Plan-and-Execute 把规划拆成两个阶段Planner 先产出一个完整的步骤列表Executor 再逐步执行每执行完一步可以把结果反馈给 Planner 决定要不要调整后续计划。这个模式的最大优势是全局视野——模型在动手之前就知道总共要干几件事不容易跑偏。对于分析一份财报并生成报告这种十几步的任务它比 ReAct 稳得多。代价是灵活性下降。如果执行到一半发现计划本身有问题比如某个假设不成立需要额外的 replan 机制来修正否则就会沿着错误的路一路走到黑。我的经验是Planner 用能力强的模型Executor 可以用便宜快的模型这样既保证规划质量又控制成本。另外计划不要生成得太细细到每一步都写死反而失去应变能力一般拆到可独立执行的动作这一层就够了。2.3 LangGraph 的 planning 模式把规划变成状态图LangGraph 这类框架的思路和上面两种不太一样它把 Agent 的执行过程建模成一张状态图State Graph节点是动作边是转移条件Planning 就体现在从当前节点该走哪条边上。这种做法的好处是可控性极强——你可以显式定义如果工具调用失败就回到重试节点如果任务完成就走向结束节点而不是全靠模型自由发挥。用 LangGraph 做 planning核心是设计好 state 的结构和条件边。state 里通常放当前任务、已完成步骤、中间结果、重试次数。条件边则根据 state 的内容决定下一步。我踩过的一个坑是state 设计得太随意导致节点之间传递信息时丢字段。建议一开始就把 state 的 schema 定死用 TypedDict 或 Pydantic 模型约束别用裸 dict 到处传。另一个坑是条件边的判断逻辑写得太复杂最后调试起来比写业务逻辑还累能简单就简单。规划模式适合任务主要优势主要坑点ReAct3-8 步、动作独立实现简单、通用易绕圈、上下文膨胀Plan-and-Execute长链路、多步依赖全局视野、不易跑偏灵活性差、需 replanLangGraph 状态图流程可控、需分支可控性强、可调试state 设计易出错2.4 规划失败的三种典型表现和应对规划这块我见过太多翻车现场总结下来无非三类。第一类是规划过粗模型只给一句先分析再总结等于没规划执行时还是抓瞎。应对办法是在 prompt 里强制要求每步必须是一个可执行的具体动作包含调用的工具和参数。第二类是规划幻觉模型规划出根本不存在的工具或能力比如让它调一个你没提供的接口。应对办法是把可用工具清单明确写进 prompt并在执行前做一次工具名校验。第三类是规划僵化计划定死了不会变遇到意外就卡住。应对办法是引入 replan 触发条件比如连续两次工具调用失败就重新规划。注意规划质量高度依赖模型能力。同一个 prompt能力弱的模型规划出来的步骤可能完全没法执行。如果预算允许Planner 这一环别省模型。3. Memory 架构短期、长期、工作记忆怎么分层Memory 是 Agent 里最像工程问题的一块因为它直接对应到存储、检索、更新这些实打实的技术选型。很多人一上来就想搞向量数据库 RAG其实 Memory 远不止这一种形态。3.1 三层记忆的分工我把 Agent 的 Memory 分成三层。短期记忆Short-term Memory就是当前会话的对话历史通常直接放在上下文里或者用一个滑动窗口截断。工作记忆Working Memory是当前任务执行过程中的中间状态比如已经查到的数据、已经生成的草稿它跟着任务生命周期走任务结束就可以丢。长期记忆Long-term Memory是跨会话、跨任务保留的知识比如用户偏好、历史交互摘要、领域知识库一般落到外部存储里需要时检索回来。这三层的更新频率和存储介质完全不同。短期记忆每轮都变放内存或 Redis 就行工作记忆跟着任务走可以放任务上下文对象里长期记忆更新慢但要求持久通常用向量库或关系库。分清楚这三层很多设计问题就迎刃而解了——比如为什么我的 Agent 记不住用户偏好答案往往是偏好信息没被写进长期记忆而不是模型不行。3.2 长期记忆的写入与检索策略长期记忆最难的不是存是决定什么时候写、写什么、什么时候读。写得太勤记忆库全是噪音写得太少关键信息丢失。我的做法是在任务结束时做一次记忆提炼让模型把这次交互里值得长期保留的信息总结成几条结构化记录再写入。比如销售场景里提炼出客户关注价格、预算在 X 区间、下次跟进时间这样的字段而不是把整段对话原样存进去。检索这块纯向量相似度检索经常召回不相关的内容。更稳的做法是混合检索向量相似度 关键词匹配 时间衰减。时间衰减很重要——三个月前的偏好可能已经过时了给旧记忆打个折。另外检索回来的记忆不要一股脑塞进 prompt要做一次相关性过滤和压缩否则上下文很快就被记忆占满了。3.3 A-MemGuard 思路给记忆加一道主动防线热词里提到的 A-MemGuard 这类面向 LLM Agent 记忆的主动防御框架思路值得借鉴。核心问题是长期记忆一旦被污染比如用户诱导写入错误信息或者检索到过时/矛盾的内容会持续影响后续所有决策。防御的做法包括写入前做一致性校验检测新记忆和已有记忆是否冲突检索时做可信度打分对来源可疑的记忆降权定期做记忆清理和过期淘汰。这套思路落到实操上就是给记忆的写入和读取都加一层守门人。写入时用一个轻量模型判断这条信息是否值得存、是否和已有信息矛盾读取时除了相关性还要看这条记忆的时效性和来源可信度。听起来麻烦但对于长期运行的 Agent这层防护能省掉大量越跑越傻的排查时间。3.4 记忆膨胀与上下文超限的实战处理跑长任务的 Agent 一定会遇到上下文超限报错信息里常见的就是各种 out of memory 或者 token 超限。处理办法有几个层次。第一层是截断保留最近 N 轮对话简单粗暴但会丢信息。第二层是摘要压缩把久远的对话用模型总结成一段话保留要点。第三层是外置把中间结果写到外部存储上下文里只留一个引用 ID需要时再取回来。我一般组合使用近期对话保留原文中期做摘要远期和大量中间数据外置。提示别等到报错才处理上下文。在设计阶段就估算一下单轮对话平均多少 token、任务平均多少轮、工具返回结果多大。算出来超过模型窗口的 70%就该上压缩或外置了。4. 工具调用与执行循环让规划真正落地规划和记忆是想和记工具调用和执行循环是做。这一节讲怎么把前面两层接到真实世界上。4.1 工具描述的质量决定调用成功率工具调用失败十有八九不是模型笨是工具描述写得烂。模型只能通过你给的描述来理解这个工具是干嘛的、参数怎么填。描述里必须包含工具的功能、每个参数的含义和格式、什么情况下该用、什么情况下不该用。我见过有人只写一句查询数据模型根本不知道查什么数据、参数怎么传调用失败是必然的。参数设计也有讲究。能用枚举就别用自由文本能限定格式就限定格式。比如日期参数明确写格式 YYYY-MM-DD比让模型自由发挥强得多。另外工具返回结果也要规范最好返回结构化数据加一句自然语言说明方便模型理解。4.2 执行循环的终止条件与错误处理执行循环最怕两件事停不下来和错得没边。停不下来是指模型一直循环调用工具永远不给最终答案。解决办法是设硬性上限——最大步数、最大工具调用次数、最大耗时任一超限就强制终止并返回当前结果。错得没边是指工具报错后模型不知道怎么处理要么忽略错误继续瞎跑要么直接崩溃。我的做法是给每类错误定义处理策略可重试错误网络超时自动重试 N 次参数错误把错误信息回传给模型让它修正参数不可恢复错误权限不足直接终止并报告。这套策略写进执行循环里比指望模型自己判断靠谱得多。热词里那个agent execution terminated due to error就是典型的没处理好错误导致的。4.3 多工具编排的顺序与依赖复杂任务往往要调多个工具而且有依赖关系——先查数据再算指标最后生成报告。编排的时候要明确哪些能并行、哪些必须串行。并行能省时间但要注意工具之间有没有共享状态。串行则要保证前一步的输出格式正好是后一步的输入格式中间最好加一层格式转换别指望模型每次都自动对齐。错误类型典型场景处理策略可重试错误网络超时、限流自动重试指数退避参数错误格式不对、缺字段回传错误让模型修正不可恢复错误权限不足、资源不存在终止并报告5. 踩坑实录Agent 跑不起来时的排查链路这一节讲几个我真实踩过的坑重点不是给答案而是把排查思路完整呈现出来方便你遇到类似问题时复现。5.1 现象Agent 反复调用同一个工具第一次遇到这个现象时我以为是模型的问题换了个更强的模型还是绕圈。于是开始排查先看日志发现模型每次调用的参数几乎一样说明它没意识到这个工具已经调过了。再回头看 prompt发现我根本没把已执行步骤告诉模型。根因是工作记忆没回传——执行循环里没有把历史动作写回上下文。修复很简单每轮把已执行的动作和结果追加到 prompt 里。这个坑让我明白Agent 的记忆不是自动的得你手动喂。5.2 现象规划出来的步骤无法执行有一次 Planner 规划出调用内部 API 获取用户画像但我根本没提供这个工具。排查发现Planner 的 prompt 里只说了任务目标没说可用工具清单。模型就按常识想象了一个工具。根因是规划阶段和执行阶段的工具信息不一致。修复办法是把工具清单同时喂给 Planner 和 Executor并在规划后加一道校验过滤掉不存在的工具。5.3 现象长任务跑到一半上下文爆炸一个分析任务跑到第七八轮时开始报 token 超限。排查发现每轮工具返回的原始数据都原样留在上下文里累积起来非常快。根因是中间结果没有外置。修复方案是把工具返回的大块数据写到临时存储上下文里只留摘要和引用 ID。改完之后同样的任务能跑到二十轮以上。5.4 现象记忆污染导致越跑越傻一个长期运行的客服 Agent跑了一周后开始给出明显错误的回答。排查记忆库发现里面混进了几条用户故意输入的误导信息被当成事实存了下来。根因是记忆写入没有校验。修复方案是加一层写入前的可信度判断并对已有记忆做定期清理。这就是前面提到的 A-MemGuard 思路的实际价值。注意Agent 的问题往往不在模型而在架构。排查时先看数据流——信息有没有正确传递、状态有没有正确保存比盯着模型调参有效得多。6. 框架选型与落地建议LangGraph、Dify 还是自己写最后聊聊选型。市面上的 Agent 框架很多LangGraph、Dify、还有各种开源的 agent 框架各有适用场景。LangGraph适合需要精细控制流程的场景它的状态图模型对复杂分支和循环支持很好但学习曲线陡state 设计要花心思。Dify这类平台适合快速搭建和可视化编排上手快但深度定制受限复杂逻辑会别扭。自己写适合对性能和可控性要求极高的场景好处是没有框架黑盒坏处是什么轮子都得自己造。我的建议是先用框架快速验证跑通之后再决定要不要下沉到自己实现。很多团队一上来就自己写结果在状态管理、错误处理这些通用问题上耗了大量时间。反过来如果业务逻辑特别复杂、框架的表达能力不够用那就果断自己写别硬套。选型时重点看几个维度状态管理能力、工具调用支持、是否支持人工介入human-in-the-loop、可观测性日志、追踪、以及社区活跃度。可观测性尤其重要——Agent 出问题时没有详细的执行日志排查基本靠猜。关于模型选择Planner 和 Executor 可以分开选。规划用能力强的执行用快而便宜的这是控制成本最有效的手段之一。本地部署的话注意显存和内存的配置训练和推理对硬件的要求差别很大别拿训练卡的思路去配推理环境。Agent 智能体架构这件事说到底是在模型能力之上补一层工程骨架。Planning 让它会拆解Memory 让它记得住工具调用让它够得着执行循环让它跑得完。这四块任何一块偷懒Agent 就会在某个环节掉链子。我自己做下来最深的体会是别指望模型自己搞定一切把架构设计好比反复调 prompt 有用得多。
