TRAE-AI编程
先给结论：评估一个 AI Agent 靠不靠谱，只有三种方法——人工按评分表打分、把固定任务集做成自动回归测试、以及审计它的中间工具调用轨迹。三者不是三选一，而是分别回答"好不好用""有没有退化""错在哪一步"三个不同问题。
新手最常见的评估方式是"我自己试几次，感觉挺顺"。这种判断在任务简单时够用，一旦接入真实流程就会失真：模型偶尔超常发挥会让你高估它，偶尔的低级错误又因为样本太少被你漏掉。想要得出能支撑决策的结论，必须有可重复的测量。
本文给出三种评测方法的建立步骤、各自的成本与局限，并附一份可直接改用的打分脚本。所有结论都基于可自行复现的本地流程，不引用任何第三方榜单数据。
先看结论
- 人工评分表回答"好不好用"：适合冷启动，缺点是慢且主观。
- 自动回归测试回答"有没有退化"：改提示词或换模型后必跑。
- 轨迹审计回答"错在哪一步"：用来定位是规划错、工具错还是输出错。
提示词与工具配置的基础写法记不清时，翻 AI 编程技能教程 里按场景分组的章节最快。
一、方法一：人工评分表
第一种评测方法最原始也最难被替代：准备一组固定任务，让熟悉业务的人按同一张表打分。
评分表要把"好"拆成能判断的条目，而不是只打一个总分。一份可用的表至少包含四栏：
- 任务是否完成——二值判断，不设中间值；
- 结果是否需要人工返工——估一个返工比例；
- 过程有没有多余动作——比如反复调用同一个工具；
- 是否出现事实性错误——一旦出现，本条直接判不合格。
# score.py：把评分结果汇总成可对比的数字
import json
def summarize(path):
rows = json.load(open(path, encoding='utf-8'))
total = len(rows)
done = sum(1 for r in rows if r['done'])
rework = sum(r['rework_ratio'] for r in rows) / total
factual_errors = sum(1 for r in rows if r['factual_error'])
return {
'样本数': total,
'完成率': round(done / total, 3),
'平均返工比例': round(rework, 3),
'事实性错误数': factual_errors,
}
print(summarize('scores.json'))这段做的是把每个人填的评分表汇总成三个可对比的数字。预期输出是完成率、平均返工比例和事实性错误数，其中事实性错误数应当优先看，因为它决定能不能上线。
适用边界要讲清：人工评测方法的主要成本是时间，样本超过几十条之后就很难坚持。它的价值在于定标准——把这张表定下来之后，后面两种自动化方法才有判断依据。
二、方法二：自动回归测试
第二种评测方法把人工判断过的任务固化成断言，之后每次改动都能自动重跑。
# eval_suite.py：固定任务集 + 断言
CASES = [
{'input': '把列表按价格升序排', 'must_contain': 'sorted'},
{'input': '读取配置文件', 'must_call': 'read_file'},
{'input': '删除临时目录', 'must_not_call': 'write_file'},
]
def run_case(agent, case):
trace = agent.run(case['input'])
ok = True
if 'must_contain' in case:
ok = ok and case['must_contain'] in trace.output
if 'must_call' in case:
ok = ok and case['must_call'] in trace.tools
if 'must_not_call' in case:
ok = ok and case['must_not_call'] not in trace.tools
return ok, trace
results = [run_case(agent, c) for c in CASES]
print('通过 %d / %d' % (sum(1 for ok, _ in results if ok), len(results)))这段做的是把三类断言写成可重跑的用例：输出必须包含某个关键词、必须调用某个工具、以及绝对不能调用某个工具。第三类断言最容易被忽略，但对安全边界至关重要。
判断标准是每次改动都要跑：换模型、改提示词、加工具、调参数，任何一种改动之后都要重跑这套用例并把通过率记下来。
三、方法三：轨迹审计
第三种评测方法不看最终答案，只看中间过程。它回答的是"错在哪一步"。
# trace_audit.py：把一次执行的轨迹打平成可检查的步骤
def audit(trace):
steps = []
for i, call in enumerate(trace.calls):
steps.append({
'序号': i + 1,
'工具': call.name,
'参数': call.args,
'是否重试': call.retry,
'耗时秒': round(call.duration, 2),
})
loops = [s for s in steps if s['是否重试']]
return {'步骤数': len(steps), '重试次数': len(loops), '明细': steps}这段做的是把一次执行的每一步工具调用提取出来。真正要看的是三类异常：同一工具被反复调用（说明它在试错）、参数里出现明显不合理的值（说明规划错了）、以及步骤数远超同类任务的正常水平。
性能取舍要讲清：轨迹审计要记录完整调用链，日志量比前两种评测方法大得多。建议只对失败的样本做全量记录，成功的样本只存摘要。
⚠️ 注意：涉及文件写入、命令执行这类有副作用的操作，评测环境必须与开发环境隔离。在真实项目目录里跑评测，一次误操作就能毁掉工作区。
四、三种方法怎么配合与常见失败
4.1 只用人工评测，样本太少
十几条样本得出的结论波动很大。修复方式是先用人工评测定标准，再把这批样本固化成回归用例，之后靠自动跑来扩大样本。
4.2 回归测试全绿但用户觉得变差
说明断言写得太松，只检查了输出包含某个词，没检查输出质量。修复方式是给关键用例补上否定断言和格式断言。
4.3 通过率忽高忽低
同一套用例两次跑出差别很大的结果，通常是任务本身有随机性或者依赖了外部状态。修复方式是给用例固定输入、清理环境，并在用例里避免依赖时间、网络等不稳定因素。
4.4 验证清单
- 检查：三种评测方法是否各自覆盖了对应问题
- 运行：改一次提示词，重跑回归用例，观察通过率变化
- 预期：通过率变化能被明确归因到这次改动
- 失败：通过率无变化或波动很大，说明用例不稳定或断言太松
- 修复：固定输入与环境，补上否定断言
- 验证：连跑三次，三次通过率一致才算稳定
上面这些步骤做的是让"靠不靠谱"变成可归因的数字。预期结果（未在本机执行）是三次连跑结果一致；如果波动明显，先排除外部依赖再下结论。
总结
评估 AI Agent 不是跑一次榜单，而是三件事：用评分表定标准、用回归用例看退化、用轨迹审计定位错误。三种评测方法成本递增，也分别回答不同问题。
三条要点带走：
- 先人工定标准，再把它固化成自动用例，顺序不能反；
- 断言要包含否定条件，尤其是"绝对不能调用某个工具"；
- 有副作用的操作必须在隔离环境里评测。
下一步建议先挑十个真实任务做人工评分，把表定下来再谈自动化。多智能体协作的写法可以对照 AI 编程 Codex Agents Md 再确认一遍。
常见问题
Q：评估 AI Agent 应该看哪些指标？
A：至少看完成率、平均返工比例和事实性错误数三项。事实性错误数优先级最高，它决定是否适合上线。
Q：回归测试为什么全绿但用户觉得变差了？
A：断言写得太松，只检查了输出里有没有某个词。补上否定断言和格式断言，让用例能反映质量而不只是存在性。
Q：通过率忽高忽低怎么办？
A：先固定输入与环境。用例依赖了时间、网络或残留文件时结果必然波动，清理干净再跑。
Q：轨迹审计有什么用？
A：用来定位错误发生在哪一步。看三类异常：同一工具被反复调用、参数值明显不合理、步骤数远超同类任务。
Q：人工评测和自动评测哪个更重要？
A：都重要但顺序固定。先用人工评测把"好"的标准定下来，自动评测才有判断依据，反过来做会得出一堆没有意义的数字。
延伸学习
想把评测这块做扎实，可以按这个顺序来：
- 想补一遍 AI 开发实践，AI 开发实战课程 可以跟一遍；
- 读一篇相关笔记 大模型评测基准是什么，理解公开基准在测什么；
- 想随手验证一段脚本，用 在线代码实例 跑一遍最快。
