OpenClaw 与 AI Agent 时代：研究笔记

Mar 08 ·

13 Min Read

涵盖：OpenClaw 技术定位 / Agent 系统性问题 / 中国大厂生态博弈 / IT 工种演变趋势

一、OpenClaw 是什么

技术架构本质

OpenClaw 是一个 应用层的 Agent 平台，本质是 middleware：

用户（via IM：WhatsApp / Telegram / Slack）
        ↓
  OpenClaw 核心层
  ├── 记忆模块（跨会话持久化）
  ├── 心跳调度（每30分钟主动触发）
  └── 工具注册表（动态可写）
        ↓
  LLM 推理层
        ↓
  执行层（OS API / 软件 API / Web / 代码执行）

主要特性

跨会话持久记忆：存储对话摘要，保留用户偏好、进行中任务和沟通风格，解决了”每次都从白板开始”的问题
主动心跳机制：每30分钟扫描文件，判断是否有需要主动为用户执行的事，不等待用户发问
动态工具扩展：通过写代码创建新工具并持久化，工具集本身可以增长
多 IM 接入：在用户已有的 app 里交互，降低使用摩擦

OpenClaw vs Cursor：自我扩展的区别

	Cursor	OpenClaw
扩展方式	在固定工具集内推理扩展	工具集本身动态增长
能力边界	预设工具（读文件/执行代码/搜索）	通过写代码创建新工具并持久化
本质差异	推理能力强弱	工具集边界是否固定

结论：这个区别没那么革命性，Cursor + Claude Code + MCP 也能实现类似效果。

准确定位

OpenClaw 是面向非技术用户的个人 Agent 脚手架，把技术人自己手搭的东西产品化了。它的创新在集成与体验层面，每一个单独模块都不新（LangChain、AutoGPT 早有先例）。最初描述其为”近似 AGI、范式转变”有明显营销成分。

二、AI Agent 的系统性问题

Agent 技术侧

1. 结果可靠性（最根本的瓶颈）

LLM 推理本身有概率性，多步 agent 任务中误差会累积
Agent 缺乏自知力，不知道自己何时不可靠，会自信地执行错误路径
代码任务可以靠测试兜底，现实操作（发邮件、下单、控制设备）几乎没有回滚机制

2. 操作边界不可控

本质是边界定义问题，不只是技术问题
现有框架要么能力受限，要么权限无限，缺乏细粒度约束层
人类雇员有隐性社会契约约束行为边界，agent 完全依赖显式规则
用户根本没能力把所有边界情况写清楚
整个行业目前相当于在用 root 权限跑 agent

3. 权限问题（最系统性）

三层问题：操作系统权限 / 服务 API 权限 / 数据访问权限
权限不足则功能受限，权限过大则成安全漏洞
目前没有成熟的”agent 权限模型”

用户侧

1. 真正的自动数字化需求是否存在

需求存在，但分布极不均匀
重度数字化用户（开发者/运营/分析师）有明确且高价值的自动化需求
普通用户的需求是潜在而非显性的——他们不知道什么可以被自动化，也不会主动定义任务边界
准确表述：需求还没被激活，且激活成本很高

2. 是否有能力人机协同

人机协同要求用户能：清晰描述目标、判断 agent 输出质量、在出错时介入纠正
这三件事对大多数普通用户都是挑战
这个门槛不会随 LLM 变强而自动消失，是用户侧的能力问题

核心矛盾

Agent 技术侧问题和用户侧问题相互放大：

Agent 不够可靠，恰好需要用户有能力识别和纠错
但有能力纠错的用户，往往是不需要 agent 的那批人

三、当前阶段最有潜力的落地方向

为什么智能家居是好的切入点（以 MiClaw / 米家为例）

问题	智能家居的天然解法
可靠性	指令集有限且结构化，出错成本低
边界可控	物理设备本身就是边界，硬件锁死了 agent 能做的事
权限清晰	用户对”我的家”有直觉性授权感，心理门槛低

大公司云端部署的额外优势：责任链清晰。用户知道找谁投诉，有法规约束和品牌压力兜底，信任结构对大规模普及至关重要。

天花板在哪里：取决于小米愿意开放多深的 LLM 推理能力。从小爱（规则匹配）到真正能理解模糊意图、跨设备编排的 agent，是产品决策问题，不是技术问题。

结论

