09f - 架构选择决策框架

本文是《AI Agent 实战手册》第 9 章第 6 节。 上一节：09e-Agent架构模板 | 下一节：10a-多Agent协作概述

概述

选择 AI Agent 架构是系统设计中最关键的决策之一——它决定了成本结构、可靠性上限和扩展路径。2025-2026 年，随着单 Agent 能力的飞速提升和多 Agent 框架的成熟，“什么时候该用单 Agent、什么时候该上多 Agent、什么时候需要层级编排”成为每个 AI 工程师必须回答的问题。本节提供一套系统化的决策框架，包含评分矩阵、决策树、成本模型和迁移路径，帮助你在三大架构范式之间做出理性选择。

1. 三大架构范式概览

1.1 架构范式定义

在深入决策框架之前，先明确三种架构范式的核心特征：

1.2 架构关系图

1.3 各架构详解

单 Agent 架构——“一人多能”

单 Agent 架构是最简单也最成熟的模式。一个 LLM Agent 配备多个工具（搜索、代码执行、文件操作等），通过 Agentic Loop 自主完成任务。2025-2026 年，随着 Claude Sonnet 4、GPT-4o 等模型能力的大幅提升，单 Agent 能处理的任务复杂度远超预期。

核心优势：

• 零协调开销——没有 Agent 间通信，延迟最低
• 调试简单——单一执行链路，问题定位直观
• 成本可控——只有一个 LLM 调用链
• 上下文一致——所有信息在同一个上下文窗口内

核心局限：

• 上下文窗口限制——单个 Agent 无法同时处理超大量信息
• 单点故障——Agent 推理出错则整个任务失败
• 无法真正并行——工具调用是串行的（除非框架支持并行工具调用）

适用场景：客服 Chatbot、编码助手、简单的 RAG 问答、单一领域的自动化任务。

多 Agent 协作——“专家团队”

多 Agent 协作模式将任务分配给多个专业化 Agent，每个 Agent 负责特定领域（如一个负责搜索、一个负责分析、一个负责写作）。Agent 之间通过消息传递或共享状态进行协作。CrewAI 的”角色制”和 AutoGen 的”对话制”是两种典型实现。

核心优势：

• 专业化分工——每个 Agent 有独立的系统提示词和工具集
• 并行执行——多个 Agent 可同时工作，缩短总耗时
• 容错性——单个 Agent 失败不影响其他 Agent
• 可扩展——新增能力只需添加新 Agent

核心局限：

• 协调复杂——Agent 间通信和状态同步是主要挑战
• 成本倍增——每个 Agent 都消耗独立的 token
• 可靠性下降——研究显示多 Agent 系统在复杂任务上的失败率可达 41-87%
• 调试困难——分布式执行链路难以追踪

适用场景：多领域研究、内容生产管线、需要多角色协作的复杂工作流。

层级编排架构——“指挥官+执行者”

层级编排架构引入一个”编排者”（Orchestrator）Agent，负责任务分解、子任务分配和结果聚合。子 Agent 各自独立执行，完成后向编排者汇报。Anthropic 的 Claude Subagent 和 LangGraph 的状态图是典型实现。

核心优势：

• 集中控制——编排者掌握全局状态，决策更优
• 并行+可控——子 Agent 并行执行，编排者统一协调
• 上下文压缩——每个子 Agent 只需处理子任务相关的上下文
• 可观测性好——编排者是天然的监控点

核心局限：

• 编排者是瓶颈——编排者的推理质量决定整个系统的上限
• Token 消耗高——Anthropic 内部测试显示 token 消耗可达单 Agent 的 15 倍
• 架构复杂——需要设计任务分解策略、结果聚合逻辑、错误恢复机制
• 延迟叠加——编排者的规划时间 + 子 Agent 执行时间

适用场景：深度研究、大型代码库重构、复杂的多步骤业务流程、需要高可靠性的生产系统。

2. 六维评估模型

选择架构不是拍脑袋决定的。以下六个维度构成了系统化的评估框架：

2.1 评估维度定义

2.2 评分矩阵

对每个维度，按 1-5 分评估你的项目需求，然后查看推荐架构：

评分结果对照表：

2.3 评分示例

案例：电商客服机器人

加权总分 = 2×0.25 + 3×0.20 + 1×0.20 + 5×0.15 + 1×0.10 + 1×0.10 = 2.25 → 推荐单 Agent 架构

