从Prompt到Agent：Tool、Context、Memory四层演进与工程实践

1. 从Prompt到Agent一条演进主线的前世今生1.1 为什么单靠Prompt已经不够用了2023年上半年绝大多数人接触大模型的姿势都是同一个打开对话框敲一段精心设计的提示词等它吐出一段回答。那时候大家比拼的是谁的Prompt写得更“玄学”——加角色设定、加思维链、加few-shot示例恨不得把一段话雕出花来。但很快做过真实项目的人都会撞到同一堵墙Prompt再漂亮它本质上只是一次性的输入模型没有记忆、没有工具、没有状态更没有自主决策的能力。我举个特别接地气的例子。你让模型“帮我查一下明天北京的天气然后根据温度推荐穿什么”纯Prompt方案下模型只能靠训练数据里那点陈旧信息瞎编因为它根本连不上实时天气接口。你让它“帮我把这份Excel里的销售数据按区域汇总再生成一份周报”它也只能给你一段代码建议真正跑起来还得你自己动手。这就是Prompt的天花板它是一个“说”的能力不是一个“做”的能力。于是行业里开始出现一个共识性的演进方向——让模型从“只会说”变成“能规划、能调用工具、能记住上下文、能多步执行”的东西。这个方向就是AI Agent。热搜词里反复出现的Prompt、Tool、Context、Memory其实正好对应了这条演进路线上的四个关键台阶。我下面会沿着这条线把每一步为什么这么走、踩过什么坑、实际怎么落地掰开揉碎讲清楚。1.2 四个关键词对应的四个能力台阶先给一张全局对照表方便你建立整体认知后面每一节我都会展开。演进阶段核心能力关键词典型形态解决的核心问题阶段一指令理解Prompt单轮对话让模型听懂人话阶段二外部调用Tool函数调用让模型能“动手”阶段三状态管理Context上下文工程让模型看得全、看得准阶段四长期记忆Memory记忆系统让模型记得住、会遗忘这四个台阶不是替代关系而是层层叠加。一个成熟的Agent是Prompt打底、Tool扩展手脚、Context撑开视野、Memory延续生命。很多人做Agent失败往往不是模型不行而是把这四层混在一起该用Memory的地方硬塞进Prompt该用Tool的地方让模型自己编最后系统又慢又贵还不准。提示判断一个项目到底需不需要Agent最简单的标准是——任务是否需要多步、是否需要外部信息、是否需要跨轮次状态。三个都不需要老老实实用Prompt就够了别为了Agent而Agent。2. Prompt层一切的地基也是最容易被低估的一层2.1 Prompt在Agent体系里的角色变了很多人以为进入Agent时代Prompt就不重要了。恰恰相反在Agent里Prompt的复杂度是成倍上升的。单轮对话时你只需要考虑“怎么问”而在Agent里你要考虑的是“系统提示词怎么定义角色和边界”“工具描述怎么写才能让模型正确选择”“多步执行时每一步的中间结果怎么回填”。热搜里那个“invalid prompt: your prompt was flagged as potentially violating our usage p”和“prompt闪退”本质上都是Prompt工程在真实系统里暴露出来的工程问题而不是写作文的问题。我自己的经验是Agent里的Prompt要分成三类来管理系统级Prompt定义Agent是谁、能做什么、不能做什么、工具级Prompt每个工具的描述、参数说明、使用时机、任务级Prompt当前这一轮用户到底要什么。这三类混在一段文本里模型很容易顾此失彼。分开管理之后调试效率会高很多。2.2 系统提示词的写法与常见坑系统提示词是Agent的“人格底座”。我一般会按这个结构来写# 角色 你是一个负责XX领域的执行型助手。 # 能力边界 你可以调用以下工具A、B、C。 你不能执行D、E。 # 行为准则 1. 每次只做一步做完确认再继续。 2. 信息不足时先提问不要臆测。 3. 工具调用失败时最多重试2次然后如实报告。 # 输出格式 最终结果用JSON返回字段包括status、result、next_action。这个结构看起来朴素但每一条都是踩坑换来的。比如“每次只做一步”这条是因为早期我让模型一口气规划五步结果第三步就基于错误假设往下跑最后全盘皆输。再比如“最多重试2次”是因为不加限制时模型会陷入无限重试循环token哗哗烧热搜里那个“api error: 400 this models maximum context length is 1048576 tokens”很多时候就是这么堆出来的。注意系统提示词里千万不要写“尽可能”“尽量”这类模糊词。模型对模糊指令的处理方式是“自由发挥”而Agent最怕的就是自由发挥。2.3 Prompt Token的成本账要提前算做Agent绕不开成本。Prompt token是每一轮都要重新计费的而Agent的多步特性意味着同一个系统提示词会被反复送入。我做过一个粗略测算一个系统提示词如果占1500 token一个任务平均走6步单次任务光系统提示词就是9000 token。如果每天跑1万次任务这个数字会非常可观。所以我的做法是系统提示词能精简就精简把不常变的部分做成缓存。现在主流模型服务都支持提示词缓存把固定的系统提示词和工具描述缓存起来命中缓存的部分成本能降一大截。这个优化在单轮对话里感知不明显但在Agent场景下是实打实的省钱手段。3. Tool层让Agent真正“下地干活”的关键3.1 从“模型编答案”到“模型调工具”Tool这一层是Agent和聊天机器人最本质的分水岭。热搜里“让AI真的下地干活”这个说法特别形象——Tool就是AI的手和脚。没有Tool模型只能基于训练数据回答有了Tool它可以查数据库、调API、读写文件、执行代码。Tool的底层机制是函数调用Function Calling。你给模型一份工具清单每个工具包含名称、描述、参数schema模型在需要时输出一个结构化的调用请求你的程序执行后再把结果回填给模型。听起来简单但实际落地时工具描述的质量直接决定了Agent的智商上限。我见过太多项目工具本身写得没问题但描述写得一塌糊涂导致模型要么不调用要么调错参数。比如一个“查询订单”的工具描述只写“查询订单信息”模型根本不知道要传订单号还是用户ID。正确的写法应该是{ name: query_order, description: 根据订单号查询订单详情。当用户提供了订单号或需要确认订单状态时使用。不要用于查询用户信息。, parameters: { order_id: { type: string, description: 订单号格式为纯数字长度12位 } } }注意描述里那句“不要用于查询用户信息”这是负向约束。模型在工具选择上经常犯的错就是“用错工具”加上明确的排除说明能显著降低误调用率。3.2 工具设计的粒度问题工具粒度是个特别考验经验的地方。粒度太粗一个工具干太多事模型难以正确填参粒度太细工具数量爆炸模型选择困难而且每多一个工具描述就多一份token开销。我的经验法则是一个工具对应一个明确的动作参数不超过5个返回值结构稳定。如果一个工具的参数超过5个通常说明它该拆了。如果两个工具经常被一起调用可以考虑合并成一个复合工具减少往返次数。举个实际例子。早期我做一个文档处理Agent设计了“读取文档”“提取段落”“总结段落”“生成报告”四个工具结果模型经常在“提取段落”和“总结段落”之间反复横跳。后来我把“提取总结”合并成一个“分析段落”工具调用次数直接降了三分之一任务成功率反而上升了。这就是粒度调整带来的收益。3.3 工具调用的错误处理工具调用一定会失败——网络超时、参数错误、权限不足、返回格式异常什么情况都有。热搜里“error response from daemon”这类报错在Agent里是家常便饭。关键不是避免失败而是让Agent能优雅地处理失败。我的处理策略分三层可重试错误超时、限流自动重试最多2次指数退避。参数错误把错误信息回填给模型让它修正参数后重试。不可恢复错误权限、资源不存在直接终止当前步骤向用户如实报告。这里有个细节特别重要回填给模型的错误信息要结构化、要简洁。不要把一整段堆栈丢给模型那只会浪费token还干扰判断。我一般只回填错误类型和一句话说明比如{error: invalid_param, message: order_id must be 12 digits}。4. Context层Agent的“视野管理”4.1 Context不只是上下文窗口很多人把Context简单理解为“上下文窗口大小”觉得窗口越大越好。这是个误区。Context的本质是在有限的窗口里放进去对当前决策最有用的信息。窗口再大塞满无关内容模型照样抓不住重点而且成本和延迟都会飙升。Agent的Context管理比单轮对话复杂得多因为它涉及多步执行。每一步都会产生新的中间结果这些结果要不要保留、保留多少、怎么压缩都是要设计的。热搜里“agent 存储 working memory”说的就是这个事——工作记忆的管理。4.2 上下文的三段式组织我一般把Agent的Context分成三段来组织固定段系统提示词、工具描述。这部分基本不变适合做缓存。滚动段最近N轮的对话和工具调用结果。这部分随任务推进滚动更新。摘要段对更早历史的压缩摘要。当滚动段超出预算时把旧内容压缩成摘要塞进这里。这个结构的好处是固定段可以缓存省钱滚动段保证近期信息完整摘要段防止历史丢失。三段各有预算加起来不超过模型窗口的70%留30%给模型输出和突发内容。4.3 上下文压缩的实操技巧压缩不是简单截断截断会丢关键信息。我的做法是按信息密度压缩工具返回的大段JSON只保留关键字段对话历史只保留决策相关的部分重复内容直接去重。举个具体操作。一个工具返回了50条记录每条20个字段直接塞进Context就是几万token。但实际上模型只需要知道“有50条记录其中前3条的摘要如下”。所以我会在工具层就做一次预处理只把摘要回填给模型完整数据存在外部需要时再通过工具按需取。提示Context管理的核心原则是“按需加载”。不要一次性把所有信息都塞给模型而是让模型在需要时主动去取。这既省token又提高准确率。5. Memory层让Agent拥有“长期生命”5.1 Memory和Context的区别这是最容易被混淆的一对概念。简单说Context是当前这一轮任务的工作台Memory是跨任务的档案柜。Context在任务结束后就清空了Memory要持久化保存下次任务还能用。热搜里“tencentdb agent memory”“agentpoison: red-teaming llm agents via poisoning memory”这些词说明Memory已经从一个功能点变成了一个独立的研究方向甚至出现了针对Memory的攻击手段。这恰恰说明Memory在Agent体系里的分量。5.2 Memory的三种类型我在项目里一般把Memory分成三类类型内容存储方式生命周期事实记忆用户偏好、固定信息键值存储长期情景记忆历史任务、交互记录向量库中期语义记忆领域知识、规则向量库结构化长期事实记忆最好理解比如“这个用户偏好简洁回复”“这个用户所在时区是东八区”。情景记忆是“上次这个用户问过类似问题当时的解决方案是X”。语义记忆是Agent自己积累的领域知识。5.3 Memory的写入与检索策略Memory最难的不是存而是什么时候写、什么时候读、什么时候忘。写入策略上我一般只在两种情况下写Memory一是用户明确表达的偏好二是任务结束后提炼出的可复用结论。不要每轮对话都写那样Memory会被噪音淹没。检索策略上用向量相似度召回是主流做法但纯向量召回经常召回不相关内容。我的改进是向量召回规则过滤先用向量召回Top20再用规则时间范围、类型、置信度过滤到Top5最后塞进Context。遗忘策略上一定要有。Memory无限增长会导致检索质量下降、成本上升。我一般给每条Memory加一个“最后访问时间”和“访问次数”长期不访问且低置信度的自动归档或删除。注意Memory里绝对不要存敏感信息。用户隐私、密钥、内部数据都不应该进Memory。这不是技术问题是底线问题。6. 从单Agent到多Agent演进的下一个路口6.1 什么时候该拆多Agent单Agent能搞定的事不要拆多Agent。多Agent带来的通信开销、状态同步、错误传播往往比它解决的问题还多。我判断的标准是当任务可以清晰划分成几个职责不同、工具集不同、甚至模型不同的子角色时才考虑拆。比如一个“内容运营Agent”如果它既要写文案、又要做数据分析、又要发消息那拆成“文案Agent”“分析Agent”“执行Agent”是合理的因为它们的工具集和提示词差异很大。但如果只是任务步骤多那还是单Agent加多步规划更简单。6.2 多Agent的通信与协调多Agent的核心难点是通信。我见过的最稳的方案是共享状态消息队列所有Agent读写同一个状态存储通过消息队列传递任务。这样每个Agent都是无状态的方便扩展和调试。热搜里“ai agent 怎么扛并发”这个问题在多Agent场景下尤其突出。我的经验是把Agent做成无状态服务状态全部外置到Redis或数据库这样并发扩展就是加实例的事。有状态的Agent在并发下会非常难搞。6.3 多Agent的常见失败模式多Agent最容易出的问题是责任扩散一个任务谁都觉得该别人做最后没人做。解决办法是给每个Agent明确的触发条件和完成标准并且有一个“协调者”角色负责兜底。另一个问题是无限循环Agent A把任务转给BB又转回A。这个必须靠跳转次数上限来硬性阻断超过就上报人工。7. 常见问题与排查技巧实录7.1 高频问题速查表问题现象可能原因排查方向解决手段模型不调用工具工具描述不清检查description补充使用时机和负向约束工具调用参数错schema不明确检查参数说明加格式示例和取值范围上下文超限中间结果堆积统计每步token加压缩和按需加载任务跑偏系统提示词模糊检查行为准则加明确的步骤约束响应越来越慢Memory检索低效看检索耗时加规则过滤和缓存成本失控重复送系统提示词看缓存命中率开启提示词缓存7.2 几个我踩过的坑第一个坑是过度依赖模型自主规划。早期我让模型自己决定走几步结果它经常规划出十几步的复杂流程中间任何一步出错就全崩。后来我改成“模型只决定下一步”由外层程序控制整体流程稳定性大幅提升。第二个坑是工具返回值太大。有个工具返回了完整的数据库查询结果几万token直接塞爆Context。后来我在工具层加了分页和字段过滤只返回必要信息。第三个坑是Memory污染。早期我把所有对话都写进Memory结果检索出来的全是无关内容。后来改成只写高置信度的结论检索质量立刻上来了。7.3 调试Agent的实用方法调试Agent和调试普通程序不一样因为它的行为有随机性。我的方法是全链路日志可回放每一步的输入、输出、工具调用、耗时全部记录出问题时可以完整回放整个任务流程。这个投入在项目初期看起来麻烦但后期排查问题时能省下大量时间。另外我会准备一批固定测试用例每次改动提示词或工具后都跑一遍看成功率有没有下降。Agent的改动很容易“按下葫芦浮起瓢”没有回归测试根本不敢上线。8. 关于演进路线的一点个人判断从Prompt到Tool到Context到Memory这条演进线背后其实是一个朴素的逻辑让模型的能力边界从“语言”扩展到“行动”从“单次”扩展到“持续”。每一步都是在补上一层的短板。我在实际项目里的体会是不要追求一步到位上全套。很多场景用PromptTool就能解决80%的问题硬上Memory和多Agent反而增加复杂度。演进应该是被需求推着走的而不是被概念推着走的。先把Prompt写扎实再把Tool设计好Context管理跟上最后才考虑Memory和Multi-Agent。这个顺序反了项目大概率会变成一堆跑不起来的组件堆砌。最后分享一个我常用的判断方法当你发现Agent的失败原因里“不知道”占比超过“做不到”时说明该补Memory了当“做不到”占比超过“不知道”时说明该补Tool了。按这个信号来演进基本不会走偏。