LangChain 다중 에이전트 핸드오프: 감사 상태, 컨텍스트 및 결과

LangChain 다중 에이전트 핸드오프 의 경우 성공적인 전송 도구 호출은 첫 번째 증거일 뿐입니다. 선언된 경로가 허용되고, 제어 상태가 의도한 에이전트로 이동하고, 도구 호출 주기가 닫히고, 필요한 컨텍스트가 도착하고, 대상이 유용한 작업을 시작하고, 요청된 결과가 독립적으로 확인되면 핸드오프를 정상으로 간주합니다. 손상된 전송 후에도 그래프가 계속 실행될 수 있기 때문에 이 답변이 중요합니다. goto 는 한 노드의 이름을 지정할 수 있지만 active agent 는 여전히 다른 노드의 이름을 지정할 수 있습니다. 전송 도구는 일치하는 도구 응답 없이 반환될 수 있습니다. 새 에이전트는 불완전한 컨텍스트로 시작할 수 있습니다. 또한 외부 작업이 완료되지 않은 상태에서 세련된 최종 메시지를 생성할 수도 있습니다. 이 가이드는 이러한 경계를 콘텐츠 없는 영수증으로 바꾸고 8가지 합성 사례를 재생합니다. 예시는 2026년 7월 30일에 검색된 공식 LangChain 및 LangGraph 문서를 반영합니다. 해당 확인에서 PyPI는 보고했습니다.LangChain 1.3.14그리고LangGraph 1.2.10. 상태 및 스트리밍 계약이 변경될 수 있으므로 종속성 버전을 고정하고 다시 확인하세요. 상태 기반의 직접적인 대화를 위한 핸드오프 선택 LangChain의핸드오프 문서상태를 통해 패턴을 정의합니다. 도구는 current step 또는 active agent 와 같은 변수를 업데이트합니다. 후속 모델 구성 또는 그래프 라우팅은 해당 변수를 읽습니다. 상태는 턴에 걸쳐 지속되므로 현재 활성 전문가가 사용자와 계속 직접 대화할 수 있습니다. 이는 다음과 같은 경우에 적합합니다. 대화는 순차적인 단계를 거쳐 진행됩니다. 기능은 전제 조건 후에만 잠금 해제되어야 합니다. 활성 전문가는 다음 턴에도 제어권을 유지해야 합니다. 사용자는 해당 전문가와 직접 상호 작용해야 합니다. 작업이 복잡하다고 해서 여러 에이전트로 시작하지 마세요. 공식다중 에이전트 개요적절한 도구와 동적 지침을 갖춘 단일 에이전트가 작업을 수행할 수 있는 경우가 많다고 합니다. 이는 핸드오프를 하위 에이전트, 스킬, 라우터 및 사용자 정의 워크플로와 구별합니다. "에이전트"의 신원이 대부분 프롬프트, 도구 또는 단계의 변경인 경우 합리적인 기본값은 하나의 에이전트와 미들웨어입니다. 전문가가 완전히 다른 상태, 도구, 수명 주기 논리 또는 소유권을 필요로 하는 경우 별도의 에이전트 하위 그래프를 선택하십시오. 해당 선택은 증거 계약에 영향을 미칩니다. 미들웨어가 포함된 단일 에이전트: 상태 변수가 변경되었고 다음 모델 호출이 의도한 구성을 수신했음을 증명합니다. 다중 하위 그래프: 또한 그래프 라우팅이 대상에 도달했고 대상이 올바른 컨텍스트를 수신했음을 증명합니다. 핸드오프는 상태 저장 및 다중 홉입니다. 이는 병렬 팬아웃을 위한 자연스러운 선택이 아니며 전문가가 사용자의 작업을 완료했음을 스스로 증명하지 않습니다. 6개의 경계를 순서대로 감사합니다. 문서화된 다중 하위 그래프 예는 goto 가 포함된 Command , active agent 업데이트, ToolMessage 및 graph=Command.PARENT 를 반환합니다. LangChain에서는 핸드오프 도구가 메시지 기록을 업데이트할 때 일치하는 tool call id 를 사용하려면 ToolMessage 가 명시적으로 필요합니다. 해당 응답이 없으면 모델의 도구 요청 응답 주기가 잘못된 상태로 남습니다. 해당 필드는 중요한 검사를 정의하지만 전체 작업을 다루지는 않습니다. 경계 최소한의 증거 실패한 상태 안전한 다음 이동 노선 to agent 가 선언되고 goto === to agent ROUTE REJECTED 전송을 차단합니다. 선언된 경로 복원 제어 이전 상태는 보낸 사람의 이름을 지정하고 이후 상태는 받는 사람의 이름을 지정합니다. STALE CONTROL 재시도하기 전에 지속 상태 조정 도구 프로토콜 하나의 ToolMessage 는 정확한 tool call id 를 닫습니다. OPEN TOOL PROTOCOL 다른 모델 호출 전 수리 내역 문맥 모든 필수 컨텍스트 키가 대상에 존재합니다. CONTEXT INCOMPLETE 최소 이전 계약 재구축 목적지 의도된 노드는 승인된 시작을 기록합니다. DESTINATION NOT STARTED 라우팅 및 노드 승인 검사 결과 작업별 검증자가 예상 결과를 기록합니다. FALSE COMPLETE 작업을 다시 엽니다. 마지막 메시지를 믿지 마세요 컨텍스트 확인에서는 스크립트가 아닌 스키마를 비교해야 합니다. 예를 들어 판매 핸드오프에는 request type , customer tier 및 consent status 가 필요할 수 있습니다. 영수증에는 해당 키 이름과 콘텐츠 다이제스트가 기록됩니다. 고객의 메시지나 도구 인수가 필요하지 않습니다. 이 경계는 별도의 하위 그래프에 특히 중요합니다. LangChain는 메시지 흐름에 명시적인 컨텍스트 엔지니어링이 필요하다고 경고합니다. 모든 것을 전달하면 컨텍스트가 부풀어 오르거나 관련 없는 데이터가 노출될 수 있습니다. 너무 적게 전달하면 수신자가 자신있게 다른 작업을 해결할 수 있습니다. 경로별로 필요한 키를 정의하고 해당 키가 없을 경우 페일클로즈됩니다. 대상 시작 수신은 제어 상태 업데이트와 별개입니다. 판매 노드가 승인되지 않거나 즉시 충돌하거나 대기열에서 대기하는 경우에도 리듀서는 active agent: "sales agent" 를 수락할 수 있습니다. 상태 돌연변이는 활동입니다. 대상 이벤트는 수신자가 실제로 시작했음을 설정합니다. 8건의 영수증 재생 이 문서의 아티팩트는 합성 구조 필드만 사용합니다. 분류자는 우선순위 규칙을 적용합니다. 이전의 실패로 인해 나중에 녹색 신호가 표시되는 것을 방지할 수 있습니다. 다음을 사용하여 전체 로컬 픽스처를 실행합니다. 재생을 통해 8개 사례에서 8개 예상 분류가 생성되었습니다. 이것은 LangChain에 대한 고장률 주장이 아닙니다. 의사결정규칙에 대한 테스트이다. 유용한 관찰은 정렬된 라우팅과 상태가 여전히 불충분하다는 것입니다. 도구 메시지 ID, 컨텍스트 키 세트, 대상 시작 시간 또는 결과 수신만 변경하면 판정이 변경됩니다. 고정 장치는 또한 유혹적인 지름길을 방지합니다. 최종 상태가 complete 이지만 결과 수신이 없으면 모든 핸드오프 관련 필드가 유효한 경우에도 분류자는 FALSE COMPLETE 를 반환합니다. 전송 정확성과 작업 정확성은 다른 질문입니다. 합법적인 대기를 유지하세요 목적지 에이전트는 구매를 승인하거나 승인된 채널을 통해 비밀을 공개하거나 되돌릴 수 없는 옵션 중에서 선택할 사람이 필요할 수 있습니다. 이는 자동으로 핸드오프가 중단되는 것이 아닙니다. 다음을 사용하여 유효한 대기를 기록합니다. 책임 있는 owner ; 제한된 reason ; 미래의 deadlineUtc ; 내구성이 뛰어난 resumeTokenId ; 대상 상태와 필수 컨텍스트가 이미 유지되었습니다. 다섯 가지 사실이 모두 존재하면 실행을 WAITING ON APPROVAL 로 라우팅합니다. 소유자에게 알리고 마감일 또는 결정이 나올 때까지 그래프를 그대로 두십시오. 반복적인 모델 호출로는 누락된 권한이 해결되지 않습니다. 예산만 지출하고 중복 효과의 위험이 있습니다. 대기에 소유자나 기한이 없으면 상태가 아닌 불확실한 대기로 분류하세요. 재개 토큰이 누락된 경우 사람의 응답이 올바른 그래프 상태로 다시 연결되지 않을 수 있습니다. 대상이 기다리는 동안 완료를 선언하면 결과 검증자가 우호적 최종 응답보다 우선합니다. 이러한 구별은 운영자에게 실질적인 개입 경계를 제공합니다. 대기 중: 상태를 보존하고 소유자에게 결정을 표시합니다. 부실 제어 또는 공개 프로토콜: 자동 지속을 중지하고 증거를 조정합니다. 거짓 완료: 작업을 다시 열고 결과 확인 프로그램을 실행합니다. 건강함: 아무것도 하지 마세요. 기본값은 복구가 아닌 관찰입니다. 경로 재지정은 부작용을 반복할 수 있으며 재구성된 메시지는 수신자가 보는 내용을 변경할 수 있습니다. 개입이 외부 상태를 변경하기 전에 명시적인 권한이 필요합니다. 영수증을 그래프 옆에 놔두세요 증거를 알 수 있게 되는 각 경계를 수집합니다. 1. 핸드오프 생성 시: 발신자, 의도된 수신자, 경로 계약 버전, 도구 호출 ID, 필수 컨텍스트 키 이름. 2. 상태 감소 후: active agent 가 관찰되었으며 결과 그래프 범위는 도구 메시지 ID와 일치했습니다. 3. 대상 승인 시: 노드 ID, 시작 시간, 시도 ID, 컨텍스트 계약 결과. 4. 대기 체크포인트: 소유자, 이유, 마감일 및 불투명한 이력서 토큰 ID. 5. 작업 확인 시: 확인자 이름, 결과, 최신성 및 민감하지 않은 영수증 ID입니다. 개인 상태 채널이 개인 원격 측정이라고 가정하지 마십시오. 그만큼LangGraph 그래프 API 문서값을 스트리밍할 때 비공개 채널이 자동으로 수정되지 않음을 경고합니다. 스트리밍된 키를 명시적으로 제한하거나 별도의 최소화된 상태 이벤트를 내보냅니다. 안전한 전달 확인에는 프롬프트, 메시지 본문, 도구 인수, 도구 결과, 비밀 및 절대 로컬 경로가 제외되어야 합니다. 경로 및 컨텍스트 계약의 버전을 지정합니다. 버전이 없으면 새로운 대상이 더 이상 이해하지 못하는 필드를 전송하는 동안 이전 발신자가 건강해 보일 수 있습니다. 두 번째 전송이 두 번째 외부 작업이 되지 않도록 재시도 전반에 걸쳐 하나의 안정적인 작업 ID를 유지합니다. 마지막으로 작업과 일치하는 결과 검증자를 선택합니다. 지원 전달에는 티켓 상태 변경이 필요할 수 있습니다. 구매 전달에는 대상 시스템의 주문 ID가 필요할 수 있습니다. 코딩 핸드오프에는 테스트와 예상 아티팩트가 필요할 수 있습니다. LLM의 최종 메시지는 해당 영수증이 아닙니다. Sidewisp는 현재 비공개 프리뷰 단계입니다. 라이브 조기 액세스 사이트 및 기사 시스템을 사용할 수 있지만 프로덕션 에이전트 상태 수집, LangChain 어댑터 및 자동 복구는 현재 웹 사이트 저장소에 제공되지 않습니다. 위 영수증은 오늘 구현할 수 있는 연산자 패턴입니다. 이러한 경계에 대한 차분한 상태 보기가 팀에 도움이 된다면 비공개 미리 보기 대기자 명단이 적절한 다음 단계입니다.