Cloudflare Agents와 Workflows: 각각의 역할

Cloudflare Agents와 Workflows 비교는 대화형 도우미가 대화보다 오래 계속되는 일을 시작할 때 유용합니다. 에이전트는 진행 상황을 설명해야 하고 백그라운드 프로세스는 중단을 견디며 승인을 기다려야 할 수 있습니다. 서로 관련된 책임이지만 생명주기는 다릅니다.

이벤트를 받고 사용자와 소통하는 지속적인 대화형 신원에는 Agents를 사용하세요. 대기와 재시도를 포함하는 내구성 있는 백그라운드 단계에는 실행 모델이 맞는 경우 Workflows를 사용하세요. 대화와 장기 작업이 독립적으로 진행돼야 할 때 결합하고, 외부 업무 효과는 명시적으로 대조할 수 있게 유지해야 합니다.

직원이 공급업체 평가를 요청하는 상황을 생각해 보세요. 도우미는 빠진 정보를 묻고 상태를 표시합니다. 평가는 기록을 모으고 보고서를 준비한 뒤 동료의 결정을 기다립니다. 브라우저를 닫아도 작업이 없어지면 안 되고 재연결이 평가를 다시 시작하게 해서도 안 됩니다.

이 글은 가상의 설계로 경계를 설명합니다. 모든 도우미에 두 제품이 필요하다거나 내구성 있는 실행 덕분에 모든 외부 작업을 안전하게 반복할 수 있다고 가정하지 않습니다.

Cloudflare Agents와 Workflows: 생명주기 비교하기

Cloudflare의 Agents와 Workflows 문서 는 보완적인 역할을 설명합니다. Agents는 지속적인 상호 작용과 신원을 지원하고 Workflows는 내구성 있는 백그라운드 실행을 지원합니다. 시작 템플릿을 고르기 전에 이 역할을 기준으로 선택하세요.

공급업체 평가에서 대화는 직원에게 보이는 생명주기를 갖고 작업은 업무 생명주기를 갖습니다. 직원은 연결을 끊을 수 있고 다른 권한 있는 동료가 결과를 검토할 수 있으며, 처음 채팅이 끝나도 평가는 계속 대기할 수 있습니다.

표는 제안하는 역할 분담입니다. SDK를 채택하면 앱의 권한 모델이나 업무 상태 원장이 자동으로 제공된다는 주장은 아닙니다.

채팅 기록이 아니라 작업 기록부터 시작하기

평가에 안정적인 작업 번호를 부여하세요. 책임자, 원본 버전, 요청 결과, 현재 상태를 대화 재독에 의존하지 않는 형태로 저장해야 합니다. 대화록은 의도를 설명할 수 있지만 수락된 작업의 유일한 기록이어서는 안 됩니다.

사용자 화면은 논의 중인 요청과 수락된 작업을 구분해야 합니다. 직원이 제출을 눌렀는데 응답이 사라지면 재연결 시 작업이 존재하는지 알 수 있어야 합니다. 마지막 채팅 메시지에서 모델이 이를 추론하게 하는 것은 믿을 수 없습니다.

프로세스 책임자에게 의미 있는 상태를 정의하세요. 입력 대기, 증거 수집, 검토 준비, 승인, 거부, 실패 등이 예입니다. 누가 상태를 바꿀 수 있고 어떤 증거가 필요한지도 포함해야 합니다.

작업 번호는 대화 화면이 바뀌어도 유지돼야 합니다. 나중에 이메일이나 대시보드가 같은 수락된 평가를 보여 줄 수는 있지만, 작업 동작에 대한 두 번째 기준이 돼서는 안 됩니다.

내구성 있는 단계를 설명 가능한 크기로 유지하기

Workflows 개요 는 내구성 있는 다단계 실행을 설명합니다. 입력, 출력, 복구 동작이 명확한 단계에 그 기능을 사용하세요. 원본 수집, 글 생성, 여러 시스템 변경을 한 거대 단계에 넣으면 실패할 때 검사하기 어렵습니다.

평가에서는 원본 기록 확보, 보고서 생성, 승인된 업무 결정 반영을 나누세요. 어떤 원본 버전이 보고서를 뒷받침했는지 기록해야 합니다. 원본 변경 후 재시도는 조용히 다른 평가를 만드는 대신 명시적인 정책을 따라야 합니다.

저장된 단계 결과를 외부 부수 효과의 증거와 혼동하지 마세요. 호출 프로세스가 응답을 잃기 직전에 목적지가 요청을 수락할 수 있습니다. 앱에는 실제로 무엇이 일어났는지 확인할 작업 번호나 다른 대조 방법이 필요합니다.

다음 조치를 분명히 해 주는 단계 경계가 유용합니다. 운영자가 재시도할지, 증거를 새로 가져올지, 검토자에게 연락할지 알 수 없다면 업무 맥락이 부족한 경계일 가능성이 큽니다.

승인을 버전이 있는 업무 이벤트로 만들기

승인은 정확한 평가 버전과 제안된 결과를 가리켜야 합니다. 검토자가 페이지를 연 뒤 원본 기록이나 보고서가 달라지면, 진행하기 전에 앱이 그 불일치를 해결하게 하세요.

이벤트가 도착할 때 검토자를 인증하고 작업 권한을 확인해야 합니다. 평가를 가리키는 URL만으로 승인 권한이 생기지는 않습니다. 도구 결과나 생성 문장이 동료의 승인을 대신하게 하지 마세요.

취소도 비슷하게 다루세요. 앞으로의 단계를 멈춰도 외부 시스템이 이미 수락한 요청을 되돌리지는 못할 수 있습니다. 어떤 작업이 중단됐고 어떤 결과는 여전히 대조해야 하는지 사용자에게 보여 주세요.

