心法利器

本栏目主要和大家一起讨论近期自己学习的心得和体会。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。

2024年新的文章合集已经发布，获取方式看这里：再添近20万字-CS的陋室2024年文章合集更新，更有历史文章合集，欢迎下载。

往期回顾

• 心法利器[145] | 论文VS应用：算法工作的理想与现实，差距究竟有多大

• 心法利器[146] | 生成式搜索：惊艳但难落地的技术浪漫

• 心法利器[147] | Agent，是大模型落地的殊途同归

• 心法利器[148] |  如何面对算法工作里的脏活

• 心法利器[149] |  生日&跨年的思考——深水区探索

最近在做一些openclaw实际应用落地开发的活，基于 openclaw 模式的实际落地开发经验，我发现该模式在企业级场景中存在若干待解决的问题，算是给我自己也泼了盆冷水，今天我也给大家介绍一下，在我目前的实践下发现的这个东西的一些问题，里面有一部分是有解决方案的，但有一些还需要探索。

补充说一下，前段时间写了个openclaw的平替nanobot的源码阅读：前沿重器[83] | nanobot：万字长文解读OpenClaw平替项目源码，了解其内部逻辑后，对下文要讲的这些问题会有更清晰的认知。

个人级应用的缺陷

第一个想讲的是，openclaw是本身是个人级的应用，目前的大多数服务模式，基本是B2C的，直接套用openclaw肯定是不合适的，我列举几个点。

• Memory、Context等信息是存在个人终端的，无论是直接存内存还是本地文件存储，都不适合跨设备维护。如果直接拿到企业级应用，多机并发场景下也会出问题，例如第一轮请求落在 A 机器，第二轮请求分配到 B 机器，此时A机器的记忆在B机器里肯定就没了。

• 必要的监控运维。openclaw是基本没有的，服务健康检查、机器的 CPU、内存占用情况难以监控，个人应用简陋一些还好，但是企业级应用对这块的稳定性要求是非常高的。

• 用户级的安全问题。此处重点说的是，设备装在个人终端上，信息维护、系统稳定性的风险就很高。举个例子吧，通过记忆，本地记忆模块可能明文记录了账号密码，明文，此时有一个skill，能读取你的Memory然后发送到特定的路径上，这类行为可能在无显性输出的情况下偷偷完成，甚至用户完全未关注大模型的输出内容，这个信息就能轻松被盗走。安全无小事。

• 迭代困难。装在客户端的产品都有一个比较统一的毛病，那就是迭代困难，每次的升级，都需要定向派发更新，类似APP升级一样，一些小bug的修复这么弄肯定是非常恶心的，但是云端服务，基本可以做到用户无感更新。

尽管如此，得力于企业的强大沉淀，类openclaw的开发并不困难。他本质还是代码，只是大模型的调度，既然是代码，哪怕是古法编程手搓，难度也并不会很高（再次推荐看看源码！前沿重器[83] | nanobot：万字长文解读OpenClaw平替项目源码），所以经过一定程度的改造，内部还是可以用的。

• 本地存储改为数据库存储，甚至可以替换更强的记忆唤醒算法（其实就是记忆搜索算法）。

• 包装成服务，配合整套通用的运维服务。

• 安全问题需要专门做，比较省事的就是沙箱，但这并不保险，skill需要做安全审查，记忆内的敏感信息要做脱敏等。

补充说一下，并非个人信息保存在终端就是不安全，换个角度也是安全的，例如手机存的通讯录、短信、APP应用列表之类的信息，在一些合规标准下，是要求存在本地，不可上云的，这也是一种安全的模式，出于安全是可以保存在本地的，所以安全问题也是要具体情况具体分析。

Token问题

为了把事做好，大模型需要读取大量内容，除了基本的prompt，还包括但不限于Skill.md的内容，自己的写代码，HTTP接口请求的返回等，还可能要输出很多，如下一步的决策、生成的代码、自己的推理分析等，这将导致大模型需要处理的Token急剧增加，这会导致以下问题。

• 按照Token计价的大模型接口，毫无疑问的价格高昂。

• 长Token，还可能要多次请求大模型，耗时急剧增加。

• 句子一长，大模型的输出效果就会下降，幻觉、遗忘等问题就开始增加。

本来，自己写一套prompt，请求大模型很可能就能把一个事解决，事情也是一次性的，但是交给openclaw这个模式后，反而磨磨唧唧花了更久的时间，质量还不一定提升，钱花多了也没有足够的效果提升，还可能更差了，作为消费者肯定不能接受。

