Acrux Core：开源LLM可观测性平台，自托管替代LangSmith

当LLM应用遇上可观测性难题

在构建AI应用的过程中，许多开发者都遭遇了同一个反复出现的痛点：LLM可观测性（Observability）与提示词管理（Prompt Management）。随着调用量增长，这个问题会变得越来越棘手。

LLM可观测性借鉴了传统分布式系统中的可观测性三大支柱——日志（Logs）、指标（Metrics）和追踪（Traces），但针对大语言模型的非确定性特征做了重要适配。在传统软件中，给定相同输入通常会得到相同输出，调试相对直观；而LLM的输出具有随机性，同一提示词在不同时间可能产生截然不同的结果。因此，LLM可观测性不仅需要记录输入输出对、Token消耗和延迟等基础指标，还需要追踪提示词版本、模型参数（如temperature、top_p）、上下文窗口内容等与生成质量直接相关的维度。这一领域在2023-2024年间快速成熟，已被视为AI工程化（AI Engineering）的关键基础设施层。

值得一提的是，传统可观测性领域（以Datadog、New Relic、Grafana为代表）经过十余年发展已形成成熟的技术栈——OpenTelemetry成为事实标准的遥测数据采集协议，Prometheus+Grafana成为指标监控的经典组合。然而LLM应用的可观测性需求与传统Web服务存在本质差异：传统服务关注的是"是否正常工作"（可用性、延迟、错误率），而LLM应用还需要回答"输出质量是否合格"这一更主观的问题。这种差异催生了LangSmith、Langfuse、Helicone等专门针对LLM场景的可观测性工具的兴起。

更具体地说，OpenTelemetry（简称OTel）是CNCF（云原生计算基金会）旗下的顶级项目，它定义了一套厂商中立的API、SDK和数据格式，用于生成、收集和导出遥测数据。在传统微服务架构中，OTel能够自动捕获HTTP请求的生命周期、数据库查询耗时、跨服务调用的因果关系等信息。但当我们尝试将同样的框架应用于LLM调用时，会发现诸多不适配之处：LLM调用的"Span"不仅需要记录耗时和状态码，还需要携带提示词全文、模型输出、Token计数、采样参数等语义丰富的属性，而这些属性的体积和敏感性都远超传统Web请求的元数据。这也是为什么专用的LLM可观测性工具应运而生——它们在数据模型层面就为LLM场景做了原生设计。

据项目作者在Reddit上的分享，现有的工具大多存在三类明显缺陷：

• 重量级SaaS平台成本高企：随着调用量攀升，费用会快速膨胀，中小团队难以承受。
• 提示词迭代不灵活：想要动态调整提示词，往往需要重新部署后端代码，迭代周期被拖长。
• 工具与提示词绑定僵化：无法在不改动代码的情况下，将任意工具与任意提示词自由组合，使提示词更具「Agent化」能力。

正是为了解决这些问题，作者构建了 Acrux Core——一个面向希望完全掌控自身遥测数据与工作流的开发者的开源平台。它同时提供了LLM可观测性、工具目录（Tool Catalog）以及提示词管理三大能力。

Acrux Core 的核心功能详解

Acrux Core 定位为 LangSmith 与 Langfuse 的开源替代方案，主打自托管与数据主权。其功能设计紧扣实际开发中的痛点。

提示词管理与动态绑定

Acrux Core 允许开发者直接在仪表盘中编辑与版本化管理提示词。这意味着提示词的迭代不再依赖后端代码的重新部署，产品经理或运营人员也能参与提示词的优化。

提示词管理的核心挑战在于，提示词本质上是一种介于代码和配置之间的特殊产物。在早期原型阶段，开发者通常将提示词硬编码在应用代码中；但随着应用走向生产，提示词需要频繁迭代——有时一天内就需要调整多次以应对边界情况。如果每次修改都需要走完整的CI/CD流程，迭代效率将大打折扣。成熟的提示词管理系统通常需要支持版本控制（类似Git的diff和回滚能力）、A/B测试、环境隔离（开发/预发/生产）以及权限管理（让非技术人员也能安全地参与优化）。

