企业Agent落地-为什么OpenClaw类工具替代不了自研Agent

企业 Agent 落地：为什么 OpenClaw 类工具替代不了自研 Agent

全文速览

OpenClaw 是面向”消息路由”设计的开源 Agent 框架，做个人助理和 ChatOps 很强，但拿来做企业级多租户 Agent 平台会遇到 9 个致命问题：能力扩展靠提示词、嵌入性差、动态管控缺失、技能快照锁死、权限粒度不足、运维成本高、水平扩展受限、知识管理薄弱、可观测性缺失。核心矛盾在于架构基因不同——Gateway-Centric vs Business-Centric。

做 Agent 选型的时候遇到一个绕不过去的问题——团队里有人提议用 OpenClaw（小龙虾）替代现有的自研 Agent 架构。理由很直白：开源的东西社区活跃、功能全、不用重复造轮子。

听起来合理，但实际调研下来发现完全不是那么回事。

先说结论

OpenClaw 是个好东西，做个人助理、聊天机器人、多渠道消息中转都很强。但拿它做企业级多租户 Agent 平台，就像拿 WordPress 做电商中台——能跑，但你会痛不欲生。

核心矛盾就一句话：OpenClaw 是面向”消息路由”设计的，不是面向”业务编排”设计的。

架构基因不同：Gateway-Centric vs Business-Centric

OpenClaw 的架构核心是一个 Gateway 守护进程，绑定 WebSocket 端口（默认 18789），所有 Agent 运行、消息收发、工具调用全部通过这个 Gateway 中转。它的设计初衷是打通 WhatsApp、Telegram、Slack、Discord 这些消息渠道，让一个 AI 助理能同时服务多个平台。

+————————————-+| Gateway (Node.js) || +—–+ +—–+ +—–+ +—–+ || | WA | | TG | |Slack| | Web | || +–+–+ +–+–+ +–+–+ +–+–+ || +——-+——-+——-+ || Router || +——-+——-+——-+ || +–+–+ +–+–+ +–+–+ || |AgentA| |AgentB| |AgentC| || +—–+ +—–+ +—–+ |+————————————-+

而我们的场景是什么？是一套已有的业务系统（Java/Go/Python/C# 都有可能），里面有几十个业务模块（客户、订单、设备、工单……），每个模块需要一个专属 Agent 来处理自己领域的问答、操作、审批。Agent 之间要互相协作，共享部分上下文但数据严格隔离。

这两个场景的设计重心完全不在一个维度：

维度	OpenClaw	自研 Agent
核心抽象	消息通道 + 路由规则	业务模块 + 知识域
Agent 生命周期	配置文件静态声明	跟随业务实体动态创建/销毁
通信模型	Gateway 星型中转	本地方法直调（A2A）
隔离粒度	Agent 级别	业务模块级别
运行时	Node.js 独立进程	嵌入业务主进程

· · ·

01 第一刀：能力扩展全靠”说服” LLM

先说最容易被忽略的一个问题。

OpenClaw 的能力扩展分三层：

提示词（SOUL.md / AGENTS.md）——定义 Agent 的人设和行为规则
Skill（SKILL.md）——告诉 Agent “什么时候用什么工具”
Plugin（TypeScript 代码）——注册自定义 Tool、加 RPC、写逻辑

前两层本质上都是提示词——你在用自然语言”请求”模型遵守规则。模型大部分时候会听，但没有任何代码层面的强制力。如果你写了一条 Skill 规则说”每次查询最多返回 100 条记录”，模型完全可能忽略这条限制直接返回 500 条。

第三层 Plugin 才是真正的代码级扩展，能做刚性的限流、鉴权、参数校验。但 Plugin 要用 TypeScript 写，跑在 Gateway 进程里。如果你的团队是 Java/Go/Python 栈，大概率不会为了写几个 Plugin 专门搞一套 TS 工程。

所以现实情况是：大部分团队用 OpenClaw 做业务，能力边界就卡在提示词和 Skill 这两层。 你没法在 Skill 层面做刚性的权限管控、调用频率限制、数据脱敏。模型”不听话”的时候，你唯一的兜底手段是改提示词再试一遍。

TIP · 软约束 vs 硬约束

提示词和 Skill 是”软约束”——模型大概率遵守，但没有 100% 保证。代码实现的限流/鉴权/校验是”硬约束”——不管 LLM 输出什么，都得过你的逻辑这道关。生产环境里，软约束只能用于”建议”，硬约束才能用于”管控”。

