![]()
![]()
![]()
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:
•
CodeScorer•
JudgeScorer•
ToolCallScorer
并且,所有 scorer 都同时提供 sync 和 async 版本。
这意味着,无论是同步链路还是异步链路,都可以统一使用这套评分能力。
1.1 CodeScorer
CodeScorer的作用是:包装任意可调用对象作为评分器。
它支持的返回值类型包括:
•
bool•
float•
Score
这让它的适用范围非常灵活。
如果你的评分逻辑已经存在为一个普通函数,那么现在可以直接用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。
它引入了:
•
Environment•
Task•
run_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_value•
score_passed•
score_reasonkeys
也就是说,评测结果在字典化输出时,会新增以下字段:
•
score_value•
score_passed•
score_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 literalno longer escapes the block
也就是说,即便被评判的内容里真的出现了字面量的,它也不能再逃逸出这个输出块。
这代表 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.environments•
run_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_value•
score_passed•
score_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
• 字面量不再逃逸
• 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 已经把:
•
Environment•
Task•
run_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 的核心,不只是“新增功能”,而是把评测、回放、工具执行验证与判分防护这几条关键链路一起做扎实了。
我们相信人工智能为普通人提供了一种“增强工具”,并致力于分享全方位的AI知识。在这里,您可以找到最新的AI科普文章、工具评测、提升效率的秘籍以及行业洞察。 欢迎关注“福大大架构师每日一题”,发消息可获得面试资料,让AI助力您的未来发展。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.