智能体执行框架详解：三层接入方式与持久会话协议

什么是智能体执行框架

智能体执行框架是驱动大模型自主完成任务的底层运行环境。它位于大模型与业务应用之间，承担中间层的职责：统一保存对话状态，解析并执行工具调用，提供沙箱环境运行代码，把输出以流的形式返回，并在高风险操作前插入人工审批。

终端用户通常不会直接接触这一层。命令行工具、IDE 插件和业务系统可以共用同一个框架，因此同一套能力在不同入口上的表现保持一致。

从工程角度看，框架把模型的推理结果转化为可以监控、可以中断、可以回放的执行流程。模型仍然会出错，但错误被限制在沙箱和审批规则之内，企业因此更容易把智能体放进正式的业务系统。

为什么需要专门的执行框架

早期的大模型应用多是直接调用 API。这种方式适合简单问答，但构建智能体时会遇到以下问题：

• 无状态：每次请求都是独立的，开发者要自己拼接历史消息，控制上下文长度。
• 工具调用需要自行解析：应用代码要识别模型返回的函数调用结构，执行后再把结果回填给模型。
• 执行环境需要自建：运行模型生成的代码时，必须自己隔离权限、限制网络和文件访问。
• 审批难以追踪：自动化流程中途需要人工确认时，任务状态很难挂起和恢复。

执行框架把这些能力集中在一处。业务应用负责提供上下文、规则和工具，框架负责代理循环。开发者可以把精力放在业务输入和最终结果上。

三层接入方式：怎么选

不同任务对连接方式的要求差别很大。下表列出三种接入方式的主要区别。

接入方式	适用任务	连接形态	状态保持	人工审批
轻量非交互调用	脚本、批处理、CI 任务	单次派发，任务结束即退出	不保留，需要时通过输入文件传递	一般不支持交互，需提前设定规则
程序化编排 SDK	定制化工作流、内部系统集成	嵌入业务代码，由代码控制循环	由业务代码管理	可在代码中插入审批回调
持久会话驱动协议	多轮产品级智能体	长连接，流式推送	框架维护会话，支持断点续传	支持挂起与恢复

轻量非交互调用适合无需人工参与的单向任务，例如代码合并后生成测试用例，或在流水线中批量检查依赖版本。它启动快，资源占用低。缺点是没有交互机会，所有约束都要在调用前写清楚。

程序化编排 SDK适合把智能体嵌入现有系统。开发者可以注册自定义工具，在每轮推理前注入业务数据，并决定何时停止循环。这一层灵活性最高，代价是需要自己维护业务代码。

持久会话驱动协议适合多轮对话、长时间运行或中途审批的场景。客户端与框架保持长连接，模型输出和工具执行过程通过流式事件实时返回。会话断开后，可以依据会话标识继续执行。

实际项目往往同时使用两到三种方式。例如，流水线使用轻量调用，内部工作台使用 SDK，面向研发人员的交互界面使用持久会话。

运行机制：应用决定目标，框架负责执行

框架的分工很清楚：应用决定做什么，框架负责怎么执行。典型流程如下。

1. 上下文下发：业务应用把产品上下文、业务规则和可用工具交给框架。框架把这些内容整理成结构化配置，并生成模型可以理解的系统提示。
2. 代理循环：模型推理后决定调用工具时，框架截获这一请求，在沙箱中执行代码或访问外部接口，再把结果交回模型继续推理。
3. 状态管理与压缩：多轮交互会让上下文越来越长。框架通过上下文压缩保留关键信息，并按策略保留必要的推理内容，减少重复消耗。
4. 审批与流式反馈：遇到预设的高风险操作时，框架挂起执行并通知审批人。审批通过则继续，拒绝则返回原因。执行结果和中间过程通过流式协议推回应用。

这四步可以概括为：上下文决定模型知道什么，沙箱决定模型能做什么，审批决定哪些动作需要人确认，压缩和状态管理决定长任务能走多远。

与直接 API 调用有何不同

直接 API 调用是无状态的单次请求和响应。开发者需要自己维护上下文、解析工具调用、执行代码并处理错误。执行框架则是有状态的持续循环，把这些逻辑封装起来。

两者的差别不只在开发量上。框架的设计会影响模型在多步任务中的表现。上下文管理是否得当，工具结果能否完整回填，失败后能否重试，这些因素都会改变最终的完成率。

不过，框架带来的效果提升取决于任务和测试条件，不能把某一次测评结果当作普遍结论。评估时可以在自己的任务集上做对照实验：固定同一个模型，分别运行有框架策略和无框架策略的版本，记录任务完成率、Token 用量和耗时。这样得到的数据才能指导选型。

典型场景

CI/CD 流水线自动化：代码提交后，智能体执行代码审查、依赖升级建议或测试脚本生成。轻量调用适合这类无人值守的任务。输出结果可以写入评论或工单，由人工决定是否合并。

企业内部研发助手：通过编排 SDK 把智能体接入内部代码库、规范文档和工单系统。工具集只开放必要的接口，上下文按项目注入，代码补全和架构建议都基于企业自有资料。

多模型路由与适配测试：框架把模型层与业务层解耦。开发者可以按任务难度切换底层模型，例如简单任务使用低成本模型，复杂任务使用能力更强的模型。切换前要确认新端点支持相同的函数调用格式和流式事件格式，否则会出现工具调用失败或输出中断。

集成前的检查清单

以下项目在上线前至少要逐一确认。

1. 模型端点与鉴权：配置端点地址和访问凭证。凭证放在环境变量或密钥管理服务中，不写入代码，也不输出到日志。
2. 协议兼容：核对函数调用的请求和响应结构，以及流式事件的字段。若出现工具调用解析失败，先抓取原始请求和响应，逐字段比对；必要时回退到原生端点，定位问题后再切换。
3. 沙箱权限：默认禁止外网访问。文件系统只挂载任务所需的工作目录，并尽量设为只读，只开放必要的输出路径。同时设置 CPU、内存和执行时长上限。若使用云厂商的容器或隔离服务，要核实其隔离级别和网络策略，不能只看产品名称。
4. 持久化存储：会话状态写入数据库或对象存储，服务重启后可以恢复。明确会话的保留期限，过期数据定期清理。
5. 循环与预算：设置最大推理轮数、单次调用超时和 Token 预算。超出任一上限时，终止循环并返回已完成的部分结果。
6. 审批规则：列出必须人工确认的操作，例如写入生产配置、发布版本、删除文件、调用付费外部接口。审批超时后的默认行为应为拒绝。
7. 观测与告警：记录每轮的工具调用、耗时和 Token 消耗。对失败率、超时率和费用设置告警阈值。
8. 回滚方案：智能体修改代码或配置时，应在独立分支或可撤销的快照中操作。合并前由人工审查，出现问题时能快速恢复。

选型三步

第一步，确认接入层：任务是否需要多轮交互或中途审