Stash - Lớp bộ nhớ bền vững cho AI agent

 (alash3al.github.io)
1 điểm bởi GN⁺ 7 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Một lớp bộ nhớ bền vững giúp duy trì mạch hội thoại và ngữ cảnh công việc ngay cả khi phiên làm việc thay đổi, bằng cách lưu các quan sát thô dưới dạng episodes rồi tích lũy thành tri thức có cấu trúc
  • Sử dụng kiến trúc độc lập với mô hình, nên có thể gắn cùng một lớp bộ nhớ cho Claude, GPT, LLM cục bộ và cả agent tùy biến; lớp lưu trữ vận hành trên PostgreSQL và pgvector
  • Đảm nhiệm vai trò khác với RAG: không chỉ dừng ở truy xuất tài liệu, mà còn tích lũy các sự kiện mới, quan hệ, mục tiêu, thất bại và giả thuyết từ hội thoại, đồng thời có thể dùng cùng RAG
  • Tách riêng người dùng, dự án và tri thức tự thân của agent bằng namespace và đường dẫn phân cấp; pipeline consolidation liên tục tổng hợp facts, relationships, causal links, patterns, contradictions
  • Bao gồm tích hợp MCP native, mô hình tự thân dựa trên /self, và cả vòng lặp nghiên cứu lặp lại để biến các agent dạng phiên không có ký ức thành các thực thể làm việc có tính liên tục dài hạn

Tổng quan về Stash

  • Một lớp bộ nhớ bền vững nằm giữa AI agent và thế giới bên ngoài, giúp tiếp nối ngữ cảnh trước đó ngay cả khi phiên làm việc thay đổi
  • Lưu các quan sát thô thành episodes, rồi tích lũy chúng thành tri thức có cấu trúc như facts, relationships, patterns, goals, failures, hypotheses
  • Không thay thế chính mô hình mà tăng cường tính liên tục, được thiết kế để gắn vào bất kỳ agent nào như Claude, GPT, mô hình cục bộ, v.v.
  • Nền tảng lưu trữ sử dụng PostgreSQL + pgvector
  • GitHub

Cách tổ chức bộ nhớ

  • Dùng namespace để tách riêng các bộ nhớ như người dùng, dự án, và tri thức tự thân của agent
  • Mỗi namespace được tổ chức theo đường dẫn phân cấp; khi đọc /projects sẽ bao gồm cả các đường dẫn con như /projects/stash, /projects/cartona
  • Ghi dữ liệu chỉ diễn ra vào đúng một namespace cụ thể để ngăn ô nhiễm bộ nhớ
  • Bộ nhớ liên quan đến người dùng, bộ nhớ dự án và tri thức tự thân dưới /self được giữ không trộn lẫn với nhau
  • Ví dụ cấu trúc gồm /users/alice, /projects/restaurant-saas, /projects/mobile-app, /self/capabilities, /self/limits, /self/preferences

Khác biệt với RAG

  • RAG gần với một lớp truy xuất dùng để tìm nội dung liên quan trong tài liệu, chứ không ghi nhớ hay học từ chính cuộc hội thoại
  • RAG chỉ có thể xử lý những gì đã có trong tài liệu và không thể tạo ra tri thức mới từ hội thoại
  • Theo dõi mục tiêu, hiểu ý định, phát hiện mâu thuẫn theo thời gian, hay suy luận nhân-quả được xem là nằm ngoài phạm vi của RAG
  • Stash tự động học từ hội thoại, quyết định, thành công và thất bại, đồng thời dần xây dựng đồ thị tri thức
  • Truy xuất tài liệu và ghi nhớ trải nghiệm giải quyết hai vấn đề khác nhau, nên có thể dùng RAG cùng Stash

Điểm khác so với bộ nhớ AI hiện có

  • Claude.ai và ChatGPT cũng có bộ nhớ, nhưng tính năng đó bị ràng buộc với nền tảng và mô hình riêng của chúng
  • Stash hoạt động độc lập với mô hình, nên có thể gắn vào cả mô hình cục bộ và mô hình riêng tư
  • Quyền sở hữu dữ liệu thuộc về phía người dùng và dự án được cung cấp dưới dạng mã nguồn mở
  • Bao gồm các thành phần như consolidation nền, theo dõi goals và intent, học từ failures, causal reasoning, và self-model của agent
  • Theo bảng so sánh, ChatGPT Memory và Claude.ai Memory là “notepad”, còn Stash được phân loại là “mind”

