Agent 步入“系统级”时代：OpenAI 详解 Skills 与 Shell 方案，终结提示词工程

当“提示词乱炖”被标准化的技能包取代，当内存管理像垃圾回收一样成为底层原语，开发者终于可以从繁琐的逻辑粘合中抽身，去构建真正具有长周期执行能力的“数字雇员”。虽然 OpenClaw 的安全性饱受诟病（被称为“带枪的管家”），但其活跃的 Skills 社区证明了：当 AI 能够直接触碰真实物理机器时，它爆发出的生产力是托管平台难以企及的。这一模式是真实工作智能体的基础，因为它创建了一个清晰的审查边界

高可用架构

410人浏览 · 2026-02-13 11:51:21

高可用架构 · 2026-02-13 11:51:21 发布

导读：如果说 2024 年是“提示词工程”的狂欢，那么 2026 年则是“智能体工程”的元年。OpenAI 最新发布的这组原语——Skills、Shell 与 Compaction——释放了一个极其明确的信号：AI 正在从一个“陪你聊天的黑盒”，进化为一套“为你干活的基础设施”。这不仅仅是工具箱的扩充，更是从 Agent-as-a-Chatbot 向 Agent-as-Infrastructure 的关键一跳。当“提示词乱炖”被标准化的技能包取代，当内存管理像垃圾回收一样成为底层原语，开发者终于可以从繁琐的逻辑粘合中抽身，去构建真正具有长周期执行能力的“数字雇员”。

TL;DR: 下文是 OpenAI 方案详情，赶时间读者可以跳到文章末尾解读部分以及与 OpenClaw 对比。

我们正在从单轮对话助手（single-turn assistants）转向能够处理真实知识工作的长期运行智能体（long-running agents）：它们可以阅读大型数据集、更新文件并编写应用程序。

基于开发者的反馈以及我们在构建 Codex 和内部智能体时的经验，我们发布了一套全新的智能体原语，让长周期（long-horizon）工作变得更加实用：

Skills（技能）：符合 Agent Skills 开放标准；它是可重用、版本化的指令，可以挂载到容器中，使智能体能够更可靠地执行任务。
升级版 Shell 工具：一个由 OpenAI 托管、具有受控网络访问权限的容器。智能体可以在其中安装依赖、运行脚本并输出结果（例如报告和artifact制品）。
服务端压缩（Server-side compaction）：一种自动压缩长周期智能体运行记录的简便方法，确保你永远不会触及上下文限制。

文档和 API 参考已经详细介绍了上述每个项目。本文将重点讨论我们在 OpenAI 内部以及早期 Skills 客户 Glean 的生产实践中发现的、最有效的非直观技巧与模式。

核心思维模型

Skills：“按需加载”的程序

技能是文件包加上一个包含前置信息和指令的 SKILL.md 清单文件。你可以把它想象成一个版本化的操作手册，模型在需要执行实际工作时可以参考。当技能可用时，平台会向模型展示每个技能的名称、描述和路径。模型利用这些元数据决定是否调用该技能。如果调用，它会读取 SKILL.md 以获取完整的操作流程。

Shell 工具：智能体的“执行引擎”

Shell 工具允许模型在真实的终端环境中工作，支持：

由 OpenAI 管理的托管容器。
你自己执行的本地 Shell 运行时（工具语义相同，但机器受你控制）。托管的 Shell 通过 Responses API 运行，这意味着你的请求自带状态、工具调用、多轮持续对话和生成的artifact制品。

压缩：保持长周期运行

随着工作流变长，往往会遇到上下文窗口限制。服务端压缩通过自动管理上下文窗口和压缩对话历史，确保长周期运行不中断。 Responses API 提供了两种处理方式：

服务端压缩（新）：当上下文超过阈值时，压缩在流式输出中自动运行，无需单独调用。
独立压缩端点：当你想要显式控制压缩时机时，使用 /responses/compact。

为什么它们结合在一起更强大？

Skills 通过将稳定的程序和示例移入可重用的包中，减少了提示词的杂乱堆砌（Prompt spaghetti）。
Shell 提供了一个完整的执行环境，允许安装代码、运行脚本和输出结果。
压缩保持了长周期运行的连续性，同一个工作流可以持续执行，无需人工手动裁剪上下文。

技巧与诀窍

