构建自主质量工程代理系统后，什么让我们感到意外？

在过去的一年里，我们一直在构建 OttoTester，这是一个围绕专用 AI 代理而非单一的“万能”模型构建的自主质量工程系统。和许多团队一样，我们最初假设执行代理将是核心。但事实并非如此。最大的挑战不是生成测试或执行测试，而是构建一个能够持续改进而无需人工不断介入的系统。这使我们走向一组专用代理，它们能够： - 规划测试策略和覆盖范围 - 生成测试 - 跨 Web 应用程序执行 - 在应用程序发生变化时修复测试 - 分析跨执行模式以改进后续运行 - 审计其他代理的性能，识别弱点并改进整体系统 分析器和审计器最终变得比我们最初预期的要重要得多。没有学习和治理，自主性最终会停滞不前。另一条经验：编排比单个模型质量更重要。更换模型带来了渐进式的改进，但改善代理之间共享上下文、从先前执行中学习以及协调工作的方式，带来了更大的改进。 我们现在正在寻找 5-10 家企业工程组织作为设计合作伙伴，在更广泛发布之前挑战架构。我们不寻找交易性的 Beta 用户——我们在寻找拥有复杂应用程序、真实 CI/CD 管道、治理要求以及对自主系统失败原因有看法的团队。 我真诚地希望听到这个社区的意见：如果您正在评估用于生产环境的自主 QA 代理系统，那么在信任它之前，您最难以满足的要求是什么？可靠性？可审计性？学习能力？治理？与现有工程工作流的集成？还是其他？我非常想听听您认为这种方法成功的地方——或者您认为它失败的地方。