企业官网建设流程全解析

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浮层加右键菜单唤醒，再加一个快捷键（Alt+Q）切换侧边栏显隐。实现上不依赖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 上线后的真实反馈与量化指标

我们选了三个场景做了前后对比，时间都是员工完成单次任务的耗时中位数：

这几个数字看着不错，但里面有一个容易被忽视的真相：员工愿意用侧边栏，不是因为它“聪明”，而是因为它省去了在多个页面之间来回切换的成本。也就是说，真正的收益点在于把信息聚合到一个操作流里，模型能力只是锦上添花。

另一个真实的反馈是用户对“草稿态”的接受度很高。我们原本担心员工会嫌“让AI帮我填单子还得再检查一遍，不如自己写”，实际上内测反馈显示，8成用户愿意使用草稿，因为他们最花时间的不是“写”，而是“查”——查设备编号、查缺陷分类、查应该填哪个系统。AI把查询环节做了，用户审核草稿的压力远小于从零开始填写。

5.2 从“能用”到“好用”：记忆、反思与自我修正

当前版本有一个核心短板——智能体偶尔会在上下文不足时“自信作答”，尤其是跨系统追问的场景。比如用户先问了一个设备台账的问题，接着又追问“那它上次检修是什么时候”，如果模型没有正确继承前一问的设备编号，就可能回答另一个设备的数据。这类问题靠提示词工程很难根治，需要在智能体框架层面加上“引用校验”环节。

我们下一阶段的计划是在架构里引入反思机制：智能体在给出回答前，先做一个自我一致性检查，把答案中出现的所有结构化实体（设备编号、工单号、日期）与当前会话记忆里的实体进行比对，不一致则重新推理。这个过程会增加300毫秒左右的响应延迟，但换来的准确性提升是值得的。

多智能体协同也在规划中。现在侧边栏里只有“一个助手”，但现实中一个任务经常要串起制度问答、台账查询、报告生成三条能力线。单独一个Agent串联执行时，一旦中间步骤出错，后面全崩。我们打算把制度问答、数据查询、文档生成拆成三个子Agent，由一个调度编排器统筹，子Agent之间通过会话上下文传递结果。这个改造和业界常说的多智能体框架思路一致，但实现上我们不打算引入重框架，而是用内网自研的轻量编排服务来完成。

5.3 最后的一点体会和建议

从立项到上线，整个项目周期不到四个月。复盘下来，我个人的体会是：在企业内部做AI智能体，最难的不是模型选型，也不是RAG效果，而是让智能体在“安全边界”和“业务价值”之间找到那个平衡点。

给准备做同类项目的同行三个建议。

第一，先圈定一个足够高频的业务场景，把“单次任务耗时”这个指标做出来，再横向复制。不要一开始就想做一个覆盖所有岗位的通用AI助手。

第二，把“读操作走AI，写操作留草稿”作为铁律。宁可让用户觉得AI“不够自动化”，也不要让AI的任何一步错误操作流到正式业务流程里。

第三，数据安全边界要用代码实现，不要靠提示词约定。所有敏感数据过滤逻辑都必须写在请求管道里，而不是写在系统提示词里让模型“自觉遵守”。

侧边栏智能体这个形态，我认为还有很大的延展空间。下一步我们打算把它从浏览器扩展到内部的桌面办公套件里，让AI的感知能力覆盖更多工作场景。但那已经是另一个项目的故事了，等跑出一版再回来分享。