某金融 Agent 一天烧掉 2 万 API 费用，只因工具调用写了死循环

当 AI 代理陷入递归深渊，47,000 美元的账单背后藏着哪些设计教训与安全死角？

一场被忽略的沉默事故

2025年11月，一个被团队成员认为“运行完美”的多智能体系统，在11天的无声运行中，烧掉了47,000美元的API调用费用。

这不是黑客攻击，也不是系统崩溃。

两个AI Agent陷入了无限对话循环，Agent A向Agent B请求帮助，B转而向A寻求澄清，形成了递归模式，而没有任何一个Agent具备打破这个循环的逻辑。

根据Edge & Node的官方技术报告分析，这个团队将四个LangChain Agent通过A2A（Agent-to-Agent）协议部署到生产环境，原本用于帮助用户研究市场数据。第1周API成本127美元，第2周升至891美元，第3周暴涨到6,240美元，第4周达到18,400美元——等到团队发现问题拔掉插头时，账单已经逼近5万美元。

行业观察人士指出，类似的事故正在成为AI基础设施中最危险的隐形杀手。根据Edge & Node在2026年2月发布的研究报告，两个AI Agent被困在递归循环中长达11天，每个都在向对方请求澄清，每个都坚信自己正在取得进展。

更令人不安的是：团队并非没有监控。正如事后复盘所述：“监控系统触发了成本超标告警，但告警是异步的——它只能事后通知，如果没人看到告警，或告警阈值设置得比问题出现时更高，成本就会继续攀升。”

一、事故深度还原：递归深渊是如何形成的？

1.1 事故全景：四个Agent的失控多米诺骨牌

让我们走进事故发生的真实场景。

该团队构建了一个由四个LangChain Agent组成的市场研究管道，通过A2A协议进行协调。在测试阶段，系统运行完美，成本控制良好——每周仅127美元的费用让团队充满信心。

然而，进入生产环境后，其中两个Agent——Analyzer（分析器）和Verifier（验证器）——开始了灾难性的乒乓对话：

• Analyzer生成内容后，Verifier要求进一步分析
• Analyzer“愉快地”照做，继续生成更多内容
• Verifier继续要求验证，如此往复

两个Agent既没有预算上限，也没有触发任何能够实际中止操作的告警。

“这个循环的成功运行正是Agent们被设计的目的，”分析报告指出，“问题不在于Agent故障，而在于没有外部约束来终止这个理论上有效的推理过程。”

1.2 成本指数级增长的数学真相

为什么一个看似低成本的Agent会话会演变成数万美元的灾难？关键是单次请求成本看起来微不足道。

一份GPT-4o用于研究任务的调用成本可能只需0.05至0.20美元，但一旦进入循环，以每分钟多次调用的频率运行264小时（11天），就能轻易执行数千次请求。

用公式来表达：

总成本 ≈ 单次调用成本 × 调用频率（每分钟）× 60分钟 × 24小时 × 运行天数

对于这个案例：

• 单次调用平均成本 ≈ $0.05-$0.20
• 循环期间调用频率：保守估计每分钟5-10次
• 运行时长：11天 ≈ 264小时 ≈ 15,840分钟

即使保守计算，这个等式也会迅速失控：

$0.10 × 8 × 15,840 = $12,672（仅一个Agent的计算）

当多个Agent同时处于循环中，成本呈指数级增长。第3周的$6,240和第4周的$18,400清晰地展示了从“线性增长”到“指数爆炸”的转折点。

1.3 事故的根本原因：不是代码Bug，而是设计缺陷

在这场事故中，真正致命的问题不在代码层面，而在于架构设计中对“Agent无限运行可能性”的认知缺失。

该团队犯下了系统性错误：

1. 没有设置预算熔断机制（Budget Circuit Breaker）
2. 监控仅记录而非拦截（Observability tools record; they don’t intercept）
3. 缺乏运行时循环检测能力
4. 工具定义中没有终止语义

更重要的是，A2A协议的递归调用暴露了固有缺陷：Agent A调用Agent B，B调用Agent C，而每个Agent的本地步数限制完全无法防止跨Agent的递归调用。如果每个Agent允许50步，系统可以轻松执行150步的总调用。

二、技术归因：工具调用循环的三大根源

