Future AGI：把 trace、eval、guardrail 收进一个自托管栈
Open-source, end-to-end platform for evaluating, observing, and improving LLM and AI agent applications. Tracing · Evals · Simulations · Datasets · Gateway · Guardrails. Self-hostable. Apache 2.0.
秒懂
- 它是什么？
- Future AGI 是一个 Apache-2.0 的 LLM 与 Agent 平台，覆盖 tracing、评估、模拟、数据集、网关和护栏。它试图解决的是评估与可观测性各用一套工具、反馈回路断掉的问题。本文只依据仓库 README 与发布信息，说明它的机制、落地命令和边界。
- 适合谁用？
- 已经在生产环境跑 Agent、并且明确需要把 trace 数据留在自己机房或自己 VPC 的团队，可以从自托管路径开始试：先确认 ./bin/install 能在目标机器上把整套服务拉起来，再确认 fi_instrumentation 的 register 与具体框架 instrumentor 能覆盖你当前用的 SDK。只需要单点评估、不打算维护一套 Docker Compose 栈的团队不该选它，直接用 ai-evaluation 这个 PyPI 包更省事。
- 能商用吗？
- 可以。Apache-2.0 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Python（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它针对的不是模型质量，而是反馈回路断裂
README 开篇给出的判断是：多数 Agent 在生产环境失效，而团队往往把评估、可观测性和护栏分别接在三套工具上，回路始终合不上。Future AGI 的定位就是把这几个环节压进同一个平台，README 里的原话是 simulate → evaluate → protect → monitor → optimize，数据以回路形式回流。
目标用户因此比较明确：已经在跑线上 Agent、手里有真实流量和真实失败案例的团队。如果你的项目还停在提示词调试阶段，这套东西的多数模块用不上。仓库把 tracing、评估、模拟、数据集、网关、护栏六个能力并列，本身就说明它假设你已经有一个持续产生 trace 的系统。
另一个前提是自托管意愿。README 把 Apache 2.0 核心与「每个 evaluator、每条 prompt、每条 trace 都可检查」放在一起讲，明确反对黑盒打分。这句话对采购流程长的团队是卖点，对只想调 API 的团队是负担。
六个模块如何串成一条数据流
从 README 能确认的机制有两条。第一条是接入层：Python 侧通过 fi_instrumentation 的 register 注册项目，再用具体框架的 instrumentor 挂钩，README 给的例子是 traceai_openai 里的 OpenAIInstrumentor。注册之后，原本调用 OpenAI 的代码不改，请求就进入 trace。这说明它的采集是基于 OpenTelemetry 的 instrumentation 模式，而不是要求你改写业务调用。
第二条是网关层。README 说明 gateway 用 Go 编写，带加权路由，并给出了一组数字：约 9.9 ns 的加权路由、t3.xlarge 上约 29k req/s、开启护栏时 P99 不超过 21 ms。这些数字来自仓库自带的 benchmark harness，README 声称可复现。需要说清楚的是，这是项目方自己提交的基准，不是第三方结果，实际数值取决于你的模型后端和护栏规则复杂度。
模块之间的连接方式，README 只描述了回路这个概念，没有展开内部存储或消息格式。哪一部分数据在 trace 之后进入评估、评估结果如何回到优化环节，从现有材料看不出来。这一点在选型时值得单独确认。
自托管的实际命令与它不做什么
README 给出两条路径。云端最快，pip install ai-evaluation 之后配合 app.futureagi.com 的免费账号即可。自托管需要先装好 Docker Desktop 或 Docker Engine 加 Docker Compose，然后：
git clone https://github.com/future-agi/future-agi.git cd future-agi ./bin/install
Windows 用 .\bin\install.ps1。安装脚本拉的是已发布镜像，不在本地构建源码，装完访问 localhost:3000。README 明确提醒，生产环境应改用 ./deploy/setup.sh，它的作用是生成必需的密钥并固定镜像版本。这一步不能省，否则版本会随镜像标签漂移。
注意 README 顶部那条警告：当前是 nightly release，供早期测试，作者自己写了 expect rough edges，稳定版尚未发布。这意味着接口和安装脚本在版本之间可能变动。v1.37.1 与 v1.37.0 相隔不到一天，发布节奏很密，跟进成本要算进去。
升级时那个容易被忽略的回填步骤
README 里有一段关于升级的说明，容易被跳过但影响很大：如果已有 trace 的安装要升级，在新栈健康之后需要显式初始化未激活的统一属性目录。命令是 ./bin/property-catalog-backfill --execute，Windows 用 .\bin\property-catalog-backfill.ps1 -Execute。
它的行为边界 README 写得很细。普通重启不会触发历史扫描，只有这条命令会。它使用 Docker Compose 已经选定的镜像，不拉分支、不拉源码、不拉新镜像。已经激活的工作区会被跳过，进度记录在目录自己的持久 ledger 里，可以断点续跑。
限制同样明确：扫描范围限定在自托管 supervisor 允许的活跃工作区和项目内，源数据窗口是滚动的 366 天。也就是说，超过一年的历史 trace 不会被纳入这次回填，被停用或不在 supervisor 准入范围内的工作区也一样。如果你依赖跨年度的对比评估，升级前要先确认这部分数据是否需要另行保留。
什么时候它反而是错的工具
最直接的反例是只需要单点评估的场景。如果你只是想给一批输出打个分，pip install ai-evaluation 就够了，没必要为了评估去维护一整套 Docker Compose 服务、属性目录和 supervisor。README 把云路径和自托管路径并列，本身就承认了这种分层。
第二个反例是团队没有运维容器栈的能力。自托管路径要求 Docker Compose 前置就绪，升级涉及镜像版本固定和属性目录回填，日常还有 supervisor 的准入范围要维护。这些都不是装完就忘的东西。
第三个是合规口径。README 在云端一栏写了 SOC 2 Type II 和 HIPAA，但那是托管服务的资质，不是这个 Apache-2.0 仓库的属性。自托管意味着这些合规责任回到你自己身上，README 里那句 data stays in your region 描述的是云端选项。把两者混为一谈是选型时常见的误读。
与 Langfuse 这类纯可观测性工具的差别
README 自己点名了一组被替代的组合：Langfuse、Braintrust、Helicone、Guardrails AI，外加一个自建模拟器。差异不在单个功能强弱，而在数据是否闭环。以 Langfuse 为代表的工具主要解决 trace 的采集、存储和查看，评估通常作为附加能力或需要外部脚本接入，护栏和路由网关则在它的职责之外。
Future AGI 的做法是把网关也纳入自己的范围，护栏直接挂在网关的请求路径上，这也是它敢给出「开启护栏时 P99 ≤ 21 ms」这个指标的原因：护栏不是事后批处理，而是在转发链路上执行。代价是流量必须经过它的 Go 网关，而不是只在 SDK 侧埋点。
这个取舍对架构有实际影响。走网关意味着多一跳，也意味着路由和限流策略要在 Future AGI 里配置；只埋点的方案则对现有网络拓扑零改动。README 提到可以通过 OTel 和 OpenAI 兼容的 HTTP 接口在任意一层替换成自己的组件，但具体怎么替换、替换后哪些能力会失效，材料里没有展开。
发布节奏、许可与跟进成本
许可为 Apache-2.0，核心可自托管、可审计，这是 README 反复强调的一点。需要注意仓库同时存在云端托管服务，README 里的 SOC 2 Type II、HIPAA、区域数据驻留这些描述指向的是托管产品，不随仓库代码一起授予。商用前应自行确认哪些组件属于仓库、哪些属于服务。
维护成本主要来自三处。一是发布频率，v1.36.1、v1.37.0、v1.37.1 集中在 2026 年 9 月 8 日到 9 日之间，跟进意味着持续关注变更。二是升级流程有显式步骤，属性目录回填不是可选项。三是 README 顶部标注 nightly，作者自己预期会有粗糙之处，并要求遇到问题开 issue。
因此合理的做法是先在非关键环境跑通 ./bin/install 和一次属性目录回填，确认升级路径可重复，再决定是否接入线上流量。这比直接在生产机上试要稳妥。
编辑结论
已经在生产环境跑 Agent、并且明确需要把 trace 数据留在自己机房或自己 VPC 的团队，可以从自托管路径开始试：先确认 ./bin/install 能在目标机器上把整套服务拉起来，再确认 fi_instrumentation 的 register 与具体框架 instrumentor 能覆盖你当前用的 SDK。只需要单点评估、不打算维护一套 Docker Compose 栈的团队不该选它，直接用 ai-evaluation 这个 PyPI 包更省事。动手前先验证两件事：一是 ./deploy/setup.sh 生成密钥后镜像版本能否固定，二是你现有 trace 量级下 ./bin/property-catalog-backfill --execute 的 366 天窗口和活跃工作区范围会不会漏掉历史数据。这两点决定它能不能长期留在你的基础设施里。
社区笔记