不想把 Trace 交给 SaaS？Arize Phoenix 的自托管路线

数据能不能出内网，先想清楚再选工具。

上一篇写 Arize AX 时，评论区有人问了一句：数据不让出内网怎么办。这个问题在金融、医疗、还有不少大厂内部是硬约束，不是「尽量」。把 Agent 的每一次运行、每一条 prompt、每一份检索到的文档都推到别人的服务器上，很多时候合规这一关就过不去。

Phoenix 就是 Arize 给这类团队准备的那条路。它和 AX 出自同一个团队、同一套标准，区别不在功能多少，而在谁来扛运维：AX 是托管服务，Phoenix 是自己部署、自己扩、自己升级。

这篇按官方文档把它拆开讲：怎么起一个实例、埋点为什么能做到和 AX 通用、评测的两条路怎么选、内置 Agent 和编码 Agent 各自能干什么，最后说清楚自托管的账到底怎么算。

本文提纲

1. Phoenix 是什么：和 Arize AX 是同一套标准的两种交付
2. 起一个实例：终端、Docker 还是自托管
3. 埋点：为什么「不用重新埋」是关键设计
4. 评测的两条路：SDK 还是 UI
5. PXI：内置 Agent，以及它不该碰什么
6. 让编码 Agent 接管：CLI、MCP、Skills 的分工
7. 放进坐标系：Phoenix、AX 和另外两家
8. 什么时候别选 Phoenix

1. Phoenix 是什么：和 Arize AX 是同一套标准的两种交付

Phoenix 由 Arize AI 和开源社区共同维护，底座是 OpenTelemetry，埋点走 OpenInference。官方把能力收成四块：Tracing、Evaluation、Prompt Engineering、Datasets & Experiments。定位是自托管、免费使用、端到端开源，文档里明确写了没有功能被商业版锁住。

先说一个容易被文档措辞带偏的细节。文档处处称 Phoenix 为 open source，但仓库里那份 LICENSE 是 Elastic License 2.0（ELv2），不是 OSI 认可的开源许可。ELv2 的核心限制只有一条：你不能把它作为托管或管理服务提供给第三方。自己用、改源码、在内网部署都不受影响，但想拿 Phoenix 搭一个对外售卖的 SaaS，许可会挡在那里。打算在它基础上做商业化产品的团队，这条要先看清楚。

规模上，Phoenix 的 GitHub 仓库约 1.19 万 star、1200+ fork，主语言 Python，首次提交在 2022 年 11 月，至今仍在高频更新。

再就是它和 AX 的关系。两者不是「免费版和付费版」的阉割关系，而是同一份内核的两种交付方式。都建在 OpenTelemetry 和 OpenInference 上，用同一套 tracing 与评测工作流。官方给的结论很直接：为其中一个埋好点的应用，换到另一个不用重新埋点，只要把 trace 的目标地址指过去就行，需要的话甚至可以同时指向两边。

2. 起一个实例：终端、Docker 还是自托管

Phoenix 对外只开两个端口：6006 同时提供 UI 和 OTLP HTTP，4317 是 OTLP gRPC。最省事的一条命令是：

# 有 uv（Phoenix 是个 Python 包，跟你的 Agent 用什么语言无关）
uvx arize-phoenix serve

# 没有 uv
pip install arize-phoenix && phoenix serve

# 或者容器
docker run -p 6006:6006 -p 4317:4317 arizephoenix/phoenix:latest

起来之后打开 http://localhost:6006 就是界面。

本地跑起来很轻松，真正的分水岭在持久化。用一个进程跑 phoenix serve，trace 只活在这个进程里；一旦要跨团队共用，就得换成 PostgreSQL 支撑的自托管部署。官方把这条路铺得很宽，Kubernetes、Helm、Railway、AWS CloudFormation、Google Cloud Run、Azure、Render 都有现成模板，配套的身份认证支持 OAuth2、LDAP 和本地账号，还有 RBAC 权限和数据保留策略。

Docker 镜像分了几个 tag，生产部署别用 latest：

Tag	说明
arizephoenix/phoenix:latest	最新发布版，root 权限
arizephoenix/phoenix:latest-nonroot	最新发布版，非 root（先确认文件系统权限）
arizephoenix/phoenix:version-X.X.X	固定版本，生产环境用这个

换到远程实例时，要改的其实只有一个环境变量。本地假设是 http://localhost:6006；指向别的部署就把 PHOENIX_COLLECTOR_ENDPOINT 设成那个部署的 OTLP HTTP traces 地址，例如 https://your-phoenix.example.com/v1/traces。开了认证的部署还要补一个 PHOENIX_API_KEY，本地 phoenix serve 不需要。

