Agent-engine-sdk-memory

해결되는 문제

메모리는 에이전트 중요한 사실, 대화, 절차, 어휘를 영구적으로 저장 하고, 에이전트 가 LLM과 나눈 대화에서 지속형 학습된 사실을 추출하여 해당 저장 자체를 채웁니다. 추출 자체는 사용자가 구성한 LLM에 의해 수행됩니다.

플랫폼에 배포된 에이전트 의 경우 이 중 어느 것도 연결이 필요하지 않습니다. 런타임은 에이전트 워크플로가 실행될 때 각 대화가 단기 메모리로 바뀌고, 승격과 추출이 배경 에서 비동기적으로 진행되므로 팩트가 정제되는 동안 응답을 차단하는 것이 아무것도 없습니다. 지속형 형을 이미 알고 있는 에이전트 이를 찾기 위해 추출을 기다릴 필요가 없습니다 — save_semantic 및 다른 유형의 쓰기를 사용하여 팩트를 직접 쓰기 (write) 수 있습니다.

다시 읽으면 어느 쪽이든 상관없이 작동합니다. 에이전트 한 번에 한 가지 종류의 사실, 즉 학습한 내용에 대해서는 search_semantic, 이전에 발생한 내용에 대해서는 search_episodes, 텀 의미에 대해서는 search_taxonomic, 어떤 것이 수행되는 방법에 대해서는 discover_procedures 등을 추적하고 처리하다. 결과 자체.

또는 전체 작업 넘길 수도 있습니다. build_context_from_sources은(는) 소스당 하나의 사양을 취하고, 각각 고유한 검색 모드, 필터하다 및 후보 수를 선언한 다음, 모든 소스에서 자체 텀에 따라 결과를 검색하고, 결과의 순위를 지정하고 중복을 제거하고, 토큰 예산으로 자르고, 다음을 반환합니다. 단일 컨텍스트 차단 사용하여 다음 프롬프트로 이동할 수 있습니다. build_context은 모든 소스에 대해 하나의 모드 와 하나의 필터하다 사용하여 동일한 작업을 수행합니다. 달라야 하는 경우 소스별 형식을 사용하세요.

2개의 레이어

메모리는 사물의 수명과 형태에 따라 분할 됩니다.

단기 기억(STM)은 원시 대화로, 세션 범위가 지정된 턴당 하나의 기록 발생하는 대로 기록됩니다. 모든 내용을 순서대로 쓰기 (write) 하고 완료하는 것은 비용이 저렴합니다.

대화에서 살아남은 장기 기억은 서로 다른 질문에 답변 때문에 네 가지 형태로 정제됩니다.

프로젝트는 네 가지 형태가 맞지 않는 도메인 레코드에 대해 사용자 지정 유형을 선언할 수도 있습니다.

쓰기가 메모리가 되는 방법

장기 기억은 직접 쓰기 (write) 는 없지만 쓸 수는 있습니다. 일반 경로는 다음과 같습니다.

record_turn(...)          you write turns as the conversation happens
      │
      ▼   turns accumulate into a session
   snapshot                a contiguous run of turns, summarised
      │
      ▼   an LLM reads the snapshot and extracts what is durable
  semantic · episodic · procedural · taxonomic

추출은 비동기식이며 배경 에서 실행되므로 record_turn은 빠른 쓰기 (write) 를 유지합니다. 따라서 한 대화에서 학습한 사실은 다음 차례가 아닌 다음 대화에서 사용할 수 있습니다.

결과는 설계할 가치가 있습니다: 최근 회전은 STM을 통해 즉시 표시되고 추출된 지식은 잠시 후에 나타납니다. 방금 언급한 내용이 필요할 때는 stm을(를) 요청하세요.

추출 실패 시

백그라운드 추출은 임베딩 서비스, 추출 LLM 및 데이터베이스 에 따라 달라지며, 이 중 하나라도 실패할 수 있습니다. 사용자의 쓰기는 다운스트림에서 어떤 일이 발생하든 record_turn이(가) 반환되었을 때 성공했다는 것과 격리됩니다.

