这篇文章深入浅出地介绍了 Agent 的工作原理将 Agent 比作项目经理将大模型比作大脑将工具比作双手通过宏观架构图和逐层拆解详细解释了 Agent 如何通过循环、状态和工具来实现复杂任务。文章还详细介绍了记忆系统、工具描述、调用链路等关键机制并提供了实用的使用建议和故障排除方法帮助读者更好地理解和应用 Agent 技术。你对 Agent 说“帮我分析上月销售数据生成一份报告。”然后它沉默了两秒开始自己干活查数据库、算同比、发现西南区掉了 38%、下钻找原因、最后把报告写出来。全程没有人再插一句话。这两秒和之后的每一步就是这篇要拆的东西。先给结论Agent 并不“聪明”它只是把一个大模型塞进了一个循环里循环外挂了状态和工具。你听过的所有名词——记忆、工具、技能、插件、OpenAPI、MCP、Function Calling——都不是并列的新物种而是这条循环上的一个个零件。这篇先给你一张宏观架构图立住全局再逐层拆到代码和数据格式最后用同一条主线把所有零件串起来跑一遍。读完你会获得一种能力任何 Agent 产品摆在面前你都能说出它内部正在发生什么。一、宏观架构一个循环、三个角色、三个规范先立一张“谁是谁”的地基图不然后面一定会读成“一会儿说 Agent 一会儿说模型”。三个角色是包含与调用的关系不是并列的三样东西Agent 是外壳宿主程序。它是一个程序不是模型。负责跑循环、管状态、调模型、执行工具。想成项目经理自己不写代码但排活、盯进度、对接外部资源。模型是内嵌在 Agent 里的大脑。Agent 每转一圈循环就把“任务 工具说明书 记忆”发给模型模型回一段推理和决策。关键点模型不联网、不碰数据库、不执行任何动作——它只输出文本。工具是 Agent 外部的双手。真正连数据库、发 HTTP 请求的是工具而真正发起调用的是 Agent不是模型。模型只是“说”了要调什么Agent 拿着这句话去执行。一句话记住分工模型负责“想”Agent 负责“管和调”工具负责“做”。三个规范各管一段连接不是三选一OpenAPI 管“工具怎么被描述”——把接口写成机器可读的说明书叫什么、收什么参数、什么类型MCPModel Context Protocol 管“Agent 和工具服务怎么连上”——发现工具、传参数、回结果的通道可以想成“工具界的 USB-C”不管什么设备插上就能用Function CallingFC 管“模型怎么表态”——模型把“我想调某工具、参数是某值”说成结构化文本的内置能力。它们在三个不同位置上干活所以根本不存在“选哪个”。记住这张图后面每一层都是往这张图上挂细节。不过三个角色、三个规范此刻还只是一张“零件清单”——真正让零件转起来的是一条循环下一节把零件装到循环上。二、循环与状态Agent 的骨架先立一个地基事实后面的所有机制都基于这个事实大模型是无状态的。一次调用结束模型内部不留任何痕迹。它不保留上一轮的对话、不保留你的偏好、甚至不保留它自己刚说过的话。下一次调用开始时它对世界的全部认知就等于你这次塞进上下文窗口的那一段文本。窗口之外一无所有。所以在 Agent 的完整行动闭环里首尾各站着一个记忆动作回合开始前有一个加载动作从外部存储里捞出与该用户、该任务相关的记忆拼进这次调用的输入回合结束后有一个写回动作把本次值得留的结论提炼成结构化条目存进外部存储。记忆不在模型里在模型外面的数据库或文件里模型只是每次被“喂”到一部分。理解这一点“为什么换个会话就忘”就不再神秘——换个会话时加载流水线没把那条记忆捞出来仅此而已。一个 Agent 的完整行动闭环由六个站点组成加载记忆Agent 从长期存储里捞出与本次任务相关的历史比如“月报口径 同比”任务拆解Agent 把目标交给模型模型把大目标拆成可执行的子任务队列Agent 记进状态对象执行与工具调用模型挑一个子任务、选一个工具、生成参数来表态tool_callsAgent 按规范真正发起调用观察结果Agent 把工具返回原样写回观察区模型读它并判断是不是自己想要的结果达成判定模型对照目标检查并表态Agent 据此决定——完成了就退出循环没完成回到第 3 步沉淀记忆Agent 把本次关键结论提炼后写回长期存储下次不用重算。其中第 3、4、5 步构成一个可以转很多圈的回路叫ReAct 循环Reasoning Acting推理一步、行动一步、观察一步再推理。工作流没有这个回路——路径是人画死的Agent 的价值和风险也都来自这个回路。状态对象六站点共写一张工单六个站点看起来各干各的其实都在读写同一个状态对象state。你可以把它想成一张随任务流转的工单循环每转一圈工单上的字段就被更新一次。为什么必须有它因为模型是无状态的——每次调用结束就清空循环要想“越转越知道得多”就必须有一块模型之外的公共记事本state { goal: ”分析 2026-09 销售数据并生成报告”, # 用户目标全程不变 memory: [ # 站点1 从长期记忆捞来的 {”id”: ”m_a”, ”text”: ”用户是华东区销售运营”}, {”id”: ”m_b”, ”text”: ”月报口径 同比”}, ], plan: [], # 站点2 拆出的子任务队列 observations: [], # 站点4 写入的工具返回 done: False, # 站点5 的判定结果 steps: 0, # 限流阀转了几圈 }有了状态对象整个 Agent 就可以写成一段诚实的循环while not state[done] and state[steps] MAX_STEPS: # 限流阀 reply call_llm(messagesbuild(state), toolsTOOL_SCHEMAS) if reply.tool_calls: # 模型表态要调工具站点3 for tc in reply.tool_calls: result execute(tc.name, json.loads(tc.arguments)) # Agent 动手 state[”observations”].append(result) # 站点4 else: state[”done”] judge(reply, state) # 站点5对照 goal 判定 state[”steps”] 1 save_memory(distill(state)) # 站点6沉淀记忆这段伪代码就是全文的地图build(state) 里藏着记忆注入和工具说明书第四、五节reply.tool_calls 是 Function Calling第三节execute 是工具执行第四节load/save_memory 是记忆系统第五节MAX_STEPS 是限流阀第六节。任何 Agent 框架剥掉包装都是这二十行。到这里把读者最容易混的两个“state”一次分清。窄义 state就是上面这张工单循环内部的结构化工作状态六站点共读共写。广义 state则是“存在模型外面、宿主程序可以用来拼窗口的所有持久化工作数据”的总称这张工单和写到盘上的产物、本会话的逐字对话记录transcript、从 transcript 派生的压缩摘要、跨会话记忆库、配置与可读写文件。两者是包含关系工单是广义总账的一个成员——还是其中结构化的核心而工单每轮的变化都会被序列化进 transcript——那些 assistant 消息和 tool 消息就是工单内容的外化。物理上这本总账散在多处一张表存对话、几张表存记忆、若干文件存产物概念上是一个夹子state 是家庭账本夹transcript 是夹子里最厚的流水账工单是当下摊在桌上的那一页。限流阀不是装饰。回路能转很多圈意味着它能转太多圈模型陷入“再查一次就好了”的自我说服步数和 Token 烧到天际。工程上必须设最大步数、Token 预算、工具白名单三道闸——这是 Agent 和工作流相比多出来的自由度所要付的账。transcript 的边界还顺带回答了另一个常被问到的概念会话是什么。一个会话 一条连续的对话线程也就是一个任务窗口会话的边界就是盘上这份记录的边界每轮对话往后面长一段。明天新开一个任务哪怕继续同一个话题就是一个新会话——记录从空白开始没有旧会话的一个字。“换个会话就忘”的根源就在这不是记忆丢了是新会话的记录本来就是空的。循环和账本都讲完了还差一环循环每转一圈和模型交接一次那次交接的数据到底长什么样下一节把这一次交接拆成四段 JSON。三、一次调用的数据模型怎么被调、怎么回答很多人对 Agent 的想象是“Agent 和模型之间聊聊天”。真实情况是两者之间传的永远是结构化的 JSON 文本一段一段、有严格格式。一次带工具调用的回合一共四段数据。我们用一个贯穿全文的例子用户是华东区销售运营月报口径是同比任务是“分析上月销售数据”。第一段Agent 拼给模型的 messagesAgent外壳程序在调用模型前要把“全部上下文”拼成一个 messages 数组。数组里每条消息有一个 role常见四种system规则与记忆、user用户当轮输入、assistant模型历史发言、tool工具返回。记忆就注入在 system 里{ model: some-llm, messages: [ { role: system, content: 你是销售数据分析助手只读不写数据库。/n/n- [preference] 月报口径 同比2026-08 用户明确指定/n- [fact] 用户是华东区销售运营/n }, { role: ”user”, content: 帮我分析上月销售数据生成月报 } ], tools: [ { type: function, function: { name: query_database, description: 在执行只读 SELECT 查询返回 JSON 行, parameters: { type: object, properties: { sql: { type: string } }, required: [sql] } } } ]}注意三件事。第一 块里那两条就是加载流水线从长期存储捞出来的——它们不是模型“想起来的”是 Agent 塞进去的。第二tools 数组是工具说明书每一轮都要重新塞一遍这是实打实的 Token 成本。第三这个数组就是模型的全部世界数组里没有的模型一律不知道。这个数组还有另一个名字本轮的上下文窗口——模型本轮能看的固定容量输入超一个 token 都塞不下。上一节把广义 state 讲清楚之后这里正好回答随之而来的问题state 和窗口什么关系能划等号吗不能窗口是 state 本轮裁出来的一份有损投影不是 state 本身。体量差决定了这一点。state 折成 token 可能是几十万上百万逐字 transcript、每次工具返回、记忆库、盘上文件窗口只有几十万的固定容量。每轮把 state 全量塞进窗口在物理上不可能所以宿主每轮实际做的是“挑选 拼装”本轮窗口 ≈ system 提示 工具说明书 跨会话记忆片段 旧轮压缩摘要 近期轮次原文 你的新消息。三个证据帮你把“投影”记牢。第一在 state 里但不在窗口里的被压成摘要的旧轮原文还在盘上但窗口里本轮是摘要不是逐字记忆库全量只有捞中的片段进得来盘上文件不用工具读就永远没有一个字进窗口。第二在窗口里但不在 state 里的system 提示和工具说明书每轮重建重塞不属于本会话的对话记录开局注入的记忆片段来自记忆库不是本会话 transcript。第三窗口每轮重建、state 持续累积本轮调用结束窗口蒸发模型忘光盘上 state 多一段新记录下一轮宿主再从新 state 拼一个新窗口。还是仓库和工作台state 是仓库窗口是工作台。每天早上每轮从仓库搬料上台——只搬台上放得下、本轮用得着的晚上调用结束台面清空仓库还在且多了新存货。台面上的东西永远是“今早从仓库选出来的一批”不是仓库本身。模型所谓的“全部世界”其实就是台面上这一批。第二段模型回给 Agent 的不是答案是 tool_calls模型读完第一段判断“我需要先查数据”。这时它返回的不是一段回答文字而是一个结构化的“表态”——这就是 Function Calling{ choices: [ { message: { role: assistant, content: null, tool_calls: [ { id: call_01, type: function, function: { name: query_database, arguments: {/sql/: /SELECT region, amount FROM sales WHERE month2026-09/} } } ] }, finish_reason: tool_calls } ]}这一段里有三个全篇最重要的细节下面单独讲。这里先记住形状模型用 tool_calls 字段说“我想调谁、参数是什么”content 是 nullfinish_reason 是 tool_calls。模型没有碰数据库它只是把意图说成了 JSON。真正去执行的是 Agent。第三段Agent 把工具结果包成 tool 消息拼回去Agent 解析出 name 和 arguments真的去连数据库执行拿到结果。然后它做一件很多人不知道的事把结果包成一条 role 为 tool 的消息拼回 messages 数组连同上一段那条 assistant 消息一起再调一次模型{ messages: [ { role: system, content: ……同第一段含 memory 块 }, { role: user, content: 帮我分析上月销售数据生成月报 }, { role: assistant, content: null, tool_calls: [ { id: call_01, …: … } ] }, { role: tool, tool_call_id: call_01, content: {/region/: /西南/, /amount/: 620000, /yoy/: -0.38} } ]}tool_call_id 必须和第二次数据里那个 id 对上——因为一轮里模型可能同时表态要调多个工具Agent 并行执行后要靠 id 把每份结果归还给对应的调用。而那条 assistant 的 tool_calls 消息必须留在历史里删了它tool 消息就成了无主之物多数模型会直接报错或读不懂。第四段模型这才输出最终答复模型第二次被调用时看到了工具结果于是给出真正的回答这次 content 是文本finish_reason 是 stop。Agent 把这段文本呈现给你回合结束——然后写回流水线启动把本次值得留的结论存进长期记忆。三个最容易记错的细节把上面四段浓缩成三句值得背下来**arguments 是字符串不是对象。 注意第二段里 arguments 的值是一整个被转义的 JSON 字符串。Agent 拿到后还要再 json.loads 一次才能得到参数对象。无数“工具调用失败”的 bug 就出在少解析了这一层{ “name”: “query_database”, “description”: “对销售库执行只读 SELECT 查询返回 JSON 行”, “parameters”: { “type”: “object”, “properties”: { “sql”: { “type”: “string”, “description”: “只读 SELECT 语句” } }, “required”: [“sql”] } }模型挑工具的方式不是查表而是读描述做匹配——所以“description 即检索”写得好坏直接决定选得对不对。坏写法是“查询数据”四个字模型无从判断该不该用好写法把“销售库、只读、SELECT、返回 JSON 行”这些判别信息给全。这里还有一个真金白银的成本说明书每一轮都要重新塞进 Prompt。30 个工具、每个 150 Token光说明书每轮就吃掉 4500 Token还没算对话历史和记忆。所以工程上有两个对策按任务动态挂载工具分析销售这轮就别塞 send_email以及描述写到“够检索”即可、不啰嗦成小作文。一次工具调用的完整链路把“描述”到“真请求”拆开是四棒接力第一棒 · 工具描述用某种规范把工具写成说明书——OpenAPI 和 MCP 的 Schema 都干这件事第二棒 · 解析注入Agent 把说明书翻译成文本塞进 Prompt模型看到的不是接口、是一段文字成本就在这一棒第三棒 · 模型决策模型输出“我要调 query_database参数 sql…”——这就是 Function Calling输出的是结构化文本不是真调用第四棒 · 执行调用Agent 解析这段结构化文本真正发起请求或 MCP 调用把结果写回 observations供下一圈循环使用。三个名词的归属由此清楚OpenAPI 和 MCP 站在第一、四棒描述与通道FC 站在第三棒决策。第一棒和第四棒发生在 Agent 一侧第三棒发生在模型里——所以“模型调用工具”的准确说法是“模型表态、Agent 动手”。能力三层工具、技能、插件工具之上还有两层经常被混用的概念一次分清工具是原子动作query_database 这种单次调用技能是流程加知识“生成月报” 先查数、再算同比、再按模板写是一段可复用的剧本插件是分发单元把一组工具和技能打包给别人安装。三层各管一件事动作、流程、分发。混用的根源是拿分发层的词去描述动作层的事。MCP把连接和描述分开最后说 MCP 为什么值得单独存在。没有它时每接一个工具服务都要写一套定制对接代码有了它发现工具、传参、回结果都走统一协议——描述OpenAPI 那类解决“工具长什么样”MCP 解决“怎么够到它”。一个 MCP Server 就像插座面板后面接着若干工具Agent 插上就能用还能多个 Agent 共享同一面板。工具解决了“够得着”可循环的首尾两站还空着——“记得住”挂在哪里下一节拆这两站。五、记忆循环的首尾两站现在看闭环的首尾两站。还是那个地基事实模型无状态记忆只能住在模型外面。所以“Agent 记得你”在工程上就是第二节立过的两条流水线回合开始前加载、回合结束后写回。下面先拆加载再拆写回。但拆四道闸之前先把一层机制讲透不然闸门的位置会摆错每轮加载的真是“记忆”吗其实同时跑着两种机制。本会话的历史不走加载流水线是直接读 state看你按下发送之后发生了什么宿主程序打开本会话在盘上的 transcript把你这条新消息 append 到末尾然后把整份内容或压缩后的“摘要 近期原文”序列化进 messages 数组发给模型。注意这个过程里没有什么没有检索、没有打分、没有四道闸。历史本来就在本会话的记录里而记录每轮都被直接拼进输入。所以 Agent“记得”本会话早前聊过什么真相是那些记录就在它本轮正在读的输入里——“记得” 读到了本轮递到手上的会议纪要而不是翻自己的脑子模型没有脑子可翻它无状态调用一结束全部蒸发。跨会话的长期记忆才走本文说的加载流水线而且两条路。一条是会话开局直接注入一份精炼的长期备忘在会话开始时就拼进 system 段相当于跳过检索、直接占记忆预算另一条是按需捞取更细的每日记录默认不在上下文里只有判断相关时才调记忆搜索工具——构造查询、检索、把命中片段读进上下文——正是下面四道闸的简化版。一个比方每轮对话都像见一位失忆的同事模型无状态但宿主在他坐下前把以往所有会议的完整纪要递到他手里。他“记得上次” 读到了手里的纪要直接读 state纪要里没有的别的会议内容 得去档案室翻记忆库检索即下面四道闸。还有一个活例子会话上下文溢出时宿主下一轮递进来的是压缩摘要——旧 transcript 被提炼成摘要再注入不是全量逐字。这正是第 6 篇讲的窗口管理动作也说明每轮进窗口的未必是 state 全量。理解这两层下面四道闸的位置就清楚了它只管跨会话的长期记忆本会话的记忆根本不需要它。加载管线四道闸第一道闸构造查询。拿什么去捞记忆最直接的是用户当轮消息加任务描述。但原始消息往往太口语工程上常先让模型把它改写成一句“检索意图”比如把“上月西南区怎么样”改写成“西南区 2026-09 销售业绩 同比口径”。查询构造的质量直接决定后面所有闸门的上限。第二道闸混合召回。只用向量语义检索会漏掉精确信息“口径同比”这种短事实语义向量并不突出只用关键词又漏掉同义改写。所以两路并跑向量库按余弦相似度捞 Top-K比如 20 条结构化存储按关键词和字段user_id、type再补一批去重合并。第三道闸重打分与阈值。语义相似度只说明“像”不说明“该用”。综合分要叠加三个信号重要度被召回次数 hits、来源权重 weight、新鲜度写入时间 ts 越近越重、类型匹配当前是分析任务preference 和 decision 类优先。公式形如综合分 相似度乘 w1 加 重要度乘 w2 加 新鲜度乘 w3。然后过一道阈值——低于阈值的宁可不用。宁缺毋滥是记忆系统的生命线一条不相关的记忆注入进去模型会认真地把它当前提用比没有记忆更糟。第四道闸截断注入。上下文窗口的预算是有限的而工具说明书、对话历史都在抢同一块地。所以给记忆一个 Token 预算比如 600按综合分从高到低装装不下就跳过——注意是跳过而不是截断半条半条记忆比没有记忆更危险。代码一个能跑的 load_memory把四道闸写成代码大概就是这样def load_memory(user_msg, budget_tokens600, threshold0.35): # 闸1构造查询这里简化为直接用用户消息 q embed(user_msg) # 闸2混合召回 向量语义 关键词/字段 cand vector_store.query(q, top_k20, filter{”user_id”: UID}) cand sql_store.match_keywords(user_msg, user_idUID) cand dedup(cand) cand [m for m in cand if m.superseded_by is None] # 过滤已作废 # 闸3重打分 阈值 for m in cand: m.score 0.5 * m.sim 0.3 * importance(m) 0.2 * freshness(m.ts) cand [m for m in cand if m.score threshold] cand.sort(keylambda m: -m.score) # 闸4Token 预算内截断装不下整条跳过 picked, used [], 0 for m in cand: cost tokens(m.text) if used cost budget_tokens: continue picked.append(m) used cost return picked每一行都对应一道闸。superseded_by is None 那行是遗忘机制的接口被新结论取代的旧记忆不作废删除而是打标记加载时过滤掉——保留删除链才能审计“当初为什么改口径”。filter user_id 那行是多用户隔离记忆库是全公司共用的捞错人的记忆比忘事严重得多。注入到哪里、以什么格式捞出来之后塞哪两个选择各有道理塞进 system 段的 memory 块本文例子用的方式地位高、稳定模型倾向于把它当长期前提适合偏好、身份、口径这类慢变信息。塞成一条独立的 user 或 system 补充消息适合与当轮任务强相关的 episodic 记忆“上次我们分析到一半发现是大客户流失”让它靠近当轮问题、注意力更集中。格式上不要只塞裸文本。带上 type 和时间模型才知道怎么用它memory- [preference | 2026-08] 月报口径 同比- [fact | 2026-07] 用户是华东区销售运营- [decision | 2026-10] 2026-09 西南区同比 -38%主因大客户流失/memory时间戳不是装饰。当两条记忆冲突时去年说看环比、今年说看同比模型靠时间戳知道该信新的。没有时间的记忆块冲突时模型只能瞎猜。回合结束后记忆是怎么被写回去的加载讲透了看写回。不是所有经历都配进长期记忆——一次任务会产生上千行原始信息查询结果、报错、中间推理全存下来等于往记忆里灌垃圾。写回的核心是一道晋升闸门加一步提炼。晋升的触发条件常见四类任务结束时的结论沉淀用户显式说“记住”这种 weight 直接拉高、来源标 user_explicit同一信息被重复提到三次以上说明稳定重要高代价事件出过事故的配置、被用户纠正过的错误。提炼是更关键的一步存结论和约束不存过程原文。那次分析任务讨论了很久、试了好几种下钻路径但进长期库的只应有一句“2026-09 西南区同比 -38%主因大客户流失”。把过程塞进去三个月后召回时全是噪声。提炼谁来做让模型做。回合结束时Agent 把本次轨迹摘要喂给模型要求它按固定 schema 输出候选记忆条目{ text: 月报口径 同比, type: preference, source: user_explicit, confidence: 0.95 }Agent 再补上 ts、hits、weight、embedding 等元数据落库。一条记忆的完整记录结构长这样{ id: m_b, text: 月报口径 同比, type: preference, source: user_explicit, ts: 2026-08-12T10:00:00Z, hits: 7, weight: 0.9, superseded_by: null, embedding: [0.021, -0.13, 0.08] }每个字段都有用途type 供召回时过滤ts 和 hits 和 weight 供重打分与遗忘superseded_by 供作废链embedding 供语义检索。字段设计得越糙加载管线就越做不精——第三道闸的每个信号都来自这些字段。还有一个隐蔽的坑带毒记忆。如果“主因大客户流失”是模型猜的、没经过工具返回校验就沉淀了下来它会变成一条带毒记忆之后每次月报都被捞出来当既定事实。对策是晋升前对结论型记忆做证据校验并且让 source 为 task 的条目比 user_explicit 的权重更低、更容易被后续证据推翻。存哪里三种方案与组合长期记忆落在哪三种主流方案软肋互补方案怎么存强项软肋向量数据库记忆转向量按语义相似度捞模糊回忆强问“上次那个数据库决定”能捞到“选型PostgreSQL”会捞回“差不多但不相关”的难精确审计SQLite 活动账本一条记忆一行带 type、ts 字段精确、可审计、可 SQL 查询不懂语义只能按字段查文件系统写成 Markdown 主账本加按日期日志人能直接读改、能进版本控制检索靠 grep 或额外索引真实产品里三者组合使用文件当人能读的主账本向量库当语义索引SQLite 当活动流水。加载管线的第二道闸“混合召回”正好就是向量库出语义候选、账本出精确候选再合并——你看存储选型不是三选一而是给流水线的不同闸门供货。它“忘”了其实是四种不同的坏法“忘”不是一种病是四种不同的坏法对症的药完全不一样第一种没写进去。回合结束后写回流水线没触发——用户那句“记住”没被识别为显式指令或晋升阈值太严。症状是“我明明说过”但库里根本没有这条。修法给显式指令加高优先级触发器用户说“记住”必须落库不走概率。第二种写进了但没命中。库里有加载管线第二道闸没捞到——查询构造太口语、或向量索引没更新。症状是“有时候记得有时候不记得”换个问法就好了。修法优化查询改写、上混合召回。第三种捞到了但没进注入名额。第三、四道闸把它挤掉了——阈值太高、或 Token 预算被工具说明书和历史对话抢光。症状是长对话后期开始忘窗口越挤越严重。修法给记忆设保底预算、动态卸载不相关工具描述。第四种注入了但被忽略或冲突。记忆在 Prompt 里却被淹没在长上下文中间或与当轮信息矛盾时模型选了错的。症状是“它看到了但还是按错的来”。修法把关键记忆放在 system 段和靠近当轮问题的位置、带时间戳让模型能判新旧、冲突时显式标注“以新为准”。还有一个反直觉的设计好的记忆系统必须会遗忘。只增不删三个月就变垃圾场被推翻的旧记忆标记作废取代链在加载管线里已经见过长期未命中的按时间衰减降权带毒的结论在晋升前就被证据校验拦下。遗忘不是缺陷是记忆系统保持可信的手段。下次你的 Agent“忘”了你先别骂它记性差。按这四条逐个排查库里有没有、召回没召回、注入没注入、模型用没用。定位到哪一种坏法才知道该修哪一段代码。把记忆挂回那条闭环它本身也是工具最后把视角拉高一层。一个能自己干活的 Agent本质是“一个大模型塞进一个循环循环外挂了状态和工具”模型负责想Agent 负责管和调工具负责做。那个循环每转一圈都要经历加载记忆、拆解任务、执行与工具调用、观察结果、达成判定、沉淀记忆六个站点——记忆正好挂在首尾两站回合前加载、回合后写回。本文拆的就是这两站的内部。还有一层容易忽略的事实记忆的读写本身常常也被注册成工具。recall_memory 和 save_memory 两个工具和 query_database 走完全相同的 Function Calling 通道——模型在 tool_calls 里表态“我要recall_memory参数是这句查询”Agent 执行后把结果包成 tool 消息传回。这意味着记忆系统的可用性一半取决于这两个工具的 description 写得好不好描述含糊模型该recall的时候不recall你又会看到第一种“忘”。而如果记忆服务通过 M站点典型失败症状对策循环回路空转步数和 Token 烧到天际“再查一次就好了”最大步数、Token 预算、工具白名单拆解目标漂移做着做着去回答了别的问题每圈对照 state.goal 复检调用参数错误工具报错、SQL 不合法schema 约束类型、执行前校验层工具选错工具该查订单时去查了库存description 四要素写全、动态挂载观察返回挤爆窗口长对话后期开始犯糊涂工具返回先摘要再入 observations记忆带毒记忆同一个错误结论反复被当事实晋升前证据校验、作废链可回滚这张表的用法很简单Agent 出错时先定位到站点再谈修法。“Agent 不稳定”不是一种病是六个站点各自的病。七、懂了原理之后怎么让 Agent 更好干活了解原理不是为了显摆是为了换一种方式下指令。下面这几条习惯每一条都对应前文的某个机制今天就能用。给上下文别考它记性。模型的世界只有当轮那一个 messages 数组你没塞的它就不知道。所以任务开头把背景、口径、约束一次给全——“我是华东区销售运营月报看同比口径数据库只读”——别预设它“应该记得”。真想让它长期记住的显式让它写回说一句“记住这条”触发显式写回闸门比顺嘴提十句都管用。把目标写成可验收的完成态。循环退不退出靠站点 5 的达成判定对照 goal 检查。“帮我分析一下数据”会让模型自己也不知道算不算完成“出一份 2026-09 月报含总额、同比、异常下钻800 字以内”就让判定有了依据。目标越可验收回路空转越少。派活前先扫一眼工具表。Agent 够得着什么由工具表和权限边界决定。派活前确认两件事需要的工具在不在——没挂 render_chart它就只能用文字描述图权限边界在哪——只读的 query_database 想误发邮件也发不了。很多“Agent 不聪明”的现场其实是工具没挂对。让回路转几圈别在第一棒就掐断。ReAct 的价值在观察之后再判断第一圈查到 -38%第二圈的下钻才值钱。看到第一个中间输出就当最终答案去打断纠正等于在接力赛中途抢棒。你要管的不是中间步骤而是限流阀最大步数、Token 预算、工具白名单让它转、但转在阀里。出错先定位站点再谈修法。输出错了先看站点 4 的观察工具返回本身就错是工具或数据的问题返回对而模型读错是模型的问题——两者修法完全不同。忘了就按四个断点排查没写、没命中、没注入、被忽略。先定位病在哪再开药别笼统归成“Agent 不稳定”。重要结论要证据把带毒记忆拦在闸门外。没经过证据校验就沉淀的结论会变成带毒记忆之后每次都被捞出来当事实。所以对关键数字多问一句“这个数从哪来的”让它指到工具返回而不是自己的印象。这一问能把大部分毒拦在晋升闸门之前。这六件事共用一个底层心态把 Agent 当一个需要喂上下文、需要明确验收标准、需要配好工具的无状态同事而不是一个会读心、会意会的老员工。这样用前面拆过的所有原理才真正变成你手里的生产力。本篇核心术语表术语白话解释Agent宿主程序跑循环、管状态、调模型、执行工具的外壳程序不是模型大模型LLM内嵌在 Agent 里的大脑只输出文本不执行任何动作工具ToolAgent 外部的原子动作真正连数据库发请求的是它状态对象state六站点共读共写的工单goal、memory、plan、observations、done、stepsReAct 循环推理、行动、观察再推理的回路Agent 与工作流的根本区别观察observations工具返回写进状态的字段下一圈循环的输入Function Calling模型把调用意图说成结构化 JSON 的内置能力即第三棒表态tool_calls模型返回里的调用意图字段content 为 null 时表示中间态tool 消息Agent 把工具结果包成的消息靠 tool_call_id 与表态配对OpenAPI工具描述规范把接口写成机器可读说明书MCPAgent 与工具服务之间的连接协议工具界的 USB-C技能Skill流程加知识的可复用剧本位于工具之上的流程层插件Plugin把一组工具与技能打包分发的单元记忆加载 / 写回回合前捞记忆注入 Prompt、回合后提炼结论存库的两条流水线记忆晋升满足触发条件并提炼成结论后才转存长期记忆的闸门限流阀最大步数、Token 预算、工具白名单防止回路空转会话Session一条连续对话线程的边界 盘上 transcript 的边界新开任务即新会话记录从空白开始Transcript本会话在盘上的逐字对话记录state 最大的成员每轮被直接拼进窗口状态state两层含义窄义 循环里的工单state 对象六站点共读共写广义 模型外持久化工作数据的总称transcript、压缩摘要、工单与产物、记忆库、配置前者是后者的一个成员、结构化核心上下文窗口本轮从 state 选材拼装、递到模型手里的固定容量输入即本轮的 messages 数组是 state 的有损投影不是 state 本身压缩摘要上下文溢出后从旧 transcript 派生的摘要替代逐字原文进窗口本身也是 state 的成员大模型的知识又多又杂到底怎么学做这行久了被问最多的问题就一个大模型的知识又多又杂我到底先学啥翻了一堆资料看啥都像重点结果啥都没学进去。今天把我自己一路摸出来的顺序捋一遍零基础、应届生、转行的都适用。跟着走至少方向不乱、不瞎忙学完拿得出手。第一阶段10天初阶应用这一阶段就一个目标把大模型真正玩明白不是只会聊天那种而是能调教它、能用代码把大模型和业务接起来。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用这阶段正式进实战目标很实在做出两个能拿出手的东西——一个私有知识库一个 agent 对话机器人。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…走完这 30 天Python 或 JavaScript 背景的基本能独立做一套 RAG 应用简历上也敢写大模型应用开发了。第三阶段约20天动手微调学到这你已经开始 “造” 模型了 —— 通过微调搞出垂直领域的专用小模型。为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你从 “只会用” 变成 “能造” 的 AI 小子。那么你还想往下探索吗想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料第四阶段20天商业闭环部署落地技术学完落地才算数。这阶段带你搞明白大模型怎么真正跑起来、用起来。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…想要入坑大模型的朋友给大家准备了一份2026 年最新 AI 大模型全套学习资料1、大模型系统化学习路线2、大模型学习视频教程3、大模型学习书籍电子文档4、AI大模型最新行业报告5、大模型项目实战配套源码6、2026大模型大厂面试真题7、为什么要学习大模型我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年人才缺口已超百万凸显培养不足。随着AI技术飞速发展预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。8、适合谁学传统后端 / Java / 前端开发想转型 AI 应用大学生、应届生想拿更好的 offer产品经理、运营想武装职业竞争力技术负责人想给团队落地提效学习是反人性的但回报是真金白银。技术会更新赛道会切换但只要你先动手机会就永远站在你这边。9、这些资料真的有用吗这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理现任上海殷泊信息科技CEO其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证服务航天科工、国家电网等1000企业以第一作者在IEEE Transactions发表论文50篇获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。资料内容涵盖了从入门到进阶的各类视频教程和实战项目无论你是小白还是有些技术基础的技术人员这份资料都绝对能帮助你提升薪资待遇转行大模型岗位。想要入局AI大模型赛道、抢占行业红利的朋友微信扫描下方CSDN官方认证二维码即可100%免费领取全套学习资料好了就写到这。路线是死的人是活的卡住了随时来问我。觉得有用就点个收藏别让它进收藏夹吃灰——动起来比啥都强。