Agent 应该记住什么做企业工单处理时这个问题不是产品细节而是系统边界。用户昨天投诉过延迟发货今天又来追问补偿同一条退款政策上周刚调整某个客户过去三个月有多次异常退货一线客服已经给过一次人工备注Agent 自己上一轮刚查过订单状态。这些信息都可能影响处理结果但它们不属于同一种“记忆”。如果我们把它们全部追加到对话上下文里Agent 很快会被旧信息、噪声和冲突事实拖住。如果我们只把它们丢进向量库又会失去状态、权限、时效性和可审计性。Agent 记忆不是一个存储插件而是一套信息生命周期管理机制。工作记忆决定下一步怎么做短期记忆保证当前任务不断线长期记忆提供跨任务的背景和经验。把这三者混成一个“memory”是很多 Agent 项目后期失控的起点。一、记忆不是一种东西而是三种时间尺度认知心理学里常说感觉记忆、工作记忆和长期记忆。我们不需要把心理学概念机械搬进系统设计但这个分层很适合帮工程团队拆问题。在企业工单 Agent 里可以这样映射认知视角工程映射典型内容生命周期感觉记忆原始观察缓冲用户本轮输入、工具原始返回、系统事件极短只用于提取事实工作记忆当前决策状态当前工单摘要、待处理动作、风险标记、最近证据每一轮动态组装短期记忆会话 / 工单线程状态当前工单处理过程、已查信息、已尝试动作、临时摘要一个会话或一个工单周期长期记忆外部可检索记忆库用户历史、政策知识、处理记录、组织经验跨会话、跨任务持久化这里特意把“感觉记忆”翻译成原始观察缓冲而不是让它变成又一个数据库。因为大部分原始观察不应该长期保存也不应该直接进入模型上下文。工具返回的完整 JSON、搜索引擎的原始结果、CRM 的完整用户档案都更适合先被压缩成事实再决定是否进入下一层。这也是记忆系统的第一条边界不是所有被 Agent 看见的信息都应该变成 Agent 的记忆。比如处理一个延迟发货工单时订单 API 可能返回几十个字段。Agent 当前真正需要的可能只有{ ticket_id: T-20260524-0831, intent: shipping_delay_complaint, order_status: in_transit, promised_delivery_date: 2026-05-21, current_date: 2026-05-24, delay_days: 3, customer_tier: gold, risk_flags: [second_contact_in_7_days] }这份结构化事实可以进入工作记忆。原始订单对象、完整物流轨迹、客服系统的后台字段不必全部塞进去。记忆的工程化不是“多记一点”而是决定一条信息应该在哪一层停留、以什么格式停留、什么时候被移出、谁有权改写它。二、工作记忆当前这一步需要什么证据工作记忆是 Agent 的当前工作台。它不是历史记录也不是知识库而是本轮决策需要同时放在手边的事实。企业工单 Agent 每一轮通常要做这几个判断用户真实意图是什么当前工单处在哪个状态已经查过哪些系统需要哪些政策依据下一步是回复、继续查询、提交审批还是升级人工本轮动作有没有权限和风险因此工作记忆最适合做成结构化状态而不是一段自然语言摘要。一个简化版本可以长这样frompydanticimportBaseModel classWorkingMemory(BaseModel): ticket_id: str user_intent: str ticket_status: str known_facts: list[str] relevant_policy_ids: list[str] pending_questions: list[str] proposed_action: str|NoneNone risk_level: strlow last_tool_observation: str|NoneNone这段结构的重点不是字段完整而是把“本轮要用来决策的东西”从聊天消息里拿出来。如果 Agent 准备给用户发补偿方案它不应该只凭上一轮自然语言记忆说“用户好像很着急”。工作记忆里应该有更可验证的证据{ known_facts: [ 订单承诺送达日为 2026-05-21当前已延迟 3 天, 用户 7 天内第二次联系同一问题, 当前物流状态为运输中未显示丢件, 延迟发货政策 policy://shipping-delay/current 命中 ], proposed_action: offer_delay_coupon, risk_level: medium }这会直接影响工具选择。低风险时可以生成回复草稿中风险时可能要先创建内部备注高风险时必须请求人工审批。工作记忆有两个常见坑。第一个坑是把它做得太胖。工作记忆不应该常驻完整用户画像、完整政策文档、完整工单历史。它只保留当前决策需要的压缩事实。第二个坑是让模型自由维护它。生产系统里工作记忆应该由控制器和工具返回共同更新。模型可以建议“我认为这是二次投诉”但是否写入risk_flags最好由规则、工具返回或审计过的分类器确认。这不是不信任模型而是保持状态可信。Agent 的语言输出可以有弹性执行状态不能靠印象管理。三、短期记忆让一个工单线程不断线短期记忆解决的是连续性问题。用户不会按系统希望的方式一次性提供所有信息。他可能先说“物流怎么还没到”过两分钟补一句“我上周已经催过一次”客服主管可能中途加一条内部备注Agent 可能已经查过订单、搜过政策、生成过一版回复草稿。这些内容不一定值得长期保存但在当前工单没有结束前它们必须可恢复、可追踪、可继续使用。短期记忆通常包含当前会话消息和用户补充信息当前工单处理摘要已调用工具和关键返回失败尝试例如某个政策检索没有命中待确认事项例如缺少订单号或需要人工审批已生成但未发送的回复草稿它适合用线程级状态、checkpoint 或工单生命周期内的临时存储来承载。LangChain / LangGraph 当前的官方抽象里短期记忆就是 Agent state 的一部分并通过 checkpointer 按线程持久化这类设计很适合“当前会话可以暂停、恢复、继续执行”的场景。工程上短期记忆最好不要只是messages数组。我们至少需要一个可覆盖更新的摘要{ thread_id: thread_7f3a, ticket_id: T-20260524-0831, summary: 用户投诉订单延迟 3 天且 7 天内第二次联系。已查询订单状态为运输中命中延迟发货政策。当前缺少是否发放补偿券的审批结果。, checked_systems: [ticket, order, policy], open_items: [等待主管审批补偿券], draft_reply_id: draft_912 }这份摘要应该随着状态变化被改写而不是不断追加。短期记忆最危险的地方是旧状态污染新决策。比如 Agent 在 10:00 查询到物流状态是“运输中”但 10:30 物流已经签收。如果短期记忆仍然把“运输中”当成当前事实后续回复就会出错。所以短期记忆里的事实要区分两类稳定事实用户 7 天内第二次联系、曾经触发过人工审批 易变事实订单状态、库存状态、优惠券是否已发放、工单当前状态易变事实不能只靠记忆续命。每次执行关键动作前都应该重新查询或校验。这一点在工单系统里尤其重要。短期记忆负责让 Agent 不断线但不能替代业务系统的当前状态。四、长期记忆不要把向量库当成全部答案长期记忆是最容易被误解的一层。很多实现会直接等同为“把历史对话切 chunk写入向量数据库”。这能做出一个像样的 Demo但很难支撑真实业务。企业工单 Agent 的长期记忆至少有四类。**第一类是政策知识。**例如退款规则、延迟发货补偿标准、会员权益、升级处理 SOP。它们通常是组织级、版本化、只读或受控写入的知识不应该让 Agent 在对话中随意改写。**第二类是用户历史。**例如这个用户过去的投诉、补偿、风险标签、服务偏好。它和隐私、权限、保留期限直接相关不能被简单当作“记住用户喜欢什么”。**第三类是处理记录。**例如某类工单最终如何解决人工为什么驳回 Agent 的建议哪种回复模板更容易二次升级。这类记忆更像经验样本可以用于后续检索、评测和流程改进。**第四类是程序性经验。**例如“遇到政策冲突时先升级到 refund_review 队列”“无法确认收货责任时不要承诺现金补偿”。它不是用户事实而是可复用的操作策略通常应该由团队审核后沉淀。这四类记忆适合的存储方式并不相同。长期记忆类型更适合的存储不适合的做法政策知识文档库、版本库、向量索引、关键词索引只存 embedding不保留版本和来源用户历史CRM、关系数据库、受控画像表写进开放向量库缺少权限隔离处理记录工单日志、事件表、可回放 trace只保存自然语言总结无法审计程序性经验Prompt / SOP / 技能文件、规则配置让模型在对话中直接自我改写向量数据库在这里很有价值但它只解决一类问题根据语义相似度召回可能相关的文本片段。它不负责事实权威性、时间有效性、权限、冲突处理和写入审计。知识图谱或关系型结构也不是为了显得高级而是用来表达向量检索不擅长的关系用户 A - 拥有订单 O 订单 O - 对应工单 T 工单 T - 命中政策 P 的 2026-05-01 版本 政策 P - 允许补偿类型 coupon但不允许 cash_refund 主管 U - 在审批单 R 中驳回 cash_refund如果系统需要回答“为什么不能直接退款”这条证据链比一段相似文本更可靠。长期记忆的关键不是“存得久”而是能回答三个问题这条记忆从哪里来 现在是否仍然有效 当前 Agent 是否有权使用它回答不了这三个问题长期记忆就会从能力变成风险。五、写入记忆比读取记忆更危险读取记忆会带来误召回写入记忆会带来污染。很多 Agent 项目喜欢设计“自动学习”用户说了什么Agent 觉得有用就写入长期记忆。这个能力听起来像智能落到企业工单场景里却很危险。用户说“你们上次答应给我免单”不等于系统应该记住“该用户享有免单权益”。Agent 判断“这个客户情绪激动”不等于可以写入长期风险标签。某次人工客服临时破例补偿不等于形成新的政策规则。一次错误回复被用户接受也不等于它应该成为未来样板。所以写入记忆必须经过分类、校验和权限控制。一个比较稳的流程是观察到新信息 - 判断信息类型事实、偏好、政策、处理经验、临时状态 - 判断作用域当前线程、当前工单、当前用户、组织级 - 判断写入方式自动写入、待审核写入、禁止写入 - 记录来源、时间、证据和操作者 - 后台合并、去重、过期或冲突检查这时我们需要的不是一个随手save_memory(text)的工具而是一个带元数据的记忆记录。fromdatetimeimportdatetime fromtypingimportLiteral frompydanticimportBaseModel classMemoryRecord(BaseModel): scope: Literal[thread, ticket, user, organization] memory_type: Literal[fact, preference, policy, episode, procedure] content: str source: str evidence_ids: list[str] valid_from: datetime valid_until: datetime|NoneNone confidence: float write_status: Literal[auto, pending_review, approved, rejected]这里最重要的是scope、memory_type、source、evidence_ids和write_status。它们决定一条记忆能不能被复用复用到哪里是否需要人工审核。比如当前用户明确说“以后请优先邮件联系”可以写成用户级偏好但仍要允许用户修改和删除。人工主管确认“本次延迟符合补偿券规则”可以写入工单处理记录但不能上升为组织政策。多次工单显示某个政策条款容易误判可以进入待审核的程序性经验而不是让 Agent 直接改系统 Prompt。写入记忆还要处理冲突。长期记忆里可能已经有一条“用户偏好短信联系”现在用户说“以后发邮件”。系统应该更新、覆盖或标记版本而不是让两条偏好同时在检索结果里打架。六、LangChain 和 LlamaIndex 解决的是不同层面的记忆问题框架能帮我们少造轮子但不能替我们决定记忆边界。从当前官方抽象看LangChain / LangGraph 更贴近 Agent 运行时记忆。短期记忆通常是 Agent state 的一部分通过 checkpointer 按线程保存长期记忆则可以通过 store 按 namespace 和 key 保存 JSON 文档并在工具或运行时里读取、写入。这个方向适合表达当前线程状态如何恢复一轮工具调用后状态如何更新不同用户或组织的记忆如何隔离命名空间Agent 执行过程中如何读写记忆这和本文里的“短期记忆”非常贴近。比如当前工单处理到一半Agent 等待主管审批补偿券用户关闭页面后再回来系统要从同一个线程状态恢复而不是让模型凭历史摘要重新猜。LlamaIndex 更贴近“记忆内容”和“知识存储”的表达。它的 Memory 抽象把短期消息和长期 MemoryBlock 分开短期记忆可以按 token 限制保留最近消息超出预算的内容可以被 flush 到长期记忆块长期记忆块又可以用事实抽取、向量记忆等方式保存更稳定的信息。这比泛泛地说“接一个向量库”更有解释力。放到工单场景里LlamaIndex 的几个抽象可以对应到非常具体的设计短期消息缓存保留当前用户和 Agent 最近几轮互动避免每轮重新总结。FactExtractionMemoryBlock从对话中抽取可复用事实例如“用户确认以后优先邮件联系”。VectorMemoryBlock保存更长的历史片段或处理经验用语义检索按需召回。ChatStore把会话消息持久化避免短期记忆只活在进程内。StorageContext把 docstore、index store、vector store、property graph store 等存储拆开承载政策文档、索引、向量和关系。注意这里仍然要守住边界。FactExtractionMemoryBlock可以帮我们抽取事实但它不能决定这个事实是否有权写入用户画像VectorMemoryBlock可以召回相似历史但它不能判断旧政策是否已经失效StorageContext可以组织存储但它不等于记忆治理层。所以不要简单问“记忆用 LangChain 还是 LlamaIndex”。更实用的分工是问题更贴近的抽象当前工单线程怎么暂停和恢复LangGraph state / checkpointerAgent 工具调用后如何更新当前状态LangGraph state用户级长期偏好如何按命名空间保存LangGraph store 或业务数据库最近对话如何受 token 预算控制LlamaIndex Memory会话事实如何抽取成长期记忆候选LlamaIndex MemoryBlock政策文档、索引、向量和图关系如何分层存储LlamaIndex StorageContext哪些记忆能写、谁来审核、如何审计应用自己的记忆治理层最后一行最关键。LangChain 和 LlamaIndex 都不会自动知道某条工单备注能不能写进长期用户画像也不会自动判断某份政策是否已经过期更不会替我们完成隐私删除、审批审计和跨系统权限隔离。框架可以承接中间很多实现细节但系统设计必须先说清楚哪类记忆属于谁谁能读谁能写什么时候过期冲突时听谁的。有技术底子的人正站在AI大模型开发的黄金入口先问自己一个问题你写了这么多年代码薪资是不是已经很久没动了面试的时候“会Spring Boot”“会Vue”会MySQL已经变成了基本操作没有人在乎了。大家都会的东西就不值钱了。但另一边有人在疯狂涨薪拉勾、BOSS直聘上“AI应用开发”“大模型开发”Agent开发的岗位数量在过去一年翻了3倍薪资中位数比同级别后端开发高出 40%-60%。不是因为他们比你聪明而是因为他们踩对了赛道。你可能觉得我又不是搞算法的大模型跟我有什么关系这就是最大的误区。AI大模型应用开发 ≠ 训练大模型说清楚一点训练大模型的是那几家大厂但用大模型做应用的是千千万万的普通企业和团队。而这些团队需要的不是PhD而是——能用大模型API搭出可用产品的应用开发者能设计Agent工作流、调用工具链的Agent工程师能把RAG、Function Calling、多轮对话落地到真实业务的AI全栈这些活儿有编程基础的你完全能干。你需要补的不是算法基础而是AI开发的技术栈和工程思维。Agent开发为什么是程序员最好的切入点因为Agent开发本质上就是用自然语言编程——而这恰恰需要你已有的工程能力你有代码功底 → 理解Function Calling、工具调用、API集成比零基础快10倍你有系统设计经验 → 设计多Agent协作架构、状态管理、错误处理逻辑一脉相承你懂工程化 → 部署、监控、性能优化这些AI项目同样需要你理解数据 → RAG系统的数据清洗、向量检索、效果调优你的DB经验直接复用说白了你已有的能力是资产不是沉没成本。差的只是AI这一层的认知和工具链。学完之后你值多少钱转型 从传统后端/前端转AI应用开发打开薪资天花板跳槽议价权拉满升职 在现有团队主导AI项目落地从写代码的变成定方向的独立 用Agent开发能力做SaaS产品、接AI外包项目技术变现多一条腿不可替代 当AI能写CRUD了你是那个用AI写代码的人而不是被AI替代的人这不是危言耸听。GitHub Copilot已经能写出70%的CRUD代码了纯执行层面的程序员价值在快速缩水。但能用AI构建AI应用的人目前严重不够用。这门课会教你什么面向有编程基础的开发者从AI大模型应用开发的工程实践出发✅ 大模型API调用与Prompt工程实战✅ RAG系统搭建从数据处理到向量检索全流程✅ Agent开发Function Calling、工具链、多步推理✅ 多Agent协作与工作流编排✅ 真实项目落地从需求到部署的完整工程链路不讲虚的全是能直接用在项目里的东西。 AI大模型应用开发课程有编程基础这就是你的下一个赛道“程序员最大的风险不是技术过时而是用旧技术赚新钱的心态。”你可能还在想再等等看——但AI这个赛道窗口期就这么长。等大模型开发变成标配技能的时候你就不是先行者了而是追赶者。你有技术底子这是你最大的优势。别浪费它。
