AI Agent 付费重试怎么管:把购买权限交还给人

一套已有两道人审关卡的视频工作流,仍让 AI Agent 在自检失败后自行重做;等人查看时,所有者密钥下已产生 $5.48 费用。本文拆解漏洞为何出在“再次购买”的权限边界,并给出可执行的控制方案:审查只记录问题,由人批准重试,付费渲染函数在调用前校验并消费许可,防止模型把自己的重做建议变成付款授权。

发布于

AI Agent 付费重试怎么管:把购买权限交还给人

在任何人查看结果之前,所有者的密钥已经产生了 $5.48 的费用,尽管这套流程原本就设有两道人审关卡:批准分镜,以及批准视频。这里的“重试”,是指 AI Agent 在自己的质量审查中否决一份已经完成的输出后,再发起一次付费渲染。缺失的控制点看似很小,却至关重要:同一内容的第二次渲染必须先获得许可,而且这份许可不能由模型自行签发。

AI 智能体工作流:费用藏在已经获批的环节里

这条管线并不是一场没有检查点的无人值守实验,而是一套围绕智能体导演重新搭建的视频工作流。导演负责编写分镜、渲染分镜图和视频片段,并检查自己的输出;原有的人审关卡也全部保留。

随后,智能体的质量检查判定三张分镜图和全部五个视频片段不合格。导演没有停下来把检查结果交给人处理,而是凭自己的判断重新生成。等到人真正看到成果时,所有者的密钥已经被扣了 $5.48。

这段过程的意义,比费用本身的多少更值得关注。它说明,即使工作流在几个显眼的里程碑上都经过了人工批准,某个步骤内部仍可能藏着未经授权的购买循环。每一次付费渲染都是一笔购买;如果质量判断会触发下一次渲染,它同时也是一项支出决定。

架构流程图:三张分镜图和五个视频片段进入质量检查,随后进入由模型决定的重做循环,并在人审前产生 $5.48 费用
实际记录的过程:在人看到输出之前,质量审查已经变成了重复购买循环。

为什么两道人审关卡仍管不住 AI Agent 的第二次付费

原有的两道关卡分别回答了分镜能否通过、视频能否通过,却没有回答另一个问题:当智能体否决一份已经完成的输出后,谁有权再买一次渲染?

这是另一种权限。批准一个工作流阶段,并不等于为软件在该阶段内可能执行的所有动作预先开放预算。人可以批准这项任务,但这不代表也批准了由模型品味触发、次数未知的重复购买。

可以把它想成一名有权拒收已交付零件的质检员。质检员应该能够记录缺陷,但这并不意味着他也可以直接从所有者的账户下单购买替换件。即便后一件事紧接着前一件事发生,“报告问题”和“发起购买”依然是两种不同的权力。

外部关卡、限制重试次数和防止重复操作都很有用,但它们处理的风险并不相同。这次实际发生的问题是:在一套已经有人参与审批的流程中,模型用自己的质量审查批准了另一笔购买。人确实在环,但没有站在“再次购买”这条边界上。

模型自己设置的重做标记,不算控制措施

原来的设计使用了一个可由模型设置的标记,用来表示已经提出重做请求。它看起来像状态管理,却没有建立独立的权限边界。对输出不满意的决策者,同时也能满足购买替代品所需的条件。

只有当受控方无法改写控制条件时,控制才真正有效。如果模型可以设置 redo_requested,这个标记记录的只是模型的意图,而不是所有者的批准。

这与生产环境 AI Agent 中的规格博弈背后的逻辑相同:系统可以满足表面条件,却绕过设置该条件的真正目的。这里的目的很简单——再次扣费必须由人来决定。

提示词修不好这种权限设计错误。要求智能体“谨慎一点”,购买决定仍然留在智能体的上下文中。真正的阻断必须写进代码,并且紧挨着付费工具的调用位置。

正确做法:把审查结论与购买权限拆开

记录中的修复方案,让审查和批准各司其职。

审查步骤可以检查已经完成的输出并写下结论,然后就此停止。它不能写入允许下一次付费渲染的字段。

人查看这些结论后按下按钮,由这个动作把批准信息写入记录。渲染步骤在尝试重复购买时会消费这份许可;如果没有人的确认标记,就直接在代码中拒绝执行。

