企业官网建设流程全解析

上个季度我们团队接手了一个客服答疑Agent的升级改造，原来的系统勉强能跑，用户对话稍微绕一点就答非所问——今天报修的设备明天再问，它完全不记得，用户只能把品牌型号重新报一遍。老业务吐槽说这哪叫Agent，顶多算个高级接口查询工具。后来我们把整条链路拆开重做，核心就落在三件事上：Agent扩展范式怎么选、Memory记忆体系怎么搭、多轮记忆改造怎么做。改造完跑了整整一个月，同一批用户的重复咨询满意度从62%涨到了88%，用户终于不用反复交代自己的背景信息了。这篇文章就是我在这轮改造里积累下来的完整思路和踩坑记录，适合正在做Agent开发、打算给Agent加记忆能力、或者准备把手头单轮对话工具升级成多轮记忆Agent的工程师参考。

1. 扩展范式决定Agent的"四肢"：三种主流机制怎么选

1.1 无扩展能力的Agent只是个会说话的接口

先说一个很多人容易忽略的前提：一个Agent如果只能"聊"，不能"做"，那不叫智能体，叫聊天机器人。真正的Agent至少要能调工具、查数据、写文件、操作外部系统，而这些能力都依赖扩展机制来加载。

我接手原有项目的时候，那个系统本质上就是"LLM + 单函数调用"的玩具结构。每个意图写一个匹配规则，命中后调用一个写死的函数，模型完全看不到函数之外的扩展空间。一旦业务方提了个不在预设规则里的需求，开发就得加班改代码。这种方案的问题非常明显：扩展成本高、耦合严重、模型没有选择权。

1.2 Function Calling、ReAct、Skill注册制三种范式的适用边界

目前在Agent开发里，扩展范式的主流选择基本是这三条路：

• Function Calling（工具调用）：模型根据系统预设的工具Schema，自主决定调用哪个函数、传什么参数。OpenAI、Claude、国产大模型都支持这个模式。优点是实现简单、决策可控；缺点是函数一旦多了，模型容易选错，需要做好路由约束。
• ReAct（推理-行动-观察循环）：模型边推理边行动，把"思考→执行→看结果→再思考"串成一个循环，适合需要多步操作才能完成的复杂任务。缺点是循环次数多了延迟高、token消耗大，而且模型在循环里容易跑偏。
• Skill注册制（技能封装）：把一组相关工具打包成"技能"，Agent按场景加载对应技能包。比如客服场景加载"工单技能""退款技能""排障技能"，而不是把所有函数一股脑丢给模型。这种方式在大规模Agent系统里最实用，也是我们这次改造的核心范式。

1.3 我最终选择的扩展范式：技能包加函数路由

改造后我选的是"Skill注册制 + 函数白名单"的混合方案，理由很直接：

第一，场景隔离。客服业务里面有几十个上游系统接口，如果全部注册成Function，模型在几十个相似函数里挑，准确率一定崩。按技能包隔离后，Agent先通过意图识别定位到"售后排障技能包"，再从包内的五六个函数里选择，路由空间小了一个数量级。

第二，权限可控。技能包可以配独立权限，比如"订单查询技能"普通用户能用，"内部工单修改技能"必须验证坐席身份。这比一把梭地开放所有工具安全得多。

第三，扩展成本低。新业务接入时只需要注册一个新的技能包，注册信息包括技能描述、函数Schema、触发条件，Agent的调度核心完全不用改。

# 技能注册的伪代码示意 skill_registry = {} def register_skill(name, description, tools, triggers, permission="user"): skill_registry[name] = { "description": description, "tools": tools, # 函数定义列表 "triggers": triggers, # 触发关键词/意图条件 "permission": permission, } register_skill( name="after_sale_troubleshooting", description="处理售后排障、报修、设备回访等请求", tools=[search_order, fetch_device_status, create_work_order], triggers=["报修", "故障", "无法使用", "维修进度"], permission="user", )

