大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



主要是AI Agent 概念爆发，大家都在找怎么让 AI 真正干活，但LangChain 门槛太高要写大量胶水代码，容易失控烧 Token，各家API手搓又太累。而OpenClaw 正好卡在中间：能够开箱即用，不需要写代码就能跑起来，解决了使用大模型的高门槛问题。

它把自己定位成”AI 的操作系统”。不做推理，那是LLM的事，它只管调度和执行，模型完全可以随便换。

今天用Claude，明天换 DeepSeek，后天跑本地Ollama，代码一行不用改，只需要改配置文件里的APl Key和Base URL，再加上开箱即用地接入多渠道的聊天平台，部署非常方便。

并日它能7x24小时常运行，支持心跳巡检（定期主动检查待办事项）和Cron定时调度（标准Cron表达式的定时任务）。这让AI 从一个“你问它才答”的被动工具变成了一个“能主动干活”的基础设施。

另一个重要的方面也是大家最在意的是开源+本地优先解决了隐私焦虑。

同期很多AI 产品都是云服务，数据在别人服务器上，而OpenClaw数据全在本地，这对企业和注重隐私的开发者吸引力很大。

答案是一定会的。不同模型对 System Prompt的理解能力、工具调用的格式遵循度、推理深度都不一样。Claude对复杂工具链的编排能力就比 7B 的小模型强很多，换成本地Ollama 跑的量化模型，一个多步骤任务可能就搞砸了。OpenClaw在工程层面做了不少适配：normalizeToolParaneters()会根据Provider 自动清洗 Tool Schema (Gemini 不支持 additionalproperties、xAl 不支持 ninLength/maxLength、OpenAl要求层必须是 type:“object”)，还有fallbackprofile机制（主横型失败自动切备用模型），但模型能力差异是框架层解决不了的。实际生产里常见的做法是按任务复杂度做路由，简单任务走便宜的小模型，复杂任务走旗舰模型。

说白了OpenClaw它本质上就是一个多渠道的AI网关，它只负责任务调度和执行，自己不做推理。抽象理解成一个中枢网关，把大模型的推理能力翻译成对操作系统、API、硬件设备的实际控制权。

因此，它是能够动手干活，而不是一问一答普通聊天的机器人那样。

要理解OpenClaw原理就要从它的两层架构（网关层Gateway和运行时层Agent Runtime）和运行时核心机制（Agentic Loop+工具生态）入手。

Agent Loop + Tools 是 ReAct 范式的标准实现， Claude Code 和 Codex 有，这不是 OpenClaw独有的。Gateway 才是 OpenClaw 真正的护城河。如果没有Gateway的话，Agent Loop 只能在终端里跑一次性对话；有了Gateway，它就变成了一个7x24常驻运行、能接入15+聊天平台、支持定时任务和主动巡检的AI基础设施。

具体来说，Gateway做了六件Agent Loop做不到的事：常驻在线(守护讲程+崩溃自动拉起+上下文恢复)、多平台接入、会话隔离、排队控制、心跳巡检、Cron定时调度。

首先Gateway是整个系统的常驻基础设施，也是消息的入口，以守护进程方式7×24小时运行。也就是API Gateway + 进程管理器 + 任务调度器 结合起来。

网关主要负责6件核心：

1、多平台接入：统一翻译各渠道消息格式为内部MsgContext

2、会话隔离：为每个用户/群/Agent 维护独立的Session Key

3、排队控制：并发消息的去重、限流、队列调度

4、心跳巡检：Heartbeat 周期性唤醒Agent来主动做任务

5、定时调度：支持Cron的精确定时任务系统

6、记忆刷盘：在上下文压缩前把关键信息持久化到磁盘来保证不会丢失关键信息

网关层详细介绍

Gateway是一个HTTP+WebSocket 服务器，默只绑定127.0.0.1:18789，不对外暴露。

作为网关，它具备传统APIGateway的基础能力：鉴权、路由分发（按优先级将消息派发到对应Agent）、限流（并发控制+队列调度）、幂等去重（防止平台重复推送导致Agent重复执行）。

但其实Agent Loop 和 Tools并不是OpenClaw 独有的，比Claude Code、Codex都有自己的实现。Gateway 才是OpenClaw 区别于其他AI编程工具的核心独有模块，除了上述基础网关能力，它还承担了六大进阶职责：

1)常驻在线(Always-on)

Gateway的主循环是一个while (true)永不退出的进程。配合操作系统级的守护进程管理: macOS用launchd、Linux用 systemd,Windows 用Scheduled Task，从而实现了崩溃自动拉起。

Gateway 重启时，因为会话状态已经以JSONL格式持久化在磁盘上，所以能恢复之前的对话上下文，继续处理没完成的任务。重启过程也不是直接杀掉：收到SIGUSR1信号后，先进入drain 阶段等待所有正在执行的Agent turn完成(最多等90秒)，然后才优雅关闭并 spawn新进程或让 supervisor 拉起。

