用极简 Python 理解智能体执行循环

Agent 能调用一次工具，和它能稳定完成一项任务，中间还隔着一套执行机制。作者主张，先用模型、工具注册表、执行层和受控循环搭出最小架构，再按业务需要增加框架与基础设施。

这篇适合想理解 AI 编程助手如何连续干活的开发者。不过，标题里的「80 行 Python」需要先打个问号：提供的正文没有代码，也没有运行结果。它讲清了设计思路，却没有交付可以直接运行的实现。

Agent 的关键，是把执行结果送回模型

普通问答通常在模型输出后结束。Agent 则可能先采取行动，观察结果，再决定下一步。两者的差别，在于回答过程中是否形成了可继续执行的反馈循环。

作者把最小架构拆成五部分：用户目标、LLM、工具注册表、执行层和控制循环。用户目标定义要完成什么；LLM 判断下一步；工具注册表列出可用能力；执行层实际调用工具；控制循环把结果送回模型，并判断是否继续。

以原文的库存检查为例，用户要求查询库存，并整理需要补货的商品。模型发现缺少实时数据，选择库存查询工具；执行层检查请求、传入参数，拿到结果；模型读取结果后，再判断能否生成最终摘要。

模型提出行动，程序决定行动能否执行。

这条边界很关键。工具注册表告诉模型「有哪些能力可选」，却不能代替执行前的参数与权限检查。模型选中了某个操作，也不代表这个操作就应该直接运行。

循环也必须有出口。原文列出三类停止条件：模型给出最终回答、达到迭代上限，或遇到需要干预的错误。缺少退出条件，多步执行就可能变成重复调用。

先看懂循环，才能知道错误出在哪里

作者并没有否定框架。框架可以简化工具注册、记忆管理、编排与执行，但它不会自动让 Agent 可靠。

原文列出的几个故障，分别落在不同环节：选错工具，会把任务带偏；工具描述含糊，会诱发无效操作；返回结果缺乏结构，会干扰下一轮判断；没有执行上限，可能反复调用；错误处理薄弱，则可能让一次临时 API 故障拖垮整个流程。

这些问题不能统称为「模型不够聪明」。工具描述、结果格式、执行策略，都属于开发者能够控制的部分。

最小实现的价值，是让这些边界更容易看见。任务失败时，可以沿着「目标、决策、调用、结果、后续决策」逐步定位，而不是先面对多层抽象。不过，这只是架构层面的推理，作者没有给出框架与自写循环的对照实验，不能据此认定代码越少，可靠性就越高。

当应用需要多个 Agent 协作、持久化状态、复杂工作流编排和高级恢复机制时，作者认为框架开始有实际价值。判断依据应该是需要维护哪些能力，而不是框架提供了多少概念。

能跑起来以后，还欠哪些工程能力

原文引用了两组调查，说明「试验」与「稳定运营」之间存在距离。

据文中转述，McKinsey 的 State of AI 2025 报告中，62% 的受访者表示组织至少正在试验 AI Agent，23% 表示组织内已有某处在规模化使用 Agentic AI 系统。

LangChain 的 2026 State of Agent Engineering 报告调查了超过 1,300 名专业人士：57.3% 表示已有 Agent 投入生产，32% 将质量视为进入生产的主要障碍之一，89% 实施了某种形式的 Agent 可观测性，52.4% 开展了离线评估。

这两组调查不能拼成同一条增长曲线。它们的受访群体、提问方式和「生产」「规模化」口径，正文没有进一步解释。它们能支持的判断比较有限：工具调用成功，只是工程工作的起点。

作者给出的生产补强有五项：

1. 每次执行前检查参数、权限和操作类型。
2. 设置最大迭代次数、超时和重试上限。
3. 用结构化信息返回工具错误，并区分可重试与需人工介入的失败。
4. 记录模型决策、工具调用、执行耗时、错误和最终结果。
5. 为高影响操作设置适当审批。

其中，错误处理尤其容易被低估。把错误送回模型，只解决了「让模型知道失败」的问题；是否允许重试、何时停止，仍需要明确策略。原文强调了这个方向，但没有展示错误结构和具体判断规则。

我的判断

我认同作者把执行边界放在架构中心。对程序员而言，这比单纯演示模型会调用工具更有价值：真正需要维护的是整个任务过程，包括它如何失败、如何停止，以及失败后能留下什么证据。

但这份正文更适合当架构入门材料，不能当作「80 行 Python 实战教程」。它没有代码、测试任务、成功率、耗时或成本数据，也没有说明所用模型、API 与版本。标题里的行数无法从正文核验，「无需框架」也没有经过对照验证。

是否需要 Agent，应该先看任务是否需要动态决定下一步。

如果业务步骤已经固定，用普通程序串联工具调用，再在明确位置让模型处理文本，通常更容易检查执行路径。只有当工具结果确实会改变后续行动时，让模型参与循环决策才更有意义。这是站内的工程取舍，并非作者实测出的结论。

同样，已有持久化状态、恢复和编排需求的团队，也不必为了追求最小代码量重新造一套基础设施。原文最后穿插的开发、集成与咨询服务推荐，没有提供额外验证材料，不影响其核心思路，也不能充当效果证据。

能拿来做什么

• 在现有 AI 工具调用流程中，画清「模型选择、程序校验、工具执行、结果回传、停止判断」五个环节，检查权限判断是否真正发生在执行之前。
• 用 Node 做最小原型时，先选原文库存查询这类读取任务，并设置迭代、超时和重试上限，让失败过程也能被完整观察。
• 调试连续调用失败时，保留每轮工具名称、输入参数、返回结果、耗时与最终状态，沿调用过程定位问题，再判断是否需要调整模型。
• 引入框架前，列出确实需要的持久化状态、多 Agent 协作、复杂编排和恢复能力，用维护需求决定选型。