企业级Agent上线前必做6件事：可观测+评估全解析

AI Agent岗位的新门槛

随着大模型应用从实验室走向企业生产环境，招聘市场对AI工程师的要求正在快速升级。据B站技术UP主的分享，针对智能体（Agent）岗位的面试要求明显提高——单纯会用AI工具已经远远不够，能否定制化开发智能体并解决其上线后的工程化难题，才是拉开候选人差距的关键。

从原始分享中提炼，一个企业级Agent在正式上线前，通常需要解决以下六类核心问题：

• 流式输出中断问题：用户中途关闭页面时，流式输出可以停止，但完整的对话记录必须完整保留，不能丢失。流式输出（Streaming Output）是大模型应用中的核心交互模式，基于Server-Sent Events（SSE）或WebSocket协议实现。与传统的请求-响应模式不同，流式输出允许服务端将生成的Token逐个或分批推送给客户端，用户无需等待完整响应即可看到实时生成的内容。这种模式极大提升了用户体验，但也带来了工程复杂性：当用户中途关闭浏览器或切换页面时，HTTP连接断开，服务端需要优雅地处理这一中断——既要停止不必要的计算资源消耗，又要确保已生成的部分内容被完整持久化到数据库中，以便后续的对话上下文拼接和审计追溯。
• 高并发问题：如何让一个Agent支撑500到1000，甚至5000以上的并发访问。
• 多租户隔离问题：不同用户（如张三和李四）同时使用同一Agent时，其生成的临时文件、数据分析报告等必须做到数据隔离，互不可见。多租户隔离（Multi-tenancy Isolation）是SaaS和企业级应用的基础架构要求。在AI Agent场景中，多租户隔离不仅涉及传统的数据库行级隔离或Schema隔离，还涉及Agent运行时产生的临时文件（如数据分析生成的CSV、图表）、沙箱执行环境（如代码解释器的文件系统）以及向量数据库中的知识库分区。常见的实现方案包括：基于容器的进程级隔离、基于命名空间的文件系统隔离、以及基于租户ID的逻辑隔离。选择哪种方案通常取决于安全等级要求和性能开销的权衡。
• 大模型网关调用问题：DeepSeek、Kimi K2等模型存在限流风险，需要网关在超时或调用失败时自动切换到备用模型，避免Agent宕机。
• 可观测与日志追踪：能追踪Agent运行的每一个环节，知道它调了几次模型、消耗了多少Token、花了多少钱。
• 评估体系：提供人工标注+大模型评估的闭环，持续提高准确率、降低幻觉。

本文重点聚焦其中最热门的三块——追踪、可观测与评估，并以Langfuse这一开源平台为核心展开。

为什么企业选择Langfuse而非LangSmith

在智能体的追踪、可观测和评估这个方向，目前主流的选择有两个：一个是Langfuse，另一个是LangChain官方团队提供的LangSmith。据分享者从一线工作同学处收集的反馈，国内企业几乎清一色地采用了Langfuse。

数据隐私与合规性

第一个也是最关键的原因是数据隐私与合规。Langfuse采用MIT开源协议（与DeepSeek的开源协议同级别），几乎完全开源，无需担心版权问题。MIT协议是最宽松的开源许可证之一，由麻省理工学院创立，允许任何人免费使用、复制、修改、合并、发布、分发、再许可和/或销售软件的副本，唯一的条件是在所有副本中包含版权声明和许可声明。与GPL协议不同，MIT协议不要求衍生作品也必须开源，这使得企业可以基于MIT协议的项目进行二次开发并闭源商用——这也是国内企业偏爱MIT协议项目的根本原因。更重要的是，Langfuse所有的Trace和Token数据可以完全留存于企业内网，不与外网发生任何通信，无需许可证回传。

反观LangSmith，即便部署在企业内网服务器上，仍然需要定期联网验证许可证，且部分元数据要上报到LangChain的服务器。这对国内企业而言几乎是不可接受的——尤其在金融、政务、医疗等对数据主权有严格监管要求的行业中，任何形式的数据出网都可能违反《数据安全法》和《个人信息保护法》的相关条款。

商业模式的差异

第二个原因藏在商业模式里。LangChain团队的LangChain、LangGraph等开发框架都是开源的，而LangSmith恰恰是其唯一的主要盈利来源——它的核心计算引擎是闭源的，主要通过面向海外企业提供SaaS云服务收费。这就注定了它难以满足国内企业对私有化、内网部署的刚性需求。

