Hermes 에이전트 아키텍처 가이드: 자체 개선 AI 에이전트 구축 방법

에이전트 아키텍처가 프롬프트보다 더 중요한 이유

많은 팀이 즉각적인 개선으로 시작합니다. 지침을 다시 작성하고, 예제를 추가하고, 어조를 조정하고, 모델을 "더 스마트하게" 만들기 위해 노력합니다. 도움이 되지만 어느 정도까지만 가능합니다.

더 깊은 문제는 일반적으로 아키텍처입니다. 상담원은 어떤 도구를 사용할 수 있는지 알지 못할 수도 있습니다. 잘못된 매개변수를 사용하여 올바른 도구를 호출할 수 있습니다. 세 단계 전에 일어난 일을 잊어버릴 수도 있습니다. 답변이 이미 충분한 후에도 계속 반복될 수 있습니다. 일부 작업에 승인이 필요한 경우에도 모든 작업을 동일하게 안전한 것으로 취급할 수 있습니다.

유용한 에이전트에는 영리한 시스템 프롬프트 이상의 것이 필요합니다. 경계, 기억, 관찰 가능성, 도구 설계, 피드백 및 평가가 필요합니다. 이러한 조각이 없으면 에이전트를 예측할 수 없게 됩니다. 데모에서는 인상적으로 보일 수 있지만 프로덕션에서는 신뢰할 수 없는 것처럼 보일 수 있습니다.

이것이 Hermes Agent 아키텍처가 의사 결정을 위한 운영 체제로 설계되어야 하는 이유입니다. 모델은 추론 엔진이지만 주변 시스템은 모델이 볼 수 있는 것, 수행할 수 있는 것, 진행 상황을 기록하는 방법, 실수를 처리하는 방법 및 인간이 개입해야 하는 시기를 결정합니다.

핵심 헤르메스 에이전트 루프

건축의 중심에는 이해하고, 계획하고, 행동하고, 관찰하고, 수정하고, 마무리하는 반복적인 주기가 있습니다.

에이전트는 먼저 사용자의 목표를 해석합니다. 약한 에이전트는 목표를 직접적인 지시로 간주하고 행동에 돌입합니다. 더 강력한 에이전트는 필요한 결과, 사용 가능한 컨텍스트, 누락된 정보 및 작업의 위험 수준을 식별합니다.

그런 다음 계획을 만듭니다. 이 계획은 눈에 띄는 긴 에세이일 필요는 없습니다. 실제로 생산 대리인은 간결한 계획을 통해 이점을 얻는 경우가 많습니다. 중요한 점은 에이전트가 어떤 일련의 작업이 적합한지 결정해야 한다는 것입니다.

계획을 세운 후 에이전트는 도구를 통해 작업을 수행합니다. 도구에는 웹 검색, 파일 읽기, 코드 실행, 데이터베이스 쿼리, 브라우저 자동화, CRM 액세스, 스프레드시트 편집, 이메일 초안 작성 또는 내부 API가 포함될 수 있습니다. 도구 호출은 상담원이 순수한 언어를 떠나 작업 환경에 닿는 곳입니다.

관찰 단계는 많은 나쁜 에이전트가 중단되는 단계입니다. 도구 결과는 자동으로 유용하지 않습니다. 에이전트는 이를 검사하고 작업 상태가 변경되었는지 여부를 결정한 후 다음에 수행할 작업을 선택해야 합니다. 검색 결과가 오래된 경우 상담원은 다시 검색해야 합니다. 파일에 예상 필드가 포함되어 있지 않으면 적응해야 합니다. API가 오류를 반환하면 성공을 환각하기보다는 복구해야 합니다.

루프는 완료 조건이 충족될 때만 종료됩니다. 해당 조건은 최종 답변, 저장된 초안, 완성된 보고서, 제출된 양식 또는 인간 검토자에게 전달일 수 있습니다.

자기 개선 에이전트의 5가지 아키텍처 계층

