BambooAI 数据分析师
在持久 Python 内核中分析数据，并复跑验证报告数字。
按维度查看评分与理由
默认将模型生成代码放入仅绑定本机的 Docker 执行器，应用工作区范围、外部模型提供商、本地模式风险、日志内容及集成数据流均有清楚说明；逐单元检查点和失败回滚证据充分。ASK 动作提供人工确认通道，但普通分析单元会自动执行，远程执行器和 --host 0.0.0.0 也扩大暴露面，因此最小权限、确认和外部影响未给满分。密钥保存在 .env、集成凭据加密，但模型提示和数据可能进入所配置的提供商且详细日志可能含敏感内容，未见完整保留、脱敏或删除策略。依赖大量采用无上限、无锁定版本，CI 未显示漏洞扫描或 SBOM，依赖安全仅属基础水平。作者、许可证、联系渠道和搜索引用机制明确，但发布者身份未经企业注册验证，且部分产品声明仍由项目自身提供。
README、架构说明、测试和 CI 对持久内核、失败回滚、重放、报告数字检查及失败上限形成一致证据，故自洽性和失败反馈充分。测试明确覆盖语法错误、连续失败、错误压缩和强制结束报告。依赖可通过 PyPI、Docker及多种模型提供商获得，也支持 Ollama/vLLM；但多数依赖未锁版本，浏览器端到端和打包测试声明为推送前本地运行而非 CI 强制执行，因此依赖可用性扣分。
目标用户、体育科学和通用表格分析场景、Quick/Deep/Adaptive 模式及技术版/通俗版输出均定义清楚。CELL、SHOW、NAMES、RECALL、SEARCH、ASK、REPORT 的固定动作契约、搜索预算、连续失败上限和 Docker/本地模式差异给出了明确能力边界与触发语义。Python 3.11+、Docker、可迁移工作目录、十种提供商、本地模型及远程执行器配置提供了充分环境适配证据，所列标准在静态材料中无明显缺口。
README 的目录、安装、快速开始、配置、架构、日志、开发及联系信息组织完整；pip、源码和托管安装路径及环境变量说明充分。MIT 文本、包元数据与分类器一致。命名总体稳定，但 1.x 到 2.x 产品形态变化明显，配置示例中还出现 templ_formating 拼写，故命名稳定性未满分。示例丰富但没有真正的 FAQ；限制分散在 Docker、本地模式、搜索密钥和预算说明中，缺少集中且完整的已知限制清单。仅有版本 2.0.0、v1 分支说明和标签发布流程，未提供正式变更日志。作者、邮箱、Issues、Discussions 和发布流程给出维护路径，但未见维护团队、支持承诺或治理说明。
产品输出包括可检查单元、图表、技术报告、通俗改写、引用、重放状态、PDF及逐调用遥测，静态设计对实际使用较完整。相较普通聊天式分析，其持久内核、失败回滚、来源搜索、记忆和新内核重放提供明确增量价值。按模式设置轮次预算，展示令牌、时间和成本，并支持成本预设与全本地零价格模型，成本收益控制证据充分；这些是设计与实现证据评价，不代表本次审查实际运行验证。
主要声明能够追溯到具体模块、契约、工作流和细粒度测试；README、pyproject、CI、发布工作流及测试对安装、隔离、回滚、重放和打包关系形成多源交叉印证。报告契约要求最佳估计、不确定性、成立条件、方法和单元引用，且数字检查会标记无依据值。不过“托管版是同一分析器”“本地测试在每次推送前运行”等仓库外或流程性声明缺乏独立佐证，README 也未始终清楚区分已由 CI 强制验证的事实与项目方陈述，因此事实与推断分离扣分。
- 模型生成的代码仍具有数据处理能力；优先使用默认 Docker 隔离，不要在处理不可信数据时切换到无隔离的 local 模式。
- 配置远程模型或 Gemini 搜索时，数据、提示和搜索内容可能发送到第三方；上传敏感数据前应核对各提供商的数据政策。
- 运行日志记录完整提示、响应和用量，可能包含原始数据或分析细节；应限制日志访问并自行制定保留与安全删除策略。
- 依赖多数未锁定且未见供应链漏洞扫描；生产部署前应生成锁文件、SBOM并执行依赖及容器扫描。
- 若以 0.0.0.0 暴露 Web 应用或使用远程执行器，应额外配置认证、TLS、网络访问控制和执行器隔离。
- 本评估仅依据给定静态文件，未运行应用、测试、容器或重放流程。
这个 Agent 能做什么，适合哪些场景？
BambooAI 是一个面向表格数据分析的 LLM 驱动型分析师，提供本地 Web 应用、命令行入口和托管版本。它把分析组织成持久 Python 内核中的连续单元格，并为每个已提交单元格保留检查点；失败的单元格会回滚。分析结束后，系统会将报告引用的单元格组装成脚本，在新的内核中针对原始数据重新执行，并核对报告数字。默认情况下，模型生成的代码运行在只绑定本机地址的 Docker executor 容器中，也可选择无隔离的本地子进程或自行部署的远程 executor。它支持十种模型提供方、Ollama 和 vLLM，并可保存分析链、数据集记忆、图表、普通读者版本、调用成本与日志。
用户上传 CSV、Parquet、JSON 或 XLSX 主数据集后，系统将其作为 df 载入持久内核，并允许附加多个辅助文件。analyst/session.py 按 analyst/contract.md 驱动逐轮分析：模型可以通过 CELL 执行 Python、SHOW 查看完整历史输出、NAMES 检查变量、RECALL 读取数据集记忆、SEARCH 获取带来源的 Google AI grounding 结果、ASK 请求用户补充信息，最后以 REPORT 结束。每次成功执行的单元格都会建立检查点，失败时恢复此前命名空间；后续问题可以继续使用同一温热内核中的变量。报告需给出最佳估计、不确定性、成立条件、推导方法以及所依赖的单元格和图表，通常使用 Plotly 生成一至三张图。报告完成后，引用单元格会在新内核中针对原始数据重放，数字会与新输出比对，图表从复跑结果中捕获，Rewriter 再生成通俗版本。保存运行时，Knowledge Distiller 会把列含义、注意事项和有效方法写入 memory/<user>/memory_pack.yaml。
- 数据分析师上传业务 CSV 或 Parquet 文件，希望让系统逐步执行 pandas、统计或可视化代码，同时保留全部中间结果以供审查。
- 研究人员需要在发布结论前复跑报告所引用的计算，并明确看到有多少数字能够在全新内核中重现。
- 体育科学从业者分析训练或生理数据，并希望直接从 Intervals.icu、Endura 或 SweatStack 导入指定日期范围的数据。
- 团队希望针对同一数据集提出连续追问，让后续分析沿用上一轮内核中的变量和已完成计算。
- 重视数据边界的组织希望自托管 Web 应用，并将所有模型席位配置到本地 Ollama 或 vLLM，使模型请求不离开机器。
- 需要长程探索的分析人员使用 Adaptive 模式，在较大的轮次预算内定期调用 Reviewer 检查并调整分析方向。
这个 Agent 有哪些优点和局限？
- 报告中的引用计算会在新内核中针对原始数据复跑，并显示成功重现的数字数量，比只保留模型生成结论更便于核验。
- 持久内核支持逐单元格分析和连续追问，同时通过检查点在单元格失败后恢复此前命名空间。
- 默认将模型编写的代码放入 Docker executor，而不是直接以用户账户运行；也支持自行托管 executor。
- 分析师、Reviewer、Rewriter、记忆蒸馏器等席位可以分别选择模型、提供方、推理强度、token 上限和温度。
- 支持 OpenRouter、OpenAI、Anthropic、Google、Groq、Mistral、xAI、DeepSeek、Ollama 和 vLLM，可组成完全本地的模型配置。
- 单元格、输出、图表、每轮提示词、token、耗时和成本均可检查，并支持 PDF 报告导出。
- 默认隔离部署要求 Python 3.11 以上和正在运行的 Docker，首次启动还需花费数分钟构建包含数据科学依赖的镜像。
- 除完全使用本地 Ollama/vLLM 外，用户需要自行提供模型密钥并承担相应调用费用；默认配置可依赖 OpenRouter。
- 带来源的网页搜索依赖 GEMINI_API_KEY 和 Google AI grounding，没有该密钥时 SEARCH 会被关闭。
- 使用 --compute local 虽然不需要 Docker，但代码没有容器隔离，而且 Intervals.icu、Endura、SweatStack 等 executor 取数集成不可用。
- Intervals.icu 和 Endura 需要用户提供 API 凭据，SweatStack 还要求自行注册应用并配置客户端 ID 与密钥。
- 从 BambooAI 1.x 迁移存在版本变化：2.x 取代了原先在 notebook 中使用 from bambooai import BambooAI 的库式接口，旧版仅保留在 v1 分支和 bambooai<2 包中。
如何安装或部署这个 Agent？
推荐安装要求为 Python 3.11 或更高版本，以及正在运行的 Docker Desktop（macOS、Windows）或 Docker Engine（Linux）。执行：
pip install bambooai
bambooai serve首次运行会创建 ~/bambooai、生成 .env、构建 executor 镜像并打开 http://127.0.0.1:5001。随后在 ~/bambooai/.env 中至少配置一个模型来源；仅配置 OPENROUTER_API_KEY 即可使用默认配置中的模型。如需 SEARCH，再配置 GEMINI_API_KEY。重新执行 bambooai serve 即可开始使用。
也可从源码安装：
git clone https://github.com/pgalko/BambooAI.git && cd BambooAI
python3 -m venv .venv && source .venv/bin/activatepip install -e .
bambooai serve不希望本地安装时，可使用 bambooai.org。若明确接受无容器隔离，可运行 bambooai serve --compute local，但该模式不支持需要在 executor 中取数的集成。
如何使用这个 Agent？
启动 bambooai serve，在浏览器中打开本地应用，上传 CSV、Parquet、JSON 或 XLSX 文件并输入问题。根据任务选择 Quick、Deep 或 Adaptive：performance 预设分别提供 4、15、50 个分析轮次，Adaptive 每 8 轮进行一次 Reviewer 自检。在 Models & Compute 中选择 cost、performance 或 max 预设；Usage 页面可查看每次运行的调用、token 和成本。追问会继续使用上一轮的内核状态，而新问题会启动新状态；保存运行可生成以后通过 RECALL 使用的数据集记忆。
无需 Web 应用的单次分析可通过 OpenRouter 运行：
export OPENROUTER_API_KEY=...
python -m analyst.cli --csv data.csv --question "Is there a trend in weekly load?" --preset deep --model x-ai/grok-4.6 --effort high本地模型示例是在 LLM_CONFIG_template.json 中把席位 provider 设为 ollama，并在 .env 中设置 REMOTE_OLLAMA=http://localhost:11434；vLLM 通过 REMOTE_VLLM 配置。
这个 Agent 与同类方案有什么区别？
本地默认模式把分析内核、复跑和集成取数放在 Docker executor 中，提供隔离；--compute local 改为 Web 应用的子进程，免除 Docker，但失去隔离和数据集成。自行部署 executor 可通过 EXECUTION_MODE=api 与 EXECUTOR_API_BASE_URL 连接本机或其他机器。bambooai.org 提供相同分析师的免安装托管版本。与 1.x 的 notebook 库式用法相比，2.x 采用 Web 应用、持久内核和 executor 架构；需要旧接口的用户必须安装 bambooai<2。