OpenClaw 实战第八篇:从设计看 Agent 的未来

同样是 AI Agent 框架。有的折腾一周就吃灰了。有的能跑半年，越用越顺手。

为什么聊设计

前七篇讲完了怎么用。

Gateway 架构、Skills 系统、多 Agent 编排、自动化、安全、插件生态。每个模块单独拿出来都能干活。

但用到现在你应该感觉到了——OpenClaw 和别的 AI Agent 框架不太一样。

具体哪里不一样？为什么不一样？

最后一篇，换一个视角。以一个 AI Agent 工程师的身份，聊聊 OpenClaw 的设计。

分两部分：

上半部分——五个它做得特别好的地方。概念不新，但实现有章法。

下半部分——四个它做了前人没做过的事。这些选择，可能会影响 Agent 框架未来几年的方向。

上半部分：五个做得特别好的地方

一、Gateway：把 Agent 从聊天框里拆出来

用 AI 的人，和被 AI 折腾过的人，看到的是两个世界。

大多数 AI 助手长什么样

打开一个聊天框 → 打字 → AI 回复 → 继续打字。

模型、工具、消息渠道，三件事捆在一起。换个聊天软件？对不起，不支持。换个模型？对不起，写死在代码里了。想多开几个 Agent 分工？对不起，只有一个聊天框。

OpenClaw 怎么做的

Gateway 是中间的调度层。

      消息渠道                         Gateway                       模型 + 工具   ────────────                    ──────────                    ────────────   飞书   ──┐                                                    ┌── DeepSeek   Telegram ─┤                 路由 → Agent                    ──┤── Claude   WhatsApp ─┼──→ 消息 ←──→ 调度 → 上下文管理 → 工具调用 ──┼── GPT-4Discord  ─┤                 权限 → 记忆                    ──┤── Skills   Signal   ─┘                                                    └── Plugins

三件事各自独立。

渠道只负责收消息、发消息。Gateway 负责调度——把消息交给哪个 Agent、用哪个模型、加载哪些技能。模型和工具负责执行。

为什么这个设计好

换模型不碰渠道配置。 今天用 DeepSeek，明天换 Claude，改一行 openclaw.json。飞书、Telegram、Discord 不受任何影响。

同一个 Agent 同时在多个渠道工作。 你在飞书上跟它聊工作，回到家 Telegram 上跟它聊生活，它知道怎么切换——因为 Gateway 按渠道区分 Agent 人格。

一个新渠道接入，所有 Agent 立即能用。 装了 Discord 插件，你的所有 Agent 都同时有了 Discord 这个入口。不需要每个 Agent 单独配置。

这跟 CrewAI、AutoGPT 的路子完全不同。后者把 Agent 看成一次性的”任务执行进程”，启动、干活、结束。OpenClaw 把 Agent 看成一个长期运行的”数字员工”，Gateway 是它的值班室。

二、Skills 系统：用 Markdown 教 Agent 做事

传统的”教 Agent 做事”有多重

LangChain 定义 agent tool 要写 Python 类。

classCodeReviewTool(BaseTool):    name = "code_review"    description = "Review code for bugs and security issues"def_run(self, code: str) -> str:# 50 行实现代码pass

写代码、写测试、处理异常、打包发布。改一个工具的提示词，就要改代码、提交 PR、等 CI。

OpenClaw 的方案

技能就是一个 Markdown 文件。

---name: code-reviewdescription: 代码审查。用户在审查代码时使用。---# 代码审查技能1. 检查安全性：SQL 注入、XSS、硬编码凭证2. 检查性能：N+1 查询、不必要的循环3. 输出格式：每行一个 [严重程度] 位置 → 建议修改

这就是一个技能的全部。

不是代码，是文本。Agent 读到它，就知道要做什么。

这个设计的几个妙处

按需加载。 100 个技能，不是 100 个全塞进系统提示。Agent 根据任务特征，只加载相关的。Token 省下来了，注意力不会被无关技能分散。

门控条件。 技能可以声明依赖——”没有 Gemini API Key，这个技能不加载”。条件不满足，自动跳过，不报错。

多来源优先级覆盖。 社区版技能安装到 ~/.openclaw/skills，你可以用自己的版本放到 workspace 里覆盖它。不需要 fork，不需要改上游。

任何会写 Markdown 的人都能写技能。 不需要学框架，不需要写代码。打开文本编辑器，描述清楚步骤，就是一个技能。

Skills 的本质不是”安装功能”。是”给 Agent 的行为描述，用一种 Agent 自己能理解的方式写下来”。

三、安全沙箱：Agent 的能力应该被约束

第七篇讲过 1184 个恶意技能的案例。安全不是附加功能，是设计前提。

一个 Agent 能做什么 ≠ 它被允许做什么

这是安全设计的第一性原理。

你的 Agent 有文件写入能力。不意味着任何技能都可以让它随便写文件。

你的 Agent 能发消息。不意味着任何渠道的任何人发来的指令它都要执行。