1) 像写“路由逻辑”一样写技能描述（而非营销文案）

技能描述实际上是模型的决策边界。它应该回答：

我什么时候应该使用它？
我什么时候不应该使用它？
输出结果和成功标准是什么？一个实用的模式是在描述中直接加入简短的“使用场景 vs. 禁用场景”区块，并保持具体（涉及的输入、工具和预期的artifact制品）。

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

一个令人惊讶的失败模式是：提供技能初期反而可能降低正确触发率。我们发现一个有效的解决方法是负面示例加上边缘情况覆盖。在实践中，这意味着显式写出几个“当……时不要调用此技能”的案例（以及此时该做什么）。这能帮助模型更清晰地进行路由，尤其是当你拥有多个乍看之下很相似的技能时。

Glean 的经验：在定向评测中，基于技能的路由最初导致触发率下降了约 20%，但在描述中加入负面示例和边缘情况后，触发率得到了恢复。

3) 将模板和示例放入技能内部（不使用时几乎不占成本）

如果你一直在把模板塞进系统提示词（System Prompt）里，请停止这样做。在技能内部放置模板和实操案例有两个优势：

它们仅在需要时（技能被调用时）才可用。
它们不会在处理无关查询时增加 Token 消耗。这对知识工作的输出尤其有效，例如：结构化报告、升级分流摘要、客户计划、数据分析报告等。

Glean 的反馈：这一模式在生产环境中带来了他们最大的质量和延迟改善，因为这些示例仅在技能触发时才被加载。

4) 及早针对长周期运行进行设计（容器复用与压缩）

长周期智能体很少能通过“一劳永逸”的提示词获得成功。从一开始就要考虑连续性：

当需要稳定的依赖、缓存文件和中间产出时，在不同步骤间复用同一个容器。
传递 previous_response_id，以便模型能在同一个线程中继续工作。
将压缩作为长周期运行的默认配置，而非应急方案。

这一组合减少了重启行为，并在线程不断增长时保持多步骤任务的连贯性。

5) 需要确定性时，明确命令模型使用该技能

默认情况下由模型决定何时使用技能，这通常很灵活。但如果你正在运行一个具有明确契约的生产工作流（且你更追求确定性而非“小聪明”），只需直接命令：

“使用 <skill name> 技能。” 这是你能动用的最简单的可靠性杠杆。它能将模糊的路由逻辑转变为明确的执行契约。

6) 将“技能 + 网络访问”视为高风险组合

这是安全方面极易被忽视、且以后难以修复的问题。将技能与开放的网络访问相结合，会为数据外泄创造高风险路径。如果你使用网络功能，请保持严格的网络白名单，假设工具输出是不可信的。在用户期望强确认控制的场景中，避免将开放互联网与强大的程序结合。

推荐的默认安全姿态：

Skills：允许
Shell：允许
网络：仅在每个请求中通过最小化白名单启用，且仅用于范围明确的任务

7) 将 `/mnt/data` 作为artifact制品的交接边界

对于托管的 Shell 工作流，将 /mnt/data 视为写入输出的标准位置，以便后续检索、审阅或传回后续步骤。例如：报告、清洗后的数据集和完成的电子表格。核心模型：工具写入磁盘，模型基于磁盘推理，开发者从磁盘检索。

8) 理解“双层白名单”网络系统

网络控制分两个层面：

组织级白名单（由管理员配置）：设定允许访问的最大范围。
请求级网络策略：必须是组织白名单的子集。这意味着：保持组织白名单小而稳定，而请求级白名单应更小（仅限该任务所需的域名）。如果请求中包含组织白名单之外的域名，将会报错。

9) 使用 `domain_secrets` 进行身份验证（避免凭据泄露）

如果允许的域名需要认证请求头，请使用 domain_secrets。在运行时，模型只会看到占位符（例如 $API_KEY），只有在发送到获批的目的地时，侧车（Sidecar）才会注入真实值。每当你的智能体需要从容器内调用受保护的 API 时，这都是一个推荐的默认做法。

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

你可以同时使用这两个原语，而无需将所有内容都托管：

Skills 同时适用于托管 Shell 和本地 Shell 模式。
Shell 提供本地执行模式，你自己执行 shell_call 并将 shell_call_output 返回给模型。
如果你使用 Agents SDK，还可以插入自定义的 Shell 执行器。

