Bộ nhớ và tri thức

Bộ nhớ dùng để làm gì

Không có bộ nhớ, mọi cuộc hội thoại với agent đều bắt đầu từ số không: cùng một quy ước phải được giải thích lại, cùng một quyết định phải tranh luận lại, cùng một ngõ cụt phải dò lại. Bộ nhớ là kho có phạm vi không gian làm việc, tồn tại qua các lần chạy, và nó tồn tại để tri thức do agent này tạo ra vẫn tìm được về sau bởi một agent khác.

Nó có ba tầng và chúng trả lời những câu hỏi khác nhau:

1. Sự kiện — điều gì là đúng (một quy ước, một kết quả, một quyết định).
2. Chính sách — agent phải làm gì với điều đó (một quy tắc mang tính quy phạm).
3. Bộ nhớ làm việc — điều mà một agent đang làm dở.

Sự phân biệt này quan trọng vì chúng đến với agent bằng những đường khác nhau. Sự kiện thì được tìm kiếm. Chính sách thì được đẩy vào. Bộ nhớ làm việc là riêng tư.

Sự kiện

MemoryFact là một đơn vị tri thức có phạm vi gắn với một không gian làm việc và một miền.

Thuộc tính	Nội dung
domain	Miền tri thức (“conventions”, “decisions”, “codebase”)
topic	Nhãn chủ đề ngắn
content	Nội dung tri thức
confidence	0.0–1.0, được gieo từ nguồn gốc và tăng lên khi được nhắc lại
memoryType	Loại của sự kiện — quyết định đường cong suy giảm theo thời gian của nó
veracity	Cách nó được biết đến — gieo độ tin cậy và định cỡ mức tăng mỗi lần nhắc lại
sourceObservationIds	Những quan sát nào đã dẫn đến nó
supersededBy	Sự kiện mới hơn đã thay thế nó, nếu có
validUntil, recallCount, mentionCount	Tín hiệu hết hạn và mức sử dụng dùng khi truy hồi

Hai dòng cuối là những dòng người ta thường bỏ qua, và chúng chính là thứ quyết định sự kiện nào nổi lên. memoryType mang các tham số suy giảm Weibull riêng cho từng loại, nên một cam kết có thời hạn sẽ phai nhanh còn một sự kiện hồ sơ ổn định thì không. veracity ghi lại nguồn gốc — do con người nêu (trọng số 1.0), do agent suy ra (0.7), do công cụ tạo ra (0.5), do nhập vào (0.6) — và trọng số đó gieo độ tin cậy ban đầu cho sự kiện.

Sự kiện không bao giờ được sửa tại chỗ khi bị mâu thuẫn. Việc ghi một sự kiện sẽ chạy phát hiện xung đột với các sự kiện cùng miền, cùng chủ đề và thay thế bên thua, đồng thời ghi lại một dòng xung đột. Dấu vết kiểm toán mới là điểm mấu chốt: bạn luôn có thể thấy trước đây người ta tin điều gì và điều gì đã thay thế nó.

Chính sách

MemoryPolicy là một quy tắc mang tính quy phạm được suy ra từ các sự kiện, có phạm vi gắn với một không gian làm việc và một miền, kèm một cờ hoạt động và một requiredRole tùy chọn.

Mọi chính sách đang hoạt động trong không gian làm việc đều được chèn vào mọi lần điều phối, không lọc — không lọc theo miền, vai trò, tác vụ hay space. Điều này đáng biết trước khi bạn viết chính sách thứ hai mươi của mình, vì các chính sách tranh nhau cùng một cửa sổ ngữ cảnh với tác vụ. Đó cũng là lý do requiredRole trên một chính sách chỉ mang tính khuyến nghị: nó mô tả quy tắc nhắm tới ai, chứ không ngăn quy tắc đến với tất cả những người còn lại.

Miền

MemoryDomain nhóm các sự kiện và chính sách trong một không gian làm việc. Miền mang lại cấu trúc tổ chức cho tri thức và chúng là đơn vị mà các cấp quyền truy cập được viết dựa trên — nhưng hãy xem phần chú ý bên dưới trước khi coi một miền là ranh giới bảo mật.

Một miền hoặc là toàn không gian làm việc (architecture), hoặc gắn với một kho mã (repo:<slug>/architecture). Cùng một tên ở hai phạm vi là hai kho độc lập: một sự kiện đúng với một kho mã không ghi đè sự kiện toàn không gian làm việc. search_memory và phần mở đầu điều phối xếp bộ nhớ theo phạm vi kho mã lên trước khi agent đang làm việc trong kho mã đó; chúng không lọc phần còn lại ra. Hãy truyền repo vào propose_fact / propose_policy / search_memory để ghi vào hoặc đẩy hạng phạm vi đó.

