过去 API 调用大体可预测：背后是人，有人的意图与上下文。哪怕自动化，也终归是人延伸出来的。但在智能体现实里，这条假设模糊了——智能体会做人类难以追踪、且未必对齐人类意图的决策。只要跑通就没事；一旦跑偏，你就得排一个完全不透明的故障：分不清哪段是自动、哪段是人、哪段是智能体。这并非理论问题：API 见到的智能体流量比以往任何时候都多，而工具忙于「接入」这半截，下一截——可观测性——还差得远。
智能体流量不映射人类意图、非线性、不可预测，传统监控失灵。本文编译自 Nordic APIs（2026-07-16，作者 Kristopher Sandoval），给出 6 步：建 API 目录与 MCP 注册表、映射工作流、跨工作流关联、启发式分流、记录工具意图、设风险阈值。
过去 API 调用大体可预测：背后是人，有人的意图与上下文。哪怕自动化，也终归是人延伸出来的。但在智能体现实里，这条假设模糊了——智能体会做人类难以追踪、且未必对齐人类意图的决策。只要跑通就没事；一旦跑偏，你就得排一个完全不透明的故障：分不清哪段是自动、哪段是人、哪段是智能体。这并非理论问题：API 见到的智能体流量比以往任何时候都多，而工具忙于「接入」这半截，下一截——可观测性——还差得远。
简单说：没编目，就无从观测。智能体环境里，问题不只是「有哪些 API」，还有「它们怎么连、被什么包着」。打个比方——厨房库存管理：你每周用多少面粉黄油？何时该补货？靠购物清单和心里那本账。现在设想有人溜进厨房偷用你的面粉黄油，若你连储藏室有啥都不知道，根本无从追踪，更别提制止。第一步就是确立「到底在观测什么交互」，把 API 与 MCP 实例当作一等公民编入目录/注册表，这是后面一切的基础。
有了 MCP 目录，下一步是真正探测智能体工作流、弄清它们怎么用你的 API。智能体不总按可预测方式用系统：比如它本要更新某资源，却反复 ping 你的目录或超媒体上下文做「上下文校验」，确认走对了地方。这种用法，恰恰说明该给那个 API 加缓存——只因为它和人的用法太不一样。过程中难免有猜测，但观察智能体如何（以及「以为你想让它」如何）用系统，能反向推动你把流程改得更清晰、更不被误导。
智能体调用可能需要和人类调用不同的对待。人一天打十个工作流调用，彼此大概率不同意图；而智能体可能走到一半，觉得此路不通，换一套全新工作流重来——对你系统是新工作流，对智能体却是「同进程的新路径」。解法是用工作流存证（workflow attestation）或 Agent ID 追踪：强制每个智能体有唯一标识，或至少在网关层用 IP/设备指纹做来源追踪，把分散的请求连起来，把噪声变成有用信息。
运行时监控只能自信识别一小部分流量，所以边界上最好用启发式 + 分流。先建「人类基线」：滤掉已知智能体与自动化，看人类用 API 长什么样（必要时从内部小群开发者起步）。再把流量更直接地分流到「对智能体友好」的端点；若发现把人类流量误归智能体池（或反之），随时在网关层改分流——这是个高度迭代的过程。分流还要配套细粒度权限与身份发放：别再把一切都标记为「接入」，必须做细。
要分清「智能体用例」与「智能体工具」、以及请求背后的意图。比如一个智能体可能编排多个工具（常经 MCP 提供）去达成某用例——它们不是不同智能体，却容易在追踪里被笼统当成「智能体流量」。部分可在 MCP 层处理：所有 MCP API 调用都应带一个「持续使用所必需」的 header，用来在整条智能体工作流里追踪。其余可在鉴权流程里追踪，但若两处都抓，识别方法必须统一，否则对不齐。
可观测系统就位后，还要让它更聪明。知道「有智能体流量」不够，应在可能处记录工具用途与意图。多数智能体流量是例行低风险——每次它问自己的 Agent ID 都要全量可观测，会逼疯你。更高风险的是：它做决策、升级请求、或试图访问资源。这些风险各有等级：访问公开稳定资源，不同于访问用户资料设置。关键是用触发器把异常检测绑定到动作——通知人工介入升级请求，并随时间追踪行为异常，形成自我强化、越来越准的系统。
这过程必须迭代。你第一天做不到完美，即便做到，智能体领域变化太快，有效期也很短。因此要不断重新评估，确保你的可观测性真的反映当下运营现实。让整套机制成为灵活、鲜活的体系：用真实的现场数据快速试错、快速失败。