AI智能体等于AI模型加框架：框架的功能及其重要性
智能体是由模型与框架组成的。了解框架如何添加工具、内存、循环结构及约束机制，开放权重智能体与开源智能体的区别，以及评估为何重要。
有一段时间，人工智能发展的故事是通过模型发布来讲述的：每隔几个月就会出现规模更大、功能更强的基础模型。但这个故事并不完整。无论大小，语言模型都提供原始智能，而这种智能有多少能传递给用户，则取决于围绕它的软件。这类软件被称为“框架”，越来越多的研究表明，它的作用可能与模型本身一样重要。近期有关为小型模型适配框架的研究指出，经过精心调优的框架能让紧凑型模型以较低的成本，在处理业务任务时展现出接近前沿模型的性能。具体数据可参见原始论文，但总体趋势与行业实践者观察到的情况一致：最强大的模型并不总能造就最具功能的系统。
因此，竞争的重点越来越在于谁能够构建出最优秀的框架，而不仅仅是谁能打造出最大的模型。
为何智能模型仍需框架
语言模型能够生成答案，但它本身无法浏览文件夹、在工具间选择、在多次调用之间保持工作记忆、验证自己写的内容、从错误中恢复，或持续朝着目标前进。这些缺陷正是智能体存在的意义——用于填补这些空白。在智能体中，框架围绕模型存在，将其智能转化为结构化、可重复且目标导向的动作。
模型与智能体
模型接收输入并生成输出，之后任务即告完成。而智能体在首次回复后会继续工作：它读取文件、使用工具、执行命令、记住之前的结果、做出决策，并通过多个步骤持续推进，直至任务完成。
既然模型只是为预测下一个输出而构建，这种情况是如何发生的？是通过围绕模型的工程系统——即“套件”来实现的。它决定哪些上下文信息会被输入模型、有哪些工具可用、工具调用如何执行、什么内容会被保留、何时再次调用模型，以及哪些操作会被拒绝或需要审批。
该套件还创建了工作循环：
循环的运行流程如下：模型读取其上下文中的内容，选择一项操作，调用一个工具，查看返回的结果，将其整合到自身上下文中，然后再次循环。
正是这个循环区分了简单回答与任务完成。它还可以绑定到调度器或外部触发器上，这样智能体便能在特定时间或事件发生时自动启动。
公式：智能体 = 模型 + 套件
模型是负责预测的部分。无论接收到何种上下文，它都会生成最实用的下一步输出或动作。而框架则是围绕其周围的软件，将这种原始能力转化为可控的、多步骤的行为。
看看将同一个模型放入不同框架后会发生什么：
- 在普通的聊天框架中，它就是一名对话助手。
- 加入网页搜索、信息检索、来源评估和引用核查功能后，它就变成了研究助手。
- 赋予它代码仓库、编辑器、终端以及测试输出功能，它就成为编程助手。
- 将其与客户数据、业务规则、消息工具、触发条件及审批流程相连，它就变成了运营助手。
模型从未改变，而框架却会变化。这也解释了为何基于相同底层模型的两种产品表现可能大相径庭：一种能够获取正确的证据、选择合适的工具、从失败中恢复、保持上下文整洁并验证结果；另一种则会丢失关键信息、不断调用错误的工具，或在不检查的情况下就宣布胜利。不能仅凭模型来判断一个产品的能力——模型决定了系统能理解什么，而框架则决定了它能完成什么。
区分不同层次
人们常常将模型、智能体和框架混为一谈，尽管它们其实是不同的层次。
Codex和Claude Code很好地展示了编程智能体中的这种模式。它们都将供应商自有的模型与一个框架相结合，该框架负责处理代码库上下文、文件访问、工具使用、shell命令、内存管理、执行流程、测试反馈以及循环迭代等功能。OpenCode、Goose、Pi、Letta和AutoGPT也遵循类似的模式，作为运行时环境或框架存在，它们之间的区别在于所支持的模型、工具集、内存设计以及开放程度。
智能体是完整的系统，模型提供智能能力，而框架则负责调控这些智能能力如何与外部世界交互。
开放权重与开源是不同的概念
Codex和Claude Code这类产品是现成的智能体，其模型与框架由同一家公司共同开发并优化。而开放权重型智能体则将可下载的模型与现有的或定制的框架结合在一起，这让开发者能更好地掌控部署、工具使用、内存分配、隐私保护、成本控制以及智能体行为。这些权重可以在用户自己的基础设施上运行，且在许可允许的情况下还可进行微调。常见的组合包括Goose与gpt-oss-120b这类开放权重模型，或是OpenCode与Qwen或Gemma模型。
开源智能体则有所不同：其框架代码是公开透明的。任何人都可以查看并修改模型提示方式、提供的工具、内存存储方式、循环运行逻辑、集成功能，以及权限和上下文处理机制。OpenCode、Goose和AutoGPT都是开源框架的示例。
这两者是相互独立的：
- 开源的框架仍然可以通过 API 调用专有模型。OpenCode 能够驱动 GPT 或 Claude 模型，因此其接口、控制逻辑和工具执行部分是开放的，而模型本身则是封闭的。
- 开源权重模型本身并非智能体。像 gpt-oss-20b 这样的模型虽然能够进行预测和决策，但除非有 Goose、OpenCode 或自定义框架这样的框架将其包裹起来，否则它无法浏览文件夹、运行工具、保存任务状态或完成工作流程。
简而言之：开源智能体是由开放框架加上任何兼容的模型构成的，而开源权重智能体则是由框架加上可下载的模型权重构成的。
为何开放生态系统如此重要
目前已有多个实验室推出价格合理的开源模型以及相应的开源智能体工具，共同构成了混合型的开源生态系统。这类产品的出现使得开源技术栈在某些智能体测试基准上成为专有编码智能体的强劲竞争对手，尽管并非在所有方面都更具优势。厂商自身的评估往往显示，专有的前沿模型在多项编码测试中仍占据优势。关键并不在于某一个模型能胜过所有其他模型，而在于一个价格合理的开源模型，结合精心设计的工具框架，便能与昂贵的封闭系统一较高下。
一个优秀的工具框架应包含什么
性能取决于模型与工具框架的结合，而工具框架由多个部分组成：
- 上下文选择。决定每次模型调用时传入哪些内容，确保相关文件、记录或文档被纳入，同时排除无关信息。
决定框架设计的各项选择
每个工具框架都会暗中设定智能体能力的上限，其中有一些需要尽早引起重视。
工具的数量及其描述方式。 给模型提供二十个相互重叠的工具通常比提供五个清晰明确的工具危害更大。工具的名称、描述以及参数格式实际上都属于提示内容，因此不清晰的工具定义会导致错误的调用。
需要记忆的信息量。 过长的历史记录会挤占有用的上下文信息。工具框架通常会简化内容、总结信息，或将相关笔记存储在提示之外，仅在需要时再调取。决定保留哪些信息以及保留多久，会极大影响智能体在长期任务中能否保持连贯性。
人类应介入的位置。某些操作，如读取文件，可以安全地自动化处理。而其他操作，如删除数据或转账，则需要经过审批步骤。确定这些界限属于架构层面的决策，而非模型层面的决策。
何为完成标准。循环需要一个终止规则，例如通过测试、得到验证的答案或达到步骤预算。如果没有这样的规则，智能体要么会提前退出，要么会持续运行。
一种实用的启动方法
如果你正在构建一个智能体，请从能够端到端完成一项实际任务的最简单框架开始：一个模型、两三个工具、带有步数限制的循环，以及明确的成功标准定义。接着收集十到二十项实际任务，运行它们，分析运行轨迹，优先修复最常见的故障。只有在确定框架本身并非限制因素后，再考虑更换模型。这样的顺序能避免将实际源于周边工具的问题归咎于模型。
文件访问的工作原理
模型无法直接访问计算机中的文件。该框架提供了受控的工具，可用于列出目录、搜索文件名、获取相关内容、打开并编辑文件、执行代码以及保存结果。模型会自行选择接下来需要哪些信息或执行何种操作。框架会对该请求进行验证并执行，然后将结果返回并添加到上下文中。这一过程会不断重复，直到模型判定任务已完成：
模型提出操作请求，框架执行该请求，返回结果后，模型再选择下一个操作。
例如，当被要求修复某个失败的测试时，模型可能会先请求列出目录，接着要求打开测试文件及被测试的模块，提出修改建议，最后请求运行测试。在每一步中，框架都会判断该请求是否允许，执行相应操作并报告处理结果。
评估框架同样重要
构建智能体框架仅是完成工作的一半。另一半则是用于评估其功能的评估框架。它会在类似实际生产的环境中测试整个系统是否能够选择合适的工具、从故障中恢复、控制成本、遵守安全规则，并持续稳定地完成任务。这远不止是通过某个孤立的基准测试而已。
智能体框架包含许多相互关联的组件，每个组件都可能是出现退化的隐患点：提示词、上下文规则、工具、记忆策略、规划循环、验证机制、权限设置以及恢复功能。如果没有评估集，团队就无法判断对某个组件的修改究竟带来了好处，还是悄然引发了新的故障。因此，这两个框架共同构成了一个反馈循环：
- 收集具有代表性的任务，包括实际的工作流程、以往遇到的难题及失败案例。
- 将整个系统、当前模型以及相关工具一起运行。
- 检查运行结果：是否成功、执行轨迹、工具调用情况、错误信息、成本及延迟时间。
- 更改某个组件，无论是提示词、工具、模型、内存策略、循环逻辑还是路由规则。
- 在保留的测试任务和回归案例上再次进行评估。
- 仅保留那些能够切实提升准确性、可靠性、安全性、速度及成本之间平衡的更改。
简而言之：构建系统、进行评估、发现缺陷、改进相关工具，然后再重新评估。
查看执行轨迹
当能够查看智能体实际执行了什么操作时，评估就会变得最为简单。一份有用的追踪记录会记载每一次模型调用、所请求的工具、参数、返回的结果、使用的令牌数量以及耗时。当任务失败时，应从追踪记录中查找第一个出错的步骤，而非最后一个。通常根本原因出现在早期：上下文中的文件缺失、工具描述模糊，或是存在某种错误假设，而后续所有步骤都会沿用这一假设。修复框架中的那个问题通常就能解决一系列相关故障，这也是为何追踪记录审查是团队能够养成的最有效的习惯之一。
模型还重要吗？
是的。新型模型在推理、编程、指令遵循、工具调用精度、上下文处理能力、速度、成本效率以及多模态技能方面不断进步，而框架无法可靠地赋予模型原本缺乏的能力。但模型已不再是整个产品的全部。
当有多个模型都能胜任某项任务时，框架可能会弥补不同产品之间剩余的大部分差异。能够找到正确文件的检索功能、操作逻辑清晰的工具、能记住已完成工作的状态管理机制、可检测错误编辑的验证系统、能阻止危险操作的权限控制，以及能在故障时恢复功能的机制，这些都会共同发挥作用。
这表明存在一种简单的劳动分工，同时也为审查任何代理项目提供了实用的检查清单。需要明确模型能够合理完成什么任务，框架必须添加哪些内容才能让这些能力稳定展现，以及评估结果又能提供何种证据证明其确实做到了。
- 模型决定了系统功能的上限。
- 框架将这一上限转化为可靠、可重复的结果。
- 评估则用于确认最终系统是否真的实现了预期功能，这与模型是否聪明是两个不同的问题。
正因如此，如今大量的应用工程工作都集中在框架与评估上。通过私有上下文、更安全的工具、领域特定的工作流程、内存管理、错误恢复以及用户体验，团队可以在框架层面建立持久的竞争优势。
核心问题的答案
模型能否在没有配套系统的情况下成为真正能独立运行的智能体？不能。仅凭模型本身，它缺乏执行动作、连接外部系统、记忆已完成步骤、观察决策结果并持续朝着目标前进所需的环境。模型相当于大脑和推理引擎，而配套系统则包括身体、工具、记忆机制、反馈回路、权限设置以及约束规则，这些共同将预测结果转化为可控的行动。
简而言之：人工智能智能体就是人工智能模型加上配套系统。