本地财务数据AI分析工具部署后续-与其自己开发不如使用成熟Agent

一、前情回顾

上回说到，我用 4 块 V100 + vLLM + Qwen3.5-35B-AWQ 搭了一个本地财务数据分析工具，Excel 传上去就能问答分析，纯本地不联网，数据不出内网。前端用 Gradio，后端 FastAPI，顺带注册到 Dify 当外部工具。前前后后折腾了快两个月，踩了无数坑，最后总算能跑了。

写上一篇教程的时候，我以为最难的部分已经过去了，然而事实证明我还是天真了。

就是这一篇：

财务数据AI分析工具本地部署教程：用vLLM + Qwen3.5在4×V100上搭建私有Excel智能问答系统

二、好消息自研工具上线了坏消息 0用户（

工具在开发的时候我其实就已经提前想好用户交互了，基本上就是按照把客户当傻子来设计的这个程序。已经很努力的把用法整理得清清楚楚了：打开浏览器、上传 Excel、输入问题、等结果。还加了四个快捷预设按钮，点了就能自动填好 Prompt。

上线之后客户说："这个怎么用？"

我发了操作步骤。客户又问："上传了文件之后点哪里？"

我截图，红框圈好按钮位置。客户继续："分析结果怎么导出来？"

"我能不能在手机上用？"

"能不能直接发微信给它分析？"

到这一步我心态已经开始崩了，备受打击.jpg

所以说去我写出来的那些东西，用的最多的是我自己？？？

三、那就换个思路：Openclaw

痛定思痛，问题出在哪？我不是做产品的，就我个人以程序员的视角写不出用户体验。我需要一个现成的、普通员工能不学就会用的 Agent 框架。

当时市面上的选择不多：

Claude Code 刚被迫开源，生态还不成熟
Codex 还没出来
各种国产 Agent 框架一眼难尽

最终选择了 Openclaw。理由很简单：

1. 部署简单。 我草那部署是真简单啊，喝了口水再抬头一看软件包装完了。

2. 自带微信接入。这个是决定性因素。员工的手机扫个码就能在微信里和机器人聊天、传文件。完完全全的零学习成本，他们本来就会用微信，直接接入微信是最简单的了。

3. 中文互联网知名度。 Openclaw 当时在中文技术圈火过好一阵，客户拿出去跟合作伙伴说"我们用的是 Openclaw"，比"我们用的是一套自研分析工具"听起来紧跟时代潮流，方便客户吹牛，这是最大硬需求（

4. 社区活跃，迭代快。 遇到问题能搜到讨论，不像我的自研工具出了问题只有自己硬啃。

四、初步上线

Openclaw 上线之后，我接的是 DeepSeek-v4-flash 的官方API。

原因是DeepSeek 的 API 性价比极高，推理质量在线，速度够快，梁圣这个API和不要钱差不多了。Openclaw config设置一下api key就能用了，不需要自己管任何基础设施。

顺便补一嘴联网搜索用的是KIMI，冲了10块钱刚才看了一眼三个月还没用完（

效果非常的立竿见影。客户那边的员工在微信里和bot发个 Excel，打一句话"帮我看下这个月的支出情况"，一分钟出结果。

说白了就是和上司给下属布置任务一样发文件，打字，等结果，在AI时代创建出一个赛博员工能让这些领导继续过官瘾。

五、合规

虽然是跑起来了，但是其实这个项目最开始要做的就是因为要合规。不能把涉密数据交给第三方，两个硬性要求砸下来：

第一，涉密数据必须本地处理。 财务数据、客户信息、合同内容这类敏感数据，不能走在线 API。DeepSeek 的服务器在外面，数据传输路径不受控，审查过不了。

第二，模型要能看图。 客户的实际场景里，很多信息是截图传过来的。报销单、对账单、合同条款的拍照。纯文本模型没法处理这些，得自己跑去看图再告诉它，流程又绕回去了。

六、分流方案：在线 + 本地混合架构

简单思考了一下，deepseek-v4-flash文字强但是没有看图的能力，本地部署的Qwen3.6性能较弱但是是多模态模型。

那就很简单了，写一个分流条件:该用在线 API 的用在线 API，该走本地模型的走本地模型

用户消息 → Openclaw Agent
↓
分流判断节点
↓
┌──── ──┴───────┐
↓ ↓
涉密数据 / 含图片普通对话 / 非涉密分析
↓ ↓
本地 Qwen3.6 DeepSeek-v4-flash
多模态模型在线 API
(安全，能看图) (快，便宜)

具体实现下来就是：

涉密检测：在 Openclaw 的请求前置环节加了一层敏感内容识别。用户上传的文件或消息里包含公司名称、银行账号、金额明细等特征，自动路由到本地 vLLM。
图片检测：消息里包含图片（截图、拍照），自动转本地多模态模型处理。Qwen3.6 支持视觉输入，能看懂报销单截图和对账单照片。
普通对话：闲聊、非涉密分析、对数据不出境没有要求的任务，继续走 DeepSeek 在线 API，速度快体验好。

客户的体验上基本是没有变差，日常聊天和一般问题照样秒回，只有真正需要本地处理的敏感数据和图片才会走稍慢一点的本地模型，但是数据分析本来也需要事件处理。所以员工基本上察觉不到区别。

七、审计

合规还不止是数据处理，审查还要求对聊天内容做审计，防止机密泄露。

说实话，一开始我觉得这个审计功能就是走个过场，防君子不防小人。

但是有一天我在翻ccswitch的时候顺手点了一下对话历史，然后就看到了有人在拿公司AI写简历？？

还有批卷子？？

于是又在 Openclaw 外面加了一层日志记录，所有对话内容落盘存档，定期审查。

主要是还都是上班时间问的。

当然这是人家的内部管理问题，我不方便多评价。但这个案例确实说明了一件事：企业把 AI 部署进公司之后，用它干什么的都有。你以为他们在分析财务数据，其实可能在写简历。 审计功能不是走过场。

八、现状与反思

目前这套系统稳定跑了两个多月，最终架构大概长这样：

前端交互：Openclaw Agent + 微信接入（员工无感知）
后端模型：DeepSeek-v4-flash 在线 API（主力）+ 本地 vLLM + Qwen3.5 多模态（涉密 / 图片兜底）
数据层：全量对话审计日志，定期拿ai手动跑一遍看看有没有涉密信息
基础设施：那 4 块 V100 终于又用上了，不算白买

但是回头看这条路实在太曲折了：

自研工具 → 无人使用 → Openclaw → DeepSeek 在线 API → 客户满意 → 合规要求 → 本地模型分流 → 审计抓包

每一步都是被客户现实需求一步一步逼出来的。

最后几个不成熟的感悟：

自己写有什么用？拿现成的改改就差不多了。 自研那段让我搞懂了 vLLM、Qwen、Gradio 的方方面面，知识以后还能用。但如果目标是让客户赶紧用起来，选成熟 Agent 框架是唯一正确答案。非必要不造轮子吧
企业 AI 落地最大的敌人不是技术，是合规和领导层的脑子。 这个就不展开细说了，不太好说
审计日志要看，而且要认真看。 你不知道员工在用你的 AI 干什么。可能分析数据，也可能写简历。
混合架构真几把好用啊。 不用非此即彼。在线 API 该用就用，本地模型该兜底就兜底，做好分流就行了。
最重要的是对于老企业的数字化改革，你要把客户当成三岁小孩来看待。