01-agent-loop与控制流
核对日期：2026-05-13。
不稳定项：Agent SDK、模型工具调用能力、computer use、浏览器自动化、长上下文和规划框架变化较快；生产实现前必须以目标模型和 SDK 的最新能力为准。
1. 学习目标
本专题聚焦 Agent 的核心：受控循环。Agent 不是“会聊天的模型”，而是模型在系统约束下不断观察、决策、行动、更新状态并判断终止的执行系统。
学完后你应该能做到：
- 画出一个最小 Agent loop。
- 区分单次 LLM、Workflow、Agent 和多 Agent。
- 设计最大步数、预算、停止条件和升级条件。
- 识别循环、计划漂移、重复行动和目标丢失。
- 判断什么时候不应该使用 Agent。
2. Agent 的工程定义
工程上，Agent 可以定义为：
模型在一个受控循环中，根据目标、状态和环境反馈，动态选择工具、更新状态并推进任务的系统。
它至少包含：
- 目标：用户真正要完成什么。
- 状态：当前进展、事实、约束和未决问题。
- 决策：下一步做什么。
- 工具：搜索、读取、写入、执行或调用业务系统。
- 观察：工具返回和环境反馈。
- 控制流：循环、停止、重试、降级和交接。
- 权限：系统层允许或拒绝动作。
- 评测：任务和轨迹是否成功。
如果没有工具、状态和控制流，通常只是普通 LLM 调用；如果步骤完全固定，通常是 Workflow。
3. Workflow 与 Agent
| 维度 | Workflow | Agent |
|---|---|---|
| 控制流 | 代码预定义 | 模型动态选择 |
| 步骤数量 | 固定或有限分支 | 随任务变化 |
| 可预测性 | 高 | 中到低 |
| 成本 | 可控 | 波动较大 |
| 调试 | 看流程节点 | 看轨迹 |
| 适合 | 稳定流程、规则明确 | 开放任务、多步探索 |
| 风险 | 灵活性不足 | 循环、漂移、越权 |
判断原则：
能用规则解决 -> 规则
能用单次 LLM 解决 -> 单次 LLM
能用固定步骤解决 -> Workflow
路径难以预定义且工具反馈有价值 -> Agent
4. 最小 Agent Loop
state = init(task)
for step in 1..max_steps:
decision = model.decide(state, allowed_tools)
if decision.type == "final":
return final_answer(decision, state)
if !policy.allowed(decision.tool, decision.args, state):
return escalate("tool_not_allowed", state)
observation = tool.run(decision.tool, decision.args)
state = update_state(state, decision, observation)
trace.record(step, decision, observation, state)
if budget.exceeded(state):
return escalate("budget_exceeded", state)
if stuck_detector.repeated(state):
return escalate("agent_stuck", state)
return escalate("max_steps_exceeded", state)
关键控制点：
allowed_tools由系统给定，不由模型自己发现高风险工具。policy.allowed是系统判断，不能只靠 Prompt。update_state要结构化，不是把所有历史塞回上下文。trace要能回放每一步。max_steps和budget是硬约束。
5. Stop Conditions
Agent 必须知道什么时候停。
| 停止条件 | 说明 |
|---|---|
| 完成任务 | 达到成功标准 |
| 信息不足 | 缺少必要证据或权限 |
| 达到最大步数 | 防止循环 |
| 达到预算 | 控制 token、时间和工具成本 |
| 工具失败 | 超过重试阈值 |
| 需要人工确认 | 高风险动作或证据冲突 |
| 安全策略拦截 | 注入、越权、敏感动作 |
没有停止条件的 Agent 不是真正的自动化，而是不可控的循环。
6. 计划与执行
计划可以帮助 Agent 组织任务，但计划不是合同。
计划字段建议：
| 字段 | 说明 |
|---|---|
goal | 原始目标 |
success_criteria | 成功标准 |
steps | 初始步骤 |
current_step | 当前步骤 |
assumptions | 当前假设 |
blocked_by | 阻塞项 |
revision_reason | 计划修改原因 |
每次计划变化都应记录原因，例如：
- 发现原假设不成立。
- 工具返回新证据。
- 用户补充约束。
- 权限不足。
- 成本或时间超预算。
7. 计划漂移
计划漂移常见表现：
- 忘记用户原始目标。
- 做无关子任务。
- 重复搜索相同关键词。
- 工具结果不支持下一步仍继续推进。
- 把“草稿”误当成“已执行”。
- 计划变化没有解释。
防护：
- 状态中保存
goal和success_criteria。 - 每步决策要求说明服务目标的关系。
- 检测重复工具调用。
- 高风险动作前做人工确认。
- trace 评测每一步是否必要。
8. Orchestrator Patterns
常见 agentic 模式：
| 模式 | 适用 | 风险 |
|---|---|---|
| ReAct | 搜索、工具使用、资料整理 | 思考漂移、工具误用 |
| Plan-and-Execute | 多步任务 | 计划过早失效 |
| Evaluator-Optimizer | 写作、代码修复 | 循环成本高 |
| Orchestrator-Workers | 可拆分复杂任务 | 子任务边界模糊 |
| Supervisor | 多 specialist 调度 | 过度架构 |
选择模式之前先问：固定 Workflow 是否足够？是否真的需要模型动态决定下一步？
9. 工程案例
9.1 只读代码库分析 Agent
目标：定位某功能实现和风险点。
循环：
- 解析问题。
- 搜索文件。
- 读取候选文件。
- 总结调用链。
- 如果证据不足，继续搜索。
- 输出带路径引用的结论。
控制：
- 最大 8 步。
- 只读工具。
- 不允许执行写入命令。
- 输出必须引用文件路径。
9.2 研究资料整理 Agent
目标：生成带引用的主题简报。
控制：
- 来源必须可访问。
- 快速变化信息标核对日期。
- 观点和事实分离。
- 不把未核实内容写成结论。
10. 常见反模式
| 反模式 | 表现 | 后果 | 修正 |
|---|---|---|---|
| 固定流程强行 Agent | 明明 3 步固定还让模型规划 | 成本高、不可控 | 用 Workflow |
| 无最大步数 | 一直搜索和重试 | 成本失控 | max_steps |
| 状态靠聊天历史 | 上下文膨胀 | 遗忘和污染 | 结构化状态 |
| 停止条件模糊 | 不知道何时完成 | 输出随机 | success criteria |
| 计划不更新原因 | 行为不可解释 | 难复盘 | revision_reason |
11. 练习
为“代码库只读分析 Agent”写一段 loop 伪代码，要求：
- 最大 8 步。
- 工具只允许 search/read。
- 每步记录 trace。
- 找不到证据时拒答。
- 重复搜索 2 次后停止并升级。
12. 验收题
- Agent 和 Workflow 的控制流差异是什么？
- 最小 Agent loop 必须包含哪些机制？
- 为什么
policy.allowed不能交给模型自己判断？ - 计划漂移有哪些表现？
- Agent 应该在哪些情况下停止或升级？
- 为什么“多个模型聊天”不等于多 Agent 系统？