Agent 项目里的 Eval 到底是什么？怎么分类？不同项目应该怎么评测？

省流

最近看了几类资料：牛客里讲的 Agentic RAG 评测体系、OLMO eval 里讲的模型研发评测框架，以及 SWE-bench、Terminal-Bench、AgentBench、Ragas、DeepEval、τ-bench 等评测思路。它们都叫 eval，但其实不是一个层级的东西。

我自己的理解是：

eval 不是某一个具体 benchmark，而是“如何证明一个模型、RAG、Agent 或应用真的有效”的系统方法。

一、先区分三个概念：eval、benchmark、评测体系

1. eval 是什么？

eval 是 evaluation 的简称，本质是“评估”。

它测的不是单一东西，而是：

一个被测对象，在一组任务上，是否按照预期完成目标。

被测对象可以是：

• 一个大模型；

• 一个 RAG 系统；

• 一个 Coding Agent；

• 一个长篇创作 Agent；

• 一个完整应用；

• 一个工具调用框架；

• 一个上下文管理策略；

• 一个记忆系统；

• 一个安全策略。

所以 eval 不是只看“模型聪不聪明”，而是看系统在真实任务中是否可靠。

2. benchmark 是什么？

benchmark 是 eval 里常见的一种形式，可以理解为：

固定题库 + 固定任务 + 固定评测协议。

比如：

• SWE-bench：评测 coding agent 修真实 GitHub issue 的能力；

• Terminal-Bench：评测 agent 在终端环境完成任务的能力；

• AgentBench：评测 LLM-as-Agent 在多个环境里的表现；

• τ-bench：评测带工具调用的多轮 agent 是否能遵守领域策略并完成任务。

benchmark 是 eval 的一部分，但 eval 不等于 benchmark。

3. 评测体系是什么？

评测体系比 benchmark 更大，它包含：

eval system
├── eval dataset / benchmark：评测数据集或题库
├── metrics：指标
├── runner / harness：运行器
├── judge / oracle：判分器
├── trace / logs：执行轨迹
├── report：评测报告
├── baseline comparison：基线对比
└── regression / CI：持续回归

所以，一个成熟项目不应该只说“我跑了某个 benchmark”，而应该说明：

• 测什么；

• 怎么测；

• 用什么数据测；

• 用什么指标判断；

• 和谁对比；

• 失败样本怎么分析；

• 改完以后是否能稳定复现提升。

二、牛客评测体系和 OLMO eval 是同一个东西吗？

不是完全同一个东西，但它们属于同一个 eval 大范畴。

1. 牛客那类评测体系：偏应用层 / Agentic RAG 项目评测

牛客文章里的评测思路更接近“项目落地评测”。

它关注的是：

• 意图识别是否正确；

• 检索是否召回了正确上下文；

• 工具是否调用正确；

• 参数是否正确；

• 生成答案是否忠实于证据；

• 是否产生幻觉；

• 多轮任务是否能完成；

• 成本和延迟是否可接受。

它适合用来评估一个 RAG / Agent 应用系统，而不是单纯评模型。

2. OLMO eval：偏模型研发 / eval workbench

OLMO eval 更像一个模型研发中的评测工作台。

它关注的是：

• 不同模型 checkpoint 怎么比较；

• task、suite、harness 怎么解耦；

• 如何复现实验；

• 如何逐题分析两个模型的差异；

• 如何支持多种 benchmark；

• 如何把评测变成模型训练和迭代过程的一部分。

它更偏模型团队、研究团队和大规模评测框架。

3. 两者的区别

维度	牛客 Agentic RAG 评测	OLMO eval
评测对象	一个 RAG / Agent 应用	一个模型或模型 checkpoint
目标	证明项目效果和工程可用性	支持模型研发和 checkpoint 对比
关注点	检索、工具调用、生成质量、业务正确性	benchmark、harness、task suite、可复现
更适合谁	应用开发者、Agent 项目开发者	模型研发团队、评测框架开发者

三、对话中提到的 eval 可以怎么分类？

我会把 eval 分成 10 类。

---

1. Model Eval：模型能力评测

测什么？

测模型本身能力，例如：

• 数学能力；

• 代码能力；

• 常识问答；

• 推理能力；

• 指令跟随；

• 多轮对话；

• 工具调用倾向；

• 安全对齐。

典型形式

• MMLU；

• GSM8K；

• HumanEval；

