最近我做了一个产品agent，准确来讲是产品调研agent，同时为它做了一个新的 Skill。
它的作用很简单：
专门让我的产品 Agent 去监控 Google Play 上的应用，看看哪些产品虽然下载量很高，但评分不太好，用户差评很多，从而挖掘出一些真实存在的用户痛点和产品机会。
产品agent 是基于 Hermes Agent 搭建的。
我现在主要用 Hermes Agent 来搭建自己的 Agent，以及给 Agent 配套各种 Skill。
正好借这个例子，聊一下：
Skill 到底是什么？
很多人一听到 Agent、Skill、Workflow、cron 容易觉得很复杂，其实换成大白话就很好理解。
我把它总结成一句话：cron 是闹钟或定时器，agent 是干活的人，skill 是工作说明书，以前我让产品 Agent 每天做 Google Play 产品调研，通常会把一大堆规则都写在临时提示词里。
要去哪里找产品？
要找什么类型的产品？
下载量要达到多少？
评分要低于多少？
哪些类别不能碰？
最终报告要写到哪里？
完成之后要不要通过微信通知我？
这些规则如果每次都写在 cron 任务里，或者散落在不同脚本、提示词和配置文件里，时间一长就很容易乱。
你今天改了下载量规则，明天改了产品类别，后天又加了一个通知方式。
最后 Agent 到底按哪套规则执行，自己都不一定说得清楚。
索性我就把这些固定规则打包成了一个 Skill，Skill 就像一本固定的说明书，改下说明书，产品agent每次干活读一下说明书就可以干活了
我更愿意把 Skill 理解成：写给 Agent 的一份正式工作手册。
不是临时交代一句话，也不是一次性的提示词，而是一套可以长期复用、反复执行、不断修改的标准流程。
以我这个产品 Agent 为例。
每天凌晨，系统里会有一个定时任务自动触发，这个定时任务就像一个闹钟。
时间到了，它就把产品 Agent 叫醒，Agent 被叫醒之后，不是凭感觉干活，也不是重新问我要怎么做，而是先读取这个 Skill。
读取完以后，它就知道今天仍然按照这套规则来做 Google Play 产品调研。
只看 Google Play 上的普通消费级应用；
下载量或安装量要大于等于 150 万；
评分要低于 3.5；
只看最近 2 年发布或更新过的产品；
排除 VPN、安全、代理、密码、隐私规避等敏感类别；
最多整理 100 款产品；
最后总结出 Top 10 个有开发潜力的产品方向。
这些规则，就是写在 Skill 里的工作说明。
Agent 按 Skill 干活，有了 Skill 之后，产品 Agent 的工作就变得非常清晰。
它会按照 Skill 的要求去找产品、看评分、看下载量、筛选类别、整理差评、归纳用户痛点，然后分析哪些方向可能存在新的产品机会。
比如一款应用下载量很高，但评分长期偏低。这说明什么？
说明用户需求是真实存在的。
因为下载量高，代表市场有需求。
但评分低，代表现有产品没有把用户服务好。
这种产品，往往就值得重点研究。
用户为什么不满意？
是功能不好用？
是广告太多？
是收费太贵？
是体验太复杂？
还是某个核心场景没有被满足？
这些内容，Agent 都可以按照 Skill 里的规则进行拆解。
最终，它不是简单地丢给我一堆应用列表，而是会进一步整理成产品机会分析，
今天发现了多少款符合条件的应用；
哪些类别的问题最多；
用户差评主要集中在哪里；
Top 10 的潜在产品方向是什么；
Top 3 最值得优先研究的机会是什么。
Skill 还规定结果写到哪里
一个真正好用的 Skill，不只是告诉 Agent “做什么”，还要告诉它“结果怎么交付”。
比如我这个产品调研 Skill，就会要求 Agent 把结果写入 dashboard 对应的数据文件：
C:\Users\lin\Desktop\codex\xiaozhi-dashboard\data\agent-reports\product-agent.json
同时，它还会生成每天的调研文档，放到固定目录里：
C:\Users\lin\Desktop\codex\xiaozhi-dashboard\data\product-research-docs\日期\
这样做的好处是：
每天的结果都有结构化数据；
历史调研文档可以长期沉淀；
dashboard 可以直接读取最新结果；
后面要复盘、筛选、对比，也都有依据。
最后，Agent 还会通过微信通知我今天的执行结果。
今天一共找到了多少款符合条件的产品；
Top 3 产品机会分别是什么；
有没有执行失败；
有没有卡在某个步骤；
是否需要我人工介入。
这样一来，整个流程就完整了，不是 Agent 做完了就结束，而是从触发、执行、分析、存档、通知，形成了一条完整链路。
为什么 Skill 很重要？
我觉得 Skill 最大的价值，不是让 Agent 变得“更聪明”，而是让 Agent 变得“更稳定”。很多时候，我们并不缺一次性的 AI 能力，我们真正缺的是：让 AI 按固定规则长期执行任务的能力。
临时提示词适合一次性沟通，但如果你想让 Agent 每天、每周、每月都稳定做同一类事情，就不能完全依赖临时提示词，因为临时提示词太容易变形。
今天说得详细一点，结果就好一点，明天少说了一个条件，Agent 就可能跑偏，后天换了一个任务入口，输出格式又变了，而 Skill 的意义，就是把这些容易变形的东西固定下来，它让 Agent 知道：
我的角色是什么；
我要完成什么任务；
我应该遵守哪些规则；
我不能碰哪些边界；
我应该按什么流程执行；
我最后应该输出什么结果；
如果失败了应该怎么处理。
这就像给一个员工写了一份 SOP，只要 SOP 清楚，员工就不需要每次都重新问老板，以后改规则，也不用重做 Agent，Skill 还有一个很大的好处：
规则可以单独修改，不需要重做整个 Agent。
比如以后我想调整这个产品调研规则，我可以说：
下载量改成 300 万以上；
评分改成 4 分以下；
只看图片类工具产品；
增加小红书、公众号适合传播的产品机会分析；
把 Top 10 改成 Top 20；
增加竞品商业模式分析；
增加广告变现和订阅变现判断。
这些改动，本质上不是重新设计一个 Agent，而是修改这本“工作手册”，Skill 改完之后，产品 Agent 下次执行任务时，就会自动按照新的规则来工作。
这也是我觉得 Skill 很适合个人开发者、产品经理、运营人员使用的原因。
你不一定要一开始就做一个特别复杂的 Agent 系统。
你可以先从一个具体场景开始。
每天监控 Google Play 产品机会；
每天整理公众号选题；
每天分析竞品评论；
每天总结行业热点；
每天生成短视频脚本；
每天复盘广告投放数据。
只要这个任务是重复发生的，就适合沉淀成 Skill。
最后再总结一下，用最简单的话来说：
Agent 是干活的人。
Cron 是叫醒它的闹钟。
Skill 是告诉它怎么干活的工作说明书。
没有 Skill，Agent 很容易变成一个每次都要重新沟通的临时工。
有了 Skill，Agent 才更像一个可以长期协作的数字员工。
我这次做的 Google Play 产品监控 Skill，本质上就是一份：
“产品 Agent 每天如何研究 Google Play 产品机会”的固定 SOP。
它让 Agent 每天按照固定规则去发现产品、分析差评、挖掘痛点、总结机会，并把结果写入 dashboard，同时通过微信通知我。
这就是我理解的 Skill，大家觉得理解上有没有分歧，可以互相交流一下
它不是一个抽象概念，而是让 Agent 真正开始稳定干活的关键。