值得补充的是，Langfuse在GitHub上的月下载量和安装量已达百万级别，在同类开源方案中处于绝对领先地位。

Langfuse与Agent的架构解耦

理解Langfuse的第一步，是理解它与Agent项目之间的解耦关系。

在整体架构中，企业自研的Agent项目（针对某条业务线开发的智能体）是一个独立的服务，而Langfuse则是另一个独立部署的服务器。两者之间通过Langfuse SDK进行数据通信，传递的核心数据就是Trace。这种架构设计遵循了微服务中的"关注点分离"原则——Agent专注于业务逻辑的执行，Langfuse专注于观测与评估，两者互不侵入，任何一方的故障都不会影响另一方的正常运行。

Langfuse自身包含一整套组件：提供给项目管理员使用的Web界面、用于存储数据的PostgreSQL、缓存数据库Redis、用于分析的ClickHouse，以及专门负责异步评估的Langfuse Worker。ClickHouse是由Yandex开发的开源列式数据库管理系统，专为在线分析处理（OLAP）场景设计，能够在数十亿行数据上实现亚秒级查询响应，非常适合存储和分析Agent运行过程中产生的海量Trace数据。与传统的行式数据库相比，ClickHouse在聚合查询、时序分析等场景下性能可提升数十甚至数百倍，这使得管理员可以对Agent表现进行多维度的实时数据分析，如按时间段统计Token消耗趋势、按模型版本对比准确率变化等。

这里的关键点在于——智能体的评估不是在Agent内部完成的，而是在Langfuse中由独立的Worker异步执行。评估打分后的结果存入ClickHouse，最终以分析面板的形式呈现给项目负责人，用于指导Agent的持续优化。

分享者在阿里云上实际租用了一台服务器（约250元/月），通过Docker Compose部署了包含Langfuse Web、Worker、PostgreSQL、Redis等六个容器的完整环境，验证了整套流程的可行性。

Trace、Observation与核心概念拆解

要用好Langfuse，必须先厘清几个基础概念。

Trace：一次完整的对话请求

Trace 表示智能体一次完整的请求，即一轮完整的问答，包含用户输入、最终输出、会话与版本信息。在Langfuse界面中，看到的每一条数据就是一个Trace。这一概念与分布式系统中的链路追踪（Distributed Tracing）思想一脉相承——正如Jaeger或Zipkin在微服务架构中追踪一个HTTP请求的完整调用链路一样，Langfuse中的Trace追踪的是一个用户问题在Agent内部经历的完整处理链路。

Observation：可观测的抽象层级

Observation 是对整个Trace内部工作过程的可观测抽象，它下面又细分为多种类型，其中最常见的是：

• Generation：一次模型调用，记录系统提示词、用户输入、模型输出以及调用耗时。
• Span：用户自定义的一段普通操作，比如把某个子智能体的运行标记为一个Span，包含起止时间。
• Tool：一次工具的使用。
• Event：一个事件节点。

每一次模型调用、工具使用、Span执行都会产生数据，这些数据通过SDK收集到Langfuse中，从而实现完整的追踪与可观测。分享者演示的财务分析Agent中，可以清晰看到：这次请求先做任务规划，再调用模型（耗时6.53秒），再调用各类工具（每个工具耗时清晰标注），并以树形结构图完整呈现每一步的执行链路。

Token统计与成本核算

Langfuse的一大实用价值在于成本可见。在配置界面中提前录入各模型的单价（如每百万输入/输出Token的价格），系统就能自动统计每一步、每一次请求消耗的Token数量，并换算出实际花费的金额。例如某次请求输入7163个Token、输出640个Token，合计消耗约0.006369元——精确到每一步。这一功能对企业而言意义重大：当一个Agent每天处理数万次请求时，不同Prompt策略、不同模型选择带来的成本差异可能从每月几百元拉大到数万元。精确的Token级成本核算使得工程团队能够量化每一次优化的ROI，为技术决策提供数据支撑。

Prompt治理与评估四阶段

提示词的集中化管理

分享者强调了一个企业级的最佳实践：将提示词托管到Langfuse，而非硬编码在项目代码中。

Langfuse提供了专门的Prompt Manager。Agent在运行时会动态调用加载函数，通过Label和名称从Langfuse拉取最新提示词。代码逻辑上做了双保险：如果开启了Langfuse且服务可用，就从平台拉取提示词；如果Langfuse服务中断，则回退到本地默认提示词。

