PROJECT 01LONG-RUNNING AGENT
软件需求到 Simulink Unit Test 的长任务 Agent Demo
一次覆盖软件需求理解、单元测试需求设计、Simulink Unit Test 和自动调试的端到端实验。首次完整运行约 32 分钟，记录中的上下文规模约为 170k，修改后的脚本最终得到 6/6 PASS；这个结果暴露了测试资产跑通与需求验证之间的区别。
证据边界 这是一次具体实验结果；修改后的脚本通过，不代表原需求验证通过。
01 / CURRENT SERIES
从测试自动化 Workflow 到 Agent Harness
三篇文章，从一次端到端 Agent 实验出发，回到它之前的 5000 行自动化 Workflow，再讨论为什么最终没有把 Agent 设计成 Workflow 的操作员。
- 01
32 分钟，6/6 PASS：我的测试 Agent 到底验证了什么？
一次从软件需求到 Simulink 单元测试的实验。Agent 找到了需求冲突，也完成了失败诊断，但最终全部通过的测试，仍不能证明软件满足需求。
- 02
在 Agent 之前，我写过一个 5000 行的测试自动化 Workflow
- 03
从强状态机到 Agent Harness：我为什么没有让 Agent 成为 Workflow 操作员
首篇已正式发布；后续两篇仍在计划中。
02 / FIELD WORK
实践起点
这里记录的是形成问题的真实工作，不是产品能力陈列。
PROJECT 02DETERMINISTIC WORKFLOW
约 5000 行 Python 的测试自动化 Workflow
在 Agent 实践之前构建的测试自动化 Workflow。它使用更明确的状态和流程控制，也成为后来比较 Workflow 与 Agent Harness 两种工程思路的起点。
03 / OPEN QUESTIONS
我正在研究的问题
- 01长任务 Agent 如何保存和恢复真正有用的状态？
- 02Harness 如何约束工具、上下文和失败恢复，而不退化成另一套强状态机？
- 03如何评估执行过程，而不只看最终 Pass / Fail？
- 04Agent 在汽车软件工具链中的适用边界在哪里？
04 / AUTHOR
关于秋声
汽车电子软件工程师，主要使用 MATLAB/Simulink、Python 和 C。正在把过去在测试自动化与 MBD 工具链中的经验，带入面向汽车软件开发流程的 Agent 工程实践。
我更关心一次成功背后的条件、失败模式和工程取舍，而不是只展示最终 Demo。
进一步了解