2026的4月，谈到的AI是什么？

type

status

date

slug

summary

Cowork是Openclaw的孪生还是新生？

Cowork，作为一款产品，首次被提是在 2026 年 1 月 ，Anthropic 推出了一款全名为Claude Cowork 的产品。背景也很简单，Anthropic 发现很多非技术人员也在尝试用 Claude Code 来处理日常任务，于是决定开发一个面向所有办公场景的、具备 Agent（智能体）能力的桌面端产品。

由于时间线的交叠，很难说这款产品的发布没有Openclaw的影子。所以最开始有人会将Cowork与Openclaw相提并论。不过时至今日，两款产品完全走的是不同的道路了。

简而言之，Cowork实际上是本地的manus，但没有具备植入IM进行远程协同的能力。Openclaw则更加开放，能够远程调度。如果要从实现层面来区分Cowork和Openclaw，Cowork使用Computer use的方式来理解用户在本机想要做的操作，并进行复刻。比如打开WPS写一个文档，Computer use是纯视觉理解，响应速度相对会慢一点。Openclaw则直接调度可用的APi。

然而，这些都不是各自软件的壁垒。Openclaw可以接一个视觉UI的API，来实现Computer use的能力，Cowork也能够通过Cli（Openclaw也可以）来直接完成本机本地的相关任务操作。这也是为什么3月的时候，自媒体开始鼓吹“MCP已死，Cli独尊”。所以本质上，由于都是Agent系统，这两者之间都是一种范式下的同一种衍生物。

理解Agent很重要

过去，AI 被认为是一个**“函数”**：你输入一段 Prompt（提示词），它输出一段文字结果。这就是 ChatGPT 刚诞生时的形态。

但 Agent（智能体） 打破了这个局限。简单来说：Agent = 大脑（大模型） + 手脚（工具） + 记忆（数据库） + 规划能力。业界有一句非常经典的话：“Agent 不是一个模型，而是一种复杂的软件工程架构。”很多人以为 Agent 的核心是那个大模型（LLM）。但实际上在真实的工程落地中，LLM 只占了 10% 的工作量，剩下 90% 的脏活累活全在这 5 层架构里。

市面上的那些Agent，底层的代码库基本都是按照以下 5 层来组织目录的：

1. 感知与接入层

这一层负责把外部世界混乱的信息，转化为 Agent 能听懂的指令。它不仅是“聊天框”，更是一个复杂的事件监听器。

它的日常工作：

被动接收：用户在文本框输入了一句话，或者通过语音输入。

主动监听：比如在 WPS 里，用户高亮了一段文字并点击了右键，或者系统到了每周五下午 5 点，这些都是“事件（Event）”。

意图路由：这是非常关键的网关。用户说“你好”，直接走闲聊通道；用户说“帮我排版”，立刻拦截并路由给排版 Agent。不能什么废话都去唤醒庞大的 Agent 引擎，那太烧钱也太慢了。

核心工程难点：多模态对齐和防并发风暴。如果用户在 1 秒内连发了 10 条长语音并传了 3 张图，感知层必须有消息队列来把这些零散的输入打包成一个完整的“任务上下文”，而不是启动 10 个 Agent 去互抢资源。

2. 中枢调度层

这是 Agent 架构的绝对核心，也是拉开产品差距的护城河。最为核心的ReAct（推理+动作）循环就是跑在这一层。

ReAct 是 Reasoning（推理） 和 Acting（行动） 两个词的缩写。它最早由普林斯顿大学和 Google 的研究人员在 2022 年底的一篇论文中提出的，它把“内部的逻辑思考”和“外部的工具交互”完美地交织在了一起，是现在正是目前所有主流 Agent 框架最底层的“运转引擎”。用最白话的方式来说：ReAct 是一种教大模型“像人类一样边想边做”的提示词工程模式。 如果去使用Agent产品，并打开思维链进行观察就会发现，Agent会经常性的在后台疯狂运行着这样一个无休止的循环，直到任务完成：思考：大模型分析当前面临的状况，决定下一步该干什么。行动：大模型决定调用某个具体的工具（比如搜索接口、计算器、或者某个特定的 JSAPI）。观察：工具在真实环境中执行后，返回的客观结果（比如网页的内容、API 的报错信息