这样做的好处极为明显：

• 无需改代码即可迭代提示词，修改后立即生效；
• 版本可回归，若某次修改后评估分数或响应时间变差，可一键回退到之前版本；
• 通过Trace数据观测提示词调整前后的分数与耗时变化，形成数据驱动的优化闭环。

这种将配置与代码分离的理念，本质上是软件工程中"配置即代码"（Configuration as Code）思想在AI领域的延伸。在传统软件开发中，我们通过Apollo、Nacos等配置中心管理应用配置；在AI Agent开发中，提示词就是最核心的"配置"——它决定了Agent的行为模式、输出质量和响应风格，其重要性远超普通的应用参数配置。

评估的四个阶段

企业级Agent的评估体系分为四个递进阶段：

1. 评分标准化：在Langfuse的Score Config中设定评估规则和用户反馈规则（分享者示例中设置了八条规则）。
2. 样本上传：上传评估样本数据（Golden Data），进行人工修正。
3. 人工标注闭环：针对具体Trace进行标注（通过界面的Annotation功能添加标注、加入数据集）。
4. 线上持续评估：由专门的评估大模型（Judge/裁判模型）根据前述人工规则、标注、标准答案，自动进行评估，并将结果反馈给Agent。

这里需要澄清一个常见误解：评估绝非让Agent自己审核自己。整个评估依赖大量人工参与——人需要在Langfuse中定义评估规则、提供错误样本、给出修正、进行标注。这种"人机协同"的评估模式借鉴了机器学习领域的"人在回路"（Human-in-the-Loop）思想：人类专家提供高质量的判断标准和边界案例，大模型负责将这些标准规模化地应用到海量Trace数据上。随着Agent运行时间增长、人工添加的规则与回归数据集越来越多，大模型评估的准确性也会越来越高，从而形成"运行越久越准确"的正向闭环。

高并发架构的工程思路

作为延伸，分享者还展示了同一项目中解决高并发的完整架构，其思路本质上是微服务化的横向扩展：

• 最前端使用负载均衡器（阿里云ALB或Nginx）分发流量；
• 流量进入多个SSE网关，网关记录请求来源，并将用户请求写入Redis消息队列；
• 从队列取出请求后，先进行限流、幂等、缓存判断。其中幂等性（Idempotency）是指同一操作执行一次和执行多次产生的效果完全相同，在Agent系统中尤为关键：由于网络抖动、超时重试等原因，同一个用户请求可能被重复提交，如果Agent的工具调用（如转账、发送邮件、数据写入）不具备幂等性，就会导致重复执行带来的严重后果。常见的幂等实现方式包括基于请求唯一ID的去重、数据库唯一约束以及分布式锁；
• 多个Agent Worker（worker1、worker2……workerN）作为消费者从队列中消费请求；
• 所有Worker共用同一套PostgreSQL，存储用户数据、Trace映射、LangGraph的Checkpoint、会话与长期记忆。LangGraph的Checkpoint机制是实现Agent状态持久化的核心功能——它会在Agent执行图（Graph）中每个节点完成后自动保存当前状态快照到外部存储中。这一机制使得不同的Worker可以接续处理同一个请求的不同阶段，实现了无状态Worker的横向扩展，同时在异常发生时可以从最近的Checkpoint恢复执行而无需从头开始；
• 处理结果一路以SSE事件流返回用户，另一路进入评估队列，由Evaluation Worker异步评估打分。

其扩展逻辑非常直接：单个Worker并发能力约200，10个Worker即可支撑2000并发，理论上只要增加Worker数量就能线性提升并发能力。同理，Langfuse本身也是分布式部署，可以通过增加Langfuse Worker节点来扩容。需要注意的是，这种线性扩展能力的前提是下游依赖（数据库、Redis、大模型API）不成为瓶颈——在实际生产中，通常还需要配合数据库读写分离、Redis集群化、以及大模型API的多Key轮询策略来保证整体系统的弹性。

总结

这份实战分享的核心价值，在于揭示了一个Agent从"能跑通Demo"到"能上线运营"之间的巨大工程鸿沟。可观测、日志追踪、Prompt治理、评估体系、Token统计——这些看似琐碎的工程环节，恰恰是AI工程师面试的核心考点，也是企业智能体真正能够持续迭代、降低幻觉、提升准确率的基石。而Langfuse凭借其MIT开源、内网自托管、数据不出网的特性，已成为国内企业在这一方向上近乎唯一的主流选择。