3. Workflow，Agent，Tools 这三个的概念和区别介绍一下？
3. Workflow，Agent，Tools 这三个的概念和区别介绍一下？
💡 简要回答
我理解这三个概念是粒度从小到大的三层结构。Tools 是最小的能力单元，就是封装好的可调用函数，比如搜索、执行代码、发邮件，它只负责「执行」，本身没有任何决策能力；Agent 是一个完整的决策系统，内部用 LLM 做大脑，自己判断什么时候调哪个 Tool、要不要继续、什么时候结束，是主动的；Workflow 是更上层的编排框架，把 Agent、LLM、Tools 组织成一条确定性流程，每个节点做什么、按什么顺序流转都是开发者事先写死的。三者最核心的区别就一句话：Tools 不做决策只执行，Agent 自己做决策，Workflow 是开发者替所有节点把决策提前写好。
📝 详细解析
要理解这三个概念，得先搞清楚一件事：它们根本不是同一维度的东西，而是粒度不同、可以相互嵌套的三层结构。 很多文章把它们并排列出来对比，容易让人误以为是三选一的关系，其实不是。你在做实际项目的时候，三者通常同时存在，只是扮演不同的角色。
我们按从小到大的粒度，一层一层讲清楚。
第一层：Tools，最小的能力积木
Tools 是整个体系里最简单、最底层的概念，它就是一个封装好的函数，有明确的输入参数、明确的输出结果，就这么简单。
你给 LLM 配备的每一个能力，比如「查天气」「搜索网页」「执行 Python 代码」「往数据库写一条记录」，本质上都是一个函数。Tools 和普通函数唯一的区别是：你需要额外写一份「说明书」告诉 LLM 这个工具叫什么名字、能做什么事、需要传哪些参数，这样 LLM 才知道自己有哪些能力可以调用。
来看一个最直观的例子：
定义两个工具，注意观察：这里只有「说明书」，没有任何决策逻辑
Tools 根本不知道自己「应该」在什么时候被用，它只负责「被调用时干什么」
tools = [
{
"name": "web_search",
"description": "在互联网上搜索信息，适合查询实时数据或不确定的知识",
"parameters": {
"type": "object",
"properties": {
# 参数说明清晰，LLM 看到这个描述就知道该填什么
"query": {"type": "string", "description": "搜索关键词，越具体越好"}
},
"required": ["query"]
}
},
{
"name": "send_email",
"description": "向指定邮箱发送一封邮件",
"parameters": {
"type": "object",
"properties": {
"to": {"type": "string", "description": "收件人邮箱地址"},
"subject": {"type": "string", "description": "邮件主题"},
"body": {"type": "string", "description": "邮件正文内容"}
},
"required": ["to", "subject", "body"]
}
}
]
工具的实际执行逻辑单独写，和「说明书」是分开的
def execute_web_search(query: str) -> str:
# 这里才是真正发出 HTTP 请求去搜索的代码
...
def execute_send_email(to: str, subject: str, body: str) -> str:
# 这里才是真正调用邮件 API 发送邮件的代码
...注意一个很关键的设计：工具本身没有任何决策能力，它甚至不知道自己「应该」在什么时候被使用。 这不是什么设计缺陷，而是故意的，Tools 的使命就是把一个具体能力封装好、随时待命，至于什么时候该用它，那是别人的事。
你可以把 Tools 理解成瑞士军刀上的每一个刀片：折叠刀、开瓶器、螺丝刀，每个刀片都有自己擅长的事，但刀片本身不会说「现在应该把我翻出来」。决定拿哪个刀片的，是拿着刀的那只手。 这只手，就是我们接下来要说的 Agent。
第二层：Agent，拿着工具自己做决定的人
理解了 Tools 之后，Agent 就很好懂了。Agent 就是那个「拿着工具、自己决定用哪个」的角色。
你给 Agent 一个目标，比如「帮我调研一下最近竞品的动态」，它不会直接给你一个答案，而是开始自己思考：我要完成这个目标，第一步应该搜索什么关键词？搜索结果里有没有我需要的信息？需不需要再多搜几次？什么时候才算调研完了？
这一系列「要不要、用哪个、够不够、停不停」的判断，全部由 Agent 内部的 LLM 做决策。这就是 Agent 和 Tools 最本质的区别：Tools 被动等待调用，Agent 主动做决策。
Agent 的运行方式是一个反复循环的过程：想清楚（Thought）-> 行动（Action）-> 看结果（Observation）-> 再想清楚 -> 再行动…… 直到 LLM 判断任务完成为止，这个循环才结束。
用代码来看这个循环是什么样的：
import anthropic
client = anthropic.Anthropic()
def run_agent(user_goal: str):
# 把用户目标放进对话历史，Agent 的所有思考和行动都在这个 messages 里积累
messages = [{"role": "user", "content": user_goal}]
# Agent 的核心：一个不断循环的决策过程
# 注意：开发者根本不知道这个循环会跑几次，完全由 LLM 自己决定
while True:
# 每一轮，LLM 看到当前的完整对话历史，自己判断下一步该做什么
response = client.messages.create(
model="claude-opus-4-6",
max_tokens=1024,
tools=tools, # 把「工具说明书」传给 LLM，让它知道自己有哪些能力
messages=messages
)
# LLM 告诉我们「任务完成了」，把最终答案返回出去，循环结束
if response.stop_reason == "end_turn":
return response.content[0].text
# LLM 认为还需要调工具，我们就真正去执行它指定的工具
# 注意：LLM 只是「告诉我们调哪个工具、传什么参数」，真正执行的是我们的代码
tool_use = next(b for b in response.content if b.type == "tool_use")
tool_result = execute_tool(tool_use.name, tool_use.input)
# 把工具的执行结果塞回对话历史，LLM 下一轮能看到这个结果，再接着决策
messages.append({"role": "assistant", "content": response.content})
messages.append({
"role": "user",
"content": [{"type": "tool_result", "tool_use_id": tool_use.id, "content": tool_result}]
})
# 回到循环顶部，LLM 再看一遍现在的状态，做下一步决策这段代码里有一个地方值得特别注意：这个 while True 循环会跑几次，开发者完全不知道，也不需要知道，这正是 Agent 和普通代码最不一样的地方。普通代码的每一步都是开发者预先写好的，但 Agent 的执行路径是 LLM 实时决定的，你可以让它完成复杂的、你事先根本没法预测路径的任务。
当然，这也带来了一个副作用：Agent 的行为是不确定的。同样的任务，今天跑和明天跑，可能调了不同的工具、走了不同的路径，甚至得到微妙不同的结果。这是因为 LLM 本质上是个概率模型，每次生成都带有随机性。灵活性和不确定性是一对孪生兄弟，有 Agent 的灵活，就必然伴随着一定程度的不可预测。
第三层：Workflow，把所有人组织起来的总指挥
理解了 Tools 和 Agent 之后，Workflow 就水到渠成了。
假设你现在要做一个客服系统，大致流程是：先判断用户问的是什么类型的问题，再去知识库里检索相关内容，最后生成一个回答。这里面每一步的逻辑，开发者其实心里都很清楚，先做什么、后做什么、结果满足什么条件走哪个分支，完全可以在代码里写死。
这就是 Workflow 做的事：把整个执行流程的「骨架」写在代码里，LLM、Agent、Tools 都只是这个流程里的「节点」，每个节点负责完成自己那一步，但整体走哪条路、下一步去哪里，全由开发者的代码决定，不是任何节点自己说了算。
来看一个具体的例子：
def run_customer_service_workflow(user_query: str) -> str:
# ---- 第一步：意图识别 ----
# 这里把 LLM 当成一个分类器来用，它只负责判断这个问题属于哪个类别
# 「下一步去哪」这个决策是下面的 if/elif 来做的，不是 LLM 自己决定的
intent = classify_intent_with_llm(user_query) # 返回 "product" / "refund" / "other"
# ---- 第二步：根据意图走不同分支 ----
# 注意：这个分支判断是开发者写的 Python 代码，不是 LLM 的决策
if intent == "product":
# 产品问题：去知识库检索，再生成回答
docs = search_knowledge_base(user_query) # 直接调 Tool，固定的检索步骤
answer = generate_answer_with_llm(user_query, docs) # LLM 作为节点生成回答
return answer
elif intent == "refund":
# 退款问题：查订单系统，再走审核流程
order_info = query_order_system(user_query) # 调 Tool 查订单
if order_info["eligible"]:
process_refund(order_info["order_id"]) # 调 Tool 处理退款
return "退款已受理，预计 3 个工作日到账"
else:
return "很抱歉，该订单不满足退款条件"
else:
# 其他问题：转人工
escalate_to_human_agent(user_query)
return "已为您转接人工客服，请稍候"
整个流程的走向在代码里一目了然
出了任何问题，你可以精确定位是哪一步出了错你看，LLM 在这里面出现了两次，一次是做意图分类，一次是生成回答，但它只是流程里的两个工位，「接下来去哪」这件事完全由 if/elif 这些普通 Python 代码控制。这就是 Workflow 和 Agent 最核心的区别：谁在做「下一步去哪」这个决策？Agent 是 LLM 自己决定，Workflow 是开发者在代码里写死。
Workflow 最大的优点是可预测、可控、好调试。你在代码里看到什么，它就做什么，不会有任何「惊喜」。生产环境里出了问题，你可以打断点逐步追，精确定位是哪个节点出了故障。这种确定性在线上系统里非常珍贵。
三者怎么组合？Agentic Workflow 才是生产主流
讲完了三层结构，我们来说说实际工程里怎么用。
很多人学完这三个概念之后，会自然而然地想：「那我应该用哪个？」这个问题本身就有点问错方向了，因为在真实的项目里，三者通常是同时存在、相互嵌套的：
完全靠 Agent 自主决策 的系统其实很少在生产环境里出现，原因很现实：行为太难控制，一旦出问题很难排查，成本也容易失控（LLM 调太多轮）。
完全靠 Workflow 写死 的系统又太脆，因为你没法把所有情况都穷举到代码里，遇到预料之外的输入就容易失败或者给出很差的结果。
所以目前生产环境里最主流的模式是**「Agentic Workflow」**：用 Workflow 固定主流程的骨架，在需要灵活判断的节点嵌入 Agent，其余固定节点直接用 LLM 或 Tools。 骨架是确定的，让你能控制整体行为、便于调试；关键节点是灵活的，让你能应对各种复杂情况。两个优点都有，两个缺点都被削弱了。
把三者的核心差异对照起来看，就很清楚了：
| 维度 | Tools | Agent | Workflow |
|---|---|---|---|
| 决策能力 | 无（只执行，不决策） | 有（LLM 自主动态决策） | 无（开发者在代码里写死） |
| 执行方式 | 被动，等待被调用 | 主动，自主循环直到完成 | 按开发者定义的顺序执行 |
| 确定性 | 高（输入固定则输出固定） | 低（同输入可能走不同路径） | 高（行为完全可预测） |
| 灵活性 | 只做一件事 | 高（能应对预料之外的情况） | 低（流程提前写死，难以动态调整） |
| 调试难度 | 容易（单一函数） | 难（执行路径不确定） | 容易（链路清晰，可逐步追踪） |
| 适用场景 | 封装单一具体能力 | 路径未知的复杂任务 | 流程相对固定的业务系统 |