给 Agent 限定业务范围，避免替滥用买单

AI 助手能回答任何问题，对产品未必是好事。一个做饭助手如果愿意替用户写 Python、运行代码、解释结果，就成了由你付费的通用 AI 入口。用户完成了任务，产品没获得价值，账单却照常增加。

原文的主张很直接：先判断请求是否属于产品，再决定是否调用昂贵模型；即使放行，也要限制单次执行的消耗。它没有提供节省成本的实测数据，但给出了一套值得在 AI 功能上线前检查的工程边界。

为什么一句「你是做饭助手」挡不住账单

作者举了一个假设：用户要求做饭助手编写打印 Fibonacci 数列的 Python 脚本，再运行 100 次并解释每次结果。通用模型可能认真完成，过程中消耗推理、输出和工具调用资源，却没有帮助用户做饭。

问题不只在这一次请求有多贵。无关请求每天出现数千次，或者被脚本批量调用，产品就可能变成付费模型的免费代理。额外负载还会拖慢真正需要做饭帮助的用户。

原文引用 OWASP 的 LLM10:2025 Unbounded Consumption，将其中利用按量付费机制推高账单的攻击称为「Denial of Wallet」。这里关心的是资源消耗失控，攻击者未必需要获取数据，也能让服务方承担损失。

为什么开发时容易漏掉？因为演示通常只验证正确用途：食谱能不能查、订单能不能订，很少验证不该做的事。单次请求的成本又不会直接出现在界面上，等月底只剩一张汇总账单，很难知道哪些提示词花掉了钱。

系统提示词可以描述职责，但不能代替程序执行的资源限制。

先做便宜的检查，再让主模型接单

作者建议按成本排列防线，让大部分不合适的请求在调用主模型前结束。

第一层是用户配额。先查请求频率和每日 token 或费用预算，超额就停止。原文称这一步免费，更准确地说，它不消耗模型 token，限流存储和服务仍有基础设施成本。

第二层是输入限制，包括提示词长度和附件大小。作者用「向做饭助手粘贴 50 页内容」举例，强调输入也需要边界。不过，长度只能判断资源规模，无法单独证明请求偏题。

第三层才是主题门禁：用小而快的模型，或者简单分类器，判断请求是否服务于产品用途。不相关就返回固定、友好的回复，主模型无需运行。小模型门禁也有成本，作者没有给出它与主模型调用的具体价格对比。

通过门禁之后，系统提示词继续说明职责和拒绝方式，作为补充防线。同时缩减工具权限：食谱搜索、购物清单符合做饭助手的用途，通用代码执行器和开放网页浏览则需要额外理由。

工具越多，用户越容易把助手带到产品之外。

原文以三个请求只有一个进入主模型作流程示意，不能读成实际节省了三分之二成本。

请求属于业务，也要有执行上限

相关请求同样可能失控。一次备餐规划可以不断搜索、补充条件、重试工具，所以主题门禁之后还要设置硬预算。

原文用下面的代码演示如何限制执行步数、工具调用和耗时，并为模型输出设置上限：

MAX_STEPS, MAX_TOOL_CALLS, MAX_SECONDS = 8, 5, 30

for step in range(MAX_STEPS):
    if tool_calls > MAX_TOOL_CALLS or elapsed() > MAX_SECONDS:
        return "That's more than I can do in one go. Can you narrow it down?"
    result = agent.step(max_output_tokens=800)
    if result.done:
        return result.answer

要仔细看 tool_calls > MAX_TOOL_CALLS 这一行：工具调用达到 5 次时，条件仍不成立。若要严格执行上限，需要在发起下一次工具调用前检查剩余额度。

这段代码表达了预算思路，却不是完整实现。max_output_tokens=800 放在循环内部，不能直接当成整个请求的输出总额度；30 秒的检查发生在 agent.step 之前，也不能保证中断一个已经卡住的调用。工具计数、超时取消和循环耗尽后的返回逻辑，都需要接入实际 Agent 框架。

执行限制之外，还要记录每次请求、每个用户的 token 与费用，设置异常告警，每周查看被拒绝和最昂贵的提示词。只有留下这些记录，团队才知道成本来自正常需求、误用，还是某条反复重试的执行路径。

我的判断

这套建议最有价值的地方，是把「模型应该守规矩」落实成服务端可以检查的条件。与只写系统提示词相比，配额、工具权限和执行上限更容易验证，也更容易追查问题。

但原文属于工程经验建议，没有门禁准确率、攻击测试结果或成本对照，不能据此承诺某个节省比例。是否需要额外的小模型，也取决于请求规模、主模型成本和业务边界；输入很短、用途很窄的功能，简单分类器可能已经够用。

另一个前提是业务范围能被合理定义。「只回答食谱」会误拒绝配酒问题，「帮助用户规划和烹饪餐食」则能容纳预算、采购清单等关联需求。作者建议同时衡量偏题请求漏放和正常请求误拒，这一点比单纯提高拦截率更实用。

边界应围绕用户要完成的目标设计，并同时检查漏放与误拒。

能拿来做什么

• 给现有 AI 功能补一组偏题测试，例如让业务助手写无关代码、重复运行任务，检查它实际调用了哪些工具、消耗了多少资源。
• 在 Node 服务端入口先检查用户频率、每日预算和输入大小，再进入主题判断与主模型调用，避免只靠前端限制输入。
• 为 Agent 同时配置输出、步数、工具次数和超时限制，并核实框架中的参数是约束单步还是整个请求，以及超时能否取消正在执行的调用。
• 每周一起查看被拒绝和最昂贵的请求，把正常需求误拒与偏题请求漏放分别记录，用真实请求调整范围和预算。