Agent Workflow：为什么真正可用的 Agent 不能只靠模型自由发挥

Tool Calling 让模型能够选择工具，MCP 让工具和外部系统拥有统一的接入方式，但如果一个 Agent 只具备这两种能力，它依然很难直接进入生产环境。

原因很简单：会调用工具，不等于会稳定地完成任务。

一个真实任务通常不是：

用户提出问题 -> 调用一个 Tool -> 返回答案

而更像是：

理解目标
-> 获取信息
-> 判断当前状态
-> 选择下一步
-> 调用工具
-> 检查结果
-> 处理异常
-> 决定是否继续
-> 最终完成任务

这个过程本身就已经是一套流程系统。

Agent Workflow 解决的，就是如何把 LLM、Tool Calling、业务规则、状态管理和异常处理组织成一条可控的执行链路。

Agent Workflow 的核心不是让模型拥有更多自由，而是规定模型应该在哪些地方拥有自由。

为什么只靠 Tool Calling 不够

假设系统中给模型提供三个工具：

search_order
refund_order
send_email

然后用户说：

帮我把刚才买错的订单退掉，并告诉我退款结果。

如果完全依赖模型自由规划，它可能执行：

search_order
-> refund_order
-> send_email

看起来没有问题。

但真实业务中可能还存在很多隐藏条件：

订单是否已经发货
是否超过退款时间
退款金额是否超过权限限制
是否属于特殊商品
用户是否已经申请过退款
退款操作是否需要人工确认

这些条件不能仅仅依赖模型根据自然语言“猜”。

真正的系统应该更接近：

识别用户诉求
-> 查询订单
-> 业务规则校验
-> 判断是否允许自动退款
-> 必要时请求用户确认
-> 执行退款
-> 验证退款结果
-> 返回最终状态

这里的很多节点，其实根本不需要 LLM。

例如：

if order.status == "shipped":
    ...

这种确定性逻辑直接使用代码会更加可靠。

因此，Agent Workflow 的第一个原则是：

不要把可以确定执行的逻辑交给概率模型。

Workflow 本质上是一套状态机

从软件工程角度看，Agent Workflow 很像状态机。

一个任务不会只是“运行中”或者“完成”，而会处于不同阶段。

例如一个研究型 Agent：

START
-> ANALYZE_TASK
-> SEARCH
-> READ
-> VERIFY
-> WRITE
-> END

系统需要知道当前执行到了哪里，并根据当前状态决定下一步允许发生什么。

可以把状态写成：

state = {
    "task": "...",
    "current_step": "search",
    "search_results": [],
    "documents": [],
    "verified": False,
    "final_answer": None
}

Workflow 中的每一个节点读取 State，再修改 State。

例如：

def search_node(state):
    results = search(state["task"])

    state["search_results"] = results
    state["current_step"] = "read"

    return state

之后再进入下一个节点。

因此，一个 Agent Workflow 可以理解为：

State + Nodes + Edges + Conditions

其中：

State
负责保存任务当前信息

Node
负责执行某一步操作

Edge
决定节点之间如何连接

Condition
决定下一步走哪条路径

这也是为什么很多 Agent 框架最终都会走向 Graph 或 State Machine 的设计。

为什么 Agent Workflow 经常使用 Graph

传统 Workflow 很多时候是线性的：

A -> B -> C -> D

但 Agent 任务通常不是完全线性的。

例如一个研究任务可能是：

分析问题
-> 搜索资料
-> 判断资料是否充分

如果充分：

-> 整理答案

如果不充分：

-> 修改搜索关键词
-> 再次搜索
-> 再判断

甚至在生成答案之后，系统还可能执行：

生成答案
-> 检查事实
-> 发现问题
-> 回到搜索

所以更准确的结构其实是：

SEARCH
-> READ
-> VERIFY

VERIFY -> PASS -> WRITE
VERIFY -> FAIL -> SEARCH

这已经不是普通的流水线，而是一张 Graph。

