# Agent Work Evaluator

> 评审 Agent 软件、Agent 框架或混合型作品，先由用户确认作品类型和成熟参照物，再通过源码、测试、运行结果与作品材料建立证据链，按统一量表给出可复核评分。适用于比赛评审、技术尽调、开源项目打分和 Agent 产品横向比较；不适用于只要功能介绍而不需要评分的请求。

- Skill: `lstm-kirigaya/agent-work-evaluator` (Agent Skill, multi-file: 6 files)
- Install (CLI): `npx skillmds@latest add lstm-kirigaya/agent-work-evaluator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lstm-kirigaya/agent-work-evaluator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: lstm-kirigaya (https://skillmd.com/u/lstm-kirigaya)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lstm-kirigaya/agent-work-evaluator

---


# Agent 作品评审

目标是产出一份用户认可比较口径、且每个分数都能回溯到源码或作品证据的评审。不要把知名度当成熟度，不要自行替用户决定“成熟产品”，也不要把 README 声明当成实现事实。

## 必须遵守的原则

1. **先分类，后比较。** 区分开箱即用的 Agent 软件、Agent 框架/Harness、混合型作品。不同类型使用不同的实现证据。
2. **参照物由用户最终决定。** 可以推荐候选，但必须说明为什么候选、掌握了哪些真实性证据及哪些仍不确定，并等待用户确认、替换或删减。
3. **评分必须有证据。** 每项分数至少引用一条源码证据；有可运行软件或 Demo 时，还要引用运行或作品证据。无法取得时明确写“未验证”，并降低置信度。
4. **声明与事实分开。** README、PPT、视频和 UI 文案是“声称”；源码路径、测试、构建结果、运行轨迹和可追溯产物是“证据”。
5. **同类相比。** 软件重点比较任务完成、用户体验和运行稳定性；框架重点比较运行语义、扩展接口和工程质量；混合型要分别验证上层产品与底层框架，并确认二者确实相连。
6. **缺证不补想象。** 不因为仓库名字、明星项目标签、Star 数或作者背景推断实现成熟。

## 工作流

### 1. 明确评审范围

从用户请求和材料中整理：

- 待评作品及仓库、Demo、附件、文档；
- 评审目的与输出形式；
- 用户关注的品味或偏好，例如本地优先、轻量、可黑客化、企业治理、UI 完整度；
- 是否允许克隆、构建、运行和网络访问；
- 是否沿用默认五项权重。

缺少的信息只有在会实质改变结论时才询问。

### 2. 作品类型确认门

在深入比较前，给出有依据的初步分类，并请用户确认：

- **开箱即用 Agent 软件**：用户安装或登录后直接完成任务；
- **Agent 框架/Harness**：开发者用它构建 Agent，核心价值是 Runtime、工具、状态、上下文、扩展接口；
- **混合型**：同时提交可用产品和可复用框架。

说明分类会如何影响评审重点。用户已明确分类时不要重复追问，但仍记录该选择。

### 3. 成熟参照物确认门

如果用户尚未指定参照物：

1. 只做足以推荐候选的轻量调查；
2. 提出 2–4 个同类型候选；
3. 对每个候选说明：类型、与作品的可比点、成熟度证据、已知限制、与用户偏好的匹配度；
4. 明确请用户选择、替换、删减，或提出自己的参照物；
5. **用户确认前，不进入正式横向比较和最终评分。**

如果用户已指定参照物，仍需确认它是唯一基准还是候选之一。若真实性不足，展示证据并建议替代项，但决定权归用户。不要用“行业公认”绕过确认。

### 4. 建立声明清单与证据台账

对待评作品和最终确认的参照物分别执行：

1. 固定评审版本：记录仓库 URL、分支、commit、评审日期；
2. 从 README、官网、作品附件和 Demo 提取核心声明；
3. 绘制源码地图：入口、Agent Loop、工具、模型、任务、子 Agent、Skill、状态、存储、安全、可观测、部署和测试；
4. 对每项声明定位实现路径、关键符号、测试和运行路径；
5. 在安全且获授权时构建或运行最小闭环，记录命令、结果和限制；
6. 检查 Demo/视频/部署是否能追溯到提交仓库和具体版本；
7. 记录反证：占位实现、固定返回成功、吞异常、不可达分支、缺失模块、伪测试或演示与源码脱节。

详细格式见 [references/evidence-protocol.md](references/evidence-protocol.md)。

### 5. 源码优先核验

每个核心能力至少回答：

- 入口在哪里？
- 谁维护状态？
- 成功和失败如何判定？
- 失败是否传播、重试、回滚或暂停？
- 有哪些边界和权限？
- 有什么自动化测试或可复现运行证明？
- 该能力是作品自身实现、依赖上游实现，还是只调用外部未提交服务？

依赖成熟上游并不扣分，但必须清楚标注作品自己的增量价值。调用无法审计的外部服务不能当作已提交源码的实现证据。

### 6. 按双轨量表评分

默认使用以下五项：

| 维度 | 权重 |
|---|---:|
| 场景价值与行业可复制性 | 25% |
| Agent 协同与自主闭环能力 | 25% |
| Skill 工程体系与生态复用 | 25% |
| 工程落地、运行验证与安全可审计 | 20% |
| 开放与开源贡献 | 5% |

读取 [references/rubric.md](references/rubric.md)，按已确认作品类型选用软件轨、框架轨或混合轨。每项分数必须列出支持证据、反证、未验证项和置信度，并遵守证据不足时的分数上限。

### 7. 最终定分前的用户校准门

先展示“证据版初评分”，不要直接宣告最终分数。明确分成：

- **客观事实**：源码、构建、测试、运行和仓库数据；
- **专业判断**：对架构、质量、风险和成熟度的解释；
- **偏好判断**：参照物选择、轻量与完整的取舍、创新与稳健的权衡。

邀请用户调整偏好判断、参照物或权重。用户可以改变价值取向，但不要因此篡改客观事实。记录所有用户调整，并同时保留：

- 原始证据分；
- 用户校准后的最终分；
- 调整理由。

如果用户明确要求一次性出分，可以同时给“证据基线分”和“等待用户校准项”，无需阻塞。

### 8. 产出报告

按 [references/report-template.md](references/report-template.md) 输出。最少包括：

- 类型与参照物确认结果；
- 版本和材料范围；
- 成熟参照物真实性与适配性说明；
- 声明核验矩阵；
- 五项评分及证据 ID；
- 原始分、用户校准和加权总分；
- 可直接粘贴到评审表的分项理由和总体评语；
- 无法验证的内容与提高置信度所需材料。

## 停止条件

以下情况不要编造结论：

- 私有仓库、附件或 Demo 无法访问；
- 用户尚未确认会显著改变结论的作品类型或参照物；
- 关键实现全部位于未提交、无法审计的外部服务；
- 构建需要高风险权限、昂贵资源或会修改外部系统。

此时报告已确认事实、缺口和所需输入，不以“看起来合理”填补证据。