波士顿 DevSummit：AI 产品交付的主要经验教训

在波士顿举行的 InfoQ Dev Summit大会上，Outropy创始人兼首席执行官Phil Calçado发表了主题演讲，主要面向那些在生产中构建和推广生成式 AI 产品的软件领导者。凭借三年的实践经验和 30 年的软件架构职业生涯，Calçado 谈了具体的经验教训，说明了在面对 AI 系统的随机性和有状态需求时，哪些传统的工程模式仍然有效。

首先，他承认了在场人员背景的多样性以及生成式 AI 不断演变的性质。Calçado 做了个对比，个人工程师有丰富的 IDE 自动化工具可以使用，而管理者和可靠性工程师几乎完全没有。他回忆说：“2021 年，我最初的想法是，我们能把这个自动化吗？我能为管理者或工程师所做的一切工作创建一个基本的 VS Code 吗？”

尽管早期在基准测试中取得了成功，但 Calçado 坦率地承认，“这个产品彻底失败了。”他指出，核心问题是激励机制的错位：用户更感兴趣的是逆向工程助手的内部设计，而不是依赖它来提高日常生产力。他解释说，这一洞见揭示了展示技术新颖性的工具和真正提供持续用户价值的工具之间的区别。

从这些经验中，他提炼出自己在 AI 开发中观察到的三种主导心态。在第一种心态中，团队聚焦最新模型的发布和资金循环而不是解决当前的限制，等待“明年的 AGI”而不是迭代当前的限制。在第二种心态中，数据科学实验室开展为期一年的项目，竭力提升准确性，而几乎没有产品思维，构建出的分类器仅比之前的版本稍好一点。在第三种心态中，团队采用以软件工程为中心的工作流，强调在生产中快速迭代，开发轻量级、可插拔的组件，然后进行测试和完善。

为了构建这些系统，Calçado 引入了两个核心抽象：工作流和代理。工作流是静态的、预定义的管道，执行一系列转换，例如接收消息、对话去重和生成摘要。相比之下，代理是半自治组件，具有记忆、目标导向和动态调用工具或其他服务的能力。他说：“代理有记忆，它们是目标导向的，动态的，并且喜欢协作”，他将它们比作传统面向对象设计中的有状态对象。

他警告说，不要将代理视为细粒度的微服务。LLM 代理固有的有状态、非确定性行为破坏了传统的服务边界，导致了脆性耦合和操作脆弱性。相反，他提倡使用语义事件总线，其中结构化、意图驱动的事件（而不是原始的数据库变更流）可以解耦组件，并在系统内实现可发现、可插拔的行为。

在组装 AI 管道时，Calçado 强调了将单体项目分解成具有清晰语义接口的小而明确的切片的重要性。例如，在 Autopi 的每日简报功能中，有单独的组件处理 Slack 接收、重复对话检测、语义摘要和日历上下文丰富。

Calçado 还挑战了十二因素应用模型对 AI 系统的适用性。他指出，配置不再是静态的，流程不能保持无状态，LLM 调用引入了固有的延迟瓶颈。为了应对这些挑战，他敦促团队探索持久工作流框架，如Temporal。这类框架能干净利落地将编排与副作用分开，透明地处理重试和超时，并为长期运行的有状态进程提供检查点功能。

最后，Calçado 强调，尽管 AI 引入了新的架构需求，但核心解决方案不在于重新发明轮子，而在于扩展经过验证的软件工程原则，适应 AI 系统的随机性和有状态性。他说：“我们不需要从头开始重建一切。我们需要更好的平台，整合这些模式，以便团队可以快速迭代，而不是重新发明管道。”

在未来几周内，想要了解更多信息的开发人员可以在infoq.com上观看活动视频。

声明：本文为 InfoQ 翻译，未经许可禁止转载。

原文链接：https://www.infoq.com/news/2025/07/devsummit-shipping-beyod-hype/