배후에서는 실패한 단계를 한 가지 질문으로 분류합니다. 즉, 요청 변경하지 않고 조건을 변경할 수 있나요? 환경 장애(네트워크 오류, 제공자 중단, 속도 제한, API 키 순환 중간)는 백오프를 사용하여 자동으로 재시도되고, 장애에 따라 속도가 조정됩니다: 네트워크 블립은 몇 초 내에 재시도하고, 자격 증명 문제는 키가 사람에 의해 순환되기 때문에 더 느리게 재시도됩니다. 재시도가 결과를 변경할 수 없으므로 콘텐츠 결정 실패는 재시도되지 않습니다. 영구적으로 반복되는 대신 연산자가 볼 수 있는 서버 측에 기록됩니다.

이는 외부 가장자리뿐만 아니라 전체 추출 경로에 적용됩니다. 실패한 단계는 더 이상 조용히 빈 결과를 생성하지 않습니다. 즉, 재시도하거나 연산자가 조치를 취할 수 있는 곳에 기록됩니다.

하나의 사용하지 않는 품목은 나머지를 버리지 않습니다. 단일 메모리를 임베드할 수 없는 경우(해당 내용이 모델에 비해 너무 길거나 제공자 거부한 경우) 해당 메모리는 계속 저장되고 동일한 배치 의 다른 메모리는 영향을 받지 않습니다. 저장된 메모리에 부족한 것은 벡터입니다. 실제로 다음을 수행합니다.

• 여전히 text 검색 및 hybrid 로 찾을 수 있으며, 하이브리드는 두 순위를 결합하므로 텍스트 면에서 여전히 표면에 표시됩니다.

• 벡터만 비교하는 semantic 검색 에서는 찾을 수 없습니다.

이것이 기본값 검색 모드 로 hybrid 을(를) 선호하는 좋은 이유입니다. 정확한 식별자와 드문 단어에 대해 이미 더 나은 선택이며, 임베디드할 수 없는 메모리가 여전히 도달한다는 의미이기도 합니다.

이것이 에이전트 에게 의미하는 바는 다음과 같습니다.

• 제공자 중단으로 인해 추출된 지식이 지연됩니다. 자신의 차례를 잃지 않습니다. STM은 동기식으로 작성되며 영향을 받지 않습니다. 방금 언급한 내용이 필요할 때 stm를 계속 요청하세요.

• 재시도에는 제한이 있습니다. 재시도 기간보다 오래 지속되는 종속성 중단은 무기한 반복되는 대신 재시도를 중지하고 실패는 삭제되지 않고 기록됩니다.

• 이 중 어느 것도 SDK를 통해 오류로 표시되지 않습니다. 추출 실패는 서버 측 문제입니다. SDK 표시 신호는 (아직) 검색에 나타나지 않거나 텍스트와 하이브리드를 통해 나타나지만 시맨틱 검색 나타나지 않는 추출된 메모리입니다.

읽기 작동 방식

조립된 산문 또는 기록 자체 - 두 가지 다른 질문입니다.

``build_context_from_sources(...)`` 가 기본값 으로 도달해야 합니다. 쿼리 와 토큰 예산을 제공합니다. 사용자가 지정한 메모리 유형 전체를 검색하고, 결과의 순위를 매기고, 중복에 가까운 항목을 삭제하고, 예산을 줄이고, 프롬프트에 바로 입력할 수 있는 항목을 반환합니다. 하나의 호출 뒤에 숨은 전체 검색 파이프라인 이며 소스당 하나의 사양이 필요하므로 모드와 필터는 모든 항목에 대해 한 번이 아닌 소스별로 설정하다 됩니다.

검색은 세 가지 방법으로 일치시킬 수 있습니다. semantic는 임베딩을 비교하고 동일한 MEAN 를 찾습니다. text은 단어를 일치시키고 동일한 내용을 찾는 항목을 찾습니다. hybrid가 두 가지를 모두 실행하고 순위를 통합합니다. 일반적으로 하이브리드가 올바른 기본값 입니다. 벡터 검색 만으로는 정확한 식별자와 드문 단어를 놓치고 텍스트 검색 만으로는 의역을 놓칠 수 있습니다.

``build_context(...)``는 더 간단한 빌더로 동일한 파이프라인 이지만 읽는 모든 소스에 하나의 모드 와 하나의 필터하다 적용 .

``검색(...)`` 및 유형별 검색 (search_semantic, search_episodes 등)은 직접 검사하거나 후처리하려는 경우 조립된 산문 대신 순위가 매겨진 레코드를 반환합니다.

메모리 범위 지정