在实践中，提示词的迭代频率远高于普通代码。据多家AI应用团队的经验分享，生产环境中的核心提示词在产品早期可能每周迭代数十次，而每次迭代的验证成本也显著高于普通代码变更——因为你无法通过确定性的单元测试来保证修改后的效果，而需要在一批有代表性的测试用例上评估输出质量。这就要求提示词管理平台不仅能做版本控制，还要能支持对比不同版本在同一数据集上的表现，即所谓的"Prompt Evaluation"能力。这种评估通常结合自动化指标（如BLEU、ROUGE用于翻译/摘要场景，或基于LLM-as-Judge的评分方式）和人工抽检，形成多层次的质量保障体系。业界已经出现了诸如"Eval-Driven Development"的方法论，强调先定义评估标准和测试集，再进行提示词优化——这与测试驱动开发（TDD）的精神一脉相承。

更值得关注的是它的动态绑定机制：你可以从工具目录中直接把工具挂载到提示词上，而无需在应用代码里硬编码执行流程。这一设计让提示词天然具备「Agent化」的潜力——工具与提示词的组合关系被抽象到平台层面，大幅降低了构建智能体应用的耦合度。

工具目录（Tool Catalog）的概念源自LLM Agent架构中的"工具调用"（Tool Use/Function Calling）范式。在这一范式中，LLM不再仅仅生成文本，而是能够决定何时调用外部工具（如搜索引擎、数据库查询、API调用等）来完成任务。OpenAI的Function Calling、Anthropic的Tool Use都是这一能力的具体实现。传统做法是在代码中硬编码工具定义和调用逻辑，这意味着每增加一个工具或调整工具与提示词的组合关系，都需要修改代码并重新部署。将工具定义抽象为"目录"并支持动态绑定，本质上是在做声明式的Agent编排——开发者只需声明"这个提示词可以使用哪些工具"，而非命令式地编写调用流程。

这种声明式的工具编排思路与当前Agent框架的演进方向高度一致。从LangChain的早期链式调用，到AutoGPT/CrewAI等框架的任务分解，再到近期MCP（Model Context Protocol）协议的提出，行业正在逐步标准化LLM与外部工具的交互方式。MCP协议由Anthropic在2024年底提出，旨在为LLM应用提供一种标准化的方式来连接各种数据源和工具——类似于USB-C为硬件设备提供统一接口。在MCP架构中，工具以标准化的Schema描述自身的能力、参数和返回值，LLM应用可以动态发现和调用这些工具。Acrux Core将工具目录独立为平台级能力，使得同一个工具定义可以被多个提示词复用，工具的增删改查也不再与业务代码耦合。这对于维护一个拥有数十甚至上百个工具的复杂Agent系统而言，是显著的工程效率提升。

用户反馈闭环

非确定性是LLM应用最大的挑战之一，而真实世界的用户反馈往往是优化提示词的最佳依据。Acrux Core 提供了**用户反馈闭环（User Feedback Loop）**功能：

可以针对某次具体的提示词执行，收集终端用户的评分、点赞/点踩、甚至纠错内容。这些反馈会直接关联到执行记录，开发者随后可以在UI中基于这些洞察持续打磨提示词。这种「执行—反馈—迭代」的闭环，正是很多团队在生产环境中最需要却最难搭建的一环。

用户反馈闭环（Human-in-the-Loop Feedback）在LLM应用优化中扮演着不可替代的角色。与传统软件通过单元测试验证正确性不同，LLM输出的"好坏"往往需要人类判断。RLHF（Reinforcement Learning from Human Feedback）在模型训练阶段证明了人类反馈的价值，而在应用层面，收集终端用户的显式反馈（如点赞/点踩、评分）和隐式反馈（如用户是否采纳了建议、是否手动修改了输出）同样重要。关键在于将反馈数据与具体的执行上下文（使用了哪个版本的提示词、什么模型参数、输入是什么）精确关联，这样才能定位问题根源并针对性优化。

