Dynatrace 9.15 亿美元收购 Arize：为什么 Agent 需要一种全新的可观测性

大多数团队都能让 AI Agent 在演示里跑起来，但能在生产里长期稳定运行的少得多。生产中，一个有状态的 Agent 会触碰几十个工具、跨会话记住上下文，还可能在延迟面板一切正常时悄悄出错。这正是 Dynatrace 在 2026 年 10 月 1 日完成对 Arize 收购所要填补的鸿沟——Arize 是一家 AI 可观测性与评估平台。这笔 9.15 亿美元的交易不只是并购新闻：它意味着「面向 AI 的可观测性」正在成为一个独立学科，与我们熟悉的 APM 分道扬镳。本文讲清发生了什么、工程师为什么要关心，以及本周就能落地的埋点方法。

AI 可观测性把 Agent 的 trace 而非单次请求当作第一对象

一笔交易，先把事实说清

据 Dynatrace 新闻稿，该收购于 2026 年 10 月 1 日完成。Dynatrace 自称「领先的 AI 驱动可观测性平台」，Arize 则是「为 Agent 提供持续学习的 AI 可观测性与评估平台」。交易以现金加股票计价，总额 9.15 亿美元；据 Dynatrace 投资者公告，其中约 8.15 亿美元为现金，其余为加入 Dynatrace 的 Arize 员工的替代股权激励。关键的是，两个产品都保留：Arize 将继续支持其开源平台 Phoenix 与企业产品 AX，相关能力会在未来逐步整合进 Dynatrace。Dynatrace 也表示会继续支持 Phoenix，并向 OpenInference 贡献。

# The deal, in one object. Numbers come straight from Dynatrace's
# press release and investor release, both dated October 1, 2026.

DYNATRACE_ARIZE = {
    "closed": "2026-10-01",
    "value_usd_m": 915,
    "cash_usd_m": 815,
    "rest": "replacement equity awards for Arize employees",
    "acquirer": "Dynatrace (NYSE: DT) - AI-powered observability",
    "target": "Arize - AI observability & evaluation platform",
    "products_that_continue": ["Arize AX (enterprise)", "Phoenix (open source)"],
    "open_source_commitment": "continue backing Phoenix + contribute to OpenInference",
}

# The headline for engineers: evaluation and observability are merging
# into one lifecycle instead of living in two separate tool silos.

它到底填了什么可见性缺口

这道逻辑写在 Dynatrace 自己的调研里。该公司博客引用的一项针对 919 位 Agentic AI 负责人的研究显示：51% 把「大规模管理与监控 Agent 的技术挑战」列为上生产的主要障碍，45% 表示缺乏明确规则来判断 Agent 何时可自主行动、何时必须人工介入。这两个数字描述的是同一个盲区：看不见就管不住。传统 APM 只能告诉你接口在线、延迟正常，但一个调错工具、又自信地给出错误答案的 Agent，能通过所有经典健康检查。面向 Agent 的可观测性必须回答不一样的问题。

# Why this matters, from Dynatrace's own study of 919 agentic AI
# leaders. The two numbers describe the same blind spot: you cannot
# govern what you cannot see.

VISIBILITY_GAP = {
    "surveyed": 919,
    "barrier_monitoring_agents_at_scale_pct": 51,
    "lack_clear_rules_for_autonomy_pct": 45,
}

# Classic APM tells you an endpoint is up and latency is fine.
# It will not tell you that the agent called the wrong tool and
# returned a confident wrong answer. That is the gap.

def health_flags(latency_ms, error_rate, answer_correct):
    return {
        "apm_says_ok": latency_ms < 800 and error_rate < 0.01,
        "actually_ok": answer_correct,
    }

评估与生产监控第一次被收进同一个闭环

Arize 究竟带来了什么

Arize 的核心思路是把 LLM 的 trace 当作第一对象。它的工具能记录：模型检索到了什么上下文、Agent 调用了哪些工具、结果是否站得住——正是普通 span 图答不了的三件事。Arize AX 是托管的企业平台，Phoenix 是开发者本地运行的开源项目。由于 Arize 是开放埋点规范 OpenInference 的坚定支持者，你可以在 OpenTelemetry 之上输出 LLM span，而不必为了拿到 trace 就绑定某个专有 Agent SDK。这种开放性最值得关注：今天采集的遥测数据，能挺过下一次框架迁移。

