最近在思考一个问题，随着大模型的能力越强，为什么大家还是不放心让 AI Agent 到生产执行命令进行故障分析或者故障恢复。
企业的运维团队需要回答几个朴素的问题。
- 这次 Skill 执行用的是团队认可的工具，还是 Agent 临时写的脚本？
- 当前版本在真实环境里跑通过吗？
- 换一位同事提问，Agent 还会走同一套流程吗？
- 工具更新以后，已经在生产使用的流程会不会跟着变化？
这些问题决定了 AI 能否从产品演示走进生产环境。
我们给的答案是：确定、可控、复用。
模型继续变聪明固然重要，但进入企业生产环境还需要另一种确定性。组织需要知道 Agent 使用的是哪些正式能力，以及这些能力是否值得信任。
今天很多企业去做运维时，已经开始保存 Skill、工作流和 Tool 去做到 AI 提效，但“保存下来”距离“成为受治理的生产资产”还有一段距离。真正的缺口，是工具、版本、真实验证、环境权限和长期流程之间，还没有形成一套可以追溯的关系。
Ontox 插件中心解决的正是这一环——我们的 Skill 设计赋予了 AI 运维能力明确的资产身份，使其能够像软件一样进行版本化管理与发布。
Agent 已经能连接系统、保存 Skill，接下来要管住真实执行
AI 行业正在形成两项共识。
一项是连接器。MCP 让 Agent 用统一方式接入外部系统，云平台、数据库、代码仓库和企业应用都可以成为实时信息与动作来源。
另一项是技能。Anthropic 把 Skill 比作新员工的入职指南。OpenAI 对 Skill 与 MCP 的区分也很清楚，Skill 解释工作怎样完成，MCP 提供实时信息并控制动作。Coze 允许用户把一次性 Prompt 中的任务方法整理成可保存、复用和继续修改的 Skill。Dify 则把 Prompt、模型和工具调用编排成可测试、可交接的工作流。产品形态不同，它们都在把 AI 从一次对话带向可以重复使用的工作方法。
连接器和技能解决了两端。中间仍有一个运维生产特有的问题就是真实执行仍需要独立管理。
因为运维 Skill 中经常包含一些已经成熟的 Bash 或 Python 动作。如果这些动作跟着每份 Skill 保存，同一段实现会在多个流程中复制；如果每次都让 Agent 临时生成，长期使用又很难保证前后一致。访问目标所需的身份、凭证和权限，也不属于工作方法本身。
Ontox 因此将它们分成三类资产。Skill 保存判断和编排，Tool 保存可以独立维护与发布的确定性动作，Connector 负责环境访问和权限。三者可以互相引用，各自保留自己的生命周期。
像软件一样发布的可控运维动作
这里说的“像软件一样发布”并非给脚本加一个版本号。
【草稿隔离】 维护者需要先在草稿中创建或修改 Tool。草稿的隔离就可让编辑态的 Tool 不会进入 Agent 的正式检索，也不能被普通用户执行。维护者就可以继续调整脚本、Schema、解释器和运行策略，不影响组织正在使用的发布版本。
【真实调试】 发布以前，Tool 必须在真实远程目标上调试，因为 Mock 结果不能代替发布证据。而一次有效调试要有真实目标、成功退出、符合 Output Schema 的结果和明确解释器版本。
【版本溯源】 一次调试成功，证明的只是当时那一版工具。脚本、输入输出或运行方式发生变化后，原来的成功记录仍可追溯，却不能继续替新内容背书。Ontox 因此不允许直接覆盖已发布版本。维护者的修改会进入新草稿，重新完成调试后，再发布为新的不可变版本。这样，生产中的每一次引用都能对应到一份确定的内容和它自己的验证记录。
【版本锁定】 已经投入使用的 Skill，不会随着底层工具更新而悄悄改变。工具发布新版本后，原有 Skill 仍然使用此前跑通的版本。维护者只有看过变化并主动升级，新的版本才会进入这套流程。对于一线运维来说，昨天验证过的工作方法，今天不会在不知情的情况下换掉执行内容。
【执行前确认】 到了真实执行前，用户还会看到本次要访问的机器、使用的能力和关键参数。确认之后，系统就按这份内容执行，不再临时更换目标、参数或工具版本。用户批准的内容与最终执行的内容保持一致。
简单来说，一套已经验证并投入使用的工作方法，不会自己变样；每次执行，也不会超出用户当次确认的范围。
稳定可控的运维动作 = 找得到、敢执行、能复用
发布体系最终要回到用户工作。对一线运维来说，插件中心最直接的价值可以归为三件事。
找得到
企业的运维团队从来不缺自动化。Git 里有 Shell 和 Python，Jenkins、Rundeck、AWX 里有作业，监控平台有告警动作，云平台有云助手，堡垒机有命令模板，ITSM 还有几十条流程。每个平台都能列出自己管理的资产，没有哪个目录自己天然可理解用户眼前要完成的任务。
新员工遇到“新主机接入”时，首先要知道公司是否已经做有固化流程处理这件事。随后还要找入口、认脚本、确认适用系统、理解参数，再问哪个版本仍然有效。工具越多，选择成本越容易超过执行成本。
Ontox 的插件中心把事务的入口倒了过来。用户先说任务，Agent 再从组织可用资产中寻找 Tool，比较用途、版本、Schema 和 Connector 兼容性。当存在多个候选时，Agent 也会把差异交给用户，不会自行猜测。
简单的 hostname、uptime、df 事务可以直接走连接器，便捷高效。需要批量执行、结构化输出、版本和真实记录的成熟动作才进入 Tool 流程。所以插件中心没有把每条远程命令都包装成资产。
用户因此少找入口，也不需要每次开展工作前先问“公司有没有现成工具”，这使得企业已经投入建设的自动化，从此更容易进入日常工作。
敢执行
组织把 Tool 开放给成员，开放的是一项运维能力，并没有同时开放所有生产环境。Tool 告诉 Agent 可以执行什么动作，Connector 管理访问环境所需的身份、凭证和目标权限。成员能够发现同一个 Tool，实际可以选择的服务器仍取决于各自拥有的 Connector 权限。
Agent 找到合适的 Tool 后，也不会立即连接目标执行。对使用者来说，最后的决定仍然在自己手里。机器选错、范围过大或阈值不合适时，可以在执行前要求 Agent 调整。自然语言降低了操作门槛，却不会替用户决定生产环境里实际执行什么。
对负责人来说，这意味着 Tool 可以交给更多成员使用，同时仍受既有环境权限和执行确认约束。团队扩大了能力的使用范围，却没有随之扩大每个人的生产权限。
能复用
自动化流程能够重复执行，并不等于团队的方法已经可以复用。脚本可以采集系统信息、检查磁盘和获取运行状态，却不知道什么情况下应该执行这些检查，也不知道缺少一项证据时还能不能给出接入结论。这些判断往往仍要靠值班手册和资深工程师补充。
第一次完成新主机接入体检时，资深工程师可以和 Agent 一起确定检查范围、工具顺序、判断标准以及哪些情况需要停止。任务跑通以后，Agent 会把这套方法整理成 Skill 提案，由工程师检查并保存。整个过程不要求工程师另外学习一套配置语言，也不需要把对话重新抄进文档。
下一次再有主机接入，其他同事只需要在新会话里提出同样的业务任务。Agent 会找到这套 Skill，询问本次要检查的主机，并按照已经沉淀的方法组织检查。环境权限和执行确认仍按本次任务重新判断，但使用什么工具、按什么顺序检查、如何整理结果，不必再从头商量。
两台主机上的一次真实验证
我们用“新主机接入体检”这个场景一起看看 Ontox 如何稳定可控地执行运维动作，如何沉淀 Skill。
目标机器是两台 Ubuntu VM，可以通过同一个 SSH Connector 访问。用户通过对话发起需求，需要针对新机器采集系统基线、检查根文件系统并收集运行态证据，磁盘阈值设为 60%。
Agent 接收到任务后，先是找到三个契合当前场景的 Tool。系统基线使用 v1，磁盘检查使用 v1，VM 运行时证据使用 v3。Ontox 先展示候选工具、用途和参数，然后再生成覆盖两台目标的执行计划。
确认卡明确地列出三个 Tool 的版本、SSH Connector、两台目标、只读影响，以及 scope=/、threshold=60。用户确认以后，三个计划才进入执行阶段。
3 个工具在 2 台机器上的执行全部成功。
执行结束后，用户让 Agent 把流程整理成“新主机接入体检”Skill。提案保留场景的适用条件、工具执行的三步顺序、默认阈值、结果分类和安全约束等，远程实现仍然留在 Tool 中。
保存后的 Skill 明确使用系统基线 v1、磁盘检查 v1 和 VM 运行时证据 v3，与本次跑通时使用的三个版本一致。
我们随后打开一个新会话，再次提出新主机接入体检需求。Agent 找到了刚刚保存的 Skill，并沿用其中的检查步骤，重新询问本次目标和阈值后生成执行方案。
从官方起点走向组织自己的能力生态
插件中心里的官方 Tool 适合帮助团队开箱即用，但是它们不应成为生态的终点。
真正拉开差异的，是每个团队在长期工作中形成的判断。新主机满足哪些条件才能接入，告警出现后先查什么，发布前必须完成哪些检查，故障证据采集到什么程度才算完整。这些经验过去散落在脚本、Wiki、ITSM 流程和资深工程师的工作习惯里。
Ontox 让团队从官方能力开始，在真实任务中逐步长出自己的能力。成熟的执行动作可以进入工具库，跑通的工作方法可以整理成 Skill，企业已有的环境权限继续由 Connector 管理。AI 帮助一线工程师把完成任务时用过的步骤和判断整理出来，再由维护者检查、验证和发布。
这样的积累会产生复利。一项经过验证的 Tool 可以支持越来越多的工作方法，一份成熟的 Skill 可以被更多同事使用，一次真实任务也可能成为下一项组织能力的起点。插件中心的价值由此不只体现在上架了多少内容，更体现在这些内容帮助多少人完成了工作，又参与组成了多少新的能力。
最终，每家企业都会形成一套属于自己的运维能力目录。新员工加入以后，不必先问遍团队有哪些脚本、入口和隐含约定。Agent 可以从组织已经发布的能力中找到合适的方法，并在他的权限范围内协助执行。
AI 已经能够操作越来越多的运维系统，接下来真正形成差距的，是企业能否让自己的经验持续进入这套能力生态，并让它们在更多任务中被找到、被验证和被复用。
结尾
选择一项团队反复执行的运维任务，在 Ontox 里走一遍。先让 Agent 使用已经发布的 Tool 完成执行，再把跑通的方法整理成 Skill，最后换一个新会话重新调用。它能直接检验，团队留下的是一次成功对话，还是一套可以继续复用的运维能力。
如果你的团队已经积累了不少脚本和流程，却不知道怎样整理成团队 Agent 可以直接使用的 Tool 与 Skill，可以在后台留言或私信，我们会结合真实场景一起梳理。
前往 Ontox控制台直达注册。
如果你也在关注 AIOps、Agent 运维、可观测性、生产环境里的 AI 安全边界，欢迎私聊我加入 Ontox 交流群，一起探索 AI 运维的正确打开方式。
