승인 대기열은 AI 제안과 홈 서버 작업을 어떻게 분리하나요?

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

승인 대기열은 제안된 도구 호출을 독립적인 결정으로 실행할 수 있을 때까지 보류 상태로 저장하여 AI 제안과 홈 서버 작업을 분리합니다.

이를 통해 영향이 큰 자동화를 2단계 시스템으로 전환할 수 있습니다. 에이전트는 정확한 작업을 준비할 수 있지만, 승인과 재검증이 완료될 때까지 파일, 서비스, 계정, 장치는 변경되지 않습니다.

에이전트는 먼저 부작용이 아닌 제안서를 생성합니다

승인 대기열은 영향이 큰 결정의 결과를 즉시 실행에서 보류 작업 생성으로 바꿉니다.

모델은 여전히 매개변수를 입력할 수 있지만, 외부 시스템은 아직 변경되지 않습니다.

Temporal의 승인 패턴은 외부 승인 결정이 도착할 때까지 워크플로 실행을 차단하는 방식을 설명합니다. 대기는 워크플로 상태의 일부입니다. LangChain의 휴먼 인 더 루프 미들웨어는 실행 전에 도구 호출을 중단할 수 있으며, 이는 LangChain 휴먼 인 더 루프 미들웨어에서 설명하는 제안 우선 경계를 보여 줍니다.

따라서 삭제, 권한 변경, 컨테이너 재시작 또는 대량 이동을 검토 가능한 데이터로 만들면서 대상은 변경되지 않은 상태로 유지할 수 있습니다.

보류 기록은 검토 중인 작업을 고정합니다

대기열에는 도구 이름, 대상, 인수, 요청자, 사유, 생성 시간을 보존해야 합니다. 이러한 필드를 고정하면 승인이 포괄적인 권한으로 변질되는 것을 막을 수 있습니다.

Temporal의 휴먼 인 더 루프 예제는 신호 기반 승인과 지속 가능한 대기를 사용하며, 워크플로가 대기 중에도 상태를 유지하는 방식을 보여 줍니다. Temporal은 승인을 워크플로의 대기 상태로 모델링하므로, Temporal 승인 패턴에서 보듯 보류 작업 기록과 최종 부작용을 분리하여 유지할 수 있습니다.

제안 내용이 Jellyfin 재시작이라면, 해당 승인이 나중에 PostgreSQL을 재시작하는 변경까지 허가해서는 안 됩니다.

중요한 매개변수 변경이 발생하면 기존 결정을 무효화해야 합니다.

검토자는 승인, 수정, 거부 또는 만료를 선택합니다

승인은 반드시 이진적일 필요가 없습니다. 검토자는 작업을 거부하거나, 변경 없이 승인하거나, 제한된 매개변수를 수정하거나, 상황이 오래되어 의미가 없어졌을 때 만료시킬 수 있습니다.

Temporal은 워크플로 신호를 통해 승인 데이터를 수집합니다. 따라서 검토자 메타데이터가 지속적인 워크플로 상태의 일부가 됩니다. AWS Step Functions는 계속 진행하기 전에 일시 중지하는 사람 승인 워크플로를 제공하며, AWS Step Functions 사람 승인에서 설명하는 승인 또는 거부 전환을 보여 줍니다.

수정 범위는 제한되어야 합니다. 검토 UI가 임의의 셸 명령으로 교체하는 것을 허용하면, 이는 의사 결정 관문이 아니라 제한 없는 두 번째 도구 인터페이스가 됩니다.

실행 시 오래된 컨텍스트를 신뢰하지 말고 재검증해야 합니다

승인은 제안이 생성된 후 한참 뒤에 도착할 수 있습니다. 그동안 파일이 이동하거나, 서비스가 복구되거나, 권한이 변경될 수 있습니다.

지속 가능한 워크플로는 결정이 전달될 때까지 차단된 상태로 유지될 수 있습니다. 그런 다음 실행기는 승인된 매개변수를 기준으로 스키마 검사, 권한 부여, 사전 조건을 다시 실행해야 합니다. Camunda는 명시적인 워크플로 구조 안에서 에이전트 작업을 지원하며, Camunda 에이전트형 워크플로 제어에서 보듯 이전에 제안된 작업을 실행하기 전에 상태를 재검증해야 한다는 점을 강조합니다.

이를 통해 승인이 오래된 가정을 고정하는 것을 방지할 수 있습니다. 대상이 이제 다른 버전을 가리킨다면 삭제를 거부할 수 있고, 서비스가 이미 정상 상태라면 재시작을 건너뛸 수 있습니다.

승인은 스키마와 권한 위에 추가되는 경계를 만듭니다

스키마 검증은 작업이 구조적으로 유효한지 확인합니다. 권한 부여는 호출자가 해당 작업을 수행할 수 있는지 확인합니다.

승인은 유효하고 권한이 부여된 이 특정 부작용을 지금 실행해도 되는지 확인합니다.

ZimaSpace의 읽기 전용 홈 AI 에이전트 전략은 수정 전에 관찰할 것을 권장합니다. MCP 도구 지침은 도구 호출과 사용자에게 표시되는 제어를 별개의 문제로 다루며, MCP 도구 안전 지침에서 스키마, 권한, 승인 사이의 계층적 관계를 뒷받침합니다.

동일한 경계는 ZimaSpace의 셀프 호스팅 에이전트 승인 게이트 예제에도 나타납니다. 여기서는 게이트가 설정된 도구가 변경 사항을 자동으로 적용하지 않고 검토를 위해 일시 중지됩니다.

우회 경로를 차단해야 대기열이 효과를 발휘합니다

동일한 에이전트가 이에 상응하는 제한 없는 엔드포인트를 직접 호출할 수 있다면 승인 시스템은 실패합니다. 영향이 큰 경로는 동일한 적용 경계를 공유하거나 별도로 차단해야 합니다.

MCP는 민감한 작업에 대해 명시적인 사용자 확인을 권장합니다. 승인 대기열은 이러한 확인을 지속 가능하고 감사 가능한 방식으로 만듭니다. Microsoft Agent Framework는 실행 전에 승인이 필요하도록 함수 도구를 표시할 수 있으며, 이는 실행 경로가 승인 계층을 우회할 수 없을 때에만 승인 계층이 작동하는 이유를 보여 줍니다. 자세한 내용은 Microsoft Agent Framework 도구 승인을 참조하세요.

위험이 낮은 읽기 작업은 여전히 자동으로 실행할 수 있습니다. 목표는 마찰을 최대화하는 것이 아니라 제안과 부작용 사이에 강제 적용 가능한 전환 단계를 만드는 것입니다.

기술 및 AI 허브

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.