先看结论。OpenClaw 不是一个慢热项目,而是典型的高势能引爆型产品。它踩中了 AI 从"会回答"转向"会执行"的时间点,同时用开源、自托管和多平台接入,迅速把抽象概念变成了可部署的个人 Agent 系统。

OpenClaw的出现,在我看来不是偶然,而是完全必然。当模型能力、工具调用能力和多步任务稳定性同时跨过临界点,一个真正能替人执行任务的 Agent 框架出现,只是时间问题。Peter Steinberger 的周末项目,刚好踩中了这个节点。

这本电子书,和市面上已有的指南不同。多数指南是技术参考手册,适合技术性查阅。而这本书,是我从一个应用实践的视角去看待技术,结合社区的一手经验,为真正想用OpenClaw做事的人写的实践指南。

• 增长视角:没有数据支撑的故事,不展开。能量化的节点尽量量化。
• 技术视角:不只告诉你哪个好用,也解释为什么某些模型更适合 Agent 场景。
• 安全视角:供应链攻击、远程代码执行漏洞、平台封号,这些风险都不是传闻,而是部署时必须正视的现实。

2025 年,大语言模型发生了一次真正意义上的能力跃迁。模型不再只是更流畅地说话,而是开始具备使用工具、执行多步任务、与外部世界持续交互的能力。这种变化,让"聊天机器人"与"Agent"之间第一次出现了清晰边界。

Anthropic、OpenAI 等模型在 Tool Use 上逐步进入实用阶段。模型不再只输出文本,而是能够判断何时调用 API、传入什么参数,并根据返回结果继续完成后续推理。这个能力决定了 AI 能否从"会回答问题"走向"会处理事情"。

早期模型在链式任务里很容易迷路。做完 A,接 B,再到 C,经常会出现目标漂移、上下文混乱和幻觉放大。到了 2025 年,新一代模型在连续工具调用场景中的稳定性大幅提升,终于可以较可靠地完成"搜索信息、整理结果、输出报告、再发到指定渠道"这类复合任务。

OpenClaw 的意义,就在于它把这种能力工程化了。它不是再造一个聊天界面,而是把 AI 执行多步任务的能力,通过开源、自托管、多平台接入的方式,交到更多普通用户和团队手里。

OpenClaw 的火,不只是"很多人讨论",而是体现在一条极短时间内冲顶的增长曲线上。源文档给出的叙述重点,不是平滑扩张,而是连续爆点叠加之后的失控传播。

因为它不是靠单一功能取胜,而是同时满足了几个条件:模型能力刚刚成熟、使用门槛被极大压低、传播载体是每个人已经在用的消息平台、再加上开源与社区二次创作,最终把一个"AI 助手框架"变成了可以迅速被模仿、部署和炫耀的社会化产品。

Peter Steinberger 是一位奥地利开发者,在 iOS 和 macOS 开发圈长期具有较高知名度。OpenClaw 的重要性,很大一部分来自这个项目并不是由一个临时蹭热点的创业者做出来的,而是出自一个已经经历过完整产品、公司和退出周期的人。

这句话是理解 Peter 的钥匙。他的驱动力不是再复制一次标准创业路线,而是重新回到"做出某个真正能改变世界的东西"这件事本身。源文档提到,在不到五个月的时间里,他个人就在项目上提交了 11,684 次 commit。这既说明投入强度,也解释了为什么 OpenClaw 在早期会表现出极强的个人风格。

在 OpenClaw 之前,Peter 已经完成过一次重量级创业。他用 13 年时间把 PSPDFKit 从一个 PDF 显示库做成运行在 10 亿台设备上的企业级产品,并最终完成出售。表面看,这是经典成功故事;但按他后来的回顾,这段经历留下的不是轻松,而是长期的人际冲突和彻底的精疲力竭。

退休后,他买了单程机票去马德里,试图补上生活中被工作挤压掉的部分。但很快他发现,彻底脱离创造并不带来自由,反而会带来空洞。没有挑战,没有期待,人的状态并不会自动变好。这个阶段很重要,因为它解释了 OpenClaw 为什么不是"商业计划",而更像一次强烈的个人反弹。

源文档这一段最有价值的,不是传奇色彩,而是它给出了一个非常具体的原型诞生路径。真正改变世界的东西,最初往往并不复杂。

2025 年 11 月,那个旧想法重新回来。Peter 想要的不是另一个聊天机器人,而是一个真正能控制电脑、替他完成任务的个人助手。为了验证这个想法,他没有先设计宏大架构,而是用最短路径把链路接起来。

