更少上下文，更智能代理：面向长周期工具使用的LLM代理的高效上下文工程

# 更少的上下文，更好的智能体：面向长周期工具型LLM智能体的高效上下文工程

来源：https://arxiv.org/html/2606.10209

###### 摘要

背景：作为自主智能体部署于企业工作流的大语言模型面临一个关键挑战：来自企业系统的冗长工具响应导致上下文窗口溢出和过高的推理成本，从而阻碍了大规模可靠任务完成。方法：我们评估了四种应用于 GPT-5 的上下文工程配置，用于通过模型上下文协议 (MCP) 在 Microsoft Dynamics 365 Finance and Operations (D365 F&O) 中自动进行酒店费用明细化：(1) 不带用户模型的 GPT-5（一个激励性消融实验），(2) 带有完整对话历史的标准全上下文智能体（我们的上下文工程基线），(3) 上下文剪枝至最后 5 个工具调用/响应对，以及 (4) 使用摘要窗口 3 进行自动摘要的上下文剪枝。结果以 50 项任务酒店费用基准上 5 次独立实验运行的平均值报告，在上下文工程比较 (C2–C4) 中保持用户模型不变，以隔离上下文管理的影响。我们扩展了原始研究，包括 (i) 95% 置信区间和效应量分析，(ii) 对剪枝窗口 N 和摘要窗口 W 的敏感性分析，(iii) 按类别划分的失败分类法，以及 (iv) 跨分属三个结构不同类别的五种费用类型以及跨第二个模型族 (Claude Sonnet 4.5) 的泛化证据。结果：C1（无用户模型）仅达到 8.0% 的完全明细化率。全上下文配置达到 71.0%，但每次基准测试消耗了 1,480,996 个令牌和 14.56 小时。将上下文剪枝至最后 5 个工具调用实现了 79.0% 的完全明细化率，消耗 535,274 个令牌——减少了 63.9%——耗时 5.39 小时。添加自动摘要后，实现了 91.6% 的完全明细化率和 99.64% 的平均明细化金额，消耗 553,374 个令牌，耗时 5.79 小时。讨论：结合摘要的上下文工程实现了性能与效率的最佳平衡，表明选择性保留最近工具交互比完整历史更具决策相关性，同时大幅减少令牌消耗。我们将这些结果定位为某一类企业工具使用工作流的强有力证据，而非通用泛化的证明，并明确讨论了该方法的范围与局限。

关键词：上下文工程，使用工具的 LLM 智能体，上下文剪枝，对话摘要，模型上下文协议，企业工作流自动化，令牌效率，Dynamics 365 Finance and Operations

Abhilasha Lodha∗，Mahsa Pahlavikhah Varnosfaderani，Abir Chakraborty，Abhinav Mithal

微软

\{ablodha, mahsap, abchak, mithal\}@microsoft.com

## 1. 背景