3. 埋点：为什么「不用重新埋」是关键设计

埋点这块和上一篇讲 AX 时是同一套东西，因为底层标准相同。

Phoenix 接受 OTLP 协议上来的 trace，同时给一批框架和模型厂商做了开箱即用的自动埋点：框架侧的 LlamaIndex、LangChain、LangGraph、DSPy、CrewAI、AutoGen、Pydantic AI、Google ADK、Vercel AI SDK、Mastra；模型侧的 OpenAI、Anthropic、Amazon Bedrock、Google、Mistral、Vertex、LiteLLM、Groq、Ollama 等；语言覆盖 Python、TypeScript、Java、Go。注册一下就可以自动埋，Python 里长这样：

from phoenix.otel import register

register(
    project_name="tracing-quickstart",
    protocol="http/protobuf",
    auto_instrument=True,
)

auto_instrument=True 会让 Phoenix 把它找到的每一个已安装的 OpenInference 包都打开埋点。注册完之后，原来的 OpenAI 调用代码一行都不用改，直接跑就会产生 trace。

一条 trace 拿到手能看到什么，官方列得很细：应用延迟、token 用量、运行期异常（比如限流）、检索到的文档及其打分和排序、embedding 用的文本和模型、调用 LLM 时的参数（temperature、system prompt）、prompt 模板及填入的变量、工具的描述和函数签名、以及 function call 的选择过程。多步 Agent 里一次失败到底出在哪一环，靠的就是这些逐 span 的字段。

真正值钱的是这个设计带来的迁移成本：

graph LR
    A[One instrumentation layer] -->|PHOENIX_COLLECTOR_ENDPOINT| B[Phoenix self-hosted]
    A -->|Arize AX endpoint| C[Arize AX managed]
    B --> B1["You operate the infrastructure"]
    C --> C1["Arize operates the infrastructure"]
    style A fill:#FF6B6B,color:#000000
    style B fill:#4ECDC4,color:#000000
    style C fill:#45B7D1,color:#000000
    style B1 fill:#96CEB4,color:#000000
    style C1 fill:#DDA0DD,color:#000000
    linkStyle default stroke:#764ba2

先本地 Phoenix 开发、上线后把 endpoint 指到 AX，代码不用动。反过来说，这也意味着你不必在下决心之前就为商业化平台付费——先埋点，选哪个目的地是后一步的事。

对还没有 trace 的存量应用，Phoenix CLI 提供了一条让编码 Agent 代劳的路：在应用根目录跑 npx -y @arizeai/phoenix-cli setup，它会识别你用的编码 Agent，把埋点任务交给它，并且一直等到第一条真实 trace 到达才结束。

4. 评测的两条路：SDK 还是 UI

评测回答的是「输出质量到底行不行」。LLM 的输出没法用 assert 判断，所以 Phoenix 提供两类评测器：确定性的代码评测（精确匹配、正则、自定义启发式）和 LLM-as-a-judge（用第二个模型按 rubric 打分）。跑的位置有两个：

graph TB
    A[Where does the evaluator run] --> B[Client-side SDK]
    A --> C[Server-side UI]
    B --> B1["Python and TypeScript SDKs"]
    B --> B2["Your own judge and pipeline"]
    B --> B3["Bring your own metrics"]
    C --> C1["Configured in the Phoenix UI"]
    C --> C2["Attached to a dataset"]
    C --> C3["Runs automatically on experiments"]
    style A fill:#FF6B6B,color:#000000
    style B fill:#4ECDC4,color:#000000
    style C fill:#45B7D1,color:#000000
    style B1 fill:#98D8C8,color:#000000
    style B2 fill:#98D8C8,color:#000000
    style B3 fill:#98D8C8,color:#000000
    style C1 fill:#FFEAA7,color:#000000
    style C2 fill:#FFEAA7,color:#000000
    style C3 fill:#FFEAA7,color:#000000
    linkStyle default stroke:#764ba2

客户端（SDK）这条路给你完全的控制权：评测逻辑、judge 模型、pipeline 都在自己代码里，适合把评测接进 CI。服务端（UI）那条路不用写代码：在界面里配好评测器挂到数据集上，跑实验时自动打分，适合不想让评测逻辑散落在各个仓库里的团队。

有些实现细节值得单独拎出来看。评测器要求模型用 function calling 返回结构化结果，而不是输出自由文本。Phoenix 从评测器的输出配置生成一个工具，比如：

