“I was wrong about the role that LLMs would come to play.” 这句话说得很坦诚也很适合作为一篇复盘式文章的开头。我前两年对 LLM 的判断大致是它会变成一个“什么都能聊、什么文案都能写、什么问题都能答”的通用助理。这个判断不能说完全错但它让我在做真实项目时几乎每一步都走在错误预期上。后来我才慢慢意识到LLM 真正改变的其实不是单次回答的质量而是整个软件流程里“判断”这个环节的归属方式。这篇文章想说的就是我从这个错误判断里得到的东西以及它如何改变了我做 LLM 应用和 Agent 的方式。1. 我原来理解的角色为什么一放进业务就崩了1.1 那时我觉得 LLM 就是“能回答任何问题的东西”大多数人接触 LLM第一步都是聊天。你问它一个常识问题它能给你一段像模像样的回答你让它翻译一段英文它也能翻得通顺你让它写一个小剧本它甚至能写出挺有氛围感的东西。这个体验太容易让人产生一个判断LLM 是一个“知识密集型问答器”只要问题描述清楚它就能给出可用答案。这个判断在对话场景里基本成立但放进真实业务流程里问题就接踵而至。原因很简单业务系统要的不是“一段话”而是“一个符合约定格式、能进入下一环节、错误可以被捕获的结果”。对话场景里答案只要看起来合理就行业务流程里输出必须是结构化的必须稳定必须能解释。我当时犯的错就是把“模型能回答好问题”等同于“模型能取代流程里的判断”。前者只是模型单点能力后者则要求模型嵌进一个系统和上游、下游都有约束关系。1.2 真正放进业务后最先崩的不是效果而是流程我在早期做试验时遇到过几个非常典型的问题。第一是幻觉在业务里不可接受。对话场景里偶尔说错一句话用户可能只是觉得“这 AI 不太聪明”但在业务场景里一段幻觉可能导致错误入库、错误下单、错误结算。你不能靠“重新问一次”来兜底。第二是输出格式不稳定。同一个 Prompt 问十次可能九次输出合法的 JSON一次输出 Markdown 代码块还有一次直接夹带了自然语言。看起来是小事但自动化链路每多一步解析就需要多一层校验和重试。第三是上下文管理极其麻烦。对话是单线程的上下文就是那一屏聊天记录但业务调用往往需要把多轮行为、数据库字段、历史记录、用户权限一起拼进上下文。上下文一旦过长模型注意力会分散上下文一旦过短回答又缺少依据。这个问题靠调 Prompt 没法根治。1.3 判断错了不是模型退步而是定位错了后来我重新看了自己遇到的那些问题发现大部分不是模型能力不够而是我把它放在了一个错误的位置上。我把它当成“最终决策者”希望它直接给出业务可用的结论。但实际能稳定工作的方式是把它当成流程里的一个“判断节点”上游给它足够明确的输入中间控制它的输出边界下游再对它给结果做校验和兜底。这个定位看起来没那么惊艳但它才是 LLM 真正能长期嵌入业务的方式。明白这一点之后我对 LLM 应用开发的理解就从“怎么写好 Prompt”变成了“怎么设计模型与系统之间的边界”。2. LLM 真正的新角色流程里的判断节点而不是答案机器2.1 一个判断节点在流程里是什么体验如果只给 LLM 一个开放问题它就像个没有任务边界的临时工如果给它明确输入、明确约束、明确校验它就是流水线里的一个质检员。举个例子。假设我要做一个把网页内容转成结构化笔记的工具。以前的思路是把网页正文粘贴给 LLM让它总结成一段笔记。但你会发现结果时好时坏格式也不统一。现在我会先把任务拆成几个节点抓取网页提取标题、正文、最后修改时间把正文切成若干块每块单独交给 LLM 过滤噪音再把多块结果合并让 LLM 按照事先定义好的 JSON 结构输出最后用代码校验 JSON 字段是否齐全缺失的字段单独重试。在这个流程里LLM 负责的是“理解内容”和“生成文案”这两个判断环节其他所有事情都不归它负责。它不能决定要抓哪个网站不能决定笔记存到哪个目录也不能决定什么时候重试。这样分工之后单次效果可能没有“一把梭”那么惊艳但整体稳定性提高了非常多。2.2 从“让 LLM 直接给结果”到“让 LLM 参与上下文决策”另一个角色变化是 LLM 参与决策的方式变了。早期很多人习惯让 LLM 直接回答最终结果但真正的 Agent 类应用里LLM 的主业往往不是“输出答案”而是“根据上下文决定下一步做什么”。比如一个客服工单系统里模型看完用户问题后可能需要先判断这个问题属于简单咨询、故障报修还是投诉不同分类对应不同处理流程。再比如一个内容审核辅助系统模型读完一段文本后需要决定是否转人工而不是直接给出“违规/不违规”的最终结论。这种“参与决策”的角色比“直接给正确答案”低一档但更稳定、更可控。为什么因为它把“最终判断”的权力仍然留给了系统或人工。模型负责降低人工的工作量而不是替代人工的责任一旦模型判断错误我们还有机会在后续环节修正。2.3 这个角色变化对开发方式的影响角色变了开发方式也要跟着变。过去做 LLM 应用核心工作是调 Prompt现在做 LLM 应用核心工作是设计流程。你得先画清楚哪个环节需要模型理解哪个环节需要模型生成哪个环节需要工具调用哪个环节需要人类确认。然后才是选模型、写 Prompt、调参数。这种开发方式的转变最明显的体现就是热词里出现的那些词Agent、RAG、MCP、编排框架、精度优化、推理引擎。它们不是炫技概念而是“LLM 从答案机器变成流程节点”这个过程中长出来的基础组件。3. 从框架到 Agent 再到 MCPLLM 角色演进的三个信号3.1 大家问的问题变了说明角色变了如果你关注技术社区一段时间会发现大家讨论 LLM 的问题已经明显变化。早两年重点还在“哪个模型文笔好”“Prompt 怎么写能出更好效果”。现在更多人问的是LLM 应用为什么需要编排框架Agent 怎么和现有系统对接RAG 怎么解决知识更新问题为什么有人把 Spring AI、MCP、RAG、Agent 串在同一个系统里这些问题的共同点是把模型当作一个可以被调用的服务而不是一个站在舞台中央的天才。它们背后真正关心的是如何把模型稳定嵌入业务流程。3.2 编排框架把“不会拆任务”变成“可配置的流程”LLM 本身不会主动拆解复杂任务。你说“帮我整理这份合同的风险点”它可能直接吐出一段风险提示但如果这个任务是“读取合同文件提取关键条款识别风险点生成摘要写入表格”它就需要被安排成一个流程。编排框架解决的就是这件事。它把任务拆成节点把节点之间的数据流串起来并且统一处理日志、缓存、重试、失败分支。社区里常见的 LangChain、LlamaIndex以及 Java 生态里 Spring AI 相关方案都在做类似的事情。你未必一定要用某个框架但这个设计思路是绕不开的没有编排LLM 就是一个个孤立的调用有了编排LLM 才能成为系统的一部分。3.3 Agent把“只会回答问题”变成“会调用工具”Agent 的出现在我看来并不是把 LLM 吹成了“智能体”而是做了一个很朴实的扩展让模型不只输出文字还能输出“调用工具”的指令。你问它“今天北京天气怎么样”它不再直接编一段天气而是先调用天气接口再把接口结果整理成自然语言。这个能力的重要性是让 LLM 从“信息生成”走向“行为驱动”。模型给出调用意图系统负责执行真实动作。如果执行失败模型还能根据报错重新规划。这种“感知—决策—行动—反思”的循环才是 Agent 类应用的核心而不是聊天框里多了一个角色设定。但 Agent 也带来了新的复杂度它会循环调用工具可能越调用越偏它会因为一次错误就全盘推倒造成时间浪费它还会访问各种外部接口权限控制如果没做好就是安全隐患。所以在实际落地时我更建议先用严格的双重校验Agent 只负责提出“建议动作”系统必须检查权限、频率、参数范围之后才真的执行。3.4 MCP把“每个工具都要写胶水代码”变成“标准接口”MCP 解决的是工具接入的标准化问题。在没有 MCP 之前你接一个数据库要写一套代码接一个浏览器要写另一套代码接一个内部系统再写一套代码。每次接入都是重复劳动而且每个工具的返回格式还不一样。MCP 的思路是用一套标准协议把工具暴露给 LLM。模型只要会调用 MCP 工具就能访问文件、数据库、网页、API 等等外部能力。你不需要为每个新工具重新训练模型也不需要为每个工具单独定制 Prompt工具属于哪个 MCP Server配置好路径和参数就能用。在这个模型里LLM 更像大脑MCP 像神经接口。接口标准化之后模型的能力边界就和工程接入成本脱钩了。这也是为什么“实现 MCP Client 与 LLM 连接”会成为许多开发者关心的实际操作问题。3.5 这三个信号指向同一个方向编排、Agent、MCP三者虽然名字不同但指向同一个方向LLM 要从“一个会说话的接口”变成“一个能参与业务流程、调用外部工具、承担特定判断职责的可运维服务”。如果只看到单点模型你会觉得角色没有变化模型还是那个模型但看到整个技术栈的演进你会明白模型的能力边界没有变变的是它周围那套工程系统。那套系统决定了模型能不能真正被用于业务。这才是“我错了”的核心不是模型变成了另外的东西而是模型的角色位置变了。4. 精度、推理引擎与本地部署新角色的新工程负担4.1 为什么精度问题突然变成讨论重点当 LLM 只是个聊天玩具时你不会关心它是 fp16 还是 fp32因为效果差别在对话里很难感知。但当它变成流程节点后同一个输出要进入数据库、触发下游任务、参与计费精度问题就变成了“结果是否可靠”的问题。更现实的原因是成本。模型一旦正式服务显存占用和推理速度直接决定钱怎么花。大模型部署最常见的瓶颈就是显存不够。为了把模型塞进一张卡或者为了降低单次请求成本大家就开始考虑要不要用半精度、混合精度、量化。这不是研究者才关心的问题而是任何一个想上线 LLM 服务的人都会遇到的选择。4.2 fp16、fp32、bf16三者的差异和选择思路这里先给出一个通识层面的对比具体到不同 GPU、不同厂商、不同框架还会有些细节差异落地前一定要结合自己的环境验证。精度格式全称参数存储位数常见用途主要风险实践建议fp32Float3232 位CPU/GPU 基准计算、精度校准显存占用大、推理速度相对慢适合做小规模验证和结果对照不太适合长期高并发服务fp16Float1616 位半精度推理、部分训练场景数值范围窄容易出现上溢或精度损失传统 NVIDIA GPU 兼容性好但要看框架是否提供 loss scaling 这类保护bf16Brain Float1616 位新一代 GPU 上的训练与推理尾数位变少极小数值的精度不如 fp32指数范围和 fp32 接近不容易溢出是不少推理框架的推荐格式从工程经验看如果用的是近几年的 NVIDIA 显卡很多框架默认会往 bf16 方向走如果用的是旧卡就可能遇到 bf16 不支持或者支持不完整的情况。到这一步就要回头再看推理引擎和驱动版本。注意不要只根据“半精度显存减半”这个结论直接上线。先跑一个小批量对比 fp32 和 fp16/bf16 的输出差异确认业务能接受精度损失再决定是否切换。4.3 推理引擎本地和服务端并不是一回事热词里既有“最佳 mac LLM 推理引擎”也有“llm studio”这类本地工具还有面向服务端的推理框架。它们的使用场景差别很大不能混为一谈。本地推理工具的意义是让开发者在没有完整显卡集群的前提下先把模型跑起来。比如在笔记本上用本地推理工具加载模型、体验不同量化版本、验证提示词效果。这种工具的价值在于“开发效率”不一定要追求最大吞吐。服务端推理框架则是另一套逻辑。它要考虑并发请求、显存调度、batch 合并、输入输出长度限制、日志监控、故障恢复。你在本地跑通一个模型离上线服务还有很远的距离。我的建议是开发调试阶段先选最省事的本地推理工具跑通链路小规模内部服务用服务端推理框架部署但先用单机单卡规模化生产再考虑多实例、负载均衡、自动扩缩容、RAG 服务分离、MCP Server 分离。如果一上来就优化到多机部署大概率会陷入运维泥潭连模型本身的问题都还没暴露。4.4 ComfyUI 与 LLM是否必须同一台电脑这个问题在热词里出现时我第一反应是它可能混淆了“同一个工作流”和“同一台机器”。ComfyUI 通常是做图像生成工作流LLM 负责提示词生成、图像描述等文本任务。两者可以通过 API 或本地 HTTP 服务互相调用不一定非要装在同一台电脑上。为什么有人会遇到这个疑问因为本地 ComfyUI 工作流里如果 LLM 模型也在同一台机器上内存和显存压力会直接叠加。图像模型很吃显存LLM 也很吃显存放在一起很容易把显卡爆掉。更合理的做法是把 LLM 部署到独立服务比如一台小机器或一个 API 服务ComfyUI 通过接口去调用。是否同机本质上是一个资源调度问题不取决于软件名字。只要网络能通、延迟可接受、并发量不大分机部署完全没问题。反过来如果只是偶尔一次调用合并在一台机器也能跑只是要控制并发数量。5. 把 LLM 当成流程节点来用的最小落地方法5.1 第一步先做一个不需要框架的单点任务不要一上来就接 Agent 编排框架。先用一个最简单的 LLM 调用完成一个单点任务把输入、输出、错误都看清楚。比如让模型判断一段文本的情感类别输出 JSON{sentiment: positive}。这一步的重点是确认三件事模型能稳定理解你的输入格式模型能在绝大多数情况下输出合法 JSON模型对边界输入有没有异常表现比如空文本只给“中性”。如果单点任务都不稳定后续接入任何框架都只会放大问题。5.2 第二步给输入输出加上边界和校验模型不能直接裸奔。你要在它前后各加一层“护栏”。前面的护栏是输入清洗把多余空白去掉把文本截断到模型支持的上下文长度把过长的内容分块避免模型因为输入异常而跑偏。后面的护栏是输出校验拿到模型输出后先检查是不是合法 JSON再检查关键字段是否存在再检查字段值是否在允许枚举范围。如果校验失败可以用一条固定 Prompt 重试一次重试仍失败就走人工兜底流程。这一步其实就是把 LLM 当成普通服务处理。不信任它的输出校验完之后才允许它进入业务流。5.3 第三步接一个编排框架或 Agent把判断交给模型单点任务稳定之后再考虑多步骤流程。这时才轮得到编排框架和 Agent。比较保守的做法是流程还是由代码控制但在每个决策节点调用 LLM。比如“先判断分类再决定走哪个分支”每个分支都是一个独立 Prompt。程序员控制流程模型负责判断两边边界清晰。如果你想做得更激进一点可以让 Agent 自己规划步骤。但我会建议先限制它可用的工具数量比如只给它四个工具并且每个工具都要带说明和参数校验。工具越少它越不容易跑偏等它对一个小工具集稳定之后再逐步扩充。5.4 第四步接知识库和外部工具让节点有“记忆”和“手脚”很多任务只靠模型自身的知识不够需要接 RAG。RAG 的作用是从自己的文档库或数据库里检索相关内容把检索结果作为上下文塞给模型让模型的回答有依据。接 RAG 时最容易踩的坑是“检索到一堆无关内容反而干扰模型”。你要做两件事一是对文档做清洗和分块分块太大容易混入噪音太短又缺少上下文二是对检索结果做重排不要把所有相似片段一股脑塞进上下文。接外部工具时则先考虑 MCP 这样的标准协议。如果工具支持 MCP就省去自己写重复接入代码。但也要注意MCP Server 本身是一个独立进程或服务它的稳定性、权限、日志、监控都要纳入整体运维体系否则模型调不动工具整条链路也会卡住。5.5 通用排查链路从现象看到底层实际运行中问题总是会出现的。按下面的顺序排查能帮你少走弯路1. 看现象 - 无输出、报错、输出格式错误、结果不稳定、速度慢 2. 看输入 - 文本是否被截断、编码是否异常、文件路径是否正确、上下文是否完整 3. 看环境 - 依赖版本、Python/Node 版本、GPU 驱动、推理引擎版本是否匹配 4. 看参数 - max_tokens 是否太小、temperature 是否过高、并发和批大小是否撑爆显存 5. 看工具边界 - 模型本身是否适合这个任务、工具是否支持当前输入、MCP Server 是否活着这个顺序看起来简单但很多人一上来就改 Prompt、调参数结果问题反而出在输入路径写错了或者推理引擎版本不兼容。先确认底层链路是通的再往上排查。6. 新角色的适用边界哪些任务该交给 LLM哪些不该6.1 适合 LLM 参与的任务特征任务需要理解自然语言比如总结、分类、抽取、改写任务没有固定规则需要根据语义做判断错误可以被接受或者可以被校验兜底任务的重心在“生成长文本”或“理解长文本”而不是精确计算。比如邮件分类、工单摘要、商品描述的批量润色、会议纪要结构化、客服问题的意图识别这些都是典型适合 LLM 的场景。因为它们原来就需要人去做判断和书写模型参与后成本显著下降质量也相对稳定。6.2 不适合 LLM 参与的任务特征任务需要精确计算比如金额汇总、库存扣减任务需要严格一致的结果比如同一段输入必须得到完全相同的输出任务涉及敏感决策且无法审计比如自动审批贷款、自动诊断疾病任务有明确规则用正则或代码就能实现没必要引入模型。在真实系统里你需要问一个问题如果模型这一条回答错了系统能不能兜住如果能LLM 可以参与如果不能这个环节就不该让 LLM 负责。这不是对模型的不信任而是工程上的底线。6.3 长期使用还需要补的工程能力把 LLM 当流程节点用长期会有三类问题冒出来。第一是稳定性。模型版本更新后之前好用的 Prompt 可能一夜之间行为变化。要对模型输入输出做埋点和回归测试像对待普通代码一样看待模型行为变化。第二是成本。长上下文、多次重试、Agent 反复调用工具都会让 token 消耗迅速上升。要建立日志审计能看清楚每一次请求花在了哪一环节。第三是权限与安全。Agent 一旦拥有工具调用能力就相当于给模型开了一个“能执行动作”的入口。这个入口必须做最小权限控制所有高危操作都要求二次确认。提醒Agent 不是不能用而是要让它在看不见的边界里运行。工具调用、数据访问、文件读写都要有白名单。不要让模型随便“发挥”。7. 回到那句话我错了但错在哪里很有价值7.1 错在把单个节点当成整个系统回看“I was wrong about the role that LLMs would come to play”这个标题我最认同的一点是很多人和我一样曾经以为 LLM 会扮演一个“站在舞台中央的超级助手”。但现实里更常见的角色是隐藏在流程里的一个判断节点负责在恰当的位置给系统一个决策建议然后由系统决定是否采纳。这个角色看起来不耀眼但它更接近软件系统的本质。系统不需要每个环节都惊艳系统需要的是每个环节可预测、可维护、可替换。LLM 作为判断节点恰好是“可预测、可维护、可替换”都还做得不够好但它第一次让“判断”这个环节可以被写入代码流程这才是它真正改变的事情。7.2 接下来最该做的一件事如果你正准备把 LLM 放进真实项目不要急着构建宏大蓝图。选一个最小任务明确输入输出加上校验跑通之后再逐步接编排、Agent、RAG、MCP。等你跑完这一轮你会发现模型是什么模型反而不重要了真正重要的是你设计的那套流程能不能在模型变化时依然稳定工作。这个认知调整比我调过的任何一个 Prompt 都值钱。