构建Elementor页面组装代理：从想法到工作流程

一位开发者分享了自己打造一款AI智能体的经历——该智能体用于在WordPress和Elementor上构建页面,并与Telegram集成。第一版使用了针对Elementor的MCP(Model Context Protocol,模型上下文协议)工具,但很快就暴露出问题:如果用户没有立即回复,请求可能会丢失;重复发起相同请求会导致任务被重复创建;此外,智能体还会绕过技能(skill)直接调用MCP。 为了解决这些问题,开发者引入了基于SQLite的任务队列:在向用户提出任何问题之前先创建一条记录,同时检查是否存在未完成的任务,并制定了严格规则,要求将具体工作委派给技能来执行。针对复合型问题,他们实现了CLI(命令行界面)工具next-question,确保每次只问一个问题。任务状态也被拆分为阻塞型(等待中、被阻塞、已完成)和非阻塞型(就绪),这样一来,只要某个步骤无需用户输入即可执行,智能体就会继续推进流程,而不会被卡住。 为了实现测试隔离,页面创建默认在beta(测试)环境中进行,只有通过单独的迁移工作流才能将其提升到生产环境。Elementor的间距错误问题则通过新增的elementor-spacing-builder.md模块得以解决,该模块修复了容器(container)与组件(widget)之间的差异问题。最终答案的输出也被移到了独立的CLI模块result_cli.py中,使其与工作流中的提问环节解耦。构建质量的校验完全依赖CLI完成,严禁智能体自我断言(即自行宣称任务已完成而不经验证)。 整个项目中最具挑战性的部分是与Figma的集成:早期版本的编译器在转换过程中会丢失信息,后来团队改用了一套严格的Python编译器,可以直接将Figma的JSON数据转换为Elementor所需的JSON格式。到第14个版本时,项目引入了语义树(semantic tree)机制,将语义信息与布局信息分离开来。此外,资源导出流程也得到了优化:矢量路径(VECTOR paths)不再被导出为SVG格式,只有明确指定的组件才会被导出。