拆解 OpenClaw:从发一条消息到 AI 吐出第一个字,中间到底发生了什么-夜雨聆风

拆解 OpenClaw:从发一条消息到 AI 吐出第一个字,中间到底发生了什么

你用 LangChain 搭过一个 Agent，用 Dify 拖过一个工作流——这些你都会。你理解 function calling 的基本模式：模型输出一个 JSON，你的代码执行它，结果塞回 prompt，循环。到这里，你觉得 Agent 框架就这点东西。

但当你真的想在生产环境跑一个 Agent——让它管理你的文件、搜索网页、执行命令、定时自主运行——你会发现事情完全不一样。Skills 不是读一个文件塞进 prompt 那么简单。Tool 的权限不是”允许/禁止”的二选一。Web Search 不是你装个 API Key 就能稳定工作。反爬更不是写个 requests.get() 就能搞定的事。

这篇文章，我们拿 OpenClaw——一个 GitHub 上超过 37.9 万 Star（截至 2026 年 6 月）、由 Peter Steinberger 创建于 2025 年 11 月的 MIT 开源 Agent 框架——来拆解一个真正工程化的 Agent 框架到底是怎么设计的。我们从一条消息的完整旅程开始：它经过网关、会话管理、上下文组装，到模型推理、工具执行、流式返回，一步一步拆开。然后再逐个放大 Skills 加载机制、Tool 权限管控、Web Search 实现和反爬应对这四个关键子系统。

需要先说明的不确定性：本文基于 OpenClaw 2026 年 6 月的官方文档（docs.openclaw.ai）和社区资料（clawdocs.org）撰写，不构成技术选型建议。部分实现细节可能随版本更新变化。文中引用的 GitHub 数据为截至 2026 年 6 月 16 日的实时快照。

核心判断：Agent 框架的价值不在”能调 function calling”，而在 Skills 加载、Tool 管控、Web Search fallback 和反爬分级应对这些工程化设计。这些才是生产级 Agent 和 demo 的分界线。

先把地图打开：OpenClaw 的五大核心组件

在跟着一条消息跑完全程之前，先搞清楚 OpenClaw 的整体骨架。

OpenClaw 是一个用 TypeScript 编写的 Node.js 应用，以 MIT 许可证开源。它支持 WhatsApp、Telegram、Discord、Slack、Signal、iMessage、微信、QQ 等 50 多个频道。截至 2026 年 6 月，已累积超过 59,000 次提交，ClawHub 技能市场上已有超过 10,700 个社区贡献的 Skills。

社区文档（clawdocs.org）将 OpenClaw 的核心架构归纳为五个组件。注意——”Brain”和”Hands”这两个称呼主要来自社区文档，官方文档更偏向使用”Agent Loop””Tool Execution”等术语。本文沿用社区称呼以便理解，但读者应知它们并非官方架构图中的正式模块名。

Gateway（网关）是”中央控制台”——一个常驻内存的 Node.js 守护进程，默认监听 127.0.0.1:18789，通过 WebSocket 对外暴露 API。不管消息从哪个频道进来，最终都是 Gateway 接手。

Brain（大脑）负责 LLM 推理。它在每次调用前从多个来源组装 System Prompt，然后调用大模型生成文本或工具调用指令。

Hands（双手）是执行层。Brain 说要读文件、搜网页、跑命令——Hands 真的去做。

Memory（记忆）是基于本地 Markdown 文件的记忆系统，结合混合搜索和 Dreaming 模式来维护上下文。

Heartbeat（心跳）让 Agent 可以自主运行——默认每隔 30 分钟自动检查一次有没有新事情要处理。

五个组件的协作关系一句话：Gateway 接住消息 → Gateway 内置的 Router（路由器）根据频道绑定分给对应 Agent → Brain 推理 → Hands 执行 → Memory 记录 → Heartbeat 自主触发新一轮循环。

地图打开了。现在跟着一条真实消息，看它们怎么动起来。

从”你好”到回复的第一个字：7 层 Prompt 组装和 Tool Call 循环

这是全文最核心的一节。一条消息进入 OpenClaw 后要经过 6 个子步骤才变成你可读的回复，每一步都有明确的设计理由。这 6 个步骤共同回答一个问题：一条消息怎么变成最终回复？我们先快走一遍，再挑关键的停下来仔细看。

第 0 步：消息到达 Gateway