这套范式跑了大半个月，工具选择准确率从改造前的74%提升到了93%，效果非常明显。如果你正在搭新Agent，我建议别一上来就堆Function，先想想业务场景能不能拆成几个技能包。

2. Memory记忆体系不是Redis缓存那么简单

2.1 记忆的本质：从无状态API到有状态协作者

第一次给Agent加记忆的时候，我和大多数人一样，第一反应是"用Redis把之前的对话存下来，下次拼进Prompt不就行了"。真正做完才发现，这个思路连及格线都够不着。

原因在于：记忆不只是"存储"，而是"理解什么该记、什么该忘、什么该用"。一个没有记忆的Agent在每一轮对话里都是"失忆者"，它面对的是全新的空白上下文；而一个有记忆的Agent，应该是像一个接手老客户的老员工——知道客户以前买过什么、说过什么、抱怨过什么。

2.2 把记忆拆成四层：工作记忆、情境记忆、语义记忆、偏好记忆

我们做记忆体系设计时，参考了认知科学里对记忆的分类方式，结合工程实际拆成了四层：

这个分层最大的价值是：记忆的使用方式完全不同。工作记忆直接进Prompt，情景记忆要检索命中才用，语义记忆是全局强约束，偏好记忆则只在推荐场景触发。如果不分层，一股脑全塞进上下文，模型会被几百条历史记录撑爆注意力，反而答得更差。

2.3 存储引擎选型：向量库、KV库、关系表的混合架构

记忆分层之后，存储引擎的问题自然浮出来了。我们的选择是：向量库做情景记忆的检索，Redis做工作记忆和偏好缓存的读写，PostgreSQL存用户实体和业务关系的结构化数据，图结构用来表达实体之间的关联。

场景化解释一下：

• 用户问"我上次那个设备报修到底处理到哪个环节了"，这句话需要从历史对话里检索出"上次那个设备"对应的工单记录，这里必须用向量相似度去找，关键词匹配几乎找不到。
• 用户画像和业务规则是高度结构化的，比如"用户等级=VIP""设备型号=X200巡检仪"，放关系表里查询快、好维护。
• 偏好记忆不需要太强的语义检索，一份JSON塞进Redis就行，读取延迟能控制在毫秒级。

提示：不要在项目初期就迷信向量库。如果你的历史记忆量在几十万条以内，业务关系又很清晰，那用PostgreSQL＋pgvector就够了，真没必要单独部署一套Milvus。我见过太多团队还没建好记忆体系就先搭了三个中间件，最后一个月过去了，数据怎么写入都没想明白。

2.4 记忆生命周期：写入、衰减、归档、遗忘

工程里最容易被忽略的环节是记忆的"死亡管理"。我们设计了四条策略：

• 写入策略：不是所有对话都值得记。能沉淀为事实的信息（用户身份、设备型号、明确偏好）才写入语义记忆；有价值的操作过程（报修、退款、投诉）写入情景记忆；废话直接丢弃。
• 衰减策略：情景记忆设置时间衰减权重，三个月前的维修记录权重降到新记录的30%，检索排序时自动靠后。
• 归档策略：一年以上的旧工单、旧对话定期归档到冷存储，不参与在线检索，减少向量库压力。
• 遗忘策略：用户明确要求删除的信息、离职员工的档案、过期的营销偏好，必须能真正物理删除，这在记忆系统里是最基础也最容易被漏掉的合规要求。

这套生命周期的管理一开始看着繁琐，但等到记忆量上来之后，你就会发现没有它系统早就被垃圾记忆拖垮了。

3. 多轮记忆改造：从无状态到有状态的完整升级路径

3.1 改造前：单轮无状态Agent的痛点复盘

改造前的原系统是彻底的"无状态"结构：用户每发一条消息，服务端就直接把它丢给LLM，生成完回复就结束，什么都不留。这种结构有两个致命伤：

