复杂 AI 系统架构演进：从一次 API 调用到 Agent 城邦

做一个思想实验。

假设你要让 AI 完成这件事：调研市面上 5 款竞品，分析它们的定价策略、用户评价、技术架构差异，最后输出一份 20 页的调研报告，带图表。

2023 年，你会打开 ChatGPT，一段一段地聊，自己组织，自己画图，本质上 AI 只是个"高级搜索引擎"。

2024 年，你可能会用 LangChain 写个 RAG 管道，让模型自己查文档、自己填模板，省了不少事——但它依然是一条"流水线"，出了错只能从头再来。

2025 年，你开始尝试多 Agent 方案：一个 Agent 负责搜索，一个负责分析，一个负责生成图表，一个负责排版。各司其职，并行推进。

2026 年呢？

2026 年的现实是：你派出一个"指挥官" Agent，它自己拆解任务、招募子 Agent、分配工具、管理记忆、监控进度，最后交付成品。整个过程中，你只说了一句话。

从一次 API 调用，到一座 Agent 城邦。这个演进，只用了不到三年。

但反直觉的是——更复杂的系统，并不意味着更好的结果。Anthropic 在 2025 年的研究表明，多 Agent 系统消耗的 token 是单 Agent 的 15 倍，但在很多任务上，单 Agent 的表现反而更好。

那问题来了：我们到底需要怎样的 AI 系统架构？什么时候该简单，什么时候该复杂？

今天就来聊聊这件事。从最简单的一次 API 调用开始，一步步走到多 Agent 城邦，看看每一步到底解决了什么问题，又引入了什么新问题。

---

一次 API 调用能走多远？

2023 年初，绝大多数 AI 应用的架构长这样：

用户输入 → 拼接 Prompt → 调用 LLM API → 返回结果。

就这么简单。一个 HTTP 请求，一个 JSON 响应，完事。

这个模式能解决的问题超乎你的想象。写邮件、翻译文档、生成代码、总结会议纪要——对于"输入明确、输出明确"的任务，单次 API 调用的效果已经非常好了。

但它有一个致命的限制：没有"过程"。

打个比方。单次 API 调用就像闭卷考试——你把题目给模型，它凭"记忆"（训练数据）答题。答对了皆大欢喜，答错了，你只能换个问法再来一遍。

它不能中途查资料，不能分步骤推进，不能根据中间结果调整策略。

更要命的是，它"记不住事"。你跟 ChatGPT 聊了 50 轮，第 51 轮的时候，前面的对话可能已经被截断了。不是它不想记，是上下文窗口就那么大，装不下了。

于是，第一批"架构师"出现了。他们开始在 LLM API 外面包一层逻辑：把大任务拆成小步骤，每步调用一次 API，中间结果存到变量里，最后拼成完整输出。

这就是最早的"链式调用"（Chain），也是 LangChain 名字的由来。

但链条越长，问题越多。某一步出错了怎么办？中间需要人工判断怎么办？任务之间有依赖怎么办？

单次调用的尽头，是系统工程的起点。

---

给 LLM 装上手脚，改变了什么？

2024 年，AI 架构迎来了第一次质变：Tool Use（工具调用）。

在此之前，LLM 就像一本百科全书——什么都知道一点，但只能"说"，不能"做"。你问它"北京今天多少度"，它只能根据训练数据瞎猜，因为它接触不到实时天气 API。

Tool Use 改变了这个局面。它让 LLM 不再只是一个"嘴巴"，而是长出了"手脚"。

具体怎么实现的？其实原理很简单：

# LLM 不直接回答，而是决定调用哪个工具
response = llm.chat(
    messages=[{"role": "user", "content": "北京今天多少度？"}],
    tools=[weather_api, search_api, calculator]
)
# LLM 返回：我要调用 weather_api，参数是 city="北京"
# 系统执行工具，拿到结果，再喂回给 LLM 生成最终答案

关键在第 3 行——你把一组"工具清单"告诉 LLM，它自己判断该用哪个。这不是写死的 if-else，是模型根据语义理解做出的决策。

但 Tool Use 带来了一个新问题：工具接入太碎了。

每个 LLM 厂商定义工具的格式不一样，每个工具的接口也不一样。你给 Claude 写了一套工具配置，换到 GPT 上全得重来。这就像每个手机品牌都用不同的充电口——用户苦不堪言。

于是 Anthropic 在 2024 年底推出了 MCP（Model Context Protocol）——一个开放标准，让所有 LLM 和所有工具之间有了统一的"USB 接口"。

截至 2026 年 5 月，MCP 已经被纳入 Linux 基金会旗下的 AAIF（AI & Agents Foundation），有 146 家成员组织支持，包括 OpenAI、Google、Microsoft、AWS。它从 Anthropic 的"自家协议"变成了行业标准。

有了工具，LLM 的能力边界一下子被打开了。它不再只能"生成文本"，而是可以查数据库、调 API、读写文件、执行代码。

但这也引出了下一个问题：工具越多，任务越复杂，Agent 需要跨越多个步骤、多轮对话才能完成一件事。

