关于OpenClaw的一些想法
最近 OpenClaw在各种社区的热度极高，我也第一时间在本地环境完成了部署。但在折腾了一周、翻遍了各种记忆系统配置和 Skill 封装后，我的第一感想并不是“Agent 时代已至”，而是作为一名产品经理对 AI 落地现状，产生了几点思考。
一、 “装机量”不等于“生产力”：Agent 的最后一公里
现在社交媒体上到处是 OpenClaw 的安装教程，但一个尴尬的现实是：大部分人装好之后，除了让它打开网页搜个新闻，就不知道该干嘛了。
这让我想起 B 端产品在交付时常遇到的“冷启动”问题。OpenClaw 本质上是一个具备多智能体协同能力的“底座”，它提供的是“手”和“脚”，但缺乏“脑子里的 SOP”。
- 从工具到数字员工：很多用户期待的是“帮我写个报告”，但 AI 需要的是具体的任务拆解。
- PM 的思考：真正能让 Agent 赋能工作的，不是模型参数的提升，而是 PM 对工作流的结构化能力。如果你不能把一项工作拆解成 3-5 个逻辑闭环，AI 永远只能在那里“转圈圈”。
二、 确定性挑战：如何在概率性模型上构建“零错判”业务？
作为 B 端/G 端产品经理，我们面对的最核心矛盾是：大模型的输出是概率性的，但业务结果必须是确定性的。尤其在政务审计或商务投标这种“零容忍”场景下，直接把 PDF 喂给 AI 是极度不负责任的。
在实践中，我复盘了一套「分层混合架构」，这比单纯讨论工具安装更有价值：
- 硬规则兜底 (Rule Engine)：像投标金额、资质有效期等“一票否决”项，完全不走 LLM，由规则引擎直接判定，确保 100% 准确。
- 局部条款校验 (RAG)：针对单章节的响应（如技术参数偏离），通过 RAG 提速，精准定位切片。
- 全局风险预警 (Long Context)：只有跨页的逻辑冲突，才交给长上下文模型处理，用在刀刃上。
- 相似度溯源 (Vector DB)：独立向量库做雷同检测，与主流程解耦。
这种“规则引擎 + RAG + 长上下文 + 向量库”的组合，才是 AI PM 在处理严肃业务时该有的“防御性设计”。
三、 交互的演变：从 GUI 的“视觉模拟”到 API 的“底层直连”
目前 OpenClaw 操控电脑的方式大多还是基于屏幕截图和像素识别（Computer Use）。这种方式虽然惊艳，但从产品架构的角度看，这其实是一种“无奈的妥协”。
人类需要 GUI（图形界面）是因为我们需要视觉反馈。但对 AI 来说，GUI 是极其低效的。它需要不断地截图、上传、定位坐标，中间任何一个弹窗都可能导致任务失败。
- API 才是 Agent 的“母语”：我认为未来的软件架构会发生分裂。人类继续使用美观的 GUI，而 AI 将通过操作系统直接开放的“语义化 API 层”进行交互。
- 无头软件 (Headless Software)：未来的办公系统可能不需要“按钮”。当我想移动文件或处理表格时，AI 应该直接下发二进制指令，而不是像人一样去屏幕上找“确认”键。
四、 产品的边界：效率的归 AI，灵魂的归人类
在尝试自动化处理社交媒体互动时，我产生了一种强烈的违和感。
以小红书为例，如果评论区全是 AI 生成的回复，那么社交平台的价值将瞬间坍塌。社交的核心是生命感。当互动变成 AI 之间的信令交换，真实的连接就消失了。
作为 PM，我们必须清醒地划分边界：B 端/G 端追求的是效率和“去人性化”；但 C 端追求的是体验和“连接”。并非所有功能都适合 AI 化，在情感场景下，AI 应该是点缀，而不应逾矩。
结语
折腾 OpenClaw，不是为了追求新鲜感，而是为了在不断的调试中看清 AI 落地边界。
AI PM 的核心竞争力，不在于调参，而在于如何在一个概率性的模型之上，构建一套确定性的业务逻辑。最终，我们都要回归到一点：我们如何用 AI 这个新变量，去重塑那些早已僵化、但又充满痛点的业务流程。