AI & Automation (vnROM): addROM

(Thủ thuật) Khai thác sức mạnh "ẩn" của Claude: Kết nối Microsoft Clarity qua MCP để x3 Tỷ lệ chuyển đổi Landing Page

addROM — Thu, 16 Apr 2026 05:24:29 +0000

Chào anh em,

Gần đây mình vừa vọc vạch và phát hiện ra một connector MIỄN PHÍ trong Claude đang thay đổi hoàn toàn cách mình chạy Facebook Ads — và khá bất ngờ là gần như chưa thấy anh em nào ở VN chia sẻ về workflow này.

Tên của "vũ khí" này là Microsoft Clarity.

Anh em chạy Ads chắc đều quá quen với cảm giác này: Đổ đống tiền vào chiến dịch, mải mê tối ưu CTR, gồng mình vít CPM, test hàng chục mẫu creative... nhưng lead trả về vẫn đắt lòi mắt. Vì sao?

Vì đa số mọi người chỉ đang tối ưu Part 1 của phễu (Funnel) — tức là cái Ad. Còn Part 2 — cái Landing Page, nơi khách hàng thực sự đưa ra quyết định điền form hay thoát trang — thì chúng ta gần như mù tịt.

Và đây là lúc combo Microsoft Clarity + Claude vào cuộc.

1. Microsoft Clarity là gì?

Dành cho anh em chưa biết, Clarity là một công cụ phân tích hành vi người dùng cực mạnh và hoàn toàn miễn phí từ Microsoft. Nó cung cấp cho anh em:

Heat map (Bản đồ nhiệt): Trực quan hóa chỗ nào khách nhìn nhiều nhất, chỗ nào họ lướt qua.
Session recording: Quay lại video từng phiên khách truy cập trên trang (họ click gì, dừng ở đâu, thoát ra lúc nào).
Tracking nâng cao: Đo lường Scroll depth (độ cuộn trang), dead clicks (click chết), error tracking — tất cả đều real-time.

Việc cài đặt cực kỳ đơn giản, gắn qua Google Tag Manager (GTM) mất đúng 5 phút là xong.

2. Sự "điên rồ" khi kết nối với Claude qua Connector

Clarity bản thân nó đã ngon, nhưng phần "ăn tiền" nhất nằm ở đây: Khi anh em kết nối Clarity vào Claude qua connector tích hợp (Customize → Connectors → Microsoft Clarity), anh em đang biến Claude thành một Data Analyst thực thụ.

Nhờ tận dụng giao thức kết nối dữ liệu máy chủ (MCP - Model Context Protocol), bạn có thể giao tiếp và truy vấn trực tiếp kho dữ liệu hành vi bằng ngôn ngữ tự nhiên:

"Khách drop-off (thoát trang) nhiều nhất ở đoạn nào trên landing page trong 7 ngày qua?"
"So sánh hành vi của nguồn traffic từ YouTube so với Paid Ads trên funnel này."
"Mobile vs Desktop, bên nào có tỷ lệ convert cao hơn? Phân tích lý do."
"Dead clicks đang xảy ra ở đâu — chỗ nào khách tưởng click được mà bấm không ăn?"

Không cần tự căng mắt xem hàng trăm cái video recording, Claude sẽ tự động đọc toàn bộ data + heat map, sau đó trả về những insight sắc lẹm kèm số liệu cụ thể.

3. Thực tế áp dụng và kết quả

Mình đã test thử và Claude chỉ ra một sự thật phũ phàng: 78% khách không scroll quá 25% trang. Nguyên nhân do cái Headline đang quá yếu. Mình lập tức sửa đổi và break form opt-in thành 2 bước để giảm ma sát (friction). Kết quả là conversion rate (tỷ lệ chuyển đổi) tăng lên rõ rệt.

Một case khác còn ảo diệu hơn: Khi yêu cầu Claude đối chiếu traffic, nó phân tích ra luồng từ YouTube convert gấp 3.2 lần so với Paid Ads (60% vs 20%). Nhờ data này, mình biết cần phải xây 2 Landing Page với flow nội dung khác nhau cho 2 tệp traffic — một insight mà nếu đoán mò theo cảm tính thì không bao giờ nghĩ ra được.

Đây mới chính là CRO (Conversion Rate Optimization) thực sự.

Workflow tự động hóa hiện tại của mình: Mỗi tuần lên 1 split test cho funnel. Sau 7 ngày, ném dữ liệu Clarity cho Claude đọc và để AI quyết định tuần tiếp theo cần test biến số nào. Cứ setup guồng như vậy, funnel sẽ tự động được mài dũa qua từng tuần.

Tóm lại: Đừng chỉ chăm chăm tối ưu Ads. Ads chỉ làm nhiệm vụ mở cửa mời khách vào, nhưng Funnel mới là thứ giữ tiền lại trong túi anh em. Bạn không thể tối ưu những thứ mà bạn không nhìn thấy!

Anh em nào đam mê build các hệ thống tự động hóa, hoặc thích setup các AI workflow quản trị dữ liệu sâu thì nhất định phải thử bài này nhé. Chúc anh em vít Ads hiệu quả!

Từ 0 đến 10.000 USD/tháng: cách một người có thể ra mắt sản phẩm SaaS trong thời AI

addROM — Fri, 10 Apr 2026 04:56:26 +0000

Nhiều người vẫn nghĩ muốn làm ra một sản phẩm phần mềm nghiêm túc thì phải có đội ngũ, vốn đầu tư và ít nhất vài tháng đến cả năm phát triển. Cách nghĩ đó từng đúng. Nhưng ở thời điểm hiện tại, nó đang nhanh chóng lỗi thời.

Sự kết hợp giữa boilerplate mã nguồn mở, hạ tầng backend dựng sẵn, công cụ AI hỗ trợ lập trình và nền tảng triển khai tự động đã khiến việc ra mắt một sản phẩm nhỏ trở nên nhẹ hơn rất nhiều. Thay vì dành hàng tuần để dựng nền móng, một cá nhân giờ có thể tập trung vào phần quan trọng nhất: giải quyết một nỗi đau thật của người dùng và đưa nó ra thị trường càng sớm càng tốt.

1. Đừng xây lại những thứ không tạo ra lợi thế

Sai lầm phổ biến nhất của người mới làm sản phẩm là dành quá nhiều thời gian cho những phần “bắt buộc phải có” nhưng không thực sự tạo ra khác biệt: đăng nhập, thanh toán, email, landing page, admin, upload file, phân quyền…

Đó đều là hạ tầng. Hạ tầng thì nên tái sử dụng, không nên phát minh lại từ đầu.

Ví dụ là Open SaaS — một bộ khởi tạo sản phẩm SaaS tích hợp sẵn nhiều phần cốt lõi. Điểm đáng chú ý không chỉ là có sẵn auth hay payments, mà còn là việc nó được chuẩn bị để làm việc tốt với AI coding tools như Claude Code. Những file như AGENTS.md hay llms.txt giúp AI hiểu cấu trúc dự án, tài liệu và cách hệ thống được tổ chức, từ đó sinh mã “ăn khớp” với kiến trúc thay vì vá chỗ này hở chỗ kia.

Nếu stack đó không hợp, vẫn còn rất nhiều lựa chọn khác trong các bộ sưu tập boilerplate mã nguồn mở. Ý chính ở đây không phải là phải dùng đúng một công cụ, mà là: đừng đốt 2–3 tuần chỉ để dựng lại một bộ khung mà cộng đồng đã làm quá tốt rồi.

Khi bỏ qua phần việc lặp lại này, bạn có thêm thời gian cho thứ thực sự đáng đầu tư: bài toán người dùng, trải nghiệm sản phẩm và tốc độ ra bản đầu tiên.

2. Backend giờ không còn là nút thắt lớn nhất

Nếu trước đây dựng backend thường đồng nghĩa với việc phải lo database, xác thực, lưu trữ file, realtime và cả deployment, thì giờ nhiều thứ đó đã được gom vào một lớp dịch vụ gần như “cắm là chạy”.

Một ví dụ khác là Supabase: PostgreSQL, auth, storage và realtime nằm trong cùng một hệ sinh thái. Với một MVP hoặc sản phẩm mới ra mắt, tầng miễn phí thường đã đủ để bắt đầu.

Điểm hay hơn nằm ở cách những công cụ này đang hòa vào quy trình làm việc với AI. Khi CLI và workflow triển khai được nối sẵn, AI không chỉ viết migration mà còn có thể hỗ trợ đưa thay đổi lên database nhanh hơn, nhất quán hơn. Nghĩa là phần backend cơ bản không còn là rào cản kỹ thuật quá lớn đối với một solo builder như trước.

Một ý đáng chú ý khác từ nguồn gốc là các đội ngũ kỹ thuật của chính những nền tảng này cũng đang tạo ra “skill” hoặc tài liệu chuyên biệt cho AI agent. Điều đó có nghĩa là thay vì mỗi lần cần truy vấn SQL hay viết migration lại phải giải thích từ đầu, bạn đang làm việc với một lớp trợ lý ngày càng hiểu ngữ cảnh công cụ tốt hơn.

Nói ngắn gọn: backend chưa bao giờ biến mất, nhưng chi phí để có một backend đủ tốt cho giai đoạn đầu đã giảm mạnh.

3. AI không chỉ viết code, nó đang rút ngắn vòng học và làm

Phần thú vị nhất không nằm ở chỗ “AI có thể code”, mà ở chỗ AI có thể được biến thành một cộng sự hiểu dự án ngày một sâu hơn nếu bạn cung cấp đúng ngữ cảnh.

Ví dụ như Repomix được nhắc đến như một cách để đóng gói toàn bộ repository thành định dạng thân thiện hơn với AI. Vấn đề cố hữu của coding assistant là thiếu bối cảnh: dự án có hàng trăm file, nhiều module, nhiều quy ước ngầm; AI chỉ nhìn thấy vài đoạn mã thì rất dễ sinh ra giải pháp lệch kiến trúc. Khi toàn bộ repo được nén và trình bày lại hợp lý, chất lượng hỗ trợ thay đổi hẳn.

Từ đó, lợi ích lớn nhất không chỉ là “viết nhanh hơn”, mà là:

AI hiểu dự án hơn nên ít phá cấu trúc hơn
bạn bớt thời gian giải thích lặp lại
việc học từ các dự án mã nguồn mở khác cũng nhanh hơn nhiều

Ngày càng nhiều công ty như Stripe, Google, Vercel… có tài nguyên hoặc skill chính thức để AI làm việc với hệ sinh thái của họ. Đây là một thay đổi quan trọng. Trước kia, tích hợp dịch vụ nghĩa là dành hàng ngày đọc docs. Bây giờ, nếu AI đã “biết nghề” ở mức đủ sâu trong từng hệ sinh thái, tốc độ tích hợp tăng lên đáng kể.

Nói cách khác, AI không chỉ là người viết code hộ. Nó đang dần trở thành bộ khuếch đại năng lực học công cụ, đọc kiến trúc và nối hệ thống.

4. Muốn khác biệt, hãy nghĩ tới AI như một tính năng của sản phẩm

Một luận điểm khá mạnh trong nguồn là: ở giai đoạn hiện nay, AI trong sản phẩm không còn là “nice to have” nữa. Trong nhiều ngách, nó bắt đầu trở thành lớp khác biệt cạnh tranh.

Điều này không có nghĩa mọi sản phẩm đều phải nhồi chatbot vào giao diện. Ý nghĩa thật sự là: liệu AI có thể giúp người dùng tiết kiệm thời gian, ra quyết định nhanh hơn, hoặc tự động hóa một phần công việc vốn đang thủ công hay không?

Để thử nghiệm nhanh, có thể sử dụng Flowise như cách dựng agent hoặc luồng AI theo kiểu kéo-thả, không cần code quá nhiều. Cách này hợp khi bạn muốn kiểm chứng ý tưởng nhanh: nối model, tài liệu và giao diện chat để xem người dùng có thật sự cần tính năng đó không.

Còn nếu sản phẩm cần logic nhiều bước, đọc tài liệu khách hàng, kết nối nhiều model, hoặc xây workflow phức tạp hơn, thì những framework như LangChain sẽ phù hợp hơn. Tư duy nên là:

thử nhanh bằng công cụ đơn giản khi chưa chắc nhu cầu
chuyển sang framework mạnh hơn khi đã thấy tín hiệu thị trường rõ ràng

Điểm đáng học ở đây không phải tên công cụ, mà là chiến lược: đừng xây AI cho oách; hãy thêm AI đúng nơi nó tạo ra giá trị mà người dùng sẵn sàng trả tiền.

5. Triển khai và thu tiền giờ là phần dễ chuẩn hóa nhất

Sau khi có sản phẩm đầu tiên, hai câu hỏi thực tế nhất luôn là: “đưa nó lên đâu?” và “thu tiền bằng gì?”.

Ở đây, hệ sinh thái hiện tại gần như đã trả lời sẵn.

Về triển khai, những nền tảng như Vercel biến việc đưa ứng dụng lên môi trường thật thành một thao tác gần như tự động: đẩy code, preview cho từng pull request, có SSL sẵn, có CDN sẵn. Với sản phẩm nhỏ và MVP, từng đó thường đã quá đủ.

Về thanh toán, Stripe gần như là lựa chọn mặc định trong rất nhiều stack hiện đại. Khi phần tích hợp thanh toán đã có sẵn trong boilerplate, thứ bạn còn lại phải quyết định chủ yếu là:

mô hình giá
gói dịch vụ
webhook và một vài luồng nghiệp vụ đi kèm

Nói cách khác, bottleneck không còn nằm ở “liệu mình có làm được thanh toán không”, mà ở “mình nên bán cái gì và định giá ra sao”. Đó là một thay đổi rất lớn.

6. Thứ cần theo đuổi không phải là một triệu người dùng

Bạn không nhất thiết phải xây thứ gì đó cho hàng triệu người. Với nhiều sản phẩm nhỏ, điều thực tế hơn là tìm một nhóm khách hàng hẹp nhưng có nhu cầu đủ đau, rồi làm một giải pháp giúp họ tiết kiệm thời gian hoặc kiếm thêm tiền.

Nguồn gốc đưa ra một hình ảnh khá rõ: thay vì mơ về quy mô khổng lồ, hãy nghĩ đến vài trăm người dùng trả tiền thực sự. Chỉ cần vài trăm người thấy sản phẩm đáng giá mỗi tháng, một business nhỏ nhưng khỏe đã có thể hình thành.

Đây là tư duy rất quan trọng với người làm micro-SaaS hoặc indie product:

không cần thị trường khổng lồ ngay từ đầu
không cần sản phẩm hoàn hảo trước khi ra mắt
không cần đội ngũ lớn để bắt đầu

Cái cần là chọn đúng nỗi đau, ra mắt đủ nhanh, rồi lặp lại liên tục dựa trên phản hồi thật.

7. Mẫu số chung của các case thành công

Dù các con số có thể mang tính truyền cảm hứng nhiều hơn là dữ liệu kiểm chứng đầy đủ, mẫu số chung mà chúng chỉ ra vẫn đáng để giữ lại:

tìm một vấn đề đủ rõ
dựng phiên bản tối thiểu càng sớm càng tốt
kiếm những người dùng trả tiền đầu tiên
tiếp tục chỉnh sửa dựa trên phản hồi thật

Đây là chu trình kinh điển, nhưng AI và hạ tầng hiện đại đã làm cho mỗi vòng lặp diễn ra nhanh hơn nhiều. Đó mới là thay đổi bản chất.

Điều đang thay đổi không phải chỉ là bộ công cụ. Điều thay đổi là ngưỡng để một người bắt đầu xây sản phẩm đã thấp hơn rất nhiều.

Bạn vẫn cần óc quan sát, khả năng chọn vấn đề đúng và sự kiên trì để đi qua nhiều vòng thử-sai. AI không thay bạn làm phần đó. Nhưng nó đã giúp giảm đáng kể thời gian, chi phí và độ nặng kỹ thuật của giai đoạn khởi đầu.

Đừng bắt đầu bằng việc xây mọi thứ; hãy bắt đầu bằng việc loại bỏ những gì không cần tự xây, để tập trung vào thứ người dùng thực sự cần.

Và khi làm được điều đó, một cá nhân cũng có thể đi nhanh hơn rất nhiều so với cách làm sản phẩm của vài năm trước.

Từ Prompt Engineering đến Harness Engineering - Cách làm chủ AI tốt hơn

addROM — Mon, 06 Apr 2026 05:52:38 +0000

Bạn đã từng nghe AI viết code siêu nhanh, nhưng rồi… nó “quên” mục tiêu giữa chừng, làm loạn file, hoặc đưa ra code lỗi lặp đi lặp lại chưa?

Đó chính là lúc Harness Engineering xuất hiện – khái niệm đang “bùng nổ” trong cộng đồng AI năm 2026. Không phải kỹ thuật mới để AI “thông minh hơn”, mà là cách để chúng ta kiểm soát và tin tưởng AI như kiểm soát một con ngựa hoang.

Hãy hình dung đơn giản thế này

Model (bộ não AI): Là con ngựa thông minh, chạy rất nhanh, có thể suy nghĩ sáng tạo. Nhưng nó đôi khi “nổi điên”, quên đường, hoặc chạy lung tung.
Harness (dây cương + yên ngựa + dây buộc + la bàn): Là tất cả những thứ còn lại – môi trường chạy, quy tắc, công cụ, bộ nhớ, kiểm tra tự động, feedback loop… giúp con ngựa không lạc đường, không làm hỏng đồ, và biết dừng lại khi sai.

Agent = Model + Harness.

Harness Engineering chính là nghệ thuật thiết kế, xây dựng và cải tiến “dây cương” đó để AI agent làm việc đáng tin cậy ở quy mô sản xuất, chứ không chỉ “chat vui vui”.

Nói cách khác:

Prompt Engineering = Nói cho ngựa nghe “hôm nay chạy theo hướng này nhé”.
Context Engineering = Đưa cho ngựa bản đồ chi tiết.
Harness Engineering = Xây dựng cả chuồng ngựa, dây cương, yên ngựa, camera theo dõi, và hệ thống tự sửa lỗi – để dù ngựa có “quên” cũng vẫn chạy đúng.

Tại sao nó lại hot đến vậy?

Khái niệm này đang nhận được sự quan tâm mạnh mẽ từ những chuyên gia và tổ chức hàng đầu thế giới:

Mitchell Hashimoto (@mitchellh) – cha đẻ của Terraform – là một trong những người đầu tiên phổ biến thuật ngữ “Harness Engineering”. Ông nhấn mạnh đây chính là cách xây dựng toàn bộ “dây cương” (ràng buộc, công cụ, tài liệu và vòng lặp phản hồi) để AI agent không bao giờ lặp lại lỗi cũ.
Martin Fowler (@martinfowler) – nhà tư tưởng phần mềm có ảnh hưởng nhất hành tinh – đã viết bài phân tích sâu và chia sẻ trên X, coi Harness Engineering là khung tư duy then chốt giúp AI coding agents đáng tin cậy hơn.
OpenAI trong bài blog chính thức kể câu chuyện một team nhỏ chỉ dùng Codex + Harness Engineering đã xây dựng hơn 1 triệu dòng code cho sản phẩm nội bộ mà gần như không cần engineer gõ tay một dòng nào.
LangChain team (@LangChain) chia sẻ trên X rằng họ chỉ tối ưu harness thôi đã đẩy coding agent của mình từ hạng Top 30 lên Top 5 trên benchmark TerminalBench.

Những ví dụ thực tế từ các “ông lớn” này chứng tỏ: Harness Engineering không chỉ là lý thuyết suông, mà đang là bí quyết giúp AI agent đi từ “trợ lý thông minh” thành lực lượng lao động thực thụ, đáng tin cậy ở quy mô sản xuất.

Harness Engineering làm những gì cụ thể?

Một harness tốt thường có các bộ phận sau (dễ hình dung):

Môi trường chạy (Execution Environment): Chạy trong container riêng, có checkpoint (điểm lưu tiến độ) để AI không mất hết công sức nếu crash.
Công cụ & Quy tắc (Tools + Guardrails): Chỉ cho phép AI dùng lệnh an toàn, tuân thủ kiến trúc code đã định sẵn (ví dụ: phải có test trước khi merge).
Bộ nhớ & Trạng thái (Memory & State): AGENTS.md, database, filesystem ảo… để AI nhớ “mình đang làm gì” qua nhiều giờ/ngày.
Feedback Loop: AI tự review code, chạy test, linter, thậm chí tự sửa lỗi trước khi đưa cho con người xem.
Garbage Collection: Quét định kỳ để dọn rác code, sửa drift (lạc hướng).