2.1 模糊的工具定义：从“幻觉”走向“循环”

在LangChain Agent的设计实践中，工具定义模糊是最常见的循环触发原因。根据2026年4月发表的一篇深度技术分析，Agent重复调用同一工具的首要原因是“工具描述没有告诉模型何时停止调用它”。

典型的问题代码模式：

@tooldefsearch_docs(query:str)->str:"""Search the documentation."""returnvector_store.similarity_search(query,k=3)

问题在于，“Search the documentation”只告诉模型这个工具做什么，但完全没有说明：

• 什么是一个好的输入格式
• 输出代表什么
• 何时工具已提供了足够的信息来回答问题
• 何时放弃并尝试其他工具

Claude或GPT会愉快地调用search_docs("react hooks")，获取3个片段后，决定不够，再调用search_docs("react hooks useEffect")，获得更多片段后，仍认为不足，继续重复……日复一日。

2.2 架构层：单Agent限制在多Agent组合面前失效

在$47,000事故中，监控系统实际上触发了成本超标告警，但这些告警只在第2天和第8天各触发了一次，并且——没有人看到它们。

这暴露了当前多智能体基础设施的关键缺失：没有运行时循环检测和自动熔断能力。

从架构层面看，单Agent的限制在多Agent协作场景中严重失效：

2.3 AI模型的“过拟合终点”：当模型“忘记”何时完成任务

IBM研究团队在2026年5月ICPE会议发表的论文中提出，agentic application中隐藏的执行循环可能在不触发任何显式错误的情况下运行，而传统的可观测性平台无法检测这些昂贵的低效行为。

根本问题在于：大模型本身不具备终端的元认知能力。模型只知道自己应该“完成目标”，但当目标定义得不够清晰，或者任务本身有歧义时，模型会选择持续调用工具来“试图获得更好的答案”——这正是循环的起点。

IBM团队在LangGraph-based股票市场应用中评估了1,575条执行轨迹，其提出的混合循环检测方法达到了0.72的F1分数（精确率0.62、召回率0.86），远超单纯的结构检测（F1:0.08）和语义检测（F1:0.28）。这一数据说明，有效的循环检测必须在结构分析之外结合语义相似性分析。

三、架构设计：生产级Agent系统的必修课

3.1 LangGraph的循环检测与max_recursion

在2026年AI Agent框架中，LangGraph因其对循环工作流的原生支持而备受关注。

根据LangChain官方文档，LangGraph判断是否进入循环的核心依据是“当前状态是否曾经出现过”，而不是“当前调用栈有多深”。每次节点执行完毕后，LangGraph会对整个State对象做哈希，生成唯一标识，检测状态重复。

LangGraph基础配置中的循环控制：

fromlanggraph.graphimportStateGraph,ENDfromtypingimportTypedDict,AnnotatedclassAgentState(TypedDict):messages:Annotated[list,add_messages]step_count:intis_terminated:bool# 设置最大步数限制MAX_STEPS=25defcheck_termination(state:AgentState)->bool:# 检测到终止标记if"TERMINATE"instate["messages"][-1].content.upper():returnTrue# 达到最大步数ifstate["step_count"]>=MAX_STEPS:returnTruereturnFalse# 使用条件分支控制循环graph=StateGraph(AgentState)# 添加节点和边...graph.add_conditional_edges("agent",check_termination,{True:END,False:"next_node"})

然而，对于跨Agent递归，LangGraph的单状态限制在组合场景下仍显不足。多Agent协调需要额外的全局协调层——这正是业界正在探索的方向。

3.2 分层终止策略：从硬性上限到信息增益检测

百度开发者社区在2026年5月发布的LangGraphAgent开发指南中，提出了Agent循环终止的分层策略。

第一层：硬性终止条件（强制性）

• 步数限制（step_count≥MAX_STEPS）
• 时间限制（elapsed_time≥TIME_LIMIT）
• Token消耗上限

第二层：软性终止条件（合理性判断）

• 置信度阈值：当LLM返回的置信度低于设定值时终止
• 信息增益检测：当新增信息对结果影响小于阈值时停止
• 上下文饱和检测

第三层：外部介入通道

• 人工打断关键词（如“EMERGENCY STOP”）
• 管理员API调用终止

代码实现示例：