那中间的信息怎么保存？上一步的结论，下一步还记得住吗？

工具不是锦上添花，是从"能说"到"能做"的分水岭。但能做事的 Agent，必须先解决一个更基础的问题——记忆。

---

记忆力决定了 Agent 的天花板？

你有没有这种体验：跟 AI 聊了半小时，突然发现它忘了你前面说过的关键信息，开始"一本正经地胡说八道"？

这不是 AI 的 bug，而是它的"出厂设定"——LLM 天生没有记忆。每次对话都是一张白纸，所谓的"上下文"只是把历史消息塞进 prompt 里重新输入而已。

对于简单任务，这无所谓。但对于需要持续运行几小时甚至几天的复杂 Agent，"记忆"就成了生死线。

2026 年，Agent 记忆架构已经形成了一套成熟的分层体系。有趣的是，它跟人脑的记忆系统惊人地相似：

记忆类型	类比	作用
情景记忆（Episodic）	你昨天干了什么	记录"发生了什么"——对话历史、操作记录
语义记忆（Semantic）	你知道地球是圆的	存储"知识和偏好"——用户习惯、业务规则
程序记忆（Procedural）	你会骑自行车	掌握"怎么做"——工作流、操作模式

这三种记忆不是学术概念，而是实打实的工程方案。

比如，当你跟一个客服 Agent 聊天，它需要情景记忆来记住"你刚才说的订单号是 20260520"；需要语义记忆来知道"这个用户是 VIP 客户，退款流程可以走快速通道"；需要程序记忆来执行"退款审批需要先查库存再提交工单"这套流程。

但真正难的不是"记住"，而是"管理记忆"。

为了解决这个问题，业界发展出了多层记忆管理的架构模式。以 Letta 框架为例，它借鉴了操作系统的虚拟内存设计：热数据放在"工作记忆"（类似 CPU 缓存），温数据放在"对话缓存"（类似内存），冷数据归入"长期存储"（类似硬盘）。Agent 的记忆管理器负责在这三层之间智能调度。

另一个值得关注的趋势是 MemSync——一种把 Agent 记忆当作"分布式系统"来设计的思路。它借鉴了数据库的最终一致性模型，让记忆可以在多个会话、多个设备、多个工具之间同步，解决了"Agent A 知道但 Agent B 不知道"的跨 Agent 记忆共享问题。

2026 年，Agent 记忆市场已经达到 62.7 亿美元，预计到 2030 年将增长到 284.5 亿美元。这不是一个"锦上添花"的功能——记忆已经成为 Agent 架构中独立的、关键的基础设施层。

没有记忆的 Agent，只是一个不断失忆的天才。它可能每次都能给你一个聪明的回答，但它永远不会"成长"。

---

一个指挥官 vs 一群平等伙伴

当单个 Agent 有了工具和记忆之后，下一个自然的演进方向就是：多个 Agent 协作。

2025 年，多 Agent 系统的部署量增长了 327%。但在这波热潮背后，有一个很多人不知道的真相。

多 Agent 系统有两种主流架构——

第一种叫"指挥官模式"（Orchestrator + Subagents）：一个总指挥拥有全局上下文，把任务拆解后派发给一群子 Agent，每个子 Agent 独立执行，完成后把结果压缩成摘要汇报给总指挥。

第二种叫"圆桌模式"（Peer Collaboration）：没有上下级，所有 Agent 地位平等，像开圆桌会议一样互相讨论、互相纠正，最后达成共识。AutoGen 的 GroupChat 就是典型代表。

猜猜哪种赢了？

答案是：指挥官模式碾压了圆桌模式。

2026 年，Anthropic、OpenAI、Microsoft、LangChain 几乎不约而同地收敛到了指挥官模式。圆桌模式悄悄退出了主流舞台。

为什么？

打个比方。圆桌模式就像让 5 个实习生在一个群里讨论方案——每个人都在发消息，每个人都在回复所有人，信息量爆炸式增长。3 个 Agent 互相对话，消息数是 O(n²)；5 个 Agent 就变成了一场混战。

而指挥官模式像一个经理带 5 个下属——经理分配任务，下属各干各的，干完汇报。信息流是 O(n)，清晰、可控、高效。

那多 Agent 到底什么时候值得用？根据 AORCHESTRA 等框架的实测数据，三种场景下多 Agent 有明显优势：

• 可并行的读密集型任务：比如同时搜索 5 个数据源，GAIA/SWE-Bench 基准测试上提升了 16.28%
• 窄领域高可靠性任务：Drammeh 的安全事件响应研究中，多 Agent 的可执行建议率达到 100%，而单 Agent 只有 1.7%
• 安全隔离需求：计费系统和工程系统需要不同的权限边界，天然适合拆成独立 Agent

而对于串行任务和共享状态密集的任务，多 Agent 反而是在增加复杂度和成本。

这里有一段小插曲值得聊聊。2025 年中，有一波"Agent 越多越好"的热潮，不少团队动辄上 10 个 Agent 协作。结果发现，系统调试的难度呈指数级增长，一个 Agent 的幻觉会像多米诺骨牌一样传导到整个链路。Anthropic 后来在文档中专门强调："vague enough that subagents misinterpreted the task"是最常见的多 Agent 失败模式。