Kết quả? OpenAI từng dùng Codex (agent của họ) xây dựng hơn 1 triệu dòng code cho một sản phẩm nội bộ mà không một dòng nào do con người gõ tay. Toàn bộ là nhờ harness được thiết kế tốt.

Tương lai của lập trình viên chúng ta?

Không phải “AI thay thế coder”.

Mà là: coder chuyển từ “viết code” sang “thiết kế harness” – xây dựng hệ thống để AI tự làm việc hiệu quả, an toàn và có thể scale.

Bạn vẫn cần hiểu business, thiết kế hệ thống, đặt ra quy tắc. Nhưng thay vì debug từng dòng, bạn debug cả “dây cương” để lần sau AI không bao giờ mắc lỗi tương tự.

Harness Engineering không phải xu hướng nhất thời. Nó là bước tiến hóa logic: từ Prompt → Context → Harness → và sau này có thể là “Agentic Engineering” đầy đủ.

Bạn đang dùng AI coding agent nào (Claude Code, Cursor, Devin, hay tự build)?

Bạn đã bắt đầu xây harness chưa?

Comment bên dưới chia sẻ kinh nghiệm của bạn đi!

Harness Engineering – không phải làm AI thông minh hơn, mà là làm chúng ta tin tưởng AI hơn. Và đó mới là chìa khóa để AI thực sự thay đổi cách chúng ta làm việc trong năm 2026 này.

18 mẹo tiết kiệm token khi dùng Claude Code (tăng hiệu quả 2–5 lần)

addROM — Fri, 03 Apr 2026 18:28:29 +0000

Gần đây thấy nhiều người phản ánh Claude Code bị hết token rất nhanh, kể cả gói $200/tháng. Mình tổng hợp lại nội dung từ một video khá hữu ích để anh em tham khảo.

1. Vấn đề cốt lõi

Mỗi lần bạn gửi prompt, Claude sẽ đọc lại toàn bộ cuộc hội thoại từ đầu.

Điều này dẫn đến:

Token không tăng tuyến tính mà tăng theo cấp số nhân
Chat càng dài → chi phí càng cao

Ví dụ:

Message đầu: ~500 tokens
Message thứ 30: ~15,000 tokens

Có trường hợp lên tới 98.5% token chỉ dùng để đọc lại lịch sử chat.

Ngoài ra:

Context càng dài → chất lượng output càng giảm
Hiện tượng “loss in the middle” khiến nội dung ở giữa bị bỏ qua

2. Tier 1 – Mẹo cơ bản

Luôn dùng chat mới cho task mới

Sử dụng /clear khi đổi chủ đề.

Đây là cách đơn giản nhưng hiệu quả nhất để tiết kiệm token.

Gộp nhiều yêu cầu vào một prompt

Thay vì gửi nhiều message liên tiếp, hãy gộp lại thành một.

Chỉ gửi phần cần thiết

Không nên paste toàn bộ file hoặc repo.
Chỉ gửi đúng đoạn code hoặc phần liên quan.

Dùng plan mode trước khi thực hiện

Giúp AI hiểu rõ yêu cầu trước khi làm, tránh đi sai hướng.

Tắt các MCP server không cần thiết

Một số server có thể tiêu tốn hàng chục nghìn token mỗi message.

Theo dõi token usage

Sử dụng:

/context
/cost

Để biết token đang bị tiêu ở đâu.

Quan sát quá trình AI làm việc

Nếu thấy đi sai hướng, dừng ngay để tránh lãng phí token.

3. Tier 2 – Tối ưu nâng cao

Giữ file `claude.md` ngắn gọn

Dưới 200 dòng
Chỉ chứa thông tin quan trọng

File này được đọc lại mỗi lần chat.

Chỉ định rõ file hoặc function

Tránh yêu cầu chung chung như “check toàn bộ repo”.

Compact context sớm

Nên compact khi khoảng 60%, không nên đợi đến 95%.

Tránh nghỉ giữa chừng quá lâu

Nếu nghỉ hơn 5 phút, hệ thống sẽ mất cache và tính lại token từ đầu.

Hạn chế output quá dài

Command output lớn sẽ làm tăng token đáng kể.

4. Tier 3 – Nâng cao

Chọn model phù hợp

Sonnet: sử dụng mặc định
Haiku: task đơn giản
Opus: task phức tạp

Hạn chế dùng sub-agent

Sub-agent có thể tiêu tốn nhiều hơn 7–10 lần token so với bình thường.

Tận dụng thời gian off-peak

Giờ thấp điểm giúp session kéo dài hơn.

Tối ưu file `claude.md`

Biến nó thành nơi lưu:

Quyết định
Quy tắc
Kiến trúc

Không lưu toàn bộ hội thoại.

Mindset quan trọng

Đây không phải là vấn đề giới hạn token thấp.

Vấn đề chính là cách quản lý context.

Để tiết kiệm token:

Giữ context ngắn
Tránh chat kéo dài
Cung cấp thông tin chính xác
Kiểm soát quá trình làm việc của AI

Tóm lại: không phải Claude đắt, mà là cách sử dụng chưa tối ưu.

Anh em đang dùng Claude Code có gặp tình trạng tương tự không? Có cách nào hay hơn thì chia sẻ thêm.

Hướng dẫn chi tiết tăng quota Antigravity bằng 9Router

addROM — Fri, 03 Apr 2026 15:14:26 +0000

Antigravity của Google là một môi trường AI dành cho lập trình viên với khả năng sinh mã, tự động hoá và quản lý agent. Khi mới ra mắt, phiên bản Pro cung cấp giới hạn được làm mới mỗi 5 giờ.

Từ giữa tháng 3/2026, Google thay đổi cấu trúc tính quota:

Ngoài giới hạn 250 đơn vị mỗi 5 giờ, người dùng còn bị ràng buộc bởi định mức 2 800 đơn vị mỗi tuần.
Hai giới hạn phải còn dư thì Antigravity mới hoạt động; nếu hết định mức tuần, việc chờ 5 giờ không khôi phục quota.
Các model nặng như Claude Opus tiêu thụ gấp ~8 lần quota so với Claude Sonnet, trong khi Gemini 3 Flash dùng ít quota nhất.

9Router là công cụ nguồn mở giúp tối ưu chi phí và quota AI. Nó hoạt động như một “router” thông minh giữa các công cụ AI khác nhau và hơn 40 nhà cung cấp mô hình. 9Router theo dõi quota, tự động chuyển sang nhà cung cấp giá rẻ hoặc miễn phí khi hết định mức.

Lợi ích khi dùng 9Router với Antigravity

Tối đa hoá gói đăng ký: Theo dõi quota cho từng tài khoản và mô hình để sử dụng triệt để trước khi hết hạn.
Đa tài khoản: Kết nối nhiều tài khoản Google/Antigravity; 9Router tự động xoay vòng API khi một tài khoản hết quota.
Chuyển đổi ba tầng: Tự động rơi xuống nhà cung cấp giá rẻ (GLM, MiniMax) hoặc mô hình miễn phí (iFlow, Qwen, Kiro) khi hết quota chính.
Hỗ trợ nhiều công cụ: Dùng một endpoint duy nhất cho Claude Code, Codex, Gemini CLI, Cursor, v.v.
Theo dõi sử dụng: Dashboard hiển thị thống kê token và chi phí ước tính (9Router không thu phí người dùng).

Cài đặt và khởi tạo

1. Chuẩn bị môi trường

9Router chạy trên Node.js. Trên Windows, mở PowerShell/Command Prompt với quyền Administrator và chạy lệnh:

npm install -g 9router
9router

Sau khi chạy, bảng điều khiển sẽ mở tại: http://localhost:20128.

2. Kết nối nhà cung cấp và tạo API key

Mở giao diện Web: Truy cập http://localhost:20128/dashboard.
**Thêm nhà cung cấp mà bạn có, ví dụ như Codex từ gói ChatGPT, free từ Kiro, iFlow, Qwen Code, hay các gói coding khác của Kimi, MiniMax, Github Copilot ... (không nên dùng các gói của chính Antigravity vì rất dễ ban).
Tạo API key: Vào mục Endpoint → Generate API key. Endpoint mặc định là http://localhost:20128/v1.

3. Cấu hình IDE/Antigravity

Trong cài đặt IDE hoặc CLI, điền các thông số:

Endpoint: http://localhost:20128/v1
API Key: Dán key vừa tạo.
Model: Thử nghiệm trước với các model miễn phí như if/kimi-k2-thinking.

Xử lý chứng chỉ (Certificate)

9Router sử dụng mitmproxy để "đánh chặn" và điều hướng yêu cầu. Hệ điều hành cần tin tưởng chứng chỉ CA để giải mã lưu lượng HTTPS.

[!CAUTION]
Cảnh báo an toàn: Cài đặt root CA cho phép 9Router giải mã lưu lượng HTTPS. Chỉ thực hiện trên máy cá nhân và hiểu rõ rủi ro bảo mật.

Các bước thực hiện trên Windows:

Nhấn Win + R, gõ %APPDATA%, vào thư mục 9router\mitm và sao chép file rootCA.crt.
Nhấn Win + R, gõ certlm.msc để mở trình quản lý chứng chỉ máy tính.
Tìm đến: Trusted Root Certification Authorities → Certificates.
Chuột phải → All Tasks → Import. Chọn file rootCA.crt và làm theo hướng dẫn.
Kiểm tra trên giao diện 9Router: Góc trên bên phải hiện biểu tượng ✅ Cert và ✅ Trusted.

Lưu ý: Trên macOS/Linux, truy cập mitm.it sau khi cấu hình proxy để cài đặt.

Cấu hình đánh chặn cho Antigravity

