厌倦了在五个不同工具之间切换来调试多步骤LLM工作流。构建了一个统一的工作空间来解决这个问题——寻求反馈!
摘要
一位开发者构建了一个统一的工作空间,通过集中可观测性日志和指标来调试多步骤LLM工作流,并寻求对其有效性的反馈。
大家好,我一直在开发一个开发者工具,以解决我在构建复杂AI工作流时遇到的一个主要痛点:可观测性碎片化。使用现有工具时,我经常发现自己在跟踪、提示日志、令牌指标和应用程序日志之间来回跳转,只是为了弄清楚为什么单次多步骤运行失败。我想要一个界面,整个调查都在一个连贯的视图中进行。这是我正在实验的数据层次结构:项目 -> 会话 -> 运行 -> 事件 事件捕获一切——工具调用、LLM输入/输出、提示和原始执行日志。如果一个运行不属于更大的用户会话,它就独立存在。这种结构似乎对单智能体循环和复杂的多智能体架构都表现良好。为了过滤噪音,我添加了过滤器,专门捕获常见的智能体问题,如无限工具循环和上下文窗口膨胀,以及标准过滤器(时间、客户端等)。它还跟踪自定义业务事件,以将技术执行与实际用户结果连接起来。我会在评论中放一个快速的2分钟演示视频,展示实际的UI操作。对于任何构建或维护生产AI工作流的人来说:这种层次结构对您的用例有意义吗?什么感觉真正有用,什么看起来像是功能膨胀?非常希望得到一些尖锐、诚实的反馈,关于这是否真正为您解决了一个实际问题。谢谢!
相似文章
构建了一个用于调试多步骤AI工作流的统一工作区(寻求反馈)
一位开发者构建了一个用于调试多步骤AI工作流的统一工作区,并正在寻求对该工具的反馈。
调试多智能体集群简直是一场噩梦。我开发了一个统一工作空间来追踪智能体的状态和循环。欢迎提供反馈!
作者构建了一个用于调试多智能体AI系统的统一工作空间工具,通过自动化检测无限工具循环和上下文膨胀来跟踪智能体状态和循环。
构建了一个让 Claude Code 代理无需工作树即可协调的工具。寻求反馈。
Crew 是一个新工具,允许 Claude Code 代理在同一仓库中协调,无需独立的工作树,通过共享上下文和消息传递来减少重叠。创建者正在征求关于痛点和期望功能的反馈。
花数月研究LLM评估与可观测性平台,针对250人规模部署——分享我们的发现
基于数月研究,针对250人公司部署的LLM评估与可观测性平台详细对比,涵盖全栈平台、可观测性工具和开源框架。
厌倦了用W&B和Langfuse调试AI代理,所以我自建了一个追踪器,寻求反馈
构建了一个新的追踪器用于调试AI代理,它能自动检测循环、将会话记录为可读时间线,并支持并排对比。寻求反馈。