Claude in Chrome 是如何工作的？

Claude in Chrome有两种工作模式, 一种是独立的AI对话模式, 用户可以在插件里直接下发任务。 另一种是与Claude Code配合, 用户在Claude Code可以使用插件暴露的浏览器能力，使用用户的浏览器完成额外任务。

我们先从第一种模式开始介绍其原理

独立对话模式

逆向插件的工作方式很简单。打开Claude Chrome插件，右击inspect监控插件的网络请求，如图。

我们发现，任务执行过程中会通过不断请求Claude的/v1/messages接口，这是Claude的官方大模型接口(类比ChatGPT的/chat/completions接口)， 从请求体中我们可以拿到system prompt、tools定义。 我已经开源整理在 https://github.com/AIPexStudio/system-prompts-of-claude-chrome

具体的system prompt比较多(40+kb)，我在这里不多做介绍，主要包含：

1. 安全防护

• 防止提示注入攻击（prompt injection）
• 隔离网页内容中的指令，要求用户明确确认
• 防止社会工程学攻击（冒充管理员、紧急请求等）
• 保护用户隐私和数据安全

2. 行为规范

• 拒绝处理有害内容（暴力、色情、恶意代码等）
• 对话风格和格式要求
• 用户健康关怀（心理健康支持）

3. 操作分类

• 禁止操作：处理银行信息、下载不可信文件、永久删除、修改安全权限等
• 需要明确许可的操作：下载文件、购买、输入财务数据、接受协议等
• 常规操作：可自动执行的操作

4. 版权保护

• 不复制受版权保护的内容
• 引用限制（每次最多 15 个词）
• 不提供歌词等受版权保护的材料

5. 工具使用要求

• 使用 read_page 获取页面元素引用
• 优先使用 DOM 元素引用而非坐标
• 高效读取长页面内容

6. 运行环境相关

• 系统信息
• 键盘快捷键

7. 多标签页管理

• 如何获取标签页信息（tabs_context）
• 如何在多个标签页间工作
• 创建和管理新标签页
• 标签页状态管理

8. 响应流程控制

• 在输出响应前调用 turn_answer_start
• 确保响应流程的正确性

其中 tools 包含以下工具，按功能分类如下：

1. 页面读取与导航（Page Reading & Navigation）

2. 交互与自动化（Interaction & Automation）

3. 标签页管理（Tab Management）

4. 媒体与文件（Media & Files）

5. 调试与监控（Debugging & Monitoring）

6. 实用工具（Utilities）

7. 自定义工具（Custom Tools）

claude chrome插件组合这些负责页面的理解、点击、填写表单、截图、调试的工具，就能完成复杂的人物。 其中update_plan和turn_answer_start是自定义工具，会在插件里有独特的UI展示。update_plan会请求用户Approve Plan或者Make Changes, turn_answer_start会请求用户二次确认任务开始。图为update_plan的UI展示。

与Claude Code配合模式

Claude Chrome 请求了 nativeMessaging 的权限，这个权限允许扩展与本地应用程序进行双向通信。通过这个权限，Claude Chrome 可以与安装在用户电脑上的 Claude Code（或其他支持 Native Messaging 的应用程序）建立连接。

Native Messaging 的工作原理

1. 权限申请：扩展在 manifest.json 中声明 nativeMessaging 权限
2. 本地应用注册：Claude Code 在系统中注册为 Native Messaging Host
3. 建立连接：扩展通过标准输入输出（stdin/stdout）与本地应用通信
4. 消息传递：使用 JSON 格式的消息进行双向数据交换

与 Claude Code 的协作流程

┌─────────────────┐         ┌──────────────────┐         ┌──────────────┐
│  Claude Code    │ ◄─────► │  Native Messaging │ ◄─────► │ Claude Chrome│
│  (本地应用)      │   JSON   │  Host (桥接层)    │   JSON   │  (浏览器扩展) │
└─────────────────┘         └──────────────────┘         └──────────────┘

工作流程：