모든 기록 기록된 ID를 포함하며, 모든 읽기는 이후가 아닌 데이터베이스 쿼리 에서 해당 ID로 필터링됩니다. 필드에는 조직, 사용자, 프로젝트, 세션 및 선택적으로 에이전트 와 기록 를 사용자에게 비공개로 유지할지 또는 더 널리 읽을 수 있도록 할지 여부를 결정하는 가시성(visibility)이 있습니다.

This matters for a practical reason: a search or build_context scoped to a user will not surface another user’s private memory, because the constraint is part of the query rather than a filter applied to its results. So bind(...) is not a convenience — it is how you declare the scope that subsequent reads and writes operate within, and getting it wrong writes one user’s memory under another’s identity.

user_id 및 visibility이(가) 다른 질문에 답변.

user_id 은(는) 누구의 메모리에 해당하는지 기록 . visibility은(는) 도달하는 거리입니다.

가시성 값은 기록 이 작성된 프로젝트 외부에 도달하지 않습니다. 메모리는 프로젝트 별로 저장되므로 프로젝트 경계는 가시성이 넘을 수 있는 것이 아닙니다 — org 은(는) 과거 이름으로, "한 사용자에게 제한되지 않음"을 의미합니다. "다른 프로젝트에 표시".

이 둘은 독립적이며, 읽기 시 and로 결합되며, 절대로 as로 결합하지 않습니다. 입력하는 각 필드 쿼리 에 하나 이상의 동등성 조건을 추가합니다. 생략한 각 필드 해당 차원에 제약이 없는 상태로 유지됩니다.

세 번째 줄은 사람들을 놀라게 하는 줄입니다. search_semantic(query, user_id="user_1", visibility="org")는 'user_1의 메모리와 조직의 메모리'를 MEAN 하지 않습니다. 이는 'user_1가 소유한 조직에서 볼 수 있는 메모리'를 의미하며, 이는 두 제약 조건 중 하나보다 작습니다. 공유된 지식과 사용자의 비공개 메모리를 읽으려면 호출을 두 번 실행하고 결과를 직접 병합하는 방법은 없습니다.

호스팅된 플랫폼

managed 서비스입니다. 서비스 계정 액세스 토큰과 프로젝트 ID를 전달합니다.

agentengine CLI 사용하여 토큰을 발행합니다. 서비스 계정을 한 번 생성합니다. 클라이언트 시크릿은 한 번만 표시되므로 즉시 저장합니다.

agentengine service-account create my-agent --project-id <your-project-id> --role AGENT_DEVELOPER

그런 다음 클라이언트 ID 와 시크릿을 단기(1시간) 액세스 토큰으로 교환합니다(curl은 클라이언트 시크릿을 입력하라는 메시지를 표시하므로 셸 기록에서 제외됨).

