01 · 基础与运行循环

本课交付：三种终态的执行轨迹。读完完成 L1：画出运行循环，区分决策次数和工具执行次数。前置：开课指南。

一、场景：这一步要解决什么问题

你想让知识库回答：“活动开始前要执行提醒，应该选哪种延时任务方案？”第一次检索只找到概念介绍，没有故障恢复的说明。此时系统应该直接给出推荐，还是继续查资料？

这就是本章的切入点：把“回答问题”拆成可观察的动作。先不接复杂框架，只设计一个能根据搜索结果继续、澄清或停止的控制循环。

二、目标与方案设计

本章目标：能把一个 Agent 请求拆成“目标、状态、决策、动作、反馈、终止”，并解释模型与运行时各自负责什么。资料核对：2026-09-06。

Agent 的判断点在哪里

采用一种实用的架构区分：预先用代码确定主要执行路径的是工作流；让模型根据环境反馈动态选择步骤和工具的是 Agent。两者可以混合，Agent 也不意味着无限自主。概念来源。

“回答这段文字的摘要”通常可以一次生成完成。“查出这套服务今天为什么变慢”可能需要先查指标，再根据结果决定读哪份日志，路径难以预先固定。

什么时候不需要 Agent

任务步骤固定、数据完整、结果能直接验证时，先用普通程序或短工作流。例如每日把固定字段填入报表，通常不需要模型反复决定下一步。Agent 的灵活性可能增加耗时、费用与错误传播机会。选型依据。

四种容易混淆的应用

应用	模型参与的位置	下一步由谁决定	适合的例子
单次生成	一次回答	应用直接结束	把已提供材料整理成摘要
固定工作流	若干预设节点	程序控制主要路径	抽取字段、校验、生成报告
动态 Agent	循环选择动作	模型选择，运行时把关	不知道证据在哪的研究任务
混合系统	局部动态、整体受控	程序和模型分工	自主研究后进入固定审核流程

这是本专题的选型归纳。是否使用框架、有没有聊天界面、是否联网，都不能单独决定系统属于哪一种。一个工具只调用一次的任务，也可能处于 Agent 系统内部。

一个循环包含什么

用户目标 + 当前状态
        ↓
模型给出下一步：回答 / 调用工具 / 请求补充信息
        ↓
运行时检查参数、权限和预算
        ↓
执行工具 → 保存真实结果 → 更新上下文
        └──────────────────→ 下一轮

任务完成、需要人工输入、预算耗尽或不可恢复错误 → 停止

这里的“运行时”就是围绕模型编写的程序。它负责真正执行操作和保存状态。模型生成 search_notes(...) 的请求，不代表搜索已经成功。

ReAct：为什么要边行动边调整

ReAct 研究把推理与环境行动交替组织：行动提供新的观察，观察帮助修正计划。论文在问答和交互环境中评估这种方法，不能据此断言所有任务都应采用同一套路。ReAct，ICLR 2023。

在研究助手中，只在开始时写一个长计划可能遇到这样的问题：计划要求比较三篇文章，实际却发现其中一篇已过期。反馈循环允许助手改查新版本，或者缩小结论适用范围，而不是继续完成一个已经失效的计划。

可以用以下抽象描述循环。这是教学建模，不是论文原公式：

动作 a_t = 决策函数(目标 g, 当前可见上下文 c_t)
观察 o_t = 环境执行(a_t)
状态 s_(t+1) = 更新(s_t, a_t, o_t)
上下文 c_(t+1) = 选择(s_(t+1), 可用证据, 预算)

注意区分状态与上下文：完整状态可以在数据库中，但每次发送给模型的只是一部分。决策函数通常包含模型，执行函数则可能访问搜索服务、文件系统或业务 API。

实际应用不需要强迫模型打印完整内部推理。审计可以围绕可见计划、调用参数、观察结果和验收依据展开。工具调用格式、内部推理实现和研究论文里的提示格式也不是同一件事。

三、实现拆解

贯穿示例：搜索延时任务笔记

以下为教学轨迹，并非真实运行日志：

轮次	当前情况	下一步	可以确认的事实
1	用户想比较活动触发方案	搜索“延时任务 活动”	工具返回两个文档 ID
2	搜索结果只有摘要	读取相关段落	获得正文和来源位置
3	缺少恢复机制的信息	补充搜索“故障 恢复”	找到证据或明确缺失
4	证据足够支持有限结论	输出比较与不确定项	答案中的来源能被查回

模型可能一次请求多个工具，也可能第一轮就能回答。轮次不应被当成能力指标。

计划和执行要分开记录

计划可以写“比较三种方案”，执行记录则应写“已读取哪些材料、哪些问题还没有证据”。后续决策依据执行事实更新，而不是把原计划标成完成。

建议保存 pending → running → completed / failed / needs_input 等显式状态。状态命名是应用设计选择，不是 Agent 的统一标准。

