深度 5：Tools、Workflow、Agent——零件、流水线、能换线的机器人

这是「Agent 工程化」系列的深度篇。很多人把 Tools、Workflow、Agent 当成"三选一"来对比，这是最大的误区——它们是粒度从小到大、可以互相嵌套的三层结构，真实项目里三者同时存在，只是各演各的角色。这篇把它们一次理清。

---

开场：三个概念，一个误区

有人问你：

“Tools、Workflow 和 Agent 三者的区别是什么？”

最常见的回答是列一张对比表，好像三者是互斥的选项。但真实系统里，一个 Agent 内部同时有 Tools 和 Workflow——所以"区别"这个词本身就问错了方向。

正确的理解是：它们不是同一维度的东西，而是从小到大嵌套的三层结构。 判别三者只看一件事：

"下一步做什么"的决策权在谁手里。

• Tools：根本没有决策
• Agent：决策权在模型手里（运行时才知道走哪条路）
• Workflow：决策权在开发者手里（代码写死每一步）

---

第一层：Tools——最小的能力积木

Tools 就是一个封装好的函数：有明确的输入参数、明确的输出结果，仅此而已。

def search_flight(depart: str, arrive: str, date: str) -> list[dict]:
    """查航班：返回候选航班列表"""
    ...

def get_weather(city: str, date: str) -> dict:
    """查天气：返回温度、降水概率"""
    ...

它和普通函数唯一的区别是：要额外写一份"说明书"（name、description、parameters），让模型知道有这个能力、什么时候该调它、参数怎么填。

关键设计：工具本身没有任何决策能力，它甚至不知道自己"应该"在什么时候被使用。

比喻：Tools 是瑞士军刀上的每个刀片——折叠刀、开瓶器、螺丝刀，每个刀片都擅长一件事，但刀片自己不会说"现在该把我翻出来"。决定用哪个刀片的，是拿刀的那只手。

---

第二层：Agent——拿着工具自己做决定的人

Agent 就是那个"拿着工具、自己决定用哪个"的角色。

给它一个目标（“帮我规划下周五出差”），它不会直接给答案，而是自己思考：第一步应该查什么？查完航班要不要顺手查酒店？预算不够怎么办？什么时候算完成？

这一连串"要不要、用哪个、够不够、停不停"的判断，全部由 Agent 内部的 LLM 决策。它的运行方式是本系列第 2 篇讲过的循环：

思考（下一步做什么）→ 行动（调哪个工具）→ 观察（结果）→ 再思考……
直到模型判定任务完成

这段代码会循环几次，开发者完全不知道，也不需要知道——这正是 Agent 和普通代码最不一样的地方。普通代码的每一步都是预写的，Agent 的执行路径是 LLM 实时决定的，它能完成你事先根本没法预测路径的任务。

代价也随之而来：Agent 的行为是不确定的。 同样的任务今天跑和明天跑，可能走了不同的路径、得到微妙不同的结果。灵活性和不确定性是一对孪生兄弟——这是后面 Workflow 存在的重要理由。

---

第三层：Workflow——把决策提前写死的流水线

Workflow 是开发者把流程编排死的结构：每个节点做什么、按什么顺序流转、什么条件下走哪条路，全部在代码里写死。LLM 只是其中一个节点，只在固定位置干活。

这个流程不会变：所有请求都走同一条路，模型不参与"下一步去哪"的决策。所以 Workflow 的优点是确定性——结果可预测、成本可控、出问题能逐节点断点排查；缺点是死板——路径外的需求一概接不住。

比喻：Workflow 是流水线/装配线，零件按固定轨道流过每个工位；Agent 是能换流水线的机器人，看情况自己决定去哪条线。

---

三层怎么嵌套：真实系统长什么样

真实项目里三者是同时存在的，嵌套关系大概是：

• 最外层是 Workflow：意图判断、常规路径写死，保证 80% 请求的确定性
• 中间是 Agent：Workflow 判断"这条路径没法枚举"时（比如超预算要动态找替代），把控制权交给 Agent
• 最底层是 Tools：Agent 和 Workflow 最终都落在 Tools 上执行

这就是"嵌套"的含义：Workflow 兜底常规路径，Agent 处理异常和动态分支，Tools 提供原子能力。 三者不是替代关系，是分工关系。

---

