Hugo Zhu's Blog

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

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

最近和几个做 AI 的朋友聊天，发现一个有趣的现象：很多人对大模型的信仰是"因为相信所以看见"——相信 AGI 会来，相信 scaling law 会继续有效，相信未来的模型会更强大。

但我的观点恰恰相反：AI 信仰应该建立在"因为看见所以相信"。而我们能看见什么？最直观的就是——高质量数据越多，大模型表现越优秀。这不是信仰，是已经被反复验证的事实。

最近我一直在思考一个问题：在 AI 时代，个人生产力的本质到底是什么？经过大半年高强度使用各类 AI 工具的实践，我得出了一个公式：

个人生产力 = 思考深度 × 资源调度广度

这不是一个数学公式，而是一个思维框架。它帮我重新理解了"人应该做什么"和"AI 应该做什么"这个根本问题。

大多数 AI 助手是无状态的——你关掉窗口，它就忘了你是谁。OpenClaw 试图解决一个更本质的问题：能不能让 AI 助手像一个真正的助手一样，记住你、理解你、主动帮你？ 经过几周的实际使用，我想分享一下 OpenClaw 的架构设计和背后的思考。

最近看到很多文章在教人如何"省 Token"——压缩 prompt、缩短上下文、用更小的模型替代、砍掉 system prompt……这些技巧看似精明，但我越来越确信一个观点：任何以省 Token 为目标的做法，都不是大模型的最佳实践。

这不是因为我不在乎成本。恰恰相反，正是因为我在乎投入产出比，所以我认为"省 Token"是一个错误的优化方向。

2025 年以来，AI 应用层出现了一波令人眼花缭乱的平台：Manus 主打通用 AI Agent，Lovable 专注 AI 驱动的应用生成，Dify 提供 LLM 应用编排框架，Coze（扣子）让用户可以可视化地构建 AI Bot。它们看起来各有侧重，产品形态也不尽相同，但如果你退后一步观察，会发现它们在做的事情本质上是一样的——为大模型开发 Skills。

软件工程师正在经历一场静悄悄的范式革命。过去，一个工程师要成为团队中的技术骨干，往往需要五到十年的摸爬滚打——踩过无数坑，读过海量源码，在生产环境的故障中积累经验。但现在，一个善于使用 Claude Code 的工程师，可以在几个月内走完别人多年的路。这不是夸张，而是正在发生的事实。

你是否好奇过 GitHub Copilot、CodeLlama 这些代码生成模型是如何工作的？本文将带你从零开始，一步步实现一个专注于 Python 代码生成的小型语言模型。通过这个项目，你将深入理解 Transformer 架构、代码 tokenization、以及如何让模型学会"写代码"。

传统的 RPA（Robotic Process Automation）工具通常需要手动编写脚本或使用可视化编排工具，学习成本高且维护困难。随着多模态 AI 的发展，一种新的范式正在兴起：通过录制用户的桌面操作，让 AI 自动理解并复现这些操作。这种方式大大降低了自动化的门槛，让业务人员也能快速构建自动化流程。