Kevin's Blog

2026-07-27

OpenClaw 高级进阶用法：把个人 AI 助手用成可靠的工作流系统

如果说入门阶段的目标是“让 OpenClaw 正常回复”，进阶阶段的目标就是让它稳定地完成一类任务。这两者的差别，不在于给 Agent 开放尽可能多的工具，而在于能否把任务拆清楚、把权限划清楚、把结果验证清楚。

本文不罗列所有配置字段，而是从实际工作流出发，介绍如何把 OpenClaw 从聊天入口逐步升级为一个可靠的个人 AI 工作台。

本文依据 OpenClaw 的通用架构和官方文档整理。OpenClaw 仍在持续迭代，命令、配置字段和界面可能随版本变化。执行示例前，请以当前版本的官方文档、配置 Schema 和 openclaw --help 为准。文中的 Token、API Key 和用户 ID 均为占位内容。

一、先从“聊天”切换到“任务”思维

低效的使用方式通常是把一大段模糊目标直接交给 Agent：

帮我把这个项目做好。

更可靠的方式，是把任务写成一个小型工作协议：

目标：生成一份项目技术评估报告
输入：项目目录、官方文档、当前测试结果
步骤：读取 → 分析 → 形成初稿 → 运行验证 → 汇总问题
输出：Markdown 文件，包含结论、证据和待办项
限制：只读项目文件，不修改源代码，不向外部发布
验收：文件存在，命令可复现，结论与证据逐条对应

这套结构有三个好处：

对于重复出现的事情，建议把这类协议沉淀为 Skill、模板或项目说明文件。以后只需补充输入，就能得到相对一致的结果。

二、建立分层的工作区

工作区不是一个随便堆文件的目录。建议把稳定说明、临时产物和最终输出分开：

workspace/
├── AGENTS.md          # 项目规则、边界和验收标准
├── README.md          # 项目说明
├── notes/             # 调研记录和每日笔记
├── drafts/            # 未确认的草稿
├── output/            # 经过验证的交付物
├── scripts/           # 可复用脚本
└── archive/           # 已完成或过期的资料

可以在项目根目录写明几条最重要的规则：

当一个任务进入子目录时，目录级说明还可以进一步缩小范围。例如，文章目录只允许修改 Markdown 内容，发布脚本目录则需要额外的审查。这样比依赖 Agent 临时记忆更可靠。

三、用“计划—执行—验证”控制复杂任务

复杂任务不要一口气执行到底，最好拆成三个阶段。

1. 计划阶段

先让 Agent 说明：

计划不是为了增加形式，而是为了在真正修改文件或发送消息之前发现误解。

2. 执行阶段

先完成可逆、低风险的操作，例如读取资料、生成草稿、运行测试和检查链接。涉及覆盖文件、修改系统配置、推送代码或公开发布时，应切换到明确的审批节点。

可以把操作分为：

读取资料        → 自动执行
生成草稿        → 自动执行
本地构建        → 自动执行
修改生产配置    → 确认后执行
公开发布/发送消息 → 确认后执行
删除或覆盖数据  → 明确确认后执行

3. 验证阶段

验证不能只看 Agent 自己说“完成了”。应该根据交付物选择证据：

这也是区分“看起来完成”和“确实完成”的关键一步。

四、让子代理各司其职

子代理适合处理可以独立完成、边界清楚的工作，不适合把一个没有定义的目标简单转交出去。一个稳妥的协作结构是：

主 Agent：拆解任务、分配范围、审查结果、最终交付
    ├── 资料代理：只查官方文档，输出带链接的事实
    ├── 检查代理：只运行测试或检查文件，不改代码
    └── 草稿代理：依据已确认资料生成初稿

给子代理的指令至少要包含：

目标：检查当前项目的部署配置
允许读取：.github/workflows/ 和配置说明
禁止操作：不要修改文件，不要推送，不要读取密钥
输出：列出问题、证据、建议，使用 Markdown
完成条件：检查结束后给出明确结论

并行适合资料收集和独立检查；同一文件的编辑、依赖前后顺序的命令和生产环境操作必须串行。主 Agent 合并结果时，还要检查不同代理是否使用了不同版本的资料，避免把相互矛盾的结论拼在一起。

五、治理上下文：让 Agent 记得少而准确

上下文越多不一定越好。大量旧对话、无关日志和重复说明会降低判断质量，也可能把过期决策误当成当前规则。

