把标题这句话拆开看它其实浓缩了我去年搭企业技术支持 Agent 时的完整心路历程。基础版本把 RAG 接进去之后问答已经能跑通但每个用户问出来的答案高度雷同敏感资料不敢放多轮对话也经常断片。后来把 Token 体系接进来Agent 才真正开始“变聪明”它知道你是谁、能看什么、上次聊到哪回答质量完全换了一个档位。这篇文章我会把项目从零到一的完整过程拉一遍重点拆解三件事Token 体系怎么设计和排障、RAG 知识库怎么建设才能真正用起来、Agent 怎么在并发场景下扛住生产流量。适合正在做企业知识问答助手、内部技术支持机器人或者想把自己手头“能跑的 Demo”升级成“能用的系统”的开发和运维同学参考。所有方案都来自真实落地经验不是 PPT 架构。1. 为什么企业技术支持场景需要 RAG Token1.1 技术支持场景的真实痛点做企业技术支持 Agent最难的不是模型选型而是回答的“一致性”和“可用性”。真实场景里员工或客户问得最多的是这几类问题操作类怎么提单、怎么重置密码、某个功能按钮在哪里排障类登录报错、接口 5xx、数据对不上政策类报销额度、假期规则、审批流程产品知识类某版本支持哪些特性、某模块依赖什么服务这些问题有一个共同特点答案往往分散在多个系统里。产品手册在 Wiki历史工单在客服系统常见问题在 FAQ 页面架构说明在内部文档库。用户问一个问题需要翻好几个地方才能拼出完整答案。传统的搜索框和 FAQ 页面解决不了因为语义表达太灵活了同一件事可能有几十种问法。另一个痛点是信息更新太快。技术支持的知识库不是静态的每周都有新发版公告、新工单案例、新的坑。如果靠人工维护“标准答案”维护成本高且永远滞后。RAG 的价值就在这它把检索和生成解耦文档更新后重新切块索引模型不需要重新训练就能回答新问题。但只做“检索 生成”还不够。技术支持的对话高度依赖上下文和身份。同一个问题“普通员工”和“IT 管理员”应该得到不同的答案同一个工单“提单人”和“审批人”能查看的信息也不同。如果没有身份层Agent 就只能做一个“没有记忆、没有边界”的百科全书这在企业内网是不可接受的。1.2 “没 Token 能用”和“有 Token 更聪明”到底指什么标题这句话其实触及了企业级 Agent 的两个层级。“没 Token 能用”指的是最基础的 RAG 问答链路用户发起提问 → 检索知识库 → 拼接 Prompt → 模型生成。这个链路确实能跑通我一开始就是先做的这个版本。问题在于它把每个请求都当成孤立的匿名请求用户身份、历史会话、权限范围全部丢失。“有 Token 更聪明”则是把身份令牌Token接入到 Agent 的每个环节里让 Agent 具备四个能力身份识别知道提问者是内部员工还是外部客户属于哪个部门什么角色权限过滤检索结果在进入 Prompt 之前先按用户的权限范围过滤没有权限的文档直接不召回上下文连续通过 Token 关联会话 ID把多轮对话、历史工单、上一次的回答都带进当前请求审计与用量每一次提问都对应到具体用户可以统计 Token 用量、做限流、留审计日志需要说明的是里外里其实有“两个 Token”需要区分。一个是身份令牌JWT 这类鉴权凭证另一个是大模型调用的 Token 用量。标题里“没 Token 能用”的 Token 主要指身份令牌但“有 Token 更聪明”里的 Token 也可以理解成大模型上下文窗口的合理使用——把身份信息、权限信息、历史会话都打包进 Prompt模型自然能给出更贴合场景的回答。企业技术支持 Agent 的关键就是把这两个 Token 体系打通让鉴权身份直接决定上下文范围。2. Token 体系设计与实现从登录到续签2.1 为什么选 JWT 而不是 Session这个项目最开始有同事建议用 Session 方案理由是简单。我的看法是Session 在单体应用里确实简单但技术支持 Agent 注定要独立部署、水平扩展、被多个客户端Web 管理后台、IM 机器人、工单系统同时调用这时候 Session 的劣势会很突出。我把两个方案的对比整理成一张表对比项SessionJWT状态存储服务端内存或 Redis客户端持有服务端无状态横向扩容需要集中式 Session 存储任何实例都能直接校验多客户端复用需要共享 Session 存储Token 天然自包含过期处理服务端统一清理依赖 exp 声明和刷新机制权限变更可实时失效需配合黑名单或版本号最终选了 JWT核心原因是无状态。Agent 服务可以随便扩缩容不需要引入额外的 Session 同步机制。JWT 本身包含用户 ID、角色、租户、过期时间网关解析后就能拿到足够信息不用每次都查数据库。要提醒的是JWT 选型时的一个大坑是密钥管理。我在项目里专门搞了一个密钥管理方案定期轮换 JWT 签名密钥同时在网关层缓存了公钥避免每次请求都去认证中心拉密钥导致性能下降。2.2 access token refresh token 双令牌方案光有 JWT 还不够生产环境必须用双令牌短期 access token 长期 refresh token。为什么如果只有一个长期 Token一旦泄露攻击者可以用很久如果只有一个短期 Token用户体验极差每十分钟就要重新登录一次。我采用的是标准双令牌流程用户登录成功后认证中心签发一对 Tokenaccess token有效期 15 分钟和 refresh token有效期 7 天客户端请求时在 Authorization 头携带 access tokenAgent 网关校验 access token 签名和过期时间通过后放行access token 过期后网关返回 401客户端收到后用 refresh token 调用刷新接口刷新接口校验 refresh token 合法后签发新的 access token同时轮换 refresh token返回新的 refresh token旧的立即失效这里有几个容易被忽略的细节refresh token 一定要做轮换否则旧 token 可以无限期续命用户登出或修改密码后要把对应的 refresh token 加入黑名单或做版本号自增刷新接口要做设备绑定同一个令牌不能同时在两个设备上使用具体看业务安全性要求高可以做这套流程跑通之后用户基本感受不到 Token 过期Agent 还能拿到最新的用户权限信息比如员工角色刚变了下一次刷新后立刻生效。2.3 Token 过期、续签和常见参数配置JWT 里最核心的三个时间参数是iat签发时间exp过期时间nbf生效时间我们项目里踩过一个坑网关服务器时间比认证中心快了半分钟导致刚签发的 Token 被判定为过期。后来统一接了 NTP 时钟同步并在校验时加了 30 秒的时钟偏移容忍问题才解决。另一个经验是不要只看exp字段。Token“失效”的原因很多失效原因排查方向过期exp 到达走 refresh 流程尚未生效nbf 在未来检查签发时间与服务器时钟签名密钥轮换确认网关是否缓存了旧公钥用户被登出/权限变更检查 refresh token 黑名单或版本号租户或 scope 不匹配检查 JWT claims 中的租户 ID为了排查方便我每个 JWT 都带了jti唯一 ID并在网关日志里记录了每个请求的 jti、用户 ID、校验结果。这样用户投诉“我明明登录了怎么又失效”时能把日志拉出来看一眼。3. RAG 知识库建设让 Agent 真正“有据可查”3.1 知识底座选型FAQ 库、文档库、结构化库、知识图谱的区别RAG 不是银弹也不是所有知识都适合丢进向量数据库。我在项目里花了很大精力做知识分类总结下来四类底座各有用武之地知识类型适合场景实现方式成本FAQ / 结构化问答高频、答案确定、变化少关键词匹配 规则兜底低非结构化文档产品手册、公告、历史工单向量检索 关键词检索中结构化数据库订单、库存、设备配置、人员信息Agent 调用 SQL/API 实时查询中高知识图谱实体关系复杂、需要多跳推理本体建模 图查询高初期最容易犯的错误是什么都想做 RAG。我有段时间把 SQL 数据直接灌进向量库检索效果很差因为“订单号 WO-2025-001”这种精确值不是靠语义能搜出来的该让 Agent 去调 HTTP API 或查数据库。后来定了原则明确的、格式化的数据走接口查询非结构化的文本知识才走 RAG。知识图谱我没铺开做但技术调研发现对于“产品 A 依赖模块 B模块 B 升级会影响哪些客户”这类问题纯向量检索完全招架不住本体约束ontology能显著提升召回准确性。如果团队资源够建议用 KG 处理核心的实体关系场景。3.2 文档切分与向量化整本手册不能直接扔进 Embedding做过 RAG 的人都知道切分策略几乎决定了检索效果的 70%。我最初直接把整本产品手册当一个 chunk 去向量化结果检索回来的内容又长又杂模型根本没法学到重点。我们最终沉淀出一套切分规范单块控制在 1000~2000 字左右太短语义不完整太长检索噪声太大相邻块设 100~200 字的重叠overlap防止关键信息被拦腰截断优先按照文档的标题层级切分而不是按固定字数保证每块是一个语义完整的小节每块保留元数据来源、版本号、适用产品、目标用户、更新日期元数据特别重要。技术支持场景里经常有版本差异同一操作步骤在 V2.1 和 V3.0 里不一样。如果不按版本过滤检索结果会混在一起Agent 就会一本正经地给出错误答案。我做了两件事第一文档入库时强制填写版本元数据第二检索时先从用户 Token 或对话上下文中判断当前的产品版本作为过滤条件传入。3.3 混合检索与重排序为什么单用向量检索会翻车向量检索擅长理解“意图”但对精确值无能为力。我测试时遇到过很典型的情况用户问“帮我查一下工单 WO-2025-001 的处理进度”向量检索会给出一堆工单相关的通用流程文档而不是这张工单的具体信息。因为“WO-2025-001”这个字符串在向量空间里几乎没有语义特征。解决方案是混合检索向量检索 关键词BM25检索双路召回再做融合排序。我用的融合策略是 RRFReciprocal Rank Fusion简单有效不用训练模型。下面是我验证过的基础版混合检索流程# 伪代码混合检索 RRF 重排 def hybrid_search(query_text, top_k10): vector_hits vector_store.search(query_text, top_k) keyword_hits bm25_index.search(query_text, top_k) scores {} for rank, hit in enumerate(vector_hits): scores[hit.id] scores.get(hit.id, 0) 1 / (60 rank) for rank, hit in enumerate(keyword_hits): scores[hit.id] scores.get(hit.id, 0) 1 / (60 rank) return sorted(scores.items(), keylambda x: x[1], reverseTrue)[:top_k]RRF 的好处是鲁棒不依赖两路召回的顺序但精度到不了顶尖水平。对检索排序要求更高的场景可以直接上 cross-encoder 重排模型效果明显更好只是耗时和成本会涨。企业技术支持场景里这条路值得走因为交互式问答的检索量不大重排的代价完全可以接受。3.4 知识库能存图片吗多模态资料的处理经验很多人问“RAG 知识库能存图片吗”真实答案是不是把图片塞进向量库而是把图片变成“可检索的信息”。企业技术支持场景里图片信息量极大。用户最喜欢发截图蓝屏、报错弹窗、接口异常堆栈、配置页面。这些截图里的文字比用户复述的“我这边报错了”准确得多不利用就太可惜了。我分两种方式处理图片图片作为知识库资料上传到对象存储用 OCR 把图片里的文字抽出来连同图片地址一起进入元数据。检索时命中文字片段回答时把原图返回给用户。用户看到“你看这张截图”比纯文字说明直观得多。用户上传图片作为输入用多模态模型把截图转成结构化文本识别报错信息、界面关键字再拿这段文本去走 RAG 检索。实测下来对“重装系统后登录失败”“某个按钮不存在”这类问题准确率比单纯让用户描述高好几个档次。如果团队暂时没有多模态模型退而求其次可以用通用的 OCR 服务先顶上核心是不要只存图不提取信息否则知识库里的图片永远搜不到。4. Agent 设计与并发实践从“问答机”到“能干活的助手”4.1 Agent 框架选型别一上来就上重型编排这个项目里我最想分享的教训是Agent 框架不要迷信“越重越好”。我们最开始调研了各种 Agent 编排框架有的支持 ReAct 循环、工具调用、Plan-and-Execute功能很全。但实际场景里80% 的技术支持问题根本不需要复杂的工具调用链只需要“检索知识 → 生成回答 → 附上来源”这个线性流程。我最终采用了轻量方案知识问答核心用 LangChain4j 的 Easy RAG 起步快速验证效果同时预留了工具调用接口等真正需要查工单、重置密码时再接上 ReAct 循环。Spring 系的团队选 LangChain4j 很顺手如果你用的是 Python 技术栈LangChain 或 LlamaIndex 都行。判断要不要上完整 Agent 编排有一个标准看你的任务是不是“需要调用多个工具且工具间有依赖”。比如“先查用户权限 → 再查工单 → 根据结果生成操作建议”就属于这种值得做 ReAct。反过来“查一下说明书里怎么配置”这种做一个 RAG 查询接口就够了别自己给自己加复杂度。4.2 让 Agent 感知 Token把用户身份注入 Prompt 与工具权限Token 在 Agent 里不只是用来做“登录校验”更关键的是把身份信息变成模型可见的上下文。我在 Prompt 里放了一段固定的身份块你是企业内部技术支持助手面向公司员工提供产品使用与故障排查帮助。 当前用户信息 - 用户名{user_name} - 角色{role} - 部门{department} - 当前产品范围{product_scope} - 上下文关联工单{order_id} 请基于以上身份信息回答问题不要返回超出用户权限范围的内容。这段信息从哪里来就是从 JWT 解析出的 claims加上一次轻量用户服务查询拼出来的。效果非常明显普通员工问“怎么申请权限”Agent 会引导他走审批流程管理员问同样的问题Agent 会直接给他管理端配置步骤。“有 Token 更聪明”的另一个落地点是工具权限。Agent 后续接入了“查询工单”工具调用时会把当前用户的 user_id 透传给下游 API。这样即使有人故意构造 Prompt 让 Agent 查别人的工单下游接口也会基于透传身份做校验从权限模型上切断越权风险。总结一句话Token 决定的不是“能不能回答问题”而是“能回答到什么程度”。4.3 并发高峰AI Agent 怎么扛住突增流量企业技术支持 Agent 的并发量不算高但会突然爆发。典型场景是早上 10 点全员登录遇到故障几百人同时来问或者月底报销政策更新短时间内涌入大量咨询。扛不住的表现就是接口超时、模型调用排队、用户等很久没回复。我做的几个关键优化无状态化部署Agent 服务本身不存任何会话状态会话上下文放在 Redis按会话 ID 读取。这样服务可以随便扩副本。热点问题缓存高频问题比如“怎么登录”“密码怎么改”提前把完整回答缓存起来命中后直接返回不走 LLM成本几乎为零。大模型调用池化模型服务端有并发限制客户端做了连接池和排队避免突发流量全部打爆。限流与熔断对单个用户限流比如每分钟 5 次提问超出后返回排队提示保护下游模型服务和知识库。另外一个容易被忽略的点是超时与重试。模型生成慢的时候用户会反复点按钮造成请求叠加。我的做法是前端做了幂等标识同一个问题 30 秒内重复提交直接返回上一次请求的结果或排队状态杜绝重复消费。5. Token 与 RAG 联动的常见问题排查实录5.1 Token 报错速查表从登录失败到 refresh_token 为空项目上线后我们接到最多的报错就是各种 Token 相关异常。我把遇到的问题整理成了一张速查表基本覆盖了大部分现场报错信息含义排查方向sign-in could not be completed token exchange failed: error sending request客户端向认证中心换 Token 时网络不通或上游不可用检查认证中心健康状态、网关路由、client 配置的 token_endpoint 地址token exchange failed: token endpoint returned status 403 forbidden认证中心拒绝了换 Token 请求检查 client_id / scope / 租户配置看认证中心风控日志确认请求头是否带了完整参数failed to refresh token: 400 bad request: invalid refresh_token: empty string刷新时 refresh token 为空查前端存储refresh token 是否被清掉、请求体字段名是否传错your access token could not be refreshed because you have since logged outrefresh token 已被登出操作撤销用户需要重新登录前端要清理本地残留 tokenyour access token could not be refreshed. please log out and sign in again.refresh token 已失效或轮换过与上一条类似按业务提示用户重新登录这里面有一条值得单独说refresh token 为空看起来是后端报错根因往往在前端。常见原因有两个一是刷新 token 存在 localStorage 里但换了域名后被清空二是刷新接口要求的参数名是refresh_token前端传了refreshToken后端拿到空值。把字段名对齐再把前端 token 存储方案从 localStorage 改成 HttpOnly Cookie或至少做持久化兜底问题就能避免。5.2 RAG 检索质量瓶颈与调优回答不对别急着怪模型项目上线后用户反馈最多的问题是“回答不对、答非所问、说了一堆废话”。多数时候不是模型的问题而是检索质量没做够。我总结了五类高频问题和对应策略现象常见原因调优策略召回为空或极少切块过大导致语义稀释或查询词太抽象缩小 chunk增加 query 改写补充同义词典召回了但排序不对只用了向量检索精确匹配能力弱上混合检索BM25 向量答案看着对但出处可疑没有重排模型被低质量 chunk 带偏加 reranker或提高元数据过滤强度版本/角色信息不对检索结果混入多个版本内容用 Token 身份信息做预过滤强制版本字段回答太长、没有重点Prompt 没做约束模型自由发挥Prompt 中明确“先给结论再给步骤不超过 200 字”最典型的优化案例是版本过滤。我们初期没做版本过滤用户问“V2.1 怎么配置”检索结果混进了 V3.0 的文档答案完全不对。后来在元数据过滤条件里把版本设成必填再配合 ask 改写把“新版”映射到具体版本号准确率直线上升。5.3 我整理的一份“避坑经验清单”最后把所有踩过的坑浓缩一下给后来者直接参考先做无 Token 的 RAG 基线再往上加身份感知。不要第一天就搞权限过滤否则系统会变得极难排错。JWT 的密钥要独立管理定期轮换网关和认证中心的时钟必须用 NTP 对齐否则“刚签发就过期”的奇事天天有。知识库一定保留元数据来源、版本、适用对象缺一不可这是检索过滤的基石。图片资料单独走 OCR 或多模态链路不要直接放弃也不要盲目把原图灌进向量库。并发控制要“限流 缓存 幂等”三件套一起上单靠扩机器解决不了 LLM 调用侧的资源瓶颈。线上问题排查时用请求 ID 串起全网日志前端 request_id → 网关 jti → 模型调用 trace没有这个链路出问题只能靠猜。写在最后这个项目做到后面我最深的体会是企业级 Agent 的难点从来不在“跑通一个Demo”而在“让系统在真实组织环境里长期稳定地运行”。我在实际调试中反复确认了一个观点——Token 体系不是锦上添花的安全组件而是让 RAG 从“能用”变“更聪明”的杠杆。身份信息一旦注入检索过滤、Prompt 上下文、工具权限这三个关键环节回答质量、合规边界、审计能力都会同步上一个台阶。如果后面继续扩展我认为第一个值得做的方向是完善多模态链路截图识别 图片结果返回第二个是给 Agent 接入会话记忆的自动压缩让长对话不丢失关键上下文。工具调用和知识检索的组合可以做深度一点但前提是先把基础链路做稳定别一上来就铺太大。还是那句话先把“没 Token 能用”的基线打到 80 分再让 Token 帮它突破 90 分。 企业技术支持Agent实战：RAG与Token体系协同提效
把标题这句话拆开看它其实浓缩了我去年搭企业技术支持 Agent 时的完整心路历程。基础版本把 RAG 接进去之后问答已经能跑通但每个用户问出来的答案高度雷同敏感资料不敢放多轮对话也经常断片。后来把 Token 体系接进来Agent 才真正开始“变聪明”它知道你是谁、能看什么、上次聊到哪回答质量完全换了一个档位。这篇文章我会把项目从零到一的完整过程拉一遍重点拆解三件事Token 体系怎么设计和排障、RAG 知识库怎么建设才能真正用起来、Agent 怎么在并发场景下扛住生产流量。适合正在做企业知识问答助手、内部技术支持机器人或者想把自己手头“能跑的 Demo”升级成“能用的系统”的开发和运维同学参考。所有方案都来自真实落地经验不是 PPT 架构。1. 为什么企业技术支持场景需要 RAG Token1.1 技术支持场景的真实痛点做企业技术支持 Agent最难的不是模型选型而是回答的“一致性”和“可用性”。真实场景里员工或客户问得最多的是这几类问题操作类怎么提单、怎么重置密码、某个功能按钮在哪里排障类登录报错、接口 5xx、数据对不上政策类报销额度、假期规则、审批流程产品知识类某版本支持哪些特性、某模块依赖什么服务这些问题有一个共同特点答案往往分散在多个系统里。产品手册在 Wiki历史工单在客服系统常见问题在 FAQ 页面架构说明在内部文档库。用户问一个问题需要翻好几个地方才能拼出完整答案。传统的搜索框和 FAQ 页面解决不了因为语义表达太灵活了同一件事可能有几十种问法。另一个痛点是信息更新太快。技术支持的知识库不是静态的每周都有新发版公告、新工单案例、新的坑。如果靠人工维护“标准答案”维护成本高且永远滞后。RAG 的价值就在这它把检索和生成解耦文档更新后重新切块索引模型不需要重新训练就能回答新问题。但只做“检索 生成”还不够。技术支持的对话高度依赖上下文和身份。同一个问题“普通员工”和“IT 管理员”应该得到不同的答案同一个工单“提单人”和“审批人”能查看的信息也不同。如果没有身份层Agent 就只能做一个“没有记忆、没有边界”的百科全书这在企业内网是不可接受的。1.2 “没 Token 能用”和“有 Token 更聪明”到底指什么标题这句话其实触及了企业级 Agent 的两个层级。“没 Token 能用”指的是最基础的 RAG 问答链路用户发起提问 → 检索知识库 → 拼接 Prompt → 模型生成。这个链路确实能跑通我一开始就是先做的这个版本。问题在于它把每个请求都当成孤立的匿名请求用户身份、历史会话、权限范围全部丢失。“有 Token 更聪明”则是把身份令牌Token接入到 Agent 的每个环节里让 Agent 具备四个能力身份识别知道提问者是内部员工还是外部客户属于哪个部门什么角色权限过滤检索结果在进入 Prompt 之前先按用户的权限范围过滤没有权限的文档直接不召回上下文连续通过 Token 关联会话 ID把多轮对话、历史工单、上一次的回答都带进当前请求审计与用量每一次提问都对应到具体用户可以统计 Token 用量、做限流、留审计日志需要说明的是里外里其实有“两个 Token”需要区分。一个是身份令牌JWT 这类鉴权凭证另一个是大模型调用的 Token 用量。标题里“没 Token 能用”的 Token 主要指身份令牌但“有 Token 更聪明”里的 Token 也可以理解成大模型上下文窗口的合理使用——把身份信息、权限信息、历史会话都打包进 Prompt模型自然能给出更贴合场景的回答。企业技术支持 Agent 的关键就是把这两个 Token 体系打通让鉴权身份直接决定上下文范围。2. Token 体系设计与实现从登录到续签2.1 为什么选 JWT 而不是 Session这个项目最开始有同事建议用 Session 方案理由是简单。我的看法是Session 在单体应用里确实简单但技术支持 Agent 注定要独立部署、水平扩展、被多个客户端Web 管理后台、IM 机器人、工单系统同时调用这时候 Session 的劣势会很突出。我把两个方案的对比整理成一张表对比项SessionJWT状态存储服务端内存或 Redis客户端持有服务端无状态横向扩容需要集中式 Session 存储任何实例都能直接校验多客户端复用需要共享 Session 存储Token 天然自包含过期处理服务端统一清理依赖 exp 声明和刷新机制权限变更可实时失效需配合黑名单或版本号最终选了 JWT核心原因是无状态。Agent 服务可以随便扩缩容不需要引入额外的 Session 同步机制。JWT 本身包含用户 ID、角色、租户、过期时间网关解析后就能拿到足够信息不用每次都查数据库。要提醒的是JWT 选型时的一个大坑是密钥管理。我在项目里专门搞了一个密钥管理方案定期轮换 JWT 签名密钥同时在网关层缓存了公钥避免每次请求都去认证中心拉密钥导致性能下降。2.2 access token refresh token 双令牌方案光有 JWT 还不够生产环境必须用双令牌短期 access token 长期 refresh token。为什么如果只有一个长期 Token一旦泄露攻击者可以用很久如果只有一个短期 Token用户体验极差每十分钟就要重新登录一次。我采用的是标准双令牌流程用户登录成功后认证中心签发一对 Tokenaccess token有效期 15 分钟和 refresh token有效期 7 天客户端请求时在 Authorization 头携带 access tokenAgent 网关校验 access token 签名和过期时间通过后放行access token 过期后网关返回 401客户端收到后用 refresh token 调用刷新接口刷新接口校验 refresh token 合法后签发新的 access token同时轮换 refresh token返回新的 refresh token旧的立即失效这里有几个容易被忽略的细节refresh token 一定要做轮换否则旧 token 可以无限期续命用户登出或修改密码后要把对应的 refresh token 加入黑名单或做版本号自增刷新接口要做设备绑定同一个令牌不能同时在两个设备上使用具体看业务安全性要求高可以做这套流程跑通之后用户基本感受不到 Token 过期Agent 还能拿到最新的用户权限信息比如员工角色刚变了下一次刷新后立刻生效。2.3 Token 过期、续签和常见参数配置JWT 里最核心的三个时间参数是iat签发时间exp过期时间nbf生效时间我们项目里踩过一个坑网关服务器时间比认证中心快了半分钟导致刚签发的 Token 被判定为过期。后来统一接了 NTP 时钟同步并在校验时加了 30 秒的时钟偏移容忍问题才解决。另一个经验是不要只看exp字段。Token“失效”的原因很多失效原因排查方向过期exp 到达走 refresh 流程尚未生效nbf 在未来检查签发时间与服务器时钟签名密钥轮换确认网关是否缓存了旧公钥用户被登出/权限变更检查 refresh token 黑名单或版本号租户或 scope 不匹配检查 JWT claims 中的租户 ID为了排查方便我每个 JWT 都带了jti唯一 ID并在网关日志里记录了每个请求的 jti、用户 ID、校验结果。这样用户投诉“我明明登录了怎么又失效”时能把日志拉出来看一眼。3. RAG 知识库建设让 Agent 真正“有据可查”3.1 知识底座选型FAQ 库、文档库、结构化库、知识图谱的区别RAG 不是银弹也不是所有知识都适合丢进向量数据库。我在项目里花了很大精力做知识分类总结下来四类底座各有用武之地知识类型适合场景实现方式成本FAQ / 结构化问答高频、答案确定、变化少关键词匹配 规则兜底低非结构化文档产品手册、公告、历史工单向量检索 关键词检索中结构化数据库订单、库存、设备配置、人员信息Agent 调用 SQL/API 实时查询中高知识图谱实体关系复杂、需要多跳推理本体建模 图查询高初期最容易犯的错误是什么都想做 RAG。我有段时间把 SQL 数据直接灌进向量库检索效果很差因为“订单号 WO-2025-001”这种精确值不是靠语义能搜出来的该让 Agent 去调 HTTP API 或查数据库。后来定了原则明确的、格式化的数据走接口查询非结构化的文本知识才走 RAG。知识图谱我没铺开做但技术调研发现对于“产品 A 依赖模块 B模块 B 升级会影响哪些客户”这类问题纯向量检索完全招架不住本体约束ontology能显著提升召回准确性。如果团队资源够建议用 KG 处理核心的实体关系场景。3.2 文档切分与向量化整本手册不能直接扔进 Embedding做过 RAG 的人都知道切分策略几乎决定了检索效果的 70%。我最初直接把整本产品手册当一个 chunk 去向量化结果检索回来的内容又长又杂模型根本没法学到重点。我们最终沉淀出一套切分规范单块控制在 1000~2000 字左右太短语义不完整太长检索噪声太大相邻块设 100~200 字的重叠overlap防止关键信息被拦腰截断优先按照文档的标题层级切分而不是按固定字数保证每块是一个语义完整的小节每块保留元数据来源、版本号、适用产品、目标用户、更新日期元数据特别重要。技术支持场景里经常有版本差异同一操作步骤在 V2.1 和 V3.0 里不一样。如果不按版本过滤检索结果会混在一起Agent 就会一本正经地给出错误答案。我做了两件事第一文档入库时强制填写版本元数据第二检索时先从用户 Token 或对话上下文中判断当前的产品版本作为过滤条件传入。3.3 混合检索与重排序为什么单用向量检索会翻车向量检索擅长理解“意图”但对精确值无能为力。我测试时遇到过很典型的情况用户问“帮我查一下工单 WO-2025-001 的处理进度”向量检索会给出一堆工单相关的通用流程文档而不是这张工单的具体信息。因为“WO-2025-001”这个字符串在向量空间里几乎没有语义特征。解决方案是混合检索向量检索 关键词BM25检索双路召回再做融合排序。我用的融合策略是 RRFReciprocal Rank Fusion简单有效不用训练模型。下面是我验证过的基础版混合检索流程# 伪代码混合检索 RRF 重排 def hybrid_search(query_text, top_k10): vector_hits vector_store.search(query_text, top_k) keyword_hits bm25_index.search(query_text, top_k) scores {} for rank, hit in enumerate(vector_hits): scores[hit.id] scores.get(hit.id, 0) 1 / (60 rank) for rank, hit in enumerate(keyword_hits): scores[hit.id] scores.get(hit.id, 0) 1 / (60 rank) return sorted(scores.items(), keylambda x: x[1], reverseTrue)[:top_k]RRF 的好处是鲁棒不依赖两路召回的顺序但精度到不了顶尖水平。对检索排序要求更高的场景可以直接上 cross-encoder 重排模型效果明显更好只是耗时和成本会涨。企业技术支持场景里这条路值得走因为交互式问答的检索量不大重排的代价完全可以接受。3.4 知识库能存图片吗多模态资料的处理经验很多人问“RAG 知识库能存图片吗”真实答案是不是把图片塞进向量库而是把图片变成“可检索的信息”。企业技术支持场景里图片信息量极大。用户最喜欢发截图蓝屏、报错弹窗、接口异常堆栈、配置页面。这些截图里的文字比用户复述的“我这边报错了”准确得多不利用就太可惜了。我分两种方式处理图片图片作为知识库资料上传到对象存储用 OCR 把图片里的文字抽出来连同图片地址一起进入元数据。检索时命中文字片段回答时把原图返回给用户。用户看到“你看这张截图”比纯文字说明直观得多。用户上传图片作为输入用多模态模型把截图转成结构化文本识别报错信息、界面关键字再拿这段文本去走 RAG 检索。实测下来对“重装系统后登录失败”“某个按钮不存在”这类问题准确率比单纯让用户描述高好几个档次。如果团队暂时没有多模态模型退而求其次可以用通用的 OCR 服务先顶上核心是不要只存图不提取信息否则知识库里的图片永远搜不到。4. Agent 设计与并发实践从“问答机”到“能干活的助手”4.1 Agent 框架选型别一上来就上重型编排这个项目里我最想分享的教训是Agent 框架不要迷信“越重越好”。我们最开始调研了各种 Agent 编排框架有的支持 ReAct 循环、工具调用、Plan-and-Execute功能很全。但实际场景里80% 的技术支持问题根本不需要复杂的工具调用链只需要“检索知识 → 生成回答 → 附上来源”这个线性流程。我最终采用了轻量方案知识问答核心用 LangChain4j 的 Easy RAG 起步快速验证效果同时预留了工具调用接口等真正需要查工单、重置密码时再接上 ReAct 循环。Spring 系的团队选 LangChain4j 很顺手如果你用的是 Python 技术栈LangChain 或 LlamaIndex 都行。判断要不要上完整 Agent 编排有一个标准看你的任务是不是“需要调用多个工具且工具间有依赖”。比如“先查用户权限 → 再查工单 → 根据结果生成操作建议”就属于这种值得做 ReAct。反过来“查一下说明书里怎么配置”这种做一个 RAG 查询接口就够了别自己给自己加复杂度。4.2 让 Agent 感知 Token把用户身份注入 Prompt 与工具权限Token 在 Agent 里不只是用来做“登录校验”更关键的是把身份信息变成模型可见的上下文。我在 Prompt 里放了一段固定的身份块你是企业内部技术支持助手面向公司员工提供产品使用与故障排查帮助。 当前用户信息 - 用户名{user_name} - 角色{role} - 部门{department} - 当前产品范围{product_scope} - 上下文关联工单{order_id} 请基于以上身份信息回答问题不要返回超出用户权限范围的内容。这段信息从哪里来就是从 JWT 解析出的 claims加上一次轻量用户服务查询拼出来的。效果非常明显普通员工问“怎么申请权限”Agent 会引导他走审批流程管理员问同样的问题Agent 会直接给他管理端配置步骤。“有 Token 更聪明”的另一个落地点是工具权限。Agent 后续接入了“查询工单”工具调用时会把当前用户的 user_id 透传给下游 API。这样即使有人故意构造 Prompt 让 Agent 查别人的工单下游接口也会基于透传身份做校验从权限模型上切断越权风险。总结一句话Token 决定的不是“能不能回答问题”而是“能回答到什么程度”。4.3 并发高峰AI Agent 怎么扛住突增流量企业技术支持 Agent 的并发量不算高但会突然爆发。典型场景是早上 10 点全员登录遇到故障几百人同时来问或者月底报销政策更新短时间内涌入大量咨询。扛不住的表现就是接口超时、模型调用排队、用户等很久没回复。我做的几个关键优化无状态化部署Agent 服务本身不存任何会话状态会话上下文放在 Redis按会话 ID 读取。这样服务可以随便扩副本。热点问题缓存高频问题比如“怎么登录”“密码怎么改”提前把完整回答缓存起来命中后直接返回不走 LLM成本几乎为零。大模型调用池化模型服务端有并发限制客户端做了连接池和排队避免突发流量全部打爆。限流与熔断对单个用户限流比如每分钟 5 次提问超出后返回排队提示保护下游模型服务和知识库。另外一个容易被忽略的点是超时与重试。模型生成慢的时候用户会反复点按钮造成请求叠加。我的做法是前端做了幂等标识同一个问题 30 秒内重复提交直接返回上一次请求的结果或排队状态杜绝重复消费。5. Token 与 RAG 联动的常见问题排查实录5.1 Token 报错速查表从登录失败到 refresh_token 为空项目上线后我们接到最多的报错就是各种 Token 相关异常。我把遇到的问题整理成了一张速查表基本覆盖了大部分现场报错信息含义排查方向sign-in could not be completed token exchange failed: error sending request客户端向认证中心换 Token 时网络不通或上游不可用检查认证中心健康状态、网关路由、client 配置的 token_endpoint 地址token exchange failed: token endpoint returned status 403 forbidden认证中心拒绝了换 Token 请求检查 client_id / scope / 租户配置看认证中心风控日志确认请求头是否带了完整参数failed to refresh token: 400 bad request: invalid refresh_token: empty string刷新时 refresh token 为空查前端存储refresh token 是否被清掉、请求体字段名是否传错your access token could not be refreshed because you have since logged outrefresh token 已被登出操作撤销用户需要重新登录前端要清理本地残留 tokenyour access token could not be refreshed. please log out and sign in again.refresh token 已失效或轮换过与上一条类似按业务提示用户重新登录这里面有一条值得单独说refresh token 为空看起来是后端报错根因往往在前端。常见原因有两个一是刷新 token 存在 localStorage 里但换了域名后被清空二是刷新接口要求的参数名是refresh_token前端传了refreshToken后端拿到空值。把字段名对齐再把前端 token 存储方案从 localStorage 改成 HttpOnly Cookie或至少做持久化兜底问题就能避免。5.2 RAG 检索质量瓶颈与调优回答不对别急着怪模型项目上线后用户反馈最多的问题是“回答不对、答非所问、说了一堆废话”。多数时候不是模型的问题而是检索质量没做够。我总结了五类高频问题和对应策略现象常见原因调优策略召回为空或极少切块过大导致语义稀释或查询词太抽象缩小 chunk增加 query 改写补充同义词典召回了但排序不对只用了向量检索精确匹配能力弱上混合检索BM25 向量答案看着对但出处可疑没有重排模型被低质量 chunk 带偏加 reranker或提高元数据过滤强度版本/角色信息不对检索结果混入多个版本内容用 Token 身份信息做预过滤强制版本字段回答太长、没有重点Prompt 没做约束模型自由发挥Prompt 中明确“先给结论再给步骤不超过 200 字”最典型的优化案例是版本过滤。我们初期没做版本过滤用户问“V2.1 怎么配置”检索结果混进了 V3.0 的文档答案完全不对。后来在元数据过滤条件里把版本设成必填再配合 ask 改写把“新版”映射到具体版本号准确率直线上升。5.3 我整理的一份“避坑经验清单”最后把所有踩过的坑浓缩一下给后来者直接参考先做无 Token 的 RAG 基线再往上加身份感知。不要第一天就搞权限过滤否则系统会变得极难排错。JWT 的密钥要独立管理定期轮换网关和认证中心的时钟必须用 NTP 对齐否则“刚签发就过期”的奇事天天有。知识库一定保留元数据来源、版本、适用对象缺一不可这是检索过滤的基石。图片资料单独走 OCR 或多模态链路不要直接放弃也不要盲目把原图灌进向量库。并发控制要“限流 缓存 幂等”三件套一起上单靠扩机器解决不了 LLM 调用侧的资源瓶颈。线上问题排查时用请求 ID 串起全网日志前端 request_id → 网关 jti → 模型调用 trace没有这个链路出问题只能靠猜。写在最后这个项目做到后面我最深的体会是企业级 Agent 的难点从来不在“跑通一个Demo”而在“让系统在真实组织环境里长期稳定地运行”。我在实际调试中反复确认了一个观点——Token 体系不是锦上添花的安全组件而是让 RAG 从“能用”变“更聪明”的杠杆。身份信息一旦注入检索过滤、Prompt 上下文、工具权限这三个关键环节回答质量、合规边界、审计能力都会同步上一个台阶。如果后面继续扩展我认为第一个值得做的方向是完善多模态链路截图识别 图片结果返回第二个是给 Agent 接入会话记忆的自动压缩让长对话不丢失关键上下文。工具调用和知识检索的组合可以做深度一点但前提是先把基础链路做稳定别一上来就铺太大。还是那句话先把“没 Token 能用”的基线打到 80 分再让 Token 帮它突破 90 分。