Agent 和 Workflow 到底有啥区别这是最近后台被问到最多的问题之一而且问的人不光是刚入门的新手一些已经写过不少 LLM 应用的工程师在被问“你这个东西到底是 Agent 还是 Workflow”时也常常会愣一下。老实说这个问题在 2026 年的大模型应用开发语境下确实是绕不开的“第一性”问题。现在市面上有 LangChain、LangGraph、AutoGen、Dify、Coze还有各类企业级 Agent 平台里面有节点编排、有工具调用、有记忆、有“智能体”按钮看得人眼花缭乱。很多人把项目做出来了但是被同事一问“你是用 Workflow 还是 Agent 做的”自己却说不出一个清晰的判断标准。这篇文章我不想再给你复制一遍官方文档里的定义。我想从一个真实的开发困惑出发把这两个概念放到同一张桌子上对比讲清楚它们的本质差异、适用边界、代码层面的区别以及现在工业界最常用的“Workflow 做骨架、Agent 做节点”混合架构。读完你至少能做到一件事以后不管别人怎么问你都能用一套自洽的话把两个概念讲明白并且能根据自己项目的实际情况做选型。1. 为什么这个问题会让很多人犯迷糊先说一下我为什么觉得这个问题值得单独写一篇。过去两年大模型应用开发的“技术热词”换了好几轮一开始大家聊 Prompt 工程后来聊 RAG再后来就是 Agent。到了 2025 年左右Workflow 这个词又开始频繁出现在各种低代码平台和框架的文档里。于是问题来了Agent 不是能自己规划、自己调用工具吗那还要 Workflow 干什么很多平台为了让用户上手简单把 Agent 做成“一句话生成一个智能体”把 Workflow 做成“拖拽节点编排流程”。这种产品化的包装反而让概念更模糊了看起来都是画图都是连节点都能调用大模型凭什么这个名字叫 Agent、那个名字叫 Workflow再加上一些团队在内部技术方案评审时经常为了“用 Agent 还是 Workflow”争得不可开交。有人说“以后都是 Agent 的天下Workflow 过时了”有人说“Agent 不可控还是老老实实用 Workflow”。这两种说法在我看来都只看到了表面。如果只从产品形态看你确实很难区分。但如果从架构层面看这两者的差异其实非常清晰而且直接决定了你的系统是“可控优先”还是“灵活优先”决定了你的成本是“可预测”还是“波动”决定了一个 bug 是可以按步骤定位还是只能靠日志和 trace 去猜。所以我想给的第一个判断是Agent 和 Workflow 的本质区别不在于“谁更智能”而在于控制权在谁手里。控制权在代码手里是 Workflow控制权在大模型手里是 Agent。这个判断虽然简单但能解释后面绝大多数现象。2. 基础概念用白话拆解 Agent 和 Workflow在给代码示例之前先把两个概念说到位。我不会用百科式的定义而是用“它到底在工程里扮演什么角色”来讲。2.1 Workflow 是什么把“怎么做”提前写死Workflow 的本质是一套预先定义好的执行流程。流程里的节点、节点之间的先后关系、每个节点的输入输出格式在系统运行之前就已经确定了。你可以把它理解成一条流水线原材料从入口进去经过 A 工序、B 工序、C 工序最后出来成品。中间如果某道工序需要判断也是代码提前定义好的规则比如“如果结果大于某个阈值就走 A 分支否则走 B 分支”。在大模型应用里Workflow 的典型特征是大模型只是流水线里的一个“工序”它负责完成某一个具体的子任务比如写一段摘要、抽取结构化信息、生成一段文案。但“这一步做完下一步做什么”“做完之后怎么判断结果是否合格”这些逻辑不受大模型控制而是由开发者写死在代码里。举一个非常具体的例子。假设你要做一个“搜索资料 → 生成摘要 → 翻译成英文 → 输出日报”的功能。如果用 Workflow 实现流程是这样的节点一调用搜索 API得到原始资料节点二把原始资料丢给大模型让它生成中文摘要节点三把中文摘要丢给大模型让它翻译成英文节点四把英文摘要写入日报模板输出。这个流程里大模型参与了两处但每一步都是固定的。节点二永远只做摘要节点三永远只做翻译不会出现“节点二自己决定先去翻译再返回摘要”的情况。这就是 Workflow流程固定、职责固定、输入输出固定。2.2 Agent 是什么把“做什么”和“怎么做”都交给模型Agent 的本质是让大模型作为系统的“决策中枢”。你给它的不是一个完整的执行路径而是一个目标、一组可用的工具、以及一些边界约束。具体要分几步完成目标、每步调用哪个工具、调用完之后怎么处理结果由大模型根据当前上下文动态决定。回到刚才那个例子。如果你用 Agent 来实现“生成一份英文日报”你做的事情是给 Agent 一个搜索工具、一个摘要工具、一个翻译工具然后告诉它“请生成一份关于今天行业动态的英文日报”。接下来Agent 可能会自己决定先搜索三条新闻然后分别做摘要再做翻译最后组合成日报。它也可能觉得搜索一次就够了也可能搜索完发现信息不够要先再搜一轮。这个过程里不仅大模型在“干活”大模型还在“安排活”。它不是一个被动的执行节点而是一个主动的调度者。所以 Agent 这种架构最大的优点就是灵活能处理很多流程不确定的任务最大的问题就是不可控你不知道它下一次会走哪条路也猜不到它会在哪个环节“发挥创意”。这也是很多生产环境对 Agent 既爱又怕的根本原因。2.3 一句话对比你可以这样记Workflow 是“把流程提前设计好模型在流程节点里干活”。Agent 是“把目标告诉模型让模型一边规划一边干活”。这里再补充一个很常见的误区很多人以为“只要在项目里调用了大模型就是 Agent”。这是错的。如果你的代码把每个步骤都写死了只是让大模型在某个步骤里帮忙生成文本那你做的依然是 Workflow。Agent 的关键不是“有没有用模型”而是“模型有没有决策权”。从热词里也能看出来现在社区里讨论的 Agent 开发、Agent 框架、Agent 的记忆和工具调用都是围绕“让模型拥有更多决策权和自主行动能力”展开的。而这个方向正好和 Workflow 所代表的“流程确定性”形成了对比。3. 核心区别控制权、确定性与工程取舍这一节是全文最核心的部分。我把 Agent 和 Workflow 的区别拆成五个维度每个维度都直接关系到工程实现。3.1 决策权归属前面说了这是最根本的区别。在 Workflow 里决策权在开发者的代码里。代码定义了图结构节点之间的边是固定的。即使有分支判断分支条件也是开发者写好的逻辑不是模型“自由意志”的产物。在 Agent 里决策权在大模型手里。模型根据 system prompt 里的指令、用户的输入、当前工具返回的结果动态决定下一步动作。这意味着同样的输入模型可能会走完全不同的路径。这个差异直接决定了系统的行为是否可以预测。对于需要审计、合规、稳定输出的场景Workflow 天然更友好对于需要探索、试错、灵活应变的任务Agent 更有优势。3.2 流程状态管理Workflow 的流程状态通常非常清晰。走到哪一步了、这一步的输出是什么、下一步应该由谁处理都是显式的。开发者很容易打印出每一步的输入输出问题一出就能定位到具体节点。Agent 的状态管理要复杂得多。Agent 在运行中会产生一个“推理 → 行动 → 观察”的循环每一步都会产生中间输出这些输出又会影响下一步的决策。如果你没有完善的 trace 机制很容易出现“模型绕了一大圈最终结果还是错的”的情况而且你很难复现。3.3 业务边界与安全边界Workflow 的边界天然严密。不管模型怎么回答它只能影响当前节点的输出不能影响整个流程走向。比如在风控流程里你想让模型帮忙做“用户意图识别”但不想让它决定“是否放行”那就用 Workflow把“是否放行”的逻辑放在代码里或者放在人工审核环节。Agent 不一样。Agent 可以调用工具可以访问外部系统甚至可以修改自己的计划。如果工具集的权限设计得不够细致Agent 有可能执行出开发者意料之外的操作。这就是为什么“Agent 安全”会成为独立的话题——当你赋予模型调用外部系统、读写数据的能力时必须有额外的安全限制比如工具白名单、敏感操作二次确认、操作审计。3.4 成本与延迟这里说的成本不只是钱还包括 token 消耗和响应时间。Workflow 的 token 消耗是相对可控的。因为你提前知道要调用几次模型、每次输入输出大概多长。延迟也基本稳定因为调用链路是固定的。Agent 的 token 消耗和延迟波动很大。如果任务比较复杂Agent 可能会反复调用工具、多次尝试、甚至陷入循环。一次简单的查询可能只需要两次调用但也可能因为模型走错方向连续调用了十几次工具都还没结束。在成本敏感或延迟敏感的场景里这个不确定性是必须考虑的问题。3.5 调试与维护Workflow 的调试接近传统软件打断点、看日志、查中间状态因为控制流是显式的。你可以在任何一个节点前后加日志甚至可以单独测试某个节点。Agent 的调试更像是在“观察一个实习生干活”。你只能看到它做了什么但不能完全理解它为什么这么做。对 Agent 类应用的故障排查通常需要依赖完整的 trace 记录包括模型的推理过程、每次工具调用的请求和响应、每一步的 token 消耗。没有这些出了问题基本靠猜。3.6 一张表看懂区别为了便于记忆我用一张表把关键维度列出来。这张表也是我在团队做技术选型时常用的参考。对比维度WorkflowAgent核心特征流程固定节点预定义流程动态模型自主规划控制权归属开发者代码大模型可预测性高低可观测性好按节点定位差需要完整 traceToken 消耗可控波动小波动大难以预估延迟相对稳定波动明显安全边界天然可控需要额外设计权限约束适用任务流程明确、输出稳定的任务流程不明确、需要探索的任务调试难度低高典型工程实践内容生成流水线、定时报告智能客服、自动化运维、多工具调度你可以把它理解成编程里的“命令式编程”和“声明式编程”的区别。Workflow 像命令式把每一步都写清楚Agent 像声明式你说清楚要什么结果执行细节交给系统自己做。这样理解工程上的很多取舍就说得通了。4. 从代码层面看两者差异概念讲再多不如看代码。这一节我用两个最小示例让你直观感受 Workflow 和 Agent 在代码实现上的差异。代码只是最简化演示重点看结构和决策权的分配。4.1 用 LangGraph 构建一个 Workflow 示例LangGraph 是目前实现 Workflow 比较主流的库之一。它的核心思想是让你显式地定义一个图Graph然后按图执行。# 文件路径examples/workflow_example.py from typing import TypedDict from langgraph.graph import StateGraph, END # 定义整个流程的状态结构 class State(TypedDict): query: str search_result: str summary: str output: str # 节点一搜索 def search_node(state: State) - dict: query state[query] # 这里简化处理实际可以调用搜索引擎 API search_result f搜索结果 for {query} return {search_result: search_result} # 节点二生成摘要 def summarize_node(state: State) - dict: content state[search_result] # 这里简化处理实际可以调用大模型生成摘要 summary f摘要: {content} return {summary: summary} # 节点三输出格式化 def format_node(state: State) - dict: summary state[summary] return {output: f[日报] {summary}} # 构建图结构 graph StateGraph(State) graph.add_node(search, search_node) graph.add_node(summarize, summarize_node) graph.add_node(format, format_node) # 显式指定边的连接关系 graph.set_entry_point(search) graph.add_edge(search, summarize) graph.add_edge(summarize, format) graph.add_edge(format, END) # 编译并执行 app graph.compile() result app.invoke({query: LangGraph}) print(result[output])这段代码的核心不是“调用了大模型”而是三个节点的连接关系在编译前就已经确定。即使你把summarize_node里的模型换成任意一个文本处理函数整个流程也能按同样的路径执行。这就是 Workflow 的典型特征结构固定、职责清晰、顺序明确。4.2 用 LangChain 生态构建一个 Agent 示例Agent 的经典实现方式是“模型 工具”。开发者只负责定义工具以及告诉模型有哪些工具可用至于模型怎么调用工具由模型自己决定。# 文件路径examples/agent_example.py from langchain_openai import ChatOpenAI from langchain_core.tools import tool from langchain.agents import create_tool_calling_agent, AgentExecutor # 定义一个工具加法计算 tool def add(a: int, b: int) - int: 计算两个整数的和。 return a b # 定义一个工具乘法计算 tool def multiply(a: int, b: int) - int: 计算两个整数的积。 return a * b llm ChatOpenAI(modelgpt-4o, temperature0) # 创建 Agent传入模型和工具列表 agent create_tool_calling_agent(llm, [add, multiply]) executor AgentExecutor(agentagent, tools[add, multiply]) # 直接给定一个目标不指定执行步骤 response executor.invoke({ input: 请计算 23 45然后把结果乘以 2最终告诉我答案 }) print(response[output])这段代码里你告诉 Agent 的是“目标”不是“步骤”。模型可能会自己规划先调用add(23, 45)得到 68再调用multiply(68, 2)得到 136。也可能模型觉得不需要调用工具直接口算出结果。总之调用链是运行时由模型决定的。这就是 Agent 的典型特征目标明确、路径动态、模型拥有决策权。4.3 一个非常容易被忽略的细节从代码对比可以看出开发 Agent 的过程中有一个隐性成本很容易被忽略你不仅要写业务逻辑还要写“给模型看的提示和约束”。比如上面这个 Agent如果工具很多、任务很复杂你还要在 prompt 里讲清楚每个工具是干什么的、适合什么场景如果工具返回异常应该怎么处理什么时候该停止、什么时候该向用户确认。这些内容传统开发里是不存在的。写 Workflow 时你只需要保证代码逻辑正确写 Agent 时你还要保证“模型在关键时刻能做出正确的判断”。这是两类开发的思维差异也是很多后端工程师转到 Agent 开发时最不习惯的地方。5. 场景选型到底该用 Workflow 还是 Agent这一节给出可操作的建议。我的判断很明确不要为了用 Agent 而用 Agent也不要因为 Agent 不可控就完全回避它。选择的关键在于你的任务对“过程确定性”要求有多高。5.1 优先选择 Workflow 的场景如果任务满足下面任意一条优先考虑 Workflow步骤固定。比如内容审核流程先做敏感词过滤再做模型判定最后人工复核。这个顺序不能变。输出结构稳定。比如固定字段的 JSON 抽取、每日报表生成每个字段的来源都是确定的。对失败路径有明确要求。比如“如果模型返回结果不合法就走 A 分支否则走 B 分支”。需要审计和合规。比如金融、医疗、政务领域要求每个决策都能溯源到具体规则不能出现“模型自由发挥”的黑盒。典型的 Workflow 案例一句话新闻摘要定期推送客服工单自动分类加标签RAG 问答流程查知识库 → 组装上下文 → 模型生成 → 答案校验合同关键信息抽取固定模板、固定字段。在这些场景里如果你强行引入 Agent表面上看起来更“智能”但实际上只会增加成本、降低稳定性还会让排查问题变得非常痛苦。5.2 优先选择 Agent 的场景如果任务满足下面任意一条可以考虑 Agent流程不固定需要根据中间结果动态调整。比如“帮我订机票 订酒店 安排行程”具体先做哪一步取决于用户偏好。需要调用大量外部工具且工具选择依赖上下文。比如一个工具列表里有搜索、计算、代码执行、数据库查询模型需要根据任务决定用哪个。面对的是开放式的、无法预先穷举的任务。比如“请帮我分析这份报告并把发现写成邮件”报告内容不同分析路径也不同。需要处理用户的模糊需求并在执行中主动澄清。典型的 Agent 案例通用型智能客服自动化运维助手数据分析助手需要自动写代码查数据个人 AI 助理需要调用日历、邮件、支付等外部服务。这些场景里如果你强行用 Workflow就要为每种可能的情况写分支逻辑不仅工作量巨大而且一旦出现预期之外的输入整个流程就崩了。5.3 最常见的工程选型建议在实际业务中真正需要“纯 Workflow”或“纯 Agent”的其实很少。绝大多数项目是混合形态。这也是 2026 年大模型工程化领域的一个共识把确定性高的部分做成 Workflow把需要灵活决策的部分交给 Agent两者嵌套使用。举个例子。一个智能客服系统可以这样设计外层是 Agent负责理解用户意图、判断是否需要转人工、决定调用哪个业务服务内层是 Workflow负责执行那些固定流程比如订单查询、退款申请、投诉记录。当 Agent 判断用户要查订单时它不直接操作数据库而是触发一个“订单查询 Workflow”由 Workflow 完成身份校验、数据库查询、结果格式化等固定步骤。这样既保留了 Agent 的自然语言理解能力又让关键业务操作保持可控可审计。这种“大流程套小流程”的设计在工程上非常实用。我建议你哪怕现在做的只是一个学习项目也尽量从这个混合视角入手而不是二选一。6. 混合落地Workflow 做骨架、Agent 做节点的模式前面说混合架构是最常见的工程解法这一节给出一个更具体的落地示例。我以一个“智能报告生成系统”为例。想象这样一个需求用户输入一个主题系统自动从多个数据源获取信息、生成分析报告、并发送邮件给相关人员。这个任务可以拆成三层固定流程层Workflow获取数据 → 生成报告 → 发送邮件这三步的顺序和格式都是确定的灵活决策层Agent数据源怎么选、报告里重点分析什么、结论怎么组织这些都可以让模型根据主题动态决定外部工具层数据库查询工具、邮件发送工具、搜索工具由 Agent 或 Workflow 按需调用。用代码示意一下# 文件路径examples/hybrid_example.py from typing import TypedDict from langgraph.graph import StateGraph, END from langchain_openai import ChatOpenAI from langchain_core.tools import tool from langchain.agents import create_tool_calling_agent, AgentExecutor class ReportState(TypedDict): topic: str raw_data: list report: str email_sent: bool # 外部工具数据查询 tool def query_database(table: str) - str: 按表名查询数据返回最新的业务指标。 # 这里简化为固定字符串实际会执行 SQL return f{table} 的最新数据: [2026-03, 2026-04] # Agent 层根据主题决定查询哪张表并生成分析结论 def research_and_analyze(state: ReportState) - dict: llm ChatOpenAI(modelgpt-4o, temperature0) agent create_tool_calling_agent(llm, [query_database]) executor AgentExecutor(agentagent, tools[query_database]) result executor.invoke({ input: f请围绕主题 {state[topic]}查询相关数据表并生成一段数据分析结论 }) return {raw_data: [result[output]]} # Workflow 层固定的报告组装和邮件发送步骤 def write_report(state: ReportState) - dict: content \n.join(state[raw_data]) report f# {state[topic]} 分析报告\n\n{content} return {report: report} def send_email(state: ReportState) - dict: # 实际会调用邮件服务 print(f发送邮件: {state[report][:50]}...) return {email_sent: True} # 构建混合图 graph StateGraph(ReportState) graph.add_node(agent_analyze, research_and_analyze) graph.add_node(write_report, write_report) graph.add_node(send_email, send_email) graph.set_entry_point(agent_analyze) graph.add_edge(agent_analyze, write_report) graph.add_edge(write_report, send_email) graph.add_edge(send_email, END) app graph.compile() result app.invoke({topic: 2026年平台营收趋势}) print(email_sent:, result[email_sent])这个例子里决策工作交给了 Agent但整体流程被 Workflow 包住了。这样写的好处很明显如果 Agent 阶段出了问题你只需要排查这个节点后面的流程不会受影响报告格式、邮件发送这些固定环节具有稳定性不会被模型“擅自改写”整个系统呈现给用户的是“一个智能的 Agent”但内部的关键操作是可解释、可回滚的。这种模式在真实项目中非常常见。你可以把它概括为Process流程为主Intelligence智能为辅——智能体有边界的自由关键流程有代码的确定性。7. 常见问题与排查思路写到这里把新手最常遇到的几个问题整理成表格方便你以后排查。问题现象可能原因排查方式解决方案Agent 反复调用工具迟迟不给出最终结果模型缺少“何时停止”的明确指令或工具返回结果不够明确查看 Agent 的完整 trace统计每轮 tool call 的输入输出在 system prompt 里明确“拿到足够信息后立即输出结论”设置最大迭代次数同一个 Agent 任务结果时好时坏模型幻觉、prompt 不够结构化对比多次输出检查失败案例的特征增加输出 JSON Schema 约束对关键步骤增加校验节点Workflow 中某一步需要灵活判断但代码写死了导致结果不满足需求该节点本应由 Agent 承担却被强行做成 Workflow分析用户输入变化频率看是否有无法穷举的分支把这个节点替换为 Agent 节点或增加模型判断分支Agent 在调用外部系统时出现越权操作工具权限控制不严格查看工具调用记录确认用户请求与工具操作的匹配度增加工具白名单、敏感操作二次确认、最小权限设计Agent 输出结果是一个良好的 JSON但字段始终对不上模型没有严格遵循输出格式检查 prompt 中 JSON Schema 是否明确使用结构化输出能力或在 prompt 里给出正反例Agent 单次调用 token 成本过高上下文越来越长工具返回结果过大看 token 消耗曲线定位是工具结果还是历史消息占大头对工具返回结果做截断定期清理历史消息使用更便宜的模型做中间步骤Agent 出现执行错误并提示 “terminated due to error”模型调用了不存在的工具名或参数格式错误查看最后一次 tool call 的请求体对比工具 schema统一工具参数校验在 prompt 中强调“必须使用给定工具”表格里提到的“最大迭代次数”“工具白名单”“trace 记录”是 Agent 生产化里最基础的三道防线。尤其要注意任何进入生产环境的 Agent都必须有迭代上限、超时控制和完整的日志记录。否则一旦模型进入死循环既浪费 token 又会让用户等不到结果。8. 大模型应用开发的最佳实践如果你正在做一个既涉及 Agent 又涉及 Workflow 的项目下面这八条经验值得收藏。8.1 先用 Workflow 把主流程跑通再加 Agent不管最终架构是 Agent 还是 Workflow第一版都建议先用固定流程实现。不要一上来就写一堆 Agent 代码。因为 Workflow 版本更容易定位问题也能让你快速验证业务逻辑是否成立。等到主流程稳定了再把那些需要灵活处理的节点替换成 Agent。8.2 给 Agent 限定工具集而不是给全部工具一个 Agent 可用的工具越多选择错误的概率越高。给 Agent 的工具应该是“当前任务最少需要的那几个”而不是整个系统所有工具。工具集越精简模型越容易做出正确选择也越容易排查问题。8.3 每个工具都要有清晰的描述在很多 Agent 框架里工具函数名和 docstring 直接影响模型能否正确调用。给工具写描述时要写清楚“这个工具是做什么的”“适合什么场景”“什么时候不要用”。这是很多初学者容易忽略的地方也是工具调用成功率低的重要源头。8.4 为 Agent 设置最大迭代次数和超时时间这个前面提过这里再强调一次。生产环境里Agent 的每次执行都应该有迭代上限、token 上限、时间上限。超过限制就中止并走兜底逻辑比如返回错误提示或转人工。这是保护系统稳定性的底线。8.5 用 Workflow 做关键业务操作的安全边界如果 Agent 需要访问数据库、发送邮件、执行订单操作不要直接让 Agent 操作底层系统。正确做法是让 Agent 生成一个“操作意图”由 Workflow 或代码层来执行这个意图并做校验。这样即使 Agent 的意图有问题底层系统也不会被直接破坏。8.6 建立完整的 trace 体系Agent 的调试依赖 trace。每次运行都要记录输入、模型推理过程、每一步工具调用的请求响应、token 消耗、最终结果。市面上很多框架已经内置了 trace 或 callback 机制建议接入统一的日志平台方便出问题时回溯。8.7 用评测集来验证 Agent 质量Agent 是动态的不能只靠几个测试用例验证。建议准备一个覆盖多种场景的评测集每个用例记录期望行为然后用统一脚本跑测试对比每次改动前后的通过率。这个做法在传统开发里叫“回归测试”在 Agent 开发里同样适用。8.8 成本和性能预算要提前做Agent 应用的 token 消耗比普通 RAG 应用高一个量级。上线前要评估清楚单次会话平均 token 消耗、峰值 token 消耗、月成本上限。为了防止极端情况可以给 Agent 配置单日预算、单次请求预算超支自动熔断。9. 总结回到最初的问题Agent 和 Workflow 到底有啥区别一句话区别在于控制权——流程由代码控制就是 Workflow流程由模型控制就是 Agent。它们不是两个互相排斥的技术路线而是同一套大模型应用架构里的两种组件。Workflow 解决的是“确定性”问题Agent 解决的是“灵活性”问题。真正成熟的项目往往是用 Workflow 守住流程边界用 Agent 承担自由决策把两者的优势叠加起来。如果你是刚开始接触这个领域我建议你按这个顺序实践先写一个纯 Workflow 的例子再写一个纯 Agent 的例子最后把 Agent 嵌进 Workflow 的一个节点里。做完这三步你对这两个概念的理解会比看十篇概念文章都深刻。如果你已经在做生产项目那么这篇文章最值得你带走的一句话是对在线业务保持敬畏不要把所有决策都交给模型也不要因为模型不可控就放弃智能化升级。用确定性流程保住下限用自主智能提升上限这才是大模型应用工程化最务实的路。