夜雨聆风上一篇我讲的是思路：为什么 OpenClaw 这波会火，以及为什么很多人真正开始需要的，已经不是一个聊天窗口，而是一套能进入工作流的 AI 系统。
这一篇我想把话说得更实一点。
不是讲配置说明书，也不是把所有内部细节摊开，而是把我自己在真正往下搭的时候，最有价值的几个判断讲清楚。
说简单点，这篇想回答的是一个更具体的问题：
我到底是怎么把 OpenClaw 从“能聊天的 AI 工具”，一步步搭成一套真正能协作、能交付、能兜底的个人工作系统的？
一开始最明显的问题：所有任务都混在一起
很多人刚开始用 AI，都会下意识追求一种状态：
一个入口，把所有事情都接住。
听起来很合理。
但真正做一段时间之后，我很快发现，这种方式最先出问题的，不是能力，而是秩序。
因为这些任务本来就不是同一种性质：
- • 日常对话
- • 长文整理
- • 资料提炼
- • 内容重写
- • 审校修改
- • 发布准备
- • 本地执行
- • 配置修改
如果全塞进同一个入口里，一开始会觉得很方便，后面就会越来越乱。
最典型的表现就是两种污染同时出现：
1）上下文污染
前一秒还在写文章，下一秒切到配置，再下一秒又回到内容发布。会话能继续，但系统会越来越糊。
2）权限污染
有些任务只是协作，有些任务已经涉及本地执行和高权限动作。如果这些东西不分层，风险会越来越高。
这也是我后来真正开始调整结构的起点。
第一个关键动作：先做“轻轨 / 重轨”分离
后来我对整个系统最核心的一个判断就是：
高频协作任务，和高权限执行任务，必须分开。
我习惯把它理解成“轻轨 / 重轨”。
轻轨：高频、前台、适合随时发起的任务
这类任务更强调：
- • 入口顺
- • 响应快
- • 交互轻
- • 方便转单
比如：
- • 日常问答
- • 内容草稿
- • 资料整理
- • 长文重写
- • 汇总与协同
- • 发布前准备
这一层最重要的，不是极限推理，而是低摩擦接单。
重轨：高权限、低容错、本地可控的任务
另一类任务完全不同。
它们往往涉及：
- • 本地脚本执行
- • 文件级修改
- • 配置变更
- • 工程项目处理
- • IDE 内重型开发
这类任务如果和前台协作任务放在同一层里，后面一定会互相拖累。
所以我后来做的，不是堆更多 Agent，而是先把这两条轨道物理拆开。
拆开之后，系统一下子安静很多。
因为你终于不再试图让同一个节点，同时承担“随时陪聊”和“真正动手”这两种完全不同的职责。
第二个关键动作：放弃“万能 Agent”，改成角色拆分
任务分轨之后，下一个问题就来了：
谁接单？谁分析？谁校验？谁交付？
这时候我越来越确定，一套系统如果想长期稳定，就不能迷信“万能 Agent”。
一个什么都能做的节点，最后往往会变成：
- • 什么都碰一点
- • 但没有哪件事能长期稳定
所以我后来更倾向于把角色拆清楚：
前台节点
负责接需求、收敛任务、做第一轮判断。
分析节点
负责长文处理、信息提炼、结构化输出。
校验节点
负责核查、纠偏、补充风险提醒。
交付节点
负责把结果送到目标位置，而不是停留在“内容已经写出来了”。
本地执行节点
负责高权限动作，把真正危险或底层的事情留在更可控的环境里。
这一步的意义，不是为了让系统看起来更复杂，而是让每个节点的目标终于明确。
明确之后，系统的稳定性会明显上升。
因为前台不再想着把所有事都包完，分析不再背交付，交付也不再同时负责深度思考和执行判断。
真正难的不是生成，而是交付
这是我这段时间体感最强的一件事。
很多人高估了“生成内容”本身的难度，低估了“把内容稳定送出去”的复杂度。
写一篇文章，真正完整的链路其实很长：
- 1. 读取源材料
- 2. 提炼结构
- 3. 改成目标风格
- 4. 删掉不适合公开讲的内容
- 5. 调整成目标平台能接受的表达
- 6. 转成可交付格式
- 7. 写入目标系统
- 8. 验证是不是已经真的落地
这中间任何一步出问题，最后结果都可能不成立。
所以我后来对系统成熟度的判断标准变成了：
不是它能不能生成结果，而是它能不能把结果稳定交付出去。
这件事在内容发布链里尤其明显。
这次踩坑最深的一件事：browser 看起来成功，不等于真的成功
这次公众号链路的排障，对我帮助很大。
一开始我优先尝试的是 browser 自动化。
逻辑上看非常顺：
- • 打开后台
- • 进入编辑器
- • 填标题
- • 填摘要
- • 粘贴正文
- • 页面上看起来一切正常
- • 点击保存
从日志上看，也像是成功的。
但真正打开草稿时，问题就出来了：
“界面看起来已经成功” 和 “后台对象真的保存成功” 不是一回事。
这是自动化里特别典型、也特别容易被忽略的一种假成功。
表层动作都做完了，但目标系统未必真的认账。
这件事让我重新改了一个判断标准：
任何交付链，都不能只验证前端状态，而必须验证目标对象是否真的生成。
这一步想明白之后，后面很多选择就顺了。
为什么发布链最后必须回到 API
这次排障之后，我对发布链的看法变得很明确：
browser 适合补位
浏览器自动化很灵活，能处理很多没有 API 或必须模拟人工操作的场景。
但它也天然更脆：
- • 依赖页面状态
- • 依赖登录态
- • 容易受编辑器细节影响
- • 很难把“看起来成功”和“真正成功”完全分开
API 更适合主链
只要目标平台有稳定 API，我现在更倾向于让主链走 API。
原因也不复杂：
- • 更接近真实状态
- • 更容易验证成功与失败
- • 更适合做重试和错误处理
- • 更适合长期沉淀成稳定流程
所以这次之后，我对内容交付链有了一个更清楚的原则：
browser 可以有，但 API 才适合做主链。
它不是更酷，而是更稳。
最后一个真正拉开差距的点：失败路径必须先于功能扩张
如果只是看 demo，AI 系统很容易让人沉迷在“功能越来越多”的成就感里。
但只要真的把它接进工作流，注意力很快就会转到另一个问题：
如果失败了怎么办？
比如：
- • 模型临时不可用怎么办
- • 某个入口掉线怎么办
- • 某个动作执行了但结果不可靠怎么办
- • 某条链路卡住之后，系统还能不能继续往下走
这些问题看起来不性感，但它们决定了系统到底是 demo，还是工具。
所以我现在越来越看重的，反而不是还能不能继续加功能，而是：
- • 失败后能不能定位
- • 出错时边界会不会失控
- • 某一环挂掉时，整条链路能不能退化
- • 系统会不会自我欺骗，以为已经成功了
这类问题处理得越早，系统越稳；处理得越晚，后面返工越重。
写在最后
回头看这次实践，我最大的感受不是“又接通了一条链路”，而是我越来越确定：
个人 AI 系统真正难的，从来不是把模型接进来，而是让系统保持秩序。
这个秩序来自什么？
不是来自一个更强的模型，
而是来自几件听上去很朴素、但真正决定成败的事：
- • 任务要不要分轨
- • 角色要不要拆开
- • 调度要不要收敛
- • 交付链要不要可验证
- • 失败路径要不要提前设计
如果这些东西没有想清楚，AI 再强，也只是在局部帮你省一点力。
但如果这些东西慢慢理顺了，AI 才会真正从“一个工具”，变成“你工作流里的一部分”。
对我来说，这才是 OpenClaw 这类系统最值得花时间的地方。
不是因为它看起来很强，而是因为它逼着你开始认真思考：
我到底是想拥有一个聊天窗口，还是想拥有一套真正能帮我长期工作的 AI 系统。
这两件事，差别非常大。