Vấn đề mà Stash muốn giải quyết

  • Các mô hình AI hiện nay dù suy luận tốt nhưng thiếu ký ức xuyên phiên, khiến người dùng phải giải thích lại bản thân và bối cảnh dự án mỗi lần
  • Cách nhét toàn bộ lịch sử hội thoại vào prompt mỗi lần là chậm và tốn kém, đồng thời vẫn bị giới hạn bởi context window
  • Thiếu một cơ chế truyền bài học để ngăn việc lặp lại các thử nghiệm thất bại ở phiên sau
  • Tính năng bộ nhớ chỉ có trên một số nền tảng nhất định, khiến agent tùy biến hay LLM cục bộ phải bắt đầu mà không có ngữ cảnh từ đầu

Pipeline tích hợp

  • Một tiến trình nền liên tục tổng hợp trải nghiệm để biến bộ nhớ thô thành tri thức có cấu trúc
  • Ở giai đoạn Episodes, các quan sát được lưu theo kiểu append-only
  • Ở giai đoạn Facts, các nhóm episode được LLM tổng hợp lại
  • Ở giai đoạn Relationships, các quan hệ thực thể giữa các fact được trích xuất
  • Ở giai đoạn Causal Links, các cặp nguyên nhân-kết quả giữa các fact được liên kết
  • Ở giai đoạn Patterns, các mẫu trừu tượng ở mức cao hơn được rút ra
  • Ở giai đoạn Contradictions, hệ thống thực hiện tự hiệu chỉnh và confidence decay
  • Goal Inference tự động theo dõi các fact liên quan đến mục tiêu đang hoạt động, đồng thời làm lộ ra tiến độ và xung đột
  • Failure Patterns phát hiện lỗi lặp lại và trích xuất chúng thành fact mới để giảm việc lặp lại cùng một thất bại
  • Hypothesis Scan cho phép bằng chứng mới xác nhận hoặc bác bỏ các giả thuyết đang mở mà không cần can thiệp thủ công

Tích hợp MCP

  • Hoạt động theo kiểu MCP native, có thể gắn vào Claude Desktop, Cursor, OpenCode, agent tùy biến, LLM cục bộ và các MCP client khác
  • Có thể kết nối mà không cần SDK và cho phép dùng cùng một lớp bộ nhớ ở bất cứ đâu mà không bị vendor lock-in
  • Cung cấp tổng cộng 28 công cụ, gồm remember, recall, forget, init cho đến causal links, contradictions, hypotheses
  • Có thể khởi động đồng thời máy chủ MCP stdio và consolidation bằng ./stash mcp execute --with-consolidation
  • Có thể chạy máy chủ SSE cho agent từ xa bằng ./stash mcp serve --port 8080 --with-consolidation

Mô hình tự thân của agent

  • Khi gọi init, hệ thống tạo bộ khung namespace /self để bắt đầu xây dựng mô hình tự thân
  • /self/capabilities ghi nhớ những việc agent làm tốt để dùng trong lập kế hoạch công việc
  • /self/limits lưu lịch sử thất bại và điểm yếu để ngăn lặp lại cùng một sai lầm
  • /self/preferences học cách vận hành hiệu quả nhất để dần hình thành phong cách làm việc dài hạn

Vòng lặp tự học

  • Khi chạy research loop theo chu kỳ 5 phút, hệ thống lấy ngữ cảnh hiện tại từ bộ nhớ quá khứ, tự chọn chủ đề để nghiên cứu, tạo kết nối mới, hợp nhất lại rồi kết thúc
  • Ở bước Orient, hệ thống gọi lại ngữ cảnh quá khứ, mục tiêu đang hoạt động, giả thuyết đang mở và các thất bại trước đó
  • Ở bước Research, agent thực hiện tìm kiếm web với chủ đề do chính nó chọn
  • Ở bước Think, hệ thống làm lộ ra các căng thẳng, khoảng trống và mâu thuẫn trong những gì hiện biết
  • Ở bước Invent, hệ thống tạo ra các đầu ra mới như giả thuyết, mẫu hình và phát hiện
  • Ở bước Consolidate, pipeline được chạy để tổng hợp raw episode thành tri thức có cấu trúc
  • Ở bước Reflect + Sleep, hệ thống để lại tóm tắt phiên, thiết lập ngữ cảnh cho lần chạy tiếp theo rồi dừng lại
  • Xem prompt của vòng lặp