• MBPP；

• Big-Bench；

• 各类模型排行榜。

适合什么项目？

适合模型研发，不太适合直接证明一个应用项目好不好。

因为一个模型在 benchmark 上强，不代表你的 Agent 项目就稳定。

---

2. Benchmark Eval：公开基准评测

测什么？

测系统在标准任务集上的表现。

典型例子

• SWE-bench：代码修复；

• Terminal-Bench：终端任务；

• AgentBench：多环境 agent 任务；

• τ-bench：多轮工具调用和领域策略；

• WebArena / MiniWoB：网页操作类任务；

• HumanEval：代码生成；

• RAG benchmark：知识问答检索类任务。

特点

优点：

• 有统一题目；

• 有可比较结果；

• 容易和其他系统对比。

缺点：

• 不一定贴合自己的业务；

• 有可能被模型“刷榜”；

• 对个人项目来说接入成本可能偏高。

结论

benchmark 是 eval 的一种，但不能完全替代自定义 eval。

---

3. RAG Eval：检索增强生成评测

测什么？

主要测 RAG 系统是否“找得到、用得对、答得准”。

核心问题：

• 检索是否召回了相关文档？

• 排名靠前的文档是否有用？

• 生成答案是否忠实于上下文？

• 答案有没有幻觉？

• 是否引用了正确证据？

• 没有答案时能否拒答？

常见指标

检索侧：

• Recall@K；

• Precision@K；

• MRR；

• nDCG；

• Hit@K；

• context recall；

• context precision。

生成侧：

• faithfulness；

• answer relevance；

• groundedness；

• hallucination rate；

• citation correctness。

典型工具

• Ragas；

• DeepEval；

• 自定义 LLM-as-Judge；

• 人工标注评测集。

适合什么项目？

适合知识库问答、文档问答、企业知识助手、搜索增强问答项目。

如果项目核心是“从资料里找答案”，就应该重点做 RAG eval。

---

4. Agent Eval：工具调用和任务执行评测

测什么？

Agent eval 不是只看最终回答，而是要看 agent 的行动过程。

核心问题：

• 是否应该调用工具？

• 是否选对工具？

• 工具参数是否正确？

• 工具调用顺序是否合理？

• 是否反复无效调用？

• 是否陷入死循环？

• 是否遵守预算？

• 是否能从工具失败中恢复？

• 最终任务是否完成？

常见指标

• task success rate；

• tool selection accuracy；

• tool argument accuracy；

• tool call count；

• max step violation；

• retry count；

• loop rate；

• budget exceeded rate；

• trajectory correctness；

• unsafe action blocked rate。

适合什么项目？

适合所有带工具调用的 Agent 项目，尤其是：

• coding agent；

• browser agent；

• data analysis agent；

• RAG agent；

• workflow agent；

• 自动化运维 agent。

只要项目有“观察 → 思考 → 调工具 → 再观察 → 再行动”的循环，就应该做 Agent eval。

---

5. Coding Agent Eval：代码任务评测

测什么？

测 agent 是否真的能完成代码任务，而不是只会生成代码片段。

核心问题：

• 能不能理解仓库结构？

• 能不能搜索相关代码？

• 能不能改正确文件？

• 能不能生成合理 patch？

• 能不能运行测试？

• 测试失败后能不能继续修？

• 能不能避免破坏无关文件？

• 能不能控制 shell 权限？

• 能不能输出清晰 trace？

典型参考

• SWE-bench；

• Terminal-Bench；

• Codex / Claude Code 的工作流；

• 自定义 repo fixture；

• regression harness。

常见指标

• task pass rate；

• test pass rate；

• patch correctness；

• changed files correctness；

• expected tool sequence match；

• unsafe shell blocked；

• average tool calls；

• average model calls；

• P95 runtime；

• budget exceeded rate。

适合什么项目？

适合 agent_study 这种 coding agent runtime / harness 项目。

对于 coding agent 来说，最重要的不是“模型说得对不对”，而是：

改完代码以后，测试能不能过，diff 是否正确，过程是否可追踪。

---

6. App Eval：应用端到端评测

测什么？

测完整应用从用户输入到最终输出的整体表现。

核心问题：

• 用户目标是否完成？

• 最终结果是否可用？

• 体验是否流畅？

• 出错时是否有合理提示？

• 多轮对话是否保持上下文？

• 是否符合业务规则？

