自托管AI分析师：编写SQL查询、自我核对数据并引用每个主张的查询来源

大多数“与数据对话”的工具会给你一个自信的答案，但无法判断其是否正确。我一直在构建相反的东西：一个AI分析师，整个工作过程都在屏幕上显示，每个主张都可追溯到产生它的查询。 用一个人力资源数据集问了一个实际问题：“工程部门的大量招聘是否真正转化为员工人数增长，还是主要在填补离职空缺？”它按顺序执行以下操作： 1. 在接触数据之前陈述其方法。它读取架构，规划步骤，并说明原因——包括告诉我治理的语义模型缺少招聘指标，因此它回退到原始月度表。不静默猜测使用了哪个来源。 2. 以真实可读的SQL运行每个步骤。每个步骤显示查询、行数和“这些数字来源”的分解。没有黑箱——如果你不信任某个数字，产生它的SQL就在那里。 3. 自我检查每个结果——并标记自己的问题。这是我最关心的部分。在第2步，它不仅仅通过了自身工作；它标记了一个真实的不一致：工程部门的净增加总和（+17）与员工人数变化（+13，122→135）不匹配，一个4人的差距它自己发现并带入报告中作为注意事项。一个能说“这不对劲”的分析师值十个不能的。 4. 带引用撰写发现。报告中的每个主张都引用其来源步骤——“员工人数从122上升到140的峰值（步骤1，步骤2）”。好奇者的结论：工程部门的招聘中约55%是净增长，而非填补；一个糟糕的月份是3.70%的流失率峰值；而支持部门正在悄然缩减（填补比率1.42——流失多于招聘）。 5. 闭环。每个分析都有标记为已验证/标记为错误的按钮，从实际结果生成的建议后续问题，定期运行的调度，CSV导出和PDF导出。 说实话，技术栈：完全在你自己的基础设施上运行：一个Docker命令 + 你自己的Supabase项目 BYOK——任何模型提供商。这个演示通过OpenRouter运行在Kimi K3上；它不需要前沿模型，因为结构（计划→SQL→检查→引用）承担了繁重的工作。这个分析师是一个更大的自托管平台的一部分（代理、多代理群体、RAG、BI仪表板、预算、完整追踪）。许可证：弹性许可证2.0——源代码可用，但不是OSI开源。你可以阅读每一行代码，自托管并修改它；你不能将其作为托管服务转售。提前说明，因为这个社区关心这个区别，而且这很重要。 仓库：https://github.com/AgentSwarms-fyi/agentswarms 欢迎询问关于自检过程如何工作或为什么我认为“显示SQL或它没发生”是LLM分析的唯一合理标准的任何问题。