把AI Agent拆成“六个模块”来聊是我在做了多个Agent项目之后觉得最合适的一种切入方式。很多人一上来就盯着提示词写得多花哨或者纠结该调哪家大模型结果做出来的东西一跑就崩、一换场景就废。真正的Agent系统核心不在于模型多强而在于外围这六个模块能不能扛得住真实业务里的脏活累活。这篇文章我按自己的实战理解把感知、记忆、规划、工具、执行、反思这六块逐一拆开讲清楚适合正在从Demo走向落地、想把Agent做得更稳的开发者参考。1. 为什么说Agent的核心是模块而不是模型1.1 一个能跑通的需求背后到底站着谁先说我最近做的一个内部项目需求很简单让Agent每周自动整理项目群里的讨论记录提炼出待办事项再按照负责人把任务派发到对应群。听起来不复杂但真做起来发现如果只靠着一次大模型调用这件事根本闭环不了。你得先能从各种聊天记录里定位到关键信息这是感知你得记住上周已经处理过哪些任务这是记忆你得判断讨论内容怎么拆成可执行的任务这是规划你还得调用群机器人的接口把消息发出去这是工具发之前要确认状态流转对不对这是执行下个星期回过头看哪些待办漏了、哪些结论错了这就是反思。你会发现任何一个真实Agent场景都是这六类能力在同时工作。它们不是相互独立的技术切片而是围绕“目标完成度”串起来的一条流水线。这也是为什么我特别建议初学者不要只盯着“提示词工程”或者“某个Agent框架的API”而是先建立模块意识。模块意识一旦建立你遇到任何新需求第一反应会是“哪个模块需要加强”而不是“换个更大的模型试试”。1.2 六大模块的边界到底是什么六个模块我分别定义为感知与输入解析、记忆管理、规划与任务分解、工具调用、执行与状态流转、反思与自校正。它们之间有一个隐形的数据流转顺序感知模块把原始输入统一成结构化语义记忆模块提供相关背景规划模块产出步骤工具模块负责和环境交互执行模块维护整个过程的中间状态反思模块在关键节点做质量校验并形成闭环。这里想多说一句很多人把工具调用理解成Agent的全部这其实是个误区。工具调用只是Agent的“手脚”但真正决定Agent是否聪明的是规划模块能分解任务到什么粒度以及反思模块能不能发现自己在走弯路。手脚再灵活方向错了也白搭。模块边界的价值在于你在做故障排查时可以快速定位问题在两个模块的交界处——比如“记忆取回的内容污染了规划的结果”而不是笼统地觉得“整个Agent坏了”或“模型能力不行”。2. 感知与输入解析Agent理解世界的第一道闸门2.1 多模态输入怎么统一成一种语义Agent的输入远比大家想象得复杂。文本、图片、语音、结构化表格、甚至用户在交互过程中的操作行为都会涌进输入层。我见过不少项目的第一版只处理纯文本等到上线才发现用户会丢截图过来而截图里恰恰藏着最关键的信息。做感知模块的时候第一步不是急着写解析逻辑而是定义清楚“Agent到底需要从输入里提取哪些信号”。我现在的做法是构造一个中间语义层。不管是文本、OCR结果还是语音转写文本最终都统一成一套带时间线、发言人、原始内容、关键实体标注的结构化事件流。事件流的好处是后续无论是做关键词召回还是交给规划模块做上下文聚合都有统一格式可供操作。举个反例如果每种输入类型走一条单独的解析分支那么当你在规划阶段需要融合同一时刻的文本加图片信息时就只能临时拼字符串语义很容易错乱。2.2 上下文框架才是感知的灵魂解析输入的下一层是维护“当前交互的上下文框架”。这个框架不完全等同于模型上下文窗口里的原始内容而是感知模块抽取出来的结构化场景信息。比如“当前用户在面包店场景里追问提拉米苏的成分”感知模块要抽取出来的不是一整段对话原文而是“场景甜品咨询实体提拉米苏意图成分查询约束可能有过敏提示需求”。我在项目里会用一个轻量的分类模型去做意图初筛再用主模型做实体填充。这里有一个实战细节分类模型做初筛不是因为它比大模型更准而是为了省成本——大量简单请求根本不需要走长上下文的大模型分类模型划分好路径后只有复杂case才走完整链路。这也从侧面回答了一个很多人关心的问题Agent不是每一层都要堆最贵的模型分层处理本身就能优化成本。2.3 感知模块最常见的三个坑第一个坑是信息丢失。我早期做一个会议纪要Agent直接把语音转写文本截断到上下文窗口上限结果会议后半段的决议全部丢失。后来改成段落级摘要压缩才保住了关键信息。第二个坑是上下文膨胀。有些开发者图省事把每次输入的全量历史都塞给感知模块结果Agent的响应越来越慢、越来越跑偏。感知模块应该有“摘要优先、全文召回靠检索”的机制。第三个坑是格式污染。结构化输入和自由文本混在一起会让大模型分不清优先级我现在要求所有解析输出必须走统一的JSON结构哪怕某个字段为空也要显式给个空值这样模型才不会被隐形内容误导。3. 记忆管理短期工作台与长期知识库怎么配合3.1 短期记忆不等于大模型的上下文窗口很多初学者把短期记忆等同于“把聊天历史都拼接到Prompt里”这是误解。大模型的上下文窗口只是一块临时工作区它无法区分哪些历史信息对当前任务更重要也无法处理“一段信息使用完就该被丢弃”的场景。真正的短期记忆应该是一个有容量上限、有淘汰策略的工作存储区。我自己设计短期记忆时参考了操作系统的分页管理思路把会话切成若干个有标题的记忆块每块绑定时间戳和相关实体当工作区快满时优先淘汰“和当前用户目标关联度最低”的块而不是机械地删除最老的内容。听起来有点抽象但直白讲就是——如果一个小时前用户曾提到某个特殊偏好而这个偏好现在正相关那即使它更老也应该留下来反而是5分钟前的闲聊内容可以被压成一句话摘要。3.2 长期记忆的本质是分层索引不是原样存储长期记忆如果只靠向量检索库把所有历史对话都塞进去那多半会在召回阶段翻车。因为用户输入的问题表述和原有信息之间往往隔着好几层同义转换纯向量相似度并不总是抓得住。我习惯把长期记忆分成三层事实层、摘要层、行为偏好层。事实层存的是明确的实体关系比如“该用户常用邮箱是什么”摘要层按话题维度压缩定期沉淀行为偏好层则记录用户在交互中表现出的习惯比如“更偏好简洁回复对技术细节要求不高”。取回策略上我并不是每次请求都把三层全量召回而是先由规划模块给出“需要哪些方向的知识”的信号再按信号去各层里检索。这里有一个我自己的经验偏好类记忆权的权重一定要高于事实类因为Agent如果违背了用户明确的偏好哪怕事实回答得再对体验上也是失败的。3.3 记忆污染和选择性遗忘记忆模块有个很容易忽视的副作用脏数据写入。如果一次请求中模型判断错了一个实体的含义这个错误写进长期记忆后后续几周都会被反复取回、反复放大。我现在会在写入长期记忆前加一道校验门槛——不是所有抽取出来的信息都允许落库只有同时满足“高置信度”和“对后续交互有潜在价值”两个条件才写入。遗忘机制也不是锦上添花而是长期记忆里的数据必须设置有效期超过一定时间没有再次被验证过的信息会被降级或清除否则记忆库会逐渐变成错误堆积场。4. 规划模块目标拆解的粒度直接决定Agent的上限4.1 显式规划与隐式规划的取舍规划模块承担的是“把模糊目标变成可执行步骤”的职责。目前的落地实现大致分两类一类是显式规划先让模型输出一份完整的步骤计划再按步骤执行典型形态是Plan-then-Execute另一类是隐式规划Agent一边执行一边根据当前结果决定下一步典型形态是ReAct的思考-行动循环。我在项目里的经验是不要迷信某一种方式而是按任务复杂度来选。简单任务用隐式规划就够了它灵活、token消耗少越是复杂、多依赖、对时序敏感的任务越值得用显式规划先把大框架定下来。显式规划的额外好处是你可以把计划本身展示给用户让用户在看到执行结果前就有机会纠偏。比如让Agent做季度数据分析规划模块先给出“拉取数据、清洗指标、生成图表、撰写结论”四步用户看到计划就能提前说“图表这步不需要”省去了执行一半再中断的尴尬。4.2 规划输出必须约束在“可校验”的边界里规划模块最大的坑是生成一份看起来完整但无法执行的任务清单。我处理的办法是给规划模块单独的提示约束和Schema校验要求每一步任务必须包含操作对象、所需工具、期望产出、判断完成的条件。这一步做完规划结果就可以做程序化校验凡是缺失关键字段的步骤直接返回规划模型重新生成。还遇到过规划步骤数量失控的情况。一个简单的“总结本周进展”需求模型可以拆出12个步骤其中一半是重复动作。后来我加了预算意识给规划模块一个隐性约束每一步都必须是前一步无法直接跳过的必要操作。同时限制未经过用户确认的自动步骤上限超过上限就强制进入“请求用户决策”的状态。规划不是步骤越多越好而是步骤之间要有因果必要性。4.3 规划的容错和重规划策略真实环境里计划赶不上变化是常态。某个外部工具临时挂了、某个API返回了意料之外的空值都会导致原计划无法推进。所以规划模块必须自带重规划能力。我现在设计时会为每一步设定最大重试次数并预先给出备选路径定义。如果主路径连续失败重规划不是从零开始而是保留已经成功的前置结果只对失败节点做局部替换。这一点极其重要很多Agent系统一遇到局部失败就整体重来既浪费token又极容易永久卡死在同一块石头上。5. 工具调用Agent与真实世界握手时最容易出戏的地方5.1 Function Calling的协议设计比数量更重要工具调用模块的核心不是接了多少个API而是协议设计是否清晰。我见过一个Agent接了四十多个工具但模型选工具的正确率只有五成因为工具描述写得太含糊大量功能重叠。真正好用的工具协议应该满足三个要求工具边界明确、参数Schema精确、失败返回值可控。我在项目里定义工具协议时会刻意做“单向意图”划分。比如“查天气”和“查空气质量”如果拆成两个工具模型很容易搞混合并成一个“查询天气与环境数据”工具再用参数里的type字段做细分效果反而更好。另外参数Schema要写严格用枚举值的地方一定要给枚举模型在参数上的幻觉大部分是枚举约束不严导致的。5.2 工具描述怎么写模型才听得懂写工具描述有技巧核心原则是“描述返回结果能支撑什么下一步动作”而不是只描述工具本身的功能。举个例子与其写“该接口返回用户订单列表”不如写“通过该接口获取用户完整订单记录可用于查询最近的订单状态、统计年度消费金额、校验商品是否支持退货”。当模型知道这个工具的数据用于什么决策时它选择工具的准确率会明显提高。我有时会故意在工具描述里附上失败场景的返回样例。比如“当订单号不存在时返回error_code404此时应提示用户核对订单号而不是重试”。这样做等于提前给模型打了失败处理的预防针省去了后续大量的异常处理提示。5.3 工具异常不能被吞进黑洞工具调用的错误处理我一直在强调“可见性”。每次工具调用返回后不管成功失败都要把状态摘要写进上下文让规划模块知道刚才发生了什么。很多Agent应用跑着跑着就“失忆”了就是因为工具返回里的错误信息没有被透传规划模块不知道结果堪忧还在按成功状态往下推。更具体一点我会把工具结果做结构化封装成功标志、业务数据、错误码、消耗时长四项齐全再交给后续模块处理。这套封装让整个链路具备可观测性调试时能一眼定位到哪个环节出了问题。6. 执行与状态流转让多步任务在混乱世界里安全抵达终点6.1 状态机的核心是“每一步都知道自己在哪”执行模块本质上是Agent系统的“进程管理器”。它负责维护任务从启动到完成全过程的状态变化包括当前步骤、已完成步骤、待确认事项、失败计数、外部依赖条件等。没有清晰状态管理的Agent就像没有存档的游戏一旦会话中断就只能从头再来。我在项目里使用有限状态机来管理Agent的生命周期状态包括等待输入、规划中、工具调用中、等待用户确认、执行完成、异常终止等。状态机的好处是让每一步转移都有明确触发条件用户确认、工具返回成功、重试耗尽这些事件都可以驱动状态变化。你不需要把状态逻辑写进提示词里状态机天然让行为变得可预期。6.2 超时、并发与中断恢复怎么处理真实场景下工具调用不可能永远如你所愿地三秒返回。超时如果处理不好Agent会傻傻地一直等或者直接把超时当成失败重试雪上加霜。我在执行模块里做了一套分级超时策略识别工具的预期耗时范围预期3秒的工具10秒不返回就抛弃预期30秒的长任务则先返回“处理中”的中间状态让Agent可以先去干别的等外部回调再恢复。并发控制也是执行模块的职责。规划模块可能会同时产出多个独立步骤这时候不是一股脑全部并行执行而是要考虑到外部API的限流。我在并发层加了令牌桶每个工具组有自己的并发上限超过上限的任务自动排队。中断恢复方面我会给每个Agent会话维护一个持久化的状态快照用户哪怕第二天回来系统也能从当前状态节点继续而不是把整段历史重新推理一遍。6.3 人类介入不是失败而是系统成熟的表现很多人总觉得“Agent问了人”就算不够智能这个观念该改改了。让Agent在关键节点主动向用户确认恰恰是降低风险、提升接受度的重要手段。我在执行模块里设计了确认点位——涉及会产生外部影响的步骤比如发送消息、扣费、删除数据在动手前必须强制请求用户确认。这种设计表面上多了一步交互实际上大幅减少了错误执行带来的返工和信任损耗长期来看是真正的效率提升。7. 反思与自校正模型跑错了怎么自己发现7.1 自我反思不是让模型“再想想”反思模块是最容易被误解的一个模块。有人把反思做成失败后的“重新生成一遍答案”比如给模型加一句“请再检查一下”这基本没用因为模型大概率会在同样的地方摔倒。真正有效的反思必须注入“外部反馈信号”——也就是说反思不能只靠模型内部再思考而是要靠额外的结构化校验来发现错误。我在Agent链路里嵌了几种外部校验器格式规范校验器检查输出是否符合预定Schema业务规则校验器检查结果是否违背硬性约束比如金额字段不能为负一致性校验器比较前后步骤的实体引用是否相互矛盾。只有当这些外部校验器给出了明确错误信号反思模块才启动让模型基于这个具体错误进行修正。用这种方式反思行为是被证据驱动的而不是被“拍脑袋”驱动的。7.2 用回归评测集守住模块迭代的底线反思模块再强也没法保证每个case都自愈。所以我在项目里同时维护了一套回归评测集。每次调整任何一个模块的提示词或逻辑参数都会先跑一遍评测集观测总体成功率的变化。曾经有一版规划模块的prompt明显提升了复杂任务的拆解质量但与此同时简单任务的步骤数也变多了。如果不是评测集指出“简单任务成功率微降”我可能就带着这个缺陷上线了。模块化系统的每一次变更都必须放在一个全局评测棋盘上看不能只看局部亮眼。7.3 什么情况下不要过度反思反思不是无限循环。有些Agent系统在失败后反复重试每次尝试都消耗token和时间用户早就不耐烦了。我设定的默认规则一次任务最多允许两轮反思修正两轮之后如果仍然失败就进入人工介入流程把当前状态、已尝试方案、可疑原因打包交给用户。这样做既给了Agent自愈的机会又不至于让系统钻牛角尖。尤其是涉及实时交互的场景响应时间本身也是一种用户体验指标过度反思换来的“完美但迟到”的答案价值会大打折扣。8. 模块整合的实战心法编排顺序、可观测性与成本8.1 模块之间不是插拔芯片那么简单六个模块设计完之后最考验工程能力的其实是把它们编排成一条可运行的流水线。模块之间会有隐性的数据依赖。举一个简单例子记忆模块取回的内容可能影响规划模块是否感知到“用户正在重复提问”而执行模块保存的中间状态又反过来影响记忆模块写入什么样的摘要。所以编排的第一步不是画架构图而是梳理清楚每个模块产生的数据会流向哪里、被谁消费、需要什么格式。我一般先在逻辑上定义出一份“数据契约”也就是模块间传递消息的统一规范。感知模块的输出消息里有scene和entites字段规划模块就承诺只消费这两个字段不自己再翻原始输入。这个契约机制让我后续想替换或升级内部模块时把影响面控制在一个比较小的范围。虽然看起来只是规范上的约束但对一个会持续演进的Agent系统来说价值不亚于任何一个核心模块本身。8.2 可观测性Agent系统最贵的隐性需求和传统后端系统不同Agent系统的中间过程不是稳定可预期的同样的输入可能因为模型微小的概率波动跑出完全不同的路径。这种不确定性让我在项目中把可观测性放到了和功能一样的优先级。我会给每一次Agent运行生成全程日志记录每个决策节点用到的输入片段、模型输出、置信度和耗时。在客户反馈“这个Agent这一次回答怪怪的”的时候如果没有这些分步日志排查会像大海捞针。实践中我把日志压缩成三层性能层记录各模块延迟和Token开销决策层记录规划路径和工具选择结果校验层记录外部校验器是否通过、反思是否触发。三层日志组合起来基本可以还原一次Agent决策的全部链条。这套机制在项目出Bug的时候帮我节省了大量时间我不需要去猜测哪里出了问题直接看日志链路就能指到具体环节。8.3 成本意识模块化的另一层收益是能省钱聊到成本很多人会默认“Agent越强大越贵”但我恰恰觉得模块化架构是控制成本最有效的武器。感知模块里的轻量分类模型可以挡掉一大半简单请求记忆模块的摘要机制避免了每次请求都拉全量历史规划模块的任务重写和复用能让后续步骤的Prompt更短。这些都让Token消耗更理智也让整体系统能在可控成本的前提下支撑复杂业务。我在刚搭建这套架构时也走过“什么任务都走大模型全家桶”的弯路结果一个月的API账单高到吓人。后来我明确了一条原则大模型只做“需要理解和生成”的部分其他能靠规则和逻辑代码完成的部分绝不上模型。比如状态流转、超时重试、字段校验这些纯确定性逻辑我全部用代码实现只有真正需要语义理解的地方才调用模型。优化之后单次任务的平均成本降到了原先的五分之一左右同时延迟也降了不少。这套优化思路恰恰是因为模块化让我能清楚地看到钱花在了哪个环节才能精准开刀。