常见指标

• end-to-end success rate；

• user satisfaction；

• completion rate；

• fallback rate；

• abandon rate；

• latency；

• cost；

• complaint rate。

适合什么项目？

适合已经有完整产品形态的项目。

比如：

• AI 写作平台；

• AI 客服；

• AI 编程助手；

• AI 数据分析助手；

• 自动生成小说的 Web 应用。

---

7. Safety Eval：安全与边界评测

测什么？

测系统是否会越权、泄露、破坏或执行危险行为。

核心问题：

• 是否会执行危险 shell？

• 是否会删除文件？

• 是否会越权读写路径？

• 是否会泄露 API key？

• 是否会暴露系统 prompt？

• 是否会被 prompt injection 诱导？

• 是否会绕过审批机制？

• 是否会误调用高风险工具？

常见指标

• unsafe action blocked rate；

• prompt injection success rate；

• secret leakage rate；

• path traversal blocked rate；

• destructive command blocked rate；

• approval bypass rate。

适合什么项目？

所有 Agent 项目都需要 safety eval。

尤其是 coding agent，因为 coding agent 通常能：

• 读本地文件；

• 写代码；

• 执行命令；

• 操作 git；

• 调用外部 API。

权限越大，越需要 safety eval。

---

8. Cost / Latency Eval：成本和性能评测

测什么？

测系统是否足够便宜、足够快、足够稳定。

核心问题：

• 一次任务平均消耗多少 token？

• 平均调用几次模型？

• 平均调用几次工具？

• P50 / P95 延迟多少？

• 成本是否可控？

• 是否因为上下文太长导致失败？

• 是否经常超时？

• 是否有并发瓶颈？

常见指标

• avg token usage；

• avg model calls；

• avg tool calls；

• P50 latency；

• P95 latency；

• timeout rate；

• cost per task；

• context length utilization；

• cache hit rate。

适合什么项目？

所有准备长期运行或上线的项目都需要。

对个人项目来说，成本评测也很重要，因为它能证明项目不是“跑一次可以，跑一批就崩”。

---

9. Domain-specific Eval：领域自定义评测

测什么？

测某个具体领域里最重要的能力。

例如写作 Agent 不能只看“回答是否正确”，它要看：

• 人物设定是否一致；

• 世界观是否一致；

• 伏笔是否延续；

• 时间线是否冲突；

• 风格是否稳定；

• 多章节记忆是否有效；

• 改写是否真的提升质量。

适合什么项目？

适合 flashnovel 这种长篇写作 / 小说生成 / 多章节创作 Agent。

这种项目无法直接套用 SWE-bench 或普通 RAG eval，需要自己定义领域指标。

常见指标

• continuity score；

• contradiction count；

• character consistency；

• plot thread recall；

• style consistency；

• chapter goal coverage；

• memory write correctness；

• rewrite improvement score。

---

10. Regression Eval：回归评测

测什么？

测系统修改后有没有退化。

核心问题：

• 新功能是否破坏旧功能？

• agent loop 是否还稳定？

• 工具调用是否还正确？

• 状态机是否还符合预期？

• 修改 memory / context 策略后效果是否下降？

• 修复一个 bug 是否引入另一个 bug？

常见形式

• eval cases；

• pytest；

• golden file；

• fixture repo；

• snapshot test；

• CI eval；

• nightly eval；

• before / after report。

适合什么项目？

所有持续迭代的 Agent 项目都需要。

Agent 项目特别容易“玄学变好”或“玄学变差”，所以 regression eval 非常重要。

---

四、Agent 项目没有 eval 的危害

很多 Agent 项目看起来能跑，但没有 eval 就会有几个严重问题。

1. 只能靠感觉判断效果

没有 eval 时，判断标准就变成：

• “这次好像回答得不错”；

• “这次 demo 跑通了”；

• “我感觉模型变强了”；

• “换 prompt 后好像更好了”。

这种判断非常不可靠。

Agent 项目尤其容易出现 demo illusion：单个样例看起来很强，但换几个任务就失败。

2. 无法证明改动真的提升了效果

比如你改了：

• prompt；

• 检索策略；

• memory 注入；

• tool schema；

• agent loop；

• 状态机；

• 预算策略；

• 失败重试策略。

如果没有 eval，就不知道这次修改到底是提升还是退化。

有时候一个改动会让某个 case 变好，但让其他 case 变差。

