测试驱动的人工智能智能体定义（TDAD）：基于行为规范编译工具使用型智能体
Test-Driven AI Agent Definition (TDAD): Compiling Tool-Using Agents from Behavioral Specifications
Tzafrir Rehan
arXiv (Cornell University) · 2026-03-09
摘要
我们提出了测试驱动的人工智能智能体定义（TDAD）方法，该方法将智能体提示视为可编译的产物：工程师提供行为规范，编码智能体将其转化为可执行测试，另一编码智能体则通过迭代方式不断优化提示，直至测试通过。在生产环境中部署使用工具的大型语言模型智能体时，需要可量化的行为合规性指标，而现有的开发实践尚无法提供此类保障。微小的提示改动便可能引发隐性回归问题，工具误用情况难以被察觉，政策违规行为往往要到部署之后才会显现。为遏制规范博弈现象，TDAD引入了三种机制：（1）可见/隐藏测试拆分机制，即在编译阶段暂不执行评估测试；（2）语义变异测试机制，由编译后的智能体生成看似合理的错误提示变体，再由测试框架检测测试套件能否识别这些变体；（3）规范演化场景机制，用于量化需求变更时的回归安全性。我们在SpecSuite-Core基准测试中评估了TDAD方法，该基准包含四个经过细致规范定义的智能体，分别涉及政策合规性、基于语境的分析能力、操作手册遵循度以及确定性执行能力。在24次独立试验中，TDAD方法实现v1版本92%的编译成功率，隐藏测试平均通过率达97%；演化后的规范编译成功率为58%，其中多数未通过试验除1-2项外均通过了所有可见测试，且变异得分达86%-100%，v2版本的隐藏测试通过率为78%，回归安全性得分达97%。相关实现已作为开源基准测试工具发布于https://github.com/f-labs-io/tdad-paper-code。
本摘要由 AI（Hy-MT2-Pro）翻译生成，仅供参考，请以原文为准。
AI 综述
基于全文生成- 主要观点
- 论文将工具使用型LLM agent的提示词重新定义为编译产物，主张以行为规范为源、可执行测试为中间表示、提示词与工具配置为编译产物，用测试驱动的方式替代试错式提示词编辑。其问题域是生产部署中agent行为合规性无法度量，具体表现为提示词微小改动引发静默回归、工具误用无法检出、策略违规只在部署后暴露；论文将此归纳为置信度、稳定性与集成三个缺口。核心论断是：只有可见测试驱动编译，隐藏测试、语义变异分数与规范演进回归分数仅用于测量，以此抑制规格投机；每个测试期望都必须能从规范条款推导，无法引用条款的行为不得写成测试。论文进一步主张工具描述与系统提示词同为编译产物的一等优化对象，因为工具描述在上下文窗口中与系统提示词并列，对「何时调用哪个工具」的约束力常强于系统提示词。
- 研究方法
- 方法路径为规范到测试再到提示词的编译流水线：输入是YAML规范，含工具模式与调用顺序约束、带优先级的策略、决策树、经respond工具的结构化响应契约、消解模糊政策的test_guidance以及变异意图目录。四个角色分工明确——TestSmith按决策树叶子节点生成MFT并为每个MFT派生INV改述变体与DIR条件对照测试；PromptSmith按算法1迭代，失败测试少于阈值10时进入只跑失败用例的聚焦内循环；MutationSmith在编译完成后依变异意图生成语义变异提示词；Built Agent经MCP调用工具并以respond工具输出decision、node_id、evidence、user_message等字段。样本为SpecSuite-Core的四个规范（SupportOps 12节点、DataInsights 10节点、IncidentRunbook 14节点、ExpenseGuard 11节点），每个规范含v1与v2两版本、各跑3次独立试验，共24次运行。测量材料包括可见测试（40–70%）与隐藏测试（30–60%）的分割、每规范5–7条变异意图、嵌入canary值的确定性fixture、脚本化多轮对话；评估不使用LLM用户模拟器或评判模型，断言作用于工具调用轨迹而非自然语言解析。实现上以pytest承载测试、Docker中的Claude Code执行测试生成与提示词编译、Claude Agent SDK运行被编译agent，全部角色由Claude Sonnet 4.5担任。
- 学术贡献
- 在方法创新层面，论文把测试驱动开发迁移为四角色、接口显式的agent提示词编译流程，并给出可见/隐藏测试分割、基于意图的语义变异测试、规范演进回归测量三种反投机机制；其中语义变异针对的是动态合成的提示词而非固定源码，需以激活探针确认变异生效后才计入变异分数。在理论建构层面，论文把源于强化学习的规格投机概念扩展到测试驱动的提示词优化语境，指出测试一旦成为优化目标便退化为规范的代理，并用隐藏测试与迭代预算为该风险设置可操作的约束。在材料与基准层面，SpecSuite-Core被定位为评估「PRD→测试→编译→回归」工作流的基准协议而非评估agent本身，四个规范均含多轮流程、10个以上决策分支、变异意图目录与v1→v2演进场景，仓库以SupportOps为完整示例开放测试、fixture与结果。在领域定位层面，论文与DSPy等提示词优化系统作了区分：优化目标是行为决策树而非任务准确率，含反投机机制，输入是自然语言规范而非代码级签名。其价值主要落在软件工程中的agent工程化与LLM行为测试两个议题上，并沿用了CheckList提出的MFT/INV/DIR测试分类法。
- 存在局限
- 样本代表性与统计效力不足：基准仅含4个规范、每个规范版本3次试验，v2阶段ExpenseGuard只有1次成功运行且无方差估计；v2整体编译成功率58%，说明编译流程在规范演进下的稳定性尚未确立，而多数失败运行仅差1–2个可见测试，提示失败可能源于迭代预算或收敛判据设置而非方法本身。评估覆盖存在缺口：作者明确未计算RPR，随机性只以3次试验的方差粗略反映；每规范变异意图仅5–7条，且约13%的意图因激活失败被排除在变异分数之外，变异测试对真实缺陷分布的覆盖有限，激活谓词也不支持「SQL查询含LIMIT子句」一类复杂语义检查。论证链条上缺少基线对照：与最接近的DSPy因输入格式根本不同而未做直接实证比较，相对有效性只能靠设计差异而非数据支撑；所有角色复用同一模型，未检验跨模型可迁移性，MutationSmith与PromptSmith同源还可能使变异分数被系统性高估。基准模式与生产模式的差异未被测量：benchmark模式下隐藏测试每次试验重新生成并在单次试验内冻结，production模式下失败隐藏测试提升为可见并触发重编译的路径未评估；SURS所依据的v1不变量测试本身由TestSmith生成，其完备性缺少独立校验。测试生成的随机性带来±10–30%的用例数量波动，可见/隐藏比例虽按规范复杂度在40–60%间调整，但未做比例敏感性分析。
- 进一步研究方向
- 其一，按论文提出的RPR协议做系统测量：对SpecSuite-Core每个测试重跑N=10（标准场景，阈值0.9）与N=50（PII与认证场景，零失败策略），报告通过率分布与编译产物的稳定性边界，检验「零失败」高风险门限在成本上是否可行。其二，做跨模型析因实验：让至少两种不同厂商与规模的模型分别担任TestSmith、PromptSmith与MutationSmith，检验角色—模型匹配对HPR与MS的主效应与交互效应，并单独比较MutationSmith与PromptSmith同源和异源时的MS差异，以判定同源是否造成分数虚高。其三，把v1→v2单次演进扩展为v1→v2→v3的连续演进链，每版保留全部历史不变量测试，测量SURS随版本数的衰减曲线，验证回归安全能否跨多版累积。其四，扩充变异意图目录至每规范20条以上并纳入结构型谓词（如SQL子句约束、工具调用顺序模式），对比行为谓词与结构谓词对MS与non-activating比例的影响，再将存活变异与真实缺陷样本对齐，检验MS的效度。其五，对v2的5次失败运行做根因编码（预算耗尽、test_guidance不足、隐藏—可见差距），并对θ阈值与迭代预算做消融，判定失败能否通过参数调整消除。其六，将TDAD规范重编码为DSPy签名或将DSPy签名反向转写为TDAD规范，在相同行为决策树上比较编译成功率与HPR，定位「从自然语言规范编译」相对「从代码级签名优化」的增益来源。
本综述由 AI（deepseek-flash）阅读开放获取全文自动生成，仅供参考，不代表原文作者观点，请以原文为准。
参考文献
相关论文
话题：Software Testing and Debugging Techniques