Kích hoạt DNS: Trong giao diện 9Router, nhấp Antigravity → Nhấn nút Start DNS (biểu tượng Play màu cam).
Chọn mô hình (Model Mapping):
- Nhấn Select cạnh model Antigravity gốc (ví dụ: Gemini 3.1 Pro High).
- Chọn mô hình thay thế mà bạn muốn dùng thực tế (ví dụ: gemini-1.5-pro).
- Nên ưu tiên các model nhẹ như Gemini Flash để tiết kiệm đơn vị.
Lưu cấu hình: Hệ thống tự động áp dụng. Bạn có thể thiết lập thứ tự ưu tiên: Thuê bao → Giá rẻ → Miễn phí.

Mẹo tối ưu quota và kinh nghiệm thực tế

Tránh mô hình "đốt" quota: Claude Opus tốn gấp 8 lần Claude Sonnet. Gemini 3 Flash là lựa chọn tiết kiệm nhất.
Chia tách nguồn quota: Claude và Gemini có quota độc lập. Nếu hết quota Claude, hãy map sang Gemini Flash để tiếp tục làm việc.
Tắt AI Credits: Trên Antigravity v1.20.5+, vô hiệu hóa AI Credits giúp quota ổn định hơn.
Combo "Free-forever": Kết hợp các model miễn phí như gc/gemini-3-flash, if/kimi-k2-thinking, và qw/qwen3-coder-plus để duy trì chi phí $0.

Việc thay đổi chính sách của Google khiến người dùng cần linh hoạt hơn trong cách quản lý tài nguyên. 9Router cung cấp giải pháp kỹ thuật hiệu quả để vượt qua rào cản quota thông qua cơ chế đa tài khoản và điều hướng mô hình thông minh. Tuy nhiên, hãy luôn lưu ý vấn đề bảo mật chứng chỉ và tuân thủ điều khoản dịch vụ của nhà cung cấp.

Khi AI agent có trình duyệt riêng: bước tiến mới cho tự động hoá trên web

addROM — Wed, 01 Apr 2026 06:48:32 +0000

Trong nhiều năm, phần lớn tác vụ AI trên web vẫn bị chặn bởi một giới hạn rất đời thường: website được thiết kế cho con người, không phải cho agent. Đăng nhập, giữ phiên làm việc, bấm nút, đi qua nhiều bước điều hướng hay xử lý giao diện động đều là những việc mà một mô hình ngôn ngữ thuần văn bản không thể tự làm chỉ bằng suy luận.

Sự thay đổi đáng chú ý gần đây nằm ở chỗ agent không chỉ “đọc web” nữa, mà có thể được cấp một môi trường trình duyệt riêng để tương tác với web giống như một người dùng. Khi kết hợp năng lực lập kế hoạch của coding agent với một lớp browser automation có trạng thái phiên bền vững, phạm vi tự động hoá mở rộng rõ rệt: từ thu thập dữ liệu, điền biểu mẫu, cho tới theo dõi cộng đồng và xử lý các quy trình nhiều bước trên những website không có API phù hợp.

Tại sao web lại khó với AI agent?

API luôn là con đường sạch nhất để phần mềm giao tiếp với phần mềm. Vấn đề là không phải dịch vụ nào cũng có API đầy đủ, và ngay cả khi có thì nhiều luồng công việc thực tế vẫn diễn ra trên giao diện web: đăng nhập bằng tài khoản riêng, nhấp qua nhiều trang, lọc danh sách, xác nhận biểu mẫu, hoặc xử lý các bước phụ thuộc trạng thái phiên.

Với agent chỉ có khả năng đọc văn bản và gọi một vài tool cơ bản, những thao tác này thường bị gãy. Agent có thể hiểu phải làm gì tiếp theo, nhưng không có “bàn tay” để thực sự thao tác trên giao diện. Vì vậy, khoảng cách giữa “biết cách làm” và “làm được” trên web vẫn là một nút thắt lớn của tự động hoá AI.

Trình duyệt riêng cho agent thay đổi điều gì?

Điểm mới quan trọng là mỗi agent có thể được cấp một phiên trình duyệt tách biệt với hồ sơ người dùng chính. Phiên này có cookie, trạng thái đăng nhập và bối cảnh hoạt động riêng. Nếu nền tảng hỗ trợ persistent session, agent có thể quay lại đúng môi trường đó trong các lần chạy sau thay vì phải thiết lập từ đầu mỗi lần.

Về mặt kỹ thuật, đây là khác biệt rất lớn so với kiểu browser automation chỉ sống trong một phiên ngắn rồi mất trạng thái. Khi trạng thái được giữ lại, agent không chỉ “mở trang lên để đọc”, mà có thể tiếp nối quy trình dang dở: vào đúng tài khoản đã xác thực, tiếp tục luồng duyệt web trước đó, hoặc lặp lại một tác vụ định kỳ mà không cần con người can thiệp lại từ bước đăng nhập.

Kết hợp coding agent với browser automation mang lại gì?

Một coding agent hiện đại thường có thế mạnh ở ba lớp: hiểu yêu cầu, lập kế hoạch nhiều bước, và phối hợp tool hoặc sub-agent để thi hành. Khi ghép thêm một lớp browser automation có khả năng tương tác với website, agent từ chỗ chỉ xử lý file, code và lệnh hệ thống sẽ có thêm khả năng làm việc trực tiếp trên giao diện web.

Điều này mở ra một mô hình tác tử thực dụng hơn: agent dùng skill để biết quy tắc công việc, dùng file hoặc notebook để lưu ngữ cảnh, dùng sub-agent để tách bước xử lý, và dùng trình duyệt để đi qua những chỗ mà scrape tĩnh hoặc tìm kiếm đơn thuần không thể chạm tới. Với các website nhiều bước, có xác thực, có nút bấm hoặc cần render động, browser layer là phần còn thiếu để agent thực thi trọn vẹn hơn.

Một số use case dễ hình dung

Một nhóm use case rõ ràng là theo dõi và phản hồi trên cộng đồng trực tuyến. Ví dụ, agent có thể mở Reddit hoặc một diễn đàn, tìm các bài viết mới liên quan tới một thương hiệu hoặc sản phẩm, sau đó soạn phản hồi theo giọng điệu đã định sẵn. Nếu được cấu hình tốt, agent còn có thể tham chiếu knowledge base nội bộ để tránh trả lời sai hoặc trả lời quá chung chung.

Ngoài cộng đồng, mô hình này còn phù hợp với các luồng cần thao tác qua web như theo dõi review trên trang đánh giá, rà các listing việc làm hoặc freelance platform, duyệt tài liệu trong cổng hỗ trợ khách hàng, hoặc đi qua các trang tra cứu có phân trang và bộ lọc phức tạp. Ở những bài toán như vậy, trình duyệt không chỉ là đầu vào dữ liệu mà là môi trường thực thi thao tác.

Skill đóng vai trò gì trong chất lượng đầu ra?

Nếu chỉ cho agent quyền thao tác trình duyệt mà không có quy tắc rõ ràng, kết quả rất dễ trượt về kiểu phản hồi chung chung hoặc thiếu kiểm soát. Đây là lý do skills trở nên quan trọng. Theo tài liệu Claude, skill là gói hướng dẫn có cấu trúc, được nạp khi đúng ngữ cảnh và có thể kèm thêm tài nguyên tham chiếu hoặc script hỗ trợ.

Trong thực tế, skill có thể quy định ba lớp rất quan trọng: giọng điệu thương hiệu, giới hạn nội dung được phép nói, và nguồn tri thức được ưu tiên tham chiếu. Nhờ vậy, agent không chỉ biết “cách dùng trình duyệt”, mà còn biết “nên hành xử như thế nào” trong từng bối cảnh. Với các tác vụ đối ngoại, đây là phần quyết định sự khác biệt giữa một công cụ tự động hữu ích và một bot gây khó chịu.

Tự động hoá định kỳ mới là lúc giá trị thật lộ ra

Một demo thao tác tay luôn gây ấn tượng, nhưng giá trị vận hành chỉ xuất hiện khi quy trình được lặp lại theo lịch. Tài liệu Claude phân biệt khá rõ các lựa chọn scheduling: chạy trong session hiện tại bằng kiểu loop ngắn hạn, chạy trên máy cá nhân, hoặc đẩy lên môi trường cloud để bền hơn qua restart.

Điểm cần nhớ là bài toán định kỳ không chỉ là “bao lâu chạy một lần”, mà còn là agent có giữ được ngữ cảnh, trạng thái đăng nhập và khả năng truy cập tool cần thiết hay không. Nếu một tác vụ cần dùng file cục bộ hoặc môi trường agent đang mở sẵn, chạy local có thể hợp lý. Nếu cần độ bền cao và không phụ thuộc máy cá nhân đang bật, dạng cloud sẽ thực tế hơn.

Nhưng đây không phải đũa thần

Browser automation cho agent không biến mọi website thành API. Nó chậm hơn gọi API trực tiếp vì còn phải đợi trang tải, render thành phần giao diện, xử lý chuyển trang và đôi khi chịu ảnh hưởng từ anti-bot. Những nền tảng có hệ thống phát hiện hành vi tự động mạnh vẫn có thể giới hạn hoặc chặn tác vụ.

Ngoài giới hạn kỹ thuật còn có giới hạn đạo đức và chính sách. Một agent được giao quyền tương tác trên web có thể tạo giá trị lớn trong các use case hợp lệ như hỗ trợ cộng đồng, tổng hợp thông tin hoặc dự thảo phản hồi. Nhưng nếu bị dùng để spam, giả làm người thật hoặc thao túng nền tảng, hệ quả gần như chắc chắn là tài khoản bị khoá, chất lượng thương hiệu suy giảm, và rủi ro tuân thủ tăng lên.

Cách tiếp cận an toàn và thực tế hơn

Thay vì xem browser agent như công cụ thay thế hoàn toàn con người, cách nhìn hợp lý hơn là coi nó như một lớp tự động hoá có giám sát. Agent có thể làm phần lặp lại: dò nội dung mới, gom ngữ cảnh, điền sườn phản hồi, hoặc thực hiện các thao tác kỹ thuật có quy tắc rõ ràng. Con người vẫn nên là lớp phê duyệt cho những tình huống nhạy cảm, nội dung công khai, hoặc quyết định có ảnh hưởng tới uy tín thương hiệu.