• 入口:使用 WhatsApp 的非官方 API 作为消息入口。
• 能力核心:把消息交给 Claude Code CLI 处理。
• 返回机制:CLI 执行后,再把结果回传到 WhatsApp。

整个原型,原文称只花了一小时。随后又用了几个小时补上图片支持。第一版没有复杂框架,没有完整设计,甚至连名字都不重要。重点只有一个,它先活了起来。

原型完成后不久,Peter 在摩洛哥马拉喀什旅行时做了一次测试。他给自己的 Bot 发去一条语音消息。这个 Bot 并没有预设语音识别功能,但它没有停在"我不支持"。相反,它自己识别文件头、尝试调用 FFmpeg、发现本地未安装后,转而用 curl 去调用 OpenAI Whisper API,再把转录结果发回。整个过程据称只用了约 9 秒。

这个瞬间的意义,不是功能有多复杂,而是系统开始表现出"自主补齐缺失环节"的倾向。也正是在这里,OpenClaw 从一个方便的脚本,变成了一个真正让人感到震动的 Agent 雏形。

OpenClaw 的爆发,不只是因为模型更强了,也不是因为 Peter 恰好有名气。更核心的原因是,他把 Agent 的价值定义得很清楚:不是回答得更漂亮,而是能不能把任务真正做完。这个定义非常朴素,但足够锋利,也足够适合传播。

OpenClaw 的名字经历了一段堪称惊险的历史。

最初项目叫 OpenCloud，强调「开放的云端能力」。但很快收到来自云服务商的商标压力。

改名 Clade，取 Claw + Anthropic 字母，寓意与 Claude 的连接。数天后，收到 Anthropic 法务团队的邮件：「友善但紧迫，请改名。」

这是整个命名战中最惊心动魄的一幕。Peter 计划把账号名原子化地同时迁移到所有平台——GitHub、Twitter、NPM、Docker、域名，必须同时完成，否则会有人抢注。

结果，消息还是泄露了。加密社区（另一个 crypto 项目声称先用了某相关名称）提前盯上了：

• 5 秒内：GitHub 账号被抢注并开始传播恶意软件
• 30 秒内：Peter 的个人 GitHub 账号被 rename 劫持
• 1 分钟内：NPM 包被抢注

Peter 当时在某个会议室里，「差点哭出来」，一度想直接删除整个项目。好在 Twitter 和 GitHub 的朋友紧急介入，帮助恢复了账号控制权。

Peter 直接联系 Anthropic，问：「OpenClaw 可以吗？」Anthropic 确认 OK（他们内部其实也有点喜欢这个名字）。

OpenClaw 爆红之后,Peter 面前其实有三条路:继续自己做,成立公司融资,或者加入大厂。源文档给出的判断很明确,他不想再重复一次 13 年创业史,也不想把自己重新放回漫长的组织博弈里。最终他选择加入 OpenAI,看中的不是报价,而是"乐趣和影响力"。

原文提到,Peter 与 Meta 和 OpenAI 都有过关键对话。Meta 的吸引力在资源,OpenAI 的吸引力在方向感。尤其是 Codex 路线,让他产生了更强的情感认同。对于一个把自己定义为 builder 的人来说,这种"我想跟谁一起把事情做大"的判断,往往比单纯的薪酬更重要。

这次加入最重要的后续安排,是项目并没有被 OpenAI 私有化。按源文档叙述,OpenClaw 被移交给开源基金会运营,OpenAI 只是赞助方之一,并不直接控制方向。这个安排很关键,它把"创始人个人职业选择"和"项目公共属性"分开处理,尽量压低社区对收编的焦虑。

源文档对 Anthropic 的描述相当尖锐。它的核心意思只有一句:Anthropic 最先意识到 OpenClaw 的风险,却没有最先理解它的价值。法务动作很快,生态动作很慢。结果是,本来最该拥抱这一波 Agent 运动的公司,反而因为商标和安全顾虑,给了竞争对手足够的时间窗口。

这也是为什么原文会把这件事描述为一次典型的"大公司被自己的谨慎反将"。从行业角度看,OpenClaw 不是单独某个开源项目的胜负,而是一次关于平台心态的测试:当社区自发把你的模型能力外延化时,你是把它视作风险,还是视作杠杆。

Peter 的判断并不温和。他不是在说"AI 会让软件更智能",而是在说,大量今天习以为常的软件形态,本身会被 Agent 吞掉。

