Agent 应用最怕“演示很好，上线就飘”。本地试十次都对，真实用户换个问法就错；工具调用在测试里正常，生产里突然走偏；你知道它失败了，却不知道失败发生在哪一步。
Future AGI 想做的是一条完整质量闭环：评测、追踪、模拟、数据集、网关、防护都放在一个平台里。它不是单点 eval 工具，而是更像 Agent 应用的质量工作台。
本地先起平台，再接一个小 Agent
项目还处在早期阶段，适合先用非生产服务试跑。自托管路径可以用 Docker Compose 起环境。
git clone https://github.com/future-agi/future-agi.git
cd future-agi
cp futureagi/.env.example futureagi/.env
docker compose up -d然后选一个最小 Agent 接入：比如一个 RAG 问答、一个客服路由、一个代码审查摘要。不要一开始就接全量业务。质量平台最重要的是建立基线，而不是把所有链路一次性迁进去。
三类数据先准备好
要让 Future AGI 这类平台发挥作用，先准备三类数据：
1. Golden set：标准问题、期望答案、禁止回答边界
2. Trace sample：真实调用链路，包含工具调用和失败案例
3. Simulation cases：恶意输入、边界输入、长上下文输入、格式破坏输入没有这些数据，平台只会变成漂亮仪表盘。有了这些数据，你才能回答：新版 prompt 是否退步？换模型后工具调用是否更稳定？guardrail 是否误伤正常用户？上线前是否能拦住高风险输出？
评测不要只看一个分数
Agent 质量不能只用“准确率”概括。更有用的指标包括：工具调用是否选对、是否遵守权限、回答是否可追溯、失败时是否安全退出、是否出现幻觉引用、成本是否超预算。
Future AGI 把 evals、tracing、gateway 和 guardrails 放在一起，意义就在于能把问题连起来看。一次错误回答，可能不是模型差，而是检索差；一次工具误调，可能不是工具问题，而是路由 prompt 太松；一次成本飙升，可能是重试策略没上限。
这类平台适合在 Agent 从 demo 走向生产前接入。别等用户已经开始报错，再补评测。更稳的节奏是：先建 baseline，再接 trace，再上 guardrail，最后把关键 eval 放进 CI。Agent 应用要上线，质量闭环得先上线。