从概念到实践的调研汇报

• OpenClaw 是什么
  • AI 名词科普
  • OpenClaw 是什么
  • OpenClaw 原理初探
• OpenClaw 能做什么
  • 工作机操作员
  • 定期从某些软件中拉取信息
  • 搭建知识库 AI
• OpenClaw 能与 WParse 产生哪些火花
  • WParse 使用 OpenClaw 日志
  • 使用 OpenClaw 接入 WParse 的 Skill
  • 为 OpenClaw 搭建 OTEL 的观测系统
• 总结评价
  • 核心价值
  • 当前问题
  • 与 WParse 的结合

---

一个只能一问一答的小人。

将之前的对话信息塞进给小人的问题中。

帮你管理上下文和 AI 对话以及其他工具的一个服务。

• Function Calling：AI 调用 agent 方法的协议
• MCP：agent 调用 MCP 服务的协议
• Skill：将某个场景的领域知识以提示词的方式发送给大模型，例如 WPL 的领域知识

OpenClaw 是一个 AI Agent，和 Claude Code CLI、Codex CLI 等 Agent 类似。

它在这些基础上做了如下核心增强：

• 接入消息通信工具并定义了操作接口
• 接入定时任务
• 将场景与上面的名词挂钩

其他 Agent 想要接入钉钉和 GitHub，通常需要：

• 写钉钉适配器用于聊天
• 自己组织相关 MCP 服务和 Skill

使用 OpenClaw：

• 不需要了解这些概念细节
• 只需下载插件（适配器 + MCP + Skill）(OpenClaw官网把适配器叫做管道)

• 网关：一个长期运行的服务，用来监听各类通信工具的消息，并将消息转发给 agent
• Agent：一个组织用户记忆、技能、场景的服务，接收网关转发来的消息，根据消息内容和用户记忆、技能、场景等信息，生成回复，并将回复发送给网关

1. 网关收到钉钉消息"我要查 wp-labs 仓库的 bug"，解析出用户 id 和消息内容，发给 agent
2. agent 通过适配器找到之前的相关会话
3. 会话里会有类似如下信息：我在使用钉钉和你聊天、在 xxx 群、xxx 是钉钉的相关知识
4. agent 将会话信息和消息内容一起输入到模型中
5. 模型分析出用户是 GitHub 这个场景，并发现有配置 GitHub 的 MCP
6. 模型通过 Function Calling 说自己要调用这个 MCP，agent 调用 GitHub MCP 查询 wp-labs 仓库所有 issue，并将结果返回给模型
7. 模型根据查询结果生成回复，agent 将回复发给网关，网关将回复发回钉钉

---

通过 Skill 配置某个领域的知识库。

---

我尝试过什么：

• WParse 使用 OpenClaw 日志
• 使用 OpenClaw 接入 WParse 的 Skill
• 为 OpenClaw 搭建 OTEL 的观测系统

OpenClaw已知有两类日志：

• 系统事件日志：/tmp/openclaw/openclaw-2026-02-09.log
• AI对话以及操作日志: ~/.openclaw/agents/main/sessions/，下面日志记录了rm -rf的操作。 OpenClaw 日志是 JSON 格式，语义相对明显，wparse接入有限，只有适配器日志内容可解析。

挑战：

• 日志没有统一格式，且官网没有描述
• 每个插件不同，整体解析难度较大

我尝试接入 WParse 的 Skill，虽然有成功过，但效果并不稳定。

主要原因：

• 模型不够给力（使用的是 Qwen 模型）
• 缺少方便 AI 验证 WPL 语句的方式（目前通过调用接口，较麻烦）

改进方向： 如果上面两个能力得到满足，稳定性会有明显提升。

这和 WParse 无关，和我们的业务比较相关。

OpenClaw 官网表示支持 OTEL，我原本计划搭建观测体系，OpenClaw 有没有记录危险操作日志，但实践中 OTEL 功能有 bug（GitHub 上有 issue）。

现状： 等待生态更加完善，或者我们自己收集。

---

OpenClaw 将配置 agent、开发适配器、管理会话和 MCP 等工作简化了，大幅度降低了 AI 应用门槛。

• 生态不成熟：自身 bug 与第三方插件 bug 都较多
• 成本较高：会非常消耗 token

• 对于 WParse 而言：介入空间有，主要在各个通信管道日志内容分析，介入比较困难
• 对于运维监控而言：内部支持 OTEL，有监控价值，等待生态更加完善才方便进行下一步深入。