夜雨聆风最近我做了一次关于 Claude Code 和 OpenClaw 的拆解。
拆到后面，我的判断越来越明确：
今天 Agent 的真正分水岭，已经不在提示词，不在 function calling，也不在“接了多少工具”。分水岭在 Runtime。
很多系统看起来很聪明，其实只是把流程图画得更复杂；很多系统真正强，不是因为它多会说，而是因为它的运行时更干净、更克制、更接近一个操作系统，而不是一个聊天框。
这篇文章，我想把这个判断写清楚。
先说我的结论
如果只让我用一句话概括这次拆解，我会这样说：
Claude Code 让我更确定，强 Agent 的核心不是复杂流程，而是一个稳定、低摩擦的 Model ↔ Harness loop。
OpenClaw 让我更在意另一件事：当用户不说话的时候，Agent 是否还“存在”。
前者解决的是 会话内如何高质量工作；后者开始触碰 会话之外如何持续待命。
这不是功能差异，而是系统哲学的差异。
一、很多 Agent 一开始就做反了
过去大家做 Agent，思路非常一致：
用户输入进来，先预处理，再分类，再走规则，再选动作，再生成输出。
这套东西很熟悉，也很像传统软件工程。但问题是，它默认真正负责思考的是开发者，模型只是流程中的一个组件。
我的看法越来越激进一点：
强模型时代，开发者不应该继续替模型写完大部分决策路径。
更合理的方式是：
给模型一个足够完整的工作环境，让它自己决定该读什么、查什么、调什么工具、什么时候停。代码负责的是执行，不是代替思考。
换句话说：
模型是 Agent，代码只是 Harness。
这句话听起来像口号，但它实际上是一条架构边界。
一旦你把这条边界划清，系统的设计重点就会立刻变化：
你不再优先去补规则，而是优先去设计循环、上下文、状态、隔离、压缩、回滚。
也就是：你终于开始做 Runtime 了。
二、Claude Code 真正值得学的，不是功能清单，而是那个循环
我看 Claude Code，最佩服的从来不是某个具体功能，而是它底层那种极简到近乎冷酷的结构。
本质上，它的内核可以压缩成下面这件事：
模型读取当前上下文
模型判断下一步动作
如果需要，发起工具调用
Harness 执行工具
执行结果回传给模型
循环继续，直到结束
这听起来朴素，但真正重要的恰恰是它的朴素。
因为这意味着，Claude Code 的核心能力不是来自“预先写好的流程编排”，而是来自一个稳定、低阻力、可持续扩展的运行环。
如果你更想看这个循环被压到工程实现层，下面这页也很关键：
这两张图里最重要的一点，不是箭头怎么画，而是责任怎么分：
模型负责判断
Harness 负责执行
循环负责推进任务
Harness 越薄越好，越稳定越好。它不需要显得聪明，它只需要不要妨碍模型发挥。
这也是我为什么一直觉得，很多团队在 Agent 上花了大量时间，却没有真正做出质变：
他们在堆 orchestration，却没有把 runtime loop 设计明白。
三、Claude Code 真正强的地方，是它把“上下文”当成系统资源，而不是聊天记录
我认为 Claude Code 最有价值的部分，不是工具，而是它把 context engineering 做成了一门系统设计。
大多数 Agent 的问题，表面上像“模型不够聪明”，其实更像是上下文管理失败。
1. 它对抗的是 Context Fade
长任务里，模型最容易发生的不是不会做，而是慢慢忘：
目标是什么
做到哪一步了
哪条分支已经验证过
下一步该推进什么
Claude Code 的高明之处在于，它不让模型“硬记住”，而是把计划和状态写出去。
Todo 类机制的价值，不在于多一个待办列表，而在于：
它把任务状态从隐式 token 流里剥出来了。
也就是说，状态不再只是“模型好像还记得”，而变成了一个外部可读取、可恢复的对象。
2. 它对抗的是 Context Pollution
另一个更隐蔽的问题，是探索污染。
模型为了完成任务，会看很多文件，试很多方向，做很多中间判断。但这些中间过程大部分不值得永久留在主上下文里。
真正危险的，不是模型犯错，而是错误和试探不断堆积，最后把主任务淹掉。
Claude Code 用 Subagent 一类机制，把探索过程隔离出去。这件事我很认同，因为它本质上不是“多开一个代理”，而是在做一件更基础的事：
把探索线程与主线程分开。
这是一种非常典型的系统思维。
3. 它对抗的是 Context Explosion
上下文不是数据库，也不是日志归档系统。
如果任务足够长，所有历史都不经处理地往里堆，结果一定是：
token 成本上升
判断质量下降
模型越来越迟钝
新旧信息混成一团
Claude Code 给我的最大启发之一，就是这句潜台词：
Context is working memory, not permanent memory.
也就是说：
上下文只负责当前热工作集
长期信息要压缩、摘要、外移
真正重要的状态，不该永久滞留在主回合里
下面这页图很适合概括 Claude Code 对上下文问题的处理框架：
如果一个 Agent 系统没有这层意识，它一开始也许还能跑 demo，但很难跑成长任务，更别说长期运行。
四、Claude Code 的贡献，不只是“写代码比较强”
我并不觉得 Claude Code 的意义，只是“代码能力很强”。
我更愿意把它看成一个信号：
Agent 产品的竞争，正在从模型参数竞争，转向 Runtime 设计竞争。
未来真正拉开差距的，很可能不是谁能接更多工具，而是谁更懂：
如何维持一个稳定循环
如何外化任务状态
如何隔离探索污染
如何压缩历史
如何把 memory 从 chat log 中解耦
说得更直接一点：
Agent 的差异，会越来越像操作系统差异，而不是聊天框差异。
这是我拆完之后非常确信的一点。
五、但 Claude Code 也有明显边界：它仍然是被动的
Claude Code 很强，我没有异议。
但它的边界也很清楚：
用户不说话，它就不工作。
这不是缺陷，而是它的定位。
对于一个“前台交互型 Agent”来说，这已经足够优秀。但如果我把 Agent 理解成一个长期在线的工程实体，那这个边界就会变得非常明显。
现实世界里，大量工作不应该总靠用户来提醒：
该不该检查一下状态
有没有新任务出现
某个待办是不是卡住太久了
是否需要做一次轻量巡检
真正成熟的 Agent，不应该永远等别人踢一脚才动。
它应该有一种低成本的、自我约束的存在方式。
而这，也正是 OpenClaw 让我开始认真关注的地方。
六、OpenClaw 最有意思的，不是“更会对话”，而是它开始进入 Runtime 层
我对 OpenClaw 的兴趣，并不只是因为它想做一个像 Claude Code 一样能干活的 Agent。
我真正觉得它值得看，是因为它在尝试回答一个更系统级的问题：
当没有用户输入的时候，Agent 如何继续存在，但又不制造噪声？
这个问题表面上像调度问题，实际上牵涉到整个运行时哲学。
如果做得粗暴，后台轮询只会带来两件事：
无意义地消耗 token
无意义地污染上下文
所以问题从来不是“能不能主动”，而是：
能不能在不把系统弄脏的前提下主动。
OpenClaw 给出的方向，是 Heartbeat。
也就是后台定时做一次非常克制的询问：
“现在有事需要做吗？”
只有在满足条件的时候，才真正进入 Agent turn。
下面这页很适合看 OpenClaw 对 Heartbeat 的设计思路：
再往下一层看，它已经不是单纯在做一个“会聊天的 Agent”，而是在做一个带前后台分离的 Runtime：
我喜欢这套设计，不是因为“主动”两个字听起来很性感，而是因为它至少在试图把 Agent 从对话界面里解放出来。
它开始像一个真正的 Runtime，而不是一次性会话脚本。
七、Heartbeat 最值钱的地方，不是唤醒，而是回滚
在我看来，OpenClaw 这里最漂亮的设计点，不是定时检查，而是 No-Action Rollback 这种思路。
也就是说：
如果一次后台心跳最后发现没有事情可做，那最好的处理方式，不是把这轮老老实实记进 transcript，而是让这轮像没有发生过。
这是一个非常“系统”的判断。
因为长期运行的 Agent，如果把每次无效巡检都写进历史，很快就会把自己拖死。几天以后，主上下文里全是“我检查过了，没事”。这样的系统不是主动，而是在自我污染。
所以我特别认同这样一个原则：
只有产生有效信息的回合，才值得被持久化。
这句话我认为很重要。
它意味着 Agent 的长期可用性，不只是靠会做事，也靠会“什么都不留下”。
在很多系统里，删除无意义状态的能力，往往比新增能力更难，也更高级。
八、我为什么越来越相信：未来的 Agent 一定会前后台分离
从 Claude Code 到 OpenClaw，我看到的其实是一条很清楚的演化路径。
第一阶段：会话内 Agent
关注的是：
当前用户任务怎么完成
工具怎么调
上下文怎么维持
探索怎么隔离
Claude Code 在这一层已经相当成熟。
第二阶段：运行时 Agent
关注的是：
没有用户输入时系统如何待命
后台如何低成本巡检
前后台是否隔离
调度是否有优先级
无效回合是否可回滚
到这一步，Agent 已经不再只是一个“更强的聊天框”，而更像一个有前台、有后台、有状态治理能力的运行体。
我越来越相信，真正长期可用的 Agent，一定会走到这一步。
下面这页图，我觉得很适合作为这条演进路径的视觉收束：
九、文件系统中的 SOUL、IDENTITY、USER、MEMORY，是另一条很重要的线
这次拆解里，还有一部分我很喜欢：
把 Agent 的人格、规则、用户画像、长期记忆，沉到文件系统里。
这个方向非常重要，因为它在回答另一个长期被混淆的问题：
人格、规则、记忆，到底应该存在于哪里？
如果全塞进 prompt，系统会臃肿；如果全写死在代码里，系统会僵硬。
文件化是一种更像工程系统的做法：
SOUL.md 管行为边界
IDENTITY.md 管身份风格
USER.md 管用户画像
MEMORY.md 管长期沉淀
下面这页，正好能把身份、记忆、heartbeat 这几个层串起来：
而如果把视角再拉远一点，这种设计最终指向的，其实是一种更像“Agent OS”的思路：
我觉得这件事的价值，不只是好维护，而是它终于把几个本来总被搅在一起的层分开了：
Constitution layer
Persona layer
User layer
Memory layer
Execution layer
一旦分层明确，系统才可能真正可演进。
这也是我为什么一直觉得，未来成熟的 Agent，一定不是“大 prompt 怪兽”，而是一套分层资产系统。
十、我的当前判断：Agent 正在从 Prompt 问题，变成 Runtime 问题
如果现在让我把这篇文章再压缩成一句更直接的话，我会说：
Agent 的本质，正在从提示词工程，转向运行时工程。
过去大家最关心的是：
prompt 怎么写
function call 怎么接
工具怎么调
但我现在更在意这些问题：
回合怎么循环
状态怎么外化
探索怎么隔离
历史怎么压缩
后台怎么唤醒
无效动作怎么回滚
人格和记忆怎么脱离 prompt 独立存在
这些问题，才真正决定一个 Agent 能不能活过 demo，活过一周，活进真实世界。
在这个意义上，Claude Code 更像是把“会话内 Agent”做到了一个很高完成度；而 OpenClaw 则让我看到，Agent 下一阶段也许不是更花哨，而是更像一个真正的 Runtime。
结尾
我并不想把这篇文章写成“Claude Code 和 OpenClaw 谁更强”的对比文。
对我来说，它们更像两个阶段性的路标：
Claude Code 让我更确定，复杂流程图不是答案，优秀的 Harness 才是
OpenClaw 让我继续追问，Agent 是否应该拥有后台、心跳、回滚、文件化人格与长期记忆
所以这次拆解之后，我最大的收获不是记住了几个功能名，而是重新调整了我看 Agent 的焦点。
未来真正重要的，不是谁把 prompt 调得更花，而是谁先做出成熟、克制、长期可运行的 Agent Runtime。
这件事，我会继续看，也会继续写。
