框架萌芽

旧金山市场街南区，OpenAI的办公室。一张会议桌上摊着打印出来的用户反馈，页边用红笔圈出了同一个问题反复出现的关键词：不能做事。ChatGPT上线不到四个月，注册用户已经突破一亿。

这个数字足以让任何产品团队失去衡量标准——没有一款消费级应用达到过这种增速，连TikTok都用了九个月才跨过一亿门槛。但桌面上的反馈记录指向一个尴尬的事实：一亿用户面对的是一个被锁在浏览器里的模型。

问天气，它道歉说自己没有实时数据。让它订机票，它解释自己没有访问外部系统的权限。一个博学但手脚被绑住的囚徒，用户给它打了一个又一个一星评价，理由是“它什么都知道，但什么都做不了”。

解决思路已经在白板上画了几个月。让ChatGPT调用外部API。如果模型能接入天气服务、航班数据库、日历应用、邮件系统，它就能从聊天机器变成数字助理。

产品团队把方案命名为“插件体系”（Plugins），核心理念是让第三方开发者按照OpenAI定义的规范编写接口，ChatGPT在对话中识别用户意图，选择对应的插件，调用API，把返回结果织入回复。这个设计思路在纸面上看不出大的问题。扩展模型能力的标准做法就是给它工具。谷歌搜索、亚马逊购物、Slack消息集成——互联网历史上到处是平台开放接口后生态爆发的案例。OpenAI的产品经理们在白板上画了无数张价值链图：用户说出自然语言需求，模型翻译成API调用，外部服务返回结构化数据，模型再翻译回自然语言。ChatGPT是中枢，插件是四肢，用户是大脑。2023年3月23日，OpenAI正式公布了插件体系。

首批合作伙伴名单覆盖了数字生活的主要场景：Expedia负责旅行预订，FiscalNote提供金融数据，Instacart和Klarna各自覆盖购物比价，Kayak搜索航班，Milo比价商品，OpenTable预订餐厅，Shopify接入电商，Slack连接办公协作，Speak做语言学习，Wolfram处理数学计算，Zapier打通自动化工作流。官方博客宣布，插件以安全为核心原则设计，帮助ChatGPT获取最新信息、运行计算或使用第三方服务。

发布当天，开发者社区在X平台上迅速分裂成乐观派和怀疑派。乐观派列出了一长串可能催生的应用场景，把插件体系比作苹果发布App Store的前夜：平台方提供分发渠道和标准接口，开发者填充功能，用户享受一站式服务。这套模式在移动互联网时代被验证过无数次，如今似乎要在大模型时代重现。

怀疑派则追问安全边界：一个能调用外部API的聊天模型，如果被提示注入攻击诱导，可能做出什么？但整体情绪是兴奋的。

兴奋压过了质疑。第一批拿到插件权限的用户开始测试。反馈的涌入速度比兴奋消退得更快。

问题不是单个插件调用失败——恰恰相反，单次调用通常能正常返回结果。问题出在用户需要的不止是单次调用。

一个测试用户描述了典型场景：他需要安排一次从旧金山到纽约的商务旅行，包括航班、酒店和会议日程。ChatGPT先调用了Kayak查航班，拿到结果后没有继续查酒店，而是直接生成了回复——几个航班选项排列整齐，但旅行计划才完成了三分之一。用户追问酒店，ChatGPT才调用第二个插件，但此时它已经忘记了航班的时间信息，给出的酒店建议与航班时间冲突。用户再次追问，ChatGPT又调用了一个日历插件，但返回的结果是要求用户提供会议的具体日期——而用户一开始就说过会议日期。

这不是一个bug。这是一个架构缺陷。OpenAI的插件体系本质上是一个单步调用模型：用户输入触发意图识别，模型选择插件，调用API，返回结果。

单步调用在简单任务上表现正常——查一次天气，搜一次航班，调一次计算器。但一旦任务涉及多步推理、先后依赖、条件分支、异常处理，单步调用模型就暴露了短板。它缺少一个编排层——一个能显式定义步骤顺序、检查中间结果、决定下一步分支、处理异常回退的架构。

而编排层恰恰是外部框架正在构建的东西。在OpenAI发布插件体系的同一周，LangChain的GitHub星标数突破了八千。这个项目由哈里森·蔡斯在2022年10月创立，最初只是一个简化大模型调用的工具包。但到了2023年3月，它的核心设计已经演化成两个清晰的架构概念：链和代理。