Tương thích mô hình và hạ tầng

  • Giả định một cấu hình provider duy nhất dùng API tương thích OpenAI cho cả embedding lẫn reasoning
  • Hỗ trợ cấu hình cloud, local và self-hosted, đồng thời khẳng định không có vendor lock-in
  • Tác giả cho biết đang kết nối OpenRouter tại local để có thể truy cập hàng trăm mô hình bằng một API key duy nhất
  • Cũng hoạt động trực tiếp với Ollama, cho phép dựng bộ nhớ offline bằng các mô hình cục bộ như Qwen, Llama, Mistral
  • Các backend dùng định dạng OpenAI API như vLLM, LM Studio, llama.cpp server, Together AI, Groq cũng được liệt kê là hỗ trợ
  • Mô hình embedding mặc định là openai/text-embedding-3-small, và với tổ hợp đó dùng STASH_VECTOR_DIM=1536
  • STASH_VECTOR_DIM chỉ có thể thiết lập trước lần chạy đầu tiên; nếu đổi sau khi khởi tạo sẽ phải reset toàn bộ cơ sở dữ liệu

Thông tin triển khai và sử dụng

  • Cung cấp cấu hình Docker Compose để khởi chạy cùng lúc Postgres, pgvector và Stash
  • Quy trình chạy được mô tả trong 3 bước: clone kho mã, sao chép .env.example thành .env rồi thiết lập API key và model, sau đó chạy docker compose up
  • Sau lần khởi chạy đầu tiên, trạng thái mong đợi là postgres + pgvector sẵn sàng, migration đã áp dụng, máy chủ MCP đang chờ, và consolidation nền đang chạy
  • Dự án được công bố theo giấy phép Apache 2.0
  • GitHub Repository
  • alash3al.com

Bài viết liên quan