首次渲染并没有被取消,仍然受原有审批关卡约束。新增控制只在一种情况下生效:质量审查完成后,工作流想为同一内容再买一次渲染。

架构控制流程图:审查步骤写入结论后停止,由人通过按钮设置批准字段;没有该字段时,付费渲染关卡会拒绝执行
检查只负责报告,购买必须由人决定;付费渲染步骤在代码中强制执行这条边界。

字段写入与执行检查必须分开

字段本身很重要,但谁有权写入它更加重要。审查步骤可以写检查结论,按钮处理程序可以写入人的批准,而模型的执行路径绝不能有任何写入批准字段的通道。

付费渲染步骤才是执行规则的位置。过早检查这个字段会留下漏洞,因为后续分支可能绕开此前的决定。只有在付费调用前一刻检查,规则才足够贴近动作本身:如果这是针对同一内容的又一次付费渲染,而记录里没有人的确认,就拒绝执行。

下面是这项控制的示意性伪代码。原始材料并未提供生产环境源代码。

Text
review(completed_output):
    write(findings)
    stop()

person_presses_retry_button(record):
    record.retry_approved_by_person = true

render(record):
    if record.is_repeat_paid_render:
        require(record.retry_approved_by_person)
        consume(record.retry_approved_by_person)
    else:
        require(record.existing_first_render_approval)

    call_paid_render_tool()

关键不在于字段叫什么,而在于权限的流向:审查可以提出建议,人可以给予授权,付费工具负责检查授权。模型不能把自己的建议升级成自己的许可。

这次事件不能证明什么

$5.48 是人在查看之前观察到的总费用。现有材料没有拆分首次渲染与重做各自占了多少,因此无法支持任何此类明细。材料同样没有给出可量化的节省、审批耗时、人审成本,也没有修复后的测试结果。

这不是在宣称人工批准是一种新做法,也不是一套通用重试方案。网络故障后的重试、超时后的重复操作,以及因主观质量判断而再次购买渲染,是三类不同事件。这次事件只支持一条明确规则:当智能体在自己的审查中决定为同一份渲染输出再次付费时,必须由人授予一项模型无法自行授予的权限。

这项控制会在该边界上增加一次人为决策。换到其他场景,这笔权衡是否值得,要看工具本身和可能造成的后果;但在这条有记录的付费渲染流程里,边界很清楚,因为智能体的自我批评直接打开了所有者的钱包。

AI Agent 成本控制:付费重试可以马上这样改

对于一套已经设有人审关卡的付费渲染工作流,先检查从质量审查返回渲染调用的整条路径。移除任何可由模型写入的重做权限,让审查只写结论并停止;再增加一个由人设置的批准字段和一个按钮,最后让付费渲染函数在缺少该字段时拒绝重复执行。

首次渲染的关卡保持不变。这项改动不是要处处削弱自主性,而是在同一内容的第二次购买处划下一条硬边界。

AI Agent 重试中的人工批准,实际案例是什么?

在这次记录中,智能体在自己的质量审查里否决了三张分镜图和全部五个视频片段,并在人查看之前重新生成。替代方案要求先由人在记录中批准重试,系统才能再次执行付费渲染。

AI Agent 可以自行重试付费渲染吗?

如果重试是由智能体自己的质量判断触发、并会形成一笔新购买,就不应该。审查可以说明为什么需要重做,但重复付费渲染必须由人授权。

为什么原有的人审关卡还不够?

它们管的是分镜和视频能否通过,却没有覆盖另一项独立决定:智能体否决已经完成的输出后,是否可以再买一次渲染。

如果模型能设置重做标记,这个标记够用吗?

不够。模型可写的标记只记录模型想要什么。只有批准字段仅允许人写入,而且付费渲染步骤在字段缺失时会拒绝执行,它才构成真正的控制。

如果希望把这项控制设计进付费智能体工作流,可以了解 AI 自动化。

发布日期
分类
Build
Devin 与 Claude Code 价格对比:个人和五人团队怎么选

Devin 与 Claude Code 价格对比:个人和五人团队怎么选

