企业已经拥有 BI、ERP、CRM、采购、财务、客服和自研后台，也开始拥有越来越多 Agent。奇怪的是，两者经常不在同一个工作现场：人正在 BI 页面里核对异常，Agent 却在另一个聊天窗口；人正在审批采购单，Agent 要求他复制字段、描述页面、粘贴链接，再从头解释自己看见了什么。
这不是模型能力不足，而是入口设计错了。团队习惯把 Agent 放进专业 IDE、独立工作台或 OA 门户，默认用户会主动离开业务页面去寻找智能能力。可业务上下文并不只存在于数据库，也存在于用户此刻打开的系统、进入的菜单、选中的对象、页面筛选条件和将要执行的动作里。让人反复搬运这些上下文，等于把最容易出错的一段工作留给人工。
浏览器提供了另一条路径：只要工作发生在 Web 系统中，组织就可以通过浏览器扩展，把适合当前页面的能力嵌到操作现场，同时在浏览器侧边保留一个持续存在的 Agent 工作区。前者负责“就在这里做”，后者负责“围绕这件事继续做”。它们不是两套产品，也不是二选一，而是同一个 Agent 扩展层的两种界面。
Agent 不应该只是一处需要用户主动前往的新系统。它更应该成为一层随业务页面出现、理解当前上下文、又能被统一授权和审计的扩展能力。
图 1：真实界面形态示例。截图只能证明“页内入口与菜单选择”可以组合出现，不证明采集结果完整，也不代表任意站点都可无条件适配。
真正被耽误的，不是大项目，而是高价值的小功能
传统企业定制通常与宿主系统强耦合。要在 BI 页面增加一个“解释异常”按钮，往往需要理解原系统前端框架、后端接口、权限模型、发布窗口和供应商责任；要在采购页面增加一个供应商风险摘要，可能还要进入原产品路线图。即使功能本身只有一个入口、一段上下文和一次服务调用，它也会继承宿主系统全部的交付成本。
于是排期自然偏向覆盖人数更多、流程更标准、责任更清晰的需求。只有某个岗位每天使用、却能省下大量判断时间的功能，反而容易被放弃。不是它没有价值，而是把它装进原系统的边际成本太高：改一处要回归整套系统，上线要等待固定窗口，升级还要重新合并。
这种模式隐含了一个过时假设：业务能力必须由宿主系统自己提供。浏览器扩展打破的是这条归属关系。它可以在获得站点权限后由 Content Script 读取或修改页面 DOM；也可以使用 Chrome 的 Side Panel API，在网页旁边提供持续界面。页内入口、侧边工作区、扩展后台和远端服务之间再通过消息与类型化接口协作。能力仍然围绕宿主系统工作，却不必成为宿主系统源码的一部分。
图 2：左侧每个小需求都进入宿主系统研发链；右侧把可复用能力放进独立扩展层，只为不同页面维护轻量适配。
这里的收益不是“零开发”。页面结构仍需识别，权限仍需配置，服务仍需维护，宿主系统变化仍会引发兼容问题。真正改变的是成本结构：过去每个功能都要穿过整套宿主系统，现在可以把通用的身份、模型、知识、工具、审批和审计复用起来，只让页面差异留在适配器中。
因此，一个财务团队专用的对账提示、一个运营团队专用的页面采集、一个销售团队专用的客户风险卡片，不必先证明自己值得进入全公司核心系统。只要它位于允许扩展的范围内、能够独立关闭、不会绕过服务端权限，就可以先以可插拔能力进入少量用户的真实工作流，再用数据决定是否扩大。
Agent 扩展层不是一个悬浮聊天框
“在网页右下角放一个机器人”只是最浅的一种形态。若它仍然要求用户重新描述当前页面、手工选择工具、自己判断输出能否执行，它只是把聊天窗口挪近了一点。Agent 扩展层要解决的是上下文、能力、运行和治理的连接问题，可以拆成四层。
第一层是页面适配层。它识别当前 URL、页面类型、业务对象、可用区域和生命周期，把不稳定的 DOM 细节翻译为稳定的页面上下文。例如，BI 适配器输出的是“当前为大盘分析页、菜单标识是什么、选择了哪些筛选条件”，而不是把整页 HTML 原样交给模型。页面改版时，主要修复这一层。
第二层是扩展运行层。它管理页内组件、侧边工作区、消息路由、任务状态和本地缓存。页内按钮点击以后，不应直接把任意字符串发往远端；运行层先校验来源、绑定当前标签页与站点授权，再把结构化请求交给能力层。侧边工作区刷新或页面跳转后，也从这里恢复任务状态。
第三层是能力接入层。它连接企业 API、MCP 工具、知识检索、模型服务和工作流。MCP 可以帮助能力以工具和输入 Schema 的方式被发现，但协议本身不替企业决定谁能调用、能操作哪些对象、调用后怎样审批。能力接入层必须把技术工具再次收敛为业务动作合同。
第四层是治理控制层。它统一处理身份、站点授权、数据最小化、风险等级、人工确认、执行回执、版本发布和熔断。没有这一层，所谓“给所有系统装插件”很容易演变成一组能读取敏感页面、又能调用外部服务的影子脚本。
图 3：两种界面共享同一个运行层；所有跨系统能力最终都经过治理控制，而不是从页面脚本直连高风险写接口。
这四层的关键不是技术名称，而是变化被隔离在哪里。宿主系统改版，修页面适配；浏览器 API 变化，修扩展运行；模型或工具替换，修能力接入；企业政策变化，修治理控制。若每次变化都要重写整条链，系统只是换了一种方式继续强耦合。
页内嵌入和侧边工作区必须配套使用
页内嵌入能力适合短路径、强上下文、低打扰的动作。它可以是悬浮入口、表格行内按钮、选中文本后的操作菜单、字段旁的风险提示，也可以是页面顶部的批量采集工具。用户不必离开当前任务，系统也不必猜测他指的是哪个对象。
侧边智能工作区适合需要持续阅读、多轮判断和跨页面积累的任务。它可以展示诊断过程、证据、引用、待确认动作和执行结果；用户切换网页时仍能保留任务，并把新页面作为补充上下文。Chrome 官方的 Side Panel API 正是为“与网页并排、在浏览过程中持续存在”的扩展界面提供基础能力。
如果只有页内嵌入，复杂输出会挤占宿主页面，长任务也缺少稳定容器；如果只有侧边工作区，Agent 又会退回一个不了解当前操作位置的通用聊天框。双界面协同让两者各做擅长的事：页内界面负责指向和触发，侧边界面负责展开和持续。
图 4：真实界面形态示例。左侧承载业务知识配置，右侧保留 Agent 工作区；截图不证明其中的模型、RAG 或后端服务已经达到生产质量。
以 BI 场景为例，一条合理的协同路径可以这样发生：用户在“大盘分析”页面点击悬浮采集入口，页内界面展示当前系统的菜单结构；用户只勾选允许进入知识范围的页面；扩展读取页面标识、路径、标题和必要结构，不默认抓取整页数据；侧边工作区显示采集进度、失败项和待补说明；后续用户再次打开该页面时，Agent 才能在明确的业务语境中回答“这张表反映什么、哪些指标值得检查”。
这条路径里，页内入口解决对象选择，侧边工作区解决过程透明，远端知识服务负责版本化保存。任何一步失败都应该可见：页面结构无法识别就停止采集，权限不足就说明缺少哪项授权，远端保存失败就保留本地待重试状态。不能用一个“已完成”通知覆盖部分失败。
图 5：真实界面形态示例。页面可以成为知识树节点并补充业务说明；这不意味着 DOM 永久稳定，也不代表宿主系统官方提供了该能力。
对用户而言，这不是“先采集、再去另一个系统配置、然后回到聊天”。整个过程仍围绕当前网页展开。对工程团队而言，它也不是把 BI 私有逻辑写进通用 Agent：菜单解析属于 BI 适配器，知识保存属于通用能力，界面状态属于扩展运行层，能否访问与保存则属于治理控制层。
页内嵌入能力负责把 Agent 放到正确的位置，侧边智能工作区负责让任务在页面之外持续；两者共享身份、上下文和状态，才是真正的双界面协同。
图 6：一次任务从页内选中对象，在侧边展开证据与步骤，再把结果反馈到原页面；两种界面不各自维护一份上下文。
可复用的不是按钮，而是能力合同
同一个“总结”按钮放到十个系统里，并不等于形成平台。真正可以跨系统复用的，是页面上下文与 Agent 能力之间的合同。
页面适配器至少要输出五类信息：宿主标识、页面类型、对象引用、用户明确选择的上下文，以及页面当前允许的交互点。对象引用不能只是一段可变的 CSS Selector，最好同时包含业务 ID、路径、页面版本或可回读标识。这样侧边工作区里的诊断、审批和回执才能重新指向原对象。
能力也要用结构化合同声明自己。一个“经营诊断”能力应说明需要哪些输入、可能读取什么数据、输出哪些证据、是否创建动作建议、风险等级多高、在哪些站点可用。模型生成的自然语言只是结果的一部分；真正驱动系统的是类型化输入、可验证输出和明确副作用。
这与 MCP 的价值边界相吻合。MCP Tools 可以用 Schema 暴露能力，任务机制可以承载需要轮询或稍后取回的结果，授权规范则要求令牌绑定资源并反对令牌透传。但即便工具描述完整，客户端仍不能把服务器提供的注解天然视为可信，也不能因为用户能看见按钮就推断他拥有业务写权限。协议解决互操作，企业治理决定可执行性。
跨系统复用还需要把“显示在哪里”从能力逻辑中拆出。相同的异常解释能力，在 BI 中可能表现为图表旁按钮，在 CRM 中可能表现为客户详情页卡片，在采购系统中可能表现为审批前提示，在没有适配器的网站中则只出现在侧边工作区。能力不应该因为入口变化而复制四份。
反过来，适配器也不应该内置某个模型供应商、某套知识库或一串提示词。它只负责识别现场、收集最小上下文、提供挂载点和接收结果。这样才能把“新接一个 Web 系统”压缩为适配工作，而不是重新开发一套 Agent。
从 BI 页面到结构化诊断，Agent 仍然不能替数据负责
侧边工作区可以把多个页面的知识、指标解释和工具调用组织成结构化诊断。它比通用聊天更接近业务现场，因为用户眼前就是被分析的页面，Agent 也能知道当前菜单和筛选范围。可这个界面优势不能被偷换成结论可靠性。
BI 页面的可见文本可能只是格式化结果，指标口径可能藏在语义层，图表可能延迟刷新，页面权限也可能让不同用户看到不同范围。扩展能读取页面，不代表拿到了完整事实；能识别菜单，不代表理解了每个指标；能生成“风险三项”，更不代表三项都由真实数据支持。
因此，诊断输出至少要区分三类内容：页面直接可见的事实、通过已授权工具查询得到的证据、模型基于前两者形成的推断。每个关键结论都应能回到页面位置、数据请求或知识版本。找不到证据时，Agent 应明确写“未知”或“需要补充”，而不是利用页面上下文制造更像真的幻觉。
图 7：真实界面形态示例。截图展示的是诊断结果如何与业务页面并排出现；其中内容已做遮挡，只能作为交互说明，不能外推为真实经营结论。
对于动作，边界要更严格。页面上出现“调整预算”“创建工单”“更新供应商状态”按钮，不等于 Content Script 可以直接操作页面控件完成业务写入。可靠路径是：Agent 先生成结构化提案，服务端用当前身份重新校验对象与权限，高风险动作取得显式批准，执行后再从宿主 API 回读真实状态。页面只展示入口、提案与回执，不成为绕过后端控制的捷径。
能进入生产的扩展层，需要七道治理门
“只要是网页就能注入”描述的是技术覆盖面，不是生产授权。浏览器扩展可以接触用户正在处理的高密度业务信息，权限一旦过宽，风险可能跨越多个系统。Chrome 的安全指南反复强调最小权限、将 Content Script 视为潜在不可信上下文，并把敏感操作收口在更受保护的扩展环境；关于扩展隐私的研究也表明，足够广的权限可能带来敏感数据暴露与外泄风险。
一个可上线的扩展治理框架至少需要七道门。
| 治理门 | 必须回答的问题 | 默认失败方式 |
|---|---|---|
| 站点授权 | 这个扩展版本能在哪些域名、哪些页面运行？ | 未授权站点不注入 |
| 上下文最小化 | 本次任务真正需要哪些字段，哪些内容禁止离开页面？ | 不采集整页，不默认持久化 |
| 结构化能力 | 工具输入、输出、副作用和失败语义是否可验证？ | Schema 不匹配即拒绝调用 |
| 风险分级 | 读取、建议、草案、写入、批量写入分别属于哪一级？ | 风险未知按高风险处理 |
| 显式确认 | 用户究竟批准了哪个对象、哪个变化、有效多久？ | 确认不完整不执行 |
| 执行回执 | 远端是否真正接受，最终状态能否回读和对账？ | 无回读不宣称成功 |
| 兼容熔断 | 页面或接口变化时，怎样停止错误注入和批量动作？ | 版本不匹配自动关闭能力 |
第一道门决定扩展在哪里出现。优先使用按需授权和 activeTab 一类临时能力，比默认申请所有站点的长期访问更符合最小权限。企业浏览器还可以通过集中策略控制扩展安装、最低版本、允许或阻止的运行站点与权限。开发者声明能做什么，组织策略再决定在自己的环境里允许什么。
第二道门决定什么能够离开页面。账号、个人信息、合同金额、内部 URL、Cookie、访问令牌和未脱敏经营数据不能因为模型“可能用得上”就被整页发送。适配器应先在本地选择与脱敏，远端只接收任务必需字段；日志同样遵守这一边界。
第三至第五道门把能力从“可以调用”变成“有资格执行”。每个工具有输入 Schema，每项动作有风险标签，每次授权绑定主体、对象、动作、影响范围和有效期。OWASP 的 Agent 安全材料强调最小权限、人工监督与工具滥用风险；这些控制必须落在确定性运行层，而不是只写进提示词要求模型自觉。
第六道门防止假成功。页面点击、消息发出、服务返回 200、宿主系统最终生效是四个不同状态。扩展需要保存幂等键、请求版本和远端对象标识，在宿主系统可用时回读结果。部分成功要逐项显示，重试不能制造第二次业务动作。
第七道门负责在变化时停下。单页应用会重用 DOM，灰度发布会让不同员工看见不同结构，浏览器版本和安全策略也会变化。适配器必须有页面指纹、兼容版本和健康检查；识别不到关键对象时宁可隐藏入口，也不能把按钮挂到错误记录旁。性能同样是熔断条件：扩展对页面加载、内存和能耗的影响需要真实环境验证。
图 8：站点、数据、能力、风险、确认、回执与兼容七道门共同限制影响范围；任一关键门失败，扩展都应降级或停止。
浏览器扩展扩大的是 Agent 的触达面，不是它的天然权限。生产级 Agent 扩展层必须让每一次出现、读取、判断和动作都能被限定、撤销、回读与审计。
哪些能力不应该做成页面注入
扩展层适合增量能力，不适合替换核心交易系统。这个边界如果不先写清楚，“低成本定制”很容易演变成无人维护的第二套业务系统。
第一类不适合的是强一致事务。付款、记账、库存扣减、合同生效和权限变更，需要服务端事务、并发控制与权威账本。扩展可以准备材料、展示风险、发起提案，最终写入必须经过宿主 API 或受治理的后端服务。
第二类不适合的是依赖秘密绕过登录的操作。扩展不应读取页面 Cookie 后转交第三方，也不应保存用户密码模拟登录。远端能力应使用自己的授权流程、资源绑定令牌和明确 scope；宿主身份无法安全委托时，就停留在读取或建议层。
第三类不适合的是页面结构极不稳定、错误挂载会造成严重后果的自动操作。可以先只开放侧边智能工作区，让用户主动选择文本或上传导出文件；等适配器稳定、监控齐全后，再逐步增加页内入口。
第四类不适合的是必须被所有角色、所有设备和所有渠道一致使用的核心流程。浏览器扩展依赖安装、浏览器政策和版本分发，更适合作为能力加速层。若某项功能已经成为组织不可缺失的标准流程，应评估把稳定合同下沉为正式 API、平台能力或宿主原生功能，扩展继续承担更贴近个人工作现场的界面。
还有一些页面天然受到限制，例如浏览器内部页面、扩展商店、特定编辑器或主动阻止扩展的安全区域。Grammarly 这类成熟扩展也公开说明某些页面和字段无法工作。合理产品不会承诺“任何网页百分之百可注入”，而会明确兼容矩阵与降级路径。
从一个岗位、一个页面、一个只读能力开始
Agent 扩展层不需要一开始就覆盖所有系统。更稳妥的落地单位是“岗位 × 页面 × 任务”。例如先选择经营分析人员在 BI 大盘页上的异常解释任务，因为页面上下文清晰、操作频率高、初期可以只读，价值也容易测量。
第一阶段只做观察：识别页面与对象，在侧边工作区展示可核对的解释和来源，不写回宿主系统。验收关注入口是否出现在正确页面、上下文是否准确、用户是否减少复制粘贴、错误时能否停止。
第二阶段加入页内嵌入：让用户在图表、记录或菜单附近直接触发能力，并把结果与当前对象绑定。此时建立适配器契约、兼容指纹、性能预算和灰度开关。页面变更导致识别失败时，系统自动退回侧边工作区的手动模式。
第三阶段引入提案：Agent 可以根据证据生成工单草案、配置建议或待审批动作，但不直接执行。用户看到修改前后、对象范围、证据时间和风险等级，批准记录进入审计链。
第四阶段才开放有限写入：只选择可逆、低影响、接口稳定的动作，设置额度、有效期、幂等与远端回读。扩大范围取决于真实运行数据，而不是演示成功。NIST AI RMF 提供的 Govern、Map、Measure、Manage 思路适合组织风险复核；SSDF 则提醒扩展本身的代码、依赖、构建和更新也必须进入安全开发生命周期。
每个能力都应有退出测试：关闭扩展以后，宿主系统是否仍然完整可用；撤销授权以后，远端是否无法继续访问；回滚版本以后，旧任务是否会被安全终止；卸载以后，本地缓存是否按政策清理。可插拔不仅表示容易装上，还表示能够干净地拿掉。
衡量价值时，也不要只看调用次数。更有效的指标包括：上下文搬运次数是否下降、从发现问题到形成可核对结论的时间是否缩短、适配器错误挂载率、权限拒绝率、提案采纳率、执行后回读一致率，以及宿主系统升级后的恢复时间。Agent 生成了多少字，不能证明业务现场变得更顺畅。
浏览器会成为 Agent 的业务接入层
浏览器的独特位置在于，它已经横跨大量企业 Web 系统，并天然知道用户此刻在哪个页面。Content Script 提供页内嵌入能力，Side Panel 提供侧边智能工作区，Service Worker 和消息机制提供协调基础，企业策略则能控制分发、站点与权限。WebExtensions 标准化工作也在推动浏览器之间形成更一致的共同能力。
但“浏览器是入口”不等于“所有逻辑都放进浏览器”。扩展负责靠近现场、组织交互和携带最小上下文；权威数据、身份策略、知识版本、复杂任务和业务写入仍应留在可以治理的服务端。扩展层的理想状态，是薄适配、厚合同、强治理。
当这层建立以后，企业定制的决策方式会发生变化。过去的问题是“值不值得修改核心系统”；新的问题是“这项能力能否在扩展治理框架内独立交付”。大量曾因排期、覆盖人数或供应商边界而被舍弃的小功能，会重新获得进入业务现场的机会。
最终目标也不是给每个网页贴满按钮，而是让智能能力在最恰当的位置出现：简单动作就地完成，复杂任务在侧边持续，高风险变化回到服务端批准与执行，不兼容时能够立即消失。用户仍在熟悉的系统里工作，Agent 则从一个孤立目的地，变成连接这些系统的扩展层。