第一，上下文缺失导致体验断裂。用户说"那台设备还是不行"，系统根本不知道"那台设备"是哪台，只能反问；用户报修到一半下线，第二天回来又得从头描述。

第二，业务处置无法连续。一个退换货流程需要校验订单、确认库存、生成退回单，但每一步的中间状态都没存，流程走一半就卡死。

拆掉重做之后，我们围绕"会话结构"和"记忆管线"做了两轮改造，下面分别展开。

3.2 会话层改造：session、turn、event三层结构

第一轮的改动是给所有对话建立结构化的会话框架。我们定义了三个基础对象：

• Session（会话）：一次完整的用户交互链路，可以跨多天，比如"用户从报修到完成退款"算一个Session。Session里存了用户ID、开始时间、目标、结束状态。
• Turn（轮次）：用户说一句话加上Agent回一句话，算一个Turn。Turn里存双方的原文、意图识别结果、命中的技能包。
• Event（事件）：Turn里面发生的关键业务动作，比如"创建工单""查询库存""发送退款通知"，每个Event带时间戳和结果状态。

这套结构的价值在于：任何时刻你都能回答"用户现在进行到哪一步了"。系统重启、服务迁移、Session切换，都不会丢状态。

# 三层结构示意 class Session: id: str user_id: str goal: str | None created_at: datetime status: str # active / closed / expired class Turn: id: str session_id: str user_msg: str agent_msg: str intent: str skill_hit: str | None created_at: datetime class Event: id: str turn_id: str action: str # 如 create_work_order params: dict result: dict status: str created_at: datetime

3.3 记忆写入管线：什么时候沉淀、什么时候忽略

有了上面的事件结构，"记忆写入"这条管线才真正跑得起来。我们把记忆写入拆成四个步骤：

第一步：抽取候选记忆。每一轮Turn结束后，由一个专门的抽取模块判断该轮是否有值得记录的信息。判断依据是三类信号：命名实体（设备型号、订单号、人名）、意图标签（报修、投诉、退款）、以及情绪信号（强烈不满或高度满意）。

第二步：去重与冲突检测。候选记忆要先和已有的语义记忆比对。比如用户第一次说"我在上海"，半小时后说"我在北京出差"，那"所在地"这条记忆不应该被覆盖成北京，而应该补一个"出差地点"字段。这一层的处理非常关键，否则用户的画像会被单次随口说的话污染。

第三步：重要性打分。我们给每条候选记忆打一个0到1的重要性分，综合来源可信度（用户主动陈述比分三方的减分项得分高）、时间相关性和业务影响。低于0.6分的直接丢弃，高分的写入长期记忆。

第四步：异步落库。记忆写入不能阻塞对话主链路，全部走异步任务，写入完成后再更新记忆索引。我在这块踩过很痛的坑，当时同步写库导致对话响应延迟从400ms飙到1.2秒，用户直接骂街。

# 记忆写入管线伪代码 async def process_turn_memory(turn): candidates = extract_memory_candidates(turn) for cand in candidates: if exists_similar(cand): merge_or_upsert(cand) # 冲突处理 continue score = importance_score(cand) if score >= 0.6: await async_write_longterm_memory(cand) await update_memory_index()

3.4 记忆读取管线：上下文组装与Token预算

写入只是第一步，真正决定用户体验的是"读取"——到底哪些记忆该在什么时机被放进LLM的上下文里。

我们的读取管线是三层组装策略：

第一层：固定上下文（系统指令 + 用户画像）。用户ID一旦确定，就把语义记忆里的用户核心画像（姓名、等级、常用设备）拼进系统指令，全程不换。这部分优先级最高，Token预算大概占总预算的20%。

第二层：情景检索（相关历史对话）。根据当前用户输入向量化后，在历史对话记忆库里检索Top-K条最相关记录。这里的K不是固定的，我们按当前对话复杂度动态调整，简单问题K=3，复杂问题K=8。预算大概占总预算的40%。

