에이전트 메모리는 파이프라인이 아니라 파일 형식이어야 한다

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