AI 洞察
30 分钟
Agent 不是一个功能，是一段循环
胡新宇
Published on 2026-07-09
ByteByteGo 7-08 最新文章把 Agent 拆成 perceive-reason-act-observe 四步循环，本文翻译成中文工程视角：把控制权交给模型之前你要想清楚的 3 笔账（compounding error、harness 成本、什么时候用 Workflow 替代）。
Loading...
Agent 不是一个功能，是一段循环
ByteByteGo 在 7 月 8 日发了一篇长文，标题是《The Agent Loop: How AI Goes From Answering Questions to Doing Things》。它做了件中文社区很少有人系统做过的事——把 Agent 最底层的循环骨架拆给你看。
看完那篇文章，我更确信一件事：Agent 不是一个功能，是一段循环。你写不写这段代码，决定了你的 AI 是一锤子买卖，还是一个能自我迭代、持续运转的系统。
工程圈过去一年谈 Agent，谈的是「记忆」「身份」「多 Agent 协作」「最后一公里」「企业落地」。这些都是上层建筑。地基是 loop——也就是 LLM 自己决定「下一步该做什么、何时停下来」的那段代码。这段代码的有无，把 Chatbot 和 Agent 区分开。
Chatbot 和 Agent 的距离，比你想的窄
文章里有一句话点得很准：
A chatbot answers a question, and an agent completes a task. This seems like a huge difference. However, the gap between the two is narrower than it appears.
翻译成中文就是：聊天机器人回答问题，Agent 完成任务。听起来天差地别，差距窄得超出你的想象。
为什么窄？因为它们的「内核」都是同一个东西——一次 LLM 调用。区别只在外层有没有套一个 loop。套了 loop，模型自己决定什么时候停；没套 loop，开发者写死调用一次就完事。
把控制循环的那行代码从开发者手里交给模型，就是 Agent 化的全部。
但你一交出去，三件事跟着来：自主性、不确定性、还有代价。这三件事不分清楚，Agent 项目十有八九会死在 PoC 阶段。
循环里到底发生了什么
ByteByteGo 把一次循环拆成四步，命名很工程师：perceive、reason、act、observe。
- perceive：循环把当前状态塞进模型——原始任务、到目前发生过什么、新进来的输入是什么。
- reason：模型思考「下一步该做什么」，可以问问题、调工具、或者直接给最终答复。
- act：运行时执行模型刚才决定要做的事。
- observe：把执行结果收回来，塞进状态，等下一次 perceive。
四步循环，模型每跑一轮，就在「我想清楚了」和「世界给我的反馈」之间来回跑一遭。Observe 是一等公民——拿不到这一步，循环就退化成链，模型只能靠「上次期望」而不是「这次真实结果」往下走。那叫闭着眼开车。
一次循环，模型能挑四条路
更细看，每轮 reason 完，模型的输出有四种归宿：
- Final answer：模型判定「我手上的够了」，输出最终答案，循环退出。
- Tool call：模型点名要调一个函数、把参数写好，运行时去执行、把结果塞回状态。
- Handoff：模型判定「这事归另一个 Agent 干」，运行时换身份继续 loop。
- Continued thought：模型没采取任何外部动作，只是把一段 reasoning 写进状态、让下一次循环接着想。
OpenAI 的 Agents SDK 把前三条作为一等行为，第四条更像是 prompt 写法带来的副产物。但不管哪种，模型在这一刻拍板的事，运行时负责执行——这条边界划清楚，你就不会再被「Agent 不听话」的问题反复困扰。
凭什么让模型自己拍板
讲到这里，技术问题变成了工程问题：凭什么让模型决定循环何时停止？
Workflow 派的答案是：开发者设计时就写死了几步、每步跑什么。Agent 派的答案是：模型自己拍板，开发者只设一个 max-turns 兜底。
这个差异就是「可预测性」和「灵活性」的取舍。Workflow 像可口可乐的装瓶厂——每个动作都固定，质量稳定、成本可控。Agent 像一支由模型当调度员的车队——灵活，但每趟活儿都得重新规划。
两种范式都该存在。工程师的工作，是判断你手上这个问题该交给调度员还是装瓶厂。
下一节把这三个隐性税算清楚。
三个让 Agent 项目「看起来活着但其实在亏」的隐性税
把控制权交给模型不是免费的。三笔账你不在立项前算清楚，半年后 PoC 转生产时会发现——Agent 不是不能用，是用错地方的代价太贵。
第一笔账：compounding error，连乘出来的 36%
ByteByteGo 给了个反直觉的算式：
If the model succeeds on each step of a loop 95 percent of the time, the joint probability of every step going right across ten steps is roughly 60 percent. Stretch that to twenty steps, and the joint success rate falls to about 36 percent.
单步 95% 成功率，看着像优秀。二十步连乘，剩 36%。 这是 Agent 落地最被低估的隐性税。
一个具体场景：让 Agent 帮你订出差行程——查航班、比价、选酒店、生成行程单、邮件通知。五个步骤，每步 95%，整条链跑通的概率 = 0.95⁵ ≈ 77%。看上去还行。
换成更复杂的企业场景：拉需求 → 拆任务 → 调工具查数据库 → 调 API 改记录 → 调 Notion 写文档 → 发邮件 → 财务系统补报销单。十步以上，整条链一次性跑通经常不到 60%。
Coding Agent 效果更好，不是模型更聪明。是测试反馈把单步可靠性从 95% 拉到 99%，链路长度从 20 步压到 5 步以内——代码能编译、能跑测试，错的立刻看见，循环里加入「自我校验」动作，可靠性立刻上一个量级。
这就是为什么「开放域任务型 Agent」至今没人敢上生产——没测试反馈托底，连乘就是赌命。
第二笔账：harness 比模型贵
Anthropic 2025 年底发了一篇博客，叫《Effective harnesses for long-running agents》。里面披露了一个内部实验：让 Claude Agent SDK 直接从高层 prompt 生成一个生产可用的 Web App。
结果：前沿模型直接跑，不及格。
团队的解法不是换模型，是给循环外面套了一堆 scaffolding：
- Initializer agent：开工前先把整个 feature 列表铺出来。
- 单 feature 编码 agent：每次会话只做一个 feature，做完收工。
- Progress file：把当前进度写到文件里，下一会话接着读。
- Git 历史：Agent 翻 git 记录就能从前一会话里恢复状态。
Harness 的复杂度，远比模型选型重要。 Anthropic 自己也说这是他们长期工程的"最大教训"。
这跟中文社区常说的一句糙话对得上：Agent 难用，不是 AI 不行，是中间件不行。 工具调用、状态恢复、上下文压缩、错误重试、Guardrails——每一项都是工程债。
第三笔账：选错工具的代价
ByteByteGo 的第三个 tradeoff 写得很直接：
An agent is often the wrong choice. It is important to find the simplest solution and only add complexity when needed, which sometimes means avoiding agentic systems entirely.
翻译：很多问题用 Agent 是错误选择。 Workflow 给你的是可预测、一致性、低成本；Agent 给你的是灵活性，但用延迟、钱、不可预测的失败面换。
OpenAI Codex 团队负责人 7 月初受访时更直白：「所有人都是 builder」是个糟糕的主意。把一切都丢给 Agent，等于把质量保证也丢出去了。
你省下的不是开发时间，是质量控制。 当公司需要一个"出错的成本是召回"的系统——比如改数据库、给客户发消息、跑支付——Agent 不该是默认答案。
什么时候用 Agent：决策树
把上面的账合在一起，画一张决策树：
1. 任务路径能否提前写死？
- 能 → Workflow（链式/Routing/Parallel/Orchestrator-Worker）。
- 不能 → 进入下一题。
2. 每一步是否有可验证的反馈？（编译、测试、API 返回、查询结果）
- 有 → Agent 是合理选择，但加 max-turns 兜底。
- 没有 → 别上 Agent，先补反馈环（比如人工审核节点）。
3. 失败一次的成本有多高？
- 低（重试无成本）→ Agent 自由跑。
- 高（涉及外部系统、写操作、客户感知）→ Agent 之上叠 Guardrails，否则别上。
4. 流程步骤数量级？
- ≤ 5 步 → Agent 完全胜任。
- 5-15 步 → Agent 可用，但加 progress file、checkpoint 持久化。
-
15 步 → 拆成多个 sub-agent，不要让一个 loop 跑全程。
这条决策树反着推也是对的——如果你的项目今天在用 Agent 跑但没有 progress file、没有 guardrails、步骤超过 15 步，那它大概率正在悄悄亏钱。
Guardrails：循环的每一道闸门
如果决定上 Agent，至少把闸门装齐。OpenAI 的 Agents SDK 给出了三层 Guardrails 的标准分类，这已经成了业界事实标准：
- Input guardrail：第一轮之前，拦 prompt injection、超出范围的输入、违规请求。常用做法是用一个小的快模型当门卫，过不了不让主模型跑。
- Tool guardrail：工具调用前后各一道闸。Tool input 拦/改请求，Tool output 拦/改返回。
- Output guardrail：最终答复生成后、用户看见前，最后一道闸——挡敏感数据、挡不该替公司说的话。
架构上的硬要求：Guardrails 必须在 loop 接触外界的每一个接缝上都装一道。 漏一道就是召回事故。
这一条 Anthropic、OpenAI、Cloudflare Agents 团队的工程实践是趋同的——没装齐的 Agent 不算上线。
Coding Agent 为何总能跑通：测试反馈托底
最后回应一个常见问题：「为什么 Coding Agent 比别的 Agent 跑得好？」
不是模型强。是反馈环短。
写代码 → 编译错 → 改；写测试 → 跑挂 → 修。每一步都有 ground truth 在等着你。 单步可靠性从 95% 拉高到 99%，5 步连乘 = 95% 整体成功。
任何想认真做 Agent 的团队，第一件事不是调 prompt，是给 loop 接一个 ground truth。 没有 ground truth 的场景，先想办法造一个——哪怕是 LLM-as-judge、哪怕是规则匹配、哪怕是抽样人工 review。
反馈环是 Agent 的氧气。 没氧气，模型再强也只在第一次吸气。
收尾：循环是地基，不是装饰
过去一年中文社区谈 Agent，谈 Memory、谈 Identity、谈多 Agent 协作、谈企业落地。这些都是二层楼。
地基是 loop——开发者把控制权交给模型的那一行代码。
这一行写下去，Agent 才有自主性、才有代价、才有"什么时候不该用"的工程判断。没想清楚这三件事就上 Agent，等于在没打地基的地方盖二层楼——不是不能用，是经不起一次失败。
下次你看到任何 Agent 类产品，先问三个问题：
- 它的 loop 在哪？（是自己决定的，还是开发者在背后设的）
- 它的 Guardrails 装齐了吗？（input / tool / output 三道闸门）
- 它的失败反馈从哪来？（没有反馈的 Agent 是赌博）
答不上来，那它就是包装过的 Chatbot，不是 Agent。
Agent 的本质不是更聪明的模型，是更成熟的工程。 把这件事看清楚，剩下所有 Agent 故事你都能自己拆。