他的逻辑很直接。如果一个应用的核心只是记录、提醒、查询、填表或调度,那么这些动作都可能被 Agent 统一接管。用户不再需要记住几十个 App 的入口,而是只要把目标交给一个持续在线的助手。日历、邮件、任务管理、票务预订、简单 CRM,这类软件最先承压。

源文档提到更激进的一层:未来不只是人使用 Agent,而是 Agent 代表人去和其他 Agent 交涉。你的 Bot 去联系餐厅 Bot、客服 Bot、平台 Bot,甚至雇佣线下执行者完成最后一公里。人类从大量数字流程里退场,变成定义目标、授权边界和做最终判断的人。

Peter 并不迷信单一全能体。他更偏向另一种图景:像人类社会一样,AI 也会专业分工。有人擅长研究,有人擅长写作,有人擅长调用系统,有人擅长编程。真正强大的,不一定是一个什么都做的通用大脑,而是一群能协作的专业智能体。

这套哲学解释了 OpenClaw 为什么不是另一个聊天壳。它真正想做的,是把"会说话的模型"变成"持续在线、带边界、可积累、可分工"的执行系统。也正因为这个目标足够大,OpenClaw 才会同时吸引开发者、内容创作者、自动化玩家和研究型用户。

在工具协议这件事上,Peter 的立场非常鲜明。源文档把它概括为一句话:OpenClaw 没有把 MCP 当成核心,而是走了 Skills + CLI 的路线。争论的重点,不是 MCP 能不能用,而是哪种方式更适合长期扩展的 Agent 系统。

• 上下文膨胀:会话一开始就加载大量 schema,先消耗 token,再谈任务本身。
• 过滤困难:工具返回信息往往过多,模型必须从冗长结构里自己筛选重点。
• 组合性不足:比起 CLI 的管道与串联,MCP 更偏向预先声明好的函数调用。
• 过度规范:模型要遵守严格 JSON 结构,灵活性和试错空间都更小。

OpenClaw 的 Skills 本质上是以 SKILL.md 为入口的工具说明系统。模型先读取简要描述,再决定要不要深入加载、更详细地看帮助文档,最后才实际调用工具。这个过程不像 MCP 那样要求一开始把所有工具暴露给模型,而是让模型像人类一样"先知道有这个东西,需要时再看说明书"。

这套机制与 CLI 天然适配。CLI 的优点不是古老,而是稳定、可组合、跨平台、可脚本化。只要一个工具在终端里能跑,OpenClaw 就能较自然地把它收编进 Agent 工作流。也正因此,它能够支撑 ClawHub 上数量庞大的技能生态,而不必每加一个技能就重启整个系统。

需要强调的是,Skills vs MCP 并不等于谁绝对先进。更准确地说,这是两种不同的产品取向。MCP 更像统一协议,希望把工具世界整理成标准接口。OpenClaw 的 Skills 则更像现实主义路线,优先解决"今天怎样把事做完"。对于一个强调自托管、多平台接入、快速扩展的系统来说,后者在当前阶段确实更有效。

一句话总结:ChatGPT是顾问,OpenClaw是员工。

顾问的工作方式是"你问,他答"。员工的工作方式是"你交代任务,他去做,中间自己补足环节,最后回来汇报"。这不是能力高低之分,而是产品定位不同。ChatGPT 的长处是把复杂问题解释清楚,OpenClaw 的长处是把分散动作串起来。

所以,OpenClaw 不是 ChatGPT 的替代网页,而是另一类产品。它更接近"你自己的操作系统入口",或者说,一个在消息流中待命的数字执行层。

很多人会问:"我已经有Claude Code了,还需要OpenClaw吗?"这个问题问错了。两者不是同一类产品。

最合理的实践不是二选一,而是分工。用 OpenClaw 管理消息、邮箱、日程、网页和轻量自动化,用 Claude Code 处理代码库、调试、重构和工程交付。二者组合,才更像 2026 年完整的 AI 工作流。

中文社区把运行和维护OpenClaw实例称为"养虾",用户自称"养虾人"。这不是一个玩笑,而是它带有社交属性的一部分。

• 第一,降低传播门槛:"养虾"比"部署 AI Agent"更容易被非技术用户理解。
• 第二,制造身份认同:一旦用户有了共同称呼,社区边界就出现了。
• 第三,增加社交货币:"我养了一只虾"比"我搭了个自动化框架"更容易在社交网络传播。

