Viv(@Vtrivedy10)의 스레드

개방형 질문을 통한 에이전트 하네스 정신 모델 구축 요약: - 에이전트의 단순화된 뷰, 작업별 하네스 + 모델 선택이 가능한 시스템입니다. - 하네스 내에서 모델은 대체 불가능합니다. 모델의 지능이 불안정하기 때문에 새 모델로 "업그레이드"하려면 더 많은 작업이 필요합니다. - 우리가 "일반 용도" 에이전트/하네스라고 부르는 것은 실제로 "사용자 정의에 소요되는 시간"과 작업 성능 간의 균형입니다. - 자율 최적화(메타 프롬프팅, 템플릿화, dspy 등)는 하네스 엔지니어링의 흥미로운 분야입니다. 사전 필수 조건: 에이전트의 "유용한 작업 단위"를 고려하고 이를 작업이라고 부르겠습니다. 질문: 질문 1: "범용" 에이전트 하네스가 존재할까요? 훨씬 더 많은 엔지니어링 작업 없이도 충분히 유용하다고 생각할 만큼 다양한 작업을 해결하는 데 도움이 되는 하네스 같은 것 말입니다. "Claude Code의 기본 하네스를 프롬프트로 표시해 봅시다"라고 생각해 보세요. 질문 2: "존재한다"는 것은 무슨 뜻인가요? 예를 들어, 제 작업에 맞게 하네스를 최적화하지 않으면 얼마나 많은 성능을 포기하게 되나요? 질문 3: "적시 생산 방식(Just-In-Time Harness)" 세대의 세상은 어떤 모습일까요? 우리는 "정말 뛰어난 작업 성능을 원한다"와 "하네스 최적화에 적절한 시간을 투자하고 싶다"라는 두 가지 문제를 해결하고 싶습니다. 생각: 이것은 무엇과 비슷한가요?: 하네스는 프롬프트와 동일하지만, 그 원리는 @DSPyOSS(Miprov2, GEPA 등)와 유사합니다. 우리는 하네스의 구성 요소들을 작업(프롬프트, 도구 설계, 하위 에이전트 정의, 유용한 컨텍스트)에 맞춰 동시에, 이상적으로는 자율적으로 최적화하고자 합니다. 모델은 대체 불가능합니다. 모델과 하네스를 분리해서는 안 됩니다. 둘은 상호 의존적이기 때문입니다! 실제로 중요한 것은 작업 성능이므로, 해당 작업을 위한 모델+하네스 쌍을 설계해야 합니다. 예를 들어, SWE 작업을 하는 경우 OCR을 위한 프롬프트+툴링+모델 벤치마크에는 크게 신경 쓰지 않습니다. 오늘 우리가 하는 일: 실제 회사에서는 업무가 종종 비슷한 "형태"로 진행됩니다. 유사한 입력, 유사한 요구 출력, 유사한 중간 단계가 있죠. 따라서 해당 업무를 워크플로로 전환하거나, 해당 업무를 수행하기 위한 매우 구체적인 하네스+에이전트를 작성합니다. 꿈: 하지만 실제 사용자가 있는 현실 세계는 변동성이 매우 높습니다. 따라서 작업이 들어오면 해당 작업에 특화된 도구, 지침, 성공 기준, 인텔리전스를 기반으로 에이전트 JIT가 생성되는 것이 꿈입니다. 현재 이를 효과적으로 수행하려면 사람이 직접 개입해야 하지만, 앞으로는 에이전트들이 다른 에이전트를 위해 스스로 시스템을 구축하는 모습을 더 많이 보게 될 것입니다. "에이전트 빌더" 기업들은 바로 여기에 모든 자원을 투입해야 하며, 승자는 이 부분을 가장 잘 해낼 것입니다. 이 중 일부는 아마도 블로그에 잘 들어맞을 것이지만 그것을 꺼내는 것이 도움이 됩니다. 하네스는 지금 멋지고 모두가 그것을 쉽게 구축할 수 있도록 열심히 노력하고 있으며…단순히 해당 도메인에 좋습니다.