链是一组预定义的步骤序列——先执行A，拿到结果后执行B，根据B的结果选择C或D，最后输出E。代理则更进一步：让模型自己决定调用什么工具以及以什么顺序调用，但整个决策过程被封装在一个循环里——模型做出选择，调用工具，观察结果，判断是否完成任务，如果没完成就继续循环。这正是ChatGPT插件体系缺失的那一层。

LangChain的代理模式核心逻辑并不复杂。一个循环，每次迭代中模型收到当前状态——包括用户原始任务、已完成的步骤、已获取的信息——然后输出一个行动：选择哪个工具、输入什么参数。执行工具调用，把结果追加到状态中，模型再次判断是否完成。如果判断是任务未完成，循环继续。如果判断是已完成，循环终止，输出最终结果。

这个循环的价值在于把完成任务的责任从单次调用转移到了持续迭代上。模型不需要在第一次尝试中就选对工具、给出完美答案。它可以试错——调用了一个工具，发现结果不对，调整参数再试，或者换一个工具。它可以把复杂任务拆解成多个子任务，每次只解决一个，逐步推进。它可以接受外部反馈——工具返回错误信息，它据此修改策略。

但循环结构本身引入了一个新问题：它需要地面真值。循环必须有一个终止条件，而终止条件必须是可验证的。模型判断任务已完成的依据是什么？

如果任务有明确的、可客观验证的完成标准——代码能编译通过，测试用例全部跑绿，数据成功写入数据库——那么循环可以在这个标准满足时终止。但如果任务没有这样的标准——写一篇好文章，制定一个合理的投资计划，安排一次愉快的旅行——模型只能自己判断够不够好。而模型自己判断的结果，往往是在循环三次后给出一个质量参差不齐的产物，然后宣布任务完成。

这个区别会在几个月后把AutoGPT送上天堂又推下地狱。但在2023年3月，它还没有显现。

LangChain的代理模式在开发者社区中快速传播，因为它解决了一个迫切的问题：如何让大模型完成多步任务。OpenAI的插件体系同期发布，但它的单步调用架构让开发者在尝试复合任务时撞上了一堵墙。两相对比，一个清晰的格局开始浮现：模型厂提供的是能力——模型能做什么；框架提供的是编排——如何把能力组织成任务。两者之间有一道缝隙，这道缝隙正在成为价值链上的关键一环。

3月23日之后的几周，OpenAI的开发者论坛上出现了越来越多关于插件协调的讨论。有人提出在用户端加一个任务规划器，在调用ChatGPT之前先把用户任务拆解成步骤序列，然后逐个步骤调用插件。这个思路本质上就是LangChain的链式调用，只是把它放在了客户端。还有人建议让ChatGPT在每次调用插件前先进行一步推理——生成一段内部思考，决定下一步该做什么。这个思路本质上就是ReAct模式，2022年10月由姚顺雨等人发表在论文中，也正是LangChain代理模式的核心机制。

这些讨论指向同一个结论：OpenAI发布的插件体系是一个半成品。它给模型装上了四肢，但没有给出协调四肢运动的神经系统。

而这个神经系统，按照ReAct论文的论证，不应该是模型的内部能力——至少在当时不是——而应该是围绕模型的一层外部架构。论文的标题已经说明了这一点：在语言模型中协同推理与行动。关键词是协同。推理和行动不是先后发生，而是在一个循环中交替推进。

模型推理一步，行动一步，观察行动结果，再推理下一步。这个循环结构本身，就是缰绳。

OpenAI的产品团队不是没有意识到这个问题。插件体系发布时，官方文档中已经提到多步调用和插件链的可能性，但实现时间是模糊的。

在3月到5月之间，开发者社区对插件体系的抱怨从多插件协调困难逐渐升级为缺乏基本的编排能力。有人梳理了主要问题：插件选择不透明——用户无法控制模型选择哪个插件；调用顺序不可预测——同样的输入可能触发不同的插件序列；错误处理缺失——插件返回错误时模型通常不知所措；状态管理混乱——多个插件之间的数据无法共享。