自研 Agent里，Agent 的每一个能力都是代码实现的函数。限流是代码写的，鉴权是代码写的，入参校验是代码写的。不管 LLM 输出什么参数，都得过你的业务逻辑这道关。软约束和硬约束的区别，上了生产你就懂了。

02 第二刀：嵌入性

OpenClaw 是一个 Node.js/TypeScript 应用，跑在自己的进程里，对外暴露 WebSocket 和 HTTP 接口。不管你的业务系统是 Java、Go 还是 Python，都没法把它当 SDK 直接引入。

这意味着什么？

你现有的业务逻辑——比如 Spring Boot 的 Service 层、Go 的 gRPC Handler、Python 的 FastAPI 路由——Agent 全部无法直接调用。每一个业务能力都得包装成 HTTP 接口，然后在 OpenClaw 里注册成 Skill 或 Plugin Tool，通过网络远程调。

一个原本几毫秒的本地方法调用变成了：

Agent -> Gateway WebSocket -> HTTP -> 反向代理 -> 业务服务 -> 返回

一来一回，网络开销、序列化开销、连接池管理，全部加上。更麻烦的是，你的 Agent 和业务代码分属两个进程甚至两台机器，事务一致性、异常传播、超时重试全得重新设计。

自研 Agent呢？Agent 就是业务主进程里的一个模块（Java 里是 Bean，Go 里是 struct，Python 里是 class）。调业务方法跟调本地函数一样，零网络开销，事务天然一致，异常栈完整，排障直接看一份日志。

03 第三刀：多租户动态管控

OpenClaw 的多 Agent 是这么配的：

{“agents”: {“list”: [ { “id”: “home”, “default”: true, “workspace”: “~/.openclaw/workspace-home” }, { “id”: “work”, “workspace”: “~/.openclaw/workspace-work” } ] },“bindings”: [ { “agentId”: “home”, “match”: { “channel”: “whatsapp”, “accountId”: “personal” } }, { “agentId”: “work”, “match”: { “channel”: “whatsapp”, “accountId”: “biz” } } ]}

看出来问题了吗？

每加一个 Agent，你得改配置文件、创建 workspace 目录、写 SOUL.md、配 binding 规则。这是典型的运维驱动模式——适合你有 3~5 个固定 Agent 的场景。

但我们的场景是：业务系统里新建一个”客户”模块，就自动生成一个对应的 Agent 实例，挂载该模块的专属知识库和元数据。客户有 500 个分类，就可能有 500 个 Agent 实例动态存在。有的活跃，有的休眠，有的临时创建用完就销毁。

这种动态性，OpenClaw 的静态配置模型完全兜不住。你难道要写个程序来动态改写 openclaw.json、创建目录、重启 Gateway？

自研 Agent里，创建一个 Agent 就是数据库里插一条记录 + 加载一份 Prompt 模板到内存。知识库分片是数据库层面的物理隔离，不是文件系统层面的目录隔离。扩缩容就是增减内存对象，不是增减进程。

04 第四刀：技能快照锁死

OpenClaw 的 Agent 运行时有一个设计：技能（Skills）在会话启动时做一次快照（snapshot），之后整个会话期间 Skill 列表固定不变。

源码里的逻辑是：

agentCommand -> loads skills snapshot -> calls runEmbeddedAgent

这个设计对个人助理场景没问题——你的 Agent 启动后能干什么就定了，用户清楚预期。

但对企业场景这是灾难。

比如：一个”订单处理 Agent”正在运行中，管理员突然给这个业务模块新增了”退款审批”能力。如果技能是快照锁死的，要让 Agent 获得新能力就得断掉会话重建。对正在进行中的多轮对话来说，上下文全丢。

自研 Agent里，技能列表是动态注册的。Agent 运行时可以热加载新能力，不中断会话，不丢上下文。因为 Skill 本质就是业务代码里的一个策略对象，注册/注销是内存操作。

05 第五刀：权限管控粒度

OpenClaw 的权限体系：

tools.allow / tools.deny

——全局级别
tools.profile

——Agent 级别（minimal/standard/coding/full）
agents.list[].tools

——per-agent 覆盖

看上去有层次，但仔细看全部是基于”工具类型”做的开关。比如你可以禁止某个 Agent 用 exec 工具，或者限制它只能用 group:fs。

但企业场景的权限需求是什么？

“客户 A 的 Agent 只能查询客户 A 自己的数据，不能碰客户 B 的”
“实习生创建的 Agent 最多查 100 条记录，资深员工的 Agent 不限”
“生产环境的 Agent 禁止写入操作，只有审批后才临时开放”

