2026年7月23日agno 发布了 v2.8.0 最新版本。这次更新的重点非常集中主要围绕三个方向展开评分与评测能力增强环境隔离与批量回放能力增强工具执行、判分安全性与可靠性进一步收紧从更新内容来看v2.8.0 不只是新增了几个功能点而是对评测链路、环境运行机制、工具执行验证方式以及判分提示词防护做了成体系的升级。尤其是agno.scorer、agno.environments、Case.scorer、run_rollouts(env, k8)、以及对ReliabilityEval和AgentAsJudgeEval的调整都是这次版本中非常值得关注的核心变化。一、版本信息版本v2.8.0状态Latest发布时间2026年7月23日本次更新内容主要分为三部分New FeaturesBug FixesBreaking Changes此外还有一组 “What’s Changed” 明细进一步列出了具体变更项。二、New Features新功能全量解析1. agno.scorer把一次运行结果转成一个分数这次更新新增了agno.scorer它的定位非常清晰把一次 run 转换成一个数字。这个能力的意义在于过去很多评测更多关注“是否通过”而agno.scorer让结果可以进一步数值化。这样一来评估不仅可以看成败也可以看分值、区间、比较结果以及更细粒度的质量差异。agno.scorer中包含三类 scorerCodeScorerJudgeScorerToolCallScorer并且所有 scorer 都同时提供 sync 和 async 版本。这意味着无论是同步链路还是异步链路都可以统一使用这套评分能力。1.1 CodeScorerCodeScorer的作用是包装任意可调用对象作为评分器。它支持的返回值类型包括boolfloatScore这让它的适用范围非常灵活。如果你的评分逻辑已经存在为一个普通函数那么现在可以直接用CodeScorer包装起来接入到 agno 的评分体系中。更新说明中特别指出推荐在output_schema下做 typed-field comparison也就是说在输出结构明确的情况下建议基于类型化字段来做比较这样会更稳定也更适合结构化评测。这一点虽然只是简短的一句说明但在新评分体系里非常关键。因为结构化输出与 typed-field comparison 结合之后评分逻辑会更清晰也更容易复用。1.2 JudgeScorerJudgeScorer是一个LLM judge 评分器。它有两个非常明确的特点使用的模型必须始终是一个显式选择数值判定会被标准化到精确端点公式为((score - 1) / 9)这两个点都很重要。第一模型必须显式指定。这意味着在使用 JudgeScorer 时不再是模糊依赖默认模型而是明确地选择具体模型这能减少判分链路中的不确定性。第二数值 verdict 会被归一化。更新内容里给出了明确公式((score - 1) / 9)这表示 JudgeScorer 的评分输出不是随意浮动的而是会映射到一个标准化数值区间中。对后续统计、比较、聚合结果来说这一点非常关键。1.3 ToolCallScorerToolCallScorer用于确定性地检查工具执行情况。这里的核心变化是它对工具调用结果的判断标准更严格而且是基于真正的执行情况而不是仅仅基于消息中“请求了工具调用”。更新说明写得非常明确refused 的调用不满足 expectationerrored 的调用不满足 expectationHITL-rejected 的调用不满足 expectation也就是说只有真正成功、干净的工具执行才可能满足预期。这和本次 Breaking Changes 中对ReliabilityEval的调整是完全一致的说明 v2.8.0 在“工具执行是否算完成”这件事上整体标准已经统一收紧。1.4 所有 scorer 都提供 sync 和 async 版本这是一个容易被忽略但实际很重要的点。更新里明确说All scorers ship sync and async variants也就是说CodeScorer有同步和异步版本JudgeScorer有同步和异步版本ToolCallScorer也有同步和异步版本这保证了在不同执行模式下开发者都可以用同一套思路组织评分逻辑而不需要额外写兼容层。2. agno.environmentsEnvironment、Task 与 run_rollouts(env, k8)本次更新的另一个绝对重点是agno.environments。它引入了EnvironmentTaskrun_rollouts(env, k8)从功能描述来看这是一套围绕环境隔离、任务回放、多次运行统计和数据导出的完整能力。其中最核心的是run_rollouts(env, k8)它的作用是对环境中的每个 task 运行 K 次默认k8但更重要的不是“运行 8 次”而是它的全隔离机制。2.1 run_rollouts(env, k8)每个任务运行 K 次并且完全隔离更新说明中明确写到run_rollouts(env, k8)会让每个任务在完全隔离的条件下运行 K 次。这个“完全隔离”包括以下内容fresh dbfresh sessionfresh userno memory writesno knowledge writesno learning writescache off也就是说每一次 attempt 都是在新的数据库、新的会话、新的用户上下文下完成的同时不会写入 memory不会写入 knowledge不会写入 learning关闭 cache这意味着每次 rollout attempt 都不会受到前一次 attempt 的污染。这个设计对于评测和稳定性测试非常关键因为它能避免“上一次运行残留状态影响本次结果”的问题。2.2 knowledge 读取仍然可用虽然写入都被关闭了但更新里特别说明knowledge reads still work这意味着在 rollout 过程中knowledge 不允许写入但 knowledge 仍然允许读取这是一个很有边界感的设计。它保持了运行环境的“只读知识访问能力”同时又确保测试过程本身不会把额外状态写回系统。2.3 live per-attempt grid实时逐次尝试网格agno.environments还提供了a live per-attempt grid也就是实时展示每次尝试的网格视图。从更新描述来看它是面向 rollout 过程中的可视化观察能力。你可以看到每次 attempt 的运行情况而不是只拿到最终汇总结果。2.4 real pass rate per task每个任务的真实通过率更新中还提到real pass rate per task也就是每个任务的真实通过率。因为run_rollouts(env, k8)会让每个任务独立跑 K 次所以每个 task 不再只是“过了还是没过”而是可以得到一个更真实的通过率表现。这个能力和 “This is the passk door” 是直接对应的。换句话说v2.8.0 正式把多次独立运行后的通过率统计能力引入到了环境评测体系中。2.5 drift-vs-policy fingerprints更新说明还包含drift-vs-policy fingerprints这是agno.environments的组成能力之一。从描述上看它用于对比漂移与策略之间的指纹信息。官方并没有在这段更新内容里展开更多定义因此这里按原意保留。重要的是v2.8.0 已经将它作为环境能力的一部分加入进来。2.6 save、load、diffagno.environments还支持saveloaddiff也就是说这套环境机制不仅能运行还能保存加载对比差异这让环境回放和结果分析更完整不再只是一次性运行。2.7 learning_zone()本次更新还加入了learning_zone()它被列在agno.environments这一组能力中说明它也是环境侧新增的重要接口之一。2.8 to_sft_jsonl(…)导出通过样本为 conversational-SFT JSONL这是这次环境能力中非常亮眼的一项。更新说明写得很完整to_sft_jsonl(...)将 passing attempts 导出为 conversational-SFT JSONL同时带有一个 provenance sidecar也就是说成功通过的尝试可以被导出成会话式 SFT 格式 JSONL 数据并且还附带provenance sidecar这个导出能力让 rollout 的结果不只是用于评估也能用于后续数据整理与样本沉淀。更新中明确指出This is the passk door也就是说环境回放、多次尝试、通过率统计和通过样本导出这几项能力组合在一起构成了面向 passk 的入口。3. Case.scorer评测套件新增第三种检查方式更新说明提到Case.scorerthe eval suite gains a third check这意味着在 eval suite 中现在新增了第三种检查机制。它的使用方式是把任意 scorer 插入到一个Case中并配合Case.expected而且它具备以下特点freeexactno LLM call这里的含义非常直接这种检查方式不需要额外的 LLM 调用可以做精确判断代价更低这一点和agno.scorer的出现是相互呼应的。因为有了 scorerCase就不仅能做原来的检查还能挂接一个独立、明确、无需 LLM 的评分或判定过程。3.1 SuiteResult.to_dict() 新增字段与Case.scorer配套更新中还提到SuiteResult.to_dict()gains additivescore_valuescore_passedscore_reasonkeys也就是说评测结果在字典化输出时会新增以下字段score_valuescore_passedscore_reason这是一个很实用的补充因为它让 scorer 的结果能被标准化带出方便做后续处理、展示和分析。4. FileGenerationTools新增代码文件生成能力本次更新还提到FileGenerationToolsAdded code file generation for FileGenerationTools也就是说FileGenerationTools新增了代码文件生成能力。更新内容没有展开更多细节但这个新增点已经明确列在 New Features 中是本次版本功能增强的一部分。5. Gmail Tools新增分页与 max_results_per_request更新说明写到Gmail ToolsAdded pagination and max_results_per_request也就是说Gmail Tools 新增了两个能力分页max_results_per_request这意味着在请求 Gmail 数据时可以进行分页处理同时还能控制每次请求的最大结果数。这是一个非常明确、面向工具使用体验的增强。6. Adanos Tools新增可选的市场情绪工具这次更新还包括Adanos ToolsAdded optional Adanos market sentiment tools也就是说Adanos Tools 现在新增了可选的市场情绪工具。需要注意两个关键词optionalmarket sentiment tools说明这部分不是强制接入而是可选能力增强。三、Bug Fixes问题修复项除了新增功能v2.8.0 还修复了几个比较明确的问题。1. RemoteAgent / RemoteTeam修复 A2A 协议路径中 metadata 丢失问题更新内容写到RemoteAgent / RemoteTeamFixed metadata being dropped on the A2A protocol path也就是说之前在 A2A protocol path 上RemoteAgent和RemoteTeam存在 metadata 被丢弃的问题。v2.8.0 对这个问题进行了修复。这个修复项也在后面的 “What’s Changed” 明细中再次出现说明它是一次明确的功能性修复。2. Content空 content list 时 get_content_string() 返回空字符串更新说明写到ContentReturn empty string for empty content list inget_content_string()也就是说当 content list 为空时get_content_string()现在会返回空字符串。这属于边界行为修正。之前的处理方式没有在这里展开但现在 v2.8.0 明确规定了空列表对应空字符串返回值。3. Decision log替换已弃用的 datetime.utcnow()更新内容写到Decision logReplaced deprecateddatetime.utcnow()in thedecision_logstore也就是说在decision_logstore 中已将废弃的datetime.utcnow()替换掉。这是一个典型的兼容性与维护性修复。四、Breaking Changes破坏性变更详解本次更新最值得认真看的部分之一就是 Breaking Changes。因为这些变更会直接影响升级后的评测结果、工具匹配结果以及 judge verdict 的稳定性表现。1. ReliabilityEval 匹配工具执行方式变更更新说明写到ReliabilityEval matches tool executions它的核心变化是Tool expectations 现在只会被 clean execution 满足匹配依据是RunOutput.tools同时要求tool_call_error未设置不再按照 message-side requests 来满足 expectation这句话的含义非常关键以前只要消息侧发起了工具请求就可能被当成满足 expectation。但现在不是这样了。在 v2.8.0 中工具 expectation 是否满足必须看是否真的有工具执行记录该执行是否是 clean executiontool_call_error是否未设置只有这样才算满足 expectation。1.1 升级后 verdict 可能从绿变红更新说明明确提醒Verdicts can flip red after upgrading也就是说升级到 v2.8.0 后一些之前通过的评测可能会变成失败。原因也被写得很直白when they do, the eval was previously passing for the wrong reason也就是之前之所以通过是因为通过的理由本身并不正确这不是新版本把正确结果判错了而是旧逻辑可能把“请求了工具”误当成“正确执行了工具”。1.2 缺失条目会带注释更新内容还说明如果出现这种情况缺失项会被标注为... (requested but refused/errored — execution matching, new in 2.8.0)这段文案意味着新版本会明确告诉你工具虽然被请求了但它被拒绝了或者执行报错了因此在 2.8.0 的执行匹配规则下不再算满足 expectation这个提示语本身就是对新旧行为差异的直接说明。1.3 参数检查位置变更更新还提到Argument checks moved toToolExecution.tool_argswith the same partial-match semantics也就是说参数检查现在移动到了ToolExecution.tool_args同时仍然保留相同的 partial-match 语义这意味着检查的位置变了但匹配方式没有变因此升级时关注点主要在“参数检查入口变化”而不是参数匹配规则变化。2. Hardened judge promptAgentAsJudgeEval 判分提示词加固本次 Breaking Changes 的另一项重点是 judge prompt 的加固。更新说明写到EveryAgentAsJudgeEvalnow fences judged output behind a per-call random noncewith the untrusted-data instruction inside the prompt也就是说现在每一次AgentAsJudgeEval调用都会把被判定的输出放在一个带随机 nonce 的边界中并且在提示词内部加入“这是不可信数据”的指令。这是一次非常明确的判分安全加固。2.1 文字注入不再轻易影响判分提示词边界更新内容进一步说明A literal/outputno longer escapes the block也就是说即便被评判的内容里真的出现了字面量的/output它也不能再逃逸出这个输出块。这代表 judge prompt 在结构边界上的防护更强了。2.2 judged answer 中的“score this 10”只是数据不是指令更新说明继续写到score this 10inside a judged answer is data, not an instruction这句话非常重要。它表示如果被评估的回答中出现类似“score this 10”这样的内容新版本会把它当成被评判数据的一部分而不会把它误识别成对 judge 的操作指令这也是 prompt hardening 的直接体现。2.3 judge verdicts 和 token counts 可能变化由于 judge prompt 结构被加固更新里明确提醒Judge verdicts and token counts may shift也就是说升级到 v2.8.0 后judge 的打分结果可能发生变化token 统计也可能发生变化这是由于提示词结构、边界防护和判定上下文发生调整所带来的自然结果。五、What’s Changed变更明细逐条汇总下面把 “What’s Changed” 中列出的条目做一次完整梳理确保不遗漏。1. 修复 decision_log store 中已弃用的 datetime.utcnow()这一项对应前面的 Bug Fixes替换decision_logstore 中已弃用的datetime.utcnow()2. cookbook新增 dpo_jury pairwise preference 示例更新中加入了一个 cookbook 相关条目add dpo_jury pairwise preference example这是 cookbook 内容扩展的一部分。3. cookbook针对 agno 2.7.x 刷新 data_labeling更新中还包括refresh data_labeling for agno 2.7.x说明 cookbook 中的数据标注相关内容做了刷新。4. cookbook新增 jury calibration、hardening 和 agreement metrics更新说明包含jury calibrationhardeningagreement metrics这些都属于 cookbook 侧的内容扩展。5. cookbook新增 synthetic data generation workflows这次还加入了synthetic data generation workflows也是 cookbook 相关能力说明的一部分。6. cookbook新增 critique-revision、persona 和 tool-call trajectory generation更新中还列出critique-revisionpersonatool-call trajectory generation这些内容也都属于 cookbook 的扩展项。7. cookbook新增 step-reward scoring、scale-out mechanics 和 safety labelingWhat’s Changed 里还包括step-reward scoringscale-out mechanicssafety labeling依旧是 cookbook 内容增强的一部分。8. cookbookimage_search README 说明 ingest 是 full rebuild不是 idempotent更新说明中有一条非常具体image_search READMEingest is a full rebuildnot idempotent也就是说相关 README 里明确说明ingest 是完整重建不是幂等操作9. 修复 RemoteAgent / RemoteTeam 在 A2A protocol path 丢失 metadata这一项和前面的 Bug Fixes 对应RemoteAgent / RemoteTeam 在 A2A 协议路径中丢失 metadata 的问题已修复10. Gmail tools新增 pagination 和 max_results_per_request对应前面 New Features 中的 Gmail Tools 增强新增分页新增max_results_per_request11. 修复 get_content_string() 在空 content list 时返回空字符串对应前面的 Content 修复项空内容列表时返回空字符串12. Adanos新增可选 market sentiment tools对应前面的 New FeaturesAdanos 新增可选市场情绪工具13. Adanos澄清 trending rankingWhat’s Changed 中还有一项Clarify Adanos trending ranking也就是说Adanos 的 trending ranking 被进一步澄清说明。14. 修复 Groq 上 retired qwen/qwen3-32b 的替换更新中还有一项模型替换相关内容replace retired qwen/qwen3-32b with openai/gpt-oss-20b on Groq也就是说在 Groq 上已将退役的qwen/qwen3-32b替换为openai/gpt-oss-20b。这是一项明确的适配修复。15. FileGenerationTools新增代码文件生成对应前面已经提到的 New FeaturesFileGenerationTools新增 code file generation16. agno.scorer 与 judge prompt fenceWhat’s Changed 中有一项总结式条目agno.scorer and the judge prompt fence它对应的是本次版本最核心的两组升级新的 scorer 体系judge prompt 的边界加固17. rollout engine 与 Case.scorer seamWhat’s Changed 还写到rollout engine andCase.scorerseam这对应的就是agno.environmentsrun_rollouts(env, k8)Case.scorer这几项能力在评测与回放链路中的衔接。18. release: v2.8.0这是版本发布条目本身release: v2.8.019. cookbook将 environments 扩展到 progressive verification suite最后还有一项 cookbook 变更expand environments into progressive verification suite说明 environments 相关内容在 cookbook 中也有进一步扩展。20. Release v2.8.0What’s Changed 中还有一次版本发布条目Release v2.8.0六、这次 v2.8.0 更新的核心脉络总结如果把这次所有更新串起来看v2.8.0 的主线其实非常清楚主要集中在以下几条1. 评分能力从“是否通过”走向“数值化表达”agno.scorer的引入意味着 run 的结果可以被转化为boolfloatScore标准化数值 verdict同时还能接入到Case.scorer中让评测套件具备第三种检查方式并通过SuiteResult.to_dict()输出score_valuescore_passedscore_reason这让评测不再只是二元结果而是可以做更细粒度的表达。2. 环境评测从“单次运行”走向“隔离回放与 passk”agno.environments与run_rollouts(env, k8)的引入带来了完整的多次独立回放机制每个 task 跑 K 次每次都 fresh db、fresh session、fresh user不写 memory、knowledge、learningcache offknowledge reads still work再配合live per-attempt gridreal pass rate per taskdrift-vs-policy fingerprintssave / load / difflearning_zone()to_sft_jsonl(...)这套能力已经完整打开了 passk 评测与通过样本导出的入口。3. 工具执行验证从“请求过”升级到“真正执行成功”不管是ToolCallScorer还是ReliabilityEval的 breaking changes都在表达同一个原则工具 expectation 不能只看有没有发出请求必须看工具是否 clean executionrefused、errored、HITL-rejected 都不算满足 expectation同时参数检查位置也移动到了ToolExecution.tool_args但仍然保留 partial-match 语义。这说明 v2.8.0 明显更强调“真实执行结果”。4. judge prompt 更严格判分链路更抗注入AgentAsJudgeEval的 judge prompt 加固体现为每次调用使用随机 nonce把 judged output 明确围起来在 prompt 中加入 untrusted-data instruction字面量/output不再逃逸judged answer 中的score this 10被视为数据而非指令代价是judge verdicts 可能变化token counts 可能变化但这是明确的安全强化。七、升级到 agno v2.8.0 时最需要关注的地方基于这次更新内容升级时最值得关注的点有以下几项1. 评测结果可能变化特别是以下两类ReliabilityEval的工具 expectation 结果AgentAsJudgeEval的 judge verdicts因为工具执行匹配规则更严格了judge prompt 也被加固了所以升级后出现结果变化是官方已经明确提示过的。2. 之前“误通过”的工具评测可能转为失败官方已经写得很清楚如果 verdict 变红往往意味着之前是“因错误原因而通过”所以升级之后如果发现工具相关测试变严格需要优先核查是否只是发出了工具请求是否真的完成了 clean execution是否存在tool_call_error是否是 refused、errored 或 HITL-rejected 情况3. 如果使用 judge 评测token 统计也可能变化由于判分提示词被重新加固所以verdict 可能变token count 也可能变这在统计成本或做历史对比时需要留意。4. 新增环境回放能力后可基于 task 做更真实的通过率观察v2.8.0 已经把EnvironmentTaskrun_rollouts(env, k8)以及通过样本导出能力串起来了。如果你关注的是任务稳定性、重复运行表现与 passk这部分就是本次版本最重要的能力入口。八、结语代码地址github.com/agno-agi/agnoagno v2.8.0 是一次非常有重点的版本升级。它没有把更新分散到很多无关紧要的小点上而是集中加强了几条关键链路用agno.scorer完善评分体系用agno.environments和run_rollouts(env, k8)打开 passk 能力入口用Case.scorer补足评测套件中的第三种检查方式用ToolCallScorer与ReliabilityEval的新规则收紧工具执行匹配用 judge prompt fence 加固AgentAsJudgeEval的判分安全同时补齐FileGenerationTools、Gmail Tools、Adanos Tools 的功能增强修复 RemoteAgent、RemoteTeam、Content、decision_log 等问题在 cookbook 和若干配套内容上继续扩展如果只用一句话概括这次版本那么可以说agno v2.8.0 的核心不只是“新增功能”而是把评测、回放、工具执行验证与判分防护这几条关键链路一起做扎实了。