随着LLM和Agent能力的迅速发展团队也在不同的场景用Agent做交付有些场景很依赖基础模型的能力换个模型可能效果就一落千丈同样Agent 改了一版 prompt线上效果变好了又改了一版突然某个场景全崩了。这样的问题我感觉在Agent时代会非常容易出现程序里面的逻辑是写死的一个数据过来只要符合要求一定会按照某个逻辑往下走但是Agent中的逻辑不一样很多都是通过prompt来约束执行而LLM的transformer本身就是预测所以你也不知道下一步应该走向哪里也许一个token就会影响走向。Anthropic 在 Demystifying Evals for AI Agents[1] 里说了一句话我很认同“Teams without evals get bogged down in reactive loops — fixing one failure, creating another.”没有评测的团队会陷入被动循环修了一个 bug 又引入另一个。所以基于以上的痛点实现了一个专门用于Agent的评测框架基于YAML 配置驱动的 Agent 评测框架支持多种 Agent 适配器和评分策略结果存 SQLite能出表格、JSON、HTML 报告。为什么 Agent 需要专门的评测我们先看一下传统的软件测试和Agent评测的区别。传统软件是确定性的——同样的输入每次都给同样的输出。单元测试、集成测试能覆盖绝大多数质量问题。但 Agent 不一样它有几个根本性的区别•输出非确定性同样的 prompt同样的模型跑两次结果可能不一样。你没法用assertEqual来断言 Agent 的输出。•Prompt 变更即代码变更改一个词可能导致整个行为链路发生变化而且这种变化往往不可预测。传统代码的变更影响范围是可以通过静态分析评估的prompt 不行。•依赖外部模型模型本身在升级、在变化。即使你什么都没改上游模型更新了一个版本Agent 的表现也可能出现波动。这意味着传统的测试金字塔单元测试 → 集成测试 → E2E 测试覆盖不了 Agent 的核心质量问题。你需要一套专门的评测体系它能处理非确定性输出、支持多次运行取统计指标、能在每次迭代时自动回归检测。更重要的是评测是贯穿Agent整个开发过程中的而不是 QA 阶段才做的事。每次改 prompt、换模型、调整Skills、调整工具之后都应该立刻跑一轮评测看效果。没有这个反馈回路根本无法预测这次调整是不是能符合预期。想解决什么问题理解了上面的背景我们来看做这个框架之前列出的几个必须解决的问题•Agent 输出不确定同样的 prompt 跑三次结果可能不一样。不能只看一次结果就说通过得多跑几次算个可靠性指标。Anthropic 提出的 passk 和 pass^k 就是为了适应Agent评测的特点——passk 衡量 k 次里至少有一次通过的概率能力上限pass^k 衡量 k 次全部通过的概率可靠性。这两个指标一起看才有意义。•评分方式多样有些任务有标准答案“法国首都是巴黎”直接字符串匹配就行。有些任务是开放式的“写一段产品介绍”得用 LLM 打分。还有些要检查合规性不能输出敏感信息。一个框架必须同时支持这些不同的评分逻辑。•迭代效率调评分规则的时候不应该每次都重新调 API。Agent 的回答缓存下来只重跑评分就好。•CI/CD 接入评测结果要能直接插进流水线通过率低于阈值就阻断合并。•断点续跑评测任务多的时候跑到一半网络断了或者被 kill 了不应该从头来。快速开始安装curl -fsSL https://raw.githubusercontent.com/wallezhang/agent-eval/main/install.sh | bash详细说明可以参考主页AgentEval官网[2]装好之后三步跑起来第一个测试case# 1. 初始化项目agent-eval init my-evalcd my-eval# 2. 改配置默认生成的 eval.yaml 可以直接用# 或者指向你自己的 Agent# 3. 运行评测agent-eval run -c eval.yamlinit会生成这样的目录结构my-eval/├── eval.yaml # 评测配置├── tasks/│ └── sample.yaml # 示例任务└── results/ # 报告输出跑完后终端直接输出结果表格 Evaluation Report: my-eval Agent: openai | Run ID: a1b2c3d4Duration: 3250msTASK PASS FAIL ERR AVG SCORE PASSK PASS^K P50ms P90ms P99ms---- ---- ---- --- --------- ------ ------ ----- ----- -----Capital of France 3 0 0 1.000 1.000 1.000 980 1050 1080--- Summary ---Tasks: 1 | Trials: 3 (passed: 3, failed: 0, error: 0)Overall Pass Rate: 100.0% | Avg Score: 1.000Avg passk: 1.000 | Avg pass^k: 1.000--- Token Usage ---Total Input Tokens: 150 | Total Output Tokens: 18 | Total: 168Estimated Cost: $0.0056同时在results/目录下会有 JSON、HTML 报告和summary.json。不同场景的怎么用场景一有标准答案的知识问答这是最简单的场景。Agent 回答法国首都是哪里期望答案是Paris用exact_match评分就够了。# eval.yamlname: qa-evalagent: type: openai config: model: gpt-4 api_key: ${OPENAI_API_KEY} temperature: 0.0defaults: trials_per_task: 5 # 每题跑 5 次看稳定性 graders: - type: exact_match config: ignore_case: true ignore_whitespace: truetask_files: - tasks/*.yaml plaintext # tasks/geography.yaml- id: capital-of-france name: Capital of France tags: [geography, easy] input: prompt: What is the capital of France? Answer with just the city name. expected: text: Paris- id: capital-of-japan name: Capital of Japan tags: [geography, easy] input: prompt: What is the capital of Japan? Answer with just the city name. expected: text: Tokyotrials_per_task: 5让每个问题跑 5 次。对于 temperature0 的模型这 5 次结果应该完全一致。如果不一致说明模型本身有不稳定的地方pass^k 会直接反映出来。场景二编码 Agent 评测评测编码 Agent 的关键是不能只看代码里有没有某个关键词要结合多种检查。# eval.yamlname: coding-evalagent: type: openai config: model: gpt-4 api_key: ${OPENAI_API_KEY} temperature: 0.0defaults: trials_per_task: 3execution: concurrency: 4 rate_limit_rps: 5 timeout: 120s plaintext # tasks/coding.yaml- id: fizzbuzz name: FizzBuzz tags: [coding, easy] input: prompt: | Write a Python function called fizzbuzz(n) that returns a list of strings from 1 to n. For multiples of 3, use Fizz; for multiples of 5, use Buzz; for multiples of both, use FizzBuzz; otherwise use the number as a string. Return ONLY the code, no explanation. graders: - type: contains weight: 1.0 config: keywords: [def fizzbuzz, Fizz, Buzz, FizzBuzz] - type: regex weight: 1.0 config: pattern: def fizzbuzz\s*\(\s*n\s*\)这里用了两个评分器contains检查关键元素在不在regex检查函数签名格式。如果有测试脚本也可以直接用command评分器直接跑单元测试。graders: - type: command config: command: python args: [-m, pytest, tests/test_fizzbuzz.py] timeout: 60s场景三开放式问答 合规检查Agent 做客服回答既要回答得好又不能泄露敏感信息。这种场景需要 LLM 评分和约束检查组合使用。# tasks/customer-service.yaml- id: refund-policy name: Refund Policy Query tags: [customer-service, compliance] input: prompt: I bought a product 15 days ago and want a refund. Whats your policy? system: You are a customer service agent. Be helpful but do not share internal system details. graders: - type: llm weight: 0.6 config: provider: openai api_key: ${OPENAI_API_KEY} model: gpt-4 rubric: | Evaluate the response on: 1. Does it address the refund timeframe question? 2. Is the tone professional and helpful? 3. Does it provide actionable next steps? Score 0.0-1.0. - type: constraint weight: 0.4 config: checks: - name: no_internal_info pattern: (?i)(internal|database|system prompt|backend) must_not_match: true - name: has_greeting pattern: (?i)(hello|hi|thank|sorry) must_match: true - name: reasonable_length max_words: 300 min_words: 20LLM 评分器用 rubric 做主观评估权重 0.6constraint 评分器做合规检查权重 0.4。最终分数是加权平均但通过条件是 AND——两个评分器都得通过才算这条 trial 通过。在客服或者其它合规的场景下回答就算写得再好如果泄露了内部信息或者是回答了非合规的内容也应该判失败。补充说明一下constraint评分器的能力除了正则匹配patternmust_match/must_not_match它还支持字数范围检查min_words/max_words。这些都是内置的约束类型在配置中直接使用即可。场景四接入 CI/CD# 在 CI 流水线里agent-eval run -c eval.yaml --fail-under 0.8--fail-under 0.8意思是通过率低于 80% 就返回退出码 1流水线会被阻断。同时results/summary.json会被写入可以被后续步骤消费。配合标签过滤可以在不同阶段跑不同的测试# PR 合并前只跑核心用例agent-eval run -c eval.yaml --tags core --fail-under 0.9# 日常回归跑全量agent-eval run -c eval.yaml --fail-under 0.8# 安全审查单独跑agent-eval run -c eval.yaml --tags safety --fail-under 1.0场景五调评分逻辑时省 API 开销开启缓存后Agent 的回答会被缓存到本地文件。改评分规则后重新运行评测不会重复调用 Agent API。cache: enabled: true dir: .cache/ ttl: 24h缓存 key 是 (Agent 类型 Agent 配置 任务输入) 的 SHA256 哈希。只有 Agent 端完全不变的情况下才会命中缓存。# 第一次运行调 API结果被缓存agent-eval run -c eval.yaml# 改了评分规则后运行命中缓存不调 APIagent-eval run -c eval.yaml# 强制跳过缓存agent-eval run -c eval.yaml --no-cache如果你在调 prompt每次 prompt 变了缓存自然不会命中。缓存主要是为了节省调评分逻辑阶段的 API 开销。场景六对比两次评测A/B Test换了模型或者改了 prompt 之后想看效果变化# 先跑一次作为基线agent-eval run -c eval.yaml# 记下 run ID比如 eefc2b36# 改了配置后再跑一次agent-eval run -c eval.yaml# 新的 run ID 比如 b3c4d5e6# 对比agent-eval compare eefc2b36 b3c4d5e6支持 ID 前缀匹配输出结果会标注每个任务是回归了还是改进了。评分器选择指南是是否是否是否否是否是否你的场景有标准答案完全匹配exact_match包含关键词contains有格式要求regexjson_match能跑测试脚本command要主观评价llmpairwiseA/B 对比提示不管选了哪个评分器如果有合规要求额外加一个constraint评分器。多个评分器可以组合使用通过weight控制各自在最终分数中的权重。扩展机制如果内置的 Agent 和 Grader 不够用框架提供了接口可以自由扩展。Agent 只需要实现两个方法type Agent interface { Execute(ctx context.Context, input model.TaskInput) (*model.AgentOutput, error) Close() error}Grader 也是两个方法type Grader interface { Grade(ctx context.Context, input GradeInput) (*model.GradeResult, error) Type() string}然后在init()里注册不需要改任何其他代码。比如你想加一个调用内部 RPC 服务的 Agent// pkg/agent/internal_rpc.gopackage agentfunc init() { Register(internal_rpc,func(config map[string]any) (Agent, error) { addr : config[address].(string) return InternalRPCAgent{address: addr}, nil })}type InternalRPCAgent struct { address string}func (a *InternalRPCAgent) Execute(ctx context.Context, input model.TaskInput) (*model.AgentOutput, error) { // 调你的 RPC 服务 resp, err : callRPC(ctx, a.address, input.Prompt) if err ! nil { return nil, err } return model.AgentOutput{Text: resp}, nil}func (a *InternalRPCAgent) Close() error { return nil }配置里直接用就行agent: type: internal_rpc config: address: localhost:9090一些实现细节•passk 用对数空间计算组合数在 n 大的时候会溢出所以实际计算时用的是 log 空间的算术避免精度问题。•SQLite 用纯 Go 实现依赖的是modernc.org/sqlite不需要 CGO交叉编译很方便。这对做 CLI 工具来说很重要——用户不需要装 C 编译器就能go install。•缓存是透明的Agent 被一层CachedAgent包裹对上层完全透明。缓存命中时会在 metadata 里加一个cache_hit: true标记报告里能看到哪些 trial 用的是缓存结果。•Hook 失败是非致命的生命周期 Hook 执行失败只会打 warning 日志不会终止评测。这样不会因为一个通知脚本挂了就导致整个评测中断。路线图接下来计划做的几个方向•动态多轮交互评测支持在评测过程中让 LLM 扮演用户动态追问评估 Agent 的多轮对话能力•可视化 Dashboard现在的 HTML 报告是静态的想做一个能看历史趋势变化的交互式面板•更多 Agent 适配器国内主流模型的 API 适配•评测集市场提供一些标准评测集针对常见场景客服、代码生成、信息提取拿来就能用•分布式执行任务量大的时候支持分发到多台机器学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
从手动到自动化：用AgentEval构建Agent评测体系
随着LLM和Agent能力的迅速发展团队也在不同的场景用Agent做交付有些场景很依赖基础模型的能力换个模型可能效果就一落千丈同样Agent 改了一版 prompt线上效果变好了又改了一版突然某个场景全崩了。这样的问题我感觉在Agent时代会非常容易出现程序里面的逻辑是写死的一个数据过来只要符合要求一定会按照某个逻辑往下走但是Agent中的逻辑不一样很多都是通过prompt来约束执行而LLM的transformer本身就是预测所以你也不知道下一步应该走向哪里也许一个token就会影响走向。Anthropic 在 Demystifying Evals for AI Agents[1] 里说了一句话我很认同“Teams without evals get bogged down in reactive loops — fixing one failure, creating another.”没有评测的团队会陷入被动循环修了一个 bug 又引入另一个。所以基于以上的痛点实现了一个专门用于Agent的评测框架基于YAML 配置驱动的 Agent 评测框架支持多种 Agent 适配器和评分策略结果存 SQLite能出表格、JSON、HTML 报告。为什么 Agent 需要专门的评测我们先看一下传统的软件测试和Agent评测的区别。传统软件是确定性的——同样的输入每次都给同样的输出。单元测试、集成测试能覆盖绝大多数质量问题。但 Agent 不一样它有几个根本性的区别•输出非确定性同样的 prompt同样的模型跑两次结果可能不一样。你没法用assertEqual来断言 Agent 的输出。•Prompt 变更即代码变更改一个词可能导致整个行为链路发生变化而且这种变化往往不可预测。传统代码的变更影响范围是可以通过静态分析评估的prompt 不行。•依赖外部模型模型本身在升级、在变化。即使你什么都没改上游模型更新了一个版本Agent 的表现也可能出现波动。这意味着传统的测试金字塔单元测试 → 集成测试 → E2E 测试覆盖不了 Agent 的核心质量问题。你需要一套专门的评测体系它能处理非确定性输出、支持多次运行取统计指标、能在每次迭代时自动回归检测。更重要的是评测是贯穿Agent整个开发过程中的而不是 QA 阶段才做的事。每次改 prompt、换模型、调整Skills、调整工具之后都应该立刻跑一轮评测看效果。没有这个反馈回路根本无法预测这次调整是不是能符合预期。想解决什么问题理解了上面的背景我们来看做这个框架之前列出的几个必须解决的问题•Agent 输出不确定同样的 prompt 跑三次结果可能不一样。不能只看一次结果就说通过得多跑几次算个可靠性指标。Anthropic 提出的 passk 和 pass^k 就是为了适应Agent评测的特点——passk 衡量 k 次里至少有一次通过的概率能力上限pass^k 衡量 k 次全部通过的概率可靠性。这两个指标一起看才有意义。•评分方式多样有些任务有标准答案“法国首都是巴黎”直接字符串匹配就行。有些任务是开放式的“写一段产品介绍”得用 LLM 打分。还有些要检查合规性不能输出敏感信息。一个框架必须同时支持这些不同的评分逻辑。•迭代效率调评分规则的时候不应该每次都重新调 API。Agent 的回答缓存下来只重跑评分就好。•CI/CD 接入评测结果要能直接插进流水线通过率低于阈值就阻断合并。•断点续跑评测任务多的时候跑到一半网络断了或者被 kill 了不应该从头来。快速开始安装curl -fsSL https://raw.githubusercontent.com/wallezhang/agent-eval/main/install.sh | bash详细说明可以参考主页AgentEval官网[2]装好之后三步跑起来第一个测试case# 1. 初始化项目agent-eval init my-evalcd my-eval# 2. 改配置默认生成的 eval.yaml 可以直接用# 或者指向你自己的 Agent# 3. 运行评测agent-eval run -c eval.yamlinit会生成这样的目录结构my-eval/├── eval.yaml # 评测配置├── tasks/│ └── sample.yaml # 示例任务└── results/ # 报告输出跑完后终端直接输出结果表格 Evaluation Report: my-eval Agent: openai | Run ID: a1b2c3d4Duration: 3250msTASK PASS FAIL ERR AVG SCORE PASSK PASS^K P50ms P90ms P99ms---- ---- ---- --- --------- ------ ------ ----- ----- -----Capital of France 3 0 0 1.000 1.000 1.000 980 1050 1080--- Summary ---Tasks: 1 | Trials: 3 (passed: 3, failed: 0, error: 0)Overall Pass Rate: 100.0% | Avg Score: 1.000Avg passk: 1.000 | Avg pass^k: 1.000--- Token Usage ---Total Input Tokens: 150 | Total Output Tokens: 18 | Total: 168Estimated Cost: $0.0056同时在results/目录下会有 JSON、HTML 报告和summary.json。不同场景的怎么用场景一有标准答案的知识问答这是最简单的场景。Agent 回答法国首都是哪里期望答案是Paris用exact_match评分就够了。# eval.yamlname: qa-evalagent: type: openai config: model: gpt-4 api_key: ${OPENAI_API_KEY} temperature: 0.0defaults: trials_per_task: 5 # 每题跑 5 次看稳定性 graders: - type: exact_match config: ignore_case: true ignore_whitespace: truetask_files: - tasks/*.yaml plaintext # tasks/geography.yaml- id: capital-of-france name: Capital of France tags: [geography, easy] input: prompt: What is the capital of France? Answer with just the city name. expected: text: Paris- id: capital-of-japan name: Capital of Japan tags: [geography, easy] input: prompt: What is the capital of Japan? Answer with just the city name. expected: text: Tokyotrials_per_task: 5让每个问题跑 5 次。对于 temperature0 的模型这 5 次结果应该完全一致。如果不一致说明模型本身有不稳定的地方pass^k 会直接反映出来。场景二编码 Agent 评测评测编码 Agent 的关键是不能只看代码里有没有某个关键词要结合多种检查。# eval.yamlname: coding-evalagent: type: openai config: model: gpt-4 api_key: ${OPENAI_API_KEY} temperature: 0.0defaults: trials_per_task: 3execution: concurrency: 4 rate_limit_rps: 5 timeout: 120s plaintext # tasks/coding.yaml- id: fizzbuzz name: FizzBuzz tags: [coding, easy] input: prompt: | Write a Python function called fizzbuzz(n) that returns a list of strings from 1 to n. For multiples of 3, use Fizz; for multiples of 5, use Buzz; for multiples of both, use FizzBuzz; otherwise use the number as a string. Return ONLY the code, no explanation. graders: - type: contains weight: 1.0 config: keywords: [def fizzbuzz, Fizz, Buzz, FizzBuzz] - type: regex weight: 1.0 config: pattern: def fizzbuzz\s*\(\s*n\s*\)这里用了两个评分器contains检查关键元素在不在regex检查函数签名格式。如果有测试脚本也可以直接用command评分器直接跑单元测试。graders: - type: command config: command: python args: [-m, pytest, tests/test_fizzbuzz.py] timeout: 60s场景三开放式问答 合规检查Agent 做客服回答既要回答得好又不能泄露敏感信息。这种场景需要 LLM 评分和约束检查组合使用。# tasks/customer-service.yaml- id: refund-policy name: Refund Policy Query tags: [customer-service, compliance] input: prompt: I bought a product 15 days ago and want a refund. Whats your policy? system: You are a customer service agent. Be helpful but do not share internal system details. graders: - type: llm weight: 0.6 config: provider: openai api_key: ${OPENAI_API_KEY} model: gpt-4 rubric: | Evaluate the response on: 1. Does it address the refund timeframe question? 2. Is the tone professional and helpful? 3. Does it provide actionable next steps? Score 0.0-1.0. - type: constraint weight: 0.4 config: checks: - name: no_internal_info pattern: (?i)(internal|database|system prompt|backend) must_not_match: true - name: has_greeting pattern: (?i)(hello|hi|thank|sorry) must_match: true - name: reasonable_length max_words: 300 min_words: 20LLM 评分器用 rubric 做主观评估权重 0.6constraint 评分器做合规检查权重 0.4。最终分数是加权平均但通过条件是 AND——两个评分器都得通过才算这条 trial 通过。在客服或者其它合规的场景下回答就算写得再好如果泄露了内部信息或者是回答了非合规的内容也应该判失败。补充说明一下constraint评分器的能力除了正则匹配patternmust_match/must_not_match它还支持字数范围检查min_words/max_words。这些都是内置的约束类型在配置中直接使用即可。场景四接入 CI/CD# 在 CI 流水线里agent-eval run -c eval.yaml --fail-under 0.8--fail-under 0.8意思是通过率低于 80% 就返回退出码 1流水线会被阻断。同时results/summary.json会被写入可以被后续步骤消费。配合标签过滤可以在不同阶段跑不同的测试# PR 合并前只跑核心用例agent-eval run -c eval.yaml --tags core --fail-under 0.9# 日常回归跑全量agent-eval run -c eval.yaml --fail-under 0.8# 安全审查单独跑agent-eval run -c eval.yaml --tags safety --fail-under 1.0场景五调评分逻辑时省 API 开销开启缓存后Agent 的回答会被缓存到本地文件。改评分规则后重新运行评测不会重复调用 Agent API。cache: enabled: true dir: .cache/ ttl: 24h缓存 key 是 (Agent 类型 Agent 配置 任务输入) 的 SHA256 哈希。只有 Agent 端完全不变的情况下才会命中缓存。# 第一次运行调 API结果被缓存agent-eval run -c eval.yaml# 改了评分规则后运行命中缓存不调 APIagent-eval run -c eval.yaml# 强制跳过缓存agent-eval run -c eval.yaml --no-cache如果你在调 prompt每次 prompt 变了缓存自然不会命中。缓存主要是为了节省调评分逻辑阶段的 API 开销。场景六对比两次评测A/B Test换了模型或者改了 prompt 之后想看效果变化# 先跑一次作为基线agent-eval run -c eval.yaml# 记下 run ID比如 eefc2b36# 改了配置后再跑一次agent-eval run -c eval.yaml# 新的 run ID 比如 b3c4d5e6# 对比agent-eval compare eefc2b36 b3c4d5e6支持 ID 前缀匹配输出结果会标注每个任务是回归了还是改进了。评分器选择指南是是否是否是否否是否是否你的场景有标准答案完全匹配exact_match包含关键词contains有格式要求regexjson_match能跑测试脚本command要主观评价llmpairwiseA/B 对比提示不管选了哪个评分器如果有合规要求额外加一个constraint评分器。多个评分器可以组合使用通过weight控制各自在最终分数中的权重。扩展机制如果内置的 Agent 和 Grader 不够用框架提供了接口可以自由扩展。Agent 只需要实现两个方法type Agent interface { Execute(ctx context.Context, input model.TaskInput) (*model.AgentOutput, error) Close() error}Grader 也是两个方法type Grader interface { Grade(ctx context.Context, input GradeInput) (*model.GradeResult, error) Type() string}然后在init()里注册不需要改任何其他代码。比如你想加一个调用内部 RPC 服务的 Agent// pkg/agent/internal_rpc.gopackage agentfunc init() { Register(internal_rpc,func(config map[string]any) (Agent, error) { addr : config[address].(string) return InternalRPCAgent{address: addr}, nil })}type InternalRPCAgent struct { address string}func (a *InternalRPCAgent) Execute(ctx context.Context, input model.TaskInput) (*model.AgentOutput, error) { // 调你的 RPC 服务 resp, err : callRPC(ctx, a.address, input.Prompt) if err ! nil { return nil, err } return model.AgentOutput{Text: resp}, nil}func (a *InternalRPCAgent) Close() error { return nil }配置里直接用就行agent: type: internal_rpc config: address: localhost:9090一些实现细节•passk 用对数空间计算组合数在 n 大的时候会溢出所以实际计算时用的是 log 空间的算术避免精度问题。•SQLite 用纯 Go 实现依赖的是modernc.org/sqlite不需要 CGO交叉编译很方便。这对做 CLI 工具来说很重要——用户不需要装 C 编译器就能go install。•缓存是透明的Agent 被一层CachedAgent包裹对上层完全透明。缓存命中时会在 metadata 里加一个cache_hit: true标记报告里能看到哪些 trial 用的是缓存结果。•Hook 失败是非致命的生命周期 Hook 执行失败只会打 warning 日志不会终止评测。这样不会因为一个通知脚本挂了就导致整个评测中断。路线图接下来计划做的几个方向•动态多轮交互评测支持在评测过程中让 LLM 扮演用户动态追问评估 Agent 的多轮对话能力•可视化 Dashboard现在的 HTML 报告是静态的想做一个能看历史趋势变化的交互式面板•更多 Agent 适配器国内主流模型的 API 适配•评测集市场提供一些标准评测集针对常见场景客服、代码生成、信息提取拿来就能用•分布式执行任务量大的时候支持分发到多台机器学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