每个渠道连接也有独立的指数退避重连策略(5秒起步、2倍增长、最大5分钟、最多重试10次)，单个渠道掉线不影响其他渠道

2)多平台入 (Channel Plugins)

每个聊天平台都有一个门的渠道适配器(Channel Plugin)，比如 Telegram 用 Bot Token 鉴权，WhatsApp用QR 码对，iMessage需要跑在真正的Mac 上.

适配器负责把各平台干差万别的消息格式统一成OpenClaw 内部的Msgcontext，顺带处理 Markdown转换、长消息切分、媒体上传这些脏活。

对于Agent运行时来说，不管消息来自哪个平台，看到的都是同一种数据结构。

3)会话隔离(Session Isolation)

Gateway 为每个用户、每个群、每个Agent 维独立的 Session Key,格式为 agent:(agentId}:(chamnel}:(peerkind}:(peerId}.

群聊一个群一个会话。私聊可通过anscope配置粒度(共享主会话/按用户/按渠道+用户/按账号+渠道+用户)。Cron定时任务和子Agent 也有各自隔离的会话空间，互不

干扰。

4)排队控制(Queue Control)

当Agent正在处理一条消息时，新消息进来怎么办?

Gateway实现了一套完整的队列系统，支持6种模式：

• steer：新消息直接注入到当前运行中的Agent上下文("插嘴”)
• followup：排队等当前turn结束后再处理
• collect：收集多条消息合并为一个turn处理
• interrupt：打断当前任务立即响应
• queue：标准FIFO先进先出
• steer-backlog：steer + backlog 混合

配套有去重机制(按message-id或prompt 去重)、容量上限(Cap)、溢出策略(丟旧消息/丟新消息/用LM 摘要合井)，防止消息洪水冲垮Agent。

5)心跳巡检+Cron定时调度(Heartbeat+Cron)

这是OpenClaw 能主动做任务的核心机制，也是它与纯被动聊天机器人最大的区别。

Heartbeat (心跳巡检)负责周期性唤醒 Agent。每隔一段时间(可配置，如每10分钟)，Gateway触发一次心跳，唤醒 Agent检查HEARTBEAT.md文件中定义的待办事项。

心跳触发有7种原因：

• 定时到期(interval)
• 手动触发(manual)
• 命令执行完成(exec-event)
• 外部唤醒(wake)
• 定时任务回调(cron)
• 钩子触发(hook)
• 重试(retry)

每个Agent 可以有不同的心跳间隔和提示词，Gateway统一调度。

Cron (定时调度)是一个完整的定时任务系统，支持标准Cron表达式。用户可以通过openclaw cron add 添加定时任务(如”每天早上9点总结昨天的邮件”)，CronService在后台管理Job的增删改查、调度执行、失败告警。Cron任务运行在独立的Agent会话中，不会污染用户的主对话。Heartbeat 负责"巡逻式”的周期检查，Cron 负责”闹钟式”的精确定时，两者配合，让OpenClaw从一个被动应答器变成了一个主动工作的AI Agent。

6)记忆刷盘(Memory Flush)

当会话接近 token上限即将触发 Compaction (压缩)时，Gateway先让 Agent 执行一次 Memory Flush：模型会把当前对话中的关键信息(决策、待办、偏好等)主动写到磁盘文件memory/YYwY-MM-DD.md 中，然后再做压缩。

这确保了压缩不会丢失重要信息。触发有两个阈值：软阈值(剩余4000 tokens时)和硬阈值(会话文件超过2MB 时强制执行)。

这是AI 干活的地方，能够接收网关分配的消息，组装上下文，调用LLM，执行工具调用，返回结果。

OpenClaw的运行核心是Agentic Loop也就是Agent循环，基于ReAct范式推理循环，当用户发送一条消息后，Agent是进入一个循环，而不是简单地交给LLM然后拿到结果就结束了。

运行时主要执行以下6个步骤：

1、组装上下文：加载会话历史、记忆文件、系统提示词

2、调用LLM：把上下文和工具列表一起发给LLM，让它思考推理

3、解析响应：LLM要么直接回复文字结束循环，要么返回一个tool_call指令，要干的事情比如制作ppt

4、执行工具：是tool_call，那就执行对应的工具拿到结果

5、结果回填：把工具执行结果追加到上下文里

6、循环：回到第2步，这个循环会一直转，直到LLM认为任务完成，输出最终文本结果

运行时层详细介绍

当Gateway把消息派发到Agent Runtime后，会经历以下阶段：

第一步：路由匹配

一个OpenClaw实例可以配置多个Agent (比t如”客服Agent”、"运维 Agent")，消息进来后要先决定交给准。resolveAgentRoute()会按优先级逐层匹配:精确 peer 绑定父 peer guild +角色guild team account channel 默认 Agent。匹配成功后同时生成一个SessionKey用于会话隔离。