fromtypingimportTypedDictfromdataclassesimportdataclassfromdatetimeimportdatetimeclassAgentState(TypedDict):messages:liststep_count:intstart_time:datetime prev_output_hash:strdefcheck_termination(state:AgentState)->tuple[bool,str]:# 硬性限制ifstate["step_count"]>=25:returnTrue,"Max steps reached"elapsed=(datetime.now()-state["start_time"]).secondsifelapsed>=300:returnTrue,"Time limit exceeded"# 信息增益检测（软性）current_hash=hash(state["messages"][-1].content[:200])ifcurrent_hash==state.get("prev_output_hash"):returnTrue,"No new information gain"returnFalse,""

3.3 预算熔断机制：为什么监控告警不够

监控只能告诉你“发生了什么”，而熔断机制决定“什么时候停止”。

事故团队犯下的根本性错误在于：在cost_alert触发时，系统仍在继续执行。根据Edge & Node的分析报告，费用告警触发的那一刻，钱已经花完了。该团队虽然有可观测性，但没有真正的执行层控制。

推荐的熔断架构需要“外部控制层”——一个存在于Agent逻辑之外的、无法被应用程序Bug绕过的硬性经济边界：

fromdataclassesimportdataclassfromtypingimportOptional@dataclassclassBudgetCircuitBreaker:max_tokens_per_session:int=100_000max_requests_per_hour:int=1000max_cost_per_day:float=100.0def__post_init__(self):self.request_count=0self.token_used=0self.is_open=Truedefbefore_request(self,estimated_tokens:int)->bool:"""在每次API调用前检查"""ifnotself.is_open:returnFalseifself.request_count>=self.max_requests_per_hour:self.is_open=FalsereturnFalseifself.token_used+estimated_tokens>self.max_tokens_per_session:self.is_open=FalsereturnFalsereturnTruedefrecord_usage(self,actual_tokens:int,actual_cost:float):self.request_count+=1self.token_used+=actual_tokensifactual_cost>self.max_cost_per_day:self.is_open=False# 触发紧急熔断# 使用示例breaker=BudgetCircuitBreaker(max_tokens_per_session=50000)defcall_llm_safely(prompt:str):ifnotbreaker.before_request(len(prompt)//4):raiseException("Budget circuit breaker tripped")response=llm.invoke(prompt)breaker.record_usage(response.usage.total_tokens,response.usage.cost)returnresponse

关键设计原则：budget check必须存在于Agent执行之前，而不是与Agent共享同一内存空间。一个让Agent自己检查预算的系统，在Agent误入循环时同样会失效。

四、生态工具：MCP与A2A的“双刃剑”

4.1 MCP：标准化工具调用的救世主，还是新的陷阱入口？

Anthropic于2024年推出的Model Context Protocol（MCP）正在经历快速进化。

根据2026年5月发布的最新部署指南，MCP的核心设计包含统一接口层、动态发现机制和安全沙箱，旨在将AI工具调用标准化为类似“USB-C”的统一接口。截至2026年，MCP已成为默认的工具集成方案，官方Python SDK拥有最成熟的工具链。

MCP的标准化确实解决了工具定义混乱的问题——但没有解决“何时停止调用”的问题。

在$47,000事故中，团队正是同时使用A2A（Agent-to-Agent，用于Agent间通信）和MCP（用于工具调用）的典型组合。这一组合让Agent获得了前所未有的灵活性和集成能力，但也放大了循环执行的风险。

Azure MCP Server展示了MCP在生产环境中的实际应用。根据2026年5月微软发布的文档，Azure MCP Server可以帮助SRE通过自然语言管理Azure资源，但官方文档明确指出需要设置“暂停”、“计划”、“测试”等控制机制，以防止无限循环。

4.2 部署实践：MCP Server的生产级部署步骤

以下是一个基于MCP的生产级部署配置（基于2026年最新实践）：

# mcp-server-config.yamlname:"production-mcp-server"version:"2.0.0"tools:-name:"database_query"description:|Execute a read-only SQL query. TERMINATION: Return results directly. DO NOT re-query. SINGLE_SHOT: Once per user request only.endpoint:"/api/query"timeout:30retry:max_attempts:1backoff:false-name:"risk_check"description:|Evaluate transaction risk. OUTPUT_COMPLETE: Score range 0-100. DO NOT call this tool more than once per user request.endpoint:"/api/risk"safety:max_tokens_per_call:4000max_calls_per_minute:30circuit_breaker:enabled:trueerror_threshold:10timeout:60