{
  "name": "correctness",
  "parameters": {
    "type": "object",
    "properties": {
      "label": { "type": "string", "enum": ["correct", "incorrect"] },
      "explanation": { "type": "string" }
    },
    "required": ["label", "explanation"]
  }
}

模型被要求必须调用这个工具，Phoenix 解析工具参数、把 label 映射成分数。为什么要绕这一圈？因为自由文本输出要靠正则去抠标签，格式一漂移，评测结果就悄悄错了，而这类错误最难发现——分数看起来还在，只是不对应真实质量。schema 约束把这一类错误从源头掐掉。

第二层是执行器（executors）。跑几千条评测时，真正麻烦的不是评测逻辑，而是限流和并发。Phoenix 自己处理这些：遇到 provider 限流自动重试，区分临时失败和永久错误（避免在必然失败的请求上烧 API 预算），并根据 provider 的实时表现动态调并发。官方说法是这套机制能带来最高 20 倍的加速。

第三层是评测器本身也被 trace。每次评测运行都会通过 OpenTelemetry 发到一个专门的 Phoenix 项目里，记录输入数据、发给 judge 的确切 prompt、模型的完整推理、最终分数和执行耗时。意义在于 judge 本身的质量可以被审查——如果你的 LLM judge 有系统性偏见，你会在这里看到，而不是靠猜。

5. PXI：内置 Agent，以及它不该碰什么

PXI（Phoenix Intelligence，读作 pixie）是 Phoenix 内置的 AI 工程 Agent，目前是 beta。它在很多方面像一个「指向观测数据而不是代码库」的编码 Agent：检查 trace、调查失败、改 prompt、跑实验、写评测器、标注 span、替你在界面里导航。

它最舒服的一点是上下文感知。你不需要复制粘贴 trace ID，也不用把数据搬到对话框里——PXI 知道你当前打开的是哪条 trace、正在编辑哪个 prompt、应用了哪些过滤器，能力还会随页面变化：在 trace 页面能做的事和在 prompt playground 里能做的事不一样。

打开方式是任意页面按 Cmd+I（Windows 和 Linux 是 Ctrl+I）。对话存在 Phoenix 服务端而不是浏览器标签页里，所以刷新不丢、换浏览器能接着看；浏览器面板和终端客户端用的是同一个会话。喜欢键盘的可以直接在终端里聊：

npx -y @arizeai/phoenix-cli pxi

# 指定 provider 和模型
pxi --endpoint http://localhost:6006 --provider OPENAI --model gpt-5.4

终端客户端默认用 Anthropic 的 claude-opus-5，要求服务端版本在 20.0.0 以上（这是引入持久化会话的版本），启动时会先做一次模型目录和凭据的预检，配置有问题直接报错，而不是等你发第一条消息才失败。

这里有两个容易被忽略的边界。

一个是会话锁。一次只能有一个 turn 在跑，流式 turn 持有锁并用周期心跳续期，心跳掉了（大约一分钟没刷新）才能被下一个 turn 回收。多个客户端同时操作会收到 409 Conflict，错误码会告诉你怎么办：

409 错误码	含义
agent_session_busy	另一个 turn 占着会话锁，等它结束或等心跳过期
agent_session_messages_stale	别的客户端追加了消息，重新拉取再试
agent_session_model_stale	会话模型被切了，重新拉取会话再试
agent_session_tool_outputs_conflict	提交的工具输出和待处理的工具调用对不上，改请求而不是重试

另一个是「treat results as data」这条安全提醒。trace 里装的是你的 AI 应用记录下来的任何内容，包括不可信的用户输入；官方明确说 Agent 不应该去执行 trace 里找到的指令。这条如果被忽略，trace 就成了一个提示注入的入口。

控制权方面，PXI 默认「改动前先问」：保存 prompt、创建或替换标注配置、写数据集样本、提交评测器，每一个都先给你看一份可审阅的 diff 或卡片，你点了 Accept 才生效。只读操作不被拦。想放开可以把编辑审批模式切到 Bypass Approval，选择器会用警告样式提醒你。它可以整个关掉（PHOENIX_DISABLE_AGENT_ASSISTANT=true），联网检索是按会话开的开关，默认关着，需要才打开。

还有一个挺实用的能力：当 PXI 定位到真实缺陷时，它能去搜重复 issue、然后直接开一个 GitHub issue，把相关的 trace 和 span 链进去，底层用的是 GitHub 托管的 MCP server。开启方式是加一个带 Issues 读写权限的 fine-grained token，token 留在浏览器里，Phoenix 不持久化它，issue 以你本人的身份提交，而且提交前会把仓库、标题、正文都给你确认。