3. 无法定位失败原因

Agent 失败可能发生在多个层次：

• 意图识别错；

• 检索错；

• 上下文没选对；

• 工具没选对；

• 参数填错；

• 工具执行失败；

• 观察结果没理解；

• 最终回答幻觉；

• 状态机跳转错误；

• 预算耗尽；

• 进入死循环。

没有 eval 和 trace，就只能看到“最终失败”，但不知道为什么失败。

4. 无法比较不同方案

比如想比较：

• naive recent context vs structured memory；

• 单 agent vs 多 agent；

• ReAct loop vs Plan-Execute；

• 是否加 critic；

• 是否加 reflection；

• 不同模型；

• 不同 chunk 策略；

• 不同 rerank 策略。

没有统一 eval，就无法公平比较。

5. 很难写进简历和面试

如果项目没有 eval，面试官很容易问：

• 你怎么证明它有效？

• 成功率是多少？

• 和 baseline 比提升多少？

• 失败 case 有哪些？

• 工具调用准确率多少？

• 有没有回归测试？

• 有没有成本统计？

• 有没有安全边界？

如果回答不上来，项目会显得像 demo。

反过来，如果能讲清 eval，项目含金量会明显提升。

---

五、不同项目应该做哪些 eval？

1. 普通聊天机器人

应该评什么？

• 指令跟随；

• 回答相关性；

• 多轮上下文；

• 拒答边界；

• 幻觉率；

• 用户满意度。

不需要重点评什么？

如果没有工具调用，就不用重点评 tool trajectory。

---

2. 知识库问答 / RAG 项目

应该评什么？

• 检索召回；

• 排名质量；

• 上下文是否覆盖答案；

• 回答是否忠实；

• 引用是否正确；

• 无答案时是否拒答；

• 成本和延迟。

推荐指标

Recall@K
Precision@K
MRR
nDCG
Faithfulness
Answer Relevance
Citation Correctness
Hallucination Rate

推荐方法

构造一批 QA case：

{
  "question": "xxx",
  "expected_answer": "xxx",
  "golden_docs": ["doc1", "doc2"],
  "must_cite": ["doc1"],
  "should_refuse": false
}

然后分别评：

• 检索有没有找对文档；

• 回答有没有基于文档；

• 是否编造文档外内容。

---

3. Coding Agent 项目，比如 agent_study

项目特征

agent_study 的核心不是普通问答，而是本地 coding agent runtime：

理解任务
→ 搜索代码
→ 读取文件
→ 修改文件
→ 运行命令
→ 根据结果继续行动
→ 记录 trace
→ 受预算和权限约束

所以它应该重点做 Coding Agent Eval。

应该评什么？

第一层：工具层 eval

测工具本身是否可靠：

• file_read 是否限制路径；

• code_search 是否能搜到符号；

• replace_in_file 是否能精确替换；

• shell 是否能限制危险命令；

• file_write 是否需要审批；

• 参数 schema 是否校验。

第二层：轨迹层 eval

测 agent 是否按正确步骤执行：

• 是否先搜索再读文件；

• 是否读完再改；

• 是否改完运行测试；

• 是否根据测试失败继续修；

• 是否避免无意义重复调用；

• 是否遵守最大轮次；

• 是否正确进入 completed / failed / waiting_user。

第三层：任务完成 eval

测最终结果是否正确：

• 测试是否通过；

• diff 是否符合预期；

• 是否只修改必要文件；

• 是否没有破坏无关代码；

• 是否输出合理总结。

第四层：安全 eval

测是否守住边界：

• 是否拒绝删除项目；

• 是否拒绝读取敏感文件；

• 是否拒绝危险 shell；

• 是否不会绕过审批；

• 是否不会无授权写入。

可以设计哪些 eval case？

edit_single_file：修改单个文件
edit_multi_file：修改多个文件
fix_test_failure：修复失败测试
add_unit_test：新增单元测试
find_symbol：定位函数或类
explain_code：解释代码结构
replace_config：修改配置
resume_pending_action：恢复等待审批的写入
forbid_unsafe_shell：拒绝危险命令
delegate_subtask：委派子任务并合并结果

一个 eval case 可以长这样

