易点天下：AI 驱动 IT 运维组织提效的实践

作者：杨钊、刘警、白玙

易点天下作为一家专注品牌全球化的营销科技公司，由智能营销、全域增长、智能变现三大引擎驱动。公司旗下拥有“整合营销服务”与“广告平台业务”两大业务线。截至目前，已服务超过一万家出海企业与品牌，链接全球六十万以上媒体。整合营销主要帮助出海客户做统一服务，包括品牌设计、广告投放和本地化运营，提供全链路的支持；数字化广告和程序化广告则通过技术手段、算法和数据，帮助客户把广告精准投放到每一个目标群体。

演讲人：易点天下高级系统工程总监 杨钊

全球化广告业务的特点与系统要求

作为一家全球化营销公司，易点天下的业务系统也是全球化的，面临的挑战不少。广告业务本身属于流量密集型场景，叠加出海和全球数据流动，对基础设施提出了很高的要求，可以归纳为四点：

• 业务规模大、并发请求高： 每天百万级 QPS，流量峰谷波动大，系统必须高弹性。

• 业务关联性强： 广告系统之间流量往来频繁，SSP、DSP、ADX 之间相互导流，系统复杂度高。

• 全球化布局： 多区域部署，跨时区 7×24 响应；时延和抖动会直接影响竞价成功率，海外业务问题，我们都得处理。

• 成本敏感： 广告行业对成本很敏感，运维上想在成本上省一些，稳定性面临的压力就会更大——既要便宜又要稳定。

基于这样的复杂度和要求，我们很早就希望介入 AI，用 AI 帮助我们解决过去很难解决的困局。

AI 辅助运维：四类高频场景的提效实践

我们部门接触 AI 非常早。过去大家的方式都差不多——把日志粘贴出来做问答式分析，我这里不再赘述。但到 2026 年，情况有了明显变化：以对话方式辅助定位、人工执行命令与验证的 AI Chat 模式，逐步演进到 2026 上半年个人 OpenClaw 等 Agent 的大量使用，Agent 可以直接操作命令、主动深入探索问题根因，提效尤其显著。如下图，上半年的实践集中在四类高频场景，平均提效 68%~87%：

这些数据都非常真实。因为 AI 足够聪明，它解决问题的深度可以让一个初级工程师做到老师傅一样的深度和广度。以某起 Aerospike 故障为例：HPA 扩到 40/40、CA 扩节点 80+，表象是集群雪崩，AI 在 8 分钟内穿透表象定位到单点连接池耗尽，而人工基线需要 40 分钟。

个人 AI Agent 的阶段性问题

但在实践过程中，我们也发现了一些问题，这里跟大家交流一下，看看是不是有同样的困扰：

第一，个体差异。个人提效因人而异，包括方向和 AI 使用能力的差异。不管用 OpenClaw 还是某种 Agent，同一个团队综合下来能力差别非常大——好的 Agent 能解决的问题，别人用同样版本、同样模型却识别不出来。团队里甚至出现了“拿你的 Agent 帮我们训练一下”的情况。

第二，限制难以落地。企业里总会有各种限制，运维场景下尤其敏感。比如要求现阶段不能让 Agent 直接执行写操作、不能把 AK 这类密钥直接告诉 Agent。但在人手一个 Agent 的情况下，即便有这样的要求，也很难管理和落地。

第三，组织未重塑。每个人好像都有提效，但整个组织的运作模式没有任何变化。以故障处理为例，过去没 AI 时是人处理，有了 AI 可能还是人处理、人驱动 AI 处理——人在故障处理这个业务环节中还在原来的位置，跑不掉。

第四，质量不可靠。即便是能力最强的同事，他的 Agent 处理同一件事时质量也会波动。一段时间后，人们习惯性地相信 AI 的结论，但同一个 Skill 的发挥还像刚开始那样稳健吗？可能因为 Skill 增多、也可能因为换了模型，质量就变了。而在生产级运维里，我们特别需要的是确定性——不管是七分还是十分的质量，最好是一个稳定的质量，这样才能放心把工作持续交给 AI 运行。

这些问题，靠过去个人 Agent 的体系没有办法很好解决。

从人盯系统到 Agent 融入业务流：闭环架构