Agent Workflow 使用 Graph，并不是为了让架构看起来更复杂，而是因为 Agent 任务天然存在分支、循环、回退和重试。

哪些节点应该交给 LLM

Agent Workflow 中最重要的架构决策之一，就是决定哪些地方使用 LLM。

一个常见的错误设计是：

每一个 Node 都调用一次 LLM

这样虽然看起来非常“AI Native”，但通常会让系统变得更慢、更贵，也更加不稳定。

LLM 更适合处理的是模糊问题。

例如：

理解用户真实意图
从多种方案中进行判断
分析非结构化文本
生成搜索关键词
决定下一步需要什么信息
总结复杂结果

而传统代码更适合处理：

字段校验
权限判断
金额计算
状态转换
数据库读写
业务规则
格式转换

所以一个合理的 Workflow 可能是：

用户请求
-> LLM：识别意图
-> Code：查询订单
-> Code：检查退款规则
-> LLM：判断用户说明是否符合特殊情况
-> Code：执行退款
-> Code：验证状态
-> LLM：生成最终回复

这里并不是模型使用得越多越好。

真正重要的是：

只在需要语言理解和不确定判断的位置使用 LLM。

Deterministic Workflow 和 Agentic Workflow

可以把 Workflow 分成两种极端形式。

第一种是完全确定性的 Workflow：

A -> B -> C -> D

每一步都提前写死。

这种架构最大的优点是稳定、可预测、容易测试，但它很难处理开放式任务。

另一种是完全 Agentic 的执行方式：

LLM
-> 自己决定下一步
-> 自己选 Tool
-> 获取结果
-> 再决定下一步

这种方式非常灵活，但控制能力较差。

真正的生产系统通常位于两者之间。

可以表示成：

Deterministic Workflow
+
Agentic Nodes

例如：

START
-> 身份验证
-> LLM 判断任务类型
-> 根据任务进入不同 Workflow
-> Tool Calling
-> 业务规则校验
-> LLM 生成结果
-> END

整体框架是固定的，但其中某些节点允许模型动态判断。

这种架构的优势在于，系统既保留了 Agent 的灵活性，又不会把整个业务流程完全交给模型。

Router 是最常见的 Agent Workflow 节点

在很多 Agent 系统中，第一个真正有价值的 Workflow Node 就是 Router。

Router 的作用是判断任务应该进入哪条处理路径。

例如：

User Request
-> Router

Router 可能得到：

knowledge_query
data_analysis
coding_task
customer_service

然后分别进入：

knowledge_query -> RAG Workflow

data_analysis -> Data Workflow

coding_task -> Coding Agent

customer_service -> Service Workflow

Router 可以使用规则，也可以使用 LLM。

如果分类非常明确，可以直接使用代码：

if request.type == "refund":
    return "refund_workflow"

如果用户输入比较开放，则可以让模型进行判断：

“帮我看看最近销售为什么突然下降了”

这时候模型可能判断：

{
  "route": "data_analysis"
}

因此 Router 实际上是：

把开放式自然语言输入转换成确定性 Workflow 的入口。

State 是 Agent Workflow 的核心

如果一个 Workflow 只有两三个步骤，状态管理可能看起来并不重要。

但任务一旦变长，State 会立刻成为整个 Agent 系统的核心。

假设一个研究 Agent 已经完成：

搜索 10 个结果
读取 5 篇文章
确认 3 个可靠来源
生成一半报告

这时候系统因为网络问题重启。

如果没有 State Persistence，那么整个任务只能从头开始。

真正可靠的 Agent 应该能够保存：

任务目标
当前节点
已经执行过的 Tool Call
Tool Result
中间数据
用户确认
错误信息
最终结果

例如：

state = {
    "task_id": "task_1024",
    "status": "running",
    "current_node": "verify_sources",
    "sources": [...],
    "tool_history": [...],
    "retry_count": 1
}

这样系统恢复之后，就可以继续：

加载 State
-> 从 verify_sources 继续执行

而不是：