# Tracing an agent: OpenInference is the open spec that lets you
# emit LLM spans over OpenTelemetry, so you are not locked into a
# proprietary SDK just to get traces. Dynatrace has said it will
# keep backing OpenInference.

# pip install arize-phoenix openinference-instrumentation-openai openai
import phoenix as px
from openinference.instrumentation.openai import OpenAIInstrumentor
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import SimpleSpanProcessor
from opentelemetry.exporter.otlp.proto.http.trace_exporter import OTLPSpanExporter

# 1. Launch a local Phoenix collector for development.
px.launch_app()

# 2. Point OpenTelemetry at it and switch on auto-instrumentation.
provider = TracerProvider()
provider.add_span_processor(
    SimpleSpanProcessor(OTLPSpanExporter(endpoint="http://localhost:6006/v1/traces"))
)
trace.set_tracer_provider(provider)
OpenAIInstrumentor().instrument(tracer_provider=provider)

# 3. Every LLM call and tool call is now a span you can inspect:
#    context retrieved, tools called, output produced.

如何开始给 Agent 做 trace

拿 trace 比多数人想象得容易。装上 Phoenix 与 OpenInference 埋点包，启动本地收集器，把 OpenTelemetry 指向它，再打开自动埋点。从此每次 LLM 调用、每次工具调用都会变成一个 span，附带检索到的上下文、工具入参与返回结果。开发时在 Phoenix 界面读这些 span；生产时把 OTLP 导出指向你选的存储后端。真正要养成的是纪律：所有环境、所有模型调用与工具调用都统一埋点，这样本地复现的 bug 才和生产事故长得一样。

# Evaluation is the other half. Instead of eyeballing outputs, run
# scored evals against a labelled set before you ship a prompt change.

from phoenix.evals import llm_classify, OpenAIModel
import pandas as pd

model = OpenAIModel(model="gpt-5.6", temperature=0)

TEMPLATE = (
    "Given a question and an answer, return correct, partial or incorrect. "
    "Question: {question} Answer: {answer}"
)

answers = pd.DataFrame({"question": [...], "answer": [...]})
results = llm_classify(
    dataframe=answers,
    template=TEMPLATE,
    model=model,
    rails=["correct", "partial", "incorrect"],
)

# Wire the same eval into CI so a regression fails the build, not prod.

51% 把大规模监控 Agent 列为障碍的负责人，如今多了一件新武器

把评估放进流水线

Trace 告诉你发生了什么，评估告诉你做得好不好。实操做法是：先定义一小批有代表性的带标签样本，写一个分类模板，按「正确 / 部分正确 / 错误」等 rails 给输出打分，再把同一套评估接进 CI，让退化质量提示词改动在构建阶段就失败，而不是发到线上。这正是「把评估并入可观测性」的意义：你在生产里调试的那条 trace，就是 CI 里用来断言的 fixture，这才是让回归到不了用户手里的办法。

# The Monday checklist. Evaluation gates belong in CI; governance
# belongs at runtime. Arize AX and Phoenix both stay available, so
# pick the surface your team already owns.

PRE_PROD_GATE = [
    "trace every LLM + tool call (OpenInference over OTel)",
    "run scored evals on a labelled set in CI",
    "fail the build on any eval regression",
    "log identity for every agent action (human or agent)",
    "set autonomy rules: when the agent must ask a human",
    "alert on trace anomalies, not just latency",
]

def ship(prompt_change):
    assert run_evals(prompt_change).passed, "eval regression blocked release"
    return deploy(prompt_change)

一份周一就能用的清单

如果只记住一件事，就记住这份清单：用 OpenInference 经 OpenTelemetry 为每次 LLM 与工具调用埋点；在 CI 里对带标签样本跑打分评估，任何退化都让构建失败；为每个 Agent 动作记录身份（人或 Agent），让「谁授权了什么」几秒可答；写清明确的自主规则，界定何时必须问人；对 trace 异常而非仅对延迟告警。Arize AX 与 Phoenix 都仍可用，从你团队已经拥有的那个面板起步即可——并把评估与生产监控之间的闭环守住。