agent-work-evaluator

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

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。

5. 源码优先核验

每个核心能力至少回答：

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

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

6. 按双轨量表评分

默认使用以下五项：

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

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

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

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

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

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

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

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

8. 产出报告

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

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

停止条件

以下情况不要编造结论：

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

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