我在 38 个部署中达到了 1,000 多个遥测事件——现在我应该考虑什么?
摘要
一位开源 AI 工作流自动化平台的独立开发者讨论了扩展到 1,000 多个遥测事件,并寻求社区关于维护、向后兼容性和可观测性的建议,以应对增长的使用量。
我一直在构建一个开源的 AI 工作流自动化平台,主要作为独立项目进行了一段时间。我最近检查了遥测仪表板,诚实地感到惊讶,看到在 38 个独特的平台部署中有 1,062 个遥测事件。该项目已经从一个相对较小的工作流运行器发展成具有工作流、分支、工具、代理记忆、文档 RAG、调度、webhooks 和可视化工作流构建器的东西。我现在到了一个阶段,开始少想‘下一个功能应该构建什么?’,而更多地考虑‘随着更多人实际使用,如何避免破坏东西?’对于那些维护过开始获得真实使用量的开源项目的人:你希望你早些时候就设置了什么?比如:当你在更改工作流格式时,如何处理向后兼容性?你什么时候开始认真担心迁移?如何安全地推出更新而不破坏现有安装?什么样的遥测/可观测性是有用的?如何处理来自你无法复现的环境的错误报告?当你的项目从‘几个人尝试’到实际部署时,你是否犯过任何错误?我特别感兴趣的是维护自托管/开源基础设施的人的经验教训,因为用户控制着他们自己的安装,我不能简单地向每个人推送更新。真的很感激听到你通过艰难方式学到的东西。
相似文章
贵公司使用哪个平台满足AI代理的可观测性和可靠性需求?
一位构建多代理金融工作流的开发者寻求社区关于生产环境中AI代理可观测性和可靠性工具的建议,分享了对碎片化现状和级联故障的困扰。
有没有人真正在生产环境中使用AI代理(面对真实用户,不是演示,也不是10个测试用户)?你的技术栈是什么?有没有人在尝试将代理用于生产后又回归传统代码——为什么?
一个讨论贴,询问关于拥有100+用户的真实AI代理部署情况,涉及技术栈和扩展问题,以及回归传统代码的经验。
你用什么进行可观测性?
一位开发者讨论了AI代理缺乏合适的可观测性工具,对现有解决方案如Opik表示失望,并希望有一个支持OpenTelemetry的服务,用于分析代理会话和故障模式。
您如何构建基于AI编程代理的生产就绪开发环境?
一位网页开发者分享了围绕AI编程代理构建系统的经验,以实现可靠开发,并寻求关于工作流和编排工具的建议。
经验分享:构建用于处理 GitHub、Discourse 和邮件的 AI Agent(开源维护的真实用例)
作者分享了为 Seafile 构建 AI Agent 的案例研究,该 Agent 通过同步知识库并提供可操作建议,协助维护人员在 GitHub、Discourse 和邮件中分流处理支持请求。