Một nguyên tắc đáng giữ là minh bạch khi cần thiết. Nếu agent đang tham gia tương tác cộng đồng hoặc trả lời dưới danh nghĩa hỗ trợ tự động, việc công khai tính chất automation thường an toàn và bền vững hơn so với cố giả lập người thật. Song song với đó, nên giới hạn phạm vi hành động ngay từ đầu: agent được phép đọc gì, đăng gì, dùng nguồn nào, và gặp trường hợp nào thì phải dừng để xin người vận hành quyết định.

Bước tiến đáng chú ý ở đây không nằm ở một câu khẩu hiệu về việc “thay đổi Internet”, mà ở việc AI agent đang tiến gần hơn tới khả năng vận hành những quy trình web thực tế. Khi có trình duyệt riêng, trạng thái phiên bền vững, skill để định hình hành vi và cơ chế chạy theo lịch, agent bắt đầu trở thành một lớp tự động hoá có thể đưa vào vận hành thật.

Dù vậy, giá trị bền vững sẽ không đến từ việc cho agent quyền làm mọi thứ, mà từ cách thiết kế ranh giới hợp lý: chọn đúng use case, giữ tính minh bạch, kiểm soát nguồn tri thức và để con người đứng ở những điểm quyết định quan trọng. Nếu làm đúng, browser-based agents có thể trở thành một mảnh ghép rất thực dụng trong hạ tầng tự động hoá mới của doanh nghiệp và cá nhân.

Multi-Agents trong OpenAI Codex: Tính năng mới giúp bạn làm việc song song, tăng tốc coding gấp bội

addROM — Thu, 19 Mar 2026 08:55:54 +0000

Ngày 16/3/2026, OpenAI chính thức ra mắt Subagents (hay còn gọi là multi-agents) cho nền tảng Codex – một bước tiến lớn biến Codex từ “một trợ lý code” thành “đội quân AI chuyên trách” thực sự.

Thay vì một agent duy nhất phải làm hết mọi việc (dễ mệt mỏi và lẫn lộn context), Codex giờ đây có thể tự động sinh ra nhiều subagent chạy song song, mỗi con chuyên một nhiệm vụ riêng, rồi tổng hợp kết quả lại chỉ trong một response duy nhất.

Đây chính là tính năng vừa hỗ trợ mà cộng đồng dev đang háo hức bàn tán trên Reddit, LinkedIn và X. Hãy cùng tìm hiểu chi tiết nhé!

Subagents là gì?

Subagents là các agent con được Codex sinh ra để xử lý các nhiệm vụ có thể song song hóa.

Bạn không cần code phức tạp hay dùng framework agent riêng – chỉ cần yêu cầu bằng ngôn ngữ tự nhiên, Codex sẽ tự:

Phân tích task
Sinh ra các subagent chuyên biệt
Chạy chúng song song
Chờ tất cả hoàn thành
Tổng hợp kết quả đẹp đẽ

Codex có sẵn 3 built-in agent:

default: Agent đa năng fallback
worker: Tập trung thực thi code, fix bug
explorer: Đọc code, khám phá codebase (read-only)

Bạn còn có thể tạo custom agent hoàn toàn theo ý mình.

Cách Subagents hoạt động (kiến trúc & workflow)

Codex đóng vai trò Orchestrator (điều phối viên):

Bạn đưa prompt yêu cầu spawn agent.
Codex sinh ra các subagent (mỗi con có model, instruction, sandbox riêng).
Các subagent chạy độc lập, song song (mặc định tối đa 6 thread).
Codex chờ tất cả xong → tổng hợp → trả về một câu trả lời duy nhất.

Giới hạn an toàn (có thể chỉnh trong config.toml):

max_threads = 6
max_depth = 1 (không cho phép agent con sinh thêm agent cháu quá sâu)
job_max_runtime_seconds = 1800

Subagent chỉ hoạt động khi bạn explicitly yêu cầu (Codex không tự động spawn để tránh tốn token vô ích).

Lợi ích nổi bật

Tăng tốc độ cực mạnh với task phức tạp (PR review, audit codebase, debug UI regression…).
Mỗi agent chuyên sâu → ít hallucinate hơn, context sạch hơn.
Tiết kiệm thời gian: Thay vì hỏi 6 lần riêng lẻ, bạn hỏi một lần, Codex làm hết.
Dễ tùy biến: Custom agent bằng file TOML siêu đơn giản.

Token note: Sẽ tốn nhiều token hơn (vì mỗi subagent đều chạy model riêng), nhưng đáng giá với task lớn.

Cách sử dụng thực tế (ví dụ cực kỳ hữu ích)

Ví dụ 1: Review PR bằng 6 agent song song

I would like to review the following points on the current PR (this branch vs main). 
Spawn one agent per point, wait for all of them, and summarize the result for each point.

1. Security issue
2. Code quality
3. Bugs
4. Race conditions
5. Test flakiness
6. Maintainability of the code

→ Codex sẽ spawn 6 subagent, mỗi con chuyên một khía cạnh, rồi trả về bảng tóm tắt gọn gàng.

Ví dụ 2: Tạo custom agent (file TOML)

Tạo thư mục ~/.codex/agents/ hoặc .codex/agents/ trong project.

File pr-explorer.toml:

name = "pr_explorer"
description = "Read-only codebase explorer"
model = "gpt-5.3-codex-spark"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"

developer_instructions = """
Stay in exploration mode. 
Trace the real execution path, cite files and symbols. 
Avoid proposing fixes unless the parent agent asks.
"""

Tương tự bạn có thể tạo reviewer.toml, docs-researcher.toml (kết nối MCP server để tra tài liệu OpenAI)… rồi dùng ngay trong prompt.

Ví dụ 3: Batch processing hàng trăm file với spawn_agents_on_csv
Đây là tính năng “thần thánh” cho audit lớn:

Tạo CSV danh sách component/file
Spawn hàng loạt worker agent
Mỗi con review một item → xuất CSV kết quả hoàn chỉnh

Cấu hình & mẹo hay

Custom agent nằm trong ~/.codex/agents/ (toàn máy) hoặc .codex/agents/ (per project).
Agent có nickname đẹp (Atlas, Delta, Echo…) để dễ theo dõi trong CLI/app.
Hiện tại hiển thị tốt trên Codex App và CLI. IDE Extension sẽ hỗ trợ sớm.
Muốn theo dõi tiến trình: Dùng lệnh /agent trong CLI.

Tương lai của coding đã đến!

Subagents biến Codex thành một hệ thống multi-agent thực thụ – giống như bạn có cả team senior dev, junior dev, tester, security expert làm việc cùng lúc, nhưng chỉ tốn một prompt.

Đây không chỉ là tính năng mới – đây là bước ngoặt khiến AI coding từ “trợ lý” lên thành “đồng nghiệp thật sự”.

Cách tạo slide đề xuất tự động bằng n8n AI Agent và Fireflies AI

addROM — Mon, 19 Jan 2026 16:03:11 +0000

Tóm tắt nhanh:

Tiết kiệm thời gian: Tự động hóa toàn bộ quy trình từ ghi chép biên bản cuộc nói chuyện đến tạo slide đề xuất (proposal deck).
Quy trình 2 bước (Decoupled): Tách biệt việc ghi log dữ liệu (Webhook) và quy trình tạo slide (Google Sheets Trigger) để hệ thống ổn định hơn.
Kiểm soát chất lượng: Tích hợp Slack để "Human approval" (phê duyệt bởi con người) ngay trong n8n trước khi gọi AI tạo slide.

Bạn vừa kết thúc một cuộc nói chuyện với khách hàng. Nhưng ngay sau đó là cảm giác "ngại" khi phải bắt tay vào viết biên bản cuộc nói chuyện, tổng hợp ý chính và thiết kế slide đề xuất. Tin vui là: "Tất cả những thứ đó giờ đây đều có thể tự động hóa."

Dưới đây là cách tôi xây dựng một "cỗ máy" tự động tạo proposal deck chuyên nghiệp ngay lập tức bằng n8n và AI Agents.

Làm thế nào để tự động tạo slide đề xuất từ cuộc nói chuyện?

Cách hiệu quả nhất là sử dụng quy trình tự động hóa (workflow) trên n8n để kết nối Fireflies.ai (ghi chép cuộc nói chuyện), Google Sheets (lưu trữ dữ liệu), Slack (duyệt) và Gamma (tạo slide).

Thay vì nhập liệu thủ công, hệ thống sẽ tự động trích xuất thông tin từ transcript cuộc nói chuyện, chờ xác nhận của bạn qua Slack, và tạo ra một bản trình bày hoàn chỉnh.

Download workflow: https://romhub.io/n8n/Gamma_Proposal_Generation

Quy trình hoạt động chi tiết

Hệ thống được chia làm hai giai đoạn riêng biệt (Decoupled workflow) nối với nhau qua Google Sheets.

Giai đoạn 1: Webhook & Polling (Ghi nhận dữ liệu)

Ngay khi cuộc nói chuyện trên Fireflies.ai kết thúc, một Webhook sẽ được kích hoạt. Tuy nhiên, Fireflies cần một chút thời gian để xử lý transcript và tóm tắt (Gist), nên n8n sẽ xử lý như sau:
1. Webhook Trigger: Nhận tín hiệu từ Fireflies.
2. Cơ chế chờ thông minh (Wait loop): Workflow sử dụng node Wait và If để kiểm tra xem bản tóm tắt (Gist) đã có chưa. Nếu chưa, nó sẽ đợi và kiểm tra lại mỗi phút. Điều này đảm bảo dữ liệu ghi vào Sheet luôn đầy đủ.
3. Trích xuất người tham dự: Sử dụng Code Node để lấy danh sách tên người nói (Speakers).
4. Log Meeting: Dữ liệu metadata (Title, Date, ID, Gist, Attendees) được ghi vào một dòng mới trên Google Sheets với trạng thái "N/A".

Giai đoạn 2: Trigger tạo slide & Human Approval

