OpenAI 公布了搭建\"能干活的 AI Agent\"的三个核心组件和10条建议

先理解一个背景：从"对话"到"干活"

过去两年，大多数人使用 AI 的方式是对话：问一个问题，得到一个回答。即使是 ChatGPT 最复杂的用法，本质上也是"一问一答"或者"多轮对话"。

但现在行业正在发生一个根本性的转变：从单轮对话（chat）转向长时间运行的 Agent（long-running agents）。

什么叫"长时间运行"？意思是你给 AI 一个任务，它可能需要：

• 读取一大堆文件
• 安装一些软件工具
• 写代码跑脚本
• 调用外部 API 获取数据
• 生成报告或其他成果物
• 整个过程可能持续几分钟甚至几小时

这不再是"聊天"了，这是"工作"。

但要让 AI 真正能这样工作，有三个核心问题需要解决。OpenAI 这篇文章给出的三个组件，恰好对应这三个问题。

三个组件，解决三个问题

问题一：AI 怎么知道该"怎么干"？

答案：Skills（技能）

你可以把 Skill 理解为一份"标准操作手册"。它是一个包含指令文件（SKILL.md）和相关资源的打包文件，告诉 AI "遇到这类任务应该按什么步骤做、用什么工具、输出什么格式"。

举个例子：你可以写一个"季度数据分析报告"的 Skill，里面包含：

• 分析步骤：先清洗数据，然后做统计，最后生成图表
• 输出模板：报告的标准格式、必须包含的章节
• 注意事项：哪些指标需要同比对比，哪些异常值需要标注

当 AI Agent 遇到"帮我分析这个季度的数据"这样的任务时，它会自动加载这个 Skill，然后按照手册执行。

关键点：Skill 不会始终占用上下文窗口。 只有当 Agent 判断需要使用某个 Skill 时，才会加载它的内容。不需要的时候，它不消耗任何 token。这比把所有指令塞进 system prompt 高效得多。

问题二：AI 怎么"动手做"？

答案：Shell（执行环境）

光有操作手册不够，还得有一个"工作台"。Shell 就是 OpenAI 给 Agent 提供的工作台，一个真正的终端环境。

在这个环境里，Agent 可以：

• 安装依赖（比如 pip install pandas）
• 运行脚本（Python、Node、Bash 都行）
• 读写文件
• 调用外部 API（有网络白名单控制）
• 生成最终成果物（报告、数据集、表格等）

OpenAI 提供了两种模式：

• 托管模式：OpenAI 帮你管容器，你通过 API 调用，Agent 在云端执行
• 本地模式：你自己管机器，Agent 在你本地环境执行

同一套 Skill 在两种模式下都能跑，工作流不用改。

问题三：长任务怎么不"断片"？

答案：Compaction（上下文压缩）

这是一个非常实际的问题。当 Agent 执行一个长任务时，对话历史会越来越长，很快就会撞到上下文窗口的天花板。

之前开发者遇到这个问题，通常要自己写逻辑来手动管理上下文，非常麻烦。

现在 OpenAI 提供了服务端 Compaction：当上下文接近上限时，系统自动压缩对话历史，保留关键信息，丢弃冗余内容，Agent 可以继续工作而不中断。

这就像一个人在做一个大项目时，会自然地把之前的笔记整理成摘要，而不是一直翻看每一页原始记录。

如果你用过 Claude Code，应该对这个问题很熟悉。Claude Code 也有 /compact 命令来做类似的事情，上下文满了就压缩一下继续干。OpenAI 的方案是把这个过程自动化了，不需要手动触发。

三个组件怎么配合工作

OpenAI 在文章里给了三个由简到复杂的实战模式：

模式 A：安装→获取→生成（最基础）

最简单的用法：Agent 在容器里安装几个库，调用 API 或抓取数据，然后生成一份报告写入 /mnt/data/report.md。

应用场景：一次性的数据分析、竞品调研、报告生成。

模式 B：Skill + Shell = 可重复的工作流

