不改一行代码，看透AI Agent的每一次调用

当一个AI Agent收到用户提问时，它可能先调用Embedding模型将问题向量化，再向向量数据库发起Top-K检索，经Rerank重排序后携带上下文调用GPT-4o，期间GPT-4o还可能通过MCP协议调用外部工具——整条链路横跨多种协议、多家云服务商。然而，当用户反馈“回答不对”时，开发者面对的却是一个没有监控录像的案发现场。传统APM能告诉你“有一个HTTP请求耗时3秒”，却无法回答“模型用了哪个、消耗了多少token、Tool Call调了什么函数、向量检索返回了几条结果”。这种可观测性缺失正在成为AI应用落地的重大瓶颈。

为什么SDK埋点方案难以落地

OBI（OpenTelemetry eBPF Instrumentation）提供了一种革命性的解法：在Linux内核里安装一台全天候取证摄像头。它不需要修改任何业务代码，就能自动识别并解析所有AI相关的网络调用，把关键证据完整记录进OpenTelemetry标准的trace和metrics。这意味着，无论应用使用Python、Go、Java还是Node.js编写，无论调用的是OpenAI、Anthropic还是国内各厂商的大模型API，OBI都能一视同仁地捕获完整调用链路。

内核层：绕过HTTPS的明文捕获

Cloud Native OpenTelemetry社区定义了一套GenAI语义约定（Semantic Conventions for GenAI），规定了gen_ai.request.model、gen_ai.usage.input_tokens等标准属性。然而，在实际业务代码中按规范埋点却困难重重。首先，每个Provider的SDK完全不同——OpenAI SDK、Anthropic SDK、Google GenAI SDK、Boto3（Bedrock）、DashScope SDK——开发者需要为每一个编写tracing wrapper，提取各自格式的字段再映射到统一属性。其次，GenAI语义约定本身还在快速演进，SDK封装者需要不断追赶规范更新。更关键的是，很多AI Agent应用压根不用官方SDK，而是直接用requests、http.Client等通用HTTP客户端拼接JSON请求，这意味着所有基于SDK monkey-patch的可观测性方案全部失效。

跨语言协程追踪：重建真实的调用血缘

OBI的核心思路是把问题换一个层面解决：不在应用层逐个Provider封装SDK，而是在Linux内核的网络层统一拦截HTTP流量。但今天所有LLM调用都跑在HTTPS上，直接在网卡或socket层抓包看到的只是一堆加密字节。OBI的解法是在用户态密码库的“加密前和解密后”这一瞬间挂钩子（uprobe），因为加密发生在用户态密码库内部，应用层和密码库之间的接口永远是明文buffer。只要探针挂在这个接口上，根本不需要中间人证书、不需要私钥，就能拿到完整的请求体和响应体。对于Go静态链接二进制，OBI通过ELF符号表和DWARF信息定位关键函数偏移；对stripped二进制则使用BTF加.eh_frame退栈信息定位，确保对生产环境编译镜像也能工作。

协议解析与生产实践

抓到明文只是数据层的胜利，更难的是关联层。一个真实的AI Agent几乎不可能是“一个请求一个线程”的同步模型——Python asyncio在单个线程里并发跑几十个协程，Go用goroutine把上下文切来切去，Node.js把callback链拆得到处都是。如果还按传统PID/TID把调用归到同一个父span，整条trace就会全部串线。OBI在Linux内核层为三种主流并发模型分别做了上下文重建：对于Python asyncio，OBI在CPython解释器上挂了4个uprobe，分别盯住task_step、Task.init、PyContext_CopyCurrent和context_run四个关键点，维护一张协程ID到父协程ID的映射表。对于Go goroutine，OBI直接对runtime.newproc1下手记录父子血缘，在HTTP请求触发时沿血缘表向上溯源找到最近一个带trace context的祖先goroutine。这套机制确保了即使单个线程里同时有多个协程并发调用LLM，OBI也能准确还原每条独立的调用链。

如有侵权，请联系删除。