多 Agent 工作流为何烧钱：无限循环的结构性根因

疯狂背后的数学

当人们谈论 agentic deadlock 时，通常会描述为"AI 困惑了"。这对任何想要运行生产级工作负载的人来说都太过模糊。事实上，你真正面对的往往是对话状态图中的结构性失败。

一个常见的错误是认为添加更多约束或更好的 system prompt 就能解决递归问题。实际上不会。如果你的逻辑流程中存在循环依赖，且没有向退出条件推进的进展，模型会愉快地烧掉 50 美元的 token 来尝试解决一个无法解决的状态。

要正确解决这个问题，你必须把对话不是当作一串文本，而是当作一个有向图来对待。具体来说，你需要寻找强连通分量（Strongly Connected Components，SCC）。

无需猜测地识别循环

我最近研究了我们如何从数学上证明一个 agentic 工作流是否陷入困境。与其依赖"感觉"或在事后手动检查日志，不如你可以将 Tarjan 算法应用于状态图。

通过将每次交互或 agent 交接作为图中的一个节点和边，你可以精确地识别哪些参与者陷入了无限循环。这不仅仅是找到循环存在，而是精确地找出逻辑在哪里失败，以便你可以注入退出条件或更改路由规则。

Agent Loop Detector 通过 MCP 实现了这种方法。它不靠猜测，而是分析。

这种分析改变你构建方式的三个主要途径：

1. 检测关键 Deadlock
   关键 deadlock 发生在一组 agent 进入一个循环，其中没有任何一个拥有通向该循环外部的退出条件。它们实际上被困在一个封闭的逻辑电路中。使用 analyze_conversation_cycles 让你在这些模式耗尽预算之前就能绘制出来。

2. 计算风险与现实
   你可能现在有两个 agent 在循环（A → B → A），但如果 Agent B 在某些参数下有条件分支最终到达目标 C，你实际上并没有一个永久的 deadlock——你只是高波动性。calculate_deadlock_risk 工具通过评估保持困住 vs 只是低效的数学概率来处理这种区别。

3. 找到逃生舱
   在调试过程中最有用的函数可能是 estimate_recovery_path。一旦你知道存在一个循环，这会告诉你需要最少多少步来打破循环——如果退出条件存在于下游分支中的话。

生产护栏 vs Playground 实验

与业余爱好者项目不同，当这些 agent 与实时 API 或客户数据库交互时，会出现更高的风险。

我看到一个巨大的问题是资源耗尽由静默失败触发。

Agent 尝试调用 API → API 返回错误 → Agent 错误地解释错误 → Agent 重试相同的请求 → 无限重复。

如果没有对这些状态转换的自动监控，你运行的不是自治系统；你运行的是一个等待崩溃的昂贵脚本。

如何集成到你的技术栈

不要为每个新的 agent 原型构建自定义遥测（这会浪费数周时间），而是使用 MCP 来桥接你的编排层和诊断工具。

例如：

# 当完成时间 >X 秒或超过 Y 次迭代时，对当前执行轨迹运行 analyze_conversation_cycles
run analyze_conversation_cycles against your current execution trace whenever completion takes >X seconds or exceeds Y iterations.

# 在长时间运行的后台任务期间定期运行 calculate_deadlock_risk，以主动触发人工介入
run calculate_deadlock_risk periodically during long-running background tasks to preemptively trigger human-in-the-loop interventions.

# 运行 estimate_recovery_path 来决定是终止进程还是尝试强制状态重置
run estimate_recovery_path to decide whether to kill a process or attempt a forced state reset.

vim 实现需要将你的对话状态图（以表示 agent/状态的节点和表示转换的边）通过其定义的 schema 传入这些工具。

MCPs are the music of AI Agents. We built the catalog. Discover Vinkius MCP Catalog.