
年初,如果你关注AI智能体,大概率被OpenClaw(龙虾)刷过屏。
短短几周,它迅速登上GitHub热榜。朋友圈、微信群、小红书里,到处都有人讨论如何安装部署。一人公司、数字员工、AI自主完成工作成了当时最热门的话题,催生了大量收费部署和远程安装服务。
我也在那时候装了OpenClaw,开始折腾。
但几个月过去,热度退了。很多人卸载了龙虾,转向Codex、Cursor、WorkBuddy等新的Agent产品。
而我,依然在用。
我继续使用它,并不是认定它是目前最好的Agent。更实际的原因是,它已经成为基金会中心网AI智能助手背后的核心编排平台。
今天这篇文章不讲OpenClaw的安装教程和使用技巧。我更想记录一个真实项目:我是如何利用OpenClaw,在一家公益机构,以尽可能低的成本,搭建一套真正服务行业用户的AI智能助手。
一、数据还在各自为战,AI却先来了
2024年初,我加入基金会中心网(CFC),开始负责基金会行业数据相关工作。
CFC一直承担着基金会行业数据基础设施建设的重要工作,积累了国内较为完整的基金会公开数据,包括年报、项目、中基透明指数(FTI)、行业研究等多个维度的数据资源。
当时,国内大模型发展非常迅速,有几家头部AI企业找到我们,希望使用CFC的行业数据训练大模型。
这也引出了一个新的问题:
这些数据,应该如何服务AI?
或者换句话说:
AI时代,数据平台真正的价值是什么?
当时,CFC内部对于数据开放、安全边界和AI应用等问题还在不断探索。与此同时,我们也发现:虽然拥有大量行业数据,但这些数据仍然分散在不同的平台、数据库和文档中,缺少统一整理与结构化组织,AI很难真正理解和使用它们。
我的领导吕全斌老师一直希望,CFC的数据不能只躺在数据库里,还要真正服务整个基金会行业。
AI的快速发展,让这个想法有了新的可能。
但对于公益机构来说,还有一个非常现实的问题:
预算。
相比商业公司,我们没有充足的研发预算,也没有专门的大模型团队。如果完全重新开发一套AI系统,成本和周期都很难接受。
因此,我们需要找到一种成本可控、能够快速验证,同时尽可能复用现有系统能力的方案。
就在这个时候,OpenClaw出现了。
二、选择OpenClaw,不是因为它能自动操作电脑
当时做技术选型,我主要对比了三类方案。
第一类是Dify、MaxKB这类带有可视化工作流的AI应用平台。它们功能很完善——拖拽式编排、内置RAG引擎、模型管理、对话流设计,基本都能开箱即用。但实际搭了几个Demo后,我的感受是:功能越多,配置也越重。一个简单的“用户提问→查知识库→调接口→返回答案”流程,在可视化画布里需要连接不少节点,调试和修改对我来说不够灵活。
这些平台本身各有优势,只是对于CFC这种“已有接口和业务系统,只需要增加一个编排层把它们连接起来”的场景来说,现阶段有些偏重。
第二类是Coze,这类偏向C端场景的Bot搭建平台。它们上手简单,但在系统对接和深度定制方面,未必完全符合我们的需要。
最终让我选择OpenClaw的关键,也不在于它能自动操作电脑。我更看重的是它相对轻量、灵活的编排能力。
定义好工具和接口,再通过自然语言描述Agent的行为逻辑,它就能按照设计好的流程完成调用。需要调整某个步骤时,也不必重新搭建整个流程。
对于CFC来说,一个会点击鼠标的AI并非我们的核心需求。我们真正需要的,是一个能够连接行业数据、知识库和业务系统的智能中枢。
相比完全重构已有系统,我更希望采用一种最小改动的方式:
- 保留原有的数据平台
- 保留已有的接口
- 保留已有的业务系统
AI负责把这些能力重新组织起来,为用户提供一个统一的智能服务入口。
于是,我们开始尝试在基金会中心官网增加AI智能助手。
三、目前已经上线了什么?
截至目前,基金会AI智能助手已经正式部署到基金会中心官网,并陆续接入:
- 基金会百科信息
- 中基透明指数(FTI)数据
- 基金会行业宏观统计数据
- 行业知识库RAG
过去,用户查询行业数据,需要分别打开多个平台、搜索不同页面。
现在,只需要提出一个问题,AI就能够综合多个数据来源,快速给出结果。
四、一个真正上线的AI智能助手,架构是什么样的?
很多人以为,AI智能助手就是接一个大模型,再连一个知识库。
真正开始做之后,我发现远没有这么简单。
为了尽量减少对现有系统的改动,我采用了一套分层架构:前端负责用户交互;中间增加一层BFF(Backend For Frontend,面向前端的后端服务),统一管理会话和请求;OpenClaw负责Agent的调度与编排。
而在OpenClaw和各业务平台之间,我又增加了一层接口整合中间件。
现在回头来看,这也是整个项目最重要的架构设计之一。
原因很简单:CFC原有的平台和接口,并不是为AI设计的。不同系统采用不同的认证方式、返回格式和参数结构。如果让OpenClaw直接调用这些接口,每增加一个平台,就要增加一套适配逻辑,Prompt会越来越复杂,维护成本也会越来越高。
于是,这层中间件统一负责五件事情:
- 接口认证
- 参数转换
- 数据清洗
- 返回格式统一
- 错误处理
对于OpenClaw来说,它始终只需要面对一套相对统一、干净的数据接口。
对于原有业务系统来说,也几乎不需要进行大的改造。
虽然整个调用链路变长了,但在现有业务基础上,这是改动较小、风险相对可控的一种实现方式。
五、自己挖的坑:把所有东西都塞进一个Agent
刚开始接触OpenClaw时,我对Agent的理解有一些偏差。
我以为,一个Agent就应该包含所有能力——工具、知识库、接口、对话全部放进去,再针对不同入口配置不同角色。
于是项目初期,我真的这么做了。
一个主Agent,什么都往里放。
一开始觉得很方便。
后来问题越来越多。
接入的数据越来越多,Prompt越来越长;角色越来越复杂,权限开始混乱;不同业务之间相互影响,甚至出现回答偏离设定范围的情况。
当时我一直以为,是Prompt没写好,或者配置没有调对。
后来我才意识到,继续修改某一句Prompt解决不了根本问题。真正不合理的,是把所有东西都塞进一个Agent这套设计思路。
OpenClaw的Agent更适合承担相对清晰、单一的职责,而不是做成一个大而全的超级Agent。
于是,我重新拆分了整个架构。
主Agent只负责统一调度和工具编排,不再承载所有具体业务逻辑;不同业务场景分别由独立的业务Agent负责。官网智能助手、内部测试等不同场景彼此隔离,各自管理用户身份、权限、工具授权、会话上下文和安全边界。
同一个业务Agent又可以服务H5、小程序、App等多个终端,共享同一套角色、权限和上下文规则。无论用户从哪个入口进入,获得的服务体验都可以保持一致。
六、从回答问题,到逐步理解业务
提到AI,大部分人的第一反应还是聊天。
但智能问答只是第一步。
我更关心的是,它能不能开始理解业务。
现在,用户已经可以直接查询某家基金会的信息、公益项目、FTI数据以及行业统计数据。
接下来,我们希望它还能完成更多具体业务,例如:
- 查询基金会FTI结果
- 自动定位未通过的指标
- 分析问题原因
- 通过自然语言补充材料
- 更新相关指标
- 根据不同用户身份提供差异化服务
这意味着,AI将从查得到逐步走向办得成:不仅把答案告诉用户,还能真正帮助用户把事情向前推进一步。
七、下一步
目前,AI智能助手还只是第一阶段。
未来,我们计划继续接入更多行业数据,包括历年FTI数据、行业数据大屏、基金会议题领域分类、SDG项目数据及研究成果、行业研究报告,以及更多经过结构化整理的行业知识。
这些数据最终将逐步形成一套统一的行业知识体系。
用户不需要知道数据来自哪个平台,也不需要了解背后的数据库结构,只需要提出问题,就能够快速获得相对准确、可理解的信息。
八、写在最后
完成这个项目之后,我最大的收获,其实不是学会了OpenClaw。
过去我一直认为,技术能力决定一个项目能不能做出来。
现在,我越来越觉得,AI正在快速降低技术实现的门槛。真正拉开差距的,更多是另外几件事情:理解业务、发现问题、设计产品、拆解任务、组织数据,以及持续试错。
AI可以帮助我们写代码,也可以完成很多具体工作。
但它替代不了我们理解业务,也替代不了我们思考:真正应该解决什么问题。
回过头来看,支撑这个AI智能助手走到今天的,并非OpenClaw本身,真正的基础是过去一年持续进行的数据治理。
数据规范了,流程清晰了,AI才能真正发挥价值。
真正让AI发挥价值的,不是接入一个大模型,而是先让数据变得可以被AI理解。
OpenClaw或许只是这个阶段的一款工具,未来可能被新的产品替代。
但理解业务、拆解问题,并借助AI把想法真正落地的能力,不会过时。
接下来,我也会继续记录基金会AI智能助手的迭代过程,包括实际使用中遇到的问题、Agent架构调整、数据与知识库建设,以及AI如何逐步从查得到走向办得成。
这些探索未必成熟,却都来自真实的业务和真实的试错。如果你也在思考AI如何进入自己的工作,希望交流具体场景、技术方案或者落地过程中遇到的问题,欢迎在文章下方留言,或者通过公众号后台联系我。
最近,我也准备启动AI工作效率共创计划,希望寻找一些真实的工作需求,一起梳理流程、设计方案,并尝试借助AI做出真正能够使用的工具。
如果你对此感兴趣,可以在公众号后台回复“AI共创”。你不需要提前想好该用什么工具,只需要告诉我:现在最消耗你时间、最容易出错、最希望被改善的一项工作是什么。
希望我们交流的,不只是AI又出现了什么新产品,而是它究竟可以帮助我们解决哪些真实问题。
朱清林 • Blog




评论(0)
暂无