案例：AI 深度研究系统

加权总分 = 5×0.25 + 4×0.20 + 4×0.20 + 1×0.15 + 3×0.10 + 3×0.10 = 3.60 → 推荐层级编排架构

3. 决策树

当你不确定该选哪种架构时，按以下决策树逐步回答问题：

3.1 快速决策树

3.2 决策检查清单

在做最终决定前，用以下清单验证你的选择：

选择单 Agent 前的检查清单

• 任务步骤 ≤ 10 步
• 只需要 1-2 个专业领域
• 上下文窗口足够容纳所有必要信息
• 延迟要求 < 10 秒
• 每次调用预算 < $0.10
• 团队没有多 Agent 开发经验
• 不需要真正的并行执行

选择多 Agent 协作前的检查清单

• 任务需要 3+ 个不同专业领域
• 子任务之间需要频繁交互和协商
• 没有明确的”指挥者”角色
• 团队有 3+ 人且有 Agent 开发经验
• 可以接受 30 秒以上的延迟
• 每次调用预算 > $0.50
• 已经评估过单 Agent 无法满足需求

选择层级编排前的检查清单

• 任务可以清晰分解为独立子任务
• 子任务可以并行执行
• 需要集中的状态管理和错误恢复
• 需要高可靠性（> 99%）
• 每次调用预算 > $1.00
• 团队有 5+ 人或有专职 AI 架构师
• 有完善的监控和可观测性基础设施

4. 成本对比模型

4.1 工具推荐

4.2 三种架构的成本模型

以一个”分析竞品并生成报告”的任务为例，对比三种架构的成本：

单 Agent 架构成本

任务：分析 3 个竞品，生成对比报告
模型：Claude Sonnet 4

执行流程（串行）：
  搜索竞品 A → 分析 → 搜索竞品 B → 分析 → 搜索竞品 C → 分析 → 生成报告

Token 消耗估算：
  - 系统提示词：~2,000 tokens
  - 每次搜索+分析：~5,000 input + ~2,000 output × 3 次
  - 报告生成：~10,000 input + ~3,000 output
  - 总计：~27,000 input + ~9,000 output

成本：27K × $3/1M + 9K × $15/1M = $0.081 + $0.135 = ~$0.22
延迟：~60-90 秒（串行执行）

多 Agent 协作成本（CrewAI 风格）

任务：同上
模型：Claude Sonnet 4 × 4 个 Agent

Agent 分工：
  - 搜索 Agent：负责信息采集
  - 分析 Agent：负责竞品分析
  - 写作 Agent：负责报告生成
  - 审查 Agent：负责质量审查

Token 消耗估算：
  - 每个 Agent 独立系统提示词：~2,000 × 4 = 8,000 tokens
  - Agent 间消息传递：~3,000 tokens × 6 次交互 = 18,000 tokens
  - 搜索 Agent：~15,000 input + ~6,000 output
  - 分析 Agent：~12,000 input + ~4,000 output
  - 写作 Agent：~10,000 input + ~3,000 output
  - 审查 Agent：~8,000 input + ~2,000 output
  - 总计：~71,000 input + ~15,000 output

成本：71K × $3/1M + 15K × $15/1M = $0.213 + $0.225 = ~$0.44
延迟：~40-60 秒（部分并行）
成本倍数：单 Agent 的 ~2x

层级编排架构成本（LangGraph / Claude Subagent 风格）

任务：同上
模型：Claude Opus 4（编排者）+ Claude Sonnet 4（子 Agent）× 3

执行流程：
  编排者规划 → 并行派发 3 个子 Agent → 子 Agent 各自搜索+分析 → 编排者聚合 → 生成报告

Token 消耗估算：
  - 编排者规划：~3,000 input + ~1,000 output（Opus 4）
  - 3 个子 Agent 各自：~7,000 input + ~3,000 output（Sonnet 4）
  - 编排者聚合+报告：~15,000 input + ~4,000 output（Opus 4）
  - 总计 Opus 4：~18,000 input + ~5,000 output
  - 总计 Sonnet 4：~21,000 input + ~9,000 output

成本：
  Opus 4: 18K × $15/1M + 5K × $75/1M = $0.27 + $0.375 = $0.645
  Sonnet 4: 21K × $3/1M + 9K × $15/1M = $0.063 + $0.135 = $0.198
  总计：~$0.84