这层文化外壳非常重要。它把原本偏硬核的技术系统,转成了可以展示、可以讨论、甚至可以拟人化养成的东西。用户不只是配置一个工具,更像是在养一个有性格、会出错、会成长的数字生命体。

源文档还提到 Moltbook 这类 Agent 社交空间。其意义不在于数据规模本身,而在于它提供了一个观察窗口:当大量 Agent 被赋予名字、人格、规则和任务之后,它们之间是否会形成某种社会化行为。即使这些实验仍很早期,它也说明 OpenClaw 的想象空间并不止于自动化。

OpenClaw 的扩散速度快,部分原因就在于它不是只服务单一圈层。它既能让技术用户深挖,也能让非技术用户直接感受到"省时间"这件事。

如果用一句话概括 OpenClaw 的核心人群,那就是:手上有很多琐碎数字任务,希望把它们交给一个长期在线助手的人。会不会写代码当然有影响,但不是决定性门槛。真正决定使用强度的,是你是否有足够多值得自动化的日常流程。

这也是 OpenClaw 能跨圈层传播的原因。对开发者,它是可编排的 Agent 平台;对普通用户,它是会做事的私人助理;对企业,它是低成本试水 AI 自动化的入口。一个产品能同时在这三条线上成立,本身就是它成为黑马的重要原因。

部署 OpenClaw,最容易踩的第一个坑,不是命令敲错,而是部署形态选错。很多人一上来就照着教程装,装完才发现:机器不常开、消息收不到、浏览器自动化跑不稳、手机节点根本连不上。OpenClaw 不是纯本地桌面工具,它更像一套持续在线的 Agent 基础设施,所以第一步应该是选部署方式。

• 电脑是否能长期不断电、不断网。
• 是否需要真实浏览器和已有登录态。
• 消息渠道是否要求公网回调或固定 URL。
• 是否接受把令牌、会话和记忆文件放在云端。

如果只推荐一种个人长期部署方案,Mac mini 仍然是最均衡的选择。它的优势不在于跑分,而在于图形环境稳定、功耗低、系统睡眠可控、浏览器兼容性好,适合把 OpenClaw 当成真正的日常助手来养。

顺序很重要。先装运行环境,再装 OpenClaw,再处理模型和渠道,最后才做自启动与远程访问。很多报错不是版本有问题,而是顺序不对,导致路径、权限和会话目录都乱了。

# 1) 安装 Homebrew(如未安装)
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# 2) 安装 Node.js LTS
brew install node
node -v
npm -v

# 3) 全局安装 OpenClaw
npm install -g openclaw

# 4) 初始化并检查版本
openclaw --version
openclaw help

# 5) 启动网关
openclaw gateway start
openclaw gateway status

• 电源:关闭自动睡眠,允许断电后自动开机。
• 登录:确认机器重启后能恢复到可远程接管状态。
• 浏览器:固定使用一套主浏览器和用户数据目录,减少会话漂移。
• 更新:不要让系统在你不知情时自动重启,尤其是夜间任务高峰期。

OpenClaw 的运行逻辑,不只是一个命令把所有事包圆。它更像"网关 + 配置 + 记忆 + 技能 + 渠道插件"的组合。理解这些文件后,后续的大部分报错才有抓手。

{
  "gateway": {
    "bind": "0.0.0.0:3000",
    "publicUrl": "https://your-domain.example.com"
  },
  "models": {
    "default": "openai/gpt-5.4",
    "fallback": "anthropic/claude-sonnet"
  },
  "plugins": {
    "telegram": {
      "enabled": true
    },
    "browser": {
      "enabled": true
    }
  },
  "logs": {
    "level": "info"
  }
}

上面是说明结构的示意性写法。具体字段名和层级应以你当前版本的官方配置模板为准,不建议照抄到生产环境。

• 路径一致性:服务进程、手动终端、编辑器看到的路径必须一致,否则文件明明存在,Agent 却读不到。
• 环境变量边界:API Key、Webhook Secret、Bot Token 不要硬编码在说明文件里,尽量通过环境变量或安全配置注入。
• 最小化原则:先让单模型、单渠道、单浏览器工作,再逐个增加复杂度。

对大多数用户来说,OpenClaw 的价值不是在终端里回一句"hello",而是它能不能出现在 Telegram、WhatsApp、Discord、飞书或企业微信里,真正承接消息、任务和提醒。渠道接入决定了你是"装了一个项目",还是"养了一只在线的虾"。

Telegram 的优点是 Bot API 成熟、回调机制清晰、跨平台稳定,中文社区教程也最多。缺点是某些地区网络条件和通知触达存在不确定性。

