一个多智能体工作流返回了错误答案——你能迅速回答这些问题吗？它在哪个节点出错？哪次调用产生了这个结果？上一个改动是否引入了回归？ 当智能体应用从演示走向生产，"让它跑起来"从来不是最难的部分。真正的难点在于：看清它如何运行、为何失败、每次改动产生了什么影响。HER Hack-Astron #2正是把这个工程难题开放给社区：让Langfuse可观测性进入企业级智能体工作流平台astron-agent（该平台已入选CNCF Landscape）。 任务核心：将Langfuse集成到astron-agent的工作流执行路径中，让一次完整的运行链路可追踪、可审计。这不是"加个文档页面"或"搭建一个接口壳"的任务——这是一个可以进入主代码树、服务于真实生产调试与质量治理的实质性贡献。 参赛者可以从三条技术路线中选择： **1. 原生插桩（Native Instrumentation）** 用Langfuse SDK包装工作流执行节点，将关键的LLM调用、工具调用、检索调用和智能体调用写入traces，同时提供配置项以控制开关、API密钥和主机地址。这是通往完整可用链路最直接的路径。 **2. 回调/钩子（Callback / Hook）** 为工作流运行器设计一个可扩展的回调接口，然后在其之上实现Langfuse回调。这种方式既能解决当前集成需求，又为未来的可观测性后端预留了清晰的接口边界，更侧重于接口抽象和兼容性设计。 **3. OpenTelemetry桥接** 复用仓库中已有的OpenTelemetry基础设施，通过OTLP协议按语义约定导出数据至Langfuse。该方案可同时保持与Jaeger、Grafana及更广泛的OTel生态系统的兼容性。 无论选择哪条路线，提交内容都必须包含：实质性代码变更、配置及使用文档、可复现的运行示例、真实的Langfuse traces（或等效的验证证据）。 评审标准是真实、可运行、可复现——而不是代码行数。拉取请求（PR）至少需要满足以下其一： 包含能正常运行的最低限度代码，且附带可验证的说明文档和可复现的使用示例；否则即为无效提交。空文档、空壳PR或占位代码一律不计入有效贡献。如果使用了AI辅助工具，必须在PR描述开头披露所用的智能体/模型、主要提示词，以及你个人设计和验证的部分——工具可以加速你的开发，但设计、验证和最终代码的责任在于你。 HER Hack-A

打开网易新闻 查看精彩图片