浏览器推理中的上下文分工

浏览器推理中的上下文分工

浏览器里的智能功能常常面对一个尴尬问题：页面上能看到的东西很多，真正与当前任务有关的内容却很少。把整页 DOM、聊天历史、网络响应和用户选择一起交给模型，看起来信息充分，实际会增加延迟，也容易把隐私数据或页面里的恶意文本带进推理过程。上下文分工的目标，是让每类信息只承担自己的职责。

当前操作是最靠近任务的上下文

用户刚刚选中的文本、正在编辑的表单、点击的按钮和当前视口，通常比整个页面更有价值。它们直接说明用户此刻在做什么。选择文本时可以先限制长度，例如：

const context = selection.slice(0, 1000);

这段代码只解决了长度问题，还没有解决内容是否相关。实际实现中应同时保存来源页面、选择范围和采集时间。用户切换标签页或页面重新渲染后，旧选择可能已经失效，不能悄悄沿用。表单里的密码、支付信息和隐藏字段默认不应进入上下文；如果功能确实需要读取敏感区域，应明确告知用户采集范围。

页面结构适合回答“元素在哪里、能否点击、当前是什么状态”，但不适合直接作为长文本材料。浏览器侧可以先提取语义角色、可见文本、可交互状态和稳定标识，再交给模型判断。样式类名、埋点属性和不可见节点往往只会制造噪声。遇到 Canvas、图表或远程桌面时，截图可以补充视觉信息，不过截图也应裁剪到任务区域，并和页面元素的可操作描述配合使用。

历史记录只保留仍然有效的决定

对话历史里有些信息会持续有效，例如用户选择的语言或任务目标；另一些只是某一步的临时结果。若把所有轮次原样累积，旧错误、过期页面状态和重复内容会逐渐盖住当前请求。更可控的做法是把历史分成稳定偏好、任务计划、已确认事实和临时观察。页面导航后，临时观察应随页面版本一起失效，而不是靠模型自己猜哪些内容过期。

摘要也不能只追求短。摘要需要保留决定的依据、尚未解决的问题和已执行的副作用。例如“已提交表单”与“准备提交表单”只差几个字，后续行为却完全不同。涉及写操作时，程序应保存结构化状态，不要让模型通过自然语言摘要判断是否已经执行。

工具负责取证和行动

上下文告诉模型当前情况，浏览器工具负责读取新状态或执行操作。点击、输入、下载和发送请求都属于有副作用的能力，必须经过目标定位、参数校验和权限判断。模型看到页面文字“点击这里授权”并不构成授权；真正的授权来自用户操作和应用策略。工具结果返回后，还要标注页面是否跳转、元素是否仍存在、操作是否成功，避免模型仅凭一段旧文本继续下一步。

读取工具也不该无限制。若模型每轮都重新抓取整个页面，成本和上下文会一起增长。可以优先读取当前视口与目标元素，找不到时再逐步扩大范围。页面中出现“忽略之前要求”之类文本时，应作为网页内容处理，不能改变系统规则或开放新的工具权限。

用页面变化验证分工

验收时不要只测静态网页。应覆盖单页应用路由切换、异步内容加载、弹窗遮挡、同名按钮、元素卸载后重建和跨标签页操作。每一步记录模型采用了哪些上下文、调用了什么工具，以及工具实际命中的元素。若用户中途修改目标，旧计划应停止；若页面状态与记录不一致，系统应重新读取，而不是强行照旧执行。

清楚的上下文分工会让问题更容易定位：理解错了，检查输入材料；点错了，检查元素定位和工具校验；用了过期信息，检查状态失效规则。把这些责任混在一份不断增长的提示词里，浏览器功能越复杂，行为就越难解释。