ACCESS_TOKEN=$(curl --fail-with-body --silent --show-error      --user <client-id>      --data grant_type=client_credentials      https://agentengine.mongodb.com/api/v1/oauth/token | jq -er .access_token)

memory = Memory(service_account_token="<your-access-token>", project_id="<your-project-id>")

플랫폼은 사용자의 자격 증명을 프로젝트 에 고정하므로 일치하지 않는 project_id는 거부됩니다. 빈 service_account_token은 ValueError를 발생시킵니다.

api_key (및 AGENTIC_MEMORY_API_KEY)은(는) 더 이상 사용되지 않는 별칭으로 허용된 상태로 유지되고 DeprecationWarning을 방출합니다. 새 입력과 레거시 입력을 모두 전달하면 ValueError가 발생합니다. 프로젝트 API 키는 더 이상 HTTP 통해 생성할 수 없으므로 새로운 통합은 서비스 계정 토큰을 사용해야 합니다.

지역 개발

직접 실행 백엔드( 예: 스택 agentengine dev up가 시작됨)를 가리킵니다.

memory = Memory(base_url="http://localhost:8080")

로컬 개발을 위해 project_id을 비워 둡니다.

플랫폼 에이전트 내부(앱 바운드)

에이전트 가 Atlas Agent Engine에서 실행될 때는 Memory 인스턴스 전혀 구성하거나 연결하지 않습니다. 애플리케이션 코드는 위의 입력 중 어느 것도 전달하지 않습니다. 런타임에 전달된 처리하다 을 사용합니다. ID(사용자, 세션, 조직, 프로젝트)는 앰비언트 런타임 컨텍스트에서 확인되므로 작업을 직접 호출할 수 있습니다.

# `memory` is supplied by the platform runtime — do not construct it.
memory.record_turn(role="user", content="I'm allergic to penicillin.")
context = memory.build_context(query="What medications should I avoid?")
# bind(...) is still available to scope a call chain to a specific identity.

앱 바인딩 경로에는 몇 가지 역량 격차(공구 호출/모형 회전 메타데이터 및 일부 목록 스타일 읽기)가 있습니다.각 연결이 지원하는 항목의 앱 바인딩 열 및 `docs/capability-matrix.md <docs/capability-matrix.md>`__를 참조하세요.

환경 변수는 폴백입니다.

인수를 생략하면 각 입력도 AGENTIC_MEMORY_* 환경 변수로 대체됩니다. 명시적인 인수는 항상 이깁니다. 인수가 없는 Memory()은 환경에서 세 가지를 모두 읽습니다.

라우팅 작동 방식

project_id 통화가 이동하는 위치를 결정합니다. 인증은 절대 그렇지 않습니다.

• project_id를 설정하면 SDK가 프로젝트의 경로 /api/v1/projects/{project_id}/memory/*를 호출합니다.

• 비워 두면 SDK가 백엔드 /api/v1/memory/*를 직접 호출합니다.

project_id 가 설정하다 되었지만 백엔드 일치하는 경로(예: 로컬 백엔드 ) 가 없는 경우 호출은 설정 해제를 위한 힌트와 함께 `MemoryRouteNotFoundError <#errors>`__를 발생시킵니다. 그 반대도 마찬가지입니다. project_id 없이 호스팅된 서비스를 대상으로 지정하고 이를 설정하다 하는 힌트와 함께 404를 호출합니다.

고급: 인증된 직접 백엔드

인증과 라우팅은 독립적이므로 project_id이 비어 있는 service_account_token을 전달할 수 있습니다. 그런 다음 SDK는 프로젝트 경로를 건너뛰고 직접 경로에서 인증된 호출을 base_url의 백엔드 로 직접 보냅니다. 이는 직접 도달하는 호스팅된 오케스트레이션 엔진(OE)에 적합합니다.

각 연결이 지원하는 것

기능은 인증이 아닌 통화가 라우팅되는 위치를 따릅니다.

지원되지 않는 호출은 `MemoryNotSupportedError <#errors>`__를 발생시킵니다 — 알려진 백엔드별 격차에 대한 네트워크 요청 이전 또는 플랫폼만 보고할 수 있는 역량 격차에 대한 응답 후(Errors 참조) — 조용한 실패나 원시 오류가 발생하지 않습니다. HTTP 오류입니다. 유형별 CRUD 의 앱 바인딩된 간격을 포함한 전체 백엔드별 참조는 `docs/capability-matrix.md <docs/capability-matrix.md>`__에 있습니다.

앱 바인딩 에이전트는 위의 모든 사항에 대한 예외입니다. 배포된 플랫폼 에이전트 내부에 플랫폼이 준비된 runtime를 주입하므로 애플리케이션 코드는 이러한 입력 중 어느 것도 전달하지 않습니다.

나중에 변경할 수 없는 설정

구성의 일부는 사실상 한 번 쓰기이므로 메모리 쓰기를 시작하기 전에 결정합니다.

• 메타데이터 파티션 키 - 선언된 필터링 가능한 속성입니다. 선언된 후에는 키는 제거하거나 유형을 변경할 수 없습니다.

• 사용자 지정 메모리 유형 선언 — 일단 유형이 허용되면 해당 컬렉션 과 태그 세트 config API 통해 편집하거나 제거할 수 없습니다. 대신 새 유형 이름을 선언합니다.

• 검색 인덱스 — 아직 존재하지 않는 경우에만 프로비저닝됩니다. 서버 시작된 후 파티션 키 추가해도 기존 인덱스 다시 작성되지 않습니다. 그러면 드리프트가 기록되고 새 키에 대한 필터하다 자동으로 무시되지 않고 데이터베이스 에서 실패합니다. 인덱스 다시 만들기는 수동 작업입니다.

로그 수준, 추출 LLM 및 활성화된 추출 유형을 변경하고 다시 적용할 수 있습니다. 임베딩 모델 또는 차원을 변경하려면 기존 메모리를 마이그레이션하고 다시 임베딩해야 합니다. 차원을 변경하려면 벡터 검색 인덱스를 다시 작성해야 합니다.

쓰기 (write) 에 대한 가시성 설정

모든 쓰기 (write) visibility이(가) 걸립니다. 유형이 다르게 사용되기 때문에 기본값 메모리 유형에 따라 다릅니다.

도메인 어휘는 텀 에 따라 공유되기 때문에 분류학적 메모리 기본값은 org입니다. 다른 모든 항목의 기본값은 private이므로, 저장하는 팩트의 범위는 별도로 지정하지 않는 한 해당 정보를 학습한 사용자로 지정됩니다.

record_turn 는 예외입니다: visibility 및 user_id도 필요하지 않습니다. 대화 차례는 항상 바인딩된 사용자 및 세션 아래에 기록되므로, 차례를 기록하기 전에 bind(...) — 사용자의 차례를 설정하다 수 있는 호출별 방법이 없습니다.

# Private to user_1 — the default.
session.save_semantic(text="Prefers window seats.", label="seat-preference")
# Readable across the whole organization.
session.save_semantic(
    text="Refunds over $500 need manager approval.",
    label="refund-policy",
    visibility="org",
)

읽기 범위 지정

읽기는 visibility를 설정하지 않은 상태로 두므로, 일반적으로 바인딩된 user_id인 확인되는 ID에 의해서만 제약을 받습니다. 이는 개인화 위한 올바른 기본값 입니다. 즉, 모든 가시성에서 사용자가 소유한 모든 것을 얻을 수 있습니다.

공유된 지식에 도달하려면 가시성 및 여기 및 규칙 바이트를 전달합니다. user_id="user_1"에 바인딩된 처리하다 여전히 해당 user_id에 기여하므로 user_1가 소유한 조직 표시 레코드만 읽습니다.

session = memory.bind(MemoryRequestContext(user_id="user_1", session_id="thread_123"))
session.search_semantic("refund policy", visibility="org")   # user_1 AND org

user_id=None을 전달해도 확장되지 않습니다. None 또는 빈 인수는 모든 계층 에서 '제공되지 않음'으로 간주되므로 바인딩된 값에 속합니다. user_id 바운드가 없는 처리하다 사용하여 모든 사용자를 읽습니다.

# The original handle is unbound, so it carries no user_id.
memory.search_semantic("refund policy", visibility="org")
# Or bind only the parts you want.
thread = memory.bind(MemoryRequestContext(session_id="thread_123"))
thread.search_semantic("refund policy", visibility="org")

따라서 사용자의 기록과 팀이 공유한 지식이 모두 필요한 어시스턴트는 이를 두 번 읽고 병합합니다.

personal = session.search_semantic(query, top_k=5)                       # user_1, any visibility
shared = memory.search_semantic(query, visibility="org", top_k=5)        # org-wide, any owner

자체 메타데이터 다시 읽기

record_turn 선택적 metadata 딕셔너리를 취하며, 단기 검색은 청크 의 자체 슬롯인 chunk.metadata["metadata"]에서 이를 반환합니다. 키는 플랫폼의 턴 필드(session_id, role, turn_seq, ...)와 혼합되지 않고 별도로 유지되므로 키가 서로 충돌하지 않습니다. 키의 이름을 role 또는 session_id를 생성하고 사용자 자신의 값을 다시 읽습니다.

Two limits that collision-safety does not cover. Values have to survive the round trip, so they must be JSON-serializable and of a sane size. And to be filterable a key additionally has to be declarable as a metadata partition key: each dot-separated segment must match ^[a-z][a-z0-9_]{0,63}$, at most one dot is allowed, and a few names are reserved (org_id, project_id, user_id, agent_id, content, embedding, embedding_model_id, created_at). A key outside that shape — Tier, $foo, a.b.c — is still stored and returned, it just cannot be filtered on.

An empty dict is treated as no metadata: metadata={} records the turn without a metadata slot on the chunk, so read it with chunk.metadata.get("metadata", {}) if the caller might not have supplied any. Semantic memory behaves identically, which is what lets one read path cover both. Episodic, taxonomic and procedural behave the same way: the dict you write comes back under chunk.metadata["metadata"], and an empty one means no slot at all. Episodic is the one exception: a compatibility filter drops the whole dict, unrelated keys included, if it happens to contain citation_score, llm_confidence_score and combined_score together, since that shape also matches a pre-migration internal blob. Retrieval may also carry chunk.metadata["contextual_metadata"] — that is the platform’s own extraction artifact, not your data, and it is not part of any contract you should depend on.

단기 기억은 세션으로 범위가 지정되므로 쓰기 (write) 와 읽기는 동일한 이름을 지정해야 합니다.

from agent_engine_sdk_memory import (
    Memory,
    MemoryRequestContext,
    MemorySource,
    RetrievalMode,
    SourceSpec,
)
session_id = "session-42"
memory = Memory(base_url="http://localhost:8080").bind(
    MemoryRequestContext(user_id="user-1", session_id=session_id)
)
memory.record_turn(
    role="user",
    content="The engagement is green and the rollout continues.",
    metadata={"engagement_id": "eng-alpha", "tier": 2},
)
context = memory.build_context_from_sources(
    query="what is the engagement status?",
    sources=[
        SourceSpec(
            source=MemorySource.STM,
            mode=RetrievalMode.HYBRID,
            metadata_filter={"metadata.engagement_id": "eng-alpha"},
        )
    ],
    session_id=session_id,
    include_memories=True,
)
for chunk in context.selected_memories or []:
    print(chunk.metadata["metadata"]["engagement_id"])

Atlas Search 쓰기 (write) 비동기적으로 인덱싱하므로 직후에 실행된 읽기는 아직 순서를 확인할 수 없습니다.

알아야 할 한 가지 철자 차이는 중첩된 딕셔너리 chunk.metadata["metadata"]["engagement_id"] 내의 베어 이름을 읽지만 정규화된 인덱스 경로 {"metadata.engagement_id": ...}를 필터하다 것입니다. 둘 다 중첩을 인정합니다 — 필터하다 저장된 문서 주소로 하며, 여기서 딕셔너리는 실제로 metadata 아래에 있습니다.

베어 이름에 대한 필터링은 허용된 경로를 나열하는 오류와 함께 거부되므로 실수를 통해 답변 알 수 있습니다.

먼저 프로젝트 에 대해 필터링 가능한 메타데이터 선언해야 합니다. 위의 engagement_id는 metadata_partition_key 아래에 나타나야 하며, short_term는 metadata_partition_index에 나열되어야 합니다.사용에서 필터링 가능한 메타데이터 선언을 참조하세요.

패키지 레이아웃

agent_engine_sdk_memory/
├── memory.py        # Memory — the public, transport-free facade
├── protocol.py      # MemoryRequestContext, MemoryRuntime + MemoryCrudClient seams
├── identity.py      # resolve_identity — call arg > bind ctx > runtime ctx
├── errors.py        # MemoryIdentityError + the typed transport-error family
├── models.py        # Pydantic models for memory requests/responses
├── validation.py    # require_positive_max_tokens — public build_context guard
├── _transport.py    # _HttpTransport — shared retry / error-mapping / lifecycle
├── _http_runtime.py # _HttpMemoryRuntime — the workflow ops + per-backend profiles
├── _direct_crud.py  # empty-tenancy MemoryCrudClient over the shared transport
├── _wire.py         # custom-type request-body builders shared by the CRUD clients
├── _tag_syntax.py   # client-side custom-type name + tag-syntax checks
├── _client.py       # MemoryClient — internal HTTP client for the Memory Server API
└── _denylist.py     # do-not-add dependency denylist (see below)

Memory 즉, 워크플로 작업(record_turn, build_context, 검색, discover_procedures)을 삽입된 MemoryRuntime에, 유형별 CRUD 삽입된 MemoryCrudClient에 위임합니다. 공개 표면은 tests/test_package_contract.py의 스냅샷 테스트로 인해 동결됩니다. MemoryClient은(는) 내부에 유지됩니다. 호출별 테넌시(org_id, 본문 수준 project_id)는 공개 서명에 표시되지 않습니다. 공개 표면의 유일한 project_id는 요청 본문이 아닌 URL 로 이동하는 선택적 생성자 경로 형태 선택기입니다.

종속성 거부 목록

The pydantic + httpx-only constraint is enforced, not aspirational. _denylist.py lists known-heavy distributions and import names (langchain, fastapi, pymongo, …), and tests/test_package_contract.py fails if importing the package pulls any of them into sys.modules.

누가 그것을 사용 하 여

agent-engine-runner-shared 이 패키지 작업 공간 종속성으로 선언하고 agent_engine_runner_shared/memory.py에 내부 MemoryClient를 구성하여 실행 컨텍스트 조회를 execution_id_provider 콜러블로 전달하여 이 패키지 플랫폼 코드를 가져오지 않고도 요청별 실행 ID 헤더가 작동하도록 합니다.