- Được cấu hình để nhiều AI agent cộng tác trong cùng một văn phòng, và nhấn mạnh luồng công việc hiển thị rõ ràng thông qua UI trình duyệt và cấu trúc nhóm theo vai trò, thay vì các lệnh gọi API ẩn
- Bộ nhớ được chia thành notebook theo từng agent và wiki dùng chung cho cả nhóm; ngữ cảnh công việc thô được giữ ở phía cá nhân, còn các sự thật đã được kiểm chứng và playbook lặp lại mới được đưa lên tri thức dùng chung
- Wiki mặc định không chỉ là một thư mục tài liệu đơn giản mà hoạt động như kho Git cục bộ, đồng thời cung cấp hệ công cụ ưu tiên file như typed facts, log append-only, brief do LLM tổng hợp,
/lookup, /lint
- Mỗi phiên được khởi tạo mới theo từng lượt, công cụ cũng bị giới hạn theo từng agent; kết hợp mô hình thực thi push-driven với prompt cache để duy trì lượng đầu vào phẳng bất kể độ dài phiên
- Kết nối cả Telegram, OpenClaw, One CLI và Composio để kéo tin nhắn và thực thi action từ bên ngoài vào, đồng thời vẫn gom bộ nhớ nhóm và cộng tác giữa các agent vào một không gian dựa trên mã nguồn mở self-hosting và việc dùng khóa API riêng
Cấu trúc bộ nhớ và wiki
- Tách riêng notebook theo từng agent và wiki dùng chung của nhóm, để quản lý ngữ cảnh công việc cá nhân và tri thức tổ chức ở các tầng khác nhau
- Notebook lưu ngữ cảnh thô, quan sát và kết luận tạm thời có được trong quá trình làm việc; chỉ những thông tin tồn tại lâu như playbook lặp lại, sự thật đã kiểm chứng và sở thích đã xác nhận mới được nâng cấp lên wiki
- Không có thông tin nào được tự động nâng cấp; agent phải tự quyết định mục nào sẽ được đưa từ notebook lên wiki
- Wiki chứa thông tin chỉ ra chủ thể đã ghi lại ngữ cảnh đó gần nhất, giúp các agent khác xác định cần mention lại ai
- Ở cài đặt mới, backend
markdown là mặc định; các workspace Nex hoặc GBrain hiện có sẽ giữ nguyên backend knowledge graph hiện tại
- Nếu chọn backend
none thì wiki dùng chung sẽ bị tắt, nhưng notebook cục bộ vẫn tiếp tục hoạt động
Cách wiki markdown hoạt động
- Wiki mặc định không phải chỉ là một thư mục Markdown đơn giản, mà vận hành như wiki nhóm dựa trên kho Git cục bộ tại đường dẫn
~/.wuphf/wiki/
- Nó bao gồm typed facts ở dạng triplet, log sự thật append-only theo từng entity, brief do LLM tổng hợp,
/lookup dựa trên trích dẫn, và /lint để tìm mâu thuẫn, tài liệu mồ côi, khẳng định đã cũ, hoặc tham chiếu chéo bị hỏng
- Brief do LLM tổng hợp được commit với danh tính
archivist, và có thể tận dụng nguyên trạng hệ công cụ ưu tiên file như cat, grep, git log, git clone
- Wiki mặc định này có thể dùng không cần khóa API
- Trong cách đặt tên nội bộ của mã nguồn, notebook là bộ nhớ
private, còn wiki là bộ nhớ shared; backend markdown và các backend nex·gbrain dùng bề mặt công cụ MCP khác nhau
- Bộ công cụ của backend
markdown và bộ công cụ legacy của nex·gbrain không cùng tồn tại trong một server instance
- Tài liệu chi tiết liên quan được nối tiếp trong
DESIGN-WIKI.md, docs/specs/WIKI-SCHEMA.md
Mô hình thực thi và các lựa chọn cấu hình
- CLI agent mặc định là Claude Code, và có thể chọn Codex CLI bằng
--provider codex
- Có thể chọn backend bộ nhớ giữa
nex, gbrain, none và markdown mặc định
- Ngay cả khi dùng
--no-nex, các tính năng tích hợp cục bộ như Telegram vẫn tiếp tục hoạt động, và sau khi chạy có thể quay lại chế độ ủy quyền định tuyến CEO bằng /focus
- Khi chọn
gbrain, quá trình onboarding ban đầu sẽ yêu cầu khóa OpenAI hoặc Anthropic; nếu cần embedding và vector search thì phải dùng OpenAI
- Các role pack được cung cấp gồm
starter, founding-team, coding-team, lead-gen-agency, revops
- Có thể điều chỉnh model, tự động mở trình duyệt, cổng, và kiểm tra quyền bằng các flag như
--opus-ceo, --no-open, --web-port, --unsafe
- Kho mã hiện ở trạng thái pre-1.0, nhánh
main có thể thay đổi hằng ngày, nên khi fork được khuyến nghị ghim theo release tag thay vì main
Cộng tác và tích hợp bên ngoài
- Hỗ trợ Telegram bridge; sau khi chạy
/connect trong văn phòng, có thể chọn Telegram và nhập token @BotFather để kết nối luồng tin nhắn hai chiều với nhóm hoặc DM
- Agent OpenClaw cũng có thể được đưa vào bằng
/connect openclaw, sử dụng URL gateway và gateway.auth.token trong ~/.openclaw/openclaw.json để bridge phiên
- Phiên OpenClaw được đưa vào văn phòng như một thành viên hạng nhất, có thể
@mention, còn việc thực thi thực tế vẫn tiếp tục trong sandbox riêng của chúng
- Xác thực gateway của OpenClaw dùng cặp khóa Ed25519, và khóa được lưu tại
~/.wuphf/openclaw/identity.json với quyền 0600
- Tích hợp sẵn hai nhà cung cấp để thực thi action bên ngoài là One CLI và Composio
- One CLI dùng binary cục bộ để thực thi action trên máy của người dùng, phù hợp với luồng không gửi thông tin xác thực cho bên thứ ba
- Composio dùng luồng OAuth được host của Composio để kết nối các tài khoản SaaS như Gmail, Slack
Lựa chọn thiết kế và đặc tính vận hành
- Các phiên được khởi tạo mới theo từng lượt, chọn cấu trúc không tích lũy lịch sử hội thoại
- Công cụ được giới hạn phạm vi theo từng agent; trong DM chỉ nạp 4 công cụ MCP, còn toàn bộ văn phòng nạp 27 công cụ
- Agent là mô hình push-driven chỉ thức dậy khi broker đẩy thông báo tới, nên không cần heartbeat polling
- Ngay cả trong lúc làm việc cũng có thể gửi DM cho một agent cụ thể để điều chỉnh giữa chừng mà không cần khởi động lại
- Có thể trộn lẫn runtime Claude Code, Codex, OpenClaw trong cùng một kênh
- Bộ nhớ kết hợp notebook theo từng agent với wiki của workspace, đồng thời cũng có thể chọn bộ nhớ dựa trên knowledge graph của
GBrain hoặc Nex
- Về chi phí, dự án nhấn mạnh mô hình mã nguồn mở miễn phí kết hợp giấy phép MIT, self-hosting và dùng khóa API riêng
- Trong phép đo phiên CEO 10 lượt dựa trên Codex, token đầu vào được giữ phẳng ở khoảng 87k mỗi lượt
- Token bị tính phí sau cache vào khoảng 40k mỗi lượt, tổng 10 lượt khoảng 286k
- Theo prompt cache của Claude API, hệ thống ghi nhận tỷ lệ cache hit 97%, và chi phí 5 lượt của Claude Code được ghi là
$0.06
- Trong khi bộ điều phối phiên tích lũy có đầu vào mỗi lượt tăng từ 124k lên 484k trong cùng một phiên, WUPHF vẫn duy trì lượng đầu vào phẳng bất kể độ dài phiên
- Sự khác biệt này được ghi là đo được chênh lệch 7 lần ở mốc 8 lượt
- Các đặc tính này gắn với fresh session, prompt caching dựa trên cùng tiền tố, số công cụ ít trong chế độ DM, và cấu trúc đánh thức push-driven không có heartbeat
- Script tái hiện được đề xuất là
wuphf --pack starter & rồi ./scripts/benchmark.sh, và mọi số liệu đều được đo trực tiếp trong môi trường cục bộ và bằng chính khóa của người dùng
Trạng thái triển khai và luồng kiểm chứng
- Với từng hạng mục chính trong README, có bảng claim status liên kết trực tiếp tới đường dẫn mã nguồn để phân biệt mục nào đã shipped và mục nào partial
- Các mục như CEO mặc định là Sonnet và được nâng cấp bằng
--opus-ceo, collaborative mode mặc định, chuyển đổi /focus, per-agent MCP scoping, fresh session, push-driven wake, cô lập workspace, Telegram bridge, 2 nhà cung cấp action, OpenClaw bridge, wuphf import, và mặc định --memory-backend markdown đều được đánh dấu shipped
- Live web agent streaming được đánh dấu partial, còn binary dựng sẵn dựa trên goreleaser được ghi là config ready
- Khôi phục công việc đang dang dở sau khi khởi động lại được ghi là shipped trong
v0.0.2.0
- LLM Wiki được đánh dấu shipped với git-native team memory và UI kiểu Wikipedia, đồng thời liên kết các vị trí triển khai liên quan như
internal/team/wiki_git.go, internal/team/wiki_worker.go, web/src/components/wiki/, DESIGN-WIKI.md
- Nếu claim và status xung đột thì mã nguồn được ưu tiên, và nếu tìm thấy vấn đề thì được hướng dẫn mở issue
Đánh giá và tài liệu demo
- Trước khi fork, dự án cung cấp một prompt fork-or-skip để đánh giá kho bằng trợ lý coding AI, yêu cầu đưa ra đường dẫn file, số dòng và kết luận trong dưới 500 từ, không dùng câu chữ marketing
- Prompt này được ghi là cũng được dùng nội bộ trước khi phát hành
- Để cho thấy luồng wiki thực sự được viết ra, dự án đưa ra demo terminal 5 phút là
./scripts/demo-entity-synthesis.sh
- Trong demo này, agent ghi lại năm sự thật, sau đó ngưỡng tổng hợp được kích hoạt, broker gọi LLM CLI cục bộ, kết quả được commit vào kho Git với danh tính
archivist, và toàn bộ chuỗi ghi chép được lưu trong git log
- Yêu cầu của demo là có
curl, python3, broker đang chạy với --memory-backend markdown, và một LLM CLI được hỗ trợ trong PATH giữa claude, codex, openclaw
1 bình luận
Ý kiến trên Hacker News
Tôi không thật sự hiểu điểm cốt lõi của việc tự động hóa ghi chú. Trước đây, kiểu sao chép rồi dán văn bản vào ghi chú vốn đã chẳng giúp ích gì, nên tôi không nghĩ tăng nó lên gấp 100 lần thì sẽ khác đi
Với tôi, cốt lõi của ghi chú là đọc nguồn một cách phản biện, tiêu hóa nó theo mô hình tinh thần của mình rồi ghi lại
Chi tiết thì sau này có thể tra lại, rốt cuộc điều quan trọng là quá trình mài giũa mô hình đó
Nếu vậy thì mục tiêu có thể là giao phần đó cho một LLM brain dùng chung, thay vì tự mình xây dựng mô hình tinh thần ấy
Tuy nhiên tôi khá hoài nghi việc cách tiếp cận này có thể tạo ra thứ gì thực sự có giá trị cho chủ sở hữu sản phẩm hay không. Nếu chỉ với prompt và agent harness là đã có thể tạo ra sản phẩm giá trị, thì ai cũng có thể làm lại sản phẩm đó, việc phát triển sản phẩm sẽ trở thành commodity và cuối cùng thứ còn giá trị có lẽ chỉ là token
Giả thuyết của tôi là do things that don’t scale của Paul Graham vẫn sẽ tiếp tục đúng, chỉ là nội dung của những việc không thể mở rộng ấy có thể sẽ thay đổi
Dù vậy, gần đây tôi cũng mới bắt đầu dùng Obsidian một cách bài bản. Tôi thiết lập các kỹ năng để ghi chú, nghiên cứu, liên kết, chia tách và tái cấu trúc cơ sở tri thức, nên có cảm giác như mình có một trợ lý số giúp sắp xếp mọi thứ
Giờ thì tôi chỉ cần ghi lại những ý nghĩ vụn vặt là agent sẽ tự dựng cấu trúc, đặt câu hỏi tiếp theo và nối nó với các công việc khác. Việc đọc nguồn và xây dựng mô hình tinh thần vẫn là do tôi làm, nhưng các ghi chú chất lượng cao thì gần như có được miễn phí
Thật sự rất lãng phí
Phần lớn mọi thứ vốn dĩ không cần phải vào ghi chú ngay từ đầu, còn LLM thì lại làm nhiễu tăng quá mức mà chẳng kiểm chứng hay lọc gì cho ra hồn
Có một video nói khá hay về chủ đề này từ bài luận của JA Westenberg
https://youtube.com/watch?v=3E00ZNdFbEk
Khá thú vị
Theo tôi, điểm tối ưu là con người tuyển chọn, và nếu không chủ động quản lý debt hay drift thì vận hành không giám sát không phải là câu trả lời
Nhất là cái tên lại trùng với sản phẩm vô dụng và thừa thãi Wuphf.com trong The Office
Có cảm giác chỉ cần gắn AI vào tên sản phẩm là hàng chục tỷ đô sẽ kéo đến, còn chỉ cần nhét Karpathy vào bài blog là có thể được tuyển làm kỹ sư cấp cao ở Anthropic
Trông như chỉ là những nỗ lực vắt tiền khi cơn sốt còn kéo dài, chứ không mấy quan tâm khách hàng thực sự cần gì
Ai cũng đang lao vào kiểu tranh thủ rửa tay khi còn có sóng
Dù vậy, hồi đó người ta vẫn thật sự xây được thứ gì đó, và môi trường gọi vốn chặt chẽ hơn khi ấy cũng phần nào kìm bớt sự quá nhiệt
Ít nhất thì cơn bùng nổ LLM lần này cũng có một mức độ khả thi và giá trị thực tế nào đó, đồng thời đây là công nghệ khá thú vị để học và vọc
Từ lâu tôi đã chấp nhận rằng khi tiền đổ vào một nơi như vậy, miễn không phi đạo đức, thì nên nắm lấy cơ hội ở đó. Khi dòng vốn VC/PE còn dồi dào, ta vẫn có thể tạo ra những thứ giá trị và hay ho
Tôi vẫn đang chờ một harness CLI đẳng cấp thế giới có thể thay thế Claude Code. Tôi cần thứ gì đó giải quyết được vấn đề bộ nhớ và vấn đề thiết kế
Thiết kế web thì với LLM hiện vẫn gần như ác mộng
Tôi cũng đã làm PoC cho doanh nghiệp, và tất cả những thứ đó cuối cùng cô đọng lại thành dự án này được xây cạnh bên để hỗ trợ chính công việc cá nhân của tôi. Kết quả là đây chính là giao diện thực sự dễ dùng cho context infra
Tôi không quan tâm đến vị trí kỹ sư cấp cao ở Anthropic. Trước đây tôi là Product Manager ở HubSpot và thu nhập tốt hơn bây giờ rất nhiều, và có lẽ trong vài năm tới tôi cũng chưa thể quay lại mức đó
Tôi đã đặt cược nhiều lần và liên tục chỉnh hướng vì sản phẩm tiến hóa qua việc nói chuyện trực tiếp với khách hàng. Trong khi đó, các đối thủ cũ vẫn còn đang stealth xây AI CRM
Với người ở lâu trong ngành như tôi, con sóng tự thân nó không quá quan trọng, nhưng tôi tin chắc là vẫn có giá trị thực chất để vớt lên từ dưới con sóng đó
Tôi đã xem bài review này: https://zby.github.io/commonplace/agent-memory-systems/reviews/wuphf/
Đây đã là wiki LLM thứ ba lên trang nhất trong vòng 24 giờ, nên rõ ràng là chủ đề đang rất nóng
Tôi cũng có lợi ích liên quan trong lĩnh vực này nên không hoàn toàn khách quan, nhưng tôi có ghi lại riêng những điều mình mong đợi ở các hệ thống kiểu này
https://zby.github.io/commonplace/notes/designing-agent-memory-systems/
Việc ai cũng tự xây lại hệ thống của riêng mình trông như một sự đầu tư trùng lặp quá lớn, nên tôi hy vọng sẽ có cách để hợp tác
Nhưng nhìn văn phong thì rõ ràng có vẻ là LLM viết, nên tôi tò mò không biết với những ghi chú thiết kế kiểu này bạn có thường viết lại sau đó bằng lời của chính mình để xác nhận rằng nó thật sự chứa suy nghĩ của bạn không
Chúng tôi khởi đầu là một công ty context infra tên là nex.ai từ rất lâu trước khi Karpathy nêu ra ý tưởng LLM wiki, và dù các khả năng đó vẫn chưa lộ ra nhiều trong WUPHF thì giờ chúng tôi đang dần công khai hơn
Khá nhiều lo ngại được viết trong bài so sánh là những thứ chúng tôi đã xử lý trong context infra mà mình xây từ trước, nên tôi rất vui khi thấy chúng được nêu ra
Dù vậy, việc hợp tác để giảm trùng lặp và chia sẻ những gì học được thì chúng tôi luôn sẵn sàng chào đón
Bạn nói là hy vọng có cơ hội hợp tác, nên nghe như thể hiện giờ không có cơ hội đó vậy, điều này khiến tôi thấy lạ
Chỉ cần chồng QMD lên một Obsidian vault là đã đạt cỡ 80%, mà chắc còn chưa tới 2 tiếng
Để có thêm ngữ cảnh thì đây là link bài gốc của Karpathy
https://x.com/karpathy/status/2039805659525644595
https://xcancel.com/karpathy/status/2039805659525644595
Tôi tò mò không biết AI Notes sẽ tạo ra giá trị hay chỉ thêm nhiễu
Dù vậy, tôi khá thích phong cách ASCII của website
Tôi muốn ai đó làm một thứ như sự hồi sinh của StackOverflow để giải quyết vấn đề này
Con người sẽ tuyển chọn, còn một tập thể các LLM sẽ giải bài toán và khi bị kẹt thì đăng câu hỏi theo kiểu cũ thành một đồ thị tri thức phân tán
Nếu agent của tôi nói kiểu “tôi bị kẹt ở đây, đã đăng câu hỏi lên SO rồi, khi nào có câu trả lời thì quay lại sau” thì như vậy cũng hoàn toàn ổn
Tôi tự hỏi phải làm sao để ngăn LLM viết quá nhiều
Tôi đã thử làm vài công cụ và hệ thống tương tự, và cái nào cũng để LLM liên tục phình tài liệu ra, cuối cùng khiến cả hệ thống thành một mớ hỗn độn và càng lớn thì càng kém hữu ích
Một thí nghiệm tôi từng làm trước đây là chỉ đưa vài liên kết để LLM tự nghiên cứu các chủ đề liên quan, tự tạo knowledge wiki của nó rồi sắp xếp tóm tắt, liên kết chéo và nguồn trên từng trang
Bề ngoài trông khá ổn, nhưng khi thật sự đọc dữ liệu thì không ổn lắm
Đó là thí nghiệm từ vài năm trước, nên có lẽ giờ thử lại với thứ như opus 4.7 cũng đáng
Để gợi thêm một hướng suy nghĩ thì cộng đồng TiddlyWiki đương nhiên cũng đã khám phá các công cụ AI
TiddlyWiki là một wiki dựa trên một tệp HTML duy nhất có thể tự sửa đổi, và đã tồn tại hơn 20 năm
Nó chưa hẳn đã tiến hóa theo hướng agentic, nhưng có plugin markdown, cũng có công cụ để làm cho tệp có thể thực thi hoặc biến nó thành webapp tự phục vụ. Git thì hơi khó chịu
Vì thế về mặt lý thuyết, một wiki agentic chỉ gồm một tệp có thể đi khắp nơi và tự chỉnh sửa chính nó là điều khả thi
https://tiddlywiki.com/
Cấu hình single-file mà bạn nói đến đã có vài connector LLM rồi. Ví dụ như https://github.com/rimir-cc/tw-llm-connect
Sức hút của nó đúng là nằm ở chỗ đó. Không phụ thuộc gì, không cần cài đặt, cực dễ lưu trữ, nên một wiki agentic một tệp tự chỉnh sửa chính nó hoàn toàn có thể làm được ngay hôm nay
Một thứ gần hơn với mẫu LLM Wiki của Karpathy là twillm mà tôi đang làm
https://github.com/Jermolene/twillm
Nó dùng cấu hình Node.js của TiddlyWiki, lưu tiddler dưới dạng từng tệp riêng lẻ để có thể trỏ thẳng vào một Markdown vault hiện có và dùng cùng các công cụ như Claude Code
Ưu điểm của TiddlyWiki cũng khá rõ ràng. Nó là mã nguồn mở nên có thể tiếp tục dùng lâu dài, và là nền web nên có thể truy cập từ bất cứ đâu
Ngoài ra, các khung nhìn được tính toán thay thế cho các tệp chỉ mục materialized. Cách của Karpathy yêu cầu LLM phải liên tục đồng bộ index.md mỗi khi thêm ghi chú, mà những thứ như vậy rất dễ bị stale khi đổi phiên, và đây lại đúng là kiểu việc LLM làm rất kém
Trong khi đó, các khung nhìn của TiddlyWiki là biểu thức lọc thời gian thực, nên ví dụ như “sắp xếp các tiddler có tag concept theo rating” sẽ được tính ngay tại thời điểm render
Frontmatter cũng trở thành một cấu trúc có thể truy vấn được. Obsidian hiển thị YAML frontmatter như một khối metadata ở đầu ghi chú, còn TiddlyWiki thì nâng các trường đó lên thành các trường tiddler hạng nhất để có thể dùng ngay cho lọc, sắp xếp và tổng hợp
Và LLM không chỉ có thể viết nội dung mà còn có thể viết cả những applet nhỏ. Ngoài ghi chú Markdown, nó còn có thể thêm các tiddler wikitext (.tid) để tạo ra các khung nhìn trực tiếp có tính tương tác như dashboard, công cụ duyệt tag, chỉ mục nhật ký hay bảng thuật ngữ
Lĩnh vực self building artefacts này rất thú vị, và gần đây đang bùng lên mạnh khi các LLM, đặc biệt là các model chuyên code, tiến bộ rất nhanh theo hướng này
Gần đây tôi cũng thử nghiệm một dự án tập trung vào việc giảm tối đa phụ thuộc và kiểm soát agent cục bộ
https://github.com/GistNoesis/Shoggoth.db/
Nó tự tạo và sắp xếp một cơ sở dữ liệu sqlite để thực hiện các tác vụ dài hạn được giao qua prompt, và dùng một bản Wikipedia cục bộ làm dữ liệu nguồn
Tôi cũng chỉ thêm vào mức tối thiểu các công cụ và harness để thử nghiệm agent drift
Việc gắn công cụ xử lý ảnh vào cũng khá dễ. Chỉ cần mã hóa ảnh sang base64 rồi đưa vào llama.cpp, còn phần hiện thực chi tiết thì có thể vibecoding tạm bằng LLM cục bộ
Tôi nghĩ đây là một công cụ khá hữu ích theo nghĩa tổng quát
Ví dụ, trước đây tôi có một script dùng Amazon Textract để trích số tiền, ngày tháng và nơi bán từ hóa đơn và biên lai trong thư mục, rồi sau đó con người kiểm lại các con số để tạo CSV đưa cho kế toán
Giờ thì có thể thay lệnh gọi Amazon Textract đó bằng một lệnh gọi model llama.cpp với prompt phù hợp, vẫn giữ nguyên công cụ hóa đơn cũ mà còn xử lý kế toán sáng tạo hơn nhiều
Tôi cũng đã thử một biến thể dùng chuỗi ảnh từ camera để điều khiển robot vật lý, và với các trường hợp đơn giản thì nó thật sự đã di chuyển và đến được mục tiêu
Tuy vậy, LLM tôi dùng vốn không hề được huấn luyện để lái robot, và lại mất tới 10 giây để chọn hành động tiếp theo nên không thực tế. Bộ điều khiển truyền thống hiện tại không dùng deep learning vẫn chạy vòng lặp thị giác ở 20Hz
Model LLM và các agent xây trên nó không mang tính quyết định mà mang tính xác suất
Chúng làm được việc với một tỷ lệ nhất định, nhưng không phải lúc nào cũng thành công
Vì vậy, agent càng kéo dài một công việc lâu thì xác suất thất bại cũng càng tăng. Những agent chạy dài kiểu này cuối cùng sẽ thất bại, và trong quá trình đó còn đốt một lượng token khổng lồ
Một trong những việc mà agent LLM làm tốt là tự viết lại chỉ thị của chính nó
Mẹo là giới hạn thời gian và số bước suy nghĩ của thinking model, rồi đánh giá, cập nhật và chạy lại
Nói ví von thì cứ xem agent như một kẻ hay vấp ngã. Đừng bắt nó chạy quá lâu để rồi ngã, 2 lần 5 phút còn hơn 1 lần 10 phút
Chỉ vài tuần nữa thôi, kiểu agent tự tham chiếu như vậy có lẽ sẽ chiếm đầy phần đầu feed Twitter
Vì thế những wiki kiểu này có nhiều khả năng sẽ đạt đến một trạng thái nào đó rồi dừng hẳn ở đó