延迟：~30-45 秒（子 Agent 并行）
成本倍数：单 Agent 的 ~3.8x

4.3 成本对比总览

⚠️ 以上数据为估算值，实际成本取决于任务复杂度、模型选择和 token 消耗。建议使用 LangSmith/Langfuse 追踪实际成本。

5. 架构迁移路径

5.1 渐进式演进策略

架构选择不是一次性决定。最佳实践是从简单开始，按需演进。以下是推荐的迁移路径：

5.2 阶段 1 → 阶段 2：工具增强

触发信号：

• 单 Agent 的回答质量下降（缺乏专业知识）
• 上下文窗口经常接近上限
• 用户反馈”回答不够深入”

迁移步骤：

步骤 1：添加 RAG 检索

# 从直接回答升级为 RAG 增强回答
# 之前：Agent 仅依赖模型内置知识
# 之后：Agent 先检索知识库，再基于检索结果回答
 
from langchain.tools import tool
 
@tool
def search_knowledge_base(query: str) -> str:
    """搜索内部知识库获取准确信息"""
    results = vector_store.similarity_search(query, k=5)
    return "\n".join([doc.page_content for doc in results])
 
# 将工具添加到 Agent
agent_tools.append(search_knowledge_base)

步骤 2：添加专业工具

# 根据任务需求添加专业工具
@tool
def analyze_code(file_path: str) -> str:
    """使用 AST 分析代码结构"""
    # ...
 
@tool
def run_tests(test_path: str) -> str:
    """执行测试并返回结果"""
    # ...
 
agent_tools.extend([analyze_code, run_tests])

步骤 3：优化上下文管理