不管你是从 Telegram 群里 @Agent、在 CLI 里敲 /ask，还是 Heartbeat 定时器到点自动触发——所有消息最终都进入 Gateway，通过 WebSocket 协议处理。Gateway 协议的首个帧必须是 connect，后续支持三种消息类型：req（请求）、res（响应）、event（事件通知）。Gateway 负责所有”消息层面的控制权”：谁在说话、属于哪个会话、有没有权限。

第 1 步：Router 分派

Gateway 接到消息后，Router 根据频道绑定关系，把消息分派给对应的 Agent。一个 OpenClaw 实例可以运行多个 Agent——你的”工作 Agent”绑定 Slack 和 Gmail，”私人 Agent”绑定 WhatsApp——它们各有各的 Skills 白名单、各有各的模型配置，彼此隔离。

第 2 步：Prompt Assembly——最容易被忽略的关键环节

这不是”把消息丢给 LLM”。OpenClaw 在每次 LLM 调用前，从 7 个来源组装出一个庞大的 System Prompt。按从内到外的顺序：

层	来源	作用
1	`SOUL.md`	定义 Agent 的身份、性格和底线约束
2	`AGENTS.md` + `TOOLS.md`	操作指令和工具使用说明
3	Memory	从 Markdown 记忆中检索出的历史上下文
4	Skills 指令	符合条件的 Skills 的紧凑 XML 列表
5	对话历史	当前会话的历史记录
6	`EXTERNAL_UNTRUSTED_CONTENT` 标记	标记外部注入的不可信内容边界
7	消息正文	你真正敲进来那句话

为什么按这个顺序？ 两个原因。第一，大模型对前面的内容更敏感——SOUL.md 的底线约束放在最前面，意味着它的约束力最强；而消息正文放在最后面，用户的直接指令不会被前面内容”压住”。第二，Prompt Caching（前缀缓存）。主流 LLM Provider（如 OpenAI、Anthropic）支持对 Prompt 前缀进行缓存——如果两次调用前缀相同，前缀 token 不重复计费。OpenClaw 把稳定内容（SOUL.md、AGENTS.md、Skills 列表）放在前面，把变化内容（对话历史、当前消息）放在后面，稳定部分就能被缓存复用。

还有一个重要细节：每次 LLM 调用都重新组装 Prompt，包括 Tool Call 循环中的每次后续调用。不是”一次组装、全程复用”。Skills 快照在同一会话内不变，但 Memory 检索和对话历史每次都可能不同。

第 3 步：Brain 推理

Prompt 组装完成后，Brain 开始推理。它可以输出三种东西：

纯文本——直接返回答案，流程结束。
Tool Call——输出一个 JSON 结构（类 JSON-RPC 格式），包含工具名、参数和调用 ID，意思是”我需要调用某某工具”。
文本 + Tool Call——边解释边调用工具。

第 4 步：Agent Loop——Tool Call 循环

如果 Brain 输出了 Tool Call，就进入了 OpenClaw 最核心的运行模式：

Brain 输出 Tool Call  → Hands 执行工具（读文件、搜网页、跑命令等）  → 工具执行结果附加到对话历史末尾  → 重新 Prompt Assembly  → Brain 再次推理  → 如果还输出 Tool Call，继续循环  → 直到产生最终文本回复（或触发超时/中断/达到循环上限）

这个循环不是无限的。有超时机制，有最大循环次数限制。同一会话通过 per-session 的基于文件的写锁（文档描述默认超时 60000ms）防止多个推理同时进行——这避免了并发混乱。

第 5 步：流式输出与持久化

当最终文本产生时，回复通过 assistant stream 以 delta（增量）方式实时流出——你在聊天窗口看到逐字出现的文字就是这么来的。生命周期事件（开始、结束、错误）通过 lifecycle stream 通知。最终完整对话写入 ~/.openclaw/agents/<agentId>/sessions/<SessionId>.jsonl 文件，确保所有交互都可回溯。

到这里，一条消息的完整旅程走完了。但你注意到 Prompt 组装里还有一层我们只提了名字——Skills 指令。它不是”读一个文件夹塞进 Prompt”这么简单。下面我们把它放大。

Skills 不是文件读取：6 级优先级、门控过滤和 Token 成本

Skill 是什么

一个 Skill 就是一个目录，里面放一个 SKILL.md 文件：YAML 头（元数据）+ Markdown 正文（操作指南）。它遵循 AgentSkills 规范（agentskills.io）。

