施耐德电气，全球能源技术领域的领导者，通过电气化、自动化和数字化，推动着从工业到家庭的可持续发展。这家拥有16万员工、年营收约400亿欧元的巨头，其AI布局相当有野心：一个由350名专家组成的内部AI Hub，已经部署了60多个Agent，用于优化能源消耗、延长资产寿命，并加速开发者的效率。
在关键基础设施中大规模部署AI
施耐德的AI项目涉及面很广，主要分为三类：
- 将智能直接嵌入产品——比如房间控制器中的热学习功能，直接降低能耗。
- 用AI预测需求和产量，让客户能将用电时间转移到更便宜、更环保的时段。
- 部署Agentic Copilot，减少运营摩擦——无论是管理更复杂的电网、提升客户成功率，还是查询碳排放软件系统。
这些Agent被嵌入到各个目标中，运行在有着严格数据驻留要求和网络安全控制的关键基础设施之上。施耐德需要一个通用的Agent平台，既能让团队快速构建，又能牢牢掌控数据、部署和质量。
"准确性、答案质量、安全护栏——这些都是非常现实的挑战。当你大规模部署解决方案时，你需要像LangSmith这样的工具。所有与可信度以及理解背后发生了什么相关的东西，对我们来说都极其宝贵。"
– Philippe Rambach, 施耐德电气首席人工智能官 (CAIO)
施耐德的AI平台团队隶属于AI Hub，负责提供共享基础设施，让各个AI团队能够在其庞大的技术版图（多云环境，从云端到边缘，各种AI类型）上可靠交付。
这篇客座博客分享的是，他们如何围绕LangSmith和更广泛的LangChain生态系统，构建LLMOps能力。具体来说，他们实现了：
- 部署并持续优化一个服务14万员工、覆盖100多个国家的AI助手的准确性和质量。
- 共同构建一个LLMOps成熟度框架，用于部署客户成功经理（CSM）Copilot。
- 利用LangSmith Deployment的任务队列模型，加速报价工作流。
作者：
Yoann Bersihand, AI平台副总裁
Nicolas Gauthier, Agentic AI工程产品负责人
Amaury Gelin, Agentic AI工程AI工程师
挑战：从传统MLOps到LLM系统的转型
要想在规模化运营中充满信心，一个专门的LLMOps学科必不可少。没有它，团队就像在黑暗中摸索。传统的MLOps方法并不能直接套用到基于LLM的系统中，否则会面临：
- 除了原始应用日志，几乎无法调试Agent行为。
- 对提示词或模型的更改缺乏精确的度量手段。
- 难以验证生成式AI和Agentic系统的生产就绪程度。
架构设计：三大支柱
施耐德AI平台的LLMOps能力建立在三个支柱上，这三个支柱恰好对应了Agent产品的生命周期：1）可观测性，2）评估，以及3）部署。
1. 可观测性：自托管LangSmith，每个产品一个工作区
可观测性的目标是“我们能看清正在发生什么”。
施耐德在AWS EKS上以自托管方式部署LangSmith，并将其集成到企业安全边界内。这种方法确保了严格的数据隐私，并符合公司关于第三方数据外发的内部政策。
在可观测性方面，关键的设计决策是工作区实例化模型：每个AI产品一个工作区，覆盖所有环境（开发、质量保证、预发布、生产）。另一种选择——每个环境一个工作区——会打破希望建立的闭环：将生产环境的追踪数据回馈到开发数据集中，用于离线评估。
通过将开发和部署放在同一个工作区，领域专家可以注释生产环境的追踪数据，并直接推送到数据集。然后，这些例子可以针对新版本的Agent进行重放，以验证改进效果。
实际上，这意味着数据集、注释和实验与它们来源的生产追踪数据紧密相连——更容易从真实使用中学习，并持续改进系统性能。
生产案例：“One Jo”
内部AI助手One Jo服务于施耐德电气的16万名员工，部署在107个国家。每一次对话都会通过LangSmith进行追踪，同时严格遵循数据隐私标准。生产环境的追踪数据被系统地重复利用，为团队提供回归数据集，使他们能够根据真实世界的使用情况来验证每一次模型或提示词的迭代。这些追踪数据还能实时洞察性能漂移，使团队能够及时发现并应对随时间推移的性能变化。
图1 - 生产案例：“One Jo”注释队列
2. 评估：离线、在线及成熟度框架
如果说可观测性让我们“看清了”，那么评估则让我们“决定是否发布”。施耐德在这方面投入很大，主要围绕三个方向。
首先，一个离线评估翻跟斗。 施耐德在Azure和AWS上发布了Agentic RAG的GitHub模板，并附带一个基于LangSmith SDK构建的轻量级评估CLI。
目标很明确：标准化所有AI团队运行实验的方式——统一的数据集规范、统一的评估器接口（基于openevals模式）。
结果：新团队能够快速从初始设置进阶到一套有意义的离线评估套件。
其次，一个LLMOps成熟度框架。 面对超过60个AI产品，推广追踪和评估的使用是一项艰巨的工作。施耐德将内部LLMOps成熟度模型标准化，用以追踪关键能力：这个产品是否被检测？它是否有离线评估套件？生产环境中是否有在线评估器在运行？用户反馈是否在回流并被重复利用？
通过这套框架，施耐德建立了基于LangSmith API的自动化报告系统。一个预定的GitHub工作流会生成一张所有AI产品在LangSmith能力方面的总览图，提供对采用进度和成果的持续可见性。
LLMOps成熟度水平被整合进AI产品生命周期，并作为关卡评审的一部分，用来推动用例从探索 → 孵化 → 工业化 → 运维的流程。
第三，领域专家的参与。 即使有了合适的工具，评估中最困难的部分仍然是让领域知识参与进来。施耐德将内部领域专家的角色映射到LangSmith的一个自定义角色上，该角色可以访问注释队列和数据集，但不会暴露开发者级别的功能面。目前，大约20%的AI产品至少有一个活跃的、有领域专家参与的注释队列。这样，领域专家可以直接审查和注释真实案例，为评估做出贡献，而无需具备工程技能。
LLMOps的闭环：
图2 简易LLMOps闭环
生产案例：客户成功管理（CSM）Copilot
施耐德电气的服务业务部门通过AI驱动的基于状态的维护、全天候远程监控和专家支持，为数据中心和建筑提供主动的资产性能管理。
CSM Copilot是支持基于状态维护的多个Agentic AI解决方案之一。它赋能250多名客户成功经理，为任何账户或合同更快地生成洞察。
从第一天起，CSM Copilot就让领域专家利用LangSmith参与设计。这使得领域专家能够直接影响共同构建产品的质量——从持续审查输出、提供注释，到在开发过程中塑造系统行为。结果，产品在首次部署时就达到了高质量水平，并获得了客户成功经理的广泛采用。
图3 - 生产案例：客户成功经理聊天机器人
3. 部署：LangSmith Deployment，每个产品一个运行时
对于需要流式传输、长期记忆、人工介入或后台处理的Agent，施耐德统一采用了LangSmith Deployment的参考架构：包含Postgres和Redis的Agent Server，部署在AWS和Azure的着陆区。
从一开始，施耐德就决定不运行集中的Agent运行时。相反，每个AI产品都运行在自己专用的栈上。
这个决策基于两个关键原则：
- “谁构建，谁运维。” AI平台的理念是为AI团队提供扎实的基础和铺设好的路径，而不是交钥匙的运行时。通过拥有自己的运行时，AI团队能完全控制延迟、成本和事件响应。
- 没有单点故障。 集中的Agent运行时将引入系统性风险。一个有问题的部署或资源问题可能会立即影响所有Agent。而使用每个产品独立运行时，任何问题都会被隔离到单个用例，保持整个平台的弹性。
当然，这种方法也有代价——需要管理更多的基础设施，协调更多的升级——而这正是施耐德下一步投资的方向（见下文“下一步是什么”）。
图4 - LangSmith Agent Server基础设施（每个用例，自托管）
每个产品都从同一个langgraph.json模板开始，该模板的设计是跨AWS和Azure的云无关的。下面的版本包含了一个大型企业环境的典型需求：一个被列入白名单的基础镜像、与企业CA捆绑包的集成，以及一个在Agent图之外暴露的自定义反馈HTTP路由。
图5 – 默认的LangSmith Agent配置
生产案例：数字能源 - 规格文档智能
在数字能源部门，施耐德正在推动商业、工业和公共基础设施中建筑运营的变革。作为这项工作的一部分，他们开发了一个文档处理Agent，能够分析客户的报价请求（包括规格书、建筑图纸和其他PDF文档），并自动添加上下文注释。报价工作流现在只需几分钟，而以前则需要几小时甚至几天。
这个Agent的平均完成时间略高于15分钟。这种长时间运行的后台处理任务，正是LangSmith Deployment的任务队列模型所擅长处理的，它能在不影响实时系统性能的情况下，确保可靠执行。
成果
通过与LangChain的合作，施耐德在能源技术领域持续取得进展：
- 超过60个AI产品正处于积极开发或生产中，全部基于LangChain生态系统构建。
- 大约200名活跃的LangSmith用户，包括工程人员和领域专家，将施耐德在能源管理和工业自动化领域深厚的领域知识，置于AI产品的核心。
大规模构建LLMOps的经验教训
最初在LLMOps上的投入得到了回报。 如果没有追踪级别的可观测性和真正的离线评估体系，施耐德所有的Agent产品都不可能达到生产就绪状态。那些早期抵制进行功能检测的团队，后来正是被非确定性回归问题卡住、只能靠自己苦苦调试的那些人。
在构建自定义功能之前，先充分利用开箱即用的特性。 构建复杂的内部框架（尤其是在评估方面）确实很有诱惑力。事后看来，一个关键的教训是，最好先依赖开箱即用的特性，再考虑构建自定义功能：一个基于LangSmith SDK的薄CLI层、一个映射到现有权限模型的自定义角色、基于公共API生成的定期报告。
自托管效果不错，但可能会让你付出代价。 LangSmith在自托管模式下表现出了非凡的稳定性。但代价是基础设施和运维工作，比如Helm chart升级、EKS生命周期管理、版本锁定，以及偶尔出现的“这在SaaS文档里能行，但我们的网络策略不允许”的调试会议。如果你的环境允许使用SaaS，那就用它。
采用率取决于你的组织，而不是技术。 虽然技术可以快速集成，但真正的差异化在于，在快速变化的AI格局中，能否让多个团队在共享的实践、标准和工作流程上保持一致。
LangChain生态系统在集成性和灵活性之间取得了很好的平衡。 其产品组合内部一致性很高（开源的库、用于可观测性和评估的LangSmith、LangSmith Deployment及LangSmith Studio），但开源库可以独立使用，LangSmith也能与第三方框架良好集成。这给了施耐德混合搭配的空间，不会把自己逼到角落。
施耐德电气与LangChain：下一步是什么？
将AI原生工程应用于平台本身
施耐德正在试点Agent Skills和编码Agent，以简化LangSmith上的LLMOps采用过程。同时，考虑到“每个产品一个运行时”的策略，他们正在投资Agent Skills，以便更轻松地维护基于LangSmith Deployment运行时上的Agent产品。
边缘AI与混合Agent系统
越来越多施耐德的AI产品运行在边缘——比如在工业环境中的硬件设备或网关上。目前，LangSmith支持这些系统的云端生命周期，包括离线评估和数据集管理，而运行时执行和在线评估则由于连接限制，在LangSmith之外本地处理。施耐德正在与LangChain团队合作，积极扩展生态系统以支持边缘AI和物理AI场景。这是下一片前沿阵地。
"用现有技术，我们已经可以节省20%到25%的能源。但我们想为客户带来与能源系统交互的新方式。真正帮助他们更好地理解、更好地互动、模拟不同场景，并根据这些智能采取行动，希望在星球层面为能源消耗和碳排放带来积极的改变。”
– Philippe Rambach, 施耐德电气首席人工智能官 (CAIO)