为什么你的多智能体 AI 系统可能是个定时炸弹

Dev.to AI 2026-08-12T12:28:07.630231

摘要：很多多智能体 AI 系统在演示时表现完美，可一上生产环境就问题频发：API 费用暴涨、日志里满是循环推理、智能体一本正经地胡言乱语。问题不在于提示词写得好不好，而在于你把智能体编排当成了写脚本，其实它应该被当作分布式系统来设计。本文从架构角度剖析了多智能体系统的设计要点，帮助你避开那些隐藏的坑。

假设你已经构建了一个多智能体 AI 系统——也许是能派生专家智能体的研究助手，也许是能把任务分派给各领域专家的客户服务编排器。演示时一切正常，大家纷纷叫好。可一旦投入生产，API 费用开始失控，日志里反复出现同一条推理路径，智能体还开始大规模生成看似合理、实则毫无意义的输出。是不是觉得很眼熟？

很多人第一反应是“提示词写得不够好”，于是拼命调 prompt。但真正的问题往往不在提示工程，而是你把智能体编排当成脚本在写，却忘了它本质上是一个分布式系统。

循环本身就是系统

当你把大语言模型（LLM）调用串起来，并允许它派生子任务时，你构建的不再是一个简单的提示词流程，而是一个控制流系统——这个系统的每个节点都是不确定的。每一次决策都可能产生分支，每一次智能体生成都可能触发无限递归。

看下面这段伪代码：

def orchestrator(task):
    subtasks = llm.decompose(task)
    results = []
    for subtask in subtasks:
        if is_complex(subtask):
            results.append(orchestrator(subtask))   # 递归调用
        else:
            results.append(specialist_agent(subtask))
    return llm.synthesize(results)

看起来挺合理，对吧？那你需要追问自己几个问题：

这些问题都不是提示词能解决的，它们属于架构问题。

三个需要显式设计的要点

如果你打算做生产级多智能体系统，就必须把“循环”当成头等工程大事来对待。这意味着以下三件事要显式设计，不能靠碰运气。

1. 生成逻辑：给“派生智能体”立规矩

你的编排器需要清晰、可测试的规则来决定何时派发子任务。“让 LLM 自己决定”远远不够，你需要护栏。比如：

class SpawnPolicy:
    max_depth: int = 3
    max_children_per_node: int = 5
    cost_ceiling_per_branch: float = 0.50

    def should_spawn(self, context: TaskContext) -> Decision:
        if context.depth >= self.max_depth:
            return Decision.EXECUTE_INLINE
        if context.current_cost + context.estimated_cost > self.cost_ceiling:
            return Decision.SIMPLIFY
        return Decision.DELEGATE

这不是在限制智能体的能力，而是让资源消耗变得可预测。生成子智能体的逻辑，应该像其他系统边界一样，可观测、可测试、可审计。

2. 状态管理：明确谁该知道什么

当智能体不断生成子智能体时，上下文由谁负责？如何避免把完整的对话历史一股脑塞给每个新生成的智能体？哪些中间结果需要逐级汇总回主控？

你需要明确的状态边界：

把智能体之间的交互当作微服务来对待，定义清晰的契约和接口，而不是让所有信息无序流动。

3. 终止条件：知道什么时候该停

你的循环需要明确的停止条件。这里的难点在于，LLM 永远觉得自己“还能再完善一点”，所以你不能只靠“任务完成”这种模糊信号，而要有硬性限制：

这些条件应该内建于架构之中，而不是等到出问题再补救。

生产环境的现实检验

团队真正缺失的，往往不是更好的提示词，而是把智能体循环当作分布式系统来认真对待。具体来说，你需要做到：

如果你正在把 AI 自动化和软件开发能力做成产品，这些东西不是锦上添花，而是生存底线。

从小处着手，全面埋点

你不需要第一天就解决所有问题，但你必须认识到：这个循环本身就是你的架构。先从让生成决策可观测开始：

然后在此基础上逐步迭代和优化。

关键要点

查看原文