多智能体系统在让软件工程师成为 AI 原生过程中的作用
来源: https://resolve.ai/blog/role-of-multi-agent-systems-AI-native-engineering 抓取时间: 2026-07-21 16:27:19
生成式 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 智能体，而不仅仅是 AI 工具。虽然 OpenAI 或 Anthropic 等 AI 模型可以加速个别任务，但只有有状态的智能体才能维护调查上下文、跨多个工具协调，并自主执行整个事件生命周期中的复杂任务。
为什么多智能体系统对于使工程 AI 原生至关重要？
现代生产系统表现出学术界所谓的"不可简化的相互依存性"：理解它们需要跨领域的专业知识，这些知识不能统一为单一的连贯模型。这是大多数构建者错过的洞见：没有任何单一 AI 工具或 AI 模型集可以在协调实时调查的同时，在所有这些领域保持专家级知识。
例如：当 API 延迟在关键事件期间飙升 10 倍时，调查需要同时执行实时分析的专业智能体：关联 50 多个微服务的追踪、分析慢速数据库查询和连接池耗尽、检查最近的部署和基础设施变更、扫描认证日志以查找安全异常、评估自动扩展函数与当前负载模式的对比，以及分析支持工单以获取客户影响和 SLA 上下文。这些功能中的每一个都需要特定领域的专业知识和上下文数据，这是任何单一系统都无法有效维护的。
在大规模情况下，随着系统复杂性的增加，单个 AI 工具缺乏处理上下文需求指数增长的适应性。这就是多智能体系统可以通过结合编排和个人领域专业化来扩展的地方。这个矩阵为工程领导者提供了概述。找到与你当前状态匹配的行，以了解其局限性：
该框架揭示了每个级别的技术局限性：
| 方法 | 它是什么 | 方法在哪里失效 | 局限性原因 |
|---|---|---|---|
| LLM | 使用 LLM（如 ChatGPT）执行单个任务，如解释、分析和文档编制 | 工程师仍然承担大部分运维工作负载 | 单次传递生成容易产生幻觉，没有反馈回路或现实世界集成 |
| LLM + 工具 | AI 可以调用函数来按需从监控系统获取数据 | 关联的认知工作负载仍由人类承担 | 上下文窗口有限，跨工具交互没有持久状态管理 |
| 单智能体 | AI 独立遵循调查工作流 | 顺序调查，没有验证就会被错误的假设卡住 | 无法管理多样化的推理策略或并行调查路径 |
| 多智能体 | 通过多智能体协作，专业 AI 智能体协调并行调查，并将其输出组合成统一的诊断 | 需要在协调协议上投资 | 分布式智能需要正式的通信模式和冲突解决 |
这种演进揭示了一个基本的架构真理：每个级别都达到不同的可扩展性上限。LLM 缺乏持久状态。工具增强的 LLM 无法在多个聊天中维护调查上下文。即使使用复杂的提示工程，随着系统复杂性的增长，单智能体也会成为决策瓶颈。只有多智能体系统才能突破限制所有先前方法的顺序推理约束。它们启用并行假设测试，而单智能体必须顺序调查，使它们从根本上不适合生产事件的时间要求。
构建多智能体系统是一个困难的工程问题
没有像 LangChain 这样的现成智能体框架能单独解决这个问题。构建生产就绪的多智能体系统需要深厚的领域专业知识和 AI 工程能力的罕见结合。大多数尝试失败是因为团队在一个领域有专业知识但没有另一个领域。以下是为什么需要这种双重专业知识：
领域专业知识决定架构：不理解生产现实，你就无法架构智能体。只有那些在 DevOps 或 SRE 角色中在凌晨 3 点调试过生产的人才知道日志模式和指标异常需要根本不同的调查策略。当支付故障激增时，你既需要数据库专业知识，也需要基础设施专业知识来确定根本原因。这样的决定不是 AI 问题。它们是塑造你如何构建多智能体系统的生产决策。
AI 专业知识使智能体能够协同工作：一旦你分解了问题，你就遇到了计算机科学的困难部分。智能体之间的上下文传播不是直觉。它是管理信息流的有向无环图，其中每个智能体的输出馈送到下一个智能体的输入。编排并行智能体需要正式的协调协议来防止竞争条件和死锁。系统需要从交互和临时故障模式中持续学习。在协调智能体时做错一步，你的系统会逐渐变得更糟，而不是更好。
交叉点创造突破性系统：没有 AI 架构的领域知识只是昂贵的咨询。没有领域知识的 AI 架构产生的输出调查的是错误的事情。当你结合两者时，突破就会发生：知道数据库连接池在负载下做什么（领域），同时构建智能体，能够协调池健康检查与部署时间线分析和上游服务验证：所有这些都并行运行而不会相互干扰（AI 系统）。
在 Resolve AI，我们的团队包括在生产系统方面拥有超过二十年经验的工程师，共同创建了 OpenTelemetry（生态系统中最具影响力的开源可观测性项目之一）的创始人，以及具有深厚人工智能专业知识的研究员，他们是 Google DeepResearch 和 Gemini Agents 的幕后推手。这种结合让我们能够构建不仅理解"支付故障不好"，而且知道检查连接池指标并与上游服务降级相关联的系统。同时管理复杂的智能体编排，防止循环调查并在并行执行路径中保持连贯的叙述线程。
关于 Resolve AI
Resolve AI 是你永远在线的 AI SRE，帮助你解决事件并运行生产。通过 Resolve AI，Salesforce、Zscaler 和 Coinbase 等客户通过让机器为人类值班，让工程师只编码，提高了工程速度和系统可靠性。在 resolve.ai 了解更多关于 AI 原生工程工作流的信息。
查看运行和修复软件的智能体实际效果
加入我们的工程负责人"构建背后"网络研讨会系列，深入探讨我们如何构建运行软件的智能体。
[立即观看]
Spiros Xanthos
创始人兼 CEO
Spiros 是 Resolve AI 的创始人兼 CEO。他喜欢向客户学习和构建产品。他帮助创建了 OpenTelemetry，并创立了 Log Insight（被 VMware 收购）和 Omnition（被 Splunk 收购），最近他担任了 Splunk 可观测性业务的 SVP 和总经理。
Gabor Angeli
研究工程师
Gabor Angeli 带来了广泛的 AI 专业知识，最近在 Google DeepMind 和 Square 工作。他在 Gemini 和 Square Assistant 等产品上的工作每天影响数百万用户。他加入 Resolve AI 是为了构建 Agentic AI 系统，帮助工程师理解和导航生产系统。
Bharat Khandelwal
研究工程师
@ Resolve AI
Bharat 是 Resolve AI 的研究工程师，在那里他构建了使大型语言模型能够调试和操作生产软件基础设施的 agentic 系统。在加入 Resolve 之前，他在 WorldQuant 领导机器学习计划，设计基于 Transformer 的宏观经济预测架构，并整合来自非结构化数据的 LLM 驱动的情绪信号。他还曾在 Moveworks 从事企业 NLP 系统工作，并在 Tower Research Capital 工作，在那里他为高频交易开发低延迟 ML 策略。Bharat 拥有斯坦福大学计算机科学硕士学位，专攻人工智能，以及 IIT Bombay 计算机科学 B.Tech.（荣誉）学位。
本文章由 Resolve.ai 团队提供，保留所有权利。