值得补充的是，显式反馈和隐式反馈在实际系统设计中各有优劣。显式反馈（点赞/点踩按钮）信号明确但收集率通常很低——业界数据表明，主动给出反馈的用户通常不超过5%，且存在"负面偏见"（不满意时更愿意反馈）。隐式反馈（如用户是否复制了输出、是否在输出基础上继续提问而非重新表述、停留时长等）收集率高但信号噪声比也高，需要更复杂的分析逻辑来提取有效信息。成熟的反馈系统通常两者兼顾，并通过标注团队对模糊案例进行二次审核，确保反馈数据的质量。

从数据飞轮（Data Flywheel）的视角来看，用户反馈的价值远不止于单次提示词优化。积累的反馈数据可以构建高质量的评估数据集（Evaluation Dataset），用于自动化地衡量提示词变更的效果；在更高级的场景中，这些数据甚至可以用于微调（Fine-tuning）特定领域的小模型，从而在降低成本的同时保持输出质量。ChatGPT本身的持续改进就高度依赖这种"部署-收集反馈-改进-再部署"的飞轮效应。对于应用开发者而言，能否系统化地构建这个飞轮，往往决定了产品能否跨越从"Demo级"到"生产级"的鸿沟。数据飞轮的每一圈转动都在积累复合优势：更好的输出带来更多用户使用，更多使用产生更多反馈数据，更多数据又驱动更精准的优化。这也解释了为什么先发的AI应用往往能建立起难以逾越的数据壁垒。

全链路追踪与成本追踪

在可观测性方面，Acrux Core 支持嵌套LLM执行的完整追踪，覆盖函数调用、Token用量以及跨运行的延迟分解。对于愈发关注推理成本的团队而言，内置的LLM成本追踪能力尤为实用——它让每一次调用的开销都清晰可见，为成本优化提供了数据基础。

LLM的计费模式通常基于Token数量，不同模型的价格差异巨大——例如GPT-4o的输入Token价格约为GPT-4 Turbo的一半，而Claude 3 Haiku的成本仅为Claude 3 Opus的约1/60。在复杂的Agent应用中，一次用户请求可能触发多轮LLM调用（思考链、工具调用、结果总结等），实际Token消耗远超表面可见。成本追踪需要解决几个关键问题：准确统计每次调用的输入/输出Token数、正确映射到对应模型的费率、支持跨多个Provider的统一核算，以及将成本归因到具体的功能模块或用户群体，从而为架构决策（如何时该用更便宜的小模型替代）提供数据支撑。

在实际的成本优化实践中，团队通常会采用分层策略（Tiered Strategy）：对于简单意图识别和分类任务使用廉价的小模型（如GPT-3.5 Turbo或开源的Mistral 7B），对于需要深度推理的核心任务才动用高端模型（如GPT-4或Claude 3.5 Sonnet）。这种"路由"决策需要精确的成本数据作为依据——你需要知道每个环节的实际Token消耗和对应费用，才能判断将某个环节替换为更便宜模型后的性价比。此外，Prompt Caching（提示词缓存）技术的出现也让成本追踪变得更加复杂——Anthropic和OpenAI都推出了缓存机制，缓存命中时的Token费用仅为正常费率的10%-25%，准确追踪缓存命中率对成本预测至关重要。

嵌套追踪（Nested Tracing）在LLM应用中的重要性不可低估。一个看似简单的用户查询，在RAG（检索增强生成）架构中可能经历以下步骤：查询改写（一次LLM调用）→ 向量检索（Embedding调用）→ 文档重排序（可能又一次LLM调用）→ 最终生成（核心LLM调用）。如果其中任一环节加入了Agent循环，调用次数还会进一步膨胀。没有嵌套追踪能力，开发者将无法定位延迟瓶颈（是检索慢还是生成慢？）和成本热点（哪个环节消耗了最多Token？）。这与微服务架构中分布式追踪（如Jaeger、Zipkin）的价值完全一致——只不过"服务间调用"变成了"LLM调用链"。

