Agent实践:什么样的系统才叫 Agent?循环才是,单次调用不是(5/12)

感知、规划、行动、观察的循环——循环才是 Agent,单次调用不是

Agent课程第 5 讲封面:Agent 的本质

感知、规划、行动、观察的循环——循环才是 Agent,单次调用不是

上一讲结束我们留了个尾巴:一个程序每天定时帮你查天气,然后推送到手机,它算 Agent 吗?如果它查完之后,自己判断今天要不要提醒你带伞呢?

这两个程序看起来差不多,做的事情都是”查天气”。但前一个和 Agent 毫无关系,后一个才是。差别不在做什么,而在谁做决定。这一讲就把这条边界划清楚——它是后面所有 Agent 设计的起点。

问题一:查天气的程序,算不算 Agent?

先看第一个程序:定时触发,调天气接口,格式化结果,推送。每一步都是开发者写死的,代码怎么走,开发的时候就全定了。它能查天气,但它不知道自己在查天气——它只是顺着写死的路径跑一遍。

再看第二个:同样是查天气,但查完之后由模型自己判断——温度骤降了吗?降水概率多少?用户今天有户外日程吗?要不要提醒、提醒什么,都是模型现场决定的。

Anthropic 在官方指南里其实说的非常清楚:

原文引用Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks.

翻译成人话:路径在代码里写死的,是 workflow;路径由模型现场决定的,是 Agent。判据只有一个——控制流在谁手里。查天气脚本再复杂也是 workflow;自己决定要不要提醒带伞的,哪怕只做这一件事,也是 Agent 的雏形。

像不像流水线工人和现场工程师的区别?流水线每一步都有标准作业书,工程师到了现场自己拿主意。都是干活,控制流不在一个地方。

问题二:Agent 的循环,长什么样?

那”模型自己拿主意”具体是怎么跑的?拆开来其实就四步,循环往复:

感知(感知环境与输入)
  ↓
规划(决定下一步做什么)
  ↓
行动(调用工具,真的去做)
  ↓
观察(读取结果,评估效果)
  ↓
回到规划——直到任务完成

拿”要不要提醒带伞”走一遍:感知——读到今天的天气数据和用户日程;规划——判断降水概率高且有户外安排,决定生成提醒;行动——写出提醒文案并推送;观察——推送成功了吗?用户读了吗?然后回到规划,决定下一步。

这里有一个必须钉死的认知:单次调用不是 Agent,循环才是。咱们让一个模型写一段代码,它写得再好,也只是”一次调用”——它没有感知结果的环节,更没有基于结果调整下一步的机会。一个完整的 Agent,必须能走完”做一步、看结果、再决定”的循环。

但别急着把什么都改成 Agent。Anthropic 在同一份指南里给了一个非常清醒的提醒:

原文引用For many applications, optimizing single LLM calls with retrieval and in-context examples is usually enough.

Agent 不是 workflow 的升级版,它是一场交易:用更高的成本、更慢的响应、更不可控的路径,换取处理开放式问题的灵活性。步骤能预先穷举的任务,写 workflow 又快又稳;只有步骤数事先无法预测的任务,才值得请 Agent 上场。

杀鸡焉用牛刀。能写死路径的,就别上 Agent——牛刀贵,而且牛刀有自己的想法。

问题三:循环里,哪一步最容易翻车?

循环给了 Agent 灵活性,也给了它三次出错的机会。每一步都有典型的翻车姿势:

规划错   目标理解偏了——我们要 A,它理解成 B,
         后面每一步都精准地奔向错误
行动错   工具用错或参数给错——该读文件它去搜索,
         该改第 3 行它改第 30 行
观察错   结果误读——命令明明报错了,它读成了成功,
         带着错误状态继续往下跑

观察错是最郁闷的一种。规划和行动错了,至少结果摆在那里;观察错了,Agent 会把错误当正常,一层一层错下去,等咱们发现问题时,它可能已经走出十步了。

所以循环的每一步都需要”护栏”:规划要可检查、行动要有权限边界、观察要有验证标准。这些护栏怎么设计,是模块四的内容——第 9 讲(评估与迭代)和第 10 讲(安全与成本)会专门展开。今天先建立意识:循环不是放它自己跑,是让它在护栏里跑。