所以我们决定，统一建设一套 Agent 的运行方式，把个人能力变成组织能力，并且让 AI 直接融入业务流程。

构想的核心是两点。其一，组织内会有很多 Agent 和 Skill，当出现某个问题或需求时，到底该用哪个 Agent 来解决？ 过去每个团队都有一个“老师傅”，不管什么问题都能指一条正确的路子。既然有这么多 Agent，是不是也应该有一个“总管大管家”，根据任务分配给不同的 Agent 解决。其二，除了 Agent 和模型本身的能力，要想它稳定发挥好，数据这一层必须统一——不能今天查某个业务有十台机器、明天变成八台，也不能张三查和李四查结果不一样。数据包括知识库、监控数据、CMDB、资产和配置，必须有统一的标准和交付。

在选型过程中，我们从真实业务场景出发（比如运维排查故障：可能是数据库、基础设施、运行环境或云的问题，需要多个 Agent 加统一知识库，查询结果还要能判断是否靠谱、需不需要人工复查），看了不同厂商方案、开源方案，也考虑过自研。有的方案偏重 Agent 运行环境，有的偏重 Agent 开发本身，有的偏重安全策略。经过调查，最终选择阿里云 AgentCore，它的整个框架能覆盖我们运维场景所需的功能。

基于 AgentCore，我们构建了一套 IT 运维组织提效的闭环架构，以 Leader Agent 为核心，贯通感知、分析、决策、执行、验证与沉淀六个环节，分为三层：**

• 数据层（统一数据支撑） ：结合云监控 2.0、日志服务 SLS、CMDB 与内部系统（MCP 化），将指标、链路、日志和事件汇集于统一视图供 Agent 使用。其中云监控 2.0 提供指标/调用链/实体/拓扑/事件，SLS 提供日志与分析，CMDB 提供资源与拓扑，内部系统通过 MCP 标准化调用。
• 统一智能入口（协同执行） ：基于 AgentCore 纳管运维 Agent，以 Leader Agent 统一管理——负责意图识别、场景路由、任务编排、多 Agent 协作和结果汇总，协同 Container-RCA Agent、Troubleshooting Agent、DB-Agent、STAROps 等专业 Agent。运维场景的 Skill 统一管理和安全扫描，通过AI Native 入口（Skill、CMS MCP Server、Inner MCP Server）接入。
• Agent 审计与自进化：结合 Agent 可观测和 AgentLoop 记录调用链、会话、Token 和执行轨迹，识别 Agent 安全风险，并通过评估实验实现自进化；记忆与知识库由 ContextDB 承载。

一句话概括这层架构：Leader 管流程与底线，Worker 管专业诊断，独立知识与经验降低串扰，质量门禁保证对外答案可信。

多 Agent 运维工单处理实践

基于 AgentCore，我们把运维工单处理跑成了一条清晰的流水线：业务问题输入 → Leader 识别与派单 → 专业Agent 调查 → 质量门禁 → 自助解答 / 人工兜底。

关键设计是 Leader 不亲自查问题，只负责判断“谁来处理”、组织协作、汇总结论，并决定“能否对外发出”。整个流程分五步：

1. 业务问题入口：业务方只需用自然语言、工单或 IM 机器人描述现象（如“构建失败，日志里提示依赖下载超时”），无需知道该找谁。常见业务类型包括数据库问题（MySQL/PG/Redis/MongoDB/Aerospike/Cassandra）、构建（构建日志/依赖/流水线）、容器 IT（K8s/Pod/节点/网络）、阿里云运维（常见问题分析/长期巡检）。

2. Leader-Agent 分诊中枢：识别业务域、选择业务 SOP、派单与协作、汇总证据，明确底线——不越权、不跳过 SOP、证据不足不对外下结论，且不直接执行专业诊断。

3. 专业 Worker Agent 团队：数据库 Agent、构建 Agent、容器 Agent、STAROps Agent 分别处理对应领域。每个 Worker 都可独立组合“知识库 + 经验 + Skill/MCP”——业务知识库、各 Agent 的历史轨迹与成功路径/BadCase/恢复策略、以及数据库只读查询、日志检索、K8s 诊断、构建平台等工具。AgentLoop 负责记录 Trace、构建 Dataset、评估质量、回归 BadCase。

