Datadog AI Agent Monitoring 面临 Dynatrace 9.15 亿美元押注 Arize 的挑战
Dynatrace 同意以 9.15 亿美元收购 Arize 后,Datadog AI agent monitoring 面临了更直接的挑战。这笔交易让一个新兴产品类别,演变为两家成熟可观测性厂商之间的正面竞争。
两家公司都希望成为企业用来检查 AI agent、评估其输出、控制成本并调查故障的系统。不过,它们切入这一机会的起点不同。Datadog 正将其云监控平台延伸至 agent 开发领域,而 Dynatrace 则通过收购获取更深厚的评估能力。
这一时机至关重要,因为 agent 会带来传统应用仪表板无法解释的运营问题。一个 agent 可以选择工具、调用其他 agent、检索外部数据,并在生成答案前重复执行步骤。即使请求成功完成,仍可能导致错误的业务结果、暴露敏感信息,或消耗远超预期的资源。
由此形成了一种颇具意味的反转。AI agent 承诺自动化数字工作,但企业还需要另一层软件来监管这种自动化。Datadog 和 Dynatrace 正竞相争夺这一控制层的主导权,赶在买家最终选择更小型的 AI 原生专业厂商之前。
Dynatrace 将 AI 可观测性变成一场 9.15 亿美元的竞争
Dynatrace 计划收购 Arize,使竞争不再局限于常规基础设施监控,而是扩展到完整的 AI 开发生命周期。
Dynatrace 于 2026 年 8 月 13 日宣布达成最终协议。该公司表示,将以 9.15 亿美元收购 Arize,但需进行惯常调整。对价包括约 8.15 亿美元现金,以及向 Arize 员工发放的替代性股权奖励。
该交易预计将在完成监管审查及满足其他惯常条件后交割。在此之前,Dynatrace 和 Arize 仍是独立企业。因此,两家公司承诺的整合应被视为路线图,而非已经实现的产品成果。
Arize 专注于评估和观测机器学习系统、大型语言模型应用及 agent。其工具帮助开发者检查追踪记录、比较实验、评估响应质量,以及识别模型行为的变化。
Dynatrace 则具备不同的基础。其平台已将应用追踪、基础设施健康状况、日志、用户活动和业务交易关联起来。该公司认为,将这些运营信号与 Arize 的评估工具结合,可覆盖 AI 应用从开发到生产的整个过程。
这一组合解决了许多工程组织内部真实存在的割裂。AI 团队通常在一个环境中测试提示词和模型,而运维团队则在另一个地方监控延迟、错误、基础设施和事故。
Dynatrace 表示,拟议中的收购将弥合这一缺口。其 Arize agreement 将 AI 可观测性描述为一个涵盖实验、评估、生产追踪、基础设施和业务成果的生命周期。
这项公告也显示出,该类别对于成熟监控厂商已具有多高的价值。Dynatrace 并非只是增加一个仪表板,而是在投入大量资本,将 AI 评估与其现有企业平台连接起来。
该公司已于 2026 年 1 月推出专门的 AI Observability app。该产品支持 agent 交互、工具使用、依赖关系、token 消耗、延迟、成本趋势和护栏结果。
Dynatrace 还表示,其支持超过 40 种 LLM 技术。列出的集成包括 OpenAI、Anthropic、Amazon Bedrock、Google Gemini、LangChain 以及新兴的 agent 协议。
Arize 为 Dynatrace 提供了一条更强的路径,可进入那些在应用进入生产环境前开展工作的 AI 工程团队。它还通过 Arize 的 Phoenix 项目,为该公司带来了开源影响力和更专业的评估工作流。
Datadog 现在面对的是一家同时具备收购速度和成熟企业销售渠道的竞争对手。Dynatrace 则面临更艰难的任务:在不削弱 Arize 吸引力所在的开发者体验的前提下,整合两款产品。
为什么 AI Agents 会打破传统监控模式
一个 agent 即使在技术层面始终可用,也可能做出一连串各自看似有效的决策,最终导致糟糕的结果。
传统应用监控通常关注服务是否响应、耗时多久,以及是否发生错误。这些指标依然必要,但它们无法解释 agent 的推理路径或输出质量。
以处理退款的客户支持 agent 为例。它可能检索账户、查询政策、调用计费工具,并更新客户记录。即使每项服务都成功返回响应,agent 仍可能套用了错误的政策。
同一请求的第二次执行也可能走上不同路径。大型语言模型具有非确定性,这意味着相同输入并不总会产生相同输出。这种可变性削弱了围绕固定预期结果构建的测试。
工具使用又增加了一层不确定性。agent 可能选择错误的函数、提供不合适的参数,或在错误的时机调用正确的工具。它还可能陷入重试循环,在不产生常规应用错误的情况下增加延迟和 token 消耗。
多 agent 系统进一步扩大了问题。协调 agent 可以将工作委派给专业 agent,后者再调用外部模型和服务。最终答案可能依赖于多个提示词、权限、检索步骤和模型响应。
因此,团队需要能够保留完整执行路径的追踪记录。追踪记录是一次请求执行步骤的关联记录,其中包括模型调用、工具调用、耗时、错误和相关元数据。
但收集追踪记录只是开始。工程师必须将技术行为与质量、安全和业务成果关联起来。如果响应包含未经支持的说法,或触发未经授权的操作,再快的响应也没有价值。
Datadog 在 2025 年 6 月推出 AI Agent Monitoring 时描述了这一问题。其 monitoring release 表示,该产品会在交互式图表中映射输入、工具调用、对其他 agent 的调用和输出。
该公司表示,工程师可以调查延迟峰值、错误的工具调用和无限循环,随后将这些事件与质量、安全和成本指标关联起来。
Dynatrace 也采取了类似的广泛视角。其 AI Observability app 会追踪提示词、工具调用和模型调用,同时将其与基础设施及应用依赖关系相连。
这些能力解释了为何 AI 可观测性正变得不只是一个 LLM 仪表板。运营对象已从可预测的软件交易,转变为拥有行动权限的概率性工作流。
这一变化同时给开发者、安全团队、站点可靠性工程师和业务负责人带来压力。每个群体都需要从同一份证据中获得不同答案。
开发者想知道哪个提示词或工具导致了故障。运维团队需要延迟、可靠性和依赖关系数据。安全团队需要权限和审计追踪。业务领导者则希望看到 agent 能产生有用成果的证据。
能够将这些问题连接起来的平台将很难被替代。这正是 Datadog 与 Dynatrace 之争背后的战略奖赏。
Datadog AI Agent Monitoring 从生产数据入手
Datadog 的优势在于,能够将 agent 行为与客户已经收集的应用和基础设施信号并列呈现。
Datadog 将 AI Agent Monitoring、LLM Experiments 和 AI Agents Console 作为其更广泛 LLM Observability 产品的一部分推出。三者共同覆盖运行时调查、受控测试和集中监督。
AI Agent Monitoring 聚焦于一次执行期间发生的情况。工程师可以检查模型调用、工具和 agent 交接构成的链路。该界面还会将这些步骤与延迟、token 使用量、错误、成本和评估结果关联起来。
LLM Experiments 则处理部署前的变更。团队可以利用从生产追踪记录创建的数据集或提供的示例,对提示词、模型和应用配置进行比较。
生产追踪记录与实验之间的这种联系,是 Datadog 方法的核心。在实时工作流中发现的故障,可以转化为可重复的测试用例。工程师随后可将拟议修复方案与原始行为进行比较。
Datadog 在 2026 年 9 月的指导中,以一个支持 agent 说明这一工作流。团队可能在部署后发现摘要被截断、计费调用缓慢。追踪数据可以识别反复出现的模式,而实验则可测试提示词或模型调整能否改善这些问题。
该公司还建议在重复运行中比较非确定性输出。当另一次执行可能产生不同结果时,单次成功响应所提供的证据很有限。
评估器又增加了一层能力。这些测试会根据相关性、准确性、安全性或任务完成度等特征,为 agent 的输出评分。有些使用确定性规则,另一些则使用另一种语言模型作为评判者。
基于模型的评估可以扩大审查规模,但也会引入自身的不确定性。Datadog 建议,在依赖 LLM 评判者的分数之前,先根据人工评估对其进行校准。这一谨慎做法很重要,因为两个模型可能共享相同的盲点。
AI Agents Console 将监控范围扩展到企业自行开发的软件之外。Datadog 表示,它能够帮助组织编目内部和第三方 agent、检查使用情况、衡量影响并核查权限。
当员工采用嵌入编码工具、客户平台和生产力软件中的 agent 时,这种编目功能尤为重要。组织可能并不拥有 agent 的模型或运行时,但仍需对数据访问和结果负责。
Datadog 更广泛的商业地位为这一战略增添了分量。该公司报告称,2026 年第二季度营收为 11.2 亿美元,同比增长 36%。该公司还报告称,年度经常性收入超过 10 万美元的客户约有 4,720 家。
这些数字并不能证明 Datadog 将引领 AI 可观测性。它们表明,Datadog 拥有庞大的客户基础,agent 监控可以成为其中又一项附加产品。
Datadog 还在该季度全面推出了 Bits Code、Bits Chat 和 Bits Agent Builder。这些产品让该公司同时处于市场的两端:它既为客户构建 agent,也销售用于观测 agent 的系统。
这一位置创造了有益的产品反馈。Datadog 可以将监控工具应用于自家的 agent,并直接遇到运营问题。它也形成了一项可信度考验,因为客户可以判断该公司的自主产品是否始终可被检查。
对于工程团队而言,吸引力在于整合。一次 agent 事故很少止步于模型边界。根本原因可能存在于缓慢的数据库、故障 API、检索管道或过载的 GPU 中。
Datadog 可以在现有监控环境中关联这些层面。团队还需要实时遥测之外可搜索的技术上下文,包括事故记录和设计决策。一套持续维护的工程知识库可以保留这些人为积累的上下文。
Datadog 面临的挑战是证明,一个广泛的平台能够在评估深度和开发者易用性上媲美专业工具。现有的分发能力打开了大门,但并不能替代产品决策。
Dynatrace 正在收购生命周期中的开发环节
Dynatrace 的 Arize 战略通过将发布前评估与围绕依赖关系上下文构建的生产平台连接起来,以此向 Datadog 发起挑战。
Dynatrace 历来强调因果分析。其 Smartscape 技术可绘制应用、基础设施、服务、网络和用户之间的关系。其 Grail 数据层则整合了可观测性、安全性和业务信息。
该公司认为,这种上下文可帮助团队理解事故为何发生,而不只是识别哪项指标发生了变化。该方法适合智能体系统,因为不良结果可能源于多个依赖项之间的联动。
Dynatrace 专门推出的 AI Observability 应用已可跟踪智能体执行路径、工具调用、模型交互、Token 使用量、成本、延迟和错误。它还支持 OpenTelemetry 和 OpenLLMetry,这两者提供了用于采集遥测数据的开放规范。
开放式埋点至关重要,因为智能体技术栈正在快速变化。企业不希望每个新模型、框架或协议都需要专有的监控集成。
Dynatrace 列出了对 Amazon Bedrock AgentCore、Strands Agents、LangChain、Google 的 Agent Development Kit、OpenAI Agents SDK 以及 Model Context Protocol 工作流的支持。这种广度降低了运行混合环境的企业的使用摩擦。
Arize 填补的是另一种需求。AI 工程师在选择数据集、提示词、模型和候选发布版本时会使用评估系统。他们的工作流在运维团队接收到生产服务之前就已开始。
因此,拟议中的组合瞄准了一个持续存在的组织分工。开发团队调查模型行为和响应质量,运维团队则审查可用性、应用依赖关系和基础设施性能。
将这些活动整合起来,可能形成一个持续改进闭环。生产故障会成为一个评估案例,随之产生的变更可在受控部署将其重新带回生产环境之前接受测试。
Dynatrace 表示,整合后平台将把 AI 行为与业务影响联系起来。这是一项重要主张,因为技术代理指标可能掩盖失败。
例如,智能体可能缩短平均处理时间,却增加重新开启的支持工单数量。编码智能体可能产出更多变更,却提高回滚率。可观测性平台需要结果数据,才能区分活动量与实际价值。
Dynatrace 带着显著的增长势头进入这场竞争。该公司报告称,其 2027 财年第一季度的年度经常性收入为 21.36 亿美元,同比增长 17%。
公司还报告季度营收为 5.55 亿美元,同比增长 16%。根据其季度业绩,有机新增年度经常性收入增长了 41%。
Dynatrace 表示,随着客户扩大云原生工作负载和 AI 项目,需求正在上升。不过,公司表述无法揭示有多少收入直接来自 AI 可观测性。
因此,Arize 交易既是一项产品决策,也是一场市场押注。Dynatrace 正在为技术、人才、开发者采用率和时间买单。
整合风险十分显著。企业监控平台和面向开发者的评估工具服务于不同用户群体。它们的界面、部署模式、发布周期和采购流程并不会自动契合。
Dynatrace 必须在将 Arize 接入更大平台的同时,保留其对 AI 工程师的吸引力。强制迁移或过于复杂的打包方式,可能会将开发者推向独立替代方案。
它还必须证明,整合后的数据能带来更好的决策。更多遥测数据并不会自动带来更多理解。糟糕的模式设计、不完整的追踪记录和不一致的评估标准,可能只会形成规模更大的模糊证据集合。
胜者必须监控质量、成本与权限
决定性功能不会是最漂亮的追踪图,而是能否将智能体行动与可接受的业务结果联系起来。
Datadog 和 Dynatrace 都能展示执行路径、Token 使用量、错误和延迟。这些能力正逐渐成为基础要求,而非持久的差异化优势。
更难的问题是如何定义成功。智能体可以完成工作流,却未必让用户满意。它可以给出准确答案,却可能违反政策。它可以提升质量,却让工作流失去经济性。
质量评估依然尤其困难。规则可以验证结构化输出、必填字段和已知事实。开放式写作、推理和建议则需要更具主观性的判断。
LLM-as-a-judge 评估提供了规模化能力,但不应成为不受质疑的事实标准。评判模型可能偏好某些写作风格、遗漏细微的事实错误,或复制被评估模型中存在的偏见。
人工审查对于校准和高风险案例仍然必要。然而,审查每一次执行会削弱自动化的大部分经济价值。供应商必须帮助客户决定哪些案例值得人工关注。
成本更容易统计,却更难解读。Token 消耗、模型费用、基础设施使用和外部工具调用,都可能构成智能体的运营成本。
重试循环可能在不引发明显故障的情况下推高支出。更昂贵的模型如果能可靠完成任务并减少返工,仍然可能具备经济性。因此,成本监控需要以结果作为分母。
权限带来的风险最高。智能体可以访问客户记录、代码仓库、财务系统和通信工具。可观测性必须记录智能体尝试了什么、使用了哪些权限,以及行动是否获得批准。
对于敏感工作流,仅在操作完成后记录不安全行为是不够的。企业将越来越要求实施策略执行、可撤销访问、人工审批和可恢复执行。
这一要求模糊了可观测性、安全、治理和运行时控制之间的边界。Datadog 和 Dynatrace 不仅彼此竞争,也面对专注于评估、智能体网关、安全、追踪和工作流编排的专业厂商。
OpenTelemetry 可以降低采集层面的供应商锁定,但无法标准化每一种评估分数或业务结果。供应商在数据模型、关联方式和自动化建议上仍将作出不同选择。
这给买家留下了一个值得怀疑的问题:统一平台究竟能揭示更多信息,还是仅仅集中更多数据?
答案因组织而异。已经标准化采用 Datadog 的公司,可能看重快速部署和熟悉的工作流。大型混合型企业则可能更偏好 Dynatrace 的依赖关系模型和因果分析。
AI 原生团队可能会继续选择专业评估工具,之后再将选定的遥测数据发送到更广泛的监控平台。Dynatrace 收购 Arize,正是试图防止这一专业层继续保持独立。
两家供应商都尚未建立一种普适方法来证明智能体可靠性。它们的产品可以收集证据、运行测试并突出异常,但客户仍必须定义可接受的行为和有意义的结果。
风险在于,AI 可观测性可能变成一系列美观的仪表盘,却缺乏运营问责。成功的部署会将每项重要评分关联到决策、负责人、阈值和响应措施。
三个信号将决定 Datadog 与 Dynatrace 的竞赛
下一阶段将由整合情况、可衡量的采用率,以及企业授予这些平台的控制权程度来评判。
第一个信号是 Dynatrace 对 Arize 的收购能否完成并实现产品整合。交易完成只是测试的开始。买家应关注追踪记录、数据集、评估和生产事故如何在两个环境之间流转,以及流转速度有多快。
连贯的工作流将强化 Dynatrace 的生命周期论点。独立的界面、重复的数据或不明确的产品归属则会削弱它。围绕 Arize 和 Phoenix 的开发者留存率也将提供另一个有价值的信号。
第二个信号是两家供应商披露的客户采用情况。总体营收增长提供了背景,但无法单独反映智能体可观测性的需求。
有价值的证据包括:受到监控的生产智能体数量、使用评估的工作负载、每位客户附加采用的产品数量,以及与 AI 相关的客户扩张。案例研究应说明可衡量的结果,而不只是智能体数量。
第三个信号是从观察走向受治理行动的进展。两家公司都在构建能够调查事故和协助运维的智能体。客户必须决定这些系统可以提出变更建议、执行获批步骤,还是自主行动。
只读分析所需承担的信任负担较低。自动化修复则需要完整的审计追踪、受约束的权限、回滚机制,以及智能体出错时明确的责任归属。
在受治理行动方面取得进展,将强化这样一种观点:可观测性平台可以成为企业智能体的控制平面。持续的犹豫则意味着,监控依然有价值,但自主性已触及信任边界。
企业买家不应仅凭功能清单选择平台。他们应从一个生产工作流开始,并定义其可接受的质量、成本、延迟、权限和业务结果。
随后,他们应测试该平台能否重建一次故障、识别其原因、比较拟议修复方案,并防止问题回归。这项练习会暴露精美演示可能掩盖的缺口。
对于已经使用其平台的组织,Datadog AI agent monitoring 目前提供了一条强有力的生产优先路径。Dynatrace 则押下更大的赌注:评估与运维必须成为同一个生命周期。
最终胜出的将是能够把不可预测的智能体行为转化为团队可信赖且可据以行动的证据的供应商。对买家而言,眼下的问题更简单:你的监控系统能否解释的,不只是智能体是否运行过,还包括它是否做对了事?



