Home

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

从 RSS、fetch 到浏览器和 Computer Use，我最后发现，工具怎么选，得从“我究竟在查什么”说起。

最近我为了一个很小的问题，在好几种工具之间来回折腾：让 AI Agent 搜资料，到底该用普通的 web fetch，还是直接开浏览器？Chrome DevTools MCP 和 Playwright CLI 有什么区别？Agent Browser、Browser Use、Stagehand、Computer Use 又该放在哪里？

后来我发现，这些东西之所以越比较越乱，是因为它们本来就不在同一个维度。RSS 和 API 是数据源，fetch 是获取网页的方式，CLI 和 MCP 是工具接口，Stagehand、Browser Use 是自动化框架或服务，Computer Use 则是一种操作界面的能力。拿它们排一张“谁更高级”的榜单，问题从一开始就问歪了。

后来我给自己定了个顺序：先想清楚要什么证据。能从 RSS、API 或原文拿到，就别急着开浏览器；这些路都走不通，或者要看的就是页面本身，再让模型去操作屏幕。这里说的“最低成本”，不只看少点了几下，还要看来源是否对得上，结果能不能核。

下面两个很日常的问题，刚好能把这件事说清楚：

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

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

第一个问题：先分清你说的是哪种“第一”

听到“少数派今天第一篇文章”，我最先会问：这里的“第一篇”指什么？

  • 今天最早发布的文章；
  • 首页当前排在第一位的文章；
  • RSS 订阅源里的最新一篇文章。

这三个答案可能完全不同。要找今天最早发布的文章，需要的是按发布时间排列的文章流；要找首页第一篇，首页本身才是证据；要找 RSS 第一篇，就应该直接读 RSS。

少数派公开过自己的 RSS 地址1。如果问题已经明确为“今天最早发布的文章”，我会先读取 RSS 或官方文章列表，按北京时间筛选，再打开候选文章核对标题、链接和原始发布时间。能这样解决，就没有必要先启动浏览器，等待渲染、滚动、识别卡片，再逐个点进去。

不过，RSS 也不是“真相接口”。订阅源可能只保留最近若干条，pubDate 也可能表示更新或分发时间。一天内内容很多时，只看 RSS 甚至可能漏掉当天较早的文章。所以更稳妥的说法是：优先找结构化来源，但要检查它的覆盖范围和时间语义，最后回到原文页验证。

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

“最火”比“第一篇”更麻烦。时间可以直接排序，热度却要先定义指标。至少有三种常见口径：

  1. 少数派官网热门内容里的第一篇；
  2. 今天发布的文章中，点赞、评论、收藏或阅读量最高的一篇；
  3. 第三方热榜里排名最高的少数派文章。

第三种不能冒充少数派官方口径，第二种也必须先说清楚究竟按哪个互动指标算。

如果默认采用“官网热门内容”，可以先 fetch 首页或热门页。普通网页获取已经能读到榜单，就到此为止；榜单由前端动态加载，fetch 拿不到，再打开浏览器。如果问题被定义成“今天发布文章里互动最高”，就要先找全当天文章，再获取同一口径的互动数据并排序。公开数据拿不到，就老实说无法严格判断。

工具多解决不了口径问题。“最火”没定义清楚，给 Agent 再多工具，也只是让它更有办法回答错问题。

我拿 Manus 和 Codex 试了一次

为了看看这种歧义会怎么影响结果，我把同一句话交给了 Manus 和 Codex：

帮我找少数派今天第一篇文章。

我故意没有解释“第一篇”。这个问题至少能被理解成三种意思：

1. 首页当前推荐流的第一篇
2. 今天新发布的第一篇
3. RSS 订阅源里的最新一篇

这不是一次严格的产品评测，只是一次具体运行：模型、版本、可用工具和当时的网页状态都会影响结果。不过，它很直观地暴露了“数据源和问题口径没有对上”会发生什么。

下面是 Manus 和 Codex 的执行结果。

Manus 打开少数派首页查找第一篇文章Codex 对照首页、RSS 和文章发布时间

Manus 先打开少数派首页，沿着页面上的推荐流找到了第一条文章：《假期出门太折磨？我的 23 条经验帮你规划惬意旅行》。如果问题是“首页现在把哪篇文章放在第一位”，这条路径没有问题。

问题出在时间。首页显示的是当天的推荐时间，而文章页记录的原始发布时间是 2025 年 6 月 9 日2。它当天再次出现在首页，并不等于当天新发布。