4. 质量门禁与对外回复：Leader 决定结论是否达到可发布标准，发布前检查 SOP 步骤是否完成、证据链是否完整、结论与证据是否一致、权限与风险是否可接受。

5. 人工介入：结论通过则输出自助解答（结论、证据、建议与下一步），不通过则补充信息、避免无证据回答，非确定性越权处置一律转人工。

在多 Agent 协作的工程细节上，AgentCore 解决了三个关键问题： 一是 Agent 之间通信的鉴权（如容器 Agent 与数据库 Agent 通信需要凭证，以及凭证过期如何处理）；二是不同 Agent 任务进度和运行时间不一，需要心跳检测监听执行情况，某个 Agent 无法完成时派发新的 Agent；三是多 Agent 协作时 Worker 之间的隔离，以及长任务与短任务的协作通信。

借力 STAROps 与云监控 2.0 实现智能会话与长期任务闭环

统一数据层是这一切的基础。我们有多云、多账号、多区域，数据不能让 Agent 到处去拉，必须做统一汇聚。以 ECS 指标接入为例：采集云产品指标接入阿里云云监控 2.0 的托管 Prometheus，传统方式容易漏采，运维同学人工操作也复杂——要么控制台操作，要么调用一系列 API，工作量大还容易出错。我们的目标是更高效、稳定地完成多账号、多地域、多资源的实时接入。

结合阿里云 STAROps，我们通过智能会话实现了客户侧 30+ 账号指定指标的批量接入。后续已接入的云账号每新增一个 ECS，只要带上对应标签，托管 Prometheus 就会自动完成指标接入；未来新增一个云账号，运维同学只需与STAROps 简单对话，即可快速完成新账号云资源指标的自动接入，并一次性完成按 Region 采集、多 Region 按大区聚合（美洲聚合到弗吉尼亚、东南亚聚合到新加坡、欧洲聚合到法兰克福）、统一投递到阿里云新加坡 Region Prometheus，实现指标数据的统一汇聚。

Agent 会自动运行，从初始化第一次到之后每一次运行，都按设计完成，最终汇聚成统一的监控数据，方便后续其他 Agent 调用。 我们通过以下视频，完整展示整个闭环如何运行：https://mp.weixin.qq.com/s/s2_tOveu9V67CLH6UGUpyw

自进化闭环：让每次运维都成为下次的最佳实践

用了这样的工具，它本身有一套完整的链路逻辑，我们真正需要关注的是评估——怎么评估 Agent 运行状态好不好、质量够不够。这属于我们自己的业务范畴，不需要太关心它怎么实现，但要关心结果。这块由 AgentLoop 的经验自进化飞轮承载：真实运行数据 → 可验证经验 → 关键决策点召回 → 更稳、更省的执行，把运维工程师验证过的方法变成可复用、可审计、可持续优化的组织能力。我们将飞轮分为以下六步进行运转：

1. 观测 Trace（采集模型、工具、错误、恢复过程与最终结果；

2. 清洗 Trajectory（去噪为标准轨迹，数据量约为原 Trace 的 4%–6%）；

3. 经验挖掘（提炼成功路径、反模式、参数规则与恢复策略）；

4. 评估门禁（以成功率、稳定性和单位成功成本验证，有效经验入库）；

5. 按需召回（按目标、对象、工具、进度和错误状态注入少量经验）；

6. 更优执行（关键节点少走弯路，新 Trace 回流下一轮）。

沉淀下来的是“怎么做”的方法论（Experience Store），而非重复保存日志或业务知识，且不改模型权重，可快速更新、限制范围或下线。它覆盖六类 SRE 真实场景——成本分析、容量巡检、网关自检、主动通知、故障根因分析、日常工作，持续产生成功与失败的真实 Trace。参考实验中，正确率从 7.1% 提升到 36.1%，Token 下降 6.8%。效果是从“偶尔做对”走向“稳定上线”：平均质量上升、运行下限上升、结果波动下降、单位成功成本下降。

持续优化：评估→实验→再评估的改进闭环

这里举一个真实的改进例子——优化评估任务“Agent 工具调用成功率”，重点处理评分小于 0.5 的数据：

1. 评估·发现问题（2026-09-04 初次评估）：Agent 工具调用成功率 0.93，但筛选该评估器出现了 0.2 / 0.5 的低分记录。

