前阵子龙虾大热，但很多朋友都不太能用得很顺畅。
它总会有莫名其妙的中断，接收到了指令没有执行完成，遇到的错误莫名其妙就停下来了，也没有任何反馈。有的时候昨天能正常看的邮箱，总结的邮件，但今天就失败了，就算有skill也不稳定。
原因可能是模型限流了，模型思考死循环了，又或者忘记自己在做什么事情了。
相同的模型、Skills，在Openclaw不稳定，到了Claude Code却表现的更好，南橘北枳。
而Claude Code源码泄露后再次证明了这一点，Agent 的差距并不是模型，而是Harness。
为什么OpenClaw不够稳定？
OpenClaw的这些不稳定的问题，并不是偶发bug，而是架构设计的必然结果。
心跳：能唤醒模型，却不能调度
OpenClaw 的 heartbeat 本质是一个定时触发的主会话轮次，默认每 30 分钟唤醒一次（来源）。
它能叫醒模型，但唤醒之后的事，心跳就不管了。
更尴尬的是，心跳会去响应已完成的后台任务，但本身却不会创建任何任务记录。没有任务记录，意味着没有完成确认，没有失败重试。
而且你也不知道到底有没有唤醒成功、会不会重复唤醒——重复唤醒，于是莫名其妙地告诉你限流了。
Sub-Agent：拆不拆靠玄学，稳不稳定靠运气
建立sub-agent的能力其实是一个Tool，既然是Tool使用的选择权其实在人类和AI手上，如果我们没有明确说明，那模型可以调用它拆解子任务，也可以不拆解。
于是复杂的任务可能在一个上下文窗口里处理，幻觉越来越多，而拆Sub-Agent如果没有设置好足够的超时，又可能会宕机、限流。
就算模型决定拆了 Sub-Agent，它的生命周期管理也是 Best Effort，在SubAgent 的篇章里，用了3-4个Best Effort，也就是尽力而为。
如果你的小龙虾重启了，那它可能就忘记了自己之前在做什么。
而在任务完成的时候，可能sub-agent处理的进程并不会关闭，还在继续占用你的资源，于是响应速度越来越慢。
默认的消息机制是收集机制
我们在使用龙虾的时候会发现，消息进线之后基本就要等待它处理完，它才会继续响应，如果说我们的任务做错了、打错字了也没用。
其实这个是龙虾的默认机制，在处理当前消息的时候，后面的都不处理，处理完手头上的事情再一次性处理刚刚的消息。但这种时候可能你要等很久，可能做错了有了脏的数据，后面的表现也越来越差。
我们可以调整成steer模式，这也是claude code相关的机制，这样可以让我们在上一条消息在处理的过程中继续发送消息让它进行调整。
出问题的时候容错性不够强
1. 事件流不是可靠日志
Gateway 文档说，实时事件错过了不会补发，客户端发现断层后要自己刷新。它能做 UI 实时同步，但不是一条可回放的事件日志。
2. 重试机制处理的的是请求，不是整段任务
Retry Policy 文档也明确说，重试是基于每个请求，复合流程里已经完成的步骤不会自动重试。
所以消息发送失败可以重试，媒体上传失败可以重试，但 Agent 跑了 10 步、第 7 步挂了，但这是因为第6步的错误导致的，这些已经完成的步骤是不会自动恢复的。
3. 队列是进程内的排队器，而不是持久化消息系统
Queue 文档说他们是一个极小的串行进程。
而且没有什么外部依赖，它主要做的是把并行的任务错开，避免争用共享资源。这种轻量的实现方式，并不是特别注重挂了以后把任务找回来。
OpenClaw 的容错短板，不是没有任何恢复机制，而是没有串成一条统一、完整的链路。
消息请求失败，可以重试。上下文过载，也会有压缩，后台的任务也会落盘。但主会话 Agent run 跑到一半断了、客户端失联了、事件漏了、工具中间失败了，系统并没有一个恢复机制让它更加的稳健。
它的局部容错还没有长成端到端 Harness 的表现。
Claude Code泄漏，揭示了什么
3月31日，Anthropic把Claude Code的大量源码直接送到了公众面前，它暴露出来的，是一整套生产级的Agent Runtime。
Claude Code并不是模型回答一句、程序执行一步的玩具循环，而是一个很长的状态机。
每次运行的时候，都会按顺序去完成10件事，先去基于上下文的活跃程度以及token消耗压缩上下文，然后对token预算进行检查，决定是否要继续完成任务。
通过了这两项检查再去调用模型，然后流式的调用工具尽可能提高工具的运行效率，在运行完毕还会注入额外的上下文，确保模型知道之前发生了什么事情。
在健壮性层面，模型还会去做自动的上下文压缩，对输出进行校验是否要允许模型继续运行等等。
第二个部分则是上下文和记忆工程了，这里有一套渐进式压缩管线。
先裁大工具输出，将完整内容存储，然后只保留预览到上下文。再清理旧结果，把没有用到的上下文进行标记和清理，这些模型就不再处理了。
最后才是做更重的折叠和总结，渐进式的处理能够避免我们上来就花钱去总结，能够使用更低的成本获取接近的效果。
而把最近文件、技能、工具声明重新注入到上下文，则是很好的容错机制，能保证模型不会断片忘记内容。
回头看 OpenClaw 的那些问题：
心跳唤醒后不管后续：Claude Code 的状态机每次循环都做完整的检查、执行、注入；
Sub-Agent 生命周期不可靠：Claude Code 对输出校验、工具失败有统一的处理路径；
消息机制无法纠偏：Claude Code 原生支持 steer；
容错孤立、单一：Claude Code 把压缩、预算、重试串成了一条完整的链路。
AI的尽头是工程，Claude Code的强大和稳定是把Agent最容易失控的几件事：长任务跑偏、上下文溢出、中途打断、子任务污染、状态丢失处理逻辑，定义在了代码里。
AI的未来是Harness Engineering
Harness Engineering的意义在于把模型的不稳定，变得稳定，它来衔接模型的调度、任务的执行、会话的记录。
Anthropic 在最新的博客 Managed Agents 把 Agent的管理拆成三件事：大脑Brain、手Hands、会话Session。
Brain 是模型和 harness，它负责思考、规划、决定下一步。Hands 是 sandbox 和 tools，负责在哪执行、执行什么以及怎么执行。Session 则负责记录任务全过程，三者相互独立。
在独立过后依赖就变少了，任务失败需要恢复的检查也会变得更少，重试会变得更高效。
把上面 Brain/Hands/Session 展开，就是这幅图的六个组件。
LangChain 在《The Anatomy of an Agent Harness》中给出了最简洁的定义："If you're not the model, you're the harness."
如果你不是模型，那你就是 Harness。
这里的每个部分有什么作用呢？
- Session 负责状态和事件日志，记录一切的上下文
- Orchestration 负责唤醒和调度
- Harness 负责判断模型的意图是否需要审批、在哪里执行和重试、怎么持久化和回复。
- Sandbox 负责隔离执行的环境，负责在哪里执行
- Resources 是你的文件系统，是需要被操作使用的内容
- Tools 是模型能调用的能力接口，负责关心怎么执行
回过头看，OpenClaw 的那些问题：心跳只是提醒、Sub-Agent 生命周期不可靠、容错链单一，本质上就是这些组件没有完全就位。
理解了这些，再看这条进化线就很自然了：从 Prompt Engineering，到 Context Engineering，现在我们走到了 Harness Engineering。
提示词决定了AI怎么做，上下文提升了AI对任务的理解，而这一轮的Harness则是给AI装上了安全带：让它运行得更加稳定、稳健。
Claude Code 的强大，是因为Infra和Harness做的更好。而OpenClaw 更像积木，它的不稳定，恰恰是开放架构的代价。它更加的开放、灵活、可拼装，但很多地方还需要自己补充。
未来真正成熟的 Agent，也许不是某一个固定 harness，而是 Anthropic 说的这种 meta-harness：Brain 可以换，Hands 也可以换，我们可以有多个大脑，也有多只手，来适应复杂、长程的任务。
Agent 的上限看模型， Agent 的下限看的是 Harness。
作业终于交完了，一口气把Openclaw的说明文档、Claude Code的源码解析还有最新的Managed-agents Blog都看完了，大概是一些想法和理解，
AI 的Infra和Harness真是有趣，Infra让搭建变得更迅速，让你的AI产品能够调度模型、提示词、知识库、MCP和Skills资源，也基于可观测性设定自己的Benchmark进行评测、调优。
Harnees，则是更健全的运行机制，仅仅是以前的React、Plan-and-Excute已经不够用了，知识常读常新，活到老也学到老。
看了很多分析和参考资料，可能有些理解不太正确或者有错误的地方，也麻烦多多见谅，欢迎斧正。
注：部分图片由AI生成
参考资料
1)www.anthropic.com/engineering…
3)harrisonsec.com/blog/claude…
4)harrisonsec.com/blog/claude…