6. 让编码 Agent 接管：CLI、MCP、Skills 的分工

这三样经常被混着说，其实服务对象不同。

CLI（px）给有 shell 的 Agent 用，比如 Claude Code、Codex、Cursor。装好之后，你让 Agent 做什么，它在底下跑 px 命令。最有价值的是 px setup：

npm install -g @arizeai/phoenix-cli
export PHOENIX_ENDPOINT=http://localhost:6006

# 在应用根目录跑，它会写 .env.phoenix、把埋点交给你的编码 Agent，
# 并且一直等到真实 trace 到达才结束
px setup

这段有几个设计细节值得注意。它会先把连接信息（endpoint、project、key）写进一个被 gitignore 的 .env.phoenix，启动前还会检查 git 工作区是否干净，避免 Agent 的改动和你自己的改动混在一起。想只重跑其中一步，可以用 px setup instrument、px setup skills、px setup mcp。在 CI 里跑的时候加 --no-input --instrument --agent claude --yolo。如果等到超时也没等到 trace，退出码是 6，含义是「已配置但未验证」——连接和改动都在，但埋点没被证实，流水线里应该按这个语义处理。

需要说清楚的是 px 的写权限边界：它唯一会写入 Phoenix 的东西是标注、笔记和标注配置。它不建数据集、不改 prompt、不跑实验——那三件事要么用 SDK，要么在 UI 里做。

MCP Server 内置在 Phoenix 的 /mcp 路径上（beta，要求 19.0.0 以上），给没有 shell 的客户端用，比如 Claude Desktop。默认暴露七个 code-mode 工具：

工具	用途
search	按查询找可用操作，按相关度排序
tags	按类别浏览操作（projects、spans、datasets 等）
get_schema	调用前先取参数的 schema
execute	跑 Python，用 await call_tool(name, params) 串起多个操作
load_skill	加载某个 Phoenix skill 的说明再动手

目录是从 Phoenix 的 REST API 生成的，所以永远和你的 Phoenix 版本对齐。execute 跑在 Monty（Pydantic 的沙箱解释器）里，没有文件系统和网络，只允许 json、re、datetime 这样的受限标准库，subprocess、socket、importlib 和第三方包都被挡住；每次 execute 限制在 30 秒代码、100 MB、50 次操作调用、端到端 5 分钟。不放心让 Agent 写代码，可以把 PHOENIX_ENABLE_MCP_CODE_MODE=false 关掉，这样每个操作会变成一个独立工具。

Skills 是给编码 Agent 的领域知识包，Phoenix 自带五个：

Skill	作用
phoenix-cli	用 CLI 查 trace、实验、数据集和 prompt（推荐）
phoenix-error-analysis	抽样读 trace、写笔记，归成失败分类并排出修复优先级
phoenix-evals	写和跑评测器，覆盖代码评测和 LLM-as-judge
phoenix-tracing	按 OpenInference 约定实现 Python 和 TypeScript 埋点
phoenix-harbor	配置 Harbor Agent 评测并解读其 Phoenix 实验与分数

一条命令全装进 Agent 的 skills 目录（比如 .claude/skills/）：

npx -y @arizeai/phoenix-cli setup skills

它是个一次性拷贝，Phoenix 更新了要重跑才会拿到新版。团队想让 Agent 懂自己的约定，可以用 PHOENIX_SKILLS_PATHS 指向自己的 skill 目录，MCP server 会把它们和内置的一起提供。

选哪条路，官方的判断标准很干脆：Agent 能跑 shell 就用 CLI，你能看到每条命令、也能自己重跑；客户端没有终端就用 MCP；想让 Agent 系统性地按 Phoenix 的约定做事，就装 Skills。

7. 放进坐标系：Phoenix、AX 和另外两家

先把 Phoenix 和 AX 摆在一起，因为这是最容易被搞混的一对：

	Phoenix	Arize AX
是什么	开源的 Agent 开发与评测平台	托管的 AI 工程平台
怎么跑	自托管：你的笔记本、你的云、你的隔离网络	全托管 SaaS（商业许可下也支持自托管）
成本	免费使用	商业产品，有免费层
扩容	你的团队自己部署和扩	基础设施自动扩，Arize 托管
支持	社区支持	企业级支持和 SLA

AX 多出来的东西，恰好都是自托管做起来最累的部分：ADB（Arize 的数据库）、Signal（定时扫描 trace 并把反复出现的失败归成 issue 的内置 worker）、托管算力、面向多团队的工作区与组织、审计、给非开发者看的监控面板和告警，还有 HIPAA 和 SOC 2 这类认证。Phoenix 在能力上可以通过自己的 API 走通同样的流程，区别是算力得由你自己的基础设施团队提供和运维。