第三层：工作记忆（当前会话动态信息）。就是本Session内前面几轮的对话原文或摘要。我们用一个可滚动窗口，只保留最近5到8轮原文，更早的对话滚动压成摘要。预算大概占总预算的30%。

这样三层组装出来的上下文，既有稳定画像，又有相关回忆，还有连续性，比单纯地把所有历史对话堆进去要干净得多，也省Token得多。

4. 记忆检索与冲突消解：多轮对话的智商分水岭

4.1 检索质量的三根支柱：相关性、时效性、可信度

很多人以为记忆检索就是"向量相似度"，哪条历史对话和当前输入向量距离最近就召回哪条。真实跑上线不到两周你就会发现，这种检索方式会给你召回一大堆"看起来有关但实际没用"的记忆。

我总结下来，合格的记忆检索必须同时考核三个维度：

• 相关性：和历史对话的语义匹配度，这个靠向量模型。
• 时效性：新记忆权重高于旧记忆，需要时间衰减因子干预排序。
• 可信度：用户陈述的原始信息比模型推断的信息更可信，主动确认的信息比自动抽取的信息更可信。

三条混在一起排序之后，召回的命中率才谈得上"可用"。

4.2 混合检索加重排：BM25加向量加时间衰减的搭配

具体实现上，我用的不是单一的向量检索，而是混合检索加重新排序的架构：

• 第一路：向量检索。使用对话Embedding模型把历史记忆和当前问题都向量化，做Top-50粗召回。
• 第二路：关键词检索。用BM25做关键词匹配，特别适合设备型号、工单号、城市名这类强标识信息。向量模型对"X200-07"这种字符串的理解很弱，但BM25一抓一个准。
• 第三路：时间衰减融合。两路召回结果合并后，每条记忆除以一个时间衰减系数。

合并之后的Top-20候选，再用一个Cross-Encoder重排序模型精排，取Top-K进上下文。整条链路在高并发下依然能保持70到120毫秒的检索延迟。

注意：Cross-Encoder重排模型是小模型，不能和大模型混淆。我当时直接用大模型做重排，一次请求多等了一两秒，还烧Token，完全不划算。后来换成一个8亿参数的Cross-Encoder，单条打分耗时5毫秒，效果差了不到两个点。

4.3 记忆冲突消解与事实校验

多轮对话里最隐蔽的坑是记忆冲突。用户周一在长沙说"设备安装在长沙园区"，周三在武汉问"长沙那台设备能调过来吗"，如果记忆系统把用户最新位置覆盖掉，就会出现"定位在武汉但设备记录还在长沙"的矛盾。

我们处理冲突的方式是：不覆盖，做版本化。每条记忆保留一个属性时间线，比如用户的"所在地"是一个时间线数组，每个时间点记录对应的值。检索的时候优先取最新值，但如果当前问题涉及的是过去某个时间点的业务，就取当时的值。

这套时间线模型在工程上比"一张画像表"复杂不少，但真实业务场景里几乎每天都有这种冲突。如果你正在做多轮记忆改造，我强烈建议从一开始就按时间线建模，后面省下的补丁代码不是一点半点。

5. 多轮记忆改造中翻过的车与填过的坑

5.1 记忆污染：用户随口一句话毁了画像

第一版上线后我们收到最多的问题反馈是："为什么用户没买过的东西被Agent说成买过？"排查后发现问题出在记忆写入的抽取环节。用户说"我考虑看看你们那个新款"，抽取模块把它当成购买意图，写入语义记忆"用户想购买新款"；第二天用户又说"算了太贵了"，模型又写入"用户放弃购买"。两条矛盾记忆同时存在，Agent在回复里一会儿推荐新款，一会儿推荐旧款。

这个案例给我的教训非常直接：意图类信息不能被当成事实记忆去存。后来的规则是，只有"明确发生的行为"才入语义记忆，一切"意向、猜测、情绪"只能留在情景记忆里供参考，不能作为决策依据。业务上我们把这条规则叫做"事实前置校验"。