{
  "id": "fix_001",
  "type": "coding_agent",
  "prompt": "修复 add 函数在负数输入下的错误，并运行测试",
  "fixture_repo": "fixtures/simple_math",
  "verify_command": "python -m pytest -q",
  "expected_changed_files": ["src/math_utils.py"],
  "must_use_tools": ["code_search", "file_read", "replace_in_file", "shell"],
  "must_not_tools": ["file_write"],
  "max_tool_calls": 8,
  "expected_terminal_state": "completed"
}

推荐指标

task_pass_rate
test_pass_rate
expected_changed_files_match
tool_selection_accuracy
tool_argument_accuracy
unsafe_action_blocked_rate
avg_tool_calls
avg_model_calls
budget_exceeded_rate
trace_complete_rate

最重要的结论

对于 agent_study，不要只说“它能调用工具”，而要证明：

它在固定代码任务集上，能稳定搜索、修改、验证、恢复，并且每次修改后都有 trace 和可回归结果。

---

4. 长篇写作 Agent，比如 flashnovel

项目特征

flashnovel 不是 coding agent，也不是普通 RAG。它的核心是长篇内容生产：

设定输入
→ 章节规划
→ 上下文选择
→ 草稿生成
→ 记忆抽取
→ 连续性检查
→ 改写
→ checkpoint
→ 继续下一章

所以它应该重点做 Domain-specific Eval。

应该评什么？

第一层：上下文选择 eval

测 Context Builder 是否选对上下文：

• 是否保留关键人物设定；

• 是否保留世界观规则；

• 是否保留伏笔；

• 是否保留最近章节；

• 是否控制 token budget；

• 是否没有塞入无关内容。

第二层：连续性 eval

测长篇内容是否前后一致：

• 人物性格是否漂移；

• 人物关系是否冲突；

• 时间线是否错乱；

• 世界观规则是否破坏；

• 前文伏笔是否遗忘；

• 事件因果是否断裂。

第三层：章节目标覆盖 eval

测生成章节是否完成目标：

• 本章剧情目标是否完成；

• 用户指定元素是否出现；

• 情绪节奏是否符合要求；

• 冲突是否推进；

• 结尾是否承接下一章。

第四层：记忆系统 eval

测记忆是否真的有用：

• 生成后是否抽取了重要新事实；

• 是否写入结构化记忆；

• 后续章节是否能使用这些记忆；

• 是否产生错误记忆；

• 是否保留已经失效的信息。

第五层：rewrite eval

测改写是否真的提升：

• 是否修复矛盾；

• 是否增强细节；

• 是否保持风格；

• 是否没有引入新 bug；

• 是否更符合章节目标。

第六层：checkpoint / resume eval

测长流程是否可控：

• 每 5 章是否正确 checkpoint；

• 用户确认后是否继续；

• 中断后是否能恢复；

• 恢复后上下文是否正确。

推荐指标

硬指标：

run_success_rate
artifact_exists_rate
event_complete_rate
checkpoint_success_rate
resume_success_rate
token_budget_pass_rate
memory_write_rate

软指标：

chapter_goal_coverage
continuity_score
contradiction_count
character_consistency
plot_thread_recall
style_consistency
rewrite_improvement_score

一个 eval case 可以长这样

{
  "id": "novel_001",
  "type": "long_form_writing",
  "story_setting": "赛博朋克城市中的失忆侦探",
  "target_chapter": 6,
  "prior_facts": [
    "主角害怕雨声",
    "女主真实身份是企业间谍",
    "第 3 章埋下了蓝色芯片伏笔"
  ],
  "chapter_goal": [
    "主角发现芯片线索",
    "不能揭露女主身份",
    "延续雨声恐惧设定"
  ],
  "must_cover": [
    "蓝色芯片",
    "雨声恐惧"
  ],
  "must_not_violate": [
    "女主身份不能暴露",
    "主角不能突然恢复全部记忆"
  ]
}

最重要的结论

对于 flashnovel，不要用普通 QA eval 来评。

它真正要证明的是：

系统能在长篇生成中保持人物、剧情、伏笔、记忆和章节目标的一致性。

---

六、如何从 0 到 1 给 Agent 项目做 eval？

第一步：明确项目类型

先问自己：

我的项目是知识问答？
还是工具调用？
还是代码执行？
还是写作生成？
还是完整应用？

项目类型不同，eval 完全不同。

第二步：定义任务集

不要一开始追求大而全，可以先做 20 个 case。

每个 case 至少包含：

id
input / prompt
初始环境
期望行为
期望结果
判分方式
最大预算
是否应该拒绝

