AI Agent四层架构解析：Prompt、Tool、Context与Memory协同设计

1. 从 Prompt 到 Agent一次范式转移的底层逻辑1.1 为什么单靠 Prompt 撑不起一个真正的 Agent2023 年那会儿大家做 AI 应用基本就是一条路写一个精心雕琢的 Prompt把用户输入塞进去调一次模型 API拿到结果返回。这套东西在问答、摘要、翻译这类单轮任务上确实够用但只要任务稍微复杂一点——比如“帮我查一下这周北京的天气如果下雨就订一张周五去上海的高铁票并把行程加到日历里”——单次 Prompt 调用就彻底歇菜了。原因很直接大模型本质上是一个无状态的函数。你给它一段文本它给你一段文本调用结束之后它什么都不记得。它没有手去查天气没有脚去订票也没有脑子去判断“先查天气还是先订票”。Prompt 能做的只是“在给定上下文里生成合理的续写”它无法主动获取新信息也无法根据中间结果调整下一步动作。这就是 AI Agent 要解决的核心问题。Agent 这个词在 2024 到 2025 年被炒得很热但剥开营销外壳它的技术内核其实就四件事Prompt 负责决策Tool 负责执行Context 负责信息供给Memory 负责状态延续。这四者缺一不可组合起来才构成一个能“自己干活”的系统。我见过太多团队一上来就说要做 Agent结果做出来的东西本质上还是一个套了循环的 Prompt 调用跑两轮就崩。问题往往不在模型能力而在于他们没有想清楚这四层各自的职责边界。下面我按演进顺序把这四层一层层拆开讲。1.2 四层架构的职责划分与协作关系先把整体图景说清楚。一个成熟的 Agent 系统运行时大致是这样一条链路用户给一个目标 → Agent 把目标 历史记忆 可用工具列表一起塞进 Prompt → 模型输出一个决策是直接回答还是调用某个工具→ 如果是调用工具执行层去跑这个工具拿到结果 → 结果作为新的 Context 回灌给模型 → 模型基于新信息继续决策 → 循环直到任务完成或达到终止条件。这里面Prompt 是大脑的思考方式Tool 是手脚Context 是眼睛和耳朵Memory 是记忆。四者协作的关键在于“循环”和“状态管理”。单次调用没有循环所以不是 Agent循环了但不管理状态跑几轮上下文就爆炸也不是一个能用的 Agent。我个人的经验是判断一个系统是不是真 Agent就看它有没有这三个特征自主决策自己决定下一步做什么、工具使用能对外部世界产生动作、状态保持跨轮次记住发生了什么。三者缺一就只能叫“增强版 Prompt”。2. Prompt 层Agent 的决策中枢怎么设计2.1 从“写一句话”到“设计一套决策协议”普通 Prompt 工程和 Agent Prompt 工程完全是两个量级的东西。普通场景下你写的是“你是一个翻译助手请把下面的中文翻译成英文”而 Agent 场景下你要写的是一套决策协议告诉模型它有哪些工具可用、每个工具的参数是什么、什么情况下该调用哪个工具、调用失败怎么办、什么时候该停止。这就引出了 Agent Prompt 的几个核心组成角色与目标定义明确 Agent 的身份和它要完成的终极目标。工具清单Tool Schema以结构化格式列出所有可用工具及其参数说明。决策规则什么条件下直接回答什么条件下调用工具调用后如何判断结果是否可用。输出格式约束强制模型以特定格式输出比如 JSON方便程序解析。终止条件明确什么情况下任务算完成避免无限循环。我踩过最大的一个坑就是早期写 Agent Prompt 时没做输出格式约束模型有时候返回自然语言有时候返回 JSON解析层直接崩。后来强制用结构化输出比如让模型输出{action: tool_name, args: {...}}这种格式稳定性立刻上了一个台阶。2.2 工具描述写得好不好直接决定 Agent 聪不聪明这一点我要重点强调因为它是被最多人忽视的环节。很多人以为 Agent 调错工具是模型笨其实十有八九是工具描述写得烂。模型选择工具的唯一依据就是你给它的工具描述。如果你写的是“查询天气”模型不知道这个工具支持哪些城市、返回什么格式、需不需要日期参数。但如果你写的是“根据城市名和日期查询天气输入参数为 city字符串如北京和 date字符串格式 YYYY-MM-DD返回该日期的天气状况和温度”模型的选择准确率会高出一大截。我总结的工具描述三要素要素说明反例正例功能边界这个工具具体做什么、不做什么“处理数据”“读取 CSV 文件并返回前 N 行”参数规格每个参数的类型、格式、是否必填“传入参数”“file_path字符串必填绝对路径”返回说明返回什么结构、异常时返回什么“返回结果”“成功返回 JSON 数组失败返回 error 字段”提示工具数量超过 10 个之后模型的选择准确率会明显下降。这时候要么做工具分组要么引入一个“路由层”先判断该用哪一类工具再在类内做细选。2.3 Prompt 层的常见故障与排查思路实际跑起来Prompt 层最常出的问题有这么几类我整理成速查表现象可能原因排查方向模型不调用工具直接瞎编答案工具描述不够明确或决策规则没写清检查 Prompt 里是否明确“不知道时必须调用工具”反复调用同一个工具没有把工具结果正确回灌或终止条件缺失检查循环逻辑和结果注入位置输出格式解析失败没有强制结构化输出加入格式约束和 few-shot 示例上下文超长报错历史轮次无限累积引入 Context 裁剪或摘要机制调用参数格式错误参数说明不清晰在工具描述里给出参数示例这里特别说一下“上下文超长”这个问题。热词里出现的maximum context length is 1048576 tokens这类报错在 Agent 场景下极其常见因为每一轮循环都会往上下文里追加内容。解决办法后面在 Context 层会详细讲。3. Tool 层让 Agent 真正“下地干活”3.1 工具的本质把自然语言决策翻译成确定性执行模型再聪明它也只是一个文本生成器。它说“我要查天气”这句话本身不会让天气发生变化。真正去查天气的是 Tool 层的一段代码。所以 Tool 层的本质是一座桥把模型输出的自然语言决策翻译成确定性的、可执行的程序调用。这个翻译过程有两个关键点。第一是参数映射模型输出的参数是文本工具需要的是具体类型整数、日期、枚举中间要做校验和转换。第二是结果封装工具执行完的结果可能是 JSON、可能是纯文本、可能是二进制要转成模型能理解的文本格式再回灌。我一般会把工具分成三类来管理信息获取类搜索、查数据库、读文件、调 API 拿数据。特点是只读相对安全。动作执行类发消息、写文件、下单、调外部服务。特点是有副作用必须加权限控制。计算处理类跑代码、做数学运算、格式转换。特点是确定性高适合把模型不擅长的精确计算外包出去。3.2 工具选型与封装的实际考量选什么工具、怎么封装直接决定 Agent 的能力上限。我的经验是遵循“能用代码解决的绝不交给模型”这个原则。比如日期计算、字符串处理、数值运算这些模型经常算错的东西全部封装成工具让模型调用准确率立刻从 70% 拉到接近 100%。封装工具时有几个实操要点单一职责一个工具只做一件事。不要搞一个“万能工具”接收各种参数做不同的事那样模型根本学不会怎么用。幂等设计尤其是动作执行类工具要考虑重复调用的情况。比如“发消息”这个工具如果 Agent 因为重试调了两次用户就收到两条消息体验很差。超时与重试外部 API 调用必须设超时失败要有明确的错误返回让模型知道“这次失败了可以换个方式再试”。错误信息友好化工具报错时返回给模型的不能是堆栈信息而应该是“查询失败原因城市名不存在请检查输入”这种模型能理解并据此调整的文本。注意动作执行类工具一定要加“确认机制”或“权限白名单”。我见过 Agent 因为理解偏差把测试环境的删除操作跑到了生产库上这种事故一旦发生就是灾难性的。3.3 工具调用失败的典型场景与处理工具调用失败是常态不是异常。网络抖动、API 限流、参数错误、权限不足各种情况都会遇到。关键是 Agent 要能优雅地处理失败而不是一失败就整个流程崩掉。我处理失败的标准套路是三层第一层工具内部重试。对于网络类瞬时故障工具内部自动重试 2-3 次对模型透明。第二层错误信息回灌。重试仍失败把清晰的错误信息返回给模型让模型决定是换个工具、换个参数还是直接告诉用户“这个操作暂时做不了”。第三层熔断降级。某个工具连续失败多次暂时把它从可用列表里摘掉避免模型反复撞墙。这套机制跑下来Agent 的鲁棒性会有质的提升。很多看起来“模型不行”的问题其实是失败处理没做好。4. Context 层Agent 的“工作台”怎么管4.1 Context 不是越长越好而是要“刚刚好”Context 是 Agent 运行时最稀缺的资源。模型的上下文窗口再大现在动辄 100 万 token也架不住 Agent 循环几十轮往里塞东西。而且上下文越长模型的注意力越分散关键信息越容易被淹没响应也越慢、越贵。所以 Context 管理的核心目标不是“塞更多”而是“在正确的时刻把正确的信息以正确的形式放到模型面前”。这跟人干活是一个道理你桌上堆满文件反而找不到东西只放当前要处理的那几份效率最高。Context 里通常包含这几类信息系统 Prompt角色、规则、工具清单相对固定。对话历史用户说了什么、Agent 回了什么。工具调用记录调了哪些工具、参数是什么、返回了什么。当前任务状态任务进行到哪一步了、还差什么。4.2 上下文膨胀的三种治理手段当上下文开始膨胀我一般按这个顺序处理第一种滑动窗口裁剪。最简单粗暴只保留最近 N 轮对话。缺点是可能丢掉早期的重要信息。适合任务步骤之间相对独立的场景。第二种摘要压缩。把早期的对话历史用模型压缩成一段摘要保留关键结论丢掉过程细节。这个方式效果好但要多花一次模型调用。我的经验是每积累 5-8 轮就压缩一次压缩后的摘要控制在 200 字以内。第三种结构化状态外置。这是最优雅的方式不把历史全塞进上下文而是维护一个结构化的“任务状态对象”只把当前状态注入 Prompt。比如一个订票 Agent状态对象就是{出发地, 目的地, 日期, 是否已查票, 是否已下单}每轮只把这个对象序列化后放进去上下文永远很短。实际项目里我通常是三种混用状态外置为主摘要压缩为辅滑动窗口兜底。4.3 上下文注入顺序对模型表现的影响这是一个很微妙但很实用的点同样的信息放在上下文的不同位置模型的使用效果不一样。我的实测经验是模型对上下文开头和结尾的信息最敏感中间部分容易被忽略这就是所谓的“lost in the middle”现象。所以注入顺序应该是系统 Prompt 和核心规则放最前面。当前任务状态和最近一轮的工具结果放最后面紧挨着模型要生成的位置。历史摘要和次要信息放中间。另外工具返回的结果如果很长比如一个网页的全文一定要先做截断或摘要再注入否则一次工具调用就能把上下文撑爆。我一般会把单个工具结果限制在 2000 字以内超长的做摘要。5. Memory 层让 Agent 拥有“记忆”5.1 Memory 和 Context 的区别很多人搞混这两个概念经常被混为一谈但它们的职责完全不同。Context 是“当前工作台”Memory 是“长期档案柜”。Context 是临时的任务结束就清空Memory 是持久的跨会话、跨任务保留。Context 容量有限必须精打细算Memory 容量可以很大但需要检索机制来决定“什么时候把哪段记忆调出来放进 Context”。举个例子一个客服 Agent用户这次来问“我上次买的那个东西到哪了”。Context 里只有这次对话但 Memory 里存着这个用户的历史订单和上次的沟通记录。Agent 需要从 Memory 里检索出相关信息注入到当前 Context才能正确回答。5.2 记忆的三种类型与存储策略我把 Agent 的记忆分成三类各自有不同的存储和检索策略记忆类型内容存储方式检索方式工作记忆当前任务的中间状态内存对象直接读取情景记忆历史对话、过往任务记录向量数据库语义相似度检索语义记忆领域知识、事实、规则知识库/向量库关键词语义混合检索工作记忆就是前面说的“结构化状态对象”生命周期最短。情景记忆是“发生过什么”用向量库存按语义相似度召回。语义记忆是“知道什么”通常是预置的领域知识。热词里提到的agent 存储 working memory和tencentdb agent memory说的就是这块。实际选型上小规模用内存 本地向量库就够规模上来了再考虑专门的存储服务。5.3 记忆检索的精度问题与优化Memory 层最容易出问题的地方是检索精度。存进去容易取出来准很难。用户问“上次那个事”你得准确找到“上次”指的是哪次、哪个事。我的优化经验有这么几条写入时做结构化不要存原始对话存的时候就提取出关键信息时间、人物、事件、结论检索时按结构字段过滤再语义匹配精度高很多。混合检索纯向量检索对精确匹配比如订单号、人名不敏感要结合关键词检索。我一般用“向量召回 Top 20 关键词过滤”的组合。加时间衰减越近的记忆权重越高符合人的记忆规律。定期清理过期的、无关的记忆要清理否则检索池被污染精度下降。提示记忆污染是个隐蔽的坑。如果 Agent 把错误的信息写进了长期记忆后续所有基于这段记忆的回答都会错而且很难排查。所以写入记忆前最好加一道校验或者对关键记忆做人工审核。6. 四层协同一个完整 Agent 的运行实录6.1 从用户输入到任务完成的完整链路把四层串起来看一个完整的 Agent 运行过程是这样的以一个“帮我整理本周工作并生成周报”的 Agent 为例接收目标用户输入“帮我整理本周工作并生成周报”。加载记忆从 Memory 检索该用户的历史工作记录和偏好格式。组装 Context系统 Prompt 工具清单 检索到的记忆 用户目标。模型决策模型判断需要先获取本周的工作数据选择调用“查询工作日志”工具。工具执行Tool 层调用日志 API返回本周的原始记录。结果回灌把日志数据注入 Context模型基于数据生成周报草稿。模型决策判断草稿是否完整是否需要调用“格式化”工具。循环直到模型输出最终周报任务终止。写入记忆把本次生成的周报和用户反馈写入 Memory供下次参考。这个链路里每一层都在各司其职。Prompt 决定“做什么”Tool 负责“怎么做”Context 保证“信息够用”Memory 保证“记得住”。6.2 并发场景下 Agent 的状态隔离热词里有个问题问得很好ai agent 怎么扛并发。这是从 Demo 走向生产必须跨过的坎。单用户单任务的 Agent 好做但一旦要同时服务成百上千个用户问题就来了状态怎么隔离资源怎么分配上下文怎么不串我的实践方案是每个会话一个独立的 Agent 实例实例之间完全隔离。具体做法会话级隔离每个用户会话对应一个独立的 Context 和 Memory 命名空间绝不共享。无状态服务 外部状态存储Agent 服务本身做成无状态的所有状态Context、Memory都存在外部存储Redis、向量库里这样服务可以水平扩展。工具调用的并发控制对外部 API 的调用要做限流和排队避免把下游打挂。超时与资源回收每个 Agent 实例设最大运行时长和最大循环次数防止死循环占资源。这套方案跑下来单机撑几百个并发会话问题不大再往上就靠加机器。6.3 一个真实项目的踩坑记录说个我实际做过的项目。当时做一个自动处理工单的 Agent四层都搭好了测试环境跑得很顺一上生产就出问题。第一个坑是上下文爆炸。工单处理过程中要读大量历史记录几轮下来上下文就超了。后来改成“只注入当前工单相关记录 历史摘要”问题解决。第二个坑是工具重试导致重复操作。有个“关闭工单”的工具因为网络超时触发了重试结果工单被关了两次触发了下游告警。后来给所有动作类工具加了幂等键同一个操作只执行一次。第三个坑是记忆污染。Agent 把一次错误的判断写进了长期记忆导致后续同类工单全部处理错误。后来加了记忆写入的校验规则关键记忆必须经过规则引擎确认才能落库。这三个坑每一个都不是模型能力问题全是工程问题。所以我一直说做 Agent模型只是其中一环工程能力才是决定成败的关键。7. 演进方向与个人实践建议7.1 从单 Agent 到多 Agent 协作单 Agent 能处理的任务复杂度是有上限的。当任务需要多种专业能力时多 Agent 协作就成了自然选择。比如一个“市场分析”任务可以拆成“数据采集 Agent”“数据分析 Agent”“报告撰写 Agent”各司其职通过消息传递协作。但多 Agent 不是银弹。Agent 之间的通信开销、任务拆分的合理性、结果汇总的一致性都是新的挑战。我的建议是能用单 Agent 加多工具解决的就不要上多 Agent。多 Agent 适合那种职责边界非常清晰、单 Agent 上下文确实装不下的场景。7.2 给不同阶段实践者的建议如果你是刚入门我的建议是从单工具单任务的 Agent 做起。先跑通“Prompt 决策 一个工具调用 结果回灌”这个最小闭环理解循环和状态管理再逐步加工具、加记忆。如果你已经在做生产级 Agent重点应该放在可观测性和稳定性上。每一次模型决策、每一次工具调用、每一次记忆读写都要有日志。出了问题能快速定位是哪一层的问题这比模型能力重要得多。如果你在考虑架构选型记住一个原则Context 管理决定性能上限Memory 设计决定能力上限Tool 生态决定应用边界。三者要平衡投入不要只盯着模型调优。我个人在实际操作中的体会是Agent 这个领域变化很快但底层的那套逻辑——决策、执行、信息、状态——是稳定的。把这几层的原理吃透不管上层框架怎么换你都能快速上手。最后分享一个小技巧调试 Agent 时把每一轮的完整 Context 和模型输出都打印出来你会发现很多问题一眼就能看出来比盯着最终结果瞎猜高效得多。