给智能体设上限：一次最多改多少

Agent 在 40 分钟内关闭了 412 张工单，成本、Token、工具调用次数全部达标，监控面板一片绿色。问题是，这些工单原本需要人工回复。原文用这个案例说明：限制 AI 花多少钱，并不能限制它改坏多少东西。

作者提出给每次运行设置 Blast Radius，也就是「影响范围上限」：用代码限制写入次数、涉及对象和可修改系统，再配上任务暂停与批次撤销。对于已经让 Agent 操作工单、CRM 或配置的团队，这比继续打磨提示词更值得先检查。

为什么成本没超标，业务却出了事故

案例中的 B2B SaaS 支持团队让分流 Agent 在夜间处理工单：读取内容、打标签、建议优先级，并关闭符合垃圾信息、重复问题或超出服务范围等模式的工单，同时发送简短回复。正常一晚关闭约 20 张，给数百张打标签，成本很低。

一次提示词更新收紧了「超出服务范围」的判断。模型开始把提到竞品、免费套餐限制、功能需求的内容都归进去，最终误关 412 张工单，还附上同一条模板回复。重新打开工单花了两天，团队又在社区公开道歉。

整个过程中，每张工单只调用一次工具，Token 和金额都没超限，任务甚至提前结束。Run Budget 衡量的是资源消耗，业务损失却来自修改规模。

单次操作便宜，不代表累计修改安全。

批量工具会放大这个缺口。一次调用可能改很多记录；「处理整个队列」也可能让许多看似合理的步骤累积成事故。所以，工具调用次数不能代替实际影响计数。

上限应该数什么，又由谁来执行

作者要求每次运行同时维护三本账：

• Writes：创建、更新、删除、发送等修改操作。
• Entities：实际涉及的不同工单、账户或订单 ID。
• Systems：本次允许运行修改的后端系统范围。

三者解决不同问题。同一张工单反复修改，可能只涉及一个实体，却产生多次写入；跨多个系统更新一个账户，也不能只按一个账户计算风险。

阈值应来自真实追踪记录。作者建议取正常修改量的约 2–3 倍，而非放宽到 100 倍。案例中的规则是：每次最多写入 25 张工单，只涉及一个产品领域，最多调用两个写工具。

这里有个未交代清楚的细节：「两个写工具」究竟指两种工具，还是两次调用？原文没有明确说明。它同时要求标签更新、关闭、回复都计入同一个写入计数器，因此「25 张工单」也不能直接等同于「25 次修改」。实现前必须把口径定下来。

执行位置同样关键：每次调用修改工具之前，由编排层（Orchestration）检查剩余额度。只读工具不计入修改额度，模型可以看到余额，但不能自行提高上限。

对于批量接口，还需要提前计算这次调用将影响多少对象，否则检查一次调用，仍可能放过整批修改。这是落实原文原则时必须补齐的工程细节。

一次运行停下来，为什么还不够

触及上限后，运行应进入明确的 blast_radius_exhausted 状态，而不是继续尝试，或被记录成普通成功。这个状态需要携带触发了哪项限制、已修改的实体 ID，以及对应撤销批次的指针。它与 approved、budget_exhausted 一样，都是系统能识别的结果。

但单次运行守住额度，仍挡不住一千次小运行共同造成损失。作者因此增加任务整体的暂停规则：按任务、按小时追踪关闭、更新、发送量，与滚动基线比较。

案例给出的具体阈值是：某晚关闭量超过过去 7 天中位数的 2 倍，就暂停任务，在下一批开始前通知值班人员。每次运行还要带上 Release Pin，用于追查异常是否来自提示词、模型或数据变化。

恢复能力由 Undo Ledger 补上：每一步修改都记录对应的逆向操作，出问题时直接撤销准确的实体集合，不必临时拼 CSV。作者称，同一模型家族、同一队列在下一次提示词回归时，处理到 25 次关闭便停止，通知人工后通过一次逆向操作重新打开工单。

这些机制分别负责拦截、发现累积异常和恢复，少一个都会留下缺口。

我的判断

我认同把修改规模作为独立约束。Permission Envelope 规定 Agent 可以做什么，Blast Radius 规定一次最多做多少；Run Budget 则继续负责资源消耗。这几项不能互相替代。

作者还把它放进五层 Agent 架构：属于 Guardrails，由 Orchestration 执行，在 Traces 留痕。超限写入不执行，也就不应获得 Receipt Gate 的凭证；Ship Gate 则要求带写工具的 Agent 上线前具备三类上限和整体暂停规则。

不过，原文没有提供追踪日志、对照实验或阈值效果统计。412 张误关、下一次止于 25 次关闭，应视为作者提供的案例陈述；2–3 倍余量、7 天中位数的 2 倍，属于经验建议，不能直接当作通用安全参数。

另一个前提是「可撤销」。重新打开工单，并不能收回客户已看到的错误回复；邮件发送、删除等动作也未必有完整逆操作。Undo Ledger 能帮助恢复系统状态，却未必能消除业务后果。

影响范围上限的价值，是让错误损失有边界，而不是证明判断正确。

与人工审批相比，它可以保留低风险任务的自动执行效率；对于不可逆或单次后果很大的操作，审批仍有必要。与改进分类器相比，两者也应同时存在：分类器降低犯错概率，上限控制犯错后的扩散。

能拿来做什么

• 给已有写权限的 Agent 做一次盘点，从上周 Traces 统计单次最大写入量、不同实体数、涉及系统，以及整个任务最繁忙一小时的修改量，先建立可用基线。
• 如果用 Node 编排工具调用，就在统一的修改入口检查额度，并让批量接口申报实际影响数量；触及上限时返回 blast_radius_exhausted，附上已修改 ID。
• 给夜间任务增加整体暂停规则，检查低成本下出现平时 10 倍修改量时，系统能否在早晨之前停下来，并阻止下一批继续执行。
• 为关闭工单、更新 CRM 或修改配置记录撤销所需信息，同时区分哪些状态可以恢复、哪些外部影响无法收回，再决定是否保留人工审批。