5.2 上下文无限膨胀与Token失控

改造初期我们架了一版"无限记忆"的上下文——把所有历史对话全文拼进Prompt。结果不用我说你也知道，Token账单一个月翻了四倍，模型输出质量反而下降。原因是上下文越长，注意力分布越稀疏，模型对关键信息的敏感度反而降低。

之后我们做了三层治理：第一，历史滚动窗口只保留最近8轮原文；第二，更早的对话由摘要模型生成压缩摘要，而不是堆原文；第三，严格控制进上下文的检索记忆数量，最多不超过10条。做完这三步，单次请求的平均Token消耗下降了58%，响应延迟也明显改善。

5.3 召回疲劳：记忆太多反而让Agent变"蠢"

还有一个有意思的坑：记忆召回太多，Agent会变成"话题复读机"。用户明明在问新功能，Agent非要扯上三个月前的旧维修记录。因为检索系统太勤快，把跟"设备"沾边的记忆全部召回，模型就容易抓着旧信息不放。

解决方案是给召回加一道"场景门槛"，只有当前意图和候选记忆的意图标签匹配时，该记忆才能进入最终上下文。比如当前意图是"功能咨询"，那"维修记录"类记忆即使相似度高也不召回；当前意图是"售后排障"，维修记录才会放行。这一步加完之后，用户的"答非所问"投诉率明显下降。

5.4 并发会话与记忆锁的坑

当同一个用户同时开着两个会话窗口时，两个会话都要写入和读取同一份用户记忆，就可能出现脏写：一个会话把用户所在地改成广州，另一个会话读的是旧数据，回了跟广州冲突的回答。

我们最后用"用户ID级别的分布式锁"解决写入冲突，同一个用户ID的写操作串行化；读操作走乐观并发控制，用版本号校验。虽然牺牲了一点点并发度，但换来的是记忆一致性，这在对话场景里是值得的。

6. 记忆框架选型与改造后的效果评估

6.1 主流方案盘点：Mem0、LangMem、MemoryScope与自研

做Memory体系之前，我们对比了当前主流的记忆开源方案，各有适用的语境：

6.2 评估指标：多轮一致性、回忆命中率、响应延迟

改造完成后，我们建了一套面向记忆能力的评估体系，核心看三个指标：

• 多轮一致性：构造一个横跨10轮以上的测试对话，检查Agent回答是否和之前的对话事实一致。比如第1轮告诉它"设备在苏州"，第8轮问"设备在哪"，答对才通过。
• 回忆命中率：在历史对话库里随机抽取200条事实，人工构造200个需要引用该事实才能回答的问题，跑Agent看能答对多少。我们改造前只有41%，改造后到了82%。
• 响应延迟与成本：记录单轮对话的平均延迟和Token成本，防止加记忆后性能劣化。改造后端到端P95延迟控制在2秒内，成本比改造前反而低了22%。

6.3 我的选型建议

如果你问我最终建议，我的观点是：在业务还不复杂、记忆量在一两万条以内的时候，直接用Mem0或LangMem快速跑通，别自己造轮子；但如果你和我一样，接手的系统本身业务耦合深、多租户权限复杂、需要深度定制记忆的生命周期管理，那自研记忆层是早晚的事。不管选哪条路，上面讲的记忆分层、读写管线、冲突消解这些设计原则都是通用的，框架只会帮你省掉一部分存储和调度的活，真正的业务逻辑永远要自己掌握。

我们最后保留了一个自研的轻量记忆核心，外面套了向量索引，整体代码量不到五千行。跑了一个月，稳定性、扩展性都验证到了。如果你也在做多轮记忆改造，建议先从最小闭环开始：建好Session结构，加一条写入管线，再接一条读取管线，跑通后再慢慢完善衰减和冲突处理。别想着一口气把所有能力都做满，记忆系统是典型的"增量迭代"工程——每次只加一个可靠环节，比一次堆一堆半成品靠谱得多。