今天在 CSDN 看到一篇 OpenClaw 相关的新文章，标题是《Python脚本到OpenClaw技能：解锁Agent原生能力的转换指南》。这个选题和本站方向挺贴近：很多人手里都有一堆 Python 小脚本，但脚本能跑，不代表 Agent 就能稳定调用。
原文地址：https://blog.csdn.net/xy520521/article/details/160961830
我不准备复述原文。这里更想把它当成一个提醒：如果你想把旧脚本接进 Agent 工作流，别急着把代码塞进去，先把脚本的“使用边界”写明白。
脚本能跑，不等于适合 Agent 调用
人手动运行脚本时，会天然补很多上下文。
比如你知道哪个参数可以省略，知道失败时该删缓存重跑，也知道某个路径不能带中文。Agent 不知道这些。它只会根据技能名、description、参数说明和当前任务去猜。
所以 Python 脚本改成 OpenClaw 技能时，最先整理的不是代码，而是这些东西：
- 这个脚本到底解决什么问题
- 输入参数有哪些，哪些必填，哪些可选
- 输出是什么，是文件、文本、JSON，还是外部副作用
- 失败时常见原因是什么
- 哪些情况不应该调用它
这些写不清楚，Agent 就算调用成功，也可能是在错误场景里成功运行了一次。
技能说明比目录结构更重要
OpenClaw 官方文档里能看到，它本身是面向“能实际做事”的个人 AI 助手，工具、插件、ClawHub、模型和网关都是它的能力来源。
官方站点：https://openclaw.ai/
官方文档：https://docs.openclaw.ai/
从实际使用角度看，技能说明文件的质量会直接影响调用质量。一个模糊的技能描述，比如“处理文件”或者“运行脚本”，对 Agent 帮助很小。更好的写法应该接近这样：
当用户需要把某个目录下的 Markdown 文件批量提取标题、日期和链接时，使用这个技能。不要用它处理二进制文件、图片或需要登录的网站。这句话不复杂，但它给了模型三个判断点：什么时候用、处理什么、不处理什么。
老脚本改造时，我会先看四件事
第一，看输入是不是稳定。
如果脚本依赖当前目录、临时文件、环境变量或者本机浏览器登录态，就要写进说明里。否则 Agent 在另一个工作目录运行，很容易失败。
第二，看输出是不是机器可读。
给人看的日志不适合直接给 Agent 接着用。能返回 JSON 就返回 JSON，至少也要让最后几行输出有固定格式。
第三，看副作用能不能控制。
会删文件、发请求、提交代码、推送仓库的脚本，要把风险写清楚。最好默认 dry-run，确认后再执行真实操作。
第四，看失败信息是否有用。
“运行失败”没什么价值。告诉 Agent 是缺依赖、没权限、网络超时，还是目标网页结构变了，后续才有机会自动修。
不是所有脚本都值得技能化
有些脚本本来就只跑一次，或者需要人肉判断很多东西，硬改成技能反而更麻烦。
适合技能化的脚本通常有几个特征：
- 经常重复用
- 输入输出比较固定
- 失败原因能枚举
- 不依赖复杂人工判断
- 可以在小范围内验证结果
比如批量整理 Markdown frontmatter、检查死链、生成站点索引、同步固定目录，这些都适合。反过来，涉及账号风控、验证码、版权资源下载、付款动作的脚本，就不应该轻易交给 Agent 自动跑。
这篇 CSDN 文章给我的实际价值
它不是一篇可以照着一步一步执行的完整教程，更像一个选题提醒：Agent 原生能力不是把旧脚本包一层壳就结束了。
真正要做的是把脚本从“人知道怎么用”改成“模型知道什么时候该用、怎么用、用完怎么判断结果”。
如果后面继续写这个主题，我更想做一篇实测文：拿一个本站正在用的 Python 小脚本，改成可调用技能，记录 SKILL.md 怎么写、脚本放哪里、验证命令怎么跑，以及 Agent 在什么提示下会真的调用它。
这比单纯讨论概念更有用。