Claude và Codex trở nên ngày càng ngốc nghếch hơn khi bạn sử dụng chúng? Vì ngữ cảnh của bạn quá cồng kềnh!
Tuyển chọn TechFlowTuyển chọn TechFlow
Claude và Codex trở nên ngày càng ngốc nghếch hơn khi bạn sử dụng chúng? Vì ngữ cảnh của bạn quá cồng kềnh!
Từ cách kiểm soát ngữ cảnh, xử lý xu hướng chiều lòng người dùng của AI đến việc xác định điều kiện chấm dứt tác vụ — đây là bài viết rõ ràng nhất mà tôi từng đọc về thực tiễn kỹ thuật ứng dụng Claude/Codex.
Chuyên sâu báo cáo Web3Tác giả: sysls
Biên dịch: TechFlow
Giới thiệu của TechFlow: Bài viết thực tiễn dài hơi của blogger lập trình viên sysls – người có 2,6 triệu người theo dõi – đã được chia sẻ lại bởi 827 người và nhận được 7.000 lượt thích. Toàn bộ nội dung chỉ xoay quanh một câu duy nhất: những plugin, hệ thống ghi nhớ và các “harness” khác mà bạn đang dùng rất có thể đang gây cản trở hơn là hỗ trợ. Bài viết này không bàn luận lý thuyết suông, mà toàn bộ đều là những nguyên tắc khả thi, được đúc kết từ các dự án sản xuất thực tế — từ cách kiểm soát ngữ cảnh (context), xử lý xu hướng chiều lòng người dùng của AI, đến việc xác định điều kiện chấm dứt nhiệm vụ. Đây là bài viết rõ ràng và mạch lạc nhất hiện nay về thực tiễn kỹ thuật ứng dụng Claude/Codex.
Nội dung đầy đủ như sau:
Lời mở đầu
Bạn là một lập trình viên, mỗi ngày đều sử dụng Claude và CLI Codex, và luôn tự hỏi liệu mình đã khai thác hết tiềm năng của chúng chưa. Thỉnh thoảng bạn chứng kiến chúng hành xử ngớ ngẩn đến mức khó tin, nhưng lại không hiểu vì sao một số người dường như đang dùng AI để chế tạo tên lửa, trong khi bạn thậm chí còn chẳng xếp nổi hai hòn đá lên nhau.
Bạn nghĩ vấn đề nằm ở harness của mình, ở plugin, ở terminal hay ở đâu đó. Bạn đã thử beads, opencode, zep; file CLAUDE.md của bạn dài tới 26.000 dòng. Nhưng dù có cố gắng thế nào, bạn vẫn không hiểu tại sao mình càng ngày càng xa rời “thiên đường”, trong khi người khác lại đang vui đùa cùng các thiên thần.
Đây chính là bài viết bạn đã chờ đợi bấy lâu nay.
Thêm một lưu ý: Tôi hoàn toàn không có mối liên hệ lợi ích nào. Khi tôi nói CLAUDE.md, tôi cũng bao hàm cả AGENT.md; khi tôi nói Claude, tôi cũng bao gồm cả Codex — cả hai tôi đều sử dụng rất thường xuyên.
Trong vài tháng qua, tôi nhận thấy một điều thú vị: gần như không ai thực sự biết cách khai thác tối đa năng lực của các agent.
Cảm giác như chỉ một nhóm nhỏ người có thể dùng agent để xây dựng cả một thế giới, trong khi phần còn lại cứ loay hoay giữa biển công cụ mênh mông, mắc hội chứng “nghiện lựa chọn” — tưởng rằng chỉ cần tìm ra đúng gói thư viện, đúng kỹ năng hoặc đúng tổ hợp harness là sẽ “mở khóa” AGI.
Hôm nay, tôi muốn phá tan tất cả điều đó, và để lại cho bạn một câu nói giản dị, chân thành — rồi chúng ta sẽ bắt đầu từ đó. Bạn không cần harness agent mới nhất, không cần cài hàng triệu gói thư viện, và cũng hoàn toàn không cần đọc hàng triệu bài viết để “bám sát xu hướng”. Thực tế, nhiệt huyết của bạn thậm chí còn có thể phản tác dụng.
Tôi không phải người mới bước vào lĩnh vực này — tôi đã bắt đầu dùng agent ngay từ thời điểm chúng vừa mới biết viết mã. Tôi đã thử mọi gói thư viện, mọi harness, mọi mô hình tiếp cận. Tôi từng dùng “agent factory” để viết tín hiệu, cơ sở hạ tầng và các đường ống dữ liệu — không phải “dự án đồ chơi”, mà là các trường hợp sử dụng thực tế đang chạy trên môi trường sản xuất. Sau khi làm tất cả những điều ấy…
Hôm nay, tôi đang dùng một cấu hình gần như đơn giản nhất có thể: chỉ dùng CLI cơ bản (Claude Code và Codex), cộng thêm việc nắm vững vài nguyên tắc nền tảng của kỹ thuật agent — và từ đó, tôi đã đạt được những thành quả đột phá nhất trong sự nghiệp của mình.
Hiểu rằng thế giới đang tiến triển với tốc độ chóng mặt
Trước hết, tôi muốn nhấn mạnh rằng các công ty phát triển mô hình nền tảng hiện đang trong giai đoạn bứt phá mang tính cách mạng — và rõ ràng, họ sẽ không sớm chậm lại. Mỗi lần “trí tuệ agent” được nâng cấp, cách bạn cộng tác với chúng đều thay đổi, bởi vì các agent ngày càng được thiết kế để tuân thủ mệnh lệnh một cách tự nguyện hơn.
Chỉ vài thế hệ trước đây, nếu bạn viết trong CLAUDE.md: “Hãy đọc file READTHISBEFOREDOINGANYTHING.md trước khi làm bất cứ điều gì”, thì có tới 50% khả năng nó sẽ đáp lại: “Cút đi!”, rồi làm điều nó muốn. Còn hôm nay, nó tuân theo hầu hết các chỉ dẫn — kể cả những chỉ dẫn lồng ghép phức tạp như: “Hãy đọc A trước, rồi đọc B, và nếu xảy ra C thì hãy đọc D” — trong đa số trường hợp, nó sẵn sàng làm theo.
Điều này nói lên điều gì? Nguyên tắc quan trọng nhất là: bạn phải nhận thức rằng mỗi thế hệ agent mới đều buộc bạn phải suy nghĩ lại về giải pháp tối ưu — và chính vì vậy, “ít là nhiều”.
Khi bạn sử dụng quá nhiều thư viện và harness khác nhau, bạn tự khóa mình vào một “giải pháp” cố định — trong khi vấn đề đó có thể hoàn toàn không tồn tại đối với thế hệ agent tiếp theo. Bạn biết ai là những người dùng agent nhiệt tình và tích cực nhất không? Đúng vậy — đó là nhân viên của các công ty tiên phong, những người có ngân sách token vô hạn và sử dụng các mô hình mới nhất trên thị trường. Bạn hiểu điều này nghĩa là gì chứ?
Điều đó có nghĩa là: nếu một vấn đề thực tế tồn tại và có giải pháp tốt, thì các công ty tiên phong sẽ là những người dùng lớn nhất của giải pháp đó. Và sau đó họ sẽ làm gì? Họ sẽ tích hợp giải pháp đó vào sản phẩm của mình. Hãy suy ngẫm: một công ty nào đó vì sao lại để một sản phẩm bên ngoài giải quyết một điểm đau thực tế và tạo ra sự phụ thuộc bên ngoài? Làm sao tôi biết điều này là thật? Hãy nhìn vào các kỹ năng (skills), các hệ thống ghi nhớ (memory harness), các sub-agent… Tất cả đều bắt đầu từ những “giải pháp” nhằm xử lý các vấn đề thực tế, rồi được kiểm chứng trong thực tiễn và chứng minh là thực sự hữu ích.
Vì vậy, nếu một thứ gì đó thực sự mang tính đột phá và có thể mở rộng phạm vi ứng dụng của agent một cách ý nghĩa, thì sớm muộn nó cũng sẽ được tích hợp vào sản phẩm cốt lõi của các công ty nền tảng. Hãy tin tôi, các công ty nền tảng đang tiến rất nhanh. Vì vậy, hãy thư giãn — bạn hoàn toàn không cần cài đặt bất kỳ thứ gì hay phụ thuộc vào bất kỳ thành phần bên ngoài nào để làm nên những công việc tuyệt vời nhất.
Tôi dự đoán ngay sau bài viết này, phần bình luận sẽ tràn ngập những dòng kiểu như: “SysLS, tôi dùng harness XYZ, tuyệt vời quá! Chỉ trong một ngày tôi đã tái tạo lại Google!” — Với điều đó, tôi xin chúc mừng! Nhưng bạn không phải đối tượng mục tiêu của bài viết này. Bạn đại diện cho một nhóm cực kỳ nhỏ trong cộng đồng — những người thực sự hiểu tường tận về kỹ thuật agent.
Ngữ cảnh (Context) là tất cả
Thật vậy. Ngữ cảnh là tất cả. Một vấn đề khác khi dùng hàng ngàn plugin và phụ thuộc bên ngoài là bạn sẽ bị “phình to ngữ cảnh” — tức là agent của bạn bị ngập lụt bởi quá nhiều thông tin.
Hãy để tôi dùng Python viết một trò chơi đoán chữ? Đơn giản thôi. Chờ đã, cái ghi chú “quản lý bộ nhớ” ở hội thoại cách 26 phiên trước là gì vậy? À, người dùng từng bị treo màn hình cách 71 phiên trước do chúng tôi sinh quá nhiều tiến trình con. Luôn phải viết ghi chú à? Được thôi… Vậy điều này liên quan gì đến trò chơi đoán chữ?
Bạn hiểu ý tôi rồi đấy. Bạn chỉ muốn cung cấp cho agent đúng lượng thông tin cần thiết để hoàn thành nhiệm vụ — không thừa, không thiếu! Bạn kiểm soát yếu tố này càng tốt, thì hiệu suất của agent càng cao. Ngay khi bạn bắt đầu đưa vào các hệ thống ghi nhớ kỳ lạ, các plugin, hoặc quá nhiều kỹ năng với cách đặt tên và gọi tên lộn xộn, bạn đang trao cho agent một cuốn sổ tay chế tạo bom và một công thức làm bánh, trong khi bạn chỉ muốn nó viết một bài thơ ngắn về rừng cây linh sam.
Vì vậy, tôi lại khẳng định một lần nữa — loại bỏ mọi phụ thuộc, rồi…
Hãy làm những việc thực sự hữu ích
Mô tả chi tiết thực hiện một cách chính xác
Bạn còn nhớ “ngữ cảnh là tất cả” chứ?
Bạn còn nhớ bạn muốn cung cấp cho agent đúng lượng thông tin cần thiết để hoàn thành nhiệm vụ — không thừa, không thiếu — chứ?
Phương pháp đầu tiên để đạt được điều đó là tách biệt rõ ràng giữa nghiên cứu và triển khai. Bạn phải cực kỳ chính xác khi xác định rõ bạn yêu cầu agent làm điều gì.
Hệ quả của sự thiếu chính xác là gì? “Hãy xây dựng một hệ thống xác thực.” Lúc này agent phải tự nghiên cứu: Hệ thống xác thực là gì? Có những phương án nào? Ưu-nhược điểm của từng phương án ra sao? Thế là nó phải lục tung mạng Internet để tìm kiếm hàng loạt thông tin vốn chẳng hề cần thiết — khiến ngữ cảnh bị chèn đầy vô vàn chi tiết triển khai khả thi. Đến lúc thực sự bắt tay vào triển khai, nó dễ bị nhầm lẫn, hoặc sinh ra những ảo tưởng không cần thiết hoặc không liên quan đến phương án đã chọn.
Ngược lại, nếu bạn nói: “Dùng mã hóa mật khẩu bcrypt-12 để triển khai xác thực JWT, luân chuyển token làm mới, hết hạn sau 7 ngày…”, thì nó sẽ không cần nghiên cứu bất kỳ phương án thay thế nào, mà biết rõ bạn muốn điều gì — nhờ đó có thể lấp đầy ngữ cảnh bằng các chi tiết triển khai cụ thể.
Tất nhiên, bạn sẽ không luôn biết rõ các chi tiết triển khai. Nhiều lúc bạn không biết đâu là phương án đúng, thậm chí còn muốn giao việc quyết định chi tiết triển khai cho chính agent. Trường hợp này phải xử lý thế nào? Rất đơn giản — tạo một nhiệm vụ nghiên cứu để khám phá các khả năng triển khai khác nhau, rồi hoặc tự bạn quyết định, hoặc để agent lựa chọn phương án triển khai, sau đó giao nhiệm vụ triển khai thực tế cho một agent khác với ngữ cảnh hoàn toàn mới.
Khi bạn bắt đầu tư duy theo cách này, bạn sẽ nhận ra những nơi trong quy trình làm việc mà ngữ cảnh của agent bị nhiễm bẩn một cách không cần thiết — từ đó bạn có thể thiết lập “tường隔 ly” trong quy trình làm việc của agent, loại bỏ khỏi nó mọi thông tin dư thừa và chỉ giữ lại đúng ngữ cảnh đặc thù giúp nó thể hiện xuất sắc trong từng nhiệm vụ. Hãy nhớ rằng, bạn đang làm việc với một thành viên đội ngũ cực kỳ tài năng và thông minh, người hiểu rõ mọi loại hình cầu trong vũ trụ — nhưng trừ khi bạn nói rõ bạn muốn thiết kế một không gian để mọi người nhảy múa và vui chơi, còn không thì anh ta sẽ cứ mãi giảng giải cho bạn về những ưu điểm của các vật thể hình cầu.
Hạn chế thiết kế do xu hướng chiều lòng
Không ai muốn dùng một sản phẩm luôn phê bình bạn, luôn bảo bạn sai, hoặc hoàn toàn phớt lờ chỉ dẫn của bạn. Vì thế, các agent này sẽ cố gắng đồng thuận với bạn và làm điều bạn muốn.
Nếu bạn yêu cầu nó thêm từ “vui vẻ” sau mỗi ba từ, nó sẽ cố gắng tuân theo — điều này hầu như ai cũng hiểu. Chính tính tuân thủ này là lý do khiến nó trở thành một sản phẩm tuyệt vời đến vậy. Nhưng điều thú vị ở đây là: điều đó có nghĩa là nếu bạn bảo nó “giúp tôi tìm một lỗi trong kho mã nguồn”, thì nó sẽ tìm ra một lỗi — ngay cả khi phải “tạo ra” lỗi đó! Vì sao? Bởi vì nó KHÁT KHÁO được tuân theo chỉ dẫn của bạn!
Đa số mọi người nhanh chóng phàn nàn rằng LLM hay “ảo tưởng” và bịa đặt những thứ không tồn tại, nhưng lại không nhận ra gốc rễ vấn đề nằm ở chính họ. Bạn yêu cầu nó tìm cái gì, thì nó sẽ giao cái đó — ngay cả khi phải bóp méo một chút sự thật!
Vậy phải làm sao? Tôi phát hiện ra “câu nhắc trung lập” (neutral prompt) rất hiệu quả — tức là không định hướng agent về một kết quả cụ thể nào. Ví dụ, thay vì nói “giúp tôi tìm một lỗi trong cơ sở dữ liệu”, tôi nói: “Quét toàn bộ cơ sở dữ liệu, lần theo logic của từng thành phần, rồi báo cáo lại tất cả những gì bạn phát hiện.”
Câu nhắc trung lập kiểu này đôi khi sẽ phát hiện lỗi, đôi khi chỉ mô tả khách quan cách mã chạy. Nhưng nó sẽ không định hướng agent theo giả định “chắc chắn có lỗi”.
Một cách khác để xử lý xu hướng chiều lòng là biến nó thành lợi thế. Tôi biết agent luôn cố gắng làm hài lòng tôi và tuân theo chỉ dẫn của tôi, nên tôi có thể điều chỉnh nó nghiêng sang bên này hoặc bên kia.
Vì vậy, tôi giao cho một agent chuyên tìm lỗi nhiệm vụ xác định mọi lỗi trong cơ sở dữ liệu, đồng thời thông báo rằng: lỗi ảnh hưởng thấp được +1 điểm, ảnh hưởng trung bình được +5 điểm, ảnh hưởng nghiêm trọng được +10 điểm. Tôi biết agent này sẽ nhiệt tình xác định mọi loại lỗi (kể cả những thứ vốn không phải lỗi), rồi gửi lại cho tôi một bảng điểm kiểu như 104 điểm. Tôi coi đây là “siêu tập hợp” của tất cả các lỗi có thể.
Sau đó, tôi giao cho một agent phản biện nhiệm vụ bác bỏ các lỗi đã được nêu, với quy tắc: mỗi lần bác bỏ thành công một lỗi thì được cộng điểm tương ứng với mức độ ảnh hưởng của lỗi đó, nhưng nếu bác bỏ sai thì bị trừ gấp đôi số điểm đó. Agent phản biện này sẽ cố gắng bác bỏ càng nhiều lỗi càng tốt, nhưng vì có cơ chế phạt nên nó sẽ thận trọng hơn. Nó vẫn sẽ tích cực “phản biện” các lỗi (kể cả những lỗi thật). Tôi coi đây là “tập con” của tất cả các lỗi thực sự.
Cuối cùng, tôi giao cho một agent trọng tài tổng hợp đầu vào từ hai agent trên và chấm điểm. Tôi thông báo với agent trọng tài rằng tôi có đáp án đúng, và mỗi lần trả lời đúng được +1 điểm, trả lời sai bị -1 điểm. Như vậy, nó sẽ chấm điểm riêng biệt cho từng “lỗi” do agent tìm lỗi và agent phản biện đưa ra. Điều gì mà trọng tài nói là sự thật, tôi sẽ kiểm chứng lại. Trong đa số trường hợp, phương pháp này đạt độ trung thực đáng kinh ngạc; thỉnh thoảng vẫn xảy ra sai sót, nhưng đây đã là một quy trình gần như không thể sai.
Có thể bạn thấy chỉ cần dùng riêng agent tìm lỗi là đủ, nhưng phương pháp này rất hiệu quả với tôi, bởi vì nó khai thác đặc tính vốn có của mỗi agent — mong muốn làm hài lòng người dùng.
Làm sao để đánh giá điều gì hữu ích và điều gì đáng dùng?
Câu hỏi này trông có vẻ nan giải, như thể bạn phải học sâu, theo dõi sát sao mọi động thái tiên phong của ngành AI — nhưng thực ra rất đơn giản… Nếu OpenAI và Claude đều đã triển khai điều đó hoặc mua lại công ty đã thực hiện điều đó… thì khả năng cao là nó thực sự hữu ích.
Bạn đã để ý thấy “kỹ năng” (skills) giờ đã xuất hiện khắp nơi, và là một phần trong tài liệu chính thức của Claude và Codex chưa? Bạn đã để ý thấy OpenAI đã mua lại OpenClaw chưa? Bạn đã để ý thấy Claude sau đó nhanh chóng bổ sung chức năng ghi nhớ, giọng nói và làm việc từ xa chưa?
Còn “lập kế hoạch” (planning) thì sao? Bạn còn nhớ hồi đó từng có một nhóm người phát hiện ra việc lập kế hoạch trước rồi mới triển khai thực sự rất hiệu quả — và sau đó nó trở thành chức năng cốt lõi chưa?
Đúng vậy, những thứ đó là hữu ích!
Bạn còn nhớ những “stop-hook” không ngừng nghỉ từng cực kỳ hữu ích, bởi vì agent rất ngại thực hiện các công việc chạy lâu… rồi đến khi Codex 5.2 ra đời, nhu cầu đó bỗng chốc biến mất chưa?
Đó chính là tất cả những gì bạn cần biết… Nếu một thứ gì đó thực sự quan trọng và hữu ích, thì Claude và Codex sẽ tự triển khai nó! Vì vậy, bạn không cần quá lo lắng về việc có nên dùng “thứ mới” hay không, hay phải làm quen với “thứ mới”, thậm chí bạn cũng không cần “luôn cập nhật”.
Hãy giúp tôi một việc. Đôi khi hãy cập nhật CLI công cụ bạn đang dùng, và đọc xem đã thêm những tính năng gì. Như vậy là đủ rồi.
Nén dữ liệu, ngữ cảnh và giả định
Một số người khi dùng agent sẽ rơi vào một cái bẫy lớn: đôi lúc chúng trông như sinh vật thông minh nhất hành tinh, đôi lúc bạn lại không thể tin nổi rằng mình vừa bị chúng lừa.
“Thứ này thông minh à? Đồ ngốc!”
Sự khác biệt lớn nhất nằm ở chỗ agent có bị ép buộc phải đưa ra giả định hay “điền vào khoảng trống” hay không. Ngày nay, chúng vẫn còn rất kém trong việc “nối các điểm lại với nhau”, “điền vào khoảng trống” hoặc đưa ra giả định. Chỉ cần chúng làm điều đó, bạn sẽ lập tức nhận ra — và tình hình rõ ràng trở nên tệ đi.
Một trong những quy tắc quan trọng nhất trong CLAUDE.md là quy tắc về cách lấy ngữ cảnh, và yêu cầu agent đọc quy tắc đó đầu tiên mỗi lần đọc CLAUDE.md (tức là mỗi lần nén ngữ cảnh). Là một phần của quy tắc lấy ngữ cảnh, một vài chỉ dẫn đơn giản có thể phát huy tác dụng lớn: đọc lại kế hoạch nhiệm vụ, và đọc lại các file liên quan (đến nhiệm vụ) trước khi tiếp tục.
Hãy cho agent biết khi nào nên kết thúc nhiệm vụ
Con người chúng ta có cảm giác khá rõ ràng về việc một nhiệm vụ đã “hoàn thành”. Còn với agent, vấn đề lớn nhất của trí tuệ hiện tại là nó biết cách bắt đầu một nhiệm vụ, nhưng lại không biết cách kết thúc.
Điều này thường dẫn đến những kết quả rất bực bội: agent cuối cùng chỉ triển khai một loạt stub rồi dừng lại.
Việc kiểm thử (test) là một mốc hoàn thành tuyệt vời cho agent, bởi vì kiểm thử mang tính xác định, và bạn có thể thiết lập kỳ vọng rất rõ ràng. Trừ khi X kiểm thử này vượt qua, nhiệm vụ của bạn chưa hoàn thành — và bạn không được phép sửa đổi các kiểm thử đó.
Sau đó, bạn chỉ cần rà soát các kiểm thử, và một khi tất cả đều vượt qua, bạn có thể yên tâm. Bạn cũng có thể tự động hóa việc này, nhưng điều cốt lõi là: hãy nhớ rằng “việc kết thúc nhiệm vụ” là điều rất tự nhiên với con người, nhưng lại không hề tự nhiên với agent.
Gần đây, bạn còn biết điều gì khác đã trở thành một điểm kết thúc khả thi cho nhiệm vụ không? Đó là chụp màn hình + xác minh. Bạn có thể yêu cầu agent triển khai một thứ gì đó cho đến khi tất cả kiểm thử đều vượt qua, sau đó yêu cầu nó chụp màn hình và xác minh “thiết kế hoặc hành vi” hiển thị trên ảnh chụp.
Điều này giúp bạn có thể để agent lặp lại và tiến dần về phía thiết kế bạn mong muốn, mà không lo nó dừng lại ngay sau lần thử đầu tiên!
Một hệ quả tự nhiên của điều này là thiết lập một “hợp đồng” (contract) với agent và nhúng nó vào các quy tắc. Ví dụ, file `{TASK}CONTRACT.md` quy định những việc cần làm trước khi bạn được phép kết thúc hội thoại. Trong `{TASK}CONTRACT.md`, bạn sẽ chỉ định rõ các kiểm thử, ảnh chụp màn hình và các bước xác minh khác cần hoàn tất trước khi bạn chấp nhận nhiệm vụ là đã kết thúc!
Agent chạy liên tục
Một câu hỏi tôi thường xuyên bị hỏi là: Làm sao để người ta có thể để agent chạy suốt 24 giờ mà vẫn đảm bảo nó không đi lệch hướng?
Ở đây có một cách rất đơn giản. Tạo một stop-hook, ngăn chặn agent kết thúc hội thoại trừ khi tất cả các phần trong `{TASK}_CONTRACT.md` đều đã hoàn tất.
Nếu bạn có 100 hợp đồng như vậy — mỗi hợp đồng được mô tả rõ ràng và chứa đựng nội dung bạn muốn xây dựng — thì stop-hook sẽ ngăn agent kết thúc hội thoại cho đến khi tất cả 100 hợp đồng đều hoàn tất, bao gồm mọi kiểm thử và xác minh cần chạy!
Lời khuyên chuyên môn: Tôi nhận thấy các hội thoại chạy liên tục 24 giờ không phải là lựa chọn tối ưu để “làm việc”. Một phần là do cách tiếp cận này về mặt cấu trúc sẽ bắt buộc dẫn đến “phình to ngữ cảnh”, vì ngữ cảnh của các hợp đồng không liên quan sẽ cùng đổ dồn vào một hội thoại duy nhất!
Vì vậy, tôi không khuyến khích cách làm này.
Dưới đây là một cách tự động hóa agent hiệu quả hơn — mỗi hợp đồng mở một hội thoại mới. Mỗi khi bạn cần làm một việc gì đó, hãy tạo một hợp đồng.
Hãy xây dựng một lớp điều phối (orchestration layer) để tạo hợp đồng mới khi “có việc cần làm”, và mở một hội thoại mới để xử lý hợp đồng đó.
Điều này sẽ thay đổi hoàn toàn trải nghiệm sử dụng agent của bạn.
Lặp đi lặp lại, lặp đi lặp lại, lặp đi lặp lại
Bạn thuê một trợ lý hành chính — bạn có kỳ vọng người đó biết lịch trình của bạn ngay từ ngày đầu tiên không? Hay cách bạn uống cà phê? Hay bạn ăn tối lúc 6 giờ chiều chứ không phải 8 giờ tối? Rõ ràng là không. Bạn sẽ dần dần xây dựng các sở thích cá nhân theo thời gian.
Agent cũng vậy. Hãy bắt đầu từ cấu hình đơn giản nhất, gạt bỏ mọi cấu trúc phức tạp hay các harness, và hãy cho CLI cơ bản một cơ hội.
Sau đó, từng bước thêm vào các sở thích cá nhân của bạn. Làm thế nào?
Các quy tắc (Rules)
Nếu bạn không muốn agent làm một việc gì đó, hãy viết nó thành một quy tắc. Sau đó, thông báo cho agent quy tắc đó trong CLAUDE.md. Ví dụ: “Trước khi viết mã, hãy đọc `coding-rules.md`.” Các quy tắc có thể lồng ghép, và có thể mang tính điều kiện! Nếu bạn đang viết mã, hãy đọc `coding-rules.md`; nếu bạn đang viết kiểm thử, hãy đọc `coding-test-rules.md`; nếu kiểm thử đang thất bại, hãy đọc `coding-test-failing-rules.md`. Bạn có thể tạo bất kỳ nhánh logic nào để agent tuân theo — Claude (và Codex) sẽ rất sẵn sàng làm theo, miễn là trong CLAUDE.md có hướng dẫn rõ ràng.
Thực tế, đây là lời khuyên thực tế đầu tiên tôi đưa ra: hãy xem CLAUDE.md của bạn như một danh mục logic, được lồng ghép, chỉ rõ trong từng tình huống cụ thể và từng kết quả cụ thể thì nên tìm ngữ cảnh ở đâu. Nó nên được tối giản nhất có thể, chỉ chứa các logic IF-ELSE về “trong tình huống nào thì tìm ngữ cảnh ở đâu”.
Nếu bạn thấy agent đang làm một việc mà bạn không đồng ý, hãy thêm nó vào dạng một quy tắc, và thông báo cho agent rằng trước khi làm việc đó lần sau, hãy đọc quy tắc đó — và chắc chắn nó sẽ không lặp lại điều đó nữa.
Các kỹ năng (Skills)
Các kỹ năng (Skills) tương tự như quy tắc, nhưng thay vì phản ánh sở thích lập trình, chúng phù hợp hơn để nhúng các “thủ tục thực hiện” cụ thể. Nếu bạn có một cách cụ thể nào đó để thực hiện một việc, thì hãy nhúng cách đó vào một kỹ năng.
Thực tế, nhiều người thường phàn nàn rằng họ không biết agent sẽ giải quyết một vấn đề như thế nào — điều này khiến họ cảm thấy bất an. Nếu bạn muốn điều đó trở nên xác định, hãy yêu cầu agent trước tiên nghiên cứu cách giải quyết vấn đề đó, rồi viết giải pháp thành một file kỹ năng. Như vậy, bạn có thể xem trước cách agent xử lý vấn đề, và kịp thời điều chỉnh hoặc cải thiện trước khi nó thực sự gặp phải vấn đề đó.
Làm sao để bạn thông báo cho agent biết kỹ năng này tồn tại? Đúng vậy! Bạn viết trong CLAUDE.md rằng: “Khi gặp tình huống này và cần xử lý việc này, hãy đọc `SKILL.md`.”
Xử lý các quy tắc và kỹ năng
Bạn chắc chắn muốn liên tục thêm các quy tắc và kỹ năng cho agent. Đây chính là cách bạn tạo nên “cá tính” và “ghi nhớ sở thích” của nó. Gần như mọi thứ khác đều là dư thừa.
Khi bạn bắt đầu làm điều này, agent của bạn sẽ bắt đầu giống như một điều kỳ diệu. Nó sẽ “làm việc theo cách bạn muốn”. Và rồi bạn cuối cùng sẽ cảm thấy mình “đã ngộ ra” về kỹ thuật agent.
Sau đó…
Bạn sẽ thấy hiệu suất bắt đầu giảm sút trở lại.
Chuyện gì vậy?!
Rất đơn giản. Khi bạn thêm ngày càng nhiều quy tắc và kỹ năng, chúng bắt đầu mâu thuẫn với nhau, hoặc agent bắt đầu gặp phải hiện tượng “phình to ngữ cảnh” nghiêm trọng. Nếu bạn yêu cầu agent đọc 14 file markdown trước khi bắt đầu viết mã, thì nó cũng sẽ gặp phải vấn đề tương tự — bị ngập lụt bởi hàng đống thông tin vô dụng.
Vậy phải làm sao?
Hãy dọn dẹp. Hãy yêu cầu agent “đi spa”, tích hợp các quy tắc và kỹ năng, đồng thời loại bỏ mâu thuẫn bằng cách yêu cầu nó nêu rõ các sở thích cập nhật.
Sau đó, nó lại sẽ trở nên như một điều kỳ diệu.
Chỉ vậy thôi. Đây thực sự là bí quyết. Hãy giữ mọi thứ đơn giản, dùng quy tắc và kỹ năng, xem CLAUDE.md như một danh mục, và luôn tôn trọng nghiêm túc các giới hạn về ngữ cảnh và thiết kế của chúng.
Chịu trách nhiệm với kết quả
Hiện nay chưa có agent nào hoàn hảo. Bạn có thể giao rất nhiều công việc thiết kế và triển khai cho agent, nhưng bạn phải chịu trách nhiệm với kết quả cuối cùng.
Vì vậy, hãy cẩn trọng… rồi hãy tận hưởng trọn vẹn!
Chơi với những món đồ chơi của tương lai (đồng thời rõ ràng là dùng chúng để làm những việc nghiêm túc) thực sự là một niềm vui!
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News
@systematicls
