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

最近我一直在想一个很具体的问题：当我们让 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 的能力。 它们不是同一层的替代品。

我的结论先放在前面：Agent 检索不是选最强工具，而是选最低成本路径。 搜索资料时，先找数据源，再用浏览器，最后才让模型看屏幕。

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

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

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

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

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

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

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

不过，“今天第一篇文章”本身也有歧义。它可以指今天最早发布的文章，也可以指首页当前显示的第一篇文章，还可以指 RSS 订阅源里的最新一篇。不同口径对应不同数据源，也会得到不同答案。

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

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

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

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

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

实操展示：Manus 和 Codex，同一个问题，两种执行风格

我让 Manus 和 Codex 去找「少数派今天第一篇文章」。这个问题看起来很简单，但实际上有多个可能的口径：

1. 首页当前推荐流的第一篇
2. 今天新发布的第一篇
3. RSS 订阅源里的最新一篇
4. 文章页 metadata 中发布时间最早的一篇

如果不先定义口径，Agent 很容易“找到了一个看起来正确的答案”，但其实回答的是另一个问题。两个 Agent 处理的方式如下图。

Manus 的处理方式更接近一个真实用户在浏览器里操作：它打开少数派首页，观察页面列表，找到首页推荐流里的第一条文章。这个路径很自然，也很符合「帮我看看网页上现在第一篇是什么」这种任务。它看到的是页面当前状态，所以能回答「首页现在把哪篇文章排在前面」。

但这个答案不一定等于「今天新发布的第一篇」。在少数派这个例子里，首页推荐流第一条是《假期出门太折磨？我的 23 条经验帮你规划惬意旅行》。首页给它显示了今天的推荐时间，但进入文章页后可以看到，这篇文章的原始发布时间并不是今天，而是更早的日期。也就是说，它今天出现在首页推荐流里，不代表它今天新发布。

Codex 的处理方式更像程序员在调试数据来源。它先按当前环境日期确认「今天」是哪一天，然后看搜索结果、抓首页 HTML、尝试 RSS/feed，再抽取首页文章列表，并进一步进入文章页核对发布时间。它不是只相信页面上看到的第一个时间，而是把「首页显示时间」「推荐/更新时间」「文章原始发布时间」拆开验证。下面展示了 Codex 的具体操作：

这两个流程的差异不在于谁更高级，而在于它们读取的是不同的数据层：

所以，Agent 搜索的难点不是「能不能打开网页」，而是知道自己正在回答哪个数据层的问题。

在这个例子里，如果我要找「首页现在第一篇」，Manus 的浏览器路径是合理的；如果我要找「今天新发布的第一篇」，Codex 那种先抓结构化数据、再校验文章页 metadata 的路径更稳。

换句话说：

这也是我现在更倾向的判断：与其把 Manus、Codex 这类工具粗暴分成「产品级 Agent」和「开发型 Agent」，不如看它们在具体任务里采用了什么执行策略。

Codex 当然是产品级 Agent。OpenAI 官方把 Codex 描述为能帮助写代码、审查代码、交付代码的 AI agent，并且它可以在终端、IDE、Codex app 和云端环境中工作；同时，Codex 也支持 Skills，让它按团队标准处理代码理解、原型、文档等工作²。

Manus 也可以看成产品级通用 Agent：用户不需要自己接 Playwright、浏览器、抓取工具或代码执行环境，只需要给它任务，它会在自己的运行环境里规划、浏览、执行和交付结果。

但「产品级」并不意味着它一定会选择最低成本路径。成品 Agent 往往优先保证任务完成率，所以可能直接打开浏览器；开发型或 coding agent 则更容易暴露中间过程，也更容易用 RSS、HTML、shell、脚本等方式做数据校验。

因此这个例子真正说明的是：

所以我现在判断 Agent 检索能力时，不再先问它有没有浏览器，而是先看它有没有数据源意识：它知道什么时候该读 RSS，什么时候该 fetch HTML，什么时候才需要打开浏览器，什么时候必须进入文章页核对 metadata。

这些名词到底怎么摆放

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

其中最容易混的是 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¹¹。这里说的 Computer Use 不是某一家产品名，而是一类能力：让模型通过截图、可访问性树或类似 UI 表征理解界面，并输出点击、输入、滚动等动作。不同厂商的实现范围、安全策略和可控粒度并不完全相同。这个能力非常通用，但也最重、最慢、最需要安全边界。只要任务能通过 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 和 Skill 并不冲突。 Codex 可以是产品级 Agent，同时也支持 Skills；Vercel Agent Browser 可以是 CLI，同时又通过 Skill 告诉 agent 该怎么使用它⁵。产品形态、工具接口和使用说明层不是同一件事。更准确的理解是：CLI 负责执行，MCP 负责连接，Skill 负责把工具使用方式沉淀成可复用流程，产品级 Agent 则把这些能力封装成用户只需要描述目标的体验。

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

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

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

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

第二个问题可以这样说：

这两个提示词没有指定 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，你更需要懂任务定义和权限边界，因为工具编排已经被产品隐藏起来了。

最终可以记一句话：

Reference