Shell + Skills + 压缩（Compaction）：让长时间运行的智能体真正干活的技巧

来源：https://developers.openai.com/blog/skills-shell-tips 作者：Charlie Guo

用 Skills、托管 Shell 与 Responses API 的服务端压缩来构建的实用模式。

作者：Charlie Guo

我们正在从单轮对话助手转向能长时间运行的智能体，让它们承担真正的知识工作：读取大型数据集、更新文件、编写应用。

基于开发者反馈，以及我们构建 Codex 和内部智能体的经验，我们正在发布一组新的智能体原语，让“长视野工作”变得更可行：

• Skills（与 Agent Skills 开放标准对齐）：可复用、可版本化的指令包，你可以把它们挂载进容器，使智能体更可靠地执行任务。

• 升级后的 shell 工具：由 OpenAI 托管、具备受控互联网访问的容器环境，智能体可在其中安装依赖、运行脚本、写出产物（例如报告与工件）。

• 服务端压缩（Server-side compaction）：一种轻松方式，可自动压缩冗长的智能体运行过程，让你永远不会撞上上下文限制。

文档与 API 参考分别覆盖了上面的每一项内容。本文聚焦于一些不那么显而易见、但迄今最有效的技巧与模式——这些经验既来自我们在 OpenAI 的实践，也来自早期 skills 客户 Glean 在生产环境中的落地。

一个简要的心智模型

Skills：“按需加载的流程（Procedures）”

Skill 是一组文件的打包，其中包含一个带 frontmatter 与说明的 SKILL.md 清单。可以把它理解为一个有版本的作业手册：当需要做真正的工作时，模型可以查阅它。

当 skills 可用时，平台会向模型暴露每个 skill 的名称、描述与路径。模型据此决定是否调用某个 skill；一旦调用，就会读取 SKILL.md 以获得完整工作流。

Shell 工具：智能体的“执行（Execution）”

Shell 工具让模型在真实的终端环境中工作，形式有两种：

• 由 OpenAI 管理的托管容器。

• 你自行执行的本地 shell 运行时（工具语义相同，但机器由你控制）。

托管 shell 通过 Responses API 运行，这意味着你的请求包含有状态的工作、工具调用、多轮续写与产物（artifacts）。

压缩（Compaction）：让长流程持续推进

随着工作流变长，它们会撞上上下文窗口限制。服务端压缩通过管理上下文窗口、自动压缩对话历史，来保持长流程持续推进。

Responses API 中的压缩为你提供两种处理方式：

• 服务端压缩（新）：当上下文超过阈值时，压缩会在流式过程中自动运行，无需单独发起压缩调用。

• 独立的 compact 端点：当你希望明确控制压缩发生的时机时，使用 /responses/compact。

为什么把它们放在一起更好

• Skills 通过把稳定的流程与示例移入可复用的包，减少“提示词意大利面”。

• Shell 提供完整执行环境，让你能安装代码、运行脚本、写出产物。

• 压缩在长流程中保持连贯性，让同一个工作流无需手动“上下文外科手术”也能继续执行。

• 组合起来，你获得可重复的工作流与真实执行能力，而不必把 system prompt 变成一份脆弱的巨型文档。

小技巧与窍门

1) 把 skill 描述写成路由逻辑（不是营销文案）

你的 skill 描述本质上就是模型的决策边界。它应该回答：

• 我什么时候应该用它？

• 我什么时候不应该用它？

• 输出与成功标准是什么？

一个实用模式是在描述中直接加入一小段“Use when vs. don’t use when”，并保持具体（输入、涉及的工具、期望产物）。

2) 加入反例与边界情况，减少误触发

一个出人意料的失败模式是：skills 一旦可用，初期反而可能降低正确触发率。我们见过有效的修复方式是加入反例与边界情况覆盖。

在实践里，这意味着写出几条明确的“不要在……情况下调用这个 skill……”（以及改做什么）。这能让模型更干净地路由，尤其当你有多个 skill 乍看相似时。

Glean 直接看到了这种现象：在针对性评测中，基于 skill 的路由最初让触发率下降了约 20%，随后他们在描述里补上反例与边界情况覆盖后，又恢复了触发率。

3) 把模板与示例放进 skill 里（不用时基本“免费”）

如果你一直把模板硬塞进 system prompt，那就停下来。

把模板与完整示例（worked examples）放在 skill 里有两个优势：

• 仅在需要时可用（即 skill 被调用时）。

• 不会为无关查询增加 token 负担。

这对知识工作输出尤其有效，例如：

• 结构化报告。

• 升级处理的分诊摘要（escalation triage summaries）。

• 客户/账户计划（account plans）。

• 数据分析撰写。

Glean 报告称，这种模式带来了他们在生产环境中一些最大的质量与延迟收益，因为这些示例只在 skill 触发时才会被加载。

4) 及早为长流程设计：容器复用 + 压缩

长视野智能体很少能靠“一次性提示词”成功。应从一开始就为连续性做规划：

• 当你希望依赖稳定、文件缓存与中间产物可复用时，在步骤间复用同一个容器。

• 传入 previous_response_id，让模型能在同一线程中继续工作。

• 把压缩当作默认的长流程原语，而不是紧急兜底手段。

这种组合会减少重启行为，并在对话线程增长时保持多步骤任务的连贯性。

5) 需要确定性时，明确告诉模型使用该 skill

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

但当你运行的是一个有清晰契约的生产工作流（你宁愿确定而不是“聪明”），直接说：