初期阶段，让大公司云端部署并在具体产品上向用户提供智能体功能，比让普通用户本地部署 OpenClaw 更有意义。本地部署 OpenClaw 接入电脑操作系统和 IM，有需求的人不是普通用户，普通用户既玩不转风险又高。

四、大公司为什么不愿开放 API

真正的威胁不只是收益模型

更深层是保护分发入口：

各家 app 的护城河很大程度是”用户习惯打开这个 app”
广告曝光、内购转化、数据采集都依赖这个行为
一旦 agent 成为中间层，平台从”目的地”退化成”基础设施”，议价权大幅下降

”用户倒逼”的机制其实很弱

普通用户感知不到”API 没开放”，只会觉得”agent 不好用”
真正能施压的是开发者生态和竞争对手
某个平台开放了而你没开放，用户会流失，竞争压力比用户投诉有效

更可能发生的路径

被竞争格局逼着开放，且是选择性开放——开放对自己有利的部分，把最核心护城河继续锁住（类比微信开放小程序 API 但锁住支付和社交关系链）。

最终结果不是”agent 自由调用一切”，而是各大平台各自圈定自己的 agent 生态，形成新的围墙花园。

五、中国大厂生态博弈

基本格局

各家不会开放 API 给第三方 agent，会各自构建自己的智能体生态：

腾讯元宝：社交娱乐方向
阿里千问：支付购物出行方向

用户能分清楚边界，就像知道麦当劳不卖肯德基。服务边界需要用户训练成本，在碰壁时才意识到边界在哪里。

阿里能否借 Agent 入口反攻腾讯社交？

逻辑链：阿里生态完备（支付/购物/出行）→ 只缺显著 IM 入口 → agent 重新定义了”入口”→ 用户不再需要”打开微信”这个动作 → 支付宝聊天功能有机会被激活

反驳：IM 的护城河不是功能，是关系链。你的家人朋友都在微信，这个不会因为千问 agent 好用就迁移。

更可能的格局：

阿里管事（任务型交互入口）
腾讯管人（社交关系链）

历史类比

PC → 移动互联网：把 PC 软件在手机上重做了一遍
移动互联网 → AI Agent 时代：把手机软件用智能体代替了一遍

六、AI 时代 IT 工种演变

新的分工模型

系统设计者（架构师 + 产品经理融合）
        ↓ 输出设计文档
     AI 编码实现
        ↓
  代码审查员（精简版程序员）
        ↓
  安全审计（独立角色）

这个模型天然契合日本传统软件开发的分工结构（文档驱动 + 分工明确），AI 只是替换了”编码实现”这一环。

各工种走向

工种	趋势
编码实现程序员	大幅缩减（20人 → 5人量级）
架构师/系统设计	价值提升，往更深技术方向集中
产品经理	极端分化：懂业务+能驱动AI实现的暴涨；纯写PRD画原型的被淘汰
代码审查员	新增/扩大，门槛比想象中高（需理解AI的系统性失败模式）
安全审计	职责拓展，关注agent调用工具的权限范围是否符合预期
DBA	合并进架构师，数据库不再需要被”管理”，只需被定义和审查
测试	迁移为代码审查，自动化测试由AI完成，人工点点点消失
对客/技术支持	历代最稳定的岗位，不受冲击

关键判断

“代码审查员”门槛比想象中高：不是简单审查 AI 输出，而是需要理解 AI 的失败模式——在哪类任务上系统性出错，输出看起来对但逻辑有漏洞的情况如何识别。这需要比普通程序员更强的抽象能力。

产品经理的分化会很极端：能力重构后的产品经理（懂业务 + 能用 AI 实现）可以替代大量程序员；没有完成重构的产品经理几乎没有存货。

新岗位类比：就像 web 时代之前没有前端/后端之分，agent 时代也会有现在无法预测的新岗位出现。

生产力演变规律

每一次生产力进化都会：

干掉一批中间层人力
催生出新的分工角色
让”对客/销售”类岗位比例相对上升（买卖本质不变）

七、总结性判断

OpenClaw 的本质：应用层集成优化，不是新概念，是面向非技术用户的 agent 脚手架
Agent 当前阶段：技术侧和用户侧问题相互放大，大规模普及条件尚不成熟
最优落地路径：大公司在垂直产品上交付（智能家居最典型），而非让普通用户自己部署
大厂博弈结果：新的围墙花园，不是开放生态
工种演变方向：编码密度下降，审查/定义/对客密度上升，产品经理极端分化

Last edited Mar 15