决策主体对照表

	Tools	Agent	Workflow
决策主体	无决策	LLM 动态决策	开发者代码固化
执行模式	被动调用	主动循环执行	按预设顺序
路径确定性	—	运行时才确定	编译时已确定
灵活性	无	最高	最低
可预测性	最高	最低	最高
出问题排查	单点	要查完整轨迹	逐节点断点
擅长	单动作	路径未知的开放任务	标准化重复流程

---

工程立场：能用 Workflow 解决的，别上 Agent

这是整套理解里最值钱的一句话：

自主性是用来对付"路径真的无法预先枚举"的，不是拿来炫技的。

• 路径可枚举（查天气→带伞提醒）→ 用 Workflow，确定、便宜、好排查
• 路径不可枚举（“帮我排查这个服务为什么挂了”）→ 才用 Agent，让它自己探索

判断标准就一条：你能不能预先画出所有可能路径？ 能画出来就用 Workflow，画不出来才上 Agent。这也是本系列第 8 篇"够用就好"原则的延续——编排模式的选择标准是场景复杂度，不是"Agent 更高级"。

---

三个最容易踩的坑

坑一：给 Workflow 塞 Agent 的活。
流程固定的任务偏要上 Agent，结果就是：同样的活每次走不同路径、成本不可控、行为不可复现——把确定性问题做成了不确定性问题。

坑二：给 Agent 塞 Workflow 的活。
"帮我查北京明天天气"这种单步任务交给 Agent 循环处理，白白多几轮 LLM 调用。先问路径能不能枚举，能就 Workflow。

坑三：Agent 不设循环上限。
Agent 的不确定性必须用工程手段兜底——最大循环次数、token 上限、运行超时，任一触发强制终止（本系列第 9 篇护栏）。生产环境没有"信任模型"这回事。

---

常见疑问

问：Workflow 里可以有 Agent 吗？
可以，而且这是最佳实践。Workflow 把常规路径写死，遇到"这步没法固定"就动态拉起一个 Agent 子流程，处理完再回到 Workflow。腾讯的实践就是"Workflow 兜底 + Agent 处理异常和动态分支"。

问：Agent 里可以有 Workflow 吗？
可以。Agent 调用工具时，某个工具本身可能就是一个内部 Workflow（多步的子过程）。工具对 Agent 是黑盒，内部怎么编排都行。

问：这是不是就是"能单不双"的翻版？
是同一个思想。选型的核心永远是"用最确定的方案满足需求"：Tools → Workflow → Agent，从确定到不确定，按需升级，别默认上最灵活的那个。

---

总结：一句话记住它

Tools、Workflow、Agent 不是三选一，是嵌套的三层：Tools 是原子能力（零件/刀片，只执行不决策），Workflow 是开发者把决策写死的流水线（确定、可控、好排查），Agent 是把决策权交给模型的机器人（灵活但不确定）。判别标尺只有一句——"下一步做什么"的决策权在谁手里。工程立场：能用 Workflow 别上 Agent，自主性只用来对付路径无法枚举的场景。

---

小结

• 不是三选一：粒度从小到大、可嵌套的三层结构，真实项目同时存在
• Tools：原子函数 + 说明书，零决策，瑞士军刀刀片
• Agent：LLM 决策的循环，灵活但不确定
• Workflow：代码写死的流水线，确定但死板
• 判别标尺：路径决策权在谁手里（无 / 模型 / 开发者）
• 最佳实践：Workflow 兜底常规 + Agent 处理动态分支 + Tools 兜底执行
• 工程立场：能用 Workflow 别上 Agent，自主性不是炫技

下一篇深度篇：LangGraph 的点和边——把图式编排里"点是什么、边是什么、生产图的点边怎么设计"一次讲透。

---

本系列路线（从 0 到 1）： Agent 是什么 → 手写最小 ReAct → Function Calling 与工具设计 → 上下文管理 → Memory 记忆系统 → RAG 知识库 → Skill 自学习 → 编排模式与多 Agent → 给 Agent 装护栏 → 生产部署与可观测 → 评测与回归 → 番外：框架横评 → LangGraph 深挖 → 框架选型决策 → 深度篇：Reflection 反思 → 记忆压缩 → 意图路由 → Skill 辨析 → 三层嵌套 → 图式编排 → 更多