Bài viết gốc Weixin: https://mp.weixin.qq.com/s/2R9xtPdgYr3kF6L-LGr8aA
Tác giả: 数字生命卡兹克 (Digital Life Kazik) · Biên dịch toàn văn & Việt hóa sơ đồ kiến trúc bởi AIHot.vn
Mở đầu: Từ tấu chương của Chu Nguyên Chương đến bài toán 'Sự chú ý' thời đại Agent
Thứ Bảy tuần trước, DeepSeek đăng tải một bài viết kỹ thuật rất dài mang tên <strong>《Khám phá thiết kế Super-Agent: Hướng tới hệ thống Agent tự chủ hơn》</strong> (<em>Super-agent设计探索：迈向更自主的Agent系统</em>). Tôi đã đọc kỹ từ đầu đến cuối — một kiến trúc cực kỳ xuất sắc mà bất kỳ nhà phát triển nào cũng rất đáng học hỏi.
Trong đó, câu nói quan trọng nhất theo tôi chính là câu mở đầu bài viết:
💡 Nhận định cốt lõi từ DeepSeek: “Một người thông thường chỉ có thể theo sát đồng thời từ 3 đến 5 phiên làm việc (session) đang hoạt động. Dưới thiết kế như vậy, giới hạn trần của đơn tác vụ phụ thuộc vào năng lực mô hình, còn giới hạn trần của đa tác vụ lại phụ thuộc vào sự chú ý của con người.”
Trong toàn bộ hệ thống Agent, <strong>sự chú ý của con người vừa là tài sản quý giá nhất, đồng thời cũng là nút thắt cổ chai lớn nhất</strong>.
Thực ra trong lịch sử, tình cảnh này đã từng xuất hiện vô số lần.
Năm 1380, nhân vụ án Hồ Duy Dung, Minh Thái Tổ Chu Nguyên Chương đã phế bỏ cả Trung thư tỉnh lẫn chức Thừa tướng. Từ đó về sau, Lục bộ trực tiếp chịu trách nhiệm trước Hoàng đế; đại sự thiên hạ tất thảy đều trình thẳng lên một mình ông.
Thế rồi quả báo ập đến rất nhanh. Tháng 9 năm Hồng Vũ thứ 17, Cấp sự trung Trương Văn Phụ trình lên Chu Nguyên Chương một bản thống kê: chỉ trong 8 ngày từ mùng 14 đến ngày 21, các nha môn trong ngoài triều đình gửi lên tổng cộng <strong>1.660 bản tấu chương</strong>, bên trong chứa <strong>hơn 3.000 công việc</strong> cần giải quyết.
Tính trung bình, mỗi ngày có hơn 200 bản tấu chương, và một mình Chu Nguyên Chương phải xử lý hơn 400 sự vụ mỗi ngày.
Chu Nguyên Chương vốn nổi tiếng là vị vua cần mẫn bậc nhất lịch sử, nhưng với cường độ khủng khiếp đó, chính ông cũng không trụ nổi mà phải thốt lên trước mặt quần thần một câu: <strong>“Trẫm nhất nhân xử thử đa vụ, khởi năng nhất nhất chu biến”</strong> (<em>朕一人处此多务，岂能一一周遍</em>).
Dịch ra ngôn ngữ đời thường chính là: <em>“Một mình ta quản ngần ấy việc, làm sao có thể chăm chút chu toàn từng việc một cho xuể!”</em>
Bạn thấy đấy, sự chú ý của một vị Hoàng đế thực ra cũng chẳng khác người bình thường chúng ta là bao.
Hơn 600 năm trôi qua, nhân loại bước vào xã hội AI, và mỗi người chúng ta đều bắt đầu trở thành vị Hoàng đế của riêng mình — chỉ khác là lần này, kẻ dâng tấu chương lên không phải Lục bộ Cửu khanh, mà là từng <strong>AI Agent</strong>.
Làm thế nào để thiết kế hệ thống điều phối Agent giúp giải phóng sự chú ý của bản thân, đồng thời nâng cao vượt bậc hiệu suất lao động, rút mình ra khỏi guồng quay vụn vặt để chỉ đưa ra những phán quyết then chốt nhất — đó chính là mệnh đề mà mỗi chúng ta đều phải học hỏi và suy ngẫm trong tương lai.
👑 Phẩm chất cốt lõi thời đại AI: Năng lực thiết kế hệ thống điều phối để rút mình ra khỏi việc vụn vặt và chỉ đưa ra quyết định then chốt thực chất có một cái tên rất quen thuộc: <strong>Năng lực Lãnh đạo (Leadership)</strong>.
Vì vậy, qua bài viết này, tôi muốn mạnh dạn chia sẻ trọn vẹn thành quả và kinh nghiệm gần 1 năm xây dựng hệ thống Agent của cá nhân mình: tôi đã làm thế nào để các Agent tự động xử lý đủ loại công việc, kiến trúc tổng thể ra sao, và tôi đã rút mình ra để phối hợp với Agent như thế nào nhằm chỉ tập trung vào những phán đoán quan trọng nhất.
Toàn bộ hệ thống này là kết quả tự mày mò, khám phá và sử dụng trong suốt thời gian dài của một người xuất thân không chuyên về lập trình như tôi — nên tôi tin rằng quy trình này cũng sẽ gần gũi, dễ áp dụng hơn cho những người dùng phổ thông. Hy vọng bài viết sẽ hữu ích với mọi người!
1. Hệ thống Tự động hóa Agent: Đưa con người ra khỏi điểm khởi phát
Trước hết, tôi muốn chia sẻ góc nhìn của mình về thế nào là <strong>Tự động hóa Agent</strong>.
Hiện nay, cách đại đa số mọi người sử dụng Agent thực chất vẫn thiên về <strong>kiểu trò chuyện (Chat-driven)</strong>: mở Claude Code hoặc Codex lên, giao cho nó một nhiệm vụ, ngồi nhìn nó làm, làm xong bạn kiểm tra lại, rồi mới giao tiếp nhiệm vụ kế tiếp.
Trong quy trình đó tồn tại một nhược điểm chí mạng: bạn sẽ nhận ra <strong>điểm khởi đầu của mọi việc đều nằm ở chính bạn</strong>. Chỉ cần bạn không mở cửa sổ đó lên, sẽ chẳng có điều gì xảy ra cả. Bởi vậy, dù mô hình AI có mạnh đến đâu, số lượng đầu việc bạn có thể thúc đẩy cùng lúc mãi mãi chỉ gói gọn trong vài cửa sổ mà mắt bạn盯 (canh chừng) kịp. Con số “3 đến 5 phiên hoạt động” mà DeepSeek nhắc tới chính là mang hàm ý này.
⚡ Chuyển dịch tư duy: Khi sử dụng Agent, chúng ta nhất định phải áp dụng <strong>tư duy lãnh đạo</strong>: gỡ bỏ điểm khởi phát công việc ra khỏi con người, dùng các <strong>tín hiệu (Signals / Events)</strong> để tự động kích hoạt Agent vào việc, thay vì bắt chúng phải ngồi chờ bạn hạ lệnh.
Bạn hãy thử tưởng tượng mình giống như Chu Nguyên Chương: chắc chắn không phải mọi công việc đều cần đẩy tới trước mặt bạn, và càng không thể có chuyện hễ bạn không lên tiếng thì quần thần bên dưới đều ngồi chơi xơi nước. Một triều đình vận hành tốt phải là nơi các đại thần khi gặp việc, việc gì tự xử lý được thì chủ động giải quyết dứt điểm; <strong>chỉ những việc họ không nắm chắc, bắt buộc phải trình lên cấp trên định đoạt thì mới đẩy tới trước mặt bạn</strong>.
Đó chính là ý nghĩa tối hậu của một Hệ thống Tự động hóa Agent theo cách hiểu của tôi.
Điều này hệt như việc dẫn dắt một đội ngũ ngoài đời thực: một đội ngũ giỏi không bao giờ chuyện gì cũng chạy đi báo cáo sếp. Họ sẽ tự mình thúc đẩy công việc, chỉ mang những việc cần bạn拍板 (chốt hạ) tới cho bạn, phần còn lại tự làm gọn gàng là xong. Thứ bạn cần trao cho họ là sự tin tưởng đầy đủ và cơ chế vận hành rõ ràng.
Dưới triết lý đó, toàn bộ kiến trúc hệ thống và luồng vận hành của tôi được thiết kế như sơ đồ dưới đây:
Việc duy nhất tôi cần làm chính là bước cuối cùng — thứ mà tôi gọi vui là <strong>“Phê tấu chương” (批奏折)</strong>.
Ngay bên trong ứng dụng Feishu (Lark), trợ lý AI của tôi là <strong>Tiểu Ca (小卡)</strong> sẽ bật lên một tấm thẻ tương tác để tôi xác nhận; tôi chỉ việc bấm chọn một nút là xong:
Bấm nút xong, Agent lập tức nhận được phán quyết của tôi và tự động quay lại tiếp tục làm việc. Cơ chế này về cơ bản giải phóng sức người của tôi ở mức tối đa.
Bây giờ, đi dọc theo luồng vận hành này, chúng ta sẽ cùng mổ xẻ chi tiết từng phân hệ một.
2. Trung đài Tự động hóa: Chuẩn hóa sự kiện, rules.json & Long-polling nội mạng
Trước tiên, hãy nói về khối cốt lõi nhất: <strong>Trung đài Tự động hóa Agent (Agent自动化中台)</strong>.
Trong hệ sinh thái Agent, một khi chúng ta muốn rút con người ra khỏi điểm khởi phát, thì câu hỏi <strong>“Khi nào và dưới tín hiệu nào sẽ kích hoạt Agent bắt đầu làm việc?”</strong> trở thành một bài toán thiết kế trọng tâm. Và câu trả lời chính là: <strong>Sự kiện (Event)</strong>.
Vạn vật trên đời, bất kỳ tín hiệu kích hoạt nào cũng đều có thể quy nạp thành một Sự kiện:
• <strong>Sự kiện chủ động đi tìm (Cron / Polling)</strong>: Các tác vụ hẹn giờ định kỳ mỗi phút hoặc mỗi giờ chủ động đi hỏi thăm (poll) hệ thống để phát hiện công việc mới.<br/>• <strong>Sự kiện chủ động tìm đến (Webhook / Push)</strong>: Khi nhận được một tin nhắn mới, một bức thư điện tử, hoặc khi một hệ thống nào đó bất ngờ phát cảnh báo lỗi...
Với nhóm tác vụ <strong>hẹn giờ định kỳ đi tìm việc</strong>, bản thân ứng dụng của Claude và Codex hiện đã hỗ trợ rất tốt: mỗi ngày mấy giờ chạy việc gì, chỉ cần cài đặt một lần là xong. Bản thân tôi cũng có cả một danh sách dài các tác vụ hẹn giờ đang chạy trực tiếp ngay trong ứng dụng của chúng:
Thậm chí có những tác vụ cực kỳ thú vị: cứ mỗi buổi chiều, <strong>Codex</strong> sẽ tự động lướt qua lịch sử trò chuyện trong các nhóm WeChat, X (Twitter), Tiểu Hồng Thư (Xiaohongshu), Douyin... để tìm kiếm những thảo luận và phản hồi mới nhất của cộng đồng về <strong>AIHOT</strong>, sau đó tổng hợp thành một bản báo cáo kèm đề xuất đánh giá khả thi xem có cần tối ưu điểm nào không.
Hay mỗi tuần, Agent sẽ tự động điều khiển trình duyệt của tôi truy cập lần lượt vào Doubao, DeepSeek, Qwen, Yuanbao, ChatGPT, Gemini... để đặt một loạt câu hỏi kiểm tra chỉ số <strong>GEO (Generative Engine Optimization)</strong> nhằm đánh giá vị thế hiển thị của AIHOT trên các công cụ AI.
Và từ khi AIHOT mở mã nguồn trên GitHub, mỗi ngày đều có anh em cộng đồng vào gửi góp ý (Issues) và yêu cầu hợp nhất mã (Pull Requests). Cứ đúng 18:00 tối hàng ngày, <strong>Claude</strong> sẽ tự động quét một lượt để xử lý các vấn đề và PR mới:
Tuy nhiên, cơ chế hẹn giờ quét định kỳ (Polling) có một nhược điểm bẩm sinh: <strong>không tức thời</strong>. Đồng nghiệp vừa đóng góp một ý kiến mới, hoặc hệ thống trên mạng đột ngột báo lỗi nghiêm trọng — bạn đâu thể ngồi đợi đến lịch chạy sáng hôm sau mới mở ra xem được, đúng không?
Những sự kiện kiểu đó, ngay khoảnh khắc vừa phát sinh, Agent phải lập tức được đánh thức dậy ngay. Muốn vậy phải dựa vào <strong>Webhook</strong>: hễ có chuyện là hệ thống bên kia chủ động đẩy (push) ngay một bản tin sang.
Thế nhưng những sự kiện tự tìm đến cửa lại có nguồn gốc muôn hình vạn trạng: tin nhắn Feishu, bot Feishu, email, cảnh báo từ đủ loại hệ thống giám sát... mỗi nguồn lại có cấu trúc dữ liệu hoàn toàn khác nhau.
Hơn nữa, vì năng lực và sở trường của từng mô hình AI rất khác nhau, để tối ưu hóa tỷ lệ hiệu năng/giá thành (P/P) và tiết kiệm Token, ứng với mỗi loại sự kiện, chúng ta lại cần đánh thức một Agent khác nhau, mô hình khác nhau và độ sâu suy luận (reasoning effort) khác nhau:
• Có sự kiện cần gọi <strong>Claude Code</strong> dùng <code>Claude Opus 5.5 (high)</code> để suy luận sâu và viết tính năng phức tạp.<br/>• Có sự kiện cần gọi <strong>Codex</strong> dùng <code>GPT-6.1 Terra (xhigh)</code> mở trình duyệt tìm kiếm những dữ liệu không có API.<br/>• Lại có sự kiện cần đẩy sang <code>GPT-6.1 Sol (xhigh)</code> để truy vết và vá lỗi (Bug) hệ thống...
Nếu cứ mỗi lần tích hợp một nguồn sự kiện mới lại viết riêng một đoạn script để hứng nguồn đó rồi gọi riêng từng Agent, làm khoảng 3–5 cái thì còn chạy được, chứ lên đến mười mấy, mấy chục luồng thì chắc chắn sẽ biến thành một nồi cháo thập cẩm hỗn loạn, không tài nào quản lý nổi.
Vì vậy, để về sau không bị loạn, tôi đã tự dựng <strong>Trung đài Tự động hóa</strong> này để quản lý tập trung toàn bộ các sự kiện kích hoạt, và về sau tích hợp luôn cả các tác vụ hẹn giờ vào chung một mối, thông suốt hoàn toàn.
Bản thân Trung đài này chỉ là một dịch vụ độc lập rất gọn nhẹ, triển khai trên một máy chủ đám mây cấu hình nhỏ (Lightweight Cloud Server), có địa chỉ web và cơ sở dữ liệu riêng. Công việc của nó cực kỳ rõ ràng: <strong>mọi sự kiện đều gửi về đây trước tiên -> Trung đài thống nhất quyết định giao cho Agent nào -> thống nhất đánh thức Agent -> thống nhất thu hồi kết quả -> chỉ khi thực sự cần tôi ra quyết định mới đẩy một tấm thẻ qua Feishu cho tôi</strong>.
Việc đầu tiên Trung đài làm là <strong>quy định một định dạng chuẩn duy nhất cho mọi sự kiện</strong>. Bất kể đến từ đâu, khi gửi vào Trung đài đều rút gọn thành một bản tin ngắn chỉ gồm 5 trường: <code>Từ đâu tới (Source)</code>, <code>Loại sự kiện (Type)</code>, <code>Đối tượng là ai (Target)</code>, <code>Tóm tắt 1 câu (Summary)</code>, cộng thêm <code>Một đường link dẫn ngược về nơi phát sinh</code>. Ví dụ: hệ thống nội bộ gửi về một sự kiện <code>feedback.new #12</code>, nghĩa là đồng nghiệp vừa gửi thêm một góp ý mới mang mã số <code>#12</code>.
Khi định dạng đã thống nhất, phần phía sau trở nên vô cùng nhẹ nhàng: Trung đài nhận sự kiện xong liền tra cứu bảng quy tắc. Toàn bộ quy tắc định tuyến được khai báo gọn trong một tệp duy nhất tên là <code>rules.json</code>. Chẳng hạn, quy tắc xử lý góp ý của đồng nghiệp được viết như sau:
{
"name": "Ý kiến Trung đài",
"when": {
"source": "virxact-hub",
"types": ["feedback.new", "feedback.followup", "feedback.decided"]
},
"to": "m5-claude",
"cwd": "~/code/work/virxact-hub",
"skill": "hub-feedback",
"ask": "Xử lý theo đúng mục 'Khi được Trung đài Tự động hóa Agent đánh thức' trong Skill.",
"group": "hub-feedback",
"parallel": 3,
"tell": "needed"
}Dịch ra tiếng người bình thường thì đoạn cấu hình trên có nghĩa là: <em>Đối với góp ý sản phẩm mới, ý kiến bổ sung của đồng nghiệp, hoặc các quyết định tôi đã chốt hạ, tất cả đều giao cho Claude Code trên máy Mac M5 Pro, mở đúng thư mục mã nguồn của Trung đài, sử dụng kỹ năng <code>hub-feedback</code> để xử lý. Câu lệnh giao cho Agent chỉ gói gọn một câu: ‘Làm theo đúng mục Khi được Trung đài Tự động hóa Agent đánh thức trong Skill’. Mỗi góp ý mở một phiên riêng, cùng một góp ý tại một thời điểm chỉ chạy tối đa 1 luồng, tối đa 3 góp ý chạy song song. Làm xong, chỉ khi nào thực sự cần tôi quyết định thì mới báo cho tôi, còn lại tự giải quyết êm thấm.</em>
Tiếp theo là bài toán <strong>đánh thức Agent</strong>. Ở đây có một vướng mắc kỹ thuật nhỏ: Webhook có thể đẩy tin nhắn tới Trung đài trên mây, nhưng Trung đài lại không thể chủ động đẩy (push) thẳng vào máy Mac của tôi được — bởi cả Claude lẫn Codex của tôi đều chạy cục bộ (Local) trên hai chiếc Mac Mini đặt trong mạng nội bộ (LAN) ở nhà và văn phòng, từ ngoài Internet hoàn toàn không thể kết nối ngược vào trong.
🔌 Lời giải kết nối nội mạng không cần mở cổng (Zero Public Exposure): Chúng tôi làm ngược lại: trên mỗi chiếc máy Mac đều chạy một <strong>trình nhận việc (Worker)</strong> treo kết nối liên tục lên Trung đài để chờ việc. Mỗi phiên giữ kết nối tối đa <strong>50 giây (Long-polling 50s)</strong>: hễ có việc là lập tức rước về chạy ngay, hết 50 giây chưa có việc thì lập tức nối lại phiên mới chờ tiếp. Nhờ vậy, máy Mac nội mạng không cần phơi ra Internet công cộng mà tốc độ phản hồi vẫn nhanh chẳng kém gì đẩy thời gian thực (Realtime Push).
Theo trải nghiệm của tôi, thiết kế Trung đài này mang lại <strong>5 lợi ích cực lớn</strong>:
<strong>Thứ nhất, tích hợp thêm một loại sự kiện mới trở nên dễ như trở bàn tay.</strong> Không cần viết lại bất kỳ kịch bản (script) mới nào, chỉ cần thêm một khối quy tắc vào <code>rules.json</code> là xong. Thậm chí tôi chỉ cần nhắn một câu cho Agent, nó tự sửa tệp cấu hình, chạy qua bước kiểm tra hợp lệ là vài phút sau đã có hiệu lực ngay.
<strong>Thứ hai, đổi Agent hay đổi Model cũng chỉ mất đúng 1 dòng chữ.</strong> Việc nào giao cho ai nằm gọn ở trường <code>to</code> trong quy tắc. Hôm nay đang giao cho <code>Claude Opus 5.5</code>, ngày mai muốn đổi sang <code>GPT-6.2 Astra</code> thì chỉ việc sửa một dòng. Sau này có mô hình mới mạnh hơn ra đời, việc nâng cấp diễn ra tức thì.
<strong>Thứ ba, khử trùng lặp tập trung (Unified Deduplication).</strong> Khi hệ thống tự động hóa chạy thực tế, chuyện cùng một sự việc bị bắn lặp lại nhiều lần là chuyện cơm bữa: mạng chập chờn khiến hệ thống nguồn tưởng chưa gửi được nên gửi lại lần nữa; hoặc đồng nghiệp vừa gửi góp ý xong lại nhắn bồi thêm một câu, rồi đính kèm thêm một tấm ảnh — thế là phát sinh liên tiếp mấy sự kiện liền. Nếu cứ mỗi tín hiệu đến lại đánh thức một Agent, thì cùng một đầu việc sẽ có mấy Agent nhảy vào sửa chồng chéo lên nhau, chắc chắn loạn thành một đống hỗn độn. Giao cho Trung đài đứng chặn ở cửa để gộp và khử trùng lặp thống nhất giúp tôi nhẹ đầu vô cùng.
<strong>Thứ tư, mọi thông báo chỉ đi qua một cửa ra duy nhất.</strong> Bất kể Agent nào, nhiệm vụ nào muốn tìm tôi cũng chỉ được phép đi qua một con đường độc đạo: trợ lý AI <strong>Tiểu Ca</strong> trên Feishu. Hơn nữa, từng quy tắc đều ghi rõ chế độ <code>tell: needed</code> (chỉ báo khi cần phán quyết), tuyệt đối không có cảnh script này bắn một tin, bot kia bắn một tin làm trôi ngập màn hình Feishu, bảo vệ tối đa sự tập trung của tôi.
<strong>Thứ năm, tích lũy dữ liệu vận hành (Data Precipitation).</strong> Vì mọi sự kiện đều đi qua Trung đài nên từng đầu việc đều lưu lại dấu vết đầy đủ trong cơ sở dữ liệu: đến lúc nào, từ nguồn nào, giao cho Agent nào, kết luận cuối cùng ra sao, có điểm gì cần tôi lưu ý không, về sau được giải quyết thế nào... Bấm vào bất kỳ nhiệm vụ nào cũng có thể nhảy thẳng tới phiên làm việc (Session) của Agent lúc đó để xem chi tiết nó đã thao tác những gì. Tích lũy lâu ngày, đây chính là kho dữ liệu quý giá giúp nhìn thấu dây chuyền nào đang bận nhất, Agent nào làm nhiều nhất, loại việc nào hay phát sinh lỗi nhất — làm căn cứ xác đáng để đổi mô hình hoặc tinh chỉnh quy tắc.
Ngoài ra còn một điểm nữa cực kỳ thỏa mãn sở thích cá nhân của tôi: <strong>nhìn thấy toàn bộ dây chuyền tự động hóa vận hành sống động ngay trước mắt</strong>. Có lẽ vì chịu ảnh hưởng sâu sắc từ các tựa game xây dựng – quản lý nông trại và nhà máy, đặc biệt là niềm mê mẩn khi ngắm nhìn những băng chuyền tự động hóa dày đặc trong <em>Dyson Sphere Program (Kế hoạch Quả cầu Dyson)</em>, tôi đã dựng hẳn một trang web tương tác để biến các đường ống Agent của chúng tôi thành một <strong>Thị trấn Tự động hóa 3D</strong> như trong game, đồng bộ hoàn toàn với thời gian và thời tiết ngoài đời thực — ngoài trời Bắc Kinh đang rơi tuyết thì trong thị trấn tự động hóa này tuyết cũng rơi trắng xóa!
Tôi đã kết xuất (render) một đoạn video thực tế dưới đây để mọi người cùng thưởng lãm:
Tóm lại, Trung đài Tự động hóa chính là bộ điều phối giúp mỗi sự kiện ngay khi vừa phát sinh đều tự tìm được đúng Agent cần làm việc, và chỉ chắt lọc phần cực nhỏ thực sự cần đến con người để dâng lên trước mặt tôi.
3. Thực thi Agent: Phân vai mô hình, cặp đôi Mac Mini M5 Pro + M4 & SOP Skill
Sau khi sự kiện được kích hoạt và định tuyến, bước tiếp theo là <strong>Agent nhận việc và thực thi</strong>.
Trước hết, tôi muốn nêu rõ một tiền đề cực kỳ thực tế: <strong>chúng ta không hề có lượng Token vô hạn</strong>. Ngay cả khi tôi đã đăng ký gói hội viên Claude cao nhất 200 USD/tháng, nếu chạy cường độ cao liên tục thì chỉ mất đúng <strong>3 ngày là đốt gần chạm mốc 90% hạn mức tuần</strong>:
Hơn nữa, điểm mạnh – điểm yếu của các mô hình chủ lực hiện nay thực sự khác nhau rõ rệt. Đó là lý do bắt buộc phải có <strong>chiến lược điều phối mô hình (Model Routing)</strong> nhằm đạt hiệu quả chi phí/hiệu năng tổng thể tối ưu nhất. Hiện tại tôi duy trì combo <strong>gói Claude 200 USD + gói GPT 100 USD</strong> mỗi tháng là cơ bản đủ dùng, với sự phân công chuyên môn hóa cho 3 mô hình chủ lực:
• <strong>Claude Opus 5.5</strong>: Lực lượng phát triển chủ lực (Core Dev) của chúng tôi. Những công việc phức tạp như lập trình tự động cho AIHOT, xử lý các góp ý cải tiến sản phẩm của đồng nghiệp trên Trung đài công ty — những việc đòi hỏi tính chủ động cao, tư duy thẩm mỹ và năng lực tự ra quyết định — hầu hết đều do nó đảm nhiệm. Phần lớn mã nguồn của các dự án cốt lõi hiện tại của tôi đều do <code>Claude Opus 5.5</code> viết.<br/>• <strong>GPT-6.1 Sol</strong>: Chuyên trách toàn bộ mảng vận hành hệ thống (DevOps & SRE) cho mọi dự án: xử lý cảnh báo lỗi, tổng hợp báo cáo hệ thống mỗi sáng, rà soát định kỳ các dịch vụ sắp hết hạn... Hễ có sự cố là nó nhảy vào tra cứu, tìm ra Bug hoặc nguyên nhân là trực tiếp sửa luôn. Trong mảng việc này, nó làm cực kỳ xuất sắc với tỷ lệ hiệu năng/chi phí (P/P) cao tuyệt vời.<br/>• <strong>GPT-6.1 Terra</strong>: Chuyên gia điều khiển trình duyệt & máy tính (Browser & Computer Use). Nó trực tiếp điều khiển trình duyệt Chrome đã đăng nhập sẵn đầy đủ các tài khoản trên chiếc Mac Mini của tôi. Những việc như chiều nào cũng đi lướt các mạng xã hội gom thảo luận về AIHOT, hay hàng tuần đi hỏi các nền tảng AI để đo chỉ số GEO — tức những nguồn dữ liệu không hề có API và cách thông thường không lấy được — tất cả đều cậy nhờ vào <code>GPT-6.1 Terra</code>.
⚠️ Nguyên tắc tối kỵ khi điều phối đa mô hình: Với những nhiệm vụ hàng ngày do chính tôi chủ động khởi phát, tôi luôn dùng <strong>Claude</strong> làm người điều phối. Tôi thường thấy nhiều người dùng Grok hoặc một số mô hình yếu hơn để đứng ra chỉ huy Claude — theo tôi cách làm đó khá sai lầm. <strong>Mô hình nắm quyền ra quyết định và quản lý bắt buộc phải là mô hình có trí tuệ và tính chủ động cao nhất; bạn tuyệt đối không thể dùng một kẻ ngốc đi chỉ huy một người thông minh</strong>, nếu không toàn bộ hệ thống sẽ rối tung lên ngay.
Về phần cứng, hiện tôi đang vận hành <strong>hai chiếc Mac Mini xếp chồng lên nhau</strong>: một chiếc <strong>Mac Mini M5 Pro</strong> mới mua và một chiếc <strong>Mac Mini M4</strong> mua từ năm ngoái:
Chiếc <strong>M5 Pro</strong> là máy làm việc chính hàng ngày của tôi, còn toàn bộ các tác vụ tự động hóa Agent về cơ bản đều chạy trên chiếc <strong>M4</strong>. Hai máy thông nhau qua mạng nội bộ (LAN), gần như toàn bộ đều xử lý cục bộ tại chỗ chứ <strong>không đưa lên đám mây (Cloud)</strong>.
Lý do rất thực tế: tôi làm việc theo mô hình phát triển độc lập, toàn bộ kho mã nguồn, quyền phát hành (Deploy keys), danh tính Feishu, cùng trình duyệt Chrome đã đăng nhập sẵn hàng chục tài khoản đều nằm gọn trên hai chiếc máy Mac này. Nếu đem Agent lên mây, tôi sẽ phải sao chép toàn bộ phiên đăng nhập và khóa quyền hạn đó lên từng đám mây một — vừa phiền phức vừa tiềm ẩn rủi ro bảo mật cực lớn.
Chưa kể rất nhiều dịch vụ nội địa, các Agent chạy trên máy chủ đám mây nước ngoài hoàn toàn không truy cập nổi hoặc xuyên biên giới về máy chủ Bắc Kinh rất chậm và liên tục đứt kết nối (timeout). Các tác vụ điều khiển trình duyệt lại càng không tưởng: những nền tảng kiểm soát chặt như WeChat, nếu bạn mở bằng trình duyệt trong máy ảo trên mây thì lập tức bị khóa hoặc văng ngay lập tức.
Cộng thêm việc hai chiếc Mac Mini vốn đã có sẵn, cắm điện bật 24/7 suốt ngày đêm cũng chẳng tốn bao nhiêu điện năng. Hàng ngày khi cần từ máy M5 Pro điều khiển sang máy M4, tôi chỉ việc bảo Agent điều khiển qua mạng LAN hoặc mở <strong>UU Remote</strong> lên là thao tác mượt mà ngay:
Trong khâu Thực thi Agent tự động, còn một mảnh ghép cực kỳ quan trọng nữa chính là <strong>Skill (Kỹ năng chuyên biệt)</strong>.
Gần như mỗi một tác vụ tự động hóa của chúng tôi đều được gắn kèm với một <strong>Skill riêng biệt</strong>. Sau ngần ấy thời gian phát triển của hệ sinh thái Agent, hẳn mọi người đều đã hiểu bản chất của Skill chính là một <strong>Quy trình thao tác chuẩn (SOP) được kết tinh lại dành riêng cho Agent</strong>, bên trong đính kèm các quy tắc, tài liệu tham chiếu và kịch bản công cụ.
Chẳng hạn, cứ <strong>6:00 sáng Chủ Nhật hàng tuần</strong>, tôi có một tác vụ hẹn giờ mang tên <strong>“Tổng vệ sinh cuối tuần”</strong> đi kèm với một Skill chuyên dụng tên là <code>sweep-aihot-leftovers</code>. Nội dung của Skill này quy định rất rõ: tìm toàn bộ những đoạn “code rác” (<em>shishan / 屎山</em>) bị hợp nhất vào trong tuần qua để dọn sạch — từ những logic cùng một việc mà viết lặp hai nơi, những miếng vá tạm bợ cho một trường hợp cá biệt, những tính năng đã ngưng sử dụng nhưng chưa tháo dỡ triệt để, cho tới những tài liệu đã biến tướng thành sổ ghi chép vụn vặt — cái gì xóa được là xóa thẳng tay rồi đẩy bản sạch lên sản phẩm:
Lợi ích của việc tách bạch từng tác vụ thành từng Skill riêng biệt là <strong>sự rõ ràng, dễ kiểm soát và dễ bảo trì</strong>: khi bạn muốn tinh chỉnh chi tiết cách làm của một đầu việc nào đó, bạn chỉ cần mở đúng tệp Skill đó ra sửa, hoàn toàn không phải đụng chạm vào logic thực thi cốt lõi của Agent — đảm bảo tính tách rời (Decoupling) cao nhất.
4. Trung đài CI 5 bước: Thẩm tra chéo tối đa 3 vòng bằng Codex & Máy ảo dùng 1 lần
Sau khi Agent viết code xong và đẩy bản đệ trình lên, quy trình sẽ bước sang trụ cột thứ tư: <strong>Trung đài CI (CI中台)</strong>.
Thuật ngữ <strong>CI (Continuous Integration / Tích hợp liên tục)</strong> có thể hơi lạ lẫm với những bạn không viết code, nhưng hiểu nôm na thì đó là <strong>trọn bộ dây chuyền tự động kiểm duyệt, chạy thử nghiệm và đưa sản phẩm lên mạng (Deploy)</strong> sau khi mã nguồn được viết xong.
Lý do tôi phải tách riêng phần này ra để tự dựng thành một Trung đài CI riêng rất đơn giản: <strong>khối lượng chạy quá khủng khiếp</strong>.
Hệ thống CI mặc định của GitHub (GitHub Actions) chạy trên máy chủ của họ; dù tôi đã mua gói hội viên trả phí thì mỗi tháng cũng chỉ được tặng <strong>3.000 phút miễn phí</strong>, vượt quá con số đó là phải trả thêm tiền theo từng phút. Trong khi đó, khối lượng PR của chúng tôi lớn đến mức chỉ riêng một dự án <strong>AIHOT</strong>, trong suốt tháng 10 đã hợp nhất (merge) <strong>gần 1.000 Pull Request</strong> — trung bình mỗi ngày từ 20 đến 30 PR, mà mỗi PR lại phải chạy đi chạy lại vài vòng kiểm tra. Chút hạn mức miễn phí kia hoàn toàn không gánh nổi.
Tôi từng nhẩm tính: với tốc độ gửi PR như hiện tại của chúng tôi, nếu cứ dùng CI của GitHub thì mỗi tháng riêng tiền phí vượt trần đã tốn đứt trên 50 USD. Thế nên tôi quyết định tận dụng luôn chiếc <strong>Mac Mini M4</strong> sẵn có ở nhà để tự dựng một <strong>Trung đài CI nội bộ</strong>: máy có sẵn không tốn thêm xu nào, hiệu năng lại mạnh vượt trội và đặt ngay tại Bắc Kinh nên tốc độ chạy nhanh hơn CI của GitHub gấp nhiều lần. (Tất nhiên nếu bạn có máy chủ Linux để làm CI thì còn chuẩn hơn nữa, vì máy Mac dùng chip ARM nên phải chạy qua lớp giả lập môi trường, nhưng với nhu cầu của tôi thì thế này đã quá dư dả).
Vì có nhiều dự án và nhiều Agent cùng hoạt động, tôi đã nâng cấp hệ thống CI cục bộ này thành một <strong>Trung đài CI dùng chung</strong> cho tất cả các dự án của mình. Toàn bộ quy trình gồm đúng <strong>5 bước khép kín: Thẩm tra -> Kiểm tra -> Hợp nhất -> Phát hành -> Xác thực</strong>:
Bất kể là Claude hay Codex, nhiệm vụ của Agent phát triển chỉ dừng lại ở bước <strong>viết xong code và mở một yêu cầu hợp nhất (Pull Request)</strong>; bản thân nó tuyệt đối không có quyền tự đẩy code lên máy chủ chính thức (Production). Toàn bộ công việc phía sau đều do Trung đài CI tiếp quản qua 5 bước nghiêm ngặt:
<strong>Bước 1: Agent Thẩm tra (Agent Review) — Mảnh ghép đáng giá nhất trong toàn bộ hệ thống.</strong><br/>Hiện tại mã nguồn các dự án của chúng tôi chủ yếu do <strong>Claude</strong> viết, nhưng bất kỳ Pull Request nào trước khi được phép gộp vào nhánh chính đều phải đi qua một cửa ải thẩm tra của <strong>Codex (dùng mô hình GPT-6.1 Sol)</strong>. Phải công nhận rằng dòng mô hình GPT trong khoản soi lỗi và thẩm tra code thực sự cực kỳ sắc bén.
Trước đây chúng tôi từng gặp tình trạng hai bên thẩm tra và bắt lỗi lẫn nhau tạo thành vòng lặp vô tận — Codex có thể càm ràm bắt bẻ tới 10 vòng chưa chịu dừng. Vì vậy, tôi đã học theo bài viết kỹ thuật của chính đội ngũ Anthropic: <strong>《How the Claude Code team does code review》</strong> (<em>Cách đội ngũ Claude Code thực hiện thẩm tra mã nguồn</em>). Đội ngũ phát triển Claude Code cũng áp dụng nguyên tắc thẩm tra mọi thay đổi trước khi gộp, nhưng <strong>giới hạn tối đa chỉ thẩm tra 3 vòng</strong>.
📊 Số liệu thực chiến từ 2 tuần vận hành Cơ chế Thẩm tra Chéo: Chỉ trong 2 tuần gần nhất trên 4 dự án, Trung đài CI đã thẩm tra tổng cộng <strong>298 Pull Request</strong>: Codex phát hiện ra <strong>333 vấn đề</strong>, trong đó <strong>306 vấn đề được sửa triệt để ngay trước khi gộp mã</strong>, bao gồm <strong>51 lỗi thuộc mức độ Nghiêm trọng nhất (Critical)</strong>. Chi phí lại cực kỳ rẻ: trung vị một lần thẩm tra chỉ mất <strong>hơn 2 phút</strong> và chỉ tiêu tốn khoảng <strong>5% đến 15% lượng Token</strong> của nhiệm vụ đó.
Đồng thời, bước thẩm tra này cũng bị ràng buộc bởi những kỷ luật sắt: <strong>Codex ở chế độ Chỉ đọc (Read-only)</strong> — chỉ được phép xem chứ không được sửa, <strong>ngắt hoàn toàn kết nối Internet</strong> và <strong>không thể đọc được bất kỳ khóa bí mật (Secrets/Keys) nào</strong>. Đặc biệt, quy tắc bắt buộc nó <strong>chỉ được báo cáo những lỗi thực sự sẽ gây hỏng hóc khi chạy, tuyệt đối không được bắt bẻ phong cách viết code (Code style)</strong> — nếu không nó sẽ bới ra hàng chục góp ý kiểu “đoạn này có thể viết đẹp hơn” và trả hồ sơ bắt sửa đến tận ngày tận thế.
<strong>Bước 2: Kiểm tra toàn diện (Full Checks) trong máy ảo dùng 1 lần.</strong><br/>Vượt qua vòng thẩm tra của Codex xong, hệ thống mới bắt đầu chạy bộ kiểm tra kỹ thuật đầy đủ: kiểm tra kiểu dữ liệu (Typecheck), chạy toàn bộ kiểm thử tự động (Unit/Integration Tests), đóng gói bản dựng (Build), cùng các quy tắc cứng như <em>“Cơ sở dữ liệu chỉ được phép thêm trường/bảng mới, tuyệt đối không được sửa hoặc xóa cấu trúc cũ”</em>. Chỉ cần 1 mục không đạt là chặn đứng, không cho gộp.
Toàn bộ các bài kiểm tra này đều chạy trên chiếc <strong>Mac Mini M4</strong>. Điểm mấu chốt về an toàn là: <strong>ứng với mỗi nhiệm vụ, máy M4 sẽ khởi tạo một Máy ảo (VM) hoàn toàn mới tinh; chạy kiểm tra xong là xóa sổ luôn cả máy ảo lẫn danh tính tạm thời đó</strong>. Mã nguồn do Agent viết ra không bao giờ được phép chạy trực tiếp ngay trên hệ điều hành gốc của máy Mac.
<strong>Bước 3: Tự động Hợp nhất (Auto-Merge).</strong><br/>Khi cả Thẩm tra và Kiểm tra đều vượt qua 100%, GitHub sẽ tự động hợp nhất mã vào nhánh chính. Hai điều kiện tiên quyết này được khóa cứng trong cấu hình bảo vệ nhánh (Branch Protection Rules) trên GitHub: bất kỳ đoạn code nào chưa qua thẩm tra và kiểm tra, dù đến từ Agent nào hay công cụ nào, cũng không thể lọt vào nhánh chính.
<strong>Bước 4: Phát hành tự động (Automated Deploy).</strong><br/>Ngay sau khi hợp nhất vào nhánh chính, GitHub tự động kích hoạt quy trình phát hành, tiếp tục giao việc về cho chiếc Mac Mini M4 mở riêng một máy ảo chuyên trách phát hành để đẩy bản mới lên máy chủ.
<strong>Bước 5: Xác thực trực tuyến (Live Production Verification).</strong><br/>Gộp mã xong, đẩy lên máy chủ xong vẫn chưa được coi là kết thúc! Trình bàn giao trên chiếc M4 sẽ đợi quy trình phát hành chạy xong xuôi, sau đó <strong>trực tiếp truy vấn vào môi trường mạng thực tế (Production)</strong> để hỏi xem phiên bản đang chạy ngoài đời thực đã thực sự chứa bản cập nhật lần này hay chưa. Chỉ khi xác nhận tính năng đã sống khỏe trên môi trường thật, nó mới ghi kết quả hoàn tất ngược về GitHub — lúc ấy một vòng lặp mới thực sự khép lại.
Cuối cùng, Agent phát triển ở máy cục bộ chỉ cần nhìn thoáng qua trạng thái trên GitHub là nắm rõ kết quả cuối cùng.
Trọn vẹn 5 bước khép kín, tính từ lúc Agent nộp code lên cho tới khi tính năng thực sự chạy trên mạng chỉ mất <strong>trung vị 2 đến 3 phút</strong> — tốc độ cực nhanh, trải nghiệm mượt mà, toàn bộ quá trình không cần tôi phải nhúng tay vào một giây nào, mà chất lượng bản phát hành lại tăng vọt, hiếm khi xảy ra lỗi vặt hay phải làm lại.
Tuyệt vời hơn cả là nhờ đã đúc thành Trung đài CI, từ nay về sau bất kỳ dự án mới nào của chúng tôi cũng có thể tái sử dụng nguyên vẹn dây chuyền này ngay lập tức.
5. Phê chuẩn Tấu chương trên Feishu: Cơ chế 'Phiếu nghĩ & Phê hồng'
Những gì có thể tự động giải quyết, các Agent đều đã tự mình giải quyết êm thấm cả rồi.
Vậy nên những việc cuối cùng còn được đẩy tới trước mặt tôi chắc chắn phải là những <strong>quyết định mang tính chiến lược hoặc đại sự</strong>.
Bản thân tôi không thích việc để các Agent tìm gặp mình thông qua những công cụ bên thứ ba rườm rà như DOT hay Grok Bot; tôi muốn mọi thứ phải liền mạch ngay trong không gian làm việc hàng ngày. Vì thế tôi kết nối thẳng với <strong>Feishu (Lark)</strong>: trợ lý AI <strong>Tiểu Ca</strong> sẽ đẩy trực tiếp một <strong>Thẻ Quyết Định tương tác (Interactive Decision Card)</strong> vào khung chat để tôi nhìn thấy ngay lập tức và bấm nút chọn phương án ngay trên thẻ:
Cảm giác này, nói thật lòng, chẳng khác gì Hoàng đế thời xưa ngồi phê chuẩn tấu chương cả!
Thời Chu Nguyên Chương mới lập quốc, một mình ông tự gồng lưng gánh vác mọi việc nên kiệt sức; nhưng đến đời con cháu nhà Minh về sau, triều đình đã dần tìm ra một cơ chế vận hành cực kỳ tinh gọn gọi là <strong>“Phiếu nghĩ” (票拟) và “Phê hồng” (批红)</strong>:
• <strong>Phiếu nghĩ (票拟)</strong>: Khi tấu chương từ các nơi gửi về, trước tiên sẽ được chuyển qua Nội các. Các vị Đại học sĩ sẽ đọc kỹ, nghiên cứu và viết sẵn phương án xử lý kiến nghị lên một mảnh giấy nhỏ đính kèm trên mặt tấu chương.<br/>• <strong>Phê hồng (批红)</strong>: Hoàng đế chỉ cần đọc lướt qua tờ phiếu đó, nếu đồng ý thì dùng bút son phê chuẩn xuống — vừa giữ trọn quyền quyết định tối cao, vừa tiết kiệm tối đa tâm sức.
Đó thực sự là phương thức quản trị tiết kiệm sức lực nhất. Trong hệ thống của tôi, <strong>tấm Thẻ Quyết Định chính là tờ “Phiếu nghĩ” mà Nội các Agent đã soạn sẵn cho tôi</strong>. Tôi chỉ làm đúng phần việc phán đoán bằng một cú chạm chuột; ngay sau khi bấm xong, Agent đang tạm dừng chờ lệnh ở phía sau sẽ lập tức nhận tín hiệu và tiếp tục thi hành phần việc còn lại, đồng thời tấm thẻ trên Feishu cũng tự động cập nhật sang trạng thái kết luận đã chốt.
Ví dụ tươi nóng vừa xảy ra ngay tối nay: có một kẻ xấu mò vào nhóm Feishu chính của cộng đồng AIHOT, thẳng tay xóa luôn con Bot đẩy tin tự động của nhóm rồi tự thoát khỏi nhóm. Trước đó tôi hoàn toàn không ngờ lại có lỗ hổng phân quyền cho phép thành viên thường xóa bot như vậy! Ngay khi con bot bị đá văng và phát sinh lỗi gửi tin, toàn bộ luồng tự động hóa lập tức được kích hoạt: Agent tự điều tra nguyên nhân, khóa quyền quản trị nhóm chỉ còn Chủ nhóm mới được sửa đổi, tạo sẵn bot mới và đẩy một tấm thẻ lên xin tôi phê chuẩn việc thay mã Webhook và phát bù bản tin:
Tuy nhiên, dù hình thức tương tác bằng thẻ quyết định có tiện lợi đến mấy, thì <strong>câu hỏi cốt tử nhất vẫn là: Rốt cuộc những việc gì mới được phép đẩy tới trước mặt tôi?</strong>
Trước đây tôi từng sập hầm rất nhiều lần ở khâu này: có những ngày hệ thống bắn cho tôi hàng chục tấm thẻ liên tiếp, làm đứt quãng nghiêm trọng sự tập trung của tôi.
🛡️ Danh sách 6 nhóm việc bắt buộc phải trình 'Tấu chương' xin ý kiến trước: Sau nhiều lần tinh chỉnh, hiện tại chỉ còn đúng <strong>6 nhóm việc nhạy cảm</strong> bắt buộc Agent phải hỏi tôi trước khi làm: <strong>(1) Xóa dữ liệu; (2) Dừng dịch vụ (Downtime); (3) Tiêu tiền / Phát sinh chi phí; (4) Gửi thông báo ra bên ngoài cho người dùng; (5) Thay đổi định hướng sản phẩm; (6) Tạo mới hoặc xoay vòng khóa bí mật (Keys) & Sửa đổi quyền hạn</strong>. Ngoài 6 nhóm này ra, tất cả những việc còn lại Agent đều có toàn quyền tự làm từ đầu đến cuối và tự đẩy lên môi trường thật!
Và một nguyên tắc vàng nữa: <strong>Chuyện gì tôi đã quyết một lần rồi, Agent tuyệt đối không được hỏi lại lần thứ hai.</strong>
Ngay trong kho mã nguồn của chúng tôi có lưu hai tệp văn bản sống còn:
• <strong>《Việc Kazik đã chốt》 (卡兹克定的事)</strong>: Chỉ ghi chép những quyết định do chính miệng tôi đưa ra, lưu kèm <strong>nguyên văn câu nói và ngày tháng</strong>.<br/>• <strong>《Việc đã chốt không làm》 (定了不做的事)</strong>: Ghi lại toàn bộ những đề xuất tôi đã từng từ chối. Từ đó về sau, bất kỳ Agent nào gặp lại đề xuất tương tự sẽ tự động đối chiếu tệp này để trả lời từ chối ngay, tuyệt đối không mang lên làm phiền tôi thêm lần nào nữa.
Cuối cùng, vẫn còn <strong>duy nhất một việc nhỏ mà tôi hoàn toàn không giao phó cho Agent tự quyết</strong>: mỗi một tin gửi về, tôi đều đích thân đọc từng chữ, rồi tự tay chọn ra những nội dung giá trị để chuyển cho Agent thực thi bước tiếp theo.
Đó chính là <strong>Phản hồi của người dùng (User Feedback)</strong>.
Mỗi ngày tôi đều nhận được rất nhiều tâm thư và góp ý trực tiếp từ người dùng, và tôi vô cùng biết ơn họ vì điều đó:
Chỉ cần là góp ý hợp lý và có thể làm được, tôi đều tự tay sao chép và giao cho Agent giải quyết triệt để. Và ngay sau khi Agent sửa xong và đẩy lên mạng, chúng tôi sẽ gửi lại vào hộp thư điện tử của người dùng đó một bức thư hồi âm chân thành nhất.
Có lẽ, đó là chút nghi thức kết nối giữa người với người cuối cùng mà tôi luôn muốn giữ lại trong một hệ thống tự động hóa toàn diện.
Lời kết: Hành trình 1 năm từ nhà thiết kế không biết code đến hệ sinh thái 9.000+ Stars
Trên đây là toàn bộ những khám phá, kiến trúc và bí quyết thực chiến của tôi trên hành trình xây dựng hệ thống tự động hóa Agent suốt một năm qua.
Chắc chắn tôi không phải là một kỹ sư phần mềm chuyên nghiệp, tôi chỉ muốn chia sẻ lại những kinh nghiệm và cách chơi của riêng mình — bởi đây thực sự là phương thức làm việc mang lại cho tôi cảm giác sảng khoái và tự do nhất trong thời gian qua. Biết đâu đấy, nếu những chia sẻ này thực sự giúp ích được cho một vài người đang loay hoay ngoài kia, thì đó đã là niềm vui lớn lao với tôi rồi.
Ngồi ngẫm lại chặng đường một năm qua, đôi lúc tôi vẫn thấy mọi thứ cứ như một giấc mơ kỳ diệu:
<strong>Một năm trước, tôi chỉ là một nhà thiết kế hoàn toàn mù tịt về lập trình.</strong>
<strong>Một năm sau — ngay hôm nay, tôi đã tự tay dựng nên Hệ thống Tự động hóa Agent của riêng mình, làm ra những sản phẩm cộng đồng phi lợi nhuận đạt hàng triệu người dùng hoạt động hàng tháng (MAU), mở mã nguồn trên GitHub và nhận về thành quả hơn 9.000 ngôi sao (Stars)</strong> cùng vô số lời nhắn gửi nói rằng sản phẩm đã thực sự giúp ích cho công việc của họ:
Không dừng lại ở đó, tôi còn dựng luôn hệ thống Trung đài cho cả công ty: chỉ mất đúng 5 ngày để thực hiện một cuộc cải tổ AI hóa toàn diện, dùng chính tư duy điều phối Agent này để nâng cấp cách vận hành của cả tập thể.
Mỗi một ngày trôi qua, tôi đều vừa học hỏi ngay trong lúc phát triển sản phẩm, vừa học hỏi ngay trong quá trình sáng tạo. Một năm trước, tôi thậm chí còn chẳng biết chữ <code>CI</code> nghĩa là gì; nửa năm trước, tôi còn chẳng hiểu <code>CDN</code> dùng để làm chi — nhưng tất cả những điều đó chẳng hề ngăn cản được việc ngày hôm nay tôi đã nắm vững và vận hành chúng trơn tru.
Đó có lẽ chính là niềm hạnh phúc thuần khiết nhất của việc không ngừng học hỏi.
Hy vọng bài viết hôm nay sẽ mang lại giá trị thiết thực cho bạn. Và cầu chúc cho tất cả chúng ta sẽ mãi mãi giữ trọn vẹn trí tò mò trước thế giới rộng lớn này!