For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
主导航
2026年2月11日 API

Shell + 技能 + 压缩:让长时间运行的智能体完成实际工作的技巧

在 Responses API 中结合技能、托管式 Shell 和服务端压缩进行构建的实用模式。

作者: Charlie Guo

Shell + 技能 + 压缩:让长时间运行的智能体完成实际工作的技巧

我们正在从单轮助手转向长时间运行的智能体,让它们处理实际的知识工作:读取大型数据集、更新文件和编写应用。

根据开发者反馈,以及我们构建 Codex 和内部智能体的经验,我们正在推出一组新的智能体基础能力,让持续较长时间的任务更切实可行:

  • 技能(遵循 Agent Skills 开放标准):可复用且带有版本管理的指令,您可以将其挂载到容器中,让智能体更可靠地执行任务。
  • 升级后的 Shell 工具:由 OpenAI 托管的容器,提供受控的互联网访问,智能体可以在其中安装依赖项、运行脚本并写入输出内容(例如报告和产物)。
  • 服务端压缩:一种简单的方法,可在智能体长时间运行时自动压缩上下文,让您不再触及上下文限制。

文档和 API 参考分别介绍了上述各项功能。本文重点介绍一些不易察觉的技巧和模式。这些做法来自我们在 OpenAI 的工作,以及技能的早期客户 Glean 的生产实践,是我们迄今观察到效果最好的做法。

快速理解这些概念

技能:模型可按需加载的“操作流程”

技能由一组文件和一个包含 frontmatter 与指令的 SKILL.md 清单组成。可以将它理解为一本带有版本管理的操作手册,模型在需要完成实际工作时可以查阅。

当有可用技能时,平台会向模型提供每项技能的 namedescriptionpath。模型根据这些元数据决定是否调用技能。如果决定调用,它就会读取 SKILL.md,了解完整的工作流程。

Shell 工具:为智能体提供“执行”能力

Shell 工具让模型可以在真实的终端环境中工作,环境可以是:

  • 由 OpenAI 管理的托管容器。
  • 由您自行运行的本地 Shell 运行时(工具语义相同,但机器由您掌控)。

托管式 Shell 通过 Responses API 运行,这意味着您的请求支持保留工作状态、调用工具、跨多轮继续执行以及产物输出。

压缩:让长时间运行的任务持续推进

随着工作流程越来越长,上下文窗口会达到上限。服务端压缩会管理上下文窗口并自动压缩对话历史,让长时间运行的任务持续推进。

Responses API 的压缩功能提供了两种处理方式:

  • 服务端压缩(新增): 当上下文超过阈值时,压缩会在流式处理过程中自动运行,无需单独发起压缩调用。
  • 独立压缩端点: 如果您希望明确控制压缩发生的时机,请使用 /responses/compact

为什么组合使用效果更好

  • 技能将稳定的操作流程和示例移入可复用的文件包中,减少提示内容的杂乱和相互纠缠。
  • Shell 提供完整的执行环境,让您可以安装代码、运行脚本并写入输出内容。
  • 压缩可以保持长时间运行任务的连续性,让同一个工作流程持续执行,无需手动调整上下文。
  • 将它们组合使用,您就能获得可重复执行、能完成实际操作的工作流程,而不必把系统提示堆成一份庞大且容易出错的文档。

实用技巧

1)像编写路由逻辑一样编写技能描述(而不是营销文案)

技能描述实际上决定了模型如何判断是否使用该技能。它应回答以下问题:

  • 什么时候应该使用这项技能?
  • 什么时候不应该使用这项技能?
  • 输出内容和成功标准是什么?

一个实用的做法是直接在描述中加入一小段“适用场景与不适用场景”,并写明具体内容(输入、涉及的工具、预期产物)。

2)添加反例和边界情况,减少错误触发

一种出人意料的失败情况是:提供技能后,正确触发率在初期反而可能下降。我们发现,一种有效的解决办法是添加反例,并覆盖边界情况。

具体来说,就是明确写出几个“在……情况下不要调用这项技能”的例子,并说明应该改用什么做法。这有助于模型更准确地选择技能,尤其是在多项技能乍看之下很相似时。

Glean 直接遇到了这种情况:在专项评测中,基于技能的路由最初使触发率下降了约 20% ;在描述中加入反例并覆盖边界情况后,触发率得以恢复。

3)将模板和示例放入技能中(不用时基本没有开销)

如果您一直在往系统提示里塞模板,请停止这种做法。

将模板和完整示例放在技能中有两个好处:

  • 它们在需要时即可使用,也就是技能被调用时。
  • 它们不会增加无关查询的 Token 用量。

这种做法对知识工作的输出内容尤其有效,例如:

  • 结构化报告。
  • 升级问题的分流摘要。
  • 客户规划。
  • 数据分析报告。

Glean 表示,这种模式为他们在生产环境中的质量提升和延迟改善带来了部分最显著的收益,因为这些示例只会在技能触发时加载。

4)尽早通过容器复用和压缩,为长时间运行做好设计

执行长时间任务的智能体很少能仅靠一次提示就成功完成工作。从一开始就应规划如何保持连续性:

  • 如果您希望保持依赖项稳定,并保留缓存文件和中间输出,请在各个步骤中复用同一个容器。
  • 传入 previous_response_id,让模型可以在同一对话线程中继续工作。
  • 将压缩作为长时间运行任务的默认基础能力,而不是紧急兜底措施。

这种组合可以减少从头开始的情况,并在对话线程不断增长时保持多步骤任务的连贯性。

5)需要确定性时,明确告诉模型使用哪项技能

默认情况下,模型自行决定何时使用技能。这通常符合您的需求。