子 Agent 的"合同"必须写得无比清晰：任务目标、输出格式、工具范围、边界条件，缺一不可。

15 倍的 token 成本，换来的不是 15 倍的效果。多 Agent 不是银弹，而是一把需要极高操控技巧的手术刀。

---

Agent 之间怎么"说话"？

如果说 Tool Use 解决了"Agent 怎么跟工具沟通"，那下一个必须回答的问题是：Agent 之间怎么互相沟通？

这就是 2025-2026 年最热闹的"协议大战"。

目前有三个主要选手：

• MCP（Model Context Protocol）：Anthropic 发起，解决"Agent ↔ 工具"的通信。把它想象成 USB 接口——让 Agent 能即插即用地连接任何外部工具和数据源。
• A2A（Agent-to-Agent Protocol）：Google 发起，解决"Agent ↔ Agent"的通信。把它想象成 Wi-Fi 协议——让不同的 Agent 能互相发现、协商能力、委派任务。
• ACP（Agent Communication Protocol）：IBM/BeeAI 发起，聚焦"异构 Agent 网络"。把它想象成 蓝牙协议——面向更松散、更开放的 Agent 组网场景。

很多人看到三个协议，第一反应是"又来了，标准之争，最后一个都赢不了"。

但有意思的是，这次的结局可能不一样。

2025 年 12 月，MCP 和 A2A 同时被纳入 Linux 基金会旗下的 AAIF（AI & Agents Foundation），146 家成员组织共同治理，OpenAI、Anthropic、Google、Microsoft、AWS 都是创始成员。

这就像 USB 和 Wi-Fi 最终都归 IEEE/Linux 基金会管理一样——它们不是竞争关系，而是协议栈的不同层。MCP 管"Agent 到工具"，A2A 管"Agent 到 Agent"，各守一层。

A2A 协议在 2026 年初达到了 v1.0，它的核心设计哲学是"Agent Card"——每个 Agent 用一个 JSON 文件声明自己的能力、接受的输入格式和安全要求。其他 Agent 通过读取这个"名片"来决定要不要跟它合作、怎么合作。

{
  "name": "financial-analyst",
  "description": "分析财务数据并生成投资建议",
  "capabilities": ["data_analysis", "chart_generation"],
  "input_schema": {"type": "object", "properties": {"ticker": {"type": "string"}}},
  "auth_required": true,
  "max_concurrent_tasks": 5
}

这段 Agent Card 声明了一个财务分析 Agent 的能力边界。其他 Agent 看到这个"名片"，就知道可以给它发什么任务、不能发什么任务。

但我要泼一盆冷水：截至 2026 年 5 月，绝大多数生产级 AI 系统还没有用到 A2A。跨组织的 Agent 协作（你的 Agent 调我的 Agent）在技术上可行了，但在信任、安全、计费上还有大量未解决的问题。

这就像 2010 年的微服务——每个人都在谈 REST API，但真正做到"服务网格"级别的跨团队协作，又花了整整五年。

协议之战的终局，不是谁赢，是都活着——各守一层，各解决一类问题。真正的挑战不在协议本身，而在协议之上的信任机制。

---

下一站：AI 架构师的时代

回顾这条演进路线：

单次 API 调用 → 链式编排 → Tool Use → Memory 层 → 多 Agent 协作 → 通信协议标准化。

每一步都在解决上一步遗留的瓶颈，每一步也都在引入新的复杂度。

有一件事我越来越确信：2026 年以后，AI 领域最稀缺的人才不是"懂模型的人"，而是"能驾驭复杂 AI 系统的架构师"。

为什么？因为模型能力的提升是"厂商的事"——你不需要自己训模型，等着 OpenAI 和 Anthropic 升级就行。但怎么把模型能力编排成一个可靠、高效、可维护的系统——这是"你的事"。

就像互联网时代，"会写代码"是入门门槛，但真正值钱的是能设计高并发、高可用架构的系统架构师。AI 时代也一样，"会调 API"是入门门槛，真正值钱的是能设计 Agent 编排、记忆管理、工具生态、通信协议的 AI 系统架构师。

我做两个预测，给自己设个 deadline：

• 2026 年底之前，"AI System Architect"（AI 系统架构师）会成为一个独立的、被大厂认可的岗位，薪资对标 Staff Engineer。
• 2027 年 Q2 之前，市面上的主流 Agent 框架会从"拼功能"转向"拼简化"——谁能用最少的代码让开发者构建可靠的多 Agent 系统，谁就赢。就像 Web 框架从 Struts 演进到 Rails 一样，Agent 框架的"Rails 时刻"即将到来。

半年后回来看看，我说得对不对。

在那之前，如果你只记住这篇文章的一句话，我希望是这句：

最强大的 AI 系统，不是模型最强的那个，而是架构最合理的那个。选对架构，一个 Agent 就够了；选错架构，十个 Agent 也是一团乱麻。