서버 측 승인으로 에이전트 콘텐츠 게시 보호하기

정의

모델에는 읽기, 점수화, 초안 작성 기능을 주되 공개 쓰기는 명시적인 승인 이벤트로 실행되는 테스트된 서버 코드에만 맡기는 에이전트 아키텍처다.

관점

harsehaj (2026-08-24, X)

콘텐츠 에이전트에 웹사이트 쓰기 도구를 주지 마라. 소스를 조사하고, 기회를 점수화하고, 정밀한 편집 초안을 만든 뒤 기존 업무 채널에 Approve/Edit/Skip 카드를 게시하게 하라. 그 에이전트 실행은 종료하고, 이후의 클릭은 별도 서버 핸들러가 처리하게 하라. 그러면 잘못된 실행이 나쁜 제안을 만들 수는 있어도 사이트를 변경할 수는 없다.

판단은 변경 가능한 스킬 파일에 두고, 쓰기 경로는 에이전트의 모든 주장을 다시 검증하는 테스트된 코드에 둬라. 자동 편집은 대체 링크가 확인된 죽은 링크와 비어 있는 SEO 필드로 제한하라. 제목, 설명 또는 정확한 문구/링크 교체는 승인을 받도록 제안할 수 있지만, 그보다 큰 변경에는 Edit와 Skip만 표시하라. 첫 클릭에서 제안을 잠그고, 저장되지 않은 CMS 초안이 새 편집을 덮어쓸 상황이면 게시를 거부하라.

생성된 게시물은 미등록 초안을 만들기 전에 전략, 구조, 코드 출처와 쿼리 잠식을 검증하라. 에이전트에 두 번의 재작성 기회를 주고, 검증에 실패하면 기준을 약화하지 말고 중단하라. 이미 점유한 쿼리는 중복 게시물을 바꿔 말하는 대신 기존 게시물 감사로 돌려보내라.

적용

• 그럴듯하지만 잘못된 편집으로 인한 비용이 사람의 승인 지연보다 큰 공개 콘텐츠에 적합하다.
• 승인 핸들러를 에이전트 세션과 분리하고, 에이전트 워크플로우를 자동화로 승격하기에 따라 결정론적 검사만 승격하라.
• 헤드룸으로 SEO 편집 기회 점수화하기에서 편집 후보를 받아오고 서버가 게시를 확인한 뒤에만 측정을 시작하라.
• 롤백이 간단하고 승인 대기열의 비용이 오류보다 큰 무해한 비공개 초안에는 맞지 않는다.

한계

• Browserbase의 6주간 운영, 생성 게시물 18개와 편집 50+건은 자체 보고이며 사고율, 검토 시간, 오탐률은 제시되지 않았다.
• 안전하게 자동 게시할 수 있는 유형은 CMS에 따라 달라지며, 리디렉션, 현지화 또는 편집 소유권이 모호할 때는 여전히 잘못될 수 있다.
• Slack, Sanity, Postgres와 KV 세부 사항은 구현 선택일 뿐 이 경계의 필수 조건은 아니다.

Original link