| name | agent-work-evaluator |
| description | 评审 Agent 软件、Agent 框架或混合型作品，先由用户确认作品类型和成熟参照物，再通过源码、测试、运行结果与作品材料建立证据链，按统一量表给出可复核评分。适用于比赛评审、技术尽调、开源项目打分和 Agent 产品横向比较；不适用于只要功能介绍而不需要评分的请求。 |
Agent 作品评审
目标是产出一份用户认可比较口径、且每个分数都能回溯到源码或作品证据的评审。不要把知名度当成熟度，不要自行替用户决定“成熟产品”，也不要把 README 声明当成实现事实。
必须遵守的原则
- 先分类，后比较。 区分开箱即用的 Agent 软件、Agent 框架/Harness、混合型作品。不同类型使用不同的实现证据。
- 参照物由用户最终决定。 可以推荐候选，但必须说明为什么候选、掌握了哪些真实性证据及哪些仍不确定，并等待用户确认、替换或删减。
- 评分必须有证据。 每项分数至少引用一条源码证据；有可运行软件或 Demo 时，还要引用运行或作品证据。无法取得时明确写“未验证”，并降低置信度。
- 声明与事实分开。 README、PPT、视频和 UI 文案是“声称”；源码路径、测试、构建结果、运行轨迹和可追溯产物是“证据”。
- 同类相比。 软件重点比较任务完成、用户体验和运行稳定性；框架重点比较运行语义、扩展接口和工程质量；混合型要分别验证上层产品与底层框架，并确认二者确实相连。
- 缺证不补想象。 不因为仓库名字、明星项目标签、Star 数或作者背景推断实现成熟。
工作流
1. 明确评审范围
从用户请求和材料中整理：
- 待评作品及仓库、Demo、附件、文档；
- 评审目的与输出形式；
- 用户关注的品味或偏好，例如本地优先、轻量、可黑客化、企业治理、UI 完整度；
- 是否允许克隆、构建、运行和网络访问；
- 是否沿用默认五项权重。
缺少的信息只有在会实质改变结论时才询问。
2. 作品类型确认门
在深入比较前，给出有依据的初步分类，并请用户确认：
- 开箱即用 Agent 软件：用户安装或登录后直接完成任务；
- Agent 框架/Harness：开发者用它构建 Agent，核心价值是 Runtime、工具、状态、上下文、扩展接口；
- 混合型：同时提交可用产品和可复用框架。
说明分类会如何影响评审重点。用户已明确分类时不要重复追问，但仍记录该选择。
3. 成熟参照物确认门
如果用户尚未指定参照物：
- 只做足以推荐候选的轻量调查；
- 提出 2–4 个同类型候选；
- 对每个候选说明：类型、与作品的可比点、成熟度证据、已知限制、与用户偏好的匹配度；
- 明确请用户选择、替换、删减，或提出自己的参照物；
- 用户确认前，不进入正式横向比较和最终评分。
如果用户已指定参照物，仍需确认它是唯一基准还是候选之一。若真实性不足，展示证据并建议替代项，但决定权归用户。不要用“行业公认”绕过确认。
4. 建立声明清单与证据台账
对待评作品和最终确认的参照物分别执行：
- 固定评审版本：记录仓库 URL、分支、commit、评审日期；
- 从 README、官网、作品附件和 Demo 提取核心声明；
- 绘制源码地图：入口、Agent Loop、工具、模型、任务、子 Agent、Skill、状态、存储、安全、可观测、部署和测试；
- 对每项声明定位实现路径、关键符号、测试和运行路径；
- 在安全且获授权时构建或运行最小闭环，记录命令、结果和限制；
- 检查 Demo/视频/部署是否能追溯到提交仓库和具体版本；
- 记录反证：占位实现、固定返回成功、吞异常、不可达分支、缺失模块、伪测试或演示与源码脱节。
详细格式见 references/evidence-protocol.md。
5. 源码优先核验
每个核心能力至少回答：
- 入口在哪里？
- 谁维护状态？
- 成功和失败如何判定？
- 失败是否传播、重试、回滚或暂停？
- 有哪些边界和权限？
- 有什么自动化测试或可复现运行证明？
- 该能力是作品自身实现、依赖上游实现，还是只调用外部未提交服务？
依赖成熟上游并不扣分，但必须清楚标注作品自己的增量价值。调用无法审计的外部服务不能当作已提交源码的实现证据。
6. 按双轨量表评分
默认使用以下五项：
| 维度 | 权重 |
|---|
| 场景价值与行业可复制性 | 25% |
| Agent 协同与自主闭环能力 | 25% |
| Skill 工程体系与生态复用 | 25% |
| 工程落地、运行验证与安全可审计 | 20% |
| 开放与开源贡献 | 5% |
读取 references/rubric.md，按已确认作品类型选用软件轨、框架轨或混合轨。每项分数必须列出支持证据、反证、未验证项和置信度，并遵守证据不足时的分数上限。
7. 最终定分前的用户校准门
先展示“证据版初评分”，不要直接宣告最终分数。明确分成：
- 客观事实：源码、构建、测试、运行和仓库数据；
- 专业判断：对架构、质量、风险和成熟度的解释；
- 偏好判断：参照物选择、轻量与完整的取舍、创新与稳健的权衡。
邀请用户调整偏好判断、参照物或权重。用户可以改变价值取向，但不要因此篡改客观事实。记录所有用户调整，并同时保留：
如果用户明确要求一次性出分，可以同时给“证据基线分”和“等待用户校准项”，无需阻塞。
8. 产出报告
按 references/report-template.md 输出。最少包括：
- 类型与参照物确认结果；
- 版本和材料范围；
- 成熟参照物真实性与适配性说明；
- 声明核验矩阵；
- 五项评分及证据 ID；
- 原始分、用户校准和加权总分；
- 可直接粘贴到评审表的分项理由和总体评语；
- 无法验证的内容与提高置信度所需材料。
停止条件
以下情况不要编造结论：
- 私有仓库、附件或 Demo 无法访问；
- 用户尚未确认会显著改变结论的作品类型或参照物；
- 关键实现全部位于未提交、无法审计的外部服务；
- 构建需要高风险权限、昂贵资源或会修改外部系统。
此时报告已确认事实、缺口和所需输入，不以“看起来合理”填补证据。
