2026年7月23日,agno 发布了 v2.8.0 最新版本。
这次更新的重点非常集中,主要围绕三个方向展开:
- 评分与评测能力增强
- 环境隔离与批量回放能力增强
- 工具执行、判分安全性与可靠性进一步收紧
从更新内容来看,v2.8.0 不只是新增了几个功能点,而是对评测链路、环境运行机制、工具执行验证方式,以及判分提示词防护做了成体系的升级。尤其是agno.scorer、agno.environments、Case.scorer、run_rollouts(env, k=8)、以及对ReliabilityEval和AgentAsJudgeEval的调整,都是这次版本中非常值得关注的核心变化。
一、版本信息
- 版本:v2.8.0
- 状态:Latest
- 发布时间:2026年7月23日
本次更新内容主要分为三部分:
- New Features
- Bug Fixes
- Breaking Changes
此外还有一组 “What’s Changed” 明细,进一步列出了具体变更项。
二、New Features:新功能全量解析
1. agno.scorer:把一次运行结果转成一个分数
这次更新新增了agno.scorer,它的定位非常清晰:把一次 run 转换成一个数字。
这个能力的意义在于,过去很多评测更多关注“是否通过”,而agno.scorer让结果可以进一步数值化。这样一来,评估不仅可以看成败,也可以看分值、区间、比较结果以及更细粒度的质量差异。
agno.scorer中包含三类 scorer:
CodeScorerJudgeScorerToolCallScorer
并且,所有 scorer 都同时提供 sync 和 async 版本。
这意味着,无论是同步链路还是异步链路,都可以统一使用这套评分能力。
1.1 CodeScorer
CodeScorer的作用是:包装任意可调用对象作为评分器。
它支持的返回值类型包括:
boolfloatScore
这让它的适用范围非常灵活。
如果你的评分逻辑已经存在为一个普通函数,那么现在可以直接用CodeScorer包装起来,接入到 agno 的评分体系中。
更新说明中特别指出:
- 推荐在
output_schema下做 typed-field comparison
也就是说,在输出结构明确的情况下,建议基于类型化字段来做比较,这样会更稳定,也更适合结构化评测。
这一点虽然只是简短的一句说明,但在新评分体系里非常关键。因为结构化输出与 typed-field comparison 结合之后,评分逻辑会更清晰,也更容易复用。
1.2 JudgeScorer
JudgeScorer是一个LLM judge 评分器。
它有两个非常明确的特点:
- 使用的模型必须始终是一个显式选择
- 数值判定会被标准化到精确端点,公式为
((score - 1) / 9)
这两个点都很重要。
第一,模型必须显式指定。
这意味着在使用 JudgeScorer 时,不再是模糊依赖默认模型,而是明确地选择具体模型,这能减少判分链路中的不确定性。
第二,数值 verdict 会被归一化。
更新内容里给出了明确公式:
((score - 1) / 9)
这表示 JudgeScorer 的评分输出不是随意浮动的,而是会映射到一个标准化数值区间中。对后续统计、比较、聚合结果来说,这一点非常关键。
1.3 ToolCallScorer
ToolCallScorer用于:确定性地检查工具执行情况。
这里的核心变化是它对工具调用结果的判断标准更严格,而且是基于真正的执行情况,而不是仅仅基于消息中“请求了工具调用”。
更新说明写得非常明确:
- refused 的调用,不满足 expectation
- errored 的调用,不满足 expectation
- HITL-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.environments:Environment、Task 与 run_rollouts(env, k=8)
本次更新的另一个绝对重点是agno.environments。
它引入了:
EnvironmentTaskrun_rollouts(env, k=8)
从功能描述来看,这是一套围绕环境隔离、任务回放、多次运行统计和数据导出的完整能力。
其中最核心的是:
run_rollouts(env, k=8)
它的作用是:
- 对环境中的每个 task 运行 K 次
- 默认
k=8
但更重要的不是“运行 8 次”,而是它的全隔离机制。
2.1 run_rollouts(env, k=8):每个任务运行 K 次,并且完全隔离
更新说明中明确写到,run_rollouts(env, k=8)会让每个任务在完全隔离的条件下运行 K 次。
这个“完全隔离”包括以下内容:
- fresh db
- fresh session
- fresh user
- no memory writes
- no knowledge writes
- no learning writes
- cache 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, k=8)会让每个任务独立跑 K 次,所以每个 task 不再只是“过了还是没过”,而是可以得到一个更真实的通过率表现。
这个能力和 “This is the pass@k door” 是直接对应的。
换句话说,v2.8.0 正式把多次独立运行后的通过率统计能力引入到了环境评测体系中。
2.5 drift-vs-policy fingerprints
更新说明还包含:
- drift-vs-policy fingerprints
这是agno.environments的组成能力之一。
从描述上看,它用于对比漂移与策略之间的指纹信息。
官方并没有在这段更新内容里展开更多定义,因此这里按原意保留。重要的是,v2.8.0 已经将它作为环境能力的一部分加入进来。
2.6 save、load、diff
agno.environments还支持:
- save
- load
- diff
也就是说,这套环境机制不仅能运行,还能:
- 保存
- 加载
- 对比差异
这让环境回放和结果分析更完整,不再只是一次性运行。
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 pass@k door
也就是说,环境回放、多次尝试、通过率统计和通过样本导出,这几项能力组合在一起,构成了面向 pass@k 的入口。
3. Case.scorer:评测套件新增第三种检查方式
更新说明提到:
Case.scorer- the eval suite gains a third check
这意味着在 eval suite 中,现在新增了第三种检查机制。
它的使用方式是:
- 把任意 scorer 插入到一个
Case中 - 并配合
Case.expected
而且它具备以下特点:
- free
- exact
- no LLM call
这里的含义非常直接:
- 这种检查方式不需要额外的 LLM 调用
- 可以做精确判断
- 代价更低
这一点和agno.scorer的出现是相互呼应的。
因为有了 scorer,Case就不仅能做原来的检查,还能挂接一个独立、明确、无需 LLM 的评分或判定过程。
3.1 SuiteResult.to_dict() 新增字段
与Case.scorer配套,更新中还提到:
SuiteResult.to_dict()gains additivescore_valuescore_passedscore_reasonkeys
也就是说,评测结果在字典化输出时,会新增以下字段:
score_valuescore_passedscore_reason
这是一个很实用的补充,因为它让 scorer 的结果能被标准化带出,方便做后续处理、展示和分析。
4. FileGenerationTools:新增代码文件生成能力
本次更新还提到:
FileGenerationTools- Added code file generation for FileGenerationTools
也就是说,FileGenerationTools新增了代码文件生成能力。
更新内容没有展开更多细节,但这个新增点已经明确列在 New Features 中,是本次版本功能增强的一部分。
5. Gmail Tools:新增分页与 max_results_per_request
更新说明写到:
- Gmail Tools
- Added pagination and max_results_per_request
也就是说,Gmail Tools 新增了两个能力:
- 分页
max_results_per_request
这意味着在请求 Gmail 数据时,可以进行分页处理,同时还能控制每次请求的最大结果数。
这是一个非常明确、面向工具使用体验的增强。
6. Adanos Tools:新增可选的市场情绪工具
这次更新还包括:
- Adanos Tools
- Added optional Adanos market sentiment tools
也就是说,Adanos Tools 现在新增了可选的市场情绪工具。
需要注意两个关键词:
- optional
- market sentiment tools
说明这部分不是强制接入,而是可选能力增强。
三、Bug Fixes:问题修复项
除了新增功能,v2.8.0 还修复了几个比较明确的问题。
1. RemoteAgent / RemoteTeam:修复 A2A 协议路径中 metadata 丢失问题
更新内容写到:
- RemoteAgent / RemoteTeam
- Fixed 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() 返回空字符串
更新说明写到:
- Content
- Return empty string for empty content list in
get_content_string()
也就是说,当 content list 为空时,get_content_string()现在会返回空字符串。
这属于边界行为修正。
之前的处理方式没有在这里展开,但现在 v2.8.0 明确规定了空列表对应空字符串返回值。
3. Decision log:替换已弃用的 datetime.utcnow()
更新内容写到:
- Decision log
- Replaced deprecated
datetime.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 execution
tool_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 to
ToolExecution.tool_args - with the same partial-match semantics
也就是说,参数检查现在移动到了:
ToolExecution.tool_args
同时,仍然保留:
- 相同的 partial-match 语义
这意味着:
- 检查的位置变了
- 但匹配方式没有变
因此升级时,关注点主要在“参数检查入口变化”,而不是参数匹配规则变化。
2. Hardened judge prompt:AgentAsJudgeEval 判分提示词加固
本次 Breaking Changes 的另一项重点,是 judge prompt 的加固。
更新说明写到:
- Every
AgentAsJudgeEvalnow fences judged output behind a per-call random nonce - with the untrusted-data instruction inside the prompt
也就是说,现在每一次AgentAsJudgeEval调用,都会把被判定的输出放在一个带随机 nonce 的边界中,并且在提示词内部加入“这是不可信数据”的指令。
这是一次非常明确的判分安全加固。
2.1 文字注入不再轻易影响判分提示词边界
更新内容进一步说明:
- A literal
</output>no longer escapes the block
也就是说,即便被评判的内容里真的出现了字面量的</output>,它也不能再逃逸出这个输出块。
这代表 judge prompt 在结构边界上的防护更强了。
2.2 judged answer 中的“score this 10”只是数据,不是指令
更新说明继续写到:
"score this 10"inside 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 calibration
- hardening
- agreement metrics
这些都属于 cookbook 侧的内容扩展。
5. cookbook:新增 synthetic data generation workflows
这次还加入了:
- synthetic data generation workflows
也是 cookbook 相关能力说明的一部分。
6. cookbook:新增 critique-revision、persona 和 tool-call trajectory generation
更新中还列出:
- critique-revision
- persona
- tool-call trajectory generation
这些内容也都属于 cookbook 的扩展项。
7. cookbook:新增 step-reward scoring、scale-out mechanics 和 safety labeling
What’s Changed 里还包括:
- step-reward scoring
- scale-out mechanics
- safety labeling
依旧是 cookbook 内容增强的一部分。
8. cookbook:image_search README 说明 ingest 是 full rebuild,不是 idempotent
更新说明中有一条非常具体:
- image_search README
- ingest is a full rebuild
- not 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_request
11. 修复 get_content_string() 在空 content list 时返回空字符串
对应前面的 Content 修复项:
- 空内容列表时返回空字符串
12. Adanos:新增可选 market sentiment tools
对应前面的 New Features:
- Adanos 新增可选市场情绪工具
13. Adanos:澄清 trending ranking
What’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 Features:
FileGenerationTools新增 code file generation
16. agno.scorer 与 judge prompt fence
What’s Changed 中有一项总结式条目:
- agno.scorer and the judge prompt fence
它对应的是本次版本最核心的两组升级:
- 新的 scorer 体系
- judge prompt 的边界加固
17. rollout engine 与 Case.scorer seam
What’s Changed 还写到:
- rollout engine and
Case.scorerseam
这对应的就是:
agno.environmentsrun_rollouts(env, k=8)Case.scorer
这几项能力在评测与回放链路中的衔接。
18. release: v2.8.0
这是版本发布条目本身:
- release: v2.8.0
19. cookbook:将 environments 扩展到 progressive verification suite
最后还有一项 cookbook 变更:
- expand environments into progressive verification suite
说明 environments 相关内容在 cookbook 中也有进一步扩展。
20. Release v2.8.0
What’s Changed 中还有一次版本发布条目:
- Release v2.8.0
六、这次 v2.8.0 更新的核心脉络总结
如果把这次所有更新串起来看,v2.8.0 的主线其实非常清楚,主要集中在以下几条:
1. 评分能力从“是否通过”走向“数值化表达”
agno.scorer的引入,意味着 run 的结果可以被转化为:
- bool
- float
- Score
- 标准化数值 verdict
同时还能接入到Case.scorer中,让评测套件具备第三种检查方式,并通过SuiteResult.to_dict()输出:
score_valuescore_passedscore_reason
这让评测不再只是二元结果,而是可以做更细粒度的表达。
2. 环境评测从“单次运行”走向“隔离回放与 pass@k”
agno.environments与run_rollouts(env, k=8)的引入,带来了完整的多次独立回放机制:
- 每个 task 跑 K 次
- 每次都 fresh db、fresh session、fresh user
- 不写 memory、knowledge、learning
- cache off
- knowledge reads still work
再配合:
- live per-attempt grid
- real pass rate per task
- drift-vs-policy fingerprints
- save / load / diff
- learning_zone()
to_sft_jsonl(...)
这套能力已经完整打开了 pass@k 评测与通过样本导出的入口。
3. 工具执行验证从“请求过”升级到“真正执行成功”
不管是ToolCallScorer,还是ReliabilityEval的 breaking changes,都在表达同一个原则:
- 工具 expectation 不能只看有没有发出请求
- 必须看工具是否 clean execution
- refused、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, k=8)
以及通过样本导出能力串起来了。
如果你关注的是任务稳定性、重复运行表现与 pass@k,这部分就是本次版本最重要的能力入口。
八、结语
代码地址:github.com/agno-agi/agno
agno v2.8.0 是一次非常有重点的版本升级。
它没有把更新分散到很多无关紧要的小点上,而是集中加强了几条关键链路:
- 用
agno.scorer完善评分体系 - 用
agno.environments和run_rollouts(env, k=8)打开 pass@k 能力入口 - 用
Case.scorer补足评测套件中的第三种检查方式 - 用
ToolCallScorer与ReliabilityEval的新规则收紧工具执行匹配 - 用 judge prompt fence 加固
AgentAsJudgeEval的判分安全 - 同时补齐
FileGenerationTools、Gmail Tools、Adanos Tools 的功能增强 - 修复 RemoteAgent、RemoteTeam、Content、decision_log 等问题
- 在 cookbook 和若干配套内容上继续扩展
如果只用一句话概括这次版本,那么可以说:
agno v2.8.0 的核心,不只是“新增功能”,而是把评测、回放、工具执行验证与判分防护这几条关键链路一起做扎实了。