贵萌兄1. Agent变成黑盒，不是模型的错，是链路没有眼睛
前阵子一个做AI客服产品的朋友跟我抱怨：他们的Agent在生产环境跑了一个月，突然开始批量输出奇怪的话术，用户投诉量暴涨。整个团队围着大模型转了一个星期，一会儿怀疑prompt被污染，一会儿怀疑温度参数被调错，一会儿怀疑模型版本回滚——最后谁也没找出问题。
其实这个场景这两年我见过太多了。AI Agent跑起来之后，外部看起来就是“输入一个问题，输出一个结果”，但中间发生了什么，几乎没人能说清楚。Agent调了哪个工具？工具返回了什么？上下文窗口被什么东西撑爆了？哪一轮推理开始走向偏离的？这些问题在传统的日志和监控体系里，基本上是盲区。
这不是模型的错。模型本身只负责做概率预测，真正让Agent变得不可控的，是它外围那套复杂的执行链路——LLM调用、工具编排、上下文组装、状态维护、外部API交互，每一环都有可能是问题源头，但每一环都缺乏足够的观测手段。
更要命的是，Agent的很多执行路径是动态的。它今天可能走A工具链，明天可能走B工具链，你没法在开发阶段把所有可能的分支都埋好点。传统的埋点监控在静态服务上很好用，但放到Agent这种高度动态的执行体上，就明显跟不上了。
所以就有了这个思路：既然从应用层、从外部去观测Agent就像隔着一堵墙看里面，那就把观测能力下沉到内核态，从系统层面把Agent所有的行为轨迹完整记录下来。这就是eBPF做的事——它可以在不侵入应用代码的前提下，对进程的每一次系统调用、每一次网络请求、每一次文件读写做细粒度的采集。
所谓四层监控链路，指的就是把AI Agent从底层算力消耗到顶层业务行为，拆成系统资源层、网络调用层、运行时协议层、Agent语义层四个层面，用eBPF统一采集、统一关联，让Agent的每一次“思考”和“行动”都有据可查。
这篇就完整聊聊我实践下来的方案设计、技术选型逻辑，以及落地过程中踩过的那些坑。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 为什么传统监控在Agent面前集体失灵
在讲eBPF方案之前，先得说清楚一个现实问题：我们之前用的那套监控体系，到底哪里不够用。
2.1 应用日志：Agent的输出不等于Agent的行为
传统的日志监控思路，是在代码里打点。Agent框架通常也会给自己留日志，比如打印每一次LLM请求的参数和返回结果。但实际用下来你会发现，框架日志能覆盖的只是它自己定义好的那部分流程，Agent真正干的事远不止这些。
举个例子，Agent要查询订单状态，它可能会先调一个意图识别工具，再调订单查询API，最后把结果拼装成自然语言回复。框架日志能记录“查询到了订单状态”，但它记录不了这个过程中网络层发生了什么——API超时重试了几次？TLS握手是不是慢了？目标服务的响应体是不是被截断了？这些信息分布在系统栈的不同层级，应用日志根本覆盖不到。
更要命的是，Agent的上下文是动态拼装的。很多框架只记录最终的prompt，但中间那些工具调用结果、历史对话摘要、上下文截断逻辑，日志里往往是残缺的。一旦Agent的行为开始偏离预期，你想从日志里回溯是哪一轮哪一步开始歪的，大概率只能靠猜。
2.2 APM与OpenTelemetry：埋点始终是绕不开的坎
APM（应用性能监控）和OpenTelemetry这套体系，解决的是分布式链路追踪问题，原理是在应用层生成trace_id、span_id，然后跨服务传递。这套逻辑在传统的微服务架构里很成熟，但放到Agent场景有三个别扭的地方。
第一是侵入性。OTel要求业务代码里集成SDK，或者至少用agent方式做字节码注入。但Agent框架的更新迭代极快，今天用的框架接口，下周可能就换版本了，埋点代码跟着框架变动反复调整，维护成本非常高。很多团队Agent还没跑稳，先被埋点代码折腾了个半死。
第二是上下文断裂。Agent请求第三方大模型API时，你只能观测到“发出了一个HTTP请求”，但模型内部究竟把注意力分配到了哪些tokens上、为什么会生成某个句子，这些你无从得知。也就是说，OTel能告诉你“哪一步慢”，但说不清楚“哪一步蠢”。
第三是短连接追不到。Agent经常会通过连接池复用连接，或者在极短时间内发起大量并发请求。传统的trace机制在这种高并发、短连接的场景下，丢span的概率很高，很多时候你拿到的链路图是不完整的。
2.3 基础设施监控：看得见资源，看不见行为
还有人会说，直接用Prometheus那套基础设施监控不就行了，CPU高就是算力瓶颈，内存涨就是泄漏。确实，基础设施监控能给你一个宏观的资源水位，但它给不了你行为层面的信息。
你想知道的是：Agent这次推理到底因为什么失败了？是模型返回了错误格式，还是工具调用的参数拼错了，还是外部服务的限流策略触发后重试逻辑有bug？这些问题的答案，全部不在基础设施监控的视野范围内。
所以总的问题就是：应用层观测不到行为全貌，APM层扛不住动态性和高频性，基础设施层看不到语义信息。三层各管一段，但中间全是空洞。
2.4 Agent的“系统复杂性”要求完全不同的观测思路
传统软件是人写死的逻辑，输入输出是可预期的，出问题大概率是代码bug或者资源不够。Agent不一样，它的行为是模型基于概率生成的，本身就是不确定的。这种不确定性放大到复杂的工具调用链路上，会让故障的定位维度变得非常多：
- 是模型本身的问题（幻觉、上下文丢失、指令遵循能力不足）
- 是工具层的问题（参数拼错