本地系统对接大模型智能体的若干尝试
摘要
最近在拿一个VibeCoding项目练手，顺手尝试了几种把本地系统接入到智能体的几种方案。
这里的智能体，泛指OpenClaw，LangChain Agent,Trae等。
项目背景
这个系统来自于我先前驾驶陪练教练的一个想法，他是在北京自己创办的驾驶陪练公司。
面向的学员一类是刚拿到驾驶证，还没信心上路驾驶的学员，一类是好久没有开车，手有点生的学员，再一类就是针对某个项目需要学习，比如侧方，山路，告诉等。
业务的逻辑流程是学员联系公司客服，根据自己所在的区域以及上课时间，客服去查找最适合学员的教练。
所有的这些信息都是维护在一个Excel里，所以他一直希望能有一套系统做支撑。
功能整理
根据这个业务的流程，就可以把系统的功能大致划分如下：
- 学员，教练管理
- 课程预约管理
- 充值管理
- 余额统计
技术选型
根据目前比较火以及我比较熟悉的，选择了如下技术框架：
- Vue3
- FastAPI
- SQLLite
然后针对VibeCoding，我具体选则如下： - Trae CN
- Trae CN内置默认大模型，加火山Coding Plan
用国内模型优点是反应速度快，不需要FQ，不需要把自己伪装成打入敌人内部忍辱负重前行的特工007。。。
但是其中的一个缺点，不得不说的就是，大模型的善后工作，要占到一半以上，而且相应的技术，你最起码要懂，要不然没法善后。
另外智能体的选型，由于我的方案都是封装SKILL，所有测试的时候就直接在Trae CN里测，实际使用的时候在小龙虾里测。
我使用的小龙虾是QClaw，也许它目前不是最好的，但是它安装方便，而且目前每天还给很多的Token，开发测试学习都够用。
整体应用演示
这个OLTP项目我直接开源在了这里：
https://github.com/microsoftbi/DRVACLAW
还有一个演示视频可以在这里观看：
【驾驶陪练管理系统功能演示-哔哩哔哩】 https://b23.tv/DvlMhcP
对接智能体的方案尝试
总体的方案都是把相应的方法封装成SKILL。下面是我具体尝试的不同的方案。
给智能体封装特定的方法
起初我是按照比较传统的方法，就是让智能体做什么我就给他封装什么方法。
在这个方案里，我封装了三个方法，包括：
- 某一天都有哪些课
- 充值
- 排课
具体的效果我录了一个视频，可以在如下地址观看：
【将本地系统接入龙虾-哔哩哔哩】 https://b23.tv/K2kBxOs
可以看到在这个演示里，用户不再需要操作生硬的屏幕UI，直接通过自然语言的方式就可以完成特定的任务。
这个方法灵活了很多，那么是否有什么方法，可以放飞大模型的能力，不仅局限在给其封装的这些方法呢？
TEXT2SQL
由于我主要关注AI+BI这块，所以TEXT2SQL的方案直接闪进我的脑海中。相比针对BI的方案，对大模型生成的SQL语句精准度会比较高，也会复杂一些。但是对于这种小型OLTP系统，那简直再合适不过。
于是，我让大模型整理了建表脚本，怕大模型不认识字段？那就给脚本里加字段的注释，默认生成的脚本没有注释？让大模型自动去加。
简单折腾了之后，重新封装SKILL，开始测试。
起初的几轮测试，结果基本完美，大模型对于需求的理解，以及针对这种小型系统生成的SQL，很是完美。
但后来发现了几个问题：
比如，我告诉系统：给某学员充值1000，按理说我的业务逻辑是，这1000块钱对应多少节课也是需要指定的，结果大模型直接在课程数量上填写了一个10。不晓得这是幻觉，还是智能体记住了我先前测试数据的规律。但在我第一个方案中，由于在方法里是明确的指定了传入参数的，所以就不存在这个问题。
还有一个安全上的风险，就是得防着点大模型根据指令生成了删库删表这类的操作。
还有一个问题，我的有些业务逻辑是串起来的，比如，插入一个充值记录，也要往余额表里写一个记录，同时计算当前余额是多少。在这个流程中，大模型识别到了跟余额表的关联，生成了相应的语句，但是它并没留意到，当前余额还有多少这个字段。直接自己写了个0上去。
如果要解决这个问题，那么在SKIL里我就需要指定更多信息，是否有更好的方法呢？
直接把接口告诉智能体
我记得先前学LangChain Agent的时候，是可以把python的方法直接作为Agent的Tools，然后让Agent自己决定该调用哪些工具。
在OpenClaw里我们无法指定Tools，但是我们可以指定SKILL，在SKILL里可以指定为了做什么，可以去调用python的哪些方法。
而我的接口都是用FastAPI写的，这不都现成的么。
那么就结合这些信息，让智能体直接给我们自动生成一个SILL，部署。
以下是我针对这个方案的一段屏幕录像，大家可以感受下：
【【iHuskies】我的最新作品，快来一睹为快！-哔哩哔哩】 https://b23.tv/ENdSFoe
可以看到，基本上但凡是接口里暴露出来的方法，智能体都可以完成相依的操作，甚至有些数据的校验逻辑，都会顺便帮你查看。而智能体具体调用的方法，就是写了一个简短的Python脚本去通过Get或者Post去调用我的FastAPI的接口。
但是录制的时候无意中发现了一个问题，就是在一个数据插入的操作上，智能体判断错了用户的ID，不过居然还能在后续草种中自己发现然后修正了过来。
相比第二个方案，一些在业务流上的操作，比如余额表的插入和余额计算，还有一些审计记录的插入，这些都是封装在接口里了，所以智能体去调用的话，这些内部逻辑都不会被丢失。
而且，不用担心智能体被坏人指挥做删库跑路的操作。
总结
这里简单的汇总了，本地系统接入智能体的几个方案，希望能有抛砖引玉的效果。
AI来了之后，时代变了，改变了我们写代码的方式，也改变了我们与系统交互的方式。
让我们静观AI的发展，探索更多的可能性。