12个AI Agent框架安全调查：无一能按美元限制Agent消费

AI Agent正在从对话工具演变为能自主调用外部服务的执行体。当Agent可以发起支付、购买API额度或调用付费工具时，一个朴素的问题浮出水面：主流框架能限制它花多少钱吗？

一项针对12个主流Agent框架的横向调查给出了直接答案：没有任何一个框架在文档中提供以货币计价的工具调用预算控制。

调查方法与八项控制维度

研究者于2026年10月9日逐一查阅了12个框架的官方文档或源码，围绕八项控制能力进行核查：

• C1：工具执行前的人类审批
• C2：可阻断调用的程序化单工具钩子
• C3：最大步骤/迭代/轮次限制
• C4：单次运行的Token或LLM成本预算
• C5：以货币计价的工具消费预算
• C6：工具调用速率限制
• C7：工具调用幂等/去重
• C8：内置的工具调用审计日志（含参数）

调查覆盖LangChain/LangGraph、CrewAI、OpenAI Agents SDK、Vercel AI SDK、Google ADK、Microsoft AutoGen、Semantic Kernel、LlamaIndex、Pydantic AI、Mastra、Claude Agent SDK和smolagents。

该调查由PinkWallet的Pink Agentic AI Payments团队发布，作者声明自身从事支付控制层工作，但强调调查对象为通用Agent框架，Pink本身不在表格中，每个单元格均链接至框架自身文档。

核心发现：0/12的美元预算缺口

表格中最醒目的一行是C5——12个框架全部为“否”，没有任何一个在文档中支持以货币计价的工具调用预算。

这一结果需要客观看待：这些是通用Agent框架，按美元限制消费从来不是它们的职责范围。但缺口客观存在——如果你的Agent能花钱，限制必须来自框架之外。

其余控制项的表现则分化明显：

• 10/12 提供某种形式的人类审批（C1为yes或partial），但并非都能拦截单次特定工具调用，部分只能停止整个运行
• 9/12 支持在代码层面阻断特定工具调用（C2），而非仅靠提示词指令。这个钩子正是接入消费检查的入口
• 9/12 记录了最大步骤限制（C3），是调查中最常见的控制项
• 仅 2/12 记录了清晰的Token或成本预算（C4为yes），另有3个为partial

这里有一个关键区分：Token预算限制的是模型的开销，而不是Agent购买的东西。一次工具调用可能触发真实的资金流动，而Token预算对此毫无感知。

Token预算与货币预算的差异值得展开。Token是模型处理文本的计量单位，Token预算通常表示为单次运行最多消耗多少输入输出Token，或折算成多少美元的大模型API费用。它计量的对象是推理本身，即"模型思考了多久"。而一次工具调用可能触发与模型开销完全无关的真实资金流动：支付一笔账单、购买一份数据、按次调用第三方付费接口。这些成本发生在模型之外，金额与Token消耗无稳定对应关系。因此即使框架提供了精确的Token上限，也无法阻止Agent在少量Token内完成高额支付，两类预算需要独立设计。

消费上限应该放在哪里？

答案明确：不放在提示词里。

“花费不超过50美元”只是模型上下文中的一段文字，它可能被误读、遗忘，或被提示注入攻击覆盖。把资金安全寄托在模型的文字理解上，风险显而易见。

更合理的方式是利用框架的C2钩子（程序化工具调用拦截），在模型之外调用一个真正“懂钱”的服务——支付API或其前置控制层。这一层应当持有预算、单笔支付上限、允许的收款方和审批规则，并在支付执行前给出答复。

三个结果几乎覆盖所有场景：允许（allow）、请求人工审批（ask a human，沉默即拒绝）、阻断（block）。

这种架构将金额控制从概率性的模型行为中剥离，转变为确定性的系统规则。

提示注入是指攻击者通过污染模型可读的输入（如网页内容、用户消息、被调用工具的返回值）来覆盖或绕过原始指令的攻击方式。当消费规则以自然语言形式写在系统提示词中时，恶意内容可以诱导模型忽略"不超过50美元"这一约束，或者伪造"已获授权"的语境。由于大模型对指令与数据的区分本身依赖上下文概率，而非严格的语法边界，任何基于提示词的金额控制都属于软约束，无法在对抗性输入下提供安全保证。这也正是把消费上限从模型上下文迁移到外部进程的根本原因：程序化钩子接收的是结构化参数，不经过模型的文字理解，因此不受提示注入影响。

支付MCP服务器同样存在缺口

调查还援引了一项针对49个支付类MCP服务器的普查，从另一侧印证了同样的缺口：在37个能够转移资金的服务器中，仅4个记录了消费预算，仅6个记录了人类审批。

两条独立数据线指向同一结论——无论是通用Agent框架还是专用的支付MCP服务器，资金级控制都处于普遍缺失状态。这种交叉验证强化了问题的真实性：这不是某个生态的孤立现象，而是整个Agent基础设施层的系统性空白。

MCP全称Model Context Protocol，是由Anthropic提出并已被多家厂商采纳的开放协议，用于让AI应用以统一方式连接外部工具与数据源。一个MCP服务器本质上是一个暴露若干"工具"（tool）的进程，Agent通过标准化的请求-响应格式调用它们，无需为每个服务单独编写集成代码。支付类MCP服务器即把转账、扣款、查余额等资金操作封装为工具。协议本身只规定调用格式与能力发现机制，不包含任何预算、审批或频率限制语义，因此资金级的控制必须由服务器实现方自行添加——这正是普查中出现大面积缺口的协议层根源。

实践路径与沙盒验证

Pink提供了公开沙盒，向Agent暴露七个MCP工具（包括pink.get_budget、pink.check_policy、pink.request_payment等），对每个请求依据单Agent预算和规则返回allowed、pending_human或blocked。沙盒仅使用测试资金。

仓库中提供了LangGraph、OpenAI Agents SDK、CrewAI和Vercel AI SDK的可运行示例，开发者可以直接观察消费控制层如何与不同框架的钩子对接。

对于框架维护者，调查方也留下了开放入口：如果某个单元格的判断有误，可提交附带文档链接的issue进行修正。

对开发者的启示

如果你的Agent具备任何形式的资金能力——无论是直接支付、购买资源还是调用按量计费的付费工具——在框架层面目前找不到开箱即用的美元级保险丝。

务实的做法是在工具调用钩子处外挂一个独立的策略层，由它持有预算和规则，并在资金流动前做出确定性判断。模型可以负责决定“要不要做”，但“能不能花”必须由模型之外的系统说了算。