헤르메스 스타일의 자기 개선 에이전트는 인터페이스, 추론, 도구, 기억, 평가의 5개 계층을 통해 이해될 수 있습니다.

인터페이스 계층

인터페이스 계층은 사용자의 의도를 포착합니다. 채팅 창, 데스크톱 앱, 브라우저 확장, Slack 봇, Telegram 봇, 내부 대시보드 또는 워크플로 트리거일 수 있습니다. 이 레이어는 단순히 원시 사용자 텍스트를 모델에 전달해서는 안 됩니다. 작업 유형을 명확히 하고, 사용 가능한 컨텍스트를 첨부하고, 권한을 식별하고, 출력 형식을 정의해야 합니다. 좋은 인터페이스 계층은 에이전트가 비용이 많이 드는 다단계 작업을 시작하기 전에 모호성을 줄여줍니다.

추론 계층

추론 계층은 다음에 수행할 작업을 결정합니다. 모델이 현재 상태를 해석하고 작업을 선택하는 곳입니다. 추론은 행동을 안내할 수 있을 만큼 충분히 구조화되어야 하지만, 부서지기 쉬울 정도로 너무 경직되어서는 안 됩니다. 최고의 추론 레이어는 가장 긴 프롬프트가 아닙니다. 가장 명확한 계약입니다. 에이전트에게 성공의 모습, 하지 말아야 할 작업, 신뢰할 수 있는 소스, 확인이 필요한 작업, 증거가 약한 경우 대응 방법을 알려줍니다.

도구 레이어

도구 계층은 에이전트가 유용해지는 곳입니다. 도구는 단순한 기술 추가 기능이 아닙니다. 이는 상담원 언어의 일부입니다. 도구 이름이 모호하거나 매개변수가 혼란스럽거나 출력에 잡음이 있는 경우 모델에서 실수가 발생합니다. get_data이라는 도구는 search_customer_orders_by_email이라는 도구보다 훨씬 약합니다. 좋은 도구 디자인은 올바른 행동을 분명하게 만듭니다. 또한 위험한 행동을 더 어렵게 만듭니다. 예를 들어 이메일 도구는 '초안 작성'과 '이메일 보내기'를 구분해야 합니다. 결제 도구는 환불을 처리하기 전에 명시적인 승인을 요구해야 합니다. 생산 과정에서 도구 설계는 종종 모델 선택만큼 중요합니다.

메모리 계층

자기계발은 기억력에 달려 있는데, 기억력을 잘못 이해하는 경우가 많습니다. 상담원이 모든 것을 기억할 필요는 없습니다. 사실, 너무 많이 기억하면 상황이 더 악화될 수 있습니다. 메모리 계층은 사용자 기본 설정, 반복되는 작업 흐름, 성공적인 도구 패턴, 실패한 시도, 승인 규칙, 프로젝트 컨텍스트, 재사용 가능한 기술 등 향후 의사 결정을 개선하는 정보를 저장해야 합니다. 일반적으로 여러 유형의 메모리가 있습니다. 단기 기억은 현재 실행을 추적합니다. 장기 기억은 지속적인 선호 사항과 작업 흐름 지식을 저장합니다. 일화 기억은 과거의 시도와 결과를 기록합니다. 스킬 메모리는 반복되는 절차를 재사용 가능한 플레이북으로 바꿔줍니다. 위험은 오래된 메모리입니다. 강력한 아키텍처에는 메모리 검토, 만료, 사용자 수정 및 소스 태깅이 포함됩니다.

평가 계층

평가 계층은 "실행"하는 에이전트와 개선하는 에이전트 간의 차이입니다. 스스로 발전하는 AI 에이전트에는 피드백 신호가 필요합니다. 일부 피드백은 자동으로 이루어집니다. 코드가 테스트를 통과했나요? API 호출이 성공했나요? 생성된 JSON이 스키마와 일치합니까? 다른 피드백은 사람의 의견입니다. 고객 지원 초안이 공감적으로 들렸나요? 연구 개요에 올바른 출처가 포함되어 있습니까? 이것이 개선이 체계적으로 이루어지는 방식입니다. 팀은 단순히 “에이전트가 나쁜 답변을 했다”고만 말하지 않는다. 불분명한 지침, 컨텍스트 누락, 잘못된 도구 스키마, 약한 검색, 안전하지 않은 메모리 또는 잘못된 중지 논리 등 실패 지점을 식별할 수 있습니다.

