用 Sniffnet 看 AI agent 在后台到底产生了多少流量
作者几乎一整天开着 Cline（VS Code 里的 AI 编程 agent）。后台它不停调模型 API、发你没手动触发的请求、在"思考"时保持连接存活。他从未从网络层看过这些：查应用日志、查 agent 输出，但从没开包嗅探器看自己机器上实际飞出去的数据包。论点很简单：不拿专用工具看，就不知道 AI agent 产生了多少后台流量，而且结果常常出人意料——不是流量可疑，是我们根本从不看。这种无知在后来诊断诡异延迟、搞懂 agent"为什么这么慢"、想知道哪个进程在跟哪些端点通信时是要付出代价的。
Sniffnet 是什么
Sniffnet 是用 Rust 写的开源网络流量监控工具，实时分析流量并用图形界面展示，不用读原始 tcpdump 输出。关键特性：跨平台（Linux/macOS/Windows）；底层用 pcap，抓真实接口的数据包需要提权；能识别每条连接对应的进程/应用——这正是把"Cline 的流量"和"开着十五个标签页的浏览器流量"分开所需的能力；它不是 IDS 也不是防火墙，不拦东西、不自己报警，是被动可观测性。
安装：
cargo install sniffnet
# Linux 上非 root 抓包：
sudo setcap cap_net_raw,cap_net_admin=eip $(which sniffnet)
sniffnet
它不能做什么
不承诺解密 TLS、不显示 LLM API 的 HTTPS 请求内容、不把流量和 token 成本或模型延迟关联。Sniffnet 看到字节和连接，看不到语义。
数字最容易错在哪
常见配方：装个监控工具、看到流量尖峰、假设"出事了/agent 吃得比预期多"、没上下文就下结论。两个隐藏代价：第一，五分钟捕获里的流量尖峰，不告诉你这是否正常、是否孤例、是否取决于 agent 当时在干嘛——在传大文件上下文？在下载模型？只是 keep-alive？没这个上下文，数字就是穿着数据外套的噪音。第二，TCP/IP 不区分"有用流量"和"协议流量"。你看到字节来回，但把真正的 LLM 调用载荷和连接开销、重试、与 AI 无关的扩展轮询分开，需要按进程、端口、目标 IP 细粒度过滤——Sniffnet 允许，但要求观察者做主动工作，不是现成的。
经典反例：跑 Sniffnet，看到编辑器（带 AI 扩展）没打字也流量不断，就断定"agent 在后台搞鬼"。其实可能是扩展遥测、连接心跳、或编辑器往云上同步配置——和 AI agent 半毛钱关系没有。工具给你原始数据，正确解释要自己挣。
决策矩阵
| 场景 | 用 Sniffnet | 别用 |
|---|---|---|
| 实时看哪些进程在产生流量 | 正是它的用途 | — |
| 想知道某个 LLM API 的 HTTPS 流量有多少 | 部分：只见字节与目标，不见内容 | 用工具自身日志（Cline 在 VS Code 面板展示活动） |
| 判断生产里 agent"吃太多" | 不行，单次观测不够 | 要跨时间的聚合指标 |
| 诊断连接掉线/延迟 | 有用：能看重试与断连 | — |
| 要自动告警的 IDS | 不是它的功能 | Suricata、Zeek |
最有价值的对比是空闲 vs 活跃：agent 空闲（不处理任何任务）时的活跃连接列表，vs 丢给它一个大重构任务时——这个对比比盯着一个孤立数字告诉你更多。
诚实说限制
单次观测会话不能得出"多少流量算正常"的结论——那需要跨不同使用场景的一系列重复测量。一次捕获是起点不是结论；若你已在用 autopilot 模式给 agent 设了自主限额，网络观测是合理补充：它不替代限额，但给了你通常被忽略的角度——网络层，而非 agent 行为层。
来源：Sniffnet: How Much Traffic Are My AI Agents Generating Behind My Back - DEV Community