AI & Automation (vnROM): Duy Nghiện

/dreaming trong OpenClaw version 2026.4.5

Duy Nghiện — Tue, 07 Apr 2026 05:30:19 +0000

OpenClaw vừa phát hành phiên bản 2026.4.5, đánh dấu một bước tiến lớn trong khả năng quản lý bộ nhớ dài hạn cho các AI agent tự vận hành. Trong bản cập nhật này, tính năng /dreaming (trước đây chỉ là experimental) đã trở thành hiện thực đầy đủ, được tích hợp sâu vào plugin memory-core. Đây là hệ thống củng cố bộ nhớ nền (background memory consolidation) hoạt động theo cơ chế “giấc ngủ” của con người, giúp agent không chỉ lưu trữ mọi thứ mà còn tổ chức, tinh chỉnh và thúc đẩy các tín hiệu quan trọng từ bộ nhớ ngắn hạn lên bộ nhớ dài hạn một cách có hệ thống và minh bạch.

Nó giải quyết vấn đề cốt lõi của hầu hết các agent AI hiện nay: bộ nhớ chỉ “tích tụ” mà không được tổ chức, dẫn đến noise, lãng phí token và giảm hiệu suất theo thời gian.

// Detect dark theme var iframe = document.getElementById('tweet-2040998570317197607-717'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2040998570317197607&theme=dark" }

1. /dreaming là gì?

Dreaming là hệ thống củng cố bộ nhớ opt-in (tùy chọn bật), chạy ngầm theo lịch cron. Nó mô phỏng chu kỳ giấc ngủ của con người với ba giai đoạn hợp tác (Light → REM → Deep) để:

Phân loại và dọn dẹp dữ liệu ngắn hạn.
Trích xuất chủ đề, suy ngẫm và ghi nhật ký giấc mơ.
Đánh giá, xếp hạng và thúc đẩy nội dung giá trị cao vào bộ nhớ dài hạn.

Tất cả đều minh bạch (explainable): bạn có thể đọc được mọi quyết định qua file markdown và giao diện Dreams UI. Không có pruning (xóa bỏ) tự động - bộ nhớ chỉ phát triển, nhưng được tổ chức thông minh hơn.

2. Ba giai đoạn hoạt động (Light - REM - Deep)

Hệ thống chạy theo thứ tự cố định trong một lần sweep (quét):

Giai đoạn	Mô tả chi tiết	Đầu ra
Light	Sắp xếp, dọn dẹp và khử trùng lặp (deduplicate) dữ liệu ngắn hạn từ recall traces + daily memory files. Ghi nhận tín hiệu củng cố. Không ghi vĩnh viễn.	Không ghi durable
REM	Phản ánh chủ đề, ý tưởng lặp lại. Tạo narrative summaries và reinforcement signals.	Dream Diary (nhật ký giấc mơ)
Deep	Xếp hạng và promote (thúc đẩy) các candidate chất lượng cao vào MEMORY.md. Sử dụng mô hình điểm số có trọng số.	MEMORY.md (bộ nhớ dài hạn)

Deep Ranking Signals (mô hình chấm điểm):

Frequency (0.24), Relevance (0.30), Query diversity (0.15), Recency (0.15), Consolidation (0.10), Conceptual richness (0.06).

Các giai đoạn Light/REM còn bổ sung boost nhỏ qua phase-signals.json.
Dreaming không ghi trực tiếp vào MEMORY.md từ Light hay REM - chỉ Deep mới promote.

3. Những gì Dreaming ghi lại?

DREAMS.md: Nhật ký giấc mơ (Dream Diary) + tóm tắt từng phase (Light Sleep, REM Sleep, Deep Sleep). Đây là file con người đọc được, nằm ở root và không được đưa vào recall mặc định để tránh noise.
memory/.dreams/: Thư mục hệ thống chứa recall store, phase signals, checkpoints, locks.
MEMORY.md: Chỉ nhận nội dung được Deep promote (replay-safe, không trùng lặp).
Báo cáo phase tùy chọn: memory/dreaming/<phase>/YYYY-MM-DD.md.

4. Cách kích hoạt và cấu hình cũng rất đơn giản

Chỉ cần chỉnh file openclaw.json:

{
  "plugins": {
    "entries": {
      "memory-core": {
        "config": {
          "dreaming": {
            "enabled": true,
            "frequency": "0 3 * * *",
            "timezone": "Asia/Ho_Chi_Minh"
          }
        }
      }
    }
  }
}

enabled: false mặc định → bật lên là chạy ngay.
Lịch cron linh hoạt (mỗi 3 giờ sáng hàng ngày…).
Sau khi chỉnh, restart memory-core hoặc gateway (openclaw gateway restart)

5. Công cụ kiểm soát và Dreams UI

Slash command trong chat:
- /dreaming status
- /dreaming on / /dreaming off
- /dreaming help
CLI tools:
- openclaw memory promote (preview + --apply)
- openclaw memory promote-explain "deployment workflow" (giải thích tại sao một chủ đề được promote)
- openclaw memory rem-harness (preview REM)
- openclaw memory status --deep
Dreams UI (mới trong 2026.4.5): Tab riêng trong Gateway (Ctrl + I). Hiển thị:
- Trạng thái dreaming
- Số lượng short-term/long-term/promoted today
- Thời gian sweep tiếp theo
- Dream Diary reader (có animation lobster dễ thương)

6. Lợi ích thực tế

Giải quyết vấn đề “memory bloat”: Agent không còn quên hoặc lẫn lộn thông tin cũ.
Tăng tính cá nhân hóa: MEMORY.md ngày càng giàu kiến thức dài hạn của bạn.
Minh bạch & kiểm soát: Bạn có thể đọc “nhật ký giấc mơ” mỗi sáng như check Apple Watch sleep score.
Tiết kiệm token: Chỉ promote nội dung thực sự giá trị.
Hỗ trợ đa ngôn ngữ: Conceptual tagging giờ hỗ trợ 12+ ngôn ngữ (bao gồm tiếng Việt).

Cộng đồng đang rất khen tính năng này: “Memory without pruning becomes noise. The real unlock is deciding what to forget, not just what to store.” Nhiều người đã bật và thấy agent “thông minh hơn rõ rệt” sau 1-2 ngày.

7. Lưu ý

Experimental: Có thể thay đổi ở các bản sau.
Không configurable sâu (threshold, weights… là internal).
Chi phí token: Phụ thuộc tần suất và volume memory. Nhiều người thử nghiệm cho biết không cao nếu chạy nightly.
Tương thích: Hoàn toàn hoạt động với GPT-5.4, Qwen, MiniMax… (OpenClaw đã chuyển hướng mạnh sau khi Anthropic cắt hỗ trợ).

Với /dreaming trong OpenClaw 2026.4.5, OpenClaw không chỉ là “AI agent làm việc” mà còn là “AI agent biết suy ngẫm và học hỏi theo thời gian”. Đây là bước tiến quan trọng nhất từ trước đến nay về memory management cho self-hosted agents. Nếu bạn đang chạy OpenClaw để quản lý email, lịch, automation hay dự án cá nhân, đây chính là tính năng đáng nâng cấp ngay hôm nay.

Vì sao OpenClaw cần tối ưu lại memory?

Duy Nghiện — Sun, 05 Apr 2026 09:08:51 +0000

Có một hiểu nhầm khá phổ biến khi build trợ lý AI kiểu OpenClaw: nhiều người nghĩ cứ nhồi thêm memory là agent sẽ thông minh hơn. Thực tế thường ngược lại: memory càng phình, càng trùng lặp, càng thiếu phân tầng thì agent càng dễ trả lời loãng, chậm, lệch ưu tiên, thậm chí nhớ sai.

Với OpenClaw, memory không chỉ là chỗ để nhớ. Nó là phần hạ tầng quyết định agent có giữ được continuity giữa các session hay không, có phối hợp đa agent ổn hay không, và có phân biệt được đâu là sự thật chuẩn, đâu chỉ là ngữ cảnh phụ trợ hay không.

Vì sao tối ưu memory lại quan trọng?

1) Giảm nhiễu, tăng độ đúng

Sau 3 lần cấu trúc lại, kiến trúc memory đã bắt đầu đi theo hướng khá chuẩn:

mind/MEMORY.md = nguồn sự thật dài hạn cho người đọc
Postgres + pgvector = canonical machine memory
mem0/openmemory = shared collaboration memory cho nhiều agent
memory/YYYY-MM-DD.md = log theo ngày, mang tính raw timeline
LanceDB = lớp cũ, chỉ còn vai trò migration/archive

Đây là hướng đúng. Nhưng nếu không tối ưu định kỳ, mấy thứ sau sẽ xảy ra:

cùng một quyết định bị ghi ở nhiều nơi
note tạm thời bị lẫn với fact dài hạn
mem0 chứa quá nhiều nugget rác, agent search ra trúng nhầm
log hằng ngày phình to nhưng không được chưng cất lên canonical memory

Khi đó agent không mất trí nhớ, mà tệ hơn: nhớ quá nhiều thứ không đáng nhớ.

2) Giữ thứ tự ưu tiên giữa các lớp memory

Một hệ memory tốt không chỉ cần nhiều dữ liệu, mà cần biết tin cái gì trước.

Policy trong workspace nên là:

latest explicit user instruction
mind/MEMORY.md
Postgres structured state
mem0
nếu còn mơ hồ thì mới hỏi lại

Cái hay ở đây là OpenClaw đã tách được:

canonical truth
semantic recall
raw logs

Nếu không tối ưu, thứ tự này sẽ bị phá vỡ trên thực tế. Agent sẽ kéo phải những mẩu context dễ match hơn, thay vì những gì đúng hơn.

3) Tăng hiệu suất cho multi-agent

Khi chạy một agent thì memory bừa bộn đã khó chịu. Khi chạy nhiều agent thì nó thành bug hệ thống.

Trong runbook nên là, mem0 được dùng làm shared collaboration memory, còn task state thật nằm ở queue / task system / notebook / file / Postgres, vì:

mem0 hợp cho handoff, blocker, fact ngắn
không ép semantic memory phải gánh vai trò task database
giảm nguy cơ agent A hiểu sai thứ agent B ghi dở dang

Tối ưu memory ở đây có nghĩa là giảm duplicate, tăng atomicity, chuẩn hóa metadata, và có cơ chế promote từ memory phụ sang memory chuẩn khi thông tin đã được verify.

4) Giảm chi phí ngầm

Memory kém tổ chức không chỉ làm sai câu trả lời. Nó còn làm tăng:

token đọc context
số lần retrieval không cần thiết
thời gian agent dò tìm đúng nguồn
công sức dọn rác về sau

Nói thẳng: memory không tối ưu là một dạng technical debt lặng lẽ. Ban đầu chưa đau, nhưng tới lúc workflow dài, nhiều task, nhiều agent, nó đẻ lỗi rất mất thời gian để debug.

Tối ưu bằng cách nào?

1) Dedupe trước khi write

Đây là nguyên tắc đáng giữ nhất: đừng ghi thêm nếu thực ra chỉ đang lặp lại ý cũ.

Trước khi tạo memory mới, nên check:

ý này đã có trong mind/MEMORY.md chưa?
Postgres machine memory đã có bản structured chưa?
mem0 đã có entry tương đương chưa?
nếu đã có, nên update/promote thay vì append tiếp

Mỗi entry nên là 1 ý chính, ngắn, searchable, có context.

2) Tách rõ “fact”, “decision”, “hypothesis”, “handoff”

Runbook hiện tại của mem0 làm đúng điểm này bằng metadata kiểu:

type=fact
type=decision
type=hypothesis
type=todo
type=blocker
type=handoff