Kiểm soát truy cập mở khi lỗi cho thao tác đọc

MemoryAccessGrant ánh xạ một vai trò agent và một miền vào một trong ba mức quyền:

Quyền	Ý nghĩa
none	Không có quyền truy cập
read	Có thể tìm kiếm và truy xuất sự kiện
write	Được propose_policy yêu cầu. Các thao tác ghi sự kiện (propose_fact, supersede_fact) không bị chặn bởi cấp quyền

Thiếu cấp quyền nghĩa là được đọc, chứ không phải bị từ chối

Khi không có dòng cấp quyền nào cho cặp (role, domain), quyền hiệu lực là read. Thao tác đọc được thiết kế theo kiểu mở khi lỗi. Thao tác ghi duy nhất ném lỗi là propose_policy khi không có quyền write (InsufficientMemoryPermission). Đặt nội dung nhạy cảm vào một miền bộ nhớ không hạn chế được ai có thể đọc nó, trừ khi bạn đã ghi tường minh một cấp quyền none cho mọi vai trò không nên thấy nó.

Hiện tại trong sản phẩm cũng không có giao diện nào để cấp quyền. Màn hình bộ nhớ chỉ có các tab Sự kiện, Chính sách và Đồ thị tri thức, không có gì khác; cấp quyền chỉ tiếp cận được qua các thao tác RPC memory_access_grant.*.

Sự bất đối xứng — dễ dãi với thao tác đọc, chặt chẽ với thao tác ghi chính sách — là một đánh đổi có chủ đích. Bộ nhớ hữu ích nhất khi nó luân chuyển, và việc từ chối đọc sẽ tạo ra một agent âm thầm biết ít hơn thay vì một agent báo lên vấn đề. Ngược lại, việc từ chối ghi chính sách thì ồn ào và có thể sửa được, nên đó là nơi đặt cơ chế thực thi. Một miền mới tạo được gieo sẵn quyền write cho mọi vai trò; siết lại sau đó là một chỉnh sửa chỉ qua RPC, vì không có giao diện cấp quyền.

Bộ nhớ làm việc

Mỗi agent có một AgentWorkingMemory: một bảng nháp văn bản tự do được đánh khóa theo không gian làm việc và agent. Nó tồn tại qua các lần chạy, là riêng tư với agent đó và được chèn vào prompt của agent ở mọi lần điều phối. Đây là nơi câu “tôi đang làm dở phần tái cấu trúc auth” nằm — trạng thái đáng mang sang lần chạy kế tiếp nhưng không đáng nâng cấp thành một sự kiện bền vững.

Điều gì thực sự đến được prompt của agent

Khi điều phối, phần mở đầu bộ nhớ được lắp ghép từ đúng ba thứ:

• Mọi chính sách đang hoạt động của không gian làm việc, dưới dạng các dòng - [domain] rule.
• Bộ nhớ làm việc của chính agent, nguyên văn.
• Một danh sách rút gọn các sự kiện khớp theo từ khóa cho tác vụ này — tối đa năm sự kiện, trong ngân sách khoảng 1.200 ký tự và chỉ khi phần mô tả tác vụ dài ít nhất 20 ký tự. Các tác vụ ngắn hơn không nhận sự kiện nào.

Danh sách rút gọn chỉ dùng FTS/từ khóa và bị giới hạn hạn mức là có chủ đích. Nhúng một truy vấn thì chậm, mà đường điều phối là nơi duy nhất độ trễ lộ ra ngay lập tức, nên đường ngữ nghĩa chậm được cố ý giữ ra ngoài. Phần mở đầu kết thúc bằng lời nhắc agent xác minh những mục then chốt bằng search_memory, nơi chứa toàn bộ mô hình truy hồi.

Trên đường này không có cấp quyền truy cập nào được tham vấn. Danh sách rút gọn tìm thấy gì thì agent thấy đúng thứ đó.

Truy hồi: một truy vấn, bốn tiếng nói

Công cụ search_memory dành cho agent có ba chế độ, và chúng thực sự là những tìm kiếm khác nhau:

• keyword — chỉ FTS5.
• semantic — kết quả BM25 và vector được hợp nhất bằng kết hợp hạng nghịch đảo.
• hybrid (mặc định) — truy hồi đa âm: bốn tiếng nói đã xếp hạng được hợp nhất với nhau, rồi đa dạng hóa.