实用的开发循环：

从本地开始（快速迭代、访问内部工具、便于调试）。
当需要可重复性、隔离性和部署一致性时，迁移到托管容器。
在两种模式下保持技能不变（即使执行环境变了，工作流保持稳定）。

三种构建模式

模式 A：安装 -> 获取 -> 写入artifact制品

这是利用托管 Shell 最简单的方式：智能体安装依赖、获取外部数据并生成具体的交付物。

例如：安装几个库 -> 爬取或调用 API -> 将报告写入 /mnt/data/report.md。

这一模式是真实工作智能体的基础，因为它创建了一个清晰的审查边界：你的应用可以向用户展示该artifact制品，记录日志，进行差异对比，或将其传入后续步骤。

模式 B：技能 + Shell 处理可重复工作流

当你构建了一两个成功的 Shell 工作流后，你会发现：当提示词发生漂移时，可靠性会下降。这就是 Skills 的用武之地。遵循以下结构：

将工作流（步骤、护栏、模板）编码进技能。
将技能挂载到 Shell 环境中。
让智能体遵循技能确定性地生成artifact制品。

这对以下工作流特别有效：

电子表格分析或编辑
数据集清洗加摘要生成
面向周期性业务流程的标准化报告生成

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

Skills 可以通过使工具推理更具程序化，且不膨胀系统提示词，来弥补单工具调用与多工具编排之间的准确性鸿沟。Glean 的案例：一个针对 Salesforce 的技能将评测准确率从 73% 提高到 85%，并将首 token 延迟（TTFT）降低了 18.1%。实用的策略包括：精细的路由、负面示例，以及在技能内部嵌入模板和示例。

Glean 还使用技能来编码企业工作流中的周期性任务，包括客户计划、升级分流和品牌一致的内容生成。

这就是事情变得强大的方向。技能成为活的 SOP（标准操作程序）：随着组织的演进而更新，并由智能体一致地执行。

一次构建，到处运行

当长周期智能体既能遵循程序又能像在电脑上一样执行实际工作时，它们的用处会大幅提升。

使用 Skills 编码“如何做”（程序、模板、护栏）。
使用 Shell 执行“做某事”（安装、运行、写入artifact制品）。
使用压缩保持长周期运行的连贯性。

建议： 快速迭代时从本地开始；需要可重复、隔离的执行环境时转移到托管容器。

通过组织级和请求级白名单锁定网络访问，并使用 domain_secrets 进行认证调用。

参考链接：https://developers.openai.com/blog/skills-shell-tips

解读

高可用架构：OpenAI 最近发布的这篇关于 Skills（技能） 与 Shell（终端） 技术的深度博文，标志着 AI Agent 从“对话助手”正式转向“操作助手”的一个关键转折点。

与此同时，开源社区爆火的 OpenClaw（原名 Clawdbot/Moltbot）正代表着另一股力量。以下是对 OpenAI 最新 Agent 技术基元（Primitives）的分析，以及它与 OpenClaw 的全方位深度对比。

一、 OpenAI 的核心技术布局：Agent 的“工程化”与“标准化”

OpenAI 的这篇文章（以及相关的 API 更新）核心围绕着解决长程任务（Long-horizon tasks）中的三个痛点：执行环境、复用性、上下文爆炸。

Skills (基于 Agent Skills 开放标准)：

本质： OpenAI 引入了一种“说明书式”的技能包。每个 Skill 包含一个 SKILL.md 描述文件和配套代码。
逻辑： 模型不再是盲目地写代码，而是像查阅“标准作业程序 (SOP)”一样，根据需求挂载（Mount）不同的技能。这标志着 Agent 开发从“写死提示词”向“软件工程模块化”演进。

Hosted Shell (托管 Shell)：

云端沙盒： OpenAI 提供了一个受控的容器环境，Agent 可以在其中安装依赖、运行 Python 脚本、读写文件并进行受控的网络访问。
意义： 开发者无需再为 Agent 配置本地服务器，安全性由 OpenAI 的云端隔离（类似隔离容器）保障。

Server-side Compaction (服务端压缩)：

痛点解决： 长程任务（如调试一个复杂仓库）会导致对话上下文迅速堆叠。OpenAI 自动在服务端压缩历史信息，保证 Agent 在长时间运行中不“断片”，同时控制 Token 成本。

