에이전트 🇷🇺 24.07.2026 16:01

Building an Agent for Elementor Page Assembly: From Idea to a Working Pipeline

WordPressWordPress ElementorElementor FigmaFigma
A developer shared their experience creating an agent that builds WordPress + Elementor pages from Telegram requests. Key issues included task loss during parallel requests, duplicates, mixing questions with final answers, Elementor indentation errors, and difficulty integrating with Figma. Solutions involve a SQLite task queue, a CLI interface for states, a default beta environment, and a strict Python compiler for Figma.
개발자가 WordPress와 Elementor로 페이지를 조립하고 Telegram과 통합되는 AI 에이전트를 만든 과정을 설명했다. 첫 번째 버전은 Elementor의 MCP 도구를 사용했지만, 사용자가 즉시 응답하지 않으면 작업이 유실되고, 반복 요청 시 작업이 중복 생성되며, 에이전트가 스킬을 거치지 않고 직접 MCP를 호출하려는 문제가 빠르게 드러났다. 이를 해결하기 위해 SQLite 기반 작업 대기열을 도입하여 사용자의 질문 전에 기록을 생성하고, 열린 작업을 확인하며, 작업을 엄격히 스킬에 위임하도록 했다. 복합 질문(compound question)의 경우 CLI next-question을 구현하여 한 번에 하나씩 질문하도록 했다. 또한 작업 상태를 대기 중(waiting), 차단됨(blocked), 완료됨(done)과 같은 차단 상태와 준비됨(ready) 같은 비차단 상태로 구분하여, 에이전트가 사용자 없이도 가능한 단계를 계속 수행할 수 있게 했다. 테스트 격리를 위해 기본적으로 페이지 생성은 베타 환경에서 이루어지며, 프로덕션 전환은 별도의 전송 워크플로(transfer workflow)를 통해서만 가능하다. Elementor의 여백 문제는 elementor-spacing-builder.md 모듈로 해결했으며, 컨테이너와 위젯 간 차이를 수정한다. 최종 응답은 별도의 CLI result_cli.py로 분리하여 워크플로 질문과 분리했다. 조립 품질은 CLI로만 확인하며, 자체 검증(self-asserting)은 금지된다. 가장 어려웠던 부분은 Figma와의 통합이었다. 초기 컴파일러 버전은 정보를 유실했고, 이후 Figma JSON을 Elementor JSON으로 직접 변환하는 엄격한 Python 컴파일러로 전환했다. 14번째 버전에서는 의미 트리(semantic tree)를 추가하여 의미론과 레이아웃을 분리했다. 또한 에셋 내보내기를 최적화하여 VECTOR 경로는 SVG로 내보내지 않고, 명시적으로 지정된 컴포넌트만 내보낸다.
출처: Habr — хаб ИИ — 원문
관련 게시물 ↓
새로운 뉴스