重新开始整个任务

因此，Agent Workflow 和普通 Chatbot 的一个重要区别就是：

Agent 执行的是 Task，而不是单纯的一次 Conversation。

Conversation 可以结束，但 Task 可能持续很久。

Checkpoint 为什么重要

Checkpoint 可以理解为 Workflow 的存档点。

例如：

Node A
-> Checkpoint
-> Node B
-> Checkpoint
-> Node C

每执行完一个关键节点，就把 State 持久化。

这样一旦：

进程崩溃
网络中断
模型请求失败
Tool 超时
服务重启

任务都可以从最近一次 Checkpoint 恢复。

这对于长任务尤其重要。

例如：

研究报告生成
代码库分析
大规模数据处理
自动化业务流程
长期 Agent Task

如果一个 Agent 跑了二十分钟，却因为最后一次 API 调用失败而全部重来，这个系统几乎不具备生产价值。

能不能恢复执行，往往是 Demo Agent 和 Production Agent 的一个明显分界线。

Retry 不应该只是简单重试

Agent Workflow 中很容易出现失败。

例如 Tool 返回：

Timeout

最简单的做法当然是：

retry()

但不同错误应该采用不同处理策略。

例如网络超时：

Timeout
-> Retry

权限不足：

Permission Denied
-> Stop
-> 请求用户授权

参数错误：

Invalid Arguments
-> 返回 LLM
-> 重新生成参数

搜索结果不足：

Insufficient Results
-> 修改 Query
-> 再次 Search

数据库不可用：

Database Unavailable
-> Retry
-> 超过次数后进入 Fallback

因此真正成熟的 Workflow 不只是：

Success / Failure

而应该针对不同失败类型设计不同路径。

可以表示成：

Tool Call
-> Success -> Next Node
-> Timeout -> Retry
-> Invalid Input -> Repair
-> Permission Error -> Human Intervention
-> Fatal Error -> Stop

这也是为什么 Agent Workflow 本质上越来越接近传统分布式任务系统。

Human-in-the-loop 也是 Workflow 的一部分

很多 Agent 系统不能完全自动执行。

尤其涉及：

转账
删除数据
发送邮件
部署代码
修改生产环境
取消订单

系统必须允许任务暂停，并等待用户确认。

例如：

LLM 判断需要删除服务器文件
-> Workflow 进入 WAITING_APPROVAL
-> 用户确认
-> DELETE_FILE
-> 继续执行

State 可以保存：

state = {
    "status": "waiting_approval",
    "pending_action": {
        "tool": "delete_file",
        "path": "/production/data.db"
    }
}

用户确认之后：

WAITING_APPROVAL
-> APPROVED
-> EXECUTE

如果用户拒绝：

WAITING_APPROVAL
-> REJECTED
-> CANCEL

这说明 Human-in-the-loop 并不是 Agent 系统外部的补丁，而应该直接成为 Workflow 的一个状态。

Sub-Workflow 比 Multi-Agent 更值得优先考虑

当 Workflow 越来越复杂时，很容易产生一个想法：

这里拆一个 Agent
那里再拆一个 Agent

最后形成：

Research Agent
Data Agent
Writer Agent
Reviewer Agent
Manager Agent

但很多情况下，这些角色其实并不需要成为独立 Agent。

完全可以拆成多个 Sub-Workflow：

Main Workflow
├── Research Workflow
├── Analysis Workflow
└── Writing Workflow

例如 Research Workflow：

Generate Query
-> Search
-> Read
-> Verify
-> Return Sources

Analysis Workflow：

Load Data
-> Clean
-> Calculate
-> Interpret

这种结构通常比一开始就做 Multi-Agent 更容易调试，也更加节省模型调用。

因此，在真正需要多个独立角色进行自主协作之前，优先考虑 Workflow Composition，而不是 Multi-Agent。

Tool Calling 在 Workflow 中的位置

Tool Calling 并不是 Workflow 本身。

它只是 Workflow 中某个 Node 可以使用的一种能力。

