AI Agent成本控制：阈值守卫优于告警后置

一次 OpenAI 的更新引起了我的注意——不是因为模型本身，而是因为它背后的控制架构。

据 OpenAI 介绍，Astra 部分开发曾在内部评估触发 Preparedness Framework 预定义阈值后被暂停。

这里重要的工程模式不是安全策略本身。

而是跨越阈值触发了自动响应。

无需任何人先盯上仪表盘。

这个区别远超 AI 安全领域。

监控告诉你发生了什么

大多数 AI 成本系统大致是这样的：

const response = await callProvider(...);

const cost = calculateCost(response);

session.spent += cost;

if (session.spent > session.limit) {
  notifySlack();
}

你可以精确知道预算何时被超支。

问题显而易见：

昂贵的请求已经发生了。

对于交互式应用，这通常是可以接受的。

对于通宵运行的自主 Agent，通常不是。

控制发生在请求之前

运行时守卫的工作方式不同。

它不是对已完成的请求做出反应，而是评估下一个请求。

const estimatedCost = estimateCost(request);

if (session.spent + estimatedCost > session.limit) {
  throw new BudgetExceededError();
}

await callProvider(...);

关键区别不在于计算本身。

而在于计算何时发生。

一种架构是观察。

另一种是预防。

阈值可以触发不同的行为

拦截不是唯一可能的响应。

生产系统可以定义多个阈值，每个阈值有预定义的行为：

这样就产生了确定性行为，而不是依赖人工干预。

系统在阈值达到之前就已经知道该做什么。

为什么这对于 Agent 很重要

传统聊天应用天然包含人工反馈循环。

编码 Agent、研究工作流或 CI 自动化可能在无人值守的情况下执行数百个请求。

在这些系统中，在支出已经发生后才到达的告警对报告有用——但无法防止额外支出。

这就是为什么自主系统受益于运行时护栏，而不是单纯的监控。

监控和控制解决不同的问题

这不是反对仪表盘、遥测或告警的论点。

这些仍然不可或缺。

但它们回答的是不同的问题。

监控回答的是：发生了什么？

运行时控制问的是：下一个请求应该被允许吗？

这些是互补的系统——不是可互换的。

随着更多软件变得由 Agent 驱动，我预计这个区别会变得越来越重要。最有效的成本控制架构不会简单地报告阈值跨越——它们会提前定义系统在达到这些阈值时的确切响应方式。

https://github.com/salimassili62-afk/ai-costguard