RAG（Retrieval-Augmented Generation，检索增强生成）是当前LLM应用中最主流的架构模式之一，它通过在生成前从外部知识库中检索相关文档，有效缓解了LLM的"幻觉"（Hallucination）问题和知识截止日期限制。一个完整的RAG流水线通常包含离线和在线两个阶段：离线阶段将文档切块、向量化后存入向量数据库（如Pinecone、Weaviate、Milvus）；在线阶段则在用户查询时执行检索、排序和生成。每个环节都可能引入延迟和成本，而嵌套追踪能力让开发者能够像使用"X光"一样透视整个流水线的内部运行状况。

开发者友好的SDK与集成方式

Acrux Core 提供了原生的 Python 与 TypeScript SDK，二者都构建在一套干净的 REST API 之上。这意味着即便你的后端使用的是其他语言，也可以通过 REST API 直接接入，具备良好的跨语言集成能力。

对于AI应用开发者来说，双语言SDK的覆盖基本满足了当下主流技术栈的需求——Python 服务于数据科学与后端逻辑，TypeScript 则覆盖了全栈与前端场景。

值得注意的是，SDK的设计质量对开发者的集成体验影响巨大。优秀的LLM可观测性SDK通常需要做到"低侵入性"——理想情况下，开发者只需添加几行装饰器（Python的decorator）或中间件，就能自动捕获所有LLM调用的输入、输出、Token用量和延迟，而无需手动在每个调用点插入追踪代码。此外，SDK还需要考虑异步调用支持（LLM调用通常是I/O密集型的异步操作）、流式响应（Streaming）的追踪处理、以及失败重试场景下的正确记录。这些看似细小的工程决策，直接决定了开发者是否愿意在真实项目中持续使用该工具。

流式响应的追踪是一个值得展开的技术挑战。现代LLM API通常支持Streaming模式——模型逐Token生成并实时返回，用户无需等待完整响应即可看到部分结果，这对用户体验至关重要。但对于可观测性SDK而言，流式响应意味着：输出Token数需要在流结束后才能确定、首Token延迟（Time to First Token, TTFT）和总延迟需要分别记录、流中断的异常处理需要正确标记。一个设计良好的SDK应该能够透明地处理这些复杂性，对业务代码完全无感知——开发者无论使用同步、异步还是流式模式调用LLM，追踪都能自动生效。

为什么选择开源自托管而非SaaS方案

作者对开源理念给出了颇具说服力的解释：调试非确定性的LLM行为，不应该以把所有提示词和追踪数据发送给第三方厂商为代价。

这一观点直击当前SaaS化可观测性工具的核心顾虑——数据主权。数据主权（Data Sovereignty）关切在AI应用场景中尤为突出。当企业使用SaaS化的LLM可观测性工具时，所有的提示词模板、用户输入、模型输出、执行追踪都会发送到第三方服务器。对于处理敏感数据的企业（如金融、医疗、法律领域），这可能违反GDPR、HIPAA等合规要求。即便在非强监管行业，提示词本身也可能包含核心业务逻辑和竞争优势——将其暴露给第三方存在商业风险。自托管方案通过让数据完全留在企业自有基础设施内，从根本上消除了这一顾虑，同时也避免了供应商锁定（Vendor Lock-in）的风险。

值得进一步解释的是，GDPR（通用数据保护条例）是欧盟2018年实施的数据保护法规，要求企业对个人数据的处理具有合法性基础，并赋予数据主体访问、删除、迁移其数据的权利；而HIPAA（健康保险可携性和责任法案）是美国针对医疗健康信息的保护法规。在LLM应用场景中，用户输入往往包含个人信息甚至敏感数据（如医疗咨询中的症状描述、法律咨询中的案件细节），如果这些数据被发送到第三方可观测性平台，就构成了一次额外的数据共享行为，需要额外的合规评估和用户知情同意。自托管方案从架构上规避了这一合规风险点。