这种行级数据权限、角色联动权限、时间窗口权限，OpenClaw 的 allow/deny 根本表达不了。它的权限模型是”这个 Agent 能不能用文件系统工具”，不是”这个 Agent 能不能访问张三的订单数据”。

自研 Agent里，Agent 的每一次工具调用都经过业务层的权限拦截器（Java 的 AOP、Go 的 middleware、Python 的 decorator），跟业务系统的 RBAC 共用一套权限体系。数据隔离在 SQL 层面 WHERE 条件里就做了，不需要额外机制。

06 第六刀：运维成本和迭代效率

引入 OpenClaw 意味着你的技术栈里多了一坨 Node.js 服务。线上维护两套运行时：

业务服务：你原本的技术栈（JVM/Go runtime/Python 进程）
OpenClaw Gateway：Node.js 进程、WebSocket 连接管理、Skills 热加载

出问题的时候，你得在两套日志里来回跳，还得理清楚是 Gateway 层的问题还是业务层的问题。

更痛苦的是迭代：改一个 Agent 的行为，你可能得同时改 OpenClaw 的 SOUL.md/SKILL.md + 业务代码里暴露的接口。两边配合改，联调、测试、上线节奏很难对齐，极易出现”OpenClaw 那边改了但业务接口还是老的”这种不同步问题。

自研 Agent呢？一套代码、一份日志、一个发布流程。Agent 的 Prompt 模板、Skill 实现、权限规则全在同一个工程里，IDE 里全局搜索就能定位所有关联点。

07 第七刀：会话存储和水平扩展

这一刀比较隐蔽，但会在生产环境里要你命。

OpenClaw 的会话存储是本地文件系统：sessions.json（元数据） + .jsonl（对话记录）。所有数据写在 Gateway 所在机器的磁盘上。

这意味着什么？

你没法做水平扩展。 多实例部署时，用户请求必须 sticky 到固定实例，否则会话数据丢失。实例挂了，它身上的所有会话上下文永久消失。社区有人专门提了 Feature Request 要求支持 Redis/MongoDB 作为外部存储后端，到现在还没落地。

避坑

有人在 GitHub 上报了一个 issue：当 subagent 会话累积到 400 个时，CPU 飙到 100%。原因是 sessions.list 每次调用都做 O(n) 全量序列化，而控制面板每 7 秒轮询一次。12 个 session/小时的创建速度，不到两天就能打爆。

自研 Agent里，会话数据存在数据库里（MySQL/Redis），天然支持多实例无状态部署。10 万个会话并发在线？加机器就行，不存在单点瓶颈。

08 第八刀：记忆与知识管理

OpenClaw 的”记忆”系统是纯 Markdown 文件：

MEMORY.md

——长期记忆（手动维护）
memory/YYYY-MM-DD.md

——每日笔记（自动追加）

检索方式是基于文件的语义搜索（memory_search 工具），本质上是全文搜索加上向量匹配。

企业 Agent 的知识管理需求：

每个业务模块有自己的知识库（产品文档、历史工单、FAQ）
知识库需要结构化存储（不是一坨 Markdown）
需要精确到字段级别的检索（”查一下客户 A 的最近 5 条工单”）
知识更新后要实时生效，不是等下次会话重启

OpenClaw 的 Markdown 文件记忆根本不是一个量级的东西。它解决的是”AI 助理记住你的偏好”，不是”企业知识库按租户隔离并高效检索”。

注意

OpenClaw 还有一个设计：会话接近 token 上限时会自动 compaction（压缩），把旧上下文总结后丢弃原文。对长对话场景是灾难——Agent 可能忘记之前讨论过的关键细节。社区的吐槽很直白：”OpenClaw treats memory as a cache (evictable) rather than an asset (persistent).”

自研 Agent里，知识库是独立的存储层（向量数据库 + 关系数据库），跟会话上下文解耦。Agent 丢了对话历史不要紧，知识库里的数据永远在。

09 第九刀：可观测性和审计

企业 Agent 上线后，领导问的第一个问题永远是：

“这个 AI 到底干了什么？谁用的？调了哪些接口？花了多少钱？”

OpenClaw 的可观测性：Gateway 的 WebSocket 事件流 + 本地 JSONL 日志。要做统计分析，你得自己写脚本解析日志文件。要做审计回溯，你得去翻磁盘上的 transcript 文件。没有内置的 Dashboard、没有调用链追踪、没有按租户维度的计费统计。

自研 Agent天然跟公司的监控体系打通：

