从 2022 年 ChatGPT 引爆生成式 AI 浪潮至今，行业叙事始终围绕一个核心命题：模型参数越大、训练数据越多、推理能力越强，产品体验就越好。这套叙事推动了一场耗资数千亿美元的算力军备竞赛，也催生了 GPT-4、Claude 3、Gemini 2.5 等一系列令人印象深刻的模型。然而，如果我们把过去四年所有真正改变用户交互方式的产品突破逐一拆解——从 CoT 推理可视化到 CodeAct 编码代理，从 MCP 工具生态到 Dynamic Workflows 多代理编排——会发现一个反直觉的规律：这些突破的本质并非模型底层能力的跃迁，而是系统工程师对 token IO 路径的重新设计。

用一个简单的比喻来说明：模型能力是引擎的排量，而 IO 架构是变速箱的齿比设计。一辆搭载 6.0L V12 引擎但匹配单速变速箱的车，在实际道路表现上可能远不如一辆 2.0T 引擎匹配 8 速双离合变速箱的车。过去四年的产品演进，本质上是一群顶尖系统工程师在反复调试「变速箱齿比」的过程——他们不是让引擎更有力，而是让每一滴燃油（token）都更高效地转化为车轮的扭矩（用户价值）。

这一洞察对产品经理和决策者具有直接的现实意义。当你评估一个 AI 产品方案时，与其追问「用了什么模型」，不如追问「token 在系统内如何流动」——不确定性被隔离在哪个环节？一次前向传播承载多少决策？历史经验如何被复用？上下文在什么粒度上被加载？这四个问题，才是决定产品体验、成本结构和扩展性的关键变量。

---

二、第一阶段（2022）：CoT / PAL / PoT——「不确定性放在哪里」

2.1 CoT：把推理过程暴露在上下文里

2022 年，Wei 等人提出的 Chain-of-Thought（CoT）Prompting 首次系统性地证明了一个简单却强大的想法：让模型在给出最终答案之前，先一步一步写出思考过程 (Claude Code Dynamic Workflows 深度解析) 。在 GSM8K 数学推理 benchmark 上，CoT 将 GPT-3 的准确率从 18% 提升到 58%，这一增幅不是靠模型微调实现的，而是完全通过改变输入提示的格式——即在问题后面追加 "Let's think step by step"。

从产品形态看，CoT 的核心设计决策是：把推理的不确定性「摊开」在上下文中，让模型（以及用户）能看到每一步的中间状态。这看似是一个简单的提示工程技巧，但其深层含义在于它重新定义了 token 的「用途分类」——在此之前，上下文中的每一个 token 要么是用户输入，要么是模型输出；CoT 之后，上下文中出现了一类新的 token：reasoning tokens（推理 token），它们不直接面向用户，而是作为模型自我校准的「草稿纸」。

然而，CoT 有一个根本性的产品缺陷：推理过程和计算过程都压在自然语言里。当多步算术介入时，错误会在每一步被放大。假设单步推理的错误率为 ε，一条 N 步推理链整链正确的概率约为 (1−ε)^N，随长度指数衰减 (Claude Code Dynamic Workflows 深度解析) 。CoT 鼓励模型把链拉得越长越好，等于把这条指数衰减曲线打满。这意味着 CoT 在很多场景里其实是一种「让模型显得在思考」的表演——它的真正价值更接近「给模型多一点 token 算预算」，而不是「更可靠的推理路径」。

2.2 PAL / PoT：把不确定性锁在 Python 解释器门口

几乎与 CoT 同期，两篇关键论文给出了同一个直觉：把推理这件事拆开。PAL（Program-aided Language Models，Gao 等，2022）让模型把自然语言问题翻译成可运行的 Python 程序，再把求解步骤外包给 Python 解释器；模型只负责「写出怎么算」，不负责「算对」 (Claude Code Dynamic Workflows 深度解析) 。PoT（Program of Thoughts，Chen 等）走的是同一条路：把逻辑推理和数值计算解耦，用代码承担计算，把孤立步骤的累积误差砍掉。

两者在 GSM-hard、FinQA 等数学/金融基准上对 CoT 实现了 8%–40% 不等的提升 (Claude Code Dynamic Workflows 深度解析) 。这个提升幅度的意义远超数字本身——它证明了一个产品设计原则：当不确定性可以被隔离到一个确定性执行环境（如 Python 解释器）时，系统整体可靠性会跃升一个数量级。