当你发现某个工作流反复出现，而且每次用 prompt 描述不够稳定时，就该把它封装成 Skill。

具体做法：

1. 把工作流程（步骤、规则、模板）写进一个 Skill
2. 把 Skill 挂载到 Shell 环境
3. Agent 按 Skill 执行，输出标准化的成果物

应用场景：定期的表格分析、数据清洗+摘要生成、标准化报告。

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

这是最有意思的部分。OpenAI 提到了他们的早期客户 Glean 的案例：

• 一个面向 Salesforce 的 Skill，把评估准确率从 73% 提升到了 85%
• 首次响应时间（time-to-first-token）减少了 18.1%
• 具体做法包括：精确的路由描述、反面案例、在 Skill 内嵌入模板和示例

Glean 把 Skills 当作企业内部的"活的 SOP"来用：随着业务变化持续更新，由 Agent 一致性地执行。涵盖客户规划、升级处理、品牌对齐的内容生成等场10 条实战经验（文章的精华部分）

OpenAI 在文章里给了 10 条具体的建议，每一条都来自实际踩坑经验。完整梳理如下：

第 1 条：Skill 的描述要像路由逻辑，不要像营销文案

Skill 的 description 字段是模型决定"要不要用这个 Skill"的依据。不要写"这个 Skill 帮助你高效完成数据分析"这种空话。要写清楚：什么情况下用、什么情况下不用、输入是什么、输出是什么。

实用做法是在描述里直接写一个"Use when vs. Don't use when"的对照块，列出具体的触发条件和排除条件。

第 2 条：加反面案例，否则准确率可能反而下降

这是一个反直觉的发现：给 Agent 配备了 Skill 之后，正确触发率可能比没有 Skill 时还低。 原因是当有多个 Skill 时，Agent 可能分不清该用哪个。

解决办法是在 Skill 描述里明确写"不要在这种情况下调用这个 Skill，那种情况应该用另一个 Skill"。Glean 的经验是，触发率先下降了约 20%，加了反面案例后恢复并超过了之前的水平。

第 3 条：模板和示例放在 Skill 里，不要塞进 system prompt

过去很多开发者把输出模板、参考示例都塞进 system prompt，结果 prompt 越来越臃肿，不管用户问什么问题，这些 token 都会被消耗。

正确做法：放进 Skill 里。只有当 Skill 被触发时才会加载这些内容。Glean 说这个改动带来了他们在生产环境中最大的质量和延迟改善。

特别适合的场景包括：结构化报告、升级处理摘要、客户规划方案、数据分析报告等知识型输出。

第 4 条：从一开始就为"长任务"设计，用好容器复用和 Compaction

长时间运行的 Agent 很难靠一次性 prompt 搞定。从项目初期就要规划好连续性：

• 跨步骤复用同一个容器，保持依赖环境、缓存文件和中间产物的稳定
• 传递 previous_response_id，让模型在同一个线程里继续工作
• 把 Compaction 作为长任务的默认配置，而不是"上下文快满了"才去救火

这三点组合起来，能大幅减少 Agent 在多步任务中"重头开始"的行为。

第 5 条：需要确定性的时候，直接告诉 Agent 用哪个 Skill

默认情况下，Agent 自己决定要不要用 Skill。这在很多场景下没问题。

但如果你的工作流是确定的，比如"每次收到客户投诉都要按标准流程处理"，那就直接在 prompt 里写"使用 XXX Skill"。

这是你能拉的最简单的可靠性杠杆。把模糊的路由判断变成明确的执行指令。

第 6 条：Skill + 网络 = 高风险组合，必须做好隔离

这是安全提示，也是最容易被忽略、事后最难修复的一条。

Skill 有执行代码的能力，如果同时开放了网络访问，就等于给数据泄露打开了一条通道。 想象一下：一个有权限读取内部数据库的 Skill，加上不受限的网络访问，理论上可以把数据发送到任意外部地址。

OpenAI 建议的默认安全姿态：

• Skills：允许
• Shell：允许
• 网络：只允许最小范围的白名单，按请求粒度控制，不要给面向消费者的流程开放宽泛的网络权限

