第 9 章
模型吞下工具
Harrison Chase 在旧金山市场街南区的办公室里，第一次看到函数调用文档时，手指在触控板上停住了。那是 2023 年 6 月 13 日下午，太平洋时区。OpenAI 的开发者关系团队照例在博客上发布了一篇更新公告，标题平淡无奇：《函数调用和其他 API 更新》。但 Chase 在滚动到代码示例的第一屏时，就知道这不是一次普通的 API 更新。他看到的是一段简洁到令人不安的 Python 代码：开发者在请求中定义一个 functions 数组，描述可用的工具名称、参数和描述，模型在响应中直接返回一个 function_call 对象，包含已经解析好的函数名和 JSON 格式的参数。没有提示词模板。没有输出解析器。没有正则表达式。没有重试逻辑去处理模型偶尔多打了一个逗号导致的 JSON 解析失败。
Chase 的 LangChain 代码库里，有超过两千行代码专门处理这个问题——如何让大语言模型输出结构化的工具调用指令，然后用健壮的解析器把这个指令从字符串变成可执行的函数调用。这是 LangChain 的 Agent 模块的地基。地基上的每一层抽象——Tool 接口、AgentExecutor 循环、输出解析器链——都建立在一个前提上：模型不会自己说话。你必须用提示词工程教会它用特定格式表达意图，然后写代码把这种表达翻译成行动。
现在 OpenAI 说：模型会自己说话了。这不是一次产品更新。这是一次领土变更。Chase 合上笔记本电脑，走到白板前。白板上还留着上午讨论的架构图，Agent 模块的各个组件用箭头连接，输出解析器被标成红色——那是他们计划在下一个版本中重构的部分。他在红色框旁边写了三个字母：API。然后画了一个箭头从 API 指向红色框，在箭头上打了一个叉。
办公室里没有人说话。工程师们已经在各自的屏幕上看到了同样的文档。Slack 频道里开始弹出消息，第一条来自一位核心维护者，只有四个字：「他们把工具吃了。」
函数调用功能的技术原理并不复杂。OpenAI 在模型训练阶段引入了新的微调数据，教会模型在判断需要调用外部工具时，输出一个结构化的 JSON 对象而非自然语言描述。在推理阶段，开发者通过 API 请求中的 functions 参数注册可用工具，模型在生成响应时，如果判定需要调用某个工具，就在响应中返回一个包含函数名和参数的 function_call 字段，而非普通的文本消息。开发者执行这个函数后，将结果作为新的消息回传给模型，模型继续生成最终的自然语言回复。
这个流程在学术文献和开源实践中已经存在了至少八个月。2022 年 10 月，姚舜宇等人发表的 ReAct 论文展示了一个清晰的范式：模型在推理过程中交替生成「思考」「行动」「观察」三个步骤，其中「行动」步骤就是调用外部工具。论文的代码实现中，外部工具调用依赖于精确的提示词工程和输出解析——模型被要求输出特定格式的字符串，解析器根据这个格式提取工具名称和参数。
2023 年春天，AutoGPT 和 BabyAGI 等项目将这种模式推向了极致，它们在提示词中嵌入复杂的工具描述格式，用多层正则表达式从模型输出中提取 JSON。OpenAI 没有发明工具调用。它做的是一件事：将分散在学术界和开源社区的最佳实践标准化，然后通过 API 的规模分发把它变成默认选项。这件事的精确狠辣之处在于时机——它发生在 LangChain 等框架刚刚建立起工具调用抽象层、但生态锁定尚未形成的时刻。2023 年 6 月 13 日这个日期，在缰绳层的简短历史中构成一个清晰的分水岭。在这之前，工具调用是缰绳层公司的核心竞争壁垒。在这之后，它是模型的基本功能。---
函数调用功能的发布文档中，OpenAI 同时更新了两个模型：gpt-4-0613 和 gpt-3.5-turbo-0613。日期后缀清晰地标记了这次更新的分水岭意味。文档中给出的示例场景是调用天气 API 和发送邮件，但任何有经验的智能体开发者都能看出，这个功能的真正战场在更复杂的领域：代码执行、数据库查询、第三方服务集成。文档发布后几个小时内，Hacker News 和 Twitter 上的开发者社区开始分裂成两个阵营。第一个阵营是直接使用 OpenAI API 的开发者，他们迅速将函数调用功能集成到自己的项目中，删除了数百行用于解析模型输出的中间代码。一个名为「Open Interpreter」的开源项目的作者在 Twitter 上发布了一段屏幕录制：他删除了一整个 output_parser.py 文件，commit 信息是「openai 吃了我们的 lunch」。第二个阵营是 LangChain 的用户。
他们在 LangChain 的 GitHub 仓库和 Discord 频道中提出了一个尖锐的问题：「既然模型原生支持函数调用，为什么我们还需要 LangChain 的 Tools 抽象？」这个问题在发布日当天被提出了至少二十次，以不同的措辞，在不同的线程中，由不同时区的开发者，几乎在同一时间发出。
LangChain 的维护者团队在当天下午召开了紧急会议。会议中的讨论焦点不是技术问题，而是定位问题。LangChain 的 Tools 抽象提供了一个比原生函数调用更丰富的接口：工具不仅有名称、描述和参数，还有回调机制、异步支持、输入验证和输出格式化。这些功能在原生函数调用中并不存在。
但问题在于——这些功能中，哪些是开发者真正需要的，哪些只是在模型不能直接调用工具时用来弥补缺陷的过渡方案？这个问题的答案，没有人能够确定。因为 LangChain 的 Tools 抽象设计于 2023 年初，那时的模型环境与当前完全不同。
当时的 GPT-3.5 和 GPT-4 需要通过繁琐的提示词模板才能理解工具概念，输出格式不稳定，经常需要重试和错误恢复。Tools 抽象中的很多设计——比如输出解析器的可插拔架构、多种格式的回退策略——正是为了应对这种不确定性。当模型原生支持函数调用后，这些设计的必要性突然变得可疑。
会议结束时，Harrison Chase 做了一个决定：不急于修改 Tools 抽象以适配函数调用，而是先观察开发者社区的实际使用模式。这个决定在当时的语境下是正确的——任何仓促的架构变更都可能引入新的问题，而 LangChain 的庞大用户基数使得每一次变更的成本都很高。但事后看来，这个决定也意味着 LangChain 在函数调用发布后的关键几周内，没有给出一个明确的答案来回应那个尖锐的问题：为什么还需要 LangChain？---
函数调用日的冲击波在发布后的第一周内迅速扩散。OpenAI 的官方 Python SDK 在那一天获得了相当于此前三个月累计的下载量。GitHub 上涌现出大量直接使用函数调用功能构建的轻量级智能体项目，每一个项目的 README 都在强调同一个卖点：「零依赖，只使用 OpenAI SDK。」
开发者社区中流传着一个比喻：函数调用就像 USB 接口。在此之前，每个外设（工具）需要定制化的驱动（解析器），框架公司的工作就是编写和维护这些驱动。当操作系统（模型）原生支持 USB 之后，大部分驱动变得多余。这个比喻的锋利之处在于，它暗示了 LangChain 等框架的命运可能与历史上的驱动程序公司一样：当标准接口被操作系统吸收后，它们要么向上迁移到更复杂的应用层，要么消失。
但这个比喻也在一个关键点上不准确。USB 是一个协作制定的开放标准，而函数调用是 OpenAI 单方面定义的专有格式。开发者在使用函数调用功能时，实际上是将自己的工具定义绑定到了 OpenAI 的 API 格式上。如果未来 Anthropic 或 Google 的模型采用了不同的工具调用格式，这些开发者将面临迁移成本。这个隐忧在 2023 年 6 月还只是技术社区中的微弱声音，但在接下来的几个月里，它将成长为一个重要议题——协议政治的核心问题。
在旧金山的一家名为 Fixie 的初创公司里，工程师们正在经历另一种冲击。Fixie 的定位是「智能体即服务」平台，它提供了一套工具调用的托管方案，帮助开发者将任意 API 包装成模型可调用的工具。
函数调用功能发布后，Fixie 的 CTO 在内部备忘录中写道：「我们地基中的一层被免费提供了。现在我们必须向上爬一层：从工具托管到工作流编排。」这个备忘录在几周后流传到了科技媒体，成为许多缰绳层公司共同心态的写照。
向上爬一层。这就是脚手架悖论在商业层面的冷酷表达：缰绳层公司前一天的核心资产，变成了第二天的模型默认设置。存活下来的唯一方式，是在模型吞并旧价值之前创造出新价值，在旧抽象层被替代之前建立起更上层的编排能力。但不是所有公司都能爬得动。---
函数调用功能发布两周后，LangChain 的 GitHub 仓库出现了一个微妙的变化。Issue 数量的增长速度超过了 Star 数量的增长速度。这不是灾难性的信号——LangChain 的 Star 数仍在增长，只是增速放缓——但它是一个值得警惕的指标。在开源社区的行为模式中，当 issue/star 比上升时，通常意味着用户对项目的期望与项目实际交付能力之间的差距在扩大。
这些新增的 Issue 呈现出一种模式。它们不再像早期那样询问「如何做 X」，而是转向了「在不使用 LangChain 的 X 模块的情况下，如何直接使用 OpenAI 的函数调用」。开发者开始将 LangChain 视为一个可选的外壳，而非必需的中间层。他们在 LangChain 的框架内绕过了 LangChain 的 Tools 抽象，直接使用原生的函数调用，只保留了 LangChain 的链式调用和记忆管理功能。这种模式在接下来的几周内变得更加普遍。
Hacker News 上出现了一篇名为《LangChain 的过度抽象正在成为负担》的文章，作者详细对比了使用 LangChain 的 Tools 和直接使用 OpenAI 函数调用的代码量差异。在 LangChain 的实现中，定义一个简单的天气查询工具需要继承 BaseTool 类、实现 _run 和 _arun 方法、定义输入模式，然后在 Agent 初始化时传入。在原生实现中，只需要在函数调用列表中定义一个 JSON 对象。代码量差距是五倍。
这篇文章的评论区迅速演变成了一场关于框架价值的辩论。支持 LangChain 的一方认为，代码量不是衡量框架价值的正确标准——框架的价值在于标准化、可维护性和生态互操作性。反对的一方则指出，当标准化意味着你必须理解一个庞大的类继承体系才能做一些简单的事情时，这个标准化本身就成了问题。这场辩论在 LangChain 的维护者团队内部引发了激烈的讨论。
一部分工程师认为应该大幅简化 Tools 抽象，让它更接近原生函数调用的接口。另一部分工程师则坚持认为，LangChain 的抽象层提供了原生函数调用无法提供的功能——比如跨模型提供商的可移植性。这正是 LangChain 的核心价值主张：一次编写，在多模型间切换。但跨模型可移植性的论据在 2023 年 6 月面临一个尴尬的事实：除了 OpenAI，其他模型提供商还没有提供与函数调用功能对等的特性。Anthropic 的 Claude API 在当时不支持结构化的工具调用输出。Google 的 PaLM API 也缺乏类似功能。开源模型如 Llama 2 在工具调用方面的能力也是远逊于闭源模型。这意味着 LangChain 的「跨模型可移植性」在当时只在一个方向上起作用：从 OpenAI 迁移到其他模型。而大多数开发者并没有这个需求。---
2023 年 7 月，Anthropic 发布了 Claude 2。这次发布没有包含函数调用功能。Anthropic 的 API 在产品形态上走了一条不同的路：他们强调 Claude 在长文本理解和安全对齐方面的能力，而非工具调用。在当时的开发者社区中，Anthropic 的定位更接近「强大的对话模型」，而 OpenAI 的定位已经转向「可编程的智能体引擎」。这种差异不是偶然的。Anthropic 的安全研究基因决定了他们对「赋予模型工具调用能力」的谨慎态度。工具调用意味着模型可以影响外部世界，这意味着新的安全威胁向量。
Anthropic 的研究团队在 2023 年夏天发表了一篇关于工具调用安全的论文，详细分析了模型在调用工具时可能出现的风险：提示注入通过工具参数传播、权限提升攻击、恶意工具描述的诱导行为。这些风险在函数调用功能发布后变得更加紧迫，因为模型不再只是「建议」调用工具，而是以结构化的方式「决定」调用工具。
Anthropic 的谨慎态度在商业层面产生了一个后果：它给 LangChain 等框架留出了一段喘息空间。只要 OpenAI 的函数调用格式不是唯一的工具调用格式，只要跨模型可移植性仍然是一个有意义的诉求，LangChain 的抽象层就仍然有价值。这个喘息空间的大小，取决于 Anthropic 和其他模型厂在多长时间内跟进函数调用功能。
Google 在 2023 年 8 月推出了 PaLM 2 的更新版本，其中包含了初步的工具调用支持。但与 OpenAI 的格式不同，Google 采用了基于声明式描述的接口，工具的定义和调用逻辑更多地集成在 Google Cloud 的生态系统中。到 2023 年 9 月，Meta 发布了 Llama 2 的微调变体，部分社区版本开始尝试通过提示词模板实现类函数调用的行为，但远未达到生产可用水平。
三个模型厂，三种不同的工具调用方式。这为后续的协议战争埋下了伏笔。
但在 2023 年夏天，多数开发者最直接的感受是：OpenAI 赢了工具调用这一轮。其他模型厂要么没跟上，要么选择了不同的路径，这意味着「跨模型可移植性」在目前只是一个理论上的需求，而非实际的生产约束。---
函数调用日之后的第三个月，开发者社区中出现了另一个显著的变化。那些在 6 月 13 日之后迅速采用原生函数调用的开发者，开始遇到新的问题。这些问题不是工具调用本身的问题，而是工具调用之上、更复杂的编排问题。一个典型的场景是：模型调用了一个工具，获得了结果，然后需要判断这个结果是否满足用户的需求，如果不满足，需要调用另一个工具，或者用不同的参数重新调用同一个工具。这个「调用-判断-再调用」的循环，在原生函数调用中没有内建支持。开发者需要自己实现循环逻辑、退出条件、错误处理和状态管理。
另一个场景是多工具选择。当注册的函数从三个增加到三十个时，模型开始出现选择错误——它调用了一个功能相似但不完全正确的工具，或者用错误的参数调用了正确的工具。开发者需要实现工具选择的辅助逻辑，比如根据用户意图预先筛选可用工具集合，或者在模型的工具选择结果上增加验证层。
这些问题的出现，印证了一个规律：当模型吞并了缰绳层的某一层后，智能体开发的起点上移至一个更高的抽象层级。开发者不再需要为「让模型说出它想调用什么工具」费心，但需要直接面对「模型应该调用哪些工具、以什么顺序调用、调用后如何判断结果」这些更复杂的编排问题。旧的缰绳层被吸收进模型后，新的缰绳层在更高的位置生长出来。
这正是脚手架悖论的第三阶段。第一阶段是缰绳层公司发明了一种技巧（提示词工程、思维链、ReAct 模式）。第二阶段是整个生态验证了这种技巧的价值，大量应用依赖它。第三阶段是模型厂将这种技巧吸收进模型本身，使用它的开发者不需要再依赖外部框架。然后是第四阶段：开发者发现模型内置的能力解决了旧问题，但创造了新问题，新问题需要新的缰绳层来管理。第四阶段又回到第一阶段。
这个循环的每一次运转，都逼着缰绳层公司向上爬一层。从提示词到输出解析，从输出解析到工具抽象，从工具抽象到工作流编排。每一次爬升，残留在下一层的公司都被淘汰，或者被吸收。---
2023 年秋天，LangChain 发布了 LangSmith 平台，这是一个用于调试、测试和监控 LLM 应用的开发者工具。这个产品的定位与 LangChain 的框架不同——它不抽象模型的能力，而是提供框架之上的可观测性和可靠性层。LangSmith 是 LangChain 对「向上爬一层」压力的回应。如果框架的下层抽象正在被模型吞并，那么就必须在更上层建立新的价值。
LangSmith 的发布时机值得注意。它正好发生在函数调用日之后约四个月，开发者社区已经充分体验了原生函数调用的威力和局限。威力的部分已经被充分验证：工具调用不再需要框架支持。局限的部分也逐渐显现：当应用变得复杂，多步工具调用链、条件分支、循环和错误恢复成为新的痛点。
LangSmith 试图解决的是这些新的痛点，而非已经被模型解决的老痛点。这个策略是否有效，取决于开发者是否愿意为可观测性和编排能力付费。
在 2023 年底，云服务上的 LLM 应用的复杂度正在快速上升。一个典型的智能体应用不再只是「调用一次工具，返回结果」，而是包含多个子代理、多步推理、与外部数据源的持续交互。这些应用的调试和监控确实成为了一个真实的问题。
LangSmith 的收入在发布后的几个月内稳步增长，虽然不足以弥补 LangChain 框架层被稀释的价值，但至少证明了一个方向：向上爬是可能的。
但 LangSmith 也面临一个根本性的限制。它建立在 LangChain 的生态之上，而 LangChain 生态的核心吸引力正在被侵蚀。如果开发者不再使用 LangChain 的框架层，他们也不会使用 LangChain 的调试工具。LangSmith 的命运与 LangChain 框架的命运是绑定的，而框架的命运正被函数调用日所定义的压力所左右。这是一种微妙的锁定：LangChain 必须保持框架层的吸引力，才能让 LangSmith 有用户基础；
但保持框架层吸引力的方式——更丰富的抽象、更多的集成——正在与「开发者想要更轻的抽象」的趋势相悖。框架越重，核心用户流失越多；核心用户流失越多，上层工具的吸引力越小。这个困局在 2023 年 10 月的一个 GitHub 讨论中得到了最清晰的表达。一位长期使用 LangChain 的开发者发帖说：「我删除了 LangChain 依赖，代码从 800 行减少到 200 行，bug 消失了。但我也承认，我需要自己实现的那些编排逻辑，LangChain 确实提供了开箱即用的方案。只是那些方案太重了，重到了得不偿失的地步。」这个帖子获得了超过 500 个赞，是 LangChain 仓库当月最受关注的讨论。---
函数调用日的另一个后果，在 2023 年下半年的开发者工具市场中逐步显现。那些在 2023 年春天围绕「提示词工程」和「输出解析」建立商业模式的公司，开始面临生存危机。
一家名为 PromptLayer 的初创公司提供了一个典型的案例。PromptLayer 最初的产品是提示词版本管理和输出解析服务，帮助开发者追踪不同提示词的效果，并将模型输出解析成结构化数据。函数调用功能发布后，输出解析的需求大幅下降——模型现在直接输出 JSON，不需要外部解析。
PromptLayer 被迫调整产品方向，转向提示词评估和 LLM 应用的可观测性。这个转型在技术上是可行的，但市场窗口已经缩小。在可观测性领域，已经有 LangSmith、Weights & Biases 和 Arize AI 等竞争对手。另一家名为 Guardrails 的创业公司，产品定位是确保模型输出符合预定义的结构和约束。
函数调用功能实现了同样的目标：如果模型被训练为输出结构化的函数调用，而非任意格式的自然语言，那么输出格式的可靠性本身就提高了。
Guardrails 的创始人回应称，他们的产品处理的不仅是格式问题，还包括内容验证、业务规则检查和合规性保证。这个回应在理论上是成立的，但投资者的质疑并没有消失：当模型层面解决了格式问题，有多少客户还需要一个额外的格式验证层？
这些公司的困境是脚手架悖论在商业层面的具体展现。每家缰绳层公司都在回答同一个问题：我们的产品中，哪些部分会被模型吸收，哪些部分不会？这个问题没有标准答案，因为模型吸收的速度和方向是不可预测的。但函数调用日提供了一个清晰的案例：当模型厂决定吸收某一层功能时，它可以在一次 API 更新中完成——而这次更新对于模型厂来说，只是常规的迭代节奏中的一步。
这就是平台权力不对等的本质。模型厂控制着模型权重和 API 入口。它可以观察生态中哪些缰绳功能被广泛使用，然后选择在模型层面实现它们。缰绳层公司没有这种能力——它们只能在模型的能力边界之外寻找价值，而这个边界每天都在移动。---
2023 年 11 月，OpenAI 举办了首届开发者大会 DevDay。在会上，Sam Altman 宣布了 Assistants API，这个 API 将函数调用、代码解释器、检索增强生成和对话管理打包成一个完整的智能体托管服务。开发者不需要自己搭建循环逻辑、工具集成和状态管理——OpenAI 提供了一站式的解决方案。这是函数调用日逻辑的延伸和升级。函数调用吞并了工具调用层，Assistants API 试图吞并整个智能体运行时。如果函数调用日的冲击针对的是 LangChain 的 Tools 模块，那么 Assistants API 的冲击针对的是 LangChain 的 Agent 模块——包括 AgentExecutor 循环、记忆管理、工具选择和错误恢复。
在 DevDay 的舞台上，Altman 展示了 Assistants API 的一个演示：用自然语言描述一个助手的功能，然后通过几次鼠标点击，就可以创建一个能够调用多个工具、与用户进行多轮对话的智能体。演示只持续了五分钟，但在那五分钟里，LangChain 的数千行 Agent 代码的意义被重新放在了天平上称量。
Harrison Chase 在 DevDay 之后发表了一篇博客文章，标题是《LangChain 和 OpenAI 的 Assistants API》。文章承认 Assistants API 与 LangChain 的部分功能重叠，但强调 LangChain 仍然提供了一些 Assistants API 无法替代的价值：多模型提供商支持、自定义工具集成、更灵活的编排逻辑、以及开源社区的透明性。这篇文章的语调是建设性的，没有防御性，但字里行间透露出一种压力：当一家拥有你依赖的模型的公司，开始在你建立的生态层上建造产品时，你的价值主张必须重新论证。
重新论证的过程，在 Chase 的博客文章的评论区中展开了。一位开发者留言：「LangChain 的价值不是一个固定的点，而是一个移动的目标。模型能力每提升一次，LangChain 就必须在更高的地方找到新的价值。这就像在流沙上盖房子。」
这个比喻准确地捕捉了缰绳层公司的处境。房子可以盖得很漂亮，但地基每天都在移动。---
函数调用日的风暴在 2023 年底趋于平静，但它的深层后果仍在扩散。最持久的影响不是在技术层面，而是在开发者心智层面。在 2023 年 6 月 13 日之前，大多数开发者将缰绳层公司视为建设者——它们在开创一个全新的软件层，这个层将会像操作系统一样持久。在这之后，越来越多的开发者开始将缰绳层公司视为过渡者——它们在一个快速收缩的时间窗口内运营，它们的产品注定会被模型吸收，问题只是时间。
这种心智转变影响了投资、招聘和开源贡献。2023 年第四季度，对 LLM 框架和工具类创业公司的风险投资开始降温。投资者开始问一个标准问题：「如果 OpenAI 或 Anthropic 在下一个版本中内置了这个功能，你的公司还能做什么？」这个问题没有好的答案——因为任何好的答案都必须证明，某个功能是模型厂不会或不能内置的，而这种证明变得越来越困难。招聘市场也出现了类似的变化。
在 2023 年上半年，拥有 LangChain 或 LlamaIndex 等框架经验是简历上的亮点。到了年底，这些经验仍然有价值，但招聘方开始更关注应聘者是否理解底层的模型能力边界，而非特定框架的 API。框架经验正在从「资产」变成「可能快速贬值的资产」。开源贡献的模式也发生了变化。2023 年秋天，涌现出一批新的开源项目，它们刻意避免创建繁重的框架，而是提供轻量级的、针对特定场景的智能体实现。这些项目的 README 中经常出现类似的声明：「不是一个框架，只是一些你可以复制粘贴的代码。」这种声明的流行，是开发者对框架膨胀的集体反应，也是对函数调用日的间接回应——如果模型已经足够强大，你需要的可能不是更多的抽象，而是更少的抽象。---
函数调用日的故事，在缰绳层的历史中占据一个特殊的位置。它是模型厂第一次成建制吞并缰绳层的时刻，但它不会是最后一次。
在接下来的两年里，这个模式会重复多次：思维链被吸收进训练，多步规划被吸收进强化学习，检索增强生成被吸收进模型上下文窗口。每一次吞并都遵循同一个模式：缰绳层公司在生态中验证了某种能力的价值，模型厂将其标准化并内置到模型或 API 中，缰绳层公司向上爬一层，或者在这一层死去。
工具调用之所以成为第一个被吞并的层，是有原因的。工具调用本身的反馈是结构化的——一个 API 调用要么成功，要么返回错误码。成功和失败的信号是明确的，这使得模型厂可以用这些信号进行针对性的训练。
地面真值定律在这里首次显影：反馈越可验证的领域，模型吞并的速度越快。工具调用之所以被吞并，不是因为它是缰绳层中最简单的部分，而是因为它是反馈最清晰的部分。
在旧金山市场街南区的办公室里，Harrison Chase 在 2023 年 12 月的最后一次全员会议上，在白板上画了一个新的架构图。图的底部是模型层，标注为「由模型厂控制」。图的中部是框架层，标注为「正在被吸收」。图的顶部是编排层，标注为「新战场」。他从框架层向编排层画了一个箭头，在箭头上写了一行字：「这是我们爬往的方向。」
然后他放下马克笔，对团队说了一句话：「模型吃了工具，但还没有吃掉工具之间的路由。」
这是脚手架悖论的下一个循环的起点。