但如果您运行的生产环境工作流程有明确约定,而且您更希望执行过程确定,而不是让模型灵活判断,那么只需告诉它:

“使用 <skill name> 技能。”

这是提升可靠性最简单的办法。它将模糊的路由选择变成明确的约定。

6)将技能与联网视为高风险组合(设计时做好隔离和限制)

这条安全建议现在很容易被忽略,但日后补救会很困难。

将技能与开放的网络访问结合使用,会形成数据外泄的高风险通道。 如果您使用联网功能,请严格限制网络允许列表,将工具输出视为不可信内容;对于面向消费者、用户期望有严格确认机制的流程,应避免将开放的互联网访问与功能强大的操作流程结合使用。

稳妥的默认安全配置如下:

  • 技能: 允许
  • Shell: 允许
  • 网络:针对范围严格限定的任务,按请求 仅在配置最小允许列表后启用

7)将 /mnt/data 作为产物的交接位置

对于托管式 Shell 工作流,将 /mnt/data 作为输出的统一存放位置,供您提取、审查或传入后续步骤。这些输出可以是报告、清理后的数据集以及处理完成的电子表格。

可以这样理解:工具将内容写入磁盘,模型基于磁盘上的内容进行推理,开发者从磁盘提取成果。

8)理解允许列表的双层机制(组织级和请求级)

网络访问由两个层级控制:

  • 组织级允许列表由管理员配置,规定允许访问的目标范围上限。
  • 请求级 network_policy 必须是组织允许列表的子集。

实际操作中,有两点需要注意:

  1. 让组织允许列表保持精简和稳定,其中包含“您信任且已批准的目标”。
  2. 让请求允许列表的范围更小,仅包含“当前任务所需的目标”。

如果请求包含组织允许列表之外的域名,就会报错。

9)使用 domain_secrets 进行需要身份验证的调用(避免凭据泄露)

如果允许访问的域名需要身份验证标头,请使用 domain_secrets,确保模型始终无法看到原始凭据。

运行时,模型看到的是占位符(例如 $API_KEY),由边车组件仅针对已批准的目标注入真实值。只要您的智能体需要从容器内调用受保护的 API,这就是一种稳妥的默认做法。

10)在云端和本地使用相同的 API

您无需将所有内容都交由托管,也能使用这两种基础能力:

  • 技能同时适用于托管式 Shell 和本地 Shell 模式。
  • Shell 提供本地执行模式,您可以自行执行 shell_call,并将 shell_call_output 返回给模型。
  • 如果您使用 Agents SDK,还可以接入自己的 Shell 执行器。

一种实用的开发迭代流程如下:

  1. 从本地开始(迭代快、可访问内部工具、便于调试)。
  2. 当您需要可重复性、隔离性和部署一致性时,迁移到托管容器。
  3. 在两种模式下保持技能一致(即使执行环境发生变化,工作流也能保持稳定)。

三种构建模式

您可以自由探索这些新的智能体基础能力。下面提供三个示例,展示如何将它们组合起来,构建实用的应用。

模式 A:安装 -> 获取数据 -> 写入产物

这是使用托管式 Shell 获益的最简单方式:让智能体安装依赖项、获取外部数据,并生成具体的交付成果。

例如:

  • 安装几个库。
  • 抓取数据或调用 API。
  • 将报告写入 /mnt/data/report.md

这种模式是构建能完成实际工作的智能体的基础,因为它划定了清晰的审查边界:您的应用可以将产物展示给用户、记录下来、比较差异,或将其传入后续步骤。

模式 B:结合技能与 Shell,构建可重复执行的工作流

当您成功构建一两个 Shell 工作流后,就会发现下一个问题:流程虽然可行,但提示逐渐偏离原意时,可靠性就会下降。

这时,技能就能派上用场。以下是一套可以长期沿用的结构:

  1. 将工作流程(步骤、护栏、模板)编写到技能中。
  2. 将技能挂载到您的 Shell 环境中。
  3. 让智能体遵循技能,以确定性的方式生成产物。

这种方式对以下工作流尤其有效:

  • 分析或编辑电子表格。
  • 清理数据集并生成摘要。
  • 为周期性业务流程生成标准化报告。

模式 C(高级):用技能承载企业工作流

我们在早期观察到一个现象:从单次工具调用扩展到多工具编排时,准确率会下降。技能可以让工具使用相关的推理更有章可循,从而弥补这一差距,同时避免系统提示变得臃肿。

以下是 Glean 的一个具体案例:

  • 一项面向 Salesforce 的技能提高了评测准确率( 73% -> 85% ),并将 首个 Token 延迟 缩短了 18.1%
  • 具体做法包括精心设计路由、提供反例,以及在技能中嵌入模板和示例。
  • Glean 还将企业工作流中的常规任务编写为技能,包括客户规划、升级问题分诊,以及生成符合品牌风格的内容。

这正是技能发挥更大作用的方向。技能成为持续演进的 SOP(标准操作规程):随着组织发展不断更新,并由智能体一致地执行。

一次构建,随处运行

当长时间运行的智能体既能遵循流程,又能在计算机上完成实际工作时,它们的实用性就会大幅提升。技能、托管式 Shell 和压缩共同构成了这一基础。总结如下:

  • 用技能明确“怎么做”(流程、模板、护栏)。
  • 用 Shell 执行具体操作(安装、运行、写入产物)。
  • 用压缩保持长时间运行任务的连贯性,无需手动管理上下文。
  • 需要快速迭代时,从本地开始。
  • 需要可重复且相互隔离的执行环境时,迁移到托管容器。
  • 通过组织级和请求级允许列表严格限制网络访问,并使用域名密钥进行需要身份验证的调用。

在您自己的应用中开始使用吧。请参阅技能文档Shell 文档压缩文档,了解具体做法。