别让你的 Agent 绕远路：AI 检索资料的底层逻辑与避坑指南 cover

别让你的 Agent 绕远路：AI 检索资料的底层逻辑与避坑指南

从结构化数据优先到 UI 自动化兜底，梳理大模型检索工具链

最近我一直在想一个很具体的问题：当我们让 AI Agent 搜资料时，到底应该让它用什么？是普通的 web fetch，还是浏览器？是 Chrome MCP，还是 Playwright CLI？Vercel Labs 的 Agent Browser、Browser Use、Stagehand、Computer Use 又分别是什么？

这个问题之所以容易让人混乱，是因为大家常常把几件不同层级的事情放在一起比较。Fetch 是拿网页内容，CLI 是命令行接口，MCP 是工具连接协议，Stagehand 和 Browser Use 更像开发框架或浏览器自动化基础设施，Computer Use 则是让模型看屏幕并操作 UI 的能力。它们不是同一层的替代品。

我想用两个非常日常的例子来讲清楚这件事：

  1. 帮我找少数派今天第一篇文章。
  2. 帮我找少数派今天最火的文章。

这两个问题看起来都只是“帮我搜一下”，但它们背后需要的工具链并不一样。

第一个问题：”今天第一篇文章“，本质是时间排序

如果我问“少数派今天第一篇文章”，这个任务的核心不是打开浏览器，也不是点按钮，而是确定一个时间流。换句话说，AI 要做的第一件事应该是找一个机器可读、按时间排列的信息源。

对这类任务来说，RSS、站点 API、站内文章列表，往往比浏览器可靠得多。少数派官方公开给出过 RSS 地址，所以如果目标是找“今天发布的第一篇文章”，理想路线应该是：先读取 RSS，按时间筛选今天的文章，再根据“第一篇”的口径决定取最早发布还是最新发布，最后打开原文页验证标题、链接和发布时间。

这里根本不需要 Chrome MCP，也不需要 Computer Use。用一个浏览器 Agent 打开首页、等待渲染、滚动页面、识别卡片、再点进文章，当然也可能完成任务，但那是绕远路。一个机器可读的信息源就能解决的问题，优先让 AI 去“看网页”，反而更慢、更贵，也更容易出错。

这也是我现在对资料检索的第一个判断：公开内容优先找结构化来源。RSS、API、sitemap、搜索索引、文章页正文，能解决就不要上浏览器自动化。浏览器是备用方案，不是默认方案。

第二个问题：”今天最火的文章“，本质是热度口径

“少数派今天最火的文章”要复杂得多，因为它不是一个单纯的时间问题，而是一个排序指标问题。这里真正困难的不是“怎么打开少数派”，而是“最火”到底是什么意思。

它至少有三种可能解释。第一种是“少数派官网热门内容里的第一篇”。第二种是“今天发布的少数派文章里，互动数据最高的一篇”，互动数据可能是点赞、评论、收藏或阅读量。第三种是“第三方热榜里少数派当前排名最高的文章”，但这种结果不能直接当成少数派官方定义。

如果默认按“官网热门内容”理解，AI 应该优先尝试读取少数派首页或热门页。如果普通 fetch 能拿到热门内容，就不需要浏览器；如果热门内容由前端动态加载，fetch 拿不到，这时才应该打开浏览器，用 Playwright CLI、Vercel Agent Browser 或类似工具读取页面结构。如果问题被定义成“今天发布文章里互动最高”，那就要先找出今天发布的全部文章，再逐篇获取公开互动数据，最后排序。如果互动数据拿不到，AI 应该说明“无法严格判断”，而不是编一个看起来合理的答案。

这说明第二个原则：工具选择之前，先定义问题口径。很多搜索失败不是因为工具不够强，而是因为问题本身没有定义清楚。AI 如果不知道“最火”按什么算，哪怕给它 Chrome MCP、Browser Use 和 Computer Use，它也只是更努力地不确定。

这些名词到底怎么摆放

