让 Agent 每次发布都可比较：Apgar 如何从生产追踪发现行为退化
传统服务上线后，团队会观察错误率、延迟和可用性；Agent 却可能没有宕机，只是工具错误变多、重试或循环增加、回答变短，或者成本上升。只看 HTTP 200 很难察觉这种变化。Apgar 是一个面向 Agent 发布健康度的开源项目：它从已有生产追踪中建立版本基线，再观察新版本的运行信号。它不使用 LLM 裁判、不要求人工标注数据集，也不保存 prompt 或 completion 正文。
这并不等于它能判定回答是否正确。若模型输出了错误事实，但工具错误率、调用数量、成本和延迟都没有明显变化，行为指标可能不会报警。Apgar 应当作为发布后异常监测的一层，不能替代离线评测、人工抽检和安全测试。
它关注运行信号，而不是答案评分
项目 README 列出的比较信号包括工具错误、重试与循环、工具调用数、回答长度、成本和延迟。数据可通过 OpenTelemetry traces 接入，也可从 Langfuse 导入；部署时给每次发布标记 release 属性，Apgar 再按版本比较生产流量。发现变化后，它可通过 Slack 或 webhook 通知团队，并指出变化较明显的信号。
这里的关键不是多加一套模型评分，而是让追踪数据能区分发布批次。若服务没有统一的版本标识，或新旧版本接收的请求类型差异很大，比较结果就难以解释。因此先把 release 标注和追踪覆盖做好，再讨论告警阈值。
用 Docker Compose 快速启动
Apgar README 给出的 Compose 起步方式如下。首次启动前按官方自托管文档准备 .env 中的密钥，不要将密钥提交到版本库：
mkdir apgar && cd apgar curl -fsSLO https://github.com/oimo-ai/apgar/releases/latest/download/docker-compose.yml curl -fsSLo .env.example https://raw.githubusercontent.com/oimo-ai/apgar/main/.env.example cp .env.example .env # 编辑 .env，为三个密钥字段填入独立随机值 docker compose up -d --wait
启动后访问 http://localhost:8080，使用 .env 中 APGAR_ADMIN_TOKEN 的值登录。Compose 需要 Docker Compose v2。README 也提到可用 Helm 部署到 Kubernetes；升级前应阅读对应文档并备份 ClickHouse。不同部署方式的密钥、持久化和升级细节应以项目自托管文档为准，不要照搬未经确认的示例配置。
把版本标签接进追踪
接入前先确认 Agent 的 trace 能到达 Apgar 支持的数据源，并且每次部署都带有稳定的 release 属性。比如可按团队现有约定使用 agent.release 一类字段，但字段名称必须以实际接入文档和配置为准；不要把示意名当作 Apgar 强制规定的键。
可先在测试环境做一次端到端检查：发出带版本标记的 trace，在 Apgar 中确认其归属，然后部署下一版本验证比较是否出现。逐步观察工具错误、重试、时延和成本等信号，再决定哪些变化值得通知值班人员。样本量太小、流量结构变化或下游依赖故障，都可能造成指标波动；出现告警时要结合发布记录和业务上下文复核，而不是自动回滚。
适用边界
Apgar 适合已经收集 OpenTelemetry 或 Langfuse 追踪、并希望比较 Agent 发布表现的团队。它提供的是运行行为的变化信号，不会检查未进入追踪系统的调用，也不会验证回答内容的语义真伪。对高风险 Agent，仍要单独配置最小权限、提示注入防护、评测和人工审批。
一个务实的落地顺序是：先接通 traces，再统一 release 标签，观察几次发布后建立基线，最后才将稳定的信号纳入告警流程。把“服务运行正常”和“Agent 输出正确”作为两项不同的验收目标，才能避免仪表盘平静带来的虚假安全感。
相关链接