Codex 的路径更像在查一笔账：先确认当前日期，再看搜索结果、首页 HTML 和 RSS/feed，最后进入文章页核对发布时间。它把首页显示时间、推荐时间和原始发布时间拆开了。下面是 Codex 当时的操作过程：

我更在意的是，这两条路径抓住了三种不同的事实：首页排序、订阅源分发和原始发布时间。Agent 选了哪个数据源，就在回答哪个问题。

如果我要的是“首页现在第一篇”，打开首页最直接；如果我要的是“今天最早发布”，按时间筛选文章并核对原文更可靠。工具本身没有高低之分，关键是它拿到的证据能不能回答眼前的问题。

别再把这些名词排成一条线

写到这里，我觉得最容易误导人的，反而是一张从 RSS 一路排到 Computer Use 的“升级表”。它看起来很清楚，却把几件不同的事压成了一个维度。

我现在会把检索任务拆成四个问题：

要决定什么常见选项真正要检查的事
问题口径最早发布、首页第一、互动最高最终答案到底按什么定义
数据来源RSS、API、sitemap、首页、文章页是否官方、是否完整、时间字段表示什么
访问与操作方式search、fetch、CLI、MCP、浏览器、Computer Use是否动态渲染、是否需要登录或交互、屏幕是否就是证据
流程封装Skill、Stagehand、Browser Use、Manus 等成品 Agent是一次性任务还是长期流程，用户需要控制到哪一步

拆完我才发现，之前很多争论其实是在各说各话：CLI 和 MCP 说的是接法，Stagehand、Browser Use 说的是流程怎么组织，Manus、Codex 则可能把这些东西都包在产品里。一个产品也可以同时提供 CLI、MCP、Skill 或云服务。Vercel 的 Agent Browser 就已经同时提供 CLI 和 MCP 入口3。所以，按品牌把工具固定在某一层，很快就会过时。

CLI 和 MCP：主要差在接法

Playwright 官方目前更推荐 coding agent 使用 CLI：命令短，适合配合 Skill，也不用长期把大量工具 schema 放进上下文4。MCP 更适合围绕页面结构反复推理、由客户端统一管理工具的 agent loop5。

这是使用偏好，不是能力边界。CLI 和 MCP 都可以维护浏览器状态、截图、读取网络请求和控制台。实际选择时，我会先看 Agent 所在的环境：已经有 shell，就优先用 CLI；客户端本来就是 MCP-first，就接 MCP。没必要为了“技术上更高级”多绕一层。

Stagehand 和 Browser Use：你是不是在写一个流程

Stagehand 把确定性的浏览器操作和 act、extract、observe 等 AI 原语放在一起，也可以与 Playwright、Puppeteer 等工具配合6,7。Browser Use 同时提供 CLI、Python 库和云端能力；一次性任务可以直接用 CLI，需要重复执行和维护时再写成程序8。

临时查一篇文章当然也能用，但一个 fetch 已经拿到答案时，我不会再搬出框架。要长期登录后台、跨页面采集、定期重跑，才值得把流程写下来。

Computer Use：当屏幕本身就是证据

OpenAI、Anthropic、Google 和 Microsoft 都提供了同类能力9,10,11,12。它们的共同点，是让模型根据截图或其他界面表征，输出点击、输入、滚动等动作。

这条路径通常更慢，也更需要安全边界，但不能简单理解成“最低级的兜底”。如果任务要检查画布、远程桌面、视觉排序，或者页面根本没有可用的 DOM，屏幕就是最直接的证据。对普通公开资料检索，它不该是默认入口；对纯视觉任务，它反而可能是第一选择。

本地 Agent 和成品 Agent，控制点不一样

在 Codex、Claude Code、Cursor 这类本地或半本地 Agent 里，用户能看到 shell，也能安装 CLI、MCP 和 Skill，所以可以直接决定工具怎么接、状态保存在哪里、失败以后换哪条路。

Manus 这类成品 Agent 把很多编排藏在产品内部。用户通常不需要指定“必须用 fetch”或“必须用 MCP”，也不该根据一次运行反推出它内部一定用了哪种页面表征。Manus 官方能确认的是：Browser Operator 在用户的本地浏览器中复用现有登录状态和本地网络，Cloud Browser 则运行在隔离的云端环境；遇到验证码、短信码或多因素认证时，Cloud Browser 会请求用户接管13,14。至于它是否总会返回整页 Markdown、何时使用坐标点击，公开资料并没有给出足够依据。

