一文讲透 Tools、Workflow、Agent:从概念辨析到 Java 工程落地
面试官最爱问的三个词,90% 的候选人第一轮就栽在概念混淆上。这篇文章帮你把边界划清楚,把代码写出来,把面试答漂亮。
一、为什么面试官爱问这三个词
2024 年以来,LLM 应用架构以月为单位在迭代。年初大家还在讨论"怎么让 GPT 调用一个 API",到了年底,Anthropic 和 OpenAI 已经把 Agent 推到了生产级。这中间,Tools、Workflow、Agent 三个词反复出现,但大多数人的理解停留在"反正都是让 AI 干活的东西"。
面试官问这个,背后在考察四件事:
- 概念是否清晰——你能不能把三个词的定义边界说清楚,还是一上来就混着用
- 有没有架构判断力——给你一个真实业务场景,你能选出正确的形态吗
- 是否具备工程能力——在 Java 生态(Spring AI / LangChain4j)里,你动手写过吗
- 是否关注前沿——Anthropic 2024 年 12 月的《Building Effective Agents》你看过吗?Spring AI 1.0 在 2025 年正式发布你知道吗
本文按这四个维度展开,每个维度都给你面试能用的答案。
二、概念辨析:把三个词的边界划清楚
2.1 一切从 Augmented LLM 开始
Anthropic 在《Building Effective Agents》中给出了一个核心框架:一切智能应用都构建在"增强型 LLM"(Augmented LLM)之上。
1 | ┌─────────────────────────────────────────────┐ |
Augmented LLM = LLM + Tools + Retrieval + Memory。这是所有上层建筑的砖块。理解了这个,三个概念的分野就清晰了:
- Tools:Augmented LLM 中的"行动"维度。模型决定调用哪个工具、传什么参数,但工具的执行是在模型之外的确定性代码。
- Workflow:在 Augmented LLM 之上,用预定义的代码路径编排多个 LLM 调用和工具调用。
- Agent:在 Augmented LLM 之上,让 LLM 自主决定调用哪些工具、按什么顺序、何时停止。
一句话区分:Tools 是能力单元,Workflow 是固定流程,Agent 是自主决策。
2.2 Tools(工具):能力的最小单位
定义:Tool 是 LLM 可以调用的外部能力,通常以 Function Calling 的形式实现。LLM 不执行工具,它只生成调用指令(函数名 + 参数),由宿主程序执行后把结果返回给 LLM。
关键特征:
- 单一职责:一个 Tool 做一件事(查天气、发邮件、查数据库)
- 确定性执行:Tool 内部的逻辑是确定性代码,不涉及 LLM 推理
- 由 LLM 选择:模型根据用户意图,自主决定是否调用以及调用哪个 Tool
一个典型的 Tool 定义(OpenAI Function Calling 格式):
1 | { |
面试要点:Tool 本身不包含"什么时候用"的决策逻辑——那是 Workflow 或 Agent 的职责。Tool 只是"能力声明"。
2.3 Workflow(工作流):预定义的编排
定义:Workflow 是通过预定义代码路径编排多个 LLM 调用和 Tool 调用的模式。流程是确定的,LLM 在每一个步骤中只负责"处理输入、产生输出",不参与流程决策。
Anthropic 将 Workflow 细分为五种模式:
| 模式 | 描述 | 适用场景 |
|---|---|---|
| Prompt Chaining(提示链) | A 的输出作为 B 的输入,串行执行 | 翻译→润色;大纲→逐节写作 |
| Routing(路由) | 根据输入分类,分发到不同处理分支 | 客服意图识别→分流到不同专员 |
| Parallelization(并行) | 同一输入同时发给多个 LLM,聚合结果 | 代码审查(安全+风格+性能并行) |
| Orchestrator-Workers(编排-工人) | 一个 LLM 做任务分解,分派给多个 Worker LLM 并行执行,再汇总 | 复杂文档多维度分析 |
| Evaluator-Optimizer(评估-优化) | 一个 LLM 生成,另一个 LLM 评估并反馈,循环迭代 | 翻译质量打磨;代码生成+审查 |
Workflow 的本质:流程图是程序员画的,LLM 只是流程中的"处理节点"。你可以把 Workflow 理解为"带 AI 的传统业务流程"——控制流是确定的,不确定的只是每个节点内部的智能处理。
面试要点:Workflow 适合"步骤明确、边界清晰"的场景。比如一个合同审核流程——先提取关键条款(LLM),再逐条对比法规库(Retrieval),再生成风险报告(LLM),步骤是确定的,每步做什么是预先定义好的。
2.4 Agent(智能体):自主决策
定义:Agent 是让 LLM 自主决定工具调用的顺序、选择和执行次数,并在运行时动态规划达成目标的路径。Agent 的控制流不是预定义的,而是涌现的(emergent)。
Agent 的核心循环:
1 | ┌──────────────────────────────────────────┐ |
Agent 区别于 Workflow 的关键:
- Workflow 中,"下一步做什么"是程序员写在代码里的
- Agent 中,"下一步做什么"是 LLM 在运行时决定的
面试要点:Agent 适合"步骤不确定、需要探索和反馈"的场景。比如"帮我调研竞争对手的定价策略"——你不知道 LLM 会搜哪些关键词、点开哪些网页、分析哪些维度,它需要在执行中根据中间结果不断调整。
2.5 一张表说清三者的关系
| 维度 | Tools | Workflow | Agent |
|---|---|---|---|
| 定义 | LLM 可调用的外部能力 | 预定义的 LLM 调用编排 | LLM 自主决策的工具编排 |
| 控制流 | 无(被动调用) | 程序员预定义 | LLM 运行时决定 |
| LLM 角色 | 选择工具+参数 | 流程中的处理节点 | 决策者+执行者 |
| 确定性 | 工具执行确定 | 流程路径确定 | 路径不确定(涌现) |
| 复杂度 | 低 | 中 | 高 |
| 可调试性 | 高 | 高 | 低 |
| 适合场景 | 单个能力增强 | 步骤明确的流程 | 开放式的探索任务 |
三、架构选型:什么时候用 Workflow,什么时候上 Agent
这是面试官最爱追问的环节。Anthropic 在文章中给出了一个著名的原则,值得全文背诵:
“Start with the simplest solution, and only add complexity when needed.”
——从最简单的方案开始,只在必要时增加复杂度。
翻译成人话:能 Workflow 解决的,不要上 Agent。
3.1 决策框架
1 | 用户需求 |
3.2 实战案例决策
案例 1:客服工单自动分类与派发
用户描述问题 → 识别意图 → 提取关键信息 → 查询知识库 → 生成回复或派单。
分析:步骤明确,每一步的输入输出清晰。选 Workflow。用 Routing 做意图识别分流,Prompt Chaining 做信息提取→知识检索→回复生成。
案例 2:竞品深度调研
“帮我调研 A、B、C 三家公司的 SaaS 定价策略,包括公开价格、隐藏费用、折扣政策,并给出我们的定价建议。”
分析:你无法预知 LLM 要搜多少次、看哪些页面、从什么角度分析。中间可能发现某个竞品有新的定价模式,需要深入追查。选 Agent。LLM 自主搜索、阅读、对比、补充搜索,直到产出完整报告。
案例 3:代码审查流水线
提交代码 → 安全检查 → 风格检查 → 性能分析 → 汇总报告。
分析:步骤确定,四个检查维度明确,可以并行。选 Workflow(Parallelization + 汇总)。
案例 4:SQL 问答助手
用户问"上个月销售额最高的 10 个产品是什么" → LLM 生成 SQL → 执行 → 用结果回答追问。
分析:追问是不确定的——用户可能问"那利润呢"“按地区分呢”“跟去年同期比呢”,每次追问 LLM 需要决定是生成新 SQL 还是解释已有结果。选 Agent。这是经典的 ReAct Agent 场景。
3.3 面试话术
当面试官问"什么时候用 Workflow 什么时候用 Agent"时,你的回答框架:
“我的判断标准是流程的可预见性。如果我能提前把任务拆成 A→B→C 的确定性步骤,用 Workflow,因为它的可调试性、可观测性和成本都更可控。只有当任务的步骤无法提前确定——需要根据中间结果动态决策、需要多轮探索——我才上 Agent。Anthropic 的原则是’从最简单开始’,在实践中我发现:能用单次 LLM 调用的不配 Tool,能配 Tool 的不上 Workflow,能 Workflow 的不上 Agent。每多一层复杂度,就多一层的延迟、成本和不确定性。”
四、工程实践:Java 生态怎么落地
这一节直接给代码。Java 生态目前两大框架:Spring AI(Spring 官方,2025 年发布 1.0 GA)和 LangChain4j(社区驱动,更早熟)。两者都完整支持 Tools / Workflow / Agent。
4.1 Tools 的实现
Spring AI — 用 @Tool 注解定义工具:
1 | import org.springframework.ai.tool.annotation.Tool; |
然后在 ChatClient 中使用:
1 |
|
当用户说"北京今天天气怎么样",模型会自动识别需要调用 getWeather("北京"),Spring AI 帮你执行并把结果传回模型。
LangChain4j — 用 @Tool 注解:
1 | import dev.langchain4j.agent.tool.Tool; |
通过 AI Service 绑定:
1 | public interface Assistant { |
两者的设计思路高度一致:用注解声明工具的签名和描述,框架自动处理 Function Calling 的协议细节(OpenAI 格式、Anthropic 格式等)。
4.2 Workflow 的实现
Workflow 的本质是"带 AI 节点的确定性流程"。框架不强制你用特定的 DSL,你可以直接用 Java 代码编排。
示例:合同审核 Workflow(Prompt Chaining + Routing)
1 |
|
关键点:这段代码的控制流(先提取→再路由→最后报告)是写死在 execute() 方法里的。LLM 只负责每个步骤内部的智能处理,不参与流程决策。这就是 Workflow。
4.3 Agent 的实现
Agent 的实现在两个框架中略有不同。
Spring AI — 用 ToolCallback + 自动 Agent 循环:
1 |
|
LangChain4j — 显式 ReAct Agent:
LangChain4j 提供了更显式的 Agent 实现,适合需要更多控制的高级场景:
1 | import dev.langchain4j.agent.tool.Tool; |
Agent 的关键差异:注意上面的 System Prompt——“先搜索→根据结果决定是否深入→汇总”——这是给 LLM 的行为指引,但具体的执行路径由 LLM 在运行时决定。程序员没有写 if (result.incomplete) { searchMore(); },这个决策是 LLM 做出的。
4.4 三个层次的工程复杂度对比
| 层次 | 你需要关心的 | 你不需要关心的 |
|---|---|---|
| Tools | 工具签名和描述写得是否清晰 | 模型会不会调用、何时调用 |
| Workflow | 流程步骤和分支逻辑 | 每个步骤内部的 LLM 推理细节 |
| Agent | System Prompt 的行为指引、工具的边界、终止条件 | LLM 具体走什么路径 |
五、前沿认知:2024-2025 的关键进展
5.1 Anthropic 的"简单胜于复杂"原则
Anthropic 在《Building Effective Agents》中的核心主张值得深入理解:
核心观点:
“The most effective agents we’ve seen are often simple, composed of well-scoped prompts and tools, rather than complex, open-ended autonomous systems.”
他们观察到,最成功的 Agent 系统不是"一个超级智能体自主搞定一切",而是"在 Workflow 框架内,给 LLM 恰到好处的自主空间"。
实践推论:
- 不要把 Agent 当成"万能的",它的自主性是双刃剑——多了不可控,少了没必要
- 用 Workflow 锁定确定性部分,只在真正需要动态决策的环节放 Agent
- 把 Agent 的 Tool 范围收窄:给它 5 个精准的工具,比给它 50 个工具效果好得多
面试金句:
“Anthropic 的经验是:框架(Workflow)给确定性,Agent 给灵活性。最好的系统是’Workflow 套 Agent’——外层是确定性的流程骨架,内层在关键决策点嵌入 Agent 的自主判断。”
5.2 Spring AI 1.0:Tool/Agent/Workflow 正式进入 JVM 生态
2025 年,Spring AI 发布了 1.0 GA 版本,标志着 AI 应用开发在 Java 生态从"实验阶段"进入"生产就绪"。关键能力:
| 能力 | Spring AI 1.0 支持 |
|---|---|
| Tool Calling | @Tool 注解 + ToolCallback 自动处理多轮调用 |
| Workflow 编排 | ChatClient 链式调用 + Spring 生态原生(集成 Spring Batch/Integration) |
| Agent 循环 | 自动 Tool Call 循环,模型自主决定停止时机 |
| MCP 协议 | 完整支持 Model Context Protocol,标准化 Tool/Resource 接入 |
| 多模型 | OpenAI / Anthropic / Ollama / Azure 统一抽象 |
| 向量存储 | 原生集成 PGVector / Redis / Milvus / Qdrant 等 |
MCP(Model Context Protocol)的意义:Anthropic 提出的 MCP 协议把 Tool 和 Resource 的接入标准化了。以前你要为每个 LLM 平台写不同的 Tool 适配代码,现在有了 MCP,Tool 提供方只需实现一个 MCP Server,所有支持 MCP 的框架都能直接调用。Spring AI 1.0 完整支持了 MCP Client,这意味着:
1 | // 通过 MCP 接入远程 Tool Server,无需为每个平台写适配 |
5.3 行业共识:三种形态的定位已明确
到 2025 年中,业界对这三者的定位已经形成共识:
- Tools → 基础设施层。框架的职责是让 Tool 定义标准化、调用协议化(MCP)。
- Workflow → 工程实践层。框架提供编排原语(链式调用、并行、条件分支),但控制流由开发者掌握。
- Agent → 高级抽象层。框架提供 Agent 循环和 Tool 自动编排,但开发者需要精心设计 System Prompt 和 Tool 边界。
六、总结:面试回答框架
当面试官问"聊聊你对 Tools、Workflow、Agent 的理解",你可以按这个结构回答:
第一层(定义):
“Tools 是 LLM 的外部能力单元,以 Function Calling 实现;Workflow 是预定义的 LLM 调用编排,控制流由代码决定;Agent 是 LLM 自主决策的工具编排,控制流由模型在运行时决定。”
第二层(选型):
“选型核心看流程的可预见性。能确定步骤的用 Workflow,步骤不确定需要探索的用 Agent。原则是:能简单不复杂,能 Workflow 不 Agent。”
第三层(工程):
“在 Java 生态里,Spring AI 用 @Tool 注解定义工具、ChatClient 处理调用循环、原生集成 MCP 协议做标准化接入。LangChain4j 用 AiServices + @Tool 注解实现类似能力,ReAct Agent 模式更显式。Workflow 直接用 Java 代码编排即可,不需要特殊框架。”
第四层(前沿):
“Anthropic 的经验是框架给确定性、Agent 给灵活性,最好的系统是 Workflow 套 Agent。Spring AI 1.0 在 2025 年把这些概念正式引入了 JVM 生态,MCP 协议正在成为 Tool 接入的行业标准。”
参考资料
- Anthropic — Building Effective Agents (Dec 2024)
- Spring AI Reference — Tool Calling
- LangChain4j — Tools (Function Calling)
- Model Context Protocol (MCP) Specification
如果您喜欢此博客或发现它对您有用,则欢迎对此发表评论。 也欢迎您共享此博客,以便更多人可以参与。 如果博客中使用的图像侵犯了您的版权,请与作者联系以将其删除。 谢谢 !