从 OpenCSG 白皮书看，MLOps 之后为什么开始讨论 AgenticOps

当 AI 开始调用工具、执行流程、影响业务，只管好模型已经不够了

近日，OpenCSG 发布了2026年度白皮书：《AgenticOps：从企业智能到 OPC 新生产力》。这份白皮书讨论了一个很现实的问题：当 Agent 真正进入企业生产，原有的模型管理方式还够不够用？

过去几年，MLOps 帮助企业把机器学习从实验室带进生产环境。模型可以被登记、测试、发布和监控，训练数据与代码也有了更清楚的版本记录。

但我们在企业项目中越来越频繁地遇到另一类问题：模型本身没有变化，Agent 的表现却变了。原因可能是一段 Prompt 被修改，也可能是知识库更新、工具接口升级，或者某项权限没有及时回收。

当 Agent 能够查询数据库、调用代码环境、修改工单，甚至触发业务流程时，问题就不再停留在“回答得准不准”。

《AgenticOps：从企业智能到 OPC 新生产力》白皮书将这种变化概括为：企业需要“从模型生命周期管理走向智能体运行体系“。白皮书认为，仅仅管理模型，已经无法覆盖一个 Agent 进入真实业务后的完整过程。企业还需要进一步管理 Prompt、知识库、工具权限、任务流程、智能体版本、运行轨迹和业务反馈，并协调多个模型与智能体共同完成复杂任务。

Agent 的生产状态不能只由模型是否在线来判断。知识是否新鲜、工具是否可用、权限是否合理、每次任务用了什么版本，同样需要被看见。

MLOps 没有过时，它仍然是底座

AgenticOps 不是为了取代 MLOps。一个 Agent 无论多聪明，底层仍然要调用模型。模型是否稳定、延迟是否可接受、使用了哪一版数据、资源成本有没有失控，这些问题仍然属于 MLOps 的核心范围。

如果企业连模型服务都没有稳定下来，直接建设大规模 Agent 系统，很容易出现“上层流程很热闹，底层能力不可靠”的情况。今天能运行，明天换一个模型版本就出现结果偏差；演示时很顺畅，进入真实并发后却频繁超时。

MLOps：管理模型训练、部署、监控、版本和成本

AgenticOps：进一步管理知识、Prompt、工具、权限、工作流和执行过程

MLOps 管理模型生命周期，AgenticOps 在它的基础上继续管理知识、Prompt、工具、工作流、Agent 版本和业务反馈。原有的模型训练、注册、部署与监控能力可以保留，不需要推倒重来。

真正增加的，是模型之外的那一长串依赖。

Agent 进入生产后，管理对象突然变多了

一个能够执行任务的 Agent，通常不只包含模型。它需要知识来理解业务，需要 Prompt 确定角色和边界，需要工具连接搜索、数据库与企业 API，还要通过工作流安排步骤、处理异常。多 Agent 协作时，又会增加角色分工、消息传递、任务依赖和结果冲突。

这些对象都在变化。知识有有效期，Prompt 会被业务人员调整，接口可能升级，员工岗位变化后权限也要更新。即使模型版本完全不变，任何一个环节发生变化，Agent 的行为都可能不同。

关键判断

Agent 最大的变化在于，它不再只是回答问题，而是开始真正执行操作。

传统的软件故障通常可以追到代码版本。Agent 的一次错误则可能来自模型、知识、Prompt、工具返回或上下文。企业如果只保存最终答案，很难在几天之后还原它当时为什么做出那个判断。

还有一个更实际的区别：Agent 会行动。生成一段内容和删除一条数据，风险完全不同。只读查询、修改业务记录、对外发送信息，也不应该使用同一套授权规则。企业需要根据任务风险决定哪些步骤可以自动执行，哪些结果要抽查，哪些操作必须由人确认。

这也是 AgenticOps 比单纯模型管理更接近业务现场的地方。它管理的不只是技术组件，还包括行动边界和人的责任。

白皮书怎样理解 AgenticOps 的完整生命周期

《AgenticOps：从企业智能到 OPC 新生产力》白皮书从企业实际运行出发，关注一个智能体从需求提出到长期运营所经历的完整过程：明确业务目标，准备数据和知识，选择模型，连接工具，设计任务流程，验证实际效果，部署到合适的环境，并根据业务反馈持续优化。

这些工作并不是彼此割裂的步骤。模型、知识、Prompt、工具或流程中的任何一项发生变化，都可能改变 Agent 的最终行为。企业因此需要把分散在不同系统中的资产、权限、记录和评价连接起来，才能知道一个结果由哪个版本产生、调用过哪些工具、经过谁的批准，以及出现问题后应该调整哪一部分。

• 核心框架

白皮书进一步把安全治理嵌入资产、开发、运行和反馈四个相互连接的环节。

举个常见的例子。一家公司准备上线内部知识助手，让它回答制度问题，并根据员工需求创建工单。演示阶段的效果很好，回答准确，工单也能正常提交。可一旦进入正式环境，很多此前看不到的问题就会冒出来。

首先要处理的是资源。这个助手用了哪一个模型，知识库更新到了什么时间，Prompt 由谁维护，工单工具又对应哪个接口版本，这些信息都要留档。模型和数据还涉及来源与许可证。如果这些内容散落在代码、文档和个人聊天记录里，几个月后再排查问题，很可能连当时使用的版本都找不到。

接下来是权限。知识助手为了创建工单，需要获得系统写入权限。权限开到什么范围，要不要经过审批，出现异常时由谁接手，最好在开发阶段就定下来。尤其是修改数据、删除内容和发送外部消息等操作，一旦执行错误，影响会直接落到业务系统里。人工确认应当放在风险较高的步骤上，而不是给所有任务统一增加审批。

