Flue Evals评测教程系统化评估AI Agent质量【免费下载链接】flueThe sandbox agent framework.项目地址: https://gitcode.com/GitHub_Trending/flue1/flue刚上线的 AI Agent 回复看着没问题但上线后却频繁翻车这正是Flue Evals 评测体系要解决的问题。Flue 是一个用 TypeScript 编写的 Agent 开发框架sandbox agent framework而 Evals 则是一套让 AI Agent 在真实模型上跑一遍、再断言其行为的自动化评测方法——覆盖回复内容、工具调用和结构化输出帮你把感觉还行变成指标合格。本教程用仓库内置的 examples/vitest-evals/ 示例带你从零搭建一套完整的 Agent 质量评估流程。为什么 AI Agent 需要 Evals 评测传统的单元测试测的是你写的代码——比如工具的run函数一个普通函数可以直接单测。但 Agent 的行为来自指令 模型 工具三者的共同涌现这正是单测覆盖不到的部分非确定性同样的输入模型可能给出不同的措辞、不同的工具调用顺序。所以断言要针对行为契约必须调用的工具、回复中的关键事实而不是精确的字符串输出。真实开销每个评测用例都消耗真实的 token 和时间因此 Evals 必须独立于单元测试拥有自己的配置、超时时间和运行节奏。官方文档 evals.md 中对 Evals 的定义非常直白跑一个真实模型上的 Agent然后断言它的可观测行为。一键搭建 Evals 评测环境Flue 提供 Blueprint蓝图机制用一条命令即可把vitest-evals集成到项目flue add tooling vitest-evals蓝图的完整规范见 tooling--vitest-evals.md。它会自动生成三个关键文件示例仓库中都有现成版本文件作用参考评测配置独立的 Vitest 配置只收集src/evals/**/*.eval.ts超时放宽到 60 秒vitest.evals.config.ts运行脚本evals/evals:info/evals:json三个命令package.json评测 Harness为每个用例开一个全新会话驱动 Agent 并把回复、工具调用、token 用量归一化为评测结果harness.ts 为什么单独建一个配置因为真实模型测试需要更长的超时、不同的凭据和文件发现规则和单元测试混在一起会互相干扰。编写第一个 AI Agent 评测用例评测文件按能力或场景命名如service-health.eval.ts而不是一个 Agent 一个文件。完整可运行的示例在 service-health.eval.ts核心思路通过 Harness 发一句话Is the checkout service currently operational?断言回复包含operational行为契约断言 Agent 确实调用了get_service_status工具而不是编造答案断言 token 用量大于 0确认真实跑过模型describeEval(service status agent, { harness }, (it) { it(checks live service status before answering, async ({ run }) { const result await run(Is the checkout service currently operational?); expect(result.output).toContain(operational); expect(toolCalls(result).map((call) call call.name)).toContain(get_service_status); }); });两种驱动方式怎么选进程内start()在测试进程里直接拉起 Flue 运行时不需要服务器适合测 Agent 本身的指令和工具行为。HTTPflue/sdk像真实用户一样走 HTTP 会话接口连路由、中间件一起验证还能通过设置FLUE_AGENT_URL直接评测线上部署环境。如果行为无法精确断言比如语气、政策合规可以再叠加Judge 评分器由一个独立的评测模型给结果打分低于阈值即判失败。原则是先写确定性断言语义判断才用 Judge。本地运行与 CI 集成评测报告运行评测只需两条命令——一个终端起服务另一个终端跑评测pnpm --filter example-vitest-evals dev # 启动 Flue 服务 pnpm --filter example-vitest-evals evals # 运行评测进阶玩法详见 READMEevals:info输出详细的工具调用与用量信息便于调试evals:json生成vitest-results.json报告可用vitest-evals serve在本地查看CI 门禁评测套件就是一次普通的 Vitest 运行失败时退出码非零天然可作流水线关卡。建议与单元测试分开成独立 job按合并、定时或手动触发小结与延伸阅读到这里你已经掌握了 Flue Evals 的完整闭环独立配置 → Harness 驱动 → 行为断言 → 报告与 CI 门禁。AI Agent 的质量保障不再是玄学而是一套可重复执行的评估流程。完整评测指南evals.md可运行示例项目examples/vitest-evals/工具集成蓝图总览tooling.md评测 Harness 实现harness.tsSDK 会话客户端packages/sdk/把这套 Evals 流程加到你的 Flue 项目里让每一次模型升级、指令调整都有据可查 【免费下载链接】flueThe sandbox agent framework.项目地址: https://gitcode.com/GitHub_Trending/flue1/flue创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Flue Evals评测教程：系统化评估AI Agent质量
Flue Evals评测教程系统化评估AI Agent质量【免费下载链接】flueThe sandbox agent framework.项目地址: https://gitcode.com/GitHub_Trending/flue1/flue刚上线的 AI Agent 回复看着没问题但上线后却频繁翻车这正是Flue Evals 评测体系要解决的问题。Flue 是一个用 TypeScript 编写的 Agent 开发框架sandbox agent framework而 Evals 则是一套让 AI Agent 在真实模型上跑一遍、再断言其行为的自动化评测方法——覆盖回复内容、工具调用和结构化输出帮你把感觉还行变成指标合格。本教程用仓库内置的 examples/vitest-evals/ 示例带你从零搭建一套完整的 Agent 质量评估流程。为什么 AI Agent 需要 Evals 评测传统的单元测试测的是你写的代码——比如工具的run函数一个普通函数可以直接单测。但 Agent 的行为来自指令 模型 工具三者的共同涌现这正是单测覆盖不到的部分非确定性同样的输入模型可能给出不同的措辞、不同的工具调用顺序。所以断言要针对行为契约必须调用的工具、回复中的关键事实而不是精确的字符串输出。真实开销每个评测用例都消耗真实的 token 和时间因此 Evals 必须独立于单元测试拥有自己的配置、超时时间和运行节奏。官方文档 evals.md 中对 Evals 的定义非常直白跑一个真实模型上的 Agent然后断言它的可观测行为。一键搭建 Evals 评测环境Flue 提供 Blueprint蓝图机制用一条命令即可把vitest-evals集成到项目flue add tooling vitest-evals蓝图的完整规范见 tooling--vitest-evals.md。它会自动生成三个关键文件示例仓库中都有现成版本文件作用参考评测配置独立的 Vitest 配置只收集src/evals/**/*.eval.ts超时放宽到 60 秒vitest.evals.config.ts运行脚本evals/evals:info/evals:json三个命令package.json评测 Harness为每个用例开一个全新会话驱动 Agent 并把回复、工具调用、token 用量归一化为评测结果harness.ts 为什么单独建一个配置因为真实模型测试需要更长的超时、不同的凭据和文件发现规则和单元测试混在一起会互相干扰。编写第一个 AI Agent 评测用例评测文件按能力或场景命名如service-health.eval.ts而不是一个 Agent 一个文件。完整可运行的示例在 service-health.eval.ts核心思路通过 Harness 发一句话Is the checkout service currently operational?断言回复包含operational行为契约断言 Agent 确实调用了get_service_status工具而不是编造答案断言 token 用量大于 0确认真实跑过模型describeEval(service status agent, { harness }, (it) { it(checks live service status before answering, async ({ run }) { const result await run(Is the checkout service currently operational?); expect(result.output).toContain(operational); expect(toolCalls(result).map((call) call call.name)).toContain(get_service_status); }); });两种驱动方式怎么选进程内start()在测试进程里直接拉起 Flue 运行时不需要服务器适合测 Agent 本身的指令和工具行为。HTTPflue/sdk像真实用户一样走 HTTP 会话接口连路由、中间件一起验证还能通过设置FLUE_AGENT_URL直接评测线上部署环境。如果行为无法精确断言比如语气、政策合规可以再叠加Judge 评分器由一个独立的评测模型给结果打分低于阈值即判失败。原则是先写确定性断言语义判断才用 Judge。本地运行与 CI 集成评测报告运行评测只需两条命令——一个终端起服务另一个终端跑评测pnpm --filter example-vitest-evals dev # 启动 Flue 服务 pnpm --filter example-vitest-evals evals # 运行评测进阶玩法详见 READMEevals:info输出详细的工具调用与用量信息便于调试evals:json生成vitest-results.json报告可用vitest-evals serve在本地查看CI 门禁评测套件就是一次普通的 Vitest 运行失败时退出码非零天然可作流水线关卡。建议与单元测试分开成独立 job按合并、定时或手动触发小结与延伸阅读到这里你已经掌握了 Flue Evals 的完整闭环独立配置 → Harness 驱动 → 行为断言 → 报告与 CI 门禁。AI Agent 的质量保障不再是玄学而是一套可重复执行的评估流程。完整评测指南evals.md可运行示例项目examples/vitest-evals/工具集成蓝图总览tooling.md评测 Harness 实现harness.tsSDK 会话客户端packages/sdk/把这套 Evals 流程加到你的 Flue 项目里让每一次模型升级、指令调整都有据可查 【免费下载链接】flueThe sandbox agent framework.项目地址: https://gitcode.com/GitHub_Trending/flue1/flue创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考