Full transcript of “Harness Engineer — Bí Mật Đằng Sau Mọi AI Coding Agent Bạn Đang Dùng”. Click a timestamp to open the video at that moment. Need another video? Use the YouTube transcript generator.
0:00 3 giờ sáng. Terminal vẫn chạy. Một season của agent vẫn đang hoạt động. Không có ai ngồi trước màn hình. Bạn đang ngủ, code vẫn được mơ. Sở dĩ như vậy là nhờ một thứ tên là HANOS. Ngày đó có tên là HANOS Engineer. Đây là một trong những nghề đáng chú ý nhất của năm 2026. Lăng Grab, Autogen, Agent Loop, React, MCB, Cloud Code. Thuật ngữ xuất hiện khắp nơi, ai cũng nhắc tới. Nhưng câu hỏi thực sự là ai nuôi những con? Hiện khắp nơi, ai cũng nhắc tới. Nhưng câu hỏi thực sự là, ai nuôi những con AI đó chạy? Ai xây bộ khung để chúng tự hoạt động? Người ta gọi họ là HANET Engineer. Trong 20 phút tới, chúng ta sẽ làm 3 việc. Thứ nhất, làm rõ HANET là gì,
0:46 và đồng thời, phân biệt với những thứ không phải là HANET. Thứ hai, bóc tách chín thành phần lõi của một HANET hiện đại. Thứ ba, tự viết một HANET hoàn chỉnh. Không lăng trên, không frame away. Khi kết thúc video, bạn sẽ hiểu đủ để... Trong trên, không Frameway. Khi kết thúc video, bạn sẽ hiểu đủ để xây HANUS cho công ty mình. Chúng ta bắt đầu. Cơ dở là một HANUS. Cơ lâu cốt là một HANUS. Devin là một HANUS. AIDER là một HANUS. Tất cả những AI agent bạn đang dùng đều có chung một bộ khung bên trong. Nhưng chính xác, HANUS là cái gì? Chúng ta vào việc, phần 1, HANUS là cái gì? Harnet là cái gì? Bạn lướt Twitter
1:36 của giới lập trình, lướt Reddit, lướt Blog, chỗ nào cũng nhắc tới Harnet. Nhưng hỏi cụ thể nó là gì? Mỗi người trả lời một kiểu, có người bảo là Lung Grab, có người bảo là React, có người chỉ vào cơ giờ và nói, chính là cái này. Tất cả đều đúng một phần, và sai một phần. Để hiểu cho thâu đáo, chúng ta quay về gốc. Harnet, trong tiếng Anh gốc, có nghĩa là bộ yên cương. Harness, trong tiếng Anh gốc, có nghĩa là bộ yên cương, là cái khung dây gắn vào con ngựa để nó kéo được xe. Không phải để điều khiển con ngựa, mà để dẫn năng lượng của nó vào đúng việc cần làm. Trong AI, ý nghĩa hoàn toàn tương tự. Agent Thanos là bộ khung, bao gồm bộ nhớ, công cụ, quyền truy cập, luôn xử lý và các điểm hút an toàn.
2:24 Bộ khung này bao quanh một AI, để AI có thể chạy xuyên suốt nhiều phiên làm việc mà không mất phương hướng, không quên việc cũ và không phá file của bạn. Cơ dở là một HANUS, Cơ lau cốt là một HANUS, Devin là một HANUS, AIDER là một HANUS. Tất cả các AI cố định agent bạn đang dùng đều là HANUS. Đây là chỗ mà 90 % người bị nhầm. Lăng trên, Lăng Grab, Autogen, Crew AI đều không phải là HANUS. Chúng là Frame Music, khác nhau ở điểm nào. Framework là thư viện bạn gắn vào trong cốt của mình. Bạn là người cấu hình. Framework là thư viện bạn gắn vào trong cốt của mình. Bạn là người cấu hình, bạn là người gọi, còn HANET là một sản phẩm hoàn chỉnh. Bạn
3:10 giao cho nó nhiệm vụ, nó tự cấu hình, nó tự chạy. Một bên bạn lái, một bên nó lái bạn. Vài trò bị đảo ngược hoàn toàn. Bản chất là khác biệt về triết lý. Framework được viết cho lập trình viên dùng. HANET được viết cho AI dùng. Framework có hàng nghìn cách lập giáp. HANET chỉ có một con đường, mang tính định hướng cao. Framework đọc cốt HANET. Có một con đường, mang tính định hướng cao. Framework đọc code, Harness đọc mà đào. Hiểu được khác biệt này, bạn sẽ hiểu vì sao cơ giờ hay cơ lâu code không thể là lăng grab và ngược lại. Vậy Harness sinh ra để làm gì? Có bốn nhiệm vụ. Thứ nhất, giữ agent chạy được lâu, không sụp đổ sau 20 turn. Thứ hai, giữ agent nhớ mọi
3:56 thứ nó đã làm, dù chạy 4 giờ liền. Thứ ba, giữ agent không phá hệ thống, không xóa nhầm file, không put lên miền. Thứ tư, giữ agent biết khi nào này. Không xóa nhầm phai, không put lên miệt. Thứ tư, giữ agent biết khi nào nên dừng lại hỏi bạn và khi nào có thể tự quyết. 4 việc nghe có vẻ đơn giản, nhưng để làm được, cần đúng 9 thành phần, chúng ta bóc tách từng cái. Đây là bản đồ. 9 thành phần. 1. Vòng ngoài lúc. 2. Quản lý contact. 3. Skill và tool. 4 shop agent 5 built -in Q6, lưu trữ Season 7, lắp ráp System Pro. 8. Lycycle hook. 9. Permission và an toàn. tầm Pro. 8 Laycycle Hook 9 Permission và an toàn 2 thành phần đầu là bắt buộc thiếu
4:41 chúng thì không còn là HANUS 7 thành phần sau là cấp độ trưởng thành Càng đầy đủ HANUS càng hoàn thiện chúng ta đi vào từng phần Một vòng wide loop trái tim của mọi HANUS nghe có vẻ đơn giản nhưng đây lại là chỗ phần lớn người bị hiểu lầm ngay từ bước đầu Cấu trúc như sau Khi chưa xong model suy nghĩ model gọi tool đọc kết quả rồi nghĩ tiếp Lặp đi lặp lại Suy nghĩ, model gọi tool đọc kết quả, rồi nghĩ tiếp. Lặp đi lặp lại, cho tới khi model tự trả về stop region bằng enter. Mỗi vòng, model nhận toàn bộ contact, cùng các tin nhắn cũ và kết quả tool cũ, rồi quyết định bước tiếp theo. Nhưng điều quan trọng hơn nằm ở đây. Vòng ngoài là nơi duy nhất trong toàn bộ Hán Ước được phép gọi model. Không có thành phần nào khác gọi model trực tiếp. Bộ
5:28 quản lý contact không gọi model. Tân permission không gọi model. Chỉ có vòng lặp này. Tại sao lại như vậy? Vì khi bạn tập trung toàn bộ logic, gọi model về một. Tại sao lại như vậy? Vì khi bạn tập trung toàn bộ logic, gọi Moodle về một chỗ, bạn kiểm soát được Telemetry, kiểm soát được Retire, và kiểm soát được Hook. Và quan trọng nhất, bạn có một điểm duy nhất để dò lỗi khi mọi thứ trục chặt. Mọi thành phần khác, gồm Contact, Tool, Permission, Hook, đều tồn tại để phục vụ vòng lập này chạy lâu hơn và an toàn hơn. Hiểu được điều này, bạn sẽ hiểu vì sao Harness có kiến trúc đúng như nó đang có. 2. Quản lý Contact Vấn đề thực tế Cửa sổ Contact 2. Quản lý contact. Vấn đề thực tế, cửa sổ contact có hạng, 200 .000 token nghe có vẻ lớn, nhưng chạy vài
6:15 tiếng là đầy. Mà khi đầy, agent bắt đầu quên đầu quên đuôi, chất lượng output giảm rõ rệt. HANUS giải quyết bằng 3 chiến lược. 1. Giữ nguyên những gì quan trọng, đặc biệt là contact của tech hiện tại, và kết quả tool gần đây. 2. Tóm tắt. Gom các tin nhấn cũ, gọi model tóm tắt thành vài dòng, rồi thay thế bằng bản tóm tắt đó. 3. Bà lợi bỏ những gì đã hoàn toàn lỗi thời. Ngưỡng contact thông thường là 18 tin nhắn. đã hoàn toàn lỗi thời. Ngưỡng Compact thông thường là 18 tin nhắn. Khi vượt ngưỡng, giữ lại 4 tin nhắn gần nhất và tóm tắt phần còn lại. Tỷ lệ này không phải ngậu nhiên. Đủ ngắn để giải phóng contact, đủ dài để agent không mất mạch. Điểm thú vị là việc tóm tắt được thực hiện bởi chính model. Bạn gửi contact cho model và yêu cầu hãy tóm tắt nội dung này thành 10 dòng quan trọng nhất. Model tóm bạn thay thế. Như vậy, bản tóm
7:02 tắt vẫn giữ được ngữ nghĩa của domain. Đây là chỗ phân biệt Junior với Senior Hanot Engineer. Quyết sai, cửa sổ contact sẽ đầy Junior với Senior Harnot Engineer. Quyết sai, cửa sổ con tech sẽ đầy, đúng lúc agent đang dò lỗi cho một tech quan trọng nhất. Quyết đúng, agent chạy hết 8 tiếng vẫn tỉnh táo. Baskill và Tool. Đây là chỗ hay bị gộp làm một, nhưng thực ra rất khác nhau. Tool là primitive, là những hành động cơ bản nhất như zip file, bug, edit file, grep, uefx. Mỗi tool có một xk mà json mô tả input. Agent gọi tool bằng cách trả về json đúng xk. Harnot nhận thực thi. Agent gọi tool bằng cách trả về JSON đúng ít cây. Harness nhận, thực thi, và trả kết quả về. Một Harness có một bộ tool cơ bản dùng được ở
7:48 mọi nơi. Q thì khác. Q là các file mà đào hướng dẫn, gắn theo từng project cụ thể. Ví dụ, bạn có một skill tên là chuyển đổi dữ liệu cho đây, ta bệnh. Nội dung là một file mà đào, giải thích bước 1 sau lưu, bước 2 chạy migration, bước 3 verify số rộng. Agent đọc skill này, và biết rằng, khi gặp yêu cầu di trú dữ liệu, hãy làm theo đúng thứ tự đó. Tun trả lời câu hỏi, tôi có thể làm gì? Làm theo đúng thứ tự đó. Tun trả lời câu hỏi, tôi có thể làm gì? Cue trả lời câu hỏi, làm theo thứ tự nào? Một bên là viên gạch, mang tính phổ quát. Một bên là bản vẽ, cắn riêng với từng project. Ở giữa là Registry. biết, project này có những cue nào, tun nào. Khi ai dần cần, ai dần hỏi Registry, và Registry trả về danh sách đúng ngữ cảnh. Bộ tun phổ quát, bộ cue riêng theo project, Registry điều phối ở giữa. Đây là
8:37 kiến trúc. Bốn Sub -Agent, phần này cần thận trọng, sai một bước là hỏng cả season. Khi tách quá lớn, ví dụ tái cấu trúc toàn bộ phân hệ xác thực, viết kiểm thử, cập nhật tài liệu, agent chính sẽ quá tải. Contact đầy rất nhanh, sự chú ý bị phân tán. Agent bắt đầu làm sai. Giải pháp là sinh ra Sub -Agent. Agent chính không giao toàn bộ contact của nó cho Sub -Agent. Nó chỉ giao đúng những gì Sub -Agent cần, gồm tách rõ ràng, phai liên quan và permission tối thiểu. Cấp bầy dần chạy trong season. Ảng, file liên quan và permission tối thiểu. Cấp agent chạy trong season riêng, hoàn toàn cố lập. Khi xong, chỉ trả lại kết quả, chứ không trả lại toàn bộ lịch sử làm việc. Cách làm này tương tự như khi bạn giao việc cho một thực
9:25 tập sinh. Bạn không kể cho họ bạn đang làm gì cả tuần. Bạn chỉ nói file này, tech này, xong thì báo sub agent vận hành đúng như vậy. Lỗi thường gặp nhất là truyền toàn bộ con tech của agent chính vào sub agent. Kết quả, sub agent quá tải ngay từ đầu. Con tech bị nhồi những thứ sub agent không cần biết. Output kém chất lượng. Contact bị nhồi những thứ Sub -Agent không cần biết. Output kém chất lượng. Trong HANET của chúng tôi có 3 bộ Sub -Agent dựng sẵn, gồm Explore, General, Verify. Mỗi bộ có tập Permission và System Prom khác nhau. Dùng đúng bộ, Sub -Agent chạy sạch sẽ. 5. Building Q. Khác với các Q do người dùng tự định nghĩa cho Project. Q do bạn viết là hướng dẫn cụ thể cho code base của bạn, cho Webflow của team bạn. Building Q là phần HANET đã đóng gói sẵn. của team
10:14 bạc. Building Q là phần HANA đã đóng gói sẵn. Điểm quan trọng là agent biết tự động sử dụng khi cần mà không cần bạn nhắc. Ví dụ điển hình bộ tôn xử lý PDF khi agent gặp file PDF, bộ tôn xử lý actual khi gặp xl, tra cứu tài liệu trên web khi cần xử lý ảnh khi gặp ảnh. Những skill này có tính phổ quát, dùng được trên bất kỳ project nào. Đây là một trong những điểm khác biệt lớn nhất giữa cloud code, cursor và AIDA. Không phải vì mô đồ mạnh hay yếu, mà vì bộ built -in skill rộng hay hẹp. HANA nào có nhiều built -in skill chất Mà vì bộ built -in skill rộng hay hẹp, HANET nào có nhiều built -in skill chất lượng hơn, agent của nó xử lý được nhiều loại tech hơn mà không cần người dùng phải cấu hình thêm. Đây cũng là chỗ các vendor HANET đang cạnh tranh khốc liệt nhất hiện nay. 6.
11:01 Lưu trữ season Câu hỏi đặt ra rất đơn giản. Một season dài 4 tiếng, máy cơ ra giữa trừng có mất hết hay không? Câu trả lời, đối với một HANET đúng nghĩa là không bao giờ mất. Cơ chế hoạt động như sao? Mỗi tên gồm mỗi tin nhắn mỗi lần gọi túi. Cơ chế hoạt động như sau. Mỗi tên gồm mỗi tin nhắn mỗi lần gọi tool, mỗi kết quả tool đều được ghi ngay ra một file JSON -L theo kiểu append only. Không đợi xong tách mới ghi, không giữ trong bộ nhớ. Ghi ngay, flat ngay, từng dòng một. File JSON -L là định dạng lý tưởng cho việc này. Append có chi phí hàng số về thời gian, không cần khóa toàn bộ file, và crack giữa chừng cũng không làm hỏng dữ liệu đã ghi. Mỗi dòng độc lập, khi khởi động lại sau cơ ra, JSON đọc lại file từ đầu, chạy lại từng sự kiện, dựng lại mảng tin nhắn như cũ, và tiếp tục. Hay từ đầu, chạy
11:47 lại từng sự kiện, dựng lại mảng tin nhắn như cũ, và tiếp tục từ đúng chỗ nó đã dừng. Agent thậm chí không cần biết là đã có cờ ra xảy ra. Đây cũng là lý do, trong phiên bản mới nhất, Antropic đã tách hẳn Season thành một lớp độc lập. Season sống tách khỏi tiến trình của HANUS, và có thể tiếp tục từ bất kỳ máy nào có cùng file JSON -L đó. 7. Lắp ráp System Prom Đây là phần gây bất ngờ nhất với hầu hết mọi người khi lần đầu đọc mã nguồn của một HANUS. Khi lần đầu đọc mã nguồn của một HANET, bạn có thể nghĩ rằng System Prom là một chuỗi Ethering cố định, dán cứng trong code. Hoàn toàn không phải. System Prom là một pipeline. Nó được lắp ráp lại ở đầu mỗi season từ nhiều nguồn khác nhau. Phần 1, Static Carpho, là
12:33 nội dung cốt lõi của HANET, không thay đổi theo project. Đặt ở đâu? Thân thiện với card. Mô đồ có thể card phần này giữa các lần gọi, giúp tiết kiệm token. Phần 2, contact động. HANET đi từ thư mục hiện tại, leo ngược lên hệ thống tệp, gom mọi file tên Cloud. Node đi từ thư mục hiện tại, leo ngược lên hệ thống tệp, gom mọi file tên cloud .md, agent .md hoặc cloud .md. Mỗi file được nối vào, có ngân sách riêng, mặc định 4 .000 token cho mỗi file. Tổng contact động có một ngân sách chung là 12 .000 token. Vượt ngưỡng, phần dư sẽ bị cắt bớt. Kết quả là cùng một hà nớt, cùng một model, nhưng khi bạn mở project ta thì prompt khác hẳn project. Agent luôn biết nó đang làm việc trong contact của project nào mà không cần bạn giải thích lại từ đầu ở mỗi season. Hãy subscribe cho kênh La La School Để không bỏ lỡ những video hấp dẫn Bạn giải thích lại
13:20 từ đầu ở mỗi season. 8. Light cycle hook Là khoảnh khắc giữa các bước, giữa lúc model quyết định gọi một tool và lúc tool đó thực sự chạy, có một khoảng. đó chính là chỗ bạn cài hút vào. Có 4 hút chính trong một hàn ớt. Pre -tool code chạy trước khi tool thực thi. Post -tool code chạy sau khi tool hoàn tất. On error khi tool lỗi hoặc model gặp lỗi. On compression khi contact bị nén lại. Dùng để làm gì? Pre -tool code để ghi lại lần gọi tool, quét nội dung. Dùng để làm gì? Pre -Tool Code, để ghi lại lần gọi tool, quét nội dung xem có lộ khóa bí mật hay không, áp giới hạn tần suất. Post -Tool Code, để cập nhật telemetry, đêm số token đã dùng. On -Error, để retry với PROM đã được viết lại, hoặc chuyển sang cho người xử lý. On
14:06 -Compaction, để lưu lịch sử cũ ra file lưu chữ, trước khi bị xóa. Một Harness Engineer giỏi, là người biết đặt hút đúng chỗ, không thừa và không thiếu. Hút thừa, mỗi lần gọi tool phải chạy thêm hàng loạt việc, hệ thống chậm rõ rệt. Hút thiếu, lúc dò lỗi không có nhật ký để lần. Việc hệ thống chậm rõ rệt, húc thiếu, lúc dò lỗi không có nhật ký để lần. Đây cũng là chỗ doanh nghiệp tuy biến nhiều nhất so với bản mã nguồn mở. 9. Permission và an toàn. Đây là lớp cuối cùng và là lớp giúp bạn yên tâm khi agent làm việc suốt đêm. Không theo kiểu chặn hết để an toàn. Cũng không theo kiểu cho phép hết để thuận tiện. Mà phân tầng theo mức độ rủi ro. 3 mức. Read only, agent chỉ được đọc, không được ghi.
14:52 cũng được ghi. UC Pay Drive, agent được ghi trong thư mục Project, không được đụng ra ngoài. Full agent ghi mọi nơi, và cần xác nhận tướng minh từ bạn. Cơ chế phân loại động, cùng một tool back, nhưng lệnh LS thì tự động cho quà ở mức read only. Lệnh RM bị phân loại là full, và cần xác nhận, cùng một tool phân loại theo nội dung lệnh, chứ không theo tên tool. Đây là điều mà frame UC không có. Framework không phân loại lệnh. Framework không có khái niệm agent đang chạy ở mức permission nào. Framework cứ chạy là chạy, bạn tự lo phần còn lại. Nào, framework cứ chạy là chạy, bạn tự lo phần còn lại. Một harners có lớp permission là harners bạn có thể tin tưởng để giao cho tách dài ngày. Không có nó, bạn phải ngồi canh liên tục. Đây là điểm phân biệt một harners thật sự với một chatbot wrapper.
15:40 Tổng kết, 9 thành phần wide loop, contact, kill và tone sắp bay dần, đưa tin kill. Thì sần, trích tầm prompt hook, permission. Đủ chín bạn có một harners hiện đại. Thiếu, bạn chỉ có một chatbot vòng đời ngắn. Thứ 9, bạn có một HANUS hiện đại. Thiếu, bạn chỉ có một chatbot vòng đời ngắn. Phần 2 kết thúc. Phần 3, phần thú vị nhất. Tự xây dựng. Thuần Python. Không frame OC. Chúng ta bắt đầu. Đây là cấu trúc tổng thể. Một packet tên HANUS, gồm 9 module, mỗi cái đảm nhiệm một vai trò riêng vòng lập chính. Contact tool to Python, các lệnh tích hợp sẵn, lưu trữ di sản, lập giáp promhook và phân quyền. Các lệnh tích hợp sẵn, lưu trữ Season, lắp dắp Prom Hook và phân quyền, thêm một
16:29 mô đun nữa để bọc lại API của mô đồ. Bên ngoài là Project Demo, có file Cloud .md, file chạy chính, file test và file khởi động. 17 test path, không phụ thuộc frame OC nào. Giờ mình mở từng phần. File Loop là trái tim của HANUS, một LX agent với method Zune, nhận vào một mục tiêu dạng Steering. Đầu tiên lắp dắp System Prom từ thư mục hiện tại, khởi tạo danh sách tiến. Đầu tiên lắp ráp system prompt từ thư mục hiện tại, khởi tạo danh sách tin nhắn rỗng, vào vòng lập tối đa 100 bước. Mỗi vòng, nếu danh sách tin nhắn quá dài thì nén lại trước, sau đó gọi mua đồ, nhận phản hồi. Nếu mua đồ báo xong việc, return luôn. Nếu mua đồ muốn gọi tool, đi spark tool đó, gắn kết quả vào danh sách, rồi lập tiếp. Hết số bước vẫn chưa xong thì báo lỗi tham out,
17:17 tổng cộng 30 dòng. Không phụ thuộc gì bên ngoài. Đây là toàn bộ động cơ contact, tool, permission đều được tiêm vào từ bên ngoài. Hãy subscribe cho kênh La La School Để không bỏ lỡ những video hấp dẫn Permission đều được tiêm vào từ bên ngoài. Phải contact lo, việc quản lý độ dài hội thoại. Contact Manager là một DataTLS có 2 tham số ngưỡng nén, mặc định 18 tin nhắn, và số tin nhắn gần nhất cần giữ lại mặc định 4. Khi được gọi, nó đếm số tin nhắn hiện tại. Nếu còn dưới ngưỡng, không làm gì. Nếu vượt ngưỡng, tách phần đầu ra, tóm tắt lại bằng mô đồ, rồi trả về một danh sách mới, công bản tóm tắt đó và 4 tin nhắn cuối cùng. Quan trọng là nó không sửa danh sách cũ tại chỗ, nó trả về. Tin nhắn cuối cùng. Quan trọng là nó không sửa danh sách cũ tại chỗ, nó trả về danh sách mới hoàn toàn.
18:03 Cách làm này dễ test hơn, dễ dò lỗi hơn nhiều. Phải tuôn định nghĩa cách đăng ký và tra cứu tuôn. là một đầy TATLIS có tên, mô tả, xk tham số dặn JSON, hàm xử lý và mức permission yêu cầu. Tuôn registry lưu tất cả vào một từ điển. Muốn thêm tuôn thì gọi register. Muốn lấy ra thì tra theo tên, nếu không có thì báo lỗi. Còn một method trả về danh sách ngô tả. Tra theo tên, nếu không có thì báo lỗi. Còn một method trả về danh sách ngô tả để truyền vào lần gọi API để mô đồ biết tool nào đang khả dụng. Khi mô đồ trả về yêu cầu gọi tool, vòng lọc tra cứu registry, kiểm tra permission, gọi hàm xử lý, rồi gắn kết quả vào tin nhắn. Đơn giản vậy thôi một tư điển. Không có desigrate tờ ký bí, không tự dò code. Mọi tool đều
18:49 phải đăng ký tưởng minh, ai đọc vào cũng biết hệ thống đang có gì. File Supervision định nghĩa 3 kiểu subagent dựng sẵn. File Supergen định nghĩa 3 kiểu Sub -Agent dựng sẵn. Explore chỉ có quyền đọc, dùng để đọc file và tìm kiếm. System Prom nhắc rõ chỉ được đọc thôi. General Law quyền Utilize, đầy đủ tôn dùng để thực thi việc chính. Verify quyền Utilize, có thêm bác để chạy test, dùng để xác nhận thay đổi. 3 kiểu này đủ xử lý 90 % yêu kết rồi. File Position Law, việc lưu và phục hồi Season. Khi khởi tạo, nó nhận đường dẫn file và tự tạo thư mục trà nếu chưa có. Mỗi lần có sự kiện mới, Đừng dẫn file và tự tạo thư mục trà nếu chưa có. Mỗi lần có sự kiện mới,
19:35 nó sẽ relight thành dây son, kể cả dead tie và các kiểu đặc biệt, rồi ghi thêm vào cuối file ngay lập tức, không chờ. Khi cần phục hồi, đọc lại từng dòng, bác xe ra, trả về danh sách sự kiện theo thứ tự. Không có cap, không có buffer phức tạp. Cơ ra giữa chừng thì khởi động lại là chạy tiếp được, chính xác từ điểm dừng. File Chrome lo việc lắp ráp system Chrome trước mỗi lần gọi mua đồ. Bắt đầu bằng phần khung tĩnh, phần này ít thay đổi. Hôm trước mỗi lần gọi mua đồ. Bắt đầu bằng phần khung tĩnh phần này ít thay đổi nên cắt hit rất cao. Tiếp theo, nó đi ngược lên cây thư mục từ vị trí hiện tại, thu thập tất cả file cloud .md và agent .md gặp được. Mỗi file có ngân sách token riêng, tổng cũng có giới hạn chung. Nếu vượt thì cắt bớt, cuối cùng nối tất cả lại, xong.
20:23 File permission định nghĩa 3 mức phân quyền chỉ đọc, UTPay và toàn quyền dưới dạng STO ring. Có một bảng điểm số để so sánh giữa các mức, khi cần phân loại. có một bảng điểm số để so sánh giữa các mức. Khi cần phân loại một lệnh bác, nó tách lệnh ra rồi kiểm tra từ khóa đầu tiên. Các lệnh như LS, Cut, Grab thì xếp vào nhóm chỉ đọc. Các lệnh như ARM, Sudo, KIN thì xếp vào nhóm toàn quyền. Còn lại thì WhatsApp Pay. Trước khi chạy bất kỳ tool nào, so sánh mức permission của tool với mức được cấp cho agent đủ thì cho chạy, không đủ thì chặn. Lớp này nhỏ, nhưng giúp bạn yên tâm hơn rất nhiều khi để agent tự chạy. Vậy vì sao bây giờ là thời điểm vàng? của Hanot Engineer? Vì 2026 là năm mà bản chất AI đang chuyển dịch. Từ
21:12 co -pilot, ngồi cạnh bạn để cốt, sang agent tự hành, tự chạy mà không cần bạn. Và mọi công ty đang dùng AI để cốt, đều sẽ cần ít nhất một Hanot Engineer để xây Hanot riêng cho cốt bay của họ. Cung chưa có, cầu đang bùng nổ. Lương ở Mỹ, 6 chữ số là mức sàn, ở Việt Nam đã bắt đầu xuất hiện vị trí Michigan, trả gấp đôi mặt bằng chung. Hãy subscribe cho kênh La La School Để không bỏ lỡ những video hấp dẫn thì Metinia trả gấp đôi mặt bằng chung. Trong tương lai gần, sẽ không còn AI chung chung nữa. Sẽ là AI cho tự động hóa, email tiếp thị, AI cho giả soát hợp đồng pháp lý, AI cho giám sát vận hành bệnh viện, AI cho sàng lọc khách hàng tiêm năng trong pipe của lên bán hàng, AI cho quản lý kho trong sản xuất. Mỗi lĩnh vực có đặc thù riêng, gồm tên file, quy trình, tool nội bộ và mô hình permission.
22:00 Tất cả đều khác nhau hoàn toàn, không thể dùng chung một hàn ớt chung chung cho tất cả, bắt buộc phải chạy. Toàn toàn, không thể dùng chung một HANET chung chung cho tất cả, bắt buộc phải tinh chỉnh riêng. Và đây cũng là cơ hội lớn nhất trong 6 đến 12 tháng tới. Người nào hiểu cả kỹ thuật HANET lẫn nhiệm vụ của một lĩnh vực, ví dụ ngân hàng, y tế, hậu cần người đó có một lợi thế mà AI không thể sao chép. Vì HANET Engineer không chỉ cần biết code, cần biết domain đủ sâu, đến mức biết được cái gì có thể ủy quyền cho agent và cái gì bắt buộc phải có người kiểm duyệt. Muốn vào nghề, có 3 bước. Một xem lại video này, hiểu rõ 9 thành phần. Hai, Cloud Repo Demo, tự viết lại từ đầu. Ba
22:46 chọn một lĩnh vực bạn đã có kinh nghiệm, ví dụ ngân hàng, thương mại điện tử, hoặc sản xuất, và xây HANET cho lĩnh vực đó. Khi đã có một HANET Production Ready trong tay, bạn sẽ không thiếu cơ hội việc làm. Cảm ơn bạn đã theo dõi đến phút thứ 20. Nếu video này hữu ích, hãy bấm thích, bình luận và đăng ký. để ủng hộ kênh. Hẹn gặp lại.
