要点速览： 新研究证实，对复杂的工具调用型人工智能体而言，提供更少但更相关的上下文反而能提升表现。正确的做法是优先投入上下文工程，而不是一味选用上下文窗口最大的模型。
1. 执行摘要
人工智能行业陷入了一场规模竞赛，基础模型供应商争相把越来越大的上下文窗口宣传为解锁更复杂能力的钥匙。我们看到谷歌、Anthropic 等厂商的模型，已能在单次提示中吞下整本小说或整个代码库。主流假设一直是：上下文越多越好。然而，近期一篇论文 更少的上下文，更好的智能体：面向长周期工具调用型大语言模型智能体的高效上下文工程 提供了有力的反证。对企业急于部署的那类精巧多步骤智能体工作流而言，用超大上下文窗口蛮力解决问题，反而可能拖累性能、推高成本，并带来无法接受的时延。
我们认为，这一发现标志着行业的一个关键成熟节点：重心正从大语言模型的原始容量，转向有效驾驭它们所需的工程学科。上下文工程——在任务的每一步中智能地选择、摘要并管理喂给模型的信息——正成为构建可靠且经济可行的人工智能体的核心能力。单纯挑选上下文窗口最大的模型，已不再是一条充分的策略。相反，工程团队必须构建精巧的上下文管理系统，去模拟一种更接近人类的记忆与专注方式。
对企业领导者而言，这是个好消息：它意味着卓越表现不再是算力预算最雄厚者的专属。巧妙的架构与有纪律的工程，就能带来显著的竞争优势。通过投资上下文工程能力，机构可以构建出不仅更准确、而且更快、运行成本大幅更低的智能体，为复杂自动化的正向投资回报铺平道路。
关键要点：
- 【带指标的战略洞察】： 在长周期智能体任务中，智能裁剪上下文可把任务成功率提升 10-15%，同时把 token 消耗与运营成本压低 50% 以上。
- 【竞争层面的含义】： 精通上下文工程的团队将构建出更快、更便宜、更可靠的智能体，相较依赖蛮力堆上下文的竞争对手形成显著的性能与成本优势。
- 【落地要素】： 这需要新的机器学习运维范式，把状态管理、动态摘要与检索增强生成（RAG）直接集成进智能体的推理循环。
- 【业务价值】： 直接收益是更低的运营成本、因时延下降带来的更高吞吐，以及自动化工作流更高的可靠性，从而带来更可预测的人工智能投资回报。
2. 超越蛮力：上下文裁剪的逻辑
在漫长的多步骤智能体任务中——比如预订一趟复杂的行程或排查一个软件故障——对话历史会膨胀得极为庞大。朴素的做法是把每一条用户查询、工具调用与模型响应统统追加到一个不断膨胀的提示词里。逻辑看似简单：赋予模型完美的记忆。问题在于，大语言模型和人一样，会在噪声中迷失。对话早期的内容可能与后续步骤无关甚至矛盾，而关键信息可能淹没在超大上下文窗口的中段。这就是有据可查的”中段迷失”现象，只不过被放大到了整个工作流的尺度。
高效的人类问题解决者，不会把一场数小时会议的逐字记录一直存在工作记忆里。我们会自然地做摘要、丢弃无关细节、聚焦于关键决策与行动项。上下文工程把同样的原则应用到人工智能体上：它不把上下文窗口当作被动的数据倾倒场，而当作一个被主动管理的工作台。这需要更精巧的架构，从简单的 API 调用，走向能够对自身历史进行推理的有状态系统。这一路径所回答的核心问题是：我们该如何从朴素的全历史做法，转向为人工智能体精心设计的上下文流水线？
flowchart TD
subgraph Task Ingestion
A([接收用户请求]):::input --> B["拆解为<br/>初始子任务"]:::process
end
subgraph Agentic Loop
B --> C{"上下文窗口<br/>是否接近上限？"}:::decision
C -->|否| D["选择下一个工具<br/>如检索 API"]:::process
C -->|是| E["触发上下文<br/>管理模块"]:::module
E --> D
D --> F["构造工具输入<br/>（JSON 负载）"]:::process
F --> G[["执行工具<br/>（如 Salesforce API）"]]:::external
G --> H["接收工具输出<br/>（API 响应）"]:::process
H --> I["把工具输入输出<br/>追加到短期历史"]:::process
I --> J{"主任务是否<br/>已完成？"}:::decision
J -->|否| C
J -->|是| K["依据历史综合出<br/>最终答案"]:::process
K --> L([交付响应]):::output
end
subgraph Context Management [上下文管理模块]
E --> M["为最早的交互<br/>生成摘要"]:::process
M --> N["识别并裁剪<br/>冗余的工具调用"]:::process
N --> O[("更新紧凑的<br/>工作上下文")]:::input
O --> E
end
该图揭示出一处关键的架构转变：在智能体的主推理循环内部引入了专门的”上下文管理模块”。智能体不再盲目追加数据，而是周期性评估自身上下文，必要时触发一个子流程去摘要、裁剪并压缩历史。这样便形成了一份紧凑而相关的”工作上下文”，让模型专注于眼前任务，同时避免信息过载。相比单纯依赖某个模型的原始容量，这是一种稳健得多也高效得多的设计。正如我们此前所主张的，工具调用型人工智能体依靠编排而非单体模型取胜。
| 考量维度 | 当前／传统做法 | Thinkia 建议做法 | 预期影响 |
|---|---|---|---|
| 上下文处理策略 | 朴素追加（全历史）： 每一轮模型调用都把完整对话与工具调用历史一并发送。 | 主动上下文工程： 借助摘要、裁剪与 RAG，维持一份紧凑且相关的上下文状态。 | token 成本降低 30-60%，任务成功率提升约 15%，时延显著下降。 |
| 智能体架构 | 单体式： 依赖单个大模型的原始能力与超大上下文窗口包办一切。 | 模块化与编排式： 采用 LangGraph 等框架，为上下文管理、工具调用与推理设置专门模块。 | 可靠性更高、调试更容易，并可为子任务启用更小、更专门的模型。 |
| 首要性能指标 | 上下文窗口大小（token 数）： 以模型理论上能处理的数据量来衡量成败。 | 每 token 的任务成功率： 以智能体的经济效率与实际效果来衡量成败。 | 厂商评估的战略重心，从原始容量转向经成本调整后的实证表现。 |
3. 企业领导者应该做什么
采用上下文工程不只是一次技术微调，而是任何认真想大规模部署智能体式人工智能的机构的战略要务。它把智能体开发从提示工程的技艺，提升为更严谨的软件工程学科。对首席信息官、首席技术官与首席数据官而言，这意味着要在机器学习运维与人工智能开发生命周期中培育新技能、引入新工具。目标是构建不只有能力，而且高效、可观测、可治理的系统。
支撑这一路径的工具正在快速成熟。LangGraph、CrewAI 等框架提供了构建有状态智能体所需的控制流，让上下文管理逻辑可以被显式定义。它们通常与向量数据库搭配，后者充当智能体的长期记忆：智能体可以按需查询这份记忆来取回相关的过往信息，而不必把一切都留在活跃上下文窗口里。短期工作记忆与长期可检索记忆的这种组合，是应对复杂任务的有力范式。
企业还有一项关键考量是治理与可审计性：如果智能体裁剪了自己的上下文，你如何追溯它的决策过程？解法是把智能体的工作上下文与不可篡改的日志分开。智能体为效率而在一份压缩过的现实上运作，但所有交互、工具调用与上下文状态的完整未删节日志必须被留存，以供调试、合规检查与性能分析。这套双重日志机制，是生产级负责任人工智能的必要条件。
要把这些原则付诸实践，我们建议清晰的四步法：
- 先测基线。 优化之前必先度量。用朴素的”全上下文”方式部署一个基线版本的智能体，细致跟踪其成本、时延与任务成功率。这些数据是为更精巧上下文工程技术争取投入的商业论证基础。
- 采用状态驱动的编排框架。 摆脱简单线性的大语言模型调用链，改用基于图的框架，以支持显式状态管理与条件逻辑。这一架构选择，是插入上下文裁剪、摘要与检索等自定义模块的基础。
- 实施分层记忆体系。 为智能体设计至少两层记忆：承载最近若干轮交互（例如最近 5-10 轮）的短期”工作记忆”，以及存放在向量数据库中的长期可检索记忆。仅当智能体判定需要时，才用 RAG 把相关历史事实拉进工作记忆。
- 建立上下文可观测层。 日志与监控系统必须同时记录发给模型的裁剪后”工作上下文”，以及交互的完整不可篡改历史。这一双重视角对调试智能体行为至关重要，也能确保你满足新兴监管在文档与透明度上的要求——具体流程见我们的 欧盟《人工智能法案》合规清单。
5. 常见问题
问：等到上下文窗口无限大且几乎免费，这是不是就成了一个临时的权宜之计？
答： 我们视之为一项根本原则，而非临时权宜。即便上下文窗口极大，“中段迷失”问题仍可能存在，而时延在面向用户的应用中永远是个因素。智能筛选是高效计算的核心理念，我们相信即使模型容量继续增长，它依然切题。
问：我的团队需要哪些技能来落实上下文工程？
答： 这超出了基础提示工程的范畴，需要机器学习运维、数据工程与软件架构技能的融合。团队应当熟悉有状态系统、基于图的编排、API 与数据结构。Thinkia 的 智能体式人工智能落地 服务，正聚焦于为企业团队打造这些跨职能能力。
问：这会如何改变我们的模型选型策略？
答： 它降低了”上下文窗口大小”作为首要标准的权重。一套有效的上下文工程策略，能让更小、更快、更便宜的模型在复杂长周期任务上胜过更大更贵的模型。你的评估流程应转向衡量”在一个经过工程化编排的系统中”的任务表现。
问：上下文工程适用于所有生成式人工智能用例吗？
答： 它的影响在多步骤、工具调用型智能体工作流中最为显著，例如自动化 IT 支持、复杂数据分析或自主软件开发智能体。对于摘要一份能装进上下文窗口的文档这类单次简单任务，收益就没那么明显。
6. 结论
单以模型上下文窗口大小来衡量人工智能进步的时代，正在落幕。大上下文固然是一项有价值的能力，但最新研究与我们自身的一线实践都表明，它并非灵丹妙药。对于那些最有望带来企业价值的复杂长周期任务而言，原始规模正让位于工程上的精巧。表现最好、效率最高的人工智能体，不会是用了最大模型的那些，而会是架构最聪明的那些。
我们认为，上下文工程是企业人工智能团队接下来必须掌握的关键学科。它代表着一次根本转向：走向更审慎、更高效、也最终更可靠的人工智能系统。通过专注于信息如何被管理并呈现给模型，机构得以解锁全新层级的性能，并在人工智能投入上获得更可持续、更可预测的回报。构建持久的生产级智能体系统需要这种有纪律的工程方法，而我们正与企业领导者携手，超越模型参数的炒作，把它切实落地。