Đây là lúc "ma thuật" thực sự xảy ra. Khi Google Sheets có dòng mới, workflow thứ hai sẽ kích hoạt:
1. Google Sheets Trigger: Phát hiện cuộc nói chuyện mới vừa được log.
2. Làm sạch Transcript (Clean Up): n8n gọi lại API Fireflies để lấy toàn bộ transcript, sau đó dùng Code Node để nhóm các câu nói liên tiếp của cùng một người và loại bỏ các ký tự thừa. Bước này cực kỳ quan trọng để AI có thể đọc hiểu nội dung tốt nhất.
3. Slack Approval (Send & Wait): Hệ thống gửi tin nhắn vào Slack kèm nút bấm: "Would you like a proposal generated?". Quy trình n8n sẽ tạm dừng tại đây để chờ bạn bấm nút.
4. Xử lý rẽ nhánh (If Node):
* Nếu chọn "Yes": AI Agent (sử dụng model Gemini/OpenAI) sẽ phân tích transcript, soạn thảo nội dung theo cấu trúc Proposal, sau đó gửi lệnh API sang Gamma để tạo slide. Cuối cùng, cập nhật trạng thái "Generated" vào Google Sheets.
* Nếu chọn "No": Cập nhật trạng thái "Generation Declined" vào Google Sheets và kết thúc quy trình.

Bảng phân tích các công cụ trong hệ thống

Để giúp bạn hình dung rõ hơn về vai trò của từng thành phần, tôi đã lập bảng tổng hợp dưới đây:

Công cụ	Vai trò chính	Lợi ích đặc biệt trong Workflow
n8n	"Nhạc trưởng" (Orchestrator)	Xử lý logic phức tạp như Wait Loop (chờ dữ liệu) và Human-in-the-loop (nút bấm Slack).
Fireflies.ai	Nguồn dữ liệu (Source)	Cung cấp transcript và tóm tắt. Workflow gọi API 2 lần: lần 1 để log, lần 2 để lấy full text xử lý.
Google Sheets	Bộ đệm (Buffer)	Kết nối giữa 2 giai đoạn, đảm bảo không bị mất dữ liệu nếu quy trình tạo slide bị lỗi.
Gamma	Đầu ra sản phẩm (Output)	Nhận nội dung dạng JSON/Text từ n8n và tự động thiết kế thành slide PDF/PPT.

Tại sao cần bước "Slack Approval" (Send & Wait)?

Trong workflow n8n này, node Slack được cấu hình ở chế độ "Wait for interaction". Tại sao không để nó chạy tự động 100%?

Theo quan điểm chuyên môn:

Tiết kiệm tín dụng AI & Gamma: Không phải cuộc nói chuyện nào cũng cần proposal. Việc tạo slide bừa bãi sẽ đốt cháy API credits của bạn rất nhanh.
Kiểm soát ngữ cảnh: Đôi khi cuộc nói chuyện có nội dung nhạy cảm hoặc chưa chốt xong, bạn chưa muốn tạo slide ngay. Nút bấm Yes/No trên Slack trao quyền quyết định cuối cùng cho bạn.

Câu hỏi thường gặp (FAQ)

Tại sao cần tách thành 2 giai đoạn (Webhook & Sheets Trigger)?
Để xử lý vấn đề về thời gian (Timing). Fireflies cần thời gian để xử lý audio. Nếu chạy tất cả trong 1 luồng ngay khi Webhook gọi, có thể bạn sẽ nhận được transcript rỗng. Việc ghi vào Google Sheets trước đóng vai trò như một "hàng đợi" (queue), giúp hệ thống ổn định hơn.

Workflow xử lý thế nào nếu có nhiều cuộc nói chuyện cùng lúc?
Trong Giai đoạn 2, ngay sau node Google Sheets Trigger, workflow có sử dụng node Limit với thiết lập "Keep Last Items: 1". Điều này giúp workflow tập trung xử lý cuộc nói chuyện mới nhất, tránh việc kích hoạt hàng loạt gây quá tải hoặc nhầm lẫn dữ liệu khi gửi tin nhắn Slack.

Tôi cần những API key nào?
Bạn sẽ cần kết nối:

Fireflies API: Để lấy transcript.
Google Sheets & Slack: Xác thực OAuth2.
OpenRouter (hoặc OpenAI/Gemini): Cho AI Agent xử lý nội dung.
Gamma API: Để generate slide deck.

Chiến lược xây dựng AI Agency tinh gọn: Kiếm $35k/tháng mà không cần sales

addROM — Fri, 02 Jan 2026 10:51:26 +0000

Bài viết này được chuyển thẻ từ chia sẻ của Liam Ottley về cuộc phỏng vấn với Linus Magsino (co-founder của AI Union).

Chào bạn,

Có bao giờ bạn nghĩ về việc điều hành một doanh nghiệp công nghệ có thể mang về hàng chục nghìn đô mỗi tháng, nhưng lại hoàn toàn vắng bóng đội ngũ bán hàng? Không tốn chi phí marketing chạy quảng cáo Facebook hay Google, và quan trọng nhất là vận hành với biên lợi nhuận cao ngất ngưởng, lên đến 80%?

Nghe có vẻ giống một câu chuyện cổ tích trong giới kinh doanh, hoặc như người ta hay nói là "Too good to be true". Mình hoàn toàn hiểu sự hoài nghi đó của bạn. Trước đây, chính mình cũng từng nghĩ làm agency đồng nghĩa với việc cày cuốc ngày đêm, gọi điện chào mời (cold call) mòn mỏi, và stress tột độ mỗi khi đến cuối tháng mà chưa đủ doanh số.

Nhưng thực tế, thị trường luôn có những ngách đi cực kỳ thông minh mà số đông thường bỏ qua. Thay vì lao ra ngoài kia săn bắn vất vả, chúng ta có thể chọn vị trí trở thành "người gác cổng" không thể thiếu cho các công ty phần mềm lớn.

Trong bài viết hôm nay, mình muốn chia sẻ sâu hơn với bạn về chiến lược Mô hình AI Agency theo hướng "Đối tác tích hợp" (Integration Partner). Đây không chỉ là lý thuyết, mà là bí mật giúp nhiều người sở hữu dòng tiền thụ động, tự do thời gian và thoát khỏi cảnh "làm dâu trăm họ" mà giới agency truyền thống hay gặp phải.

Tại sao mô hình agency truyền thống đang kìm hãm bạn

Nếu bạn đang vận hành một agency hoặc đang làm freelancer tự do, có lẽ bạn đã quá quen thuộc, thậm chí là ám ảnh với quy trình làm việc hiện tại. Phần lớn thời gian của bạn, khoảng 50-70%, không phải dùng để làm chuyên môn mà là để đi tìm kiếm khách hàng mới.

Cái bẫy của việc tự tìm kiếm khách hàng

Hàng ngày, bạn phải vắt óc sáng tạo nội dung trên mạng xã hội, đốt tiền vào các chiến dịch quảng cáo với hy vọng tìm được leads (khách hàng tiềm năng), và gửi hàng trăm email lạnh (cold emails) mỗi tuần.

Thực tế phũ phàng là tỷ lệ chuyển đổi thường rất thấp (chỉ quanh quẩn 10-20%), trong khi sự cạnh tranh thì ngày càng khốc liệt. Kết quả là bạn kiệt sức. Lợi nhuận kiếm được bị bào mòn bởi chi phí thu hút khách hàng (CAC - Customer Acquisition Cost). Cuối cùng, thay vì làm chủ doanh nghiệp, bạn trở thành nô lệ cho chính hệ thống mình tạo ra.

Tư duy "cá ép": Lối đi tắt khôn ngoan

Trong tự nhiên, loài cá ép có một chiến thuật sinh tồn cực hay: chúng bám vào cá mập để di chuyển xa hơn và kiếm ăn từ thức ăn thừa mà không tốn chút sức lực nào. Trong kinh doanh, chúng ta có thể áp dụng chiến lược tương tự bằng cách trở thành đối tác chiến lược của các công ty SaaS (phần mềm).

Thay vì tự mình đi tìm từng khách hàng lẻ, bạn hãy hợp tác với các công ty phần mềm đang trên đà phát triển mạnh. Họ có sẵn lượng khách hàng khổng lồ (leads) nhưng lại đang thiếu trầm trọng nhân sự để hỗ trợ khách hàng cài đặt và tích hợp hệ thống. Đó chính xác là "điểm huyệt" để bạn xuất hiện như một vị cứu tinh.

Chiến lược "Integration Partner": Biến đối thủ thành nguồn tiền

Hãy cùng mình phân tích sâu hơn một chút về bối cảnh thị trường hiện nay. Các công ty phần mềm (ví dụ như Voice AI, Automation, CRM) thường nhận được vốn đầu tư rất lớn từ các quỹ VC (Venture Capital). Họ dùng số tiền đó để đốt vào quảng cáo nhằm thu hút người dùng đăng ký.

Tuy nhiên, vấn đề cốt lõi nằm ở chỗ: Khách hàng mua phần mềm nhưng không biết cách sử dụng hiệu quả, hoặc không biết làm thế nào để kết nối phần mềm mới này với hệ thống cũ kỹ họ đang dùng.

Nỗi đau của các công ty SaaS và cơ hội của bạn

Các công ty phần mềm, đặc biệt là các startup giai đoạn đầu với quy mô nhân sự mỏng (khoảng 10-20 người), chỉ muốn tập trung toàn lực vào việc phát triển sản phẩm cốt lõi (coding, feature development). Họ không muốn, và thực tế là không đủ nhân lực để xây dựng một đội ngũ dịch vụ (service team) đi cài đặt thủ công cho từng khách hàng.

Hậu quả là nếu khách hàng không dùng được phần mềm, họ sẽ hủy đăng ký (churn). Trong thế giới SaaS, "churn rate" (tỷ lệ rời bỏ) là kẻ thù số một.

Khi bạn đến và nói với Founder của họ rằng: "Hãy để tôi lo phần cài đặt kỹ thuật cho khách của bạn", bạn đang giải quyết nỗi đau lớn nhất của họ. Đổi lại, họ sẽ vui vẻ chuyển toàn bộ những khách hàng tiềm năng (hot leads) - những người đã có tiền và có nhu cầu - sang cho bạn.

Kết quả bạn nhận được:

Chi phí marketing = 0 (vì đối tác cung cấp khách).
Tỷ lệ chốt sale gần như 100% (khách hàng đã mua phần mềm, họ bắt buộc cần người cài đặt).
Bạn giúp công ty SaaS giữ chân khách hàng lâu dài (Win-Win).

Quy trình 4 bước để xây dựng đế chế agency không cần sales