它的日常工作：

任务拆解：收到“整理一份竞品报告”的任务后，调度器会生成一个流程图（先搜索 -> 再总结 -> 最后生成表格）。

循环控制：驱动大模型进行 Thought -> Action -> Observation 的循环。

错误兜底与重试：这是最难的。如果 Agent 调用的天气 API 挂了，或者找错了文件，调度层必须能“踩刹车”，告诉模型：“刚才的调用报错了，换个方法试试，你还有 2 次重试机会。”

这里有个有意思的地方：业界都在鼓吹“全自动自治”，但这其实并没有考虑到用户本机的资源限度。未来在移动端使用的场景下，这种“全自动调度”会非常危险。一旦调度器失控陷入死循环（无限重试一个死掉的接口），手机就会发热耗电甚至崩溃。更务实的做法是“Human-in-the-loop（人类在环）”调度器，在关键执行节点主动悬停，弹出授权框让用户确认。

3. 大模型引擎层

这一层是对外接 API（如 GPT,Opus,KiMi）的深度封装。它屏蔽了不同厂商模型的差异。

它的日常工作：

Prompt 模板引擎：将调度层传来的指令，动态组装成 LLM 喜欢的格式。比如把当前时间、系统状态、用户权限悄悄塞进 System Prompt 里。

Function Calling 解析：强制大模型以极其严格的 JSON 格式输出结果。大模型天生喜欢说“好的，没问题，我已经为你调用了...”，引擎层必须把这些废话过滤掉，只提取代码需要的 JSON 字段。

Token 截断与滑动窗口：如果上下文太长超过了 128K 限制，引擎层要负责把最不重要的历史对话“剪掉”，保证最新指令能传进去。

核心工程难点：输出格式的强稳定性。 如果模型哪怕少输出一个 } 括号，下层的代码就会直接崩溃。所以这里通常需要配置多重正则验证和自动修复机制。

4. 记忆与数据层

大模型本身像是一个失忆症患者，你刷新一下它就全忘了。记忆层赋予了 Agent “历史连续性”。

它的日常工作：

短期记忆：通常缓存在内存或 Redis 中，记录“当前正在进行的这个任务”的中间状态和上下文。

长期记忆：通常使用向量数据库。把用户过去的所有喜好、文档语料转化为多维向量存起来。

RAG 管道：当用户问“我上个月那个关于 AI 的 PPT 里写了啥”，记忆层会先去向量数据库里检索出相关的 PPT 段落，喂给大模型。

核心工程难点：“记忆污染”与“遗忘机制”。 用户的偏好是会变的。如果去年用户设定了“用冷酷的语气回复”，今年改成了“用热情的语气”，如果长期记忆不更新权重，Agent 就会精神分裂。必须设计时间衰减算法。

5. 工具与执行层

这是架构的最底端，也就是大模型最终要去改变世界的地方。所谓的业界常提到的JSAPI、CLI、Bash 都在这一层。

它的日常工作：

接口注册表：维护一个清单，告诉大模型现在有哪些工具可用（比如“翻译工具”、“日历查询工具”、“本地文件重命名工具”），以及它们的入参规范。

沙箱执行：安全地执行模型生成的代码或接口请求，并将执行结果（成功或报错信息）原封不动地返回给中枢调度层。

核心工程难点：绝对的权限隔离。 对于移动端 App（如 WPS），工具层的大部分能力是由端侧的 JSAPI 提供的。必须极其严格地校验每一个来自云端的 API 调用指令，防止中间人篡改指令，导致恶意读取本地私密文档。。