모두 "루프가 도대체 뭐야?"라고 묻고 있습니다. 아무도 묻지 않는 질문이 있습니다: 루프를 실행하는 것은 무엇일까요?
AI 담론은 루프를 에이전트 시스템의 핵심 프리미티브로 수렴하고 있습니다. Matt Van Horn(@mvanhorn)은 ReAct부터 도구 사용, 오케스트레이션 루프, 그리고 루프가 루프를 감독하는 것까지 에이전트 루프의 계보를 추적했습니다. Addy Osmani(@addyosmani)는 루프 내부의 구성 요소를 분석했습니다: 자동화, 작업 트리, 스킬, 커넥터, 하위 에이전트. Van Horn은 내구성에 초점을 맞추며, 재시작에도 살아남을 수 없는 루프는 루프가 아니라고 주장했습니다. Osmani의 핵심은 오케스트레이션이었습니다: 당신 대신 에이전트를 프롬프트하는 시스템을 설계하라는 것입니다.
저는 그들의 주장을 더 발전시키고자 합니다. 내구성은 단순히 루프의 속성이 아닙니다. 그것은 루프 아래에 있는 전체 실행 계층입니다. 중요한 사실은 내구성 있는 오케스트레이션이 에이전트 루프 아키텍처를 구축하는 데 필수적이라는 것입니다. 그 아키텍처를 분석해 보겠습니다.
루프가 깨지는 지점
/loop 와 /goal 패턴은 단일 에이전트, 단일 세션 작업을 잘 처리합니다. 에이전트는 작업이 완료될 때까지 루프를 돕니다. 그것은 많은 부분을 커버합니다. 하지만 다음 단계(Van Horn의 프레이밍에서 5단계)는 바로 여기서 무너집니다:
- 다른 루프를 감독하는 루프
- 사람이 트리거하는 것이 아니라 스케줄에 따라 실행되는 루프
- 프로세스 재시작, 배포, 충돌에서 살아남는 루프
- 하위 에이전트를 생성하고 결과를 기다리는 루프 (때로는 몇 시간 후)
- 사후에 관찰 가능해야 하는 루프
이는 프롬프팅 문제가 아닙니다. 인프라 문제입니다.
Van Horn은 @runes_leo를 인용합니다: "AI 코딩에서 가장 비용이 많이 드는 것은 더 이상 코드를 작성하는 것이 아니라 에이전트 루프를 관리하는 것입니다." 터미널에서의 while True는 이 중 어떤 것도 제공하지 않습니다. VM이나 샌드박스에서의 장기 실행 프로세스도 마찬가지입니다.
서버에서 에이전트 루프를 실행할 때 어떤 일이 발생하는지 생각해 보세요. 프로세스는 죽거나 재시작됩니다. 배포, OOM, 스팟 인스턴스 회수 등이 발생합니다. 루프가 재시작됩니다. 하지만 무엇을 하고 있었나요? 어느 단계에 있었나요? 그 Slack 메시지를 이미 보냈나요? 하위 에이전트를 이미 호출했나요?
당신은 모릅니다. 처음부터 다시 시작합니다. 이미 가지고 있던 데이터를 다시 가져옵니다. 이미 내렸던 결정을 위해 LLM을 다시 호출합니다. 중복 알림을 보냅니다. 중복 하위 에이전트를 생성합니다. 아침에 일어나서 세 개의 동일한 Slack 메시지와 혼란스러운 팀을 마주하게 됩니다.
해결책은 "더 나은 오류 처리"가 아닙니다. 각 단계가 체크포인트되고, 각 결정이 지속되며, 복구는 마지막으로 성공한 단계부터 재개하는 것을 의미하는 실행 모델입니다.
세 가지 계층의 에이전트 루프 아키텍처
세 가지 계층입니다. 각 계층은 구체적인 프리미티브에 매핑됩니다.
계층 1: 루프
루프는 크론(cron)에 의사 결정자를 더한 것입니다. 스케줄(또는 트리거)에 따라 실행되고, 상태를 평가하며, 다음에 무엇을 할지 결정합니다.
이것이 Van Horn의 정의를 구체화한 것입니다: 크론에 없었던 것은 중간의 결정입니다. 당신이 아니라 에이전트가 결정합니다. 크론은 하트비트입니다. LLM은 의사 결정자입니다. 단계는 진행 상황을 체크포인트하는 내구성 있는 실행입니다.
1export const infraHealthCheck = inngest.createFunction(2 { id: "infra-health-check" },3 { cron: "*/30 * * * *" }, // 30 분마다4 async ({ step }) => {5 const metrics = await step.run("fetch-service-metrics", async () => {6 return await fetchServiceMetrics(); // 오류율, 지연 시간, 메모리, CPU7 });89 const assessment = await step.run("assess-health", async () => {10 return await callLLM({11 prompt: `주어진 서비스 메트릭을 바탕으로 전체 시스템 상태를12 "정상", "저하", 또는 "심각"으로 분류하십시오. 그 이유를 설명하십시오.13 메트릭: ${JSON.stringify(metrics)}`,14 });15 });1617 if (assessment.status === "degraded" || assessment.status === "critical") {18 await step.invoke("triage-incident", {19 function: incidentTriage,20 data: { metrics, assessment, services: assessment.affectedServices },21 });22 }23 }24);
매주 월요일 오전 9시, 루프가 실행됩니다. 데이터를 가져오고, LLM에 보고서가 필요한지 묻고, 필요하면 스킬을 호출합니다. 단계 사이에 프로세스가 재시작되면 이미 완료된 단계는 다시 실행되지 않습니다. 이것이 루프입니다. LLM이 아니라, LLM 주변의 루프입니다.
계층 2: 스킬
이 맥락에서 스킬은 프롬프트가 아닙니다. 내구성 있는 워크플로우입니다. 다단계, 재시도 가능, 구성 가능, 독립적으로 배포 가능합니다.
Van Horn: "루프는 배관입니다. 자산은 루프가 호출하는 스킬입니다." 이것이 복리 효과를 내는 부분입니다. 시스템이 학습하는 각각의 새로운 스킬은 모든 루프를 더욱 강력하게 만듭니다.
1export const incidentTriage = inngest.createFunction(2 { id: "incident-triage", retries: 3 },3 { event: "infra.incident.triage" },4 async ({ event, step }) => {5 const details = await step.run("fetch-detailed-metrics", async () => {6 return await fetchDetailedMetrics({ services: event.data.services });7 });89 const deploys = await step.run("fetch-deploy-history", async () => {10 return await fetchRecentDeploys({ since: hoursAgo(2) });11 });1213 const analysis = await step.run("correlate-incident", async () => {14 return await callLLM({15 prompt: `다음 서비스 메트릭을 최근 배포 내역과 연관 지으십시오.16 가능한 근본 원인과 심각도를 식별하십시오.17 메트릭: ${JSON.stringify(details)}18 최근 배포: ${JSON.stringify(deploys)}`,19 });20 });2122 await step.run("post-triage-summary", async () => {23 await slack.postMessage({24 channel: "#incidents",25 text: formatTriageSummary({26 analysis,27 affectedServices: event.data.services,28 recommendedActions: analysis.recommendations,29 }),30 });31 });3233 return analysis;34 }35);
이 스킬은 가져오고, 분류하고, 라우팅합니다. 내장된 내결함성을 가진 작업 단위입니다. 스킬은 중간에 LLM이 있는 AI 워크플로우이거나 결정론적 코드일 수 있습니다.
계층 3: 오케스트레이터
오케스트레이터는 모든 것을 실행하는 엔진입니다: 크론 스케줄링, 단계 실행, 재시도 관리, 동시성 제한 적용, 실행 기록 저장, 실행 중인 워크플로우를 중단하지 않고 새 함수/워크플로우를 핫 배포합니다.
이것은 보이지 않아야 하기 때문에 아무도 이야기하지 않는 계층입니다. 하지만 근본적입니다.
대부분의 사람들은 에이전트를 "LLM + 도구"로 생각합니다. 에이전트 루프 아키텍처는 이를 "루프 + 스킬 + 오케스트레이션"으로 재구성합니다. LLM + 도구는 루프 내부에 있습니다. LLM과 도구는 아키텍처가 유지되는 동안 교체되거나 조정될 수 있습니다. 오케스트레이션이 아키텍처를 가능하게 합니다.
문제가 발생했을 때
해피 패스는 쉽습니다. 하지만 이것은 프로덕션에서 실행되는 소프트웨어입니다. 모든 것이 항상 계획대로 진행될까요?
인시던트 분류 스킬이 실행되고 메트릭 API가 타임아웃됩니다. 읽기는 디스크로 가야 했고 인메모리 캐시에 데이터가 없었습니다. 이 API를 호출하는 단계는 이제 재시도하고 API를 다시 호출합니다. 데이터가 부분적으로 캐시되고 API가 완료됩니다. 스킬은 아무 일도 없었던 것처럼 다음 단계를 계속합니다.
때로는 그렇게 간단하지 않을 수 있습니다. API 키가 만료되거나 호스팅 제공업체가 30분 동안 다운되면 어떻게 될까요? 모든 재시도가 소진됩니다. 이제 어떻게 될까요? 또한 실패를 처리해야 합니다.
1export const incidentTriage = inngest.createFunction(2 {3 id: "incident-triage",4 retries: 3,5 onFailure: async ({ error, event, step }) => {6 // 재시도 소진 후 함수가 실패했습니다.7 // 원본 이벤트 데이터는 여전히 있습니다. 아무것도 손실되지 않았습니다.8 await step.run("notify-failure", async () => {9 await slack.postMessage({10 channel: "#agent-ops",11 text: `⚠️ 인시던트 분류 실패: ${error.message}. ` +12 `다음 건강 점검 주기에 재시도됩니다. ` +13 `영향받은 서비스: ${event.data.services.join(", ")}`,14 });15 });16 },17 },18 { event: "infra.incident.triage" },19 async ({ event, step }) => {20 /* 위의 스킬과 동일한 로직 */21 }22);
onFailure 핸들러는 모든 재시도가 소진된 후에 실행됩니다. 운영 채널에 게시하여 누군가 알 수 있도록 합니다. 이벤트는 보존되며, 아무것도 손실되지 않습니다. 다음 예약된 실행이 실패한 부분을 이어받습니다.
내구성 있는 오케스트레이션은 일시적인 오류에 대한 단계 수준 재시도와 복구 불가능한 오류에 대한 실패 처리 훅을 제공해야 합니다. 이것이 없으면 예상대로 문제가 발생하고, 몇 시간 또는 며칠 후에야 알게 됩니다.
일시적인 오류는 또한 비용이 많이 듭니다. 스킬이나 에이전트가 처음부터 재시도하면 LLM을 여러 번 호출하고 불필요하게 토큰을 소모합니다. LLM 호출은 체크포인트될 수 있습니다. 이제 시스템 전체에 10개 또는 30개의 에이전트가 있다고 곱해 보십시오. 그것은 비용이 많이 듭니다.
단계 수준 체크포인팅은 단순한 정확성 기능이 아닙니다. 비용 절감 효과입니다.
자체 스킬을 구축하는 에이전트
여기서부터 더 흥미로워집니다. 시스템은 정적이지 않으며, 진화하고 확장하도록 설계되었습니다.
에이전트는 루프 내에서 실행될 뿐만 아니라 새로운 루플를 작성하고 오케스트레이션 엔진에 등록합니다. 배포된 각 함수는 독립적으로 실행되는 내구성 있는 스킬이며, 루프나 에이전트에서 트리거되거나 스케줄에 따라 실행될 수 있으며, 자체 재시도 로직을 가지고 있습니다. 스킬은 복리 효과를 냅니다.
이것은 오케스트레이션을 인식하는 에이전트입니다.
작동 방식은 다음과 같습니다. AI 에이전트는 오케스트레이션 SDK를 도구로 사용할 수 있습니다. 새 함수를 작성하고, 엔진에 등록하면 즉시 실행을 시작할 수 있습니다. 에이전트 프로세스는 실행 중인 실행을 재시작하거나 중단하지 않고 새 함수를 핫 리로드합니다.
구체적인 예를 살펴보겠습니다:
1. 인간이 필요를 표현합니다. 엔지니어가 말합니다: "매일 밤 서비스에 지연 시간 스파이크가 발생하는데 아무도 아침까지 눈치채지 못합니다." 이것이 트리거입니다. 에이전트는 주변 데이터에서 모호한 패턴을 추론할 필요가 없습니다. 명확한 지침이 있습니다.
2. 에이전트가 스킬을 작성합니다. 두 개의 다단계 함수: 30분마다 실행되어 오류율, 지연 시간 및 리소스 사용량을 가져오고, LLM이 시스템 상태를 정상, 저하 또는 심각으로 분류하는 건강 점검 루프. 그리고 상세 메트릭과 최근 배포 기록을 가져오고, LLM으로 근본 원인을 연관 짓고, 권장 조치와 함께 분류 요약을 Slack에 게시하는 인시던트 분류 스킬. 오류 처리: 메트릭 API가 다운되면 백오프 후 재시도. LLM이 실패하면 규칙 기반 심각도 분류로 폴백.
3. 에이전트가 스킬을 배포합니다. 에이전트는 사이드카 프로세스에 의해 선택되는 함수 코드를 작성합니다. 새 함수가 자동으로 등록됩니다. 배포 파이프라인, PR 없이 즉시 라이브 상태가 됩니다.
4. 스킬이 자율적으로 실행됩니다. 30분마다 엔진이 건강 점검을 트리거합니다. 문제가 있으면 분류 스킬을 호출합니다. 인간의 개입 없이 완전히 내구성 있습니다.
5. 에이전트가 신호를 기반으로 반복합니다. 사람들이 간과하는 부분이니, "반복"이 무엇을 의미하는지 구체적으로 설명하겠습니다. 에이전트는 마술처럼 패턴을 알아차리지 않습니다. 별도의 검토 루프가 있습니다: 매주 실행되는 크론 트리거 함수로, 오케스트레이터에서 실행 기록을 읽고 성능을 평가합니다:
1export const reviewSkillPerformance = inngest.createFunction(2 { id: "review-skill-performance" },3 { cron: "0 10 * * 5" }, // 매주 금요일 오전 10시4 async ({ step }) => {5 const runs = await step.run("fetch-run-history", async () => {6 return await getInngestRuns({7 functionId: "incident-triage",8 since: daysAgo(7),9 });10 });1112 const analysis = await step.run("analyze-performance", async () => {13 const successRate = runs.filter(r => r.status === "completed").length / runs.length;14 const avgDuration = average(runs.map(r => r.duration));15 const incidents = await fetchIncidentOutcomes(); // 인시던트가 실제 장애와 연관되었는가?1617 return await callLLM({18 prompt: `지난주 이 스킬의 성능을 검토하십시오.19 성공률: ${successRate}20 평균 지속 시간: ${avgDuration}ms21 실제 장애와 연관된 인시던트: ${incidents.confirmed}/${incidents.total}22 거짓 양성: ${incidents.falsePositives}23 팀이 알림에 조치함: ${incidents.actedOn}/${incidents.total}2425 임계값이나 분류를 조정해야 합니까? 구체적인 변경 사항은 무엇입니까?`,26 });27 });2829 if (analysis.shouldModify) {30 await step.invoke("update-skill", {31 function: coreAgent,32 data: { prompt: `다음 제안된 변경 사항을 기반으로 incident-triage 스킬을 업데이트하십시오: ${analysis.proposedChanges}` },33 });34 }35 }36);
"검토"는 함수입니다. 실행 기록을 읽고, 인시던트가 실제 장애와 연관되었는지 확인하고, 그 신호를 LLM에 제공합니다. 건강 점검에서 서비스를 계속 저하로 표시하지만 임계값이 너무 민감하여 팀이 무시하는 경우, 검토 루프가 이를 포착하고 분류를 조정하기 위해 스킬이 업데이트됩니다. 마술이 아닙니다. 의사 결정 자리에 LLM이 있는 크론 작업입니다.
검증은 어떻게 하나요? 코드를 작성하는 에이전트는 그 주변의 안전장치만큼만 좋습니다. 코드는 타입 검사될 수 있습니다. 에이전트는 오케스트레이션 엔진 자체와 상호 작용할 수 있으므로 함수 자체를 호출하여 테스트할 수 있습니다. 완벽하지는 않지만, 코어 에이전트가 자체적으로 작성한 스킬을 시스템 내에서 디버그할 수 있는 능력을 제공합니다. 검토 루프는 초기 디버깅으로 잡히지 않은 문제를 포착합니다.
한 단계 더 나아가, 에이전트는 onFailure 훅을 사용하여 특정 실패를 자체적으로 평가하도록 트리거할 수 있습니다. 지속적으로 개선되는 피드백 루프입니다.
충돌은 어떻게 처리하나요? 특히, 동시성 제어 또는 싱글톤과 같은 흐름 제어는 간단한 경우(동시성: { limit: 1, key: "[event.data.service" }])를 처리합니다. 이는 서비스당 한 번에 하나의 인시던트 분류만 실행됨을 의미합니다. 하지만 더 깊은 질문은: 두 개의 건강 점검이 동시에 동일한 서비스에서 문제를 감지하면 어떻게 될까요? 오케스트레이터가 대기열에 넣습니다. 두 번째 분류는 첫 번째가 완료될 때까지 기다립니다. 중복 알림, 경쟁 조건이 없습니다. 이는 이론적이지 않습니다. 모든 작업 대기열에서 사용하는 것과 동일한 동시성 프리미티브입니다.
에이전트는 단순히 작업을 실행하는 것이 아닙니다. 자신을 위한 인프라를 구축하고 있습니다. 각 스킬은 그것을 생성한 대화를 넘어 지속됩니다. 에이전트 프로세스를 종료하고 다시 시작하십시오. 스킬은 계속 실행됩니다. 기본 모델을 교체하십시오. 스킬은 계속 실행됩니다. 에이전트는 일시적입니다. 하지만 그 출력은 내구성 있습니다.
에이전트 루프 아키텍처 시스템 개요
개발자의 관점
개발자가 에이전트가 배포한 것을 볼 수 없고, 무엇이 고장 났는지 디버그할 수 없으며, 오전 3시에 무엇이 실행되었는지 감사할 수 없다면 전체 아키텍처는 큰 부채가 됩니다.
오케스트레이션 엔진은 모든 실행, 모든 단계, 모든 입력, 모든 출력, 모든 재시도를 저장합니다. 지난주 화요일에 에이전트가 배포한 스킬이 오전 4시에 실패했습니까? 어떤 단계가 실패했는지, 입력이 무엇인지, 어떤 오류가 발생했는지, 포기하기 전에 몇 번 재시도했는지 정확히 볼 수 있습니다. 단계 수준까지의 전체 추적은 오케스트레이션 엔진 자체의 출력입니다.
이것은 사후에 추가된 대시보드가 아닙니다. 내구성 있는 실행에 내재된 것입니다. 모든 step.run()은 체크포인트입니다. 모든 체크포인트는 관찰 가능합니다. 코드를 작성한 것이 인간이 아닐 때, 관찰 가능성은 단순한 있으면 좋은 기능이 아닙니다. 그것은 신뢰 계층입니다.
일상적으로 개발자의 워크플로우는 다음과 같습니다: 아침에 실행 대시보드를 확인합니다. 밤새 어떤 스킬이 실행되었는지, 어떤 것이 성공하고 실패했는지 확인합니다. 에이전트가 작성한 스킬이 오작동하는 경우, 코드를 직접 읽고, 편집하고, 삭제하거나 에이전트에게 수정하도록 지시할 수 있습니다. 에이전트가 작성했지만, 당신이 소유합니다. 에이전트와 그 스킬은 여전히 당신이 가꿔야 할 정원입니다.
내구성이 근본적인 이유
Van Horn: "이것들은 재시작을 견뎌야 합니다."
실제로 내구성이 의미하는 바는 다음과 같습니다:
요구 사항
의미
기본 while 루프가 실패하는 이유
독립적인 단계 재시도
5단계 중 3단계가 실패하면, 1, 2단계가 아닌 3단계만 재시도
루프 재시작 시 모든 것을 처음부터 다시 실행
하위 에이전트 수명 주기
하위 작업 생성, 대기(몇 시간일 수 있음), 상위가 취소되면 취소
기본 제공 상위-하위 수명 주기 관리 없음
보장된 이벤트 전달
에이전트가 다운된 동안 이벤트가 발생하면, 여전히 처리되어야 함
프로세스가 실행 중이 아니면 이벤트 손실
사후 관찰 가능성
사후에 발생한 상황 확인: 모든 단계, 모든 결정, 모든 재시도
로그만이 유일한 옵션이며, 일시적임
다운타임 없는 핫 배포
실행 중인 실행을 중단하지 않고 새 함수 버전 배포
프로세스 재시작이 모든 것을 종료
동시성 제어
스킬의 N개 인스턴스만 동시에 실행
기본 제공 동시성 프리미티브 없음
"그냥 컨테이너에서 실행"하면 가동 시간을 얻을 수 있습니다. 정확성은 얻지 못합니다. 충돌 후 재시작하는 컨테이너는 프로세스를 다시 시작하지만, 실행 중인 모든 루프는 처음부터 다시 시작합니다. 모든 단계가 다시 실행됩니다. 모든 LLM 호출이 다시 이루어집니다. 루프가 실행되는 것처럼 보이지만, 맹목적으로 실행되고 있습니다.
기존 도구와의 비교
일부 도구는 이러한 유형의 시스템에 대한 "멋진" 턴키 솔루션을 제공하거나, 하위 수준 도구를 결합하여 자신만의 시스템을 만들 수도 있습니다. 어느 선택도 틀리지 않았지만, 올바른 아키텍처 계층은 당신 그리고 당신의 에이전트가 시간이 지남에 따라 진화할 수 있도록 해야 합니다. 유연하고, 동적이며, 내구성 있어야 합니다.
에이전트에 잘 맞고 에이전트가 쉽게 작성할 수 있는 내구성 있는 실행 프리미티브, 그리고 에이전트 자체가 오케스트레이션을 인식할 수 있도록 관찰하고 가능하게 하는 관찰 가능성과 API.
작동 예시
우리는 Inngest 내부에서 이러한 패턴을 테스트하고 있으며, 여기 utah 프로젝트 저장소에서 이 개념을 볼 수 있습니다: https://github.com/inngest/utah: 이는 Inngest의 내구성 있는 오케스트레이션 위에 구축된 에이전트 하니스로, 오케스트레이션을 인식합니다.
이 시스템에는 메인 에이전트가 자체 작업 공간에서 Inngest 함수를 작성하고 편집할 수 있게 해주는 사이드카 프로세스가 있어, (이 글의 맥락에서) "스킬"로 자신을 확장합니다. 곧 시작 루프를 예시로 포함하는 전체 시스템을 제공할 계획이지만, 거기에 있는 아이디어들은 이 글의 개념을 더 명확하게 보여줄 수 있습니다.
복리 루프
Satya Nadella의 최근 게시물은 업계가 느껴온 것을 명명했습니다: 해자는 모델이 아니라 루프입니다.
그의 프레이밍: 두 가지 유형의 자본이 있습니다. 인적 자본, 팀이 수년간 쌓아온 지식과 판단력. 그리고 그가 토큰 자본이라고 부르는 것, 회사가 기반 모델 위에 구축하는 AI 워크플로우, 의사 결정 패턴, 학습된 스킬.
이 둘은 함께 복리 효과를 낸다는 것이 핵심입니다. 개선된 모든 워크플로우는 더 나은 신호를 생성합니다. 더 나은 신호는 더 날카로운 AI 행동을 만듭니다. 더 날카로운 행동은 더 높은 판단력 작업을 위해 인간의 주의를 자유롭게 합니다. 언덕 오르기 기계입니다.
이것이 에이전트 루프 아키텍처가 구체적으로 가능하게 하는 것입니다:
- 에이전트가 배포하는 모든 내구성 있는 스킬은 실행 가능한 인프라로 인코딩된 조직 지식입니다. 그것은 지속됩니다. 인간이 보고 있든 말든 실행됩니다.
- 스킬 성능을 평가하고 반복하는 크론 트리거 검토 루프. 이것이 현실이 된 언덕 오르기 기계입니다. 데크에 있는 플라이휠 다이어그램이 아닙니다. 크론 트리거가 있는 함수입니다.
- 프로세스 재시작 시 스킬이 죽으면 복리 효과는 0으로 재설정됩니다. 내구성은 투자를 지속하게 만드는 것입니다.
Nadella의 핵심 요점: "회사는 학습 시스템에 내장된 '회사 베테랑' 전문성을 잃지 않고 '일반' 모델을 교체할 수 있어야 합니다." 이것이 스킬 라이브러리 패턴입니다. 내구성 있는 함수는 어떤 LLM이 호출하는지 상관하지 않습니다.
그에 따라 구축하십시오
지금까지의 논의는 에이전트가 무엇을 하는지에 관한 것이었습니다: 루프, 도구, 추론, 컨텍스트 엔지니어링. 다음 논의는 에이전트를 실행하는 것이 무엇인지에 관한 것입니다.
세 가지 계층: 루프, 스킬, 오케스트레이터. 루프는 작업 단위입니다. 스킬은 자산입니다. 오케스트레이션 엔진은 둘 다 내구성 있게 만드는 것입니다. 사이드카 패턴은 모델입니다: 에이전트가 자체 내구성 있는 스킬을 작성하고, 배포하고, 성능을 검토하고, 반복합니다. 사고 실험이 아닙니다. 작동하는 모델입니다.
우리는 Inngest를 이를 위한 오케스트레이션 엔진으로 구축했습니다: step.run(), step.invoke(), 크론 트리거, 이벤트 기반 제어 흐름, 동시성 제어, 완전한 단계 수준 관찰 가능성. 하지만 아키텍처 패턴은 단일 도구보다 더 큽니다. 프로덕션에서 에이전트 루프를 구축하고 있다면, 세 가지 계층을 정의하십시오.
프리미티브는 오늘날 존재합니다. 그에 따라 구축하십시오.
