Agent 的可观测性不能只盯着模型调用和工具执行；一旦 runtime 进入 durable、可恢复、多租户模式，启动、hydration、checkpoint、恢复、请求持久化这些存储阶段同样决定一次运行到底卡在哪里、为什么变慢、是否重复执行。把这些阶段藏在一个“agent latency”里，线上排障只能靠猜。

Cloudflare Agents 0.18.0 把 SDK 管理的初始化、启动、聊天交互、turn 和 durable submission 拆成语义阶段，并为 storage-heavy setup、hydration、recovery、request/response persistence 建立命名 span。每个 span 带 agent identity、稳定的 UI grouping marker 和操作元数据；同时通过 invoke_agent {agent}、chat {model}、execute_tool {tool} 形成从运行到模型、工具的统一 OTel 投影。关键不在 span 变多，而在“推理慢”和“存储慢”终于能被区分。

工程上，这会改变 OPC 类平台的 trace 设计：不要只给 run 记一个总耗时，而要把 lifecycle phase、storage phase、run id、session scope 和 recovery attempt 放进低基数属性；payload 默认不进 telemetry，只有显式开启时才存消息或工具参数。这样既能定位 hydration/写盘背压、恢复风暴和重复提交，也不会把用户内容变成默认日志。更重要的是，phase 边界应该和取消、重试、告警、SLO 对齐，否则“可观测”仍然只是漂亮的时间线。

如果一次 Agent 运行变慢，你的系统能否在不打开用户 payload 的情况下回答：慢在推理、工具，还是状态恢复？