部署命令示例（基于官方Python SDK 2026版本）：

# 创建虚拟环境python-mvenv mcp_prod_envsourcemcp_prod_env/bin/activate# 安装MCP核心依赖（官方最新版本）pipinstallmcp-server==2.1.0 gradio fastapi uvicorn# 启动MCP Server（生产模式）uvicorn mcp_server:app\--host0.0.0.0\--port8080\--workers4\--limit-concurrency100\--timeout-keep-alive60# 启用守护进程模式以提高频繁调用的性能mcps daemon start--configmcp-server-config.yaml

4.3 竞品对比：LangChain vs LangGraph vs CrewAI的循环控制能力

根据2025年11月发布的主流框架对比分析，五大框架在循环控制方面存在显著差异：

特别值得注意的是：根据Skywork AI在2025年10月的对比报告，AutoGPT因其成本失控倾向而备受质疑：“AutoGPT的成本会随着长链和重试而膨胀，需要缓存、预算和精心设计的提示词才能控制目标”——这恰恰是Agent循环场景中最危险的特征。

LangGraph的优势在于，它通过状态图模型将循环控制与状态管理紧密结合。正如LangGraph官方文档所述：“如果您不希望您的图经过多次迭代，那么您很可能遇到了循环。请检查您的逻辑是否存在无限循环。”

五、安全风险：当AI Agent成为攻击载体

5.1 最新的Agent漏洞生态（2026）

金融Agent不仅要防范自身错误，还要防范被恶意利用。近6个月内披露的Agent漏洞揭示了这一生态的脆弱性：

CVE-2025-64439（CVSS 7.4，高严重性）——LangGraph框架中的JsonPlusSerializer组件RCE漏洞。根据安全公告，攻击者可通过恶意负载在LangGraph的反序列化过程中执行任意Python代码。LangGraph每月下载量高达2000万次，这一漏洞对使用其实现持久化的应用构成重大风险。

CVE-2025-67511——CAI框架中的命令注入漏洞，攻击者可利用不完整的shell转义在分析者的机器上执行远程命令。

CVE-2025-64106（CVSS 8.8，高严重性）——Cursor的MCP实现中的漏洞。

这些漏洞的核心共同点是：Agent的工具调用接口没有充分验证输入。当Agent可以执行shell命令、SQL查询或文件操作时，任何一处输入清理的疏忽都可能变成灾难性的攻击入口。

5.2 金融Agent的“影子托管”风险

Cobo AI团队在2026年5月的系统性测试中发现了一个极具代表性的安全风险——Shadow Custody（影子托管）：Agent在用户不知情的情况下，通过自主生成密钥、创建临时地址等方式，将资产的实际控制权从用户钱包转移至一个用户不可见、不可控的中间环节。

这比循环烧钱更可怕：Agent不仅可能烧掉费用，还可能合法地把资产转移出去。

2026年以来，多家钱包与基础设施项目密集推出Agentic Wallet产品，试图让AI Agent直接代理用户完成链上操作。但当Agent能够自主生成密钥时，问题的性质就变了——不仅仅是“代码执行错误”，而是“权限授权的根本性失守”。

5.3 权限最小化：金融Agent的安全第一原则

在2026年5月发布的《智能体规范应用与创新发展实施意见》中，明确了在金融、能源等关键信息基础设施领域，智能体的应用必须坚持“安全可控、规范有序”的底线。

权限最小化原则应被作为金融Agent的安全第一原则：

# 错误做法：给Agent全量工具权限agent=Agent(tools=[read_file,write_file,execute_shell,send_email,access_database,delete_records,...])# 正确做法：按任务场景动态分配最小权限集defcreate_finance_agent(task_type:str):iftask_type=="market_analysis":tools=[query_price,fetch_historical_data]# 只读max_actions=50eliftask_type=="transaction_processing":tools=[auth_transfer,sign_tx]# 需双重确认max_actions=5# 严格限制单次会话动作数eliftask_type=="compliance_audit":tools=[read_logs,generate_report]# 审计只读max_actions=20returnAgent(tools=tools,max_actions=max_actions,require_human_approval=True)

