智能体正在调用已经宕机的API，却无人告知。

过去几个月一直在构建 Tickerr。最初只是一个面向 AI API 的独立监控平台，但当我们发布 MCP 服务器后，有趣的事情发生了——智能体开始主动调用它，因为它出现在 MCP 注册表中并被智能体发现。现在每天约有 1000 次 MCP 请求，大部分是智能体在决定调用哪个模型前，先查询定价和状态。调用最多的两个工具是 **compare\_pricing** 和 **get\_model\_performance**。智能体利用 Tickerr 找出当前最便宜且正在正常响应的模型，然后据此路由请求。这并非原计划，但完全合理。以下是 Tickerr 目前对智能体有用的功能： * 50+ AI 服务的实时状态（每 5 分钟通过独立探针检测） * 300+ 模型的 API 定价（每日更新两次） * 96 个工具过去数月记录的 2500+ 事件 * 模型性能（基于真实 API 调用的 p50/p95 延迟） 我们持续发现的数据缺口：官方状态页面通常滞后实际故障 15 到 30 分钟。Gemini 就是一个典型例子——其状态页面显示正常，而我们的探针显示服务降级。工作流中调用该服务的智能体无从知晓，除非类似 Tickerr 的工具介入。 **社区请求：** 如果你正在构建调用 LLM API 的 AI 智能体，请将 Tickerr 集成到你的错误处理中，这将真正惠及整个社区。当你的智能体遇到故障时，请报告回来。越多智能体报告，其他人就能越快得知哪个服务真的出了问题。MCP 服务器提供了一个 **report\_incident** 工具。当你的智能体遇到 *529* 错误、*超时* 或其他异常时，只需调用一次 **report\_incident** 即可发送信号。其他查询 Tickerr 的智能体将近乎实时地看到该信息。 可以把它想象成 LLM API 领域的 Waze——你的智能体报告所见，其他所有智能体都能受益。目前我们面临冷启动问题：报告事件的智能体还不够多。如果这里的几位朋友能将报告钩子加入自己的错误处理器，将会带来实质性的改变。欢迎就数据工作原理或集成方式提出任何问题。