AI智能体成本：付费兜底如何耗尽共享余额

AI智能体成本：这次故障留下的记录

真正昂贵的并不是某次异常庞大的模型调用，而是一次受阻的文件交接：原本只应备用的计费兜底路径，最终默认扛起了全部工作。

在 2026-09-18 → 09-19 期间，两个自主发布代理采用了大致相同的流程：沙箱中的写作代理先生成文章，再由网站发布。其中一个代理刚在新服务器上重启。它在 12 小时内发布了 18 篇文章，而这 18 个载荷无一例外都只有图片描述，没有图片文件。

网站把这些描述当成了图片生成请求，通过付费图片模型生成了 18 张封面和约 26 张配图，平均每篇约 $0.45。两个发布系统共用同一个计费网关余额。到 01:15 UTC，余额已从 $8.30 降至 $0。

图片数量和单篇成本都是约数，因此必须继续按约数理解，不能据此精确还原共享余额。两组产物缺失数量也是各自独立的观察结果，不能合并推导出受影响文章的去重总数。

证据都指向文件上传边界

载荷、日志和余额共同指向了同一个断点：写作代理可以描述图片，却无法交付图片文件。

• 18 个载荷全部包含场景描述，图片文件数却都是 0。这并非轻微的渲染质量问题，而是产物根本没有跨过发布边界。
• 一份日志提到图片工具 10 次，另一份为 0 次。两个代理使用相同的 CLI 版本、拥有相同的工具，也带着相同的参数。这个反差说明相关能力确实存在，只是第二个写作代理无法通过自己的可达路径使用它。
• 网站把描述转成付费图片时，共享余额在 01:15 UTC 从 $8.30 降至 $0。支付路径一停，两个发布系统都开始缺少封面和嵌入。

这也是为什么，这次事故的意义远不止内容发布。人们谈论 AI智能体成本时，通常关注模型选择、token 用量或重试次数。但这次成本更早就开始产生了：安全边界把生成文件的进程，与上传文件所需的凭据隔开了。

安全沙箱为何让付费路径成了唯一选择

不让沙箱中的写作代理接触网站密钥，是正确的安全决策；仍把必须依赖该密钥的上传步骤留在它的工作流里，才是架构错误。

沙箱会限制代理能够访问和修改的内容。在这次事故中，写作代理的 shell 无法获得网站密钥，而图片上传又需要这个密钥，因此，从渲染文件到存储文件的直接路径在沙箱内根本走不通。

与此同时，载荷仍然接受封面场景和文内场景描述。所谓兜底，就是首选路径无法完成时启用的替代路径。由于载荷抵达时有描述却没有文件，网站便通过计费网关生成图片。替代路径就这样悄无声息地成了唯一可走的路。

另一个代理走的是一条不同且可达的路径。它的写作代理使用订阅中包含的图片工具，完成文件渲染并自行上传。“订阅中包含”并不意味着订阅免费，只表示那次运行没有把每一张缺失图片都送进本次事故中的独立计费兜底路径。

教训不是削弱沙箱，而是把需要凭据的工作放到边界的可信一侧。选择哪一种 AI智能体代码沙箱 固然重要，但如果工作流把一个代理根本无法执行的凭据操作交给它，再好的沙箱产品也无法补救。

为什么 done 是错误的状态

支付错误本应改变任务结果。但系统把 402 当成了软失败：它记录或容忍了错误，却没有停止任务。

这个决定把“任务完成”和“产物完成”割裂开来。文章正文还能发布，任务便返回 done，即使必需的封面或嵌入根本不存在。

嵌入是内容的一种存储表示，系统靠它匹配相关文章，用于内部链接和搜索。封面缺失在页面上一眼可见；嵌入缺失则隐蔽得多——文章虽然存在，却不会出现在负责发现和关联内容的系统中。因此，5 篇文章可以在没有嵌入的情况下发布，而最终状态完全没有暴露问题。

正确的完成契约其实很简单：只有工作流规定的必需产物全部就位，任务才算完成。需要封面，就确认封面存在；需要嵌入，就确认嵌入存在。数据库里有一条正文记录，并不能证明发布任务已经结束。

对构建者、运维者和采购者意味着什么

同一起事故，会改变三类角色各自的决策。

构建者：设计好交接，不只是沙箱

构建者应该画清凭据边界，并为每一个跨越边界的步骤指定执行方。“写作代理不能获取密钥”是一条安全规则；与它并列的工作流要求，不能还是“写作代理用该密钥上传”。

所有代理系统最终都会撞上同一堵墙：生成意图与外部副作用之间的边界。写出描述是意图；存储图片、向计费服务商付费、发布文章则是副作用。每个副作用都需要明确的可信执行方、可观测的结果，以及能够传递到父任务的失败状态。

运维者：监控多个产品共用的依赖

运维者应该把共享的计费余额视为公共基础设施，而不是无关紧要的供应商设置。在这次事故中，两个发布系统的封面、配图和嵌入都依赖同一笔余额。因此，一个写作代理的兜底行为会直接改变另一个发布系统的可靠性。

AI智能体 API 预算控制 可以约束支出，但限额本身无法让产物路径变得正确。给这根共享保险丝明确命名，监控并告警它的健康状态，同时让所有依赖它的工作流都能看到余额耗尽。原始记录没有提供告警阈值或修复后的测量结果，因此这里也不应凭空补充。

采购者：追问理想路径失效后会发生什么

采购者应该问清楚：兜底路径是否计费，哪些产品共用它的预算，以及兜底路径无法支付时任务会返回什么状态。一次顺利完成的演示，回答不了这些问题。