所以官方对「该选哪个」的回答不是二选一：先用 Phoenix 开发和早期生产，等企业侧的约束（支持、SLA、更多干系人的监控需求）出现时再迁到 AX，埋点原样带过去。反过来，已经在用 AX 的团队也常常留一个本地 Phoenix 用在 CI 流水线、隔离环境和内部实验上。

再放到 Langfuse、LangSmith 这些同类工具里看，Phoenix 的差异集中在两点。一是自托管的彻底程度：它能在最受监管、完全隔离网络的环境里跑，数据和基础设施都留在你自己的边界内，这在商业产品基本出局的场景里往往是唯一可行选项。二是埋点标准的通用性：它的 OpenInference 埋点同时服务于自家商业平台，意味着你选的不是「一个开源工具」，而是一套可以指向多个后端的标准。

至于谁在某个 benchmark 上更强、哪家对某个框架支持更全，得看你自己的技术栈和当时的官方文档，我不给没验证过的结论。

8. 什么时候别选 Phoenix

自托管省钱这件事是有前提的。

别选：团队里没人愿意接这套运维。Kubernetes 加 PostgreSQL 加升级跟版，都是持续投入；等这些成本超过省下来的授权费，免费就不免费了。文档里也点明了，Phoenix 跑生产没问题，真正的问题是「谁来运维这个平台」。

别选：你需要 Signal 那种自动把故障聚成 issue、还能直接开修复 PR 的能力。那是 AX 的实现，Phoenix 这边得自己用 API 拼出来，算力也得自己出。

别选：你需要一张 vendor 的合规证书交给审计。自托管的认证不来自 Arize，而是由你自己的环境承担——好处是数据根本不碰外部基础设施，代价是合规材料得自己准备。

别选：你想拿 Phoenix 做一个对外卖的托管服务。ELv2 在许可层面就禁止了这件事。

反过来，这几种情况它很合适：数据有明确的出境限制或者要跑在隔离网络里；预算敏感又需要完整的 tracing 加评测链路；想在 CI 里跑离线评测，让每次改 prompt 都过一遍固定数据集。这些场景里，Phoenix 给的是一套能自己读、自己改、自己扩的观测底座，而不是一份订阅。

---

参考文档与链接

• Arize Phoenix 官方文档首页 — 平台定位、四大能力模块、与 AX 的关系
• Start Phoenix — 端口、终端与容器启动、远程连接、编码 Agent 一键接入
• Observe（Tracing 快速开始） — Python / TypeScript 埋点示例与读 trace
• Evaluate（评测快速开始） — 数据集、LLM judge、双实验对比的完整代码
• Evaluation 总览 — 客户端与服务端两条路、tool calling 结构化输出、executors、评测器 trace
• Tracing 总览 — OTLP 接入、trace 能拿到哪些字段、Projects/Sessions/Annotations
• Datasets & Experiments — 数据集、实验、Dataset Evaluators 作为自动测试用例
• Prompts 总览 — Prompt Management、Playground、Span Replay、Prompts in Code
• PXI — 内置 Agent 的用法、会话锁与 409 错误码、审批模式、GitHub issue 集成
• Phoenix CLI — px setup 流程、CI 用法、退出码 6 的含义、写权限边界
• MCP Server — /mcp 七个 code-mode 工具、Monty 沙箱限制、各客户端接入
• Skills — 自带五个 skill 的职责、安装方式、自定义 skill 路径
• Self-Hosting — 部署选项、Docker tag、认证与 RBAC、数据保留、网络与隐私
• Integrations — 框架、模型厂商、语言、编码 Agent 的完整集成清单
• Phoenix 与 Arize AX 的区别 — 两平台对比表与迁移路径
• GitHub: Arize-ai/phoenix — 约 1.19 万 star，主语言 Python
• Elastic License 2.0 — Phoenix 采用的许可，含禁止作为托管服务转售的条款
• GitHub: Arize-ai/openinference — Phoenix 与 AX 共用的埋点标准

你的 Agent 观测数据现在放在谁那儿？评论区聊聊你的选择。觉得有用的话，点个赞让更多人看到。

---

作者: itech001
来源: 公众号：AI人工智能时代(the-ai-era)
网站: https://www.theaiera.top/ 关注每日最新AI新闻和技术博客，主页有更多的文章的AI 技术参考：https://www.theaiera.top

本文首发于 AI人工智能时代，转载请注明出处。