跳到主要内容

Agent 工作流：不是让模型“自己聊”，而是把任务变成可控执行链

很多人一说 Agent，就想到“模型自己思考、自己决定、自己干活”。这个理解太泛了。更准确的理解是：Agent 工作流（Agent Workflow）本质上是在任务执行过程中，把模型决策、工具调用、状态流转、检查回路和人工介入组织成一条可控的运行链。

0. 面试速答（30 秒版 TL;DR）​

  • Agent 工作流不是单轮问答，而是“状态 + 路由 + 工具 + 终止条件”的组合。
  • 常见模式包括：
    • ReAct 循环
    • Plan-and-Execute
    • Router
    • Reviewer / Supervisor
    • Human-in-the-loop
  • 不是所有任务都需要 Agent。
    • 简单问答、固定表单、纯确定性流程，通常没必要上 Agent。
  • 真正的难点不在“让模型会想”，而在：
    • 工具定义清不清楚
    • 状态能不能恢复
    • 终止条件稳不稳
    • 结果能不能评估
  • 一句话：Agent 工作流的核心不是更聪明，而是更可执行、更可观测、更可控。

1. 先分清：工作流不等于完全自治 Agent​

这是面试里最容易拉开层次的一点。

可以把它们粗分成两类：

  • 工作流（Workflow）：很多步骤、分支和工具调用，是由开发者预先定义好的。
  • Agent：模型在运行中拥有更强的动态决策权，决定下一步做什么、调哪个工具、何时结束。

真实系统里，大多数并不是纯粹二选一，而是：

  • 确定性流程 + 模型决策节点 的混合结构

所以你可以这样记：

  • 工作流偏“预设路径”
  • Agent 偏“动态路由”

最常见的生产实践，其实是两者混合。

2. Agent 工作流的核心心智模型​

不要把 Agent 工作流想成“多轮聊天”。更好的心智模型是：

  • 用户提出目标
  • 系统维护状态
  • 模型决定下一步
  • 工具返回外部事实
  • 检查器判断是否通过
  • 不通过就继续循环
  • 达到终止条件才结束

先记主链路：目标 -> 状态 -> 路由 -> 执行 -> 检查 -> 结束，不达标时再回到路由节点。

这张图说明了 Agent 工作流和普通问答的根本差异：

  • 它有 状态
  • 它有 工具
  • 它有 循环
  • 它有 检查
  • 它有 退出条件

3. 组成一个 Agent 工作流，通常要哪些构件​

3.1 状态（State）​

状态不是附属品，而是核心。

通常至少包括：

  • 用户目标
  • 中间结果
  • 已调用工具记录
  • 当前步骤
  • 错误信息
  • 人工批注

如果没有显式状态，复杂流程很快会乱。

3.2 工具（Tools）​

工具是 Agent 真正和外部世界交互的手。

常见工具包括：

  • 搜索
  • 数据库查询
  • HTTP API 调用
  • 文件读写
  • 代码执行
  • 业务动作执行

一个 Agent 没有工具，很多时候就只是“会说话的助手”，不是“能执行的系统”。

3.3 路由（Routing）​

路由决定：

  • 该回答
  • 该搜资料
  • 该调工具
  • 该转人工
  • 该结束

没有路由，工作流只会变成固定链条，无法适应复杂任务。

3.4 检查器（Reviewer / Judge）​

这是很多人最容易漏掉的一层。

如果没有检查器，你就只能相信模型第一版答案。但真实任务通常需要：

  • 完整性检查
  • 格式检查
  • 事实依据检查
  • 业务规则检查

3.5 终止条件（Stopping Conditions）​

必须明确：

  • 最大循环次数
  • 成功判定
  • 失败退出
  • 人工接管条件

否则 Agent 很容易进入高成本空转。

4. 常见 Agent 工作流模式​

4.1 ReAct：边想边做​

这类模式通常是：

  • 先思考当前情况
  • 决定调用哪个工具
  • 根据工具结果继续思考

优点：

  • 简单直接
  • 对单任务型工具代理很常见

缺点：

  • 状态和可观测性容易做浅
  • 复杂任务下容易反复横跳

4.2 Plan-and-Execute：先规划，再执行​

常见做法是：

  • 先由 Planner 拆任务
  • 再由 Executor 执行各子步骤
  • 必要时由 Reviewer 返工

它更适合：

  • 长任务
  • 可拆分任务
  • 需要多阶段交付的任务

4.3 Router：先分类，再走不同路径​

例如：

  • FAQ 问题直接回答
  • 资料问题走 RAG
  • 高风险动作转人工审批

这类模式本质上是在做 动态分流。

4.4 Supervisor / Multi-Agent：角色分工协作​

典型形态是：

  • Supervisor 分派任务
  • Researcher 查资料
  • Executor 执行
  • Reviewer 审查

它的优势是职责清晰，缺点是成本和调试复杂度更高。

4.5 Human-in-the-loop：把人工审批放进链路​

这对高风险任务非常重要，例如：

  • 发邮件
  • 改正式数据
  • 调资金接口
  • 发布线上配置

成熟系统不是追求“完全无人”，而是追求“该自动自动，该确认确认”。

5. 一个最小可落地示例​

下面给一个极简的 TypeScript 风格伪代码，帮助建立结构感：

