夜雨聆风很多 Agent 技能看起来都很朴素。
一个目录，一个 SKILL.md，几段说明，一些步骤，最多再配几个参考文件。
从外观上看，它很像普通 Markdown 文档。
但在 Agent Runtime 里，Markdown 技能不是普通说明文档。
它会影响 Agent 怎么理解任务、怎么调用工具、怎么判断完成、怎么处理异常，甚至怎么处理权限边界。
同一句用户请求，在有没有技能的情况下，Agent 的理解可能完全不同。
比如用户说：“做一个公众号预览。”
没有技能时，Agent 可能理解成写一篇文章、生成一段排版建议，或者给出操作步骤。
有技能时，它会知道这是一条完整业务链路。
1. 读取正文。
2. 生成富文本。
3. 制作封面。
4. 打开公众号后台。
5. 设置标题、作者、摘要、原创声明和 AI 来源。
6. 保存草稿并推送预览。
7. 记录状态，明确不发表、不群发。
这时，技能改变了任务边界。
它让一句简单指令，映射到一套稳定流程。
Agent 的能力来自模型，也来自工具。
一个现代 Agent 可能能读文件、写文件、搜索网页、调用浏览器、生成图片、执行命令、发送消息、操作 Office 文档。
问题是：什么时候该用什么工具？
这不是模型自然就能稳定判断的。
✅ 处理本地代码时，优先用 rg 搜索。
✅ 修改文件时，使用受控编辑方式。
✅ 处理 Office 文档时，优先用专用工具读回校验。
✅ 制作公众号预览时，必须进入后台，不只生成 HTML。
✅ 发送图片到微信时，默认按文件附件，而不是普通图片预览。
这些规则不是内容创作规则。
它们是工具编排规则。
普通说明文档往往告诉人“应该怎么做”。
但技能还要告诉 Agent“做到什么程度才算完成”。
这非常关键。
用户要公众号预览：不是写完正文，而是后台保存草稿并推送预览。
用户要归档文件：不是整理完目录，而是进入正式归档路径并更新台账。
用户要检查合同：不是列出风险点，而是完成字段核对、版本保存和交付确认。
如果技能不写完成标准，Agent 的“完成”只是它自己的理解，不一定是业务闭环。
更容易被忽视的是权限。
一个 Markdown 技能如果写着“可以读取项目目录下所有文件”“可以自动修改配置”“可以自动发送给用户”，这些话本身不是代码，但会影响 Agent 的行为。
如果运行时没有更硬的权限系统，技能里的文字规则就可能成为事实上的授权。
⚠️ 自动读取敏感文件。
⚠️ 自动外发数据。
⚠️ 自动修改配置。
⚠️ 自动跳过原本应该确认的高风险动作。
这就是技能危险的地方。
它看起来只是说明，实际可能改变 Agent 对“能不能做”的判断。
Agent 不只是短期执行工具。
在长期协作中，它还会积累记忆、规则、偏好和流程。
什么内容要写入记忆。
什么内容不要写入长期记忆。
什么材料属于临时文件。
什么材料必须归档。
什么操作要记录到状态文件。
这些都涉及长期资产管理。
如果技能乱写，长期记忆会变脏；如果技能过度自动化，临时产物可能混进正式资产目录；如果技能缺少完成判定，业务状态会混乱。
判断一个技能是不是好技能，不应只看它文字是否漂亮。
更应该看它有没有回答几个问题。
它在什么场景触发？
它允许 Agent 做什么？
它禁止 Agent 做什么？
它要求 Agent 用哪些工具？
它如何判断完成？
它如何处理失败？
它如何保护敏感数据？
它如何留下审计记录？
如果这些问题没有答案，那它只是文档。
如果这些问题有清晰答案，它才开始成为技能。
技能可以从 Markdown 开始。
这是合理的。
因为 Markdown 易读、易写、易审查，也适合普通用户参与。
但不能因为它是 Markdown，就低估它的影响。
未来企业管理 Agent 技能时，不能只问：这份文档写得好不好？
更应该问：它会让 Agent 做什么？它会让 Agent 自动做什么？它会让 Agent 以为什么事情已经被授权？
这才是技能时代真正需要理解的变化。
