简介
AI的发展正在经历从“信息检索”到“任务执行”的范式转移。 OpenClaw是一个 Local-First (本地优先， vs manus 这种Cloud-native产品) 的 AI Agent 运行时环境，旨在将大模型（LLM）的能力与用户的本地系统、工具链和通讯软件深度结合。最擅长处理那些跨平台、需要系统级权限且带有自动化性质的任务。
- IM 入口带来的体验质变
- 拟人，主动。会主动问你今天怎么样，会在完成任务后开个小玩笑，会记得你上次抱怨过什么。
- Memory做的好。Memory 会是 ChatBot 产品的最大壁垒。
架构
编排流程
- 感知 (Observe)：接收用户消息 + 读取最近的 MEMORY 上下文 + 系统状态。
- 规划 (Plan/Reasoning)：LLM 进行思考（Chain-of-Thought），决定是否需要调用工具。
- 行动 (Act)：LLM 输出结构化 JSON (Tool Call)。Runtime 拦截并执行对应的 JavaScript 函数（如 read, exec）。
- 关键点：如果任务复杂，Agent 会自行决定生成并运行一段代码，或者 Spawn 一个 Sub-Agent（子智能体）。
- 反馈 (Reflect)：工具的输出（stdout/stderr/file）回传给 LLM，LLM 判断任务是否完成，未完成则继续循环。
多智能体 (Sub-Agents)：通过 sessions_spawn 工具，主 Agent 可以分裂出子 Session 处理耗时任务（如：“帮我爬取这10个网站并总结”）。子 Agent 在独立上下文中运行，完成后回调主 Agent。
OpenClaw 的核心是什么？在于 3 个文件。
- SOUL.md（Agent如何思考与交流），SOUL.md 承担的工作比系统中任何其他组件都重，代理在每次对话开始时都会读取它，并将其作为沟通的基础，包括语气、回复的优先级、行为边界等。如果你的代理回复让你感觉哪里不对劲，但又说不出个所以然，答案通常就在这个文件里。
- USER.md（代理在为谁工作）要提供足够的背景信息，让 OpenClaw 感觉它已经认识你几十年了。
- MEMORY.md（代理长期记忆的内容）
关键设计
记忆的分层结构和记忆的按需加载（file system 式的）
Steinberger 提到OpenClaw 的哲学是：记忆属于用户。所有的交互历史和上下文都以 Markdown 文件形式存储在本地，这种透明且可迁移的“本地优先”模式，是保护个人隐私的最终防线。
本地架构、记忆管理、Agent 编排与上下文组装原理 self-evolving, 没有 memory，Agent 基本上就没有进化的能力。比如反馈都做成 memory，写记忆就是写文件，记忆就是agent workspace 里的md文件。
- Session Context(会话上下文)， 仅存在于系统内部的会话状态流。用户无法直接访问或编辑， 完全由系统自动管理，包含 Compaction 逻辑。会话会持久化存储在一个基础的 .jsonl 文件中，每一行都是一个包含用户消息、工具调用、执行结果及模型响应的 JSON 对象。
- Daily Logs(每日日志/流水)，每日的原始流水账记录，存储在用户项目根目录下。混合模式 (Hybrid): 既包含原始交互日志，也包含 Memory Flush 产生的自动摘要。Append-only(只追加)。用户可读可写，系统自动加载“今天+昨天”。
- Curated Memory(精选记忆)，长期维护的、经过提炼的事实、偏好和决策。仅在主会话 (Main Session) 中加载，用户可手动编辑优化。
~/clawd/
├── MEMORY.md - 第二层：经整理的长期知识库
└── memory/
├── 2026-01-26.md - 第一层：今日笔记
├── 2026-01-25.md - 第一层：昨日笔记
├── 2026-01-24.md - 第一层：往期笔记
└── ...
AGENTS.md存着智能体的指令和记忆使用规则，示例如下：
每次会话的必做步骤
开始任何操作前，需完成以下步骤：
1. 读取SOUL.md文件——定义智能体的自身定位
2. 读取USER.md文件——明确服务的用户信息
3. 读取memory目录下今日和昨日的日志文件——获取近期上下文
4. 若为「主会话」（与用户的直接聊天），额外读取MEMORY.md——获取长期记忆
无需向用户申请权限，直接执行即可。
具体到记忆部分
## Memory Recall
Before answering anything about prior work, decisions, dates, people, preferences, or todos: run memory_search on MEMORY.md + memory/*.md; then use memory_get to pull only the needed lines. If low confidence after search, say you checked.
Recall (召回)：
- memory_search是其中一个工具，由模型决策是否需要召回记忆。memory_get在memory_search（找到相关内容的文件路径后）之后用来精准读取文件里的指定内容。
- 提到 “Last time” (上次), “Previous” (之前)。
- 询问 项目细节、代码逻辑、历史决策。
- 询问 个人偏好 (“我喜欢什么颜色？”)。
- 任务依赖 上下文连贯性 (“继续上次的话题”)。
- Compaction ：定期回顾 memory/daily.md，提炼精华写入 MEMORY.md，模拟人类的“海马体到皮层”的记忆固化过程。
有一层对用户的理解，有人设 (SOUL.md)，对用户的理解（USER.md）。
没有设计专属的 memory_write 工具，而是直接用智能体自带的、用于文件操作的标准write和edit工具完成记忆写入。agent的写入行为由 AGENTS.md 中的提示词规则驱动，不同的记忆内容会被写入不同的文件，形成了清晰的写入规则，不同触发场景对应不同的写入文件：
- 日常笔记、临时需要记录的内容，会写入memory/YYYY-MM-DD.md按日归档；
- 长期有效的事实、个人偏好、关键决策，会写入MEMORY.md作为核心知识库；
- 经验总结、工具的实操技巧，会写入AGENTS.md或TOOLS.md，让记忆和智能体的能力配置结合更紧密。
- 系统还会在两个关键节点自动执行记忆写入：
- 一是对话历史压缩前的记忆刷写阶段，
- 二是会话正式结束时，这两个节点的自动写入，能有效避免关键信息因对话结束或压缩而丢失。
Clawdbot 设计了自动索引构建功能，只要你保存了任意一个记忆文件（不管是智能体自动写入还是手动编辑），系统都会在后台自动触发索引构建流程，确保新内容能被快速检索。系统会用Chokidar工具监控文件变化，为了避免频繁写入触发重复操作，还设置了1.5秒的防抖延迟；然后，系统会把文件内容分成约400个token的文本块，相邻文本块会保留80个token的重叠区域，这样既能保证语义连贯，又能提高检索精度；接着每个文本块会被传入embedding模型，转换成1536维的embedding数据，最后存储在数据库里。过程中，会结合语义检索（向量检索）和关键词检索（BM25）两种方式，按 7:3 的权重计算最终检索得分，公式如下最终得分 = 0.7 × 向量检索得分 + 0.3 × 关键词检索得分
更主动——Heartbeat（心跳）与 Cron（定时）系统
这些系统让它从一个被动工具变成了一个后台协作伙伴。
- 心跳是一个预设的间隔时间，代理会自主醒来，检查你要求它监控的任务列表，并决定发现的内容是否值得通过消息平台联系你。
- Cron 系统处理需要精确时间的任务，而不是周期性扫描。这就像让 ChatGPT 定时推送新闻一样。心跳和 Cron 的区别在于：一个是特定时间点（日/周），另一个是主动的意识检查。不要在应该用心跳的时候用 Cron，反之亦然。
大多数人的 OpenClaw 配置不尽如人意，并不是因为缺少某个文件，而是文件之间不匹配。如果你的代理有详细的 SOUL.md 但记忆是空的，你可能会得到回复语气很漂亮但完全不记得昨天聊了什么的代理。同理，一个有激进心跳监控但 USER.md 极其单薄的代理，发出的通知虽然技术上准确，但完全不符合你的关注点。这两种情况都要避免。与其只花一小时试用一下就决定它是否值得，我建议额外花几个小时按你的期望设置好所有系统。记住：Soul 文件中的性格定义应与 User 文件中的背景对齐，两者应与 Memory 中的信息对齐，最后与 Heartbeat 中的监控优先级对齐。
插件和Skills系统设计
Agent实践的一个关键瓶颈：大多数智能体的“能力”仍嵌在提示词或硬编码逻辑中——难以复用、适配与系统化推理。PS：经验的标准化与售卖。
OpenClaw核心系统只做最基础的事情——消息路由、模型调用、上下文管理、安全沙箱，其他所有功能都通过插件和Skills来实现，这种”核心精简、外围开放”的架构模式，才是做平台型产品的正确姿势。而且它的Skills系统设计得特别工程化。每个Skill就是一个标准格式的配置文件加一个执行脚本，有manifest描述元信息，有input/output schema定义接口，有sandbox配置指定权限边界。
skill分为三个层级，优先级从高到低：
- Workspace Skills：位于当前项目目录，仅对该项目生效。
- User Skills：位于
~/.clawdbot/skills/，对该用户的所有项目生效。 - Bundled Skills：项目自带的内置技能。
社区还自发创建了名为 ClawdHub 的技能注册中心，Agent 甚至可被授权自行搜索并安装新技能，以完成超出其当前能力范围的任务。将“做什么”（自然语言描述）和“怎么做”（代码实现）分离，极大地降低了扩展难度。非程序员甚至可在 AI 协助下，通过修改
.md文件微调 Agent 的行为。
干活儿——安全沙箱机制
Clawd如何操控你的电脑？你直接给它一台电脑，并允许它使用。Clawd 赋予了智能体极高的电脑访问权限（风险由用户自担）。它使用一个 exec 工具在以下环境中运行 Shell 命令：
- 沙箱 (Sandbox)：这是默认设置，命令在 Docker 容器中运行。
- 宿主机：直接在你的主机上运行。
- 远程设备：在远程机器上运行。
除此之外，Clawd 还拥有：
- 文件系统工具：支持读取、写入和编辑。
- 浏览器工具：基于 Playwright 开发，并使用“语义快照”（vs 截图/cdp）。这是一种基于文本的页面可访问性树（Accessibility Tree / ARIA） 的表示形式（浏览网页的行为本质上并不一定是一项视觉任务，一张截图的大小可能有 5 MB，而语义快照通常不到 50 KB）。智能体（Agent）看到的页面结构如下：
```
- button “Sign In” [ref=1]
- textbox “Email” [ref=2]
- textbox “Password” [ref=3]
- link “Forgot password?” [ref=4]
- heading “Welcome back”
- list
- listitem “Dashboard”
- listitem “Settings” ```
- 进程管理 (Process tool)：用于处理后台长期运行的命令、终止进程等。
AI Agent和普通chatbot最大的区别是什么？是它能执行真实操作——跑命令、改文件、发请求、调API。这个能力是双刃剑，问题是怎么降低风险、怎么控制爆炸半径。
- 默认情况下Agent执行任何敏感操作都需要用户确认，文件操作只能在指定目录里搞，网络请求有白名单限制，系统命令要过审批。
- Docker部署的话更狠——非root用户运行、文件系统可以设成只读、capabilities全部drop掉。
- 还有个openclaw security audit –deep命令，能扫描当前配置有没有安全隐患，扫完给你出报告告诉你哪里有风险、怎么修。 OpenClaw的安全策略明确写了”prompt injection attacks are out of scope”——就是说它不试图防prompt注入，因为以现在的技术这玩意防不住。它的思路是：既然prompt注入防不住，那就假设Agent会被”骗”，然后在执行层面做限制，让Agent就算被骗了也干不了太出格的事。
用户交互
IM 即任务入口
- 基本上你能想到的平台OpenClaw都支持。每个平台的消息格式不一样、富文本能力不一样、附件限制不一样、webhook机制不一样、rate limit不一样。Clawdbot的做法是搞了一个WebSocket Gateway作为中心枢纽，所有平台的消息都先转成统一的内部格式进Gateway，处理完再转成各平台的格式出去，中间的AI Agent只处理标准格式的输入输出。每个平台对应一个Channel Adapter，Adapter只负责格式转换这一件事，业务逻辑一行都没有。
- CLI系统。OpenClaw有100多个CLI子命令，能干的事情包括但不限于：管理Skills、配置插件、调试Agent、查看日志、管理记忆、做安全审计、导入导出数据。为什么这很重要？因为CLI是最被低估的用户体验。
源码
从技术上讲 是一个 TypeScript CLI 应用程序，一个 Node.js 应用。核心配置文件位于 ~/.clawdbot/clawdbot.json，在此调整模型参数、渠道设置、安全策略等。
- 运行在你机器上的进程，并暴露一个 网关服务器（Gateway Server） 来处理所有频道连接（Telegram, WhatsApp, Slack 等）。
- 调用 LLM API（Anthropic, OpenAI, 本地模型等）。
- 在本地执行工具。
- 根据你的指令操控电脑。
Channel Adapter ==> Gateway Server ==> Agent Runner ( loop[build context ==> llm call] ==> save response ) ==> Gateway Server ==> Channel Adapter。
Agent Runner 内模型在处理每个请求时到底看到了什么：
[0] 系统提示词 (System Prompt) (静态+条件指令)
[1] 项目上下文 (引导文件: AGENTS.md, SOUL.md 等)
[2] 对话历史 (消息, 工具调用, 压缩摘要)
[3] 当前消息
畅想汇总
- 每个人有一个bot，bot 与bot 可以交流
- 我们可以预见，未来的个人计算设备，可能不再是一个个独立的 App 图标的集合，而是一个由类似 Clawd 这样的 AI Agent 作为核心交互界面的“个人 AI 操作系统”。用户通过自然语言下达任务，AI Agent 则负责调度设备上的所有硬件、软件和服务资源来完成它。