agno Environments 快速入门七个单文件示例掌握 Agent 评测、Pass Rate 网格与 SFT 数据集生成【免费下载链接】agnoBuild, run, and manage agent platforms.项目地址: https://gitcode.com/GitHub_Trending/ag/agno本篇技术指南以 cookbook/environments/_00_quickstart/README.md 为核心骨架完整拆解其覆盖的七个子标题示例_01 到 _07并结合agno.environments模块的源码实现runner.py、sft.py与三类评分器code.py、tools.py、judge.py展开底层原理。读完本文你将掌握如何把已有 Agent 包装成Environment如何用 K 次 rollout 得到真实通过率pass rate如何读取网格、摘要与指纹如何用learning_zone()挑出值得训练的任务以及如何把通过的轨迹导出为对话式 SFT JSONL 数据集。一、Quickstart 定位最短路径从零到可用环境_00_quickstart是 agno 的 environments cookbook 的入口。其 README 开宗明义七个单文件示例覆盖完整闭环——运行一个 Agent K 次、给每次尝试打分、读取网格、导出通过的结果。每个文件独立成篇、端到端可运行无需在不同文件夹之间跳转。该目录结构如下可在仓库中直接核对cookbook/environments/_00_quickstart/ ├── README.md ├── TEST_LOG.md ├── tasks/ │ └── support_triage.jsonl # _05 示例使用的任务集团队可入库管理的 JSONL ├── _01_first_env.py # 最小完整环境 ├── _02_export_sft.py # 导出通过的尝试为 SFT 数据集 ├── _03_tool_reliability.py # 工具调用可靠性评测 ├── _04_judge_rubric.py # 用 LLM 评委按 rubric 打分 ├── _05_compare_models.py # 同一环境跑两个模型并 diff ├── _06_drilldown_demo.py # 单次尝试的深度下钻 └── _07_support_triage.py # 完整的工单分类环境README 明确指出一旦某个文件读懂了后面编号递增的文件夹会对同一思想做更深入的展开每个文件只讲一个选项。也就是说quickstart 是最短路径后续_01_first_environment/、_06_learning_zone/、_10_export_sft/等目录才是同一主题的纵深变体。紧随其后的 cookbook/environments/_01_first_environment/README.md 便印证了这一设计它把 _01 的最小环境拆成basic.py、with_summary.py、with_fingerprints.py三个文件一个选项一个文件。二、运行方式与前置条件README 给出了两种运行方式。方式一运行单个文件python cookbook/environments/_00_quickstart/_01_first_env.py方式二用共享 runner 按顺序批量运行整个目录python cookbook/scripts/cookbook_runner.py cookbook/environments/_00_quickstart \ --batch --timeout-seconds 1800 --json-report /tmp/quickstart.json其中各参数含义为--batch批量顺序执行--timeout-seconds 1800为每个文件设置 1800 秒30 分钟的超时上限--json-report /tmp/quickstart.json把运行结果汇总为 JSON 报告便于 CI 消费。前置条件与成本提示README 原话必须完整保留每个文件都会发起真实模型调用因此必须设置OPENAI_API_KEY完整跑一遍整个目录会消耗真实 token有成本如果某个任务需要更长时间用--timeout-seconds 0可以禁用单文件超时限制。结合 cookbook/environments/_00_quickstart/TEST_LOG.md 的实测记录这些文件均在gpt-5.5OpenAIResponses上验证过_01 的 16 次尝试耗时约 55 秒_02 的 24 次尝试耗时约 103 秒_03 的 24 次尝试仅约 21 秒。测试日志同时记录了一个值得注意的真实排障案例_05 首次运行曾因tasks/support_triage.jsonl未提交到 git 而抛出FileNotFoundError补交文件后重跑通过——这从侧面说明了任务集以文件形式入库管理的实践价值。三、_01_first_env.py最小完整环境这是整个 quickstart 的基石代码位于 cookbook/environments/_00_quickstart/_01_first_env.py。它演示的核心思想是Agent 输出是采样的单次运行什么都证明不了。把一个任务跑 K 次并统计才能得到真实的通过率pass rate在改了提示词、换了工具、换了模型之后重跑才能看出什么变了。3.1 结构化输出 类型化校验class Answer(BaseModel): value: int reasoning: str def exact(run, expected): # The verifier compares a typed field, not a string. String comparison against # structured output is where most first environments quietly go wrong. return run.content.value expected这是整个 cookbook 反复强调的第一条实践校验器比较的是类型化字段而不是字符串。对结构化输出做字符串比较是绝大多数第一个环境悄然出错的地方。run.content是 Agent 解析后的Answer实例直接访问.value做整型比较天然避开 JSON 格式抖动、多余空白、大小写等问题。3.2 Environment 的四个核心要素agent Agent( modelOpenAIResponses(idgpt-5.5, reasoning_effortlow), output_schemaAnswer ) env Environment( namemental-math, agentagent, tasks( Task(inputWhat is 17 x 23?, expected391), Task( input( Compute 2718281828459045 multiplied by 1618033988749895. Add the decimal digits of the product, multiply that digit sum by 131071, then subtract the products remainder modulo 65521. ), expected20944939, ), ), scorerCodeScorer(exact), )从 libs/agno/agno/environments/environment.py 的源码结构看一个Environment由四个核心要素构成name环境名称参与环境指纹fingerprint计算agent被评测的 Agent 本身tasks任务集每个Task至少包含input给 Agent 的输入与expected期望结果scorer评分器决定一次尝试算不算通过。注意示例中两个任务的设计意图文件注释写得很清楚第一个任务17 x 23是饱和锚点easy anchor预期 8/8 全对不携带任何信号第二个任务是十六位大数相乘 数字求和 两次取模的长链式计算足够难不同尝试会产生分歧给采样留出打滑的机会——单乘积任务会饱和在 8/8而这个任务能让通过率呈现出有区分度的分布。3.3 命名函数作评分器的理由# A named function, so the environment fingerprints cleanly: edit the function # and env_fingerprint flips, telling you the environment drifted. scorerCodeScorer(exact),文件注释解释了为什么用命名函数exact而不是内联 lambda命名函数让环境能被干净地指纹化。你编辑了校验函数env_fingerprint就会翻转从而明确告诉你环境漂移了。这也是 quickstart 目录与_07_support_triage.py中 lambda 写法形成对照的原因——后者更贴近快速验证的随手用法前者是可追踪可复现的严谨用法。3.4 run_rollouts 与三份关键输出results run_rollouts(env, k8) print(results) print() summary results.summary() print(fpass rate: {summary[pass_rate]}) print(fscored attempts: {summary[n_scored]} of {summary[n_attempts]}) print(fenv fingerprint: {summary[env_fingerprint]}) print(fpolicy fingerprint: {summary[policy_fingerprint]}) zone_ids [task[id] for task in summary[tasks] if task[learning_zone]] print(flearning zone tasks: {zone_ids})run_rollouts(env, k8)对每个任务执行 8 次相互隔离的尝试全新的 session、全新的内存数据库、不捕获记忆、关闭响应缓存注释原文fresh session, fresh in-memory db, no memory capture, response cache off。这样得到的通过率才值得信赖。对应的实现位于 libs/agno/agno/environments/runner.py 的run_rolloutsL1221 起。运行结果有三层输出契约print(results)静态打印同一张网格运行时在 TTY 上会实时渲染每次尝试一个字形符号每一行是一个任务、每一列是一次尝试results.summary()机器可读的 CI 契约返回包含pass_rate、n_scored、n_attempts、env_fingerprint、policy_fingerprint、tasks每项含learning_zone布尔标记等字段的字典learning_zone尝试结果出现分歧的任务0 pass rate 1被视为携带信号的任务是后续训练数据选择的重点。TEST_LOG 对 _01 的实测记录印证了学习区间的含义Both tasks 8/8 this run, so the learning zone was empty: the hard task sits at the edge of gpt-5.5s ability (7/8 on some runs, 8/8 on others)——难任务正好处在模型能力边缘有时 7/8 有时 8/8学习区间是否出现取决于当次采样。四、_02_export_sft.py把通过的运行导出为 SFT 数据集代码见 cookbook/environments/_00_quickstart/_02_export_sft.py。核心主张非常直接通过的尝试无需任何额外标注本身就是监督微调SFT数据集。这是同一个 rollout 产物顺带赠送的价值。4.1 两层选择叠加learning_zone() 与 only_passedTrue文件注释明确区分了两个回答不同问题的选择results.learning_zone()选择任务层尝试结果有分歧的任务。Agent 8/8 全过的任务不携带训练信号导出它会 K 倍地加重模型已经会的东西0/8 全挂的任务无物可导。两者之间的任务才是 trainer 值得投入的地方。to_sft_jsonl(..., only_passedTrue)选择尝试层学习区间内的任务按构造必然包含失败尝试而监督文件绝不能教模型错误答案所以只保留通过的尝试。zone results.learning_zone() zone_ids [task_result.task.id for task_result in zone.task_results] print(flearning zone: {zone_ids}) if not zone.task_results: print(no task disagreed across attempts, so there is nothing worth training on) print((make a task harder, or raise k, and the zone fills)) else: _OUTPUT_DIR.mkdir(parentsTrue, exist_okTrue) train_path _OUTPUT_DIR / train.jsonl report to_sft_jsonl(zone, train_path) print(fwrote {report.n_written} conversations to {train_path}) print(fskipped failed attempts: {report.n_skipped_failed}) print(fskipped tool-bearing runs: {report.n_skipped_tool_runs}) print(fskipped limit-hit runs: {report.n_skipped_limit_hit}) print(fskipped runs with no text: {report.n_skipped_no_text}) print(fdropped over cap: {report.n_dropped_over_cap}) print(fprovenance sidecar: {train_path}.meta.json)注意to_sft_jsonl返回的ExportReport提供了一组跳过计数器n_skipped_failed失败的尝试、n_skipped_tool_runs带工具调用的运行、n_skipped_limit_hit触达上限的运行、n_skipped_no_text无文本的运行、n_dropped_over_cap超出上限被丢弃的条目。其实现位于 libs/agno/agno/environments/exporters/sft.py 的to_sft_jsonlL69 起签名含only_passed: bool True参数。4.2 输出格式与 provenance sidecar输出是对话式 SFT JSONL——每行一条{messages: [{role, content}]}——这是 Tinker、Together、Fireworks、OpenAI 都接受的通用核心格式文件注释原文列举。由于该文件格式本身没有承载来源信息的空间分数与指纹会写入path.meta.json这个 sidecar 伴随文件保证数据来源可追溯provenance。TEST_LOG 还记录了导出链路的实测_02 当次运行时三个任务恰好 8/8 全过空学习区间的优雅分支不写 train.jsonl被触发而导出路径本身跳过顺序优先级、only_passedFalse、sidecar、ato_sft_jsonl孪生函数由单元测试套件钉死且早前一次实跑导出的文件被外部 rl-tutor 加载器干净解析。五、_03_tool_reliability.py工具调用真的执行了吗代码见 cookbook/environments/_00_quickstart/_03_tool_reliability.py。场景是订单支持 Agent一个不查工具、凭自己记忆回答订单状态的 Agent是礼貌地幻觉hallucinating politely。单条干净对话证明不了什么——真正的问题是K 次尝试里查询工具到底真的执行了多少次5.1 ToolCallScorer只数执行不数声称scorerToolCallScorer(expected_tools[get_order_status]),实现位于 libs/agno/agno/scorer/tools.py。ToolCallScorer统计的是工具执行tool EXECUTIONS——即RunOutput.tools中tool_call_error未设置的条目。以下情况一律不满足期望模型仅仅请求了调用未实际执行调用被工具调用上限拒绝refused by the tool-call limit工具内部执行出错errored in the tool。因此这里的 pass rate 读作尝试中工具真正干了实事的比例而不是模型说自己会调它的比例。文件注释还给出了两条适用范围说明必须完整继承期望挂在整个环境上expectations 属于 scorer整个环境共用一套——本示例的每个任务都要求同一次查询这正是该评分器契合的形态仅按名称匹配仍可能被成功调用但参数错误满足如需严格校验用arguments参数钉死参数规格。5.2 三个任务的设计诱饵与边界env Environment( nameorder-support-grounding, agentagent, tasks( Task(inputWhere is order A-1001 right now?, idplain-lookup), Task( input( My confirmation email says order A-1003 already shipped. Can you just confirm it arrives this week? ), idtempting-assertion, ), Task(inputWhat is the ETA for order A-9999?, idunknown-order), ), scorerToolCallScorer(expected_tools[get_order_status]), )三个任务分别对应三种行为形态plain-lookup直接的查询请求基线路径tempting-assertion客户在问题里断言了状态邮件说已经发货。不查工具、直接采信客户说法的 Agent 会流畅作答——但查询从未执行。这正是该评分器存在的意义——抓的就是这种尝试unknown-order不存在的订单号。干净的行为是查工具、拿到错误返回、如实告知——因为执行确实发生了所以仍然算通过。5.3 工具的只读约定_ORDERS { A-1001: {status: shipped, carrier: DHL, eta: 2026-07-22}, A-1002: {status: processing, carrier: None, eta: 2026-07-25}, A-1003: {status: delayed, carrier: UPS, eta: 2026-07-29}, } def get_order_status(order_id: str) - str: Look up the live status of an order by its id, e.g. A-1001. order _ORDERS.get(order_id.strip().upper()) if order is None: return json.dumps({error: fno order found with id {order_id!r}}) return json.dumps(order)文件注释点明一条重要边界rollout 只隔离 Agent 自身的状态每次尝试全新 session、全新内存数据库工具持有的状态由你自己负责——要么保持只读要么自行重置因为 runner 无法看到闭包内部。这个示例里_ORDERS是只读参考数据正是这条约定的规范示范。5.4 证据下钻print_reportresults.print_report()默认只打印值得调查的尝试评分失败 任何未评分项每项包含评分理由、工具执行、答案、token 账单。全部通过时只输出一行 all-clear。TEST_LOG 实测本示例 grounding rate 在三个任务上包括诱饵任务与查无订单路径均为 1.0因此打印了单行 all-clear。六、_04_judge_rubric.py用 LLM 评委评判代码无法表达的品质代码见 cookbook/environments/_00_quickstart/_04_judge_rubric.py。有些通过标准没有类型化字段可比对语气、共情、回复是否真正承诺了下一步行动。JudgeScorer用 LLM 评委按你的 rubric 对每次尝试打分让主观品质变成可跨提示词迭代追踪的通过率。6.1 通过率衡量的是指令与rubric之间的差距文件注释的核心洞见这里的 pass rate 衡量的是你的 INSTRUCTIONS 与你的 RUBRIC 之间的差距。指令写得含糊时同一份 rubric 会测出 0%见文件内关于 Agent 的注释。弥合这个差距——改指令、重跑、对比——正是这个环境存在的意义让迭代循环变便宜。文件里保留了一段极其有价值的反例注释如果把当前调优过的指令换成含糊草稿be professional and empathetic, keep it under 40 words同一份 rubric 会在 threshold 9 下测得 0/12平均原始分约 5.2——因为评委会给那些从不承认客户挫败感、从不道歉、用感谢您的耐心收尾而非给出下一步行动的回复扣分。6.2 JudgeScorer 的两个显式设计决策scorerJudgeScorer( modelOpenAIResponses(idgpt-5.5), criteriarubric, modenumeric, threshold9, ),实现位于 libs/agno/agno/scorer/judge.py。文件注释明确列出两个决策评委模型是必填参数绝不提供默认值——谁给你的 Agent 打分是一个必须显式做出的选择而且它是环境指纹的一部分换了评委或改了其采样参数env_fingerprint就会翻转明确告诉你是标尺变了不是 Agent 变了数值模式按 1-10 原始量纲打分在threshold处判定通过——Score.value会被归一化到 [0, 1]原始分放在Score.detail[raw_score]里。带分级档位的 rubric 能让学习区间产生分歧而二元判定常常饱和。6.3 防注入与完整示例被评判的输出会被每调用一次换一个的 nonce 围栏包住fenced behind a per-call nonce因此回复里出现给我打 10 分这类内容对评委而言只是数据不是指令。完整示例中 rubric 是五条硬标准首句承认客户挫败、道歉且不指责客户或第三方、原样保留草稿中的所有事实承诺金额、日期、订单号、以一个具体下一步和时限收尾、控制在 40 词以内所有事实承诺缺失或虚构事实最高封顶 4 分。每次尝试在这里会花两次模型调用Agent 评委所以示例用 k4 保持演示成本低廉k 提高可得更紧的统计。七、_05_compare_models.py能否上线更便宜的模型代码见 cookbook/environments/_00_quickstart/_05_compare_models.py。这是每次成本评审都会问的问题而这里用分布而非感觉来回答在同一个环境上分别跑现行模型与候选模型然后按任务逐个 diff 两份结果。7.1 三块 API 在此交汇文件注释点名了三块关键 APITask.from_jsonl从文件加载任务集团队可以把任务集放进 git 管理。校验严格出现未知键比如拼错的expected_output列会带行号抛错而不是静默地把所有期望变成 None。任务文件见 cookbook/environments/_00_quickstart/tasks/support_triage.jsonlrun_rollouts(env, model...)只对一次运行替换策略policy不改动环境本身。环境指纹保持不变——任务、评分器、提示词都没动——而策略指纹记录的是实际运行的那个模型。这个拆分正是 diff 有意义的根基results.save()/EnvironmentRunResult.load()/candidate.diff(baseline)跨时间闭环——今天保存基线下周拿候选者与它对 diff。若期间环境发生漂移diff会抛MismatchError让你不可能在不同的任务集之间误做对比。注意保存的产物包含明文完整对话transcript要像对待任何含生产提示词的文件一样对待它。7.2 完整流程baseline run_rollouts(env, k8) print(baseline) baseline.save(baseline_path) print(fbaseline saved to {baseline_path}) candidate run_rollouts(env, k8, modelOpenAIResponses(idgpt-5-mini)) print(candidate) baseline EnvironmentRunResult.load(baseline_path) diff candidate.diff(baseline) print(diff) baseline_rate baseline.summary()[pass_rate] candidate_rate candidate.summary()[pass_rate] print(fbaseline pass rate: {baseline_rate}) print(fcandidate pass rate: {candidate_rate})流程五步跑基线 → 保存 → 换模型跑候选 → 重载基线并 diff → 用两个数字下决策。TEST_LOG 记录了真实的失败与修复过程是理解本示例价值的最佳注脚首次运行因tasks/support_triage.jsonl未入库而FileNotFoundError失败任务集重建入库后重跑通过——基线 5 个任务全部 1.0候选模型在支付中崩溃的歧义行上掉到 7/8diff 打印出真实的-0.12 regressed行和(env identical, policy changed)标注。便宜模型能否上线的答案就是几乎可以而且这是需要看的那一行。八、_06_drilldown_demo.py阅读证据单次尝试深度下钻代码见 cookbook/environments/_00_quickstart/_06_drilldown_demo.py。网格给出数字这个文件处理的是当一个数字需要调查时该怎么办。它复用 _03 的订单支持环境但重点是三个下钻 APIerrors()、print_report()、print_attempt()。8.1 errors()错误与失败的区分# Attempts that errored (provider failures, timeouts) are excluded from # the statistics, never counted as failures -- inspect them separately. errors results.errors() if errors: print(fattempts with errors: {errors})文件注释强调出错provider 失败、超时的尝试被排除在统计之外绝不当作失败计数需要单独检查。这是保证 pass rate 语义干净的重要细节。8.2 print_report() 的两个层次# 默认只打印值得调查的尝试评分失败 未评分项全绿则单行 all-clear results.print_report() # onlyall完整证据——判定、评分理由、每次工具执行含解析后的参数、答案、token 账单 results.print_report(onlyall, attempts2)TEST_LOG 实测确认报告逐尝试渲染了判定、带解析参数的工具执行、答案与 token 数attempts2上限与... 6 more省略逻辑正常print_attempt通过pprint_run_response渲染了评分判定加完整对话。8.3 print_attempt()单个尝试的完整转录results.print_attempt(tempting-assertion, 1)一次尝试可以被完整渲染评分器的未删减推理过程 完整对话转录——正是to_sft_jsonl会导出的那些消息。文件注释同时强调所有这些都是对保留数据的呈现。底层的对象——results.task_results[i].attempts[j].run / .score / .stop_reason——始终可用供任何自定义逻辑使用results.save(rollouts.json)可以把整个产物对话、分数、指纹写成一个 JSON 文件。8.4 边界声明本 release 不含实时交互环文件末尾有一段明确的路线图声明上面的一切都属于验证与数据集生成——运行 K 次、逐次打分、读证据、导出通过的尝试用于监督微调。没有任何东西在运行中途与 Agent 对话。下一步不在本 release 内是实时循环live loop一个对 Agent 每一轮都做出响应、并在交互过程中打分的环境让分数直接驱动训练。这个边界同样出现在 cookbook/environments/_01_first_environment/README.md 中The live turn-by-turn reward loop is not part of this release; these environments perform verification and dataset generation.九、_07_support_triage.py学习区间一览的完整示例代码见 cookbook/environments/_00_quickstart/_07_support_triage.py。这是整个 quickstart 的收尾之作对真实工单分类、每个任务跑多次、看网格如何分裂成拿捏的任务、摇摆的任务、永远搞不定的任务三档。9.1 中间带才是重点文件注释再次点题Agent 永远通过的任务对 trainer 毫无教益无信号永远失败的任务同样毫无教益只有有时赢的任务——0 pass rate 1——才是学习区间learning zone。results.learning_zone()把这些任务直接交到你手里随时可以导出。这也是目录 cookbook/environments/_06_learning_zone/ 的主题为什么 Agent偶尔通过的任务才是值得训练的任务。改一次提示词或模型再跑一遍网格就会告诉你什么变了——README 称之为tweet screenshot一次运行、每个任务的通过率、被点名标出的学习区间。9.2 六个任务干净案例 刻意歧义env Environment( namesupport-ticket-triage, agentagent, tasks( Task(iddouble-charge, inputI was charged twice for my July invoice. Refund one., expectedbilling), Task(idexport-bug, inputThe export button does nothing; the console shows a TypeError., expectedbug), Task(iddark-mode, inputPlease add a dark mode -- half my team works nights., expectedfeature_request), Task(idlocked-out, inputCant log in since this morning and the reset email never arrives., expectedaccount_access), Task(idcrash-charge, inputThe app crashed mid-payment and now I see two pending charges., expectedbilling), Task(idslow-then-refund, inputReports take 30s to load and I want a refund for the trouble., expectedbilling), ), scorerCodeScorer(lambda run, expected: run.content.category expected), )前四个任务分别对应四个桶billing / bug / feature_request / account_access的干净案例后两个是刻意设计的歧义任务支付中途崩溃读起来像 bug 实则是 billing报表慢要退款同样落在 billing——好模型大部分时间但不是全部能答对正好落入学习区间。results run_rollouts(env, k8, concurrency4) print(results) zone results.learning_zone() print(\nlearning zone (tasks worth training on):) for task_result in zone.task_results: print(f - {task_result.task.id}: {task_result.pass_rate:.2f}) report to_sft_jsonl(zone, data/generated/triage_sft.jsonl)这个示例额外展示了concurrency4并发参数每任务 8 次尝试、4 个并发在飞并把前面所有环节串成一条流水线run_rollouts → print(results) → learning_zone() → to_sft_jsonl——验证、读网格、选任务、导出一条命令完成。TEST_LOG 注明该文件在编写会话中未做线上运行当时无 API key但语法检查通过、公共 API 导入无误并已用 stub 模型端到端验证了 scorer → grid → learning_zone() → to_sft_jsonl 的完整接线。十、底层支撑agno.environments 与 agno.scorer围绕七个子标题示例仓库 libs/agno/agno/environments/ 与 libs/agno/agno/scorer/ 提供了全部底层实现示例文件只是这些 API 的最小用法示例使用的 API源码位置一句话作用Environment/Taskenvironment.py任务集、Agent 与评分器的容器携带 name 参与指纹run_rollouts(env, k, ...)runner.py L1221对每个任务执行 K 次隔离尝试并逐次评分results.learning_zone()runner.py L147筛选出尝试结果有分歧0 pass rate 1的任务to_sft_jsonl(...)exporters/sft.py L69把学习区间内通过的尝试导出为对话式 SFT JSONLCodeScorerscorer/code.py用 Python 函数比对类型化字段ToolCallScorerscorer/tools.py统计工具真实执行而非声称调用JudgeScorerscorer/judge.py用 LLM 评委按 rubric 打分支持数值阈值模式三类评分器覆盖了验证的全部形态代码可表达的标准CodeScorer、工具行为标准ToolCallScorer、代码无法表达的主观品质JudgeScorer。指纹机制env fingerprint / policy fingerprint贯穿所有示例用于区分环境变了还是策略变了为跨时间、跨模型的对比提供不变量保障。十一、下一步README 推荐的三个纵深目录quickstart README 的 Where to go next 给出了三条继续深入的路以下路径均已按仓库根目录转换cookbook/environments/_01_first_environment/ —— 把 _01 的最小环境拆成一个选项一个文件basic.py、with_summary.py、with_fingerprints.py并明确适用范围当单次成功运行不足以作为证据时从这里开始cookbook/environments/_06_learning_zone/ —— 深入讲解为什么 Agent 偶尔通过的任务才值得训练cookbook/environments/_10_export_sft/ —— 完整展开导出路径包括 provenance来源追踪。十二、实践要点速查把七个子标题示例压缩为可直接照搬的实践清单校验类型化字段不要比对字符串CodeScorer的回调里访问run.content.value这类结构化字段_01、_07用命名函数作评分器让环境指纹可追踪、可发现漂移_01K 次隔离尝试 统计通过率run_rollouts(env, k8)每次尝试全新 session、无记忆、关缓存_01学习区间选择任务only_passed 选择尝试learning_zone()过滤任务to_sft_jsonl(..., only_passedTrue)过滤尝试避免导出错误答案_02、_07导出结果带 sidecar分数与指纹在path.meta.json对话式 JSONL 本身不带来源信息_02工具可靠性数执行不数声称ToolCallScorer只认tool_call_error未设置的执行记录严格校验用arguments钉参数_03工具状态自管rollout 只隔离 Agent 状态闭包内工具数据保持只读或自行重置_03主观品质用 LLM 评委JudgeScorer的 judge model 必填、参与指纹数值模式 1-10 分、threshold 判定输出用 nonce 围栏防注入_04同环境跨模型对比run_rollouts(env, model...)换策略不换环境save/load/diff跨时间闭环漂移时diff抛MismatchError_05错误不计入失败errors()单独检查 provider 失败与超时_06下钻三件套print_report()默认只看值得调查项、onlyall看全量、print_attempt()单个尝试的完整转录、底层对象task_results[i].attempts[j]始终可访问_06记住 release 边界本版本只做验证与数据集生成实时交互评分环不在其中_06、_01 README。【免费下载链接】agnoBuild, run, and manage agent platforms.项目地址: https://gitcode.com/GitHub_Trending/ag/agno创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
