先说结论

• 核心架构是“AI生成，本地执行”，通过MCP协议严格划分职责，用确定性程序解决AI执行不稳定的问题。

• 提供了从自然语言（Gherkin）到多平台代码的“翻译”流水线，显著降低了非技术人员参与自动化的门槛。

• 这种方案的适用前提明确：需要搭建MCP服务层，依赖Copilot等AI工具，更适合需求相对稳定、追求规模化执行的场景。

从“把AI限定在翻译角色，执行交给本地引擎”这个架构设计的务实取舍切入，讨论这种模式如何在控制不确定性的前提下，真正为混合技能团队提效。

谈论用AI做自动化测试，很容易陷入一个两极分化的讨论：要么是怀疑论，觉得AI不可靠，远不如自己写的脚本；要么是全能论，幻想一个AI Agent能理解一切并自主完成所有测试。其实，更务实、能落地的路，可能在这两者之间。微软Edge QA团队开源的AutoGenesis，就提供了一个值得细看的样本。

它没让AI去“跑”测试，而是让AI去“写”测试脚本。执行，则完全交给本地的、确定性的自动化框架。这个分工听起来简单，但背后是一套完整的、意在控制风险的工程化设计。如果你们的团队也在头疼如何让非技术人员参与自动化，或者被多平台测试脚本的维护搞得疲惫，这个方案的思路比工具本身更有参考价值。

架构拆解：四层设计，如何用MCP给AI“戴上镣铐”

AutoGenesis整个系统分为四层，清晰得像一份职责说明书。

最上层是用户输入层，就是写Gherkin语法（Given-When-Then）的自然语言场景。这层没技术含量，却是降低门槛的关键。外包人员、产品经理，只要能描述清楚“先点什么，再输入什么，最后检查什么”的人，都能在这层工作。

第二层是LLM层，也就是AI（比如GitHub Copilot）待的地方。它的工作被严格限定：像一个翻译官，把上一层的自然语言步骤，“翻译”成一系列对底层工具的标准调用指令序列。它不负责执行，也不判断结果对错，只做代码生成。

这里的关键桥梁是MCP。你可以把它理解为一本标准的“工具使用说明书”协议。第三层MCP Server层，就是这本说明书的具体实现者，它把本地复杂的能力（比如用PyWinauto操作Windows窗口，用Appium操控手机）封装成一个个标准的、有清晰描述的工具，通过MCP协议暴露给上层的AI。

最后一层是本地执行层，用成熟的BDD框架（如Behave）去运行AI生成的、调用了MCP工具的Python代码。执行过程是纯粹的、确定性的本地代码运行，没有任何AI的不确定性参与。

这个设计的精明之处在于，它用协议和分层，给AI划定了明确的行动范围。AI只能从MCP提供的“工具箱”里挑选工具，按照既定序列组合，而无法天马行空地自由发挥。不可靠的部分（AI生成）被前置且可审查，可靠的部分（本地执行）被后置以保证结果稳定。

深入MCP层：统一抽象与平台适配的代价

MCP层是这个架构能跨平台的核心。但“统一抽象”这个词背后，是实实在在的工程成本。

AutoGenesis实现了两个主要的MCP Server：一个是基于pywinauto的Windows桌面应用Server，另一个是基于Appium的移动端与macOS Server。它们都遵循MCP协议，向上提供看起来类似的工具，比如click_element、input_text。但对下层，它们必须分别处理Windows的UI Automation API、Android的UIAutomator2、iOS的XCUITest。

这意味着，要想让这套系统在一个新平台上跑起来，你必须为这个平台实现一个符合MCP协议的Server，把该平台特有的自动化SDK封装进去。这是一次性的基础设施投入，不轻。但如果你的应用恰好覆盖了Windows、mac、iOS、Android，那这笔投入的复用价值就很高，因为上层的用例描述和AI生成逻辑可以完全复用。

另一个细节是，Server会通过FastMCP这样的框架，按平台注册工具。也就是说，连接iOS设备时，AI不会看到那些Windows专用的工具，避免了干扰。这种设计保证了AI生成的代码对当前上下文是精准可用的。

