更智能的模型会缩小智能体工具包的规模，还是让它变得更加重要？

几年前，要让人工智能功能变得更出色，主要就是提升模型性能：选择更强大的模型、对其进行微调、提供更干净的数据，并通过 API 提供接口。如今，围绕模型的生产系统可能还包括检索、内存管理、工具功能、规划能力、评估机制、可观测性保障、限制规则、重试机制、上下文管理以及多个协同工作的代理组件，而所有这些外围组件的总称就是“框架”。这就给那些需要决定将工程精力投入何处的人提出了一个实际问题：随着模型不断改进，这一层会逐渐简化，还是会成为系统中最重要的部分？本文将探讨这一问题的正反两面，并最终给出一种方法，帮助判断你自己的框架中哪些部分可能会缩小，哪些部分则会发展壮大。

什么是框架，什么不是

框架是围绕模型存在的软件，它使模型能够可靠地完成任务。模型负责进行推理，而框架则为这种推理产生有用结果创造条件。在实际应用中，它整合了多项功能：对工具和API的访问控制；信息的检索、上下文管理及内存处理；将工作分解为计划好的步骤并跟踪状态；对输出结果进行检验、将错误反馈并重新尝试；实施权限与限制措施；以及衡量和观察所发生的一切。

关键在于，这种框架并非旨在让模型变得更聪明，其目标是打造一个整体上更强大、更可靠且更安全的系统。以文本转SQL为例，模型可能已经知道如何编写查询语句。此时框架会为模型提供数据结构说明，让其查看表的结构元数据，执行查询，捕获错误，返回结果或错误信息，在需要时触发重试，并帮助判断最终答案是否足够好。模型负责进行推理，而框架则为这种推理提供循环结构。一旦模型的功能不止于生成文本，这种循环结构就显得尤为重要。

如需详细了解单个智能体中模型与框架之间的职责划分，可参阅可靠人工智能行为究竟源自何处。本文重点探讨这种职责划分随时间的变化情况。

简化框架的必要性

期望更优秀的模型需要更少的辅助结构是完全合理的。试想这样一个能够稳定完成以下所有任务的模型：

• 遵循复杂的指令。
• 保留相关信息。
• 选择正确的工具。
• 规划多步骤的任务。
• 在出现故障时恢复运行。
• 检查自身的输出结果。
• 识别自身不确定的情况。
• 在长时间运行的任务中持续跟踪状态。

有了这样的模型，如今许多编排方式都显得多余了。更强的推理能力减少了对显式规划层的需要；更好的原生工具使用方式则减少了手动编写工具选择逻辑的必要；对长上下文更出色的处理能力降低了对复杂内存系统的需求；可靠的自评估功能则减少了对外部验证流程的依赖。

这种情况确实可能发生，而且已经在某些领域出现：早期模型所必需的提示技巧和解析变通方法如今往往已不再必要。未来最优秀的工具或许会比现在许多工具更为精简，这并非不可能。不过这只是问题的一半而已。

能力拓展应用范围

当模型的能力大幅提升时，团队很少仅仅为了以更低成本完成相同工作而使用这些能力，而是会将其用于解决更复杂的难题。

• 目前只能总结一份文档的模型，很快就会被要求分析上百份文档。
• 目前只能编写单个SQL查询的模型，将会被要求解决涉及多个系统的业务问题。
• 目前只能调用一个API的模型，将会被交给整个软件环境来使用。

能力提升的同时，任务范围也在扩大，这改变了相关系统的职责。问题从“模型能否回应请求”转变为“系统能否让模型安全可靠地实现目标”。这是两种不同的工程问题：前者关乎智能，后者则涉及控制、信任与责任归属。

具备能力的智能体会引发系统层面的问题

假设一个能力日益强大的智能体被赋予了浏览器、数据库、内部API、文件处理功能、代码执行能力、消息传递工具以及长期记忆。此时智力已不再是限制因素。人们就需要回答如下问题：

• 该智能体被允许执行哪些操作？
• 它可以读取哪些信息？
• 何时必须请求批准？
• 当某个工具出现故障时会发生什么？
• 如何避免循环和重复操作？
• 如何让他人能够了解它为何做出特定决策？
• 如何评估一个持续30分钟的工作流程而非仅一次响应的结果？
• 当模型判断错误但自身十分确信时会发生什么？

