跳到正文

Shell + Skills + Compaction:让长时间运行的智能体真正干活的技巧

本文目录文章开头

我们正在从单轮助手转向能够处理真实知识工作的长时运行智能体:阅读大型数据集、更新文件以及编写应用。

基于开发者的反馈以及我们构建 Codex 和内部智能体的自身经验,我们发布了一组新的智能体原语,使长时程工作更加切实可行:

  • Skills(与 Agent Skills 开放标准对齐):可复用、带版本的指令,你可以将其挂载到容器中,使智能体能够更可靠地执行任务。
  • 升级后的 shell 工具:一个由 OpenAI 托管的容器,具备受控的网络访问权限,智能体可以在其中安装依赖、运行脚本并写出输出(例如报告和工件)。
  • Server-side compaction:一种自动压缩长时智能体运行的简便方式,让你永远不会触及上下文限制。

文档和 API 参考分别涵盖了上述每一项。本文重点介绍我们迄今为止观察到的最有效的非显而易见的技巧和模式,这些经验既来自我们在 OpenAI 的工作,也来自 Glean(早期 Skills 客户)的生产实践。

一个简短的心智模型

Skills:模型可按需加载的“程序”

一个 Skill 是一组文件加上一个 SKILL.md 清单,其中包含 frontmatter 和指令。可以理解为:一份带版本的操作手册,模型在需要开展实际工作时可以查阅。

当 Skills 可用时,平台会将每个 Skill 的 name、description 和 path 暴露给模型。模型利用这些元数据来决定是否调用某个 Skill。如果决定调用,它会读取 SKILL.md 以获取完整的工作流。

Shell 工具:智能体的“执行”环境

shell 工具让模型能够在真实的终端环境中工作,方式包括:

  • 由 OpenAI 托管的容器。
  • 你自己执行的本地 shell 运行时(工具语义相同,但由你控制机器)。

托管 shell 通过 Responses API 运行,这意味着你的请求带有有状态的工作、工具调用、多轮续接和工件。

Compaction:让长时运行持续推进

随着工作流变长,它们会遇到上下文窗口限制。Server-side compaction 通过管理上下文窗口并自动压缩对话历史,使长时运行得以持续推进。

Responses API 中的 compaction 提供了两种处理方式:

  • Server-side compaction(新增):当上下文超过阈值时,compaction 会在流中自动运行,因此无需单独的 compaction 调用。
  • 独立的 compact 端点:当你想显式控制 compaction 发生的时机时,使用 /responses/compact。

为什么它们协同工作效果更好

  • Skills 通过将稳定的程序和示例移入可复用的包中,减少了提示词的杂乱无章。
  • Shell 提供了完整的执行环境,让你能够安装代码、运行脚本并写出输出。
  • Compaction 在长时运行中保持了连续性,使同一工作流无需手动的上下文手术即可持续执行。
  • 三者结合,你将获得带有真实执行能力的可重复工作流,而无需把你的系统提示词变成脆弱的巨型文档。

技巧与窍门

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

你的 Skill 描述实际上就是模型的决策边界。它应该回答:

  • 我什么时候应该使用这个?
  • 我什么时候不应该使用这个?
  • 输出和成功标准是什么?

一个实用的模式是在描述中直接包含一个简短的“何时使用 vs. 何时不使用”区块,并保持具体(输入、涉及的工具、预期的工件)。

2) 添加反例和边缘情况以减少误触发

一种令人意外的失败模式是,让技能可用最初反而会降低正确触发率。我们见过的一种有效修复方法是加入负面示例和边缘情况覆盖。

在实践中,这意味着编写一些明确的“不要在……时调用此技能”的用例(以及应该怎么做)。这有助于模型更清晰地进行路由,尤其是当你有多个乍看之下相似的技能时。

Glean 直接观察到了这一点:在针对性评估中,基于技能的路由最初使触发率下降了约20%,但在他们在描述中加入负面示例和边缘情况覆盖后,触发率得以恢复。

3)将模板和示例放在技能内部(未使用时它们基本不消耗成本)

如果你一直把模板硬塞进系统提示中,请停止这样做。

技能内部的模板和工作示例有两个优点:

  • 它们恰好在需要时可用(当技能被调用时)。
  • 它们不会为无关查询增加 token 消耗。

这对于知识工作产出尤其有效,例如:

  • 结构化报告。
  • 升级处理分诊摘要。
  • 客户账户计划。
  • 数据分析报告。