OpenClaw 的分层安全模型

第一层：工具白名单。tools.allow 明确列出哪些工具可用。不在列表里的，Agent 根本看不到。

第二层：执行环境隔离。 高风险操作（文件写入、网络请求、Shell 执行）可以选择跑在沙箱里。即使 Agent 被 prompt injection 攻击，攻击者也突破不了沙箱边界。

第三层：用户确认。 发消息、删文件、发邮件——这些”不可逆操作”，Agent 默认需要用户确认。

第四层：审计记录。 每次工具调用有 trace_id，记录输入、输出、耗时。出了事能追溯整个调用链。

类比：手机 App 的权限管理

一个 App 想访问你的相册，系统弹窗问你同不同意。

Agent 也是一样。Skills 就像 App，想用某个工具，需要先声明、再授权、再审计。

安全设计的本质不是”防止一切攻击”。是”即使被攻击，攻击者能做的事情也极其有限”。

四、多模型支持：不绑定任何一家

这是容易被低估的能力。

绑定单一模型的代价

Cursor 绑定 GPT-4，GPT-4 涨价你就跟着涨。Copilot 绑定自家模型，效果不好你也换不了。

OpenClaw 的选择：任何 OpenAI-compatible 的 API 都能接。

你可以用 DeepSeek、Claude、GPT-4、Qwen、本地跑的小模型。

不只是”支持多模型”

热切换。 推理型任务用 Claude，代码型任务用 DeepSeek，日常聊天用小模型。同一个 Gateway，按 Agent 配置不同模型。

Fallback 链。 主模型超时了，自动切到备用模型。不需要人工干预。

不同 Agent 不同模型。 taichu（你的总管 Agent）用顶级模型做调度和决策。tfzl（你的写作助手）用性价比高的模型做内容生成。

为什么这很重要

AI 模型市场变化极快。今天的最优解可能是明天的次优解。

OpenClaw 的设计让你不被任何一个模型提供商锁定。这是架构层面的自由。

五、上下文压缩：长任务的记忆管理

上下文窗口有限。所有 Agent 框架都面临这个问题。

问题在哪

一份 50 页的文档丢给 Agent，写方案写到一半，它开始”失忆”——前面定好的框架、提的要求，全忘了。

不是模型不够聪明。是早期的关键指令被新信息挤到了上下文窗口外面。

OpenClaw 的解法

四层策略叠加：

角色隔离。 系统指令、用户指令、工具返回、历史对话——不混在一起。Agent 知道哪个信息来源更可靠。

信息裁剪。 工具返回的日志可能有几千行。只提取关键结论注入上下文，原始日志存文件。Agent 不需要读几十行堆栈跟踪才知道”编译失败了”。

来源分层。 不同来源的信息权重不同。系统指令优先级最高、全程保留。历史对话优先级最低、可以被压缩或淘汰。

过期淘汰。 超过一定轮次未引用的信息，标记为过期，不再注入上下文。

上下文不是仓库，是工作台。台上只放当前要用的东西。

跟 MemGPT 的路子不同。MemGPT 的思路是”用模型自己管理记忆”——让 LLM 自己判断该存什么、该取什么。这个思路优雅，但引入了额外的推理开销。

OpenClaw 的思路更工程化：不是让 Agent 自己猜，而是设计好结构和策略，让 Agent 在正确的时刻拿到正确的信息。

下半部分：四个前人没做过的事

以上五个，是 OpenClaw 把成熟概念实现得好的地方。

下面四个，是它真正做了开创性选择的地方。

一、用文件系统取代数据库

Agent 框架行业的主流做法是什么？

LangChain 用 YAML 配链，AutoGPT 用 JSON 定义 agent，CrewAI 用 Python 类定义角色。配置、状态、记忆——分散在数据库、配置文件、环境变量里。

OpenClaw 说：不用这么复杂。

Agent 的全部存在——身份、记忆、技能、会话历史——就是硬盘上的一个文件夹。

~/.openclaw/workspace/├── SOUL.md           # Agent 的身份和性格├── AGENTS.md         # 团队定义和协作规则├── USER.md           # 用户信息和偏好├── MEMORY.md         # 长期记忆├── HEARTBEAT.md      # 定期巡检任务├── IDENTITY.md       # 自我认知├── memory/# 按日期组织的记忆日志├── skills/# 技能文件└── TOOLS.md          # 环境配置笔记

为什么这是根本性的改变

人类和 AI 共享同一个工作界面。 你看 SOUL.md 理解 Agent，Agent 也读 SOUL.md 理解自己。没有”人类看到的配置”和”模型看到的 prompt”之间的翻译层。

Agent 可以像代码一样被管理。 git clone 一个文件夹就是完整的 Agent。git diff 就知道 Agent 的什么行为被改动了。

Agent 可以在 Gateway 重启后自动恢复。 状态全在文件里，不在内存里。不是启动 → 运行 → 销毁的进程，是一个持久存在的东西。