1. 通过 BotFather 创建机器人,拿到 Bot Token
2. 在 OpenClaw 中启用 telegram 插件
3. 配置 webhook 或轮询模式
4. 确认 gateway.publicUrl 能被 Telegram 访问
5. 给机器人发送 /start,观察日志是否收到 update

WhatsApp 往往更像"真实生活入口",因为联系人、家庭群、客户沟通都在那里。但它的代价也最明显:扫码、登录态、封号风险、桥接方式、网页版本变动,都会直接影响稳定性。若是生产环境,必须接受它比 Telegram 更难维护。

OpenClaw 的报错表面很多,底层通常只有几类:进程没起来、配置没读到、渠道没打通、模型不可用、浏览器没权限、节点配对失败。不要见到报错就满网搜字符串,先给故障分层。

1. 第一层,进程层:OpenClaw 是否真的在运行,网关端口是否监听。
2. 第二层,配置层:读取的是不是你刚改的那份配置,路径是否一致。
3. 第三层,网络层:回调地址、反向代理、证书、内外网可达性是否正常。
4. 第四层,插件层:渠道插件是否启用、令牌是否有效、平台侧是否报错。
5. 第五层,模型层:基础文本请求能否成功,速率限制和余额是否异常。
6. 第六层,行为层:不是系统坏了,而是规则文件把它限制住了,比如 AGENTS.md 明确禁止某类动作。

openclaw gateway status
openclaw gateway restart
openclaw help

# 配合日志查看时,重点关注:
# 1) 配置加载路径
# 2) 插件初始化是否成功
# 3) 外部回调是否到达
# 4) 模型调用返回码
# 5) 浏览器 / 节点连接状态

进入 2026 年,OpenClaw 用户面对的已不是"有没有模型可用",而是"模型太多,应该怎么配"。同一套 Agent,如果默认模型、备用模型、搜索模型、长文模型、代码模型和本地模型没有分工,再强的能力也会被成本、延迟和不稳定吞掉。

第四部分的核心任务,是把杂乱的模型市场重新整理成可执行的配置方案。判断标准不只包括分数和榜单,更包括四个现实指标:第一,工具调用是否稳定;第二,长上下文是否真能用;第三,价格是否适合高频运行;第四,在中国网络环境和多渠道接入条件下,是否容易落地。

今天的可用模型,大致可以分成六类:Anthropic Claude、OpenAI GPT、Google Gemini、DeepSeek、国产闭源模型,以及本地开源模型。它们的差异,不只是"谁更聪明",而是能力结构不同。有的擅长长文推理,有的擅长代码执行,有的成本低到适合批处理,有的则更适合隐私敏感场景。

可以把市场粗分成三档。第一档是高性能高价格模型,适合关键决策和复杂工作流,常见于 Claude 高阶型号、OpenAI 高阶型号、Gemini Pro 高阶版本。第二档是均衡型模型,适合做默认主力。第三档是低成本高吞吐模型,适合分类、摘要、意图识别、批量整理和兜底。

如果你的 OpenClaw 任务偏长文整理、研究报告、邮件起草、复杂规则执行,Claude 通常仍是高质量选项。它的优势不在单点跑分,而在整体完成度,尤其是上下文保持、文字稳定性、长段落重写和复杂约束下的输出质量。

OpenAI 系列模型的优势在于生态成熟,工具调用、结构化输出、多模态支持和开发资料最完整。对于需要"能写、能调工具、能读图、能接生态"的 OpenClaw 部署,OpenAI 往往是默认起点。

Gemini 的亮点是超长上下文和文档吸收能力。面对长 PDF、会议资料、资料包归纳、多附件分析时,它常常比只看短对话分数更有意义。若你的 Agent 常处理文档密集型任务,Gemini 值得放进主力池。

DeepSeek 的吸引力很直接,便宜,中文强,推理能力在同价位里有竞争力。对于日常助理、信息整理、内容重写、批处理任务,它往往能把单位成本压到很低。问题也同样直接,复杂代理链路里的稳定性,必须自己在生产环境压测。

豆包、通义千问、文心、混元、Kimi 等模型,在中文办公、企业文档、国内网络环境和本地商务支持上更友好。如果你的 OpenClaw 要接企业微信、飞书、钉钉、内部知识库,这一类模型往往比国际模型更容易落地。

只要场景涉及隐私、内网、离线、固定流程,或者你想把边际成本压到最低,本地模型就有价值。Qwen、Llama、Mistral、GLM 开源系配合 Ollama、vLLM 或 LM Studio,可以承担兜底问答、内部检索摘要、基础流程判断等任务。

