AI Agent 不只会聊天用 OpenClaw Skill 把常用工具变成可调用工作流如果你最近也在用 Agent 写代码、查资料、跑脚本大概率会遇到一个很现实的问题它聊天很顺但一碰到真实软件、内网面板、公司自研工具就开始“隔着玻璃干活”。它知道你想做什么却没有稳定入口去调用那个工具。这篇不聊“让 Agent 更聪明”的大词直接聊一个更落地的方向把常用工具包装成 Agent 能调用的工作流。这里会用到两个关键词OpenClaw Skill 和 CLI-Anything。前者负责让 OpenClaw 识别一类能力后者的思路是把软件或代码库包装成 Agent 友好的 CLI。这件事做成以后Agent 不只是回答“怎么做”而是能按步骤调用命令、读取输出、继续下一步。说白了就是让工具从“给人点的按钮”变成“给 Agent 调的接口”。1 为什么 Agent 需要 Skill而不是只靠聊天单纯聊天的 Agent最擅长的是解释、总结、规划。但真实工作里大量任务不止是“说清楚”还要“做完”把一个文件转换成另一种格式从本地项目里抽取信息调用内网 API 生成测试数据打开某个后台面板查状态让工具跑一轮校验并返回结构化结果这些动作都有一个共同点需要稳定、可重复、可验证的调用入口。如果入口只有 GUIAgent 就会很别扭。它要么依赖截图和点击要么依赖浏览器自动化。能做但链路长、反馈慢遇到弹窗、布局变化、权限提示就容易卡住。CLI 对 Agent 更友好。CLI 命令天然是文本参数清晰输出可保存如果再提供--json这类机器可读结果Agent 就能直接根据返回值判断下一步怎么走。CLI-Anything 的 README 中文文档里也把这个点说得很直白CLI 是人类和 AI Agent 共通的接口具备结构化、可组合、自描述、JSON 输出、确定可靠这些特点。这里别把它理解成“所有软件一秒自动变神器”更准确的理解是它提供了一套把软件变成 Agent 可调用 CLI 的方法论和工程模板。2 先看 CLI-Anything 在这条链路里负责什么CLI-Anything 项目地址是 HKUDS/CLI-Anythinggit clone https://github.com/HKUDS/CLI-Anything.git它的定位可以概括成一句话把任意软件或代码库包装成 Agent 可调用的 CLI harness。这里的 harness 可以理解成“适配层”。原来的工具有自己的 GUI、脚本接口、API 或内部模块Agent 不一定知道怎么用harness 则把高频能力整理成命令比如convert、search、export、inspect、validate再给出稳定输出。官方中文 README 里提到的构建流程分成 7 个阶段分析扫描源码或能力入口把 GUI 操作映射到可调用接口设计规划命令分组、状态模型、输出格式实现构建 Click CLI包含 REPL、JSON 输出、撤销/重做等能力规划测试生成 TEST.md覆盖单元测试和端到端测试计划编写测试实现测试套件文档更新使用说明和测试结果发布生成安装入口让命令能被 PATH 调用这套流程最有价值的地方不是“自动化”三个字而是它把 Agent 调工具这件事拆成了工程步骤。命令长什么样、输出怎么稳定、怎么测试、怎么安装都有明确落点。提醒一句实际效果取决于目标软件本身有没有可复用的后端能力。一个本来就有命令行、Python API 或稳定数据结构的软件适配起来更顺纯 GUI、强交互、闭源且没有脚本接口的工具就要保守评估。3 在 OpenClaw 里安装 cli-anything SkillOpenClaw 的 Skill 可以理解成 Agent 的“能力说明书”。一个SKILL.md文件会告诉 Agent什么时候该用这个能力、输入是什么、应该产出什么结构、有哪些边界。CLI-Anything 提供了 OpenClaw Skill 接入方式。按官方 README 的口径可以把仓库里的openclaw-skill/SKILL.md放到 OpenClaw 的 skills 目录# 克隆 CLI-Anything 仓库 git clone https://github.com/HKUDS/CLI-Anything.git # 安装到 OpenClaw 全局 skills 目录 mkdir -p ~/.openclaw/skills/cli-anything cp CLI-Anything/openclaw-skill/SKILL.md ~/.openclaw/skills/cli-anything/SKILL.md装完以后先别急着让 Agent 大干一场。建议先把 Skill 文件打开看一眼确认它到底要求 Agent 做什么sed -n 1,220p ~/.openclaw/skills/cli-anything/SKILL.md这一步不是走形式。Skill 写得越清楚Agent 越不容易乱跑。你至少要看三件事它支持 build、refine、test、validate 哪些模式它要求生成什么目录结构它有没有强调 JSON 输出、REPL、测试、安装验证如果你的 OpenClaw 已经安装过这个 Skill也可以直接查看本机文件ls ~/.openclaw/skills/cli-anything/ cat ~/.openclaw/skills/cli-anything/SKILL.md这里别填错路径。OpenClaw 的 Skill 通常按目录分组存放目录名和 Skill 名最好保持一致后面唤起时更直观。4 用 cli-anything 把一个工具变成可调用 CLISkill 装好后在 OpenClaw 里可以按实际唤起方式调用。不同 OpenClaw 版本、不同聊天入口的唤起格式会有差异下面写法按cli-anything这个语义示例来理解实际使用时以你当前 OpenClaw 的 Skill 调用方式为准。假设你有一个本地工具项目放在./demo-tool可以让 OpenClaw 走 build 流程cli-anything build a CLI for ./demo-tool如果项目在 GitHub 上也可以让它先围绕仓库做分析cli-anything build a CLI for https://github.com/example/demo-tool跑完第一版后不要直接把结果当成生产工具。更稳的做法是先让它补齐高频场景cli-anything refine ./demo-tool 补充批量导入、状态查询和 JSON 输出能力再做验证cli-anything validate ./demo-tool如果生成的是 Python CLI harness常见的本地验证会落到这几类命令# 进入生成的 harness 目录按实际目录名调整 cd demo-tool/agent-harness # 本地可编辑安装 pip install -e . # 查看命令帮助 cli-anything-demo-tool --help # 跑测试 pytest这里建议先挑 12 个小工具练手不要一上来就选一个巨大的商业软件。范围越小Agent 越容易把命令边界、输出格式和测试写清楚后面再 refine比一口吃成胖子靠谱得多。5 一个更像真实工作的场景让 Agent 调本地 Web 工具很多团队的工具并不是公开 SaaS而是跑在本地、NAS、公司内网或开发机里本地测试 API127.0.0.1:8080NAS 管理面板内部 Webhook 接收器自研低代码后台临时数据处理 Web 服务人在同一个网络里访问没问题但远程 Agent、云端回调、外部协作者访问不到。这时就会出现一个尴尬局面工具已经有了Agent 也能编排任务中间差一个安全可控的入口。cpolar 适合放在这个位置它不是替 Agent 做决策而是把本地 HTTP 服务映射成公网可访问地址。比如你的本地工具 Web 服务监听在 8080 端口可以开一个 HTTP 隧道cpolar http 8080如果是 macOS 新环境cpolar 官方文档给出的 Homebrew 安装方式是brew tap probezy/core brew install cpolarLinux 或树莓派这类支持 systemd 的环境可以使用官方一键安装脚本curl -L https://www.cpolar.com/static/downloads/install-release-cpolar.sh | sudo bash安装后先确认本地控制台能打开再去做映射cpolar version curl -s http://127.0.0.1:9200 || echo 服务未启动映射成功后cpolar 会给出公网访问地址。你可以把这个地址填进 OpenClaw Skill 的配置、环境变量或者让 Agent 在工作流里调用它的 API。这里有个安全边界要提前说清楚不要把数据库、管理后台、无鉴权 API 长期裸露到公网。更推荐的方式是只映射必要的 Web 服务端口给工具本身加账号、Token 或访问控制临时测试用随机地址长期使用再考虑固定地址面向 Agent 的接口只开放最小能力不给删除、重置、批量导出这类高风险操作如果你只是让 Agent 调一个本地测试 APIcpolar http 8080已经够用。要是要给团队长期用再去配置固定二级子域名和更完整的访问控制。6 把 Skill、CLI 和内网入口串起来到这里链路就比较清楚了用 CLI-Anything 的方法把工具能力整理成 CLI harness用 OpenClaw Skill 告诉 Agent 什么时候调用、怎么调用、怎么验证如果工具或 Web 服务在内网用 cpolar 给它一个可控入口Agent 拿到结构化输出后继续执行下一步举个具体例子。你有一个本地“报告生成器”跑在 8080 端口接口是/api/report。你可以先用 cpolar 暴露它cpolar http 8080再把得到的公网地址写到环境变量里export REPORT_SERVICE_URLhttps://你的-cpolar-公网地址然后在 CLI harness 里读取这个变量对外提供一个命令report-cli generate --project ./demo --jsonAgent 看到--json输出就能继续判断报告是否生成成功、文件在哪里、下一步要不要上传或通知。这里的关键不是命令多酷而是每一步都有证据命令可执行输出可解析失败能定位。如果结果不对优先查这三处本地服务是否真的在127.0.0.1:8080监听cpolar 在线隧道列表里公网地址是否对应 8080CLI harness 调用的环境变量是否写成了最新地址这类排错顺序很重要。别一上来就改 Agent 提示词很多时候只是端口没开、地址过期、Token 没带。7 写 Skill 时别忽略这几个细节OpenClaw Skill 不是越长越好关键是让 Agent 少猜。我建议 Skill 里至少写清楚四件事。第一触发场景。比如“当用户要求为本地工具生成 Agent 可调用 CLI、补充 JSON 输出、验证 harness 时使用”。这能减少 Agent 把普通脚本任务误判成 CLI-Anything 构建任务。第二输入范围。支持本地路径还是 GitHub URL路径不存在怎么办目标软件需要先安装吗这些都要写明白。第三输出结构。生成哪些目录、哪些文件、命令入口叫什么、测试文档放哪里。CLI-Anything 的 OpenClaw Skill 里就强调了agent-harness目录、setup.py、命名空间包、README、tests 等结构。第四验证命令。至少要有pip install -e .、--help、pytest这类落地检查。Agent 写完代码不跑验证等于只完成了一半。还有一个血泪提醒不要让 Skill 默认拥有过大的写权限。能在项目目录里生成 harness就不要让它扫整个用户目录能只读配置就不要给删除权限。Agent 工具化越强边界越要写清楚。8 总结Agent 真正好用从“会聊”走向“会调用”这篇做完以后我们得到的不是一个万能 Agent而是一条更稳的工具化路径把常用软件或本地服务整理成 CLI/API再用 OpenClaw Skill 告诉 Agent 怎么发现、调用和验证它。关键步骤可以压缩成三件事用 CLI-Anything 的思路给工具做 CLI harness优先保证命令清晰、输出稳定、支持 JSON。用 OpenClaw Skill 描述触发条件、输入输出、目录结构和验证命令让 Agent 少猜、少乱跑。本地 Web 工具需要远程调用时用 cpolar 映射必要端口比如cpolar http 8080同时做好鉴权和最小暴露。我更推荐把这套方案从小工具开始试先让 Agent 调一个转换器、报告生成器、内部查询 API跑通 build、refine、validate再逐步扩展到更复杂的软件。工具化做得越扎实Agent 才越像一个能进工作流的队友而不是只会给建议的聊天窗口。
