★ FEATURED ARTICLE 做了几年大模型应用落地我最深的感受是Demo和产品之间隔着一整个LLMOps的距离。很多团队在原型阶段跑通了个对话机器人、智能问答助手就觉得大功告成结果一进生产环境就露馅了——Prompt改一次线上崩一次、模型服务不稳定没人知道该找谁、Agent调用工具出错连日志都翻不明白、部门之间的模型费用算不清楚。这些问题单靠某个框架、某个算法工程师的“妙手”是解决不了的它需要一套体系化的工程能力支撑。这篇内容要讲的就是围绕“LEC-LLMOps平台”这样一个基于智能体工作流的企业级AI应用开发平台完整拆解它从设计到落地的全链路思路。我会把平台要解决的核心问题、智能体工作流引擎的设计方式、企业级能力权限、安全、成本、可观测的搭建要点以及我在实际实施过程中踩过的坑和排查经验一并梳理出来。如果你正准备在企业内部做AI应用平台或者正在思考怎么把零散的Agent脚本变成可维护、可治理的生产系统这篇文章会比那些只讲Demo的教程实在得多。1. 项目出发点企业做LLM应用卡点从来不在“模型”在动手设计这个平台之前我先把企业使用大模型遇到的典型问题列了一遍。列完之后发现几乎没有一个问题是“模型能力不够”造成的问题全部集中在模型之外的工程和管理层面。1.1 先看清LLMOps要解决的三个真问题第一个问题毫无悬念是Prompt和应用的治理。在一个稍微正规点的团队里可能出现几百条不同的Prompt分散在代码里、配置文件里、甚至某个同事的本地笔记里。没有版本管理、没有评审机制、改坏了没法回滚。更麻烦的是Prompt往往和业务逻辑耦合在一起改一条Prompt影响的可能是整个对话链路。第二个问题是Agent工作流缺乏标准的编排和运行机制。很多团队早期是用硬编码的方式写Agent逻辑if-else判断该调哪个工具、循环里塞一个模型调用、工具出错直接在代码里throw异常。这样写出来的系统根本谈不上复用换个业务场景就得推倒重来。真正的生产级智能体应用需要一种声明式的、可视化可追踪的工作流编排方式让开发、测试、业务方都能看清整个逻辑链路。第三个问题是可观测性与成本治理几乎空白。大模型应用和传统应用最大的差异在于它的不确定性同样的输入这次和下次可能输出完全不同的内容。如果平台不能记录每次调用的输入输出、token消耗、耗时、模型版本、Prompt版本出问题的时候就是一场灾难。成本也一样企业内部各业务线用模型费用必须能分摊到具体项目和部门否则预算完全失控。1.2 为什么智能体工作流是这个时代的答案如果说LLMOps是目标那智能体工作流就是实现目标的最佳载体。它的价值在于把模型、工具、数据、人这四类资源统一放到一个可编排的体系里用工作流的方式描述“一个复杂任务是怎么一步步完成的”。我举个例子。一个企业内部的知识库问答助手如果只是单纯的检索问答那不用Agent一个RAG管道就够了。但如果你要它完成“查询本月销售数据→对比三个区域的完成率→生成分析结论→给出改善建议”这种多步骤任务就必须引入智能体工作流了。因为每一步依赖上一步的输出每一步可能调用不同的工具和模型而且过程中还可能出错、需要重试、甚至需要用户确认。LEC-LLMOps平台在设计上就是围绕“工作流”这个核心概念展开的。它把一次智能体任务拆解为节点Node、边Edge、状态State三个维度节点定义了做什么边定义了执行顺序和条件分支状态负责在整个流程中传递和积累数据。注意我们在这里讨论的智能体工作流和传统的工作流引擎比如审批流、业务流程管理BPM有本质区别。BPM的流程是固定的人在里面按步骤操作LLM工作流是有弹性的模型会根据上下文决定走哪个分支、要不要调整执行计划、甚至自己创建新的子步骤。设计平台时一定不要把两者混为一谈否则会把模型的能力框死。2. 平台整体架构与核心设计思路架构设计的核心原则用一句话概括就是把复杂留给平台把简单留给开发者。用户面对的是一个可拖拽、可配置、可调试的工作流编辑器而底层则是一整套负责调度、推理、缓存、监控的分布式系统。2.1 四层架构各司其职我把平台划分为四层每层只做自己该做的事情。接入层API网关与服务入口统一对外暴露RESTful API和WebSocket接口负责鉴权、限流、超时管理。企业里的调用方可能是Web前端、移动端、内部系统、第三方系统每一类调用方的QPS优先级和配额都不一样这一层就是第一道关卡。编排层工作流引擎与智能体运行时这是整个平台的核心。它负责解析工作流定义、维护执行状态、调度节点运行、处理分支和循环、管理重试与异常恢复。能力层模型网关、工具库、知识库、记忆库把模型调用、外部工具、向量检索、上下文记忆统一封装为可编排的能力节点。能力层向上提供统一的接口协议向下屏蔽不同模型供应商和工具服务商的差异。数据层指标、日志、审计、版本仓库所有运行过程中产生的数据都落到这里包括调用日志、Token统计、Prompt版本、工作流版本、评估结果。这四层的关系好比是接入层是大楼的前台编排层是大脑和中枢神经能力层是各种专业的职能部门数据层则是档案室和监控室。缺了任何一层平台都会失衡。2.2 技术选型的关键取舍技术栈这部分我直接说结论和理由避免大家再走弯路。工作流引擎我们没有自己造轮子。在对比了市面上主流的编排框架之后最终选择了基于有向无环图的执行方案而不是传统的基于状态机的方案。原因是DAG的表达能力强得多并行节点、条件分支、聚合节点都能自然表达而且天然适合可视化展示。但这并不影响我们在Workflow内部支持循环子图可以在一个节点内部做小范围的迭代。模型网关层用的是统一适配器模式。所有模型供应商无论开源还是闭源、自部署还是云上都通过一套统一的接口接入。接口设计需要注意几点请求参数兼容主流格式里的关键字段、响应结果统一包装成标准结构、错误码体系统一比如把限流、超时、上下文超长分别映射成不同错误码。这样上层业务代码不会因为换了模型而大改。存储层我们分了三种用途元数据用关系型数据库存保证事务一致性运行日志和时间序列指标用列式存储和时序库Prompt和知识库的向量索引单独用向量数据库。不少团队犯过一个错误就是让一种数据库扛所有活儿最后不仅查询慢数据模型还越搞越乱。2.3 为什么开发者和业务方都需要“可视化”我见过一些纯代码方案的Agent框架确实灵活但企业场景里它有一个致命问题业务方看不懂。数据部门想改一个分析步骤、运营部门想调整一个客服流程如果都必须找开发改代码这个平台就很难规模化推广。所以在LEC-LLMOps平台里工作流提供了一个可视化的编排视图支持两种编辑模式一种是拖拽画布适合业务人员和初级开发者快速搭框架一种是YAML/JSON编辑适合专业开发者写复杂逻辑、做精细控制。两种模式底层共享同一套工作流定义Schema画布上改的东西对应到配置里的具体字段双端实时同步。这么做还有个隐藏好处——评审和审计变得直观。企业在生产环境发布一个AI应用不能像个人项目那样拍脑袋就上需要测试、评审、审批。可视化的工作流定义让评审人一眼就能看出这个Agent会调用哪些工具、在什么条件下会触发哪些动作、有没有敏感数据的流向。这比让人读几百行代码靠谱多了。3. 智能体工作流引擎的核心实现细节架构说得再好落到代码和运行机制上才是真章。这章我重点展开工作流引擎的实现细节因为它是平台差异化的核心。3.1 工作流定义Schema如何描述一个Agent任务工作流定义是整个平台的“宪法”。我贴一个简化版的工作流定义示例供参考workflow: id: sales-analysis-agent name: 销售数据分析智能体 version: 1.4.2 description: 查询销售数据并生成分析报告 input_schema: - name: period type: string required: true description: 查询的时间范围如2025-Q1 nodes: - id: query_sales_data type: tool tool: internal_sales_api params: period: ${input.period} - id: classify_regions type: agent model: reasoning_model prompt_template: regions_classify input: ${query_sales_data.output} - id: generate_report type: llm model: writing_model prompt_template: report_generation input: ${classify_regions.output} output_schema: report_md: string summary: string require_human_approval: true edges: - source: start target: query_sales_data - source: query_sales_data target: classify_regions - source: classify_regions target: generate_report condition: ${classify_regions.status} success timeout: 120s error_policy: retry: 3 on_failure: notify_admin这个Schema里有几个设计点是值得推敲的。第一节点类型分三类tool节点代表调用外部工具agent节点代表需要模型进行推理决策的子流程llm节点代表纯粹的一次模型生成。分类的意义在于平台可以在不同节点上施加不同的策略——tool节点重点管超时和重试agent节点管上下文窗口和推理深度llm节点管输出校验。第二输入输出统一通过变量引用传递。上面示例里${query_sales_data.output}表示把前一个节点的输出作为后一个节点的输入。这样每个节点天然是幂等的、可测试的调试时可以单独运行某个节点并传入mock数据。第三条件分支显式声明在edges里。这比在节点内部用代码写条件更清晰可视化时也能直观看出来哪条路径是主流程、哪条是异常分支。3.2 运行时的状态管理与上下文传递工作流的一次执行会产生一个Run实例Run实例里维护一个State对象。我用的是一个可持久化的状态容器每次节点执行完就把状态更新落到存储里。这么做有两个好处一是崩溃恢复变得简单节点执行到一半进程挂了重启后可以接着未完成的节点继续跑二是支持人工介入审批人看到某个节点输出后决定是否放行本质上就是在修改状态机。上下文传递还有一个细节很多初学者会忽略——模型的上下文窗口不是越大越好。工作流里多个节点可能产生大量中间数据如果一股脑全塞给下一步的模型不仅浪费Token还可能把关键信息淹没在噪声里。我们平台在处理上下文时做了一个“上下文压缩层”每个节点在向后续节点传递数据时可以选择原样传递、抽取摘要、只传结构化关键字段。这个能力在长流程的Agent任务里极其重要。3.3 Agent的规划-执行-反思循环怎么落到工作流里现在市面上流行的Agent范式是ReAct推理行动或者Plan-and-Execute规划执行。平台的做法是把这两个范式都抽象成工作流模板供使用者按需选择。以Plan-and-Execute为例一个工作流节点内部可以内嵌一个子循环规划器模型→ 生成任务清单 → 执行器工具/模型→ 执行结果反馈 → 反思器模型→ 调整任务清单 → 循环子循环的执行次数、终止条件、最大步数都需要在节点定义里显式声明。我强烈建议给所有Agent子循环都设置最大步数上限因为LLM在自由探索场景下非常容易陷入“自我循环”——模型反复修正计划但迟迟不收敛。企业场景里宁可让任务失败返回一个明确的错误也不能让它在后台空转烧Token还不出结果。这里有一个实操经验在Agent的反思环节加入“终止候选”机制会有效很多。反思器每次循环都输出一组候选的“最终答案”如果连续两轮候选答案之间的差异低于阈值就直接判定收敛结束循环。这比死等模型主动说“我完成了”要可靠得多。3.4 模型网关与工具调用的可靠性设计模型和工具是智能体的两条腿任何一条出问题任务都会歇菜。平台在可靠性上做了几件事。模型调用侧我们在网关层实现了多模型路由和自动降级。每个工作流的llm节点和agent节点可以配置一组候选模型比如优先使用便宜快速的模型A当A的响应质量不达标或服务异常时自动路由到质量更高的模型B。路由策略支持按模型供应商的实时健康状态、历史成功率、当前延迟动态决策。实测下来这种设计让整体任务的可用性从95%左右提升到了99%以上。工具调用侧我们遵循一个原则——让工具描述足够精确然后信任工具的结构化输出。工具注册时需要有完整的OpenAPI描述包括入参校验规则、错误码定义、成功响应示例。工作流引擎在调用工具之前会先做参数模式校验调用之后会对返回结果做结构校验。这能拦截掉大部分因参数格式不对导致的问题。3.5 一个完整的执行追踪示例平台里每个Run都可以生成一份可读的执行轨迹。以销售分析任务为例一次执行的追踪大概长这样步骤节点模型/工具耗时Token消耗状态1查询销售数据internal_sales_api850ms0成功2区域分类reasoning_model3.2s1850成功3报告生成writing_model5.8s3240待审批4人工审批-12min0已通过5结果回传-60ms0完成这个追踪视图的价值在于你一眼就能看出整个任务的时间花在哪、钱烧在哪、哪一步是人卡着没放行。生产环境出了问题排查的第一步永远是这个轨迹图。4. 企业级能力建设安全、权限、成本与可观测标题里的“企业级”三个字不是白加的。个人开发者的Agent项目可以只关注功能是否跑通但企业平台必须回答这些问题数据安全怎么保证谁能看什么、改什么每个应用花了多少钱出了问题怎么回溯4.1 安全体系大模型场景下的新老问题叠加传统安全关注的是越权和注入攻击LLM应用还需要额外面对Prompt注入、敏感信息泄漏、模型幻觉引发的内容合规风险。平台在安全侧做了三道防线。第一道是输入过滤与脱敏。所有进入工作流的用户输入先经过敏感信息识别识别出手机号、身份证号、内部工号等字段后自动脱敏。这个环节放在网关层确保所有应用统一生效不依赖每个开发者自己写过滤逻辑。第二道是Prompt安全审查。对于平台内维护的所有Prompt模板系统会定期用专门的评测集做攻击测试模拟各种恶意注入看模型会不会被诱导输出系统指令或越权行为。这个能力在知识库问答场景尤其重要——用户的提问内容可能本身就包含恶意指令Agent不该无脑执行。第三道是行为审计留痕。每次Agent执行过程中的工具调用、数据读取、外部请求都会被记录审计日志且日志不可篡改写进独立的审计存储。企业内部合规检查时这就是最直接的证据链。4.2 权限模型从“谁能用”到“谁能编排”平台里我把权限分成了四个层级。平台管理员管理用户、配额、全局模型配置。工作流开发者创建/编辑/发布自己的工作流。应用操作者只允许调用已发布的API看不到工作流内部逻辑。数据审计员只读权限负责查看日志和评估报告。这种层级划分的核心是为了隔离职责。开发者可以改Prompt和流程但不能查看生产环境的敏感调用数据操作者天天调用应用但不能修改底层逻辑。最终效果就是业务放心的用技术放心的改审计放心的查。还有一个细节容易被忽略——模型输出的内容也需要按权限过滤。比如一个工作流内部调用了外部数据分析服务生成了一份含敏感数据的报告这份报告在传给用户之前平台要根据接收者的组织权限做一次过滤。如果接收者是普通员工报告里涉及高层审批意见的字段就得隐藏。4.3 成本治理让每一分Token都算得清账大模型应用的成本是实时发生的和传统IT基础设施不同你没办法“买断”一个模型长期用。所以平台必须提供精细的成本计量能力。我们实现了一套多维度的Token计量与分配机制。每个工作流、每个应用、每个部门都带有成本归属标签每次模型调用的费用自动计入对应的成本中心。月末的账单是自动生成的精确到“某个部门某个应用在某个时间段的模型消耗明细”。实践证明成本治理最有效的杠杆不是事后记账而是事前的预算控制。平台支持给每个应用设置单次调用的Token上限、每月的总消耗预算、单日调用频次上限。一旦超过阈值系统自动降级——优先路由到更廉价的模型、拒绝非关键请求、通知管理员。我见过很多团队做大模型应用时完全不设上限月底收到账单才发现钱已经烧出去一大截。预算控制这个功能往小了说是省钱往大了说是让业务方养成精打细算的习惯。4.4 可观测性从三张仪表盘说起大模型应用的可观测性和传统后端有一个显著区别除了“系统运行健康度”之外你还需要关注“生成内容质量”。平台提供了三张仪表盘。第一张是基础设施监控模型服务的响应时间、错误率、限流次数、网关吞吐。这张盘主要给运维看只管系统稳不稳。第二张是业务指标监控每个工作流的调用量、成功率、平均完成耗时、人工介入率。这张盘给业务和开发看只管应用效果好不好。第三张是质量评估面板自动化的LLM评测结果、幻觉率、拒答率、用户反馈打分。这张盘是最有LLMOps特色的。模型生成结果的质量不能只靠人去抽检平台内置了LLM-as-a-Judge的评估能力用专门的评估模型对待测输出做打分覆盖正确性、完整性、有害性等维度。三张盘配合看到的才是完整图景。举个例子某天客服Agent的响应成功率下降了你去看基础设施盘发现模型服务没问题再看业务盘发现不是调用失败而是很多请求被安全过滤了最后定位到是安全策略里一个新加的敏感词规则误伤了大量正常提问。这种排查路径没有分层可观测能力是走不通的。5. 实操过程与踩坑记录从搭建到上线的完整路径前面讲的是设计理念和核心机制这部分我把平台从零搭建到生产可用的关键步骤梳理一遍附上我实际遇到的高频坑。每一条都是真金白银换来的教训。5.1 第一步先搭一个最小的模型网关闭环不管你的平台最终做得多大第一件事永远是让模型能够被统一、稳定地调用。我在MVP阶段只做了三件事封装统一的模型调用接口、接上两个不同供应商的模型、写一个简单的Failover逻辑主模型超时自动切换备用模型。这一步最容易犯的错是过度设计。有团队一开始就想把几十个供应商全部接入结果光是维护适配层的测试工作就拖了两周核心闭环反而没跑起来。我的建议很简单先用两个模型把链路走通后面再加。这里有个配置细节值得记一下。模型调用的超时时间不要统一写死不同模型和不同任务的延迟差异很大。我把超时设计成可配置的三档推理型任务30秒、生成型任务60秒、长文档任务120秒。网关层根据工作流节点声明的任务类型自动选择对应的超时和重试策略。5.2 第二步把工作流引擎的骨架立起来模型网关通了之后开始做最核心的工作流引擎。我推荐的启动顺序是先实现“串行节点执行”再实现“条件分支”最后实现“并行节点和子循环”。千万不要一开始就想着支持全特性因为每多一个特性状态管理的复杂度就上一个台阶。串行节点和条件分支的实现思路我在前面已经讲了。并行节点有一个必须处理的问题就是分支汇聚时的数据合并。几个并行节点各自产出了结果汇聚节点需要根据定义好的合并策略取第一个成功的结果、合并所有结果、按优先级取结果来决定最终传给下一步的数据。这个策略一定要在Schema里显式声明否则运行时会出现不可预期的行为。踩坑记录一曾经有一个并行分析的工作流三个分支分别分析销售、库存、客户数据汇聚节点直接用了“取第一个成功”的策略导致偶尔把库存分支的数据丢掉。排查了半天最后发现是分支执行速度不同导致“第一个成功”的结果并不总是销售数据。修复方案很简单——汇聚策略改成“按声明顺序取指定分支的结果”。5.3 第三步建立Prompt的全生命周期管理Prompt管理平台里我把它设计为一个独立的子模块。每条Prompt都有自己的一份档案创建人、创建时间、版本历史、适用场景、历史评估分数、关联的工作流。发布一份新的Prompt版本绝不能直接覆盖线上版本必须经过评估流程。评估流程是一个半自动的机制先跑一组固定的评测集看新版本比旧版本是进步还是退步。评测集里的用例来自真实生产流量每天自动挑选有代表性的样本加入。我踩过的坑是评测集过于陈旧导致Prompt优化产生“过拟合”。曾经有一条Prompt为了在某几个固定评测用例上得分更高而修改结果上线后发现真实场景的泛化能力反而下降了。从此之后评测集每周都会用在线采样的方式进行更新并且新旧版本Prompt会同时在线跑灰度对比。5.4 第四步接工具、接知识库、接企业系统工作流引擎能跑通模型之后就要开始接真实的企业系统了。这一步的工作量往往被低估。一个内部系统看起来API文档写得很全实际用起来各种返回格式不标准、字段缺失、鉴权方式老旧适配成本比想象中高得多。我们的做法是给企业系统的接入建了一层“工具适配器”标准。每个工具接入需要提供标准化的OpenAPI描述、一套mock响应数据和对应的测试用例、超时和错误处理策略。工具接入完成后必须通过自动化测试才能注册到工具库中被工作流使用。这里建议给工具调用加一个“熔断”机制。当某个工具连续失败达到阈值比如5次工作流引擎暂时跳过该工具并把失败信息通知管理员。否则在高峰期一个下游系统抖动会导致所有工作流排队等待超时整个平台跟着遭殃。5.5 第五步灰度发布与全链路压测企业平台的发布不能一刀切。LEC-LLMOps平台里的工作流发布默认走“金丝雀发布”流程新版本先切5%的生产流量跑一段时间看质量指标成功率、耗时、Token成本、用户反馈达标后再逐步放大比例直到100%。灰度发布特别适合Prompt和工作流这类“改了不知道效果会怎样”的变更。我见过不止一次一个看似无关紧要的Prompt措辞修改上线后让回答风格整体跑偏。灰度机制就能及时发现这类问题不至于把所有用户都带沟里去。压测方面全链路压测的重点不在并发量而在于降级链路是否真的有效。你要测试的是主模型挂了备用模型能否无缝接管、工具熔断后流程能否优雅降级、缓存服务挂掉后系统能否继续跑。这些降级场景平时不显山露水关键时刻就是生死线。5.6 常见问题排查速查表最后把我在平台运维过程中遇到的典型问题和排查思路整理成一张表方便你遇到同类问题时快速定位。问题现象可能原因排查顺序与建议Agent任务长时间不结束子循环没有最大步数限制、模型反复修改计划先查执行轨迹里循环次数加上步数上限和终止候选机制Token消耗突然飙升Prompt没做上下文压缩、Retry次数过多、长上下文重复传入看单节点Token统计开启上下文压缩降低重试上限工具调用频繁报错入参格式不匹配、工具描述过时、下游服务异常先看工具测试报告再查熔断状态最后看下游服务健康度线上回答质量忽高忽低模型切换、Prompt灰度流量分配、上下文被污染先查当前节点实际用的模型版本和Prompt版本再跑一轮评测集某部门成本失控没有预算阈值、成本归属标签缺失开启预算告警检查工作流配置里的成本标签用户反馈被误杀安全过滤规则过严查安全日志看是哪些规则拦截调整敏感词匹配策略工作流偶发不可用某个下游工具超时拖累整体设置工具并发超时时间启用熔断开启异步降级这张表对应的每一个问题我都实际处理过。值得单独拿出来提醒的是“Token消耗突然飙升”这个问题它太隐蔽了。有一次线上业务只是改了Prompt模板没改模型结果发现单次调用的Token量涨了40%原因是在新Prompt模板里系统把几条辅助指令拼接进了主Prompt的每一轮对话导致消息历史被越养越长。排查这类问题token维度的统计报表是唯一靠谱的工具建议大家把token统计作为平台的默认能力而不是需要的时候再加。6. 平台化之后的一些心得与扩展方向平台从第一个版本上线到现在经历了从“开发自用工具”到“全公司AI应用底座”的转变有几个体会值得记录下来。第一平台的价值要拿业务结果说话。最开始向各业务线推广时最有效的不是讲平台技术多先进而是让一个业务团队用一个具体场景比如客服摘要、数据分析报告跑通一条工作流用数字对比改造前后的效率差。但凡有过一个典型的成功案例后面推广就容易多了。第二开发者体验决定平台的天花板。企业内部的平台本质上是个产品开发者用得爽才会持续用。我们后来投入了大量精力在文档、模板库、样例工作流和调试工具上。一个即开即用的“工作流模板市场”比几百页的接口文档有用一百倍。业务团队复制一个模板改改参数就能出活儿这才是平台能规模化的关键。第三平台的下一步方向我的判断是两个。一个是让工作流具备更强的自适应能力——不光是人配置好流程让机器执行而是让模型根据任务描述动态生成工作流建议人来确认后执行。另一个是跨工作流的经验沉淀——把历史上跑得好、效果佳的工作流片段沉淀为可复用的能力单元让后来的开发者站在前人的肩膀上做东西而不是每次都从第一行Prompt开始写。关于LEC-LLMOps这个平台本身我想说的是做企业内部AI平台心态上要做好“持久战”的准备。它不是一个一次性的交付项目而是一个需要持续运营、持续投入的基础设施。你今天搭好的工作流编排机制明天可能就要支持新的工具类型今天够用的评测集下个月业务变了就得扩充。但只要地基打得稳每一次扩展都是在给平台增值而不是推倒重来。最后分享一个落地小建议如果你正在规划类似的平台别想着第一版就要把所有企业级特性做齐。先把“模型网关工作流引擎基础可观测权限隔离”这四件套跑通让一两个真实业务用起来后面再慢慢补充评测、成本治理、灰度发布这些增强能力。平台是长在业务上的没有真实业务在平台上持续跑再完善的能力都是空中楼阁。
阅读完成 · 觉得有帮助？
