这个提示词用来做什么

agent 装了一堆技能与工具，上游 API 或依赖悄悄变了，能力在无人察觉的情况下退化。为每个能力定义探活方式与告警条件，定期自动检查，避免能力悄悄退化。列出已装的技能与依赖即可，可指定检查频率。

提示词全文

请帮我给一批已经装到 agent 上的技能 / 插件做一次「失效检查」设计，目标是：上游一变就能发现，而不是等用户报错。不要写通用运维原则，要针对我列的清单逐条给出具体检查项。

## 输入
清单：{逐个列出技能或工具：它做什么、依赖哪些外部 API 或服务、依赖的模型或版本、最近一次被用到是什么时候}
已有信号：{现在能观测到什么——调用成功率、报错日志、用户反馈、有没有自动回归}
调用频率：{哪些是每天用、哪些是偶尔用}
失效的代价：{静默出错会怎样，会不会把错的结果放进正式产出}

## 输出
1）依赖地图：把每个技能的外部依赖摊平——外部 API、模型版本、文件格式、权限或凭证。标出哪些是「上游可以单方面改」的。
2）逐条检查设计：对每个技能给出一个最小检查（一次真实或半真实的调用、断言什么、期望输出长什么样），以及建议的检查频率（按调用频率而不是统一每天）。
3）静默失效清单：点名最可能「不报错但结果变错」的地方，并为每处给一条断言（例如结果字段齐全、引用编号可解析、输出能通过 Schema 校验）。
4）下架规则：定义什么条件下这个技能应该被自动禁用并通知负责人，而不是继续带着错误运行。
5）排序：按「失效代价 ÷ 检查成本」排序，给出先做哪三个。

怎么用

  1. 把上面的提示词全文复制到对话窗口或工作流里。
  2. 把花括号占位符（如 {任务描述}）替换成你自己的内容。
  3. 条目越具体，产出越稳定；不需要的条目可以直接删掉。

输出示例

典型输出会先标出某个抓取类技能的依赖是「上游网页结构」，属于典型的能单方面变更；检查设计会写成每天一次、用固定查询断言返回条数大于 0 且字段齐全；静默失效清单里会指出「摘要类技能即使上游挂了，也可能一本正经地输出空泛内容」——对应的断言是「输出必须包含至少两个可回溯到原文的引用」；下架规则会写成连续两次检查失败即自动禁用。

基本信息

  • 分类：运维
  • 标签：Skill 治理 · 失效检查 · 回归测试 · 依赖变更
  • 收录日期：2026-09-30

同类提示词