夜雨聆风
配好一只虾，和真正用好一只虾，是两件事。
很多人配完五层之后，虾还是一个"反应更快的搜索框"——你说话它才动，你不说它就在那等。这不是虾的问题，是它还没被激活。
这篇文章用一周五天、五个真实场景，展示激活之后工作流长什么样。每天两层：操作层直接给配置，复制可用；深层讲清楚机制，让你真正理解发生了什么。
周一：情报开工
周一早上坐下来，打开手机，飞书有一条新消息。
不是同事发的，是虾。三天的 AI 行业动态，五条摘要，每条带原文链接。你喝咖啡的时候读完了。
这个动作之前要花你一到两小时——开始手动刷，刷着刷着跑题，重要的可能错过，不重要的反而读了很多。
现在不用了。这是第一次感受到"它在为你工作，不是等你开口"。
深层：HEARTBEAT 和 Cron 是两个不同机制
很多人把这两个概念混在一起，用错场景。
HEARTBEAT = 巡逻员。每隔固定时间（30分钟、1小时）主动检查一次：有没有紧急消息？有没有需要跟进的事？没事的话它只在系统内部返回 HEARTBEAT_OK，不打扰你；有事才推送。实测数据：每次心跳耗时约10秒，一整天主动推送 3-5 条，绝大多数心跳你根本感受不到它在运行。
Cron = 闹钟。你定时间，到点就执行。不管今天有没有紧急情况，不管虾在不在忙，该8点推的8点推。用于固定时间的定制任务——比如周一早上的情报摘要。
两者配合才完整：Cron 保证关键任务准时触发，HEARTBEAT 保持持续的背景感知。
HEARTBEAT 为什么不会骚扰你？
关键在 HEARTBEAT_OK 机制。虾每次检查完如果没有需要推送的事，只在内部记录这个状态，不发任何消息。你的飞书不会收到"我巡逻了没发现问题"这种废话。只有真正有内容时，才会出现在你的消息列表里。
操作层：先用自然语言，再决定要不要配文件
最简单的方式，不是先打开配置文件。
你直接对虾说：
以后工作时间每小时巡检一次。检查三件事：有没有紧急消息、有没有今天承诺但还没开始的任务、有没有值得我现在知道的新情况。没有就不要打扰我。另外，从每周一早上 8 点开始，给我发过去 3 天的 AI 工具和产品行业重要动态，整理成 5 条摘要，每条不超过 60 字，带原文链接。
如果你的 OpenClaw 已经开了对应工具权限，这件事本来就可以由它来帮你完成：它可以改 HEARTBEAT.md，也可以创建 cron 任务。如果你不想让它直接动配置，或者你想完全可控，那再用手动方式。
Heartbeat的手动版，核心不是写很多规则，而是写一张很短的清单。HEARTBEAT.md 放在 workspace 里，内容越短越好。比如：
# 心跳检查清单- 快速扫描：有没有需要立即跟进的紧急消息？- 有没有今天承诺要做但还没开始的事？- 如果没有需要主动提醒的内容，回复 HEARTBEAT_OK，不要发送任何消息
然后在配置里打开 heartbeat，例如：
{"agents": {"defaults": {"heartbeat": {"every": "1h","target": "last","activeHours": {"start": "09:00","end": "22:00","timezone": "Asia/Shanghai"}}}}}
Cron的手动版也很直接。比如周一早上 8 点的情报摘要，可以这样加：
openclaw cron add \--name "周一AI情报" \--cron "0 8 * * 1" \--tz "Asia/Shanghai" \--session main \--system-event "现在是周一早8点，请搜集过去3天的AI工具和产品行业重要动态，整理成5条摘要，每条不超过60字并附原文链接，推送到飞书" \--wake now
你不需要先理解全部 cron 语法。
08**1就是“每周一早上8点”；想改工作日，就改成08**1-5；想每天早上9点，就改成09***。
这里真正重要的不是命令本身，而是一个判断标准：
能用自然语言完成的，优先让它自己完成；只有涉及权限边界、安全范围、外部通道控制时，才保留手动配置。
比如“帮我把巡检逻辑写进 HEARTBEAT.md”“帮我加一个周一晨报”，这类都可以优先自然语言。但像 allowFrom、外发权限、谁能给它发消息、它能不能自动发到飞书，这些属于安全边界，最好还是你手动确认。
周二：需求拆解
周二上午，收到一份新需求文档。
没有虾之前：自己读，套框架，翻历史项目找参考，写分析，发现方向不太对，再改。整个过程有一半时间在"重建工作状态"——重新提醒自己这个项目的背景是什么，上次类似的需求踩过什么坑。
有了配置好的 SOUL.md 和 MEMORY.md 之后：发过去，直接说"帮我分析这个需求"。
深层：SOUL 和 MEMORY 的分工
两者分工明确，不能混用：
SOUL.md 管"你是谁，你怎么工作"。它在每次对话开始前就注入到系统提示词里，虾不是"听了你的要求才知道你是产品经理"，是"它一开始就知道"。
MEMORY.md 管"你们之间发生过什么"。对话中积累的偏好、纠正的错误、做过的决策，通过 memoryFlush 自动写入，下次对话自动带入。
一个对比就很明显：
没有沉淀的虾，看到需求文档，容易给出这种回答：
当然，我来帮你分析这份需求。功能需求包括：登录、数据看板、导出报表。建议：这些功能可以按优先级逐步实现……
它很礼貌，也不算错，但没有立场。
有沉淀的虾，起手更像这样：
这份需求有个核心问题没说清楚：它说要“提升用户体验”，但没说明到底是在解决“找不到入口”，还是在解决“流程太长”。这两个问题的解法完全不同。我先看到三个风险：第一，没有老用户迁移方案；第二，时间节点和资源投入没对上；第三，“更简洁”和“功能完整”在这里是有冲突的，但文档没有说明优先级。这类需求先确认业务目标，再谈功能。
差距不只是风格，而是：它是不是已经知道你怎么判断问题。
操作层：别一上来写文件，先让它帮你写
这类设置，现在最省力的办法，通常不是你自己先去编辑 Markdown。
你可以直接对它说：
以后我发需求文档给你时，默认按这套顺序分析：业务目标 → 用户真实痛点 → 技术边界 → 与现有功能的冲突。不要用“当然”“这取决于具体情况”这种空话开头。风险要先说，不要把结论藏到最后。把这些写进 AGENTS.md。另外，我是产品经理，专注 AI 工具方向，分析时优先考虑用户真实痛点而不是表面需求，这部分放进 SOUL.md。
这样比你先手写三份文件更符合真实使用路径。
如果你确实想手动写，也建议按这个分工来：
SOUL.md 写你是谁，不要写满流程。比如：Cop
我是产品经理，专注 AI 工具方向。判断问题时，优先看用户真实痛点，而不是表面提出的功能诉求。表达上直接、结论先行，不用讨好式开场，不给无立场答案。
AGENTS.md 写工作方法。比如：
# 需求分析默认流程1. 先判断业务目标，不是先列功能2. 区分用户表达的需求和真实痛点3. 主动指出技术边界和风险4. 检查与现有功能的冲突或协同# 输出要求- 先结论，后论据- 风险必须明确标出- 禁止以“当然”“这取决于具体情况”开头
MEMORY.md 写长期有效的共识。比如：
- 用户做需求分析时，偏好先说风险，再谈方案- 用户不喜欢没有立场的回答- 迁移类需求需要主动追问老用户迁移成本
这里有一个很重要的经验：SOUL 要短，AGENTS 要准，MEMORY 要少而真。
不是写得越多越好。写得太长，它们会互相抢上下文；写得太满，很多规则根本不会长期稳定执行。短，但清楚，通常比长而全面更有效。
还有一个容易被误解的点：memoryFlush。它的作用，不是神奇地“自动把你的一切偏好都写好”，而是在会话接近压缩时，提醒系统先把值得留下的内容写进记忆文件。官方示例里，常见配置是：
{"agents": {"defaults": {"compaction": {"reserveTokensFloor": 20000,"memoryFlush": {"enabled": true,"softThresholdTokens": 4000}}}}}
备注：核心参数 softThresholdTokens 控制的是距离压缩阈值还剩多少 token 时提前触发。默认值 4000，调大则更早触发、稳定性更高；调小则更晚触发、flush 频率更低。
你不一定需要手动改这些参数。对大多数人来说，知道它存在、知道它是“接近压缩前的记忆提醒机制”就够了。真正重要的不是你把数值调到多少，而是：你有没有把值得长期生效的东西，真的写进长期记忆。
周三：深度写作
周三，要写一篇专栏文章。
过去的流程：第一件事解释风格——"我不要 AI 味，要直接，开头不要从定义开始"。写出来发现还是不对，再解释，再改，改三遍。每次写文章，有一半时间花在"让虾理解我的风格"上。
现在：直接说主题，它已经知道你的风格，知道你喜欢的开头方式，知道哪些表达你改了三次。第一稿的方向基本对了，修改集中在内容本身，不在形式。
深层：写作偏好靠 MEMORY，写作流程靠 AGENTS 或 Skill
这里最容易被写错。
很多人会把写作流程、写作偏好、人格风格全部混在一起，最后哪都不准。
更稳定的分法是：
写作偏好，放在 MEMORY.md。比如：不喜欢“综上所述”、开头不从定义开始、第一稿不要写太满、不要“很多人认为”这种泛泛表达。
写作默认流程，先放在 AGENTS.md。比如：先确认核心主张；给两个开头方向；第一节写完先停一下；每节完成前默默检查是否违反用户偏好。
当这套流程已经稳定复用很多次时，再升级成 Skill。
这里要特别说明一个技术点：Skill 不是在 workspace 根目录直接放一个 SKILL.md 就完了。真正的 Skill，是放在 skills/某个技能目录/SKILL.md 里的一套可复用能力。也就是说，如果你要做写作 Skill，更像这样：
workspace/skills/writing-flow/SKILL.md
而不是：
workspace/SKILL.md
这件事看起来像小细节，但会直接影响“你配了为什么没生效”。
操作层：先别急着做 Skill，先把高频写作规则沉淀下来
如果你现在刚开始，最省事的方法不是上来就做 Skill。
你直接对它说：
以后帮我写文章时，默认先问我这篇文章的核心主张是什么；给我两个开头方向，不要替我直接决定；第一节写完先停一下；开头不要从定义开始；不要“总结一下”“综上所述”这种收尾；这些规则写进 AGENTS.md。如果我在修改里反复强调某种表达偏好，就记进 MEMORY.md。
这一步做完，体验已经会明显改善。
当你发现同一套写作流程已经重复用了三五次，再把它升级成 Skill。那时的 SKILL.md 才是真正有意义的，因为它固化的是一套已经被验证过的流程，而不是你临时想到的愿望清单。
比如一个写作 Skill 的核心结构，可以是这样：
---name: writing-flowdescription: 长文写作流程---# 触发条件用户说“我要写一篇文章”或“帮我写……”# 执行步骤1. 先确认这篇文章的核心主张2. 提供两个开头方向，不直接替用户决定3. 第一节完成后暂停，等待确认4. 每节完成前检查是否违反已知写作偏好# 注意事项- 优先遵循 AGENTS.md 和 MEMORY.md 中已有的写作规则- 如果本次协作中出现新的稳定偏好，提醒写入MEMORY.md
写作上的积累，真正产生差距，靠的不是某一篇写得有多惊艳，而是十篇之后，它是不是已经知道什么叫“像你”。
第一次写，它是在猜。第十次写，它是在延续。
这时候 MEMORY.md 里记录的，可能已经不是“用户喜欢简洁输出”这种泛泛偏好，而是这样的东西：
这些不是配置，而是协作历史开始变成默认前提。
周四：复杂攻坚
周四，要做一份竞品分析报告。任务链：搜集5个竞品最新动态 → 对比分析 → 审核逻辑漏洞 → 整理飞书文档。
一只虾顺序做没问题，但有代价：任务链越长，上下文积累越多，越到后面越慢。而且你要一直盯着，不能去做别的事。
这是该切换到多 Agent 的时机。
深层：复杂任务有两种拆法，先软拆，再真拆
很多人一讲多 Agent，就直接上三只、五只、七只。这很容易把“工作流升级”做成“架构爱好”。
更稳的做法是：先软拆，再真拆。
软拆，就是还用一只虾，但你强制它按角色分阶段工作。这其实已经能解决大部分问题。
比如你直接这样说：
帮我做一份竞品分析报告，我们分三步走。第一步，研究员模式：只搜集，不分析。搜集这 5 个产品的最新功能动态，整理成原始数据，等我确认。第二步，写手模式：只基于上面的数据写对比分析，重点说“它们分别在解决什么不同的问题”，500 字以内。第三步，审核模式：检查这段分析的逻辑，找出论据薄弱的地方并标注，不要重写。
这不是真正的多 Agent，但它已经能大幅降低“边搜边写边审”的上下文污染。
真拆，才是真正的多 Agent。它不是简单地“起三个名字”，而是三个独立 agent：各自有 workspace、session、权限和路由。你甚至可以给不同 agent 配不同工具权限和 sandbox 级别。
这里有两个技术点一定要说准：
第一，真正定义 agent 行为的，不是某个神秘的 agent.md 文件。每个 agent 仍然是用自己 workspace 里的 AGENTS.md、SOUL.md、USER.md 这些文件来定义行为和人格。
第二，agent和agent之间互相调用，不是默认就开着的。agent-to-agent messaging 默认是关闭的，要在配置里显式开启，还要做 allowlist。换句话说，真正多 Agent 不是“创建完就能 @researcher、@writer、@reviewer 互相协作”，而是你先决定：它们能不能互相说话，谁能跟谁说。
操作层：日常先用软拆，真的高频再上多 Agent
如果你现在还处在“偶尔做复杂任务”的阶段，软拆就够了。它门槛低，而且最符合大多数人的使用现实。
只有当你已经很稳定地遇到这种情况——同一类复杂任务反复出现；每次都要拆成“搜集 / 写作 / 审核”几段；同一段总被另一段污染；你已经开始明显感觉一只虾顺序做会变笨——这时候才值得上真正多 Agent。
真正多 Agent 的创建方式，是用命令创建独立 agent，并给它各自的 workspace：
openclaw agents add researcher --workspace ~/.openclaw/workspace-researcheropenclaw agents add writer --workspace ~/.openclaw/workspace-writeropenclaw agents add reviewer --workspace ~/.openclaw/workspace-reviewer
然后分别在各自 workspace 里写清楚它们的职责。
比如 researcher的 AGENTS.md只写一件事：你负责搜集和整理信息，不负责写结论。writer的AGENTS.md也只写一件事：你只基于已给的数据撰写分析，不主动扩展搜集。reviewer的 AGENTS.md更简单：你只检查逻辑是否成立、证据是否支持结论、有没有漏掉关键反驳点，不负责重写。
如果你希望限制它们的工具，也不要指望靠文档写一句“不要搜索”就够了。真正的工具限制要在配置里做，用 per-agent 的 tools.allow/ tools.deny 控制。比如给 writer 禁搜索、给 reviewer 禁写文件，这种是权限配置，不是文案提醒。
这也是为什么多 Agent 值得，但不适合一开始就上。它不是“更高级的 prompt”，而是一次真正的工作流拆分。
周五：沉淀喂养
周五下午，我会留出 15 分钟，不拿虾干活，只做一件事：把这一周临时发生的经验，整理成下周还能继续生效的能力。
前四天，你是在和虾一起完成工作；周五这 15 分钟，你是在决定它下周会不会比这周更像你。
这不是“维护一下配置”，而是把一次性的纠正，变成长期有效的默认行为。
深层：为什么养虾是复利系统
大多数工具是线性的：你今天多花一小时，它今天多给你一小时结果；明天再来，还是从头开始。
养虾不是这样。
你这周说过的话、改过的稿、纠正过的顺序、强调过的判断标准，如果被正确沉淀下来，下周就不会再从零开始。一次偏好，不只影响一次回答；一次修正，也不只修正这一轮任务。它会变成之后每次协作的默认前提。
所以真正拉开差距的，不是某一次它答得多漂亮，而是它有没有开始带着积累做事。
比如第一周，它对你的理解可能只有两句：
- 用户是产品经理- 喜欢简洁输出
到第四周，这些记忆开始变成可执行的工作习惯：
- [2026-03-18] 做需求分析时，先说风险，再谈功能- [2026-03-15] 用户不喜欢矩阵图做优先级，更偏好叙述式决策依据- [2026-03-12] 遇到迁移类需求，要主动追问老用户迁移成本- [2026-03-08] 写作里禁用“综上所述”这类过强总结腔- [2026-03-04] 竞品分析要看“解决了什么不同问题”，不是功能清单- [2026-02-26] 中断后的任务恢复，不要要求用户重新解释背景
这时候，同样是“帮我分析一个需求”，它的起手已经不一样了。它会先想：这是不是应该先说风险？这类分析用户要的到底是问题维度，还是功能对比？这里有没有迁移成本被忽略？
它不是在回答你的问题，而是在带着你们已经形成的共识继续工作。
这就是复利。
但复利不会自动发生。如果你只用不养，MEMORY.md 会慢慢堆满过时信息，旧偏好和新偏好混在一起，虾反而会越来越不准。周五这 15 分钟的意义，就是把“会越来越乱”改成“会越来越准”。
操作层：15 分钟到底在做什么？
第一步，清一下 MEMORY.md。这周有没有新的偏好值得留下？有没有已经过时的条目应该删掉？如果一条信息已经不再影响你的工作方式，就不要继续占着上下文。MEMORY.md 不是仓库，而是工作台。
第二步，回看 SOUL.md。这周有没有同一个问题反复出现？比如它总喜欢先铺背景、总爱写得太满、总在你要判断的时候给分析。遇到这种重复纠正，就不要只在对话里改一次，而是回到 SOUL.md，把规则改成长期生效。
第三步，补一次 SKILL.md。这周有没有某个任务你已经做了两次以上？如果有，就把那套流程固化下来。让“这次做得顺”变成“下次默认就这样做”。
第四步，回看 HEARTBEAT / Cron。哪些推送你根本不看？删掉。哪些你真正关心却没出现？补关键词。主动能力不是越多越好，而是越准越好。
一个简单判断标准
如果这一周里，你在某个场景下重复纠正了虾同一个问题，这件事就值得被写下来。
写进 MEMORY.md，它下次会少错一次；写进 SOUL.md，它以后都按这个方式来；写进 SKILL.md，它会变成一套可复用流程。
周五的 15 分钟，本质上是在做这件事：把一次次临场纠正，升级成长期有效的系统能力。
一周走完，你在复利曲线的哪里？
周一，你不再手动刷信息。周二，你不再每次重新解释自己是谁。周三，你不再把精力花在风格校准上。周四，你开始把复杂任务拆给一队虾。周五，你第一次主动把这一周的协作经验沉淀下来。
到这里，变化已经不是“学会了五个功能”，而是工作流被重新分配了五次。
复利曲线的拐点，也不是某一天虾突然变强。而是这些变化累积到一个时刻，你开始明确感觉到：少了它，会不方便。
不是因为你习惯了它。而是因为它真的已经接住了你工作流中的一部分。
配好，只是起点。这一周的养虾，才是真正的激活。
本系列前期文章推荐👇
OpenClaw系列①·大多数小龙虾，是贵了十倍的ChatGPT
本文配套《养虾宝典》工具箱（完整配置模板、安装命令、Skill库、故障排查手册），关注后评论区回复「养虾宝典」获取。