每一个问题都不是孤立的bug，而是架构层面的空白。到了5月中旬，一些早期开发者开始放弃插件体系，转而使用LangChain的框架。典型做法是用LangChain定义任务步骤，每一步调用OpenAI的API——如果模型能力足够就直接生成，如果需要数据就调用外部工具——然后用LangChain管理步骤之间的状态和分支。

在这个架构中，ChatGPT本身变成了一个被编排的组件，而不是编排者。插件体系的价值被削弱了。开发者需要的不是ChatGPT内部的插件调用，而是外部的、可编程的、可控制的任务编排层。

这不是一个技术优劣的问题。这是一个权力分配的问题。谁控制编排层，谁就定义任务如何被完成。如果编排层在模型内部，模型厂拥有对任务执行方式的最终决定权。如果编排层在外部框架，框架拥有对任务执行方式的定义权，模型只是执行单元。前者意味着模型厂可以收取更高的API费用——因为编排被捆绑在模型调用中；后者意味着框架可以在模型调用之上叠加一层价值——编排本身成为产品，而模型厂退化为底层基础设施。

这种张力在2023年春天还没有完全爆发，但裂缝已经清晰可见。OpenAI的插件体系试图把工具调用收进平台内部，但半成品式的编排能力让开发者纷纷转向外部框架。LangChain的快速增长则证明，编排层作为一个独立架构层的价值已经被市场认可。

开发者愿意为了把任务完成而多学一套框架，多写一层抽象，多管理一层依赖。这种意愿在软件工程史上出现过很多次：开发者愿意为了把界面做出来而学React，为了把数据管清楚而学Redux，为了把服务部署好而学Docker。每一层抽象都对应着一类真实的复杂性，而编排大模型的多步任务显然是一种足够复杂的复杂性。

但LangChain的快速崛起也埋下了它自己的问题。框架扩张的速度越快，它封装的抽象就越厚。从最初的链式调用到代理模式，再到后来加入的向量存储、记忆管理、文档加载、索引构建，LangChain的API表面在2023年春天迅速膨胀。开发者开始抱怨过度抽象——为了完成一个简单的任务，需要理解太多的概念层级，而每一层抽象都可能在其内部隐藏了不可预测的行为。这种批评在4月底开始出现，到5月已经形成可辨识的声浪。

但当时没有人能准确判断，这种过度抽象究竟是框架早期演化的必然混乱，还是LangChain试图在模型之上构建一个过于厚重的中间层，而这个中间层最终会被模型能力的内化所吞没。脚手架悖论的第一轮兑现还没有到来，但条件已经全部就位。

在GitHub的另一个角落，一件事正在发生，事后被证明是命运转折点。2023年3月30日，一位名叫托兰·布鲁斯·理查兹的开发者在GitHub上发布了一个名为AutoGPT的项目。项目的README文件宣称，AutoGPT是GPT-4的完全自主实验，推动AI的边界，实现真正自主的任务完成。项目描述列出了几个关键特性：连接到互联网进行搜索和信息收集，长期和短期记忆管理，使用GPT-4生成和执行代码，文件存储和检索，以及最重要的——一个自我提示的循环。这个自我提示的循环是AutoGPT的核心机制。用户给AutoGPT一个总目标，AutoGPT启动一个循环。

在每次迭代中，模型生成一个当前任务，执行这个任务，把结果存入记忆，然后生成下一个任务，以此类推，直到模型判断总目标已经完成。任务可以是搜索特定信息、读取网页、提取数据、比较分析，模型自己决定要做什么。这个循环结构粗看很像LangChain的代理模式，但有一个关键区别。LangChain的代理循环依赖开发者显式定义终止条件——任务完成的标准是什么。AutoGPT的循环依赖模型自己判断什么时候算完成。模型在每次迭代中不仅决定下一步做什么，还要决定现在是否已经完成了总目标。这就把地面真值的问题推到了极致：如果模型判断自己已经完成了，但实际上结果质量很差，循环就会在错误的时间停止，用户得到一份质量低劣的输出却浑然不觉。如果模型永远判断自己还没完成，循环就会无限运行，不断消耗token和API费用，直到用户手动停止或者钱包被掏空。在AutoGPT发布的最初几天，这些问题还没有暴露。

项目在GitHub上获得的早期关注主要集中在它的自主性概念上——一个不需要人类逐步指导、能自己规划任务并执行的AI。这个概念的吸引力是巨大的。在ChatGPT时代，用户习惯了给模型一个指令，得到一次回复。但如果模型能接受一个模糊的总目标，然后自己拆解成子任务、自己执行、自己检查结果、自己决定下一步，那它就从一个工具变成了一个代理。这个跃迁的想象空间，足以让任何一个技术社区的脉搏加速。

