夜雨聆风2026 年，"Agent"大概是 AI 圈被用烂的第一个词。
每隔三天就有一个新框架宣称自己解锁了"真正的 Agent 能力"，每隔一周就有人在推特上画出比航天飞机还复杂的多 Agent 架构图。创业者在 pitch deck 里写满了 Agent，投资人的嘴里也全是 Agent。
但如果你拉住任何一个人问："Agent 到底是什么？"——大概率你会得到一段模糊的、充满术语的、本质上什么都没说的回答。
直到 OpenAI 自己下场，发了一份 34 页的实战指南。
翻完整份 PDF，X 上有个开发者 @shmidtqq 写了一条总结帖，把 34 页浓缩成了一个判断：
"The key insight: the agent is not the model, it is the loop around it. The same model in one call is a chatbot. The same model in a loop, with tools and an exit condition, is an agent."
「关键洞见：Agent 的本质是围绕模型的那个循环。同一个模型调用一次就是聊天机器人；放进循环，配上工具和退出条件，就成了 Agent。」
这条帖子拿下 172 赞、1.6 万次浏览——在技术圈，这算得上刷屏级别。
▲ @shmidtqq 把 34 页指南浓缩为"Agent is a loop"，1.6 万浏览
34 页写了什么？OpenAI 把底裤都亮了
这份指南叫A Practical Guide to Building Agents，挂在 OpenAI Business 页面上，面向产品和工程团队。
打开目录，结构极其干净：
What is an agent?（什么是 Agent） When should you build an agent?（什么时候该建） Agent design foundations（设计基础） Orchestration（编排） Guardrails（护栏）
没有废话，没有营销包装。34 页全是从真实客户部署中提炼出的实战经验。
▲ OpenAI 官网指南落地页，目录结构一目了然
先看 OpenAI 怎么定义 Agent：
"Agents are systems that independently accomplish tasks on your behalf."
「Agent 是能代表你独立完成任务的系统。」
注意"独立"两个字。你给 ChatGPT 发一条消息，它回你一条——这是聊天。你给一个系统目标、工具和规则手册，它自己决定查什么资料、调什么 API、写什么草稿，遇到错误自己重试，最后达成你定义的"完成标准"——这才是 Agent。
指南特意划了一条线：集成了 LLM 但没有把工作流执行的控制权交给 LLM 的应用——简单聊天机器人、单轮 API 调用、情感分类器——统统不算 Agent。
三件套：Model、Tools、Instructions
OpenAI 把 Agent 的地基拆成三个组件：
01 Model——LLM 本身，负责推理和决策。选什么模型取决于任务复杂度和延迟要求。
02 Tools——模型能调用的外部函数和 API。这是 Agent 伸向真实世界的手脚。指南把工具分成三种：
- Data 工具
：读取信息（查数据库、搜网页、读 PDF） - Action 工具
：执行操作（发邮件、更新 CRM、转人工） - Orchestration 工具
：把另一个 Agent 当工具调用
03 Instructions——明确的行为指南，告诉 Agent 怎么做、什么能做、什么不能做。
用代码写出来就是这样：
weather_agent = Agent( name="Weather agent", instructions="You are a helpful agent who can talk to users about the weather.", tools=[get_weather], ) 看起来简单到离谱。但这段代码本身只是一个静态定义——接下来的部分，才是让它活过来的关键。
灵魂段落：while loop 才是整个引擎
这是整份指南最核心的一段话：
"Every orchestration approach needs the concept of a 'run', typically implemented as aloopthat lets agents operate until an exit condition is reached."
「每种编排方式都需要一个'运行'的概念，通常实现为一个循环，让 Agent 持续操作直到满足退出条件。」
紧接着，指南直接点明：
"This concept of a while loop is central to the functioning of an agent."
「while loop 这个概念是 Agent 运行的核心。」
白纸黑字，OpenAI 亲手写的。
翻译成人话就是：模型运行 → 决定调用哪个工具 → 拿到工具结果 → 把结果喂回去 → 模型再运行 → 再决定 → 再调用……如此循环，直到触发退出条件。
用伪代码表示这个过程：
while True: response = model.run(context) if response.is_final_output() or response.has_no_tool_calls(): break # 退出循环 tool_results = execute_tools(response.tool_calls) context.append(tool_results) # 结果喂回去，继续转 就这么几行。这就是 Agent 的全部架构骨架。
OpenAI Agents SDK 里的Runner.run()方法，封装的正是这个 while 循环。SDK 文档说得很明白：想自己控制循环，用 Responses API；想让框架帮你管循环、工具、护栏和状态传递，就用 Agent + Runner。
▲ OpenAI Agents SDK 文档，清晰展示 Runner 内部的 loop 运行机制
退出条件只有两种：
模型调用了一个被标记为"最终输出"的工具（ final_output）模型直接回复文本，没有发起任何工具调用
没有第三种。
退出条件：最容易被忽略、也最容易烧钱的地方
@shmidtqq 在帖子里专门强调了这一点：
"The exit condition is the design: the loop stops on a clear rule. You define when it stops, not 'until it is done'."
「退出条件是设计决策：循环在明确规则下停止。停止时刻由你定义，不能交给一句'直到做完'。」
这绝对是实话。
"直到做完"听起来很合理，但在实际部署中，它恰恰是成本失控的起点。社区里有人分享过真实案例：一个没有设好退出条件的 Agent 跑了11 天，烧掉了4.7 万美元。模型在循环里不断调用工具、不断拿到新数据、不断决定"还没完"——然后账单就这么滚上去了。
反过来，设计好退出条件和工具边界的 Agent loop，能让一个人在一个月内产出259 个 Pull Request——这也是真实的生产数据。
同一个 while 循环，有刹车和没刹车，天差地别。
先把一个 loop 打磨到极致
指南里有一个建议，可能会让很多"多 Agent 架构师"不太舒服：
先别急着搞 swarm。
OpenAI 强烈建议先把单个 Agent 加工具的能力做到极致。只有当你的 prompt 里出现大量 if-then-else 分支、工具数量太多且功能重叠的时候，再考虑拆分成多个 Agent。
指南给了两种多 Agent 模式：
Manager 模式——一个中央 Manager Agent 把子 Agent 当工具调用，保持单一控制点。比如一个翻译 Manager 调用西班牙语、法语、意大利语三个子 Agent。
Handoff 模式——对等的 Agent 之间互相交接控制权。比如一个分诊 Agent 根据问题类型把用户交给技术支持、销售或订单处理 Agent。
但两种模式的前提都是：你已经证明单 Agent 搞不定了。
很多团队一上来就搞四五个 Agent 互相喊话，结果调试时发现状态传递一团乱麻。先把一个 loop 跑顺，比搭建任何花哨的 Agent 网络都重要。
给 loop 装上护栏
一个裸奔的 while 循环在生产环境里只有一个结局：出事。
所以指南用了整整 8 页讲 Guardrails（护栏），把防御做成多层结构：
LLM 层——用分类器做护栏。包括相关性分类器（防止 Agent 跑题）、安全分类器（拦截 jailbreak 和 PII 泄漏）、对话循环检测器（发现 Agent 在原地打转）。
规则层——黑名单、正则匹配、长度限制。简单粗暴但有效。
工具层——给每个工具标风险等级。只读操作标"低风险"，可逆操作标"中风险"，涉及财务或不可逆操作标"高风险"。高风险工具触发人工审批。
人机回环——这是最后一道防线。指南的原话：高风险动作必须有人类审批，直到系统置信度足够高。失败次数超过阈值时，Agent 必须把控制权交还人类。
SDK 的实现方式很聪明：主流程乐观执行，护栏并发检查。护栏没触发，用户无感知；护栏触发了，抛出异常，中断循环。兼顾体验和安全。
开发者社区的反应：真香
这份指南在多个渠道引发了大量讨论。
@AnatoliKopadze 做了一件更狠的事——把 34 页压缩成了1 页架构图。6 个阶段、1 个循环，从 Goal + Input → Model → Tools → Instructions → Guardrails → Evals，底层跑着 Traces + Logs + Feedback 持续改进层。这条帖子拿到了601 赞、7.5 万次浏览。
▲ @AnatoliKopadze 把 34 页压缩成 1 页，6 stages + 1 loop，601 赞
Reddit 的 r/AI_Agents 社区也在热议。有用户指出指南覆盖了架构、工具迭代循环和安全护栏三个关键层面，评价是"this type of docs are really helpful"。Indie Hackers 上有开发者做了详细的 breakdown，称赞其"really good"。
▲ Reddit 上开发者对指南的讨论
有一条评论特别精辟：
"The agent is not the model, it's the loop around it — is such a clean way to put it."
「Agent 的本质是围绕模型的那个循环——这表述太干净了。」
当然，也有清醒的声音。有评论指出这是给开发者在 OpenAI API 上构建 Agent 的实战指南，不要误读成"OpenAI 内部用的模型架构"。还有人对 exit condition 表达了直觉上的焦虑："'Until it is done' is where agents get expensive and weird."——"直到做完"，恰恰是 Agent 变贵和变诡异的起点。
从调 prompt 到设计 loop
回到那个最根本的问题：这 34 页到底改变了什么？
它把过去一年多笼罩在 Agent 概念上的迷雾一扫而光。
很多人以为"更好的 prompt = 更好的 Agent"，以为给 GPT 写一段更长更精妙的系统提示词就能让它变成自主 Agent。OpenAI 用自己的生产经验告诉你：prompt 只是配置项，loop 才是架构。
同一个模型，一次调用就是聊天机器人。 同一个模型，放进一个设计过退出条件的循环，配上精选的工具和分层的护栏——就是能帮你干活的 Agent。
这份指南给出的起步建议也极其务实：
先选一个适合 Agent 化的工作流（复杂、多步骤、需要判断力） 先搭单个 loop + 少量工具 用真实用户去验证 逐步加护栏、加工具、加 eval 遇到瓶颈了再拆多 Agent
"Start small, validate with real users, and grow capabilities over time."
「从小处开始，用真实用户验证，随时间逐步扩展能力。」
计算机科学里最朴素的原语——一个 while 循环——被证明是 Agent 时代最核心的构建单元。34 页 PDF 的分量，全压在这几行代码上。
接下来的战场，属于懂得设计这个循环的人。