落到 sdd-site-agent:它的四步循环

回到贯穿项目。把咱们前几讲的设计拼起来,sdd-site-agent 的循环长这样:

感知   读当前任务(需求 a)+ 当前步骤规范
规划   决定这一步做什么:写需求/画原型/出方案/写代码
行动   调工具:读文件、写文件、跑命令
观察   产出符合规范吗?格式对吗?验收标准过吗?

不符合 → 回到规划,修正再来
符合   → 进入下一步,载入下一步的规范

注意它和前面几讲的咬合:感知环节用的是第 3 讲的分层加载,只载当前规范;上下文写满了,用第 4 讲的压缩和外部记忆;行动环节需要工具。工具从哪来?第 6 讲,我们讲工具设计。

实操演练(约 25 分钟)

必做部分 + 一步加餐。做完必做部分,本讲的核心手感就到手了。

画我们自己工作流的 Agent 化改造图
挑一个你工作中重复做的流程(周报、发布检查、数据巡检都行),画出它的四步循环:感知读什么、规划决定什么、行动用什么工具、观察看什么结果。然后标注:哪些步骤现在是”写死的路径”,改成 Agent 后哪一步交给模型决定。
你会发现,大部分流程 70% 用写死的 workflow 就够了,真正需要模型做主的只有一两步。这就是”能写死就不上 Agent”的实证
对照实验:单次调用 vs 循环执行
找一个有点小复杂的任务(比如”把一个长文档整理成结构化笔记”)。第一次用一个超长 prompt 让 AI 一次做完;第二次分步来:先让它读并列出要点,再把要点给它让它分类,最后让它成文。对比两次质量。
分步版明显更稳——这就是”循环”的价值:每一步都有观察结果、修正方向的机会
(加餐·选做)观察真实 Agent 产品的循环痕迹
打开一个 Agent 类工具(AI 编程助手等),给它一个需要多步完成的任务,观察它的输出:能不能认出”规划(它说要做什么)→ 行动(调工具)→ 观察(读结果)”的循环痕迹?把它循环了几轮记下来。
能清晰看到循环的脚印——看过的 Agent 内部循环,比读十篇介绍都直观。顺手记一条翻车现场:它在循环的哪一步出错(规划偏了/工具用错/结果误读)?这些翻车点,第 9 讲会把它们变成验收标准

检验一下

检索练习 · 本质判据
一个系统用了大模型,就能叫 Agent 吗?判断的核心标准是什么?

检索练习 · 循环结构
Agent 循环的四个步骤,正确的顺序是?

检索练习 · 使用时机
一个步骤能预先穷举的固定任务,为什么不该做成 Agent?

检索练习 · 哪步错最远
Agent 循环四步里,为什么说「观察错」最容易让系统翻车翻得最远?

课后作业一份产出,自己留存(第 6 讲直接用):

①sdd-site-agent 四步循环图:感知/规划/行动/观察各输入什么、输出什么,附工具清单初稿——这是第 6 讲工具设计的直接输入。

作业实现思路你刚画的四步循环,mini-agent 的loop.py就是它的代码版:感知(把历史发给模型)→ 规划(模型决定调工具还是回答)→ 行动(执行工具)→ 观察(结果喂回去),外加一道轮数护栏防失控。先自己动手做,再对照着看。mini-agent 的完整代码,后续我会分享出来——但别等它,先把你的设计做出来。
本讲一手来源

你如果想深挖一层,读这篇:Anthropic · Building effective agents

workflow 和 agent 的官方区分、五种 workflow 模式、”先求简单”的忠告都在里面。它也是第 8 讲(多 Agent 编排)的终审依据。另一个值得存的:Lilian Weng 的 Agent 综述,Agent 领域被引最多的文章。(沈剑注:”先求简单”这四个字,值很多钱——见过的过度设计,比见过的系统还多。)

但还有一个没解决的问题:循环里的”行动”要靠工具,可工具不是天上掉下来的——给 Agent 造什么手?手的形状怎么设计,它才用得顺手?——第 6 讲,我们讲工具设计。

知其然,知其所以然。思路比结论更重要。

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

京ICP备2025137728号-3