Tools、Workflow、Agent 三层架构详解从最小能力单元到编排框架1. 三者的核心误区很多人把 Tools、Workflow、Agent 当成三个并列的竞争方案认为做项目时需要在三者中选一个。这个理解是错的。三者不是同一维度的东西而是粒度不同、可以相互嵌套的三层结构。Tools 是最小的能力单元Agent 是一个完整的决策系统Workflow 是更上层的编排框架。在实际项目中三者通常同时存在扮演不同角色。三者最核心的区别一句话Tools 不做决策只执行Agent 自己做决策Workflow 是开发者替所有节点把决策提前写好。2. 第一层Tools——最小能力单元2.1 核心定义Tools 是整个体系里最底层的概念就是一个封装好的函数有明确的输入参数、明确的输出结果。你给 LLM 配备的每一个能力比如查天气“搜索网页”“执行 Python 代码”“往数据库写一条记录”本质上都是一个函数。Tools 和普通函数唯一的区别是需要额外写一份说明书告诉 LLM 这个工具叫什么名字、能做什么事、需要传哪些参数这样 LLM 才知道自己有哪些能力可以调用。一个工具定义的结构示例{name:search_web,description:搜索互联网并返回结果,parameters:{type:object,properties:{query:{type:string,description:搜索关键词}},required:[query]}}2.2 技术特征零决策能力工具本身没有任何决策能力它甚至不知道自己应该在什么时候被使用被动等待调用由外部Agent 或 Workflow触发不会主动执行高确定性输入固定则输出固定行为可预测2.3 边界与局限Tools 的使命就是把一个具体能力封装好、随时待命至于什么时候该用它那是别人的事。Tools 只负责执行不负责判断什么时候该用需要组合才能完成复杂任务。3. 第二层Agent——拿着工具自己做决定3.1 核心定义Agent 是一个完整的决策系统内部用 LLM 做大脑自己判断什么时候调哪个工具、要不要继续、什么时候结束。给 Agent 一个目标比如调研一下最近竞品的动态它不会直接给一个答案而是开始自己思考第一步应该搜索什么关键词搜索结果里有没有需要的信息需不需要多搜几次什么时候才算调研完了这一系列要不要、用哪个、够不够、停不停的判断全部由 Agent 内部的 LLM 做决策。3.2 运行机制思考-行动-观察循环Agent 的运行方式是一个反复循环的过程Thought想清楚→ Action行动→ Observation看结果→ 再 Thought → 再 Action → ...直到 LLM 判断任务完成为止这个循环才结束。用 Go 代码表示这个循环funcRunAgent(taskstring)string{for{thought:llm.Think(task,context)// 思考下一步做什么ifthought.IsDone{// 判断是否完成returnthought.FinalAnswer}result:callTool(thought.ToolName,thought.Args)// 执行工具调用context.AddObservation(thought.ToolName,result)// 记录观察结果}}关键点这个 for 循环会跑几次开发者完全不知道也不需要知道。这正是 Agent 和普通代码最不一样的地方——普通代码的每一步都是开发者预先写好的但 Agent 的执行路径是 LLM 实时决定的。3.3 关键特征主动决策Agent 自己决定执行路径灵活性高能应对预料之外的复杂情况完成事先无法预测路径的任务行为不确定同样的任务今天跑和明天跑可能调了不同的工具、走了不同的路径。这是因为 LLM 本质上是概率模型每次生成都带有随机性灵活性和不确定性是一对孪生兄弟。有 Agent 的灵活就必然伴随着一定程度的不可预测。3.4 边界与局限行为不可预测线上排查困难成本不可控LLM 调用轮次可能超出预期调试难度大执行路径不确定无法打断点逐步追踪4. 第三层Workflow——确定性编排框架4.1 核心定义Workflow 把整个执行流程的骨架写在代码里LLM、Agent、Tools 都只是这个流程里的节点每个节点负责完成自己那一步。但整体走哪条路、下一步去哪里全由开发者的代码决定不是任何节点自己说了算。4.2 技术特征一个客服系统的 Workflow 示例defcustomer_service(user_input):# 第一步意图分类intentllm.classify(user_input)# 第二步根据意图走不同分支ifintentrefund:order_infosearch_order(user_input)resultgenerate_refund_response(order_info)elifintentcomplaint:complaint_infoanalyze_complaint(user_input)resulttransfer_human_service(complaint_info)else:knowledgesearch_knowledge_base(user_input)resultllm.generate_answer(knowledge)returnresult关键点LLM 在这里出现了两次一次是做意图分类一次是生成回答但它只是流程里的两个工位。接下来去哪这件事完全由 if/elif 这些普通代码控制。开发者预先写死执行路径if/elif/else 控制流程高确定性代码看到什么就做什么不会有惊喜易调试可以打断点逐步追踪精确定位是哪个节点出了故障4.3 与 Agent 的核心区别谁在做下一步去哪的决策维度AgentWorkflow决策者LLM 实时决定开发者代码写死行为不确定路径动态变化确定完全可预测调试难执行路径不确定易链路清晰可追踪4.4 边界与局限流程提前写死难以动态调整无法穷举所有情况遇到预料之外输入容易失败或给出很差结果5. 三者对比总结维度ToolsAgentWorkflow决策能力无只执行不决策有LLM 自主动态决策无开发者在代码里写死执行方式被动等待被调用主动自主循环直到完成按开发者定义的顺序执行确定性高输入固定则输出固定低同输入可能走不同路径高行为完全可预测灵活性只做一件事高能应对预料之外的情况低流程提前写死调试难度容易单一函数难执行路径不确定容易链路清晰可逐步追踪适用场景封装单一具体能力路径未知的复杂任务流程相对固定的业务系统6. Agentic Workflow生产环境的主流组合模式完全靠 Agent 自主决策的系统其实很少在生产环境出现原因行为太难控制一旦出问题很难排查成本也容易失控LLM 调太多轮。完全靠 Workflow 写死的系统又太脆弱没法把所有情况都穷举到代码里遇到预料之外的输入就容易失败。Agentic Workflow 的核心思想用 Workflow 固定主流程的骨架在需要灵活判断的节点嵌入 Agent其余固定节点直接用 LLM 或 Tools。Workflow 骨架确定性 ├── 节点 1固定逻辑LLM 或 Tools ├── 节点 2Agent 子模块自主决策灵活应对 │ ├── 子工具 A │ ├── 子工具 B │ └── 子工具 C ├── 节点 3固定逻辑LLM 或 Tools └── 节点 4结果聚合骨架是确定的让你能控制整体行为、便于调试关键节点是灵活的让你能应对各种复杂情况。两个优点都有两个缺点都被削弱了。7. 总结Tools、Workflow、Agent 不是三个并列的竞争方案而是不同粒度的三层结构在项目中通常同时存在、相互嵌套Tools 是手负责执行具体操作不做决策Agent 是大脑自主判断用哪个工具、什么时候结束Workflow 是骨架由开发者预先编排好整体流程生产环境推荐采用 Agentic Workflow 组合模式用 Workflow 固定主流程在需要灵活性的节点嵌入 Agent实现可控与灵活的平衡。
