에이전트 메모리를 이식 가능한 파일 형식으로 관리하기

실제 에이전트는 빈 컨텍스트가 아니라 관련 메모리와 함께 시작해야 하며, 복잡한 처리 파이프라인보다 이식 가능한 데이터 형식으로 관리하는 편이 적합함 Memoryfield는 짧은 Markdown 페이지와 선택적 YAML frontmatter, SQLite 벡터 인덱스로 구성되며, 각 메모리를 에이전트가 직접 산문으로 작성함 지식 그래프를 순차 탐색하는 대신 시맨틱 검색으로 관련 페이지를 찾고 병렬로 읽어, 검색과 읽기에 최대 2회의 도구 호출만 사용함 특정 하네스나 API에 접근 방식을 고정하지 않아 Bash·Markdown·SQLite 같은 익숙한 도구를 활용할 수 있으며, ZIP·로컬 파일·S3·GitHub·HTTP로 교환 가능함 관련 없는 메모리는 검색 결과에서 제외되지만 외부 메모리에는 프롬프트 인젝션 위험이 있으므로, 신뢰할 수 없는 상대와 컨텍스트를 공유하지 않고 정적 ZIP을 검토·고정해야 함 기존 에이전트 메모리의 세 가지 한계 많은 모델 벤치마크는 공정성을 위해 빈 컨텍스트 윈도우에서 시작하지만, 실제 에이전트는 가능한 한 많은 관련 정보를 가진 상태에서 시작해야 함 현재 널리 쓰이는 메모리 시스템은 대략 세 종류이며 각각 다른 한계가 있음 특정 연구소의 에이전트 하네스에 종속된 시스템은 대화 기록에서 정보를 추출하기 때문에 세계에 관한 정보보다 사용자에 관한 메모리를 주로 생성함 복잡한 시스템은 pgvector, Neo4j 그래프 데이터베이스, 기억할 내용을 판단하는 별도 LLM까지 요구할 수 있어 운영이 어렵고 모델에 혼란을 주며 발전 속도를 따라가기 힘듦 이상화된 합리적 메모리를 추구하는 시스템은 그래프나 논리 명제로 정보를 맥락에서 분리해, 에이전트와 사용자에게 의미 없는 정제된 사실 목록만 남길 수 있음 세 유형 모두 메모리를 하나의 처리 과정으로 다루지만, 모델에는 데이터로 표현하는 방식이 더 적합함 Memoryfield 파일 구조 Brooks의 표현처럼 흐름도보다 테이블을 보면 처리 과정도 명확해질 수 있다는 원칙을 메모리 설계에 적용함 Memoryfield의 표준 보관 형태는 여러 Markdown 파일과 선택적 SQLite 벡터 인덱스를 담은 ZIP 파일임 my-memories.memoryfield.zip ├── carbon-fibre-woks.md ├── finnish-bureaucracy-tips.md ├── [... many more md files...] ├── wec-20...