从更广阔的行业趋势来看，开源+自托管的模式在DevOps和数据基础设施领域已经反复验证了其商业可行性——GitLab之于GitHub、Mattermost之于Slack、PostHog之于Amplitude都是成功案例。这些项目通常采用"开放核心"（Open Core）商业模式：核心功能完全开源免费，企业级特性（如SSO、审计日志、高级权限管理）作为付费增值服务。这种模式既保证了社区驱动的创新速度，又为项目的长期可持续发展提供了商业基础。对于LLM可观测性这一新兴领域，自托管方案还有一个独特优势：当遥测数据量随着AI应用规模增长而爆发式增加时，自托管的边际成本远低于按量计费的SaaS方案。

以具体数字来看，一个日活跃用户1万人的AI应用，假设每用户每天平均产生10次LLM调用，则每月产生约300万条追踪记录。在主流SaaS可观测性平台上，这一量级的数据存储和查询费用可能达到数百甚至数千美元/月；而自托管方案的主要成本是服务器资源，一台中等配置的云服务器（约$50-100/月）配合适当的数据库优化即可承载。当应用规模增长10倍时，SaaS费用线性增长，而自托管的基础设施成本增长通常是亚线性的——通过水平扩展和数据分层存储（热数据/冷数据分离），可以有效控制成本曲线。

Acrux Core 支持 100% 自托管，可以通过 Docker 在本地运行或部署到自有基础设施上，不存在数据锁定或强制依赖第三方云的问题。

当然，对于偏好托管方案的用户，项目也提供了完整的云端托管版本，实现了「灵活选择」的平衡：既能享受托管的便利，也能在需要时完全掌控自己的遥测数据。

与LangSmith、Langfuse的对比思考

从赛道来看，LLM可观测性正在成为AI工程化基础设施的关键一环。LangSmith、Langfuse 等工具已经证明了这一市场的需求，而 Acrux Core 选择以开源+自托管为差异化切入点，切中了对成本敏感、对数据主权敏感的这批开发者。

具体而言，LangSmith作为LangChain生态的官方可观测性产品，与LangChain框架深度集成，但其闭源SaaS模式和与LangChain的强绑定让部分开发者心存顾虑；Langfuse走开源路线且框架无关（Framework-agnostic），已获得较好的社区认可，但其功能主要聚焦在追踪和评估层面。Acrux Core试图在开源自托管的基础上，进一步整合工具目录和动态绑定能力，形成差异化定位。当然，在这个快速演进的赛道中，工具的成熟度、社区活跃度和生态集成广度同样是开发者选型时的重要考量因素。

补充一些竞品的背景有助于理解这一赛道的全貌。LangChain是目前最流行的LLM应用开发框架之一，拥有庞大的社区和丰富的集成生态，但也因其频繁的Breaking Changes和过度抽象而受到批评。LangSmith作为其配套的商业产品，优势在于与LangChain的无缝集成（自动追踪所有Chain和Agent的执行），但对于不使用LangChain的团队则吸引力有限。Langfuse在2023年作为开源项目出现后快速获得了社区认可，其GitHub star数增长迅速，特点在于提供了精美的追踪可视化界面和灵活的评估框架，支持OpenAI、Anthropic、LangChain、LlamaIndex等多种集成。除此之外，Helicone以其"一行代码接入"的极简体验著称（通过代理API的方式拦截LLM调用），Braintrust则强调评估和数据集管理能力。这一赛道的玩家各有侧重，尚未出现绝对的赢家。

其真正的亮点在于将工具目录、提示词管理与反馈闭环整合为一体，而非仅仅提供追踪能力。工具与提示词的动态绑定，某种程度上是在平台层面提供了轻量级的Agent编排能力，这一思路值得关注。

作为一个仍在积极开发中的项目，Acrux Core 目前更适合愿意尝鲜、参与共建的早期用户。作者也明确表示，欢迎社区提供早期反馈、贡献代码或提出功能需求。对于正在为LLM应用可观测性发愁、又不愿被SaaS平台绑定的团队而言，这是一个值得纳入评估清单的开源新选择。

项目地址：https://github.com/AcruxCore/AcruxCore