多智能体系统在使软件工程师成为 AI 原生中的作用
今天的工程学带有一个奇怪的矛盾：您可以在几小时内使用 AI 启动整个服务，但理解这些服务出了什么问题仍然需要在碎片化工具中进行艰苦的工作。以以下例子为例：
| 编码 | 生产 |
|---|---|
| 编写服务：您打开 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 主导：工程师 → 自然语言请求 → AI 系统 → 响应/行动。工程师设定目标，让 AI 代理处理运营工作
以事件响应为例。在 AI 辅助工作流程中，您仍然在生成假设，决定哪些证据重要，并手动跨工具关联信号。AI 帮助数据检索和分析，但您在调查中承担繁重工作。
AI 原生事件响应以不同方式运作：AI 代理自动分类调查优先级，并行生成竞争假设，并根据跨系统证据迭代完善理论。您不是问"你能分析这些日志吗？"而是说"解决这个结账失败"，代理协调整个调查。
这不仅更快。它改变了哪些问题值得工程关注。当 AI 代理处理日志分析、指标关联和部署时间线重建时，工程师专注于架构决策和系统设计，而不是战术性调查。
这种转变需要持久的 AI 代理，而不仅仅是 AI 工具。虽然 LLM 可以加速个别任务，但只有有状态的代理才能维护调查上下文，协调多个工具，并自主执行复杂的多步骤工作流程。
为什么多智能体系统对使工程 AI 原生至关重要？
现代生产系统表现出学者所称的"不可简化的相互依赖性"：理解它们需要跨领域专业化知识，这些知识无法统一到单一连贯模型中。这是大多数构建者忽略的见解：没有单一的 AI 工具可以在协调调查的同时在所有这些领域维持专家级知识。
例如：当 API 延迟在关键事件中飙升 10 倍时，调查需要同时进行专业化分析：跨 50 多个微服务关联追踪、分析缓慢的数据库查询和连接池耗尽、检查最近的部署和基础设施更改、扫描认证日志的安全异常、根据当前负载模式评估自动扩展决策，以及在 SLA 上下文中分析支持票证的客户影响。每项活动都需要领域特定的专业知识和上下文数据，没有任何单一系统能够有效维护。
随着系统复杂性增加，单个 AI 工具面临上下文需求的指数级增长。这就是多智能体系统可以通过结合协调和个体领域专业化来扩展的地方。这个矩阵为工程领导者提供了一个概述。找到匹配您当前状态的行以了解其局限性：
这个框架揭示了每个级别的技术限制：
| 方法 | 它是什么 | 方法在哪里失效 | 限制原因 |
|---|---|---|---|
| LLM | 使用 LLM 进行个别任务，如解释、分析和文档 | 工程师仍然进行大部分运营工作 | 单次生成，没有反馈循环或现实世界集成 |
| LLM + 工具 | AI 可以根据命令从监控系统获取数据 | 关联的认知负担仍在人类身上 | 有限的上下文窗口，跨工具交互没有持久状态管理 |
| 单一代理 | AI 独立遵循调查工作流程 | 顺序调查，陷入错误假设 | 无法管理多样化的推理策略或并行调查路径 |
| 多代理 | 专业化 AI 代理协调并行调查 | 需要投资协调协议 | 分布式智能需要正式的通信模式和冲突解决 |
进展揭示了一个基本的架构真理：每个级别都遇到不同的可扩展性上限。LLM 缺乏持久状态。工具增强的 LLM 无法在多次聊天中维护调查上下文。单一代理随着系统复杂性增长成为决策瓶颈。只有多智能体系统能够突破限制所有先前方法的顺序推理约束。它们启用并行假设测试，而单一代理必须顺序调查，使它们从根本上不适合生产事件的时间需求。
构建多智能体系统是一个困难的工程问题
构建生产就绪的多智能体系统需要深厚的领域专业知识和 AI 工程能力的罕见结合。大多数尝试失败是因为团队在一个领域有专业知识，但不是两者都有。以下是为什么需要这种双重专业知识：
领域专业知识决定架构
不了解生产现实就无法架构代理。只有在凌晨 3 点调试过生产的人才知道日志模式和指标异常需要根本不同的调查策略。当支付失败激增时，您需要数据库专业知识和基础设施专业知识来确定根本原因。这样的决定不是 AI 问题。它们是塑造您如何构建多智能体系统的生产决策。
AI 专业知识使代理协同工作
一旦您分解了问题，您就遇到了计算机科学的困难部分。代理之间的上下文传播不是直觉。它是管理信息流的有向无环图。协调并行代理需要正式的协调协议以防止竞争条件和死锁。系统需要从交互和短暂故障模式中持续学习。在协调代理时走错一步，您的系统会逐渐变差，而不是更好。
交集创造突破性系统
没有 AI 架构的领域知识只是昂贵的咨询。没有领域知识的 AI 架构只是调查错误事物的自动化。当您结合两者时发生突破：知道数据库连接池在负载下做什么（领域）与构建能够协调池健康检查与部署时间线分析和上游服务验证的代理：所有并行运行而不相互踩踏（AI 系统）。
在 Resolve AI，我们的团队包括在生产系统有超过二十年经验的工程师、共同创建 OpenTelemetry 的创始人和具有深度 AI 专业知识的研究人员，他们是 Google DeepResearch 和 Gemini Agents 背后的思维。这种组合让我们构建的系统不仅理解"支付失败是坏事"，而且知道检查连接池指标并与上游服务降级相关联。同时管理复杂代理编排，防止循环调查并在并行执行路径中保持连贯的叙述线程。
关于 Resolve AI
Resolve AI 是您全天候的 AI SRE，帮助您解决事件和运行生产。使用 Resolve AI，像 DataStax、Tubi 和 Rappi 这样的客户通过让机器为人类值班，让工程师只编码，提高了工程速度和系统可靠性。
作者团队：
- Spiros Xanthos - 创始人兼首席执行官，OpenTelemetry 共同创建者
- Gabor Angeli - 研究工程师，前 Google DeepMind，参与 Gemini 开发
- Bharat Khandelwal - 研究工程师，斯坦福大学 AI 硕士