Dưới đây là lộ trình chi tiết từng bước mà mình đã đúc kết lại để bạn có thể sao chép và triển khai mô hình này ngay trong năm nay.

Bước 1: Chọn mặt gửi vàng (Find the Goldilocks Zone)

Sai lầm đầu tiên mà nhiều bạn mắc phải là chọn sai đối tác. Đừng chọn những nền tảng quá đơn giản như Calendly (vì ai cũng có thể tự setup trong 5 phút) hay những ông lớn quá khổ như Vapi (họ đã có đội ngũ kỹ thuật nội bộ hùng hậu).

Bạn cần tìm đến "Vùng Goldilocks" - nơi mọi thứ vừa đủ. Hãy tìm những phần mềm ngách (Niche SaaS), đang trên đà tăng trưởng nóng nhưng đội ngũ còn mỏng (dưới 50 nhân sự).

Gợi ý cụ thể:

Các phần mềm Voice AI tại thị trường địa phương (Đức, Pháp, hoặc chính Việt Nam đang rất hot).
Các công ty CRM chuyên biệt cho ngành bất động sản, nha khoa, spa.

Pro tip: Hãy lượn lờ trên các trang review phần mềm uy tín như G2, Capterra hoặc các cộng đồng Product Hunt. Lọc ra những cái tên mới nổi đang được rót vốn (Series A, Series B) gần đây. Đó là những "mỏ vàng" chưa ai khai thác.

Bước 2: Chiến lược nội dung "thả thính"

Khi đã xác định được mục tiêu, đừng vội vàng gửi email xin hợp tác theo kiểu "spam". Bạn cần chứng minh năng lực trước khi đưa ra đề nghị.

Làm video hướng dẫn: Quay màn hình, hướng dẫn cách sử dụng phần mềm của họ để giải quyết một vấn đề cụ thể, sau đó đăng lên YouTube.
Tham gia cộng đồng: Gia nhập Discord hoặc Facebook Group của họ. Tích cực trả lời câu hỏi, gỡ lỗi cho những người dùng khác.

Khi bạn làm video chất lượng về sản phẩm của họ, thực chất bạn đang làm marketing miễn phí cho họ. Nhà sáng lập (Founder) hoặc Giám đốc sản phẩm chắc chắn sẽ chú ý đến bạn. Đây là lúc mối quan hệ được xây dựng dựa trên sự tin tưởng. Hãy luôn nhớ nguyên tắc vàng: Trao giá trị trước, đề nghị hợp tác sau.

Bước 3: Đóng gói dịch vụ (Productization)

Để mở rộng quy mô (scale) doanh nghiệp lên mức $35k/tháng, bạn không thể làm việc theo kiểu thủ công mỹ nghệ "mỗi khách một kiểu". Bạn cần tư duy công nghiệp hóa dịch vụ của mình. Hãy đóng gói kỹ năng của bạn thành các gói sản phẩm cố định (Productized Service).

Ví dụ về cấu trúc giá bạn có thể tham khảo:

Gói cơ bản ($1,000): Cài đặt nhanh trong 8 giờ, setup prompting (câu lệnh) cơ bản cho AI, kết nối lịch hẹn Google Calendar.
Gói nâng cao ($2,000 - $3,000): Tích hợp sâu API, sử dụng các công cụ automation như Make.com (trước đây là Integromat) hoặc n8n để tạo quy trình xử lý dữ liệu phức tạp hai chiều.

Việc niêm yết giá rõ ràng giúp đối tác SaaS cực kỳ dễ dàng "bán hộ" bạn. Họ chỉ cần nói với khách hàng: "Bạn muốn cài đặt nhanh và chuẩn? Đối tác của chúng tôi có gói $1,000 này, rất phù hợp với bạn."

Bước 4: Tự động hóa và ủy quyền

Khi lượng khách hàng đổ về ồ ạt từ đối tác (và tin mình đi, khi bạn làm tốt, họ sẽ đổ về rất nhiều), bạn không thể "ba đầu sáu tay" tự làm mọi thứ.

Viết tài liệu quy trình (SOP): Soạn thảo hướng dẫn chi tiết từng bước cài đặt, từ lúc nhận account đến lúc bàn giao.
Thuê nhân sự giá tốt: Bạn có thể thuê sinh viên công nghệ năm cuối hoặc freelancer part-time. Vì đã có SOP chuẩn, họ chỉ cần làm theo hướng dẫn là đạt 90% yêu cầu.
Chia sẻ doanh thu (Revenue Share): Để mối quan hệ với đối tác SaaS bền vững như bê tông cốt thép, hãy trích lại 10-20% hoa hồng cho họ trên mỗi hợp đồng thành công. Đối với họ, đây là khoản "lợi nhuận ròng" không tốn sức, khiến họ càng có động lực gửi thêm khách cho bạn thay vì đối tác khác.

Từ làm thuê sang làm chủ công nghệ (SaaS)

Điều tuyệt vời nhất của mô hình AI Agency này không chỉ dừng lại ở dòng tiền mặt (cash flow) dồi dào. Giá trị lớn nhất mà nó mang lại chính là dữ liệu và sự thấu hiểu thị trường sâu sắc.

Khi bạn trực tiếp triển khai 100-200 dự án thực tế, bạn sẽ bắt đầu nhận ra những "lỗ hổng" - những vấn đề lặp đi lặp lại mà phần mềm gốc chưa giải quyết được hoặc giải quyết chưa tốt.

Biến insight khách hàng thành tài sản triệu đô

Ví dụ, trong quá trình làm việc, bạn nhận thấy 80% khách hàng dùng Voice AI đều gặp khó khăn trong việc quản lý và phân loại lịch sử cuộc gọi trên Google Sheets một cách trực quan. Đó là lúc bạn tự xây dựng một phần mềm nhỏ (Micro-SaaS) hoặc một plugin để giải quyết triệt để vấn đề đó.

Lúc này, bạn chính thức chuyển mình từ một chủ Agency (bán thời gian lấy tiền) sang một Founder SaaS (bán sản phẩm/bản quyền). Bạn có lợi thế hơn bất kỳ startup nào ngoài kia vì:

Bạn đã có sẵn tệp khách hàng đang khao khát giải pháp.
Bạn có sẵn uy tín từ quá trình làm dịch vụ.
Bạn hiểu rõ nỗi đau của thị trường hơn bất kỳ ai.

Mô hình AI Agency dựa trên quan hệ đối tác "Integration Partner" không phải là con đường trải đầy hoa hồng, bạn vẫn cần nỗ lực về mặt kỹ thuật và xây dựng mối quan hệ. Tuy nhiên, đây chắc chắn là con đường thông minh nhất cho những ai muốn đi đường dài, muốn xây dựng sự nghiệp bền vững mà không muốn kiệt sức vì vòng xoáy sales và marketing vô tận.

Bạn không cần phải là thiên tài lập trình để bắt đầu. Bạn chỉ cần một tư duy đúng đắn: Tìm người khổng lồ đang gặp khó khăn trong khâu triển khai, và trở thành cánh tay phải đắc lực của họ.

Đừng chờ đợi đến khi thị trường bão hòa hay mọi thứ quá hoàn hảo. Hãy bắt đầu tìm kiếm các phần mềm tiềm năng trên G2 ngay hôm nay, vọc vạch dùng thử nó và sản xuất nội dung chia sẻ. Cơ hội đổi đời đôi khi chỉ bắt đầu từ một video hướng dẫn 5 phút trên YouTube mà thôi.

Chúc bạn thành công rực rỡ trên hành trình tự động hóa doanh nghiệp của mình!

Hướng dẫn xây dựng hệ thống Báo giá tự động (AI Quote Agent) với n8n, Supabase và Replit

addROM — Fri, 12 Dec 2025 19:39:40 +0000

Hello AE,

Trong quá trình vận hành doanh nghiệp, đặc biệt là mảng logistic hay dịch vụ (Agency), "nút thắt cổ chai" lớn nhất thường nằm ở khâu báo giá thủ công. Quy trình: Check mail -> Tra cứu giá -> Tính toán -> Soạn mail thường ngốn 10-20 phút/khách. Khi nhân viên nhấn "Gửi" thì có khi đối thủ đã chốt đơn rồi.

Hôm nay mình chia sẻ case study xây dựng Hệ thống báo giá tự động (AI Quote System) giúp rút ngắn quy trình này xuống dưới 60 giây.

Hệ thống kết hợp 3 công cụ:

n8n: Backend xử lý logic và AI.
Supabase: Database lưu trữ khách hàng/lịch sử giá.
Replit: Frontend Dashboard để sale duyệt giá (Human-in-the-loop).

1. Tại sao cần hệ thống này?

Thay vì để AI tự tung tự tác, mô hình này giữ lại quyền kiểm soát của con người nhưng loại bỏ các tác vụ lặp lại:

Tốc độ: AI soạn thảo báo giá gần như tức thì ngay khi nhận request.
Chính xác: Hệ thống tham chiếu dữ liệu lịch sử (RAG) để đưa ra mức giá "Good - Better - Best" sát thị trường nhất.
Trải nghiệm (UX): Nhân viên Sales chỉ cần thao tác trên Dashboard (Replit), không cần biết code hay chui vào n8n sửa flow.

2. Kiến trúc hệ thống (Architecture)

Bộ não (n8n): Nhận trigger, gọi OpenAI phân tích, tính toán giá.
Bộ nhớ (Supabase): Lưu thông tin Request, trạng thái đơn hàng và lịch sử các đơn đã thắng (Won Deals).
Giao diện (Replit): Hiển thị các báo giá đang chờ duyệt (Pending Review).

3. Chi tiết quy trình xử lý trên n8n

Dựa trên workflow thực tế, luồng dữ liệu sẽ đi như sau:

Bước 1: Hợp nhất đầu vào (Input & Merge)

Hệ thống được thiết kế để bắt dữ liệu từ đa kênh:

Gmail Trigger: Quét inbox mỗi phút để bắt email mới.
Webhook: Nhận dữ liệu từ Form trên website (Contact Form).

Một node Merge sẽ gộp 2 nguồn này về một format chuẩn (gồm contact_name, email, service_type...) để xử lý đồng nhất.

Bước 2: Bộ lọc AI & Trích xuất dữ liệu