기준 상태를 바탕으로 재연결하기

직원이 돌아오면 현재 권한으로 작업 상태를 읽으세요. 최근 기록된 단계와 관찰 시각을 보여 줘야 합니다. 대화 요약은 도움이 될 수 있지만 추측한 상태로 작업 기록을 덮어써서는 안 됩니다.

진행 알림과 기준 상태를 분리하세요. 알림을 놓쳤다고 작업 전환도 놓쳐서는 안 됩니다. 반대로 알림 수신이 해당 공급업체 원본 기록을 열람할 권한을 부여해서도 안 됩니다.

대기 중, 실패 뒤, 다른 동료의 조치 뒤에 재연결하는 경우를 시험하세요. 오래된 결정을 제출하려는 낡은 브라우저 탭도 포함해야 합니다. 교대나 팀을 넘나드는 업무에서는 이런 것이 정상 운영 조건입니다.

더 넓은 결과 시험은 당사의 에이전트 평가 안내 를 참고하세요. 도구 호출 성공만으로는 충분하지 않은 이유를 설명합니다. 여기서 핵심은 올바른 작업이 계속됐고 사용자가 진짜 상태를 보는지입니다.

요구를 만족하는 가장 작은 구조 선택하기

짧은 조회를 하는 도우미는 별도 백그라운드 흐름이 필요 없을 수 있습니다. 예약된 데이터 변환에는 대화형 에이전트가 필요 없을 수 있습니다. 둘 다 추가하면 유지할 설정, 상태 관계, 사고 경로가 늘어납니다.

구조는 책임을 더 명확하게 만들어야 합니다. 에이전트와 워크플로 중 누가 현재 작업 상태를 책임지는지 아무도 설명할 수 없다면, 도구 호출을 늘리기 전에 계약을 작성하세요.

조율과 장애 시험의 예산 잡기

시스템 수, 작업 전환, 승인 역할, 불확실한 외부 결과가 늘수록 구현 비용도 증가합니다. 채팅 텍스트의 양은 그 작업량을 잘 나타내지 못합니다.

작업 설계, 에이전트 상호 작용, 워크플로 실행, 목적지 통합, 인수를 분리한 GBP 견적을 요청하세요. 의존성 버전 유지와 배포 중 이미 진행 중인 작업의 처리 절차도 포함해야 합니다.

현재 사용료는 선택한 서비스와 부하에 맞춰 검증해야 합니다. 대기, 반복 시도, 추론, 저장, 관찰 작업을 따로 추정하세요. 거의 실행되지 않는 배경 작업도 업무 영향이 중요하면 세심한 운영 지원이 필요할 수 있습니다.

유용한 파일럿은 브라우저 종료, 프로세스 중단, 중복 승인, 목적지 타임아웃을 보여 줘야 합니다. 운영자가 채팅을 재구성하지 않고도 평가를 찾아 다음 안전한 조치를 확립할 수 있어야 합니다.

당사의 범위가 정해진 AI 통합 파일럿 에서 이 계약을 정의할 수 있습니다. 작업 단계, 연결 시스템, 승인 역할을 포함해 에이전트 워크플로 제안 요청 을 보내 주세요. 그러면 팀이 실제로 끝내야 하는 일을 기준으로 런타임을 선택하게 됩니다.

자주 묻는 질문

Agents와 Workflows는 경쟁 제품인가요? 강점이 다르고 함께 쓸 수 있습니다. Agents는 지속적인 상호 작용과 신원에 적합하고 Workflows는 내구성 있는 배경 단계에 적합합니다. 모든 작업에 둘 다 필요하다고 가정하지 말고 앱 생명주기로 조합을 선택하세요.

모든 AI 도우미에 Workflow가 필요한가요? 아닙니다. 짧은 대화형 작업은 없어도 충분할 수 있습니다. 수락한 작업이 독립적으로 계속되거나 이벤트를 기다리거나 정의된 단계로 복구해야 한다면 내구성 있는 백그라운드 처리를 고려하세요.

내구성 있는 실행이 중복 업무 작업을 막나요? 외부 시스템을 따져 봐야 할 필요는 사라지지 않습니다. 응답이 없어져도 목적지는 요청을 완료할 수 있습니다. 중요한 효과에는 안정적인 작업 번호와 문서화된 대조 정책을 사용하세요.

승인 상태는 어디에 저장해야 하나요? 정확한 제안 버전과 검토자에 연결된 기준 작업 기록에 보관하세요. 대화는 결정을 보여 주고 설명할 수 있지만 승인에 대한 유일한 기록이면 안 됩니다.

사용자가 브라우저를 닫으면 어떻게 되나요? 앱은 연결과 독립적으로 수락된 작업을 유지해야 합니다. 돌아오면 사용자를 인증하고 현재 상태를 읽어야 하며, 작업을 다시 시작하거나 모델에 진행 상황을 추측하게 하면 안 됩니다.

파일럿은 무엇을 시험해야 하나요? 보통의 여정과 함께 연결 끊김, 처리 중단, 오래된 승인, 중복 이벤트, 불확실한 목적지 결과를 시험하세요. 각 상태를 어느 구성 요소가 책임지고 운영자가 어떻게 복구하는지 보고서가 보여 줘야 합니다.

결합한 구현 비용은 얼마나 되나요? 작업 전환, 시스템 통합, 권한 역할, 복구 요구에 따라 다릅니다. 채팅 기능만을 기준으로 가격을 정하지 말고 상호 작용, 처리, 인수, 지원을 분리한 GBP 견적을 요청하세요.