例如：

START
-> Intent Node
-> Search Node
-> Verify Node
-> Answer Node
-> END

其中 Search Node 内部可能执行：

LLM
-> Tool Calling
-> MCP Client
-> Search MCP Server
-> Search Engine

所以完整层次可以表示为：

Workflow
-> Node
-> LLM
-> Tool Calling
-> MCP
-> External System

Workflow 决定：

什么时候进入这个 Node

LLM 决定：

这个 Node 中应该做什么

Tool Calling 决定：

应该调用哪个 Tool

MCP 决定：

如何标准化地连接这个 Tool

把这些概念分层之后，Agent 的整体架构会清晰很多。

一个完整的 Agent Workflow

假设要开发一个自动研究 Agent，用户提出：

帮我调查一家公司的最新情况，并生成一份分析。

一个相对完整的 Workflow 可以设计成：

START
-> Parse Task
-> Generate Search Plan
-> Search
-> Read Sources
-> Evaluate Sources
-> Enough Information?

如果信息不足：

-> Generate New Query
-> Search

如果信息充分：

-> Analyze
-> Draft
-> Fact Check

如果事实检查失败：

-> Search Missing Evidence
-> Revise

如果通过：

-> Finalize
-> END

对应的 State 可能包含：

state = {
    "task": "",
    "queries": [],
    "sources": [],
    "facts": [],
    "draft": "",
    "verified": False,
    "retry_count": 0
}

整个 Agent 并不是：

agent.run(task)

这么简单。

实际上它背后是一套：

Workflow Engine
+
State
+
LLM
+
Tool Calling
+
MCP
+
Retry
+
Checkpoint
+
Human-in-the-loop

共同组成的执行系统。

Agent Workflow 最大的价值是可控性

很多 Agent Demo 强调的是 Autonomous：

让模型自己完成所有事情

但真正进入生产之后，更重要的往往不是 Autonomous，而是 Controlled。

企业真正关心的是：

它现在在做什么？
为什么执行这个操作？
失败以后会发生什么？
最多会执行多少步？
哪些操作需要确认？
任务中断后能否恢复？
能不能查看完整执行记录？

这些问题靠 Prompt 无法真正解决。

它们需要 Workflow。

因此，Agent Workflow 的意义可以总结为：

把大模型的不确定能力放进一个确定的软件执行框架里。

模型负责处理那些过去很难用规则表达的问题，例如理解、语义判断和动态规划。

Workflow 则负责：

执行顺序
状态管理
路径限制
异常恢复
权限边界
生命周期

二者并不是互相替代的关系。

Agent Workflow 真正改变了什么

传统 Workflow 的特点是：

程序员提前知道所有路径

例如：

A -> B -> C

Agent 出现以后，一部分路径开始可以在运行时动态决定：

A
-> LLM 判断
-> B / C / D

再进一步：

A
-> LLM
-> Tool
-> Result
-> LLM
-> 根据结果动态选择下一节点

所以 Agent Workflow 并不是抛弃传统 Workflow，而是在其中加入了一个新的可编程组件：

LLM Decision Node。

最终，一个比较完整的 Agent 技术栈可以表示为：

User
-> Agent Workflow
-> State
-> LLM
-> Tool Calling
-> MCP
-> External Systems

其中每一层负责不同的问题：

LLM
负责理解、推理和判断

Tool Calling
负责把判断转换成工具调用

MCP
负责标准化连接外部能力

State
负责记录任务执行过程

Workflow
负责控制整个任务生命周期

因此，如果 Tool Calling 让模型第一次拥有了“行动能力”，MCP 解决了“行动如何连接外部系统”，那么 Agent Workflow 解决的就是最后一个更重要的问题：

这些行动应该按照什么顺序发生，在什么条件下发生，以及出错之后系统应该怎么办。

真正可用的 Agent，从来不是让模型自由发挥。

而是让模型在一个设计良好的 Workflow 中拥有恰到好处的自由。