Claude Code 与 OpenClaw：Agent 的分水岭，不在提示词，在 Runtime
最近我做了一次关于 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。
这件事，我会继续看，也会继续写。