AI Agent 别再写成脚本了：循环架构设计指南

大多数 AI Agent 代码的问题

如果你最近上线过一个 AI Agent，有很大概率它本质上就是一个花哨的脚本——你发一个 prompt，收到一个响应，也许再串起几次调用，打个日志，完事。Demo 演示时这完全没问题。但一旦你需要这个 Agent 能够：

判断自己的输出是否足够好、是否可以继续

生成子 Agent 来处理特定任务

从 API 错误或胡编乱造的内容中恢复

解释为什么它在三步之前做了某个决策

……你的脚本就土崩瓦解了。

你缺少的是循环架构（loop architecture）——这就是控制 Agent 如何推理、如何行动、如何评估、如何决定下一步做什么的那个控制结构。大多数团队把这当成事后才考虑的事。不应该这样。

循环架构实际长什么样

把循环架构想象成 Agent 的运行时（runtime）。它不是模型，也不是 prompt。它是包裹在两者之上的脚手架，强制执行以下内容：

状态管理：Agent 做了什么？它知道什么？

评估逻辑：那个动作成功了吗？我们应该重试、委托，还是停止？

控制流：接下来发生什么？是再循环一次，还是调用另一个 Agent，还是返回给用户？

下面是一个伪代码示例：

class AgentLoop:
    def __init__(self, task, max_iterations=5):
        self.task = task
        self.state = {"steps": [], "status": "running"}
        self.max_iterations = max_iterations

    def run(self):
        iteration = 0
        while self.state["status"] == "running" and iteration < self.max_iterations:
            action = self.reason(self.state)
            result = self.execute(action)
            self.state = self.evaluate(result, self.state)
            iteration += 1
        return self.state

    def reason(self, state):
        # LLM call: "given state, what should I do next?"
        pass

    def execute(self, action):
        # Actually do the thing (API call, DB query, spawn sub-agent)
        pass

    def evaluate(self, result, state):
        # LLM or deterministic check: did it work? update state accordingly
        pass

注意这个循环不是无穷的。它有预算。它会检查自己的输出。它在多次迭代之间维持状态。这才是一切的基础。

你会遇到的失败模式

一旦你开始构建循环，很快就会遇到以下这些失败模式：

你的编排 Agent 判定每个子任务都需要自己的 Agent。结果你突然搞出了 47 个并行的 LLM 调用，API 配额直接爆掉，而且你根本不知道是哪一个调用导致失败。

修复：对生成深度和广度设置硬限制。显式跟踪 Agent 树。

Agent 忘记了两步之前自己做了什么，因为你在调用之间没有持久化状态。它重复工作、自相矛盾，或者陷入无限循环。

修复：结构化状态（JSON，而不是感觉）。记录每一次状态转换。让它可查询。

你的循环没有清晰的成功或失败条件。它只是……一直运行直到超时。

修复：显式的停止条件。"任务完成"、"不可恢复的错误"、"预算耗尽"。把这些当作控制流中的头等公民来对待。

治理不是可选项（尤其在英国）

如果你在金融、医疗、法律或公共部门构建 Agent，治理问题不能一笔带过。循环架构正是你强制执行以下内容的地方：

审计追踪：每个决策、每个动作、每次状态变更

人工介入门控：某些动作在执行前需要审批

回滚和重放：如果出了问题，你可以倒带并调试

这不是理论。如果你的 Agent 做了一个影响金钱或人员的决策，你需要能够解释它为什么那样做。这个解释存在于你的循环架构中，而不是对你 prompt 历史的感觉检查里。

如果你正在重构一个现有 Agent 或从零开始

显式化状态。使用 schema。给它加版本号。持久化它。

提前定义停止条件。成功、失败、预算耗尽。

给所有东西加上检测。记录状态转换、决策和评估。当出问题的时候你会需要这些。

设置硬限制。最大迭代次数、最大生成深度、每次循环的最大成本。

把评估构建到循环里。不要等到上线了才发现你的 Agent 一半时间都在胡编。

结论

循环架构是 Demo 演示时让人眼前一亮、与实际可信赖的生产系统之间的区别。大多数团队跳过这一步，因为它不如微调模型或精心设计 prompt 那么令人兴奋。但它是一切其他东西得以运作的脚手架。

像对待任何其他关键系统组件一样对待你的 Agent 运行时：严谨、可观测、正视失败模式。你未来的 on-call 自己会感谢你。