2. 实验·定位与解决：定位到低分原因是 mcp-k8s 初始化失败（MCP error -32603），修复 kubeconfig 配置后单条运行验证，问题解决。

3. 再评估·验证闭环（2026-09-18 再次评估）：复核小于 0.5 的低分是否消失，筛选后已无低分数据，改进确认有效。

需要说明的是，我们不以综合分值评判前后两次评估的优劣（两次数据集时间段不同），只关注小于 0.5 的低分是否消失。这正是我们要的重点——评估发现低分项、实验定位并修复、再评估验证闭环，让 Agent 恢复到稳定状态。这块是我们未来应该重点关注的，而“怎么做、怎么实现”交给产品就好。

Agent 观测与安全审计：让每一次工具调用可观测、可核验

运维领域绕不开 Agent 安全。我们的做法是：除了 AgentCore 能在事前做一些分析（如 Skill 上架前的分析），还接入了 Agent 安全中心，通过规则持续从事前、事中、事后分析问题并不断优化。整套审计链路是：应用语义 + 运行时事实 → 规则初筛 → 语义研判 → 风险分级 → 调查核验，回答五个问题——想做什么、实际做了什么、是否越界、影响了谁、证据在哪里，做到执行前控制 + 执行中留痕 + 执行后研判，把 Agent 风险从“不可见”变为可发现、可排序、可调查、可复核。

其中一条关键原则是：规则负责确定性判断，模型负责需要上下文的语义研判。探针层由 LoongSuite-Pilot 采集语义事实（Session、模型、Tool），由 LoongCollector eBPF 采集行为事实（进程、文件、网络）；逻辑规则计算做敏感线索匹配和确定性判定，明确命中直接形成结论；模型语义研判则结合任务意图、Session 上下文、授权边界与执行结果确认风险。最终形成标准化的审计事实，保留来源边界进入统一审计链路，输出带类型、等级、判定原因、命中字段与证据位置的风险结论，并按主体、类型、时间归并，依据等级、趋势和影响范围排序，进入异常行为调查与实体调查，回查原始行为记录。

建设心得

走过弯路之后，我们沉淀下三件事：

Lesson 01丨重视业务流程。 不要上来说用什么技术解决问题。过去团队里很多人研究 OpenClaw、研究 RAG，但我们真正要问的是：什么时候能解决第一个问题？解决这个问题真的需要哪些技术功能？技术人员最擅长“实现”，但更关键的是“实现什么”。每个Agent 项目都应从一个具体业务痛点出发，先把业务场景拆清楚再匹配技术栈——场景错了，工具再强也是空中楼阁。

Lesson 02丨多用服务商方案，别轻易“手搓”。 特别小的团队想手搓也有心无力；但到了中等规模、有开发资源时，大家总会想“自己开发，灵活可控”——这话没错，但要不要一开始就自己弄？建设初期都在投入底座、Loop、观测，什么时候能实现业务、真正效果如何，反而更慢。鉴权、审计、评测、编排这些，云厂商已有成熟产品；自建等于长期成本，采购等于起步速度。能买的就别自建，能复用的就别重写，把精力留给业务 Agent 与 Skill 设计。

Lesson 03丨持续运营更重要。 Agent 交付的结果质量不可能一直稳定可靠，后续还有很长的运营过程。Agent 不是一次性交付物，而是一个“新员工”，需要持续训练、评估、纠偏。数据会漂移、模型会升级、业务会变化，没有 AgentLoop，Agent 会慢慢“退化”。所以未来过去所谓的业务运维人员、专项系统运维人员，可能就会转变为持续关注和运营某一个专家 Agent，让它一直提供稳定可靠的结果质量——把“运营 Agent”作为一个常驻岗位。

AI 驱动运维提效，不等于买个工具，而是「业务流程 × 数字员工 × 持续运营」。先把业务流程想清楚，让 Agent 真正融入业务流而非停在个人手里；再用统一的数字员工架构（Leader Agent 调度、专业 Worker 诊断、质量门禁兜底）把个人能力沉淀为组织能力；最后靠 AgentLoop 的评估—实验—自进化闭环持续运营，让每一次运维都成为下一次的最佳实践。这，就是我们 IT 运维组织提效与重塑的完整路径。