维度	CoT (Chain-of-Thought)	PAL (Program-Aided Language)
不确定性位置	分布在自然语言推理链的每一步	集中在「自然语言→代码」的翻译环节
计算执行者	模型自身（next-token 采样）	Python 解释器（确定性执行）
错误传播模式	指数衰减：(1−ε)^N	线性可控：翻译错误 + 执行错误
上下文占用	推理链全部摊开在上下文中	仅保留程序代码和最终输出
典型提升幅度	GSM8K: 18%→58%	GSM-hard: +8%–40% vs CoT
产品形态	推理过程可见（透明度高）	中间计算黑盒化（效率优先）

这一阶段的 IO 架构博弈，本质上是 「不确定性治理」 的策略选择。CoT 选择了透明但脆弱的方案（全部暴露在上下文中），PAL 选择了隔离但黑盒的方案（把不确定性锁在解释器门口）。这个权衡框架至今仍在影响产品设计——2025 年 OpenAI o3 的隐藏推理链 vs DeepSeek R1 的可见思维链，正是这一博弈的延续。

---

三、第二阶段（2023）：ReAct / CodeAct——「一次 forward 写多少」

3.1 ReAct：推理与行动的交错舞步

2023 年，Yao 等人提出的 ReAct（Reasoning + Acting）框架将 CoT 的思路扩展到了一个更广阔的领域：让模型在推理和行动之间交替进行 (arXiv.org) 。与 CoT 只「思考」不「行动」不同，ReAct 的每一次 forward 都包含两个部分：先输出一段自然语言推理（Thought），再输出一个行动指令（Action）——可能是调用搜索工具、查询数据库或执行代码。观察环境返回结果后，模型进入下一轮推理-行动循环。

ReAct 的产品形态意义在于它定义了 Agent 循环的基本节拍：Think → Act → Observe → Think → ... 这个循环成为了此后几乎所有 Agent 框架的底层节拍器。但 ReAct 也引入了一个根本性的 IO 效率问题：每一步推理和行动都需要一次完整的前向传播，而每次前向传播的上下文都要携带完整的历史记录（之前的所有 Thought、Action、Observation）。这意味着随着任务步骤的增加，上下文长度线性增长，而每步的边际成本保持不变。

3.2 CodeAct：用代码统一行动空间

2024 年，Wang 等人提出的 CodeAct 给出了一个更激进的答案：直接把可执行 Python 代码作为唯一的行动空间 (arXiv.org) 。在 CodeAct 架构中，模型不再输出离散的「工具调用」指令，而是直接编写一段 Python 代码，由解释器执行。这段代码可以包含循环、条件判断、变量赋值、函数定义——本质上，模型在一次 forward 中可以表达任意复杂的计算逻辑。

CodeAct 的 IO 效率优势是显著的。传统 ReAct 需要 10 次 forward 才能完成的循环+条件逻辑，CodeAct 可以在 1 次 forward 中通过一段 Python 代码完成。这不是模型变聪明了，而是一次 forward 承载的「信息量」发生了质变——从单个工具调用的粒度，提升到了完整程序脚本的粒度。

维度	ReAct	CodeAct
一次 forward 的输出	一段 Thought + 一个 Action	一段可执行 Python 代码
循环/条件表达	需多轮 forward 实现	单轮 forward 内完成
上下文增长模式	线性增长（每步追加）	亚线性增长（代码压缩逻辑）
错误恢复成本	低（单步失败可重试）	高（代码失败需重新生成）
适用场景	探索性任务、需人类监督	确定性计算、批处理任务
代表产品	早期 ChatGPT Plugins、Perplexity	Claude Code、OpenAI Codex

2025-2026 年，这一博弈的最新变体是 OpenAI Codex 的 Goal Mode 与 Claude Code 的 Dynamic Workflows。Codex Goal Mode 让模型在单次会话中自主工作「数小时甚至数天」，本质上是把一次 forward 的边界扩展到了极端——整个工作流变成了一次超长的「代码生成+执行」过程 (QCode.cc) 。而 Claude Dynamic Workflows 则走了另一条路：Claude 动态生成 JavaScript 编排脚本，在运行时独立调度和验证数百个并行子代理 (Claude) 。两者都在回答同一个问题，但给出了不同的答案：Codex 选择「一次 forward 写尽可能多的代码」，Dynamic Workflows 选择「一次 forward 写一个编排器，让它去管理更多 forward」。

---

四、第三阶段（2024）：Voyager / Skills / MCP——「跑过的东西如何复用」

4.1 Voyager：技能库作为外部记忆

2023 年的 Voyager 项目（Wang 等）首次系统性地将「技能复用」作为 Agent 架构的一等公民 (arXiv.org) 。在 Minecraft 开放世界环境中，Voyager 不仅让 Agent 完成任务，更重要的是把成功的任务执行轨迹提取为可复用的代码技能（skill），存入一个外部技能库。当遇到新任务时，Agent 先检索相关技能，再加载到上下文中指导执行。

