多智能体系统如何支撑 AI 原生工程
作者：Spiros Xanthos, Gabor Angeli, Bharat Khandelwal
原文：查看原文
今天的软件工程里有一个很明显的反差：你可以在几小时内借助 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 硕士