Bốn tiếng nói là từ vựng (FTS), ngữ nghĩa (KNN vector), thời gian (các sự kiện đang hoạt động gần đây) và đồ thị — một bước duyệt hai chặng trên các cạnh tình tiết xuất phát từ những hạt giống từ vựng và ngữ nghĩa mạnh nhất. Tiếng nói đồ thị chính là lý do các cạnh tình tiết tồn tại ngay từ đầu: nó làm nổi lên sự kiện có liên quan đến câu trả lời của bạn mà không khớp với bất kỳ từ nào của bạn. Các tiếng nói được đánh trọng số theo ý định truy vấn đã được phân loại (mặc định ngữ nghĩa nặng nhất, rồi đến đồ thị và từ vựng, rồi đến độ mới), điểm của mọi ứng viên được co giãn theo suy giảm Weibull của nó, và tập kết quả được đa dạng hóa bằng MMR để năm cách diễn đạt lại cùng một sự kiện không chèn ép bốn sự kiện khác nhau.

Truy hồi ngữ nghĩa im lặng cho đến khi cài mô hình

Tiếng nói vector chỉ đóng góp sau khi mô hình embedding trên máy đã được tải về. Trước đó, truy hồi lai chạy với ba tiếng nói và không có việc điền bù hồi tố — các sự kiện được ghi trước khi cài mô hình sẽ không bao giờ có vector. Đường vector còn suy giảm thêm, thành một bước quét trong Dart trên các embedding đã đóng gói, nếu bản thân tiện ích mở rộng vector của SQLite không tải được; truy hồi vẫn trả lời, chỉ chậm hơn.

Tìm kiếm bộ nhớ trên desktop và web là một đường riêng, đơn giản hơn: thao tác RPC memory_fact.search chỉ dùng FTS5, vì một máy khách mỏng không thể gửi kèm embedding truy vấn và đường lai vẫn nằm trong máy chủ. Vậy nên thứ hạng bạn thấy trong trình duyệt bộ nhớ không phải thứ hạng mà agent nhận được từ search_memory. Đó là điều đã dự kiến, không phải lỗi, nhưng nó cũng có nghĩa “tôi đã tìm mà không thấy” trên giao diện không phải bằng chứng rằng agent cũng sẽ không thấy.

Bộ nhớ nằm ở đâu và ai ghi vào đó

Trình duyệt bộ nhớ nằm ở Cài đặt → Không gian làm việc → Bộ nhớ (/workspaces/<id>/settings/memory), với các tab Sự kiện, Chính sách và Đồ thị tri thức.

Ở đó có một sự bất đối xứng khiến người ta ngạc nhiên: bạn có thể sửa và xóa bộ nhớ, nhưng không thể tạo. Cả tab Sự kiện lẫn tab Chính sách đều không có nút thêm. Việc soạn thảo diễn ra ở phía agent, qua propose_fact và propose_policy (supersede_fact / supersede_policy để thay thế chúng). remember ghi một mục thuộc tầng nóng giới hạn theo phiên mà consolidate_memory có thể nâng cấp sau đó thành một sự kiện; record_observation và update_my_notes ghi bảng nháp riêng tư được chèn khi điều phối. Trình duyệt là bề mặt để xem lại và chỉnh sửa, không phải bề mặt soạn thảo — nên nếu bạn muốn có một sự kiện trong bộ nhớ, cách đưa nó vào là bảo một agent làm việc đó.

Hai thao tác bảo trì cũng do agent gọi chứ không chạy theo lịch: consolidate_memory hợp nhất và cắt tỉa các sự kiện tích lũy, còn harmonize_memory hòa giải những hiểu biết đã lệch nhau giữa các agent. list_memory_conflicts cho thấy những gì phát hiện xung đột đã ghi lại. Không có gì chạy chúng thay bạn theo bộ hẹn giờ. Các quyết định từ cuộc họp được thu hoạch vào miền decisions khi một bước lưu cuộc họp ghi lại chúng; đó không phải bộ hẹn giờ trên các lần chạy agent đã hoàn tất.

Khái niệm liên quan

• Mô hình agent: vai trò là thứ mà cấp quyền được viết dựa trên
• Không gian làm việc và cô lập: bộ nhớ có phạm vi không gian làm việc và nằm trong tệp cơ sở dữ liệu riêng của không gian làm việc đó
• Quản lý bộ nhớ không gian làm việc: làm việc với bộ nhớ trong thực tế