왜 중요한가
스코핑이 없으면 Alice를 돕는 Agent가 Bob에 대해 쓴 노트도 봅니다. 이건 이렇습니다.- 프라이버시 문제입니다.
- 품질 문제입니다(Bob의 맥락이 Alice의 답을 더럽힙니다).
- 컴플라이언스 문제입니다(GDPR, HIPAA).
스코프 모양
스코프 키는 JSON 같은 객체입니다. 흔한 모양은 이렇습니다.런타임에 스코프 정하기
두 가지입니다.Trigger로
Trigger가 실행에 스코프 키를 넘깁니다. 그 실행의 모든 메모리 작업이 자동으로 씁니다. 채팅 트리거는 스코프 기본값이{ conversation_id: <session> } 입니다. Trigger 블록 설정에서 덮어씁니다.
웹훅 트리거는 페이로드에서 뽑습니다.
도구별 덮어쓰기
도구가 실행 기본값을 덮어쓰는 스코프로 메모리를 부를 수 있습니다. 드뭅니다. 대개 냄새가 나죠. Agent가 정당하게 스코프를 넘어 읽어야 할 때만 씁니다(예: 지원 에이전트가 모든 고객에 걸친 자기 지식을 읽음).스코프 계층
스코프는 겹칠 수 있습니다. 더 넓은 스코프로 쓰면 항목이 모든 좁은 스코프에서 보입니다. 예를 들면 이렇습니다.{ tenant: "acme" }에 쓰면 Acme 안 모두가 봅니다.{ tenant: "acme", user: "alice" }에 쓰면 Alice만 봅니다.- Alice의 읽기는 자기 항목과 테넌트 전체 항목을 둘 다 봅니다.
스코프를 넘는 접근(주의!)
일부 Agent는 정당하게 스코프를 넘어 읽어야 합니다. 지원 에이전트, 관리자 대시보드 같은 것들이죠. 스페이스마다 줍니다.- Cross-scope read Agent가 어느 스코프든 읽습니다. 쓰기는 여전히 지금 스코프를 지킵니다.
- Cross-scope everything 읽기와 쓰기 다요. 관리자 용도에만 씁니다.
스코프 격리 테스트
Space settings → Test isolation 입니다. 스코프 키 두 개와 쿼리를 넣습니다. Nora가 각 스코프에서 쿼리를 돌려 항목이 서로 안 새는지 보여줍니다. 격리가 깨지면 시끄럽게 실패합니다. 여러 사용자 메모리를 가진 Flow를 배포하기 전에 권합니다.새는 것 디버깅
Agent가 몰라야 할 걸 아는 것 같으면 이렇게 합니다.- 트레이스의 메모리 작업을 봅니다. 모든 읽기/쓰기가 스코프와 함께 기록됩니다.
- 의도보다 넓은 스코프로 쓰인 항목을 찾습니다.
- 실수로 스코프를 넘은 도구 호출을 찾습니다.