Skills 和 Tools 不是一回事。 Skills 是”使用说明书”——教模型怎么用已有工具完成特定任务。Tools 才是”手”——真正能干活的东西（读文件、执行命令、搜索网页）。Skill 不能添加新工具，只能告诉模型如何组合使用现有工具。

6 级加载优先级

Skills 不是所有混在一起。OpenClaw 用一个严格的 6 级系统来决定”当存在同名 Skill 时，用哪个版本”：

优先级	来源	路径
1（最高）	Workspace skills	`<workspace>/skills`
2	Project agent skills	`<workspace>/.agents/skills`
3	Personal agent skills	`~/.agents/skills`
4	Managed / local skills	`~/.openclaw/skills`
5	Bundled skills	随安装包发布
6（最低）	Extra dirs + plugin skills	`skills.load.extraDirs` + 插件贡献

同名覆盖，不是合并。 如果同一个 name 的 Skill 出现在多个位置，高优先级版本直接覆盖低优先级版本。这意味着你可以在 Workspace 里放一个与社区 Skill 同名的 Skill，用来定制行为——你的版本直接顶掉社区的。举个例子：团队可以在 Project agent skills 里放”代码审查 Skill”的定制版，覆盖 ClawHub 上的通用版。

门控——按条件自动过滤

Skills 加载时不是”全上”。在 SKILL.md 的 frontmatter 里，metadata.openclaw.requires 字段可以设置以下门控条件：

门控字段	含义	例子
`requires.bins`	PATH 上必须存在这些二进制	`["uv", "python"]`
`requires.anyBins`	至少有一个二进制存在	`["node", "bun"]`
`requires.env`	这些环境变量必须已设置	`["GEMINI_API_KEY"]`
`requires.config`	配置文件中指定路径必须为真值	`["browser.enabled"]`
`os`	限定平台	`"darwin"` / `"linux"` / `"win32"`

实际效果：比如一个图片处理 Skill 需要 uv 和 GEMINI_API_KEY。如果你没装 uv 或没设 API Key，这个 Skill 就不会进入 Agent 的可用列表——模型根本不知道有这个 Skill 存在。这是一种”按环境自动裁剪”的设计，而不是让模型看到一个没能力用的工具然后报错。

环境注入——临时注入，用完恢复

如果 Skill 需要 API Key，可以在配置文件中设置。Agent 运行开始时，这些值被临时注入到 process.env，运行结束后恢复原环境变量——防止凭据在进程间泄漏。

但有一个常见的配置陷阱：环境注入只在宿主机 Agent 运行中生效，沙箱内无效。如果你的 Agent 跑在 Docker 沙箱里，注入的 API Key 不会被沙箱内的进程看到——需要额外配置才能传递 secrets。

Prompt 构建——目录在 Prompt 里，正文在磁盘上

加载完成后，符合条件的 Skills 被编译为紧凑的 XML 块注入 System Prompt，大概是这种形式：

<skill><name>my-skill</name><description>简短描述</description><location>file:///path/to/skill/SKILL.md</location></skill>

关键是”按需加载”策略。每个 Skill 在 System Prompt 里只占约 24 个 token（按官方文档 4 chars/token 的估算，不含描述长度）。加上描述，一个典型 Skill 大约 40-60 tokens。如果你有 50 个激活的 Skills，光技能目录就占 2000-3000 tokens。

模型不需要在推理前读完所有 Skill 的完整指令——它只在需要时通过 read 工具按需加载 SKILL.md 的正文。这是一种”菜单挂在墙上，菜谱锁在柜子里”的设计。

官方文档给出的完整 Token 成本公式是：195 + Σ(97 + len(name) + len(description) + len(filepath))。用人话说就是：不管有多少个 Skills，先有一个约 195 个字符的固定开销（对 Σ 求和范围内的所有 Skill 都一样）；然后每个 Skill 再额外增加约 97 个字符，加上它的名称、描述和文件路径的字符数。按官方文档大约 4 个字符折合 1 token 的估算，一个典型 Skill 在 System Prompt 里实际占地约 40-60 tokens。注意这个公式基于 4 chars/token 的估算，不同模型的 tokenizer 实际行为有差异。

Session 快照

Skill 列表在每次会话开始时生成快照，整个会话期间不再改变——除非 SKILL.md 文件被修改（文件监听器检测到变化），或新的远程 Node 连接进来。这意味着：你在一个长会话中间通过 ClawHub 安装了新 Skill，当前会话里模型看不到它，需要开新会话。