Voyager 的 IO 架构创新在于它引入了一个 「技能缓存层」——介于模型参数（长期记忆）和上下文窗口（工作记忆）之间的一个可读写存储层。技能库中的每一项都是一个压缩后的「经验包」：包含触发条件、执行代码、使用频次和成功率。这大大降低了模型在新任务上的探索成本：不需要从零开始试错，只需要检索和组合已有技能。

4.2 Claude Code Skills：渐进式披露与团队知识管理

2025-2026 年，Anthropic 将技能概念产品化为 Claude Code Skills——一种模型自触发的可复用指令集 (Duet) 。每个 Skill 是一个包含 SKILL.md 文件的文件夹，定义了特定任务的执行流程。关键设计在于「渐进式披露」（progressive disclosure）：Claude 每轮会话只读取所有 skill 的名称和描述（约 100 tokens/skill），只有当用户请求匹配时才加载完整内容（约 5K tokens）。这意味着一个团队可以安装数十个 skill 而不会拖慢日常会话的响应速度。

Skills 的产品意义超越了技术层面——它实际上是 「团队知识」的 token 化封装。一个资深工程师的代码审查标准、一个运维团队的部署流程、一个产品经理的需求分析框架，都可以被编码为 skill 并在团队中复用。2025 年 12 月，Anthropic 将 Agent Skills 规范开源，OpenAI 随即在 Codex CLI 和 ChatGPT 中采用，Gemini CLI、Cursor 等工具也宣布兼容 (Duet) 。这标志着 skill 正在从单一产品的功能，演变为跨生态的标准化知识交换格式。

4.3 MCP：工具生态的「USB-C」时刻

2024 年 11 月，Anthropic 发布了 Model Context Protocol（MCP），旨在解决一个 N×M 的集成难题：每个 Agent 框架需要为每个外部工具写定制连接器，导致集成成本随工具数量和框架数量的乘积增长 (Anthropic) 。MCP 采用客户端-服务器模型：MCP 服务器暴露标准化的工具接口（通过 JSON-RPC），任何兼容 MCP 的 Agent 都可以调用。

MCP 的 IO 架构意义在于它将工具调用从「上下文内联」模式转变为「按需加载」模式。传统方式下，所有可用工具的 schema 都需要在每次请求时放入系统提示（system prompt）中——一个典型的 5 服务器 MCP 配置会在会话开始前占用约 55,000 tokens (Duet) 。而 MCP 支持渐进式发现：Agent 可以先获取工具目录摘要，再按需加载具体工具的详细定义，将初始上下文占用降低 98.7%（从 150,000 tokens 降至 2,000 tokens） (mbgsec.com) 。

维度	传统 Function Calling	MCP Protocol
工具发现方式	预定义 schema 全量注入	目录摘要 + 按需加载
初始上下文占用	50K-150K tokens	2K-5K tokens
工具新增成本	需修改系统提示	启动新 MCP 服务器即可
跨框架兼容性	无（各框架私有格式）	有（标准化协议）
安全性边界	工具输出直接进入上下文	支持数据脱敏和权限控制
生态规模（2026）	碎片化	150+ 组织支持，5 种 SDK 语言

---

五、第四阶段（2025-2026）：编排与标准化——A2A、Dynamic Workflows 与 Agent 框架之战

5.1 A2A 与 MCP：互补而非竞争的双层协议栈

2025 年 4 月，Google 在 Cloud Next 大会上发布了 Agent-to-Agent（A2A）协议，并于 6 月将其捐赠给 Linux Foundation (Atlan) 。A2A 的核心设计围绕三个概念：Agent Cards（能力广告卡片，发布在 /.well-known/agent-card.json）、Task Lifecycle（任务状态机：submitted → working → input-required → completed/failed）、以及基于 HTTP+SSE 的传输层 (DEV Community) 。

A2A 与 MCP 的关系是过去两年最容易被误解的话题。两者的本质区别可以用一句话概括：MCP 解决「一个 Agent 能做什么」，A2A 解决「多个 Agent 能一起做什么」 (DEV Community) 。MCP 是垂直的（Agent→Tool），A2A 是水平的（Agent→Agent）。在生产系统中，两者通常是组合使用的：A2A 负责将任务路由到正确的专家 Agent，MCP 负责为该 Agent 提供所需的工具和数据访问。