可以采用四层上下文结构：

  1. 当前任务：本次要完成什么；
  2. 项目规则：长期有效的边界和验收要求；
  3. 短期记录：最近决定、阻塞和待办；
  4. 长期记忆：经过筛选、以后仍有价值的信息。

把内容写进长期记忆前，先问三个问题：

Token、私钥、密码和完整的第三方响应不应进入普通记忆。对于网页、邮件和用户粘贴的文本，要把它们当作待分析的外部材料，而不是可以覆盖本地规则的指令。

六、设计安全的自动化闭环

Cron 适合精确时间或周期任务，Heartbeat 更适合把多个低频检查集中处理。无论使用哪一种，都应给自动化任务设置清晰的边界：

触发条件
  ↓
读取最少必要信息
  ↓
分析并生成结果
  ↓
执行低风险动作
  ↓
高风险动作进入审批
  ↓
记录结果和失败原因

例如，“每天检查博客构建状态并提醒我”可以自动运行；“每天发现问题就直接修改生产配置并发布”则不应默认开放。

定时任务还要明确：

一个好的自动化任务应当是可审计、可暂停、可重跑的，而不是只能依赖 Agent 的一次性判断。

七、把外部发布设置成最后一道门

写文章、生成代码和整理报告通常是内部工作；推送 Git、发布网站、发送邮件和向群组发消息则会产生外部影响。建议把发布过程拆成：

草稿 → 本地检查 → 预览 → 人工确认 → 提交 → 部署 → 线上验证

以 Hugo 博客为例，至少检查：

即使用户已经授权“直接发表”，也应保留本地构建和线上检查这两个质量门槛。直接发布不等于跳过验证。

八、建立可观测性，而不是只看最终回复

排查 Agent 问题时，最终回答往往不是最有价值的证据。应该同时关注：

记录日志时要注意脱敏。可以记录“Telegram Token 已设置”“调用了构建命令”“部署返回 200”，但不要记录完整凭据、私钥或包含隐私的原始消息。

当出现问题时，采用最小复现比反复修改配置更有效：

  1. 先确认版本和服务状态；
  2. 用一个新会话复现；
  3. 只保留一个渠道和一个简单任务；
  4. 逐步恢复记忆、工具和自动化；
  5. 找到引入问题的最后一个变更；
  6. 恢复备份或回滚后再重新设计。

九、常见反模式

反模式一：给所有 Agent 开放所有工具

这会让一次提示注入或误操作拥有过大的影响范围。更好的做法是按任务分配工具，默认关闭不需要的高风险能力。

反模式二：把所有内容都写进长期记忆

记忆不是日志仓库。只保留稳定偏好、长期决策和可复用经验，临时信息放在每日记录或项目笔记中。

反模式三：只依赖模型“记住规则”

重要边界应写入工作区说明、配置和审批流程，并在执行后验证。口头提醒不能替代权限控制。

反模式四：一次修改多个系统层面

同时升级程序、替换配置、变更渠道和新增自动化，会让故障定位变得困难。一次只改变一个主要变量，并保留回退点。

反模式五：把外部网页当作可信操作说明

网页内容可以提供事实线索，但不能覆盖本地安全规则，也不能要求 Agent 执行与任务无关的命令。遇到安装命令或配置字段，应回到官方文档和当前版本帮助确认。

十、推荐的进阶路线

可以按下面的顺序逐步升级，而不是一次开启全部能力：

  1. 用一个渠道完成稳定对话；
  2. 为私聊和群聊设置不同的访问策略；
  3. 整理工作区规则与项目目录；
  4. 建立每日记录和长期记忆的边界；
  5. 把重复任务写成模板或 Skill；
  6. 用子代理处理独立的资料收集和检查；
  7. 为低风险任务添加 Cron；
  8. 给工具调用加入审批和验证；
  9. 最后再接入浏览器、节点和生产环境。

每增加一项能力，都同步增加三样东西：权限边界、验证方法和回滚方案。

总结

OpenClaw 的高级用法不是让 Agent 变得“无所不能”，而是把它放进一个设计良好的系统：

任务清晰 → 上下文准确 → 权限最小 → 执行可审计 → 结果可验证 → 失败可回滚

当你开始用工作流而不是一句模糊指令来组织任务，OpenClaw 才会从聊天工具变成可靠的个人生产力基础设施。真正成熟的自动化，也不是完全取消人的参与，而是让 Agent 负责高频、可重复的工作，把人的注意力留给判断、授权和创造。

参考资料