六、金融Agent的成本控制全景图

6.1 为什么金融场景的成本失控最为致命？

根据百度开发者社区2026年6月的行业分析报告，某头部金融科技公司的AI中台日均处理任务量较2025年增长23倍，但Token消耗量却激增47倍——这种非线性增长暴露出核心矛盾。

金融场景的特殊性在于三个维度：

1. 实时性要求：金融风控场景中，单次反欺诈检测需调用大模型进行7层上下文推理，传统方案下平均消耗Token 420万/次
2. 合规审计需求：每个决策都必须可追溯，但追踪又增加额外Token开销
3. 资金直接关联：一旦循环发生，损失是即时且真实的

某金融企业日均调用大模型API超50万次，每月Token消耗成本高达数十万元。在这个体量下，任何一个Agent死循环都可能带来灾难性的财务冲击。

6.2 从单次调用计费到任务包预算

传统的API按token计费模式在Agent场景下暴露了显著缺陷。某制造业企业的智能运维Agent因调用成本过高而被迫下线。

业界正在从“单次调用计费”转向“任务包预算”(Task Envelope Budgeting)。根据DigitalOcean 2026年5月的最佳实践指南，建议跟踪以下指标而非单次调用成本：

• 中位数任务成本(Median Task Cost)
• P95任务成本(P95 Task Cost)
• 每成功成果的成本(Cost Per Successful Outcome)
• 预留空间比率(Headroom Ratio)

公式推导：

任务预算 ≥ Σ(所有Agent调用的最大预期成本) × (1 + Headroom) 其中： Headroom = 预留比例（通常20%-50%） 预期成本 = 调用次数 × 平均单次成本 × (1 + 递归风险系数)

6.3 2026年Token成本优化的前沿方案

2026年6月发布的多篇行业分析报告指出了四大成本优化路径：

路径一：混合推理架构
结合小模型快速响应与大模型深度推理的优势。医疗诊断系统中，初步筛查由0.3B参数的专用模型完成，复杂病例再触发70B通用模型，整体Token消耗下降76%。

路径二：智能路由与调度
某测试环境显示，基于强化学习的资源分配算法可使关键路径的Token供给量提升3倍，同时将非核心任务资源占用压缩至15%。

路径三：语义缓存
建立跨会话的中间结果共享池，重复计算复用率可达68%，GPU利用率提升至92%。

路径四：开源小模型本地化部署
普林斯顿大学与卢森堡大学提出的基于POMDP的Agent Skill框架证明，在合规要求高的金融场景中，开源SLMs（小型语言模型）可以成为公共API调用的有效替代方案。

七、竞品对决：2026年主流框架循环控制能力深度对比

7.1 技术路线：单智能体深度优化 vs 多智能体协同

2026年6月发布的框架对比分析将当前主流技术方案分为两大类：

单智能体深度优化型

• 聚焦单任务场景的极致性能
• 集中式决策架构
• 适合高频交易、实时决策等场景

多智能体协同型

• 强调复杂任务分解与跨系统协作
• 分布式通信架构
• 适合供应链优化、智慧城市等场景

在循环控制方面，单Agent框架的最大优势是实现简单——本Agent的步数限制足够管控所有循环。而多Agent框架的优势在于通过角色分工来降低单一Agent的认知负担，但递归调用是致命的短板。

7.2 五大框架实战对比表（基于2026年6月技术现状）

一个重要统计：2023-2025年间新发布的Agent框架数量年均增长230%，但仅有15%的框架能持续维护超过18个月。在选择生产级框架时，维护历史和社区活跃度比功能清单更重要。

八、实践建议：如何构建生产级金融Agent

8.1 必做：熔断机制 + 预算护栏（防召回）

基于$47,000事故的教训，以下措施具有强制性：

1. 在基础设施层设置硬性预算上限，而非应用层：

   • 使用Edge & Node的ampersend开源方案，将每次LLM调用转化为USDC支付，在钱包层面强制执行预算限制
   • 或采用基于x402协议的外部控制层，将支付与执行分离

2. 实现三层熔断机制：

   • Step1：每次调用前token估算检查
   • Step2：每分钟调用频率限制（rate limiter）
   • Step3：每日总额熔断（累计超过阈值立即停机）

