用了 OpenClaw,再回头看当初的选择

今年 3 月，OpenClaw 开始频繁出现在我的视野里。

那时，我已经在团队里落地了一套 AI 助手，接入了对内和对客的系统。我们不是从零开始，也不是看到 OpenClaw，才决定做 AI。

但后来，我还是选择把它引入进来。

我们最初采用的是多 Agent 架构：Master Agent 负责协调、意图识别和路由，SubAgent 通过 ReAct 循环完成具体的业务任务。

这套方案支撑了第一批能力上线，分工也比较清楚。

不过，当时 AI 还是探索项目。我从团队里调了一位同学，和我一起推进。除了我们自己开发，还需要和其他业务研发团队协作。

以退款 Agent 为例。

从用户侧看，只是多了一个“帮我处理退款”的能力。但在研发侧，需要退款业务团队提供 API，还要设计信息补齐、异常处理，以及模型理解错误时的防护。

涉及真实资金操作，账户、金额、权限和业务状态都需要校验。不能因为模型说可以退款，系统就真的执行。

业务研发团队也有自己的交付压力。有些需求排不上，我们就得自己参与业务方案和接口设计，才能继续往前推。

做少量几个场景，还能这样推进。但随着需求增加，三个问题逐渐明显。

覆盖不过来。 业务领域太多，Agent 越拆越细，研发不可能提前穷举每个人的工作场景。

调整不够灵活。 有时用户只是想改个分析口径、加个处理步骤，也容易重新回到研发的需求队列里。

产能被研发人数卡住。 长尾需求不是没有价值，只是总排不到前面。助手能做的事情有限，用户也就只有在少数场景里才会想起它。

这也影响了使用渗透率。当然，渗透率有很多影响因素，但当时我已经意识到：能力覆盖不足，不能只靠推广来弥补。

我需要改变的，不只是开发速度，而是新增能力都依赖研发的方式。

其实，今年年初，我就在考虑改造现有架构，支持 Skills 的加载模式。

我想尝试的是：能不能把一部分业务经验交还给熟悉业务的人，让他们自己描述、调整，再沉淀成可以复用的 Skill？

比如，平台已经提供查询和诊断能力。至于先看哪些数据、按什么步骤分析、最后输出什么格式，未必都需要研发提前写好。

这件事并不一定要用 OpenClaw。我们完全可以继续改造原有架构，多 Agent 和 Skills 也没有必要二选一。

所以，当时真正的选择不是“多 Agent 不行，必须换框架”，而是：继续自己建设这些通用能力，还是复用现成的实现，把有限的人力放到业务落地上？

OpenClaw 恰好在这个时候出现。它有一套可以直接利用的助手能力，让我们不必每一层都从头建设。

对于当时的人力配置，我更愿意先把产品往前推，去验证用户能不能真正用起来。

但我也清楚，它不会替我们补齐退款 API，更不会替我们理解公司的业务规则。省下来的是一部分通用机制和重复编排，不是所有业务研发工作。

回头看，还有一个原因：我们的用户，需要的不只是几个固定功能。

对内，我们面向公司的销售、运营和其他职能团队。他们需要内部系统提供可靠的能力，也有自己的工作方法。

同一份数据，有人拿来准备客户沟通，有人用来做日常复盘，还有人希望整理成自己的报告模板。

对外，我们面向的是帮助客户投放的代理商。他们同样需要平台提供数据和业务能力，但也有各自的服务经验和处理流程。

平台很难把这些差异，全部开发成标准功能。

所以，我希望这个助手能够同时容纳两件事：平台提供标准能力，用户组合自己的工作方法。

标准能力需要稳定、有权限边界；工作方法则需要允许调整和复用。OpenClaw 所呈现的助手形态，和我想尝试的方向比较接近。

当然，这不意味着开放一个 Skill 编辑入口，所有业务人员就都会创造能力。

更现实的起点，是先让一部分熟悉业务、愿意尝试的人参与进来，把自己的方法做出来，再让其他人复用。

至于这件事能否成立，要靠真实使用去验证，不是架构支持了就算完成。

在当时的阶段，引入 OpenClaw 确实加快了我们的产品进展。但随之而来的质疑，也很值得认真回答。

成本，是省下来了，还是换了个地方花？

最直接的是 Token 成本和机器部署成本。

研发少写一些代码，不代表线上运行就更便宜。通用助手是否值得用，应该放到同一个业务任务里，比较完成质量、人工介入和总成本。

路径固定、逻辑简单的任务，也没必要为了统一架构，都交给通用 Agent。

部署也是一样。一个人使用，和面向很多员工、很多客户提供服务，是不同的问题。

如果每人一个常驻实例，空闲资源怎么办？如果共享运行资源，状态、文件和凭据怎么隔离？这些都需要继续设计，不能把“部署成功”当成“服务化完成”。

Skill 多了，还能不能选对？

另一个经常被问到的问题是：如果有 100 个 Skill，意图识别和能力选择还可靠吗？

我不会把 100 个当成一个已经确定的失效阈值，也不会因为框架支持 Skills，就认为数量增加后效果不会变化。

尤其当几个 Skill 的描述相近、适用范围重叠时，能否选对，必须拿真实业务请求来测。

这个问题得靠评测回答，不能只靠对框架的信心。

安全边界同样没有消失。用户可以调整自己的处理流程，但不能因此改变业务权限。退款 Agent 变成退款 Skill，该做的业务校验仍然一个都不能少。

今天再看，我会把“帮助产品更快起步”和“能够长期规模化运行”分开评价。

前者，在当时的人力和业务背景下，我认为 OpenClaw 做到了。后者，还要继续看成本、效果、安全和维护投入。

对我来说，最重要的也不是部署了多少 Agent、积累了多少 Skill，而是新增一个场景，是否还只能回到我们两个人的研发排期里。

如果是，那最初想改变的问题，其实还在。

我不认为当时的选择是跟风：我们先遇到了问题，也已经有了改造方向，OpenClaw 提供了一条更快尝试的路。

但值得尝试，和已经证明适合长期使用，是两回事。

抛开热度，我仍然愿意继续研究它的设计。不是为了证明当时选得对，而是想看清楚：哪些能力值得继续复用，哪些问题需要我们自己补上。