Glean 报告称,这种模式在生产环境中为其带来了最大的质量和延迟提升,因为这些示例仅在技能触发时才会加载。

4)尽早为长时运行设计容器复用和压缩

长时程智能体很少能通过一次性提示成功。从一开始就规划连续性:

  • 当你需要稳定的依赖、缓存文件和中间输出时,在各个步骤间复用同一个容器。
  • 传递 previous_response_id,以便模型能在同一线程中继续工作。
  • 将压缩(compaction)作为长时运行的默认基础能力,而非紧急情况下的补救措施。

这种组合减少了重启行为,并确保随着线程增长,多步骤任务保持连贯。

5)当你需要确定性时,明确告诉模型使用该技能

默认行为是模型自行决定何时使用技能。这通常正是你想要的。

但当你在运行一个具有明确契约的生产工作流时(并且你宁愿确定也不愿取巧),只需说:

“使用 <skill name> 技能。”

这是你能使用的最简单的可靠性杠杆。它将模糊的路由转变为明确的契约。

6)将技能与网络访问视为高风险组合(为遏制风险而设计)

这是一条现在容易被忽略、日后难以修复的安全提示。

将技能与开放网络访问结合,会为数据外泄创造高风险路径。如果你使用网络功能,请保持网络允许列表严格,假设工具输出是不可信的,并避免在面向用户的流程中使用开放互联网加强大功能的流程,因为用户期望有严格的确认控制。

一个稳健的默认姿态:

  • 技能:允许
  • Shell:允许
  • 网络:仅在具有最小允许列表的情况下启用,按请求进行,用于范围狭窄的任务

7)将 /mnt/data 作为你交付产物的交接边界

对于托管的 shell 工作流,将 /mnt/data 视为写入输出的标准位置,你将从那里检索、审查或将输出传回后续步骤。示例包括报告、清洗后的数据集和完成的电子表格。

一个好的心智模型是:工具写入磁盘,模型基于磁盘进行推理,开发者从磁盘检索。

8)将允许列表理解为两层系统(组织级和请求级)

网络访问在两个地方受控:

  • 组织级允许列表(由管理员配置),设定允许的最大目标范围。
  • 请求级的 network_policy,必须是组织允许列表的子集。

两个对运营有重要影响的含义:

  1. 保持组织允许列表小而稳定(即“你信任的已批准目标”集合)。
  2. 保持请求允许列表更小(即“本次任务所需的目标”集合)。

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

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

如果允许的域名需要身份验证标头,请使用 domain_secrets,这样模型就永远不会看到原始凭据。

在运行时,模型看到的是占位符(例如 $API_KEY),而边车(sidecar)仅为已批准的目标注入真实值。只要你的智能体需要在容器内调用受保护的 API,这就是一个强大的默认设置。

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

你可以同时使用这两种原语,而不必承诺将所有内容托管:

  • 技能(Skills)同时支持托管 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% 提高,并将首字词元时间缩短了 18.1%。
  • 实际策略包括精细路由、负面示例,以及在技能内部嵌入模板/示例。
  • Glean 还使用技能在企业工作流中编码重复性任务,包括客户规划、升级分类和符合品牌调性的内容生成。

这就是事情变得强大的形态。技能成为活的 SOP(标准操作程序):随着组织的发展而更新,并由智能体一致地执行。

一次构建,随处运行

当长期运行的智能体既能遵循流程又能在计算机上完成实际工作时,其效用会大幅提升。Skills、托管 shell 和 compaction 共同奠定了这一基础。回顾一下:

  • 使用 skills 来编码“如何做”(流程、模板、护栏)。
  • 使用 shell 来执行“做什么”(安装、运行、生成产物)。
  • 使用 compaction 来保持长时间运行的连贯性(无需手动管理上下文)。
  • 快速迭代时,从本地开始。
  • 当需要可重复、隔离的执行环境时,迁移到托管容器。
  • 通过组织级和请求级允许列表严格限制网络访问,并使用领域密钥进行需要认证的调用。

在你自己的应用中开始使用。查看 skills 文档、shell 文档 和 compaction 文档 以了解如何操作。

阅读显示设置

调整正文排版

当前浏览器记住选择,应用于文章正文。手机上正文宽度以屏幕可用空间为限。

图表完整性提示

普通文章遇到图表保存问题时显示提示。