夜雨聆风系列：《让 AI Agent 真正交付测试结果》· 连载第 3 篇
上一篇我们提出了六层约束模型。但有个尴尬的问题：
你把规则写得再好，Agent 也可能跳过它。
它不是故意的。长对话压缩了早期规则，任务切换会忘记前置条件，它也可能“觉得”某步不需要就自己跳过。
所以我们需要把“应该做”升级为“必须做”。校验不通过，流程就推不动。
这就是 Test Agent Workflow Runner 的设计动机。
文档约束的四个技术瓶颈
第一，流程跳步。
Agent 从用例直接跳到下单，跳过环境确认和工具选型，最后测试结果无法证明目标功能。
第二，上下文丢失。
跨会话时，Agent 不知道上次做到哪了，容易重复执行或遗漏步骤。
第三，产物质量不可控。
标题存在但内容为空，表格全是占位符，看起来形式合格，实质上没有信息。
第四，流程灵活性不足。
有时只需要实施指南，却被迫走完整流程，效率反而降低。
Runner 三层架构
门禁校验：三层防线
当 Agent 说“这步做完了”时，Runner 不直接接受口头状态，而是执行三层校验。
第一层，依赖校验。
前置步骤必须完成。比如 execution_guide 依赖 tool_selection，那么工具选型未完成时，实施指南不能被标记完成。
第二层，存在性校验。
目标产物必须存在。没有产物文件，就不能只凭聊天里的描述推进流程。
第三层，内容校验。
标题、表格、有效数据必须合格。空标题、空内容、全占位符表格，都不能通过门禁。
目标产物模式：按需裁剪
不是每次都要走完整流程。Runner 支持四种目标模式。
execution_guide：步骤 1 到步骤 5，到实施指南为止，适用于只需要整理测试方案的场景。
execution_record：步骤 1 到步骤 6，到执行记录为止，适用于需要记录执行过程的场景。
report：步骤 1 到步骤 7，到最终报告为止，适用于需要输出正式报告的场景。
full：完整 8 步，包含反思沉淀，适用于完整测试实施闭环。
创建实例时指定 target，系统自动裁剪必经步骤。后续步骤标记为“当前目标不要求”，不阻塞当前目标完成。
状态持久化与中断恢复
所有状态写入本地 JSON 文件，不依赖 Agent 的对话记忆。
一个 run 实例至少包含：
run.json：运行标识、目标、当前步骤。
checklist.json：每步状态、完成时间、校验错误。
artifacts：每个步骤产出的文档。
中断恢复时，Agent 新会话开始后，必须先执行 status 读取运行状态，再执行 next 获取当前步骤、产物路径和校验要求。
关键约束是：禁止依赖聊天上下文推测进度，必须以持久化文件为唯一事实来源。
声明式配置：YAML 定义工作流
工作流通过 YAML 声明，不需要写代码。
配置中定义 workflow id、目标模式、步骤顺序、依赖关系、输出文件、必需标题和表格列要求。
新增步骤、修改校验规则、调整依赖关系，只需要改 YAML，无需改 Runner 代码。
与六层模型的对应关系
Runner 不是独立于方法论之外的工具，它是六层模型的技术保障层。
第 1、2 层的路由和需求，对应输入资料、测试范围等步骤，门禁重点是标题和基础内容校验。
第 3 层的实施设计，对应环境前置判断、工具选型和实施指南，门禁重点是必需标题、表格列和有效数据。
第 4 层的执行证据，对应执行记录，门禁重点是 case 状态、证据路径和执行结果。
第 5、6 层的判断和交付，对应最终报告，门禁重点是结论结构和必要章节。
第 6 层的沉淀，对应测试工程反思，门禁重点是规则缺口、流程缺口和建议沉淀项。
分层约束模型告诉 Runner 应该约束什么，Runner 告诉 Agent 必须做到什么。
幂等性：重复操作不破坏状态
Runner 的 complete 操作具备幂等性。
第一次 complete 某个步骤时，如果校验通过，步骤状态会被标记为 completed。
如果不小心重复 complete 同一个步骤，Runner 返回 already completed，不修改完成时间，不推进指针，也不影响后续步骤。
这点很重要。Agent 在长任务中可能重复执行命令，幂等性可以避免状态被误改。
设计哲学
Runner 的设计遵循几个原则。
轻量级：纯 Python CLI、YAML 配置、JSON 状态，不引入复杂依赖。
声明式：工作流通过配置定义，而不是硬编码。
可演进：方法论演进时，门禁系统可以同步演进。
不替代 Agent：Runner 不执行测试，只保证 Agent 不跳步。
本地优先：所有状态在本地，不依赖云服务。
要点总结
文档约束依赖 Agent 自觉，门禁系统把关键步骤变成强制校验。
三层校验覆盖依赖、产物存在性和内容质量，任一层失败都会阻止流程推进。
目标产物模式支持按需裁剪，不要求所有任务都走完整闭环。
状态持久化让跨会话恢复有据可依，不再依赖聊天记忆。
声明式配置让 workflow 可以随方法论演进，而不需要频繁改代码。
下篇预告
第 4 篇：实战验证——两个真实案例的完整闭环。
理论讲完了，来看真实案例。一个复杂业务功能、一个 Runner 自身测试，分别验证方法论的纠偏能力和门禁系统的技术保障能力。
本文基于真实期货交易系统测试项目实践总结。
