--- title: 251112-多智能体系统如何支撑 AI 原生工程 description: Resolve AI 深度解析多智能体架构如何支撑 AI 原生工作流，推动工程实践从 AI 辅助走向 AI 原生 author: Spiros Xanthos, Gabor Angeli, Bharat Khandelwal source: https://resolve.ai/blog/multi-agent-systems-ai-native-engineering date: '2025-11-12' category: 02-technical-architecture tags: - 多智能体系统 - AI 原生工程 - 生产运维 - 事件响应 - Resolve AI --- # 多智能体系统如何支撑 AI 原生工程 **作者：Spiros Xanthos, Gabor Angeli, Bharat Khandelwal** **原文：[查看原文](https://resolve.ai/blog/multi-agent-systems-ai-native-engineering)**
今天的软件工程里有一个很明显的反差：你可以在几小时内借助 AI 搭起一项新服务，但一旦这项服务在生产环境里出问题，排查工作往往仍然要在一堆割裂的工具之间来回切换。 | 编码 | 生产 | | ---- | ---- | | 写服务时：你打开 AI 原生开发环境，直接要求 AI“创建一个能处理重试和超时的支付服务”，它会结合代码库上下文生成实现。 | 出现高延迟时：你通常要先提出假设，再去 Datadog 看指标、切到 Loki 查日志、回头核对部署记录、对齐时间戳、继续排查。 | 问题不在于 AI 能不能写代码，而在于我们如何组织 AI 系统。很多团队只是用 AI 去加速旧流程，而不是重构整个工作方式。 在 Resolve AI，我们一直在为工程师构建面向生产系统的多智能体架构。我们的判断是：真正的 AI 原生工程，不是“让 AI 帮你多写一点代码”，而是让 AI 成为处理生产系统的主要入口。 我们最近也向斯坦福大学研究生的 AI 项目分享了这套方法，重点讨论了让 AI 原生工程真正落地所需要的智能体架构模式。 ## 什么是 AI 原生工程？为什么重要？ AI 原生工程，指的是工程师主要通过 AI 接口来协调工作——无论是写代码，还是处理生产系统。它和“使用 AI”是两回事。 **AI 辅助工程**：你用 AI 提高效率，但工作流仍然是以人为中心。工程师依旧直接操作系统和工具，只是把其中部分步骤交给 AI 加速。 **AI 原生工程**：AI 成为处理工作的主入口。工程师提出目标，AI 系统再去组织调查、收集证据、执行动作并返回结果。 以事件响应为例： - 在 **AI 辅助** 模式下，你仍要自己提出假设、判断哪些信号重要，并手动在不同工具间完成关联。 - 在 **AI 原生** 模式下，你可以直接说一句“解决这个结账失败问题”，然后由智能体系统去自动分流调查、并行验证假设、根据证据不断收敛结论。 这不只是“更快一点”。当日志分析、指标关联和部署时间线重建都能由智能体系统承担时，你的注意力就可以从战术排查转回到架构判断和系统设计上。 而要实现这种转变，靠的不是单次对话式工具，而是能够持续维护上下文、协调多个工具、执行多步流程的有状态智能体系统。 ## 为什么多智能体系统对 AI 原生工程至关重要？ 现代生产系统有一个很现实的特点：它们依赖大量无法被压缩成单一视角的专业知识。要理解一个复杂故障，往往需要数据库、基础设施、应用逻辑、安全、客户影响等多个维度同时介入。 **例如**：当 API 延迟在关键时段突然飙升 10 倍时，调查通常要并行展开： - 在几十个微服务之间关联追踪链路 - 分析慢查询与连接池耗尽 - 检查最近的部署与基础设施变更 - 排查认证日志中的异常安全事件 - 结合当前负载模式评估自动扩缩容行为 - 从 SLA 角度判断客户支持工单的实际影响 这些工作需要的是分工明确、上下文各自充分的专业分析，而不是把一切都塞给一个单体系统去顺序处理。 随着系统复杂度上升，单一智能体面临的上下文需求会快速膨胀。多智能体系统的价值就在这里：通过“统一协调 + 领域分工”的方式，把问题拆成多个可并行推进的分析线程。 | 方法 | 它是什么 | 会在哪里失效 | 限制原因 | | ---- | ---- | ---- | ---- | | **LLM** | 用 LLM 处理单个解释、分析或文档任务 | 工程师仍然要亲自完成大部分运营工作 | 单次生成，没有反馈闭环，也没有真实系统集成 | | **LLM + 工具** | AI 可以按指令从监控系统取数 | 跨工具关联的认知负担仍在你身上 | 上下文窗口有限，且缺少持久状态 | | **单一智能体** | 一个智能体独立执行调查流程 | 调查只能顺序推进，容易卡在错误假设上 | 难以同时管理多种推理路径 | | **多智能体** | 多个专业化智能体并行调查并协调结果 | 需要投入额外的协调成本 | 分布式智能需要正式的通信与冲突处理机制 | 这个演进过程揭示了一个基本事实：每一层方法都有自己的可扩展性上限。只有多智能体系统，才真正具备并行验证假设的能力；而在生产事件里，时间往往就是最稀缺的资源。 ## 构建多智能体系统，本身就是一个困难的工程问题 生产级多智能体系统难做，不只是因为模型复杂，更因为它要求你同时具备两种能力：领域理解和 AI 系统工程。 ### 领域知识决定架构边界 如果不了解生产系统真实是怎么出问题的，就很难设计出合适的智能体边界。真正经历过凌晨三点排障的人会知道：日志异常和指标异常不是一回事，支付失败激增时，到底该先看数据库、基础设施，还是上游依赖，也不是一个抽象层面的问题，而是生产经验本身决定的。 ### AI 工程能力决定系统能否协同 把问题拆开只是第一步。接下来你还得处理上下文传播、并行协调、冲突解决、失败重试和持续学习。多智能体系统不是“多开几个窗口”那么简单，它本质上是一个分布式系统问题。 ### 真正的突破发生在两者交叉处 只有领域知识，没有 AI 架构能力，你得到的往往只是昂贵但无法自动化的人工经验；只有 AI 架构，没有领域知识，系统又很容易自动化地调查错方向。真正有价值的，是把两者结合起来：既知道数据库连接池在高负载下会发生什么，也知道如何设计多个智能体，让它们分别检查连接池健康、部署时间线与上游服务状态，并且并行推进而不互相踩踏。 Resolve AI 的判断很明确：这类系统之所以难，不是因为“模型不够聪明”，而是因为生产世界本身就复杂，而系统设计必须忠实反映这种复杂性。 --- ## 关于 Resolve AI Resolve AI 将自己定位为全天候的 AI SRE，帮助团队处理事件响应与生产系统运维。按照他们的说法，像 DataStax、Tubi 和 Rappi 这样的客户，正在借助这类系统让工程师把更多精力放回到构建本身。 **作者团队：** - **Spiros Xanthos**：创始人兼 CEO，OpenTelemetry 共同创建者 - **Gabor Angeli**：研究工程师，前 Google DeepMind，参与 Gemini 开发 - **Bharat Khandelwal**：研究工程师，斯坦福大学 AI 硕士