高风险操作：写入数据、删除内容、付款或对外发送信息——人在回路应成为流程本身的一部分。

测试也要尽量接近真实使用。员工可能只说一句“帮我处理一下”，没有提供完整信息；知识库中可能缺少对应制度；工单接口偶尔也会超时。面对这些情况，Agent 应该追问、停止还是转给人工，需要在上线前反复验证。演示环境里一路顺畅，并不能说明它已经适合生产。

上线之后，团队要能从日志里还原任务经过。假如某一天 Agent 开始引用旧制度，排查人员应该看到它调用了哪个知识库版本，以及同步任务从什么时候开始异常。如果工单重复创建，也要顺着调用记录找到触发原因。只有模型服务的运行状态远远不够，真正影响业务的细节往往藏在任务过程里。

失败原因排查：

知识没有更新 → Prompt 表达含糊 → 工具接口变化 → 工作流设计不合理

如何把 AgenticOps 落到产品和任务里

AgenticOps 不能只停留在白皮书里。OpenCSG 用 CSGHub、AgenticHub、CSGLite 和 CSGClaw 承接不同环节，同时保持资产与运行之间的联系。

• CSGHub — AI 资产底座

模型、数据集、代码、Prompt、MCP、Skills、应用和 Agent 进入同一目录，保留来源、版本、权限与评价记录。

• AgenticHub — 组织级 Agent 复用

面向构建、发现和复用。一个部门验证有效的流程可以沉淀为模板，再根据另一部门的数据范围和审批规则重新配置。

• CSGLite — 轻量本地模型入口

在个人电脑、边缘设备或敏感环境本地完成模型查找、下载和推理，通过兼容接口接入现有应用。

• CSGClaw — 多角色任务执行

Manager 拆解目标并协调任务，专业 Worker 分别处理研究、开发、测试或文档工作。隔离环境、任务记录和人工确认。

四个产品解决的层级不同，但它们共同服务一件事：让模型、知识、工具和 Agent 成为可以持续管理的生产资产。

企业不以一个边界清楚、结果可以核验、失败能够回滚的任务开始，逐步搭建覆盖全公司的 AgenticOps 平台。例如，让一个内部知识 Agent 帮助员工查找制度文件。团队可以先写清用户、输入、知识范围、模型版本、可调用工具、成功标准和人工确认节点，再设定成本上限与退出条件。这些信息组成一张最小运行卡。

随后用固定样例做离线评价，在沙箱中检查权限和异常分支，再用小流量接触真实请求。每一次失败都要能够回答：是模型问题、知识问题，还是工具和流程问题。跑通一个闭环后，再把成熟资产放入 CSGHub，把 Agent 和工作流交给 AgenticHub 统一管理，并根据本地运行或多角色协作需要接入 CSGLite、CSGClaw。

权限也应随风险逐步开放。先从只读任务开始，再连接真实系统；确认日志、评价和回滚机制有效后，才考虑增加写入或自动执行能力。

这条路径看起来没有“一次建设完整平台”那么宏大，却更接近企业真实的采用过程。一个可复现的任务，比十个无法说明依赖关系的 Demo 更有价值。

为什么是现在

今天的企业已经可以方便地调用开源模型、商业 API 和本地模型。模型选择越来越多，真正消耗时间的工作开始转向选择、连接、治理和持续运营。同时，Agent 正在从内容生成进入研发、客服、运营和分析流程。它们读取企业知识，也可能调用真正的业务系统。随着数量增加，资产分散、重复接入、权限失控和责任模糊会一起出现。

OpenCSG发布《AgenticOps：从企业智能到 OPC 新生产力》白皮书，是因为这些问题已经不能靠项目成员在群里互相提醒来解决。企业需要一套可执行的方法，把需求、资产、连接、运行、评价、反馈与退出放到同一个生命周期中。

它仍然是一套持续发展的实践。我们不会把一个新名词包装成万能答案。最终要检验的，是 Agent 能否稳定完成任务，是否降低了重复建设和人工返工，出现异常时能不能停下来、查清楚、恢复运行。

每个进入生产的 Agent 都应该有明确负责人、可追溯依赖和可执行的停止条件。

这也是OpenCSG写这份白皮书的出发点。希望给企业的不是一张概念地图，而是一套能够从小任务开始、可以逐步补齐的工程方法。团队规模不同，已有系统也不同，但每个进入生产的 Agent 都应该有明确负责人、可追溯依赖和可执行的停止条件。

MLOps 解决了模型如何可靠进入生产。AgenticOps 继续向前一步，处理模型、知识、Prompt、工具和工作流共同参与任务之后出现的新问题。

对企业来说，下一步未必是马上建设一套庞大的新平台。先选一个真实任务，把它的版本、权限、评价、人工责任和退出条件写清楚，往往更有意义。OpenCSG 正在通过 CSGHub、AgenticHub、CSGLite 和 CSGClaw，把 AgenticOps 从方法论落实到开发与运行链路。如果你的团队已经开始建设 Agent，也欢迎从一个可验证的场景开始，与我们一起把这套闭环跑起来。

关于 OpenCSG

OpenCSG是全球领先的开源大模型社区平台，致力于打造开放、协同、可持续生态，AgenticOps是人工智能领域的一种 AI 原生方法论，由 OpenCSG（开放传神）提出。AgenticOps 是 Agentic AI 的最佳落地实践也是方法论。核心产品CSGHub提供模型、数据集、代码与 AI 应用的一站式托管、协作与共享服务，具备业界领先的模型资产管理能力，支持多角色协同和高效复用。