📰 来源: 博客园
核心洞察：过去四年，从大模型产品形态的所有重要突破来看，真正驱动体验的并非模型参数量的增长，而是 token 在系统内流动方式的重新设计。CoT/PAL 在决定「不确定性放在哪里」；ReAct/CodeAct 在决定「一次 forward 写多少」；Voyager/Skills 在决定「跑过的东西如何复用」；Code Execution with MCP 在决定「上下文如何按需加载」。2025-2026 年，这场「IO 架构的设计游戏」已经升级为 Agent 框架、协议标准与编排范式的全面竞争。
一、一个被忽视的真相：模型能力不是瓶颈，token 的流动方式才是
从 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 解释器）时，系统整体可靠性会跃升一个数量级。
这一阶段的 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）。这意味着随着任务步骤的增加，上下文长度线性增长，而每步的边际成本
🔗 原文链接: 点击阅读原文
文章评论