Skills 是使用说明书。但模型真正做事靠的是 Tools——说明书告诉你怎么用，手得自己动。下一节看手是怎么管住的。

五层洋葱皮：OpenClaw 是怎么管住 Agent 的双手的

Tools 是什么

Tools 是模型可以调用的函数——读文件（read）、写文件（write）、执行命令（exec）、搜索网页（web_search）、抓取链接（web_fetch）、操作浏览器（browser）等。OpenClaw 内置了 9 大类工具：Runtime（命令执行）、Files（文件读写）、Web（网页搜索与抓取）、Browser（浏览器操控）、Messaging（消息发送）、Sessions/Agents（会话和子代理管理）、Automation（定时任务）、Gateway/Nodes（网关管理）、Media（图片/语音生成）。

工具权限不是”要么全开要么全关”。 OpenClaw 用一套五层洋葱模型来逐层过滤。

五层洋葱模型

从外到内：

第 1 层：Profile 预设。 四档粗粒度模板——minimal 只给最基本的文件读写；coding 加上代码执行、网页搜索和获取；messaging 侧重消息收发；full 开放全部工具（包括浏览器）。

第 2 层：allow/deny 列表。 在 Profile 基础上精细增减。比如你用了 full Profile，但想禁止某类特定操作——用 deny 列表精确剔除。

第 3 层：Provider 限制。 即使用 full Profile，如果浏览器 Provider 没配置好，Browser 工具实际上不可用。这是能力层面的限制，不是权限层面。

第 4 层：Sandbox 状态。 某些工具在沙箱内和沙箱外行为不同。比如 Docker 沙箱默认无网络（network: "none"），沙箱里的 exec 受额外限制。

第 5 层：Channel 权限。 Telegram 上的 Agent 可能没有 exec 权限，但 CLI 上的 Agent 什么都行——不同入口有不同信任等级。

核心原则：模型永远看不到它无权调用的工具 schema。 工具过滤在 LLM 调用之前执行——如果策略移除了某个工具，那次调用的 System Prompt 里就不会有这个工具的 function definition。这比”事后拦截”安全得多：模型不能假装调用一个它不知道存在的工具。

exec 的专门护栏——Exec Approval Manager

exec 是最危险的工具（能直接运行系统命令），OpenClaw 为它设计了独立的审批机制，支持 5 个安全层级：

层级	含义	做什么
`deny`	拒绝	禁止一切 exec
`allowlist`	白名单	只允许白名单命令
`ask`	询问	白名单通过，miss 时弹出审批
`auto`	自动审查	白名单通过，miss 时自动审查 + human fallback
`full`（YOLO）	不审批	直接执行，不分青红皂白

allowlist 不仅支持命令名的 glob 匹配（如 git*），还支持 argPattern 正则限制参数——比如你可以允许 git push 但不允许 git push --force。

审批结果可以转发到聊天频道。比如后台 Agent 需要运行一个不在白名单上的命令时，审批请求弹到你常用的 Telegram——你在手机上点”批准”，命令就在后台执行了。

但有一个重要的边界需要了解：Exec Approval 不是多用户权限系统。它控制的是”Agent 能不能跑这个命令”，不是”哪个用户请求的”。一旦命令被批准，它就能修改文件系统中的任意可写文件。

Docker 沙箱——把危险操作关进笼子

OpenClaw 支持三种沙箱后端：Docker（最常用，默认镜像 openclaw-sandbox:bookworm-slim）、SSH（转发到远程主机）、OpenShell（管理沙箱）。有三种模式：off（关闭）、non-main（隔离非 main 会话）、all（全部隔离）。

Docker 沙箱默认无网络——沙箱里的工具不能连外网，除非你显式配置。浏览器要联网，所以 OpenClaw 为沙箱内浏览器创建了独立的 Docker 网络（openclaw-sandbox-browser）。

沙箱不是绝对安全的隔离边界。它隔离了文件系统和进程，但不能防御精密的 Prompt Injection 攻击。有效的安全需要多层叠加：审批 + 沙箱 + 最小权限原则。此外，有线索指向 Docker 沙箱的 TOCTOU（检查时间/使用时间）竞态条件漏洞已在近期版本中修复，建议始终运行最新版本以确保安全边界有效。

Tool 里有一类特别有意思——web_search 和 web_fetch。你以为就调一个 API？背后是 15 个 Provider 的自动检测和降级链。

搜个网页而已，OpenClaw 为什么搞了 15 个 Search Provider？

15 个 Provider，按”谁有 Key 用谁”自动选择