type WorkflowState = {
  goal: string
  step: 'route' | 'retrieve' | 'act' | 'review' | 'done'
  category?: 'faq' | 'search' | 'action'
  docs?: string[]
  result?: string
  attempts: number
}

async function runWorkflow(state: WorkflowState) {
  while (state.step !== 'done' && state.attempts < 5) {
    if (state.step === 'route') {
      state.category = await classifyGoal(state.goal)
      state.step = state.category === 'faq' ? 'review' : 'retrieve'
    } else if (state.step === 'retrieve') {
      state.docs = await searchDocs(state.goal)
      state.step = 'act'
    } else if (state.step === 'act') {
      state.result = await callModelWithTools(state.goal, state.docs)
      state.step = 'review'
    } else if (state.step === 'review') {
      const passed = await reviewResult(state.result)
      state.step = passed ? 'done' : 'retrieve'
      state.attempts += 1
    }
  }

  return state
}

这个示例虽然简化，但它已经体现出 Agent 工作流最关键的 4 个点：

  • 有显式状态
  • 有路由
  • 有工具阶段
  • 有检查与退出

6. 为什么状态和终止条件是一等公民​

很多 Agent Demo 看起来很聪明，但一上线就出问题，原因经常不在模型本身，而在工作流设计。

6.1 没有显式状态，流程很难恢复​

如果一次任务跑了很久，中途断了：

  • 断在哪一步
  • 哪个工具已经执行过
  • 哪些中间结果还能复用

都需要状态来支撑。

6.2 没有终止条件，成本会失控​

没有终止条件的 Agent 很容易出现：

  • 一直查资料
  • 一直重试
  • 一直自我反思

最后不是答案更好了，而是 token 更贵了。

6.3 没有观测，排障几乎不可能​

你至少要知道：

  • 每一步走了什么路由
  • 调了什么工具
  • 哪一步失败
  • 最终为什么结束

否则 Agent 出错时，你只能“感觉它不太对”。

7. 什么场景适合 Agent 工作流​

更适合的通常是：

  • 多步骤任务
  • 需要工具调用
  • 有中间检查点
  • 成功标准相对明确
  • 允许分阶段推进

例如：

  • 客服助手接知识库和工单系统
  • 编码助手接搜索、编辑、测试工具
  • 研究助理接检索、阅读、总结、审校流程

8. 什么场景不适合​

不适合硬上 Agent 的通常是：

  • 单轮问答
  • 纯模板填充
  • 完全确定性的业务流
  • 没有工具也没有外部动作的简单聊天

如果任务本身就是固定规则，用普通代码往往更稳定、更便宜。

9. 如何评估一个 Agent 工作流是不是好​

不要只看最终回答像不像。

成熟评估至少拆成这些维度：

9.1 任务成功率​

有没有真的把任务做完。

9.2 工具调用质量​

包括：

  • 调没调对工具
  • 参数对不对
  • 是否过度调用

9.3 迭代成本​

包括：

  • 平均循环次数
  • 平均 token 消耗
  • 平均完成时延

9.4 升级与回退能力​

工作流变复杂后，能不能：

  • 灰度发布
  • 快速回滚
  • 对比新旧策略

这决定了它是不是生产可维护系统。

10. 面试高频追问​

10.1 为什么 Agent 工作流不应该只靠 Prompt 堆出来？​

标准答法：

因为复杂任务不仅需要语言理解，还需要状态管理、工具调用、错误恢复、人工介入和退出控制。只靠 Prompt 堆出来，流程不可观测、不可恢复、也不可治理。

10.2 工作流和自治 Agent，怎么选？​

标准答法：

任务明确、步骤稳定、可预测时，更适合工作流；任务开放、路径不固定、需要模型根据环境动态决策时，才更适合更强自治的 Agent。生产实践里通常是混合方案。

10.3 Agent 工作流最容易失控的点是什么？​

标准答法：

最容易失控的是工具边界不清、状态设计薄弱、缺少终止条件和缺少评估闭环。很多系统不是模型不会做，而是流程没有被设计成可控系统。

11. 常见误区​

  • 误区一：把多轮聊天当成 Agent 工作流。 真正的工作流至少还需要状态、工具和路由。
  • 误区二：任务一复杂就拆成很多 Agent。 Agent 数量变多，不等于系统更强，只会先增加调试难度和成本。
  • 误区三：只看最终答案，不看过程指标。 这样很难定位问题到底出在路由、工具还是检查阶段。
  • 误区四：不做人类兜底。 高风险动作没有审批，会把系统风险放大。

12. 版本与事实说明​

截至 2026 年 3 月 30 日，主流 Agent 工程实践的共识仍然偏向：先用简单、可组合的工作流，再在必要时增加自治能力。 官方和社区资料也越来越强调状态、工具接口、检查机制、人工介入和可观测性，而不是一味追求“完全自动”的黑盒代理。因此在面试或设计系统时，重点应放在 工作流如何被设计成可控系统，而不是把 Agent 理解成会无限自主行动的模型。

13. 速记要点​

  • Agent 工作流核心是 状态 + 路由 + 工具 + 终止条件
  • 常见模式：ReAct / Plan-and-Execute / Router / Reviewer / HITL
  • 真正难点在 可控、可观测、可恢复
  • 不是所有任务都需要 Agent
  • 生产实践常是 工作流和 Agent 的混合体