第三步：设计 baseline

没有 baseline，提升就无从谈起。

常见 baseline：

• 不使用 RAG；

• 只用最近上下文；

• 不使用 structured memory；

• 不使用 rerank；

• 不使用 agent loop；

• 单次回答；

• 不使用工具；

• 旧版本系统。

例如 flashnovel 可以比较：

naive_recent_text
structured_memory_only
flashnovel_full

例如 agent_study 可以比较：

chat_only
read_only_agent
edit_without_test
full_coding_agent

第四步：分 hard metrics 和 soft metrics

hard metrics

硬指标是可程序判断的：

• 测试是否通过；

• 文件是否存在；

• diff 是否匹配；

• 是否超时；

• 是否触发 checkpoint；

• 是否调用了指定工具；

• 是否拒绝危险命令。

优点是稳定、可复现。

soft metrics

软指标需要人工或 LLM judge：

• 回答是否自然；

• 小说是否连贯；

• 风格是否一致；

• 解释是否清晰；

• 改写是否更好；

• 是否满足复杂目标。

软指标更贴近体验，但容易不稳定，所以要有清晰 rubric。

第五步：记录 trace

Agent 项目必须记录 trace。

因为只看最终结果不够，还要看过程：

用户输入
模型输出
工具调用
工具参数
工具结果
状态变化
预算消耗
错误信息
最终答案

没有 trace，就无法分析失败原因。

第六步：输出报告

一个基本 eval report 至少包含：

eval version
dataset version
model config
agent config
task count
pass rate
failed cases
avg tool calls
avg model calls
avg cost
avg latency
failure categories
baseline comparison

第七步：接入回归

当项目每次改 prompt、tool、memory、状态机时，都跑一遍核心 eval。

目标不是一次性写报告，而是持续回答：

这次修改有没有让系统变得更稳定？

---

七、可以形成一套通用分类表

Eval 类型	主要对象	主要问题	典型指标
Model Eval	模型	模型本身强不强	accuracy、pass@k
Benchmark Eval	模型或系统	标准任务上表现如何	score、rank、pass rate
RAG Eval	检索 + 生成	找得对不对，答得准不准	Recall@K、faithfulness
Agent Eval	工具调用 Agent	工具选得对不对，任务完成了吗	task success、tool accuracy
Coding Agent Eval	编程 Agent	是否能改代码并跑通测试	test pass、patch correctness
App Eval	完整应用	用户目标是否完成	completion rate、satisfaction
Safety Eval	安全边界	是否越权或危险操作	unsafe blocked rate
Cost Eval	工程效率	是否够快够便宜	latency、cost、token
Domain Eval	特定领域项目	是否满足领域目标	自定义指标
Regression Eval	持续迭代系统	改动后是否退化	before / after delta

---

八、最终总结

eval 不是一个固定工具，也不是某个 benchmark。

更准确地说：

eval 是一套证明系统可靠性的工程方法。

benchmark 是 eval 的一种形式；评测体系则包括数据集、指标、运行器、判分器、trace、报告和回归流程。

对于 Agent 项目来说，eval 特别重要，因为 Agent 的失败不是单点失败，而是链路失败。它可能在检索、上下文选择、工具调用、参数生成、状态跳转、预算控制、安全边界、最终回答中的任何一步出错。

如果没有 eval，Agent 项目就只能停留在 demo 阶段。

不同项目应该做不同 eval：

知识库问答项目：重点做 RAG eval
coding agent 项目：重点做工具轨迹 + 测试通过率 + patch correctness
长篇写作项目：重点做连续性 + 记忆 + 上下文选择 + 章节目标覆盖
完整应用项目：重点做端到端成功率 + 用户体验 + 成本延迟
高权限 Agent：必须做 safety eval
持续迭代项目：必须做 regression eval

对于我的项目来说：

• agent_study 应该重点做 Coding Agent Eval，包括任务通过率、工具调用轨迹、测试通过率、diff 正确性、安全拒绝率和 trace 完整性。

• flashnovel 应该重点做 Domain-specific Eval，包括上下文选择、连续性、人物一致性、伏笔延续、章节目标覆盖、记忆写入和 checkpoint/resume。

一句话概括：

没有 eval 的 Agent 项目，只能证明“它跑起来了”；有 eval 的 Agent 项目，才能证明“它稳定、可复现、可比较、可优化”。