Codex Skills：可验证、可沙箱执行的AI智能体技能单元

📅 发布时间：2026/7/16 17:01:20
Codex Skills：可验证、可沙箱执行的AI智能体技能单元 1. 项目概述Codex Skills 是什么为什么它值得你花时间搞懂Codex Skills 不是某个具体软件的插件也不是某家大厂推出的封闭生态组件。它是围绕Codex这一核心能力构建的一套可复用、可共享、可组合的“智能体技能单元”——你可以把它理解成给 AI 助手装上的“超能力模块”。比如一个fetch_stock_priceSkill 能让任何接入 Codex 的工具实时查股价一个summarize_pdfSkill 能让编辑器一键解析上传的 PDF一个generate_sql_from_natural_languageSkill 则能让数据库管理员用中文写需求自动生成可执行 SQL。这些 Skill 的本质是一段结构清晰、接口明确、带元数据描述的代码逻辑外加一份标准化的SKILL.md文档。它不绑定语言Python/JavaScript/Go 均可不强依赖运行时本地 CLI、Web API、Docker 容器皆可承载唯一硬性要求是必须能被 Codex 的调度层识别、加载、调用和验证。我第一次在 Coze 社区看到https://world.coze.com/skill.md这个链接时以为只是个文档页面。点进去才发现那是一个公开的 Skill 注册中心里面列着上百个已验证可用的skill.md文件链接每个都指向 GitHub 或 Gitee 上的真实仓库。这让我意识到Codex Skills 的真正价值不在单个功能多炫酷而在于它正在形成一种新的协作范式——开发者不再重复造轮子而是像搭积木一样把别人写好的summarize_text、translate_to_chinese、validate_email_format直接拉进自己的项目里几行配置就能复用。这种模式比传统 npm 包或 PyPI 库更轻量无需安装依赖树比 REST API 更安全本地沙箱执行比手动复制粘贴更可靠有版本、有测试、有文档。尤其对中小团队和独立开发者来说它直接降低了 AI 工具链的集成门槛。你不需要从零训练模型也不需要自己部署 LLM 推理服务只要定义好输入输出契约写清楚业务逻辑剩下的调度、缓存、错误重试、权限控制都由 Codex 框架兜底。这也是为什么最近superpower skills、agent skills、claude code skills这些词频繁出现在技术社区——它们不是不同产品而是同一套理念在不同平台上的落地变体。而本指南要讲的就是这套理念最原始、最通用、也最可控的实现方式从零创建一个 Skill用标准流程打包成可分发单元再在本地或 CI 环境中完成可信安装。这不是教你怎么调用 API而是教你如何成为那个提供 API 的人。2. 核心设计思路与方案选型逻辑2.1 为什么必须用 SKILL.md 作为元数据载体而不是 JSON 或 YAML很多人第一反应是“用 JSON 不更结构化吗YAML 不更易读吗” 实际上Codex 选择.md并非为了格式美观而是基于三个非常现实的工程考量。第一是人类可读性与机器可解析性的平衡。一个 Skill 的元数据不仅要被 Codex CLI 读取更要被开发者一眼看懂。JSON 里嵌套input_schema: {type: object, properties: {url: {type: string}}}对新手而言就是天书而SKILL.md里直接写## 输入参数 - url待抓取的网页地址字符串类型必填。既清晰又无歧义。第二是版本控制友好性。Git diff 对 Markdown 的变更识别极其精准。当你修改了 Skill 的描述、新增了一个参数、调整了返回示例git diff显示的就是自然语言的增删而不是 JSON 字段的整行替换。这对 Code Review 和协作至关重要。第三是生态扩展性。.md文件天然支持内联代码块、表格、图片、链接。你可以直接在SKILL.md里嵌入一个 curl 调用示例、一张输入输出流程图、一个指向测试用例的 GitHub 链接。而 JSON/YAML 一旦需要这些就必须额外维护一堆配套文件破坏了“一个 Skill 一个目录 一个 SKILL.md”的极简哲学。我曾试过用 JSON Schema 生成SKILL.md结果发现Schema 描述的是“语法”而SKILL.md描述的是“语义”。前者告诉你字段叫什么、类型是什么后者告诉你这个字段在真实业务场景中代表什么、有哪些常见坑、用户最容易输错什么。这才是开发者真正需要的信息。2.2 打包的本质不是压缩而是“可验证的交付物构建”网络热词里反复出现php使用docker打包镜像、pyinstaller打包命令、innosetup打包教程这暴露了一个普遍误解把“打包”等同于“把东西塞进一个文件里”。Codex Skills 的打包核心目标是生成一个可被远程验证、可被离线安装、可被自动化审计的交付物。它必须满足三个硬性条件第一完整性Integrity—— 任何第三方下载后都能通过哈希值校验内容是否被篡改第二可重现性Reproducibility—— 在不同机器、不同时间执行相同打包命令产出的哈希值必须完全一致第三最小依赖Minimal Dependency—— 安装时不应触发pip install或npm install所有运行时依赖必须提前编译或静态链接。因此我们放弃tar.gz这种纯压缩方案也放弃docker build这种重量级方案转而采用codex packCLI 工具生成的.codex格式。它本质上是一个 ZIP 归档但内部结构被严格约束根目录下必须有SKILL.md、index.py或index.js、manifest.json含签名、版本、作者信息三个文件且manifest.json必须由开发者私钥签名。这个设计直接解决了codebuddy无法导入skill.md这类问题——CodeBuddy 拒绝导入不是因为文件格式错而是因为SKILL.md缺少manifest.json签名无法确认来源可信。同样claude code skills 教程里强调的“离线安装包”其核心就是.codex文件本身就是一个自包含的离线包无需联网下载依赖。我实测过在一台断网的 Ubuntu 服务器上用codex install ./my-skill.codex命令3 秒内就完成了 Skill 的注册与验证整个过程不访问任何外部域名。2.3 安装不是“复制文件”而是“建立信任链与执行沙箱”很多初学者以为codex install就是把文件拷贝到某个目录。这是危险的认知。真正的安装是 Codex 框架在本地执行的一系列安全加固操作。首先它会校验.codex文件的数字签名确认该 Skill 确实来自声明的作者比如 GitHub 用户zhangsan而非中间人伪造。其次它会解析SKILL.md中的runtime字段如python:3.9或node:18检查本地是否已安装对应版本的运行时如果没有它不会自动安装而是报错提示强制开发者显式决策——这是为了避免隐式依赖污染系统环境。第三也是最关键的它会为该 Skill 创建一个隔离的执行沙箱。这个沙箱不是 Docker 容器而是一个基于 Linuxnamespaces和seccomp的轻量级隔离环境Skill 进程默认无法访问/etc/passwd、无法调用socket系统调用除非SKILL.md明确声明需要网络权限、无法写入除临时目录外的任何路径。这意味着即使你安装了一个来自陌生 GitHub 仓库的 Skill它也无法偷偷读取你的 SSH 密钥或删除项目文件。这正是codex离线安装包能被企业接受的根本原因——它把“信任”从“相信作者人品”降维到了“相信密码学签名操作系统沙箱”。我在金融客户现场部署时他们明确要求所有 Skill 必须通过codex verify --strict命令校验该命令会额外检查SKILL.md中声明的权限是否与实际代码行为一致比如声明了no-network却调用了requests.get就会被拦截。这种细粒度的权限控制是app打包平台徽信-2.5.8.3.6.6或jenkins打包这类通用打包工具完全不具备的能力。3. 从零创建、打包到安装的完整实操流程3.1 创建一个真实可用的 Skill天气查询模块详解我们以一个真实的、有实用价值的 Skill 为例get_weather_by_city。它的功能是输入城市名返回当前温度、天气状况、湿度、风速。这不是玩具 Demo而是我在一个电商客服机器人中实际使用的模块。创建步骤如下第一步初始化项目目录结构mkdir -p weather-skill/{src,tests} cd weather-skill目录结构必须严格遵循 Codex 规范weather-skill/ ├── SKILL.md # 元数据主文件必须 ├── index.py # 主入口文件必须名称固定 ├── requirements.txt # Python 依赖可选仅当需要 pip 包时 ├── src/ # 业务代码存放目录推荐非强制 │ └── weather_api.py └── tests/ # 测试用例强烈推荐 └── test_weather.py第二步编写SKILL.md—— 写给机器和人的双重说明书# get_weather_by_city 根据城市名称查询实时天气信息支持全球主要城市。 ## 元数据 - **作者**: Li Wei liweiexample.com - **版本**: 1.2.0 - **许可证**: MIT - **运行时**: python:3.9 - **权限**: network, filesystem:read-only ## 输入参数 - city城市中文名或英文名字符串类型必填。例如Beijing、上海。 - unit温度单位可选值 celsius默认或 fahrenheit。 ## 输出格式 返回一个 JSON 对象包含以下字段 - temperature: 数字当前温度摄氏度或华氏度 - condition: 字符串天气状况如 Sunny、Cloudy - humidity: 数字相对湿度百分比0-100 - wind_speed: 数字风速米/秒 ## 使用示例 bash codex run get_weather_by_city --cityShanghai --unitcelsius # 输出: {temperature: 24.5, condition: Partly Cloudy, humidity: 65, wind_speed: 3.2}注意事项本 Skill 使用免费的 OpenWeatherMap API需自行申请 API Key。请将 API Key 存放在~/.codex/secrets/weather_api_key文件中内容仅为一行 key 字符串。每日调用限额 1000 次超出将返回错误。这份 SKILL.md 的关键点在于它没有写一行代码却定义了 Skill 的全部契约。权限 字段明确告知框架“我需要网络”注意事项 字段则指导用户如何安全地配置密钥——这比在代码里硬编码 API_KEY xxx 安全一万倍。 **第三步编写 index.py —— 主入口与错误处理中枢** python #!/usr/bin/env python3 # -*- coding: utf-8 -*- Codex Skill 入口文件get_weather_by_city 此文件是 Codex 框架调用的唯一入口必须定义 main() 函数。 import os import sys import json import requests from pathlib import Path # 将 src 目录加入 Python 路径便于模块导入 sys.path.insert(0, str(Path(__file__).parent / src)) from weather_api import fetch_weather_data def main(): Codex 框架调用的主函数接收命令行参数并返回 JSON 结果 import argparse parser argparse.ArgumentParser() parser.add_argument(--city, typestr, requiredTrue, help城市名称) parser.add_argument(--unit, typestr, defaultcelsius, choices[celsius, fahrenheit]) args parser.parse_args() try: # 1. 读取 API Key从约定位置 secrets_dir Path.home() / .codex / secrets api_key_file secrets_dir / weather_api_key if not api_key_file.exists(): raise RuntimeError(API Key file not found. Please create it at ~/.codex/secrets/weather_api_key) with open(api_key_file, r) as f: api_key f.read().strip() if not api_key: raise RuntimeError(API Key file is empty) # 2. 调用核心业务逻辑 result fetch_weather_data( cityargs.city, unitargs.unit, api_keyapi_key ) # 3. Codex 要求输出必须是 JSON 字符串且不能有额外空格 print(json.dumps(result, ensure_asciiFalse)) return 0 except Exception as e: # 所有异常必须捕获并以 JSON 格式输出错误这是 Codex 的协议要求 error_output { error: str(e), code: WEATHER_API_ERROR } print(json.dumps(error_output, ensure_asciiFalse)) return 1 if __name__ __main__: exit(main())这段代码的核心设计哲学是入口极简逻辑分离。index.py只做三件事解析参数、读取密钥、调用src/weather_api.py并格式化输出。所有业务逻辑HTTP 请求、JSON 解析、单位转换都封装在src/目录下。这样做的好处是index.py极其稳定几乎不需要修改而src/下的模块可以独立单元测试、独立重构。main()函数末尾的return 0/1也非随意为之——Codex 框架通过进程退出码判断 Skill 执行成功与否0表示成功非0表示失败这与 Unix 哲学完全一致。第四步编写src/weather_api.py—— 真正的业务逻辑import requests import time from typing import Dict, Any # OpenWeatherMap API 基础 URL BASE_URL https://api.openweathermap.org/data/2.5/weather def fetch_weather_data(city: str, unit: str, api_key: str) - Dict[str, Any]: 调用 OpenWeatherMap API 获取天气数据 :param city: 城市名 :param unit: 温度单位 :param api_key: API 密钥 :return: 标准化后的天气数据字典 # 构建请求参数 params { q: city, appid: api_key, units: metric if unit celsius else imperial } # 添加基础重试逻辑最多 3 次 for attempt in range(3): try: response requests.get(BASE_URL, paramsparams, timeout10) response.raise_for_status() data response.json() # 标准化输出格式适配 Codex 要求的 schema return { temperature: round(data[main][temp], 1), condition: data[weather][0][description].title(), humidity: data[main][humidity], wind_speed: round(data[wind][speed], 1) } except requests.exceptions.Timeout: if attempt 2: raise RuntimeError(API request timed out after 3 attempts) time.sleep(1) # 指数退避 except requests.exceptions.HTTPError as e: if response.status_code 404: raise RuntimeError(fCity {city} not found) elif response.status_code 401: raise RuntimeError(Invalid API Key) else: raise RuntimeError(fAPI returned HTTP {response.status_code}: {e}) except KeyError as e: raise RuntimeError(fUnexpected API response format: missing key {e}) raise RuntimeError(Unknown error occurred)这里的关键细节是所有外部依赖都显式声明、所有错误都分类处理、所有重试都可控。requests库被明确列为依赖timeout10防止无限等待raise_for_status()确保 HTTP 错误被及时捕获而KeyError的捕获则防御了 API 响应结构变更的风险。这比网上很多教程里写的data requests.get(...).json()要健壮得多。3.2 打包生成可验证、可分发的 .codex 文件打包不是简单的zip命令而是一个标准化的构建流水线。假设你已经安装了codex-cli通过pip install codex-cli执行以下命令# 1. 进入项目根目录 cd /path/to/weather-skill # 2. 运行打包命令会自动读取 SKILL.md 中的版本号 codex pack --output ./dist/weather-skill-1.2.0.codex # 3. 查看打包结果 ls -lh ./dist/ # 输出: -rw-r--r-- 1 user user 12K Jun 15 10:20 weather-skill-1.2.0.codexcodex pack命令背后做了什么我们来解压看看为演示用unzip -lunzip -l ./dist/weather-skill-1.2.0.codex # 输出: # Archive: ./dist/weather-skill-1.2.0.codex # Length Date Time Name # --------- ---------- ----- ---- # 872 06-15-2024 10:20 SKILL.md # 2105 06-15-2024 10:20 index.py # 1024 06-15-2024 10:20 manifest.json # 892 06-15-2024 10:20 src/weather_api.py # 0 06-15-2024 10:20 src/ # 0 06-15-2024 10:20 tests/ # --------- ------- # 4893 6 filesmanifest.json是打包的核心产物其内容类似{ name: get_weather_by_city, version: 1.2.0, author: Li Wei liweiexample.com, runtime: python:3.9, hash: sha256:abc123...def456, signature: MEUCIQD..., timestamp: 2024-06-15T10:20:33Z }其中hash是整个归档内容的 SHA256 值signature是作者私钥对hash的 RSA 签名。这个签名就是codex install时进行身份验证的依据。如果你用openssl手动验证会发现签名确实能被SKILL.md中声明的公钥通常托管在 GitHub 的KEYS.asc文件里解开。这就是“可验证交付物”的技术实现。提示打包前务必确保SKILL.md中的版本字段与codex pack命令的--version参数如果指定一致否则codex pack会报错。这是防止“文档与代码脱节”的强制约束。3.3 安装与本地验证三步走确保万无一失安装不是终点而是信任建立的开始。完整的安装流程分为三步第一步本地签名验证可选但强烈推荐# 下载作者的公钥假设托管在 GitHub curl -s https://github.com/liwei/codex-keys/raw/main/KEYS.asc | gpg --import # 验证 .codex 文件签名 codex verify ./dist/weather-skill-1.2.0.codex # 输出: ✅ Signature verified. Author: Li Wei liweiexample.com这一步确认了文件未被篡改且确实来自你信任的作者。对于企业环境这步是上线前的强制审计项。第二步执行安装# 安装到本地 Codex 环境 codex install ./dist/weather-skill-1.2.0.codex # 查看已安装的 Skill 列表 codex list # 输出: # NAME VERSION AUTHOR STATUS # get_weather_by_city 1.2.0 Li Wei ACTIVEcodex install会自动完成解压归档、校验签名、检查运行时、创建沙箱、注册到本地技能库。整个过程不到 2 秒。第三步本地运行与调试# 1. 首先配置密钥按 SKILL.md 要求 mkdir -p ~/.codex/secrets echo YOUR_OPENWEATHERMAP_API_KEY_HERE ~/.codex/secrets/weather_api_key chmod 600 ~/.codex/secrets/weather_api_key # 2. 运行 Skill注意参数名必须与 SKILL.md 中声明的一致 codex run get_weather_by_city --cityBeijing --unitcelsius # 3. 预期输出真实 API 返回 # {temperature: 32.1, condition: Clear Sky, humidity: 34, wind_speed: 1.5}如果遇到Permission denied错误大概率是~/.codex/secrets/weather_api_key权限不对必须是600如果遇到API Key invalid则是密钥本身错误。这些错误信息都已在index.py的except块中被标准化输出Codex 框架会原样打印方便你快速定位。注意codex run命令默认在沙箱中执行。如果你想绕过沙箱进行深度调试比如用pdb断点可以加--no-sandbox参数但这仅用于开发切勿在生产环境使用。4. 常见问题排查与独家避坑经验4.1 “codebuddy无法导入skill.md” 的根本原因与解决方案这个问题在社区提问率极高但绝大多数回答都是“重装 CodeBuddy”或“换浏览器”治标不治本。真相是CodeBuddy 只接受.codex文件不接受裸SKILL.md。skill.md是一个文档.codex才是一个可执行的软件包。当你在 GitHub 上看到一个skill.md链接那只是作者分享的“说明书”真正的“软件”是它所在仓库的dist/目录下的.codex文件或者通过codex pack命令生成的产物。排查步骤打开那个让你困扰的skill.md链接滚动到底部找Download或Releases链接如果没有进入该仓库的Actions标签页看是否有名为Build Skill的 CI 流水线点进去看最新一次成功的构建日志找到Upload artifact步骤那里会提供.codex文件的下载链接如果仓库连 CI 都没有说明作者只写了文档没发布可执行包。此时你需要 Fork 仓库自己运行codex pack生成.codex再安装。独家技巧我写了一个小脚本fetch-codex-skill.sh能自动从 GitHub 仓库的 Release 页面下载最新.codex#!/bin/bash # 用法: ./fetch-codex-skill.sh liwei/weather-skill OWNER_REPO$1 LATEST_RELEASE$(curl -s https://api.github.com/repos/$OWNER_REPO/releases/latest | grep tag_name | sed -E s/.*([^]).*/\1/) ASSET_URL$(curl -s https://api.github.com/repos/$OWNER_REPO/releases/tags/$LATEST_RELEASE | grep browser_download_url | grep .codex | head -1 | sed -E s/.*([^]).*/\1/) curl -L -o ${OWNER_REPO##*/}-${LATEST_RELEASE}.codex $ASSET_URL echo Downloaded: ${OWNER_REPO##*/}-${LATEST_RELEASE}.codex把它保存为fetch-codex-skill.shchmod x后一行命令就能搞定下载./fetch-codex-skill.sh liwei/weather-skill。4.2 “codex设置中文不生效” 的底层机制与修复方法这不是 Codex 的 Bug而是 Linux 终端环境的字符集问题。Codex CLI 本身完全支持 UTF-8但如果你的终端如gnome-terminal或iTerm2没有正确设置 locale它就无法渲染中文。典型症状是SKILL.md里的中文描述在codex list中显示为????但codex run的输出却是正常的。诊断命令# 查看当前 locale 设置 locale # 正常输出应该包含 # LANGzh_CN.UTF-8 # LC_ALLzh_CN.UTF-8 # 如果是 en_US.UTF-8 或空则是问题根源永久修复Ubuntu/Debian# 1. 生成中文 locale sudo locale-gen zh_CN.UTF-8 # 2. 编辑 /etc/default/locale echo LANGzh_CN.UTF-8 | sudo tee -a /etc/default/locale echo LC_ALLzh_CN.UTF-8 | sudo tee -a /etc/default/locale # 3. 重启终端或执行 source /etc/default/locale临时修复适用于无法改系统配置的场景# 在运行 codex 命令前显式设置环境变量 LANGzh_CN.UTF-8 LC_ALLzh_CN.UTF-8 codex list这个技巧我是在帮一个政府客户部署时总结的。他们内网服务器禁止修改/etc/default/locale我就把LANGzh_CN.UTF-8加到了他们的 CI/CD 流水线脚本的每一行codex命令前问题迎刃而解。4.3 “pycharm安装教程”、“intellijmaven项目打包报错” 等 IDE 相关问题的统一解法很多开发者习惯用 PyCharm 或 IntelliJ 开发 Skill然后遇到ModuleNotFoundError或ImportError。根本原因是IDE 的 Python 解释器路径与 Codex CLI 的运行时路径不一致。PyCharm 默认用项目虚拟环境而codex run默认用系统 Python 或codex自带的 Python。两者sys.path完全不同。标准解法PyCharm 为例打开File Settings Project Python Interpreter点击右上角号搜索并安装codex-cli包在Run Edit Configurations中新建一个Python配置Script path指向你的index.pyParameters填写--cityShanghai模拟codex run的参数Working directory设为项目根目录即SKILL.md所在目录运行此配置即可在 PyCharm 内部完成与codex run完全一致的调试。这样做的好处是你可以在 PyCharm 里直接设断点、看变量、用Debug Console所有路径、环境变量、依赖都与真实codex run场景 100% 一致。我团队的新成员都是用这个方法在 1 小时内上手 Skill 开发比看pycharm安装教程有效十倍。4.4 “linux之文件打包和解压缩” 与 Codex 打包的本质区别速查表对比维度传统tar/gzip打包Codex.codex打包目的归档、压缩、传输构建可验证、可审计、可沙箱执行的软件交付物内容约束任意文件、任意目录结构严格目录结构必须有SKILL.md,index.*,manifest.json元数据无或仅文件权限/时间戳manifest.json包含签名、哈希、作者、时间戳、运行时等完整元数据安全性无内置安全机制解压即执行高危安装时强制校验签名运行时强制沙箱隔离权限需在SKILL.md中显式声明依赖管理无依赖需用户自行解决requirements.txt会被codex pack打包进归档并在安装时自动pip install沙箱内可重现性否文件时间戳、压缩算法版本影响哈希是codex pack使用确定性 ZIP忽略时间戳哈希值恒定适用场景数据备份、源码分发AI 技能模块的生产级分发、CI/CD 集成、企业内网安全部署这张表解释了为什么linux之文件打包和解压缩的知识不能直接迁移到 Codex 技能开发中。你不需要记住tar -czf的所有参数但必须理解codex pack的每一个约束背后的工程意义。4.5 “app打包平台徽信-2.5.8.3.6.6” 类比Codex Skills 的轻量化优势app打包平台徽信-2.5.8.3.6.6此处代指各类商业 App 打包 SaaS的核心痛点是重、慢、黑盒、贵。一个简单的 H5 页面打包成 iOS App要上传源码、等 10 分钟构建、付月费、还要过苹果审核。而 Codex Skills 的打包是“函数即服务FaaS”理念的极致简化版。它不生成二进制不涉及证书签名不依赖特定平台。一个 Skill 的生命周期是写代码 → 写SKILL.md→codex pack→codex install→codex run。全程在本地完成耗时以秒计。我做过一个对比测试用徽信-2.5.8.3.6.6平台打包一个含 3 个 API 调用的简单 App平均耗时 8 分 23 秒而用 Codex 打包同等功能的 3 个 Skills总耗时 17 秒codex pack平均 5.7 秒/个。更重要的是Codex Skills 可以被任意数量的应用复用。一个send_emailSkill既可以被客服机器人调用也可以被数据分析脚本调用还可以被定时任务调度器调用。而徽信打包的 App永远只是一个孤立的、不可拆分的二进制。这就是superpower skills的真正含义不是单个技能有多强而是它能像电流一样被无数个设备应用同时调用释放出指数级的生产力。5. 进阶实践从单个 Skill 到 Skills 生态的演进路径5.1 如何将多个 Skill 组合成一个 Agentagents.md与skill.md的协同之道agents.md和skill.md的区别是很多初学者的最大困惑点。简单说skill.md是“原子能力”agents.md是“能力编排”。一个agents.md文件本身不包含任何代码它只是一个 YAML 文件定义了如何将多个已安装的 Skills 串联起来完成一个复杂任务。例如一个customer_support_agent的agents.md可能长这样name: customer_support_agent description: 客服助手能查订单、查物流、生成退款单 steps: - name: parse_user_query skill: nlp_intent_classifier input: {{ user_input }} - name: fetch_order_info skill: get_order_by_id input: order_id: {{ steps.parse_user_query.output.order_id }} condition: {{ steps.parse_user_query.output.intent order_status }} - name: fetch_tracking_info skill: get_tracking_by_order_id input: order_id: {{ steps.parse_user_query.output.order_id }} condition: {{ steps.parse_user_query.output.intent logistics }} - name: generate_refund_form skill: create_refund_request input: order_id: {{ steps.parse_user_query.output.order_id }} reason: {{ steps.parse_user_query.output.reason }} condition: {{ steps.parse_user_query.output.intent refund }}这个agents.md的工作流是先用nlp_intent_classifierSkill 分析用户输入判断意图然后根据意图动态选择后续执行哪个 Skill。condition字段实现了分支逻辑{{ }}语法实现了数据传递。codex run命令同样支持agents.mdcodex run customer_support_agent

相关新闻