AIOps探索：用OpenClaw做AIOps，最大绊脚石不是能力而是成本

推荐语

OpenClaw在AIOps中的实际应用挑战：能力不是问题，成本才是关键。

核心内容：
1. OpenClaw在日志分析中的实际表现与成本问题
2. AIOps生产环境中面临的三大核心挑战
3. 长链路运行带来的效率损耗与解决方案

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

研究AIOps已有数月，目前手里有不少可落地的方案了，接下来会把这些方案全部整理到我的大模型课程里。欢迎大家把你遇到的场景在评论区留言。我会在能力范围内给你提供思路和建议。

上周尝试着将OpenClaw做日志分析，整个链路跑通，最终分析结果还行。但让我无法忍受的有两点：1）Tokens消耗太快；2）分析周期太久。

OpenClaw很强，但没做优化的话，它只适合跑Demo

如果你还没有设计好Token预算和上下文治理，就不要急着用OpenClaw这类 Agent编排框架去承接生产级AIOps。

不是因为它不能做，恰恰相反，正因为它能接告警、能拉日志、能串工具、能生成结论、还能继续联动动作，所以一旦链路被拉长、上下文被放大，成本和时延问题就不会是“偶发问题”，而会变成系统问题。

我想很多朋友跟我一样，第一次接触这类框架，最容易被打动的是能力完整。接告警、查指标、拉日志、补知识、做判断、回写工单，一条链路看起来很顺，甚至很像未来。

但AIOps最大的门槛，从来不是“能不能编排出来”，而是：这套东西在高频、并发、持续运行的生产环境里，到底算不算得过来。

真正难的，不是做出链路，而是把链路跑得起来。在demo里，大家通常只会看到一件事：它会不会分析。可到了生产里，你真正要看的不是“会不会分析”，而是三件更硬的事：

• 一次分析到底要吃掉多少上下文；

• 一条链路到底要调用多少轮工具；

• 高峰期多条告警并发时，预算会不会失控。

因为AIOps不是一次性的问答任务。它不是“有人问一句，模型答一句”这么简单。它面对的是持续涌入的真实运维信号：指标序列、日志片段、变更记录、依赖关系、历史工单、服务画像、SLO状态。

这些信息一旦开始拼接，问题就来了。你送进模型的，不再是一段简洁问题，而是一整包上下文。模型要在这包信息里做筛选、比对、定位、归因、判断，Tokens消耗自然不会只按“多一行字、多一点钱”这么简单增加。

OpenClaw就把context定义为“一次运行发送给模型的全部内容”，里面不仅有会话历史，还有系统提示、工具调用结果、文件和附件。而且工具列表、工具schema、本地注入文件本身都会占上下文窗口。换句话说，不是只有你主动塞进去的日志才花Tokens，系统为了让agent能工作，本身就在持续消耗上下文预算。

这也是为什么很多链路在演示环境里显得“很聪明”，到了生产侧却容易变成“又贵又慢”。

为什么链路越长，效率反而越容易下降

很多人会本能地觉得：链路更完整，结论应该更稳；工具接得更多，效果应该更好。

但在AIOps里，这件事经常反过来。链路一旦变长，至少会出现四类典型损耗。

1. 上下文堆叠损耗

最常见的错误，不是信息不够，而是信息塞太多。

为了“保险”，大家总想把可能有用的信息都丢进去：更多日志、更多指标、更多历史工单、更多依赖关系。结果是模型先在噪声里消耗大量注意力，真正关键的异常信号反而被淹掉。

你以为自己是在补证据，很多时候其实是在补噪声。

2. 多跳转译损耗

AIOps链路不是单节点决策，而是多节点流转。

一次告警，可能先经过检测节点，再进入归因节点，然后到建议节点、执行节点、回写节点。每走一跳，上下文都可能被重新组织、重新摘要、重新包装，再发给下一个节点。

表面上你是在让系统“逐步推理”，实际上你也在为重复转译反复付费。

真正贵的，往往不是某一次大调用，而是很多次“看起来合理的小调用”叠加起来。

3. 并发放大损耗

单次消耗能接受，不代表系统消耗能接受。在低频情况下，一条链路多跑两轮，问题不明显；但一到高峰期，多条告警同时触发，成本结构就会完全变样。

原本单次看上去还行的开销，很快就会演变成预算黑洞。这也是为什么很多系统在压测和演示时都没问题，等到线上告警高峰，才突然发现“每一步都没错，但总账算不过来”。

4. 无边界回溯损耗

还有一种特别隐蔽的损耗：系统没有边界、没有限制回溯窗口、没有限制证据粒度、没有限制工具调用次数、没有规定“到这一步就必须停”或者“证据不充分就转人工”。

一旦没有这些约束，agent 很容易在“求稳妥”的逻辑下不断追加查询。再看一点日志，再补一次验证，再追一次链路，再查一次历史记录。

每一步都很像正确动作。但这些动作叠加在一起，成本和时延就一起失控了。

所以AIOps里经常会出现一个很讽刺的悖论：链路看起来越全，效率未必越高；结论看起来越稳，代价可能越重。

最危险的，不是贵，而是“贵得没有感觉”，这类系统最麻烦的，不是大家一开始就知道它很贵。恰恰相反，最危险的是：它往往贵得很自然。因为每一步看上去都合情合理：

• 多拉一点日志，更稳；

• 多补一次比对，更准；

• 多走一轮验证，更放心；

• 多查一段历史，更完整。

单看每个动作，都像是在认真做事。但当这些动作被放进长链路、并发流量和持续运行的生产环境里，它们就不再只是“认真”，而是会一起把预算和时延推高。

而一旦时延上来，它影响的就不只是账单。它会开始影响MTTR，影响处置节奏，影响团队对系统的信任。

到最后，问题就不再是“这个分析贵不贵”，而是“这个系统还敢不敢继续放在关键链路上”。

OpenClaw真正适合的，不是“先全上”，而是“先受控”

OpenClaw这类框架的价值，不在于它能把一切都连起来，而在于它给了你把推理、工具、会话和上下文组织起来的能力。

官方文档也明确提供了上下文检查、压缩，以及 token / cost / duration 的可观测入口，这恰恰说明它适合被当成一个需要治理、需要约束、需要监控的运行系统，而不是一个“接上就能无脑放大”的智能黑盒。

所以它在 AIOps 里的正确打开方式，不是先追求：

• 全自动，

• 全覆盖，

• 全场景。

而是先做到另外三件更重要的事：

• 可预算

• 可观测

• 可约束

只有这三件事先成立，你后面谈扩展、谈自治、谈生产闭环，才有意义。