给 Agent 装上眼睛和手：Agent Reach 与 agent-browser 深度解析

引言

2026 年的 AI Agent 竞争，已经从前几年的"谁的模型更聪明"，转向"谁能在真实世界里把事做成"。模型能力在快速商品化，真正拉开差距的是 Agent 与外部世界之间的那一层接口：它能不能读到登录墙后面的内容，能不能点开一个按钮、填完一张表单、提交一次订单。

现实却很骨感。大多数 CLI Agent（Claude Code、Codex、OpenClaw 这一类）出厂自带的能力只有通用网页搜索和简单抓取。一旦碰上需要登录的小红书、只有字幕才有信息的 B 站视频，或者一个必须点三步才能提交的后台系统，Agent 就原地卡住了。

今天介绍的两个项目，恰好补上这两块短板：Agent Reach 负责"看得到"，agent-browser 负责"做得动"。两者都是 CLI 形态、都把复杂状态收进本地，思路值得借鉴，也能直接拿来用。

一、Agent Reach：把散落的互联网渠道收进一条命令

• 项目地址：https://github.com/Panniantong/Agent-Reach
• Star 数：约 108K（2026-11 初）
• 语言 / 许可：Python 3.10+，MIT

Agent Reach 的定位一句话就能说清：让 Agent 够得着它自己上不去的互联网。它不是一个新爬虫，而是一层"渠道抽象"——把每个平台背后的工具替你装好、测好，再统一成 agent-reach <渠道> <动作> [参数] 这一种调用方式。

它不是靠某个接口硬扛，而是给每个平台的每个动作维护一份有序工具列表：首选工具失败就自动切到备选。比如读 B 站视频先用 bili-cli，失败再走公开接口；读网页先用 Jina Reader，再退到 Exa。平台改版、工具失效是常态，换工具只是调整这个列表，Agent 侧的命令不变。这个设计比"写死一个 API"务实得多。

当前渠道分三档：

安装方式很有代表性——不是让你背命令，而是把安装文档链接丢给 Agent，让它自己读完装完：

帮我安装 Agent Reach：https://raw.githubusercontent.com/Panniantong/Agent-Reach/main/docs/install.md

底层依赖 uv，所有东西（各渠道工具、登录态、配置）都收在 ~/.agent-reach/ 一个目录里，升级和卸载都很干净。装完可以直接验证：

agent-reach channels                          # 有哪些渠道、各自能做什么
agent-reach bilibili search "大模型"           # 搜索
agent-reach read https://www.v2ex.com/t/123   # 按链接自动选渠道

安全边界是这个项目最值得称道的部分：只读，不发帖、不评论、不点赞、不私信；从不替你登录也不要密码；需要登录的平台用专用浏览器在后台运行，首次使用只复制你 Chrome 里该网站的登录态（不读密码库），且专用浏览器只对本机开放。官方也明确建议用小号登录。对一个要接管你账号环境的工具来说，这种"最小权限 + 明确边界"的自我约束比功能数量更重要。

简要评价：中文平台覆盖是它最大的差异化优势（小红书、B 站、雪球、V2EX 这些通用搜索几乎拿不到的地方），"首选 + 备选"的降级链和只读定位让它在不稳定环境里依然可用。代价是可选渠道需要登录态、实验渠道随时可能挂，属于"能用但不承诺 SLA"的类型。

二、agent-browser：把浏览器变成 Agent 的一只手

• 项目地址：https://github.com/vercel-labs/agent-browser
• Star 数：约 45K（2026-11 初）
• 语言 / 许可：Rust CLI，Apache-2.0（Vercel Labs 出品）

如果说 Agent Reach 解决"读",agent-browser 解决"操作"。它的核心循环非常克制：快照 → 决策 → 动作 → 再快照。

agent-browser open example.com
agent-browser snapshot -i       # 只输出可交互元素，每个带一个 ref
agent-browser click @e1         # 对 ref 执行动作
agent-browser get url           # 核对结果
agent-browser close

snapshot 会把页面压成一段紧凑文本，给每个元素分配 @e1 这样的引用。Agent 不需要理解 DOM 结构，也不需要为每个网站写选择器，只要读文本、点引用。这个抽象层的价值在于：把"网页"翻译成了 LLM 最擅长的形式——短文本 + 明确 ID。

架构上，CLI 把每条命令发给一个后台 daemon，daemon 通过 Chrome DevTools Protocol 控制浏览器。浏览器在多次命令之间保持打开，所以每一步都是一次很短的 shell 调用，不需要每次重启浏览器。每个 --session 有独立 daemon 和浏览器，无命令一小时后自动关闭，并支持会话持久化。

几个实现细节很能说明它是"为 Agent 设计"的：

• 失败就报失败。点击目标被遮挡、禁用、在视口外时，命令直接失败而不是返回一个假的"成功"，逼 Agent 重新快照再试。这比很多自动化工具默认"尽力而为"的行为可靠得多。
• 移植现成技能。agent-browser skills get core 会输出与当前版本匹配的操作手册，还能通过 npx skills add vercel-labs/agent-browser 装进各种 Agent harness。
• MCP 不是唯一入口。agent-browser mcp 可以起 stdio MCP server，但也保留了纯 CLI 路径，成本和灵活性更好控制。
• 可换引擎和云端。默认 Chrome for Testing，也能接 Lightpanda、iOS 模拟器里的 Mobile Safari，或 Browserbase 等云浏览器。

安装：

npm install -g agent-browser
agent-browser install          # 首次下载 Chrome for Testing
# 或 brew install agent-browser

简要评价：它把"浏览器自动化"从 Playwright 式的编程 API，变成了 Agent 可以直接消费的单步命令，这个方向是对的。局限也清楚——ref 只对快照那一刻有效，页面一变就要重取；对强风控站点，headless 浏览器依然会被识别。它是"手"，不是"通行证"。

三、放在一起看：读与做的分工

两者共享同一套设计哲学，这也是 2026 年 Agent 工具层最明显的变化：

1. CLI-first：一条命令一个动作，Agent 用 shell 就能驱动，不必为每个工具写一套 SDK。
2. 输出为 LLM 优化：紧凑文本、结构 JSON、稳定 ID，而不是给人看的富文本。
3. 状态本地化：登录态、会话、配置都收在单一目录或 daemon 里，可迁移、可清理。
4. 显式失败：宁可报错让 Agent 重试，也不返回模糊的成功。

对比模型层的军备竞赛，这一层其实更值得投入——同样是 GPT 级模型，接不接得上真实世界，产出差距是数量级的。

总结

两个项目不是替代关系，而是接力关系：

• 做情报聚合、舆情监控、内容研究：优先 Agent Reach。一条命令拿到 B 站字幕、小红书笔记、V2EX 讨论，成本极低。
• 做端到端流程自动化、表单填写、前端回归测试：优先 agent-browser。ref-based 的交互模型对 Agent 最友好。
• 做完整闭环：先让 Reach 找到目标链接和背景资料，再让 browser 打开页面完成操作，最后用 Reach 读取结果做校验。

如果你正在搭自己的 Agent harness，这两个仓库最值得抄的不是代码，而是它们对"工具应该长什么样"的答案：给 Agent 的工具，要短、要稳、要能失败、要能降级。