拒绝AI“黑盒”：2025年，我用SkyWalking“监控”了自己的Agent大模型应用

原创已于 2026-01-04 11:17:41 修改 · 767 阅读

14 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#人工智能 #skywalking #大模型 #Agent #python

于 2025-12-30 11:40:09 首次发布

Python3.8

Python 是一种高级、解释型、通用的编程语言，以其简洁易读的语法而闻名，适用于广泛的应用，包括Web开发、数据分析、人工智能和自动化脚本

从DevOps到LLMOps，谈谈在LangChain实战中如何优化耗时与Token成本

摘要

2025年是Agent（智能体）爆发元年，但开发者的噩梦也随之而来：Agent死循环、Token消耗失控、响应慢如蜗牛。在本文中，我将分享如何跳出单纯的Prompt工程，引入Apache SkyWalking进行全链路追踪，实现对LLM应用的深度可观测性。我们将探讨如何从架构层面解构Agent的“思考过程”，并基于数据进行精准的性能优化。

一、引言：当代码变成了“概率学”

2025年，我的开发重心从传统的CRUD微服务全面转向了AI Agent开发。起初的兴奋很快被现实浇灭——传统的软件工程是确定的（Input A 必得 Output B），但LLM是概率性的。

在开发一个基于RAG（检索增强生成）的企业助手时，我经常遇到这样的场景：

用户问一个简单问题，Agent却思考了30秒。
月末账单出来，Token费用莫名其妙翻倍。
Agent在“思考-行动”的循环中卡死，不断重复调用同一个工具。

我意识到：我们不能用Debug传统代码的方式去Debug大模型。 我们需要可观测性（Observability）。于是，我决定将云原生时代的监控利器——Apache SkyWalking，引入我的AI项目。

二、痛点：Agent 开发中的“隐形杀手”

在没有引入链路追踪之前，优化Agent全靠“猜”。

一个典型的 LangChain Agent 执行流程包含：用户输入 -> Embedding -> 向量库检索 -> Rerank重排序 -> LLM思考 -> 工具调用 -> LLM最终总结。

这中间任何一个环节出问题，都会导致体验崩塌。

网络抖动？ 还是OpenAI API响应慢？
向量检索太耗时？ 还是Prompt太长导致首字生成（TTFT）过慢？

没有数据，就没有优化。

三、破局：SkyWalking 的“魔法”改造

SkyWalking 作为一个强大的 APM 工具，很多人只用它监控 Java/Spring Boot。但其实 SkyWalking 社区已经推出了针对 Python 和 AI 的强大的生态支持。

我的技术方案如下：

框架： LangChain + OpenAI/Qwen
监控： SkyWalking Python Agent (sw-python)
可视化： SkyWalking OAP Server + UI

在这里插入图片描述

3.1 核心接入代码实现

不同于传统的埋点，我利用了 Python 的装饰器特性，专门针对 LLM 的关键节点进行了追踪。

# 这是一个简化的接入示例，展示如何追踪 LLM 的关键函数
from skywalking import agent, config, Layer
from skywalking.decorators import runnable

# 配置 SkyWalking Agent
config.init(collector_address='127.0.0.1:11800', service_name='My-AI-Agent-Service')
agent.start()

# 1. 追踪 RAG 检索过程
@runnable(op='VectorDB/Search', layer=Layer.Database)
def search_knowledge_base(query):
    # 模拟向量数据库查询
    # ... 实际代码 ...
    return docs

# 2. 追踪 LLM 调用 (核心)
@runnable(op='LLM/ChatCompletion', layer=Layer.Http)
def call_llm(prompt):
    # 这里记录具体的 Prompt 长度作为 Tag，方便后续分析成本
    span = agent.context.active_span()
    span.tag('llm.provider', 'gpt-4')
    span.tag('llm.prompt_tokens', str(len(prompt))) 
    
    response = openai.ChatCompletion.create(...)
    return response

def main_flow(user_input):
    # 整个 Agent 的思考链条
    docs = search_knowledge_base(user_input)
    final_response = call_llm(docs + user_input)
    return final_response

通过这种方式，原本黑盒的 Agent 逻辑，在 SkyWalking 的 UI 上变成了一条清晰的瀑布流（Trace）。

四、实战：基于数据的三次关键优化

接入监控只是第一步，基于数据做决策才是核心。以下是我通过 SkyWalking 发现并解决的三个真实问题：

优化 1：发现“假慢”——向量库的锅

现象： 用户反馈回答慢，我一直以为是 LLM 生成慢。
Trace分析： 打开 SkyWalking 链路图，我惊讶地发现，LLM/ChatCompletion 耗时其实只有 2 秒，但前面的 VectorDB/Search 竟然高达 4 秒！
解决： 根本原因不是模型慢，而是向量库没有建立索引，且 Embedding 模型在 CPU 上运行。
成果： 将 Embedding 服务迁移至 GPU 并优化索引后，整体 P99 延迟下降了 40%。
在这里插入图片描述

优化 2：治理 Token——Prompt 的精简

现象： 成本居高不下。
数据分析： 我利用 SkyWalking 的 Tags 功能记录了每次请求的 Token 数。在分析聚合数据时发现，某个特定工具的 System Prompt 竟然占据了 3000 tokens，而且每次都在重复发送。
解决： 引入 Prompt 压缩技术，并对上下文窗口进行动态截断。
成果： 单次调用 Token 成本降低 60%，且并未影响回答质量。

优化 3：监控 Agent 的“精神状态”

现象： 偶尔 Agent 会进入死循环。
监控策略： 我在 SkyWalking 中配置了告警规则（Alarm）。如果单次 Trace 中 LLM/ChatCompletion 的调用次数超过 5 次（意味着 Agent 在反复思考却不行动），立即触发飞书/钉钉告警。
成果： 成功拦截了数次 Agent 的“死循环”事故，避免了 Token 的无限浪费。