8.0
热点
AI SCORE
技术实践2026-09-10 02:13
AI 应用正在演化成分布式系统
dev.to · AI#架构#分布式系统#AI工程
Editor brief · 编辑速览
现代 AI 应用已整合检索、外部 API 调用、工具执行、多模型协同、后台任务和状态维护——这本质上是在构建分布式系统而非带 AI 特性的简单应用。Google Cloud 和 OpenAI 均已在架构层面描述这种转变。
AI 应用曾经相对简单。
用户发送一条 prompt，应用将 prompt 发送给模型，模型返回一个答案，应用将其展示出来。
这种架构正在快速改变。
现代 AI 应用越来越多地执行信息检索、调用外部 API、执行工具、操作数据库、调用多个模型、运行后台任务、维护状态，有时还将工作委托给其他 AI Agent。
到了这个阶段，你构建的已不是一个带有 AI 功能的简单应用。
你在构建一个分布式系统。
这种转变是当今软件工程领域最重要的架构变化之一。
Google Cloud 最近在分布式 AI Agent 上的工作描述了一种架构：专业化的 Agent 作为独立服务运行，通过编排层进行通信。OpenAI 的 Agent 指南同样描述了围绕模型、工具、编排、护栏（guardrails）以及可能存在的多个 Agent 构建的系统。
有趣的是，这种转变甚至在开发者并未主动选择分布式架构的情况下也在发生。
考虑一个基础的 AI 驱动的应用：
User
|
v
Frontend
|
v
Backend
|
v
LLM API
|
v
Response
这很直接。
后端接收请求，发送给模型，接收结果，再返回给用户。
在延迟、成本、认证、限流和错误处理方面已经存在挑战，但架构本身仍然相对容易理解。
现在想象加入一些真实世界的功能。
读取公司文档 记住之前的交互 生成结构化输出 验证自己的输出 请另一个模型进行验证
架构开始变得截然不同。
+----------------+
| Web Search |
+-------+--------+
|
v
+--------+ +----------------+ +------------+
| User +------->| AI Backend +------->| Model |
+--------+ +-------+--------+ +------------+
|
+--------------+--------------+
| | |
v v v
+---------+ +---------+ +---------+
| Database| | Tools | | Cache |
+---------+ +---------+ +---------+
模型不再是整个应用。
它变成了更大系统中的一个组件。
最大的架构变化之一，是从仅生成文本的模型过渡到参与工作流的模型。
Agent 可以决定使用哪个工具、执行操作、检查结果，并继续工作流。
OpenAI 将 Agent 描述为能够独立完成任务、并能使用外部工具收集信息或执行动作的系统。他们当前的指南也涵盖了单 Agent 和多 Agent 的编排模式。
这为应用架构引入了一个新的层次。
Request → Model → Response
Request
↓
Agent
↓
Decision
↓
Tool
↓
External Service
↓
Tool Result
↓
Agent
↓
Another Tool
↓
Final Response
每个箭头都可能代表一个网络请求。
每个组件都可能失败。
每个额外的步骤都可能引入延迟。
而每个额外的服务都会产生另一种工程团队需要理解的状态。
这就是 AI 应用越来越像分布式系统的原因。
设计 AI 系统时的一个常见错误，是把 LLM 作为核心依赖，把其他一切都当作支撑基础设施。
实际上，现代 AI 应用往往依赖许多外部组件。
一个生产级 AI 应用可能依赖：
关系型数据库 搜索基础设施 认证服务 可观测性平台 内容审核服务
因此，单个用户请求可能跨越多个基础设施边界。
例如，想象一个 AI 研究助手。
"分析这三份报告，比较它们的财务风险。"
应用可能执行以下序列：
认证用户。 检索上传的文档。 提取文档文本。 将文档拆分成块。 搜索相关段落。 将选定的上下文发送给 LLM。 请模型识别风险。 再运行另一个模型进行验证。 将最终答案流式返回给用户。
原本看似一个请求，实际是一个涉及多个服务的工作流。
这就是分布式计算。
延迟是 AI 工作流引入的最大挑战之一。
假设一次模型请求需要两秒。
这也许可以接受。
但想象一个 Agent 做了五次顺序调用：
Model 2.0s
Search 0.5s
Database 0.2s
Model 2.0s
Validator 1.0s
总时间可能很快达到好几秒。
如果某些操作是顺序执行的，延迟会累积。
这产生了一个重要的工程问题：
哪些操作实际上需要顺序执行？
有些可以并行进行。
+--> Search
|
User --> Agent +--> Database
|
+--> Document Retrieval
Agent 可以等待全部三个结果，而不是依次独立等待。
最近的模型和 Agent 工具越来越关注编排和并行分解。OpenAI 的 GPT-5.6 开发者指南特别讨论了并行分解，以及将确定性处理移入代码以降低成本、延迟和不必要的模型工作。
这是一种经典的分布式系统优化。
区别在于，现在分布式组件中包含了 AI 模型和 AI Agent。
传统应用本来就有失败。
服务器会崩溃。数据库会不可用。网络会变得不可靠。
AI 应用又增加了一类失败：概率性行为。
模型可能返回一个出乎意料的答案。 工具可能被错误地选中。 检索系统可能返回不相关的上下文。 Agent 可能进入一个不必要的循环。 工作流可能消耗过多的模型调用。
这意味着 AI 系统需要的不仅仅是传统的错误处理。
考虑一个应该更新客户记录的 Agent。
工作流可能长这样：
User Request
↓
Agent
↓
Find Customer
↓
Validate Request
↓
Update Database
↓
Confirm Update
如果数据库更新成功了，但确认请求失败了怎么办？
用户可能会重试。
Agent 可能会重试。
系统可能意外地执行了同一操作两次。
分布式系统工程师多年来一直在处理这类问题，使用幂等性、重试、超时、队列和事务边界等概念。
AI 开发者越来越需要同样的概念。
重试是有用的，但盲目重试 AI 工作流可能产生意想不到的行为。
想象一个 Agent 发送 API 请求来创建发票。
响应超时了。
Agent 假定操作失败并重试。
结果现在有了两张发票。
这就是为什么生产级 AI 系统需要精心设计的行为边界。
对于会改变状态的操作，开发者应该考虑：
请求去重 显式确认 高风险操作需要人工批准
OpenAI 的 Agent 指南建议对高风险或不可逆操作进行人工干预，并在 Agent 超过失败阈值时进行升级。
教训很简单：
AI Agent 不应该拥有无限重试操作的权限。
AI 应用像分布式系统的另一个原因，是状态。
传统 Web 应用已经通过数据库、会话、缓存和队列来管理状态。
AI 应用可以再增加一层：
对话和推理状态。
Agent 可能需要记住：
已调用了哪些工具 检索了哪些信息 做了哪些决定 哪些操作成功了 接下来应该发生什么
当涉及多个 Agent 时，状态管理就更加复杂了。
User
↓
Manager Agent
↓
Research Agent
↓
Analysis Agent
↓
Writing Agent
↓
Manager Agent
↓
User
共享状态存放在哪里？
如果 Analysis Agent 失败了会发生什么？
工作流能否从失败的步骤恢复？
Writing Agent 应该收到整个历史，还是只有相关输出？
这些都是分布式工作流的问题。
Google Cloud 的多 Agent 系统参考架构同样将专业化 Agent 视为独立组件，协作完成复杂工作流。
在传统应用中，你可能检查：
HTTP request
→ database query
→ response
在 AI 应用中，追踪可能长这样：
Request
↓
Agent decision
↓
Model call
↓
Tool selection
↓
Search API
↓
Database query
↓
Model call
↓
Validation
↓
Tool execution
↓
Final response
没有适当的可观测性，调试会变得极其困难。
调用了哪个模型？ 延迟是多少？ 选择了哪些工具？ 消耗了多少 token？ 重试了多少次？ 是哪个外部服务导致的延迟？ Agent 决定做什么？
这就是现代 Agent 平台越来越多地添加追踪和可观测性功能的原因。例如，OpenAI 的 Agent 工具包含可观测性功能，用于检查 Agent 工作流的执行。
对开发者来说有一个重要的实践教训：
不要等到 AI 系统变得复杂后才添加可观测性。从一开始就要设计它。
微服务并不新鲜。
但 AI 创造了分离工作负载的新理由。
想象一个应用有：
Document Agent
Research Agent
Analysis Agent
Writing Agent
Validation Agent
每个组件可能有：
不同的扩缩容需求 不同的延迟需求 不同的权限
例如，研究 Agent 可能需要网络搜索。
写作 Agent 可能不需要。
数据库 Agent 可能需要访问客户记录。
摘要 Agent 可能只需要对文档的只读访问。
分离这些职责可以提高安全性和可靠性。
但有一个重要的警告。
分布式不一定自动意味着更好。
当一个服务就能工作时，创建十个服务只会让系统更难维护。
OpenAI 当前的 Agent 指南建议在引入多个 Agent 之前最大化单个 Agent 的能力，因为多 Agent 架构会引入额外的复杂性和开销。
这同样适用于微服务。
不要仅仅因为你可以就分布式地拆分什么。
只有在边界提供了真正的工程优势时才进行拆分。
一个现代 AI 应用最终可能长这样：
+----------------+
| Frontend |
+-------+--------+
|
v
+----------------+
| API Gateway |
+-------+--------+
|
v
+----------------------+
| Agent Orchestrator |
+----------+-----------+
|
+-------------------+-------------------+
| | |
v v v
+-------------+ +-------------+ +-------------+
| Research | | Analysis | | Action |
| Agent | | Agent | | Agent |
+------+------+ +------+------+ +------+------+
| | |
v v v
Search APIs Databases External APIs
| | |
+-------------------+-------------------+
|
v
+-------------------+
| Observability |
| + Evaluation |
+-------------------+
这个架构不是强制的。
但它代表了许多生产级 AI 系统正在迈向的方向。
Google 最近在分布式 AI Agent 上的工作描述了一种编排器模式，专业化的 Agent 可以作为可扩缩的微服务部署，并通过 Agent 间通信进行连接。
如果 AI 应用正在成为分布式系统，开发者需要扩展他们的技能集。
仅仅学习 prompt 工程是不够的。
构建严肃 AI 应用的开发者应该理解：
事件驱动架构 多 Agent 工作流
AI Agent 可以与真实系统交互，因此权限很重要。 工具级授权 敏感操作需要人工批准
AI 系统不能只靠"是否能用"来评判。 你需要可衡量的评估标准。
这尤其重要，因为模型行为可能随着模型、prompt、工具或检索上下文的变化而变化。
开发者能犯的最大的错误是认为：
"我在现有应用中加上 AI，架构以后再想。"
这种方法对原型是有用的。
当 AI 开始控制工作流时，它就变得危险了。
一旦模型可以调用 API、修改数据、触发任务、搜索私密信息或与其他 Agent 交互，它就成为了应用控制流的一部分。
到了那个阶段，AI 不仅仅是一个依赖项。
它是一个架构组件。
讽刺的是，许多这些工程问题并不新鲜。
分布式系统工程师几十年来一直在处理不可靠的网络、局部失败、异步通信、状态协调和可观测性问题。
新鲜的是参与者。
不再是每个组件都是确定性软件，有些组件现在可以推理、选择动作并产生不可预测的输出。
这使得架构变得更加重要。
AI 工程的未来不仅仅是构建更智能的模型。
而是构建能够安全可靠地使用这些模型的系统。
AI 应用正在成为分布式系统，因为 AI 正在超越文本生成。
模型越来越多地连接到工具、数据库、API、搜索系统、后台工作者和其他 Agent。
单个用户请求可以触发跨多个服务的操作链。
这产生了熟悉的分布式系统问题：
延迟。失败。状态。安全。协调。可观测性。
区别在于，做决策的组件之一可能是概率性的。
这改变了一切。
随着 Agentic 应用的普及，同时理解 AI 和分布式系统的开发者将拥有巨大优势。
重要的思维转变是：
不要把 AI 模型当作应用本身。把它当作分布式系统中的一个组件。
一旦你完成这种转变，许多架构决策就会变得更清晰。
而这才是严肃 AI 工程的起点。