개발자들이 Cloudflare에서 점점 더 정교한 에이전트 를 구축하면서 직면하고 있는 가장 큰 과제 중 하나는 적시에 적절한 정보를 컨텍스트에 적용하는 것입니다. 모델에서 생성되는 결과의 품질은 모델이 작업을 수행하는 데 사용하는 컨텍스트의 품질과 직접적인 관련이 있지만, 컨텍스트 창 크기가 100만(1M) 토큰을 넘어 증가하더라도 컨텍스트 손상 은 해결되지 않은 문제로 남아 있습니다. 컨텍스트에 맞게 모든 항목을 유지하면서 품질 저하를 지켜보는 것과, 공격적으로 가지치기를 하면 나중에 에이전트가 필요로 하는 정보가 손실될 위험이 있는 것 사이에 두 가지 나쁜 옵션 사이에 자연스러운 긴장이 생깁니다.
오늘 저희는 에이전트 대화에서 정보를 추출하여 컨텍스트 창을 채우지 않고도 필요할 때 사용할 수 있도록 하는 관리형 서비스인 Agent Memory 비공개 베타를 발표합니다.
이는 AI 에이전트에게 지속적인 메모리를 제공하여 중요한 것을 기억하고, 불필요한 것을 잊어버리며, 시간이 지남에 따라 더 똑똑해질 수 있도록 합니다. 이번 게시물에서는 이 기능의 작동 방식과 구축에 어떤 도움이 될 수 있는지 설명하겠습니다.
에이전트형 메모리는 AI 인프라에서 가장 빠르게 변화하는 공간 중 하나로, 새로운 오픈 소스 라이브러리, 관리형 서비스, 연구 프로토타입이 거의 매주 출시됩니다. 이러한 제품은 저장하는 대상, 검색 방법, 설계된 에이전트의 종류가 매우 다양합니다. LongMemEval, LoCoMo, BEAM 과 같은 벤치마크는 공정한 비교에 유용하지만, 특정 평가에 과적합 되어 프로덕션 환경에서 제대로 작동하지 않는 시스템을 쉽게 구축하게 만들기도 합니다.
또한 기존 제품은 아키텍처가 다릅니다. 일부는 백그라운드에서 추출 및 검색을 처리하는 관리형 서비스이고, 다른 일부는 메모리 파이프라인을 직접 실행하는 자체 호스팅 프레임워크입니다. 일부는 에이전트의 기본 컨텍스트에서 메모리 로직을 분리하는 목적에 맞게 구축된 APIs를 제한적으로 노출합니다. 다른 모델은 모델에 데이터베이스나 파일 시스템에 대한 원시 액세스 권한을 부여하고 스스로 쿼리를 설계하도록 하여 실제 작업 대신 저장소와 검색 전략에 토큰을 소진합니다. 일부는 필요한 경우 여러 에이전트로 분할하여 모든 것을 컨텍스트 창에 맞추고자 하는 반면, 다른 일부는 검색을 사용하여 관련성 있는 내용만 표시하려고 합니다.
에이전트 메모리는 독단적인 API 및 검색 기반 아키텍처를 갖춘 관리형 서비스입니다. Cloudflare는 여러 대안을 신중하게 고려했으며, 이 조합이 대부분의 프로덕션 워크로드에 적합한 기본값이라고 생각합니다. 에이전트에게 원시 파일 시스템 액세스 권한을 제공하는 것보다 더 엄격한 수집 및 검색 파이프라인이 더 우수합니다. 이러한 도구는 비용과 성능이 개선되었을 뿐만 아니라 시간 논리, 대체, 명령 따르기 등 프로덕션에 필요한 복잡한 추론 작업을 위한 더 나은 기반을 제공합니다. 향후 프로그래밍 방식 쿼리를 위한 데이터가 노출될 가능성이 높지만, 이는 일반적인 경우가 아니라 에지 사례에 유용할 것으로 예상합니다.
저희가 에이전트 메모리를 구축한 이유는 저희 플랫폼에서 확인되는 워크로드가 기존 접근 방식으로 완전히 해결하지 못하는 격차가 노출되기 때문입니다. 실제 코드베이스와 프로덕션 시스템에 대해 몇 주 또는 몇 달에 걸쳐 실행되는 에이전트는 새로운 모델의 컨텍스트 윈도우에 완전히 맞을 수 있는 클린 벤치마크 데이터 세트에서 잘 작동하는 메모리가 아니라, 성장함에 따라 유용하게 유지되는 메모리가 필요합니다.
빠른 수집이 필요합니다. 대화를 방해하지 않으면서 검색을 해야 합니다. 또한 쿼리당 비용을 합리적으로 유지하는 모델에서 실행되어야 합니다.
에이전트 메모리는 이름으로 주소가 지정된 프로필에 메모리를 저장합니다. 프로필을 사용하면 대화 가져오기, 특정 사항 기억, 필요한 항목 호출, 기억 나열, 특정 메모리 삭제 등의 여러 작업이 수행될 수 있습니다. Ingest은 일반적으로 하네스가 컨텍스트를 압축할 때 호출되는 대량 경로입니다. Remember는 모델이 중요한 정보를 즉시 저장하기 위한 것입니다. Recall은 전체 검색 파이프라인을 실행하고 종합된 답변을 반환합니다.
export default {
async fetch(request: Request, env: Env): Promise<Response> {
// Get a profile -- an isolated memory store shared across sessions, agents, and users
const profile = await env.MEMORY.getProfile("my-project");
// Ingest -- extract memories from a conversation (typically called at compaction)
await profile.ingest([
{ role: "user", content: "Set up the project with React and TypeScript." },
{ role: "assistant", content: "Done. Scaffolded a React + TS project targeting Workers." },
{ role: "user", content: "Use pnpm, not npm. And dark mode by default." },
{ role: "assistant", content: "Got it -- pnpm and dark mode as default." },
], { sessionId: "session-001" });
// Remember -- store a single memory explicitly (direct tool use by the model)
const memory = await profile.remember({
content: "API rate limit was increased to 10,000 req/s per zone after the April 10 incident.",
sessionId: "session-001",
});
// Recall -- retrieve memories and get a synthesized answer
const results = await profile.recall("What package manager does the user prefer?");
console.log(results.result); // "The user prefers pnpm over npm."
return Response.json({ ok: true });
},
};
에이전트 메모리는 Cloudflare Worker에서 바인딩을 통해 액세스됩니다. 다른 Cloudflare 개발자 플랫폼 API와 동일한 패턴을 따라 Workers 외부에서 실행되는 에이전트의 경우 REST API를 통해 액세스할 수도 있습니다. Cloudflare Agents SDK로 구축하는 경우, 에이전트 메모리 서비스가 세션 API의 메모리 부분 에서 압축, 기억, 검색을 처리하기 위한 참조 구현으로 깔끔하게 통합됩니다.
에이전트 메모리는 다양한 에이전트 아키텍처에서 작동하도록 설계되었습니다.
개별 에이전트를 위한 메모리. Claude Code나 OpenCode와 같은 코딩 에이전트로 구축하고 인간과 함께 루프에 참여하든, OpenClaw 또는 Hermes와 같은 자체 호스팅 에이전트 프레임워크를 사용하여 귀사를 대신하여 행동하든, Anthropic의 관리형 에이전트와 같은 관리형 서비스를 연결하든, Agent Memory는 에이전트의 코어 루프를 변경하지 않고도 영구 메모리 계층 역할을 할 수 있습니다.
사용자 지정 에이전트 하니스용 메모리. 많은 팀에서는 루프에 사람 없이 자율적으로 실행되는 백그라운드 에이전트를 포함하여 자체 에이전트 인프라를 구축하고 있습니다. Ramp 검사는 공개된 한 가지 예입니다. Stripe 와 Spotify 도 비슷한 시스템을 소개하고 있습니다. 이러한 하네스는 에이전트에게 세션 전반에 걸쳐 지속되고 재시작 시에도 지속되는 메모리를 제공할 수 있어 이점을 누릴 수 있습니다.
에이전트, 사람, 도구 간에 메모리를 공유합니다. 메모리 프로필은 단일 에이전트에 속할 필요가 없습니다. 엔지니어 팀에서는 메모리 프로필을 공유하여 코딩 규칙, 아키텍처 관련 결정, 현재 사람들이 머리 속에 저장하고 있거나 컨텍스트를 프루닝하면 잃어버리는 지식 등 한 사람의 코딩 에이전트가 학습한 지식을 모든 사람이 사용할 수 있도록 할 수 있습니다. 코드 검토 봇과 코딩 에이전트는 메모리를 공유하여 리뷰 피드백으로 향후 코드 생성을 형성합니다. 에이전트가 축적한 지식은 마비되지 않으며 지속적인 팀 자산이 됩니다.
검색은 메모리의 구성 요소인 반면, 에이전트 검색과 에이전트 메모리는 서로 다른 문제를 해결합니다. AI Search 는 비정형 및 정형 파일에서 결과를 찾기 위한 저희의 기본 요소입니다. 에이전트 메모리는 컨텍스트 회수를 위한 것입니다. 에이전트 메모리에 있는 데이터는 파일로 존재하지 않습니다. 이는 세션에서 파생됩니다. 에이전트는 두 가지를 모두 사용할 수 있으며, 함께 작동하도록 설계되었습니다.
에이전트의 역량이 더욱 강화되고 비즈니스 프로세스에 더 깊이 내장됨에 따라 에이전트에 축적되는 메모리는 단순히 작동 상태가 아니라 실제적인 노력이 필요한 제도적 지식으로서 진정으로 가치가 있게 됩니다. Cloudflare는 고객으로부터 해당 자산을 단일 벤더와 연결하는 것이 의미하는 바에 대해 우려를 표하고 있으며 이는 합리적인 수준입니다. 에이전트가 학습하는 것이 많을수록 해당 메모리가 함께 이동할 수 없는 경우 전환 비용이 높아집니다.
에이전트 메모리는 관리형 서비스이지만, 귀사의 데이터는 곧 귀사의 것입니다. 모든 메모리는 내보낼 수 있으며, 우리는 최선을 다해 에이전트의 Cloudflare에서 축적된 정보를 여러분의 요구 사항이 바뀌는 경우에도 사용할 수 있습니다. 장기적인 신뢰를 얻는 올바른 방법은 퇴사를 쉽게 만들고 원하지 않는 것을 계속 충분히 만드는 것이라고 우리는 생각합니다.
위에 표시된 API 뒤에서 어떤 일이 발생하는지 이해하려면 에이전트가 컨텍스트를 관리하는 방법을 분석하는 것이 도움이 됩니다. 에이전트에는 세 가지 구성 요소가 있습니다.
모델에 대한 반복적인 호출을 유도하고, 도구 호출을 촉진하며, 상태를 관리하는 하네스 입니다.
컨텍스트를 가져오고 완성을 반환하는 모델.
상태 현재 컨텍스트 창과 대화 기록, 파일, 데이터베이스, 메모리 등 컨텍스트 외부의 추가 정보를 모두 포함하는
에이전트의 컨텍스트 수명 주기에서 중요한 순간은 압축 입니다. 이 시점은 하네스가 모델의 한계 내를 유지하거나 컨텍스트가 부패하는 것을 피하기 위해 컨텍스트를 단축하기로 결정합니다. 오늘날 대부분의 요원은 정보를 영구적으로 폐기합니다. 에이전트 메모리는 압축에 관한 정보를 잃지 않고 유지합니다.
에이전트 메모리는 다음과 같은 두 가지 방식으로 이 수명 주기에 통합됩니다.
압축 시 대량 수집. 하네스가 컨텍스트를 압축하면 수집을 위해 대화를 에이전트 메모리로 전송합니다. 수집은 메시지 기록에서 사실, 이벤트, 지침, 작업을 추출하고 기존 메모리와 비교하여 중복을 제거하고, 향후 검색을 위해 메모리로 저장합니다.
모델의 직접적인 도구 사용. 이 모델은 회상(특정 정보를 위해 메모리에서 검색)하는 기능을 포함하여 메모리와 직접 상호 작용할 수 있는 도구를 제공합니다. 이 모델은 또한 기억(중요한 것을 기반으로 명시적으로 메모리를 저장)하고, 잊어버리거나(더 이상 중요하지 않거나 사실이 아닌 메모리를 표시), 나열(저장된 메모리 확인)할 수 있습니다. 이는 가벼운 작업이므로 모델에 쿼리를 설계하거나 스토리지를 관리할 필요가 없습니다. 기본 에이전트는 절대 스토리지 전략에 대한 컨텍스트를 소모해서는 안 됩니다. 도구에 표시되는 표면은 의도적으로 제한되어 있으므로 메모리가 실제 작업에 방해가 되지 않습니다.
수집할 대화가 도착하면 메모리를 추출, 확인, 분류, 저장하는 다단계 파이프라인을 거칩니다.
첫 번째 단계는 결정론적 ID 생성입니다. 각 메시지는 콘텐츠 주소가 지정된 ID(세션 ID, 역할, 콘텐츠의 SHA-256 해시)를 가지며 128비트로 잘립니다. 동일한 대화가 두 번 수집되면 모든 메시지가 동일한 ID로 확인되므로 재 수집 멱등이 생깁니다.
다음으로, 추출기는 두 개의 경로를 동시에 실행합니다. 전체 경로는 두 개의 메시지가 겹치는 약 10,000자의 메시지를 분할하고 최대 4개의 청크를 동시에 처리합니다. 각 청크는 역할 라벨, 절대값으로 확인된 상대 날짜('어제'는 '2026-04-14'가 됨), 출처 출처에 대한 줄 인덱스가 포함된 구조화된 전사를 가져옵니다. 더 긴 대화(9개 이상의 메시지)의 경우 세부 정보 단계가 전체 단계와 함께 실행되며, 광범위한 추출에서는 놓치기 쉬운 이름, 가격, 버전 번호, 엔터티 속성 등의 구체적인 값을 추출하는 데 특히 중점을 두는 중복 창을 사용합니다. 그런 다음 두 결과 집합이 병합됩니다.
다음 단계는 추출된 각 메모리를 소스 스크립트와 비교하는 것입니다. 검증자는 엔터티 ID, 개체 ID, 위치 컨텍스트, 시간 정확도, 조직적 컨텍스트, 완전성, 관계 컨텍스트, 추론한 사실이 대화에서 실제로 뒷받침되는지 여부에 대해 8가지 검사를 실행합니다. 각 항목은 그에 따라 통과되거나 수정되거나 삭제됩니다.
그런 다음 파이프라인은 검증된 각 메모리를 네 가지 유형 중 하나로 분류합니다.
Facts는 "이 프로젝트에서는 GraphQL을 사용합니다" 또는 "사용자가 다크 모드를 선호한다"와 같이 지금 당장 사실인 것, 원자적이고 안정적인 지식을 나타냅니다.
이벤트는 배포나 의사 결정 등 특정 시간에 발생한 일을 포착합니다.
지침은 절차, 워크플로우, 런북 등 작업 방법을 설명합니다.
작업은 현재 진행 중인 작업을 추적하며 설계상 일시적입니다.
사실과 지침이 핵심입니다. 각각 정규화된 토픽 키를 가져오며, 새 메모리에 기존 메모리와 동일한 키가 있으면 기존 메모리가 삭제되지 않고 대체됩니다. 이렇게 하면 이전 메모리에서 새 메모리로의 포워드 포인터가 있는 버전 체인이 생성됩니다. 벡터 인덱스를 간소화하기 위해 벡터 인덱스에서 작업이 완전히 제외되었지만, 전체 텍스트 검색을 통해 여전히 작업을 찾을 수 있습니다.
마지막으로, 모든 내용이 INSERT OR IGNORE를 사용해 스토리지에 기록되므로 콘텐츠 주소가 지정된 복제본은 자동으로 건너뛸 수 있습니다. 장치에 응답이 반환되면 백그라운드 벡터화가 비동기적으로 실행됩니다. 임베딩 텍스트는 분류 중에 생성된 3~5개의 검색 쿼리를 메모리 콘텐츠 자체 앞에 추가하여 메모리가 기록되는 방법(선호적으로 "사용자가 다크 모드를 선호합니다")과 검색하는 방법( 의문스럽게 "테마가 무엇을 의미하는지 원하는가?")를 생성합니다. 대체된 메모리의 벡터는 새로운 삽입과 함께 삭제됩니다.
에이전트가 메모리를 검색할 때 쿼리는 별도의 검색 파이프라인을 거칩니다. 하나의 검색 방법이 모든 쿼리에 가장 적합한 방법은 없다는 사실을 개발 과정에서 발견하여, 여러 메서드를 동시에 실행하고 결과를 통합합니다.
첫 번째 단계에서는 쿼리 분석 및 임베딩을 동시에 실행합니다. 쿼리 분석기는 순위가 매겨진 주제 키, 동의어가 포함된 전체 텍스트 검색어, 해당 질문에 대한 답변인 것처럼 구성된 선언문인 HyDE(가상 문서 임베딩)를 생성합니다. 이 단계에서는 원시 쿼리를 직접 임베딩하며 두 임베딩 모두 다운스트림에서 사용됩니다.
다음 단계에서는 다섯 개의 검색 채널이 병렬로 작동합니다. 포터 형태소 분석을 사용한 전체 텍스트 검색은 정확한 용어는 알고 있지만 주변 컨텍스트는 잘 모르는 쿼리에 대해 키워드 정밀도를 처리합니다. 정확한 팩트키 조회는 쿼리가 알려진 주제 키에 직접 매핑되는 결과를 반환합니다. 원시 메시지 검색은 전체 텍스트 검색을 통해 저장된 대화 메시지를 직접 쿼리하여 분류되지 않은 대화 조각을 찾아 안전망 역할을 하여 추출 파이프라인이 일반화했을 수 있는 글자 그대로의 세부 정보를 포착합니다. 직접 벡터 검색은 임베디드 쿼리를 사용하여 시맨틱 면에서 유사한 메모리를 찾습니다. 또한 HyDE 벡터 검색은 답변이 어떻게 보이는지 유사한 메모리를 찾아주며, 특히 질문과 답변이 다른 어휘를 사용하는 추상 또는 멀티홉 쿼리의 경우 직접 임베딩에서 놓치는 결과를 드러내는 경우가 많습니다.
세 번째이자 마지막 단계에서는 5개 검색 채널 모두의 결과가 지정된 채널 내에서 순위가 지정된 위치에 따라 각 결과에 가중치가 부여되는 상호 순위 통합(RRF)을 사용하여 병합됩니다. 주제와 정확히 일치한다는 신호가 가장 강력하므로 사실과 핵심적인 일치 여부가 가장 높은 비중을 차지합니다. 전체 텍스트 검색, HyDE 벡터, 직접 벡터는 각각 신호의 강도에 따라 가중치가 부여됩니다. 마지막으로, 추출 파이프라인이 놓쳤을 수 있는 후보 결과를 식별하기 위해 안전망으로 원시 메시지 일치도 가볍게 포함되어 있습니다. 동점은 최신 순으로 정렬되며 최신 결과의 순위가 더 높습니다.
그런 다음 파이프라인은 상위 후보를 합성 모델로 전달하여, 원본 검색 쿼리에 대한 자연어 답변을 생성합니다. 일부 특정 쿼리 유형은 특별 취급을 받습니다. 예를 들어, 시간 계산은 LLM이 아닌 정규식과 산술을 통해 결정론적으로 처리됩니다. 결과는 미리 계산된 사실로 종합 프롬프트에 주입됩니다. 모델은 날짜 계산과 같은 사항에서 신뢰할 수 없으므로 우리는 모델에게 모델을 요청하지 않습니다.
에이전트 메모리의 초기 프로토타입은 기본 추출 파이프라인, 벡터 스토리지, 간단한 검색 기능을 갖추고 있을 정도로 가벼웠습니다. 개념을 시연하기에 충분했지만, 출시하기에 충분하지는 않았습니다.
그래서 이를 에이전트 기반 루프에 넣고 반복했습니다. 주기는 다음과 같았습니다. 벤치마크 실행, 격차가 발생한 부분 분석, 솔루션 제안, 제안서를 검토하여 과적합이 아닌 일반화를 위한 전략을 선택하고, 에이전트가 변경하도록 허용하고, 반복합니다.
이는 잘 작동했지만, 한 가지 문제가 발생했습니다. LLM은 온도가 0으로 설정되어 있어도 확률적입니다. 이로 인해 실행에 따라 결과가 달라지게 되어 여러 실행(대규모 벤치마크의 경우 시간이 많이 소요됨)을 평균화하고 원시 점수와 함께 추세 분석을 통해 실제로 효과가 있었던 것을 파악해야 했습니다. 그 과정에서 우리는 제품이 일반적인 경우에 더 나아지지 않도록 벤치마크를 과도하게 맞추지 않도록 주의해야 했습니다.
시간이 지남에 따라 반복할 때마다 벤치마크 점수가 일관되게 개선되고 실제 환경에서 작동할 수 있는 일반화된 아키텍처를 갖추는 데 성공했습니다. 우리는 의도적으로 여러 벤치마크(LoCoMo, LongMemEval, BEAM 포함)와 비교하여 다양한 방식으로 시스템을 테스트했습니다.
우리는 Cloudflare를 기반으로 Cloudflare를 구축하며, 에이전트 메모리도 마찬가지입니다. 강력하고 쉽게 구성할 수 있는 기존의 기본 요소를 이용하여 주말에 첫 번째 프로토타입을 출시하고 한 달도 안 되는 시간에 내부 버전의 에이전트 메모리가 완전히 작동하여 프로덕션화할 수 있었습니다. 전달 속도 외에도 Cloudflare는 몇 가지 다른 이유로 이러한 종류의 서비스를 구축하기에 이상적인 장소로 판명되었습니다.
내부적으로 에이전트 메모리는 여러 시스템을 조정하는 Cloudflare Worker입니다.
Durable Object: 원시 메시지와 기밀된 메모리를 저장합니다
Vectorize: 임베디드 메모리에 대한 벡터 검색 제공
Workers AI: LLM 및 임베딩 모델 실행
각 메모리 컨텍스트는 자체 Durable Object 인스턴스와 Vectorize 인덱스에 매핑되므로 컨텍스트 간에 데이터가 완전히 격리됩니다. 또한 저희는 더 높은 수준의 요구에 맞춰 쉽게 확장할 수 있습니다.
Durable Objects를 통한 컴퓨팅 격리. 각 메모리 프로필에는 SQLite 지원 저장소가 있는 자체 Durable Object (DO)를 가져와 인프라 오버헤드 없이 테넌트를 강력하게 격리합니다. DO는 FTS 인덱싱, 대체 체인, 트랜잭션 쓰기를 처리합니다. DO의 getByName() 주소 할당은 어디에서든 모든 요청이 이름별로 올바른 메모리 프로필에 도달할 수 있음을 의미하고, 중요한 메모리가 다른 테넌트와 강력하게 격리되도록 보장합니다.
스택 전반에 걸친 스토리지. 메모리 콘텐츠는 SQLite 기반 DO에 있습니다. 벡터는 Vectorize에 있습니다. 향후에는 스냅샷 및 내보내기가 비용 효율적인 장기 스토리지를 위해 R2 로 전환될 것입니다. 각 기본 요소는 워크로드에 맞게 목적에 맞게 구축되어 있으므로, 모든 것을 하나의 셰이프나 데이터베이스로 강제할 필요는 없습니다.
Workers AI를 사용한 로컬 모델 추론. 전체 추출, 분류, 종합 파이프라인은 Cloudflare의 네트워크에 배포된 Workers AI 모델에서 실행됩니다. 모든 AI 호출은 메모리 프로파일 이름으로 라우팅된 세션 선호도 헤더를 전달하므로 반복 요청이 동일한 백엔드에 도달하여 프롬프트 캐싱 이점이 제공됩니다.
Cloudflare가 선택한 모델 중 한 가지 흥미로운 사실은 더 크고 강력한 모델이 항상 더 좋은 것은 아니라는 점입니다. 현재 추출, 검증, 분류, 쿼리 분석에는 Llama 4 Scout(17B, 16-전문가 MoE), 합성에는 Nemotron 3(120B MoE, 12B 활성 파라미터)을 기본 사용하고 있습니다. Scout는 구조화된 분류 작업을 효율적으로 처리하는 반면, Nemotron의 더 큰 추론 용량은 자연어 답변의 품질을 개선합니다. 신시사이저는 문제에 더 많은 매개변수를 지속적으로 적용하는 것이 도움이 된 유일한 단계입니다. 다른 모든 경우에는 소규모 모델이 비용, 품질, 대기 시간 측면에서 스위트 스폿이 더 적었습니다.
Cloudflare에서는 자체 워크플로우를 위해 내부적으로 에이전트 메모리를 다음에 구축할 것에 대한 검증장이자 아이디어의 원천으로 실행하고 있습니다.
코딩 에이전트 메모리. 저희는 에이전트 메모리를 개발 루프에 연결하는 내부 OpenCode 플러그인을 사용하고 있습니다. 에이전트 메모리는 세션 내에서, 그리고 세션 전반에서 과거 압축의 메모리를 제공합니다. 이점은 덜 분명했지만 팀 간에 메모리를 공유하면 에이전트가 팀의 다른 구성원이 이미 배운 내용을 알 수 있으므로 이미 답변된 질문을 하지 않고 이미 답변된 실수를 피할 수 있습니다 수정했습니다.
에이전트에 의한 코드 검토. 우리는 에이전트 메모리를 내부 에이전트 코드 검토기에 연결했습니다. AI에서 배운 가장 유용한 방법은 '조용한 상태를 유지하는 것'이었습니다. 이제 리뷰어는 특정 댓글이 과거 리뷰와 관련이 없었고, 특정 패턴에 플래그가 지정되었으며, 작성자가 정당한 이유로 해당 댓글을 유지하기로 결정했음을 기억합니다. 리뷰는 시간이 지날수록 더 스마트해지는 것이 아니라 덜 복잡해집니다.
채팅 봇. 또한 메시지 기록을 수집한 다음 전송된 새 메시지를 숨기고 기억하는 내부 챗봇에 메모리를 연결했습니다. 그런 다음 누군가가 질문하면 이전 대화를 기반으로 답변할 수 있습니다.
또한 서비스를 개선하고 개선하면서 가까운 시일 내에 내부적으로 롤아웃할 계획인 여러 추가 사용 사례가 있습니다.
추출 파이프라인을 개선하고, 검색 품질을 조정하며, 백그라운드 처리 기능을 확장하면서 내부적으로 에이전트 메모리를 계속 테스트하고 개선하고 있습니다. 인간의 뇌가 수면 중에 재생하고 연결을 강화하여 기억을 통합하는 것과 마찬가지로, 메모리 저장이 비동기적으로 개선될 기회를 포착하며, 현재 이를 작동시키기 위해 다양한 전략을 구현하고 테스트하고 있습니다.
에이전트 메모리는 곧 일반에 공개할 계획입니다. Cloudflare에서 에이전트를 구축하는 중이고 초기 액세스를 이용하려면 대기 목록에 참여하려면 문의하세요.
아키텍처에 대해 자세히 알아보거나, 구축 중인 것을 공유하거나, 추가 개발 과정을 확인하고 싶으시다면, Cloudflare Discord 에 참여하시거나 Cloudflare Community에서 스레드를 시작하세요. Cloudflare는 두 가지 모두를 적극적으로 주시하고 있으며, 프로덕션 에이전트 워크로드가 실제로 작동하는 방식에 관심이 있습니다.