把上面两个例子放在一起看，可以得到一张更清楚的地图。AI 搜资料时，工具不是从“高级”到“低级”排序，而是从“离真实数据近”到“离真实数据远”排序。

层级 代表工具或概念 适合什么 不适合什么
结构化来源 RSS、API、sitemap、站内数据接口 最新文章、列表、价格、榜单、公开数据 需要登录、点击、复杂交互的页面
普通网页获取 web search、web fetch、requests、curl 公开文章、文档、新闻、博客正文 动态渲染、反爬、登录后内容
浏览器 CLI Playwright CLI、Vercel Agent Browser、Browser Use CLI shell-first agent 的网页调试、点击、截图、登录态复用 没有命令行环境、需要统一 MCP 管理的客户端
MCP 浏览器工具 Playwright MCP、Chrome MCP MCP-first 客户端里的浏览器能力接入 高频轻量搜索、简单公开资料检索
浏览器 Agent 框架 Stagehand、Browser Use 开发可复用的浏览器自动化流程 临时搜一篇文章
Computer Use OpenAI、Anthropic、Google、Microsoft 的同类能力 没有结构化接口、只能像人一样看屏幕操作的任务 本可通过 API、RSS、fetch 完成的资料检索
成品 Agent Manus、ChatGPT Agent、Gemini Agent Mode 等 用户只说目标，系统自己编排工具 用户想精确控制底层每一步工具调用

其中最容易混的是 CLI 和 MCP。Playwright 官方现在已经把分工说得很清楚：Playwright CLI 更适合 Claude Code、GitHub Copilot、Codex 这类 coding agent，因为它用命令和 skill 控制浏览器，避免把大量工具 schema 和页面结构长期塞进上下文；Playwright MCP 更适合需要持久状态、反复围绕页面结构推理的专用 agent loop。Vercel Labs 的 Agent Browser 也是同一类思路：给 agent 一个浏览器自动化 CLI，用紧凑文本输出、元素引用、截图、网络和 console 等命令，让 shell-first agent 直接操作网页。

Stagehand 和 Browser Use 又是另一层。Stagehand 是基于 Playwright 的浏览器自动化 SDK，它把 Playwright 的确定性操作和 AI 的 act、extract、observe 这类能力结合起来。Browser Use 则更像一个浏览器 agent 框架和基础设施，可以本地跑，也可以使用云浏览器能力。这些东西很强，但它们更适合“我要做一个长期可复用的网页自动化系统”，而不是“我临时查少数派今天最火文章”。

Computer Use 也不是 OpenAI 独有。OpenAI 有 Computer Use API，Anthropic 的 Claude 有 computer use tool，Google 发布了 Gemini 2.5 Computer Use，Microsoft 也把 Computer Use 做进 Copilot Studio。它们的共同点是让模型通过截图理解界面，再输出点击、输入、滚动等动作。这个能力非常通用，但也最重、最慢、最需要安全边界。只要任务能通过 RSS、API、fetch、DOM 或 accessibility tree 完成，就不应该优先走 Computer Use。

本地 Agent 和类 Manus 产品不是同一种心智

前面这些判断，主要适用于本地或半本地的 agent：比如你在 Codex、Claude Code、Cursor、opencode、Workbuddy 里让 AI 做事。这些工具通常能跑 shell，也能装 CLI、MCP、Skill。你需要知道什么时候用 fetch，什么时候用 Agent Browser，什么时候开 Chrome MCP。

但 Manus 这类闭源成品 Agent 不是同一种心智。对 Manus 来说，用户通常不需要说“请用 fetch”或“请用 browser”。产品的价值就在于，它已经内置了搜索、浏览器、文件、Shell、计划、上下文管理和用户确认机制。你只说目标，它自己决定先搜索、再打开网页、再保存文件、必要时让你接管浏览器。