从生成到执行：三阶段预览与同步/异步的工程处理

有了架构，如何保证AI“翻译”出来的代码质量可控？AutoGenesis设计了一个“三阶段预览确认”工作流，把最终写入文件的控制权交还给了人。

简单说，AI（Copilot）在接到Gherkin场景后，不会直接生成最终代码。它先会模拟“录制”一遍，通过调用MCP工具，生成一个代码变更的预览diff。这个预览会展示给用户确认。只有用户确认后，这些代码才会被真正写入到步骤定义文件中。这相当于在“生成”和“落盘”之间加了一个人工检查点，防止AI“乱写”。

另一个工程上的处理点是异步到同步的桥接。MCP的客户端通信通常是异步的，但Behave这类BDD框架的运行是同步的。AutoGenesis在before_all钩子函数里，用janus.Queue创建了一个线程安全的队列，并启动了一个独立的异步事件循环线程来专门处理与MCP Server的通信。步骤函数通过一个同步封装函数来调用工具，这个函数把任务扔进队列，然后阻塞等待从结果队列中取出响应。

这种做法确保了测试步骤可以按顺序、同步地书写和执行，底层却是高效的异步IO。虽然代码看起来有些绕，但它解决了一个实际的集成难题，让成熟的同步测试框架能顺畅地驱动异步的AI工具协议。

谁适合用？明确方案的成本与适用边界

AutoGenesis展示的路径很吸引人，但它不是零成本银弹，有明确的适用边界。

它更适合的场景是：

1. 混合技能团队：团队里有懂业务的非开发人员（如外包测试、产品），希望让他们也能产出自动化资产。Gherkin+AI生成的方式，门槛降低是实实在在的。
2. 多平台产品：应用需要同时覆盖桌面端和移动端。一套基于MCP的抽象能统一生成和执行逻辑，避免为每个平台维护完全不同的脚本和工具链。
3. 需求相对稳定的核心场景回归：对于高频执行的冒烟测试、核心回归用例，AI生成一次脚本后，可以无限次低成本、稳定地重复运行，ROE（Return on Execution）很高。

而它的成本和限制也同样明显：

1. 前期基础设施投入：你需要搭建或适配MCP Server，配置好CI/CD管道来运行这些生成的Behave脚本。这不是一个“安装即用”的工具，更像一套需要运维的“测试代码生产线”。
2. 依赖特定AI服务：目前深度集成GitHub Copilot。虽然理论上可适配其他LLM，但开箱体验和工具调用的优化是围绕Copilot设计的。这带来了厂商绑定和额外的服务成本。
3. 对动态变化的界面仍需维护：AI生成的代码本质还是基于控件定位（如accessibility id, xpath）。当UI大改，定位器失效时，依然需要人工介入更新Gherkin描述或调整MCP工具的选择策略，AI不会自动适应。它解决的是“从需求到脚本”的生成效率，而不是“脚本自我修复”的维护问题。

收尾：一次关于自动化提效的架构启发

所以，看AutoGenesis，重点或许不该只是“微软又开源了个测试工具”，而是它在“AI能力应用”上展示的一种工程化态度：不追求Agent的全能自主，而是追求人机协同的确定性效率。

它把AI放在了“高级翻译”和“代码生成器”的位置上，用MCP协议这个“标准接口”框定了它的能力范围，然后把执行这个需要绝对可靠的任务，交还给了久经考验的本地自动化框架。这种架构上的清晰分隔，比单纯追求更强大的AI模型，可能更能解决当下工程中的实际问题。

如果你的团队正面临自动化覆盖率难以提升、测试脚本维护负担重的困境，这种“AI生成，本地执行”的范式值得作为一个选项进行技术评估。当然，你需要冷静衡量搭建和维护那条“MCP流水线”的初始成本，是否能在你团队的规模和应用场景下，被长期的效率收益所覆盖。它更像一个为中大型、多平台团队准备的“基础设施升级”方案，而非解决所有测试痛点的速效药。

最后留一个讨论点

如果你的团队也想引入类似的AI辅助测试，你会更倾向于选择“AI生成，本地执行”这种架构，还是探索“Agent自主执行”的路线？为什么？