但概念与实际运行之间的裂缝，在第一个周末就开始显现。早期用户贴出的运行日志中，AutoGPT经常陷入循环地狱：反复搜索同一个主题，不断生成相似的任务，永远无法满足自己设定的完成标准。有些日志显示，AutoGPT在搜索过程中访问了完全不相关的网页，把错误信息当成了有效数据，基于这些错误信息生成了新的任务，导致整个任务链偏离了初始目标。更让用户困扰的是token消耗速度。

一个看似简单的任务可能在几分钟内烧掉几美元的API费用，而产出的结果甚至不如一次精心设计的prompt。

但这些失败案例在大规模传播中并没有成为焦点。因为AutoGPT的演示视频看起来很震撼。一个终端窗口，里面一行行文字滚动，模型在思考，在行动，在判断，在继续。这种动态过程本身就具有说服力——它让观众感觉AI不只是被动回答问题，而是在主动解决问题。而人类对主动有一种天然的信任偏见：只要看起来在主动做某事，我们就倾向于相信它做得好。这种偏见会在随后几周驱动AutoGPT的星标数爆涨，也将在九十天后驱动它从神坛跌落。

3月31日，旧金山下了雨。OpenAI的插件体系上线一周，开发者社区的反馈从兴奋转向失望。LangChain的Discord频道里，用户数量在当周翻了一倍，哈里森·蔡斯和他的小团队正在处理激增的技术支持请求。

插件体系上线后的头两周，用户反馈的密度超过了OpenAI产品团队的处理能力。内部沟通记录后来被部分披露：产品经理们每天早晨打开共享文档，看到的不是零星的bug报告，而是一堵由重复问题组成的墙。最集中的投诉指向一个看似简单的场景：用户同时安装了三四个插件，期望ChatGPT能像一个熟练的行政助理那样，在航班、酒店、日历之间自动协调，但模型的表现更像一个被临时抓来顶班的实习生——每次只做一件事，做完就忘，需要反复提醒，而且经常搞错顺序。

一位早期测试者在论坛上贴出了完整的对话记录：他安装了Kayak、OpenTable和Zapier三个插件，要求ChatGPT帮他安排一次到芝加哥的出差——查航班、订酒店、在到达当晚预订一家意大利餐厅，最后把行程同步到他的谷歌日历。ChatGPT先调用了Kayak，返回了三个航班选项。然后它停住了，直接问用户：“你想订哪一个航班？”用户选了第一个，ChatGPT没有继续查酒店，而是开始解释航班的具体信息——起飞时间、航站楼、行李政策——这些信息用户并没有要求。用户不得不再次输入：“现在查酒店。”ChatGPT调用了一个酒店搜索插件，但搜索参数里填的是用户所在城市旧金山，而不是目的地芝加哥。

用户纠正后，ChatGPT重新搜索，给出了酒店列表。用户选择了一家，ChatGPT确认了预订信息，然后再次停住。用户提醒它预订餐厅，ChatGPT调用OpenTable，但搜索的是“今晚”——而用户的行程是下周。用户纠正日期，ChatGPT找到了餐厅，但预订时间与航班到达时间冲突。用户指出冲突，ChatGPT道歉，重新搜索，找到了另一家餐厅。

整个过程花了四十分钟，用户发出了十一条纠正指令，最终的结果仍然需要手动调整才能使用。这条帖子被顶到了论坛最上方，标题是：“插件体系让我的工作效率降低了一半。”

这不是孤例。在随后的几天里，类似的帖子不断涌现。用户们描述的共同模式是：ChatGPT在单插件单次调用上表现良好，但一旦任务涉及多个插件、多个步骤、步骤之间有依赖关系，模型就暴露出缺乏全局规划能力的缺陷。它像一个没有工作记忆的执行者，每次只能处理眼前的一步，无法在脑中保持整个任务的图景。这种缺陷在认知心理学中有一个对应概念：执行功能障碍。人类的执行功能包括任务规划、注意力切换、工作记忆更新、抑制无关反应。ChatGPT的插件调用模式恰恰在这些维度上表现出了系统性的不足。

