기능 설명 01: 오케스트레이션 엔진

첫 작업 지시부터 검증된 패치까지

Agent Argo는 하나의 모델이 가능한 한 오래 한 가지 작업을 수행하는 방식으로 이루어져 있지 않습니다. 그것은 소프트웨어 작업을 추적 가능한 단계로 변환하는 시스템입니다: 계획, 분할, 처리, 검사, 수정, 그리고 그 후에만 적용을 위해 제시합니다.

이 글로 "기능 설명" 시리즈가 시작됩니다. 이 시리즈는 Agent Argo의 핵심 메커니즘을 이해하기 쉽게 설명합니다 — 마케팅 약속이 아니라 실제 사용 사례를 따라서입니다. 첫 번째 주제는 오케스트레이션 엔진입니다: 요구사항을 통제된 작업 프로세스로 만드는 흐름입니다.

1. 시작 전: 품질, 비용 및 자율성 결정하기

Argo가 작업을 처리하기 전에 두 가지 결정이 중요합니다. 이들은 의도적으로 서로 분리되어 있습니다:

1. Argo는 비용과 결과 품질 사이에서 어떻게 저울질해야 하는가?
2. Argo는 프로젝트 내에서 얼마나 독립적으로 행동할 수 있는가?

이를 통해 전형적인 목표 충돌을 방지합니다: 철저한 실행이 자동으로 더 많은 쓰기 권한을 받는 것은 아니며, 자율적인 실행이 자동으로 비싼 모델을 선택하는 것도 아닙니다.

비용과 품질을 위한 세 가지 단계

모델 라우터는 이해하기 쉬운 세 가지 모드를 갖추고 있습니다. 이는 가격과 모델 등급이 선택에 얼마나 반영되는지를 바꿉니다. 필요한 스킬은 항상 중심에 남습니다.

단계	라우터 모드	적합한 용도
절약형	economy	일상 작업, 추출, 명확히 구분된 변경. 비용이 크게 작용합니다.
균형형	balanced	대부분 실행의 기본값: 스킬 적합성, 비용 및 품질 등급이 균형을 이룹니다.
정밀형	expert	아키텍처, 조사, 복잡한 분석 및 까다로운 리뷰. 모델 등급이 훨씬 더 크게 작용하고 비용은 덜합니다.

운영 프로필 빠르고 저렴하게, 균형형, 철저하게는 이 라우터 모드를 추가 결정과 묶습니다: 예를 들어 공동 사고가 단지 관찰만 되는지 능동적으로 실행되는지, 검증이 의무적인지, Argo가 실패 시 더 강하게 에스컬레이션할 수 있는지 등입니다.

자율성의 세 가지 단계

자율성은 Argo가 무엇을 옳다고 생각하는지가 아니라, 언제 인간이 필요한지를 규정합니다.

단계	동작
안전	Argo가 분석하고 계획합니다. 변경은 검토를 위해 남으며, 쓰기나 위험한 행동 전에는 확인을 요청합니다.
균형형	일반적인 변경은 격리된 작업 상태에서 생성될 수 있습니다. 삭제, 명령, 다운로드, 네트워크 접근 또는 보호 경로에서는 Argo가 계속 확인을 요청합니다.
완전 자율	실행은 일반적인 확인 없이 진행됩니다. 단단한 보안, 정책 및 예산 한계는 계속 적용됩니다.

코드에서 이러한 규칙은 readonly, confirm_write, auto_write, bypass로 더 정확히 구현됩니다. 세 단계는 이를 사용하기 쉽게 만들지만, 프로젝트 정책이 항상 최종 결정권자로 남습니다. 예를 들어 클라우드 제공자를 제외하거나, 로컬 모델만 허용하거나, 네트워크 접근을 차단하거나, 명령을 제한하거나, 비밀을 보호하거나, 비용 한도를 설정할 수 있습니다.

2. CEO 계층이 작업 지시를 계획으로 바꿉니다

사용자는 먼저 일반 언어로 목표를 설명합니다. Argo의 CEO 계층은 제한된 프로젝트 개요, 사용 가능한 모델 카탈로그 및 관련 프로젝트 정보를 받습니다. 미해결 질문이 있으면 먼저 묻거나 계획을 생성할 수 있습니다.

계획은 할 일 목록만 포함하지 않습니다. 각 작업에는 역할, 설명, 종속성 및 필요한 능력(예: coding, planning, qa_review, context_comprehension)이 부여됩니다. 어려운 작업에는 더 높은 난이도가 표시될 수도 있습니다. CEO 계층은 여기서 딱딱하게 모델을 지정하지 않습니다: 작업을 설명하고, 라우터가 나중에 작업별로 적합한 모델을 결정합니다.

