DecisionBox
让 AI 自主查询数据仓库、验证结论并输出可执行建议。
- Star 数
- ★ 122
- 最近更新
- 1 天前
- License
- AGPL-3.0
- 主语言
- Go
- FA 评分
- 44/100 · 缺口较多
30 秒速览
- 运行形态
- 可在哪里用
- 通用 · 跨平台OpenAI API · Claude API
- 费用
- 软件免费，模型调用费用自付
- 上手难度
- 中 · 需要几步配置
- 开始前需要
- 典型场景
- 电商数据团队希望在无人值守时检查转化漏斗、复购和利润相关异常，并获得经过 SQL 复核的行动建议。
- 不适合
- 只想用托管 SaaS、不愿自建 MongoDB 与 Qdrant 的团队
- 使用 BigQuery、Redshift、Snowflake、PostgreSQL、Databricks、SQL Server 之外数仓的团队
这个 Agent 能做什么，适合哪些场景？
DecisionBox 是一个可自托管的数据发现平台，由 Go 编写的 Agent 与 API，以及 Next.js 仪表盘组成。它连接 BigQuery、Redshift、Snowflake、PostgreSQL、Databricks 或 Microsoft SQL Server 后，让 Agent 自行决定分析方向、生成并执行 SQL。发现结果会经独立验证查询复核，再以带置信度和严重级别的洞察及排序建议呈现。仪表盘还提供实时执行进度、SQL 与推理过程查看、语义搜索和带引用的 Ask Insights 问答。它可通过 Docker Compose、Helm 或面向 GCP、AWS、Azure 的 Terraform 部署，适合希望把数据探索运行在自身基础设施中的团队。
用户先为项目配置数据仓库、领域包、LLM Provider 与凭据。Agent 在 discovery run 中探索仓库 schema，生成并执行 SQL，依据结果继续迭代，并为每项发现运行独立 verification query；随后生成洞察、置信度、严重级别和按优先级排序的 recommendation。结果被写入 MongoDB，并由 Qdrant 的 HNSW 向量搜索支持跨项目 semantic search、相关内容匹配和 Ask Insights 的 RAG 问答。LLM 扩展实现 llm.Provider 的 Chat 方法，仓库扩展实现 warehouse.Provider；部署者还可通过 warehouse.RegisterMiddleware()、apiserver.RegisterGlobalMiddleware()、apiserver.Run() 或 agentserver.Run() 接入自定义中间件与构建。
- 电商数据团队希望在无人值守时检查转化漏斗、复购和利润相关异常，并获得经过 SQL 复核的行动建议。
- SaaS 分析负责人已将产品事件和订阅数据放在 PostgreSQL、BigQuery 或 Snowflake 中，希望自动发现激活与流失信号。
- 游戏运营团队需要围绕 match-3、idle/incremental 或 casual/hyper-casual 领域包分析关卡失败、留存和付费表现。
- 使用 Redshift、Databricks 或 SQL Server 的企业，希望向业务人员提供可追溯的洞察阅读界面、搜索和带引用问答。
- 平台工程团队希望在 Kubernetes 上部署数据分析服务，并使用 Terraform 为 GKE、EKS 或 AKS 配置基础设施。
如何安装或部署这个 Agent？
前提：安装 Docker 与 Docker Compose，并准备受支持数据仓库的连接信息和 LLM API 密钥。执行：
git clone https://github.com/decisionbox-io/decisionbox-platform.git
cd decisionbox-platform
docker compose up -d然后打开 http://localhost:3000。该命令启动 MongoDB、Qdrant、API 和 Dashboard。开发模式可先执行 docker compose up -d mongodb qdrant，再分别运行 make dev-api 与 make dev-dashboard。
如何使用这个 Agent？
在 http://localhost:3000 创建项目，配置数据仓库连接、领域包、项目资料和 LLM Provider。启动 discovery run 后，Agent 会自动探索数据并执行 SQL；在仪表盘中查看实时阶段、步骤和可展开的 SQL。完成后审阅按严重级别和置信度排列的洞察与建议，可对结果点赞或点踩、保存到 bookmark list，并通过 Ask Insights 在已有发现中进行带引用的多轮问答。可在运行前使用成本估算功能评估 LLM token 与仓库查询成本。
这个 Agent 有哪些优点和局限？
- 不是要求用户提问的 SQL Copilot：discovery run 会由 Agent 自主选择调查方向，并可执行 50–100+ 条 SQL 查询。
- 每项发现通过独立 verification query 再次查询数据仓库，且 SQL、推理步骤和决策可在界面中审计。
- 覆盖六类已列明的数据仓库，并支持 Claude、OpenAI、Ollama、Vertex AI、Bedrock 和 Azure AI Foundry 等多种 LLM 路径。
- 领域包可在仪表盘中创建、编辑、导入和导出，无需修改核心代码；内置电商、社交和游戏包。
- 提供 Docker Compose、Helm、多架构镜像以及 GCP、AWS、Azure 的 Terraform 部署选项。
- 首次使用必须同时具备可连接的数据仓库和 LLM Provider 凭据；没有两者无法完成 discovery。
- 系统会实际对仓库执行 SQL，运行成本取决于 LLM token 与仓库查询，虽提供运行前估算但并非零成本。
- 可用仓库范围目前限于 BigQuery、Redshift、Snowflake、PostgreSQL、Databricks 和 Microsoft SQL Server；其他仓库需要自行实现 warehouse.Provider。
- 生产部署需要运营 MongoDB、Qdrant，以及 Docker、Kubernetes 或云端 Terraform 相关组件。
- 许可证为 AGPL-3.0，采用或分发时需要自行评估其许可证义务。
这个 Agent 与同类方案有什么区别？
与相关度最高的同类 agent 并排比较关键指标。
| Agent | 源码审查 | 形态 / 费用 | Star | 最近更新 | 主语言 | 完整支持的平台 |
|---|---|---|---|---|---|---|
| DecisionBox 当前 | 44 · 缺口较多 | 自托管服务免费 + 模型费 | ★ 122 | 1 天前 | Go | OpenAI API · Claude API |
| Astronomer Agents：Airflow 数据工程 AI 工具集 | 46 · 缺口较多 | Agent 插件 / 技能免费 + 模型费 | ★ 458 | 7 天前 | Python | Claude Code |
| DDC CWICR 建筑工程量造价库 | 41 · 缺口较多 | 自托管服务免费 + 模型费 | ★ 273 | 2 个月前 | HTML | OpenAI API |
| Dex 数据工程工具箱 | 84 · 表现良好 | Agent 插件 / 技能免费 | ★ 113 | 今天 | Python | Codex · Claude Code |
FollowAgents 如何评估这个 Agent？
查看各维度的扣分理由
证据显示有只读强制、秘密加密、非root容器等安全措施，但缺少用户确认机制和回滚功能。数据流透明度有日志记录，但未提供具体实现细节。依赖安全有license检查，但未提供漏洞扫描证据。外部影响有成本估算和通知，但未明确限制。来源归属有CLA和贡献指南，但发布者未验证。
自一致性较好，README与CI配置一致，但依赖可用性未提供版本锁定或镜像摘要。失败消息有超时和重试，但未提供用户友好的错误提示。
受众明确为数据驱动团队，场景覆盖多个行业。能力边界有插件架构和中间件，但未明确限制。触发精度有选择性发现，但未详细说明。环境适配支持多种部署方式，但未提供详细配置。
信息架构清晰，有README、文档链接、目录结构。安装说明有Docker Compose和Helm。命名稳定性未提供API版本策略。示例和FAQ有使用案例，但无FAQ。已知限制未明确列出。许可证为AGPL-3.0，但未提供版权信息。版本变更日志有CHANGELOG.md，但未提供内容。维护责任有贡献指南和CLA，但未明确维护者。
输出可用性有洞察和推荐，但未提供格式细节。边际价值有自主发现和验证，但未提供对比。成本效益有成本估算，但未提供实际数据。
声明可追溯性有文档和代码，但未提供具体实现。跨来源佐证有CI和测试，但未提供独立验证。事实与推断分离未明确。
- 源码中未见：执行前用户确认开启或自行加上执行前确认；先在沙箱或测试环境跑通，确认行为后再接入真实数据。
- 源码中未见：回滚或恢复路径运行前先备份，或在 git 分支、快照上操作，确保改动可以撤销。
- 发布者身份未验证，需谨慎评估供应链风险。
- 缺少用户确认机制，自主执行SQL可能带来风险。
- 依赖安全仅检查许可证，未提供漏洞扫描证据。
- 回滚功能缺失，需自行备份。
最近版本
来自该项目 GitHub Releases 的最新发布记录，说明为上游原文摘录，未经本站改写或测试。
-
发布说明摘录
Each layer's output ceiling comes from its own model Two fixes. Output ceilings and reasoning effort (#504) Per-layer models let every layer run a different model — but the output ceiling was still derived from a shared default rather than from the model actually assigned to that layer. A layer pointed at a model with a smaller ceiling could be asked for more than it could return; one pointed at a larger model was capped below what it could do. …在 GitHub 查看 ↗ -
发布说明摘录
Per-layer models now reach the projects you already had v0.37.0 gave every LLM layer its own provider and model — but only for projects written after that release. managedai.Apply stamps llm_providers, layer_models and llm_config_version on a project write. A project last written before v0.37.0 has none of them, so the layer resolver falls back to the default row and every layer quietly runs the single legacy model. …在 GitHub 查看 ↗ -
发布说明摘录
A provider and a model for every LLM layer A project is no longer limited to one LLM provider and one model. It can hold multiple provider entries, and choose a provider and model per layer — with per-layer reasoning, prompt-cache and output-cap settings. Every layer that calls an LLM resolves its own: exploration, analysis, recommendations, reflection, schema blurbs, questions, verification and refutation, Ask and its router and suggestions, and the rest. Why it matters …在 GitHub 查看 ↗