APM
应用性能管理工具，用于监控软件应用的性能和可用性，传统APM关注HTTP请求、数据库查询等基础设施层面指标
时间轴 (近 90 天)
在 SDK 或网关层重试比中间件层面的重试更容易与现有的 APM 体系对接。
Signal被唤醒后会构建一个沙箱，将trace上下文、第三方APM日志与指标、仓库访问权限和所需密钥放入其中；沙箱只有一个代理出入口，内部一切操作都被追踪。
Agent在生产环境中存在三种传统APM无法告警的故障模式：循环（反复重试失败动作导致成本增加和副作用）、漂移（模型输出特征随时间逐渐偏移）、异常（单步合理但序列整体错误的行为）。
传统APM工具（如Datadog、New Relic）的设计假设是系统行为可以被归纳为有限的错误模式，其监控粒度是单次请求，无法捕获Agent在跨请求序列层面的结构性故障。
传统 APM 工具通常只能看到一次 HTTP 请求的耗时和状态码，无法回答 prompt 中拼入了哪些文本块、调用花了多少 token 和美元、检索相似度分布如何等问题。
在 LLM 应用中，模型可以返回 HTTP 200 状态码，但内容却可能是幻觉、错误计算、拒答或空工具调用，传统 APM 指标无法识别这些异常。
AI 可观测性借鉴传统 APM 思路，记录每次调用的输入、输出、延迟、token 消耗和用户反馈评分，用于发现模型静默退化
标准APM工具在AI负载面前缺乏对LLM交互的语义理解——只能看到HTTP请求，却抓不住真正重要的语义span：实际发送的prompt、消耗的token数、结束原因，以及检索步骤（RAG）与最终生成之间的语义关系。
传统HTTP健康检查、进程存活探针和APM工具通常只关注状态码和延迟，不解析响应语义
传统APM工具是为确定性软件逻辑设计的，面对LLM这类概率性、非结构化输出的系统力不从心
还有 6 条时间轴事件
全部知识事实 (16)
在 SDK 或网关层重试比中间件层面的重试更容易与现有的 APM 体系对接。
50%待验证Signal被唤醒后会构建一个沙箱，将trace上下文、第三方APM日志与指标、仓库访问权限和所需密钥放入其中；沙箱只有一个代理出入口，内部一切操作都被追踪。
50%待验证Agent在生产环境中存在三种传统APM无法告警的故障模式：循环（反复重试失败动作导致成本增加和副作用）、漂移（模型输出特征随时间逐渐偏移）、异常（单步合理但序列整体错误的行为）。
50%待验证传统APM工具（如Datadog、New Relic）的设计假设是系统行为可以被归纳为有限的错误模式，其监控粒度是单次请求，无法捕获Agent在跨请求序列层面的结构性故障。
50%待验证传统 APM 工具通常只能看到一次 HTTP 请求的耗时和状态码，无法回答 prompt 中拼入了哪些文本块、调用花了多少 token 和美元、检索相似度分布如何等问题。
50%待验证在 LLM 应用中，模型可以返回 HTTP 200 状态码，但内容却可能是幻觉、错误计算、拒答或空工具调用，传统 APM 指标无法识别这些异常。
50%待验证AI 可观测性借鉴传统 APM 思路，记录每次调用的输入、输出、延迟、token 消耗和用户反馈评分，用于发现模型静默退化
50%待验证标准APM工具在AI负载面前缺乏对LLM交互的语义理解——只能看到HTTP请求，却抓不住真正重要的语义span：实际发送的prompt、消耗的token数、结束原因，以及检索步骤（RAG）与最终生成之间的语义关系。
50%待验证传统HTTP健康检查、进程存活探针和APM工具通常只关注状态码和延迟，不解析响应语义
50%待验证传统APM工具是为确定性软件逻辑设计的，面对LLM这类概率性、非结构化输出的系统力不从心
50%待验证LLM可观测性平台与传统APM工具的区别在于需要对Prompt模板版本、模型采样参数（Temperature、Top-p）以及多轮对话上下文进行版本化管理
50%待验证作者提出'APM=智能体生产力监控'，用'仪式'（检查、交接、批准等流程活动）与实际进展的比率作为集群健康的关键指标
50%待验证传统的应用性能监控（APM）通常依赖在代码中埋点或通过SDK注入来采集指标
50%待验证通用APM工具往往只能监控网络层和崩溃，无法感知JS执行耗时、Bridge通信开销或React组件渲染瀑布流等框架层面的瓶颈
50%待验证传统的日志、APM和监控工具是为确定性软件设计的，面对AI系统'跑通了但结果错了'的问题时力不从心
50%待验证APM赛道早期工具仅提供性能指标采集和展示，后来的赢家如Datadog和PagerDuty通过智能告警、根因分析和事件响应自动化建立差异化优势
50%