# 实现上下文压缩，避免窗口溢出
def compress_context(messages: list, max_tokens: int) -> list:
    """当消息历史超过阈值时，压缩早期消息为摘要"""
    if count_tokens(messages) > max_tokens * 0.8:
        early_messages = messages[:len(messages)//2]
        summary = llm.summarize(early_messages)
        return [{"role": "system", "content": summary}] + messages[len(messages)//2:]
    return messages

迁移成本：低（1-2 天），不改变核心架构。

5.3 阶段 2 → 阶段 3：引入层级编排

触发信号：

• 单 Agent 执行时间过长（> 2 分钟）
• 任务可以明确拆分为独立子任务
• 需要并行处理以降低延迟
• 单 Agent 的错误率上升（任务太复杂）

迁移步骤：

步骤 1：识别可并行的子任务

原始单 Agent 流程（串行）：
  搜索 A → 分析 A → 搜索 B → 分析 B → 搜索 C → 分析 C → 综合报告

拆分后（可并行）：
  编排者规划 → [搜索+分析 A] || [搜索+分析 B] || [搜索+分析 C] → 编排者综合

步骤 2：实现编排者

# LangGraph 层级编排示例
from langgraph.graph import StateGraph, END
from typing import TypedDict
import asyncio
 
class ResearchState(TypedDict):
    query: str
    sub_tasks: list[str]
    sub_results: dict[str, str]
    final_report: str
 
def plan_research(state: ResearchState) -> ResearchState:
    """编排者：分解任务"""
    sub_tasks = llm.invoke(
        f"将以下研究任务分解为 3 个独立子任务：{state['query']}"
    )
    return {**state, "sub_tasks": sub_tasks}
 
async def execute_sub_task(task: str) -> str:
    """子 Agent：执行单个子任务"""
    result = await llm.ainvoke(
        f"你是一个研究助手。请完成以下任务：{task}"
    )
    return result
 
async def parallel_execution(state: ResearchState) -> ResearchState:
    """并行执行所有子任务"""
    tasks = [execute_sub_task(t) for t in state["sub_tasks"]]
    results = await asyncio.gather(*tasks)
    return {**state, "sub_results": dict(zip(state["sub_tasks"], results))}
 
def synthesize(state: ResearchState) -> ResearchState:
    """编排者：聚合结果"""
    report = llm.invoke(
        f"基于以下研究结果生成综合报告：{state['sub_results']}"
    )
    return {**state, "final_report": report}

步骤 3：添加错误恢复

def execute_with_retry(state: ResearchState) -> ResearchState:
    """带重试的子任务执行"""
    for task in state["sub_tasks"]:
        for attempt in range(3):
            try:
                result = execute_sub_task(task)
                state["sub_results"][task] = result
                break
            except Exception as e:
                if attempt == 2:
                    state["sub_results"][task] = f"[失败] {str(e)}"
    return state

迁移成本：中（3-5 天），需要重构执行流程。

5.4 阶段 3 → 阶段 4：混合多 Agent 架构

触发信号：

• 子 Agent 之间需要动态协商（不是简单的任务分配）
• 需要”辩论”或”投票”机制来提高决策质量
• 系统需要处理高度不确定的开放式任务

迁移步骤：

步骤 1：在层级编排基础上添加 Agent 间通信

# 在编排者框架内引入 Agent 间协商
class DebateState(TypedDict):
    topic: str
    agent_a_position: str
    agent_b_position: str
    rounds: int
    consensus: str | None
 
def agent_debate(state: DebateState) -> DebateState:
    """两个 Agent 就某个问题进行辩论"""
    for round in range(state["rounds"]):
        # Agent A 提出观点
        a_response = llm.invoke(
            f"你持正方立场。对方观点：{state['agent_b_position']}。"
            f"请反驳并阐述你的观点。"
        )
        state["agent_a_position"] = a_response
 
        # Agent B 反驳
        b_response = llm.invoke(
            f"你持反方立场。对方观点：{state['agent_a_position']}。"
            f"请反驳并阐述你的观点。"
        )
        state["agent_b_position"] = b_response
 
    # 编排者判断共识
    consensus = llm.invoke(
        f"基于以下辩论，总结共识：\n正方：{state['agent_a_position']}\n反方：{state['agent_b_position']}"
    )
    return {**state, "consensus": consensus}

迁移成本：高（1-2 周），需要设计通信协议和协商机制。

5.5 迁移路径总览

💡 关键原则：永远不要跳过阶段。从阶段 1 直接跳到阶段 4 几乎必然失败。每个阶段都是下一个阶段的基础。

6. 操作步骤：架构选择实战流程

步骤 1：需求分析

请回答以下问题，明确你的 Agent 系统需求：

1. 核心任务描述：[用一句话描述 Agent 要完成的任务]
2. 任务步骤数：[预估完成任务需要多少步]
3. 涉及领域数：[需要几个专业领域的知识]
4. 是否可并行：[任务的子部分能否同时执行？是/否]
5. 延迟要求：[用户可接受的最大等待时间]
6. 每次预算：[单次任务执行的成本上限]
7. 月调用量：[预估每月调用次数]
8. 团队规模：[负责开发和维护的人数]
9. 可靠性要求：[可接受的失败率是多少]
10. 是否需要人工审批：[关键步骤是否需要人工确认？是/否]

步骤 2：六维评分

根据步骤 1 的回答，对六个维度打分（1-5）：

任务复杂度：[  ] 分
可靠性要求：[  ] 分
成本预算：  [  ] 分
延迟要求：  [  ] 分
团队规模：  [  ] 分
可维护性：  [  ] 分

加权总分 = 复杂度×0.25 + 可靠性×0.20 + 成本×0.20 + 延迟×0.15 + 团队×0.10 + 维护×0.10
         = [  ]

步骤 3：决策树验证

按照第 3 节的决策树回答问题，确认评分结果与决策树推荐一致。
如果不一致，重新审视评分是否准确。

步骤 4：成本估算

使用第 4 节的成本模型，估算选定架构的：
- 单次执行成本：$[  ]
- 月度总成本：$[  ]（基于预估调用量）
- 与备选架构的成本差异：[  ]x

确认成本在预算范围内。

步骤 5：制定迁移计划

如果选择了单 Agent 架构，提前规划：
- 什么条件下需要升级到层级编排？
- 升级的触发指标是什么？（延迟 > Xs、错误率 > Y%、成本 > $Z）
- 预留哪些扩展点？

提示词模板：架构选择咨询

你是一个 AI Agent 架构顾问。请根据以下项目需求，推荐最合适的架构方案。

## 项目需求
- 核心任务：[描述]
- 任务复杂度：[低/中/高]
- 延迟要求：[秒级/十秒级/分钟级]
- 每次预算：[$X]
- 月调用量：[N 次]
- 团队规模：[N 人]
- 可靠性要求：[N%]

## 请输出
1. 推荐架构（单 Agent / 多 Agent 协作 / 层级编排）及理由
2. 推荐的模型和框架组合
3. 预估成本（单次 + 月度）
4. 关键风险和缓解措施
5. 未来扩展建议（什么时候需要升级架构）

实战案例：三个真实场景的架构选择

案例 1：SaaS 产品智能客服

背景：一个 B2B SaaS 产品需要 AI 客服，处理用户咨询、查询订单、解答产品问题。

需求分析：

• 任务步骤：3-5 步（理解问题→查知识库→回答/转人工）
• 涉及领域：1 个（产品知识）
• 延迟要求：< 3 秒
• 每次预算：< $0.05
• 月调用量：50,000 次
• 可靠性：95%（允许 5% 转人工）

六维评分：

决策：✅ 单 Agent 架构

方案：

• 模型：GPT-4o-mini（低成本、快速响应）
• 工具：知识库搜索（RAG）、订单查询 API、转人工工具
• 成本：~$0.02/次 × 50,000 = ~$1,000/月
• 框架：直接使用 OpenAI API + 自定义工具

迁移预案：当产品线扩展到 3+ 个产品时，考虑升级为层级编排（一个路由 Agent + 多个产品专家子 Agent）。

案例 2：AI 驱动的代码审查系统

背景：一个开发团队需要 AI 自动审查 Pull Request，检查代码质量、安全漏洞、性能问题和测试覆盖率。

需求分析：

• 任务步骤：10-15 步（解析 PR→分析代码→检查安全→检查性能→检查测试→生成报告）
• 涉及领域：4 个（代码质量、安全、性能、测试）
• 延迟要求：< 2 分钟
• 每次预算：< $2.00
• 月调用量：3,000 次
• 可靠性：90%（允许漏检，但不能误报）

六维评分：

决策：✅ 层级编排架构

方案：

• 编排者：Claude Sonnet 4（解析 PR、分配子任务、聚合报告）
• 子 Agent 1：安全审查 Agent（Claude Sonnet 4 + 安全规则库）
• 子 Agent 2：性能审查 Agent（Claude Sonnet 4 + 性能 lint 工具）
• 子 Agent 3：测试覆盖 Agent（Claude Haiku 4 + 覆盖率工具）
• 子 Agent 4：代码风格 Agent（Claude Haiku 4 + ESLint/Prettier）
• 成本：~$0.80/次 × 3,000 = ~$2,400/月
• 框架：LangGraph 状态图

关键设计：4 个子 Agent 并行执行，编排者聚合结果并生成统一报告。安全审查使用更强的模型，代码风格使用轻量模型降低成本。

案例 3：多领域深度研究平台

背景：一个咨询公司需要 AI 研究平台，能够对任意主题进行深度调研，生成带引用的研究报告。

需求分析：

• 任务步骤：20+ 步（规划→多源搜索→交叉验证→分析→报告→审查）
• 涉及领域：动态（取决于研究主题）
• 延迟要求：5-10 分钟可接受
• 每次预算：< $10.00
• 月调用量：500 次
• 可靠性：95%（报告必须准确）

六维评分：

决策：✅ 层级编排 + 多 Agent 协作（混合架构）

方案：

• 编排者：Claude Opus 4（研究规划、结果聚合、质量审查）
• 搜索子 Agent 组：3-5 个 Claude Sonnet 4 并行搜索不同来源
• 分析子 Agent：Claude Sonnet 4（交叉验证和深度分析）
• 写作子 Agent：Claude Opus 4（报告生成）
• 审查子 Agent：Claude Sonnet 4（事实核查和引用验证）
• 成本：~$5.00/次 × 500 = ~$2,500/月
• 框架：LangGraph（编排层）+ 自定义并行执行

关键设计：编排者负责全局规划，搜索子 Agent 并行采集信息（类似 Anthropic 的 Research 架构），分析和审查子 Agent 之间有交叉验证的协作关系。

案例对比总结

避坑指南

❌ 常见错误

1. 过早引入多 Agent 架构

   • 问题：团队在单 Agent 还没跑通的情况下就上多 Agent，结果协调开销远超收益。研究显示，70% 的 AI 任务用单 Agent 就能以 1/3 的成本达到同等效果
   • 正确做法：先用单 Agent 验证核心功能，只在明确遇到瓶颈时才升级架构

2. 忽视协调失败率

   • 问题：多 Agent 系统的可靠性不是各 Agent 可靠性的简单乘积。5 个 Agent 各 90% 可靠，系统可靠性可能只有 33%（0.9^5 × 协调因子）
   • 正确做法：在架构设计阶段就计算端到端可靠性，为每个协调点添加重试和降级机制

3. 所有子 Agent 都用最贵的模型

   • 问题：编排者和所有子 Agent 都用 Claude Opus 4，成本是必要的 5-10 倍
   • 正确做法：编排者用强模型（Opus 4），简单子任务用轻量模型（Haiku 4 / GPT-4o-mini），按任务复杂度路由

4. 没有设置全局预算上限

   • 问题：层级编排中编排者不断重新规划和派发子 Agent，token 消耗失控
   • 正确做法：设置全局 token 预算和最大重试次数，接近上限时强制降级或终止

5. 跳过阶段直接上最复杂的架构

   • 问题：从零开始直接构建混合多 Agent 系统，团队没有经验，项目延期 3 个月
   • 正确做法：遵循渐进式演进路径（单 Agent → 工具增强 → 层级编排 → 混合架构），每个阶段积累经验

6. 忽略延迟叠加效应

   • 问题：层级编排中编排者规划 5 秒 + 3 个子 Agent 各 10 秒 + 聚合 5 秒 = 40 秒，远超用户预期
   • 正确做法：在架构设计阶段就估算端到端延迟，确保并行执行的子 Agent 不会被最慢的那个拖累

7. 多 Agent 系统缺乏可观测性

   • 问题：多个 Agent 并行执行，出错时无法定位是哪个 Agent 在哪个步骤失败
   • 正确做法：从第一天就接入 LangSmith/Langfuse，为每个 Agent 和每次交互添加 trace

✅ 最佳实践

1. “45% 规则”：如果单 Agent 能完成任务的 45% 以上，先优化单 Agent（更好的提示词、更多工具），而不是引入多 Agent
2. Agent 数量上限：预算有限时，将 Agent 数量控制在 3-4 个以内。超过这个数量，协调开销急剧上升
3. 编排者最小权限：编排者只负责规划和路由，不直接执行任务。保持编排者的工具权限为”只读+路由”
4. 子 Agent 单一职责：每个子 Agent 只做一件事，有明确的输入/输出接口。避免”万能子 Agent”
5. 成本监控前置：在开发阶段就接入成本追踪，不要等到生产环境才发现成本超标
6. 降级策略必备：每种架构都要有降级方案——多 Agent 降级为单 Agent，层级编排降级为串行执行

相关资源与延伸阅读

1. Anthropic — How We Built Our Multi-Agent Research System  — Anthropic 官方分享的多 Agent 研究系统架构设计原则
2. Redis — AI Agent Architecture Patterns  — 架构选择对成本、可靠性和扩展路径的影响分析
3. Redis — Single-Agent vs Multi-Agent Systems  — 单 Agent 与多 Agent 的深度对比和选择指南
4. Iterathon — Multi-Agent Orchestration Economics  — 多 Agent 编排的经济学分析，70% 场景单 Agent 更优
5. Galileo — Single vs Multi-Agent Systems  — 架构选择的系统化方法论
6. Taskade — Single Agent vs Multi-Agent Teams (2026 Guide)  — 2026 年单 Agent 与多 Agent 团队的全面对比
7. LangGraph 官方文档  — 层级编排架构的参考实现
8. CrewAI 官方文档  — 角色制多 Agent 协作框架

参考来源

• How We Built Our Multi-Agent Research System — Anthropic Engineering （2025-06）
• AI Agent Architecture Patterns — Redis Blog （2026-06）
• Single-Agent vs Multi-Agent Systems — Redis Blog （2026-06）
• Multi-Agent Orchestration Economics When Single Agents Win — Iterathon （2026-01）
• Single Agent vs Multi Agent AI — Kubiya （2025-07）
• Single AI Agent vs Multi-Agent Teams — Taskade （2025-12）
• Agent Orchestration 2026: LangGraph, CrewAI & AutoGen Guide — Iterathon （2026-04）
• AI-Native Architecture in 2026: 7 Agentic AI Setups — FlowZap （2026-06）
• The Agent Complexity Spectrum: A Decision Framework — Applied AI （2025-12）
• Why Your 5-Agent System Has a 33% Success Rate — NextBuild （2025-11）
• Claude Subagents: Multi-Agent AI Systems — Cursor IDE Blog （2025-07）

📖 返回 总览与导航 | 上一节：09e-Agent架构模板 | 下一节：10a-多Agent协作概述