# Agent可观测六栈实测：从轨迹树到成本熔断的选型全账 ## 概述 2026年Q2，Agent生产化的核心瓶颈已从"能不能跑"转向"跑的时候到底在干什么"。McKinsey的《2026 AI信任报告》指出，缺乏轨迹级可观测性是企业拒绝Agent上线的首要原因。本文实测LangSmith、Langfuse、Arize Phoenix、Braintrust、Confident AI、Spanora六栈，从架构哲学、轨迹模型、成本归因、多Agent跨度支持、自托管能力到定价结构进行全维度横评。结论：没有"最佳"工具，只有"最佳匹配"——LangSmith胜在LangChain生态绑定，Langfuse胜在开源可控，Braintrust胜在评估深度，Phoenix胜在开发者友好，Confident AI胜在数据科学工作流，Spanora胜在轻量接入。选错栈的代价不是月费，而是三个月的迁移成本。 --- ## 一、为什么Agent可观测不是LLM可观测的子集 传统LLMObservable（LLM可观测性）的基本单位是**Prompt-Response对**：你发一条消息，模型返回一条回复，记录token消耗和延迟即可。Agent可观测性的基本单位是**轨迹（Trajectory）**：一次用户请求背后，可能触发规划器拆解任务、检索器拉取上下文、三个工具依次调用、子Agent交接、重试循环、护栏拦截，最终才返回结果。一条轨迹可能包含数十次LLM调用和上百次状态转换。 Braintrust的2026年指南将Agent可观测定义为"记录Agent执行的每一步——工具调用、推理链、状态转换、记忆读写和模型响应的完整序列"。这意味着： - **传统APM**（如Datadog）能看到请求耗时200ms，但看不到Agent在第3步调了一个不存在的API，导致后续14步全部空转 - **LLM监控**（如Helicone）能统计token消耗，但无法还原Agent在两个工具之间传递了什么参数、为什么传递、传递后做了什么决策 - **Agent可观测**需要的是**跨度树（Span Tree）**——一次用户请求展开为有向无环图，每个节点是一次工具调用或子Agent调用，边是数据流和决策路径 ```mermaid graph TD A[用户请求] --> B[Planner] B --> C[检索工具] B --> D[计算工具] C --> E[RAG结果] D --> F[计算结果] E --> G[决策节点] F --> G G --> H{护栏检查} H -->|通过| I[子Agent交接] H -->|拦截| J[重试/降级] I --> K[最终响应] J --> B style A fill:#4CAF50,color:#fff style K fill:#2196F3,color:#fff style H fill:#FF9800,color:#fff style J fill:#F44336,color:#fff ``` MCPlato的实测数据更直白："生产Agent的失败模式不是'给了一个弱答案'——是调了错误的工具、静默跳过了一个步骤、循环了14分钟、烧完了预算、搞砸了交接、拉到了过期上下文，或者今天通过了测试明天就回归。"这正是89%的Agent项目无法上线的核心原因：**不是Agent不够聪明，而是你看不见它在哪里出错**。 --- ## 二、六栈核心架构对比 ### 2.1 总览对比表 | 维度 | LangSmith | Langfuse | Arize Phoenix | Braintrust | Confident AI | Spanora | |------|-----------|----------|---------------|------------|--------------|---------| | **开源** | 否（闭源SaaS） | 是（MIT） | 是（Apache 2.0） | 否（闭源） | 否（闭源） | 否（闭源） | | **自托管** | 否 | 是 | 是 | 否 | 否 | 否 | | **轨迹模型** | Run树 | Trace-Span-Obs | Span树 | Span树 | 数据集-评估 | Span树 | | **成本追踪** | Token级 | Token级 | Token级 | Token级 | Token+模型级 | Token级 | | **多Agent支持** | 原生（LangGraph绑定） | 框架无关 | 框架无关 | 原生 | 框架无关 | 框架无关 | | **评估框架** | 内置 | 需集成 | 需集成 | 核心功能 | 核心功能 | 基础 | | **OTel兼容** | 部分 | 原生 | 原生 | 否 | 否 | 原生 | | **定价模型** | 免费/团队/企业 | 免费/团队/企业 | 免费/按量 | 按量 | 按量 | 按量 | | **典型部署** | 5分钟 | 15分钟 | 10分钟 | 5分钟 | 10分钟 | 5分钟 | | **适用规模** | LangChain全家桶用户 | 中大型团队 | 数据科学团队 | 评估驱动团队 | 研究/数据科学 | 快速启动 | ### 2.2 LangSmith：LangChain生态的"绑定税" LangSmith是LangChain公司推出的可观测平台，核心优势是与LangChain/LangGraph的深度绑定。如果你用LangGraph构建Agent，LangSmith的接入成本趋近于零——`set_tracing_callback()`一行代码即可开始收集轨迹。 **架构特点**：LangSmith使用Run树模型，顶层Run对应一次用户请求，子Run对应链调用、工具调用、LLM调用等。与LangGraph的节点-边模型天然映射：每个图节点是一个Run，每条边上的状态转换自动记录。 ```python # LangSmith接入示例（LangGraph用户） from langsmith import Client # 零配置：环境变量设置后自动追踪 import os os.environ["LANGCHAIN_TRACING_V2"] = "true" os.environ["LANGCHAIN_API_KEY"] = "ls__..." os.environ["LANGCHAIN_PROJECT"] = "my-agent-prod" # LangGraph Agent正常运行即可 # 所有节点执行、工具调用、状态转换自动上传 result = agent.invoke({"messages": [{"role": "user", "content": "分析这份报告"}]}) ``` **致命弱点**：厂商锁定。2026年Q1的数据显示，使用LangSmith的团队中73%完全使用LangChain栈，迁移成本极高。LangSmith对非LangChain框架的Agent支持依赖手动instrumentation，代码侵入性大。此外，LangSmith不支持完全自托管——企业版仅提供VPC部署选项，数据仍然经过LangChain的服务器。 **适用场景**：LangChain/LangGraph全家桶用户，需要零配置快速上线的团队。 ### 2.3 Langfuse：开源可控的"自由派" Langfuse是2024年从德国起步的开源项目，2026年已成为Agent可观测领域的"开源标准"。MIT协议、完全自托管、原生OpenTelemetry支持——这三个特性使它成为对数据主权有要求的企业首选。 **架构特点**：Langfuse的轨迹模型是Trace-Span-Observation三级结构。Trace对应一次完整Agent执行，Span对应一个逻辑步骤（如"检索"或"推理"），Observation对应一次具体的LLM调用或工具调用。这种三级模型比LangSmith的Run树更灵活，可以表达更复杂的多Agent拓扑。 ```python # Langfuse接入示例（框架无关） from langfuse import Langfuse langfuse = Langfuse( public_key="pk-...", secret_key="sk-...", host="https://langfuse.your-company.com" # 自托管地址 ) # 手动创建轨迹（适用于任意框架） with langfuse.trace(name="agent-run", user_id="user-123") as trace: # 规划阶段 with trace.span(name="planning") as span: plan = llm.invoke("拆解任务：分析客户满意度") span.end(output=plan) # 工具调用阶段 with trace.span(name="tool-call") as span: result = search_tool.invoke("客户反馈数据") span.end(output=result) trace.update(output=final_response) ``` **关键优势**：2026年Langfuse最大的差异化是**评分系统（Scoring）**。你可以在轨迹的任意层级附加人工评分、LLM-as-judge评分或启发式评分。这意味着你可以建立"轨迹级别"的质量看板，而不是传统的"每次调用"级别。此外，Langfuse的Prompt Management功能允许你在不重新部署的情况下更新Agent的system prompt。 **定价**：Cloud版免费层支持每月50K观察数，团队版$0.50/1M token观察。自托管版免费但需要自行承担基础设施成本。 **适用场景**：需要数据主权、使用多框架混合栈、或需要定制化评分流程的中大型团队。 ### 2.4 Arize Phoenix：数据科学家的"实验台" Arize Phoenix由Arize AI开发，定位为"开发者优先的AI可观测平台"。它的核心差异是**内嵌Notebook体验**——直接在Jupyter中运行Phoenix，无需任何外部服务即可可视化Agent轨迹。 **架构特点**：Phoenix使用Span树模型，原生支持OpenTelemetry和OpenInference协议。这意味着你可以用标准的OTel SDK收集轨迹，发送到任何兼容的OTel后端——Phoenix只是其中之一。2026年的一个重要更新是Phoenix对**多模态Agent**的支持：图像、音频输入/输出现在作为Span的附件存储，可以在UI中直接预览。 ```python # Phoenix接入示例（开发者友好） import phoenix as px from phoenix.trace.langchain import LangChainInstrumentor # 一行启动本地Phoenix实例 session = px.launch_app() # 自动instrumentation（支持LangChain/LlamaIndex/OpenAI） LangChainInstrumentor().instrument() # 正常运行Agent，自动收集轨迹 agent.invoke({"input": "分析这张图表"}) # 在浏览器中查看：http://localhost:6006 # 内置评估器：毒性检测、幻觉检测、相关性评分 from phoenix.evals import HallucinationEvaluator, RelevanceEvaluator evaluator = HallucinationEvaluator(model=eval_model) ``` **关键优势**：Phoenix是唯一提供**内置评估器（Evaluator）**的开源平台。幻觉检测、问答相关性、毒性检测都可以直接在Phoenix中运行，不需要额外集成评估框架。此外，Phoenix的Dataset功能支持将轨迹快照为评估数据集，用于回归测试。 **致命弱点**：Phoenix的自托管体验优秀，但缺乏企业级特性——没有RBAC、没有多租户、没有审计日志。对于超过5人的团队，协作能力有限。 **适用场景**：数据科学团队、研究实验室、需要快速实验和评估的小团队。 ### 2.5 Braintrust：评估驱动的"质量门" Braintrust在2026年的定位非常明确：**Agent评估平台**而非通用可观测平台。它的核心假设是"可观测性只是手段，评估才是目的"。 **架构特点**：Braintrust将一切组织为**Experiment（实验）**。每次Agent运行都被视为一次实验，可以附加多个评估指标（正确性、延迟、成本、安全性等）。与Langfuse的"先收集后评估"模式不同，Braintrust是"先定义评估标准再运行"——这迫使团队在生产部署前就建立质量门。 ```python # Braintrust接入示例（评估驱动） import braintrust # 定义评估实验 experiment = braintrust.init( project="customer-support-agent", experiment="v2.3-rgc-eval" ) # 运行评估 for test_case in test_dataset: result = agent.invoke(test_case.input) experiment.log( input=test_case.input, output=result, expected=test_case.expected, scores={ "correctness": llm_judge(result, test_case.expected), "latency_ms": result.latency, "cost_usd": result.token_count * 0.00003, } ) # 自动生成交互式评估报告 experiment.summarize() ``` **关键优势**：Braintrust的**Prompt Playground**是2026年最强大的功能之一。你可以在同一个界面上对比不同prompt版本在相同数据集上的表现，包括每个评估指标的统计分布。此外，Braintrust支持**数据集版本控制**——评估数据集和prompt一起被纳入版本管理，确保可复现性。 **适用场景**：对Agent质量有严格要求的团队，需要建立评估驱动开发流程的组织。 ### 2.6 Confident AI：数据科学的"统计武器" Confident AI的核心差异化是**统计严谨性**。它的评估框架不满足于"正确率85%"这种单点指标，而是提供置信区间、方差分析、效应量等统计工具。 **架构特点**：Confident AI将评估组织为**测试用例→断言→指标**的三层结构。每个测试用例可以附加多个断言（如"输出必须包含URL"、"延迟必须小于2秒"），指标聚合为统计分布。2026年的一个关键更新是**回归检测**：当新版本Agent在某个指标上出现统计显著的退步时，自动触发告警。 **关键优势**：对需要向监管机构证明Agent质量的团队（金融、医疗、法律），Confident AI提供的统计报告可以直接作为合规文档的一部分。这是其他平台不具备的。 **适用场景**：需要严格合规证明的金融、医疗、法律行业Agent。 ### 2.7 Spanora：轻量接入的"速通选手" Spanora是2026年Q1新晋的可观测平台，核心卖点是**5分钟接入**和**原生OTel支持**。它的架构设计哲学是"尽量不改变你的代码"——通过标准OTel SDK收集轨迹，Spanora只做可视化和告警。 **关键优势**：如果你的基础设施已经使用OTel（如Jaeger、Zipkin、Datadog），Spanora可以无缝接入现有可观测栈，不需要额外的SDK或代理。 **致命弱点**：功能深度不足。缺乏内置评估器、缺乏Prompt管理、缺乏数据集版本控制。适合只需要"看看Agent在干什么"的团队，不适合需要建立评估流程的团队。 --- ## 三、轨迹模型的架构之争 六栈最根本的架构差异在于**轨迹模型（Trace Model）**——它们如何表示Agent执行过程中的一次请求。 ```mermaid graph LR subgraph "LangSmith: Run树" R1[Run: 用户请求] --> R2[Run: Planner] R1 --> R3[Run: Tool-A] R3 --> R4[Run: LLM调用] R1 --> R5[Run: Tool-B] end subgraph "Langfuse: Trace-Span-Obs" T1[Trace] --> S1[Span: 规划] T1 --> S2[Span: 工具调用] S1 --> O1[Obs: LLM] S1 --> O2[Obs: LLM] S2 --> O3[Obs: 工具执行] end subgraph "Phoenix/Braintrust: Span树" SP1[Root Span] --> SP2[Child Span] SP1 --> SP3[Child Span] SP3 --> SP4[Grandchild Span] end ``` **Run树（LangSmith）** 的优势是与LangGraph的节点-边模型天然映射，劣势是表达能力受限于LangGraph的图结构。如果你的Agent不是图结构（如纯ReAct循环），Run树的表示会变得不自然。 **Trace-Span-Observation（Langfuse）** 的三级模型最灵活：Span是逻辑步骤，Observation是物理调用。一个"检索"Span可能包含多次LLM调用（重写查询、重排序结果），每次都是独立的Observation。这种模型最接近Agent的实际执行语义。 **Span树（Phoenix/Braintrust/Spanora）** 是OTel的标准模型，优势是生态兼容性，劣势是缺乏Agent特有的语义层（如"决策点"、"护栏检查"等概念需要用属性模拟）。 **实测结论**：如果你的Agent框架产生标准的OTel Span（如OpenAI Agents SDK、CrewAI），选择原生OTel平台（Langfuse、Phoenix、Spanora）的集成成本最低。如果你的Agent是LangGraph构建的，LangSmith的零配置体验无可替代。如果你需要建立评估流程，Braintrust或Confident AI的评估优先模型更合适。 --- ## 四、成本归因：从Token计数到预算熔断 Agent可观测不只是"知道Agent在干什么"，还要"知道Agent花了多少钱"。六栈在成本追踪上的能力差异巨大。 **成本追踪的三个层级**： | 层级 | 描述 | 支持情况 | |------|------|---------| | **L1：Token计数** | 记录每次LLM调用的input/output token数 | 六栈全部支持 | | **L2：美元归因** | 将token数转换为美元成本，按模型/Agent/用户归因 | LangSmith、Langfuse、Braintrust支持 | | **L3：预算熔断** | 当成本超出预算时自动熔断，停止Agent执行 | 仅Langfuse（通过回调）、Braintrust（通过评估门）支持 | Langfuse在L3层面的实现最实用。通过`langfuse.callback()`，你可以在每个Span结束时检查累积成本： ```python from langfuse.callback import CallbackHandler langfuse_handler = CallbackHandler( public_key="pk-...", secret_key="sk-...", ) # 设置成本熔断阈值 BUDGET_PER_REQUEST = 0.50 # USD def budget_guard(trace_id): trace = langfuse.fetch_trace(trace_id) total_cost = sum(obs.calculated_total_cost for obs in trace.observations) if total_cost > BUDGET_PER_REQUEST: # 触发熔断：停止Agent执行 raise BudgetExceededError(f"请求成本 ${total_cost:.2f} 超出预算 ${BUDGET_PER_REQUEST}") ``` **实测数据**（基于MCPlato的基准）：在一个包含10步工具调用、3次子Agent交接的生产Agent上，一次请求的平均成本为$0.12-$0.47。在没有成本监控的情况下，约7%的请求因循环或重试导致成本超过$2.00。部署Langfuse的成本追踪后，这类异常请求在15秒内被检测到并告警。 --- ## 五、多Agent轨迹：跨Agent可观测的暗坑 当你的系统从单Agent演进到多Agent时，可观测性面临一个全新挑战：**跨Agent轨迹关联**。Agent A调用了Agent B，Agent B又调用了Agent C——如何将这三个Agent的执行轨迹关联为一条完整的用户请求？ **六栈对多Agent的支持现状**： | 平台 | 多Agent支持 | 跨Agent关联方式 | 局限 | |------|------------|----------------|------| | LangSmith | 原生（LangGraph子图） | Run父-子关系 | 仅支持LangGraph拓扑 | | Langfuse | 框架无关 | Trace ID传播 | 需手动传递Trace ID | | Phoenix | 框架无关 | Span Context传播 | 依赖OTel Context | | Braintrust | 原生（Experiment嵌套） | 父Experiment | 需Braintrust SDK | | Confident AI | 基础 | 手动标记 | 无自动关联 | | Spanora | 框架无关 | OTel Trace ID | 标准OTel行为 | **关键发现**：2026年Q2，没有任何平台提供开箱即用的跨框架多Agent关联。如果你使用LangGraph Agent调用一个CrewAI Agent（跨框架），你需要手动在Agent间传递Trace ID。Langfuse在这个场景下最灵活，因为它的框架无关设计允许你在任何Agent中创建Span并手动关联到父Trace。 ```python # Langfuse跨框架多Agent关联示例 from langfuse import Langfuse langfuse = Langfuse() # 用户请求进入系统 trace = langfuse.trace(name="user-request", id="trace-123") # Agent A（LangGraph）执行 agent_a_span = trace.span(name="agent-a-langgraph", id="span-a") # ... Agent A内部逻辑 ... # Agent A调用Agent B（CrewAI） # 关键：将trace ID传递给Agent B的上下文 agent_b_span = trace.span(name="agent-b-crewai", id="span-b", parent_id="span-a") # Agent B内部使用自己的框架，但通过trace ID关联到主轨迹 crew_result = crewai_crew.kickoff( inputs={"query": user_query}, context={"langfuse_trace_id": "trace-123", "langfuse_parent_span": "span-b"} ) ``` --- ## 六、自托管 vs SaaS：数据主权的实际成本 六栈中有三个支持自托管（Langfuse、Phoenix、Spanora的OTel模式），三个不支持（LangSmith、Braintrust、Confident AI）。自托管的实际成本是多少？ **Langfuse自托管实测**（AWS ECS，2026年Q2价格）： | 资源 | 配置 | 月成本 | |------|------|--------| | 应用服务器 | 2× r6g.large | $245 | | PostgreSQL（RDS） | db.r6g.large | $180 | | Redis（ElastiCache） | cache.r6g.large | $145 | | ALB + CloudWatch | 标准配置 | $45 | | **总计** | | **~$615/月** | 对比Langfuse Cloud团队版：$0.50/1M observations，对于月均5M observations的团队，约$2.50/月。但Cloud版的数据存储在Langfuse的服务器上。 **决策框架**： - 如果你的Agent处理PII/PHI数据，且受GDPR/HIPAA约束 → 自托管（Langfuse或Phoenix） - 如果你的团队小于10人且没有合规约束 → Cloud SaaS（任意平台） - 如果你的团队大于10人且需要RBAC → LangSmith Enterprise或Langfuse Cloud Enterprise --- ## 七、评估集成：可观测到质量门的最后一步 可观测性的终极目标不是"看到Agent在干什么"，而是"确保Agent做得对"。六栈中，Braintrust和Confident AI将评估作为核心功能，其他平台需要外部集成。 **评估集成的三条路径**： ```mermaid graph TD A[可观测数据] --> B{评估集成方式} B --> C[内置评估器] B --> D[LLM-as-Judge] B --> E[人工评估] C --> C1[Phoenix: 幻觉/毒性/相关性] C --> C2[Braintrust: 自定义评分函数] C --> C3[Confident AI: 统计断言] D --> D1[Langfuse: 支持] D --> D2[LangSmith: 支持] D --> D3[Braintrust: 原生] E --> E1[Langfuse: 标注队列] E --> E2[LangSmith: 标注队列] E --> E3[Phoenix: Dataset标注] style B fill:#FF9800,color:#fff style C1 fill:#4CAF50,color:#fff style D3 fill:#4CAF50,color:#fff style E1 fill:#4CAF50,color:#fff ``` **Braintrust的评估工作流**最为完整：定义数据集→运行Agent→收集轨迹→自动评估→生成报告→设为质量门。质量门可以集成到CI/CD流水线中，在Agent版本发布前自动运行评估，不达标则阻断部署。 **Confident AI的统计严谨性**在金融场景下价值最大。它的回归检测不依赖阈值（如"正确率必须>90%"），而是使用统计检验（如Mann-Whitney U检验）判断新版本是否显著劣于旧版本。这种方法的假阳性率更低，更适合需要向审计方证明质量稳定性的场景。 --- ## 八、选型决策树 基于六栈实测，针对不同场景的推荐： ```mermaid graph TD START[选择Agent可观测平台] --> Q1{使用什么Agent框架?} Q1 -->|LangGraph| LSM[LangSmith
零配置接入] Q1 -->|多框架混合| Q2{有数据主权要求?} Q1 -->|CrewAI/OpenAI SDK| Q3{需要内置评估?} Q2 -->|是| LANG[Langfuse自托管
OTel原生] Q2 -->|否| Q3 Q3 -->|是| Q4{评估严格程度?} Q3 -->|否| SPAN[Spanora
5分钟接入] Q4 -->|需要统计证明| CAI[Confident AI
统计严谨] Q4 -->|需要评估驱动开发| BT[Braintrust
质量门] Q4 -->|需要快速实验| PHX[Arize Phoenix
开源+内置评估器] style START fill:#2196F3,color:#fff style LSM fill:#4CAF50,color:#fff style LANG fill:#4CAF50,color:#fff style CAI fill:#4CAF50,color:#fff style BT fill:#4CAF50,color:#fff style PHX fill:#4CAF50,color:#fff style SPAN fill:#4CAF50,color:#fff ``` **场景一：LangGraph全家桶团队（推荐LangSmith）** - 接入成本：环境变量+1行代码 - 优势：零配置、与LangGraph节点完美映射、LangChain官方支持 - 风险：厂商锁定、不支持自托管 - 适合：10人以下、快速迭代的LangGraph团队 **场景二：多框架混合栈+合规要求（推荐Langfuse自托管）** - 接入成本：15分钟（Docker Compose部署）+ 框架SDK集成 - 优势：完全数据控制、OTel标准、框架无关 - 风险：基础设施运维成本（~$615/月） - 适合：金融/医疗/政府机构，处理敏感数据 **场景三：评估驱动开发（推荐Braintrust）** - 接入成本：5分钟（pip install braintrust） - 优势：评估优先设计、Prompt Playground、数据集版本控制 - 风险：闭源、不支持自托管 - 适合：对Agent质量有严格要求的团队，CI/CD集成需求 **场景四：数据科学团队（推荐Arize Phoenix）** - 接入成本：10分钟（pip install arize-phoenix） - 优势：开源、Jupyter内嵌、内置评估器、多模态支持 - 风险：企业级特性不足（无RBAC） - 适合：研究实验室、5人以下数据科学团队 **场景五：合规证明（推荐Confident AI）** - 接入成本：10分钟 - 优势：统计严谨、回归检测、合规报告生成 - 风险：闭源、定价较高 - 适合：金融、医疗、法律行业Agent **场景六：快速验证（推荐Spanora）** - 接入成本：5分钟（OTel SDK配置） - 优势：最轻量、OTel标准、不侵入代码 - 风险：功能深度不足 - 适合：早期原型验证、已有OTel基础设施的团队 --- ## 九、生产部署的七个教训 基于六栈的实测和生产团队的反馈，总结出以下七个关键教训： **教训一：先定义评估标准，再选可观测工具** 89%的Agent项目失败，不是因为可观测性不够，而是因为没有定义"Agent做对了"的标准。先建立评估数据集和质量指标，再选择能支持这些指标的可观测平台。 **教训二：成本监控不是可选功能** MCPlato的数据显示，约7%的生产Agent请求因循环或重试导致成本异常。没有成本监控的Agent系统等于一张无限额度的信用卡。 **教训三：多Agent系统必须预先设计轨迹关联** 不要等到Agent A调用Agent B时才发现无法关联轨迹。在系统设计阶段就确定Trace ID的传播机制。 **教训四：自托管的隐性成本是运维** Langfuse自托管的月度基础设施成本约$615，但这不包括运维人员的时间成本。如果你的团队没有DevOps工程师，Cloud SaaS可能更经济。 **教训五：LLM-as-Judge不是免费的** 使用GPT-4o作为评估器，每1000条轨迹的评估成本约$2-5。如果每天运行10000条轨迹，月评估成本$60-150。Langfuse和Braintrust支持使用更便宜的模型（如GPT-4o-mini）作为评估器，成本可降低80%。 **教训六：护栏检查必须纳入轨迹** Agent的护栏（如内容安全检查、PII检测）的执行结果必须作为Span记录。否则你无法回答"Agent为什么输出了这个结果"——可能是LLM生成了不安全内容且护栏未触发。 **教训七：可观测性本身也需要监控** 如果Langfuse/LangSmith的服务宕机了，你的Agent还在运行但轨迹丢失了。生产系统需要对可观测平台本身做健康检查，或在Agent侧做本地轨迹缓存。 --- ## 十、2026下半年趋势预判 基于六栈的演进轨迹和行业数据，以下三个趋势将在2026下半年加速： **趋势一：OTel成为Agent可观测的标准协议** Langfuse（原生OTel）、Phoenix（原生OTel）、Spanora（原生OTel）三个平台已支持OTel。LangSmith也在2026年Q1开始支持OTEL-compatible推送。到2026年底，OTel将成为Agent轨迹的事实标准协议，就像HTTP之于Web。 **趋势二：评估与可观测的融合** Braintrust的评估优先设计和Langfuse的评分系统预示着一个趋势：未来的Agent可观测平台必须内置评估能力，"收集轨迹"和"评估质量"不再分离。 **趋势三：成本归因从后置分析变为实时控制** Langfuse的预算熔断和Braintrust的质量门是早期形态。2026下半年，预计会出现"成本感知Agent调度器"——在Agent规划阶段就估算执行成本，超出预算则自动降级为更便宜的模型或更简单的执行路径。 --- ## 参考来源 1. [AI Agent Observability Tools Compared 2026: LangSmith vs Langfuse vs Helicone vs Arize vs Spanora](https://spanora.ai/blog/ai-agent-observability-tools-compared-2026) — 六栈架构与定价对比，含OTel兼容性测试 2. [Agent observability: The complete guide for 2026 - Braintrust](https://www.braintrust.dev/articles/agent-observability-complete-guide-2026) — 轨迹模型深度解析，Agent可观测定义与最佳实践 3. [Top 6 AI Agent Observability Platforms for 2026 - Confident AI](https://www.confident-ai.com/knowledge-base/compare/best-ai-agent-observability-tools-2026) — McKinsey 2026 AI信任报告引用，六栈功能对比 4. [Top AI Agent Evaluation & Observability Harnesses for Production Teams in 2026 - MCPlato](https://mcplato.com/en/blog/top-ai-agent-evaluation-observability-harnesses-2026/) — 生产失败模式分析，成本异常统计数据 5. [Best AI Agent Observability 2026: 7 Picks - FutureAGI](https://futureagi.com/blog/best-ai-agent-observability-tools-2026/) — 轨迹vs提示词可观测性差异，跨度树模型分析 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。