它无法在调用插件之前先规划一个完整的步骤序列；它在插件之间切换时丢失了上下文信息；它无法抑制对用户已经明确不需要的信息的生成冲动；它的工作记忆——即对话上下文窗口——虽然技术上可以容纳大量信息，但在实际使用中，模型对上下文中不同部分的注意力分配是不均匀的，早期信息容易被后期信息覆盖。这些都不是单个bug，而是架构层面的空白。单步调用模型假设任务可以被分解为独立的、无状态的请求-响应对，但真实世界的任务几乎都不是这样。

在OpenAI内部，插件团队在3月底到4月初的几周里经历了一次剧烈的认知修正。最初的设计假设是：模型本身足够聪明，能够在对话中隐式地管理多步任务——用户说“安排一次旅行”，模型就会自动拆解成查航班、查酒店、订餐厅、同步日历，并按正确顺序执行。这个假设在内部测试中似乎成立，因为测试场景通常只涉及一两个插件，而且测试者的指令往往比普通用户更精确。但一旦放到真实用户和真实多插件环境中，隐式管理的脆弱性就暴露了。

模型有时候能正确拆解任务，有时候不能，而用户无法预测什么时候能、什么时候不能。这种不可预测性比单纯的失败更损害用户信任——一个偶尔能完成复杂任务的系统比一个明确不能的系统更让人困惑，因为用户无法建立稳定的使用预期。

到4月中旬，插件团队开始讨论是否需要在插件调用之前增加一个显式的规划步骤。这个讨论在内部引发了分歧。

一派认为，规划能力应该由模型自身通过更好的提示工程来实现——给模型一个系统指令，要求它在调用插件之前先生成一个任务计划。另一派认为，规划应该作为一个独立的架构层放在模型之外——在用户输入和模型调用之间插入一个规划器，把用户任务拆解成步骤序列，然后逐个步骤调用模型。前者的优势是简单，不需要改变架构；后者的优势是可靠，规划逻辑可以被显式地编写、测试和调试。这个分歧在OpenAI内部没有被迅速解决，因为双方都有合理的论据，而且当时的优先级是修复更紧急的bug——插件认证的安全漏洞、API调用的延迟波动、某些插件返回格式不兼容导致模型崩溃。规划问题被暂时搁置了。

但外部世界没有搁置。在OpenAI内部争论的同时，LangChain的开发者社区正在以惊人的速度吸收插件失败的教训，并将其转化为框架的新功能。3月底到4月初，LangChain的文档中新增了一个专门讨论“多步代理”的章节，其中明确对比了单步调用和多步编排的区别。

AutoGPT的GitHub仓库里，第一个提交的代码静静躺在那里——一个while循环，没有地面真值，没有沙箱，没有权限控制，只有模型自己判断自己是否完成了任务。

三件事同时发生，彼此关联却尚未碰撞。框架、协议、模型厂三方在一个陡升的地租曲线上同时加速，彼此踩踏又彼此催生。

插件失败的教训正在被消化，但消化的方式不是OpenAI修正插件体系，而是外部框架吸收了这个教训并把它转化为自己的产品逻辑。循环高于模型——这个判断在2022年秋天还只是ReAct论文里的一个学术论证，到了2023年春天，它已经变成了一个正在被代码实现的工程原则。原则的实现者不是模型厂，而是框架的作者。

这个分工会决定接下来一年里大量资源的流向，也会让脚手架悖论第一次兑现：凡是被框架验证过的编排能力，模型厂都要吞噬。但吞噬尚未开始。

此刻需要的是一颗引爆全局的火星。AutoGPT的GitHub仓库已经建好，README已经写好，自我提示的循环已经就位。

它缺乏的只是地面真值——一个能让循环终止的可靠依据。而这个缺乏，在随后几周会被证明不是AutoGPT的专属缺陷，而是所有没有可验证反馈的智能体系统的共同命运。代码的编译器和测试框架提供了天然的地面真值，所以编程场景会成为第一个杀手场景。而AutoGPT试图在研究市场、写报告、制定计划这类没有可验证标准的领域实现自主——它的循环从一开始就注定是一场昂贵的随机游走，只是在等待被发现。在3月的最后一天，这个发现还没有完成。所有人都在观望，在讨论，在犹豫是否要投入。而犹豫本身，就是框架发现自己的最佳时机。