Không phải email nào gửi đến cũng là hỏi giá. Để tiết kiệm token và tránh spam:

AI Filter: OpenAI sẽ đọc nội dung email. Chỉ những email có độ tin cậy (confidence score) >= 60% là "Yêu cầu báo giá" mới được đi tiếp.
AI Extraction: AI tiếp tục trích xuất các trường thông tin: Loại dịch vụ, Ngân sách, Timeline, Độ phức tạp dự án...

Bước 3: Tham chiếu lịch sử (RAG đơn giản)

Đây là bước quan trọng giúp AI không "báo giá trên trời".

Dữ liệu thô được lưu vào Supabase (trạng thái PROCESSING).
Hệ thống truy vấn ngược lại Supabase để lấy 10 dự án gần nhất có trạng thái WON cùng loại dịch vụ để làm cơ sở tham chiếu giá.

Bước 4: Chiến thuật giá & Soạn thảo (Drafting)

Node OpenAI - Calculate Pricing sẽ tính toán ra 3 option giá (tâm lý học hành vi):

Good (Basic): Giá tiết kiệm (0.8x).
Better (Standard): Giá tiêu chuẩn (1.0x) - AI khuyên dùng.
Best (Premium): Giá cao cấp (1.4x).

Sau đó, AI soạn sẵn một email chuyên nghiệp (HTML format) chứa bảng giá này, nhưng CHƯA GỬI NGAY.

Bước 5: Cập nhật & Cảnh báo

Dữ liệu (Giá + Email nháp) được update vào Supabase với trạng thái PENDING_REVIEW.
Slack Alert: Nếu giá trị đơn hàng >= $10,000, bot sẽ bắn tin nhắn ngay vào Slack để quản lý vào xử lý gấp.

4. Dashboard quản lý (Replit) & Webhook gửi đi

Đây là bước Human-in-the-loop. Chúng ta không để AI tự gửi mail để tránh sai sót.

Nhân viên truy cập Dashboard trên Replit, thấy danh sách các yêu cầu đang PENDING.
Review giá và nội dung email AI soạn.
Nhấn nút "Approve & Send".

Lúc này, Replit sẽ gọi Webhook thứ 2 trên n8n:

Gửi email thực tế qua node Gmail.
Update trạng thái Supabase thành SENT.
Ghi log thời gian gửi.

Mô hình này giải quyết triệt để bài toán: Tự động hóa việc tính toán/soạn thảo nhưng vẫn giữ quyền quyết định cuối cùng cho con người.

Anh em hoàn toàn có thể build hệ thống này với chi phí rất rẻ (n8n self-host, Supabase free tier, Replit basic).

Chúc anh em áp dụng thành công vào doanh nghiệp! Ai có thắc mắc chỗ nào comment mình giải đáp nhé.

Workflow tham khảo: https://romhub.io/n8n/Data_Analysis_Agent

Hướng dẫn tạo nhân viên trực tổng đài AI với Vapi và n8n MCP

addROM — Mon, 08 Dec 2025 11:39:47 +0000

Trong kỷ nguyên tự động hóa, việc sở hữu một nhân viên trực tổng đài AI (AI Voice Receptionist) không chỉ giúp doanh nghiệp hoạt động 24/7 mà còn nâng cao trải nghiệm khách hàng. Dựa trên bản thiết kế hệ thống “Kylie” – nhân viên lễ tân ảo cho dịch vụ chăm sóc xe Hercules Detailing, bài viết này sẽ hướng dẫn bạn xây dựng một hệ thống hoàn chỉnh sử dụng Vapi (Frontend) và n8n (Backend) thông qua giao thức MCP (Model Context Protocol).

Tại sao nên sử dụng n8n MCP Server?

Khi xây dựng Voice Agent, thay vì tạo hàng loạt webhook riêng lẻ khó quản lý, giải pháp tối ưu là sử dụng kiến trúc MCP Server.

Vapi (Frontend): Đóng vai trò là “giao diện giọng nói”, chịu trách nhiệm hội thoại, tổng hợp giọng nói và ra quyết định.
n8n (Backend): Đóng vai trò là “bộ não công cụ” (Tool Brain). Workflow chính hoạt động như một bộ định tuyến (Router), nhận yêu cầu từ Vapi và điều hướng đến các công cụ con cụ thể.
Lợi ích: Việc sử dụng MCP Server giúp bạn thay đổi cấu hình logic bên n8n mà không cần chỉnh sửa lại cài đặt bên Vapi, giúp hệ thống dễ dàng mở rộng.

Bước 1: Quy tắc “Paper First” và thiết kế luồng hội thoại

Trước khi viết code, bạn bắt buộc phải tuân thủ quy tắc “Paper First” – phác thảo logic trên giấy. Hội thoại giọng nói là phi tuyến tính (non-linear), người dùng có thể nhảy từ việc hỏi giá sang đặt lịch bất cứ lúc nào.

Bạn cần xác định rõ các kịch bản “If/Then”:

Nếu khách mới -> Thu thập Tên/Email -> Tạo hồ sơ CRM.
Nếu khách cũ -> Chào bằng tên -> Hỏi ý định.
Nếu muốn đặt lịch -> Kiểm tra lịch trống trước -> Sau đó mới đề xuất giờ.

Bước 2: Cấu trúc cơ sở dữ liệu

Hệ thống yêu cầu một file Google Sheets đóng vai trò là CRM với 3 tab chính:

Clients: Chứa cột Email, Name, Phone.
Appointment Log: Chứa ID, Email, Appointment Type (Loại dịch vụ), Date, Notes.
Call Log: Chứa Date, Summary (Tóm tắt), Outcome (Kết quả).

Bước 3: Xây dựng 7 workflow “thần thánh” trong n8n

Download: https://romhub.io/n8n/AI_Receptionist_n8n_Workflows

Trong file Vapi MCP Server.json, chúng ta thấy một workflow chính điều hướng đến các công cụ con. Dưới đây là chi tiết 7 công cụ cần thiết lập:

1. Client Lookup (Tra cứu khách hàng)

Mục đích: Xác định người gọi là khách mới hay khách cũ.
Input: Email.
Logic: Tìm kiếm email trong tab “Clients”. Nếu tìm thấy, kiểm tra tiếp lịch sử trong “Appointment Log”. Nếu không, trả về thông báo đây là khách mới.

2. New Client CRM (Tạo khách hàng mới)

Mục đích: Lưu thông tin khách hàng mới vào hệ thống.
Input: Email, Full Name, Phone Number.
Hành động: Thêm một dòng mới vào tab “Clients”.

3. Check Availability (Kiểm tra lịch trống)

Mục đích: Kiểm tra các khung giờ bận trên Google Calendar trước khi đặt lịch.
Input: afterTime, beforeTime (Cửa sổ tìm kiếm).
Logic: Quét lịch Google. Nếu không có sự kiện nào, trả về “cả ngày rảnh”. Nếu có, trả về danh sách giờ bận để AI biết và tránh ra.

4. Book Event (Đặt lịch hẹn)

Mục đích: Chốt lịch và lưu vào hệ thống.
Input: startTime, endTime, email, eventSummary (Loại dịch vụ).
Hành động:
1. Tạo sự kiện trên Google Calendar và thêm email khách hàng vào danh sách tham dự.
2. Ghi lại thông tin và Calendar Event ID vào tab “Appointment Log” trên Google Sheets.

5. Lookup Appointment (Tra cứu lịch hẹn cụ thể)

Mục đích: Lấy thông tin chi tiết (đặc biệt là Event ID) để phục vụ việc sửa hoặc hủy lịch.
Input: Khoảng thời gian tìm kiếm (afterTime, beforeTime).

6. Update Appointment (Cập nhật lịch hẹn)

Mục đích: Dời lịch hẹn sang giờ khác.
Input: startTime mới, endTime mới, eventID (lấy từ tool Lookup).
Hành động: Cập nhật giờ trên Google Calendar và ghi chú “Moved to…” trong Google Sheets.

7. Delete Appointment (Hủy lịch)

Mục đích: Hủy bỏ lịch hẹn.
Input: eventID.
Hành động: Xóa sự kiện trên Calendar và cập nhật ghi chú là “Canceled” trên Sheets.

(Ngoài ra còn có một workflow EOC Report kích hoạt bằng Webhook sau khi cuộc gọi kết thúc để ghi log, nhưng không nằm trong nhóm MCP tool)

Bước 4: Cấu hình Vapi – “Linh hồn” của AI

Sau khi backend n8n sẵn sàng, bạn cần cấu hình Vapi để giao tiếp với nó.

Thiết lập System Prompt

Bạn cần tạo nhân vật “Kylie” với tính cách vui vẻ, nói nhanh và thân thiện.

Quy tắc quan trọng: Trước khi gọi bất kỳ tool n8n nào, AI BẮT BUỘC phải nói một câu đệm như “Just give me a sec” hoặc “Let me check on that”. Điều này giúp che giấu độ trễ mạng và giữ cuộc hội thoại tự nhiên, tránh khoảng lặng chết (dead air).
Xử lý dữ liệu: Yêu cầu AI chuyển đổi email và tên thành chữ thường (lowercase) trước khi gửi sang n8n.

Kết nối MCP Tool

Trong Vapi Dashboard, thay vì thêm từng tool lẻ tẻ, bạn cấu hình như sau:

Tạo tool mới, chọn loại MCP.
Server URL: Dán đường dẫn Production URL của node MCP Server Trigger trong n8n.
Headers (Rất quan trọng): Thêm Authorization với giá trị Bearer <YOUR_N8N_API_KEY> để xác thực.
Cài đặt chế độ giao tiếp là Server-Sent Events (SSE).

Bằng cách kết hợp khả năng đàm thoại tự nhiên của Vapi với tư duy logic mạnh mẽ của n8n MCP Server, bạn có thể tạo ra một nhân viên lễ tân AI không chỉ biết chào hỏi mà còn thực sự làm việc: tra cứu CRM, quản lý lịch trình và xử lý tình huống phức tạp.

Mấu chốt của thành công nằm ở việc tách biệt nhiệm vụ: Vapi lo phần giao tiếp, n8n lo phần xử lý dữ liệu. Hãy nhớ kiểm tra kỹ các kết nối và System Prompt để đảm bảo trải nghiệm mượt mà nhất cho khách hàng.