测试层次与方法
1. 单元级：单步逻辑与工具
-
目标：保证解析、决策、工具调用的“逻辑正确”。
-
做法：
-
对固定输入测解析结果（例如 intent、槽位、选中的 tool）。
-
对工具函数单独写单元测试（参数、返回值、异常）。
-
用 mock 替代 LLM：给 mock 返回固定内容，只测“收到某回复后，Agent 会做什么”。
-
-
特点：稳定、可重复，适合回归；不直接测“模型好不好”，而是测“Agent 代码对不对”。
2. 集成级：多步流程与工具链
-
目标：保证在真实或接近真实环境下，整条链路行为正确。
-
做法：
-
端到端用例：给定用户输入 → 跑完多轮对话/多步调用 → 断言最终结果或关键中间状态（如调用了某 API、写入了某数据）。
-
契约测试：Agent 调用的下游 API/服务用契约（如 OpenAPI）做请求/响应校验。
-
沙箱/测试环境：数据库、API、外部服务用测试实例，避免动生产。
-
-
思路：用“场景”而不是“单句”来测，覆盖主流程、主要分支和常见错误路径。
3. 评估级：输出质量与行为
-
目标：衡量“答得对不对、好不好、安不安全”，而不仅是“有没有报错”。
-
做法：
-
黄金数据集（Golden Dataset）：一批输入 + 期望输出（或期望行为），用脚本/评估框架跑 Agent，对比：
-
完全匹配（适合封闭任务）；
-
或用评分模型/规则算相似度、关键信息命中、格式正确性等。
-
LLM-as-Judge：用另一个模型对 Agent 输出打分（相关性、准确性、安全性、是否按要求格式）。
-
规则/关键词检查：必须包含/不包含某类内容、必须调用某工具、禁止泄露敏感信息等。
-
-
思路：把“质量”拆成可计算的维度（准确、安全、格式、工具使用正确性），每个维度用少量可重复的用例 + 明确标准。
4. 回归与稳定性
-
目标：改 prompt、改模型或改代码后，不把原来能过的用例搞坏。
-
做法：
-
把上述单元 + 集成 + 黄金集都纳入 CI，每次 MR/发布前自动跑。
-
对非确定性：固定 seed、固定温度=0，或对同一用例跑 N 次，用“通过率”或“统计通过”代替单次必须一致。
-
-
思路：优先保证“关键路径和关键用例”可重复、可追踪。
5. 人工评估与红队
-
目标：覆盖边界情况、主观质量、对抗性输入。
-
做法：
-
抽样人工标注：对线上或测试用例抽样，人打质量分或写评语。
-
红队/对抗测试：故意喂越狱、误导、敏感问题，检查是否拒绝或安全回复。
-
-
思路：自动化解决“大部分稳定与可重复”，人工解决“难定义、高风险的 case”。
跟我AI出来的结果是一样的，有没有实际的经验分享啊
每个agent基于的框架和开发方式都不太一样，前面两步结合自身的agent代码去实现就可以，都是很直接的做法了。后面几点的评判会稍微主观一点，不是很稳定，这种建议有一个通过阈值或者是制定一些关键点，作为更容易自动化的衡量标准，不然的话就需要人去深度参与了。