这些问题都无法通过更智能的模型来解决。能力更强的模型反而可能让最后一个问题变得更糟，因为流畅且自信的错误更难被察觉。这些都是系统层面的问题，正是在这种情况下，框架的重要性而非其价值才会凸显。

从协调调度到环境设计

如今的许多智能体框架都侧重于协调调度：决定下一步该做什么、调用哪个工具以及将什么信息传回模型。随着模型越来越擅长自我规划，那种顺序控制逻辑很可能会逐渐减少。而剩下的、且会不断发展的部分则更接近于环境设计。框架负责定义：

• 工具：智能体可以与之交互的对象。
• 上下文：展示给它的信息内容。
• 状态：它在不同步骤之间所记住的信息。
• 权限：它被允许修改的内容。

反馈：模型如何得知出现了问题。

评估：如何衡量成功与否。

边界：何时需要停止运行或将控制权交还给人类。

在这种框架下，模型获得了自主性，而约束机制则成为这种自主性的边界。你不再需要为智能体指定行动路径，而是开始塑造它活动的空间。

复杂性会转移，而不会消失

软件工程中存在一种常见的规律：当某一层变得简单后，复杂性通常会转移位置而非彻底消失。抽象机制可以隐藏复杂性，但无法将其消除。托管数据库并未减少对索引理解的必要性，云平台也同样没有免除容量规划的需求。

智能体很可能会遵循相同的路径。更先进的模型或许会让一些手工编写的智能体逻辑变得不再必要，但同时会提升对更强大的评估能力、安全性、可观测性、内存管理、成本控制、可靠性工程以及长任务支持的需求。这类工具对应用程序开发者的可见度可能会降低，因为这些功能已被服务提供商和框架所承担，但它们在系统运行方式中却变得愈发重要。更简单的开发者体验并不意味着其底层架构也更为简单。

在某些方面重要性降低，而在其他方面则上升

诚实的答案并非非此即彼。作为手动弥补模型缺陷的手段，框架的重要性正在下降；而作为让强大模型在现实世界中运行而不出现安全问题、不可靠或资源浪费现象的基础，它的作用却愈发重要。未来的框架可能会采用不那么严格的协调机制，并具备更为复杂的评估、权限管理、状态监控、反馈系统、可观测性以及环境控制功能。

大致的发展趋势如下：

• 早期：模型几乎直接连接到应用程序。
• 现在：模型需要经过提示词、RAG、工具、智能体以及评估流程，才能接入应用程序。
• 未来：模型与框架共同构成一个自主系统。

最后一步才是最关键的。一旦人工智能从生成答案转变为执行动作，核心问题就不再仅仅是模型的智能程度，而是其周围环境的设计质量。

测试你所用工具框架的实用方法

为确定投资方向，需将每个工具框架组件归入以下两组之一：

• 那些补偿性组件存在的原因是当前模型在某些方面存在缺陷：僵化的逐步规划机制、复杂的输出解析与修复逻辑、基于关键词的工具匹配方式、提示词绕过技巧。这类组件应保持简单且易于删除，每次升级模型后都需重新测试，因为它们最有可能变成累赘。

那些持久存在的组件之所以存在，是因为相关任务会带来现实世界中的后果：权限控制与沙箱机制、审批流程、审计日志与追踪功能、成本限制与循环次数限制、评估工具以及状态持久化。应当对这些方面进行适当投资，因为更强大的模型只会进一步提升它们的价值。

一个有用的判断标准是：如果模型在推理方面已经完美无缺，该组件是否仍然必要。对于访问控制、可审计性以及成功度衡量而言，答案是肯定的，这类组件就属于系统核心中不可或缺的部分。

关键要点

• 框架并不会让模型变得更聪明，而是能让整个系统具备更强的能力、更高的可靠性与安全性。
• 更强大的模型很可能会减少协调逻辑和临时解决方案的必要性，这一点值得提前规划。
• 更强的能力意味着更广阔的应用范围，这引发了关于权限、故障处理、评估及责任归属等问题，而这些都不是模型改进所能解决的。
• 开发框架正从逐步骤编写脚本转向设计整体环境：包括工具、上下文、状态、权限、反馈机制、评估标准以及边界条件。
• 预计复杂性不会消失，而是会转移到基础设施层面，因此在构建框架时需考虑到这一点，并确保其中核心部分具有持久性。