1. 为什么是“安全浏览器”而不是普通Chrome/Firefox——企业内网的真实约束先说个场景。电网调度员处理一个变电站的越限告警需要在一分钟内翻出《变电站运维规程》对应章节、确认告警处置时限、再看一眼同类型缺陷的历史记录最后把判断结果填进缺陷流程单。传统做法是打开知识库网站搜索、切到生产管理系统翻台账、再打开办公软件写报告三个系统来回切熟练工也要五分钟。整个过程没有一秒钟是“创造性的”但所有人都默认这是工作的一部分。我们最初的想法很朴素能不能在浏览器里放一个AI助手让它在当前页面右侧随时待命把这种“查资料—对照规则—填表单”的重复劳动直接接管。这个想法一旦放到真实的企业环境里第一个问题不是“用什么大模型”而是“这个功能到底该装在哪里”。1.1 “安全”二字意味着什么——终端管控与网络隔离普通用户理解的安全浏览器可能觉得是“不会中毒的浏览器”。但在电网这类企业内部国网安全浏览器代表的是一整套终端安全策略操作系统国产化适配、USB外设管控、软件安装白名单、内外网隔离、上网行为审计每一层都有严格的管控要求。这带来两个直接后果。第一不能指望员工自己打开Chrome商店装一个AI插件因为终端的软件安装权限是收敛的插件的安装和更新也必须走企业内部的软件分发通道。第二业务系统大多只在内网域名下提供服务访问生产系统页面必须通过统一认证网关任何外部大模型的在线API在默认网络策略下根本不可达。所以“基于国网安全浏览器做AI侧边栏”这个题目的隐含约束是在不改变终端安全基线、不破坏网络隔离策略的前提下找到一个能被现有终端环境接纳的AI交互形态。侧边栏恰好满足这个条件——它不是一个需要额外安装的独立软件而是浏览器这一个已被充分管控的进程内部的扩展视图。1.2 选择侧边栏形态的原因——从浏览器扩展到企业集成框架我们评估过三种落地形态。第一种是独立的桌面客户端交互自由度最高但需要重新走终端软件入网审批流程部署周期长而且员工不愿为一个AI助手多装一个常驻程序。第二种是网页版门户把AI对话固化成内网站点技术上最简单但它和员工正在使用的业务系统是割裂的用户必须切走再问AI再切回来操作上下文全丢体验和翻文档差不多。第三种就是浏览器侧边栏。它挂在浏览器主窗体的右侧或左侧与当前页面同屏共存既能保持AI对话的独立面板又能通过浏览器扩展能力读取当前页面信息做到“人看着业务系统AI在旁边待命”。最终我们选择了第三种并且注册为浏览器扩展。技术上它遵循Chromium扩展标准通过Side Panel API或注入式浮动面板实现侧边栏UI再通过content script与主页面做受控通信。整个开发链路完全在原生浏览器安全模型内运行不触碰终端管控边界这也是它能快速通过安全评审的根本原因。2. 侧边栏智能体的整体架构与定位——不是聊天机器人而是工作台把侧边栏做成“能聊天的搜索框”很容易但那不是智能体只是给知识库套了个对话框外壳。我们的定位从一开始就很明确侧边栏智能体是一个驻扎在浏览器里的工作助手它要能感知员工正在做什么、理解业务上下文、调用企业内部工具最终把结果直接送回工作流里。整体架构分为六层客户端层国网安全浏览器扩展负责侧边栏UI、页面上下文捕获、会话状态管理接入层内网API网关统一处理鉴权、限流、审计日志模型服务层私有化部署的大模型推理服务对外提供chat/embedding接口知识层RAG检索服务对接企业内部制度库、规程文档、缺陷台账工具层面向业务系统的Function工具集包括查台账、建工单、调历史记录沉淀层会话记录、结果回写、反馈统计2.1 智能体的核心链路感知—规划—行动—沉淀智能体与普通对话机器人的本质区别在于它有“行动”能力。我们拆出的核心链路是四步。感知扩展侧content script捕获当前页面的URL、页面标题、用户选中文本、当前浏览器标签页列表。这些信息经过脱敏处理后作为上下文拼入系统提示词。规划模型根据用户输入和页面上下文决定本次请求要走“直接回答”“检索知识库”“调用业务工具”还是“组合执行”。这里我们用Function Calling配合意图识别完成规划不依赖复杂的Agent推理框架因为企业内部场景的意图种类其实是有限的。行动如果规划结果是要查缺陷台账模型会构造一个结构化的工具调用请求由扩展侧发起对内网业务系统的API调用返回结果再拼回对话上下文。沉淀每一次问答和工具调用的过程、参数、结果都写入审计日志并对用户可见的结果加“参考来源”标注。这条链路看起来简单但每一步都踩过不少坑。比如“感知”这一步页面URL里经常带工单编号我们一开始直接把它塞进提示词结果模型会在回答里“引用”用户根本没打开过的工单内容后来改成只从URL提取页码参数其余一律丢弃。2.2 为什么采用私有化部署而不是公有云大模型讨论模型选型时团队内部有过一场争论。公有云大模型能力更强、迭代更快RAG效果也更好但有三道坎过不去一是业务数据出域问题制度文档、缺陷台账属于内部敏感信息明文上送公有云在我们这里是明确禁止的二是网络隔离问题生产网段的终端访问不了公共互联网的大模型API三是审计合规问题所有AI交互必须留痕可追溯公有云服务的日志留存策略满足不了内部审计要求。最终我们选择了私有化部署方案。模型本体用的是开源权重的中等规模底座量化到INT8后部署在两张推理卡上通过vLLM提供OpenAI兼容接口。参数规模没有选择最大的版本主要是考虑内网服务器的显存容量和并发上限。实测单卡并发8路请求、首token延迟1.2秒左右在办公场景下是可接受的。这里也给正在选型的同行一个建议如果你们的场景也是“制度问答工具调用”不需要一味追求大参数模型一个70亿到140亿参数级别的开源权重模型配合一个质量不错的RAG管道已经能覆盖绝大部分需求。真正拉高体验上限的往往不是模型本身而是知识库的切分质量和工具返回结果的提示词表达。2.3 与业务系统的桥接从跳转URL到能力开放智能体要“做事”就必须和业务系统打通。最粗暴的打通方式是返回一个URL让用户自己点但这算不上行动只是导航。我们选择了另一条路通过业务系统的只读API开放接口让智能体直接查询数据再通过表单自动填充帮助用户完成低风险的操作闭环。举个例子用户输入“查一下编号GD-2024-0153缺陷的处理状态”智能体直接调用缺陷管理系统的查询接口返回结构化结果并渲染成卡片而不是先跳转再人肉搜索。第一批工具集的开放范围是严格收敛的。我们只开放了查询类接口按编号查台账、按关键词搜规程、按部门查周报模板和几个低风险的创建类操作生成缺陷初稿草稿、创建巡检任务草稿。所有创建类操作默认状态是“草稿”必须经过人工确认后才能流向业务系统避免智能体误操作引发连锁问题。这个取舍在安全评审时帮了大忙评审专家看到“所有写操作都是草稿态、所有读操作都有审计日志”时基本没有提出额外要求。反过来如果一上来就开放自动提交工单的能力大概率会被一票否决。3. 核心功能拆解与实现路径——从制度问答到业务协同再往下说是侧边栏智能体实际落地的那几个功能。我们分了三批推进第一批做制度问答第二批做业务辅助第三批做上下文感知的跨系统联动。每批功能我们都设定了明确的验收标准不和“智能”这个词较劲只看员工单次任务完成时间有没有下降。3.1 制度问答与RAG检索增强让模型“看在内部文档上说话”制度问答是所有企业AI助手的第一站因为制度文档对准确性的要求极高而大模型本身并不忠实于原文必须用检索增强生成RAG约束模型输出。具体实现上我们把《变电站运维规程》《调度操作指令票管理规定》《缺陷管理实施细则》等文档统一解析成Markdown按章节标题做结构切分再通过Embedding模型转成向量存入向量库。检索时先做混合检索——向量相似度召回一批段落关键词匹配召回一批段落合并后按BM25与向量得分加权排序。很多人会在这一步忽略“标题段落匹配”的价值。我们踩过这样一个坑员工问“缺陷消除时限是几天”RAG召回的是《缺陷管理实施细则》里对缺陷等级的定义章节模型照着念了半天就是没说清时限。后来我们给切分块额外加了一个字段——当前段落所属的顶层章节标题并在提示词里要求“回答时必须根据块标题所在章节来组织上下文”。加了这一步回答准确率从78%直接跳到89%。3.2 业务操作的“副驾”工单填写、故障定位、报告初稿制度问答跑通之后团队的信心上来了就开始碰真正硬核的东西让智能体直接参与业务操作。第一个落地场景是缺陷工单填写。之前员工填写缺陷单要手动从台账系统复制设备编号、从规程里翻缺陷分类、再自己写一段现象描述。侧边栏智能体实现的工作流是用户复制设备名称或粘贴一段巡检异常描述智能体自动抽取设备标识、匹配缺陷现象库、推荐缺陷分类并生成一份描述草稿用户确认后自动填充到工单表单。这段流程拆开看并不神奇抽取设备标识靠正则加实体识别匹配缺陷现象库靠向量检索生成描述草稿靠大模型的文本润色能力。但合在一起员工填写一张缺陷单的时间从8分钟压到了1分半。而且因为草稿必须用户确认错误率没有增加这一点让业务部门很放心。第二个场景是故障定位辅助。当用户粘贴一段告警信息或运行日志时智能体自动检索同类型故障的历史处置记录按照“曾经发生—处置步骤—生效时间”的结构生成推荐处置路径。它不直接给结论而是给路径。这个设计是为了防止模型在信息不足时强行归因把“可能原因列表”呈现出来让有经验的运行人员来做最终判断。3.3 上下文感知智能体如何“看懂”当前页面内容侧边栏如果只做一个独立的对话框价值会小一半。让它“看懂”当前页面才能从被动应答变成主动辅助。技术路径是通过浏览器扩展的content script在当前业务系统页面加载后采集三类信息页面URL和标题、页面中用户选中的文本、以及页面表单里当前的填写内容。采集到的信息经过一个本地的脱敏模块处理把手机号、身份证号、具体的工单编号等敏感字段用掩码替换然后才上送模型。脱敏模块是整个上下文感知功能能通过安全评审的关键。我们在一开始就把“页面内容默认不采集、用户主动选中才采集”作为交互原则而不是像某些浏览器插件那样默认抓取全页面DOM。侧边栏顶部有一个常驻开关显示“当前页面关注中”或“当前页面未接入”员工对这个提示的信任度远高于那些默默读取浏览历史的插件。3.4 会话管理与多轮记忆贴近实际工作流的对话设计智能体能不能记住上文直接决定对话体验。我们做的不是把历史消息全塞进窗口这种粗暴做法而是提炼出“业务状态记忆”和“任务清单记忆”两种结构。业务状态记忆记录的是当前会话中用户提到过的关键实体比如“上次提到的设备编号是XX缺陷等级是III级”。任务清单记忆则记录的是对话中产生的待办事项比如用户说了“帮我查三份规程然后生成一份排查提纲”智能体会在侧边栏底部维护一个任务列表每完成一项就打钩。这两类记忆都以JSON结构保存在每次请求时拼入系统提示词。它的好处是可以压缩历史长度不必无限增长上下文窗口同时还能让用户看到智能体“记住了什么”不确定时也能手动删除某条记忆。交互成本低透明度高上线后几乎没有用户抱怨过“忘记前文”的问题。4. 落地过程中踩过的坑与规避方案——数据边界、网络隔离、容器兼容这个项目如果只看功能清单写出来也就三四页纸但真正把它从Demo推到全员可用花了我们将近两个月而且有一半时间是在解决那些文档里不会写的环境问题。下面把踩过的坑和当时的具体处理方式都摊开来说给准备在类似环境里做AI改造的同行做个参考。4.1 侧边栏容器与浏览器内核的兼容性问题国网安全浏览器的内核版本比主流Chrome落后两个大版本这意味着新版扩展API不一定可用尤其是Side Panel API——标准的侧边栏API在旧内核上直接不存在。第一次打包完测的时候扩展装上了却看不到侧边栏入口排查半天才发现是这个原因。规避方案是降级实现用扩展的popup浮层加右键菜单唤醒再加一个快捷键AltQ切换侧边栏显隐。实现上不依赖Side Panel API而是通过一个固定定位的iframe浮层模拟侧边栏效果再通过扩展的存储接口同步显隐状态。这样哪怕浏览器内核不更新功能也不受影响。另一个兼容性问题是样式。侧边栏浮层用的是现代CSS在旧内核上部分属性解析异常比如flex gap间距在低版本上不生效导致按钮挤在一起。我们在打包前先在一个同内核版本的测试浏览器里跑了一遍视觉回归发现问题后用margin替代gap、用grid替代flex彻底解决了样式兼容问题。4.2 内网大模型服务的网络连通与高可用前面说了生产网访问不了外网所以模型服务必须部署在可以同时被办公终端和生产系统调研的内网服务器上。但“能通”和“稳定通”是两码事。第一次联调时我们遇到一个问题模型服务部署在A区而办公终端在B区中间防火墙只放通了特定IP和端口。一开始测的时候是通的第二天再测就超时了——防火墙策略重启后恢复默认我们的端口不在白名单里。解决方法是把所有依赖的网络路径整理成一张清单包括模型服务地址、向量库地址、业务API网关地址一次性提交防火墙策略变更申请并在测试环境做了完整的连通性脚本每次更新后自动跑一遍端口探测。高可用方面也交过学费。我们最初只部署了一个模型实例结果一次推理卡故障整个侧边栏的AI能力直接停摆。后来改成双实例主备部署通过内网负载均衡分发请求并给模型服务加了一个健康检查接口。这个动作虽然简单但价值很大——现在哪怕某个实例要升级重启侧边栏也不会感觉到任何中断。4.3 页面上下文注入时机、范围与权限边界content script向主页面注入脚本是有时机窗口的。业务系统的页面如果是异步渲染的SPA框架content script在页面加载时执行可能拿不到用户正在看的DOM节点。我们一开始的做法是在DOMContentLoaded事件里采集页面信息结果有些页面拿到的是空表单因为表单内容是接口返回后异步填充的。改成轮询加MutationObserver的组合方案——监听目标区域DOM变化等主数据渲染完成后再采集。这不是什么新鲜技术但真的需要针对每一个接入页面单独调参因为每个系统的渲染时机都不同。权限边界这块我们坚持一个原则只读页面信息不做页面DOM改动。侧边栏的所有UI都挂在自身浮层上不侵入业务系统页面的原始DOM。这样即使智能体出错也不会导致业务系统页面崩溃。唯一例外是表单自动填充这一步我们通过扩展的chrome.scripting接口临时注入一次性的填充代码执行完就销毁不留驻任何钩子。4.4 数据安全边界什么能上送模型什么不能数据上送策略从第一天就明确了客户信息、密码类字段、密钥文件内容三类数据严格禁上。技术上通过一个拦截模块在扩展的发送管道里做检查任何请求体只要命中敏感字段正则或关键字黑名单就直接丢弃并提示用户“内容含敏感信息已阻止上送”。这里有个容易被忽略的细节敏感信息不一定只出现在用户输入里也可能藏在RAG检索出的文档段落中。比如制度文档里如果包含了联系人电话检索时会返回到上下文然后模型可能会在回答里把它复述出来。我们后来在RAG管道的输出端加了一层过滤服务对检索结果做一次密级标注扫描命中涉密关键词的段落直接摘除。这一层过滤是上线前补上的当时测试人员用“员工联系方式”做了一轮对抗性测试发现侧边栏确实能引用文档中的电话信息我们还因为这个差点推迟上线。补上过滤后重新测试这类问题才彻底清零。5. 效果复盘与下一阶段的优化方向侧边栏智能体上线已经跑了一个季度从最初的内测20人扩展到全员可用中间经历过几次比较大的调整。这一节说点真实数据和方向判断给同行们做个参考。5.1 上线后的真实反馈与量化指标我们选了三个场景做了前后对比时间都是员工完成单次任务的耗时中位数场景使用前使用后变化制度条目查询4分20秒1分05秒耗时下降75%缺陷工单填写8分钟1分30秒耗时下降81%异常告警初步研判12分钟5分钟耗时下降58%这几个数字看着不错但里面有一个容易被忽视的真相员工愿意用侧边栏不是因为它“聪明”而是因为它省去了在多个页面之间来回切换的成本。也就是说真正的收益点在于把信息聚合到一个操作流里模型能力只是锦上添花。另一个真实的反馈是用户对“草稿态”的接受度很高。我们原本担心员工会嫌“让AI帮我填单子还得再检查一遍不如自己写”实际上内测反馈显示8成用户愿意使用草稿因为他们最花时间的不是“写”而是“查”——查设备编号、查缺陷分类、查应该填哪个系统。AI把查询环节做了用户审核草稿的压力远小于从零开始填写。5.2 从“能用”到“好用”记忆、反思与自我修正当前版本有一个核心短板——智能体偶尔会在上下文不足时“自信作答”尤其是跨系统追问的场景。比如用户先问了一个设备台账的问题接着又追问“那它上次检修是什么时候”如果模型没有正确继承前一问的设备编号就可能回答另一个设备的数据。这类问题靠提示词工程很难根治需要在智能体框架层面加上“引用校验”环节。我们下一阶段的计划是在架构里引入反思机制智能体在给出回答前先做一个自我一致性检查把答案中出现的所有结构化实体设备编号、工单号、日期与当前会话记忆里的实体进行比对不一致则重新推理。这个过程会增加300毫秒左右的响应延迟但换来的准确性提升是值得的。多智能体协同也在规划中。现在侧边栏里只有“一个助手”但现实中一个任务经常要串起制度问答、台账查询、报告生成三条能力线。单独一个Agent串联执行时一旦中间步骤出错后面全崩。我们打算把制度问答、数据查询、文档生成拆成三个子Agent由一个调度编排器统筹子Agent之间通过会话上下文传递结果。这个改造和业界常说的多智能体框架思路一致但实现上我们不打算引入重框架而是用内网自研的轻量编排服务来完成。5.3 最后的一点体会和建议从立项到上线整个项目周期不到四个月。复盘下来我个人的体会是在企业内部做AI智能体最难的不是模型选型也不是RAG效果而是让智能体在“安全边界”和“业务价值”之间找到那个平衡点。给准备做同类项目的同行三个建议。第一先圈定一个足够高频的业务场景把“单次任务耗时”这个指标做出来再横向复制。不要一开始就想做一个覆盖所有岗位的通用AI助手。第二把“读操作走AI写操作留草稿”作为铁律。宁可让用户觉得AI“不够自动化”也不要让AI的任何一步错误操作流到正式业务流程里。第三数据安全边界要用代码实现不要靠提示词约定。所有敏感数据过滤逻辑都必须写在请求管道里而不是写在系统提示词里让模型“自觉遵守”。侧边栏智能体这个形态我认为还有很大的延展空间。下一步我们打算把它从浏览器扩展到内部的桌面办公套件里让AI的感知能力覆盖更多工作场景。但那已经是另一个项目的故事了等跑出一版再回来分享。
企业内网AI助手实战：基于安全浏览器的侧边栏智能体架构与落地
1. 为什么是“安全浏览器”而不是普通Chrome/Firefox——企业内网的真实约束先说个场景。电网调度员处理一个变电站的越限告警需要在一分钟内翻出《变电站运维规程》对应章节、确认告警处置时限、再看一眼同类型缺陷的历史记录最后把判断结果填进缺陷流程单。传统做法是打开知识库网站搜索、切到生产管理系统翻台账、再打开办公软件写报告三个系统来回切熟练工也要五分钟。整个过程没有一秒钟是“创造性的”但所有人都默认这是工作的一部分。我们最初的想法很朴素能不能在浏览器里放一个AI助手让它在当前页面右侧随时待命把这种“查资料—对照规则—填表单”的重复劳动直接接管。这个想法一旦放到真实的企业环境里第一个问题不是“用什么大模型”而是“这个功能到底该装在哪里”。1.1 “安全”二字意味着什么——终端管控与网络隔离普通用户理解的安全浏览器可能觉得是“不会中毒的浏览器”。但在电网这类企业内部国网安全浏览器代表的是一整套终端安全策略操作系统国产化适配、USB外设管控、软件安装白名单、内外网隔离、上网行为审计每一层都有严格的管控要求。这带来两个直接后果。第一不能指望员工自己打开Chrome商店装一个AI插件因为终端的软件安装权限是收敛的插件的安装和更新也必须走企业内部的软件分发通道。第二业务系统大多只在内网域名下提供服务访问生产系统页面必须通过统一认证网关任何外部大模型的在线API在默认网络策略下根本不可达。所以“基于国网安全浏览器做AI侧边栏”这个题目的隐含约束是在不改变终端安全基线、不破坏网络隔离策略的前提下找到一个能被现有终端环境接纳的AI交互形态。侧边栏恰好满足这个条件——它不是一个需要额外安装的独立软件而是浏览器这一个已被充分管控的进程内部的扩展视图。1.2 选择侧边栏形态的原因——从浏览器扩展到企业集成框架我们评估过三种落地形态。第一种是独立的桌面客户端交互自由度最高但需要重新走终端软件入网审批流程部署周期长而且员工不愿为一个AI助手多装一个常驻程序。第二种是网页版门户把AI对话固化成内网站点技术上最简单但它和员工正在使用的业务系统是割裂的用户必须切走再问AI再切回来操作上下文全丢体验和翻文档差不多。第三种就是浏览器侧边栏。它挂在浏览器主窗体的右侧或左侧与当前页面同屏共存既能保持AI对话的独立面板又能通过浏览器扩展能力读取当前页面信息做到“人看着业务系统AI在旁边待命”。最终我们选择了第三种并且注册为浏览器扩展。技术上它遵循Chromium扩展标准通过Side Panel API或注入式浮动面板实现侧边栏UI再通过content script与主页面做受控通信。整个开发链路完全在原生浏览器安全模型内运行不触碰终端管控边界这也是它能快速通过安全评审的根本原因。2. 侧边栏智能体的整体架构与定位——不是聊天机器人而是工作台把侧边栏做成“能聊天的搜索框”很容易但那不是智能体只是给知识库套了个对话框外壳。我们的定位从一开始就很明确侧边栏智能体是一个驻扎在浏览器里的工作助手它要能感知员工正在做什么、理解业务上下文、调用企业内部工具最终把结果直接送回工作流里。整体架构分为六层客户端层国网安全浏览器扩展负责侧边栏UI、页面上下文捕获、会话状态管理接入层内网API网关统一处理鉴权、限流、审计日志模型服务层私有化部署的大模型推理服务对外提供chat/embedding接口知识层RAG检索服务对接企业内部制度库、规程文档、缺陷台账工具层面向业务系统的Function工具集包括查台账、建工单、调历史记录沉淀层会话记录、结果回写、反馈统计2.1 智能体的核心链路感知—规划—行动—沉淀智能体与普通对话机器人的本质区别在于它有“行动”能力。我们拆出的核心链路是四步。感知扩展侧content script捕获当前页面的URL、页面标题、用户选中文本、当前浏览器标签页列表。这些信息经过脱敏处理后作为上下文拼入系统提示词。规划模型根据用户输入和页面上下文决定本次请求要走“直接回答”“检索知识库”“调用业务工具”还是“组合执行”。这里我们用Function Calling配合意图识别完成规划不依赖复杂的Agent推理框架因为企业内部场景的意图种类其实是有限的。行动如果规划结果是要查缺陷台账模型会构造一个结构化的工具调用请求由扩展侧发起对内网业务系统的API调用返回结果再拼回对话上下文。沉淀每一次问答和工具调用的过程、参数、结果都写入审计日志并对用户可见的结果加“参考来源”标注。这条链路看起来简单但每一步都踩过不少坑。比如“感知”这一步页面URL里经常带工单编号我们一开始直接把它塞进提示词结果模型会在回答里“引用”用户根本没打开过的工单内容后来改成只从URL提取页码参数其余一律丢弃。2.2 为什么采用私有化部署而不是公有云大模型讨论模型选型时团队内部有过一场争论。公有云大模型能力更强、迭代更快RAG效果也更好但有三道坎过不去一是业务数据出域问题制度文档、缺陷台账属于内部敏感信息明文上送公有云在我们这里是明确禁止的二是网络隔离问题生产网段的终端访问不了公共互联网的大模型API三是审计合规问题所有AI交互必须留痕可追溯公有云服务的日志留存策略满足不了内部审计要求。最终我们选择了私有化部署方案。模型本体用的是开源权重的中等规模底座量化到INT8后部署在两张推理卡上通过vLLM提供OpenAI兼容接口。参数规模没有选择最大的版本主要是考虑内网服务器的显存容量和并发上限。实测单卡并发8路请求、首token延迟1.2秒左右在办公场景下是可接受的。这里也给正在选型的同行一个建议如果你们的场景也是“制度问答工具调用”不需要一味追求大参数模型一个70亿到140亿参数级别的开源权重模型配合一个质量不错的RAG管道已经能覆盖绝大部分需求。真正拉高体验上限的往往不是模型本身而是知识库的切分质量和工具返回结果的提示词表达。2.3 与业务系统的桥接从跳转URL到能力开放智能体要“做事”就必须和业务系统打通。最粗暴的打通方式是返回一个URL让用户自己点但这算不上行动只是导航。我们选择了另一条路通过业务系统的只读API开放接口让智能体直接查询数据再通过表单自动填充帮助用户完成低风险的操作闭环。举个例子用户输入“查一下编号GD-2024-0153缺陷的处理状态”智能体直接调用缺陷管理系统的查询接口返回结构化结果并渲染成卡片而不是先跳转再人肉搜索。第一批工具集的开放范围是严格收敛的。我们只开放了查询类接口按编号查台账、按关键词搜规程、按部门查周报模板和几个低风险的创建类操作生成缺陷初稿草稿、创建巡检任务草稿。所有创建类操作默认状态是“草稿”必须经过人工确认后才能流向业务系统避免智能体误操作引发连锁问题。这个取舍在安全评审时帮了大忙评审专家看到“所有写操作都是草稿态、所有读操作都有审计日志”时基本没有提出额外要求。反过来如果一上来就开放自动提交工单的能力大概率会被一票否决。3. 核心功能拆解与实现路径——从制度问答到业务协同再往下说是侧边栏智能体实际落地的那几个功能。我们分了三批推进第一批做制度问答第二批做业务辅助第三批做上下文感知的跨系统联动。每批功能我们都设定了明确的验收标准不和“智能”这个词较劲只看员工单次任务完成时间有没有下降。3.1 制度问答与RAG检索增强让模型“看在内部文档上说话”制度问答是所有企业AI助手的第一站因为制度文档对准确性的要求极高而大模型本身并不忠实于原文必须用检索增强生成RAG约束模型输出。具体实现上我们把《变电站运维规程》《调度操作指令票管理规定》《缺陷管理实施细则》等文档统一解析成Markdown按章节标题做结构切分再通过Embedding模型转成向量存入向量库。检索时先做混合检索——向量相似度召回一批段落关键词匹配召回一批段落合并后按BM25与向量得分加权排序。很多人会在这一步忽略“标题段落匹配”的价值。我们踩过这样一个坑员工问“缺陷消除时限是几天”RAG召回的是《缺陷管理实施细则》里对缺陷等级的定义章节模型照着念了半天就是没说清时限。后来我们给切分块额外加了一个字段——当前段落所属的顶层章节标题并在提示词里要求“回答时必须根据块标题所在章节来组织上下文”。加了这一步回答准确率从78%直接跳到89%。3.2 业务操作的“副驾”工单填写、故障定位、报告初稿制度问答跑通之后团队的信心上来了就开始碰真正硬核的东西让智能体直接参与业务操作。第一个落地场景是缺陷工单填写。之前员工填写缺陷单要手动从台账系统复制设备编号、从规程里翻缺陷分类、再自己写一段现象描述。侧边栏智能体实现的工作流是用户复制设备名称或粘贴一段巡检异常描述智能体自动抽取设备标识、匹配缺陷现象库、推荐缺陷分类并生成一份描述草稿用户确认后自动填充到工单表单。这段流程拆开看并不神奇抽取设备标识靠正则加实体识别匹配缺陷现象库靠向量检索生成描述草稿靠大模型的文本润色能力。但合在一起员工填写一张缺陷单的时间从8分钟压到了1分半。而且因为草稿必须用户确认错误率没有增加这一点让业务部门很放心。第二个场景是故障定位辅助。当用户粘贴一段告警信息或运行日志时智能体自动检索同类型故障的历史处置记录按照“曾经发生—处置步骤—生效时间”的结构生成推荐处置路径。它不直接给结论而是给路径。这个设计是为了防止模型在信息不足时强行归因把“可能原因列表”呈现出来让有经验的运行人员来做最终判断。3.3 上下文感知智能体如何“看懂”当前页面内容侧边栏如果只做一个独立的对话框价值会小一半。让它“看懂”当前页面才能从被动应答变成主动辅助。技术路径是通过浏览器扩展的content script在当前业务系统页面加载后采集三类信息页面URL和标题、页面中用户选中的文本、以及页面表单里当前的填写内容。采集到的信息经过一个本地的脱敏模块处理把手机号、身份证号、具体的工单编号等敏感字段用掩码替换然后才上送模型。脱敏模块是整个上下文感知功能能通过安全评审的关键。我们在一开始就把“页面内容默认不采集、用户主动选中才采集”作为交互原则而不是像某些浏览器插件那样默认抓取全页面DOM。侧边栏顶部有一个常驻开关显示“当前页面关注中”或“当前页面未接入”员工对这个提示的信任度远高于那些默默读取浏览历史的插件。3.4 会话管理与多轮记忆贴近实际工作流的对话设计智能体能不能记住上文直接决定对话体验。我们做的不是把历史消息全塞进窗口这种粗暴做法而是提炼出“业务状态记忆”和“任务清单记忆”两种结构。业务状态记忆记录的是当前会话中用户提到过的关键实体比如“上次提到的设备编号是XX缺陷等级是III级”。任务清单记忆则记录的是对话中产生的待办事项比如用户说了“帮我查三份规程然后生成一份排查提纲”智能体会在侧边栏底部维护一个任务列表每完成一项就打钩。这两类记忆都以JSON结构保存在每次请求时拼入系统提示词。它的好处是可以压缩历史长度不必无限增长上下文窗口同时还能让用户看到智能体“记住了什么”不确定时也能手动删除某条记忆。交互成本低透明度高上线后几乎没有用户抱怨过“忘记前文”的问题。4. 落地过程中踩过的坑与规避方案——数据边界、网络隔离、容器兼容这个项目如果只看功能清单写出来也就三四页纸但真正把它从Demo推到全员可用花了我们将近两个月而且有一半时间是在解决那些文档里不会写的环境问题。下面把踩过的坑和当时的具体处理方式都摊开来说给准备在类似环境里做AI改造的同行做个参考。4.1 侧边栏容器与浏览器内核的兼容性问题国网安全浏览器的内核版本比主流Chrome落后两个大版本这意味着新版扩展API不一定可用尤其是Side Panel API——标准的侧边栏API在旧内核上直接不存在。第一次打包完测的时候扩展装上了却看不到侧边栏入口排查半天才发现是这个原因。规避方案是降级实现用扩展的popup浮层加右键菜单唤醒再加一个快捷键AltQ切换侧边栏显隐。实现上不依赖Side Panel API而是通过一个固定定位的iframe浮层模拟侧边栏效果再通过扩展的存储接口同步显隐状态。这样哪怕浏览器内核不更新功能也不受影响。另一个兼容性问题是样式。侧边栏浮层用的是现代CSS在旧内核上部分属性解析异常比如flex gap间距在低版本上不生效导致按钮挤在一起。我们在打包前先在一个同内核版本的测试浏览器里跑了一遍视觉回归发现问题后用margin替代gap、用grid替代flex彻底解决了样式兼容问题。4.2 内网大模型服务的网络连通与高可用前面说了生产网访问不了外网所以模型服务必须部署在可以同时被办公终端和生产系统调研的内网服务器上。但“能通”和“稳定通”是两码事。第一次联调时我们遇到一个问题模型服务部署在A区而办公终端在B区中间防火墙只放通了特定IP和端口。一开始测的时候是通的第二天再测就超时了——防火墙策略重启后恢复默认我们的端口不在白名单里。解决方法是把所有依赖的网络路径整理成一张清单包括模型服务地址、向量库地址、业务API网关地址一次性提交防火墙策略变更申请并在测试环境做了完整的连通性脚本每次更新后自动跑一遍端口探测。高可用方面也交过学费。我们最初只部署了一个模型实例结果一次推理卡故障整个侧边栏的AI能力直接停摆。后来改成双实例主备部署通过内网负载均衡分发请求并给模型服务加了一个健康检查接口。这个动作虽然简单但价值很大——现在哪怕某个实例要升级重启侧边栏也不会感觉到任何中断。4.3 页面上下文注入时机、范围与权限边界content script向主页面注入脚本是有时机窗口的。业务系统的页面如果是异步渲染的SPA框架content script在页面加载时执行可能拿不到用户正在看的DOM节点。我们一开始的做法是在DOMContentLoaded事件里采集页面信息结果有些页面拿到的是空表单因为表单内容是接口返回后异步填充的。改成轮询加MutationObserver的组合方案——监听目标区域DOM变化等主数据渲染完成后再采集。这不是什么新鲜技术但真的需要针对每一个接入页面单独调参因为每个系统的渲染时机都不同。权限边界这块我们坚持一个原则只读页面信息不做页面DOM改动。侧边栏的所有UI都挂在自身浮层上不侵入业务系统页面的原始DOM。这样即使智能体出错也不会导致业务系统页面崩溃。唯一例外是表单自动填充这一步我们通过扩展的chrome.scripting接口临时注入一次性的填充代码执行完就销毁不留驻任何钩子。4.4 数据安全边界什么能上送模型什么不能数据上送策略从第一天就明确了客户信息、密码类字段、密钥文件内容三类数据严格禁上。技术上通过一个拦截模块在扩展的发送管道里做检查任何请求体只要命中敏感字段正则或关键字黑名单就直接丢弃并提示用户“内容含敏感信息已阻止上送”。这里有个容易被忽略的细节敏感信息不一定只出现在用户输入里也可能藏在RAG检索出的文档段落中。比如制度文档里如果包含了联系人电话检索时会返回到上下文然后模型可能会在回答里把它复述出来。我们后来在RAG管道的输出端加了一层过滤服务对检索结果做一次密级标注扫描命中涉密关键词的段落直接摘除。这一层过滤是上线前补上的当时测试人员用“员工联系方式”做了一轮对抗性测试发现侧边栏确实能引用文档中的电话信息我们还因为这个差点推迟上线。补上过滤后重新测试这类问题才彻底清零。5. 效果复盘与下一阶段的优化方向侧边栏智能体上线已经跑了一个季度从最初的内测20人扩展到全员可用中间经历过几次比较大的调整。这一节说点真实数据和方向判断给同行们做个参考。5.1 上线后的真实反馈与量化指标我们选了三个场景做了前后对比时间都是员工完成单次任务的耗时中位数场景使用前使用后变化制度条目查询4分20秒1分05秒耗时下降75%缺陷工单填写8分钟1分30秒耗时下降81%异常告警初步研判12分钟5分钟耗时下降58%这几个数字看着不错但里面有一个容易被忽视的真相员工愿意用侧边栏不是因为它“聪明”而是因为它省去了在多个页面之间来回切换的成本。也就是说真正的收益点在于把信息聚合到一个操作流里模型能力只是锦上添花。另一个真实的反馈是用户对“草稿态”的接受度很高。我们原本担心员工会嫌“让AI帮我填单子还得再检查一遍不如自己写”实际上内测反馈显示8成用户愿意使用草稿因为他们最花时间的不是“写”而是“查”——查设备编号、查缺陷分类、查应该填哪个系统。AI把查询环节做了用户审核草稿的压力远小于从零开始填写。5.2 从“能用”到“好用”记忆、反思与自我修正当前版本有一个核心短板——智能体偶尔会在上下文不足时“自信作答”尤其是跨系统追问的场景。比如用户先问了一个设备台账的问题接着又追问“那它上次检修是什么时候”如果模型没有正确继承前一问的设备编号就可能回答另一个设备的数据。这类问题靠提示词工程很难根治需要在智能体框架层面加上“引用校验”环节。我们下一阶段的计划是在架构里引入反思机制智能体在给出回答前先做一个自我一致性检查把答案中出现的所有结构化实体设备编号、工单号、日期与当前会话记忆里的实体进行比对不一致则重新推理。这个过程会增加300毫秒左右的响应延迟但换来的准确性提升是值得的。多智能体协同也在规划中。现在侧边栏里只有“一个助手”但现实中一个任务经常要串起制度问答、台账查询、报告生成三条能力线。单独一个Agent串联执行时一旦中间步骤出错后面全崩。我们打算把制度问答、数据查询、文档生成拆成三个子Agent由一个调度编排器统筹子Agent之间通过会话上下文传递结果。这个改造和业界常说的多智能体框架思路一致但实现上我们不打算引入重框架而是用内网自研的轻量编排服务来完成。5.3 最后的一点体会和建议从立项到上线整个项目周期不到四个月。复盘下来我个人的体会是在企业内部做AI智能体最难的不是模型选型也不是RAG效果而是让智能体在“安全边界”和“业务价值”之间找到那个平衡点。给准备做同类项目的同行三个建议。第一先圈定一个足够高频的业务场景把“单次任务耗时”这个指标做出来再横向复制。不要一开始就想做一个覆盖所有岗位的通用AI助手。第二把“读操作走AI写操作留草稿”作为铁律。宁可让用户觉得AI“不够自动化”也不要让AI的任何一步错误操作流到正式业务流程里。第三数据安全边界要用代码实现不要靠提示词约定。所有敏感数据过滤逻辑都必须写在请求管道里而不是写在系统提示词里让模型“自觉遵守”。侧边栏智能体这个形态我认为还有很大的延展空间。下一步我们打算把它从浏览器扩展到内部的桌面办公套件里让AI的感知能力覆盖更多工作场景。但那已经是另一个项目的故事了等跑出一版再回来分享。