这里给的是部署视角下的能力印象,不是学术基准测试排名。真正落地时,应以你的任务样本做 A/B 测试。

最容易犯的错误,是把配置写成"有很多模型名的列表",但没有决策逻辑。真正有效的配置,不是堆供应商,而是明确谁是默认、谁是备用、谁负责便宜任务、谁负责长文档、谁负责本地兜底。

{
  "models": {
    "default": "anthropic/claude-sonnet",
    "fallback": "deepseek/deepseek-v3",
    "profiles": {
      "writing": "anthropic/claude-sonnet",
      "daily": "deepseek/deepseek-v3"
    }
  },
  "routing": {
    "preferCheapFor": ["summary", "classify", "rewrite"],
    "preferStrongFor": ["research", "tool-use", "longform"]
  }
}

{
  "models": {
    "default": "openai/gpt-5.4",
    "fallback": "anthropic/claude-sonnet",
    "lowCost": "deepseek/deepseek-v3",
    "longContext": "google/gemini-2.5-pro",
    "local": "ollama/qwen3:14b"
  },
  "routing": {
    "rules": [
      { "match": "attachments|pdf|long-context", "use": "longContext" },
      { "match": "classification|batch|summary", "use": "lowCost" },
      { "match": "private|offline", "use": "local" },
      { "match": "default", "use": "default" }
    ]
  }
}

{
  "models": {
    "default": "qwen/qwen-max",
    "fallback": "deepseek/deepseek-v3",
    "backupInternational": "openai/gpt-5.4",
    "local": "ollama/qwen3:8b"
  },
  "policy": {
    "preferDomestic": true,
    "allowInternationalFor": ["coding", "deep-research"],
    "sensitiveTasksUseLocal": true
  }
}

以上示例用于说明思路。不同 OpenClaw 版本的字段名可能不同,实际生产配置请以当前模板和插件文档为准。

模型路由的价值,不在炫技,而在省钱和降风险。只要你的 Agent 每天处理几十到几百条请求,手动指定模型这件事就已经过时了。好的路由策略会让用户只管提任务,系统自己判断该用哪个模型。

if task.has_private_files:
    model = "ollama/qwen3:14b"
elif task.contains_many_attachments or task.context_length > 120000:
    model = "google/gemini-2.5-pro"
elif task.requires_multi_tool_use or task.is_high_value:
    model = "openai/gpt-5.4"
elif task.type in ["summary", "classify", "rewrite", "tagging"]:
    model = "deepseek/deepseek-v3"
else:
    model = "anthropic/claude-sonnet"

很多团队不是被模型单价拖垮,而是被错误使用方式拖垮。比如,所有消息都走最强模型;每次请求都带上过长历史;失败后无脑重试;明明是摘要任务却用推理旗舰;低价值通知也调用完整 Agent 链路。成本爆炸,通常是系统设计问题,不是供应商问题。

• 把任务分层,高价值任务才上高价模型,普通任务统一下放到均衡或低成本模型。
• 压缩上下文,能摘要后再传的,不要整段历史全带。
• 做结果缓存,重复问答、重复检索、重复总结优先返回缓存结果。
• 限制失败重试次数,并在第二次重试时切换供应商或切换更稳的模型。
• 把批量任务异步化,让低成本模型并发跑,不要占用主模型处理队列。

1. 默认使用均衡模型
2. 检测到以下条件才升级:
   - 多步工具调用
   - 长文高质量改写
   - 高价值用户请求
   - 复杂代码/数据分析
3. 重复任务优先走缓存
4. 私密资料优先走本地模型
5. 每周复盘:
   - 各模型调用次数
   - 平均响应时间
   - 失败率
   - 单任务平均成本

如果只记一个原则,那就是:把"模型最强"改成"系统最优"。Agent 时代,决定上限的是模型,决定利润和可持续性的是调度。

• 目录项回调:将第二、四部分及第四部分目录下各章标题,尽量回调到 v4 原文表述。
• 章节标题回调:将多处被概括或重写的章节、小节标题,改回更接近原文的说法,如"从0到278,932 Stars:史上最快增长""命名大战:从OpenCloud到OpenClaw""Skills > MCP:Peter的鲜明立场"。
• 关键句回调:将前言、ChatGPT/Claude Code 对比、"养虾"文化等处明显加工过的总括句,回调到更接近原文的句式,保留最小必要排版修正。