从已知 Manus 相关文档来看，它的浏览器能力并不是单纯的 Chrome MCP，也不是纯粹的 Computer Use。它更像一个产品级的内置浏览器执行层：浏览器访问页面后，会返回可见交互元素、整页 Markdown 内容和带标注的视口截图；如果 Markdown 抽取完整，就不需要反复滚动；如果页面上有没被结构化识别的元素，才可能使用截图或坐标作为兜底。它还有跨任务登录状态和 cookie 持久化，但遇到登录、验证码、个人信息输入、发帖、支付、提交表单等敏感场景，需要用户接管或确认。

更关键的是 Manus 的上下文管理。它不是把所有网页内容、截图理解、搜索结果都塞进上下文里硬扛，而是强调把关键发现写入文件系统。上下文像 CPU 缓存，文件系统像主存；浏览器、图片、表格这些容易在压缩后丢失的信息，应该尽快文本化保存。这样一来，成品 Agent 就能跑更长的任务，而不是在几十轮浏览器操作后忘掉自己之前看到了什么。

所以在 Manus 里，问题不是“我应该让它用 MCP 还是 CLI”，而是“我有没有把任务口径说清楚，有没有设好边界”。比如“少数派今天最火的文章”，你应该告诉它默认按官网热门榜，还是按今天发布文章的互动数。如果涉及登录后台或账号操作，你应该告诉它哪些网站可以访问，哪些动作必须先问你。

用户真正该控制的，不是工具名，而是任务边界

对本地 Agent 来说，我会这样定默认规则：公开资料先用 RSS、API、search、fetch；fetch 失败或页面动态加载，再用 Playwright CLI 或 Vercel Agent Browser；如果你所在的客户端是 MCP-first，再用 Playwright MCP 或 Chrome MCP；Stagehand、Browser Use 适合写长期流程；Computer Use 只做最后兜底。

对 Manus 这类成品 Agent，规则要换一种说法。你不必告诉它“用哪个工具”，你应该告诉它“按什么口径判断，优先使用官方来源，失败后可以逐步升级工具；如果使用第三方榜单，要标明不是官方；涉及登录、发帖、购买、删除、提交等动作，必须先问我”。这比指定底层工具更有效。

比如第一个少数派问题，可以这样说：

帮我找少数派今天第一篇文章。默认按北京时间判断“今天”，请先找官方 RSS 或官方文章列表；如果“第一篇”存在歧义，请区分“今天最早发布”和“今天最新发布”。最后给我标题、链接和发布时间。

第二个问题可以这样说：

帮我找少数派今天最火的文章。默认“最火”按少数派官网热门内容排序；如果官网无法直接判断，再尝试查今天发布文章的公开互动数据。若使用第三方热榜，请明确说明它不是少数派官方口径。不要编造热度指标。

这两个提示词没有指定 MCP、CLI 或 Computer Use，但它们会让一个好的 Agent 更容易走对路径。因为它们控制的是任务定义，而不是工具偏好。

结论：不是选最强工具，而是选最低成本路径

现在很多关于 Agent 工具的讨论都容易变成“CLI 会不会替代 MCP”“Agent Browser 会不会替代 Playwright MCP”“Computer Use 是不是终局”。我现在更倾向于反过来看：Agent 的成熟，不是它每次都能打开浏览器点来点去，而是它知道什么时候根本不该打开浏览器。

“少数派今天第一篇文章”这种任务，最优解往往是 RSS 或 fetch；“少数派今天最火的文章”这种任务，关键是先定义热度口径，再找官方热门榜或互动数据。只有当结构化来源失败、页面必须交互、内容需要登录态，浏览器自动化才应该登场。再往后，CLI、MCP、Stagehand、Browser Use、Computer Use 都只是不同成本和不同控制粒度的工具。

如果你使用的是本地 Agent，你需要懂工具选择，因为你就是那个搭积木的人。如果你使用的是 Manus 这类成品 Agent，你更需要懂任务定义和权限边界，因为工具编排已经被产品隐藏起来了。

最终可以记一句话：

本地 Agent 要研究工具怎么接；成品 Agent 要研究任务怎么说。搜索资料时，先找数据源，再用浏览器，最后才让模型看屏幕。

Reference

tech