type
Post
status
Published
date
Oct 11, 2025
slug
crewai-evaluation-learning-notes
summary
我从 CrewAI Evaluation 出发梳理 Agent 评测：可运行不等于可靠，评测要覆盖任务完成度、过程质量、稳定性和成本。
tags
LLM
agent
工具
category
LLM
icon
password
这篇是我学习 CrewAI Evaluation 时整理的笔记。以前我更关心 Agent 能不能跑起来，现在我越来越觉得，真正难的是如何评价它跑得好不好。
📝 主旨内容
💡 一、为什么我开始关注 Agent 评测
Agent 项目最容易出现的问题，是 demo 看起来很顺，但真实任务里不稳定。
我第一次做 Agent 时，常常会被一次成功运行骗到。模型成功调用了工具，生成了答案，页面看起来也像完成了任务。但只要换一个输入、换一个环境、换一个边界条件，就可能出错。
CrewAI 这类多 Agent 框架更是如此。多个角色协作时，错误可能来自任务拆分、角色提示词、工具调用、上下文传递，也可能来自最终输出没有验证。没有评测，我很难知道问题到底在哪里。
🔍 二、我理解的评测不只是看最终答案
我现在会把 Agent 评测拆成几层：
- 任务完成度：最终有没有解决用户问题
- 过程质量：中间步骤是否合理，是否乱调用工具
- 输出质量：结果是否清楚、可用、有证据
- 稳定性：同类任务多次运行是否一致
- 成本和延迟：完成任务用了多少调用和时间
这比普通文本生成评测更复杂。Agent 是一个过程系统，不能只看最后一句话。
🛠️ 三、我会如何设计 CrewAI 的评测集
评测集要尽量贴近真实任务，而不是只测模型会不会说漂亮话。
如果我要评测一个 CrewAI 项目，我会先准备一批固定任务，每个任务都有明确预期结果。比如资料整理、代码审查、报告生成、数据清洗。然后记录每次运行的工具调用、耗时、输出和失败原因。
我也会给评测任务分难度：简单任务看基本稳定性，中等任务看多角色协作，复杂任务看规划和纠错能力。这样才能知道系统是在全面变好，还是只在某类任务上表现好。
🧩 四、我学到的工程原则
我现在会优先做这些事情
- 固定评测输入，避免每次凭感觉判断。
- 保存 Agent 中间轨迹，方便定位失败原因。
- 把工具调用结果和最终答案分开评估。
- 明确成功标准，不用“看起来还行”做结论。
评测不是项目最后才补的东西，而应该从 Agent 设计初期就加入。
🤗 总结归纳
学习 CrewAI Evaluation 后，我更清楚 Agent 工程的核心问题：可运行不等于可靠。没有评测，就无法知道一次成功是能力还是运气。
作为学习者，我会把评测当成 Agent 项目的基础设施。只有能持续评价，才能持续改进。
📎 参考文章
- CrewAI 文档：https://docs.crewai.com/
- CrewAI GitHub：https://github.com/crewAIInc/crewAI
- LangSmith Evaluation：https://docs.smith.langchain.com/evaluation
我后面如果继续做多 Agent 项目，会先写一小批评测任务，再开始堆角色和工具。
- 作者:老王TechTalk
- 链接:https://www.illusionjourney.com/article/crewai-evaluation-learning-notes
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。
相关文章