每次 LLM 调用记录到统一日志平台（ELK/Loki），带上业务模块 ID、用户 ID、耗时、token 消耗
接入 Prometheus 指标，Grafana 面板一目了然
工具调用全部过拦截器切面，自动记录审计日志
按租户维度统计 token 消耗，月底谁花了多少钱清清楚楚

这不是锦上添花，很多行业（金融、医疗、政企）这是合规强制要求。

· · ·

关于二次开发的现实

有人会说：那我深度二开 OpenClaw 呢？

OpenClaw 确实支持 Plugin 系统，能用 TypeScript 写自定义 Tool、注册 Gateway RPC 方法、甚至加 HTTP 路由。技术上不是”只能改提示词和 Skill”。

但问题是：

Plugin 是 TypeScript 写的，你的团队可能是 Java/Go/Python 栈。要么招 TS 开发，要么现有团队学新语言
Plugin 跑在 Gateway 进程里，跟你的业务进程不在一个内存空间。想调业务方法还是得走网络
框架的核心抽象不匹配——你二开了半天发现自己在跟框架的设计理念作斗争。改路由逻辑、改会话管理、改权限模型……改到最后框架只剩个壳子，还不如从头写

二次开发的真正成本不是”改代码”，而是”跟框架的设计假设做对抗”。当你的需求跟框架的核心假设冲突时，二开的工作量可能比从零搭建还大，而且你还背上了框架升级的包袱。

那 OpenClaw 适合什么？

话说回来，OpenClaw 不是不好，是场景不对。它适合的场景很明确：

个人 AI 助理——一个人跨多平台（WhatsApp + Telegram + Slack）用一个统一的 AI 大脑
小团队 ChatOps——几个固定 Agent 各管一摊事，偶尔互相转发消息
消息中转枢纽——把各种 IM 平台消息聚合到一起，AI 统一处理
原型验证——快速搭建 Agent Demo，验证 Prompt 和工具编排思路

这些场景下 OpenClaw 的优势巨大：开箱即用、渠道集成丰富、社区 Skill 生态好。

但如果你的需求是”在现有业务体系里，按业务模块维度做多租户 Agent 平台”——开源框架只能给你灵感，不能给你答案。

几个常见误解的澄清

写到这里，得纠正几个对 OpenClaw 的过度简化说法，否则文章不够公正：

误解 1：”OpenClaw 只能用 Skill 和提示词做功能扩展”

不对。OpenClaw 有完整的 Plugin 系统，能用 TypeScript 写自定义 Tool、注册 Gateway RPC、加 HTTP 路由、甚至注册后台服务。它的 Plugin 跑在 Gateway 进程里（in-process），性能不差。

但关键问题是：你的业务系统是 Java/Go/Python 写的，Plugin 是 TypeScript 的，两者不在一个进程空间。所以结论没变——调业务方法还是得走网络。

误解 2：”Agent 之间完全不能直接通信”

OpenClaw 有 ACP（Agent Communication Protocol），支持 subagent 派生，父子 Agent 可以协作。但现状是子 Agent 只能向父 Agent 报告，不能跟其他 Agent 直接对话。社区有 RFC 提案（Agent Teams）要做 Agent 直连，但还没落地。

误解 3：”权限是全局统一配置”

OpenClaw 支持 per-agent 的 tools.profile 和 tools.allow/deny，粒度到 Agent 级别。但这是”工具级权限”（能不能用某个工具），不是”数据级权限”（能不能访问某条数据）。企业需要的后者，它确实做不到。

选型建议

做 Agent 架构选型，先问三个问题：

1. 你的 Agent 是独立产品，还是嵌入已有系统？

独立产品 -> 开源框架省力
嵌入已有系统 -> 自研 Agent可控

2. 你的 Agent 数量是固定的，还是动态伸缩的？

固定几个 -> 配置驱动的框架够用
动态成百上千 -> 需要代码驱动的生命周期管理

3. 你的权限需求是工具级别的，还是数据级别的？

工具级别（能不能用搜索、能不能执行命令） -> 开源方案自带
数据级别（能不能看某条记录、能不能改某个字段） -> 必须跟业务权限体系打通

三个问题只要有一个答案指向后者，自研 Agent大概率是更合适的选择。

不是说开源框架不行，而是架构这东西，合脚比名牌重要。

一句话总结

开源框架给你的是”消息路由”的最佳实践，但企业 Agent 需要的是”业务编排”的深度定制——架构基因不同，强扭的瓜不甜。

#AIAgent #企业架构 #OpenClaw #多租户 #自研框架 #技术选型 #Agent开发 #微服务 #后端架构 #Go

觉得有用？扫码关注「昕悦技术栈」持续输出实战干货

长按识别二维码，关注我！