日志

单轮聊天出错，看一眼输出就知道问题。但 Agent 跑十几步、调了五六个工具、还把上下文越滚越长之后，用户一句「结果不对」甩过来，你根本无从下手——它当时到底检索了哪段文档、调了哪个工具、中间哪一步开始跑偏？这就是为什么 2026 年做 Agent，可观测性是必需品，不是锦上添花。Langfuse 是这一范畴里常用的开源选择。 它解决什么 Langfuse 的核心是 trace：一次 Agent 运行从开始到结束，被记成一棵树。每个节点记录输入、输出、耗时、token 数、错误。你可以在网页上回放：这一步模型看到的上下文是什么，那一步工具返回了什么。 三步接进来 自托管一行 docker 起 Langfuse，或用云版拿一对公钥私钥； 在你的 Agent 代码里装它的 SDK，用装饰器或上下文管理器包住模型调用与工具函数； 给每步打上 name 和元数据（任务 id、用户 id），跑几次，控制台就能看到轨迹树。 对用 OpenAI Agents SDK、LangChain、Dify 的项目，Langfuse 都有现成集成，基本是填两个环境变量的事。 怎么用起来 复现 bug：用户报障时，按任务 id 拉出那一次 trace，定位是检索错了还是工具返回错了； 找成本黑洞：按 token 排序，找出那几个每轮都把超长上下文重发的步骤，针对性做压缩； 回归对比：改完提示词，对比新旧 trace 的步数与失败率。 判断 Agent 从 demo 走向生产，最后一公里往往不是「它够不够聪明」，而是「它出错时你能不能修好」。给 Agent 装上 Langfuse 这个黑匣子，等于给飞行记录仪——飞得多高是模型的事，坠机了能黑匣子读数，才是工程团队的底气。 补充一个进阶用法：给 trace 打标签。按部门、按场景、按用户等级打标签，事后就能对比「市场部的 Agent 平均跑几步、花多少 token」和研发的差异。这种横向对比，往往能直接定位到那个一直没被注意的高成本流程——它跑得勤，却没人意识到它在烧钱。 去论坛讨论 这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：Agent观测