到 2026 年 4 月，A2A 已获得 150+ 组织的支持，包括 Google、Microsoft、AWS、Salesforce、SAP、ServiceNow 等 (Atlan) 。GitHub 仓库超过 22,000 stars，SDK 覆盖 Python、JavaScript、Java、Go 和 .NET 五种语言。MCP 则在 2025 年 12 月由 Anthropic 捐赠给 Linux Foundation 后，获得了 OpenAI、Google、Microsoft 等主流平台的原生支持 (futureagi.com) 。

协议层	解决的问题	核心抽象	代表实现
A2A（水平层）	Agent 之间如何发现、委托、协调	Agent Cards、Task Lifecycle、Artifacts	Google A2A、Azure AI Foundry
MCP（垂直层）	Agent 如何访问工具和数据	Tools、Resources、Prompts、Sampling	Anthropic MCP、OpenAI Agents SDK
两者组合	跨厂商多 Agent 系统	A2A 路由任务 → MCP 提供工具	企业级 Agent 架构默认模式

5.2 Agent 框架四巨头：OpenAI、Anthropic、Google、DeepSeek 的 IO 架构差异

2025-2026 年，四大 AI 实验室在 Agent 框架层面形成了鲜明差异化的 IO 架构路线：

OpenAI Agents SDK（2025 年 3 月发布） 的核心设计哲学是「极简的 Handoff」。Agent 之间通过显式的工具调用（transfer_to_agent_b）移交控制权，携带会话历史但不共享状态总线 (Morph AI) 。三层 Guardrails（input/output/tool）默认并行运行，tracing 内置于 OpenAI Traces dashboard。这个架构的优势是简单、快速原型、与 OpenAI 模型深度集成；劣势是 handoff 是线性链而非图拓扑，无原生 A2A 支持，且无内置状态持久化 (Morph AI) 。OpenAI 在 2026 年 4 月发布的 Agents SDK 2.0 增加了沙箱环境、持久执行、MCP 集成和记忆/编排能力 (Consumer Insights & Market Research Platform) 。

Claude Code Dynamic Workflows（2026 年 5 月发布） 代表了另一条极端路线：Claude 根据用户目标动态生成 JavaScript 编排脚本，运行时独立执行，管理多达 1,000 个并行子代理（16 并发上限） (Claude) 。与 OpenAI 的显式 handoff 不同，Dynamic Workflows 的协调发生在上下文窗口之外——计划存储在脚本变量中，中间结果不回流主会话，只有最终答案返回给用户 (MarkTechPost) 。这种「计划外置」设计的关键优势是：无论子代理数量多少，主 Claude 会话的上下文始终保持恒定，避免了上下文膨胀问题。Jarred Sumner 使用 Dynamic Workflows 将 Bun 从 Zig 移植到 Rust（75 万行代码，99.8% 测试通过率，11 天完成），是这一架构能力的最佳证明 (Claude) 。

Google ADK（Agent Development Kit，2025 年 4 月发布） 的设计围绕层次化 Agent 树展开：Root Agent 作为入口，Sub Agents 作为领域专家，通过 ADK 的 SequentialAgent、ParallelAgent、LoopAgent 等工作流原语组合 (博客园) 。ADK 的独特优势在于原生集成 A2A 协议和 Gemini 的 1M+ token 长上下文，以及 Vertex AI 的成熟评估和监控工具链 (infoservices.com) 。其编排模型更适合需要严格流程控制的的企业场景（如审批链、合规检查），但学习曲线相对陡峭，且强绑定 GCP 生态。

DeepSeek V4-Pro（2026 年 4 月预览） 的 IO 架构则体现了模型层与系统层的深度融合。V4-Pro 采用 1 万亿参数 MoE 架构（每 token 激活 37B），支持 100 万 token 上下文 (Github) 。其独特之处在于「思考/不思考」动态路由——模型根据任务复杂度自动决定是否进入深度推理模式，而非由外部系统硬编码规则 (arXiv.org) 。这种「模型自路由」设计简化了上层的编排逻辑，但也意味着 DeepSeek 的 IO 架构更依赖模型自身的能力，而非外部编排框架。

维度	OpenAI Agents SDK	Claude Dynamic Workflows	Google ADK	DeepSeek V4-Pro
编排范式	显式 Handoff（线性链）	动态 JS 脚本生成	层次化 Agent 树	模型自路由
并发能力	单线程顺序执行	16 并发 / 1000 总计	ParallelAgent 原生支持	MoE 专家并行
状态管理	无内置（用户自建）	脚本变量 + 进度保存	Firestore 持久化	上下文内推理链
上下文策略	全量注入（1M window）	计划外置（仅返回答案）	长上下文依赖（2M Gemini）	按需激活（37B/671B）
协议支持	MCP（2025 年 3 月集成）	MCP（原生）	A2A + MCP 双协议	Function Calli