对这类产品，用户真正应该控制的是任务口径、来源要求和动作边界。例如：优先使用官方来源；引用第三方榜单时要说明；发帖、购买、删除、提交表单之前必须征得确认。这些要求比猜测产品内部用了 CLI 还是 MCP 更有用。

“最低成本”也要把验证和风险算进去

我后来发现，“最低成本”很容易被误读成少做几步。其实有些步骤不能省：

  • 看来源是否真的回答了问题。 官方来源通常更可信，但 RSS 可能不完整，首页时间也可能只是推荐时间。
  • 记录口径和查询时间。 “今天”“第一”“最火”都依赖时区、排序字段和页面状态。
  • 保留证据。 至少给出链接、发布时间和采用的排序指标；多个来源冲突时，不要悄悄挑一个。
  • 把网页当作不可信输入。 页面里的文字不能擅自改变任务；涉及账号、隐私、支付、发布和删除时，应由用户确认。Computer Use 的官方文档也明确强调隔离环境和高影响动作的人工确认9。

少一次核对不一定真省事。答案交出去以后解释不清，往往还得从头再查。

两个可以直接使用的提示词

第一个少数派问题，我会这样说：

帮我找少数派今天第一篇文章。默认按北京时间判断“今天”，请分别给出“今天最早发布的文章”“首页当前第一篇”和“RSS 当前第一篇”；如果三者相同，可以合并。最后标明每个答案采用的口径、链接和时间。

第二个问题可以这样说：

帮我找少数派今天最火的文章。默认“最火”按少数派官网热门内容排序；如果官网没有可读的热门榜，请明确说无法按这个口径判断。若能取得今天发布文章的公开互动数据，可以另列“今日互动最高”，但不要把它当成官网热门的替代。使用第三方热榜时，也请单独标明来源和口径，不要编造热度指标。

这两个提示词都没有指定 MCP、CLI 或 Computer Use。它们只是把“今天”怎么算、“第一”和“最火”按什么判断、什么情况不能下结论说清楚。工具可以交给 Agent 选择，证据标准不能也一起交出去。

写在最后

写这篇文章之前，我总觉得自己缺的是一张工具地图：把 RSS、fetch、Playwright、MCP、Stagehand、Computer Use 按顺序摆好，以后照表选择就行。真正跑过几次以后才发现，工具表只能解决一半问题。

另一半是：我想知道的到底是哪件事，哪个来源能证明它，证据不够时要不要继续查。少数派首页第一篇和今天最早发布的一篇，可能不是同一篇；官网热门、互动最高和第三方热榜，也不是同一个“最火”。这些口径不先说清楚，工具越强，跑偏以后走得越远。

Reference

  1. 少数派 RSS 相关说明 - https://sspai.com/post/24194 ↩

  2. 《假期出门太折磨？我的 23 条经验帮你规划惬意旅行》- https://sspai.com/post/100006 ↩

  3. Vercel Labs Agent Browser GitHub - https://github.com/vercel-labs/agent-browser ↩

  4. Playwright CLI 官方文档 - https://playwright.dev/docs/getting-started-cli ↩

  5. Playwright MCP 官方文档 - https://playwright.dev/docs/getting-started-mcp ↩

  6. Stagehand 与 Playwright 集成 - https://docs.stagehand.dev/v3/integrations/playwright ↩

  7. Stagehand 与 Puppeteer 集成 - https://docs.stagehand.dev/v3/integrations/puppeteer ↩

  8. Browser Use CLI 文档 - https://docs.browser-use.com/open-source/browser-use-cli ↩

  9. OpenAI Computer Use 文档 - https://developers.openai.com/api/docs/guides/tools-computer-use ↩ ↩2

  10. Anthropic Claude Computer Use 文档 - https://platform.claude.com/docs/en/agents-and-tools/tool-use/computer-use-tool ↩

  11. Google Gemini Computer Use 文档 - https://ai.google.dev/gemini-api/docs/computer-use ↩

  12. Microsoft Copilot Studio Computer Use 文档 - https://learn.microsoft.com/en-us/microsoft-copilot-studio/computer-use ↩

  13. Manus Browser Operator 官方文档 - https://manus.im/docs/integrations/manus-browser-operator ↩

  14. Manus Cloud Browser 官方文档 - https://manus.im/docs/features/cloud-browser ↩