자기 개선이 실제로 어떻게 작동하는지

자기 개선은 에이전트가 모든 작업 후에 자체 신경 가중치를 마법처럼 다시 작성한다는 의미는 아닙니다. 대부분의 실제 시스템에서 자기 개선은 더 나은 컨텍스트, 더 나은 메모리, 더 나은 도구 및 더 나은 평가 루프를 통해 이루어집니다.

SEO 콘텐츠 제작에 에이전트가 사용된다고 가정해 보겠습니다. 처음에는 경쟁사 검색, 제목 추출, 개요 초안 작성, 기사 작성, 메타데이터 생성 등의 일반적인 작업 흐름을 따를 수 있습니다. 여러 번 실행한 후 시스템은 편집자의 반복된 수정 사항을 감지합니다. 어쩌면 초안이 너무 홍보적일 수도 있습니다. 어쩌면 소개가 너무 느린 것 같습니다. 어쩌면 내부 링크가 종종 관련이 없을 수도 있습니다.

자체 개선 아키텍처는 이러한 수정 사항을 포착합니다. 스타일 메모리를 업데이트하고, 콘텐츠 체크리스트를 개선하고, 평가 루브릭을 변경하거나, 재사용 가능한 "편집자 합격" 기술을 만들 수 있습니다. 모델 자체는 동일할 수 있지만 이를 둘러싼 시스템은 팀의 표준에 더욱 부합하게 됩니다.

이것이 스스로 개선되는 AI 에이전트의 실질적인 의미입니다. 환경이 그들을 가르치기 때문에 그들은 향상됩니다. 피드백은 지침이 됩니다. 반복된 행동은 기술이 됩니다. 실수는 테스트 사례가 됩니다. 사람의 검토는 채팅 기록으로 사라지는 대신 구조화된 메모리가 됩니다.

구체적인 작업 흐름: 연구 요청부터 최종 요약까지

에이전트에게 새로운 생산성 앱에 대한 경쟁 연구 개요를 준비하도록 요청하는 제품 관리자를 생각해 보십시오.

약한 보조자는 메모리에서 일반적인 시장 요약을 생성할 수 있습니다. Hermes 스타일 에이전트는 작업에 다르게 접근합니다. 첫째, 경쟁사, 포지셔닝, 가격, 기능 격차, 사용자 불만 등 목표를 명확히 합니다. 그런 다음 현재 공개 소스를 검색하고, 관련 페이지를 열고, 데이터를 추출하고, 인용을 기록합니다. 결과가 일관되지 않으면 추가 검사를 수행합니다. 비교표를 만들고, 리뷰의 패턴을 식별하고, 검증된 사실을 해석에서 분리할 수 있습니다.

다음으로 상담원은 브리핑 초안을 작성합니다. 평가자 단계에서는 개요가 원래 질문에 대한 답변인지, 주장이 뒷받침되는지, 권장 사항이 실행 가능한지 여부를 확인합니다. 요약 내용이 너무 광범위하면 상담사가 내용을 수정합니다. 중요한 경쟁사가 누락된 경우 다시 검색합니다. 출력물이 경영진을 대상으로 하는 경우 결론이 짧아지고 전술적 세부 사항이 부록으로 이동됩니다.

최종 결과물은 단순한 텍스트가 아닙니다. 이는 연구, 검증, 종합, 비평, 수정이라는 통제된 루프의 결과입니다.

이러한 유형의 워크플로는 에이전트 아키텍처가 중요한 이유를 보여줍니다. 가치는 하나의 인상적인 모델 응답이 아니라 전체 시스템에서 나옵니다.