OpenClaw

上周五下午 3 点，告警群炸了：MaaS 层的 GPU 推理集群 QPS 在 60 秒内从 1200 飙到 18000，p99 延迟从 800ms 打到 45 秒，大量请求 429。

排查发现原因很"朴素"——大约 3 万个 OpenClaw 实例的定时任务都跑在整点。每个实例可能只有 1-3 个 cron job（数据摘要、定时巡检、报表生成），但所有人的 cron 都写着 0 * * * * 或 0 0 * * *。三万乘以三，就是整点瞬间涌来的近十万个 LLM 推理请求。

这不是应用层的 bug，而是平台设计的缺陷。当你的平台承载成千上万个租户的定时任务时，“整点风暴"不是意外——它是必然。问题是：作为平台设计者，你该怎么办？

你在钉钉里对 AI 助手说：“帮我写一个博客文章”，然后 Agent 回复"好的"——接下来呢？你等了 3 分钟、5 分钟、10 分钟，不知道它在干什么、进展到哪了、是不是卡住了。这是所有 Agent 系统面临的共同问题：编程类耗时任务的进度黑洞。

OpenClaw 通过 Sub-Agent 机制调用 Claude Code 执行编程任务，再借助 stream-json 输出格式和一个轻量级的监控脚本，将任务进度实时同步到钉钉。本文完整拆解这套方案的架构设计和实现细节。

AI Agent 能搜索、能总结、能写代码，但有一件事它做不好：读你的互联网。你的 Twitter Timeline、你的 YouTube 推荐、你的 Hacker News 首页——这些个性化内容藏在登录态背后，普通的 API 调用拿不到。

OpenClaw 的远程浏览器方案解决了这个问题：在一台带桌面的 Ubuntu 服务器上运行真实浏览器，保存各大网站的登录信息，然后通过网络让 AI Agent 直接操控这个浏览器。AI 看到的就是你看到的。

软件行业有一个永恒的矛盾：标准化产品满足不了个性化需求，定制开发又贵得离谱。每家企业都想要"适合自己的办公系统"，但 SaaS 只能给你 80% 的功能，剩下 20% 要么忍着，要么花十倍的钱去定制。

钉钉的 CLI 化开放正在改变这个游戏规则。当钉钉的消息、日历、审批、文档、通讯录等能力都可以通过命令行接口被 AI Agent 直接调用时，一个新范式浮现了：过去需要写代码、做定制、走项目的办公需求，现在可以用自然语言描述，由 AI 用 Token 来交付。

在上一篇文章中，我从 Karpathy 的 autoresearch 项目提炼了一个范式：人写规则，Token 做实验。我们用 AI 客服 Prompt 优化作为案例，验证了这个范式在业务场景中的可行性。但那个方案有一个前提——你需要预先准备评估数据集。

OpenClaw 的场景让我意识到，还有一种更彻底的可能：Agent 用自己的真实执行数据作为评估信号，在用户无感知的情况下持续自我优化。 不需要人工标注测试集，不需要离线批处理，每一次真实使用都是一条训练数据。

把一个 AI Agent 拉进钉钉的多个群，是一件非常容易的事情——群管理员点一下"添加机器人"就完成了。但这也是一件极其危险的事情——如果 Agent Runtime 没有做好隔离，你可能正在制造一个企业级的安全事故。

想象这个场景：你的 AI Agent 同时服务于"核心技术架构群"和"外部合作伙伴群"。有人在合作伙伴群里问了一个问题，Agent 的回答中不小心带出了它在架构群里学到的技术方案细节。信息就这样泄露了，而且没有任何人会收到告警。

这不是假设。这是没有隔离的 Agent Runtime 的默认行为。

你让 AI Agent 帮你跑一个需要 30 分钟的数据迁移脚本，然后就没了下文——它在干嘛？卡住了？还是已经跑完了？你不知道，因为 Agent 只会在任务彻底完成或彻底失败时才告诉你结果。

这是 Agent 系统中一个普遍的痛点：耗时任务的进度黑洞。用户发出指令后陷入等待，没有进度条，没有中间反馈，只有最终的成功或失败。在 OpenClaw 的实际使用中，我总结了四种适用于不同场景的进度上报方案，每种都有其最佳适用场景。

OpenClaw 一天发布了两个版本。消息传开后，有人兴奋地说"AI 时代人月神话终于被打破了"，也有人冷静地问"这真的算打破了吗？"

这个问题值得认真回答。因为它触及的不是某个产品的发布节奏，而是软件工程最根本的规律之一——加人到底能不能加速交付？ 在 AI Agent 成为新型"开发者"的今天，这条规律是否需要被重新审视？

想象这样一个场景：你花了半小时向 AI 助手解释你的项目架构、编码偏好和团队规范，得到了一次满意的协作体验。第二天再打开对话——它全忘了。你又得从头来一遍。这不是 AI 不够聪明的问题，而是记忆架构缺失的问题。OpenClaw 的 Memory 系统试图从根本上解决这个痛点：让 AI Agent 拥有持久、可检索、可自维护的记忆能力。

绝大多数 AI 助手都是被动的——用户不说话，它就沉默。这在"问答"场景下没问题，但如果你想让 AI 助手真正成为助手，它需要主动意识：定期检查收件箱有没有紧急邮件、日历上有没有即将到来的会议、GitHub 上有没有需要关注的 PR。OpenClaw 的 Heartbeat（心跳）机制正是为此设计的。本文将深入解析这一设计的工程细节和最佳实践。