第 7 条：用 /mnt/data 作为成果物的标准交接点

在托管 Shell 环境中，把 /mnt/data 当作 Agent 输出成果物的标准目录。报告、清洗后的数据集、生成的表格，都写到这里。

OpenAI 给了一个很好的心智模型：工具写入磁盘，模型基于磁盘推理，开发者从磁盘提取结果。 三方通过文件系统交接，清晰、可审计、可复用。

第 8 条：网络白名单是两层系统，搞清楚层级关系

网络访问权限在两个层面控制：

• 组织级白名单：管理员配置，定义"这个组织信任哪些外部域名"，这是上限
• 请求级白名单（network_policy）：每次 API 请求时指定，必须是组织级白名单的子集

实际操作建议：组织级白名单保持小而稳定（"我们信任的所有目标地址"），请求级白名单更小（"这一次任务需要访问的具体地址"）。如果请求中包含了组织级白名单之外的域名，会直接报错。

第 9 条：用 domain_secrets 处理认证，别让模型看到真实密钥

如果 Agent 需要调用一个需要认证的外部 API，用 domain_secrets 机制来传递凭证。

运行时，模型看到的只是占位符（比如 $API_KEY），真实的密钥由旁路注入，只对白名单内的目标域名生效。模型全程接触不到真实凭证。

任何时候你的 Agent 需要在容器内调用受保护的 API，这都应该是默认做法。

第 10 条：云端和本地用同一套 API，先本地开发再上云

你不需要一上来就用托管容器。Skills 和 Shell 都支持两种运行模式：

• Skills 在托管 Shell 和本地 Shell 中都能用
• Shell 有本地执行模式：你自己执行 shell_call，然后把 shell_call_output 返回给模型
• 如果用 Agents SDK，还可以插入自定义的 Shell 执行器

推荐的开发流程：

1. 先在本地跑：迭代快，能访问内部工具，调试方便
2. 稳定后迁移到托管容器：获得可复现性、隔离性和部署一致性
3. Skill 保持不变：工作流在两种模式下通用，只是执行环境换了默认情况下，Agent 自己决定要不要用 Skill。但如果你的工作流是确定的，直接在 prompt 里说"使用 XXX Skill"就行。这是你能拉的最简单的可靠性杠杆。

"Skill + 网络 = 高风险组合，必须做好隔离"

这是安全提示。如果你的 Skill 有能力执行代码，又有网络访问权限，那就存在数据泄露的风险。

OpenAI 建议的默认姿态：

• Skills：允许
• Shell：允许
• 网络：只允许最小范围的白名单，按请求粒度控制

这件事为什么值得关注

表面上看，这就是 OpenAI 发布了几个新的 API 功能。但如果你跳出来看，会发现它反映了一个更大的趋势。

AI Agent 的基础设施正在从"能聊天"进化到"能干活"。

过去的 AI 基础设施围绕一个核心能力建设：文本生成。所有的 API、SDK、工具链都是为了让 AI 更好地"说话"。

现在的建设重心转向了：

• 执行：让 Agent 能在真实环境中运行代码（Shell）
• 记忆：让 Agent 在长任务中不丢失上下文（Compaction）
• 流程：让 Agent 按照标准化流程工作（Skills）

这三个加在一起，就是一个"AI 打工人"的基本能力栈。

再结合最近的其他动态：

• Cloudflare 的 Markdown for Agents：让 Agent 高效读取网页内容
• Google 的 WebMCP：让 Agent 高效操作网站功能
• Anthropic 的 MCP：让 Agent 调用后端服务
• OpenAI 的 Skills + Shell + Compaction：让 Agent 按流程在真实环境中执行任务

你会发现，整个行业正在同时、从不同层面构建一个完整的"Agent 工作基础设施"。

这不再是"AI 会不会取代人"的讨论，而是"AI 在用什么工具干活"的现实。

原文：https://developers.openai.com/blog/skills-shell-tips 发布时间：2026年2月11日 作者：Charlie Guo（OpenAI）