一份真正有用的契约，应明确必需产物、凭据持有方、付费兜底路径，以及产物缺失时返回的状态。对于可能花钱或发布不完整内容的重试，AI智能体重试的人工审批 也是一道控制关口。它是对产物契约的补充，而不是替代。

现在行动、暂缓，还是保持原样

如果沙箱中的写作代理能提交描述，却无法暂存这些描述所替代的文件；如果多个产品共用同一个付费依赖；或者兜底失败后任务仍能以 done 结束，就应该立即行动。只有当现有日志能够证明存储文件确实跨过了边界，而且缺少必需产物已经会阻止任务成功时，才可以暂缓重构。若必需的发布产物无论直接还是通过兜底生成，都不依赖这笔余额，那么该工作流不受这次特定的共享余额故障影响，可以保持原样。

被高估的做法：兜底越多，不代表韧性越强

兜底路径不会因为能让任务继续向前，就自动等于韧性。只有它的成本、依赖关系、输出质量和失败状态都足够清楚时，才称得上真正可靠。

在余额尚未耗尽时，这条兜底路径确实完成了有用的工作；但它也掩盖了主上传路径不可达的事实。这种组合很危险：表面上的可用性，会推迟原本可以暴露边界故障的信号。

再增加一个供应商，并不能解决核心问题。它可能只是多添一张账单和一个软失败，同时让 done 继续与必需产物脱节。工程目标不是堆出最多的替代路径，而是先有一条代理真正能走通的主路径，再配一条成本清晰、失败时能够明确报错的兜底路径。

让 AI智能体成本保持可见的工程规则

修复应从明确归属开始，再把成本与完成条件写清楚。

把凭据留在可信进程中

沙箱中的写作代理负责生成文章、载荷，以及它有能力渲染的图片文件。需要授权的上传，则交给沙箱外的可信进程。这样做保留了安全边界，而不是在边界上打一个密钥形状的洞。

把文件和描述定义为不同的输入类型

文件是已经就绪的产物，描述则是制作产物的配方。把两者当成可以互换的东西，会同时掩盖成本与失败行为。

发布契约应优先使用已经暂存的文件。描述则保留下来，作为来源记录和修复数据。如果系统调用描述进行兜底生成，这条分支就应明确标为付费路径，并在状态中如实报告。

让 done 与必需产物绑定

父任务必须等待它承诺交付的产物。当封面或嵌入契约尚未满足时，支付软错误不能以 done 收尾。必需产物检查应该发生在终态成功之前，而不是留给一份事后报告去描述已经造成的损失。

把依赖健康状态与任务日志分开

两份日志的反差很有价值，因为它说明一个代理使用了图片工具，另一个没有。这个信号应该保留。同时，还要让所有依赖共享计费服务的发布系统都能看到该依赖的健康状态。任务日志回答的是某一个工作进程尝试了什么；依赖遥测回答的是这条共享路径还能不能为任何工作流提供服务。

下面是一种示意性的代码结构，并非生产源码。它只描述执行归属和状态流转；原始材料没有提供具体实现或修复后的测量结果。

// Illustrative only. This is not production source.
const handoff = {
  payload: writerOutput.payload,
  pictureFiles: writerOutput.pictureFiles,
  pictureDescriptions: writerOutput.pictureDescriptions,
};

const stagedFiles = await trustedProcess.stage(
  handoff.pictureFiles,
  "presigned PUT",
);

const fallbackRender = stagedFiles.complete
  ? null
  : await paidFallback(handoff.pictureDescriptions);

if (fallbackRender?.status === 402) {
  failJob("Paid fallback unavailable");
}

const publishableArtifacts = mergeArtifacts(
  stagedFiles,
  fallbackRender,
);

const rewrittenPayload = rewritePictureReferences(
  handoff.payload,
  publishableArtifacts,
);

rewrittenPayload.pictureDescriptions = handoff.pictureDescriptions;

assertRequiredArtifacts(rewrittenPayload);
markDone();

关键在于顺序：写作代理在不接触网站凭据的情况下输出文件，可信进程负责暂存，载荷再指向已经存储的产物；只有通过验证的完整结果，才能进入 done 状态。

堵住成本漏洞的交接方式

持久有效的修复需要一套两段式交接：写作代理负责渲染，可信执行方负责暂存。

写作代理把图片文件与载荷放在一起，作为它本来就有权创建的输出。沙箱外的可信进程接收这些文件，再通过 presigned PUT 将其发送出去——也就是一次专门为该交接授权的上传。现有记录没有规定它的过期时间或权限，因此这些细节仍属于实现选择，不能当成既定事实。

文件暂存后，可信进程重写载荷，让图片引用指向已经存储的文件。网站收到的是现成产物，而不是生成产物的指令。写作代理从未拿到网站密钥，发布路径也不再依靠假装它拿到了密钥才能运行。

描述仍保留在载荷中。它既是修复记录，也是在写作代理无法渲染图片时启用的付费兜底。因此，兜底仍可能产生费用。这项修复并没有删除兜底路径，也没有宣称已经测得节省金额；它只是让文件暂存重新成为可达的主路径，使付费生成再次回到有条件触发的状态。

周一就能做的事

梳理每一个必须使用凭据的步骤。如果写作代理不能持有该凭据，就把操作移交给可信进程，并定义双方之间的产物交接。随后，让任务终态取决于必需的封面、嵌入和已存储文件引用是否齐全。描述可以继续与文件并存，但要准确标明它会触发的路径：这是一条付费兜底。

常见问题

通过 新闻通讯 获取下一篇生产事故复盘。