agent-self-evaluation

用途

Agent Self-Evaluation 是一个智能体在完成复杂任务后启用的自我评估技能。它的目的不是通过/失败的门禁，而是一个刻意的反思步骤，帮助智能体在用户发现问题之前，捕捉遗漏、标记过度自信，并暴露需要改进的地方。

何时启用

根据资料，以下情况会触发该技能：

编写跨越 3 个以上文件或 50 行以上的代码后
完成多步骤工作流（实现 → 测试 → 审查）后
经历 3 次以上尝试的调试会话后
产出设计文档、架构决策或书面分析后
用户询问“刚才做得怎么样？”或“给自己打个分”时
在任何会话的 Stop 钩子结束时（如果已配置，参见 references/hook-integration.md）

核心概念：五个评估轴

该技能围绕五个维度对输出进行独立评分：

评估轴	提出的问题	能捕捉的问题
准确性	事实、主张和输出是否正确？	幻觉、错误的 API 名称、错误的语法、虚假陈述
完整性	是否覆盖了用户要求的一切？	遗漏的边界情况、未处理的错误路径、被遗忘的需求、跳过的子任务
清晰度	解释是否易懂且结构良好？	令人困惑的解释、未定义的行话、缺失的上下文、冗长散乱
可操作性	用户能否立即对输出采取行动？	模糊的建议、缺失的步骤、只说“你应该 X”却不展示怎么做、没有验证路径
简洁性	是否只用了所需的最少词语/token？	冗余、过度解释、逐字重复用户的问题、填充内容

评分标准

5 — 卓越：没有合理可改进的空间
4 — 良好：只有小瑕疵，没有实质性缺口
3 — 合格：满足请求，但至少在某个评估轴上有明显弱点
2 — 薄弱：存在影响可用性或正确性的明显缺口
1 — 差：从根本上未满足请求，或包含重大错误

证据规则

每个低于 5 的评分都必须引用具体证据。3 分不能只说“还可以更好”——它必须准确说明缺失或错误之处。原则是：“展示缺口，而不仅仅是命名它。”

工作流

第一步：收集原始素材

收集将要评估的内容：

原始用户请求（从对话中回顾）
最终响应/输出（交付物）
任何验证正确性的工具输出（测试结果、退出码、lint 输出）
任务期间收到的任何用户反馈（更正、“再试一次”、“这不对”）

第二步：独立为每个评估轴打分

逐一处理五个评估轴。对每一个：

阅读该评估轴的问题
在输出中寻找证据（或缺乏证据）
分配 1-5 分的评分
如果评分低于 5，写一句引用缺口的改进说明

不要先在脑中算出平均分然后再反向推导。要新鲜地为每个评估轴打分。

第三步：产出评估报告

使用 templates/evaluation-report.md 中的模板。报告必须包含：

一句话摘要
五轴评分卡（每个评估轴的评分 + 证据）
总体评分（简单平均值，四舍五入到一位小数）
1-3 项按影响排序的具体改进
自检：“用户会同意这个评估吗？”

第四步：应用改进

如果有任何评估轴得分在 3 或以下：

说明你会如何不同地去做
如果缺口能在 30 秒内修复（缺失链接、措辞不清），现在就修复
如果缺口需要返工，明确标记：“该评估轴得分为 [原因]，因为 [证据]。以 [具体修复] 重新运行可能会将其提升到 [分数]。”

代码示例

示例：良好评估（4 分以上）

任务：为 HTTP 客户端添加重试逻辑

评分卡：

准确性:     5 — 所有 API 调用正确。已验证：重试使用
                指数退避。没有幻觉的方法。
完整性:     4 — 覆盖了正常路径 + 3 个错误情况。缺失：
                对挂起连接的超时处理。
清晰度:     5 — 代码注释解释了退避公式。
                PR 描述链接到促使此工作的故障事件。
可操作性:   5 — 单次合并。无后续任务。测试通过。
简洁性:     4 — 共 47 行。重试循环可以提取
                到一个辅助函数中，减少约 8 行。

总体：4.6 — 一个缺口（超时处理）。合并前修复。

示例：薄弱评估（2-3 分）

任务：为 HTTP 客户端添加重试逻辑

评分卡：

准确性:     2 — 使用了 urllib3，与我们基于 httpx 的
                代码库不匹配。错误的库。
完整性:     3 — 对 GET 有效。未处理 POST/PUT（用户
                说的是“所有 HTTP 请求”）。
清晰度:     4 — 代码可读。变量名良好。
可操作性:   2 — 提到了“添加测试”但没有创建测试文件。
                用户必须在合并前编写测试。
简洁性:     3 — 120 行。重试配置在 3 个地方
                重复，而不是一个共享的 RetryConfig 对象。

总体：2.8 — 使用了错误的库。需要 httpx 重写。
先修复准确性（切换到 httpx），然后扩展到所有
HTTP 方法，然后合并配置。

反模式

“一切都是 5 分”

失败示例：没有引用任何证据。这是自我恭维，不是评估。真正的 5 分需要证明没有可改进之处。

因范围蔓延而过度扣分

失败示例：只应根据用户实际请求的内容来评估，而不是你本可以额外构建的内容。

利用评估重新争论

失败示例：评估是关于已交付的输出，而不是重新争论已经做出的设计决策。如果方法有误，那应该在交付前就被发现。

将个人偏好与客观缺口混为一谈

失败示例：“不喜欢”不是证据。引用具体的可读性、可测试性或正确性问题，否则将评分保持在 4 分以上。

最佳实践

评估输出，而不是过程。用户关心的是你交付了什么，而不是你迭代了多少次。
每个薄弱评估轴一个改进项。不要为一个评估轴列出 5 件事——挑选影响最大的缺口。
将改进与用户影响挂钩。“缺失错误处理意味着用户的 API 调用会静默崩溃”比“添加错误处理”更好。
具体说明“修复”是什么样子。“以配置了重试的 httpx 传输重新运行”比“修复库问题”更好。
使用工具输出作为证据。如果测试通过，引用它们。如果 lint 干净，引用它。不要猜测——用 grep 寻找证据。
如果找不到任何缺口，再努力找找。在所有 5 个评估轴上拿到满分是罕见的。问：“如果我是用户，这个输出中什么会让我烦恼？”

限制

资料未提供该技能对具体平台、模型或编程语言的依赖说明，也未说明其收费、价格或商业条款。使用方式（安装命令、配置文件路径等）在所提供的资料中暂未提供。

技能介绍

用途