OpenAI 发布长时运行智能体实践指南:Skills、shell 工具与服务端 compaction
Shell + Skills + Compaction: Tips for long-running agents that do real work
OpenAI 基于 Codex 与内部智能体经验发布一组智能体原语实践指南,包括 Skills(对齐 Agent Skills 开放标准的可复用版本化指令)、支持安装依赖和写输出的托管 shell 工具,以及自动压缩对话历史的服务端 compaction。
OpenAI 以自家和 Glean 的生产经验总结了 Skills、shell 与 compaction 的组合模式,含可操作的路由与安全建议。
我们正在从单轮助手转向能够处理真实知识工作的长期运行的智能体:读取大型数据集、更新文件以及编写应用。
基于开发者的反馈以及我们在构建 Codex 和内部智能体时的经验,我们发布了一组新的智能体原语,让长周期工作更加实用:
- Skills(与 Agent Skills 开放标准保持一致):可复用、带版本控制的指令,你可以将其挂载到容器中,让智能体更可靠地执行任务。
- 升级版 shell 工具:一个由 OpenAI 托管的容器,具备受控的互联网访问能力,智能体可以在其中安装依赖、运行脚本并写入输出(例如报告和产物)。
- 服务端压缩:一种简便的方式,可自动压缩长时间运行的智能体任务,让你永远不会触及上下文上限。
文档和 API 参考分别涵盖了上述每一项。本文聚焦于我们迄今为止在实践中发现最有效的那些不那么显而易见的技巧和模式,既包括我们在 OpenAI 的工作,也包括早期 Skills 客户 Glean 的生产实践。
一个简明的思维模型
Skills:模型可按需加载的“流程”
一个 skill 是一组文件加上一个 SKILL.md 清单,其中包含 frontmatter 和指令。可以把它想象成一本带版本控制的剧本,模型在需要做实际工作时可以查阅。
当 skills 可用时,平台会向模型暴露每个 skill 的 name、description 和 path。模型利用这些元数据来决定是否调用某个 skill。如果调用,它会读取 SKILL.md 以获取完整的工作流程。
Shell 工具:智能体的“执行”能力
shell 工具让模型能够在真实的终端环境中工作,可以是:
- 由 OpenAI 托管的容器。
- 由你自己执行的本地 shell 运行时(工具语义相同,但机器由你掌控)。
托管 shell 通过 Responses API 运行,这意味着你的请求自带状态化工作、工具调用、多轮续接和产物。
压缩:让长时间运行持续推进
随着工作流变得越来越长,它们会触及上下文窗口上限。服务端压缩通过管理上下文窗口并自动压缩对话历史,让长时间运行持续推进。
Responses API 中的压缩为你提供了两种处理方式:
- 服务端压缩(新增):当上下文越过阈值时,压缩会在流中自动运行,因此无需单独的压缩调用。
- 独立的 compact 端点:当你希望对压缩发生的时机进行显式控制时,使用
/responses/compact。
为什么它们组合起来更好
- Skills 通过将稳定的流程和示例移入可复用的包中,减少了提示词意大利面。
- Shell 提供了完整的执行环境,让你可以安装代码、运行脚本并写入输出。
- 压缩在长时间运行中保持连续性,因此同一工作流可以持续执行,而无需手动对上下文动手术。
- 结合起来,你就能获得具备真实执行能力的可重复工作流,而无需把系统提示词变成一份脆弱的大杂烩文档。
技巧与窍门
1)像写路由逻辑一样写 skill 描述(而不是营销文案)
你的 skill 描述实际上就是模型的决策边界。它应该回答:
- 我应该在什么时候使用它?
- 我应该在什么时候不使用它?
- 输出和成功标准是什么?
一个实用的模式是直接在描述中包含一个简短的“何时使用 vs. 何时不使用”区块,并保持具体(输入、涉及的工具、预期产物)。
2)添加反例和边缘情况以减少误触发
一个令人意外的失败模式是,让技能可用最初反而会降低正确触发率。我们看到有效的一个修复方法是负例加上边缘情况覆盖。
在实践中,这意味着写几个明确的“当……时不要调用此技能”的案例(以及应该改做什么)。这有助于模型更清晰地进行路由,尤其是在你有多个乍看之下很相似的技能时。
Glean 直接观察到了这一点:在针对性评估中,基于技能的路由最初使触发率下降了约 20%,随后他们在描述中添加了负例和边缘情况覆盖后得以恢复。
3) 将模板和示例放入技能内部(未使用时基本零成本)
如果你一直把模板塞进系统提示词里,请停止。
技能内部的模板和示例有两个优势:
- 它们恰好在需要时可用(当技能被调用时)。
- 它们不会为无关查询增加 token。
这对知识工作产出尤其有效,例如:
- 结构化报告。
- 升级分诊摘要。
- 客户计划。
- 数据分析报告。
Glean 报告称,这种模式在生产环境中带来了他们最大的质量和延迟改进,因为这些示例仅在技能触发时才加载。
4) 尽早为长时间运行做设计,利用容器复用和压缩
长周期智能体很少能靠一次性提示词成功。从一开始就规划好连续性:
- 当你需要稳定的依赖、缓存文件和中间输出时,跨步骤复用同一个容器。
- 传递
previous_response_id,以便模型可以在同一线程中继续工作。 - 将压缩作为默认的长时运行原语,而非紧急回退方案。
这种组合减少了重启行为,并随着线程增长保持多步骤任务的一致性。
5) 当你需要确定性时,明确告诉模型使用该技能
默认行为是模型自行决定何时使用技能。这通常是你想要的。
但当你运行具有明确契约的生产工作流时(而且你宁愿确定性而非聪明),只需说:
“使用 <skill name> 技能。”
这是你可以拉动的最简单的可靠性杠杆。它将模糊的路由转变为明确的契约。
6) 将技能加网络视为高风险组合(为隔离而设计)
这是那种现在容易被忽视、以后却难以修复的安全提示。
将技能与开放网络访问结合会为数据外泄创造高风险路径。如果你使用网络,请保持网络允许列表严格,假设工具输出不可信,并避免在面向消费者的流程中同时使用开放互联网和强大的过程,因为用户期望有强确认控制。
一个强有力的默认姿态:
- 技能:允许
- Shell:允许
- 网络:仅在最小允许列表下启用,按请求、针对范围狭窄的任务
7) 将 /mnt/data 作为产物的交接边界
对于托管 shell 工作流,将 /mnt/data 视为写入你将检索、审查或传回后续步骤的输出的标准位置。示例包括报告、清理后的数据集和完成的电子表格。
一个好的心智模型:工具写入磁盘,模型在磁盘上推理,开发者从磁盘检索。
8) 将允许列表理解为两层系统(组织级和请求级)
网络在两个地方受到控制:
- 组织级允许列表(由管理员配置),设定允许的最大目的地。
- 请求级
network_policy,必须是组织允许列表的子集。
两个在操作上重要的含义:
- 保持组织允许列表小而稳定(即“你信任的已批准目标”集合)。
- 让请求允许列表更小(即“这一项任务所需的目标”集合)。
如果请求包含组织允许列表之外的域名,就会报错。
9) 使用 domain_secrets 进行经过身份验证的调用(避免凭据泄露)
如果某个允许的域名需要认证头,请使用 domain_secrets,这样模型就永远不会看到原始凭据。
在运行时,模型看到的是占位符(例如 $API_KEY),而 sidecar 只会为已批准的目标注入真实值。当你的 agent 需要在容器内调用受保护的 API 时,这是一个强有力的默认做法。
10) 在云端和本地使用相同的 API
你可以同时使用这两种原语,而不必承诺把所有东西都托管起来:
- Skills 可与托管 shell 和本地 shell 模式配合使用。
- Shell 有一种本地执行模式,你可以自己执行
shell_call,并把shell_call_output返回给模型。 - 如果你使用的是 Agents SDK,你也可以接入自己的 shell 执行器。
一个实用的开发循环大致如下:
- 从本地开始(快速迭代、可访问内部工具、易于调试)。
- 当你需要可重复性、隔离性和部署一致性时,转向托管容器。
- 在两种模式下保持 skills 相同(即使执行位置发生变化,工作流也保持稳定)。
三种构建模式
虽然你可以随意试验这些新的 agentic 原语,但这里有三个示例,展示如何将它们组合起来构建有用的应用。
模式 A:安装 -> 获取 -> 写入产物
这是从托管 shell 中获益的最简单方式:agent 安装依赖、获取外部数据,并产出一个具体的交付物。
例如:
- 安装几个库。
- 抓取或调用 API。
- 将报告写入
/mnt/data/report.md。
这种模式是真实工作 agent 的基础,因为它创建了清晰的审查边界:你的应用可以向用户展示产物、记录它、对它做 diff,或将其送入后续步骤。
模式 B:Skills + shell 实现可重复的工作流
一旦你构建了一两个成功的 shell 工作流,你就会注意到下一个问题:这能行,但当提示词漂移时,可靠性会下降。
这就是 skills 发挥作用的地方。以下是一个可长期遵循的结构:
- 将工作流(步骤、护栏、模板)编码进一个 skill。
- 将该 skill 挂载到你的 shell 环境中。
- 让 agent 遵循该 skill,确定性地产出产物。
这对以下工作流尤其有效:
- 电子表格分析或编辑。
- 数据集清理加摘要生成。
- 为重复性业务流程生成标准化报告。
模式 C(高级):将 Skills 作为企业工作流载体
我们观察到的一个早期模式是:在单工具调用与多工具编排之间的鸿沟中,准确性会下降。Skills 可以通过让工具推理更具流程化、同时不使系统提示词膨胀,来弥合这一差距。
来自 Glean 的一个具体示例:
- 一个面向 Salesforce 的 skill 将评估准确率从 73% -> 85% 提升,并将 time-to-first-token 降低了 18.1%。
- 实用策略包括谨慎路由、反例,以及在 skill 内嵌入模板/示例。
- Glean 还使用 skills 来编码企业工作流中的重复性任务,包括客户规划、升级分诊和品牌一致性内容生成。
这就是事情变得强大的形态。Skills 成为活的 SOP(标准操作程序):随着你的组织演进而更新,并由 agent 一致地执行。
一次构建,随处运行
当长时间运行的智能体既能遵循流程,又能在计算机上完成实际工作时,它们会变得有用得多。Skills、托管 shell 和压缩共同构成了这一基础。回顾一下:
- 使用 skills 来编码“怎么做”(流程、模板、护栏)。
- 使用 shell 来执行“做”(安装、运行、写入产物)。
- 使用压缩来保持长时间运行的一致性(无需手动管理上下文)。
- 在快速迭代时,从本地开始。
- 当你想要可重复、隔离的执行时,转向托管容器。
- 通过组织级和请求级允许列表锁定网络,并使用域密钥进行经过身份验证的调用。
来源:OpenAI Developers:Blog(网页) · developers.openai.com