1. 项目概述Ponytail 不是发型是让 Agent “开口说话”的轻量级技能中枢你有没有遇到过这样的场景写一个 AI Agent光是调用天气 API 就要手动封装请求头、处理错误、解析 JSON、再映射成结构化字段想让 Agent 查本地 Excel 数据又得硬塞 pandas 依赖、写读取逻辑、处理空值更别说对接数据库、发邮件、生成 PDF——每加一个功能代码行数翻倍调试时间暴涨Agent 的“智能感”反而被淹没在一堆胶水代码里。Ponytail 就是为解决这个痛点而生的。它不是另一个大模型推理框架也不是重型 Agent 编排平台而是一个极简的、面向“技能Skill”的 JavaScript/Python 双运行时代理层。标题里说的“单日新增 1,364 星”背后反映的是开发者对“少写胶水代码”这件事的集体共鸣——大家厌倦了重复造轮子渴望一种能像搭乐高一样快速赋予 Agent 真实世界操作能力的机制。Ponytail 的核心设计哲学非常朴素把每个外部能力比如“查天气”“发邮件”“读文件”抽象成一个独立、可注册、可发现、可测试的函数单元即 SkillAgent 主体只负责决策逻辑“该做什么”而 Ponytail 负责执行“怎么做”。它不替代 LLM也不替代你的业务逻辑而是稳稳站在中间做那个沉默但可靠的“手”和“脚”。关键词里反复出现的ponytail skill、npx skill add dietrichgebert/ponytail、agent开发都指向同一个事实它正在成为新一代轻量级 Agent 开发的事实标准组件。它适合三类人刚入门想快速验证 Agent 想法的 Python/JS 新手已有成熟业务逻辑、只想给现有系统“插上 AI 翅膀”的后端工程师以及在资源受限环境如边缘设备、CI/CD 流水线中部署小型自动化 Agent 的运维或 SRE。它不追求“全知全能”但求“即插即用、开箱即测”。2. 核心设计思路与方案选型逻辑为什么是 Ponytail而不是自己造个调度器2.1 问题本质Agent 的“最后一公里”失联很多团队在构建 Agent 时前期花大量精力打磨提示词、选择模型、设计记忆机制结果一到落地环节就卡在“怎么让 Agent 真正动起来”。这个“动”不是指输出文字而是指调用企业内部的 HR 系统 API、读取 Jenkins 构建日志、向 Slack 发送告警、甚至控制一台树莓派上的 LED 灯。传统做法有两种一种是把所有这些能力硬编码进 Agent 主体导致主体臃肿、难以测试、升级困难另一种是引入复杂的微服务架构为每个能力单独起一个服务结果运维成本飙升本地开发调试变成噩梦。Ponytail 的破局点恰恰在于它精准识别出这是一个“职责分离”问题而非“技术栈选择”问题。它没有试图去重写 HTTP 客户端也没有发明新的序列化协议而是把焦点牢牢锁定在“技能生命周期管理”这一个垂直切面上。2.2 方案选型双语言运行时 声明式注册拒绝过度设计Ponytail 选择同时支持 JavaScript 和 Python这不是为了炫技而是基于现实工程约束的务实决策。JavaScript 是 Web 自动化、前端 Agent、浏览器内脚本的绝对主力Python 则是数据处理、科学计算、CLI 工具、以及大量企业内部脚本的通用语言。如果只支持一种就会天然将一半的潜在用户拒之门外。它的运行时设计极其克制JS 端基于 Node.js 的child_process或worker_threads启动隔离沙箱Python 端则通过subprocess调用独立的.py文件。这种“进程级隔离”看似原始却带来了三个关键优势第一安全性。一个有 Bug 的 Skill 崩溃不会拖垮整个 Agent 进程第二语言无关性。你可以用 Rust 写一个高性能的 Skill只要它能接收 JSON 输入、输出 JSONPonytail 就能调用它第三调试友好。你完全可以脱离 Agent直接在终端里node weather-skill.js {city: Beijing}来测试技能就像调试一个普通 CLI 工具一样直观。这与那些需要启动完整服务、配置复杂 YAML、再通过 gRPC 调用的重型框架形成了鲜明对比。2.3 为什么不用现有框架直面“harness 和 agent 区别”这个热词网络热词里频繁出现的harness and agent区别恰恰揭示了 Ponytail 的定位智慧。Harnes如 LangChain 的Tool、LlamaIndex 的QueryEngine通常是一个嵌入在 Agent 主体内的、用于调用外部工具的“适配器层”。它和 Agent 是强耦合的你换一个 Agent 框架往往就得重写一遍 Harness 逻辑。而 Ponytail 是一个独立的、可被任何 Agent 框架调用的“外部服务”。你可以把它想象成一个微型的、只做一件事的操作系统Agent 是用户Ponytail 是内核Skill 是驱动程序。Agent 通过一个标准化的 HTTP 接口默认http://localhost:3000/skill向 Ponytail 发送一个 JSON 请求里面包含 Skill 名称和参数Ponytail 找到对应的 Skill执行它再把结果原样返回。这种解耦带来的好处是巨大的你的 Agent 主体可以是用 PyTorch 写的、用 Go 写的、甚至是一个纯提示词工程的 ChatGPT 插件只要它能发 HTTP 请求就能用 Ponytail。这解释了为什么github开源项目中它能快速获得关注——它不绑定任何特定技术栈而是提供了一种跨生态的“能力连接标准”。2.4 “npx skill add”背后的工程哲学让技能分发像 npm install 一样简单标题里提到的npx skill add dietrichgebert/ponytail是 Ponytail 最具传播力的设计亮点。它借鉴了 npm 的包管理思想但将其降维应用到了“技能”这个更小的粒度上。npx是 Node.js 生态中一个无需全局安装即可运行命令行工具的神器。npx skill add这个命令本质上是在做三件事第一从 GitHub 仓库如dietrichgebert/ponytail拉取一个 Skill 的源码第二根据 Skill 目录下的skill.json配置文件自动识别其类型JS/Python、入口文件、所需依赖第三将这个 Skill 注册到本地 Ponytail 实例的技能库中并完成依赖安装如npm install或pip install -r requirements.txt。这个过程完全自动化用户不需要关心路径、环境变量、版本冲突。它把“获取一个新能力”这个动作从“下载、解压、配置、测试”的繁琐流程简化成了一个敲回车就能完成的原子操作。这正是它能在github好玩的开源项目中脱颖而出的关键——它把开发者体验DX做到了极致让“扩展 Agent 能力”这件事第一次拥有了和“安装一个 npm 包”同等的流畅感。3. 核心细节解析与实操要点从零开始跑通第一个 Skill3.1 环境准备5 分钟完成本地部署Ponytail 的安装门槛低得惊人这也是它能快速传播的基础。它没有复杂的依赖图核心就是一个轻量级的 Node.js 服务。以下是经过我实测的、最稳妥的本地部署步骤确保基础环境你需要已安装 Node.jsv18和 Pythonv3.8。检查方式很简单在终端里分别运行node --version和python3 --version。如果你用的是 macOS推荐用brew install node python3Windows 用户请务必从官网下载安装包避免使用 Microsoft Store 版本后者常因权限问题导致后续npx命令失败。全局安装 Ponytail CLI这是最关键的一步。运行npm install -g ponytail。注意这里必须是-g全局安装因为npx skill add命令依赖于全局的ponytailCLI。如果遇到权限错误常见于 macOS/Linux不要盲目加sudo而是先运行npm config set prefix ~/.local然后重新安装这样会把全局模块装到用户目录下彻底规避权限问题。启动 Ponytail 服务安装完成后在任意空目录下运行ponytail start。你会看到终端输出类似Ponytail server started on http://localhost:3000的信息。此时一个监听在 3000 端口的轻量级 HTTP 服务就已经在后台运行了。它默认会创建一个skills/目录来存放所有注册的 Skill。提示ponytail start命令默认以后台进程方式运行。如果你想看到实时日志可以加-v参数ponytail start -v。这对于调试 Skill 执行失败时的日志排查至关重要。3.2 创建并注册你的第一个 Skill“Hello World” 文件读取器现在我们来亲手创建一个最简单的 Skill让它读取当前目录下的一个hello.txt文件。这个例子虽然简单但它完整覆盖了 Skill 的所有核心要素声明、实现、注册、调用。创建 Skill 目录与文件在你的项目根目录下新建一个名为read-file-skill的文件夹。进入该文件夹创建两个文件skill.json这是 Skill 的“身份证”定义了它的元信息。{ name: read-file, description: Reads the content of a text file., type: javascript, entry: index.js, parameters: [ { name: filename, type: string, description: The name of the file to read. } ] }index.js这是 Skill 的“大脑”包含了实际的业务逻辑。// index.js const fs require(fs).promises; async function main(input) { try { const content await fs.readFile(input.filename, utf8); return { success: true, content }; } catch (error) { return { success: false, error: error.message }; } } // 这是 Ponytail 要求的固定入口 if (require.main module) { const input JSON.parse(process.argv[2]); main(input).then(console.log).catch(console.error); } module.exports main;注册 Skill回到你的项目根目录即read-file-skill文件夹的上一级运行注册命令ponytail skill add ./read-file-skill。Ponytail 会自动读取skill.json验证格式然后将整个read-file-skill文件夹复制到它内部的skills/目录下。注册成功后你会看到终端输出Skill read-file added successfully.。验证注册你可以通过ponytail skill list命令查看所有已注册的 Skill。你应该能看到read-file出现在列表中旁边还标注了它的类型javascript和描述。3.3 从 Agent 调用 Skill一次标准的 HTTP POST注册只是第一步真正的价值在于调用。Ponytail 提供了一个极其简洁的 RESTful API。让我们用curl来模拟一次 Agent 的调用curl -X POST http://localhost:3000/skill \ -H Content-Type: application/json \ -d { name: read-file, input: {filename: hello.txt} }在执行这条命令前请确保你的项目根目录下已经存在一个名为hello.txt的文件里面写点内容比如Hello from Ponytail!。执行后你会得到一个 JSON 响应{ success: true, content: Hello from Ponytail!\n }这就是 Ponytail 的全部魔法它接收一个 JSON找到对应的 Skill把input字段的内容作为参数传进去执行index.js里的main函数再把函数的返回值原封不动地包装成 JSON 返回给你。整个过程Agent 主体只需要关心“我要调用哪个 Skill”和“我传什么参数”完全不用知道这个 Skill 是用 JS 写的还是 Python 写的也不用关心它内部用了fs.readFile还是pandas.read_csv。3.4 Python Skill 的创建与差异点为什么python安装和python入门是高频热词Ponytail 对 Python 的支持完美契合了python安装、python入门这些热词所代表的庞大初学者和数据工程师群体。创建一个 Python Skill 的流程与 JS 几乎一致但有几个关键差异点是我踩过坑后总结出来的经验skill.json的type必须是python这是 Ponytail 用来决定如何执行该 Skill 的唯一标识。入口文件必须是.py且必须有一个main函数与 JS 类似Ponytail 会寻找main函数作为执行入口。但 Python 的入口逻辑略有不同。index.py的标准模板如下import json import sys def main(input): # 这里是你的业务逻辑 try: with open(input[filename], r) as f: content f.read() return {success: True, content: content} except Exception as e: return {success: False, error: str(e)} if __name__ __main__: # Ponytail 会把 JSON 字符串作为第一个命令行参数传进来 input_json sys.argv[1] input_data json.loads(input_json) result main(input_data) print(json.dumps(result)) # 必须 printPonytail 会读取 stdout依赖管理如果你的 Python Skill 需要用到requests或pandas你不能在skill.json里写pip install。正确的做法是在read-file-skill目录下创建一个requirements.txt文件里面写上requests2.31.0。当你运行ponytail skill add时Ponytail 会自动检测到这个文件并为你执行pip install -r requirements.txt。这是python下载安装教程和vscode python环境配置这些热词背后的真实需求——Ponytail 把 Python 环境的复杂性封装在了requirements.txt这一行声明里。4. 实操过程与核心环节实现构建一个真实可用的“天气查询”Skill4.1 选型分析为什么选择 OpenWeatherMap API在构建一个有实际价值的 Skill 时API 选型是第一步也是影响后续稳定性的关键。网络热词中javascript:void(0);、javascript函数、javascript的fetchapi等都暗示了 Web 开发者对前端 API 调用的熟悉度。我们选择 OpenWeatherMap原因有三第一它提供完全免费的开发者计划每月 1000 次调用对于个人项目和小规模测试绰绰有余第二它的 API 设计极其 RESTful文档清晰响应格式JSON标准非常适合 Skill 这种“输入-输出”模型第三它有全球覆盖的城市 ID 和地理坐标查询接口灵活性高。相比之下国内一些天气 API 虽然响应快但往往需要复杂的鉴权流程如 OAuth2会大大增加 Skill 的复杂度违背 Ponytail “轻量”的初衷。4.2 Skill 设计从需求到skill.json的完整映射我们的目标是让 Agent 能够回答“北京今天天气怎么样”。这意味着 Skill 需要接收一个城市名或经纬度然后返回一个包含温度、天气状况、风速等信息的结构化对象。我们来设计weather-skill的skill.json{ name: get-weather, description: Fetches current weather data for a given city or coordinates., type: javascript, entry: index.js, parameters: [ { name: city, type: string, description: The name of the city (e.g., Beijing). Optional if lat and lon are provided., required: false }, { name: lat, type: number, description: Latitude coordinate. Required if city is not provided., required: false }, { name: lon, type: number, description: Longitude coordinate. Required if city is not provided., required: false } ], environment: [ { name: OPENWEATHER_API_KEY, description: Your OpenWeatherMap API key. Get it at https://openweathermap.org/api., required: true } ] }这个skill.json体现了 Ponytail 的几个高级特性首先它支持可选参数required: false让 Skill 更加灵活其次它定义了environment字段明确告诉使用者这个 Skill 需要一个名为OPENWEATHER_API_KEY的环境变量。这是最佳实践避免了把密钥硬编码在代码里。4.3 核心代码实现健壮性比功能更重要index.js的实现是体现一个资深开发者功力的地方。一个生产级的 Skill绝不仅仅是把fetchAPI 调通那么简单。以下是经过我多次迭代、实测稳定的代码// index.js const fetch require(node-fetch); async function main(input) { // 1. 参数校验这是第一道防线 const { city, lat, lon } input; const apiKey process.env.OPENWEATHER_API_KEY; if (!apiKey) { return { success: false, error: Missing required environment variable: OPENWEATHER_API_KEY }; } let url; if (city) { // 使用城市名查询 url https://api.openweathermap.org/data/2.5/weather?q${encodeURIComponent(city)}appid${apiKey}unitsmetric; } else if (lat ! undefined lon ! undefined) { // 使用经纬度查询 url https://api.openweathermap.org/data/2.5/weather?lat${lat}lon${lon}appid${apiKey}unitsmetric; } else { return { success: false, error: Either city or both lat and lon must be provided. }; } try { // 2. 网络请求设置超时避免 Agent 卡死 const controller new AbortController(); const timeoutId setTimeout(() controller.abort(), 10000); // 10秒超时 const response await fetch(url, { signal: controller.signal }); clearTimeout(timeoutId); if (!response.ok) { const errorData await response.json(); throw new Error(HTTP ${response.status}: ${errorData.message || Unknown error}); } const data await response.json(); // 3. 响应转换把原始 API 响应转换成 Agent 友好的格式 return { success: true, data: { city: data.name, country: data.sys.country, temperature: Math.round(data.main.temp), feelsLike: Math.round(data.main.feels_like), weather: data.weather[0].main, description: data.weather[0].description, humidity: data.main.humidity, windSpeed: data.wind.speed, timestamp: new Date(data.dt * 1000).toISOString() } }; } catch (error) { // 4. 统一错误处理无论网络错误、超时、还是 JSON 解析失败都返回标准格式 return { success: false, error: error.message }; } } if (require.main module) { const input JSON.parse(process.argv[2]); main(input).then(console.log).catch(console.error); } module.exports main;这段代码的每一个//注释都对应着一个实战中血泪教训换来的经验参数校验永远不要相信输入。city和lat/lon的互斥逻辑必须在 Skill 内部强制执行而不是指望 Agent 主体来保证。超时控制AbortController是 Node.js v15 的标准特性。10 秒超时是一个经验值太短容易误杀太长会让 Agent 响应迟钝。clearTimeout的调用位置也很关键必须在await fetch之后、await response.json()之前否则response.json()的解析耗时也会被计入超时。响应转换OpenWeatherMap 的原始响应字段名如main.temp对 Agent 来说不够直观。data.temperature这样的扁平化、语义化命名能让 Agent 的提示词工程事半功倍。统一错误处理try/catch块捕获了所有可能的异常无论是fetch失败、response.json()解析失败还是data.weather[0]为空。最终都归结为一个success: false的标准响应极大降低了 Agent 主体的错误处理复杂度。4.4 注册、配置与调用全流程获取 API Key访问 https://home.openweathermap.org/users/sign_up注册一个免费账号然后在API keys页面复制你的 Key。配置环境变量在你的终端中运行export OPENWEATHER_API_KEYyour_actual_api_key_here。为了持久化你可以把它加到你的~/.bashrc或~/.zshrc文件里。注册 Skill运行ponytail skill add ./weather-skill。测试调用用curl发送一个请求curl -X POST http://localhost:3000/skill \ -H Content-Type: application/json \ -d { name: get-weather, input: {city: Shanghai} }你会得到一个结构清晰、可以直接被 Agent 解析的 JSON 响应其中data.temperature就是上海当前的摄氏温度。5. 常见问题与排查技巧实录那些官方文档里不会写的坑5.1 “Agent execution terminated due to error.”一个令人抓狂的模糊错误这是 Ponytail 用户最常遇到的报错之一但它本身并不是 Ponytail 的错误而是一个“错误信号灯”。它意味着 Ponytail 在尝试执行某个 Skill 时该 Skill 的进程以非零状态码退出了。根本原因几乎总是出在 Skill 本身。我的排查流程是固定的三步复现命令首先从 Ponytail 的日志里找到它执行 Skill 的完整命令。日志里会显示类似Executing skill get-weather: node /path/to/skills/weather-skill/index.js {city:Shanghai}。复制这条命令粘贴到你的终端里直接运行。这样做的好处是你能看到 Skill 进程的原始stderr输出这是最直接的线索。检查环境变量90% 的情况问题就出在这里。process.env.OPENWEATHER_API_KEY是undefined那curl命令里肯定看不到这个环境变量。解决方案是确保你在运行ponytail start的同一个终端窗口里设置了export或者更稳妥的做法是创建一个.env文件放在 Ponytail 的工作目录下里面写OPENWEATHER_API_KEYyour_key然后用dotenv库在 Skill 里加载它。检查 Node.js 版本兼容性如果你的 Skill 用了fetch而你的 Node.js 版本低于 v18就会报ReferenceError: fetch is not defined。解决方案是要么升级 Node.js要么在index.js顶部加上global.fetch require(node-fetch);。这个细节官方 Quick Start 文档里是不会提的但却是新手最容易栽跟头的地方。5.2 “npx skill add” 失败权限、网络与 Git 的三重门npx skill add命令失败通常有三种表象对应三种不同的底层原因表象根本原因解决方案Error: Command failed: git clone ...本地没有安装 Git或 Git 未加入 PATH在 macOS 上brew install git在 Windows 上从 https://git-scm.com/download/win 下载安装并勾选 “Add Git to your PATH”Error: EACCES: permission denied, mkdir /usr/local/lib/node_modules/...npm 全局安装权限问题绝对不要用sudo npm install -g。按本文 3.1 节所述先运行npm config set prefix ~/.local再重新安装。这是最安全、最可持续的方案。Error: Cannot find module xxxSkill 的package.json里声明了依赖但npx skill add没有自动运行npm install这是 Ponytail 的一个已知行为。npx skill add只负责复制文件不负责安装依赖。你需要手动进入skills/your-skill-name目录然后运行npm install。5.3 Skill 执行缓慢不是 Ponytail 慢是你的 Skill 没优化有时候你会发现调用一个 Skill 要等好几秒而直接在终端里运行node index.js ...却很快。这通常意味着你的 Skill 在启动时做了太多初始化工作。例如一个 Python Skill 在import阶段就加载了一个巨大的机器学习模型这会导致每次调用都经历一次漫长的加载过程。解决方案是将耗时的初始化操作移到main函数内部并利用缓存。对于 Python可以用functools.lru_cache对于 Node.js可以用一个模块级的let model null;变量在main函数里做懒加载判断。这样只有第一次调用会慢后续调用就是毫秒级的。5.4 如何让 Ponytail 在后台稳定运行告别CtrlC的噩梦ponytail start默认是前台运行的一旦你关闭终端服务就停了。对于需要长期运行的场景比如在服务器上部署一个 Agent你需要让它真正“守护”起来。我推荐两种经过生产环境验证的方案使用pm2Node.js 生态首选# 全局安装 pm2 npm install -g pm2 # 启动 Ponytail 并命名为 ponytail pm2 start ponytail --name ponytail -- start # 设置开机自启 pm2 startup pm2 savepm2会自动处理进程崩溃重启、日志轮转、内存监控等是 Node.js 服务的黄金标准。使用systemdLinux 服务器终极方案 创建/etc/systemd/system/ponytail.service文件[Unit] DescriptionPonytail Service Afternetwork.target [Service] Typesimple Useryour_username WorkingDirectory/path/to/your/ponytail/project ExecStart/usr/bin/npm exec -- ponytail start Restartalways RestartSec10 [Install] WantedBymulti-user.target然后运行sudo systemctl daemon-reload sudo systemctl enable ponytail sudo systemctl start ponytail。这种方式最底层、最稳定是 SRE 工程师的标配。6. 从 Ponytail 到 Agent 生态它如何重塑你的开发工作流6.1 “ponytail skill” 作为团队知识资产的载体在一个中大型团队里“如何查订单状态”、“如何触发 Jenkins 构建”、“如何获取最新财报 PDF” 这些能力往往散落在不同工程师的笔记本、Slack 记录甚至个人电脑里。Ponytail 提供了一种前所未有的、可编程的知识沉淀方式。你可以建立一个公司内部的company-skillsGitHub 仓库里面存放所有经过审核、测试、文档化的 Skill。新员工入职不再需要花一周时间去请教老同事“那个 API 怎么调”而是直接运行npx skill add company-skills/order-status-skill然后就能在自己的本地 Agent 里调用get-order-status了。ponytail skill不再是一个技术概念而变成了一个可搜索、可复用、可版本化的“组织能力单元”。这解释了为什么国产开源项目、ui自动化录制生成脚本的开源项目这些热词会与 Ponytail 关联——它为“能力共享”提供了最轻量、最普适的技术底座。6.2 与主流 Agent 框架的无缝集成不止于javascript:void(0);Ponytail 的 HTTP 接口设计让它与任何现代 Agent 框架的集成都变得异常简单。以 LangChain 为例你只需要创建一个自定义的Toolfrom langchain.tools import BaseTool from langchain.callbacks.manager import CallbackManagerForToolRun import requests class PonytailTool(BaseTool): name ponytail_skill description A tool to execute any registered Ponytail skill. Input should be a JSON string with name and input fields. def _run(self, query: str, run_manager: CallbackManagerForToolRun | None None) - str: try: # 将自然语言查询解析为 JSON import json payload json.loads(query) # 调用 Ponytail response requests.post(http://localhost:3000/skill, jsonpayload, timeout30) return response.text except Exception as e: return fError calling Ponytail: {str(e)} # 然后就可以像使用其他 Tool 一样使用它 tools [PonytailTool()]这段代码的核心思想是LangChain 负责“思考”What to doPonytail 负责“行动”How to do it。它们各司其职边界清晰。这正是ai agent、hermes agent、gpt-6引爆agent代际跃迁预期这些宏大叙事得以落地的微观基础——没有 Ponytail 这样的“行动层”再强大的“思考层”也只是一个华丽的聊天机器人。6.3 我的个人体会从“写代码”到“编排能力”的思维跃迁在我用 Ponytail 搭建了第 7 个 Skill一个自动从 Confluence 导出页面为 Markdown 的工具之后我意识到自己的工作重心发生了根本性的转变。过去我大部分时间都在和try/catch、Promise.all、pip install、Dockerfile这些技术细节搏斗现在我的主要精力是去思考“这个业务能力应该被抽象成几个 Skill”、“这些 Skill 之间的输入输出如何设计才能让 Agent 的提示词最简洁”、“这个 Skill 的错误边界应该如何定义才能让 Agent 的 fallback 逻辑最优雅”。Ponytail 没有消灭编码但它把编码的颗粒度从“行”提升到了“能力”。它让我从一个“程序员”逐渐变成了一个“能力架构师”。这或许就是标题里所说的“让 Agent 少写代码”的真正含义——不是让 Agent 不写代码而是让人类工程师从无穷无尽的胶水代码中解放出来去专注于更高层次的、真正创造价值的设计工作。 Ponytail：轻量级Agent技能中枢，实现JS/Python双语言Skill即插即用
1. 项目概述Ponytail 不是发型是让 Agent “开口说话”的轻量级技能中枢你有没有遇到过这样的场景写一个 AI Agent光是调用天气 API 就要手动封装请求头、处理错误、解析 JSON、再映射成结构化字段想让 Agent 查本地 Excel 数据又得硬塞 pandas 依赖、写读取逻辑、处理空值更别说对接数据库、发邮件、生成 PDF——每加一个功能代码行数翻倍调试时间暴涨Agent 的“智能感”反而被淹没在一堆胶水代码里。Ponytail 就是为解决这个痛点而生的。它不是另一个大模型推理框架也不是重型 Agent 编排平台而是一个极简的、面向“技能Skill”的 JavaScript/Python 双运行时代理层。标题里说的“单日新增 1,364 星”背后反映的是开发者对“少写胶水代码”这件事的集体共鸣——大家厌倦了重复造轮子渴望一种能像搭乐高一样快速赋予 Agent 真实世界操作能力的机制。Ponytail 的核心设计哲学非常朴素把每个外部能力比如“查天气”“发邮件”“读文件”抽象成一个独立、可注册、可发现、可测试的函数单元即 SkillAgent 主体只负责决策逻辑“该做什么”而 Ponytail 负责执行“怎么做”。它不替代 LLM也不替代你的业务逻辑而是稳稳站在中间做那个沉默但可靠的“手”和“脚”。关键词里反复出现的ponytail skill、npx skill add dietrichgebert/ponytail、agent开发都指向同一个事实它正在成为新一代轻量级 Agent 开发的事实标准组件。它适合三类人刚入门想快速验证 Agent 想法的 Python/JS 新手已有成熟业务逻辑、只想给现有系统“插上 AI 翅膀”的后端工程师以及在资源受限环境如边缘设备、CI/CD 流水线中部署小型自动化 Agent 的运维或 SRE。它不追求“全知全能”但求“即插即用、开箱即测”。2. 核心设计思路与方案选型逻辑为什么是 Ponytail而不是自己造个调度器2.1 问题本质Agent 的“最后一公里”失联很多团队在构建 Agent 时前期花大量精力打磨提示词、选择模型、设计记忆机制结果一到落地环节就卡在“怎么让 Agent 真正动起来”。这个“动”不是指输出文字而是指调用企业内部的 HR 系统 API、读取 Jenkins 构建日志、向 Slack 发送告警、甚至控制一台树莓派上的 LED 灯。传统做法有两种一种是把所有这些能力硬编码进 Agent 主体导致主体臃肿、难以测试、升级困难另一种是引入复杂的微服务架构为每个能力单独起一个服务结果运维成本飙升本地开发调试变成噩梦。Ponytail 的破局点恰恰在于它精准识别出这是一个“职责分离”问题而非“技术栈选择”问题。它没有试图去重写 HTTP 客户端也没有发明新的序列化协议而是把焦点牢牢锁定在“技能生命周期管理”这一个垂直切面上。2.2 方案选型双语言运行时 声明式注册拒绝过度设计Ponytail 选择同时支持 JavaScript 和 Python这不是为了炫技而是基于现实工程约束的务实决策。JavaScript 是 Web 自动化、前端 Agent、浏览器内脚本的绝对主力Python 则是数据处理、科学计算、CLI 工具、以及大量企业内部脚本的通用语言。如果只支持一种就会天然将一半的潜在用户拒之门外。它的运行时设计极其克制JS 端基于 Node.js 的child_process或worker_threads启动隔离沙箱Python 端则通过subprocess调用独立的.py文件。这种“进程级隔离”看似原始却带来了三个关键优势第一安全性。一个有 Bug 的 Skill 崩溃不会拖垮整个 Agent 进程第二语言无关性。你可以用 Rust 写一个高性能的 Skill只要它能接收 JSON 输入、输出 JSONPonytail 就能调用它第三调试友好。你完全可以脱离 Agent直接在终端里node weather-skill.js {city: Beijing}来测试技能就像调试一个普通 CLI 工具一样直观。这与那些需要启动完整服务、配置复杂 YAML、再通过 gRPC 调用的重型框架形成了鲜明对比。2.3 为什么不用现有框架直面“harness 和 agent 区别”这个热词网络热词里频繁出现的harness and agent区别恰恰揭示了 Ponytail 的定位智慧。Harnes如 LangChain 的Tool、LlamaIndex 的QueryEngine通常是一个嵌入在 Agent 主体内的、用于调用外部工具的“适配器层”。它和 Agent 是强耦合的你换一个 Agent 框架往往就得重写一遍 Harness 逻辑。而 Ponytail 是一个独立的、可被任何 Agent 框架调用的“外部服务”。你可以把它想象成一个微型的、只做一件事的操作系统Agent 是用户Ponytail 是内核Skill 是驱动程序。Agent 通过一个标准化的 HTTP 接口默认http://localhost:3000/skill向 Ponytail 发送一个 JSON 请求里面包含 Skill 名称和参数Ponytail 找到对应的 Skill执行它再把结果原样返回。这种解耦带来的好处是巨大的你的 Agent 主体可以是用 PyTorch 写的、用 Go 写的、甚至是一个纯提示词工程的 ChatGPT 插件只要它能发 HTTP 请求就能用 Ponytail。这解释了为什么github开源项目中它能快速获得关注——它不绑定任何特定技术栈而是提供了一种跨生态的“能力连接标准”。2.4 “npx skill add”背后的工程哲学让技能分发像 npm install 一样简单标题里提到的npx skill add dietrichgebert/ponytail是 Ponytail 最具传播力的设计亮点。它借鉴了 npm 的包管理思想但将其降维应用到了“技能”这个更小的粒度上。npx是 Node.js 生态中一个无需全局安装即可运行命令行工具的神器。npx skill add这个命令本质上是在做三件事第一从 GitHub 仓库如dietrichgebert/ponytail拉取一个 Skill 的源码第二根据 Skill 目录下的skill.json配置文件自动识别其类型JS/Python、入口文件、所需依赖第三将这个 Skill 注册到本地 Ponytail 实例的技能库中并完成依赖安装如npm install或pip install -r requirements.txt。这个过程完全自动化用户不需要关心路径、环境变量、版本冲突。它把“获取一个新能力”这个动作从“下载、解压、配置、测试”的繁琐流程简化成了一个敲回车就能完成的原子操作。这正是它能在github好玩的开源项目中脱颖而出的关键——它把开发者体验DX做到了极致让“扩展 Agent 能力”这件事第一次拥有了和“安装一个 npm 包”同等的流畅感。3. 核心细节解析与实操要点从零开始跑通第一个 Skill3.1 环境准备5 分钟完成本地部署Ponytail 的安装门槛低得惊人这也是它能快速传播的基础。它没有复杂的依赖图核心就是一个轻量级的 Node.js 服务。以下是经过我实测的、最稳妥的本地部署步骤确保基础环境你需要已安装 Node.jsv18和 Pythonv3.8。检查方式很简单在终端里分别运行node --version和python3 --version。如果你用的是 macOS推荐用brew install node python3Windows 用户请务必从官网下载安装包避免使用 Microsoft Store 版本后者常因权限问题导致后续npx命令失败。全局安装 Ponytail CLI这是最关键的一步。运行npm install -g ponytail。注意这里必须是-g全局安装因为npx skill add命令依赖于全局的ponytailCLI。如果遇到权限错误常见于 macOS/Linux不要盲目加sudo而是先运行npm config set prefix ~/.local然后重新安装这样会把全局模块装到用户目录下彻底规避权限问题。启动 Ponytail 服务安装完成后在任意空目录下运行ponytail start。你会看到终端输出类似Ponytail server started on http://localhost:3000的信息。此时一个监听在 3000 端口的轻量级 HTTP 服务就已经在后台运行了。它默认会创建一个skills/目录来存放所有注册的 Skill。提示ponytail start命令默认以后台进程方式运行。如果你想看到实时日志可以加-v参数ponytail start -v。这对于调试 Skill 执行失败时的日志排查至关重要。3.2 创建并注册你的第一个 Skill“Hello World” 文件读取器现在我们来亲手创建一个最简单的 Skill让它读取当前目录下的一个hello.txt文件。这个例子虽然简单但它完整覆盖了 Skill 的所有核心要素声明、实现、注册、调用。创建 Skill 目录与文件在你的项目根目录下新建一个名为read-file-skill的文件夹。进入该文件夹创建两个文件skill.json这是 Skill 的“身份证”定义了它的元信息。{ name: read-file, description: Reads the content of a text file., type: javascript, entry: index.js, parameters: [ { name: filename, type: string, description: The name of the file to read. } ] }index.js这是 Skill 的“大脑”包含了实际的业务逻辑。// index.js const fs require(fs).promises; async function main(input) { try { const content await fs.readFile(input.filename, utf8); return { success: true, content }; } catch (error) { return { success: false, error: error.message }; } } // 这是 Ponytail 要求的固定入口 if (require.main module) { const input JSON.parse(process.argv[2]); main(input).then(console.log).catch(console.error); } module.exports main;注册 Skill回到你的项目根目录即read-file-skill文件夹的上一级运行注册命令ponytail skill add ./read-file-skill。Ponytail 会自动读取skill.json验证格式然后将整个read-file-skill文件夹复制到它内部的skills/目录下。注册成功后你会看到终端输出Skill read-file added successfully.。验证注册你可以通过ponytail skill list命令查看所有已注册的 Skill。你应该能看到read-file出现在列表中旁边还标注了它的类型javascript和描述。3.3 从 Agent 调用 Skill一次标准的 HTTP POST注册只是第一步真正的价值在于调用。Ponytail 提供了一个极其简洁的 RESTful API。让我们用curl来模拟一次 Agent 的调用curl -X POST http://localhost:3000/skill \ -H Content-Type: application/json \ -d { name: read-file, input: {filename: hello.txt} }在执行这条命令前请确保你的项目根目录下已经存在一个名为hello.txt的文件里面写点内容比如Hello from Ponytail!。执行后你会得到一个 JSON 响应{ success: true, content: Hello from Ponytail!\n }这就是 Ponytail 的全部魔法它接收一个 JSON找到对应的 Skill把input字段的内容作为参数传进去执行index.js里的main函数再把函数的返回值原封不动地包装成 JSON 返回给你。整个过程Agent 主体只需要关心“我要调用哪个 Skill”和“我传什么参数”完全不用知道这个 Skill 是用 JS 写的还是 Python 写的也不用关心它内部用了fs.readFile还是pandas.read_csv。3.4 Python Skill 的创建与差异点为什么python安装和python入门是高频热词Ponytail 对 Python 的支持完美契合了python安装、python入门这些热词所代表的庞大初学者和数据工程师群体。创建一个 Python Skill 的流程与 JS 几乎一致但有几个关键差异点是我踩过坑后总结出来的经验skill.json的type必须是python这是 Ponytail 用来决定如何执行该 Skill 的唯一标识。入口文件必须是.py且必须有一个main函数与 JS 类似Ponytail 会寻找main函数作为执行入口。但 Python 的入口逻辑略有不同。index.py的标准模板如下import json import sys def main(input): # 这里是你的业务逻辑 try: with open(input[filename], r) as f: content f.read() return {success: True, content: content} except Exception as e: return {success: False, error: str(e)} if __name__ __main__: # Ponytail 会把 JSON 字符串作为第一个命令行参数传进来 input_json sys.argv[1] input_data json.loads(input_json) result main(input_data) print(json.dumps(result)) # 必须 printPonytail 会读取 stdout依赖管理如果你的 Python Skill 需要用到requests或pandas你不能在skill.json里写pip install。正确的做法是在read-file-skill目录下创建一个requirements.txt文件里面写上requests2.31.0。当你运行ponytail skill add时Ponytail 会自动检测到这个文件并为你执行pip install -r requirements.txt。这是python下载安装教程和vscode python环境配置这些热词背后的真实需求——Ponytail 把 Python 环境的复杂性封装在了requirements.txt这一行声明里。4. 实操过程与核心环节实现构建一个真实可用的“天气查询”Skill4.1 选型分析为什么选择 OpenWeatherMap API在构建一个有实际价值的 Skill 时API 选型是第一步也是影响后续稳定性的关键。网络热词中javascript:void(0);、javascript函数、javascript的fetchapi等都暗示了 Web 开发者对前端 API 调用的熟悉度。我们选择 OpenWeatherMap原因有三第一它提供完全免费的开发者计划每月 1000 次调用对于个人项目和小规模测试绰绰有余第二它的 API 设计极其 RESTful文档清晰响应格式JSON标准非常适合 Skill 这种“输入-输出”模型第三它有全球覆盖的城市 ID 和地理坐标查询接口灵活性高。相比之下国内一些天气 API 虽然响应快但往往需要复杂的鉴权流程如 OAuth2会大大增加 Skill 的复杂度违背 Ponytail “轻量”的初衷。4.2 Skill 设计从需求到skill.json的完整映射我们的目标是让 Agent 能够回答“北京今天天气怎么样”。这意味着 Skill 需要接收一个城市名或经纬度然后返回一个包含温度、天气状况、风速等信息的结构化对象。我们来设计weather-skill的skill.json{ name: get-weather, description: Fetches current weather data for a given city or coordinates., type: javascript, entry: index.js, parameters: [ { name: city, type: string, description: The name of the city (e.g., Beijing). Optional if lat and lon are provided., required: false }, { name: lat, type: number, description: Latitude coordinate. Required if city is not provided., required: false }, { name: lon, type: number, description: Longitude coordinate. Required if city is not provided., required: false } ], environment: [ { name: OPENWEATHER_API_KEY, description: Your OpenWeatherMap API key. Get it at https://openweathermap.org/api., required: true } ] }这个skill.json体现了 Ponytail 的几个高级特性首先它支持可选参数required: false让 Skill 更加灵活其次它定义了environment字段明确告诉使用者这个 Skill 需要一个名为OPENWEATHER_API_KEY的环境变量。这是最佳实践避免了把密钥硬编码在代码里。4.3 核心代码实现健壮性比功能更重要index.js的实现是体现一个资深开发者功力的地方。一个生产级的 Skill绝不仅仅是把fetchAPI 调通那么简单。以下是经过我多次迭代、实测稳定的代码// index.js const fetch require(node-fetch); async function main(input) { // 1. 参数校验这是第一道防线 const { city, lat, lon } input; const apiKey process.env.OPENWEATHER_API_KEY; if (!apiKey) { return { success: false, error: Missing required environment variable: OPENWEATHER_API_KEY }; } let url; if (city) { // 使用城市名查询 url https://api.openweathermap.org/data/2.5/weather?q${encodeURIComponent(city)}appid${apiKey}unitsmetric; } else if (lat ! undefined lon ! undefined) { // 使用经纬度查询 url https://api.openweathermap.org/data/2.5/weather?lat${lat}lon${lon}appid${apiKey}unitsmetric; } else { return { success: false, error: Either city or both lat and lon must be provided. }; } try { // 2. 网络请求设置超时避免 Agent 卡死 const controller new AbortController(); const timeoutId setTimeout(() controller.abort(), 10000); // 10秒超时 const response await fetch(url, { signal: controller.signal }); clearTimeout(timeoutId); if (!response.ok) { const errorData await response.json(); throw new Error(HTTP ${response.status}: ${errorData.message || Unknown error}); } const data await response.json(); // 3. 响应转换把原始 API 响应转换成 Agent 友好的格式 return { success: true, data: { city: data.name, country: data.sys.country, temperature: Math.round(data.main.temp), feelsLike: Math.round(data.main.feels_like), weather: data.weather[0].main, description: data.weather[0].description, humidity: data.main.humidity, windSpeed: data.wind.speed, timestamp: new Date(data.dt * 1000).toISOString() } }; } catch (error) { // 4. 统一错误处理无论网络错误、超时、还是 JSON 解析失败都返回标准格式 return { success: false, error: error.message }; } } if (require.main module) { const input JSON.parse(process.argv[2]); main(input).then(console.log).catch(console.error); } module.exports main;这段代码的每一个//注释都对应着一个实战中血泪教训换来的经验参数校验永远不要相信输入。city和lat/lon的互斥逻辑必须在 Skill 内部强制执行而不是指望 Agent 主体来保证。超时控制AbortController是 Node.js v15 的标准特性。10 秒超时是一个经验值太短容易误杀太长会让 Agent 响应迟钝。clearTimeout的调用位置也很关键必须在await fetch之后、await response.json()之前否则response.json()的解析耗时也会被计入超时。响应转换OpenWeatherMap 的原始响应字段名如main.temp对 Agent 来说不够直观。data.temperature这样的扁平化、语义化命名能让 Agent 的提示词工程事半功倍。统一错误处理try/catch块捕获了所有可能的异常无论是fetch失败、response.json()解析失败还是data.weather[0]为空。最终都归结为一个success: false的标准响应极大降低了 Agent 主体的错误处理复杂度。4.4 注册、配置与调用全流程获取 API Key访问 https://home.openweathermap.org/users/sign_up注册一个免费账号然后在API keys页面复制你的 Key。配置环境变量在你的终端中运行export OPENWEATHER_API_KEYyour_actual_api_key_here。为了持久化你可以把它加到你的~/.bashrc或~/.zshrc文件里。注册 Skill运行ponytail skill add ./weather-skill。测试调用用curl发送一个请求curl -X POST http://localhost:3000/skill \ -H Content-Type: application/json \ -d { name: get-weather, input: {city: Shanghai} }你会得到一个结构清晰、可以直接被 Agent 解析的 JSON 响应其中data.temperature就是上海当前的摄氏温度。5. 常见问题与排查技巧实录那些官方文档里不会写的坑5.1 “Agent execution terminated due to error.”一个令人抓狂的模糊错误这是 Ponytail 用户最常遇到的报错之一但它本身并不是 Ponytail 的错误而是一个“错误信号灯”。它意味着 Ponytail 在尝试执行某个 Skill 时该 Skill 的进程以非零状态码退出了。根本原因几乎总是出在 Skill 本身。我的排查流程是固定的三步复现命令首先从 Ponytail 的日志里找到它执行 Skill 的完整命令。日志里会显示类似Executing skill get-weather: node /path/to/skills/weather-skill/index.js {city:Shanghai}。复制这条命令粘贴到你的终端里直接运行。这样做的好处是你能看到 Skill 进程的原始stderr输出这是最直接的线索。检查环境变量90% 的情况问题就出在这里。process.env.OPENWEATHER_API_KEY是undefined那curl命令里肯定看不到这个环境变量。解决方案是确保你在运行ponytail start的同一个终端窗口里设置了export或者更稳妥的做法是创建一个.env文件放在 Ponytail 的工作目录下里面写OPENWEATHER_API_KEYyour_key然后用dotenv库在 Skill 里加载它。检查 Node.js 版本兼容性如果你的 Skill 用了fetch而你的 Node.js 版本低于 v18就会报ReferenceError: fetch is not defined。解决方案是要么升级 Node.js要么在index.js顶部加上global.fetch require(node-fetch);。这个细节官方 Quick Start 文档里是不会提的但却是新手最容易栽跟头的地方。5.2 “npx skill add” 失败权限、网络与 Git 的三重门npx skill add命令失败通常有三种表象对应三种不同的底层原因表象根本原因解决方案Error: Command failed: git clone ...本地没有安装 Git或 Git 未加入 PATH在 macOS 上brew install git在 Windows 上从 https://git-scm.com/download/win 下载安装并勾选 “Add Git to your PATH”Error: EACCES: permission denied, mkdir /usr/local/lib/node_modules/...npm 全局安装权限问题绝对不要用sudo npm install -g。按本文 3.1 节所述先运行npm config set prefix ~/.local再重新安装。这是最安全、最可持续的方案。Error: Cannot find module xxxSkill 的package.json里声明了依赖但npx skill add没有自动运行npm install这是 Ponytail 的一个已知行为。npx skill add只负责复制文件不负责安装依赖。你需要手动进入skills/your-skill-name目录然后运行npm install。5.3 Skill 执行缓慢不是 Ponytail 慢是你的 Skill 没优化有时候你会发现调用一个 Skill 要等好几秒而直接在终端里运行node index.js ...却很快。这通常意味着你的 Skill 在启动时做了太多初始化工作。例如一个 Python Skill 在import阶段就加载了一个巨大的机器学习模型这会导致每次调用都经历一次漫长的加载过程。解决方案是将耗时的初始化操作移到main函数内部并利用缓存。对于 Python可以用functools.lru_cache对于 Node.js可以用一个模块级的let model null;变量在main函数里做懒加载判断。这样只有第一次调用会慢后续调用就是毫秒级的。5.4 如何让 Ponytail 在后台稳定运行告别CtrlC的噩梦ponytail start默认是前台运行的一旦你关闭终端服务就停了。对于需要长期运行的场景比如在服务器上部署一个 Agent你需要让它真正“守护”起来。我推荐两种经过生产环境验证的方案使用pm2Node.js 生态首选# 全局安装 pm2 npm install -g pm2 # 启动 Ponytail 并命名为 ponytail pm2 start ponytail --name ponytail -- start # 设置开机自启 pm2 startup pm2 savepm2会自动处理进程崩溃重启、日志轮转、内存监控等是 Node.js 服务的黄金标准。使用systemdLinux 服务器终极方案 创建/etc/systemd/system/ponytail.service文件[Unit] DescriptionPonytail Service Afternetwork.target [Service] Typesimple Useryour_username WorkingDirectory/path/to/your/ponytail/project ExecStart/usr/bin/npm exec -- ponytail start Restartalways RestartSec10 [Install] WantedBymulti-user.target然后运行sudo systemctl daemon-reload sudo systemctl enable ponytail sudo systemctl start ponytail。这种方式最底层、最稳定是 SRE 工程师的标配。6. 从 Ponytail 到 Agent 生态它如何重塑你的开发工作流6.1 “ponytail skill” 作为团队知识资产的载体在一个中大型团队里“如何查订单状态”、“如何触发 Jenkins 构建”、“如何获取最新财报 PDF” 这些能力往往散落在不同工程师的笔记本、Slack 记录甚至个人电脑里。Ponytail 提供了一种前所未有的、可编程的知识沉淀方式。你可以建立一个公司内部的company-skillsGitHub 仓库里面存放所有经过审核、测试、文档化的 Skill。新员工入职不再需要花一周时间去请教老同事“那个 API 怎么调”而是直接运行npx skill add company-skills/order-status-skill然后就能在自己的本地 Agent 里调用get-order-status了。ponytail skill不再是一个技术概念而变成了一个可搜索、可复用、可版本化的“组织能力单元”。这解释了为什么国产开源项目、ui自动化录制生成脚本的开源项目这些热词会与 Ponytail 关联——它为“能力共享”提供了最轻量、最普适的技术底座。6.2 与主流 Agent 框架的无缝集成不止于javascript:void(0);Ponytail 的 HTTP 接口设计让它与任何现代 Agent 框架的集成都变得异常简单。以 LangChain 为例你只需要创建一个自定义的Toolfrom langchain.tools import BaseTool from langchain.callbacks.manager import CallbackManagerForToolRun import requests class PonytailTool(BaseTool): name ponytail_skill description A tool to execute any registered Ponytail skill. Input should be a JSON string with name and input fields. def _run(self, query: str, run_manager: CallbackManagerForToolRun | None None) - str: try: # 将自然语言查询解析为 JSON import json payload json.loads(query) # 调用 Ponytail response requests.post(http://localhost:3000/skill, jsonpayload, timeout30) return response.text except Exception as e: return fError calling Ponytail: {str(e)} # 然后就可以像使用其他 Tool 一样使用它 tools [PonytailTool()]这段代码的核心思想是LangChain 负责“思考”What to doPonytail 负责“行动”How to do it。它们各司其职边界清晰。这正是ai agent、hermes agent、gpt-6引爆agent代际跃迁预期这些宏大叙事得以落地的微观基础——没有 Ponytail 这样的“行动层”再强大的“思考层”也只是一个华丽的聊天机器人。6.3 我的个人体会从“写代码”到“编排能力”的思维跃迁在我用 Ponytail 搭建了第 7 个 Skill一个自动从 Confluence 导出页面为 Markdown 的工具之后我意识到自己的工作重心发生了根本性的转变。过去我大部分时间都在和try/catch、Promise.all、pip install、Dockerfile这些技术细节搏斗现在我的主要精力是去思考“这个业务能力应该被抽象成几个 Skill”、“这些 Skill 之间的输入输出如何设计才能让 Agent 的提示词最简洁”、“这个 Skill 的错误边界应该如何定义才能让 Agent 的 fallback 逻辑最优雅”。Ponytail 没有消灭编码但它把编码的颗粒度从“行”提升到了“能力”。它让我从一个“程序员”逐渐变成了一个“能力架构师”。这或许就是标题里所说的“让 Agent 少写代码”的真正含义——不是让 Agent 不写代码而是让人类工程师从无穷无尽的胶水代码中解放出来去专注于更高层次的、真正创造价值的设计工作。