따라서 계획은 진행 상황에 대한 인간이 읽을 수 있는 합의로 남고, 실행은 적응형으로 남을 수 있습니다.

3. 계획은 태스크 그래프로 변환됩니다

계획 승인 후 Argo는 작업을 태스크 그래프로 변환합니다. 노드는 종속성이 성공적으로 완료된 후에만 실행될 수 있습니다. 독립적인 작업은 병렬로 실행될 수 있습니다.

스케줄러는 준비된 노드를 추적 가능한 효용 휴리스틱으로 정렬합니다: 예상 품질에서 비용, 시간 및 위험 페널티를 뺀 값입니다. 노드가 중요 경로에 있으면, 전체 실행 기간을 결정하므로 동점일 때 우선순위를 받습니다.

높은 불확실성이나 높은 위험이 있는 경우 Argo는 처리 전에 공동 사고 모드를 선택할 수 있습니다: 여러 관점이 접근법을 개발하고 서로 비판하며 작업자에게 근거 있는 작업 접근법을 제공합니다. 이가 단지 기록만 되는지 실제로 실행되는지는 실행 전에 선택한 운영 프로필이 결정합니다.

4. 모든 태스크 전: 적합한 컨텍스트, 적합한 능력, 적합한 모델

작업자가 시작하기 전에 Argo는 역할과 작업에 맞춘 컨텍스트를 구축합니다. 여기에는 관련 파일, 종속성 결과 및 — 활성화된 경우 — 압축된 메모리 패키지 및 적절한 스킬 지침이 포함됩니다. Argo는 프로젝트 지식을 맹목적으로 전체 프롬프트에 넣지 않습니다. 메모리와 스킬은 관련성, 출처, 최신성, 비용 및 보안 상태에 따라 선택됩니다.

그런 다음 모델 라우터가 모델을 선택합니다. 먼저 접근 불가능하거나, 충분한 컨텍스트 창이 없거나, 할당량이 소진되었거나, 활성 정책을 위반하는 후보를 제외합니다. 남은 모델 중에서 Argo는 네 가지 요소를 평가합니다:

• 능력 적합성: 필요한 스킬에 대해 모델이 얼마나 잘 평가되는가? 여러 스킬이 있으면 평균을 봅니다.
• 비용: 요청 비용은 얼마인가 — 또는 활성 비용 라우팅 시 예상 성공 결과는?
• 모델 등급: 어려운, 보안 중요, 아키텍처 및 리뷰 작업은 플래그십 등급을 선호할 수 있습니다.
• 경험 값: 충분한 실제 결과 후에는 모델/스킬 조합의 최근 성공 및 반복 비율이 반영됩니다.

비용 계산을 위해 Argo는 성공의 기대 비용(Expected Cost of Success)을 사용할 수 있습니다: 직접 가격, 예상 반복, 검증 노력, 가능한 재작업 및 작은 지연 페널티입니다. 따라서 싼 개별 호출이 더 자주 실패하거나 재작업을 유발하면 자동으로 가장 저렴한 해결책이 아닙니다.

명시적 모델 추천은 사용 가능하고, 정책에 허용되며, 컨텍스트에 충분히 큰 경우에만 수락됩니다. CEO 계층의 계획, 위임 및 컨텍스트 이해에는 다시 이 세 가지 능력에 특화되어 선택된 강력한 모델이 사용됩니다.

5. 작업자는 작고 검증 가능한 단계로 태스크를 처리합니다

작업자는 단일 응답으로 작업하지 않습니다. 제한된 ReAct 루프를 거칩니다:

1. 모델이 구조화된 행동을 제안합니다 — 예를 들어 파일 읽기, 검색, 테스트 실행 또는 변경 작성.
2. 실행자가 권한, 경로, 명령 위험 및 활성 정책을 확인합니다.
3. Argo는 허용된 행동만 실행합니다.
4. 결과, diff 및 오류 메시지는 관찰로서 모델에 다시 흐릅니다.
5. 이를 바탕으로 작업자는 다음 단계를 수정하거나 작업을 완료합니다.

이를 통해 에이전트는 예를 들어 먼저 관련 코드를 읽고, 변경을 수행하고, 테스트를 실행하고, 테스트 결과를 다음 결정에 반영할 수 있습니다. 전체 흐름은 실행 로그에 남습니다.

출력 자체도 검사됩니다. 모델이 유효하지 않은 행동 JSON을 제공하면 Argo는 제한된 수리 루프를 요청할 수 있습니다. 엄격한 모드에서는 지속적으로 오류가 있는 출력이 모호한 텍스트를 행동으로 해석하는 대신 통제적으로 거부됩니다.

6. 오류 시: 맹목적 반복 대신 표적 수정

실패한 모든 태스크가 전체 실행 실패를 의미하는 것은 아닙니다. 오케스트레이션 엔진은 오류 원인을 구분하고 통제적으로 반응합니다:

• 일시적 오류는 고정된 한도 내에서 다시 시도될 수 있습니다.
• 단단한 검증 결과는 구체적인 지적 사항을 다음 시도를 위한 지시로 제공합니다.
• 활성화된 캐스케이딩 시 다음 시도는 이전 시도의 통찰을 이어받아 0에서 시작하지 않습니다.
• 실패 후 Argo는 더 강한 모델을 선호할 수 있습니다.
• 예산이 소진되면 비싼 맹목적 시도를 시작하지 않습니다: 노드는 문서화된 부분 결과로 끝나거나 눈에 띄게 에스컬레이션됩니다.

노드 전략은 finally 작업을 건너뛸 수 있는지, 통제적으로 실패하는지 또는 사용자 결정이 필요한지를 결정합니다. 종속 작업은 확인된 부분 결과만 받습니다. 이를 통해 지역적 오류가 나머지 계획으로 이어지는 조용한 오류가 되지 않습니다.

7. 구현 후: 리뷰, 검증 및 가능한 추가 주기

계획된 태스크가 처리되면 Argo는 통합 상태를 여러 관점에서 검사합니다:

• QA 에이전트는 파일을 읽고 테스트 명령을 실행할 수 있습니다.
• 아키텍처 에이전트는 읽기로 구조를 검사하며 의도적으로 쓰기 권한 없이 남습니다.
• 결정적 검증기는 테스트, 타입 검사 또는 린팅을 객관적 오라클로 실행할 수 있습니다.
• 모델 기반 및 결정적 소견은 종합 판단으로 통합됩니다.

QA, 아키텍처 또는 의무 검증기가 문제를 발견하면 Argo는 소견을 해당 작업에 할당합니다. 이 작업만 구체적 피드백으로 다시 처리됩니다. 이후 다시 리뷰와 검증이 따릅니다. 합의 모드 없이는 이 루프가 제한되며, 명시적으로 선택된 합의 모드에서는 사용자가 중지하거나 검사자가 동의할 때까지 계속됩니다.

관찰 모드의 검증기는 소견을 기록하지만 차단하지 않습니다. 의무 모드에서는 단단한 소견이 결과가 성공으로 간주되는 것을 막을 수 있습니다. 이렇게 추적 가능성을 포기하지 않고 운영 프로필별로 엄격함을 선택할 수 있습니다.

8. 상태가 검사된 후에만: 문서화 및 CEO 요약

완료된 작업 및 검사 주기 후 문서화 에이전트가 변경 사항을 기록할 수 있습니다. 그 후 CEO 계층이 사용자를 위한 요약을 작성합니다: 무엇이 완료되었는가? 무엇이 열려 있었는가? 어떤 검사가 실행되었는가? 어떤 파일이나 결정이 영향을 받았는가?

결과는 단순한 채팅 텍스트 이상입니다. 실행은 계획, 모델 선택, 비용, 행동, 검증 판단, 사용자 중단 및 이후 패치 결정을 위한 공통 식별자를 갖습니다. 이를 통해 Argo가 어떻게 결과에 도달했는지 추적할 수 있습니다.

9. 마지막으로 실제 작업 공간에 대해 인간이 결정합니다

기본적으로 Argo는 격리된 워크트리에서 작업합니다. 변경은 실제 프로젝트에 조용히 있지 않고 패치로那里에 있습니다. 자율성 수준에 따라 다음 세 가지 중 하나가 발생합니다:

• 패치는 수락, 부분 적용, 편집 또는 폐기를 위해 대기합니다.
• 성공한 패치는 자동으로 적용됩니다.
• 중간에 변경된 파일과 충돌 시 Argo는 눈에 띄게 멈춥니다. 타인 변경을 덮어쓰지 않습니다.

실패한 실행은 자동으로 적용되지 않습니다. 매우 자율적인 구성도 정책을 무효화하지 않습니다: 비밀 보호, 명령 규칙, 제공자 한계, 예산 한도 및 필요한 인간 게이트는 계속 유효합니다.

오케스트레이션 엔진이 수행하는 것

오케스트레이션 엔진은 다음에 응답할 모델이 무엇인지만 결정하지 않습니다. 그것은 사용자 의도, 설정, 계획, 병렬화, 모델 선택, 도구 사용, 오류 수정, 품질 보증 및 안전한 적용을 연결된 흐름으로 결합합니다.

기준은 "가능한 한 많은 에이전트"가 아닙니다. 추가 작업은 근거가 있는 곳에서만 발생합니다: 어려운 아키텍처 결정을 위한 더 강한 모델, 불확실 시 두 번째 사고 접근, 검증기 지적 후 표적 재시도 또는 위험한 효과 전 인간 승인.

방향이 thus 정해졌습니다.