1. Claude Code 发起请求：用户在 Claude Code 中请求执行浏览器操作
2. 消息传递：Claude Code 通过 Native Messaging 将请求发送给 Claude Chrome 扩展
3. 扩展执行：Claude Chrome 扩展在浏览器中执行相应的操作（如点击、填写表单等）
4. 结果返回：操作结果通过 Native Messaging 返回给 Claude Code
5. 展示结果：Claude Code 将结果展示给用户

此时， Claude Chrome扩展就不再是个Agent，而只是作为MCP server将浏览器工具暴露给Claude Code， 由Claude Code去进行使用。

上下文效率

我尝试使用Claude in Chrome跑了官方给的样例

Navigate to Zillow and find me a 2-bedroom apartment in San Francisco under $4000/month. Filter for places available within the next 30 days and show me the top 3 options with photos.

我发现他运行了10分钟才执行完成，于是我就看了下这个过程中哪里出了问题。发现claude chrome插件主要用两种模式去理解页面， 一种是使用页面的无障碍树，在无障碍达成不了目标时会使用截图。

很多人可能对无障碍树没有概念，我稍微介绍一下。

无障碍树（Accessibility Tree）是浏览器为了支持辅助技术（如屏幕阅读器）而构建的页面结构表示。它包含了页面上所有可交互元素的语义信息，比如：

• 元素角色：按钮、链接、输入框、标题等
• 元素属性：名称、描述、状态（是否禁用、是否选中等）
• 层级关系：元素之间的父子关系和顺序
• 文本内容：元素的可读文本

相比直接解析 DOM 树，无障碍树提供了更简洁、更语义化的页面表示。对于 AI 来说，无障碍树比原始 HTML 更容易理解，因为它已经过滤掉了大量样式和布局相关的信息，只保留了功能性的语义信息。 但无障碍树是有局限性的，依赖于网站的无障碍树构建是否完善，如果网站的无障碍树构建不完善，可能会导致无障碍树的表示不准确，从而影响AI的理解。

这里我发现claude chrome的一个问题是对于同一个页面的多次快照，都保存在了上下文中，但其实过去的快照是无意义的，可以丢弃的。并且，claude in chrome会将整个页面的无障碍树 放进上下文，在对长页面进行任务时，上下文会迅速爆炸。

另一个问题是claude in chrome在无障碍树失败时会使用截图，然而一次截图多大呢，100kb-500kb不等，我这次任务截图是335kb。 这样的一张截图信息会一直存在于后续的上下文中，上下文的爆炸从而引起任务的慢、无效以及贵。 其实大可不必把截图信息原封不动放进上下文，为了理解页面其实可以先降低清晰度，处理之后放进上下文。AIPex的经验是可以压缩10-20倍。

当然了，claude是首个提出上下文工程的，我相信不久之后插件的上下文优化算法也会上线，敬请期待。

交互体验

claude in chrome的UI让人非常舒服，用户可以记录workflow并进行编辑，下一次直接用命令唤起。Claude in Chrome的一个卖点是说自己支持后台运行， 但其实claude in chrome的操作都依赖于debugger权限，而debugger权限在被使用时，浏览器一定会获取用户焦点，强制展示在最前端，这就使得“后台运行”成为无稽之谈。 有个做法是不使用debugger，但这样的话需要自己抛弃无障碍树、以及用其他方式完成点击、输入等操作。

为什么我推荐你尝试AIPex？

本来是抱着学习的心态使用并逆向了Claude in Chrome插件，但在跑完第一个用例之后，我就明白了这个插件目前的上下文效率是存在很大问题的，那会导致任务的慢和低效。 AIPex已经走过这些坑，并在上下文工程上做了很多工作，同一个任务AIPex能比claude in chrome至少快2倍以上，任务越复杂越明显。AIPex的上下文核心实践已整理在了https://www.claudechrome.com/zh/blog/ai-browser-automation-challenges. 同时AIPex支持BYOK，你可以用自己的大模型密钥免费尝试。

References

1. https://x.com/pk_iv/status/2005694082627297735