“Use the skill name skill.”

这是你能用上的最简单可靠性杠杆：把模糊路由变成显式契约。

6) 把 skills + 网络当作高风险组合（按“可控范围”来设计）

这是那种现在很容易略过、但以后很难补救的安全提示。

把 skills 与开放网络访问结合，会形成高风险的数据外泄路径。如果你要用网络，请保持网络 allowlist 严格、默认将工具输出视为不可信，并避免在面向消费者的流程里把开放互联网与强力流程组合在一起——尤其当用户期望强确认控制时。

一个强默认姿态是：

• Skills：允许

• Shell：允许

• 网络：仅在每次请求时、为范围非常窄的任务启用，并使用最小 allowlist

7) 把 /mnt/data 当作产物交接边界

对于托管 shell 工作流，把 /mnt/data 视为写出你要检索、审阅或传递到后续步骤的输出的标准位置。比如报告、清洗后的数据集、完成的表格等。

一个很好的心智模型是：工具写入磁盘，模型在磁盘上推理，开发者从磁盘取回。

8) 把 allowlist 理解为双层系统（组织级 + 请求级）

网络访问在两处受控：

• 组织级 allowlist（由管理员配置），定义最大允许的目标集合。

• 请求级 network_policy，必须是组织 allowlist 的子集。

两点对实际运维很关键：

• 让组织 allowlist 小而稳定（“你信任的已批准目的地”集合）。

• 让请求 allowlist 更小（“这个单次任务确实需要的目的地”集合）。

如果请求包含组织 allowlist 之外的域名，将会报错。

9) 用 domain_secrets 做鉴权调用（避免凭据泄漏）

如果某个允许的域名需要鉴权头，使用 domain_secrets，这样模型永远看不到原始凭据。

运行时模型看到的是占位符（例如 $API_KEY），而侧车（sidecar）只会对已批准目的地注入真实值。只要你的智能体需要在容器内调用受保护的 API，这都是一个很强的默认选择。

10) 云端与本地使用同一套 API

你可以同时使用这两类原语，而无需承诺把一切都托管起来：

• Skills 同时适用于托管 shell 与本地 shell 模式。

• Shell 具备本地执行模式：你自行执行 shell_call，并把 shell_call_output 回传给模型。

• 如果你在用 Agents SDK，也可以接入你自己的 shell 执行器。

一个实用的开发循环是：

• 先从本地开始（迭代快、能访问内部工具、易于调试）。

• 当你需要可重复性、隔离性与部署一致性时，再迁移到托管容器。

• 两种模式下保持 skills 不变（即使执行环境迁移，工作流仍保持稳定）。

三种构建模式

你当然可以自由试验这些新的智能体原语。下面给出三个例子，展示如何把它们组合起来构建实用应用。

模式 A：安装 - 拉取 - 写出产物

这是受益于托管 shell 的最简单方式：智能体安装依赖、拉取外部数据，并产出一个具体可交付物。

例如：

• 安装几个库。

• 抓取网页或调用 API。

• 把报告写到 /mnt/data/report.md。

这种模式是“真实工作”智能体的基础，因为它建立了清晰的审阅边界：你的应用可以把产物展示给用户、记录日志、做 diff，或把它喂给后续步骤。

模式 B：Skills + Shell，用于可重复的工作流

当你做出一两个成功的 shell 工作流后，你会遇到下一个问题：确实能跑，但当提示词漂移时可靠性会下降。

这就是 skills 的用武之地。下面是一个更耐用的结构：

• 用 skill 编码工作流（步骤、护栏、模板）。

• 把 skill 挂载进你的 shell 环境。

• 让智能体遵循 skill，以确定性的方式产生产物。

这对以下工作流尤其有效：

• 电子表格分析或编辑。

• 数据集清洗 + 摘要生成。

• 面向重复业务流程的标准化报告生成。

模式 C（高级）：把 skills 作为企业工作流的载体

我们观察到的一个早期模式是：在“单工具调用”和“多工具编排”之间的缝隙里，准确性会下降。Skills 可以通过更“程序化”的工具推理来弥合这一差距，同时不把 system prompt 膨胀成巨无霸。

一个来自 Glean 的具体例子：

• 一个面向 Salesforce 的 skill 把评测准确率从 73% 提升到 85%，并将首 token 时间（time-to-first-token）降低了 18.1%。

• 实用战术包括精心路由、反例，以及把模板/示例嵌入到 skill 内。

• Glean 也使用 skills 来编码企业工作流中的重复任务，包括账户规划、升级分诊，以及与品牌一致的内容生成。

这就是事情开始变强的形状：Skills 成为“活的”SOP（标准作业流程）——随着组织演进而更新，并由智能体一致执行。

一次构建，随处运行

当长时间运行的智能体既能遵循流程、又能在电脑上真正干活时，它们会变得格外有用。Skills、托管 shell 与压缩提供了这一基础。回顾一下：

• 用 skills 来编码“怎么做”（流程、模板、护栏）。

• 用 shell 来执行“做什么”（安装、运行、写出产物）。

• 用压缩让长流程保持连贯（无需手动管理上下文）。

• 快速迭代时先从本地开始。

• 需要可重复、隔离的执行时迁移到托管容器。

• 用组织级与请求级 allowlist 锁紧网络访问，并对鉴权调用使用 domain secrets。

从你的应用里开始上手。参阅 skills 文档、shell 文档 和 compaction 文档 了解如何使用它们。

相关笔记