问题
在API智能体直播课中有提及到使用swagger解析成mcp tools 实现API自动化，可否提供一些更详细的设计思路，如一个业务场景是由一组API组成的，1）如何解决上下文传值 2）给大模型指定的业务场景，大模型又是根据什么来确定需要调用哪些API组合等
api文档
最早公司做这块技术的时候，我们用的是swagger。我们使用这个技术呢，去获取API的一些说明这个方案的优点是，它的确有API非常完整的信息结构，同样缺点也很明显，有的公司里面，它不是不使用swagger, 或者说有的公司里面本身已经沉淀了大量的API，那这些API其实是一些网页啊，word之类的一些结构，那典型的比如说像企业微信啊，飞书。所以我们做的第二版呢，已经不带严格的限制说一定要使用swagger了，我们其实就使用最万能的通用的文档就可以了只要这个文档里面有详细的结构信息，那么API都是可以，AI都是可以识别的啊，所以我比较推荐使用标准的文档格式，而不是再去遵从斯瓦格这个规范了
流程定义
然后再说流程，流程在传统的API文档里面的确是得不到一个很好的表达。那所以呢，我也是为什么推荐说我们就使用普通文档就可以了。那至少普通文档里是有接口的一个顺序的啊。所以呢，我们同样让AI去分析接口文档就可以了。这个接口文档是接口相关的文档啊，不再是swag了。
站在一个大模型的上下文里，如果说你想让它推理出来具体接口的一个调用顺序，那么对那个上下文里面它就必须要包含接口本身的文档定义啊，然后是接口的顺序的这个参考文档。接着你就可以让大模型帮你去生成对应的流程调用了啊，无论是基于react还是说直接去生成pytest的代码。所以上下文工程才是整个技术里面，最核心的一个技术。
传值
大模型的传值问题，也是一个比较经典的问题，这个传值呢，大模型自己会根据接口的定义，是能猜出来一部分的当然，如果说只是指望这个，也不一定完整，所以一般我们都会通过去加一些提示词来去解决它在提示词里面明确说明，那什么样的参数，它的业务含义是什么，需不需要要在多个多个接口之间进行传递。
好，那最后总体给你总结一下哈。想用AI去做接口测试呢，我可以不用严格再去依赖于Spark文档了。理论上说，普通的网页文档任何的文档都是可以的。然后这个文档里面它必须要包含接口本身的定义，一些重要概念的规则的一个定义啊，可以是文档也可以是你的提示词补充啊。如果说再带上一些对应的案例，比如你过去抓包的一些历史记录，或者说你给的一些参考的事例，那也是可以的。最后呢，让大模型整体再进行内容的一个生成啊，这就是用AI做结构测试的一个思路哈，它其实跟做我们UI自动化是一样的。