web_search 不是去抓 Google 搜索结果页——它是通过第三方搜索 API Provider 完成的。OpenClaw 支持 15 个 Provider，从 Brave、Tavily 等商业搜索 API，到 Gemini、Grok 等 AI 合成回答，再到 DuckDuckGo、Parallel Search Free 等免费选项。

如果你在环境变量中设置了某个 Provider 的 API Key，OpenClaw 会自动优先使用它。具体的自动检测优先级是：先遍历所有 API-backed Provider（Brave → MiniMax → Gemini → Grok → Kimi → Perplexity → Firecrawl → Exa → Tavily → Parallel Paid），如果有 Key 就用；如果上述 Provider 都没有配置 API Key，则回退到免费的 Parallel Search Free——不需要注册、不需要 Key。

换句话说，零配置也能用。安装 OpenClaw 后不需要任何设置就能让 Agent 上网搜索。这是降低使用门槛的重要手段。

15 分钟缓存，同一查询不重复花钱

同一个查询词在 15 分钟内不会重复调用 Provider API——结果从缓存返回。这对降低费用和延迟很重要：如果模型在同一轮对话中对同一个问题调用了两次 web_search，第二次直接从缓存拿，省了 API 调用费。

web_search / web_fetch / Browser 的三分工

这三种获取网页内容的方式最容易混淆。它们的职责边界是这样的：

工具	原理	JS 渲染	适用场景
`web_search`	调搜索 API	不涉及	搜索”信息是否存在”
`web_fetch`	HTTP GET + Readability 提取正文	❌	抓取已知 URL 的静态内容
`browser`	真实 Chromium + Playwright/CDP	✅	需要 JS 渲染、登录、交互

web_fetch 的工作流程

web_fetch 分三步走：

以 Chrome 的 User-Agent 发送 HTTP GET 请求。
用 Readability 算法从 HTML 中提取正文——去掉导航栏、广告、侧边栏。Readability 对大多数静态网站够用。
如果 Readability 提取失败（比如页面内容全靠 JS 动态生成，HTML 是空的），且你配置了 Firecrawl API Key，就回退到 Firecrawl 的 bot-circumvention 模式。

本质区别：web_fetch 不执行 JavaScript。 这是它和 Browser 工具之间最根本的差异。对于 <div id="app"> 然后全靠 JS 渲染的 SPA 单页应用，web_fetch 拿到的是空白页面——因为 HTML 里根本就没有内容。

网络安全

所有搜索请求走 guarded fetch 路径。内部地址（localhost、私有 IP 段、link-local、云 metadata 端点）被一律阻止。唯一的例外是对可信 Provider 主机开放代理软件的 fake-IP DNS 范围（198.18.0.0/15 和 fc00::/7），用于兼容 Clash/sing-box 等网络代理环境。

一个小提醒

“默认用 Parallel Search Free”不等于”和 Google 搜索结果一样好”。免费 Provider 的质量和覆盖范围通常不如付费商业 API。如果你依赖高质量实时搜索结果，花几美元配一个 Brave Search API Key 就是最简单的升级路径。

但 web_fetch 有一个致命短板：不执行 JavaScript。遇到 SPA 和 Cloudflare 保护的网站怎么办？这时候需要 Browser——但 Browser 也有自己的坎。

Agent 爬网页不是写个 requests.get()——反爬的三级应对模型

核心认知：反爬不是 OpenClaw 的原生能力

OpenClaw 本身不提供反爬能力。web_fetch 的 Chrome User-Agent + Readability 只是基本伪装，不是反爬系统。真正的反爬能力来自第三方服务——Firecrawl 的 bot-circumvention 和 Browserbase/Notte 的 CAPTCHA 求解、stealth mode、住宅代理。

反爬不是”有或没有”的二元问题，而是分级应对。OpenClaw 提供了三条路径，每条有自己的适用场景和边界。

三级应对模型

等级	工具	反爬能力	能处理什么	搞不定的
Level 1	`web_fetch`	Chrome UA + Readability 提取 + Firecrawl 降级	静态 HTML 页面、博客、文档	SPA、JS 渲染、Cloudflare JS Challenge
Level 2	Browser（managed）	真实 Chromium + Playwright/CDP	JS 渲染页面、需要交互的网页	CAPTCHA、Stealth 检测、高级 Cloudflare
Level 3	Browser + Browserbase/Notte	CAPTCHA 求解 + Stealth + 住宅代理	高防网站	登录墙、付费墙、极端防护

