夜雨聆风
OpenClaw教会我们的三件事:从Prompt到Harness的设计哲学
当所有人都在”养虾”时，真正值得学习的，是这只龙虾背后的设计思想。
一场狂欢背后的冷静思考
2026 年开年， OpenClaw 突然火了。
从科技圈到普通用户，人人都在谈论这只”小龙虾”。各大厂纷纷推出类似产品，社区里充斥着”养虾攻略”，甚至出现了”499 安装之后再花 299 卸载”的段子。
但热闹之外，我更想知道的是：这只虾到底是怎么设计的？
翻完它的源码，我发现 OpenClaw 并非凭空诞生。它更像是一次技术集大成——把 Agent 领域近年来的关键突破，系统地整合在一起：
量变引起质变。当这些技术汇聚到一起， Agent 从”聊天机器人”进化成了真正的”私人助理”。
而这背后，藏着三个工程维度的设计哲学。
Prompt Engineering ：不再是写提示词那么简单
很多人以为 Prompt Engineering 就是”写好提示词”。
但 OpenClaw 告诉我们：现代 Agent 的 Prompt ，是一场结构化的组装工程。
它的 System Prompt 不是一段固定文本，而是由 23 个模块像搭积木一样拼起来：
更关键的是，它定义了三种模式：
| 模式 | 用途 | 特点 |
|---|---|---|
| full | 主 Agent 对话 | 全模块加载 |
| minimal | 子 Agent 执行 | 只保留核心 |
| none | 极简场景 | 仅身份标识 |
为什么这样设计？因为上下文窗口是有限的。
不同场景用不同配置，既保证了能力，又控制了成本。
Markdown 驱动：把”灵魂”写进文件
OpenClaw 最精妙的设计之一，是用 Markdown 文件来管理 Agent 的核心信息：
这套机制的好处是：配置与代码解耦。
你可以用普通的文本编辑器修改 Agent 的”灵魂”，不用碰一行代码。
而且 Markdown 比纯文本多了格式，能清晰刻画重点；同时又可以用 Shell 命令管理——grep 一下就能读取。
极简主义：质量大于数量
读 OpenClaw 的原始 Prompt ，你会发现一个特点：极度简洁。
比如，要求群聊时不要每条都回复，它只用一句：
Quality > quantity
要求不确定时询问用户：
Ask anything you’re uncertain about.
这种极简风格，背后是对 token 的敬畏。
每一个指令都要精炼，为业务数据留出更多上下文空间。优秀的 Prompt 不是越长越好，而是越清晰、越模块化越好。
Context Engineering ：在有限窗口里装下无限知识
如果说 Prompt 解决的是”做什么”， Context Engineering 解决的是”做得更好”。
Agent 运行中最大的挑战：上下文窗口爆炸。
如果一味堆砌历史记录、工具返回，不仅推理变慢、成本飙升，还会触发”Lost in the Middle”——模型找不到核心指令。
OpenClaw 用三层机制来应对。
Skills 机制：能力无限，上下文有限
OpenClaw 默认只有基础能力。但通过 ClawHub 市场，它可以获得 PPT 制作、语音合成等新技能。
关键是：技能不预加载。
当任务需要时，系统才把技能名称注入上下文。这样 Agent 拥有近乎无限的能力边界，同时保持日常运行的轻量级。
上下文压缩：保留精华，舍弃冗余
当对话历史太长时， OpenClaw 会触发压缩机制：
/compact 命令压缩算法的核心思路：
完整保留最近的对话，将早期内容压缩成精炼摘要。
这就像开卷考试：必考的最近几页完整保留，前面的知识做成摘要。
而且摘要会被特别要求保留：
– 当前活跃任务
– 重要决策和结论
– 待办事项
– 所有 UUID 、哈希值等标识符（必须原文保留）
双层记忆：长期不丢，每日可查
大模型有个致命弱点：每次会话”全部失忆”。
OpenClaw 的解决方案是双层记忆：
| 层级 | 文件 | 内容 | 特点 |
|---|---|---|---|
| 长期记忆 | MEMORY.md | 高价值事实与偏好 | 每次对话都注入，不衰减 |
| 每日记忆 | memory/日期.md | 日常交互细节 | 按需搜索，随时间衰减 |
每日记忆还设计了时间衰减机制：
30 天前的记忆权重减半， 60 天前只剩四分之一
模拟人类的”自然遗忘”，确保记忆库聚焦于高价值信息。
Harness Engineering ：给野马套上缰绳
第三个维度，是最近兴起的概念： Harness Engineering 。
Harness 原意是”马具”。
如果 Agent 是一匹天赋异禀的”千里马”，不加 Harness 就是草原上自由奔跑的野马——速度快，但方向不可控。
Harness Engineering 的核心使命：确保模型”可控地做”。
为什么需要 Harness ？
没有约束的 Agent ，容易出现四大问题：
| 问题 | 表现 |
|---|---|
| 过早终止 | 写完代码就停，不管有没有报错 |
| 缺乏反思 | 执行完毕不验证，交付质量低下 |
| 死循环陷阱 | 遇到错误无限重试，浪费资源 |
| 高风险操作 | 删除文件、调用外部 API 缺乏审批 |
Harness 把这些”自觉行为”变成强制约束：
Hook 机制：全生命周期的”检查点”
OpenClaw 的 Hook 系统贯穿 Agent 运行全程：
| 钩子 | 触发时机 | 用途 |
|---|---|---|
| before_tool_call | 执行工具前 | 参数校验、拦截错误 |
| after_tool_call | 工具执行后 | 结果处理、纠偏 |
| before_compaction | 上下文压缩前 | 观察压缩过程 |
| message_received | 收到消息时 | 消息预处理 |
实战场景：调用云服务 API 时， Hook 可以校验实例 ID 格式。如果发现参数错误，直接返回提示，迫使模型修正——而非盲目执行后报错。
三层沙箱：安全纵深防御
随着 Agent 能力增强，安全边界也在扩展。 OpenClaw 设计了三层沙箱：
底层还有操作系统最小权限兜底。
这套机制不依赖模型的”自觉”，而是系统级的强制力——给马匹装上”电子围栏”。
从”养虾”到”造虾”
OpenClaw 火了，但它的价值不在于”跟风养一只虾”。
真正的价值在于设计哲学：
Prompt Engineering 告诉我们：
优秀的提示词不是写得长，而是结构清晰、模块化、节省资源。
Context Engineering 告诉我们：
上下文管理不是堆砌数据，而是像图书管理员——知道何时放进仓库，何时抽出递给你。
Harness Engineering 告诉我们：
不要指望野马自己认路。只有配上合适的马具，才能让它成为可靠的助手。
在 to B 的企业场景，我们面临更严苛的要求：时效性、数据安全、可控性标准。完全照搬开源的”个人助理”形态往往不现实。
但 OpenClaw 的设计思想，是可以复用的。
当你构建自己的 Agent 系统时，问问自己：
相较于闭源产品只能黑盒推演， OpenClaw 让我们有机会深入源码，理解每一个设计决策。
这才是这场狂欢背后，真正值得沉淀的东西。
技术浪潮总有起伏。大潮来时敢于直面，大潮退去要能留下精华。
OpenClaw 是一次重要的技术里程碑。它教会我们：构建 Agent ，不是调用模型那么简单，而是三个工程维度的系统性设计。
未来已在加速狂奔。让我们带着这些设计哲学，去构建属于自己的、可靠的、可控的 Agent 系统。