求教：是否有开发者尝试用C++反射替代扁平化MCP工具集？

我是一名EDA（电子设计自动化）软件开发人员，开发类似KLayout或FreeCAD的产品，技术栈涵盖C++、Qt、Vulkan、vcpkg和CMake。今年我的核心目标是为软件打造AI助手，终极愿景是实现AI独立完成电路版图的绘制与布线。

要让AI像人类工程师一样工作，必须能感知并操控软件内的所有对象，这一需求的实现难度远超预期。最初我尝试封装大量MCP（Model Context Protocol）工具，比如触发菜单栏操作、读取版图对象的工具，但这种方式极为繁琐。我的核心数据结构基于library -> cell -> geo (polygon, path, rectangle, label)，为适配AI，不得不编写碎片化的getter接口，如get_library_cell、get_cell_polygon、get_cell_path，还要添加find_box_xxx、find_layer_xxx等快速查询接口——这完全是样板代码的噩梦！

这种模式就像初学C语言时，写数百个孤立函数再在main()里拼凑，属于被迫的过程式编程。接口间难以交互，所有内容碎片化、语义重复且相互孤立。作为面向对象程序员，我厌恶这种扁平化工具列表，也不愿在架构完善的程序上搭建怪异的二次API层。我一直在思考：为何不能让AI像调试时手动修改对象那样直接控制运行时对象？

于是我转向了另一种方案：使用**RTTR（Run Time Type Information and Reflection）**构建反射库。现在我只需用RTTR宏来反射想要操控的C++类，完成反射后，任何AI客户端都能直接读写运行时对象的属性并调用其方法。

这种方案的效果极佳：我让cell内的所有geo对象具备代理感知能力，AI现在可以原生地感知并操控它们。相比手动封装数百个MCP工具，我现在只需编写宏来反射library、cell、geo等类，就能在AI语境中1:1操作它们，软件中的每个类、接口和属性都完美映射给AI，无遗漏无冗余。说实话，我认为这种方式更符合编程逻辑，否则AI就得像在main()里用数百个函数做过程式编程，而非和我们一样使用OOP模式。

请问是否有其他开发者尝试过这种基于反射的方案来替代扁平化MCP工具？期待交流想法！

内容的提问来源于stack exchange，提问作者YouthDuGan