Level 1 的边界：大部分网页够用

Chrome UA 对静态网站来说足够了。Readability 只提取有用内容块，通常不会触发”你在爬取整个页面”的检测。但如果 HTML 是 <div id="app">的空壳——Readability 什么也提取不到，因为 HTML 里根本就没有内容。如果配置了 Firecrawl，web_fetch 会回退到 Firecrawl 的 bot-circumvention 模式——这是第三方服务提供的反爬能力。

Level 2 的边界：真实浏览器，但不隐身

Browser 工具启动真实 Chromium，能处理 JS 渲染页面、能点击按钮、能填表单。但 managed profile 模式没有内置 stealth mode 或 CAPTCHA solving——你的 Chromium 对目标网站来说就是一个普通的自动化浏览器，该被 Cloudflare 拦还是会被拦。

Level 3 的能力与成本：反爬的”军火库”要钱

当基础 Browser 也搞不定时，可以接入第三方云浏览器服务：

Browserbase：内置 CAPTCHA 自动求解、stealth mode 和住宅代理。免费层提供每月 1 个并发会话和 1 个浏览器小时——每天只能用 2 分钟，只能做测试。
Notte：类似能力，免费层提供 5 个并发和 100 个终身浏览器小时。
Browserless：托管 Chromium 服务，暴露 CDP 接入。

接上这些服务后，Browser 工具就具备了”翻墙”能力——但这是第三方服务，需要额外付费和配置。

仍然会遇到的障碍

即使上了 Level 3，以下情况仍然可能拿不到数据：

登录墙：网站要求登录且流程复杂（如手机验证码），Browserbase 不能自动帮你注册账号。
付费墙：内容在付费订阅后面，只能看到预览。
高级 Cloudflare 防护：没有任何反爬方案是永久的——这是猫鼠游戏。
法律约束：绕过防护不等于有权抓取。目标网站的 robots.txt 和服务条款仍然适用。

这意味着什么

对于普通用户：让 Agent 搜索新闻或抓取公开博客文章，大概率不会遇到反爬问题——web_search + web_fetch 对 80% 的公开网页有效。对于重度用户：如果你的 Agent 需要监控电商价格或抓取社交媒体信息，你得接受一个现实——反爬是有成本的，需要投入时间去配置第三方服务并持续付费。对于产品设计者：设计一个”上网搜索+汇总分析”的 AI 产品时，反爬是最大的隐性成本之一——不是技术成本，而是持续维护成本（Provider 随时可能被目标网站封禁，防护策略随时升级）。

总结：OpenClaw 的设计哲学，和留给你的三个认知

OpenClaw 的设计哲学可以总结为一句话：把 Agent 的每一步都工程化——加载有优先级、权限有多层过滤、搜索有自动检测和降级、反爬有分级应对。这些不是炫技，是生产环境和水族馆的分界线。

带走这三个认知：

认知一：Agent 框架的价值不在”能调 function calling”，而在工程化管控。

Skills 的 6 级优先级和门控、Tool 的五层洋葱、沙箱隔离——这些才是 demo 和 production 的分界线。任何一个写了三天 Agent demo 的工程师都能调 API，但能管住 Agent 不乱动你的文件、不乱花 API 费用、不被反爬卡住——这才是框架真正在做的事。

认知二：你以为很简单的地方，往往是最多工程细节的地方。

“加载一个 Skill”不是读文件塞 Prompt——它有 6 级优先级、5 种门控条件、环境注入生命周期、Prompt 拼装的 token 成本公式。”搜个网页”不是调一个搜索 API——它有 15 个 Provider 自动检测、15 分钟缓存、Readability 提取、Firecrawl 降级、guarded fetch 网络安全。这些”你以为很简单”的地方，才是真正区分框架深度的地方。

认知三：反爬不是技术问题，是成本问题。

80% 的公开网页用 web_fetch 就能抓——零成本。剩下 20% 需要 Browser、需要 Browserbase、需要持续付费和持续维护。设计一个”能上网搜资料然后分析”的 Agent 时，最大的隐性成本不是开发成本，而是反爬的持续维护成本。提前判断你的目标网站落在哪一级——这比技术选型更重要。

下一个你要问自己的问题是：如果我今天要自己设计一个 Agent 框架——Skills 的加载优先级怎么定？Tool 的权限怎么分层？搜索 Provider 怎么编排？反爬边界怎么划定？这篇文章给你的，就是一份答题参考。