这不是技术选型。这是对”Agent 是什么”这个命题的重新定义。Agent 不是运行中的进程。Agent 是一个目录。

二、插件和技能彻底分离

在 OpenClaw 之前，主流框架对”扩展”的理解是模糊的。

LangChain 的 tool 和 agent 混在一起。AutoGPT 的 command 和 prompt 不分家。给 Agent 增加能力和教 Agent 使用能力，用的是同一套机制。

OpenClaw 的分离

为什么这个分离很重要

不同风险模型需要不同的安全策略。 对插件——做运行时沙箱隔离。对技能——做静态文本审计。不会因为混在一起而一刀切地套用高成本的安全措施。

不同迭代速度需要不同的加载机制。 改一个技能的 Markdown，下一次对话就生效。改一个插件的代码，需要重启 Gateway。分离意味着最快的迭代不需要触碰运行时。

技能市场因此成为可能。 ClawHub 上有超过 4000 个社区技能。如果技能是代码，发布和安装的门槛会高几个数量级——需要编译、签名、沙箱审计。但因为技能是 Markdown，任何人都能写、任何人都能读、任何人都能审核。

三、六层自动化精度分层

大多数 Agent 框架的自动化提供两种模式：定时任务 和 事件触发。

但真实场景没这么简单

“每天早上 9 点发日报”——精确时间，不需要上下文。→ 定时任务。

“时不时帮我看看有没有新邮件”——模糊时间，需要知道最近的对话上下文。→ 什么机制？

“永远不要在周末给我发工作消息”——永久规则。→ 什么机制？

“刚才对话里你答应帮我跟进的那个事”——自然对话中的承诺。→ 什么机制？

OpenClaw 把这六种需求拆成了六个独立机制：

背后的工程思考

精确时间、共享上下文、失败隔离——这三件事不可能同时做到。

一个任务在精确时间触发，就不可能共享主会话的上下文（主会话可能正在处理别的事）。一个任务共享主会话上下文，触发时间就只能”等主会话空闲”。

大多数框架的解法是：找一个”足够好”的中间方案，放弃某个维度。

OpenClaw 的解法是：六种全给你，根据场景选最适合的。

懒不是把能做的事简化为不做。真正的工程懒是——把所有场景的解法都做好了，你只需要选。

四、多 Agent 隔离 + 消息路由

“多个 AI 助手”和”一个团队的数字员工”是两回事。

多 Agent 的本质问题

协作需要共享信息。稳定需要彼此隔离。

一个 Agent 被恶意 prompt injection 攻击——它产生的有毒上下文，不应该污染另一个 Agent。

一个 Agent 因为长任务上下文爆满而崩溃——不应该拖累其他 Agent。

但完全隔离又没法协作。怎么设计？

OpenClaw 的方案

每个 Agent 拥有一套独立的东西：

• 独立的 workspace
  
  ——互不干扰的工作目录
• 独立的认证
  
  ——taichu 的飞书 token 不会漏给 tfzl
• 独立的技能集
  
  ——按需加载，互不相关
• 独立的会话存储
  
  ——上下文互不污染

但它们可以通过三种方式协作：

• sessions_spawn
  
  ——Agent A 可以委托任务给 Agent B
• 共享文件系统
  
  ——Agent A 写入分析结果，Agent B 读取后生成报告
• memory_search 跨 Agent
  
  ——tfzl 可以搜索 taichu 记录的项目信息

实现了什么

一个人的 AI 助手 → 一个团队的 AI 基础设施。

你有 taichu 当总管协调，有 tfzl 专职写文章。互不干扰，但能配合。

这就是从”个人工具”到”团队设施”的架构跃迁。

大多数 Agent 框架还停留在”单 Agent 怎么更强”。OpenClaw 已经在做”多 Agent 怎么协作”了。

最后

回顾一下。

OpenClaw 做得特别好的地方：

Gateway 把 Agent 从聊天框里拆出来，渠道和模型解耦。

Skills 用 Markdown 而不是代码定义 Agent 行为，任何人都能写。

安全沙箱四层防护，能力 ≠ 权限。

多模型热切换，不绑任何一家。

上下文分层压缩，工作台上只放当前要用的东西。

它做了前人没做过的事：

用文件系统取代数据库——Agent 是一个目录，不是进程。

插件和技能彻底分离——代码和文本的风险模型不同，就应该分开管。

六层自动化精度分层——三角不可兼得就全部给你。

多 Agent 隔离 + 路由——从个人工具到团队基础设施。

大模型提供了能力上限。Agent 的设计决定你能拿到多少。而这些设计选择，决定你拿到的东西往哪个方向走。

OpenClaw 没有选”开箱即用”的路线。它选择了”可定制”。这不是偷懒。这是价值观——用户控制权，永远排在便利性前面。

这是 OpenClaw 实战系列的第八篇，也是最后一篇。

感谢阅读。