有关解决方案，从产品层面肯定是很难处理了，只能通过内部的优化解决。Manus之前提过渐进式披露和上下文工程（前沿重器[81] | Manus 如何用上下文工程释放大模型能力），就是压缩上下文的有效方法，最近还有个新概念，Harness Engineering（怎么这么爱造新词），是上下文的基础上，提供更多系统化、工程化整体的工作，这事看起来和我们现在日常干的活差不多，实际上，也差不多，真的差不多，现在算法的很多工作就是围绕大模型，给他提供一个更有利于他运转解决用户实际问题的这么一套框架，后续如果有比较统一的范式或者思路，我会持续跟进。

大模型的局限性

在openclaw的实践上，身边朋友诟病最多的问题是，这个东西的出现，并没有解决新问题，原本大模型能解决的问题，现在依旧是解决这些问题，原本大模型就解决不好的，现在依旧是不行。这里我举几个大模型解决的并不好的问题。

复杂数字计算的问题。设计一些复杂的数据计算，即使是把公式告诉他，他仍就可能会算错，尤其是批量的数据，还会出现丢数据的情况。而代码的执行逻辑是确定的，输入与输出高度可控，怎么进就怎么出，训练好的小模型、机器学习模型，可能在一些数值特征的问题上，有更高的上限。

信息差的问题。很多问题的解决，主要取决于对信息的收集，如公司内部的资料，一旦缺少这样的信息，大模型依旧解决的不好，顶多就是外部信息猜一猜。此外，跨过信息壁垒，还涉及获取的难度问题，类似接口文档的解析，我们作为开发的可以轻松知道怎么做，但是作为小白用户，这些信息就是一堆乱码，根本解决不了。再举一个仔细一些的问题，一个不了解代码的产品经理，要直接让大模型通过查数据的方式获取分析结果，要做好是非常难的，尽管大模型总能出结果，但质量依旧难以保障，数据采集口径、统计时长等等。

上限低的问题。这个模式基本都是基于大模型自身的能力，相信大家都知道，通用的大体积大模型，对特定领域，效果还是比较差的，这也是我们还需要微调的原因，举个例子，大家熟知的推荐系统，简单地问个问题让大模型推荐一下，肯定能得到一个还行的答案，但是要想推得准、转化率够高、收益够高，不结合大量的用户行为进行统计分析和深入的模型训练，上限难以提升。

定制难度高。对一个企业或者一个业务，他们有自己的一套管理模式和流程方案，这些对于大模型而言是不清楚的，简单地，让模型学会是简单的，但是复杂的、不可枚举的、依赖大数据来训练的任务，显然一个通用的大模型并不能搞定，这就不只是上限低的问题，而是完全无法落地使用。举个例子，在一些场景下，一些行为是不合规的，但是大模型并不了解，仍旧推荐给用户，这显然就踩了红线，要修正，成功率在实际生产中并不会那么高。

也许会有人说，大模型原本并不能做类似提醒、帮忙查数据、看PDF之类的功能，但从技术层面，其实早就有了，没大模型之前有些功能就已经有了，例如很多手机厂商的助手，就已经能做提醒之类的功能，只要和终端应用的接口打通就行，至于查数据、看PDF之类的，类似KIMI、千问之类的产品也很早就有做，顶多是前面的宣传没那么到位，现在的门槛变低，配合skill这种用户友好的模式，用户使用门槛降低了而已。

小结

我想，openclaw这套模式下依旧还有很多问题，还有待进一步实践才能暴露，但我相信这条路并不会平坦，在解决完各种简单的如提醒、做笔记之类的任务后，更多复杂的问题会逐步浮现。当然这也不意味着他就不行，我们要尝试着与之磨合，找到最适合的使用方式。

似乎成了习惯，我通常喜欢在很热闹的时候泼冷水。例如chatgpt刚出来的时候，我更倾向于去思考他的局限性和边界，这次也是一样，一个突破性技术出现后，我们总会很激动的畅想有哪些事情可以做了，然而我们还需要记住，一个新技术出来后，我们还需要知道他们的能力边界，知道他们不能做什么，或者说他需要哪些辅助，我们可以借助他做的更好，技术热潮下，让自己冷静下来进行全面、系统地思考，对实际的执行会更有用。