1 bình luận

 
GN⁺ 7 giờ trước
Ý kiến trên Hacker News

  • Tôi đã bấm vào vì tưởng cuối cùng cũng có thứ kiểu hệ thống bộ nhớ của Claude.ai nhưng làm được theo kiểu portable, hóa ra hoàn toàn không phải vậy
    Cái ở đây chỉ là kiểu store/remember, còn thứ tôi thấy tốt hơn là cách một mô hình nền tóm tắt lịch sử chat để tạo ra bộ nhớ
    Bên đó hoạt động tốt hơn nhiều vì mô hình không phải tự viết bộ nhớ, nên việc giới thiệu cái này như cùng đẳng cấp với Claude.ai có vẻ hơi misleading
    Tôi cũng đang vẫn tìm một hệ thống bộ nhớ kiểu đó để chuyển sang phía LibreChat nhưng vẫn chưa thấy, và hiện gần như lý do duy nhất khiến tôi còn ở lại Claude.ai là tính năng đó
    Tham khảo thêm thì hệ thống đó chỉ có trên Claude.ai chứ không có trong Claude Code

    • Theo vụ Claude Code leak gần đây thì có thứ gọi là autoDream, ở đây được mô tả là background memory consolidation engine: https://kuber.studio/blog/AI/Claude-Code's-Entire-Source-Code-Got-Leaked-via-a-Sourcemap-in-npm,-Let's-Talk-About-it
    • Tôi thật sự muốn thử cách tiếp cận đó
      Trải nghiệm của tôi lại hoàn toàn ngược lại, tôi chủ yếu làm https://github.com/flippyhead/ai-brain cho chính mình dùng, và vài người bạn cũng dùng
      Đến giờ thì cách để AI dùng CLAUDE.md nhằm tìm các ký ức liên quan và tự cân nhắc khi nào, bằng cách nào nên lưu lại đang hoạt động khá tốt
      Cách này có thể tạo cấu trúc theo mức độ ưu tiên và còn để lại ghi chú cho tương lai, nên cảm giác khá khác với kiểu chỉ tóm tắt tất cả
    • Tôi thích kiểu tự động recall diễn ra mà agent không nhìn thấy
      Việc tạo bộ nhớ bằng tool call cũng hoạt động khá ổn, và tôi cũng thấy cách tự động tạo bộ nhớ khi nén ngữ cảnh là chấp nhận được
      Chỉ là nếu đã tự động tạo thì cần consolidation bất đồng bộ, và gọi nó là dreaming thì có hơi cường điệu
      Phần triển khai của tôi nằm trong Elroy.bot, và tôi đã tổng hợp nhiều cách tiếp cận ở đây: https://tombedor.dev/approaches-to-agent-memory/
    • Tôi tò mò không biết họ benchmark chuyện đó như thế nào
      Nếu trích xuất bộ nhớ ở nền thì vấn đề là khó phối hợp tốt với prefix cache
      Chỉ với một LOG.md hai tầng đơn giản (log chi tiết công việc và bài học) + MEMORY.md (ghi lại các mục được nâng cấp khi log bị cắt bớt) + stop hook chạy ở cuối lượt là cũng đi được khá xa rồi
    • Khái niệm này khá thú vị
      Nó giống như phía sau một agent đang nói chuyện với người dùng có các trợ lý đang nghe lén cuộc trò chuyện, ghi lại các sự kiện quan trọng hoặc tìm các dữ kiện liên quan trong DB rồi chen vào kiểu ký ức X này có vẻ liên quan đấy
      Nếu token là miễn phí thì có vẻ dễ, nhưng làm cho nó hiệu quả lại là một bài toán khá thú vị

  • Những dự án hứa hẹn điều gì đó nhưng gần như không tiết lộ cách triển khai thì lúc nào cũng là một red flag lớn
    Đào sâu hơn thì về cơ bản nó là pg_vector gắn với mcp, cùng hai hàm recall/remember
    Cuối cùng thì nó gần với RAG, và dù có thể lập luận rằng cấu trúc dữ liệu là quan trọng, nhưng hầu như mọi hệ thống bộ nhớ kiểu này từ trước đến nay đều hoạt động na ná nhau
    Tôi vẫn chưa thấy trường hợp nào chứng minh được tìm kiếm của nó tốt hơn vector DB search cơ bản

    • Website thì đẹp, ghi là memory, và cho thấy LLM thì tệ nhưng sản phẩm này giải quyết được mọi thứ như phép màu
      Nếu nó thật sự làm được vậy thì rốt cuộc nó cũng khá giống việc gói lại một vectordb cho đẹp hơn thôi

  • Đã có bài review ở đây: https://zby.github.io/commonplace/agent-memory-systems/reviews/stash/
    Nhiều LLM memory systems khác cũng được tập hợp ở đây: https://zby.github.io/commonplace/agent-memory-systems/
    Và ở đây cũng có tổng hợp những điều người ta mong đợi ở các hệ thống kiểu này: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/

  • Mấy agent memory systems kiểu này vừa có vẻ bị thiết kế quá mức, vừa có vẻ lại chưa được thiết kế đủ, và trông khá giống ngõ cụt
    Tôi khó hình dung được một hiện thực mà nó không nhanh chóng lệch khỏi nhu cầu của các mô hình mới nhất rồi mục ruỗng đi
    Ví dụ chỉ vì đã từng làm tính năng thanh toán một lần mà về sau nhiều phiên cứ bị nghiêng về hướng thanh toán do có ký ức kiểu don't use stripe

    • Tệ hơn nữa là có vẻ chính tác giả cũng gần như chưa tự dùng nó
      Đây là một memory layer hoàn toàn chưa được kiểm chứng, cảm giác như chỉ dựng một trang marketing hào nhoáng với những tuyên bố phóng đại mà không có ảnh chụp sử dụng thực tế nào
    • Tôi xem đây là một vấn đề thông tin, và đã làm một tiện ích nhỏ có chủ đích là không lưu phần lớn mọi thứ: https://github.com/skorokithakis/gnosis
      Tiền đề rất đơn giản. Những gì LLM vốn đã biết thì nó sẽ tiếp tục biết, nên tôi không lưu những gì LLM đã nói; còn nội dung liên quan tới code thì cứ để trong code và comment là được
      Thay vào đó, có những thứ không thuộc cả hai nhóm nhưng lại tuyệt đối không được ghi lại
      Khi xây dựng thứ gì đó, thường những gì đã quyết định không làm còn quan trọng hơn những gì thực sự đã làm, và tiện ích này bắt các phương án bị loại ở cuối phiên cùng với lý do, rồi lưu chúng thành system knowledge
      Cuối cùng mục tiêu là giữ lại loại thông tin không thể tìm ra chỉ bằng grep trong code, mà thường chỉ nằm trong đầu đồng đội; đến giờ nó hoạt động khá ổn nhưng vẫn còn sớm
    • Tôi dùng một hệ thống bộ nhớ may đo tự làm, và tránh vấn đề này bằng cách biến mọi ký ức thành không gian tìm kiếm theo từng ngữ cảnh
      Những ký ức như don't use stripe chỉ được đưa vào ngữ cảnh khi mô hình nhận prompt làm việc liên quan tới payment processing

  • Tôi đã tìm mấy thứ như thế này một thời gian, và cũng vui khi thấy tài khoản này đã công khai phần mềm từ trước thời bùng nổ LLM
    Tuy vậy, tôi muốn mỗi dự án đều có thứ kiểu lịch sử sử dụng LLM
    Sẽ tốt nếu có thông tin về việc có dùng LLM để tạo ra hay không, nếu có thì dùng bao nhiêu, ở giai đoạn nào, đầu ra đã được rà soát kỹ tới mức nào, và người làm có cảm thấy chất lượng ít nhất ngang hoặc tốt hơn so với tự làm một mình không
    Không phải vì nghi ngờ cá nhân cụ thể nào, mà tôi muốn đó là thông tin chung cho mọi dự án, và bản thân tôi cũng định làm vậy

    • Thành thật mà nói thì cái này nghe hơi entitled
      Chẳng ai ép ai phải dùng dự án này cả, cứ tự đọc và xem xét code rồi quyết định dùng hay không là được
    • Bản thân câu hỏi là hợp lý, nhưng tôi không nghĩ có thể để người trong cuộc trả lời chỉ bằng tự khai
      Có vẻ sẽ không nhiều người thành thật thừa nhận rằng họ gần như không thiết kế, không test, và chất lượng code cũng kém
      Có khi lại cần một hệ thống bên thứ ba để trả lời những câu hỏi kiểu này, dù tất nhiên nếu nó cũng dựa trên LLM thì có thể khá chủ quan
    • Có rất nhiều cách khác nhau để làm phần mềm với LLM
      Dạo này tôi vận hành hầu hết dự án của mình xoay quanh nhiều file Markdown, dùng AI để nghiên cứu trước, lập kế hoạch và theo dõi tiến độ triển khai
      Việc triển khai được làm từng bước theo kế hoạch và cũng được rà soát liên tục ở mỗi bước
      Nếu bắt tôi tài liệu hóa workflow của mình thì chính các file đó là tài liệu ấy
      99% code là do sinh ra, nhưng tôi chú ý để nó được sinh theo cách tôi hài lòng, và kết quả nhiều khi còn tốt hơn lúc tôi tự làm một mình
    • Tôi không hiểu vì sao điều đó lại quan trọng
      Phần mềm tốt lẫn phần mềm tệ đều có thể được tạo ra cả khi không dùng LLM lẫn khi dùng LLM
      Người ta đâu có hỏi thợ mộc đã dùng búa hay nail gun, hoặc dùng cái nào cho mái nhà và cái nào cho sàn gỗ
      Nếu không có nền tảng tin cậy thì cuối cùng bạn vẫn phải tự kiểm chứng chất lượng hoặc tự làm lấy, ngoài ra thì chỉ là một dạng kỳ vọng pha chút hy vọng mà thôi

  • Tôi vẫn chưa tìm được memory nào dùng ra hồn
    Một kiểu là chỉ để lại tóm tắt cấp cao như agents.md, nhưng như vậy lại chẳng giúp mấy cho các chi tiết cụ thể, ví dụ như nếu sửa phần tử này thì phải đánh dấu phần tử kia là draft
    Ngược lại, kiểu quá chi tiết thì hoặc là chi tiết quá mức nên bị bỏ qua, hoặc là làm các chi tiết của một vùng tính năng lây nhiễm sang cả thay đổi ở vùng khác
    Rốt cuộc đến giờ thứ hiệu quả nhất với tôi vẫn là không dùng bộ nhớ, mà chỉ chọn thủ công những ngữ cảnh quan trọng cho phiên/prompt đó

    • Tôi khá quan tâm tới bộ nhớ, nhưng ít nhất với công cụ phục vụ coding thì tôi không thấy nó hữu ích lắm
      Source of truth về việc repository làm gì và nên làm gì rốt cuộc vẫn là repo itself
      Điều bạn nói nghe giống guideline review code hơn, và những thứ như vậy thì cứ đưa tường minh vào ngữ cảnh đúng lúc có thay đổi là được
      So với vậy thì hệ thống bộ nhớ vừa quá phức tạp vừa kém chính xác
    • Wishlist cho các hệ thống kiểu này ở đây: https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
    • Tôi cũng có cảm giác tương tự
      Tôi tự hỏi liệu một lúc nào đó các mô hình kiểu này có continual learning hay không
      Chúng đã đủ thông minh rồi, nhưng lại không có bộ nhớ thực sự nên cảm giác rất bất tiện khi làm việc cùng
    • Những bộ nhớ mà Claude tạo ra gần như toàn là kiểu remember-to-not-forget, nên cuối cùng tôi đã tắt hẳn tính năng đó

  • Với tôi thì vài thứ đơn giản hoạt động khá tốt, công cụ ở đây là Codex

    1. Một functional specification chi tiết luôn được cập nhật
    2. Codebase được cấu trúc thành nhiều project
    3. Code có naming tốt và được tài liệu hóa. Tên class, biến, hàm có dài hay trông ngớ ngẩn đến đâu cũng phải làm rõ mục đích, và các quy tắc này được đưa vào guideline coding trong Agent.md
      Functional spec của tôi đóng vai trò Project.md đối với agent
      Và trước mỗi lần review code theo kiểu agentic, tôi tạo cây thư mục project, rồi gộp nó với codebase thành một file duy nhất và gắn timestamp vào tên file
      Việc này quan trọng hơn tưởng tượng, vì nó giúp giảm việc LLM tham chiếu nhầm phiên bản cũ, đồng thời cũng tiện để xem diff nhanh mà không cần gửi cả git
      Tới giờ workflow đơn giản này hoạt động khá tốt ngay cả với những codebase lớn và phức tạp
      Không hiệu quả về token lắm nhưng đơn giản là nó chạy tốt
      Không cần lần nào cũng phải gộp toàn bộ codebase; có thể bỏ các project đã xong, đã test, hoặc không liên quan đến công việc hiện tại
      Dù vậy tôi vẫn đưa chúng vào printed directory tree để agent ít nhất biết chúng tồn tại và có thể yêu cầu file cụ thể nếu cần
    • Cách tiếp cận thú vị đấy
      Tôi tò mò không biết anh làm việc gộp đó như thế nào
      Làm thủ công, chỉ gộp các file đã thay đổi, hay là kiểu lai?

  • LLM memory nghe thì hay trên lý thuyết, nhưng thực tế càng lớn thì lại càng bừa bộn gần như lúc chạy không có bộ nhớ
    Ngay cả ví dụ ở màn hình đầu như hãy tiếp tục làm dự án của tôi thì trong thực tế hiếm ai chỉ làm một dự án
    Có thể có 5 hay 10 dự án nằm trong bộ nhớ, và mỗi cái ở thời điểm lưu đều từng có ý nghĩa
    Cuối cùng bạn vẫn phải chỉ định lại kiểu hãy tiếp tục dự án sass, đổi lại chỉ nhận thêm được chút ngữ cảnh chi tiết nhưng phải lấp đầy LLM context và còn tốn thêm chi phí MCP calls

    • Đúng là vậy, nhưng đây là một naive implementation quá mức
      Nếu triển khai tử tế thì có thể vượt qua những giới hạn đó
    • Rồi khi bạn bắt đầu chỉ định cụ thể phải nhớ cái gì, thì thực ra gần như chẳng khác mấy việc bảo AI write/read vào file

  • Tôi tự hỏi liệu cái này có phải chỉ dành cho vibecoder làm việc một mình không
    Khi làm dự án thực với người thật thì hệ thống này không thể có toàn bộ ký ức của cả dự án, mà bản thân tôi cũng đâu có toàn bộ ký ức đó
    Chỉ cần PR khác được merge là những gì tôi nhớ đã lập tức cũ đi, và thứ tôi quan tâm chỉ là ticket của mình
    Nên tôi ngày càng cảm thấy mấy thứ này có lẽ không phải công cụ cho kiểu làm việc cộng tác như vậy

  • Thật ngạc nhiên là dù chi phí làm phần mềm giờ gần như tiệm cận 0, người ta vẫn cố bán thứ này bằng một trang marketing vibe-coded
    Không rõ ai sẽ có thời gian dùng thử cái này rồi chờ vài tuần, vài tháng để xác minh xem nó có thực sự hiệu quả không
    Trên site không có bằng chứng nào cho thấy nó tốt hơn RAG hay tốt hơn việc chỉ có một thư mục file bộ nhớ cộng với grep
    Vậy mà vẫn toàn là những tuyên bố trên mây, còn trang thì cuộn giật ở mức 14fps
    Trông như được code trong 24 giờ trước, thành thật mà nói cảm giác quá lười biếng