将大规模语言模型 (LLM) 作为自主智能体部署于企业工作流自动化，代表了人工智能驱动生产力的重大进步 (Brown et al., 2020 (https://arxiv.org/html/2606.10209#bib.bib1))。智能体可以导航复杂多步骤流程，通过工具调用与企业系统交互，并完成以前需要持续人工关注的任务。然而，随着这些智能体参与扩展工作流——特别是那些与企业资源规划 (ERP) 系统交互的工作流——一个根本性的技术限制出现了：由冗长工具响应引起的上下文窗口溢出 (Jiang et al., 2023 (https://arxiv.org/html/2606.10209#bib.bib2))。

现代 LLM 在有限的上下文窗口内运行，限制了每次推理调用可处理的令牌总数。虽然最近的前沿模型已大大扩展了这些限制，但企业系统集成通常会生成包含大量元数据、嵌套表单状态、导航路径信息和系统信息的工具响应，远超出决策相关的范围 (Li et al., 2023 (https://arxiv.org/html/2606.10209#bib.bib3))。在多步骤智能体工作流中，智能体执行数十次工具交互以完成单个任务，即使是大上下文窗口也可能在完成前耗尽。此外，处理成本与上下文长度呈线性增长，使得在生产规模下保留完整历史变得极其昂贵。近期对生产智能体的行业分析将同样的故障模式描述为“上下文腐化”，即在达到硬性上下文限制之前，随着令牌数量增长，模型的有效回忆能力就会下降 (Anthropic, 2025 (https://arxiv.org/html/2606.10209#bib.bib13))。

这个挑战在 Microsoft Dynamics 365 Finance and Operations (D365 F&O) 的费用管理工作流中尤为突出。当 LLM 智能体通过 MCP 代理与 D365 F&O 交互时，每个工具响应可能包含数百到数千个令牌的表单元数据。对于一项费用明细化任务，需要将单张收据分解为 4-22 个单独的明细项目——每个项目都需要多次工具交互来创建、填充和验证——累积的上下文迅速耗尽可用的令牌预算。

费用明细化任务代表了一类广泛的企业智能体挑战：智能体必须将总收据金额分解为多个具有正确子类别和金额的明细行，并严格要求未分配余额精确为零。这种精确性要求意味着部分完成在生产系统中构成失败，导致会计错误、策略违规和手动补救成本。

上下文工程——在每个步骤中有意识地管理智能体上下文中保留哪些信息——提供了一种实用的解决方案。与其维护完整的对话历史（标准做法），上下文工程有选择地保留最决策相关的近期交互，同时摘要或丢弃较旧的上下文。这种方法仅在推理时执行，不需要模型重新训练，并且设计为可跨 LLM 后端移植。

#### 贡献。

本文做出以下贡献：

1. 1. 我们形式化了一种针对工具型智能体的*语义级*上下文工程策略——基于最近性的整体工具调用/响应对剪枝，加上对已驱逐对的自动摘要——并提供了其精确构建算法 (算法 1 (https://arxiv.org/html/2606.10209#alg1))，将其与令牌级提示压缩和外部记忆存储区分开来 (第 2 节 (https://arxiv.org/html/2606.10209#S2))。
2. 2. 在实时 D365 F&O 环境中的 50 项酒店费用基准测试上，我们表明，在用户模型保持不变的情况下，最近性剪枝和剪枝+摘要将完全明细化率从 71.0% 提高到 79.0%，再到 91.6%，*同时*相对于全上下文减少了 62.7% 的令牌和 60.2% 的运行时间。
3. 3. 我们报告了运行间离散度、95% 置信区间和效应量分析 (第 4.6 节 (https://arxiv.org/html/2606.10209#S4.SS6))，并提供了对剪枝窗口 N 和摘要窗口 W 的敏感性分析 (第 4.7 节 (https://arxiv.org/html/2606.10209#S4.SS7))。
4. 4. 我们提供了按类别划分的失败分类法 (第 5 节 (https://arxiv.org/html/2606.10209#S5))，以及跨分属三个结构不同类别的五种费用类型和第二个模型族 Claude Sonnet 4.5 的泛化证据 (第 4.8 节 (https://arxiv.org/html/2606.10209#S4.SS8)–4.9 (https://arxiv.org/html/2606.10209#S4.SS9))。

我们假设：(1) 将上下文限制在最近的工具交互可以提高任务相关关注度，同时防止溢出；(2) 对剪枝上下文进行自动摘要可以在不显著增加令牌开销的情况下保持任务级情境感知。我们的结果支持了针对这类工作流的这两个假设。

## 2. 相关工作

我们沿着三个轴组织先前工作，并针对每个轴定位我们的贡献。表 1 (https://arxiv.org/html/2606.10209#S2.T1) 总结了比较。

#### 令牌级提示压缩。

LLMLingua (Jiang et al., 2023 (https://arxiv.org/html/2606.10209#bib.bib2)) 和 Selective Context (Li et al., 2023 (https://arxiv.org/html/2606.10209#bib.bib3)) 通过删除或合并提示中低信息量的*令牌*来减少输入大小。这些方法在工具交互级别之下运作：它们不推理哪些工具调用/响应*单元*仍与智能体当前状态相关，并且它们可能破坏 ERP 智能体必须逐字读取的结构化表单状态（例如，控件名称、数字余额）。我们的策略在整体工具调用/响应对的*语义级别*上运作，保留保留交互的精确文本，并且总是只驱逐或摘要完整单元。

#### 外部和长期记忆。

MemoryBank (Zhong et al., 2024 (https://arxiv.org/html/2606.10209#bib.bib4)) 和 LongMem (Wang et al., 2024 (https://arxiv.org/html/2606.10209#bib.bib5)) 用可检索的记忆存储增强模型，最近的基准测试如 LoCoMo (Maharana et al., 2024 (https://arxiv.org/html/2606.10209#bib.bib11)) 和 LongMemEval (Wu et al., 2025 (https://arxiv.org/html/2606.10209#bib.bib14)) 评估多会话*对话*中的长周期回忆。这些方法针对跨对话的事实召回，而非工具密集型单会话工作流中的工作记忆和过时状态问题，其中最近的表单状态——而非检索到的事实——才是决策相关的信号。我们表明，对于这种模式，一个轻量级的最近窗口加上一个紧凑的运行摘要就足够了，无需外部存储或检索器。

#### 智能体上下文管理和压缩。

最接近的当代工作线直接研究长周期智能体的上下文管理。ACON (Kang 等人, 2025 (https://arxiv.org/html/2606.10209#bib.bib10)) 学习一种故障驱动的压缩*指南*，并将其提炼到更小的压缩器中；同期工作研究长周期软件工程智能体的上下文管理 (Liu et al., 2025 (https://arxiv.org/html/2606.10209#bib.bib12))；并且提供商平台现在提供了原生的“压缩”和工具结果清除功能 (Anthropic, 2025 (https://arxiv.org/html/2606.10209#bib.bib13))。我们的工作是互补的且故意更简单：一个固定最近性的驱逐策略，带有可选的单次摘要，在*实时企业 ERP* 中进行端到端评估，具有严格的、业务定义的成功标准（零剩余），而不是在 QA 或编码基准上评估。

#### 工具使用基准。

MCP-Bench (Wang 等人, 2025 (https://arxiv.org/html/2606.10209#bib.bib9)) 和相关的 MCP 智能体基准评估跨多个服务器和领域工具使用的广度。我们的研究更窄但更深：一个单一的高风险工作流，具有严格的完成标准，对任务成功*和*成本（令牌、挂钟时间）进行测量，这揭示了广度为导向的基准测试无法孤立出的效率-准确度权衡。

诸如 ReAct (Yao et al., 2023 (https://arxiv.org/html/2606.10209#bib.bib6)) 的智能体推理框架确立了将推理和行动交织的价值，但没有为具有冗长工具响应的扩展工作流规定上下文策略——这正是本文填补的空白。

表 1：相对于先前上下文管理方法的定位。我们的策略作用于整个工具调用/响应对（智能体工作流的语义单元）。

## 3. 方法

### 3.1 任务定义

D365 F&O 中的费用明细化任务要求一个自主 LLM 智能体：(1) 导航到包含已知总金额收据的现有费用报告；(2) 创建与每项购买物品对应的单独明细行；(3) 为每个明细行分配正确的费用子类别（例如，房费、城市税、度假村费、早餐）；(4) 输入正确的美元金额；(5) 继续直到未分配余额恰好等于 $0.00。只有当剩余金额达到零时任务才算完成。任何非零剩余在生产 ERP 工作流中都构成失败，阻止费用报告的最终确定并触发合规审查。

### 3.2 系统架构

评估系统由四个组件组成：

- •GPT-5 智能体：执行自主明细化工作流的主要 LLM (GPT-5)，由详细的智能体系统提示指导，涵盖完整的明细化工作流、有效的费用子类别和子类别映射。
- •用户模型 (仅限于 C2–C4)：一个次要 LLM (GPT-4.1) 作为“用户”参与智能体对话，回答 GPT-5 智能体在执行期间提出的任何后续问题或确认请求。C1 中不存在。
- •D365 F&O MCP 服务器：一个模型上下文协议代理，将 D365 F&O 表单交互暴露为离散工具（表单导航、字段读取、字段值设置、按钮点击）。智能体暴露出一个固定的工具清单，涵盖 UI 级表单交互、实体级数据访问和动作调用；能力级描述在附录 B (https://arxiv.org/html/2606.10209#A2) 中给出。
- •内部评估框架：一个非交互式编排框架，管理智能体-工具交互循环、上下文工程逻辑和指标收集。执行过程中没有人类参与。

来自 D365 F&O 的 MCP 工具响应由于设计原因而冗长，包含完整的表单状态快照，包括字段值、元数据、导航路径和系统状态。单个工具响应可能包含 500-3,000 个令牌，对于复杂的明细化任务，完整的对话历史在 15-30 次工具交互中可能累积到 50,000-150,000+ 个令牌。

### 3.3 实验配置

我们评估了四种配置，代表了从最小到最优工程设计上下文管理的进展：

C1 — GPT-5，无用户模型（激励性消融实验）：GPT-5 配备了完整的智能体系统提示，其中提供了详细的分步明细化工作流指令、有效的 D365 F&O 费用子类别完整列表、子类别映射规则（例如，“酒店税”→\\rightarrow房间税；“客房服务和餐饮”→\\rightarrow客房服务），以及明确的指令，要求持续进行明细化而不中断，直到剩余金额达到零。尽管有这些指令，GPT-5 在实践中偶尔会偏离完全自主执行——中途暂停以提出澄清性问题或在继续之前请求确认。由于评估框架是一个非交互式框架，没有人类参与，这些未回答的查询会完全停滞智能体工作流，导致任务不完整。因此，C1 建立了一个性能下界，并且正如我们在下面明确说明的那样，它作为用户模型的*激励性消融实验*，而不是上下文工程阶梯中的一步。

C2 — GPT-5 + 用户模型（全上下文）：为了解决在 C1 中观察到的非交互式框架限制，引入了一个用户模型 (gpt-4.1) 作为对话参与者。GPT-5 智能体现在可以在任务中途提出问题，并获得有意义的响应，使工作流继续进行。用户模型由一个 `user_context` 指导，该上下文定义了一个严格的完成协议：只有费用明细行被保存、明细化剩余金额为 0.00 *并且*表单被关闭时，任务才被认为完成。用户模型还被指示处理常见的智能体查询——确认应添加缺失的明细项、拒绝不必要的收据或费用报告附件请求，并在每次明细化遍历后提示智能体验证完成。整个执行过程中保留完整的对话历史。这种配置代表了使用用户模型的标准化智能体实践。