docs: finalize P-Reinforce wikification and cross-post topics to domain categories
This commit is contained in:
@@ -0,0 +1,44 @@
|
||||
# [[Agent Harness (에이전트 하네스)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
Agent Harness는 에이전트(LLM)가 독립적으로 동작하지 않고, 시스템 자원(파일, 네트워크, 도구)에 접근하고, 상태를 유지하며, 외부와 소통할 수 있도록 감싸는 **'실행 런타임이자 거버넌스 계층'**이다. 에이전트에게는 외부 세계와 소통하는 인터페이스를 제공하고, 시스템에게는 에이전트의 행동을 통제하고 관찰하는 보안 및 운영 경계를 제공한다. 최근에는 이를 **'Agent OS'**라고도 부른다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **6대 구성 요소 (Standard Architecture)**:
|
||||
* **[[C-component (Context Manager)]]**: 컨텍스트 조립 및 압축 관리.
|
||||
* **[[E-component (Execution Loop)]]**: 에이전트의 사고-행동 반복 루프 제어.
|
||||
* **[[L-component (Lifecycle Hooks)]]**: 이벤트 인터셉터 및 정책 강제 계층.
|
||||
* **[[S-component (State Store)]]**: 단기/장기 메모리 및 지식 지속성 관리.
|
||||
* **[[T-component (Tool Registry)]]**: 외부 도구 연결 및 실행 표준화(MCP 등).
|
||||
* **[[V-component (Evaluation Interface)]]**: 결과 검증 및 피드백 루프.
|
||||
* **시스템 자원 추상화**: 에이전트가 직접 OS API를 호출하는 대신, 하네스가 제공하는 가상화된 파일 시스템, 네트워크 게이트웨이, 도구 셋을 통해 안전하게 상호작용하도록 한다.
|
||||
* **보안 및 격리 (Sandboxing)**: 에이전트의 실행 환경을 호스트 시스템과 격리하여, 프롬프트 인젝션이나 악성 코드 실행으로 인한 피해가 확산되는 것을 방지한다.
|
||||
* **상태 보존 및 복구**: 작업 중단 시 현재의 컨텍스트와 메모리 상태를 저장하고, 나중에 동일한 지점에서 작업을 재개할 수 있는 스냅샷 기능을 제공한다.
|
||||
* **관측 가능성 (Observability)**: 에이전트의 모든 사고 과정(Thought), 도구 호출 로그, 데이터 흐름을 기록하여 디버깅과 감사가 가능하게 한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **추상화 오버헤드**: 하네스 계층이 두꺼워질수록 에이전트의 반응 속도(Latency)가 느려질 수 있다.
|
||||
* **유연성과 통제의 균형**: 하네스가 너무 엄격하면 에이전트의 창의적 문제 해결이 제한될 수 있고, 너무 느슨하면 보안 리스크가 발생한다.
|
||||
* **복잡한 동기화**: 다중 에이전트 환경에서 여러 하네스 간의 상태 일관성을 유지하는 것은 매우 어려운 공학적 과제이다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Agent OS]]
|
||||
* 연결 이유: 에이전트 하네스의 개념이 확장되어 운영체제 수준의 자원 관리를 수행하는 상위 개념이다.
|
||||
* [[MCP (Model Context Protocol)]]
|
||||
* 연결 이유: 하네스의 T-component가 외부 도구와 통신하기 위해 채택하는 표준 프로토콜이다.
|
||||
* [[Execution Environment (Sandbox)]]
|
||||
* 연결 이유: 하네스가 에이전트를 실제로 실행시키는 물리적/가상적 격리 공간이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 하네스의 각 구성 요소(C/E/L/S/T/V) 간의 의존성을 최소화하면서도 고성능 데이터 파이프라인을 구축하는 마이크로커널 아키텍처는 어떻게 설계해야 하는가?
|
||||
* 에이전트가 하네스의 제약을 인지하고 이를 우회하려 할 때(Jailbreaking), 하네스 계층에서 이를 실시간으로 탐지하는 하드웨어 수준의 감시 기법은 무엇인가?
|
||||
* 하네스가 여러 모델(Multi-model)을 동시에 지원하며, 작업별로 최적의 모델에게 서브 태스크를 할당하는 '동적 라우팅' 기능을 어떻게 최적화하는가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** Python의 LangGraph나 JS의 LangChain 등을 활용하여 기본적인 하네스 루프를 구축하고, 커스텀 미들웨어(L-component)를 추가하여 보안 정책을 적용한다.
|
||||
* **System Design:** 기업용 에이전트 플랫폼 구축 시, Docker나 WASM 기반의 샌드박스를 하네스 하단에 배치하여 에이전트의 코드 실행 권한을 엄격히 제한한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,38 @@
|
||||
# [[C-component (Context Manager)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
C-component(Context Manager)는 에이전트 하네스(Harness)의 6대 구성 요소 중 하나로, 모델의 제한된 컨텍스트 윈도우(Context Window)를 관리하고 최적화하는 책임을 진다. 사용자의 요청, 대화 이력, 외부 도구의 출력, 그리고 메모리 시스템(S-component)에서 가져온 지식을 조합하여 모델이 현재 작업을 수행하는 데 가장 적합한 '최적의 입력(Optimal Prompt)'을 구성한다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **컨텍스트 조립 (Context Assembly)**: STM, WTM, LTM 및 도구 실행 결과 등 흩어져 있는 지식 조각들을 우선순위에 따라 하나의 프롬프트로 결합한다.
|
||||
* **압축 및 요약 (Compaction & Summarization)**: 컨텍스트 크기가 모델의 한계에 도달하면, 중요도가 낮은 정보를 요약하거나 제거하여 추론 성능 저하(Context Rot)를 방지한다.
|
||||
* **우선순위 제어 (Priority Management)**: 최신 사용자 명령과 필수 제약사항이 모델의 주의력(Attention)을 가장 많이 받는 위치에 배치되도록 조정한다.
|
||||
* **윈도우 슬라이딩 (Windowing)**: 대화가 길어질 경우 고정된 크기의 윈도우를 유지하면서, 이전의 결정 사항을 요약본으로 대체하여 맥락을 유지한다.
|
||||
* **아티팩트 참조 관리 (Artifact Referencing)**: 대규모 데이터는 외부 저장소에 두고, 컨텍스트 내에는 해당 데이터의 메타데이터와 참조 ID만을 포함시켜 토큰 소모를 최소화한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **지연 시간**: 실시간으로 컨텍스트를 분석하고 재구성하는 과정에서 오버헤드가 발생한다.
|
||||
* **정보 유실**: 공격적인 압축은 모델이 세부적인 지시사항을 놓치게 만들 수 있다.
|
||||
* **일관성 문제**: 요약된 정보와 메모리 시스템의 원본 데이터 간에 불일치가 발생할 수 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Context Engineering]]
|
||||
* 연결 이유: C-component가 수행하는 전략적 활동의 총칭이다.
|
||||
* [[E-component (Execution Loop)]]
|
||||
* 연결 이유: 실행 루프가 한 번 돌 때마다 C-component가 새로운 컨텍스트를 생성하여 모델에게 전달한다.
|
||||
* [[S-component (State Store)]]
|
||||
* 연결 이유: 컨텍스트에 주입할 장기적인 상태 정보를 제공받는 소스이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 모델의 특정 레이어에서 주의력이 떨어지는 정보를 실시간으로 탐지하여 C-component가 이를 자동으로 제거하는 피드백 루프는 가능한가?
|
||||
* 다양한 모델(Claude, GPT, Gemini)의 컨텍스트 윈도우 특성에 따라 최적의 프롬프트 구조를 동적으로 생성하는 '모델 적응형 C-component'는 어떻게 설계해야 하는가?
|
||||
* 컨텍스트 내의 정보 간 충돌(Conflict)이 발생했을 때, C-component가 이를 해결하기 위해 수행해야 하는 우선순위 결정 로직은 무엇인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** 하네스 구현 시 `ContextManager` 클래스를 정의하고, `assemble()`, `compact()`, `injectEvidence()` 등의 메서드를 통해 컨텍스트를 제어한다.
|
||||
* **System Design:** 대규모 에이전트 시스템에서 C-component를 별도의 마이크로서비스로 분리하여 여러 하네스가 공유하는 '중앙 집중형 컨텍스트 최적화 서비스'를 구축할 수 있다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,41 @@
|
||||
# [[E-component (Execution Loop)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
E-component(Execution Loop)는 에이전트 하네스의 '심장'에 해당하는 구성 요소로, 에이전트가 목표를 달성할 때까지 수행하는 **관찰(Observe) - 사고(Think) - 행동(Act)** 루프를 제어하고 관리한다. 에이전트의 생명 주기를 유지하며, 언제 모델을 호출하고 언제 도구를 실행할지, 그리고 작업이 완료되었는지를 판단하는 결정론적(Deterministic) 흐름 제어 계층이다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **루프 제어 전략**:
|
||||
* **고정 반복 (Fixed Iteration)**: 사전에 정의된 횟수만큼 루프를 실행.
|
||||
* **조건 기반 종료 (Condition-based)**: 모델이 "완료" 신호를 보내거나, 특정 결과값에 도달했을 때 종료.
|
||||
* **자기 반성 (Self-Correction)**: 루프 내부에서 이전 행동의 결과를 평가하고 다음 행동을 수정하는 단계(Reflexion)를 포함.
|
||||
* **상태 전이 관리 (State Transition)**: 루프의 각 단계에서 에이전트의 내부 상태가 어떻게 변하는지 추적하며, 오류 발생 시 이전 상태로 복구(Rollback)하거나 재시도(Retry)하는 로직을 수행한다.
|
||||
* **비동기 작업 관리**: 장시간 실행되는 도구나 외부 API 호출 시 루프가 멈추지 않도록 비동기 스트리밍과 이벤트 대기 메커니즘을 관리한다.
|
||||
* **휴먼-인-더-루프 (HITL) 개입**: 루프의 특정 지점에서 인간의 승인을 기다리거나 피드백을 받아 작업 방향을 수정하는 중단점(Breakpoints)을 제어한다.
|
||||
* **토큰 및 비용 가드레일**: 무한 루프에 빠져 토큰을 과도하게 소모하는 것을 방지하기 위해 최대 실행 시간이나 비용 한도를 강제한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **루프 깊이와 정확도**: 루프를 많이 돌수록 결과의 품질은 향상될 수 있으나(Test-time scaling), 지연 시간과 비용이 비례해서 증가한다.
|
||||
* **무한 루프 리스크**: 모델이 동일한 잘못된 행동을 반복하며 루프를 탈출하지 못하는 '논리적 데드락'에 빠질 수 있다.
|
||||
* **상태 폭발**: 루프가 길어질수록 컨텍스트에 쌓이는 데이터가 많아져 모델의 성능이 저하(Context Rot)될 수 있다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Agent Harness]]
|
||||
* 연결 이유: E-component는 하네스의 실행 주체이다.
|
||||
* [[C-component (Context Manager)]]
|
||||
* 연결 이유: 루프가 한 번 돌 때마다 C-component가 갱신된 컨텍스트를 공급해야 한다.
|
||||
* [[Self-verification]]
|
||||
* 연결 이유: E-component 내에서 결과의 신뢰성을 검증하는 핵심 기법이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 에이전트가 작업의 '난이도'를 스스로 평가하여 루프의 복잡도를 동적으로 조절하는 스케줄링 알고리즘은 무엇인가?
|
||||
* 다중 에이전트 협업 시, 여러 에이전트의 개별 실행 루프를 하나의 상위 루프(Orchestration Loop)로 통합하는 효율적인 방법은 무엇인가?
|
||||
* 루프 실행 중 발생하는 중간 산출물(Intermediate thoughts) 중 어떤 정보가 최종 결과 도달에 결정적이었는지를 분석하여 향후 루프를 최적화하는 기법은 무엇인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** `while` 루프 내에서 `agent.think()`와 `agent.act()`를 호출하고, 각 단계의 결과를 `AgentHistory`에 기록하는 구조로 구현한다.
|
||||
* **System Design:** 웹 서비스 환경에서 에이전트 실행 루프를 백그라운드 작업(Celery, Redis 등)으로 처리하여 사용자의 연결이 끊겨도 작업이 완료되도록 설계한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,42 @@
|
||||
# [[L-component (Lifecycle Hooks)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
L-component(Lifecycle Hooks)는 에이전트 하네스의 '감시 및 제어' 계층으로, 에이전트의 사고, 도구 실행, 상태 저장 등 모든 주요 이벤트 사이사이에 개입(Intercept)하여 정책을 강제하고 데이터를 정제하는 미들웨어(Middleware) 역할을 한다. 에이전트의 자율성을 보장하면서도 시스템의 안정성과 보안 가드레일을 유지하는 핵심 장치이다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **이벤트 인터셉션 (Interception)**:
|
||||
* **Pre-Inference**: 모델 호출 전 프롬프트를 검사하여 민감 정보 유출을 차단하거나 필수 지침을 주입.
|
||||
* **Post-Inference**: 모델의 답변을 파싱하고 실행 가능한 형식인지 검증.
|
||||
* **Pre-Tool Execution**: 도구 실행 전 권한(Permission)을 확인하고 사용자의 승인을 요청.
|
||||
* **Post-Tool Execution**: 도구 출력값을 필터링하거나 압축하여 컨텍스트 오염 방지.
|
||||
* **정책 강제 (Policy Enforcement)**: 에이전트가 접근 가능한 자원 범위, 최대 비용, 금지어 목록 등을 런타임에 체크하여 위반 시 실행을 중단(Kill-switch)하거나 경고를 보낸다.
|
||||
* **데이터 정제 및 변환**: 도구의 대량 로그를 요약하거나, 특정 형식의 결과물을 시스템이 이해할 수 있는 아티팩트로 변환한다.
|
||||
* **로깅 및 감사 (Audit)**: 모든 이벤트의 시점과 내용을 기록하여 에이전트의 행동을 사후에 분석하고 책임 소재를 명확히 한다.
|
||||
* **동적 가드레일 (Guardrails)**: 작업의 위험도에 따라 실시간으로 감시 수준을 조절하거나, 인간의 개입(Human-in-the-loop)을 트리거한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **성능 저하**: 너무 많은 훅(Hook)이 활성화되면 에이전트의 전체 반응 속도가 눈에 띄게 느려진다.
|
||||
* **지능 간섭**: 가드레일이 너무 엄격하거나 잘못 설계되면 모델의 추론 능력을 방해하여 작업 성공률이 떨어질 수 있다.
|
||||
* **복잡성 증가**: 수많은 정책과 미들웨어 간의 우선순위 및 충돌을 관리하는 로직이 복잡해진다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Agent Harness]]
|
||||
* 연결 이유: L-component는 하네스의 정책 시행 계층이다.
|
||||
* [[Excessive Agency]]
|
||||
* 연결 이유: 에이전트의 과도한 권한 남용을 막는 실질적인 방어 수단이 L-component이다.
|
||||
* [[Safety & Reliability]]
|
||||
* 연결 이유: 시스템의 신뢰성을 보장하기 위한 기술적 구현체이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 모델의 의도를 분석하여 '잠재적 위험'을 사전에 예측하고 훅을 실행하는 지능형 미들웨어는 어떻게 구현하는가?
|
||||
* 다중 에이전트 시스템에서 에이전트 간 메시지를 가로채어 권한 에스컬레이션(Privilege Escalation)을 방지하는 상호 감시 로직은 무엇인가?
|
||||
* 가드레일을 프롬프트에 포함하는 방식(Soft guardrail)과 하네스 코드에서 강제하는 방식(Hard guardrail)의 보안 효율성 차이는 어느 정도인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** Express.js의 미들웨어나 Python의 데코레이터 패턴을 활용하여 각 실행 단계 전후에 훅 함수를 등록하고 실행한다.
|
||||
* **System Design:** 보안이 중요한 금융이나 의료 도메인 에이전트 구축 시, 모든 외부 API 호출에 대해 L-component에서 엄격한 스키마 검증과 데이터 마스킹을 수행한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,41 @@
|
||||
# [[S-component (State Store)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
S-component(State Store)는 에이전트 하네스의 '기억'을 담당하는 물리적/논리적 저장소 계층이다. 에이전트의 현재 작업 상태, 과거 대화 이력, 추출된 지식, 그리고 영구적으로 보존해야 할 사용자 선호도를 저장하고 관리한다. 단순한 데이터베이스를 넘어, 에이전트가 시간이 지남에 따라 학습하고 진화할 수 있는 토대를 제공한다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **다층 저장 구조**:
|
||||
* **단기 상태 (Short-term)**: 현재 세션의 휘발성 데이터 및 즉각적인 작업 맥락 보존.
|
||||
* **영구 상태 (Long-term)**: 세션을 넘어 지속되는 사용자 프로필, 프로젝트 규칙, 자가 학습된 지식 저장.
|
||||
* **체크포인트 (Checkpoints)**: 작업 중 특정 시점의 전체 상태를 스냅샷으로 저장하여 실패 시 복구 가능하게 함.
|
||||
* **지식 인덱싱 (RAG Integration)**: 대규모 텍스트나 데이터를 벡터 임베딩하여 에이전트가 필요할 때 의미 기반 검색(Semantic Search)을 통해 정보를 불러올 수 있도록 지원한다.
|
||||
* **데이터 직렬화 및 동기화**: 메모리 내의 복잡한 에이전트 상태 객체를 영구 저장소(JSON, SQL, Vector DB 등)에 효율적으로 저장하고, 여러 장치나 세션 간에 동기화한다.
|
||||
* **메모리 거버넌스**: 정보의 유효 기간(TTL)을 설정하여 오래된 정보를 자동으로 삭제하거나, 중요도가 낮은 데이터를 요약하여 저장 공간을 최적화(Compaction)한다.
|
||||
* **보안 및 암호화**: 저장된 메모리에 포함된 민감한 사용자 데이터나 시스템 비밀번호 등을 암호화하여 외부 유출을 방지한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **검색 정확도 vs 속도**: 저장된 데이터가 방대해질수록 관련 정보를 찾는 데 더 많은 시간과 컴퓨팅 자원이 소모된다.
|
||||
* **데이터 오염 (Memory Poisoning)**: 잘못된 정보가 S-component에 기록되면 이후 에이전트의 모든 판단에 악영향을 미치는 '영구적 지능 저하'가 발생할 수 있다.
|
||||
* **개인정보 보호**: 에이전트가 사용자의 모든 행동을 기억하게 될 때 발생하는 프라이버시 침해 리스크를 관리해야 한다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Agent Memory System]]
|
||||
* 연결 이유: S-component가 실질적으로 구현하는 논리적 시스템이다.
|
||||
* [[Inference-Coupled Persistence]]
|
||||
* 연결 이유: 추론을 통해 S-component에 지식을 공급하는 기술적 방법이다.
|
||||
* [[C-component (Context Manager)]]
|
||||
* 연결 이유: S-component에서 저장된 정보를 꺼내어 실제 모델 입력으로 변환하는 파트너이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 에이전트가 '잊어야 할 정보'를 스스로 판단하여 폐기하는 '능동적 망각 알고리즘'은 어떻게 설계해야 하는가?
|
||||
* 수백만 개의 에피소드 기억 중 현재 작업의 '인과 관계'를 가장 잘 설명하는 과거 사례를 순위화(Ranking)하는 최적의 모델은 무엇인가?
|
||||
* 분산 환경에서 여러 에이전트 하네스가 하나의 거대한 S-component를 공유할 때 발생하는 쓰기 충돌과 데이터 일관성 문제를 어떻게 해결하는가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** SQLite나 PostgreSQL(pgvector)을 사용하여 로컬 및 서버 사이드 상태 저장소를 구축하고, 에이전트의 `MemoryState` 클래스와 연동한다.
|
||||
* **System Design:** 멀티 테넌트(Multi-tenant) 에이전트 서비스 구축 시, 사용자별로 S-component를 물리적으로 분리하여 데이터 유출 리스크를 원천 차단한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,38 @@
|
||||
# [[T-component (Tool Registry)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
T-component(Tool Registry)는 에이전트 하네스의 '손과 발'에 해당하는 구성 요소로, 에이전트가 외부 세계와 상호작용하기 위해 사용할 수 있는 모든 도구(함수, API, 스크립트)를 등록, 관리, 실행하는 책임을 진다. 모델이 도구의 기능을 이해할 수 있도록 명세를 제공하고, 모델의 실행 요청을 실제 코드 호출로 변환하는 가교 역할을 한다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **도구 명세 관리 (Tool Definitions)**: 모델이 어떤 상황에서 어떤 도구를 써야 할지 알 수 있도록 도구의 이름, 설명, 파라미터 스키마를 정의하고 공급한다.
|
||||
* **실행 프로토콜 표준화 (MCP)**: 서로 다른 언어나 환경으로 작성된 도구들을 일관된 방식으로 호출하기 위해 **MCP(Model Context Protocol)**와 같은 표준 프로토콜을 사용한다.
|
||||
* **권한 및 가이딩 (Guarding)**: 특정 에이전트나 작업 세션이 사용할 수 있는 도구의 범위를 제한하고, 민감한 도구 호출 시 승인 게이트를 트리거한다.
|
||||
* **결과 파싱 및 피드백**: 도구 실행 결과(성공 데이터, 에러 로그)를 모델이 이해할 수 있는 형식으로 정제하여 전달한다.
|
||||
* **동적 로딩 및 확장성**: 하네스 코드를 수정하지 않고도 새로운 도구 서버를 추가하거나 외부 API를 연동할 수 있는 플러그인 아키텍처를 제공한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **스키마 복잡성**: 도구 명세가 너무 복잡하면 모델이 파라미터를 잘못 생성할 확률이 높아진다.
|
||||
* **보안 리스크 (Excessive Agency)**: 도구 레지스트리에 강력한 권한을 가진 도구(예: 셸 실행)가 포함되어 있을 경우, 프롬프트 인젝션을 통한 시스템 장악 위험이 있다.
|
||||
* **의존성 지옥**: 수많은 외부 API와 라이브러리에 의존하는 도구들의 버전 관리와 안정성을 유지하는 것은 어려운 운영 과제이다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[MCP (Model Context Protocol)]]
|
||||
* 연결 이유: T-component가 도구를 등록하고 실행하는 실질적인 기술 표준이다.
|
||||
* [[Agent Harness]]
|
||||
* 연결 이유: T-component는 하네스의 외부 세계 인터페이스이다.
|
||||
* [[L-component (Lifecycle Hooks)]]
|
||||
* 연결 이유: 도구 실행 전후에 권한을 검사하고 결과를 필터링하는 파트너이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* 모델이 도구의 기능을 더 정확히 이해하게 만들기 위해, 단순한 텍스트 설명 대신 '실행 예시'나 '단위 테스트 결과'를 명세에 포함하는 방식의 효율성은 어떠한가?
|
||||
* 수백 개의 도구 중 현재 상황에 가장 적합한 도구 5개만을 골라 모델에게 제안하는 '도구 검색(Tool Retrieval)' 알고리즘은 어떻게 설계해야 하는가?
|
||||
* 도구 실행 결과가 너무 클 때(예: 대규모 DB 조회), 이를 컨텍스트에 주입하지 않고 아티팩트로 처리하는 최적의 임계점은 무엇인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** `ToolRegistry` 클래스에 `register_tool()`, `call_tool()` 메서드를 구현하고, 각 도구는 JSON Schema를 통해 파라미터를 정의한다.
|
||||
* **System Design:** 보안을 위해 도구 실행부를 별도의 격리된 컨테이너(Sandbox)에서 동작하게 하고, T-component는 네트워크를 통해 결과만 전달받도록 설계한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
@@ -0,0 +1,38 @@
|
||||
# [[V-component (Evaluation Interface)]]
|
||||
|
||||
## 📌 Brief Summary
|
||||
V-component(Evaluation Interface)는 에이전트 하네스의 '눈'에 해당하는 구성 요소로, 에이전트의 출력물이나 도구 실행 결과를 객관적으로 평가하고 피드백을 생성하는 책임을 진다. 작업이 성공적으로 완료되었는지, 결과물이 제약 사항을 준수했는지, 혹은 오류가 발생했는지를 판단하여 실행 루프(E-component)에 다음 행동을 결정할 근거를 제공한다.
|
||||
|
||||
## 📖 Core Content
|
||||
* **결과 검증 (Output Verification)**: 모델이 생성한 코드, 문서, 데이터 형식이 사전에 정의된 스펙(Schema, Linter, Test Case)에 부합하는지 자동 검사한다.
|
||||
* **자기 비판 (Self-Correction Feedback)**: 검증 실패 시 단순히 "에러 발생"이라고 알리는 대신, 무엇이 틀렸고 어떻게 고쳐야 하는지에 대한 구체적인 피드백 프롬프트를 생성하여 에이전트에게 전달한다.
|
||||
* **벤치마킹 및 채점 (Scoring)**: 작업의 품질을 정량화된 점수로 환산하여, 여러 번의 시도 중 가장 우수한 결과물을 선택하거나 에이전트의 성능 추이를 모니터링한다.
|
||||
* **환각 탐지 (Hallucination Detection)**: 에이전트의 답변이 실제 근거(Evidence Memory)와 일치하는지, 혹은 논리적 모순이 없는지 검토한다.
|
||||
* **인간 피드백 통합 (HITL Evaluation)**: 자동화된 평가가 어려운 경우 인간 사용자의 승인이나 점수를 입력받아 평가 프로세스에 반영한다.
|
||||
|
||||
## ⚖️ Trade-offs & Caveats
|
||||
* **평가자 모델의 한계**: 평가를 위해 또 다른 LLM을 사용할 경우, 평가자 자체가 환각을 일으키거나 편향된 판단을 내릴 리스크가 있다.
|
||||
* **검증 오버헤드**: 모든 단계에서 엄격한 검증을 수행하면 전체 작업 시간이 길어지고 비용이 증가한다.
|
||||
* **평가 기준의 모호성**: 주관적인 디자인이나 문구 작성 등의 작업에 대해서는 객관적인 평가 지표를 설정하기 어렵다.
|
||||
|
||||
## 🔗 Knowledge Connections
|
||||
|
||||
### Related Concepts
|
||||
* [[Agent Harness]]
|
||||
* 연결 이유: V-component는 하네스의 품질 보증 계층이다.
|
||||
* [[Self-verification]]
|
||||
* 연결 이유: V-component가 수행하는 핵심 활동 중 하나이다.
|
||||
* [[Agent Evaluation Benchmarks]]
|
||||
* 연결 이유: V-component가 사용하는 표준화된 평가 기준과 도구 모음이다.
|
||||
|
||||
### Deeper Research Questions
|
||||
* '평가자의 평가자(Meta-evaluator)'를 두어 평가 시스템 자체의 신뢰성을 지속적으로 모니터링하는 아키텍처는 어떻게 설계해야 하는가?
|
||||
* 실패한 작업의 원인을 분석하여 V-component가 자동으로 '성공 가이드라인'을 생성하고 다음 루프에 반영하게 만드는 방법은 무엇인가?
|
||||
* 정적 분석(Linter)과 동적 추론(LLM)을 결합하여 최소한의 비용으로 최대의 검증 효과를 내는 '하이브리드 평가 전략'은 무엇인가?
|
||||
|
||||
### Practical Application Contexts
|
||||
* **Implementation:** 코딩 에이전트에서 작성된 코드를 테스트 코드를 통해 실행해보고, 실패 시 스택 트레이스를 V-component에 입력하여 수정 전략을 세우게 한다.
|
||||
* **System Design:** 프로덕션 환경에서 에이전트의 답변을 실시간으로 채점하여, 일정 점수 미만의 답변은 사용자에게 보여주지 않고 즉시 재시도(Retry)하도록 설계한다.
|
||||
|
||||
---
|
||||
*Last updated: 2026-05-01*
|
||||
Reference in New Issue
Block a user