Đây không phải chuyện trang trí. Nó giúp agent:

biết cái nào đáng tin
biết cái nào chỉ là giả thuyết
biết cái nào dùng để tiếp sức cho agent khác

Nếu memory nào cũng là text tự do, sớm muộn retrieval cũng trả về mớ hỗn độn.

3) Chỉ promote thứ đã được verify

Không phải cái gì agent thấy hữu ích cũng đáng thành canonical memory.

Rule tốt là:

note tạm → ở daily log hoặc mem0
thứ có reuse trung bình/cao → Postgres machine memory
thứ ổn định lâu dài → mind/MEMORY.md

Nói cách khác, memory nên có pipeline thăng hạng:
raw note -> shared recall -> canonical state

Không có pipeline này thì hệ thống hoặc là quên quá nhanh, hoặc là giữ rác quá lâu.

4) Đặt TTL cho memory mang tính tác vụ

Policy nên gợi ý kiểu:

global facts/decisions: ttl=none
project operational notes: 30–90 ngày
task scratch/handoff: 7–30 ngày

Đây là phần cực đáng làm thật, vì task-level memory thường là nơi phình nhanh nhất. Nếu không có TTL hoặc cleanup cadence, mem0 sẽ biến thành bãi rác semantic.

5) Có lịch vệ sinh memory định kỳ

Một hệ memory khỏe cần maintenance, không chỉ architecture.

Tối thiểu nên có:

hàng tuần: prune duplicate trong mem0/Postgres machine memory
hàng tuần: distill log ngày sang durable memory
hàng tháng: xóa preferences hoặc constraint đã lỗi thời

Nói ngắn gọn: memory cũng cần garbage collection kiểu vận hành, không phải chỉ ở tầng database.

Khi nào cần tối ưu lại memory?

Có 6 dấu hiệu khá rõ:

1) Agent bắt đầu trả lời đúng kiểu na ná đúng

Nó không sai hẳn, nhưng dùng context cũ, lẫn note tạm với rule thật, hoặc nhắc lại một quyết định đã bị thay thế.

2) Cùng một fact xuất hiện ở nhiều file/layer

Ví dụ một rule vừa nằm ở daily log, vừa ở mem0, vừa ở Postgres, vừa bị copy sang docs khác — nhưng nội dung hơi lệch nhau.

3) Retrieval ra quá nhiều kết quả có vẻ liên quan nhưng ít cái thật sự hữu ích

Đây là triệu chứng điển hình của memory noise.

4) Multi-agent handoff hay bị trượt

Agent sau không biết đâu là outcome thật, đâu là note nháp, đâu là blocker cũ đã giải quyết.

5) Chi phí context tăng lên rõ rệt

Muốn làm một việc nhỏ mà phải đọc quá nhiều file, quá nhiều log, quá nhiều note lặp.

6) Sau vài tuần hoặc vài tháng làm việc liên tục

Dù chưa thấy lỗi lớn, vẫn nên tối ưu theo chu kỳ. Đừng chờ đến lúc hệ nhớ sai mới dọn.

Nếu anh em đang build OpenClaw hoặc một hệ AI agent tương tự, đừng xem memory là phần phụ. Nó chính là phần backend của continuity.

Hướng dẫn sử dụng ClawTask cho người mới

Duy Nghiện — Sat, 28 Mar 2026 13:38:27 +0000

ClawTask là một nền tảng để điều phối công việc giữa con người và AI agents (như OpenClaw). Thay vì chỉ chat với AI, bạn có một workspace có task, subtasks, notebook, clarification, recurring tasks, tài liệu và dashboard để theo dõi toàn bộ vòng đời công việc.

Tóm gọn lại thì nó là:

Con người tạo và quản lý task trong web dashboard
Agent nhận và xử lý task qua MCP/API
Khi bị thiếu dữ liệu, agent tạo clarification để hỏi lại người vận hành
Output cuối, ghi chú trung gian và lịch sử cập nhật đều được lưu lại

ClawTask phù hợp nhất khi bạn cần:

giao việc cho nhiều AI agents song song
theo dõi trạng thái công việc rõ ràng
giữ lại notebook, note và report
vẫn có human-in-the-loop thay vì để agent tự đoán

Nhìn nhanh các khu vực chính

Trong dashboard hiện tại, bạn sẽ thấy các mục sau:

Tasks: bảng công việc chính, xem theo Kanban hoặc list, tạo task, mở task detail, quản lý recurring tasks
Agents: tạo agent, xem trạng thái agent, lấy API key, mở onboarding bundle
Notebooks: nơi lưu ghi chú Markdown, research, kết quả trung gian, tri thức liên quan task
Documents: hướng dẫn cho agent
Settings: cài đặt người dùng

Luồng bắt đầu cho người mới

1. Tạo tài khoản

Vào trang Sign up, nhập họ tên, email, mật khẩu > sau đó mở email và bấm link verify

Nếu không thấy email:

kiểm tra spam
vào https://clawtask.app/auth/verify-email
nhập email để gửi lại verification link

2. Đăng nhập

Sau khi verify email, đăng nhập tại trang Login

Việc cần làm sau khi đăng nhập lần đầu

Vào Settings và điền time zone đúng của bạn (mặc định là UTC), vì nó ảnh hưởng việc lên lịch task
Thêm OpenClaw (hoặc các họ hàng nhà Claw đều được)
Lưu lại API Key khi thêm OpenClaw
Thêm API Key vào .env runtime của OpenClaw với format: CLAWTASK_API_KEY=ct_xxxxxxxxxxxxxxxx
Gửi bundle cho OpenClaw theo thứ tự như hướng dẫn: SETUP > SKILL CORE > SKILL EXTENDED > CRON > POLICY

OpenClaw sẽ hỏi bạn thêm 1 vài thông tin để nó setup và xong thì có thể tạo task và chờ nó vào thực hiện.

Cách dùng Tasks

Tasks là nơi bạn sẽ dùng nhiều nhất.

Chế độ xem

Trang Tasks hiện hỗ trợ ít nhất 2 kiểu xem:

kanban: hợp khi theo dõi luồng công việc theo status
list: hợp khi cần tìm, lọc và đọc nhanh

Dashboard có các bộ lọc cơ bản:

search theo title hoặc description
lọc theo assigned agent
lọc theo priority
lọc theo tag

Vòng đời task

ClawTask sử dụng vòng đời có trạng thái rõ ràng:

todo
in_progress
in_review
blocked
done

Một vài điểm cần hiểu đúng:

report là output cuối khi task đã done
statusReason là lý do hoặc trạng thái hiện tại
nếu task bị blocked đúng nghĩa, luồng đúng là clarification, không phải sửa status tay cho có

Tạo task tốt

Một task tốt trong ClawTask nên có:

title rõ ràng
mô tả context
expected output cụ thể
assigned agent nếu đã biết ai sẽ xử lý
tags nếu cần lọc hoặc tìm lại sau này
due date nếu bạn chỉ cần deadline
scheduled time nếu bạn muốn đặt lịch để agent thực hiện

Phân biệt quan trọng:

scheduledFor: cổng thực thi, agent chưa nhặt task nếu chưa đến giờ
dueDate: chỉ là deadline metadata

Clarification là gì

Khi agent không đủ dữ liệu để làm tiếp, nó sẽ tạo clarification thay vì đoán.

Với người vận hành, điều này có nghĩa:

task đang bị dừng có chủ đích
bạn cần vào task và trả lời câu hỏi đó
sau khi resolve clarification, agent mới tiếp tục từ checkpoint trước đó

Hãy xem clarification như primitive chính của human-in-the-loop, không phải tính năng phụ.

Notebook và task

Một số task yêu cầu hoặc khuyến nghị có notebook.

Notebook được dùng để lưu:

research notes
phân tích trung gian
draft outline
cách agent xử lý vấn đề
tri thức có thể tái sử dụng

Nếu task có bật Requires Notebook hoặc ClawTask đánh giá dựa trên các tiêu chí như tiêu đề, mô tả, sub-task thì cũng sẽ gửi một gợi ý cho agent, agent có thể bị chặn complete task cho đến khi có notebook.

Cách dùng Agents

Khu Agents dùng để quản lý workforce AI của bạn.

Bạn có thể làm gì ở đây

tạo agent mới
xem online, offline, sleeping
xem active tasks của từng agent
tạo API key
mở thông tin chi tiết từng agent

Điều cần hiểu về API key

Khi tạo agent hoặc tạo key mới:

API key chỉ hiển thị một lần
hệ thống lưu hash và prefix, không lưu raw key để đọc lại sau
key mặc định có hạn sử dụng 180 ngày

Vậy nên ngay lúc tạo key:

lưu vào secret manager
hoặc truyền vào môi trường runtime của worker (.env)
đừng copy vào docs công khai hay git

Agent kết nối vào đâu

ClawTask hỗ trợ:

REST base: https://mcp.clawtask.app/mcp

Agent docs runtime cần lấy từ:

POST https://mcp.clawtask.app/mcp/get-docs

Đây là source of truth cho contract hiện tại. Nếu worker có hành vi lạ, việc đầu tiên nên kiểm tra là bundle hoặc docs đã cũ hay chưa.

Luồng agent cơ bản

Luồng chuẩn cho một agent bên ngoài:

POST /mcp/register
POST /mcp/heartbeat
POST /mcp/list-tasks
POST /mcp/get-task
đổi status sang in_progress
thêm note, tạo notebook nếu cần
tạo clarification nếu bị thiếu dữ liệu
POST /mcp/complete-task khi xong

Nếu bạn là user mới chưa viết worker ngay, chỉ cần nhớ:

dashboard là nơi giao việc và theo dõi
agent là worker bên ngoài kết nối qua MCP/API

Notebooks dùng khi nào

Notebooks không chỉ là chỗ ghi chú tay. Đây là workspace lưu tri thức và output trung gian.

Nên dùng notebook khi:

task có nghiên cứu
cần lưu reasoning hoặc kết quả trung gian
có tài liệu cần tham chiếu lại
output cần dùng lại cho task khác

Không nên spam notebook cho các task quá nhỏ, đổi tên file, fix formatting, hay việc thuần cơ học.

Những lỗi người mới hay gặp

"Đăng ký xong mà chưa vào được dashboard"

Thường là chưa verify email. Vào Verify Email và gửi lại link.

"Quên lưu API key"

Nếu đã đóng popup rồi, bạn không đọc lại raw key được. Tạo key mới.

"Agent không nhận task"

Kiểm tra:

