智能体框架，又称智能体脚手架，是指围绕大型语言模型（LLM）的软件基础设施，使其能够作为AI智能体运行。它管理工具使用、记忆、状态持久化、执行环境和反馈循环，而非模型内部的推理。英国AI安全研究所在2023年就将AI智能体描述为由模型加上框架构成，这种关系通常表示为智能体 = 模型 + 框架。
由于“基础模型”LLM是一种无状态的概率函数，将输入词元序列映射到输出词元序列，因此框架是将模型转变为智能体的关键，，它使模型能够与外部工具交互，输入和输出非词元数据（如图像），并在多轮对话中与任务环境连贯地互动。框架不是反复在上下文窗口内重读不断增长的记录，而是可以将记录保存到结构化的软件环境中，从而管理智能体的状态。对于单次提示-响应交换，最小化框架并非必要，但随着任务变得多步骤、面向工具或长期运行，框架的重要性日益凸显。
流行的智能体框架主要聚焦于AI辅助软件开发，包括Anthropic的Claude Code、OpenAI的Codex、Google DeepMind的Antigravity、SpaceXAI的Cursor、Qwen、DeepSeek、Kimi和GLM。
架构
框架协调的机制早于该术语出现。模型在循环中交替进行推理和行动的模式源自同行评审的ReAct框架，而模型调用外部工具的能力在Toolformer中得到了展示。
框架通常包含的组件包括工具调度、记忆和状态持久化、隔离的沙箱或工作区、上下文管理，以及护栏，如范围权限、审批层级和监控。在2026年的一篇工程文章中，Anthropic描述了一个工作示例，该示例由一个初始化智能体（负责准备环境）和一个编码智能体（反复选择下一个未完成任务、提交并更新进度记录后停止）构建而成。
Thoughtworks的Birgitta Böckeler区分了模型构建者提供的内层框架（例如智能体SDK或诸如Cursor、Codex等编码工具）与用户在其上组装的外层框架，例如指令文件、模型上下文协议服务器和自定义技能。她进一步将引导（在智能体行动前引导其方向）与传感器（观察结果并让智能体自我纠正）区分开来；每种都可能是计算性的（如linter或测试等确定性检查）或推断性的（如“LLM作为评判者”等语义检查）。
历史与术语
围绕模型的脚手架相关概念存在于软件测试（测试框架）、LLM基准测试（评估框架）以及强化学习中围绕学习智能体的环境和包装器中。智能体框架和LLM框架这两个名词在相关学科被命名之前就在从业者中流传。
“框架工程”的词汇在2026年初出现，具体短语的归属存在争议。一些说法将其追溯到HashiCorp联合创始人Mitchell Hashimoto在2026年2月的一篇博客文章，他描述了一种实践：每当智能体犯错时，就在其环境中工程化一个永久修复；其他说法则归功于LangChain的Vivek Trivedy，其“智能体框架剖析”一文从智能体 = 模型 + 框架公式推导出框架组件。一份被广泛引用的OpenAI工程报告描述了一个主要由编码智能体构建的大型代码库，加上Thoughtworks、LangChain和Anthropic的后续文章，帮助传播了这一术语。
到2026年中期，框架已成为学术研究的对象。独立报道描述了诸如Self-Harness等研究，其中智能体迭代地挖掘自身失败以提出并验证对其框架的更改，以及Harness-1，一个开源搜索智能体，主要通过重新设计模型周围的软件环境而非扩大模型来提高检索准确性。
与提示和上下文工程的关系
框架工程通常被定位为比提示工程（优化单次交互）或上下文工程（控制模型在特定时刻看到的信息）更广泛的层面；在这种框架下，框架设计整个操作环境，并将其他两者作为其组成部分。一个显著特征是，被包装的组件是非确定性的，因此框架的设计目的是在模型虚构动作或错误报告任务已完成时优雅地恢复。