限制入口请求，仍挡不住 Agent 成本失控

给 AI 应用的入口加上限流，并不能保证账单可控。用户点一次「研究这个话题」，后台可能连续搜索、读网页、调用模型，还会重试失败的工具。入口只记下一次请求，实际付费操作却在不断增加。

作者的核心主张是：把控制单位从「请求」扩展到「完整任务」，为调用次数、执行时间、费用和取消行为设置可执行的边界。这篇没有提供实测收益，但它列出的检查项，很适合用来审视带有自主循环和后台任务的 AI 功能。

一次点击之后，到底产生了多少工作

研究任务可能先调用模型制定计划，再多次分析搜索结果，最后生成答案。这是作者构造的示例流程，并非某个产品的运行数据。它说明了一个问题：用户操作次数与计费操作次数并不相等。

所以，统计不能停在 HTTP 请求结束的位置。重试、队列和后台执行都要归入同一个任务，否则你看到的可能只是「用户请求成功」，看不到后续工作仍在消耗资源。

作者给出的任务记录字段，可以直接作为埋点清单：

task_id
account_id
model_calls
tool_calls
input_tokens
output_tokens
elapsed_time
estimated_cost
stop_reason

要留意 stop_reason：除了知道花了多少，还要知道为什么结束。正常完成、预算耗尽和用户取消，对排查问题的价值完全不同。常规日志也应避开敏感文档正文和凭据。

入口限流控制请求进入的频率，任务预算控制进入之后还能做多少事。

两者解决的是不同环节的问题，需要一起使用。

预算怎样才能真正拦住下一次调用

作者用下面的配置展示任务预算：

const limits = {
  maxModelCalls: 8,
  maxToolCalls: 15,
  maxDurationMs: 90_000,
  maxEstimatedCostUsd: 0.30,
};

关键是 maxEstimatedCostUsd 中的 Estimated：这是估算费用。8 次模型调用、15 次工具调用、90_000 毫秒和 0.30 美元都是示例，作者明确没有把它们当作推荐默认值。

预算需要由应用代码检查。提示词里写「别花太多钱」，无法替代每次操作开始前的判断。

这里还有一道容易漏掉的工序：调用尚未结束时，最终费用通常还不知道。作者建议先根据输入大小、输出上限和适用价格预留一笔保守额度，结束后再用返回的用量核对。付费搜索和其他收费工具也要算进去。

如果多个 worker 共用预算，预留必须具有原子性，也就是「检查余额并扣留额度」要作为一个不可被并发插队的操作完成。否则，几个 worker 都看到同一笔余额，各自判断足够，合起来就超支了。原文提出了这个要求，但没有给出具体存储方案或实现代码。

重试同样要受两层约束：单次操作最多尝试多少次，整个任务最多消耗多少资源。只限制工具自己的重试次数，仍可能被模型重新选择同一个工具绕过去。反复抓取同一网页、重复失败查询，也应该触发停止或澄清。

关掉页面以后，后台还会继续花钱吗

用户关闭标签页，并不代表后端研究任务已经停止。队列里的作业和正在工作的 worker，都需要收到取消信号，并在下一次模型或工具调用之前检查状态。

对于已经发出的操作，可以在服务支持时尝试取消，但已经完成的工作仍可能计费。因此，取消功能最基本的验收标准，是尽快阻止后续工作继续启动。

体积限制也不能省。一句短问题和一份巨大文档，在请求计数里都只占一次，资源需求却差很多。作者明确提到了提取后的文档长度；虽然该节标题同时涉及输入和输出，正文没有给出完整的限制项目或具体阈值。超限时，应向用户解释支持范围，而不是让人等待很久后只看到失败。

任务之外还要有账号和应用层面的限制。单个任务有上限，用户同时启动大量任务，累计开销仍会放大。作者提到并发任务限制和应用整体支出控制，也提醒核实供应商的「预算」究竟会阻断调用，还是只发告警。

到达上限后，结果也要诚实。作者举例：已经查看六个来源，就返回已有发现及尚未解决的问题，明确说明研究额度已用完；产品支持的话，再提供显式继续执行的入口。

我的判断

我认同把完整任务作为计量和控制单位。对于会自主调用工具的功能，仅靠入口限流，很难回答「这一次操作最多能花多少」；仅靠供应商告警，也无法保证应用及时停止后续工作。

不过，这是一份工程检查清单，缺少成本下降、答案质量变化和误停率的对照数据。预算设得多紧才合适，仍属于需要团队自行验证的经验问题。示例中的 0.30 美元不能直接照搬。

它也有实现前提：任务状态必须能跨队列和 worker 传递，收费操作必须经过预算检查，取消信号必须被执行端处理。原文没有展开这些环节的实现与故障恢复方式。对于只做一次模型调用的简单功能，可以先落实输入、输出和账号额度；引入自主循环后，再补齐共享预算、重复动作检测和取消传播。

能拿来做什么

• 给 Node 后端的 AI 任务分配统一的 task_id，把模型、工具、重试及后台作业的用量汇总到同一条任务记录，先量清一次点击的实际开销。
• 在研究助手的模型和工具调用入口检查剩余预算；存在并行 worker 时，把额度预留做成原子操作，并在调用结束后核对实际用量。
• 联调前端取消按钮与后台队列，验证取消后不会启动下一次调用；同时测试工具连续失败、重复动作、大文档、多个任务同时启动及账号额度耗尽。
• 为预算耗尽设计明确的结果状态，展示已完成的工作和遗留问题，让用户知道当前答案的完成范围。