第二步：组装上下文(System Prompt+历史+工具)

OpenClaw 的系统提示词不是写死的，而是每轮对话由buildAgentsystemPrompt()动态拼装。数据来源包括:

• 工作空间的 Markdown 配置文件：AGENTS.md (行为规则)、SOUL.md (人格语气)、TOOLS.md(工具使用备注)、USER.md (用户偏好)、IDENTITY.md (身份配置）
• 自动注入的运行时信息：可用工具列表及说明、当前时区、渠道能力、沙箱状态
• 按需加载的技能指令（Skills）和语义搜索召回的记忆片段

插件还可以通过 before prompt _build钩子在构建阶段注入自己的上下文。改Agent 行为只需编辑Markdown文件，完全不用动代码。

第三步：进入Agentic Loop

上下文组装好后，进入前面说的核心循环。Agent底层使用pi-coding-8gent SDK 管理会话状态，配合流式输出把模型的回复实时推送给用户。

在循环过程中，系统对上下文大小有严格的管控:ContextGuard:单条工具结果最多占context的50%，超出自动截断Token Budget:整体上下文有token预算，超出触发自动Compaction(压缩)Overflow Recovery:如果遇到 context overflow错误，系统会自动 compaction截断tool result重试，最多重试数十次第四步:保存状态

对话结束后，所有消息和工具调用结果以JSONL格式落盘到~/.openclaw/sessions/目录，下次对话时加载恢复。

架构图如下：

除了这个循环，OpenClaw还有个很重要的点在于它内置了一套丰富的工具生态，能直接操作操作系统：读写文件、执行终端命令、浏览网页、调用外部API等。

循环是引擎，工具才是手脚。普通聊天机器人就算有循环，没有这些执行器，也只能回复文字。OpenClaw能做到”搜网页一读取内容一整理摘要一写入文件告诉用户搞定了“这种多步骤任务链，靠的是循环+工具的组合驱动。技术栈上，OpenClaw用Node.js+ TypeScript (ESM) 实现，HTTP 服务直接基于 Node原生的 node:http 模块 (没有用Express/Koa)，WebSocket做控制面实时通信。底层的Agent 会话管理构建在pi-coding-agent SDK之上。

工具调用流程

Tool Calling的核心链路就四步:定义工具一LLM决策一系统执行一结果回传。

打个比方：LLM就像一个只会动嘴的指挥言，它不能亲自去查数据库、读文件，但它可以”下命令"让外部系统去执行，然后看执行报告决定下一步。Tool Calling就是这个"下命令再拿报告”的标准化流程。

先说工具定义。每个工具本质上就是一段JSON Schema (一种衙述数据结构的准格式)，里面包含工具的名字、一段自然语吉簡述、以及参数的类型约束。LLM不会白接执行任何代码，它只认这段 Schema文本。你在系统里注册好工具，然后把这些Schema塞进system prompt或者tools字段传给LLM。

然后是LLM决策调用。LLM收到用户消息和工具列表后，如果判断当前问题得调用工具，它不会直接回答用户，而是返回一个特殊的 tool.use消息，里面带着工具名和填好的参数JSON。

备注：不同厂商命名不同，OpenAI用tool_calls,Anthropic用tool_use,本文以Anthropic命名为例。

注意，LLM只是"说“它想调什么工具、传什么参数，它自己压根不会去执行。这跟你在聊天里说”帮我查一下天气”一样，说的人不会真的去查，执行的是系统侧。系统侧拿到tool_use消息后，解析出工具名，找到本地注册的对应函数，把参数传进去跑。执行完拿到结果，包装成tool_result消息追加到对话历史里，再整个发回给LLM。LLM看到tool_result后有两种选择：

1、如果信息够了就直接生成最终回答；

2、如果还需要更多信息，它会再发一个tool_use，形成一个循环，直到它认为可以回复用户为止。

整个链路：用户发消息 ---> LLM分析消息和工具列表 ---> LLM返回tool_use含工具名和参数 ---> 系统执行工具函数 ---> 系统构造 tool_result ---> 发回LLM ---> LLM 决定继续调用或输出最终回复

那如果OpenClaw 的Agentic Loop某一步工具调用失败了，怎么处理？

工具执行失败时，错误信息和详情会作为tool result 回填到上下文里，然后继续下一轮循环。LLM看到错误后自己决定下一步，可能换参数重试，换一个工具绕过去，或者直接告诉用户”这个搞不定“。所以错误处理逻辑不是硬编码的if-else，而是交给LLM的推理能力来判断。不过系统层面提供兜底保护：用户发新消息可以直接中断当前循环，防止 Agent卡死烧Token；如果遇到context overflow，系统会按优先级自动恢复：先触发Compaction 压缩历史 —> 再截断过大的 tool result —> 最后报错建议/reset。整个重试循环有迭代次数上限(默认 32~160次,取决于配置的auth profile数量)，防止无限重试。