浏览器 Agent 最吸引人的地方，是它看起来像一个能操作网页的人。
它可以打开网页、读取内容、点击按钮、填写表单、比较信息、生成总结。演示视频里，它像一个不知疲倦的实习生，在多个网站之间替用户完成任务。
但 Google 披露并拦截 AI 辅助零日漏洞攻击之后，我们需要重新审视 Agent 的安全边界。因为同样的 AI 能力，既可以帮用户自动完成任务，也可以被攻击者用于自动探测、生成脚本、组织攻击步骤。浏览器自动化越强，越不能只看能不能跑。
Agent 工程的核心问题，不是它会不会点击，而是它什么时候不能点击。
真实网页环境非常复杂。一个页面可能包含登录态、支付按钮、删除按钮、管理后台入口、客户隐私、内部数据、自动提交表单。Agent 如果只是按照模型规划一路执行，很容易出现越权、误操作和数据泄露。
所以开发者设计浏览器 Agent 时，应该先定义动作风险，而不是先堆功能。
可以把动作分成三类。
第一类是低风险动作：读取页面、总结文本、提取标题、整理公开信息。这类动作通常可以自动执行，但仍然需要记录来源。
第二类是中风险动作：填写表单、生成草稿、准备邮件、选择选项。这类动作可以由 Agent 完成，但提交前要让用户确认。
第三类是高风险动作：提交订单、发送邮件、删除数据、修改配置、确认付款、发布内容。这类动作不应该自动执行，必须由人点击确认。
一个最小的风险判断结构可以这样写：
type AgentAction = 'read' | 'extract' | 'type' | 'click' | 'submit' | 'delete';
type AgentStep = {
action: AgentAction;
target: string;
risk: 'low' | 'medium' | 'high';
needHumanConfirm: boolean;
reason: string;
};
function canAutoExecute(step: AgentStep) {
if (step.risk === 'high') return false;
if (['submit', 'delete'].includes(step.action)) return false;
if (step.needHumanConfirm) return false;
return true;
}
这个逻辑很简单，但它代表了一个重要原则：Agent 的执行权不能完全交给模型。模型可以提出下一步，但系统必须有硬边界。
很多 Agent Demo 最大的问题，是只展示成功路径，不展示失败路径。真实产品里，失败才是常态。按钮找不到怎么办？页面加载超时怎么办？弹窗遮挡怎么办？用户未登录怎么办？验证码出现怎么办？模型不确定怎么办？页面里的按钮文案和预期不一致怎么办？
如果没有失败恢复，Agent 就只能停留在演示阶段。
一个更完整的 Agent 状态可以这样设计：
type AgentState = {
goal: string;
currentStep: string;
pageSnapshot: string;
retryCount: number;
lastError?: string;
riskLevel: 'low' | 'medium' | 'high';
needsUserInput: boolean;
};
失败时，不应该简单重试，而应该先进入判断：
当前步骤失败。
请根据页面状态判断：
1. 失败原因可能是什么？
2. 是否可以安全重试？
3. 是否需要换路径？
4. 是否涉及高风险动作？
5. 是否需要用户确认？
然后系统根据结果决定是否继续。
这里还要注意一个问题：模型的判断不能直接成为最终权限。不能让模型自己说“这是低风险”，系统就相信。风险分类应该由产品规则和代码共同控制。比如凡是 submit、delete、payment、publish、send 这类动作，默认高风险；凡是涉及用户隐私或业务后台，默认需要确认。
Agent 安全的第二个关键，是可观测性。
如果 Agent 执行失败，开发者需要知道它看到了什么、为什么选择某个按钮、执行了什么动作、什么时候进入重试、为什么要求用户确认。没有日志，就无法调试，也无法建立用户信任。
可以把每一步记录成结构化日志：
{
"step": "fill_form",
"target": "email_input",
"action": "type",
"risk": "medium",
"reason": "用户要求生成邮件草稿，但未发送",
"result": "success"
}
这类日志不只是给工程师看的，也可以在用户界面里简化展示，让用户知道 Agent 正在做什么。
Agent 安全的第三个关键，是输入数据最小化。
浏览器里有很多信息，并不是完成任务所必需的。Agent 不应该把整个页面、所有 Cookie、所有表单内容都交给模型，而应该提取完成任务所需的最小上下文。比如做网页摘要，只需要正文；做价格对比，只需要商品名、价格、库存、时间；做表单草稿，只需要字段标签和用户提供的信息。
数据给得越多，模型越容易误用，风险也越高。
Google 关闭 Project Mariner 后，相关能力被整合进 Gemini Agent、AI Mode 等方向。这说明浏览器 Agent 方向并没有消失，而是在从单独 Demo 进入更大的产品体系。越是产品化，越需要安全边界。
如果你想测试不同模型在网页理解、任务规划和安全判断上的表现，可以把 gpt985.com 作为多模型体验入口。开发者可以用同一组任务比较不同模型：谁更少幻觉，谁更能识别高风险动作，谁在失败恢复中更稳，谁能输出更规范的结构化计划。
但无论哪个模型，都不应该拥有无限执行权。
我建议新 Agent 项目从低风险场景开始，比如网页摘要、资料整理、多页面对比、表单草稿、操作前确认摘要。这些场景能验证模型理解能力，又不容易造成真实损失。等到观察、规划、执行、评估和恢复机制稳定后，再逐步增加更复杂的动作。
Agent 的未来很有想象力，但真正能进入生产环境的，不是最炫的 Demo，而是最可控的系统。
总结一句：浏览器自动化不能只看能不能跑。它必须知道什么时候停、什么时候问、什么时候拒绝执行。AI 进入攻防时代后，Agent 安全不再是附加项，而是产品设计的第一层。
为什么 Agent 安全要前置到产品设计阶段
很多团队做 Agent 时，会先追求能力闭环：能打开网页，能读内容，能点按钮，能生成结果。等到功能差不多能演示了，才开始想安全问题。这种顺序是危险的。Agent 和普通文本生成不同，它会影响真实环境。只要涉及浏览器、账号、表单、邮件、支付、后台配置，安全就不是后置补丁，而是产品架构的一部分。
第一个要前置的是权限模型。Agent 是否能访问当前页面？是否能读取隐藏字段？是否能跨站点带着上下文继续执行？是否能在用户未确认时提交表单？这些问题不能留给模型判断，必须由系统规则控制。
第二个要前置的是确认机制。很多动作看起来只是“下一步”，但可能有真实后果。比如点击“发送”会发出邮件，点击“删除”会移除数据，点击“确认”可能提交订单。Agent 可以准备这些动作，但执行前要让用户看到摘要：将要操作什么、影响什么、是否可撤销。只有用户确认后，系统才执行。
第三个要前置的是回放能力。Agent 出错时，如果没有步骤日志，工程师只能猜。一个可用系统至少要记录观察内容、模型计划、执行动作、失败原因、重试次数和人工确认点。这样不仅方便调试，也方便用户理解为什么系统停下来。
第四个要前置的是最小上下文。不要把整个浏览器状态都塞给模型。做页面摘要，只给正文；做价格对比，只给商品名、价格、库存；做表单草稿，只给字段名和用户提供的信息。上下文越少，越容易控制风险，也越容易评估输出质量。
这就是为什么我认为新 Agent 产品不应该先追求全自动，而应该先追求可控。能自动执行十步但不可解释，不如只执行三步但每一步都可验证。真正能长期使用的 Agent，不是最像人的 Agent，而是最懂边界的 Agent。
评估 Agent，不要只看演示视频
一个 Agent 是否可用，至少要看五个指标。第一是任务完成率，同一类任务在不同页面、不同网络状态下能否稳定完成。第二是误操作率，它是否会点击不该点击的按钮。第三是人工确认覆盖率，高风险动作是否都经过确认。第四是可观测性，用户和开发者是否能知道它每一步做了什么。第五是恢复能力，失败后是否能解释原因并安全停止。
很多演示只展示一次成功任务，这不足以证明产品可用。真正的测试应该准备一组异常页面：按钮缺失、弹窗遮挡、登录过期、字段变化、网络超时、页面多语言、表单校验失败。Agent 在这些情况下的表现，才决定它能不能进入真实产品。
如果一个 Agent 不会停，它就不适合处理真实任务。停下来不是失败，错误地继续执行才是失败。
一个更适合落地的路线
如果我是掘金读者，我会更关注这个方案能不能落地。Agent 安全不是一句“加人工确认”就结束了，而是要体现在动作分类、状态管理、失败恢复、日志记录和最小上下文上。开发者愿意看这样的内容，是因为它能转化成产品设计和代码结构。
对新团队来说，可以先做三个低风险 Agent 能力。第一，网页摘要，只读取正文，输出标题、摘要、关键事实和缺失信息。第二，表单草稿，只生成填写建议，不自动提交。第三，操作前摘要，在用户确认之前列出将要执行的动作和可能影响。
这三个能力看起来不如全自动浏览器助手炫，但更容易进入真实产品。它们有明确输入、明确输出、明确人工确认点，也更容易测试。等这些能力稳定之后，再加入更复杂的任务规划和多步执行。
工程上，先可控，再自动；先可验证，再扩展；先低风险，再高风险。这比一开始追求全自动更符合产品落地规律。
如果我是开发者，我不会只看某个 Agent Demo 是否跑通，而会拿同一组网页任务去测试不同模型：谁更能识别高风险动作，谁的结构化输出更稳定，谁在失败恢复时更可靠。需要集中体验 ChatGPT、Claude、Gemini、Grok 等模型时，可以把 gpt985.com 作为多模型入口。把模型放进真实任务里测，才比看宣传图和跑分更接近工程判断。