task đã được assign đúng agent chưa
task có bị scheduledFor ở tương lai không
agent đã register/heartbeat chưa
agent đang gọi đúng /mcp/* hoặc /api/mcp chưa

"Task bị blocked mà không thấy output"

Hãy mở clarification. Agent đang đợi trả lời, không phải đang tự fail.

Nếu bạn mới vào ClawTask, hãy nhớ 4 ý chính:

Tasks là trung tâm điều phối
Agents là nơi cấp workforce và key
Notebooks và Clarifications là hai cơ chế giúp workflow AI không bị mù
Documents là nguồn hướng dẫn chính cho workers và vận hành

ClawTask không cố gắng trở thành một chat app tốt hơn. Nó giải bài toán khác: biến AI agents thành một đội worker có trạng thái, có quy trình, có checkpoint và có thể vận hành nghiêm túc.

Build một workflow deep research thực tế với OpenClaw, Codex multi-agents và ACP

Duy Nghiện — Thu, 19 Mar 2026 17:55:12 +0000

Mấy hôm nay chắc mọi người đã từng thấy ít nhất một post hay thông tin đâu đó nói về việc Codex đã hỗ trợ multi agents trong coding. Việc một agent coding hỗ trợ multi agents không phải mới vì trước đó Claude Code, OpenCode đã hỗ trợ rồi.

Tuy nhiên, việc nhiều anh em (trong đó có mình) đang sử dụng Codex làm nguồn sử dụng token cho OpenClaw, và vì giá tài khoản ChatGPT Plus người thị trường chợ đen đang rất rẻ, anh em bào rất nhiệt tình. Vậy thì đang sử dụng Codex, chi phí không còn là rào cản và nó lại hỗ trợ multi agents, thì ngoài coding ra còn dùng nó để làm gì? Mình nghĩ ngay đến việc áp dụng vào các công việc thường ngày của mình.

Vì sao mình build skill này

Thứ mình cần không đơn giản là một AI nghiên cứu sâu. Thứ mình cần là một workflow deep research có thể dùng đi dùng lại, gắn được vào hệ thống giao việc (ClawTask), bớt copy-paste thủ công, và cuối cùng vẫn trả ra đúng thứ mình cần: bài blog, memo, outline hay report.

Lý do rất đơn giản. Khi dùng deep research trên các web chat như Perplexity, ChatGPT, Gemini hay GenSpark, kết quả thường đủ tốt để dùng, nhưng quy trình lại rất tốn tay. Anh em phải:

copy prompt qua lại giữa các nền tảng
gom kết quả từ nhiều nơi
bỏ bớt phần nội dung thừa hoặc các đoạn trích dẫn link nguồn.
sửa lại định dạng markdown
chỉnh heading, độ dài, giọng điệu
rồi mới đưa về một artifact cuối có thể dùng được

Cái đau ở đây không nằm ở một câu trả lời đơn lẻ. Nó nằm ở việc không thể automation hoàn toàn nếu cứ bám vào web chat UI.

Vì sao thời điểm này mình mới làm nó?

Có vài điều khiến chuyện này đáng build ngay bây giờ.

Codex vừa có multi-agents

Ngày 16/03/2026, Codex bắt đầu hỗ trợ multi-agents/subagents. Đây là khác biệt lớn. Trước đó, dù Codex có sẵn tính năng research, anh em có thể dùng model để research, nhưng rất khó chia bài toán ra thành nhiều nhánh rồi gom lại một cách tử tế trong cùng một workflow.

Khi multi-agents xuất hiện, cách nghĩ thay đổi hẳn. Bây giờ anh em có thể để một planner bẻ đề bài, một nhóm researcher đi tìm nguồn, một skeptic lật ngược lại luận điểm, rồi một writer tổng hợp ra artifact cuối. Nghĩa là deep research không còn là một model cố nhớ mọi thứ trong một lần chạy, mà thành một pipeline có vai trò rõ ràng hơn.

ChatGPT Plus đang là một lợi thế

Một lý do khác rất thực tế: giá tài khoản ChatGPT Plus ở ngoài chợ đen hiện tại khá rẻ. Mình không bàn chuyện đạo đức mua bán tài khoản ở đây; cái mình đang nói là về động lực kinh tế của người dùng thật. Khi chi phí truy cập Codex đủ dễ chịu, nhiều người bắt đầu nghĩ tới việc tận dụng nó như một công cụ làm việc nặng, không chỉ là chat vui, hay coding, giống như cách nhiều anh em khác đang tận dụng Antigravity vào những việc rất hay, không chỉ còn là coding.

Nếu anh em đã có đang dùng Codex, thì chuyện bào token để làm research, so sánh nguồn, chạy nhiều pass kiểm tra, hoặc dùng subagents song song trở nên hợp lý hơn rất nhiều so với trước.

OpenClaw đã có ACP (`acpx`)

Đây là mảnh ghép mà mình thấy nhiều người bỏ qua. Có model mạnh chưa đủ. Muốn biến nó thành workflow, anh em cần một lớp giao tiếp như người dùng thật giữa agent với agent hoặc giữa tool với agent.

OpenClaw hỗ trợ ACP (hay acpx) cho phép gọi coding/research agents theo kiểu headless thay vì bới PTY hay scrape terminal output. Cái này quan trọng vì nó mở đường cho một workflow automation sạch hơn:

tạo session
chạy one-shot exec
chia nhánh theo session/name
queue follow-up
kiểm tra trạng thái
nối vào pipeline tasking

Khi có ACP, deep research bắt đầu giống một hệ thống làm việc hơn là một tab chat.

Vấn đề thật sự của deep research trên web chat

Nhiều người nhìn vào mấy công cụ như Perplexity, ChatGPT Deep Research, Gemini hay GenSpark rồi nghĩ câu chuyện chỉ là “tool nào trả lời hay hơn”. Theo mình, đó là nhìn thiếu một nửa.

Nửa còn lại là rào cản thao tác.

Một ví dụ như này: anh em muốn viết một bài blog chuyên sâu. Anh em có thể research trên Perplexity để lấy nguồn, dùng Gemini để xem nó cấu trúc nội dung thế nào, dùng ChatGPT để viết lại câu chữ, rồi mang qua một chỗ khác để format markdown. Cách này vẫn ra kết quả, nhưng nó có mấy vấn đề:

1. Không có single workflow rõ ràng

Mỗi nền tảng là một hòn đảo. Anh em phải tự nối chúng lại bằng tay.

2. Khó tái sử dụng

Hôm nay anh em làm được một bài. Mai muốn lặp lại với chủ đề khác, anh em lại phải lặp lại cả đống thao tác tương tự.

3. Citation và nội dung thừa

Web chat hay nhả ra rất nhiều thứ “trông có vẻ hữu ích” nhưng không phải cái anh em cần cho output cuối. anh em lại phải lọc bằng tay.

4. Khó automation

Ngay cả khi kết quả tốt, việc nối các bước lại thành một pipeline gần như vẫn thủ công. Không dễ cắm nó vào dashboard giao việc, chia subtask hay build flow nhiều bước tử tế.

Skill `codex-deep-research` giải bài toán gì

Skill này được mình build trong OpenClaw không phải để cạnh tranh trực diện với Perplexity hay GenSpark về việc ai trả lời thông minh hơn. Nó giải một bài khác: biến deep research thành workflow có thể giao việc và tái sử dụng.

Cốt lõi của skill này là tách pipeline thành nhiều lớp.

Lớp 1: Research engine

Phần này lo:

planner để bẻ đề bài thành streams
researcher để gom facts và nguồn
skeptic pass để tìm chỗ yếu
source grading để chấm độ mạnh yếu của nguồn
synthesis để hợp nhất findings

Nói ngắn, nó cố làm phần “nghiên cứu sâu” cho ra hình hài rõ ràng thay vì một đống notes rời rạc.

Lớp 2: Artifact-aware output

Đây là phần mình thấy quan trọng nhất. Skill không mặc định coi deep research = research report. Nó biết rằng output cuối phải bám đúng yêu cầu của user.

Nếu user muốn:

blog post -> trả blog post
memo -> trả memo
outline -> trả outline
report -> trả report

Research là động cơ, artifact mới là thứ được giao.

Lớp 3: Preset + compliance

Sau vài vòng test, skill được nâng thêm preset theo loại output như:

blog/article
memo
outline

và thêm final compliance/polish pass để soát:

word count
heading rules
markdown hygiene
prose smoothness
việc research scaffolding có bị lộ ra không

Đây là phần giúp giảm đáng kể chuyện kết quả research tốt nhưng thành phẩm cuối còn phải sửa tay quá nhiều.

Sau khi chạy skill research này thì mình có đem bài viết qua cho Gemini, Grok và ChatGPT chấm điểm, thì bọn nó tự nâng bi nhau như này :))

Tại sao OpenClaw + ACP lại hợp bài này

Nếu chỉ muốn một câu trả lời sâu hơn, anh em có thể ở lại web chat. Nhưng nếu muốn một hệ thống giao việc thực tế, OpenClaw có lợi thế riêng.

Với ACP (acpx), anh em có thể nghĩ về deep research như một task execution layer:

nhận task thô
biến thành spec
gọi agent research
giữ context theo session
tách các pass khác nhau
trả artifact cuối

Điều này cực hợp nếu anh em đang có một dashboard kiểu ClawTask. Khi đó, deep research không còn là một thứ “ngồi chat bằng tay”, mà là một node trong pipeline công việc.

Skill này có thay được web chat không?

Không hoàn toàn. Mình không nghĩ nên thần thánh hóa skill hay agent workflow. Có những lúc mở Perplexity hay Gemini rồi hỏi nhanh một câu vẫn tiện hơn hẳn. Web chat vẫn có chỗ đứng, nhất là cho exploratory thinking và câu hỏi ngắn.

Nhưng nếu anh em đang làm những thứ lặp lại như:

viết bài blog kỹ thuật
viết memo nghiên cứu
gom nguồn cho quyết định sản phẩm
tạo brief cho bài dài

thì skill riêng bắt đầu đáng giá hơn. Không phải vì nó thông minh hơn mọi web chat, mà vì nó phù hợp cho automation với agent như OpenClaw.

Câu chuyện thật sự đằng sau skill này

Nếu nói ngắn gọn, mình build codex-deep-research vì mình chán phải sống trong vòng lặp:

research ở chỗ này
copy qua chỗ khác
lọc lại nội dung
sửa format
rồi mới ra được thành phẩm

Khi Codex có multi-agents, khi ChatGPT Plus đủ dễ tiếp cận, và khi OpenClaw đã có ACP/acpx, việc system hóa thứ đó thành một workflow bắt đầu đáng làm hơn hẳn.

Thứ mình muốn không phải “thêm một chat tool”. Mình muốn một pipeline mà khi có task mới, mình có thể ném nó vào, để hệ thống nghiên cứu, kiểm chứng, rồi trả ra đúng thứ cần giao. Đó là lý do skill này tồn tại.

codex-deep-research không phải một cái gì đấy mới. Nhưng nó giải một vấn đề rất thật: làm sao đưa deep research ra khỏi tình trạng chat thủ công và biến nó thành một workflow có thể tái sử dụng.

Nếu anh em cũng đang “bào token” từ Codex, có nhu cầu research nhiều nguồn để viết bài, làm nghiên cứu, tạo knowledge cho agent,... và muốn gắn chuyện đó vào hệ thống giao việc kiểu ClawTask, thì đây là lúc hợp lý để làm nghiêm túc. Không phải vì công nghệ bỗng nhiên hoàn hảo, mà vì cuối cùng các mảnh ghép cần thiết đã bắt đầu đủ mặt trên bàn.

Anh em cần tham khảo skill thì tải ở đây nhé:
https://romhub.io/OpenClaw/skills/codex-deep-research

ClawTask: bảng điều phối công việc cho đội OpenClaw

Duy Nghiện — Wed, 18 Mar 2026 06:11:31 +0000

Hello anh em

Mình muốn giới thiệu ClawTask, một web app task management dành riêng cho workflow AI agent + automation, không phải kiểu Kanban chung chung rồi gắn AI vào cho có.

Ý tưởng của ClawTask khá đơn giản:

Con người tạo task, chia subtask, gán agent
Agent nhận việc qua MCP/API
Trong lúc chạy, agent có thể cập nhật tiến độ, ghi note, tạo notebook
Nếu thiếu input, agent chủ động tạo clarification để hỏi lại người vận hành
Khi đủ dữ liệu thì tiếp tục chạy, thay vì fail im lặng hoặc đoán bừa

Nói ngắn: đây là một lớp điều phối nằm giữa dashboard của người vận hành và đội agent tự động.

Vấn đề mình thấy ở đa số workflow AI hiện tại

Hiện giờ nhiều team đang chạy AI theo 3 kiểu:

Chat tay trong ChatGPT/Claude rồi copy-paste kết quả
Dùng n8n/Make/Zapier cho automation, nhưng không quản lý được task loop phức tạp
Tự build agent runner, nhưng phần dashboard và human-in-the-loop rất yếu

Kết quả là:

Agent chạy nhưng khó biết đang kẹt ở đâu
Task dài dễ mất context
Không có chỗ chuẩn để agent hỏi lại khi thiếu yêu cầu
Khó giao nhiều việc song song cho nhiều agent khác nhau
Lịch sử làm việc, notebook, tiến độ, subtasks bị tản ra nhiều nơi

ClawTask được làm để xử lý đúng mấy điểm đó.

ClawTask là gì

ClawTask là một nền tảng AI agent task orchestration gồm:

Web dashboard để con người theo dõi toàn bộ board
MCP để agent kết nối
Kanban UI để kéo thả, gán việc, theo dõi trạng thái
Notebook layer để agent lưu markdown, ghi chép, output trung gian
Clarification flow để agent dừng đúng lúc và hỏi người dùng khi bị thiếu thông tin
Recurring tasks cho các việc lặp như check server, báo cáo định kỳ, audit, spy, crawl
Smart task suggestions để gợi ý subtasks từ lịch sử/template, có thể nâng cấp bằng provider + pgvector

Điểm mình thấy đáng giá nhất là ClawTask không xem agent như một chat box. Nó xem agent là một worker có trạng thái, có vòng đời task rõ ràng.

Vì sao mình nghĩ nó hợp với cộng đồng AI & Automation

Nếu anh em đang build:

đội content agent
team SEO tự động
research agent
coding agent nội bộ
ops bot / monitoring bot
quy trình review, báo cáo, audit lặp lại

thì ClawTask hợp hơn Trello/Notion/Jira ở chỗ nó có sẵn tư duy:

task do người tạo
task do agent xử lý
cần checkpoint rõ
cần hỏi lại khi thiếu dữ liệu
cần lưu output dạng notebook
cần API contract sạch để worker ngoài hệ thống vẫn chạy được

Nó không cố thay hết stack automation. Nó đứng ở lớp điều phối task cho agent.

Một vài điểm kỹ thuật đáng chú ý

1. MCP + REST đều có

Agent có thể giao tiếp qua:

POST /mcp/*
streamable RPC qua /api/mcp hoặc /mcp/rpc

Tức là có thể dùng worker tự viết, hoặc client theo chuẩn MCP.

2. Clarification là tính năng rất thực tế

Đây là điểm mình thích nhất.

Trong nhiều hệ thống AI, khi prompt thiếu dữ liệu thì agent hoặc đoán, hoặc fail. ClawTask cho agent tạo một clarification riêng, gắn với task, rồi dừng branch đó cho tới khi người dùng trả lời.

Cách này làm workflow an toàn hơn nhiều cho các job:

cần quyết định nghiệp vụ
thiếu file đầu vào
thiếu yêu cầu brand/content/code
cần user approve trước khi chạy tiếp

3. Notebook không phải đồ trang trí

Agent có thể tạo và cập nhật notebook theo task scope. Với các job dài như research, content outline, audit, code analysis, notebook giúp giữ lại reasoning và output trung gian thay vì chỉ còn một cục final result.

4. Recurring task hữu ích cho ops

Các job như:

check server mỗi ngày
tạo báo cáo 24h
quét log lỗi
backup checklist
review KPI hàng tuần

có thể cấu hình lặp lại thay vì tạo tay từng task.

ClawTask không phải gì

Để nói thật cho rõ:

Nó không phải no-code automation platform kiểu n8n
Nó không phải chat app cho LLM
Nó không phải project management tool cho mọi đối tượng

Nó hợp nhất khi anh em thật sự đang quản lý:

nhiều agent
nhiều task song song
nhiều bước có thể block
nhiều output cần lưu vết

Use case mình nghĩ dễ thấy giá trị

SEO/content team

Tạo campaign
Sinh subtasks tự động
Gán cho content agent, research agent, review agent
Khi thiếu brief, agent tạo clarification
Output nháp, outline, keyword cluster lưu vào notebook

Dev/ops team

Recurring task kiểm tra server, latency, cert, backup
Agent ghi log, note, báo cáo
Khi có điểm bất thường, tạo clarification cho human approve

Founder/solo builder

Dùng như trung tâm điều phối mini cho đội AI riêng
Theo dõi task nào done, task nào blocked, agent nào đang làm gì

Vì sao mình nghĩ hướng này đáng theo

AI workflow đang chuyển từ:

“hỏi một câu, lấy một câu trả lời”

sang:

“giao việc, theo dõi tiến độ, xử lý block, lưu kết quả, lặp lại theo quy trình”

Muốn đi theo hướng thứ hai thì cần nhiều hơn một prompt box. Cần một lớp orchestration có UI, trạng thái, log, checkpoint, clarification và API contract ổn định.

ClawTask đang đi đúng vào phần đó.

Nếu anh em muốn góp ý

Mình rất muốn nghe feedback theo các hướng:

Tính năng nào là must-have nếu anh em dùng cho đội agent thật
Clarification flow như vậy đã đủ chưa
Nên ưu tiên dashboard/UX, agent SDK, hay template workflow trước
Anh em muốn dùng theo hướng content, coding, ops hay research nhiều hơn

Nếu có nhu cầu, mình có thể viết tiếp các bài:

demo luồng agent nhận task qua MCP
cách dùng ClawTask cho SEO/content pipeline
cách dùng recurring tasks cho ops/monitoring
so sánh ClawTask với Trello + n8n + agent runner tự build

Nếu anh em trong forum đang build AI automation nghiêm túc, mình nghĩ đây là hướng đáng thử hơn việc chắp vá nhiều tool rời rạc.

(v3) Memory Architecture cho OpenClaw: Shared Postgres Runtime + Structured Context + Agent-Scoped Access

Duy Nghiện — Mon, 16 Mar 2026 19:24:57 +0000

Sau 2 bài trước:

Version 1: Hybrid Memory 3 lớp + Compaction
Version 2: Structured Context Architecture

thì bản v3 này là mảnh còn thiếu ở tầng runtime backend.

Nói ngắn gọn:

v1 giúp agent nhớ tốt hơn
v2 giúp agent nạp context tốt hơn
v3 giúp agent có backend machine memory tốt hơn

Trọng tâm của v3 là:

dùng Postgres + pgvector làm canonical machine memory cho OpenClaw.

Vì sao cần thêm bước này?

Ở v1 và v2, mình đã giải quyết khá ổn phần:

nên lưu cái gì
nên để ở đâu
nên nạp context theo thứ tự nào
task memory / retrieval trail / context namespace nên tổ chức ra sao

Nhưng khi chạy thực tế lâu hơn, mình gặp một câu hỏi khác:

memory runtime nên đặt trên backend nào để vừa lưu được structured state, vừa semantic retrieval tốt, lại đủ ổn định để dùng lâu dài?

Đó là lúc Postgres + pgvector bắt đầu hợp lý hơn hẳn.

Postgres + pgvector bổ sung gì cho 2 version đầu?

1) Biến machine memory thành một hệ vừa structured vừa semantic

Trước đây, khi nghĩ về durable memory, nhiều lúc mình nghiêng nhiều về semantic store:

lưu snippets
embed
semantic search lại khi cần

Nhưng thực tế OpenClaw không chỉ cần “nhớ gần nghĩa”. Nó còn cần giữ những thứ rất có cấu trúc như:

people
groups
memberships
reporting rules
reporting events
report deliveries
task runs
task run steps
documents
document chunks
memory items

Những dữ liệu này nếu chỉ để dưới dạng semantic snippets thì không đủ.

Postgres + pgvector giải quyết đẹp ở chỗ:

Postgres giữ factual/structured state
pgvector giữ semantic retrieval

Tức là cùng một stack, nhưng làm được cả 2 việc.

2) Structured query mạnh hơn hẳn cho workflow và operational state

Semantic search rất hợp cho các câu kiểu:

“hôm trước mình chốt hướng gì cho memory architecture?”
“rule F&B là gì nhỉ?”
“đoạn nào trong docs nói về reporting workflow?”

Nhưng nó không phải công cụ tốt nhất cho các câu kiểu:

ai thuộc group nào?
ai exempt khỏi rule này?
ngày nào ai missing report?
task run nào đang pending / failed / completed?

Đây là chỗ Postgres mạnh hơn rất nhiều.

Với v3, mình formalize retrieval như sau:

structured-first cho facts / workflow / rules / status
semantic-second cho docs / history / fuzzy recall

Đây là điểm mình thấy đáng giá nhất.

3) Một backend duy nhất cho nhiều loại machine memory

Điểm hay nữa là Postgres + pgvector giúp gom nhiều lớp machine memory về cùng một trục:

structured operational state
semantic memory items
document chunk store
workflow / reporting audit trail

Nhờ đó:

query chéo dễ hơn
backup/restore dễ hơn
governance/source-of-truth rõ hơn
bớt cảm giác mỗi loại dữ liệu nằm một nơi

Nếu làm agent lâu dài, đây là một lợi thế rất lớn.

So sánh nhẹ với LanceDB

Mình không nói LanceDB dở.

Ở giai đoạn đầu, LanceDB khá hợp để:

prototype semantic memory nhanh
local-first
nhẹ
ít công setup

Nhưng khi nhu cầu bắt đầu mở rộng sang:

structured state
reporting / workflow audit
people / groups / memberships
task runs / task steps
document chunk retrieval gắn với state

thì LanceDB không còn là trung tâm phù hợp nhất nữa.

Vì sao?

nó hợp cho vector retrieval hơn là canonical operational state
dễ bị lệch thành “semantic-first cho mọi thứ”
không tự nhiên bằng Postgres khi cần query quan hệ dữ liệu
lâu dài, governance và audit không thoải mái bằng

Kết luận hiện tại của mình

LanceDB: deprecated cho runtime chính, có thể giữ làm archive/migration-only nếu cần
Postgres + pgvector: canonical machine memory runtime

Nói gọn:

LanceDB hợp cho giai đoạn semantic memory sớm.
Postgres + pgvector hợp hơn khi machine memory bắt đầu phải phục vụ vận hành thực tế.

Kiến trúc hiện tại mình đang chốt

1) File memory vẫn giữ nguyên

Dùng cho:

mind/BRAIN.md
mind/MEMORY.md
memory/YYYY-MM-DD.md
context/decisions/*
agent/task-memory/*

Vai trò:

human-readable
fallback
journal
curated long-term notes

2) Structured Context layer vẫn giữ nguyên tinh thần v2

Bao gồm:

task memory
context namespace
tiered loading (L0/L1/L2)
retrieval trail

3) Postgres + pgvector là machine memory runtime chính

Dùng cho:

memory items
embeddings
documents
document chunks
people / groups / memberships
reporting rules / events / deliveries
task runs / task run steps

4) Retrieval policy rõ hơn

structured-first cho factual/workflow queries
semantic-second cho docs/history/knowledge queries

Mình thấy đây là điểm cân bằng tốt nhất hiện tại giữa:

practical
dễ vận hành
đủ mạnh
dễ mở rộng cho OpenClaw

Với mình, câu trả lời hiện tại là:

Postgres + pgvector

Không phải vì nó “ngầu” hơn.
Mà vì nó cân bằng tốt giữa:

structured state
semantic retrieval
audit/workflow support
độ bền cho use case thật
v1 giúp OpenClaw nhớ tốt hơn
v2 giúp OpenClaw nạp context tốt hơn
v3 giúp OpenClaw có machine memory runtime trưởng thành hơn

Và theo mình, đây là bước rất đáng làm nếu muốn đi từ một agent “có trí nhớ” sang một agent “có memory system đủ chín để chạy dài hạn”.

Tách biệt AI với máy Mac chính: Hướng dẫn chạy OpenClaw ngầm qua Lume

Duy Nghiện — Mon, 16 Mar 2026 14:55:45 +0000

Hello anh em,

Trong bài viết trước nói về Cua: Khi AI biết dùng máy tính thay bạn, mình đã có nhắc đến công cụ ảo hoá Lume. Hôm nay mình sẽ làm một bài hướng dẫn chi tiết từng bước cho anh em cách cài đặt máy ảo macOS bằng Lume và setup OpenClaw ngay bên trong đó.

Tại sao phải làm vậy?

Việc để một con AI tự do thao tác trên máy Mac làm việc chính là một rủi ro bảo mật khổng lồ. Nhỡ nó đọc nhầm file mật, hay táy máy gửi tin nhắn lung tung thì sao? Giải pháp ở đây là tạo ra một môi trường sandbox cô lập hoàn toàn. Setup này giúp tách biệt không gian của AI với máy chính, giảm thiểu tối đa rủi ro rò rỉ dữ liệu cá nhân mà vẫn cho phép AI chạy ngầm 24/7 cực kỳ ổn định.

Dưới đây là các bước chi tiết:

Cài Lume & tạo máy ảo macOS

1. Cài đặt Lume
Anh em mở Terminal trên máy Mac (máy chính) và chạy lệnh sau để cài đặt Lume:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/trycua/cua/main/libs/lume/scripts/install.sh)"

2. Khởi tạo máy ảo (VM)
Chạy lệnh này để tạo một máy ảo tên là openclaw. Lệnh này sẽ tự động tải bộ cài macOS mới nhất về từ Apple. Mình cấu hình luôn 4 nhân CPU, 8GB RAM và ổ cứng 60GB cho thoải mái nhé:

lume create openclaw --os macos --ipsw latest --cpu 4 --memory 8GB --disk-size 60GB

(Mẹo: Nếu anh em lười click chuột thiết lập macOS thủ công, có thể thêm cờ --unattended tahoe vào cuối lệnh để hệ thống tự động hóa luôn bước setup ban đầu nhé).

Cấu hình Remote Login (SSH)

Để lát nữa có thể chạy máy ảo ẩn đi mà vẫn điều khiển được, anh em cần bật SSH lên.

Chạy máy ảo bằng lệnh: lume run openclaw
Cửa sổ màn hình máy ảo (VNC) hiện lên, anh em thao tác thiết lập hệ điều hành macOS như bình thường (tạo user, pass...).
Vào System Settings > General > Sharing và bật Remote Login.
Bấm vào icon chữ "i" bên cạnh Remote Login để lấy địa chỉ IP của máy ảo (ví dụ: 192.168.64.12). Nhớ ghi lại IP và Username nhé.

Chạy ngầm (Headless) và cài OpenClaw

1. Kết nối vào máy ảo ngầm
Anh em tắt máy ảo từ giao diện VNC đi. Bây giờ chúng ta sẽ cho nó chạy ngầm hoàn toàn, không cần hiển thị cửa sổ hiển thị để tiết kiệm tài nguyên:

lume run openclaw --no-display

Tiếp theo, dùng Terminal của máy chính để SSH thẳng vào máy ảo:

ssh <username>@<địa_chỉ_IP>

2. Cài đặt môi trường Node.js
OpenClaw chạy trên nền Node.js (yêu cầu bản 22 trở lên). Ở trong giao diện SSH của máy ảo, anh em cài Homebrew rồi cài Node.js bằng 2 lệnh sau:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
brew install node

3. Cài đặt OpenClaw
Giờ thì cài OpenClaw thông qua trình quản lý npm:

npm install -g openclaw@latest

(Lưu ý: Nếu máy ảo báo lỗi "command not found" khi gõ lệnh openclaw, anh em chạy thêm 2 dòng này để nạp biến môi trường cho Terminal:

echo 'export PATH="$(npm prefix -g)/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

)

Thiết lập AI Agent

1. Cấu hình ban đầu
Gõ lệnh sau để bắt đầu khởi tạo Agent:

openclaw onboard --install-daemon

Hệ thống sẽ hiển thị các bước hỏi anh em muốn dùng nhà cung cấp mô hình AI nào (Anthropic, OpenAI, hay Custom Provider) và yêu cầu nhập API Key. Cứ làm theo hướng dẫn trên màn hình là được.

2. Kết nối kênh giao tiếp
Để AI có thể nhận lệnh và gửi tin nhắn tự động qua WhatsApp hoặc Telegram, anh em chạy tiếp lệnh:

openclaw channels add

Quét mã QR theo hướng dẫn trên màn hình là xong.

Đến đây, anh em đã có một máy chủ AI túc trực 24/7 trong một môi trường hộp cát an toàn tuyệt đối, tha hồ voọc vạch mà không lo ảnh hưởng hệ thống gốc!

Trong quá trình cài đặt, nếu anh em vướng mắc hay báo lỗi ở bước nào thì cứ bình luận bên dưới, mình sẽ hỗ trợ giải đáp!

(v2) Từ Hybrid Memory sang Structured Context cho OpenClaw

Duy Nghiện — Sat, 14 Mar 2026 09:14:05 +0000

Sau thêm một thời gian chạy thực tế với OpenClaw, mình nhận ra kiến trúc Hybrid Memory 3 lớp + Compaction vẫn mới giải được một nửa bài toán.

Nó giúp mình trả lời khá ổn câu hỏi:

nên lưu cái gì,
nên để ở đâu,
và nên nén/lọc lại khi nào.

Nhưng khi task bắt đầu dài hơn, có nhiều nhánh hơn, nhiều project hơn, hoặc có chuyện agent phải tự phối hợp main / worker / clarification, thì mình thấy còn thiếu một lớp rất quan trọng:

Context không chỉ cần được lưu. Nó còn cần được tổ chức, nạp đúng lúc, và giải thích được vì sao nó được dùng.

Vì vậy, mình update kiến trúc từ mô hình “memory 3 lớp” sang một mô hình đầy đủ hơn, tạm gọi là:

Structured Context Architecture

Nó vẫn giữ nguyên tinh thần cũ:

file-based working memory để dễ đọc, dễ debug
semantic durable memory để giữ continuity
compaction để chống phình context

Nhưng bổ sung thêm 4 phần mới:

Task Memory
Context Namespace
Tiered Loading Policy (L0/L1/L2)
Retrieval Trail

Nếu bạn đang dùng OpenClaw hoặc xây một agent tương tự, đây là phần mình thấy đáng áp dụng nhất.

1) Vấn đề của bản cũ: nhớ được, nhưng chưa tổ chức đủ tốt

Trong bản đầu tiên, mình chia memory thành:

Working Memory → file local, dễ đọc
Durable Memory → semantic store cho preference / fact / decision
Compaction Layer → job định kỳ để promote / distill / dedupe

Cách này giúp giảm đáng kể tình trạng nhét full history vào context. Nó cũng giúp session dài ổn định hơn, ít nghẽn hơn, và đỡ lãng phí token hơn.

Nhưng về sau mình gặp thêm 3 vấn đề khác:

Thứ nhất: context vẫn hơi phẳng

Dù đã có memory ngắn hạn và dài hạn, nhưng nhiều loại thông tin vẫn nằm lẫn vào nhau:

cái nào là user preference,
cái nào là task pattern,
cái nào là project-specific,
cái nào chỉ là state tạm,
cái nào là reusable runbook.

Khi chưa tách rõ phạm vi, retrieval dễ bị lan man.

Thứ hai: agent nhớ người dùng, nhưng chưa thật sự nhớ cách làm việc

Rất nhiều kinh nghiệm vận hành quan trọng không nằm trong preference/fact/decision, mà nằm ở dạng:

task kiểu này hay thiếu input gì,
clarification nào nên hỏi sớm,
bước nào hay fail,
task nào nên route sang worker,
done criteria nào cần check.

Nếu không có lớp nhớ riêng cho execution pattern, agent sẽ cứ lặp lại cùng một kiểu sai.

Thứ ba: retrieval vẫn hơi giống “hộp đen”

Khi agent quyết định hỏi clarification hoặc route một task sang worker, mình thường muốn biết:

nó đã load context nào,
vì sao nó dùng context đó,
nó bỏ qua context nào,
nó phát hiện thiếu field nào,
và quyết định đó dựa trên rule nào.

Nếu không nhìn thấy đường đi của context, rất khó debug khi hệ thống bắt đầu phức tạp hơn.

2) Bước nâng cấp: từ Memory Architecture sang Structured Context Architecture

Bản update này không đập bỏ kiến trúc cũ. Nó là một lớp nâng cấp ở trên.

Tức là mình vẫn giữ:

Working Memory
Durable Semantic Memory
Compaction

Nhưng thêm vào 4 mảnh mới để hệ thống bớt phụ thuộc vào việc agent phải tự nhớ trong đầu.

3) Task Memory: agent không chỉ nhớ người dùng, mà còn phải nhớ cách làm việc

Đây là thay đổi mình thấy đáng nhất.

Trước đây, kinh nghiệm xử lý task thường bị rơi vào:

chat log,
note theo ngày,
working memory,
hoặc không được ghi lại hẳn.

Điều đó có nghĩa là agent có thể nhớ rằng user thích xưng hô thế nào, nhưng lại không nhớ rằng:

task gửi Telegram thường thiếu target,
task browser relay thường thiếu attached tab,
task nhiều subtasks nên route sang worker sớm,
task kiểu A thường bị block ở bước B.

Vì vậy mình tách riêng một vùng Task Memory để lưu những pattern thực thi có thể tái sử dụng:

required inputs thường gặp,
common missing fields,
clarification mẫu,
resume checkpoint mẫu,
failure pattern,
done criteria,
routing heuristic.

Ví dụ, một task memory cho telegram-send có thể ghi rất rõ:

Required inputs: target, message
Common missing field: telegram.target
Clarification mẫu: “Bạn muốn gửi cho ai? chatId, @username hay channel target nào?”
Resume checkpoint: “Continue at Telegram send step after target is provided”

Lợi ích rất thực tế:

agent block đúng chỗ hơn,
hỏi đúng câu hơn,
resume mượt hơn,
và đỡ lặp lại lỗi cũ.

Đây là bước chuyển từ user memory sang execution memory.

4) Context Namespace: chia context theo phạm vi thay vì để chung một rổ

Một thay đổi nữa là mình không còn xem context như một khối thông tin lớn, mà tách nó theo namespace/phạm vi sử dụng.

Một cấu trúc gợi ý như sau:

core/
- persona
- user profile
- critical policies
agent/
- working memory
- long-term learned patterns
- task memory
projects/
- project brain riêng cho từng project
- goals, decisions, resources, playbooks, artifacts
tasks/
- task-local execution state
- subtasks
- clarifications
- outputs
- retrieval trail
shared/
- runbooks dùng chung
- references
- tools notes

Điểm quan trọng của cách chia này là nó trả lời được câu hỏi:

cái gì thuộc core identity,
cái gì thuộc project hiện tại,
cái gì là knowledge dùng lại lâu dài,
cái gì chỉ là state tạm của task đang chạy.

Khi các scope được tách rõ, retrieval bớt bị nhiễu hơn rất nhiều.

Với OpenClaw, cách làm này hợp tự nhiên vì bản thân hệ thống đã có xu hướng sống trong workspace file-based. Chỉ cần thêm quy ước và namespace rõ hơn là đã có khác biệt lớn.

5) Tiered Loading Policy (L0 / L1 / L2): không phải cái gì cũng đáng được nạp vào prompt

Một lỗi rất phổ biến khi build agent là cứ nghĩ “càng nhiều context càng tốt”. Thực tế thường ngược lại.

Context quá nhiều sẽ gây:

token bloat,
nhiễu,
retrieval sai ưu tiên,
và đôi khi làm agent tự tin sai.

Vì vậy mình thêm một policy nạp context theo 3 tầng:

Layer 0 — Always-on context

Đây là phần gần như luôn cần:

persona / identity
user profile
working memory hiện tại
task/request đang xử lý
policy critical có liên quan trực tiếp

L0 nên nhỏ, ổn định, và dễ dự đoán.

Layer 1 — Task / Project-specific context

Đây là phần nạp khi có liên quan rõ ràng:

project docs
playbook liên quan
task memory đúng loại việc
recent notes gần đây
relevant ops runbooks

Nói cách khác, L1 là nơi retrieval bắt đầu có ngữ cảnh thực sự.

Layer 2 — Deep / On-demand context

Đây là phần chỉ nên truy hồi khi thật sự cần:

archive cũ,
long logs,
docs lớn,
historical artifacts,
deep references.

Mình thấy việc formalize 3 tầng này có ích hơn rất nhiều.

Nó giúp agent biết dừng đúng lúc:

đủ thông tin để làm bước tiếp theo thì làm,
thiếu required input thì hỏi clarification,
không kéo thêm cả núi context chỉ để cố đoán.

Nếu phải tóm gọn retrieval order mặc định, mình dùng thứ tự này:

L0 core
task-local context
project context
task memory
shared runbooks / playbooks
recent daily memory
archive sâu

Cách này đặc biệt hữu ích cho OpenClaw vì nó làm cho việc đọc file bớt cảm tính và bớt phụ thuộc vào trí nhớ ngắn hạn của agent.

6) Retrieval Trail: để context không còn là một “hộp đen”

Khi agent bắt đầu làm task dài, hỏi clarification, hay route qua worker, mình thấy cần một thứ giống như “flight recorder” cho context.

Đó là lý do mình thêm khái niệm Retrieval Trail.

Một retrieval trail tốt không cần dài dòng. Nó chỉ cần ghi lại những thứ có thể quan sát được, ví dụ:

đã load những context nào,
vì sao load chúng,
đã bỏ qua context nào,
phát hiện thiếu field nào,
quyết định gì được đưa ra,
resume checkpoint là gì.

Ví dụ như này:

load USER.md vì đây là core context,
load agent/task-memory/telegram-send.md vì task khớp loại “telegram send”,
phát hiện thiếu telegram.target,
quyết định create_clarification,
resume từ bước “Telegram send” sau khi user trả lời.

Điểm này cực kỳ hữu ích trong 4 trường hợp:

debug task fail,
audit hành vi của agent,
thiết kế UI giải thích cho user,
và xây clarification-first workflow tử tế.

Nó cũng làm cho hệ thống dễ tin hơn, vì khi có gì sai, mình không còn phải hỏi kiểu “nó nghĩ gì trong đầu vậy?”.

7) Clarification-first workflow: hệ quả tự nhiên của structured context

Khi có task memory, namespace rõ, loading policy rõ và retrieval trail rõ, một chuyện xảy ra gần như tự nhiên:

Agent sẽ biết sớm hơn khi nào nó đang thiếu dữ kiện bắt buộc.

Thay vì giữ task ở in_progress và lửng lơ, hệ thống có thể:

phát hiện field bắt buộc còn thiếu,
tạo clarification đúng lúc,
ghi rõ câu hỏi,
ghi rõ resume checkpoint,
chờ answer,
và resume đúng từ chỗ cần resume.

Đây là một cải tiến rất thực dụng.

Nó không chỉ giúp agent hành xử đúng hơn, mà còn giúp user hiểu hệ thống hơn. User thấy rõ:

vì sao task bị block,
thiếu đúng cái gì,
trả lời xong thì cái gì sẽ chạy tiếp.

Nếu đang build một hệ như OpenClaw + ClawTask, mình nghĩ phần này gần như bắt buộc nếu muốn tiến tới workflow dài hạn hoặc multi-agent.

8) Kiến trúc đầy đủ sau update

Sau khi bổ sung các phần trên, mô hình hiện tại của mình có thể tóm gọn như sau:

Working Memory
- file-based
- human-readable
- giữ current focus / blockers / next steps
Durable Semantic Memory
- lưu preference / fact / decision / entity bền vững
- truy hồi theo ngữ nghĩa khi cần continuity
Compaction Layer
- promote / distill / dedupe theo cron
- chống context phình to và giữ memory sạch
Task Memory Layer
- lưu các pattern thực thi có thể tái sử dụng
- common blockers / clarification patterns / routing heuristics
Structured Context Namespaces
- tách rõ core / agent / project / task / shared
Tiered Loading Policy (L0 / L1 / L2)
- nạp context theo thứ tự ưu tiên, không theo cảm tính
Retrieval Trail
- lưu dấu quá trình truy hồi và quyết định
- hỗ trợ debug, audit, explainability

Nói ngắn gọn, mình không còn nghĩ theo kiểu:

“memory là chỗ để nhớ”

Mà chuyển sang kiểu:

“context là một hệ thống có cấu trúc: biết lưu, biết nạp, biết giải thích, và biết học từ execution”.

9) Nếu bạn đang dùng OpenClaw và muốn áp dụng luôn

Nếu mục tiêu là để một agent/OpenClaw khác đọc bài này xong có thể tự setup theo mà không cần giải thích nhiều, thì mình khuyên đi theo đúng thứ tự này:

Bước 1 — Giữ nguyên hybrid memory cũ

Bắt đầu từ nền đã ổn:

working memory file-based
durable semantic memory
compaction cron

Đừng rewrite mọi thứ ngay từ đầu.

Bước 2 — Thêm 3 namespace mới

Tạo thêm:

agent/task-memory/
projects/
tasks/

Chỉ riêng bước này đã giúp hệ thống bớt lẫn context rất nhiều.

Bước 3 — Viết context loading policy

Formalize retrieval order thành:

L0 core
task-local
project
task-memory
shared playbooks/runbooks
recent memory
archive sâu

Bước 4 — Tạo 2–3 task memory đầu tiên

Đừng tham. Chỉ cần bắt đầu bằng vài pattern hay gặp nhất, ví dụ:

telegram-send.md
browser-relay.md
clarifications-common.md

Bước 5 — Chỉ thêm retrieval trail cho task dài hoặc blocked task

Đừng ép mọi task nhỏ phải có trail. Chỉ cần dùng cho:

task nhiều subtasks,
task có blocker,
task cần debug,
task có routing decision.

Đây là cách rollout ít đau nhất và dễ vận hành nhất.

9) Trade-off thực tế

Mình thích kiến trúc này vì nó thực dụng, nhưng không phải không có giá phải trả.

Những trade-off rõ nhất là:

phải có kỷ luật naming/namespace,
phải biết cái gì là pattern bền, cái gì chỉ là note tạm,
phải tránh over-engineer retrieval trail,
và phải chấp nhận rằng memory không còn chỉ là ghi gì đó vào file.

Tuy vậy, so với lợi ích nhận được thì mình thấy đáng:

bớt nhiễu,
block đúng hơn,
route đúng hơn,
explain tốt hơn,
và tăng khả năng vận hành dài hạn.

Nếu phiên bản đầu tiên của kiến trúc này trả lời câu hỏi:

“Memory nên lưu như thế nào?”

thì phiên bản update này trả lời thêm một câu hỏi quan trọng không kém:

“Context nên được tổ chức, nạp và giải thích như thế nào để agent chạy lâu dài mà không hóa thành bãi rác?”

Theo mình, đây là bước chuyển từ một agent “có trí nhớ” sang một agent “có kiến trúc nhận thức” rõ ràng hơn.

Và nếu mục tiêu là để OpenClaw hoặc các agent tương tự có thể tự setup, tự duy trì continuity, tự block đúng chỗ, và tự học dần từ execution, thì đây là hướng mình thấy đáng làm nhất hiện tại.

OpenClaw + Paperclip: từ trợ lý 24/7 đến đội ngũ AI có mục tiêu, ngân sách và quy trình

Duy Nghiện — Fri, 13 Mar 2026 08:55:02 +0000

Phần lớn các bản demo AI hiện nay vẫn đang mắc kẹt ở một hình thái chung: "Nhắn tin và nhận lại câu trả lời". Phải thừa nhận là nó rất tiện, tốc độ phản hồi nhanh và mang tính giải trí cao. Nhưng khi bắt tay vào dùng AI để vận hành công việc thật sự, vấn đề không còn nằm ở việc chat nữa.

Vấn đề thực tế là: Ai đang làm việc gì? Dữ liệu nằm ở đâu? Công việc này có bị trùng lặp không? Ai là người duyệt bước cuối, và ngân sách API đang đốt đến mức nào?

Đó là lý do dạo gần đây, mình bắt đầu đưa cặp đôi OpenClaw và Paperclip lên môi trường OrbStack quen thuộc để test luồng. Khi ghép hai công cụ này lại, góc nhìn về "AI Agent" hoàn toàn thay đổi.

Nói một cách ngắn gọn:

OpenClaw là nhân viên thực thi.
Paperclip là công ty vận hành.

Và chính việc tách bạch hai lớp này mới là cơ hội thực sự để tự động hóa quy trình.

OpenClaw: Khi AI sống trong túi của bạn

OpenClaw là một self-hosted gateway dùng để kết nối AI agent với các kênh chat quen thuộc. Thay vì ép người dùng phải học cách dùng một cái app mới hay mở thêm một tab trình duyệt, OpenClaw nương theo hành vi cũ: nhắn tin.

Nó hỗ trợ đa kênh từ WhatsApp, Telegram, Discord, iMessage và quản lý các session tách biệt rất mượt.

Điều này quan trọng ở điểm nào? Hầu hết chúng ta không muốn phải mở một giao diện Control UI phức tạp chỉ để giao việc. mình muốn AI luôn ở trong túi mình. Một ý tưởng chợt lóe lên, một lệnh kiểm tra hệ thống, mình chỉ cần rút điện thoại ra nhắn tin vào Telegram. OpenClaw sẽ đứng ra nhận lệnh, giữ ngữ cảnh, xử lý hình ảnh/tài liệu và chạy dài hơi thay vì chỉ hỏi-đáp một lần rồi quên.

Paperclip: Bộ não điều phối phía sau

Nếu OpenClaw là lớp tiếp xúc (giao diện), thì Paperclip (với bản release v0.3.1) là lớp điều phối và quản trị (control plane).

Paperclip tự định vị họ là open-source orchestration cho "zero-human companies". Bỏ qua lớp vỏ ngôn từ hơi hype, bản chất của nó là hệ thống giúp bạn vận hành một đội agent thay vì từng cá nhân lẻ tẻ. Paperclip giải quyết gọn gàng những câu hỏi hóc búa nhất khi scale hệ thống AI:

Sơ đồ tổ chức & mục tiêu: Task này phục vụ mục tiêu gì? Ai sở hữu nó?
Chống chồng chéo (Atomic checkout): Đảm bảo hai agent không lao vào xử lý cùng một việc.
Ngân sách & quản trị (Budget & Approval): Token đang tiêu tốn ra sao? Lệnh nào cần người thật (human-in-the-loop) bấm duyệt trước khi chạy?

Nhiều team hiện nay vẫn đang chắp vá luồng này bằng cách móc nối n8n, Slack, Google Sheets và vài đoạn script tự viết. Paperclip gom tất cả sự cồng kềnh đó lại thành một mô hình vận hành chuẩn chỉ.

Sức mạnh thực sự nằm ở sự kết hợp

Hãy hình dung luồng vận hành khi ghép nối cả hai:

flowchart LR
    U[Người Vận Hành] --> C[Zalo / Telegram / WhatsApp]
    C --> O[OpenClaw Gateway]
    O --> P[Paperclip]
    P --> A1[Sales Agent]
    P --> A2[Content Agent]
    P --> A3[Ops Agent]
    P --> A4[Dev/Engineer Agent]
    A1 --> P
    A2 --> P
    A3 --> P
    A4 --> P
    P --> O
    O --> C

Chỉ cần nhắn một tin từ điện thoại, OpenClaw sẽ nhận lệnh và đẩy lên Paperclip. Tại đây, Paperclip chia việc, gán mục tiêu, kiểm tra ngân sách và giữ log (audit trail). Xong xuôi, kết quả được đẩy ngược về lại kênh chat cho bạn.

Đây không còn là một trợ lý ảo. Nó là một bộ máy.

3 Use case thực tế (và cách đóng gói ra tiền)

Nhìn từ góc độ tối ưu hóa cho các dự án hiện tại, đây là những kịch bản thực tế nhất:

1. Hệ thống không để rớt lead (cho F&B & dịch vụ B2B)

Khi chạy Facebook Ads cho các thương hiệu như Homey Co-working hay Lẩu Đây tại Thái Nguyên, bài toán đau đầu nhất không phải là thiếu lead, mà là rớt lead do follow-up chậm. Khách hàng nhắn tin vào fanpage, nhân viên trực quá tải hoặc bị trôi tin nhắn, thế là mất tiền quảng cáo.

Với stack này:

OpenClaw đứng hứng lead trực tiếp.
Paperclip ngay lập tức tạo task, giao cho Sales Agent soạn kịch bản phản hồi hoặc Ops Agent báo động cho quản lý nếu lead thuộc dạng VIP.
Mọi thứ diễn ra theo luồng, có log rõ ràng, không ai phải nhớ thủ công.

Sản phẩm này cực kỳ dễ bán cho các business dịch vụ nhỏ dưới thông điệp: "Hệ thống bắt lead và tự động nhắc nhở follow-up".

2. Cỗ máy sản xuất content (cho blog & forum)

Duy trì nhịp độ lên bài cho các trang như vnrom.net hay cộng đồng ai.vnrom.net tốn rất nhiều chất xám tổ chức. Thay vì tự làm mọi thứ, mình có thể nhắn một chiếc Voice memo ý tưởng vào Telegram.

OpenClaw tiếp nhận, Paperclip giao cho Writer Agent chuyển ý tưởng thành brief, draft bài, sau đó đẩy sang cho một agent khác cắt nhỏ thành post chia sẻ mạng xã hội. mình chỉ việc vào duyệt (Approval) và lên lịch. Nhanh và không bị rơi rớt context.

3. Founder Command Center

Thay vì nhảy qua lại giữa hàng chục tab quản lý, hệ thống backup Rclone, hay các dashboard tự build, một câu lệnh: "Check xem luồng backup rạng sáng nay có lỗi gì không, phân tích log và báo lại" sẽ kích hoạt đội Ops Agent làm việc và báo cáo thẳng về chat.

Thị trường đang chuyển dịch rõ rệt. Người dùng doanh nghiệp không muốn nghe về công ty tự hành xa xôi. Họ muốn những thứ giải quyết cơn đau thực tế: làm sao để nhanh hơn, ít rớt việc hơn, và quan trọng nhất – vẫn giữ được quyền kiểm soát.

OpenClaw giúp chúng ta nói chuyện với AI ở bất cứ đâu. Còn Paperclip giúp chúng ta giao việc và quản lý AI như một doanh nghiệp thực thụ. Và đó mới là lúc AI thực sự bắt đầu tạo ra ROI.

OpenClaw ACP - Bridge CLI giúp Claude Code và Codex (app + CLI) kết nối mượt mà với AI Agent siêu nhẹ và mạnh

Duy Nghiện — Thu, 12 Mar 2026 17:49:31 +0000

Hello anh em

Gần đây mình chuyển sang dùng OpenClaw làm gateway chính và phát hiện ra OpenClaw ACP là một “vũ khí bí mật” cực kỳ tiện lợi. Không phải full runtime nặng nề, mà chỉ là một bridge nhẹ giữa Agent Client Protocol (ACP) và OpenClaw Gateway.

Mình share bài này để anh em nào đang build agent, dùng Claude Code với Antigravity, Codex app hay Codex CLI thì dễ dàng triển khai. Toàn bộ thông tin lấy trực tiếp từ docs chính thức , mình đã test trên cả local và remote gateway rồi.

OpenClaw ACP thực chất làm gì?

Nói đơn giản: khi Claude Code hoặc Codex (app/CLI) nói chuyện bằng ngôn ngữ ACP (qua stdio), thì OpenClaw ACP sẽ nhận lệnh đó, map session rồi forward prompt qua WebSocket đến Gateway. Gateway mới là nơi xử lý thật sự (tool calls, memory, MCP servers, routing…).

Ưu điểm lớn nhất:

Siêu nhẹ, không cần chạy full editor native
Hỗ trợ cả local gateway lẫn remote (qua URL + token)
Session mapping 1:1, dễ quản lý
Không hỗ trợ per-session MCP servers (đây là điểm quan trọng, mình sẽ nói sau)

Cách cài đặt chỉ mất 30 giây

Anh em chỉ cần chạy một lệnh duy nhất (cho ae nào chưa cài OpenClaw):

curl -fsSL https://openclaw.ai/install.sh | bash

Sau đó onboard gateway:

openclaw onboard --install-daemon

Kiểm tra nhanh:

openclaw --version
openclaw gateway status

Nếu đã có npm thì đơn giản hơn:

npm install -g openclaw@latest

Xong. Gateway chạy ngầm như service (systemd hoặc launchd).

Lệnh chính: openclaw acp và các tham số hay dùng

Lệnh cốt lõi:

openclaw acp

Các flag mình hay dùng nhất (copy-paste luôn cho tiện):

Kết nối gateway:

openclaw acp --url wss://localhost:18789 --token-file ~/.openclaw/gateway.token

Gắn vào session cụ thể:

openclaw acp --session agent:main:main
openclaw acp --session-label "claude-main"

Reset transcript nhưng giữ session key:

openclaw acp --session agent:main:main --reset-session

Debug mode (test nhanh không cần app):

openclaw acp client

Mình khuyên anh em luôn dùng --token-file hoặc biến môi trường OPENCLAW_GATEWAY_TOKEN để tránh lộ token trong process list. Đừng dùng --token trực tiếp trên command line.

Tích hợp với Claude Code & Codex

Cách chuẩn nhất: Dùng acpx làm cầu nối

Đầu tiên tạo session:

acpx openclaw sessions ensure --name claude-bridge

Sau đó chạy Claude Code / Codex CLI qua acpx:

acpx openclaw -s claude-bridge "Hỏi agent OpenClaw về context repo này"

Config vĩnh viễn trong ~/.acpx/config.json:

{
  "agents": {
    "openclaw": {
      "command": "env OPENCLAW_HIDE_BANNER=1 openclaw acp --url wss://localhost:18789 --token-file ~/.openclaw/gateway.token --session agent:main:main"
    }
  }
}

Sau đó chỉ cần:

acpx openclaw "Làm giúp mình task XYZ"

Claude Code (với Antigravity qua CCS) và Codex app/CLI đều chạy mượt qua acpx + OpenClaw ACP. Không còn proxy thủ công, session map 1:1, MCP tập trung. Mình port từ ClaudeKit qua chỉ mất 2 phút là xong.

Lưu ý quan trọng về MCP servers

Đây là điểm nhiều anh em hay gặp lỗi: OpenClaw ACP không hỗ trợ per-session mcpServers. Nếu gửi thì sẽ báo lỗi rõ ràng.

Cách đúng là cấu hình MCP tập trung ở mức Gateway hoặc Agent (qua config hoặc lệnh openclaw config). Làm vậy thì Claude Code, Codex app và CLI đều dùng chung một bộ tool, permission và scaling dễ quản lý hơn nhiều.

Mẹo nhỏ mình hay dùng

--require-existing để tránh tạo session mới vô ý
OPENCLAW_HIDE_BANNER=1 cho output sạch
--verbose khi debug
Dùng --reset-session khi muốn “làm mới” transcript nhưng giữ session label

Mình đang dùng OpenClaw ACP + Claude Code + Codex app/CLI làm workflow chính: agent tự edit code, chạy test, commit, thậm chí kết nối multi-session (dev + qa + support). Tốc độ nhanh, bảo mật cao, và đặc biệt là không còn phải lo proxy thủ công nữa.

Anh em nào đang build agentic system với Claude Code hoặc Codex thì nên thử ngay. Chỉ mất 5 phút cài đặt là thấy khác biệt.

Memory Architecture cho OpenClaw: Hybrid 3 lớp + Compaction

Duy Nghiện — Tue, 24 Feb 2026 04:25:25 +0000

Hello anh em,

Bài này mình chia sẻ kiến trúc memory hiện tại mình đang dùng với OpenClaw sau vài vòng thử nghiệm. Mục tiêu là tăng độ nhớ đúng ngữ cảnh nhưng vẫn giữ context gọn và vận hành ổn định.

Tóm tắt nhanh cho anh nắm được

Mình không dùng kiểu "nhét full history vào context". Thay vào đó, mình sử dụng Hybrid Memory 3 lớp:

Working Memory (File-based):
- mind/BRAIN.md: Trạng thái công việc hiện tại.
- memory/YYYY-MM-DD.md: Nhật ký công việc theo ngày.
Durable Memory (Semantic Store):
- Sử dụng Memory plugin (hiện tại là memory-lancedb) để lưu các dữ liệu bền vững: preference, decision, fact, entity.
Compaction Layer (Cron):
- Job giữa ngày: Lọc nhẹ và thúc đẩy (promote) các memory quan trọng.
- Job cuối ngày: Tổng hợp sâu, xóa trùng lặp (dedupe) và chắt lọc (distill).

Kết quả: Context sạch hơn, ít "quên vặt", và tiết kiệm token đáng kể khi chạy lâu dài.

Vì sao mình chuyển sang kiến trúc này?

Vấn đề mình gặp trước đây:

Session dài: Model bắt đầu bị nhiễu thông tin.
Trôi thông tin: Những quyết định cũ bị chìm nghỉm giữa chat log.
Chi phí & Hiệu suất: Càng nhét nhiều context càng đắt và chậm, trong khi độ chính xác chưa chắc tăng.

Vì vậy, mình tách memory thành các lớp ngắn hạn/dài hạn kết hợp với Compaction định kỳ để duy trì chất lượng.

Chi tiết từng lớp

1. Working Memory (Ngắn hạn, dễ đọc)

Sử dụng file Markdown để giữ trạng thái "đang làm gì":

Task hiện tại.
Các rào cản (Blockers).
Các việc cần theo dõi (Follow-up).

Ưu điểm: Người dùng có thể đọc (human-readable), debug cực dễ và không phụ thuộc vào Database ngay từ đầu.
Nhược điểm: Nếu không có compaction, file sẽ phình to và gây rối.

2. Durable Memory (Dài hạn, Semantic)

Lưu trữ những gì thực sự đáng nhớ:

Thói quen và sở thích người dùng (User preference).
Các quyết định kỹ thuật hoặc vận hành.
Các sự thật (Facts) có tính lặp lại trong workflow.

Ưu điểm: Truy xuất (recall) theo ngữ nghĩa tốt hơn việc tìm kiếm văn bản thông thường. Giữ được tính liên tục (continuity) qua nhiều session.
Nhược điểm: Cần quản trị tốt (governance), nếu không sẽ trở thành "bãi rác vector".

3. Compaction (Trái tim của hệ thống)

Mình chạy 2 job định kỳ:

Midday pass: Lọc nhanh các mục quan trọng.
Nightly pass: Tổng hợp sâu, xóa trùng lặp và chuyển đổi thành memory bền vững.

Policy đang áp dụng (Rất quan trọng)

Write Policy (Cái gì được nhớ)

Nên nhớ	Không nên nhớ
Preference ổn định	Tán gẫu (Chit-chat)
Quyết định & Lý do (Rationale)	Fact công khai dễ tìm lại
Milestone / Blocker / Next step	Nội dung nhạy cảm không cần thiết

Retrieval Policy (Khi nào truy xuất)

Nên: Khi câu hỏi liên quan đến lịch sử, quyết định hoặc sở thích; các task nhiều bước cần tính liên tục.
Không nên: Khi câu hỏi mang tính chất chung chung, không liên quan ngữ cảnh cá nhân. Tránh lỗi "search first" cho mọi câu hỏi.

Injection Policy

Chỉ inject từ 3–8 memory snippets hàng đầu.
Ưu tiên theo thứ tự: Relevance > Importance > Recency.
Luôn giữ giới hạn token (budget) cho khối memory.

Đánh giá thực tế

Ưu điểm

Giảm tình trạng nghẽn context (context bloat) rõ rệt.
Tăng độ ổn định cho các task dài hoặc đa bước.
Dễ vận hành và audit/debug vì vẫn có file local để kiểm tra.

Nhược điểm / Trade-off

Thêm các thành phần chuyển động (cron, policy, cleanup).
Cần kỷ luật trong việc ghi nhớ để tránh nhiễu.
Tốn thời gian tinh chỉnh ngưỡng (threshold) và top-k retrieval.

Lộ trình triển khai khuyến nghị

Để tránh việc quá sa đà vào kỹ thuật (over-engineer), bạn nên:

Bắt đầu với File-based memory và thiết lập policy rõ ràng.
Kích hoạt Semantic memory store (LanceDB hoặc pgvector).
Thêm Compaction cron.
Sau 1 tuần mới tiến hành benchmark và tinh chỉnh (tune).

Tại sao nên dùng Vaultwarden để quản lý secret key cho dàn AI Agent

Duy Nghiện — Tue, 17 Feb 2026 11:43:42 +0000

Hello anh em,

Mình đang đang dùng hệ automation nội bộ, combo gồm: OpenClaw, n8n, một mớ MCP server, và Cloudflare Tunnel để public 1 vài app ra ngoài internet.

Lúc đầu mọi thứ rất vui, cho đến khi cái đống Secrets (API Key, Token) bắt đầu nhiều lên.

Nào là key OpenAI, token Telegram, mật khẩu SMTP gửi mail, token tunnel, cookie đăng nhập web... Ban đầu mình cứ ném hết vào file .env cho tiện. Nhưng càng làm thì cái file .env nó càng nhiều lên, bắt đầu khó xem và quản lý:

Copy sang máy khác là lệch tên, chạy không được.
Muốn đổi key thì phải đi sửa từng chỗ, bực nhất cái này.
Sợ nhất là lỡ tay paste nhầm cái .env lên nhóm chat hay GitHub là xác định toang.

Sau nghĩ lại thì thấy OpenClaw có cái skill 1Password nên định dùng, nhưng mà nó mất phí subscription, cũng rẻ thôi đâu đó $2.99/tháng. Nhưng mình cũng đang self-hosting một bài ứng dụng nên sẵn đấy tìm 1 phiên bản open-source để dùng. Và mình quyết định dựng Vaultwarden (bản self-hosted siêu nhẹ của Bitwarden) để làm cái kho tổng quản lý đám key này. Dưới đây là lý do tại sao và cách mình dùng nó.

1. Vaultwarden là gì và tại sao lại hợp?

Nói đơn giản, Vaultwarden là một cái server giữ mật khẩu (password manager) mà anh em tự host được, viết bằng Rust nên ăn cực ít RAM.

Với anh em làm automation, "mật khẩu" không chỉ là user/pass. Nó là tất cả những thứ nhạy cảm:

API Key (OpenAI, Anthropic...).
URL của mấy con MCP server (thường có token dính trong URL).
Token bot Telegram/Discord.
Hay là Cookie/Session của trình duyệt để agent đỡ phải login lại.

Thay vì rải rác mỗi nơi một tí, giờ mình gom tất cả về một mối: Single Source of Truth.

Hướng dẫn self-hosted Vaultwarden: Hướng dẫn cài đặt Vaultwarden trên Ubuntu

2. Dùng Vaultwarden sướng ở chỗ nào?

Bớt cái tật tiện tay

Cái chết của ae là sự tiện lợi. Tiện tay gửi key qua Zalo, tiện tay note vào file text... Dùng Vaultwarden ép mình vào khuôn khổ: cần key thì mở Vault copy, hạn chế tối đa việc key lộ ra ngoài.

Quản lý ngăn nắp

Trước mình dùng n8n thì hay lưu API key các nền tảng và note của Apple, nhưng mà test nhiều công cụ giờ nó dài mấy trang toàn là API key.

Nên dù là dùng cá nhân, mình vẫn chia key theo từng nhóm để dễ quản lý:

Nhóm Social: Key Facebook, X, Telegram.
Nhóm Automation: Key n8n, webhook.
Nhóm Infra: SSH key, token server, Cloudflare.

Nhìn vào là biết key nào thuộc về đâu, không còn cảnh một file .env gánh cả thế giới.

Đổi key (Rotate) không lo chết chùm

Khi nghi ngờ lộ key, mình chỉ cần đổi trong Vaultwarden, rồi chạy script update lại cho các service là xong. Không phải mò mẫm xem "cái key này đang nằm ở những file nào".

Agent không cần nhớ password

Với mấy con agent cần login web (như X hay LinkedIn), mình không lưu password cứng trong code. Mình lưu session/cookie, hoặc lưu key mã hóa state trong Vault. Agent khởi động lên, lấy key giải mã session rồi chạy tiếp. An toàn hơn nhiều.

3. Điểm trừ và lưu ý, ae nên đọc cái này

Dĩ nhiên không có gì hoàn hảo:

Nó không tự điền vào .env cho anh em đâu: Vaultwarden chỉ là chỗ lưu. Để agent chạy được, anh em vẫn cần một bước "lấy key từ Vault bỏ vào .env".
Cách mình làm: Code một cái script nhỏ, mỗi lần deploy hoặc update service thì nó tự kéo key từ Vault về, ghi vào .env rồi chmod 600 để chỉ owner mới đọc được.
Sập Vault là sập tất:
Gom trứng vào một giỏ thì phải giữ cái giỏ cho kỹ. Vault mà down là hệ thống không lấy được key mới.
Giải pháp: Luôn có backup định kỳ. Và với các service quan trọng, .env đóng vai trò là cache. Vault chết thì service vẫn chạy bằng .env cũ được.
Bảo mật phải làm tới nơi:
Đã self-host cái kho lưu toàn đồ nhạy cảm thì hãy bật HTTPS, cài 2FA, và đừng public nó ra internet vô tội vạ.

4. Tóm lại là khi nào nên dùng?

Nếu anh em chỉ có 1 con server, 2-3 cái API key: Thôi, dùng .env cho lẹ.
Nếu anh em bắt đầu có: OpenClaw + n8n + chục cái MCP + server ở nhà + VPS: Thì triển khai Vaultwarden ngay và luôn đi.

Nó không giúp AI của anh em thông minh hơn, nhưng nó giúp anh em ngủ ngon hơn vì biết đống key của mình đang nằm gọn gàng một chỗ, không bay lung tung trên mạng.

Chúc anh em quản lý đám agent hiệu quả và không bao giờ bị lộ key!

AI & Automation (vnROM): Duy Nghiện

/dreaming trong OpenClaw version 2026.4.5

1. /dreaming là gì?

2. Ba giai đoạn hoạt động (Light - REM - Deep)

3. Những gì Dreaming ghi lại?

4. Cách kích hoạt và cấu hình cũng rất đơn giản

5. Công cụ kiểm soát và Dreams UI

6. Lợi ích thực tế

7. Lưu ý

Vì sao OpenClaw cần tối ưu lại memory?

Vì sao tối ưu memory lại quan trọng?

1) Giảm nhiễu, tăng độ đúng

2) Giữ thứ tự ưu tiên giữa các lớp memory

3) Tăng hiệu suất cho multi-agent

4) Giảm chi phí ngầm

Tối ưu bằng cách nào?

1) Dedupe trước khi write

2) Tách rõ “fact”, “decision”, “hypothesis”, “handoff”

3) Chỉ promote thứ đã được verify

4) Đặt TTL cho memory mang tính tác vụ

5) Có lịch vệ sinh memory định kỳ

Khi nào cần tối ưu lại memory?

1) Agent bắt đầu trả lời đúng kiểu na ná đúng

2) Cùng một fact xuất hiện ở nhiều file/layer

3) Retrieval ra quá nhiều kết quả có vẻ liên quan nhưng ít cái thật sự hữu ích

4) Multi-agent handoff hay bị trượt

5) Chi phí context tăng lên rõ rệt

6) Sau vài tuần hoặc vài tháng làm việc liên tục

Hướng dẫn sử dụng ClawTask cho người mới

Nhìn nhanh các khu vực chính

Luồng bắt đầu cho người mới

1. Tạo tài khoản

2. Đăng nhập

Việc cần làm sau khi đăng nhập lần đầu

Cách dùng Tasks

Chế độ xem

Vòng đời task

Tạo task tốt

Clarification là gì

Notebook và task

Cách dùng Agents

Bạn có thể làm gì ở đây

Điều cần hiểu về API key

Agent kết nối vào đâu

Luồng agent cơ bản

Notebooks dùng khi nào

Những lỗi người mới hay gặp

"Đăng ký xong mà chưa vào được dashboard"

"Quên lưu API key"

"Agent không nhận task"

"Task bị blocked mà không thấy output"

Build một workflow deep research thực tế với OpenClaw, Codex multi-agents và ACP

Vì sao mình build skill này

Vì sao thời điểm này mình mới làm nó?

Codex vừa có multi-agents

ChatGPT Plus đang là một lợi thế

OpenClaw đã có ACP (acpx)

Vấn đề thật sự của deep research trên web chat

1. Không có single workflow rõ ràng

2. Khó tái sử dụng

3. Citation và nội dung thừa

4. Khó automation

Skill codex-deep-research giải bài toán gì

Lớp 1: Research engine

Lớp 2: Artifact-aware output

Lớp 3: Preset + compliance

Tại sao OpenClaw + ACP lại hợp bài này

Skill này có thay được web chat không?

Câu chuyện thật sự đằng sau skill này

ClawTask: bảng điều phối công việc cho đội OpenClaw

Vấn đề mình thấy ở đa số workflow AI hiện tại

ClawTask là gì

Vì sao mình nghĩ nó hợp với cộng đồng AI & Automation

Một vài điểm kỹ thuật đáng chú ý

1. MCP + REST đều có

2. Clarification là tính năng rất thực tế

3. Notebook không phải đồ trang trí

4. Recurring task hữu ích cho ops

ClawTask không phải gì

Use case mình nghĩ dễ thấy giá trị

OpenClaw đã có ACP (`acpx`)

Skill `codex-deep-research` giải bài toán gì