用 TypeScript 与 MCP 搭建销售分析助手
教程以 TypeScript、SQLite 和本地 MCP 服务构建销售分析工具,先明确日期、取消订单和销量口径,再让 Agent 调用结果。配套项目含合成数据、自动化测试和可复现演示,本地运行无需 API 密钥,未声称验证了在线模型效果。
原文暂未完整获取,基于公开信息的快读
一篇 dev.to 教程用 TypeScript、SQLite 和本地 MCP 服务搭建销售分析助手,并提供合成数据、自动化测试和可复现演示。它的重点是先把统计口径写进代码,再让 Agent 调用工具、解释结果。本地演示无需 API 密钥,但作者没有声称验证了在线模型的效果。
目前能确认什么
这个系统把分析逻辑和模型职责分开:服务端实现固定查询、绑定参数,以只读连接访问 SQLite;Agent 只能选择已提供的操作,没有直接执行 SQL 的工具。
教程里的销售额有明确边界:只计算订单快照状态为 delivered 的商品金额,取消和退货订单全部排除,按下单日期归属。它不代表实收款或利润,也没有覆盖税费、运费和折扣。
日期处理同样进入了代码约束。查询区间采用左闭右开,比较窗口必须等长;数据覆盖范围内的空白日期可以返回零,超出覆盖范围则报错。没有数据,不能直接解释成没有销量。
MCP 在这里通过本地 stdio 通信:Agent 宿主启动子进程,通过标准输入输出交换消息。在线运行时,问题和聚合结果会发送给 DEVUP AI API,数据库文件留在本机。本地运行不等于所有信息都留在本地。
我的判断
对程序员来说,最值得复用的是分析层与 MCP 工具的拆分方式。把日期、金额和订单状态规则固定下来,才能用同一份数据检验统计结果;模型负责选择操作和组织语言,统计正确性则由代码承担。
这也给接业务系统划出了一条具体边界:部分退款、多币种或状态变化,首先需要补充数据结构和指标定义,不能只靠修改提示词。
当前演示能证明本地服务确实执行了 SQL 聚合,但不能证明模型能稳定选对工具、理解模糊提问或准确解释结果。这些仍需在线调用验证。四个工具的完整定义及返回结构,现有节选也没有展示清楚。