最近这段时间，我一直在反复用 Claude Code、Codex 这类 AI 工具去做真实浏览器任务。
一开始我觉得问题只是它能不能把任务做完。后来我越来越在意另一件事：
同一个网页任务，昨天明明已经做成功了，今天它还是要重新探索一遍。还是要重新读页面、重新找按钮、重新确认入口、重新消耗 token。
这件事让我觉得很不对劲。
如果 AI 已经学会过一次一个站点上的发帖流程、填写流程或者后台操作流程，为什么第二次还要像第一次一样从零开始？
所以我后来做了 AgentLimb。
它是一个本地运行的 Chrome 插件，外加一个本地 bridge。目标不是单纯让 AI 会操作浏览器，而是让 AI 在浏览器里的重复任务真正形成一种可复用的 muscle memory。
一句话说，就是：第一次探索，后面直接重放。
这件事真正解决的，不是自动化，而是重复探索
现在很多浏览器自动化方案其实都能完成任务。
但如果你真的连续用几天，就会发现一个很现实的问题：
- 重复任务的成本降不下来
- 每次都要重新理解页面
- 登录态和真实会话很难复用干净
- 页面稍微复杂一点，AI 就会在看图猜按钮和反复试 selector 之间来回浪费 token
我自己最在意的不是任务失败，而是明明做过，还得再学一次。
所以 AgentLimb 的核心设计不是做一个新的 headless 浏览器，也不是做一个云端 RPA 平台，而是把 AI 第一次探索浏览器任务时学到的东西沉淀下来。
AgentLimb 现在的结构其实很简单
目前公开版本里，核心是三层：
-
你的 AI 工具
比如 Claude Code、Cursor、Codex、Windsurf，只要它能跑命令或者能接 HTTP / MCP，就能接进来。 -
本地 bridge
一个跑在127.0.0.1:7791的本地 Node.js bridge，负责把 AI 的调用转成浏览器可执行的动作。 -
Chrome 扩展
一个 MV3 扩展，带 side panel，用来承接任务状态、muscle、日志，以及和真实浏览器页面交互。
它没有 cloud bridge，也不走远程浏览器。它直接在你正在使用的真实 Chrome 上工作，沿用你当前的登录状态、Cookie、扩展环境和会话。
这件事在很多真实场景里很关键。因为很多自动化流程的问题，从来不是能不能打开网页，而是能不能在真实账号、真实权限、真实 session 里稳定完成事情。
我为什么坚持用真实 Chrome，而不是截图流或者 headless 流
我后面越来越确定，浏览器自动化如果要服务真实工作流，不能只靠截图猜。
截图流最大的问题不是它不能用，而是它每一步都太贵了，也太容易在复杂页面里变得不稳定。
所以 AgentLimb 现在的方向更偏 CDP-native：
- AI 先拿到结构化的页面状态
- 能读真实 DOM 和可交互元素
- 点击和输入尽量走更原生的浏览器能力
- 导航和页面变化也尽量拿到明确反馈
这样做的好处很直接：
- 不用每一步都靠截图理解页面
- 不用每一步都重新看图推理
- 选择器、流程和页面知识更容易沉淀成可以复用的 muscle
这个结构比纯截图加坐标点击更像一种长期可积累的浏览器知识层。
muscle 这件事，是我做这个插件时最想验证的点
AgentLimb 里最有意思的部分其实不是点击按钮，而是 muscle。
我的想法很简单：当 AI 第一次在某个站点上把任务做通之后，不应该只留下这次成功了这个结果，而应该把成功路径本身保存下来。
所以现在它会把一些和站点相关的知识写到桌面的目录里：
~/Desktop/AgentLimb-muscle/<domain>.json
这些文件是可读的 JSON，不是黑盒。里面存的是这个站点上已经验证过的一部分知识，比如：
- selectors
- workflows
- notes
这意味着第二次再做同站点任务的时候，AI 不需要从 0 重新探索，而是可以先 recall，再决定要不要补探索。
我自己很喜欢这个设计的一点是：它不绑定某一个 AI 工具。今天 Claude Code 学出来的 muscle，明天 Codex 可以直接复用；以后如果换别的支持 HTTP/MCP 的工具，也还是同一套 JSON。
真正让我确定这个方向对了的，是 token 对比
在公开 README 里，我放了一组我觉得很关键的数据。
同样是一个 Reddit 发帖任务：
- 冷启动第一次探索：
23次工具调用，约12,250 tokens - 记忆加载后的热启动：
10次工具调用，约1,750 tokens
按这组回归数据看，token 大约下降了 85.7%。如果把等待时间也算进去，重复任务的墙钟时间也会明显下降。
我现在更愿意把它理解成：AgentLimb 不是在把每次任务做得更聪明，而是在把第二次、第三次、第四次做得越来越便宜。
这个差别很重要。因为浏览器自动化真正值钱的地方，本来就不在第一次，而在重复。
side panel 也是我后来补得很重的一层
另一个我自己很在意的点，是任务生命周期必须是显式的。
很多 AI 工具在做浏览器任务的时候，最难受的地方不是慢，而是你不知道它现在到底是：
- 还在执行
- 卡住了
- 超时了
- 其实已经失败了，只是没有明确告诉你
所以 AgentLimb 现在会把任务过程拆成一套比较显式的状态流：
task_plan -> task_step_done -> task_complete / task_fail
这样 side panel 里能直接看到：
- 它准备做什么
- 当前做到第几步
- 哪一步出错
- 任务到底是成功、失败还是超时
我觉得这层看起来像 UI 细节，但其实很关键。因为只要任务状态不透明，AI 浏览器自动化在真实工作里就很难让人放心长期使用。
这类工具到底更适合谁
我现在自己的判断是，AgentLimb 最适合的不是所有人，而是几类非常具体的人：
- 已经在用 Claude Code / Cursor / Codex 做真实任务的人
- 有重复网页登录态流程的人
- 做增长、运营、发帖、提交流程的人
- 做真实浏览器 QA 和验证的人
因为这些人的痛点不是我想让 AI 第一次帮我点按钮，而是：我不想让 AI 每天都重新学一遍昨天已经会的事情。
最后
我做这个插件花了不少心力，但到现在为止，我觉得最值得继续押注的不是 AI 会不会更强，而是浏览器里的重复知识，能不能被稳定沉淀下来。
如果这件事成立，那么浏览器自动化的成本模型会变。它不再是每次都线性付费、线性等待，而是会随着使用次数增加越来越便宜。
这也是我现在继续做 AgentLimb 的原因。
如果你也在做 AI + 浏览器自动化，或者你现在就在用 Claude Code / Codex 重复做网页任务，我很想知道：你最希望 AI 不要再重复学的那个浏览器流程是什么？
GitHub： github.com/hooosberg/A…
官网： agentlimb.com/