오류 복구
Myrm의 오류 복구 시스템은 네트워크 장애, 모델 중단, 속도 제한 및 예상치 못한 오류가 발생하더라도 사용자 개입 없이 자동으로 에이전트가 계속 실행되도록 보장합니다.병렬 작업공간 병합 실패(GUI)
병렬 하위 에이전트가 격리된 작업 영역(ISOLATED_COPY)을 사용하고 일괄 병합 또는 sync_back이 실패하면 Myrm은 로그에서만 실패를 숨기지 않습니다.
- 채팅의 어시스턴트 메시지에 경고 배너 및 확장 패널(
WorkspaceMergeWarning)이 나타납니다. - 메시지 메타데이터(
workspaceMergeFailures) 및 페이지 다시 로드 생존에서 오류가 지속됩니다. - 턴은
completionStatus: warning로 완료되므로 출력이 불완전할 수 있음을 알 수 있습니다.
14레이어 복구 아키텍처
회로 차단기
회로 차단기는 모델 공급자가 다운될 때 계단식 오류를 방지합니다.주
오류 분류
자격 증명 풀
하나의 API 키가 비율 제한에 도달하면 시스템은 자동으로 사용 가능한 다음 키로 순환합니다.- 4가지 파견 전략(라운드 로빈, 최소 사용, 무작위, 우선 순위)
- 키별 오류 인식 쿨다운
- 키당 지수 백오프
- 쿨타임이 만료되면 자동 프로브
오류 진단
오류가 발생하면 시스템은 체계적이고 실행 가능한 피드백을 제공합니다.9개의 오류 카테고리
각 오류에는
error_hint, error_category(ToolErrorCategory StrEnum을 통한 28개의 표준 카테고리, 4개 언어로 완전히 i18n 번역됨) 및 제안된 RecoveryAction이 포함된 구조화된 컨텍스트가 포함되어 있으며 GUI에서 클릭 가능한 버튼으로 표시됩니다. 크로스 레이어 동기화 테스트 모음(46개 테스트)은 하네스 열거형 및 프런트엔드 i18n 키가 절대 표류하지 않도록 보장합니다.
대화형 복구 버튼
일반적인 LLM 오류의 경우 오류 카드에는 올바른 설정 페이지로 바로 이동할 수 있는 원클릭 수정 버튼이 포함되어 있습니다.
버튼 라벨은 5개 언어(영어, 중국어, 일본어, 한국어, 독일어)로 현지화되어 있으며 인터페이스 언어와 자동으로 일치합니다. 진단 엔진에 예기치 않은 오류가 발생하면 정상적으로 성능이 저하됩니다. 기본 오류 메시지는 복구 버튼 없이 계속 표시됩니다.
코드 실행 자동 진단
에이전트가 Python 코드 또는 Bash 명령을 실행하면 실행 엔진이 자동으로 오류를 분류하고 실행 가능한 힌트를 생성합니다.
엔진에는 내장된 PyPI로 가져오기 매핑 테이블(PIL → Pillow, sklearn → scikit-learn, yaml → PyYAML 등)이 포함되어 있으며
uv pip 사용 가능 여부를 자동 감지합니다. 모든 코드는 VenvManager가 관리하는 격리된 공유 가상 환경에서 실행되므로 사용자가 설치한 패키지가 시스템 Python을 오염시키지 않습니다.
투명 명령 자동 복구
힌트를 넘어, Myrm은 샌드박스 내에서 취약한 일반 명령을 결정적으로 자동 복구하여 Agent가 실패하기 전에 작업을 완료합니다. 셸 초기화 레이어(resilience_init.sh)가 실패 가능성이 있는 명령을 감싸 투명하게 대체합니다:
각 대체는 “프레임워크가 성공을 보장하기 위해 자동으로 대체했습니다”라는
[System Note: ...] 한 줄을 LLM에 돌려보내므로 모델은 바로 이어갑니다 — 재분석 없이, 추가 토큰 0, 수동 개입 0. 이는 경쟁사가 “실패 경험 검색”으로 달성하려는 런타임 의미 검색의 결정적 등가물이며, LLM 비용 0, 지연 0, 프롬프트 캐시 불변(노트는 동적 도구 출력 채널을 탑니다)을 보장합니다. 위의 규칙 기반 error_hint와 영속화된 반복 실패 규칙(tool_capture)과 결합하여 Agent는 취약 명령을 자동 복구할 뿐 아니라 세션 간에 도구가 어떻게 실패하는지도 학습합니다.
실패 원인 귀인 판별 (Fault-Side Attribution)
작업이 실패했을 때 가장 아픈 질문은 “실패했다”가 아니라 “누구의 잘못인가”입니다. 모델 환각? 도구 오류? 환경 설정? 아니면 사용자의 지시가 불명확했던 것? 경쟁사는 빨간 오류 블록만 던져주고 나머지는 사용자가 추측하게 둡니다. Myrm은 결정적 규칙으로 모든 실패를 여섯 가지 장애 측 중 하나에 귀인합니다 — 기존 오류 메타데이터의 순수 규칙 분류, LLM 비용 0:
귀인은 제품의 세 곳에 표시됩니다:
- 실시간 진행 단계 — SSE 진행 패널의 각 실패 단계에 fault-side 배지가 표시되어 재시도 / 모델 전환 / 입력 변경 / 에스컬레이션 여부를 한눈에 알 수 있습니다
- 실행 궤적 타임라인 — 궤적의 모든 오류 이벤트에 귀인이 붙어 사후에 근본 원인을 되짚어볼 수 있습니다
- 복구 동작 버튼 — 귀인된 오류는 클릭 가능한
recovery_actions버튼(API 키 업데이트, 잔액 충전, 모델 전환)을 가지며 올바른 설정 페이지로 바로 이동합니다
압축 삭제 감사
경쟁사가 이름조차 지을 수 없는 실패 모드: 컨텍스트 압축 이후 사용자의 제약이 요약기에 의해 삭제되었는지, 아니면 모델이 무시했는지. Myrm의dropped_manifest는 압축이 폐기한 모든 제약 조각을 기록하여 GUI가 둘을 정확히 구분할 수 있게 합니다 — 업계 유일의 압축 후(post-compaction) 귀인 능력입니다.
검증: harness fault_side 100% 커버리지 + trace_builder 98% + broadcaster 99%; 프런트엔드 fault-side 배지 렌더링 스위트 (66 vitest); server fault-side 소비 통합 (11개 테스트).
Shell 세션 자가 치유
Myrm은 호출마다 새 일회성 프로세스를 띄우는 대신 장수(長壽) 대화형 bash 세션에서 명령을 실행하므로cd, export, 환경 상태가 명령 간에 유지됩니다. 장수 세션에는 일회성 설계가 결코 마주치지 않는 두 가지 고장 유형이 존재하며, Myrm은 이를 결정적으로 해결합니다:
환경 변수 바이트 단위 정확 주입
환경 변수는 ANSI-C 인용($'…') 으로 bash에 주입되므로 $, 백틱, 큰따옴표, 줄바꿈, 탭, 캐리지 리턴이 포함된 값이 바이트 단위로 그대로 보존됩니다 — 다시 확장되지도 않고 초기화 배치를 깨뜨릴 수도 없습니다. "를 \\"로 이스케이프하는 순진한 방식은 값에 홀수 개의 "가 있을 때 큰따옴표 컨텍스트를 조기 종료시켜 bash가 PS2 연속 프롬프트에 갇히게 하고, 이후 모든 명령이 타임아웃됩니다. 실제 bash -c 서브프로세스를 실행하는 20개 파라미터 라운드트립 테스트로 검증되었습니다(따옴표 홀짝, 백슬래시, $HOME, 백틱, 줄바꿈/탭/CR, 유니코드, %, !, 빈 값).
웨지(멈춤) 자가 치유
차단 또는 stdin 삼키기 명령(cat, ssh, python -c "input()", tail -f)은 장수 셸을 영구적으로 독(毒)으로 만들 수 있습니다 — 이후 출력과 마커가 모두 삼켜집니다. Myrm은 이를 감지하고 투명하게 복구합니다:
- 타임아웃 자가 치유: 타임아웃된 명령은 전체 프로세스 그룹을 종료하고 세션을
TERMINATED로 표시합니다. 다음 execute/stream 호출은 세션을 투명하게 재구축합니다(env/cwd 재주입) - 경계 손상 감지: stdin 삼키기가 출력 마커를 원시 텍스트로 되돌리면 exit-code 필드 파싱이 실패 →
parse_failed플래그 → 동일한 종료+재구축 경로, 잘린 절반 출력을 LLM에 반환하지 않음 - 이중 경로 일관성:
execute와execute_stream(실시간 SSE) 모두 자가 치유를 트리거합니다
세션 수준 방어선
- 무작위 명령별 마커(
secrets.token_hex)가 출력을 분리하여 사용자 출력이 고정 구분자와 충돌할 수 없습니다 — 잘림 오판 없음 bash -n구문 사전 검사: 종결되지 않은 heredoc/괄호를 장수 프로세스에 닿기 전에 차단exit()인터셉터: 후행exit N이 셸을 종료하는 대신 명령 블록에서 반환합니다 — cwd/env 보존- 블록 내 rc 캡처 +
EXIT트랩:set -eerrexit 크래시에서도 완전한 마커 쌍과 실제 종료 코드를 출력 - 실시간 PII 스크러빙: 호스트 경로와 자격 증명 토큰을
execute및 SSE 스트림 경로에서 동일하게 마스킹
env.execute, jiuwenclaw sandbox daemon)는 상태를 지니지 않으므로 인용 또는 웨지 문제를 겪지 않습니다 — 그러나 호출마다 cd/export 상태를 잃고, 작업 중간에 자가 치유할 수 없습니다.
모델 자체 에스컬레이션
경량 모델이 작업을 완료할 수 있는 기능이 부족하다는 것을 감지하면 다음과 같습니다.- 모델은 특별한
<<<NEEDS_PRO>>>마커를 출력합니다. EscalationScrubber은 마커(사용자에게 숨겨짐)를 가로챕니다.- 에이전트는 구성된 강력한 모델로 자동 전환됩니다.
- 작업이 원활하게 계속됩니다.
루프 감지
7개의 독립적인 감지기가 다양한 유형의 에이전트 루프를 식별합니다.
감지는 점진적인 응답을 따릅니다. 먼저 상황 인식 제안이 포함된 경고가 에이전트의 상황에 주입된 다음 패턴이 지속되면 강제 중단됩니다(심각도: 경고 3-5x → 오류 6-9x → 위험 10+x).
압축 후 루프 보호
컨텍스트 오버플로가 긴급 압축을 트리거하면 LoopGuard는 전환을 정확하게 처리합니다.- 루프 감지 상태는 그대로 유지됩니다 — 슬라이딩 창(패턴 감지) 및 오류 서명은
ContextVar에서 작동하며 압축을 수정하는 메시지 목록에서 완전히 분리됩니다. - 반복 예산은 지능적으로 재설정됩니다 —
notify_compaction()은total_calls를 재설정하여 사전 압축 호출 기록으로 인해 에이전트가 조기 종료되지 않도록 하고 교차 압축 실패 추적을 위해error_signatures을 보존합니다. - 에이전트 단계가 보존됩니다 — 현재 실행 단계(탐색, 실행 등)가 이어지며 상황 인식 감지 임계값이 유지됩니다.
압축 후 메모리 보호
컨텍스트 압축 후에도 에이전트의 메모리 검색은 5계층 메모리 보호 아키텍처 덕분에 지연이나 데이터 손실 없이 완전히 그대로 유지됩니다.- SystemMessage는 압축에 면역: 사용자 프로필과 규칙은 위치 0에 SystemMessage로 삽입되며 압축 프로세서에 의해 절대 건드리지 않습니다.
- 학습된 컨텍스트는 압축에 면역: 학습된 컨텍스트는 도구 호출 쌍이 아닌 HumanMessage로 주입되므로 압축을 위해 선택되지 않습니다.
- PreCompactProcessor 사전 리콜: 압축하기 전에 시스템은 자동으로 벡터 데이터베이스 의미론적 검색을 트리거하고 관련 메모리를 독립형 메시지 블록으로 주입하여 압축 후 LLM이 중요한 메모리에 대한 액세스를 유지하도록 보장합니다.
- 실시간 벡터 인덱스: Qdrant 벡터 데이터베이스 항목은 쓰기 후 즉시 검색 가능 — 인덱스 지연 없음
- 독립 메모리 추출: 세션 종료 메모리 추출은 세션 내 압축의 영향을 받지 않고 원래 대화를 사용합니다.
반복 예산
에이전트에는 그래프 재귀 제한을 기반으로 동적으로 계산된 임계값을 사용하여 구성 가능한 반복 제한(기본값: 50)이 있습니다.
임계값은
graph_recursion_limit에서 자동으로 파생되고 도구 호출 수로 변환되므로 구성에 관계없이 예산 규모가 올바르게 조정됩니다. 유예 요약은 완료된 작업, 남은 작업 및 지속을 위한 제안에 대한 구조화된 요약을 제공합니다.
자동 도구 재시도
일시적인 오류(네트워크 시간 초과, 속도 제한, 일시적인 사용 불가능)로 인해 도구 호출이 실패하면 시스템이 자동으로 재시도합니다. 사용자에게는 하트비트 타이머가 작동하는 모습만 표시되며 실패는 표시되지 않습니다.6계층 재시도 아키텍처
경쟁사와 다른 점
- 프롬프트 기반이 아님: 재시도 논리는 무시될 수 있는 LLM 명령어가 아닌 결정론적 코드(Pydantic 스키마 + 카운터)입니다.
- 개발자 전용 아님: 프레임워크 수준 재시도 구성(예: LangGraph의
RetryPolicy)과 달리 하트비트 UI는 최종 사용자에게 가시성을 제공합니다. - 시끄럽지 않음: 재시도가 자동으로 진행됩니다. 오류 팝업이 표시되지 않으며 일시적인 오류에 대해 사용자 결정이 필요하지 않습니다.
도구 피드백 무시 가드
약한 모델은 종종 도구 피드백을 무시합니다. 도구가 명확한 복구 불가 오류를 반환했는데도 모델이 변형을 바꿔가며 재시도하고, 무관한 도구로 전환하거나, 답을 지어냅니다 — 토큰을 낭비하고 반쯤 완성된 작업을 내놓습니다. 학술 연구(Scale AI의 Tool Feedback Neglect 논문, Zhou et al. 2024)는 이를 별도의 failure mode로 식별했지만 모든 경쟁사는 연구만 있을 뿐 제품이 없습니다. Myrm은 런타임 가드를 출시했습니다:
검증: 터미널 가드 단위 스위트(20) + 계열 분류 분기 커버리지(12) + 레지스트리 2채널 의미(9) + 전체 체인 미들웨어 통합(7) + 서버 E2E 결정론적 재작성(연속 8회 통과) + Chrome E2E 실제 세션 통과 + 전체 회귀 4116 passed, 2 skipped(2026년 8월).
파일 체크포인트
파괴적인 파일 작업 전에AutoSnapshotInterceptor은 자동으로 스냅샷을 찍습니다.
- 6가지 도구 범주를 다룹니다:
write_file,patch_file,delete_file,move_file,execute_terminal,code_execute - 턴당 중복 제거로 중복된 스냅샷을 방지합니다.
- 스냅샷을 사용하면 GUI에서 한 번의 클릭으로 롤백이 가능합니다.
데이터베이스 안전
5계층 보호 시스템은 데이터(대화, 예약된 작업, 추억)가 어떤 장애에서도 살아남도록 보장합니다.
다단계 테이블 재구축 마이그레이션(예:
CREATE TABLE AS SELECT → DROP → RENAME)은 완벽하게 보호됩니다. 마이그레이션 도중 프로세스가 중단되면 마이그레이션 전 백업이 깨끗한 복원 지점을 제공합니다.
하위 에이전트 오류 압축
긴 추적으로 인해 하위 에이전트가 충돌하는 경우 상위 에이전트의 컨텍스트에 도달하기 전에 오류 메시지가 자동으로 압축되어 상위 에이전트의 추론 품질을 저하시키는 오염을 방지합니다.
이는 일반적인 다중 에이전트 실패 패턴, 즉 하위 에이전트의 자세한 충돌 출력이 상위 컨텍스트 창을 소비하여 에이전트 계층 전체에 걸쳐 계단식 추론 성능 저하를 일으키는 것을 방지합니다.
실패 시 하위 에이전트 부분 진행
하위 에이전트가 실행 중에 실패하면(LLM 오류, 예산 초과, 시간 초과 또는 런타임 예외) 누적된 모든 작업이 보존되어 상위 에이전트에 반환되며 손실되지 않습니다.이것이 중요한 이유
부분적인 진행률 보존이 없으면 속도 제한에 도달하기 전에 복잡한 작업의 80%를 완료한 하위 에이전트는 모든 작업을 잃게 됩니다. 상위 에이전트는 처음부터 시작해야 합니다. 즉, 이미 소비된 토큰을 낭비하고 비용이 두 배로 늘어납니다. Myrm의 접근 방식:- 부모는 완료된 모든 작업을 구조화된 출력으로 받습니다.
- 상위 에이전트는 하위 에이전트가 중단된 지점부터 다시 시작할 수 있습니다.
- 성공한 부분에 대한 토큰 비용이 낭비되지 않습니다.
- 너무 긴 부분 출력은 자동으로 잘립니다(
max_error_chars * 2을 통해 구성 가능).
경쟁사 비교
Myrm은 에이전트 계층 구조의 모든 수준에서 연속적인 오류에 대한 심층 방어를 제공합니다.
기존 마이크로서비스 종속성 체인과 달리 LLM 에이전트에는 명시적인 도구 DAG가 없습니다. LLM은 런타임에 호출 순서를 결정합니다. Myrm은 존재하지 않는 도구 종속성을 모델링하려고 시도하는 대신 인프라 수준 회로 차단, 동작 패턴 감지 및 계층적 취소 등 올바른 추상화 수준에서 연쇄 오류를 해결합니다.
검증됨: 모든 계단식 오류 보호 모듈(LoopGuard, FrequencyGuard, E-Stop, ToolCallBroadcaster, SubagentExecutor, CircuitBreaker, ToolGuards)에 걸쳐 604개의 테스트를 통과했습니다.
폭풍 및 예산 보호 재시도
Myrm은 폭주 재시도 루프를 적극적으로 방지하고 API 예산을 보호합니다.
이는 수동적 모니터링(로그 및 경고만)이 아닌 활성 잘림(즉시 실행 중지)입니다. 재시도 폭주가 감지되면 에이전트는 강제로 중지되고 어떤 결과가 나오든 최선의 답변을 제공해야 합니다. 즉, 클라우드 컴퓨팅 비용과 로컬 API 키 밸런스를 모두 보호합니다.
검증됨: 모든 재시도 보호 모듈(LoopGuard, FrequencyGuard, BudgetGuard, MultiDimensionBudgetGuard, BudgetBoundaryMiddleware)에 걸쳐 330개의 테스트를 통과했습니다.
예산 보호
Myrm은 모든 배포 모드에 걸쳐 포괄적인 예산 제어 기능을 제공합니다.- MultiDimensionalBudgetGuard: 4단계 점진적 응답으로 세션당, 일일 및 호출당 USD 한도(확인 → 경고 → 마무리 → 초과)
- 동적 예산 힌트: 예산이 WARNING(경고) 또는 FINALIZATION(확정) 상태로 떨어지면 정확히 남은 USD가 LLM 프롬프트에 주입됩니다. AI는 지출할 수 있는 금액을 정확히 알고 그에 따라 행동을 자체 조정합니다.
- BudgetBadge: 색상으로 구분된 상태와 함께 사용 비율을 표시하는 채팅 입력 영역의 실시간 예산 표시기
- BudgetExceededDialog: 예산 초과 시 원클릭 충전 또는 계획 업그레이드
- ChannelBudget: 각 IM 채널(Telegram, WeChat 등)에 대한 독립적인 예산 한도
- BudgetPolicySection: 확정 예비비로 예산 정책을 구성하기 위한 전체 UI
- DailyChart: 캐시 적중률 오버레이를 통한 30일간의 사용 추세
데이터 수명주기 관리
Myrm은 모든 스토리지 엔진에서 데이터 보존을 자동으로 관리하므로 수동 정리가 필요하지 않습니다.- 9개의 자동 스케줄러: 컨텍스트 파일(3계층: 30d/14d/7d), 인증 로그(보존 구성 가능), 채팅 휴지통(30일 자동 제거), SQLite WAL 체크포인트(6시간마다), 데이터베이스 순환 백업, Qdrant 세그먼트 최적화, 브라우저 좀비 감지(48시간 임계값), Kanban GC, 시크릿 자동 삭제(1시간)
- MemoryGuardian: 적응형 유지 관리 빈도 — 정상일 때는 6시간마다, 성능이 저하되면 2시간마다. 상태 점수(70개 정상/35개 심각)는 2회 연속 비정상 검사 후 자동 강제 유지 관리를 구동합니다.
- 파일 액세스 추적:
file_access_tracker을 통해 참조된 컨텍스트 파일이 실수로 삭제되는 것을 방지합니다. - 스케줄러 상태 API: 모든 백그라운드 스케줄러에 대한 실시간 녹색/노란색/빨간색 상태 모니터링
- 핫 백업: 유지 관리 주기마다 자동 SQLite 핫 백업
스킬 진화 — 자기 개선 에이전트
Myrm의 에이전트는 실패로부터 학습하고 자율적으로 기술을 발전시킵니다.- 자동 진화: 스킬이 실패하거나 부정적인 피드백을 받으면 시스템은 임시 프롬프트 패치가 아닌 스킬 자체를 업데이트하는 진화 제안을 생성합니다.
- 수명 주기 검토: 안전한 변경 사항이 자동으로 적용됩니다. 위험한 항목은 승인/거부 워크플로를 통해 검토 가능한 성장 사례가 됩니다.
- 의미적 중복 제거: 유사성 검사 기능으로 스킬 엔트로피를 방지합니다. 중복되거나 거의 동일한 스킬을 저장하기 전에 잡아냅니다.
- 경험 원장: 모든 진화 이벤트(14종)는 감사 및 분석을 위해 영구적으로 기록됩니다.
- 품질 경고: 기술 품질이 저하되면 Webhook 알림을 보내 사전 유지 관리가 가능합니다.
사용자가 경험하는 것
모든 복구는 투명하게 이루어집니다.- 모델이 다운되나요? — 밀리초 단위로 백업으로 자동 전환
- 네트워크 중단? — 스트림이 중지된 정확한 토큰에서 다시 시작됩니다.
- 속도가 제한되어 있나요? — 키 순환 또는 백오프 후 재시도
- API 키가 만료되었습니까? — 오류 카드에서 바로 버튼을 클릭하여 업데이트할 수 있습니다.
- 에이전트 루프? — 예산이 낭비되기 전에 조기에 감지됩니다.
- 응답이 잘렸나요? — 텍스트 잘림: 점진적인 출력 부스트(2x/3x/4x, cap 32768)로 원활한 유지+계속; 도구 잘림: 유효하지 않은 삭제 + 자동 재시도; JSON 잘림: 로컬 복구. 5가지 공급자 형식(Anthropic, OpenRouter, LM Studio, vLLM, DashScope)에 대한 출력 한도 자동 복구. SSE 5개 언어로 상태 알림. 388개 출력 한도 + 294개 잘림/복구 테스트 확인(2026년 7월)
- 업그레이드가 중단되었나요? — 마이그레이션 전 스냅샷이 데이터를 자동으로 복원합니다.
- 하위 에이전트가 충돌합니까? — 오류가 자동으로 압축되고, 상위가 명확한 요약을 받고 추론이 오염되지 않은 상태로 유지됩니다.
- 도구 호출이 실패합니까? — 하트비트 타이머를 사용한 자동 재시도; 오류 대신 “실행 중… 15초”가 표시됩니다.
- 실행 가능한 복구가 포함된 스트림 오류? — 오류에는 채팅 UI에 직접 있는
recovery_actions버튼(재시도, 모델 전환, 종속성 설치)과 i18n 오류 메시지 및 단계별 해결 가이드가 포함된diagnostic_result이 포함됩니다. 추측할 필요가 없습니다. 제안된 작업을 클릭하기만 하면 됩니다. - 반복적인 실패? — 3-Strike 프로토콜은 도움을 요청하기 위해 자동으로 에스컬레이션됩니다. 무한 루프가 없습니다.
- 환경이 손상되었나요? — Doctor Dashboard는 9개의 병렬 진단 프로브(Python 버전, 종속성, LLM 연결, 네트워크, 작업 공간 저장소, 데이터베이스, 브라우저, 후크, 데스크톱 제어)를 실행하고 원클릭 복구 작업으로 상태를 한눈에 보여줍니다. 터미널 액세스가 필요한 CLI 전용 경쟁업체와 달리 GUI 건강 카드는 실행 가능한 수정 버튼을 통해 실시간 상태를 표시합니다.
- SSE 작업 중간에 연결이 끊어지나요? — 목표 진행률 패널은 다시 연결할 때 오래된 표시기를 자동으로 지우고 서버에서 다시 동기화하며 완료된 단계를 보존합니다. 고스트 스피너가 없고 에이전트가 중지된 후 오해의 소지가 있는 “진행 중”이 없습니다.
- 실행 중인 작업을 취소하시겠습니까? — 엔드투엔드 취소는 0.5초(CancellationMonitor 폴링 간격) 내에 전체 실행 체인을 통해 전파됩니다. 백그라운드 작업 종료, 하위 에이전트 계단식 취소, 리소스 정리, 토큰 레지스트리 등록 취소
- 장기 작업 중에 연결이 끊어지나요? — 유예 기간 허용 범위는 작업을 활성 상태로 유지합니다. 연결 끊김이 지속되면 OfflineDurableTask는 완료 시 사용자 알림과 함께 백그라운드 완료 작업을 등록합니다. 백그라운드 프로세스(npm install, webpack watch, 테스트 스위트)는 SSE 스트림에서 완전히 분리된 프로세스 수준 싱글톤 레지스트리에 의해 관리됩니다. 페이지를 새로 고치거나 다시 연결해도 라이브 데몬 세션이 종료되지 않습니다. SSE 재연결에서는 무손실 이벤트 재생을 위해 5MB 슬라이딩 창 버퍼가 있는 Last-Event-ID를 사용합니다 — 중복·유실·순서 뒤섞임이 없습니다. 스트리밍 동시성이 강화되어 느린 소비자(약한 네트워크 모바일)가 다른 클라이언트를 막지 않습니다. yield 지점이 공유 조건 잠금 밖에 있어 여러 기기에서 같은 라이브 세션을 서로 차단 없이 볼 수 있습니다. 4개 배치(레지스트리, 스트리밍, 재연결)에 걸쳐 검증된 108개 테스트 + 스트림 버퍼 동시성 15개(느린 소비자 격리, 하트비트, 다중 소비자 팬아웃)
- 서버가 목표 중간에 다시 시작됩니까? — 고아 목표는 명확한 이유에 따라 자동으로 일시 중지됩니다. 다음 시작 시 LangGraph 체크포인트에서 내구성 있는 작업이 재개됩니다. 반복 작업이 전혀 없습니다.
- 일반 대화 중 프로세스 충돌이 발생합니까? — InterruptedTurnMarker는 모든 에이전트 스트림 전에 내구성 있는 미리 쓰기 레코드를 작성합니다. 다시 시작하면 채팅 기록 다시 로드, 메시지 지속성, 충돌 루프 차단기(최대 2회 시도), 15분 새로 고침 창 및 성공 또는 실패에 대한 사용자 알림을 통해 백그라운드 지속을 위해 적합한 마커가 스캔되고 자동으로 전달됩니다.
autoContinueInterruptedTurns설정을 통해 사용자가 제어 가능(기본값: 활성화됨) - 긴급 정지가 필요합니까? — E-Stop API(
/freeze)은 한 번의 호출로 전역적으로 모든 활성 에이전트 스트림을 취소합니다. — 생산 사고에 대한 패닉 버튼