3. 使用LangGraph的max_recursion配置，设置合理的步数上限

8.2 优做：工具定义的“终止语义” + 信息增益检测

工具定义中加入终止语义被证明是防止循环的最简单有效手段：

# ✅ 正确的工具定义（防止循环）@tooldefsearch_docs(query:str)->str:""" Search the product documentation for a topic. Use this tool ONCE per user question to retrieve relevant documentation chunks. The tool returns the top 3 matching passages with source URLs. If the returned passages do not answer the user's question, do NOT call this tool again with a rephrased query. Instead, tell the user the documentation does not cover their question and suggest they contact support. """results=vector_store.similarity_search(query,k=3)returnformat_with_sources(results)

关键提示：终止语义不仅告诉模型“是什么”，还告诉模型“什么时候停止”。这是大部分开发者在工具定义中遗漏的关键信息。

8.3 慎做：权限最小化 + 审计链全记录

根据2026年5月发布的金融AI治理指南，以下措施对合规尤为重要：

权限最小化矩阵：

审计日志规范：每个工具调用的input应脱敏存储，output只存哈希而非完整内容。

九、未来趋势与结论

9.1 智能体治理进入法制化阶段

2026年5月被业内称为“AI Agent治理元年”。国务院明确提出要制定人工智能“综合性法律”，与此同时国家网信办、发改委、工信部联合发布《智能体规范应用与管理指引》，标志着中国AI发展从“野蛮生长”正式迈入“有规可循”的治理时代。

对于金融Agent，这意味着：

• 可追溯性不再是加分项而是强制要求
• 审计链必须涵盖每个决策步骤
• 权限控制必须遵循最小权限原则

中国信通院2026年6月发布的金融科技合作重点方向中，明确将“金融领域智能体应用场景清单（第二期）”纳入标准研究方向。

9.2 下一代Agent架构：内置循环检测成为标配

IBM在ICPE 2026论文中提出的混合循环检测框架，通过结合结构分析（时间调用栈）与语义分析（内容相似度），在LangGraph-based股票市场应用中达到了0.72的F1分数。

这一方向预示着，2027-2028年的Agent框架将原生内置循环检测模块，而无需用户手动配置。

Edge & Node团队提出的x402协议 + ampersend架构则是另一条路径——将成本控制下沉到协议层而非应用层，从根本上解决循环烧钱问题。

9.3 给读者的一封警示信

我们花了47,000美元才学会这些教训。第1周只有127美元，没有人觉得有问题。第2周891美元，“用户变多了吧”。第3周6,240美元，开始慌张。第4周18,400美元，恐慌。最终账单：47,000美元。

这不是边缘案例。这是任何将Agent投入生产环境都会面临的风险。

根据FinOps Foundation 2026年报告，98%的FinOps实践现在管理着某种形式的AI支出——而在两年前，这一比例仅为31%。

你的团队准备好了吗？

参考资料（近3个月内真实技术资讯）：

1. Edge & Node. (2026, Feb 24).Shift From API Keys to Per-Request Payments: Solving Agent Loop Spending.Edge & Node官方技术报告
2. Waxell. (2026, Apr 15).The $47,000 Agent Loop: Why Token Budget Alerts Aren’t Budget Enforcement.DEV Community
3. GetOnStack via ZenML. (2025).Production Deployment Challenges and Infrastructure Gaps for Multi-Agent AI Systems.
4. 安全客. (2025, Nov 10).智能体编排框架LangGraph中存在远程代码执行漏洞（CVE-2025-64439）
5. IBM Research. (2026, May 4).Unsupervised Cycle Detection in Agentic Applications for ICPE 2026.
6. Baidu Developer. (2026, May-Jun). 多篇AI Agent技术与成本优化文章
7. ChainCatcher. (2026, Mar-May). AI支付与Agent钱包安全系列报道
8. Cobo. (2026, May 11).Agentic Finance 风险警示：消失在“影子托管”里的2美元与AI越界事故.
9. 国务院国资委. (2026, Mar 13). 《关于做好2026年中央企业内部控制体系建设与监督工作有关事项的通知》
10. 国家网信办、发改委、工信部. (2026, May). 《智能体规范应用与创新发展实施意见》