你在用 Claude Code 或者自建 Agent 抓网页、填表单、跑自动化的时候，可能没意识到：海外社区已经为「AI 浏览器到底能不能安全地替人上网」这件事吵了半年多，而且到今天都没吵出共识。这不是未来的问题——ChatGPT Atlas、Perplexity Comet、Dia 这些「Agent 浏览器」已经装进了几千万人的电脑，安全研究圈却在反复警告：这类产品的底层缺陷，可能根本修不好。这篇文章带你把这场大战的来龙去脉、三方观点、以及已经跑通的防御姿势一次看明白——重点是，这些坑你自建的 Agent 一样会踩，而且国内讨论得还很少。
先补个时间线。这场仗的导火索是 2025 年下半年密集爆发的「AI 浏览器」产品潮：
产品形态大同小异：浏览器侧边栏住着一个 Agent，你用自然语言下指令，它替你开页面、点按钮、填表单。The Browser Company 甚至直接放弃了 Arc，全力转向 Agent 浏览器 Dia。
听起来很美好，对吧？问题出在两个月前的一次安全实验上。
2025 年 8 月，Brave 的安全研究团队（Brave Research）发了一篇博客，演示了对 Comet 的间接提示注入（Indirect Prompt Injection）攻击：在一个网页里藏一段人眼看不见的恶意指令（比如隐藏文本、图片 alt 属性），Comet 的 Agent 读到这段指令后，会把它当成「用户的命令」执行——跟着指令去访问你的邮箱、抽取隐私数据，然后把数据发到攻击者控制的外部地址。整个过程用户毫无感知。Brave 做了负责任的披露，Perplexity 也很快打了补丁，但 Brave 在报告里点破了关键：这类攻击的形态千变万化，堵住一个漏洞，下一种变体马上出现，这不是某个 bug，而是架构层面的问题。
把这个问题讲得最透的，是安全圈无人不知的 Simon Willison。他提出了一个概念叫 「致命三要素」（The Lethal Trifecta）：一个 AI Agent 只要同时满足这三个条件，就必然存在被提示注入攻击的空间——
三要素同时成立的系统，恶意指令就可以走「外部内容进来 → 误当命令 → 带着私有数据出去」这条完整链路。而 Agent 浏览器，恰恰是三要素全满的产品：它天生要读网页、天生有你的登录态、天生能发请求。
Willison 的结论在社区里争议极大：提示注入至今没有可靠的通用修复手段，任何声称「我们已经解决了提示注入」的宣传都值得怀疑。唯一安全的工程路线，是主动拆掉三要素中的一环。这条推文/博文在 HN 和 Reddit 上被反复翻出来讨论了大半年，支持者和反对者的辩词都非常精彩。
厂商阵营（乐观派）：OpenAI 在 Atlas 的发布说明里强调，Agent 模式针对提示注入做了多层防护，并且对银行等金融敏感站点采取了「默认不代操作」的策略；Anthropic 则把 Claude for Chrome 定位成「研究预览」，同步公开了自己的提示注入评估方法和分类器防护数据，姿态是「我们知道问题存在，正在边造边测」。厂商的共同话术是：风险真实存在，但可以靠工程手段收敛。
安全研究阵营（悲观派）：Willison、Brave Research 等反复强调，提示注入和 SQL 注入有本质区别——SQL 注入可以用参数化查询这种「写对了就没事」的方案根治，而提示注入的本质是：语言模型无法从数学上区分「数据」和「指令」，页面上的文字就是模型上下文的一部分。只要还用单模型直接读不可信内容，就不存在「写对了就没事」。这一派甚至认为 Agent 浏览器的产品形态本身就是错的，应该推倒重来。
务实派（中间路线）：Google DeepMind 的研究团队在 2025 年发过一篇论文叫《CaMeL: Defeating Prompt Injections by Design》（可在 arXiv 上检索标题获取），思路是双 LLM 架构——一个「有权限的 LLM」负责执行，一个「无权限的 LLM」负责读不可信内容，中间用系统级的控制流和数据流约束隔开，相当于把安全从「靠模型自觉」升级成「靠架构保证」。这一派的观点是：通用解不存在，但针对具体场景的系统级方案是可行的，只是会牺牲一部分 Agent 的自由度。
值得一提的是，OWASP 已经把提示注入列为 LLM 应用十大风险的第一名（LLM01），这个问题早已不是学术讨论，而是所有做 Agent 产品的团队必须过的合规关。
flowchart TD
A["不可信网页<br/>藏了隐藏指令"] --> B["AI浏览器阅读页面"]
B --> C["指令被当成<br/>用户的命令"]
C --> D["Agent翻出<br/>你的私有数据"]
D --> E["打包发往<br/>攻击者的服务器"]
F["防御1：敏感站点<br/>强制人工确认"] -.->|掐断| C
G["防御2：只读模式<br/>禁止对外发请求"] -.->|掐断| E
H["防御3：会话隔离<br/>数据不出沙箱"] -.->|掐断| D
这张图的核心思想是 Willison 那句话的工程化翻译：你不需要同时打赢三场仗，只要在任意一环把链路掐断，攻击就不成立。这也是目前社区已经跑通的三个防御姿势的底层逻辑：
| 你以为 | 实际上 |
|---|---|
| AI 浏览器就是换壳 Chrome | 真正的战场是 Agent 权限边界，三要素全满的产品形态存在结构性风险 |
| 提示注入是 prompt 问题，写好系统提示词就能防 | 主流安全圈共识：这是架构问题，模型层面无法根治 |
| 出事了是厂商的锅，与我无关 | 你自建的爬虫 Agent、MCP 数据管道、RAG 系统一样在踩同一个坑 |
| 防御无从下手 | 拆掉「致命三要素」任意一环即可：人工确认 / 降权 / 隔离，三选一立刻能落地 |
| 这是海外的事 | Atlas、Comet 靠插件就能在国内浏览器环境跑起来，而国内 Agent 产品的安全审计讨论还非常少 |
一句话收尾：Agent 浏览器这场仗，表面上争的是「AI 能不能替你点鼠标」，实际上争的是「指令和数据的边界能不能被机器理解」。这个问题一天不解决，所有让 AI 读网页的产品——包括你自己写的那一个——都在裸奔。先给它们穿上裤子，再谈自动化。
注：文中产品发布时间为 2025 年公开信息；本文撰写环境网络受限，未能实时核验 2026 年 9 月最新进展，相关时间点与结论建议以参考来源原文为准。
本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵爱卫生（微信ID: gprshome201101）维护。 聚焦5G/6G核心网、3GPP标准、AI工具实战。知识星球「51学通信」提供深度技术答疑和行业洞察。
[!tip] 51学通信知识星球 星主：爱卫生（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 星球定位：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 当前规模：5200 篇主题 / 990 个回答，198 元/年。 加入福利：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 AI 加持：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。