停止条件要成为状态机的一部分

循环最容易被忽略的设计不是“如何继续”，而是“什么情况下不再继续”。建议把状态区分为：

状态	进入条件	是否能自动继续
running	正在收集证据或执行操作	在预算与权限内可以
needs_input	缺少用户必须决定的信息	收到所需输入后继续
completed	输出已通过约定验收	不应再次执行同一任务
exhausted	时间、调用量或费用达到上限	由应用决定是否重新安排
failed	发生不可恢复错误	修复原因后新建或恢复运行
cancelled	用户取消任务	不再调度新动作

取消和超时并不保证远端已发出的操作立即停止。因此任务结束状态与外部操作状态应分别保存。只读研究助手可以给出部分证据和停止原因；写入型助手还必须处理结果未知的操作。

用一次失败看清责任边界

假设模型要求读取 doc-17，工具返回“该文档不存在”。有三种不同责任：模型可能从未存在的 ID 中猜了一个；检索返回的 ID 可能过期；工具可能错误地解释了参数。仅修改提示词无法覆盖所有原因。

先比较调用 ID、搜索结果、读取参数和存储记录，再归因。把问题分成“选错动作、工具错误、证据不足、验收缺陷”，通常比笼统说“模型不聪明”更容易采取修复措施。这是本案例的排障建议。

推演一次没有证据的运行

先把知识库设为空。第一轮 search_notes 返回空列表，这是一次成功执行的搜索，不是系统异常。下一轮可以换查询，也可以声明资料不足；但不能把“没有查到”改写成“这些方案都不支持”。

对照实践章的离线示例，执行器负责保存搜索结果，脚本决策器选择 insufficient，最终状态为 insufficient_evidence。这个演练把三件事分开了：工具是否成功、证据是否充分、任务能否完成。真实模型接入后，可以改变第二轮的策略，但不能取消这些边界。

四、验证与练习

工程加深：给循环定义不变量

一个可控循环不只是 while 加调用上限。研究助手可以先约定四条不变量，再据此审查每个分支：

• 没有成功读取的材料不能进入已读证据集合；搜索摘要不等于正文。
• 模型只能提出动作，不能修改可信身份、预算或验收结果。
• 每次继续必须有理由：获得新证据、修正可定位错误，或者等待明确输入。
• 终态之后不再发起新动作；已发出的外部操作单独跟踪，不能被任务状态覆盖。

这些是本站提出的实现约束，不是某个框架的标准。比如连续两轮返回相同文档、相同版本、相同片段，即使查询文字不同，也可能没有信息增量。应记录“新增证据数量”和“尚缺的证据类型”，而不是只比较查询字符串。

把业务问题转成任务契约

“帮我研究延时任务”过于宽泛。进入循环前，整理为：比较对象、业务约束、资料范围、产物形式、必须回答的问题、停止条件。缺少负载数据时，可以先完成概念比较，但不能替用户确定容量选型。

允许：查阅授权笔记，提出条件化候选，列出需实测的事项
不允许：编造生产指标，擅自修改配置或发布文章
完成证据：每个主要比较项有来源，缺口单独列出
停止原因：完成 / 缺用户信息 / 资料不足 / 预算耗尽 / 故障

模型输出的 final 是“申请结束”，不是验收器的结论。这样换模型时，业务完成标准也不会跟着模型措辞变化。

小实验：什么时候值得增加循环

准备三组问题：答案就在输入里、答案在某篇笔记里、答案需要多篇相互补充的笔记。分别运行单次生成、固定检索工作流与循环研究助手。固定文档快照，记录成功与失败原因，同时记录耗时和调用次数。

假如只有第三组受益，就把循环用于第三组，而不必让所有请求都多轮运行。这个实验用来做本地选型，不预设哪种架构胜出。

自测与参考答案

1. 一个聊天机器人能调用天气接口，就一定需要多轮 Agent 循环吗？
2. 工具请求已发出，但没有收到结果，任务应是什么状态？
3. 为什么“模型说完成了”不适合直接作为业务验收条件？

参考：一次天气查询不一定需要循环；请求已发出但结果缺失时，应记录执行中或结果未知，而不是成功；完成必须由约定的输出或环境状态支持。

五、本章小结

本章交付的是控制循环，不是一段更长的提示词。复述一次运行时，应能指出“动作由谁提出、结果由谁记录、停止由什么触发”。下一章为这些动作定义工具契约，防止一个看似合理的请求在执行时越界。

六、参考资料

• ReAct 论文：理解行动与观察如何改变后续决策。
• Building effective agents：理解动态决策与预定义工作流的区别。
• LangGraph Persistence：进一步了解运行状态的持久化设计。

返回 Agent 专题目录。本文场景与推演为原创教学设计，参考写法及资料边界见专题目录。