루프 이해
에이전트가 챗봇, 스크립트, 기존 자동화와 다른 점을 알아보세요.
의도적으로 구축
제작 전 도구, 컨텍스트, 권한 및 평가를 설계합니다.
대규모로 운영
Yaju를 통해 함대를 배포, 관리, 관찰 및 최적화하세요.
모듈 1
실제로 AI 에이전트란 무엇인가
A language model answers. 대리인이 행동합니다. 차이점은 루프입니다. 모델은 목표를 받고, 다음 단계 하나를 결정하고, 도구를 통해 해당 단계를 수행하고, 돌아온 내용을 읽고, 다시 결정하고, 목표가 달성되거나 한계에 도달하거나 포기할 때까지 반복합니다.
그 구별은 들리는 것보다 더 중요합니다. 챗봇은 텍스트를 생성하고 중지합니다. 다음에 무슨 일이 일어나든 그 답을 읽고 그에 따라 행동하는 사람이 하는 일이다. 에이전트는 데이터베이스를 쿼리하고, 끌어오기 요청을 열고, 메시지를 보냅니다. 출력은 제안이 아니며 실제 시스템의 부작용입니다.
기존 자동화도 부작용을 낳지만 결과는 다릅니다. 스크립트, RPA 로봇 또는 워크플로 빌더는 누군가가 미리 그린 경로를 따릅니다. 모든 지점이 열거됩니다. 동일한 입력이 주어지면 영원히 동일한 작업을 수행합니다. 이것이 바로 이것이 신뢰할 수 있는 이유이며, 현실이 다이어그램 밖으로 나가는 순간을 깨뜨리는 정확한 이유입니다.
에이전트는 해당 관계를 반전시킵니다. 제어 흐름을 작성하지 않습니다. 목표를 설명하고, 가능한 작업 세트를 넘겨주고, 런타임 시 모델이 순서를 결정하도록 합니다. 절차는 에이전트가 관찰하는 내용에 따라 그 자리에서 매번 다르게 생성될 수 있습니다.
따라서 둘 중 하나를 선택할 때 실제 질문은 어느 것이 더 고급인지가 아닙니다. 절차가 얼마나 안정적인지입니다. 단계가 알려져 있고 반복 가능하며 거의 변경되지 않는 경우 스크립트를 작성하세요. 스크립트가 더 저렴하고 빠르며 결정적이며 쉽게 감사할 수 있습니다. 지저분한 지원 티켓, 구조화되지 않은 문서 또는 3단계가 2단계에서 발견한 내용에 따라 달라지는 조사와 같이 입력이 너무 다양하여 분기를 열거하는 것이 비실용적인 경우 에이전트는 비용을 벌기 시작합니다.
유용한 테스트: 도구를 치워 두세요. 남은 것이 여전히 유용하다면 챗봇을 구축한 것입니다. 무의미해지면 에이전트를 구축한 것입니다. 그리고 동일한 동작이 조건이 포함된 20줄의 코드일 수 있었다면 아마도 그 20줄을 대신 작성했어야 했습니다.
모듈 2
에이전트의 작동 방식(부분별)
어떤 프레임워크를 생성하든 거의 모든 에이전트는 동일한 소수의 부품으로 조립됩니다. 오류를 구분하는 방법을 배우는 것이 디버깅의 대부분입니다. 오류가 오류를 따라 명확하게 국한되기 때문입니다.
모델은 추론 엔진이다. 현재 상태를 읽고 다음에 무슨 일이 일어날지 결정합니다. 모델 선택은 기본값이 아니라 실제 엔지니어링 결정입니다. 더 큰 모델은 모호한 지침에서 더 잘 견디고, 작은 모델은 비용이 적게 들고 응답이 더 빠릅니다. 성숙한 상담원은 실제로 판단이 필요한 단계에 대해 비용이 많이 드는 모델을 남겨두면서 둘 이상의 상담원을 사용하는 경우가 많습니다.
일반적으로 시스템 프롬프트로 전달되는 지침은 성격이라기보다는 계약입니다. 그들은 역할, 제약, 출력 형식, 그리고 무엇보다도 완료의 정의를 설정합니다. 모호한 지시는 에이전트가 원을 그리며 헤매거나 중간에 멈추는 가장 일반적인 단일 원인입니다.
컨텍스트는 작업 자체, 검색한 기록, 이전 도구 호출의 결과 등 이 특정 단계에서 모델이 볼 수 있는 모든 것입니다. 컨테이너가 아닌 예산으로 취급하십시오. 관련 없는 재료에 소비된 모든 토큰은 비용이 들고 대기 시간을 추가하며 실제로 중요한 한 줄에 대한 모델의 관심을 희석시킵니다.
기억은 단계와 실행 사이에 살아남는 것입니다. 단기 기억은 대개 실행 중인 기록일 뿐입니다. 장기 기억은 의도적인 행위입니다. 지속되는 요약, 과거 결정 기록, 사용자 프로필입니다. 이 둘을 합치는 것은 에이전트가 세션 사이에 기억 상실증을 겪거나 자신의 역사에 서서히 빠져들게 되는 방식입니다.
도구는 에이전트가 호출할 수 있는 입력된 기능인 작업 공간입니다. 이름과 설명은 모델이 도구를 읽어서 선택하기 때문에 프롬프트의 일부입니다. 설명이 없는 processData라는 도구는 잘못 선택되어 모델 탓으로 돌릴 것입니다.
결정 단계는 모델이 인수가 포함된 도구 호출 또는 최종 답변을 내보내는 순간입니다. 그 하나의 선택을 잘하기 위해 모든 업스트림이 존재합니다.
실행은 런타임입니다. 실제로 도구를 호출하고, 루프 및 재시도 제한을 적용하고, 자격 증명을 연결하고, 오류를 처리하고, 발생한 상황을 기록하는 구성 요소입니다. 프레임워크는 추론 부분을 제공합니다. 런타임은 결과를 다른 사람 앞에 안전하게 공개할 수 있도록 하는 것입니다.
조립된 주기는 다음과 같습니다. 상태를 관찰하고, 하나의 작업을 선택하고, 실행하고, 결과를 관찰하고, 반복합니다. 뭔가 잘못되면 증상은 대개 한 부분을 가리킵니다. 자신 있게 틀린 대답은 일반적으로 맥락이 누락된 것입니다. 부적절한 조치는 일반적으로 잘못된 도구 설명입니다. 결코 끝나지 않는 실행은 일반적으로 완료에 대한 정의가 누락된 것입니다.
모듈 3
좋은 에이전트 확보: 구축, 포크 또는 채택
작업 에이전트에게 정직하게 접근하는 세 가지 경로가 있으며 예측 가능한 방식으로 제어와 시간을 교환합니다.
SDK를 사용하여 직접 작성할 수 있습니다. 이를 통해 프롬프트, 도구 표면 및 오류 처리를 완벽하게 제어할 수 있으며 가장 많은 시간이 소요됩니다. 작업이 귀하의 비즈니스와 관련되어 있고 일반 버전이 귀하의 규칙을 알 수 없는 경우 올바른 선택입니다. 모델을 사용하여 에이전트 초안을 작성하는 것은 괜찮고 점점 더 정상화되지만 출력을 유능한 낯선 사람의 첫 번째 초안으로 취급합니다. 에이전트는 사용자의 데이터, 제약 조건 또는 잘못된 답변으로 인해 발생하는 비용을 알지 못합니다.
공개 저장소에서 포크할 수 있습니다. 이것은 빠르며 대부분의 사람들이 시작하는 곳입니다. 이는 또한 자신이 만들지 않은 가정을 상속받는다는 의미이므로 실행하기 전에 읽어보세요. 도구가 실제로 도달할 수 있는 대상, 프롬프트가 신뢰할 수 없는 입력을 보간하는지 여부, 자격 증명이 어떻게 도착할 것으로 예상되는지, 라이선스에서 사용을 허용하는지 여부를 확인하세요. 중요한 것에 대한 쓰기 액세스 권한을 조용히 갖고 있는 포크된 에이전트는 프로덕션 환경에서 발견하기에는 매우 놀라운 일입니다.
또는 검색, 포크, 게시, 개선 등 오픈 소스 리듬을 기반으로 구축된 Yaju 에이전트 허브와 같은 카탈로그에서 프로덕션용 에이전트를 채택할 수 있습니다. 공개 저장소와의 차이점은 일회성 프롬프트 데모가 아닌 엔드투엔드 작동을 위한 에이전트이며 관리되는 런타임에 맞게 이미 구성되어 있다는 점입니다.
어떤 경로를 선택하든 에이전트가 처음으로 좋은 답변을 생성할 때 완료되는 것은 아닙니다. 무엇이든 조정하기 전에 무시하고 싶은 어색한 사례를 포함하여 10~30개의 실제 사례로 구성된 작은 평가 세트를 구성하십시오. 각각에 대한 정답이 어떤 것인지 미리 적어 두세요. 사실 이후의 결과를 인상으로 판단하는 것은 에이전트가 단지 변경되었을 때 개선되었다고 팀이 스스로 확신하는 방법입니다.
그런 다음 의도적으로 반복하십시오. 한 번에 하나씩 변경하고 전체 세트를 다시 실행하여 점수를 유지하세요. 모든 생산 실패를 회귀 사례로 세트에 추가하면 동일한 실수가 조용히 반복되지 않습니다. 적대적인 사례도 포함합니다. 에이전트가 충분한 정보 없이 지나치거나 발명하거나 행동하도록 설계된 입력입니다.
마지막으로 개인화하세요. 귀하의 데이터, 명명 규칙, 에스컬레이션 규칙, 완료 정의. 거의 맞는 일반 에이전트는 전혀 에이전트가 없는 것보다 더 나쁜 경우가 많습니다. 왜냐하면 사람들은 두 번째 잘못된 대답 후에 이를 포기하고 신뢰를 구축하는 것보다 재건하기가 훨씬 어렵기 때문입니다.
그리고 은퇴를 테이블 위에 두십시오. 사용되지 않거나 그 아래에서 작업이 변경된 에이전트는 감정을 유지하기보다는 꺼야 합니다.
모듈 4
도구, 컨텍스트 및 기능
에이전트의 능력은 사용자가 제공하는 작업과 정보만큼만 가능합니다. 이곳은 실제 엔지니어링의 대부분이 살고 있는 곳입니다.
도구를 좁고 동사 모양으로 디자인하세요. 고객 주문을 읽는 도구 중 하나가 데이터베이스를 관리하는 도구보다 낫습니다. 좁은 도구는 명확한 결정을 내리고, 허가하기 쉽고, 해석할 수 있는 방식으로 실패합니다. 광범위한 도구는 모델이 즉흥적으로 행동하도록 유도하며 즉흥적인 행동은 해를 끼칩니다.
동료를 위한 설명이 아닌 모델에 대한 설명을 작성하세요. 도구가 무엇을 하는지, 언제 사용해야 하는지, 언제 사용하지 말아야 하는지, 무엇을 반환하는지 말해야 합니다. 인수를 입력하고 유효성을 검사합니다. 여기서 스키마는 관료주의가 아니라 거부된 호출과 프로덕션 시스템에 대한 잘못된 형식의 쓰기 간의 차이입니다.
추측에 따라 도구를 추가하지 마세요. 행동 공간이 커짐에 따라 선택 품질이 저하됩니다. 사용 가능한 도구가 30개 있으면 모델은 작업보다는 선택에 추론을 소비하고 더 자주 잘못 선택합니다. 두 도구가 겹치는 경우 병합하거나 하나를 삭제하세요.
컨텍스트는 덤프되지 않고 검색되어야 합니다. 이 작업에 필요한 특정 기록을 가져와 전달합니다. 소스가 큰 경우 전체 문서를 붙여넣기보다는 현명하게 청크를 나누어 검색합니다. 인용문을 다시 요청하여 해당 인용문을 작성한 구절에서 답변을 추적할 수 있습니다.
읽기와 쓰기를 분리하세요. 대부분의 에이전트에는 광범위한 읽기 액세스와 매우 좁은 쓰기 액세스가 필요하며 이를 하나의 권한으로 처리하는 것이 요약 에이전트가 레코드를 삭제할 수 있는 방법입니다. 쓰기가 되돌릴 수 없는 경우 그 앞에 사람을 배치합니다.
통합은 이것이 코딩 문제가 아닌 조직의 문제가 되는 곳입니다. 동일한 업스트림 시스템에 자체 연결을 연결하는 모든 팀은 중복된 자격 증명, 일관되지 않은 정책 및 단일 감사 추적을 생성하지 않습니다. MCP와 같은 개방형 표준을 사용하면 호환되는 모든 에이전트가 팀당 하나가 아닌 업스트림 시스템당 하나의 바인딩을 사용하여 동일한 관리 통합을 재사용할 수 있습니다.
자격 증명은 자체 규칙을 가질 자격이 있으며 간단합니다. 에이전트는 비밀을 보유하지 않습니다. 작업을 요청하고 플랫폼은 아웃바운드 호출 순간에 자격 증명을 연결합니다. 이렇게 하면 유출된 프롬프트, 자세한 로그 또는 공유된 기록이 유출된 키가 되지 않습니다.
마지막으로 부분적인 실패에 대한 계획을 세웁니다. 실제 시스템은 속도 제한, 페이지 매기기, 시간 초과 및 절반의 답변을 반환합니다. 모든 도구 응답을 성공으로 간주하는 에이전트는 자신 있게 아무것도 기반하지 않을 것입니다. 모델이 추론할 수 있는 구조화된 데이터로 오류를 반환하고, 해결하기보다는 실행을 중지해야 하는 오류를 미리 결정합니다.
모듈 5
한계, 실패 모드 및 정직한 기대
자율성은 자신을 가장 많이 과대평가하는 속성이므로 무엇이 잘못되었는지 정확하게 파악하는 것이 좋습니다.
오류가 복합적으로 발생합니다. 루프의 각 단계가 95% 신뢰도가 있는 경우 20단계 실행은 전체 신뢰도가 약 36%에 불과합니다. 더 나쁜 것은 3단계의 잘못된 가정이 스스로를 알리지 않는다는 것입니다. 이는 4단계에서 20단계까지 조용히 형성되고 에이전트가 자신의 실수와 일치했기 때문에 최종 출력이 일관되게 보입니다.
모델이 제작됩니다. 무작위가 아니라 그럴듯하게, 이것이 문제입니다. 발명된 기록 식별자, API에 존재하지 않는 기능, 검색된 적이 없는 문서의 확실한 인용. 제작은 검증이 가장 지루한 곳에서 가장 위험하므로 발견하기를 바라기보다는 설계 검증을 수행하십시오.
컨텍스트 오류는 보기보다 미묘합니다. 누락된 컨텍스트는 추측을 낳습니다. 오래된 컨텍스트는 지난 분기에 올바른 결정을 내렸습니다. 과도한 맥락은 기술적으로 답을 말했지만 알아차리지 못한 모델을 생성합니다. 각각은 추론 실패처럼 보이지만 어느 것도 그렇지 않습니다.
비용은 비선형적으로 동작합니다. 루프의 모든 단일 단계에서 긴 컨텍스트가 지불되고 재시도가 곱해지며 15단계 후에 실패한 실행은 3단계에서 성공한 실행보다 비용이 더 많이 듭니다. 테스트 사례는 짧고 실제 사례는 그렇지 않기 때문에 테스트에서 저렴해 보이는 에이전트는 프로덕션 환경에서 일상적으로 사람들을 놀라게 합니다.
보안은 일반 애플리케이션 보안과 근본적으로 다릅니다. 상담원이 읽는 모든 콘텐츠는 이를 지시하려고 시도할 수 있으므로 지원 티켓, 웹 페이지 또는 PDF가 주입 표면이 됩니다. 이를 오용하도록 설득할 수 있는 합법적인 자격 증명을 가진 에이전트는 혼란스러운 대리인이며 일반적인 방어 수단은 적용되지 않습니다. 언어를 위생적으로 처리하려고 하기보다는 도구가 도달할 수 있는 범위를 제한하세요.
유지관리는 지속적으로 이루어집니다. 변화하는 비즈니스에 맞춰 메시지가 표류하고, 업스트림 API의 형태가 변경되고, 모델이 더 이상 사용되지 않거나 자동으로 업데이트되고, 3월에 통과된 평가 제품군이 6월에 조용히 실패하기 시작합니다. 에이전트는 한 번만 제공되는 프로젝트가 아니라 소유자가 실행 중인 시스템입니다.
이 모든 것은 이 과정에서 가장 유행에 뒤떨어진 결론으로 이어집니다. 즉, 많은 평범한 에이전트보다 몇 명의 좋은 에이전트를 선호한다는 것입니다. 10명의 미숙한 상담원은 자신의 업무를 제대로 수행하는 2명의 상담원보다 비용이 더 많이 들고, 더 자주 휴식을 취하고, 신뢰도를 더 빠르게 약화시킵니다. 각각의 추가 에이전트는 모니터링할 표면, 관리할 자격 증명 및 설명할 동작을 추가합니다. 하나를 만들지 않거나 끄기로 결정하는 것은 합법적이고 충분히 활용되지 않는 결과입니다.
모듈 6
외부 세계를 위한 에이전트 패키징
작성된 머신에서만 실행되는 에이전트가 프로토타입입니다. 패키징은 다른 사람, 팀 또는 환경이 질문 없이 실행할 수 있는 것으로 바꾸는 것입니다.
재현성부터 시작하세요. 최신 해결 방법을 받아들이는 대신 종속성을 고정하세요. 발신자가 보낼 내용과 돌아올 내용을 정확히 알 수 있도록 스키마를 사용하여 입력 및 출력을 입력합니다. 코드 외부에서 구성을 유지하면 동일한 아티팩트가 편집 없이 스테이징 및 프로덕션에서 실행될 수 있습니다.
함께 여행하면 안 되는 것에 대해 명시적으로 설명하세요. 물론 비밀이지만 환경별 엔드포인트, 하드 코딩된 계정 식별자 및 절대 경로도 있습니다. 값 없이 에이전트를 시작할 수 없는 경우 실행 중간에 실행하는 것이 아니라 시작 시 어떤 값이 누락되었는지 큰 소리로 실패해야 합니다.
에이전트가 작동하기 위해 필요한 계약(예: 예상되는 도구, 해당 도구에 필요한 권한, 가정하는 모델, 대략적인 실행당 비용)을 선언합니다. 검토자는 해당 선언만으로 승인 여부를 결정할 수 있어야 합니다.
소프트웨어처럼 버전을 지정하세요. 그것이 바로 소프트웨어이기 때문입니다. Git에 보관하고, 브랜치가 아닌 특정 버전을 가리키고, 두 버전을 비교하여 프롬프트와 코드에서 변경된 사항을 확인하고, 변경 사항이 보기보다 나쁠 경우 하나의 명령으로 롤백할 수 있습니다.
에이전트와 함께 평가 세트를 배송합니다. 이는 에이전트가 수행해야 하는 작업에 대한 유일하고 정직한 설명이며, 이를 상속받은 사람은 출력을 신뢰하기 전에 자신의 환경이 사용자의 환경과 동일하게 작동하는지 확인할 수 있습니다.
마지막으로 이 에이전트의 용도, 절대 수행해서는 안 되는 작업, 소유자, 실패 시 수행할 작업 등의 경계를 일반 언어로 기록합니다. 이 메모의 비용은 10분이며 채택된 에이전트와 조용히 버려진 에이전트의 차이입니다.
모듈 7
Yaju에 에이전트 배포
배포는 에이전트가 더 이상 혼자만의 것이 아닌 다른 사람들이 의존하는 시스템의 일부가 되는 지점입니다. 그것을 실행하는 기술적 행위는 쉬운 절반입니다.
생산이란 노트북에서는 사실이 아닌 네 가지 사실이 사실임을 의미합니다. 에이전트에는 신원과 명명된 소유자가 있습니다. 무언가가 도달할 수 있는 범위를 강제합니다. 그것이 한 모든 것이 기록되었습니다. 그리고 누군가는 그 비용이 얼마인지 알 수 있습니다. 이들 중 하나라도 누락된 에이전트는 의도된 것이 아니라 실수로 프로덕션에서 실행되고 있습니다.
Yaju에서 그 중 첫 번째는 자동입니다. 에이전트는 실행되는 순간 고유한 ID와 소유자를 가져오므로 누군가의 터미널에 거주하는 대신 하나의 카탈로그에 나타납니다. 이는 정책 문제가 아닌 가시성 문제인 섀도우 에이전트에 대한 실질적인 답변입니다.
거기에서 에이전트 오케스트레이션 시스템은 에이전트가 필요한 순간에 필요한 것을 연결합니다. 자격 증명은 런타임 시 조직 수준 저장소에서 확인되므로 코드나 프롬프트에 저장되지 않습니다. 액세스 규칙은 각 아웃바운드 통화 전에 네트워크가 아닌 작업 공간 및 상담원 수준에서 평가됩니다. 정책은 조치가 취해지는 순간 시행되며, 사고 발생 시 누구도 읽지 않는 문서에 설명되어 있지 않습니다.
관찰 가능성은 첫 번째 놀라움 이후에 추가되는 것이 아니라 첫 번째 실행부터 켜져 있습니다. 모든 모델 호출, 도구 호출, 입력, 출력 및 결정은 재생, 검색 및 내보낼 수 있는 세션 추적으로 캡처됩니다. 감사인이 특정 날짜에 무슨 일이 일어났는지 물으면 조사가 아닌 검색이라고 대답합니다.
위험한 행동의 경우 명시적으로 루프에 사람을 포함시킵니다. 런타임은 되돌릴 수 없는 단계 전에 일시 중지되고 승인을 요청하며 승인된 후에만 계속됩니다. 이는 마찰이 거의 없이 많은 신뢰를 얻는 설계 결정이며, 사고 후에 추가하는 것보다 나중에 긴장을 푸는 것이 훨씬 쉽습니다.
배포 자체는 명령줄에서 이루어지며 이는 말처럼 들리는 것보다 중요합니다. 동일한 명령이 기존 CI/CD 파이프라인 내에서 작동하므로 에이전트 배송은 별도의 절차가 필요하지 않고 다른 것을 배송하는 것처럼 보입니다. 데이터가 귀하의 환경을 떠날 수 없는 경우 동일한 에이전트 오케스트레이션 시스템이 자체 호스팅되거나 자체 클라우드에서 또는 완전히 에어갭으로 실행됩니다.
이 중 어느 것도 에이전트 구축 방식을 변경할 필요가 없습니다. 프레임워크에 관계없이 자체 에이전트를 가져오면 동일한 ID, 자격 증명, 정책 및 추적이 적용됩니다. 이러한 중립성은 의도적인 것입니다. 누구도 이미 모델 제공자와 함께 갖고 있는 것 위에 두 번째 종속 계층을 원하지 않습니다.
실제로는 점진적으로 출시하세요. 먼저 아무도 작업하지 않는 출력을 생성하는 섀도우 모드에서 에이전트를 실행하고 사람이 수행한 작업과 비교합니다. 그런 다음 승인 게이트를 사용하여 좁은 실제 범위를 제공합니다. 흔적이 지루할 때만 넓히십시오.
모듈 8
Yaju 에이전트 시스템으로 차량 운영
하나의 에이전트는 프로젝트입니다. 30명의 상담원은 운영 문제이며 대부분의 팀이 예상하는 것보다 빨리 도착하며 일반적으로 누구도 결정하지 못한 채 도착합니다.
변화는 양적이라기보다는 질적이다. 하나의 에이전트를 사용하면 그 역할을 기억할 수 있습니다. 각각 자신의 프레임워크를 선택한 팀에 분산된 30개의 팀에서는 전체 그림을 아는 사람이 아무도 없으며 중요한 질문에 답할 수 없게 됩니다. 무엇이 실행되고 있는지, 누가 소유하고 있는지, 무엇을 만질 수 있는지, 무엇을 했는지, 비용이 얼마나 드는지.
재고가 먼저입니다. 다른 모든 것이 재고에 달려 있기 때문입니다. 모든 에이전트는 이를 생성한 ID, 소유자 및 버전을 보유합니다. 플랫폼 외부에 구축된 에이전트는 플랫폼에 구축된 에이전트와 동일한 조건으로 카탈로그화되며, 이는 인벤토리가 정직하게 유지되는 유일한 방법입니다.
제어는 중앙에서 적용되고 균일하게 시행됩니다. 플랫폼 팀이 정책을 한 번 설정하면 런타임은 이를 실행 순간에 모든 팀의 에이전트에 적용합니다. 이는 각 에이전트에 대한 권한을 요청하고 싶지 않은 엔지니어링과 볼 수 없는 것을 승인할 수 없는 보안 간의 일반적인 대립을 해결하는 배열입니다.
Fleet 규모의 관찰 가능성은 로그 보존 이상의 의미를 갖습니다. 추적을 사용하면 개별 실행을 재생할 수 있습니다. 불변의 감사 추적은 현재 사용자, 사용된 자격 증명 및 생성된 출력을 기록합니다. 평가 점수는 동작, 구조, 대기 시간 및 비용을 포함하여 사용자가 정의한 기준에 따라 지속적으로 실행되며, 중요한 확인에 실패하면 이에 대한 보고서를 제출하는 대신 에이전트가 중지됩니다. 이는 수동적인 로깅에서 적극적인 품질 시행으로의 단계입니다.
비용은 팀이 마지막으로 발견하고 가장 후회하는 차원입니다. 토큰이 아닌 통화로 에이전트, 작업 공간, 사용자, 제공자 및 모델에 따른 지출은 설명할 수 없는 송장을 결정 목록으로 바꿉니다. 그런 다음 회로 차단 예산을 통해 이를 실행 가능하게 만듭니다. 즉, 80%에서 경고하고, 100%에서 차단하고, 나중에 보고하는 대신 오버런을 중지합니다. 경고는 경고합니다. 차단기만이 실제로 지출을 중지합니다.
비용이 가시화되면 일화적인 비용이 아닌 체계적으로 비용을 줄일 수 있습니다. 최적화는 더 작은 모델 시도, 프롬프트 및 컨텍스트 트리밍, 결과 개선 없이 비용만 추가하는 도구 제거, 모델에서 결정적 단계를 일반 코드로 이동 등 네 가지 요소에 걸쳐 작동합니다. 각 권장 사항은 적용되기 전에 자체 평가를 기준으로 측정되므로 비용 절감은 결코 좋은 품질로 조용히 이루어지지 않습니다.
통합은 동일한 중앙 방식으로 관리됩니다. 업스트림 시스템당 하나의 바인딩, 승인된 카탈로그 팀이 요청할 수 있으며 각 팀이 자체 연결 및 자격 증명 사본을 유지하는 대신 모든 시스템에 대한 단일 감사 추적이 가능합니다.
조정은 규모에 따라 실질적인 관심사가 됩니다. 에이전트는 서로 직접 작업하고 두 팀이 동일한 문제를 독립적으로 해결할 때 서로 복제하며 동일한 속도 제한을 놓고 경쟁합니다. 재사용 가능한 에이전트와 스킬이 포함된 공유 카탈로그는 가장 저렴한 중복 수정 방법이며, 엔지니어의 첫 번째 에이전트를 몇 주가 아닌 몇 시간 만에 배송할 수 있는 이유이기도 합니다.
마지막으로 플릿을 수명 주기가 있는 것으로 취급합니다. 에이전트는 실험에서 프로덕션으로 승격되고, 더 나은 에이전트가 존재하면 더 이상 사용되지 않으며, 작업이 사라지면 은퇴합니다. 팀당 채택, 에이전트당 비용 및 평가 대비 성능을 측정하는 것은 대화를 실험 계산을 넘어 단순히 AI를 사용하는 것이 아니라 AI 운영으로 이동시키는 것입니다.
과정을 순서대로 진행하세요. 각 모듈은 첫 번째 에이전트 루프부터 ID, 정책, 추적, 비용 제어 및 차량 운영에 이르기까지 마지막 모듈을 기반으로 구축됩니다.
프로그레시브 모듈
사전 경험이 필요합니다