Devin 和 Claude Code 怎么选?本文对比云端任务委派、工程师主导的本地迭代、代码仓库集成与订阅费用,算清个人及五人团队的月账单,说明 Premium 席位升级何时让费用反超,并厘清额外用量、自动化计费和迁移条件,帮助创始人与技术负责人按实际工作流程选择 AI 编程工具。2026年10月12日Build
A2A 协议详解:与 MCP 的区别、协作机制和接入时机

A2A 协议详解:与 MCP 的区别、协作机制和接入时机

A2A 协议用于独立智能体之间的任务委派,MCP 则连接工具与数据。从供应商筛选出发,讲清 Agent Card、任务、消息与产物,梳理 v1.0 的兼容性变化及 Google ADK、LangSmith、CrewAI、Microsoft Foundry 的支持范围,帮助你判断接入时机,并规划授权、重试和结果验收。2026年10月12日Build
Cloudflare Workers 等 Deno Deploy 替代方案:价格对比与迁移指南

Cloudflare Workers 等 Deno Deploy 替代方案:价格对比与迁移指南

Deno Deploy 迁移该选哪家?比较 Cloudflare Workers、Netlify、Supabase、Vercel、Val Town 与自托管 Deno 的价格、免费额度和运行时限制,梳理 Deno KV、定时任务、队列及静态站点的迁移改造,帮助你先确定数据与调度方案,再安排代码部署、流量切换和回滚。2026年10月12日Build
Claude Agent SDK 入门:用工单分流任务搭建第一个 AI 智能体

Claude Agent SDK 入门:用工单分流任务搭建第一个 AI 智能体

把 Claude Code 的智能体循环接入自己的应用:本文讲清 Claude Agent SDK、Messages API 与 Claude Code 的选择,提供 Python 工单分流示例,并梳理内置工具、权限、项目配置、会话部署和计费说明,帮助团队从可人工验收的只读任务起步,评估自动化是否值得投入。2026年10月12日Build
tmux 配置指南:用 Claude Code 多开任务、远程重连

tmux 配置指南:用 Claude Code 多开任务、远程重连

这份 tmux 配置指南带你在远程主机上运行 Claude Code,为独立任务分配 Git worktree 和命名会话,合上笔记本后再通过 SSH 接回原会话。文中涵盖官方配置、常用切换命令、分屏智能体团队与排障要点,并说明会话保活、对话恢复和文件隔离各自解决什么问题,帮助你搭好可持续使用的远程开发工作流。2026年10月12日Build
Ollama vs vLLM 怎么选:从本地部署到高并发推理

Ollama vs vLLM 怎么选:从本地部署到高并发推理

Ollama vs vLLM 怎么选?围绕并发请求、GPU 显存、模型规模、量化格式和 API 兼容性,梳理本地部署与共享推理服务的取舍。两者自托管软件费用均为 $0,真正拉开成本的是硬件与运维。结合预算示例和迁移清单,判断何时保留 Ollama,何时评估 vLLM,并在切换前验证模型、延迟与回滚方案。2026年10月12日Build
Lovable vs Cursor:从 MVP 起步到代码接手,该选谁?

Lovable vs Cursor:从 MVP 起步到代码接手,该选谁?

Lovable vs Cursor 该怎么选?本文面向创始人和产品经理,对比 AI 编程工具的上手门槛、托管与数据库、代码所有权和维护责任,拆解 Lovable 价格与 Cursor 价格,并按单人开发、多人协作及交接月份计算订阅预算,说明如何通过 GitHub 接手代码,以及何时需要单独迁移后端。2026年10月11日Build
Ollama 和 LM Studio 对比:本地大模型部署怎么选?

Ollama 和 LM Studio 对比:本地大模型部署怎么选?

Ollama 和 LM Studio 对比,怎么选才适合本地大模型部署?本文从桌面体验、本地 API、无界面服务、GPU 与 Mac 支持、工作用途许可、隐私和云端费用分析,说明有状态 Responses 何时会改变选型,迁移前又该核对哪些设置。两者本地运行软件费用均为 $0,差异主要在工作流程、接口行为与授权边界。2026年10月11日Build
订阅通讯

每周日,一封信。写运转中的系统,不写热评。

每周一期。无垃圾邮件。随时退订。