二、 OpenAI vs. OpenClaw：两种路径的碰撞

如果说 OpenAI 代表的是 “Agentic Cloud（智能体云）”，追求安全、可控和企业级稳定；那么 OpenClaw 则代表了 “Sovereign Agent（主权智能体）”，追求私有化、全权限和极客自由。

1. 架构与部署逻辑

OpenAI: 采用 托管式（Hosted）。计算、存储和 Shell 执行都在 OpenAI 的服务器上。用户通过 Responses API 调用。优点是零运维、极速起步。
OpenClaw: 采用 自托管（Self-hosted）。它通常运行在用户的本地机器或自己的云服务器（EC2 等）上。它是一个基于 Node.js 的长期运行服务，充当消息网关和 Agent 运行环境。

2. 用户入口与交互

OpenAI: 主要面向开发者，通过 API、CLI 或 IDE 插件集成，偏向生产力工具和 B 端应用。
OpenClaw: 极具社交属性，被称为“长在聊天软件里的 Agent”。它通过 WhatsApp、Telegram、Discord 等入口直接控制。你可以给自己的 Bot 发一条微信：“帮我把最近 10 个 GitHub 标星项目的 README 汇总成 PDF 发给我”，它会直接在你的电脑上执行。

3. 安全性与访问权限

OpenAI (安全沙盒): 执行环境是隔离的。Agent 无法直接碰触你的真实电脑文件，除非你手动上传。虽然安全，但处理“本地自动化任务”略显繁琐。
OpenClaw (高 agency，高风险): 它是典型的“乱世枭雄”。它拥有本地 Shell 的真实权限。虽然可以配置 Docker 沙盒，但其核心吸引力在于它能操作你的真实文件、真实浏览器和真实密钥。这也导致了近期关于 OpenClaw “中毒技能包（Malware Skills）”的安全恐慌。

4. 技术标准（意外的共识）

有趣的是，OpenAI 提到的 Agent Skills 开放标准 与 OpenClaw 是兼容的。OpenClaw 的开发者（如 Peter Steinberger）极力推动 Skill 标准化，这意味着你在 OpenAI 平台上开发的一个“SEO 分析技能包”，理论上可以无缝迁移到 OpenClaw 上使用。

三、深度对比总结表

维度	OpenAI (Shell + Skills)	OpenClaw (原 Clawdbot)
定位	企业级/开发者 Agent 平台	极客/个人 AI 全能管家
基础设施	托管容器 (Hosted Shell)	本地 runtime / 个人服务器
上下文管理	服务端自动压缩 (Compaction)	本地持久化存储 / 向量记忆
安全性	极高 (多重沙盒隔离)	风险较高 (拥有 Host Shell 权限)
交互界面	API / CLI / Responses 界面	WhatsApp / Telegram / Signal
适用场景	大规模数据分析、自动化编程、SaaS 集成	本地文件管理、个人生活自动化、跨平台消息路由
核心优势	稳定、安全、上下文无限扩展	私有隐私、直接操控硬件/本地环境、完全掌控

四、编辑视点：我们该如何选择？

作为技术观察者，我认为 OpenAI 正在将 Agent “平民化”和“安全化”。通过 Skills 和 Hosted Shell，它极大地降低了开发者构建可靠 Agent 的门槛——你不再需要担心服务器安全和复杂的上下文管理。

而 OpenClaw 则是对 Agent 极致形态的探索。它代表了用户对数据主权和操作深度的渴望。虽然 OpenClaw 的安全性饱受诟病（被称为“带枪的管家”），但其活跃的 Skills 社区证明了：当 AI 能够直接触碰真实物理机器时，它爆发出的生产力是托管平台难以企及的。

建议：

如果你是 企业开发者 或构建 面向客户的应用，紧跟 OpenAI 的 Skills & Shell 体系。它的 SKILL.md 标准将是未来的“Agent 协议”。
如果你是 极客或个人开发者，想打造一个能 24 小时处理自己杂事的“超级分身”，OpenClaw 是目前最先进、生态最丰富的实验室，但请务必在沙盒环境下运行。

Agent 的竞争已经不再是模型的竞争，而是 “技能库”和“执行环境” 的竞争。OpenAI 的这篇博文，实际上是给所有 Agent 开发者发出的“标准化邀请函”。