用途：分析一次代码变更需要哪些测试，并把相应测试加入测试套件，覆盖单元测试以及随机化/模糊测试，保证新功能被测试、缺陷修复带回归测试。
主要能力：
- 识别变更类型：新功能、缺陷修复、重构、性能改动。
- 定位相关既有测试，查找相近命名测试文件、引用被改函数/类的测试以及集成测试。
- 按类型给出测试需求：新功能需公共函数单测、正常输入、边界情况、非法输入错误处理、必要时集成测试；缺陷修复需一个在修复前会失败的回归测试并引用问题编号；重构一般只需既有测试通过；性能改动需功能测试通过，可考虑基准测试、指标或 tracy ZoneScoped 注解，以及 LogSlowExecution 包装。涉及交易处理/应用逻辑变更时，应一并补充 fee bump 测试。
- 判断是否需要随机化测试：涉及交易处理、共识/SCP、账本状态管理、序列化/反序列化或协议关键代码时，考虑模糊目标、基于属性的不变量测试、分布式行为模拟测试。
使用方式：输入包括获取 diff 的 git 命令（如 git diff master...HEAD）、变更类型、缺陷/问题引用，以及可选的特定测试要求；作为子代理运行时由调用方提供，提示中应写明分析对象、git 命令与要求。建议拆分为多个子代理分步执行。
测试编写约定：测试通常位于被测代码同目录下的 test/ 子目录，文件名多为 *Tests.cpp，辅助文件为 *TestUtils.cpp，通用测试工具在 src/test；使用 Catch2 框架。应沿用既有测试夹具、断言宏、命名与辅助函数；测试要严格，检查超时、失败断言，避免用日志代替 assert/panic。新测试要自包含，不依赖外部状态，单独运行验证通过；回归测试应验证在缺陷仍存在时会失败。
禁止事项：不加依赖外部状态或顺序的测试，不加易抖动或依赖时序的测试，不重复既有覆盖，不测实现细节而非行为，不加未运行的测试，协议关键代码不得跳过随机测试考虑，不重复创建已有辅助工具。
输出：报告新增测试清单（含文件、测试名、验证点与问题引用），或确认无需新增测试并说明理由。