Nano Banana Pro: Tính Năng Mới, So Sánh Với Nano Banana và Test Thực Tế

1. Tính năng mới / nổi bật của Nano Banana Pro

Dựa theo blog Google, DeepMind và tài liệu Nano Banana Pro:

1.1 Model nền mạnh hơn

  • Nano Banana Pro dựa trên Gemini 3 Pro Image, cao cấp hơn Gemini 2.5 (Nano Banana thường).

  • Khả năng render hình ảnh, màu sắc, ánh sáng, texture, chi tiết nhân vật vượt trội.

1.2 Text trong ảnh rõ ràng

  • Render chữ tốt, hỗ trợ từ short text đến paragraphs.

  • Hỗ trợ đa ngôn ngữ, có thể dùng để localize hoặc dịch nội dung.

  • Nhiều lựa chọn font, style, texture, phù hợp làm poster, infographic hoặc mockup thiết kế.

1.3 Kiểm soát “studio-quality”

  • Camera angle: chỉnh góc máy chính xác.

  • Lighting: chuyển sáng / tối, ban ngày / đêm.

  • Depth of field: làm mờ nền, lấy nét chủ thể.

  • Color grading: chỉnh ánh sáng, tone màu, giúp ảnh nhìn chuyên nghiệp hơn.

1.4 Blend nhiều ảnh tham chiếu

  • Trộn tối đa 14 ảnh tham chiếu trong cùng một khung hình.

  • Giữ consistency đến 5 nhân vật / objects trong nhiều cảnh.

1.5 Grounding / kiến thức thực tế

  • Sử dụng Google Search để tạo cảnh, infographic, biểu đồ với dữ liệu chính xác.

  • Ảnh không chỉ đẹp mà còn chứa thông tin thực tế.

1.6 Độ phân giải cao

  • Tạo draft nhanh ở 2K, upscale đến 4K để in ấn hoặc sản xuất chất lượng cao.

1.7 Tạo mới + chỉnh sửa trong cùng một workflow

  • Hỗ trợ masked editing, chỉ chỉnh một phần ảnh mà vẫn giữ nguyên phần còn lại.

1.8 Tích hợp & minh bạch

  • Gắn SynthID watermark, metadata C2PA để kiểm tra nguồn ảnh.

  • Có mặt trên Google AI Studio, Gemini app, API doanh nghiệp, và tích hợp Google Ads.


2. So sánh Nano Banana Pro vs Nano Banana thường

Nano Banana Pro vs. Nano Banana 1 – What's New & How to Use It

3. Trải nghiệm thực tế với cùng một prompt

Mình thử test cùng một promptcùng ảnh tham chiếu trên cả hai phiên bản Nano Banana (Gemini 2.5) và Nano Banana Pro (Gemini 3 Pro).

Prompt: Giúp tôi tạo ra ảnh từ bất kỳ chương nào trong Doraemon, chọn một trong những cốt truyện, vẽ theo phong cách của võ sư Hồng Kông Huang Yulang và Ma Rong-sheng, với đối thoại nhân vật, phông chữ là tiếng việt

Đây là kết quả của Nano Banana Pro

Đây là kết quả của Nano Banana thường:

Kết quả:

  • Bức ảnh khá tốt, nhưng với text là tiếng việt thì đang lỗi.
  • Text bị đặt sai vị trí & sai ngữ cảnh
  • Text bị “không tự nhiên”, giống dịch máy
  • Font chữ không đồng nhất

Tuy nhiên nếu chọn tôi sẽ chọn hỉnh ảnh của Nano Banana Pro vì ảnh có nghĩa hơn và đúng hơn so với Nano Banana.

Tôi sẽ thử mởi một prompt tiếng anh khác:

Create a highly artistic, cinematic digital illustration featuring a Vietnamese girl as the central subject. She stands beside a serene lakeside, wearing a traditional Vietnamese áo dài. Her presence conveys emotional depth, with delicate facial expressions and finely rendered details.
Surround her with drifting peach blossoms gently carried by the wind. Use soft, diffused lighting combined with dramatic contrast to highlight her silhouette and the flowing fabric. Incorporate subtle atmospheric effects such as floating particles, light fog over the water, gentle reflections, and soft backlighting to enhance depth and mood.
The overall style should resemble high-end concept art: ultra-detailed, realistic textures, painterly yet refined, with modern digital painting techniques and 8K-quality rendering.

No text, no subtitles, no labels, and no watermark.

Đây là hình ảnh của Nano Banana Pro

Woa, hình ảnh đẹp hơn rồi

Còn đây là hình ảnh với Nano Banana:

Theo bản thân tôi nhận thấy thì Nano Banana đẹp hơn Nano Banana Pro :)))

Tôi đã đọc và xem một số video trên youtube và tổng kết được một số case sử dụng gồm:

1. Tạo hình ảnh từ mô tả

Ví dụ: yêu cầu AI tạo hình ảnh vệ tinh của TP.Hà Nội.

Chọn chế độ “tư duy” để AI hiểu ngữ cảnh hơn.

Kết quả sắc nét; có thể dùng Google AI Mode để kiểm tra lại ảnh.

2. Face Swap (đổi mặt)

Ghép mặt của mình vào ảnh người khác (ví dụ idol Sơn Tùng).

Nano 2 xử lý tự nhiên, màu da hài hòa.

Có thể đổi tỷ lệ khung hình (không bị giới hạn như Nano 1).

Có thể thêm đạo cụ vào tay nhân vật (ví dụ bình nước bạn bán).

3. Dịch & tô màu truyện tranh

Upload trang manga → AI dịch sang tiếng Việt và tự động tô màu chuẩn.

Giữ nguyên bố cục, chữ trong tranh.

4. Tạo truyện tranh từ câu chuyện

Gemini 3 viết cốt truyện (theo phong cách One Piece).

Nano 2 vẽ từng trang truyện dựa trên cốt truyện và hình nhân vật upload.

Chỉ cần chia nội dung thành đoạn ngắn để tranh chính xác hơn.

5. Tạo poster truyền động lực theo phong cách Pinterest

Upload poster mẫu → yêu cầu tạo phiên bản mới với nội dung mình muốn.

Có thể thêm chữ lên ảnh của mình (ví dụ “Never Give Up”).

6. Tạo Flashcard học tiếng Anh cho trẻ

Yêu cầu AI vẽ flashcard minh họa cho danh sách từ vựng.

Có thể dùng để dạy con, làm hình minh họa cho slide, tranh tô màu…

7. Tạo Infographic trong học tập

Lấy thông tin chính xác từ Google AI Mode.

Mang nội dung vào Nano 2 để vẽ infographic, ví dụ: vòng đời của con ếch.

Chữ và bố cục rất rõ ràng, giống tài liệu giáo khoa.

8. Tạo mascot / thiết kế để kinh doanh (MMO)

Tạo mascot 3D, nhân vật chibi… rồi in lên: áo, cốc, bình giữ nhiệt, phụ kiện

Có thể nhờ mẫu ảo “mặc thử” sản phẩm để bán hàng (affiliate hoặc shop online).

 

Khám Phá Google Anti-gravity

Google Anti-gravity không chỉ là một công cụ; đó là một triết lý mới về kỹ thuật phần mềm. Trong kỷ nguyên của các agent lập trình, Google đã mạnh dạn định nghĩa lại quy trình phát triển bằng cách tung ra một Hệ thống Lập trình Agentic đầy đủ chức năng và đáng kinh ngạc, chạy hoàn toàn cục bộ (locally) trên máy tính của bạn.

Nếu bạn đang tìm kiếm một “lập trình viên cấp dưới” thông minh, đa nhiệm và luôn sẵn sàng làm việc, Anti-gravity chính là thứ bạn cần.

Dưới đây là những tính năng cốt lõi làm nên sức mạnh và sự khác biệt của Google Anti-gravity:

Google Antigravity và cách sử dụng

I.  Môi Trường Phát Triển & Khả Năng Cơ Bản

1. IDE Đầy Đủ Chức Năng Chạy Cục Bộ (Local, Full-fledged IDE)

Khác biệt lớn nhất so với các agent tiền nhiệm như Gemini CLA (CLI) hay Jules (Cloud), Anti-gravity là IDE lập trình đầy đủ chức năng đầu tiên của Google chạy trực tiếp trên máy của bạn. Giao diện quen thuộc (dựa trên VS Code) giúp bạn chuyển đổi mượt mà và tập trung vào công việc.

2. Hệ Thống Lập Trình Đa Agent & Đa Nhiệm

Đây là trụ cột sức mạnh của Anti-gravity.

  • Chạy Song Song: Cho phép bạn quản lý và chạy nhiều dự án hoặc nhiều tác vụ của các agent khác nhau cùng một lúc mà không bị gián đoạn.

  • Hộp Thư Đến Agent (Inbox): Cung cấp một trung tâm thông báo tập trung, nơi bạn nhận được cập nhật theo thời gian thực về tiến độ và trạng thái của tất cả các tác vụ đang được thực thi.

II. Lên Kế Hoạch Thông Minh & Tương Tác Có Kiểm Soát

3. Quy Trình Lập Kế Hoạch (Planning) Chi Tiết

Agent không thực thi ngay lập tức. Nó học hỏi từ quy trình phát triển phần mềm thực tế bằng cách:

  • Phân tích Yêu Cầu: Chia nhỏ tác vụ phức tạp thành danh sách các bước thực thi (Ví dụ: Nghiên cứu -> Triển khai -> Xác minh).

  • Chế Độ Planning: Lý tưởng cho các dự án mới, nghiên cứu sâu và các tác vụ phức tạp, cho phép agent lập kế hoạch kỹ lưỡng trước khi bắt đầu viết code.

4. Kiểm Soát Hoàn Toàn Qua Chế Độ Review

Bạn luôn giữ vai trò là Kiến trúc sư phần mềm.

  • Review Kế Hoạch: Bạn có thể xem xét chi tiết kế hoạch của agent trước khi thực thi.

  • Thêm Nhận Xét & Điều Chỉnh: Dễ dàng thêm nhận xét, yêu cầu thay đổi (ví dụ: “chỉ tạo 2 hình ảnh thay vì 4”) và agent sẽ tự động cập nhật kế hoạch dựa trên phản hồi của bạn.

III. Khả Năng Tự Sửa Lỗi & Tự Kiểm Tra Độc Đáo

5. Trình Duyệt Tích Hợp (Built-in Browser)

Đây là tính năng đột phá nhất. Anti-gravity nhúng một trình duyệt web, cho phép agent:

  • Tương Tác Website: Tự động nhấp, cuộn, gõ, và điều hướng các trang web.

  • Tự Kiểm Tra: Agent có thể mở ứng dụng vừa code, tự nhập liệu (ví dụ: khóa API), và chạy thử nghiệm hoàn toàn tự động để tìm và sửa lỗi. Điều này loại bỏ nhu cầu về các máy chủ bên ngoài hay công cụ kiểm thử phức tạp.

6. Video Phát Lại Hành Động (Action Playback)

  • Trong quá trình kiểm tra và sửa lỗi tự động, Anti-gravity ghi lại một video nhỏ (playback) về các hành động mà agent đã thực hiện (những cú nhấp chuột, cuộn, gõ phím).

  • Tính năng này cực kỳ hữu ích cho việc xem xét lại công việc của agent sau khi chạy tác vụ trong thời gian dài (ví dụ: qua đêm).

IV.  Học Tập Liên Tục & Tính Mở

7. Tính Năng Kiến Thức (Knowledge)

Anti-gravity không chỉ code; nó học hỏi. Nó xây dựng một cơ sở kiến thức theo thời gian, ghi lại:

  • Các vấn đề đã gặp phải.

  • Cách thức đã khắc phục các vấn đề đó. Điều này giúp agent ngày càng thông minh và hiệu quả hơn trong các dự án tương lai.

8. Hỗ Trợ Mô Hình Ngoài (Open Model Support)

Dù được xây dựng bởi Google và tối ưu với Gemini, đội ngũ Anti-gravity cam kết mở rộng hỗ trợ cho các mô hình từ nhà cung cấp khác (ví dụ: Claude, OpenAI). Đây là một bước đi đột phá cho thấy Google đang ưu tiên tính hiệu quả và sự lựa chọn cho nhà phát triển.

V. Điều gì làm IDE này tốt hơn các IDE khác?

Có 3 thứ:

  1. Agent Manager (Trình quản lý tác nhân).

  2. Evidential: Sau khi thực thi câu lệnh, IDE sẽ cung cấp cho dev các bằng chứng, chứng minh ứng dụng đã hoạt động bằng cách chụp ảnh màn hình, video, các test case đã thực hiện cho dev mà các công cụ khác không có.
  3. Inbuilt Browser (Trình duyệt tích hợp). Nếu bạn muốn test giao diện (UI), bạn có thể yêu cầu trình duyệt tự làm. Bạn cần thêm extension (tiện ích mở rộng) để làm việc này.

Trong Agent Manager, bạn có thể làm việc với nhiều dự án cùng lúc, tạo nhiều agent cho các dự án khác nhau và chuyển đổi qua lại. Bạn có thể thay đổi Model AI. Ở đây có Gemini 3 Pro (bản gốc ghi nhầm là “Germany”) là một model rất tốt. Bạn cũng có thể thử các model khác như GPT (bản gốc ghi “GPD”).

 

VI. Thử nghiệm

OK. nói nhiều rồi, bây giờ sẽ đến lúc chúng ta thử nhiệm với Anti-gravity.

Antigravity vs Cursor: Which AI Coding Tool Is Better? - Skywork ai

Tôi sẽ thử nghiệm trực tiếp nó bằng 2 cách.

1.   Thử nghiệm Anti-gravity với dự án công ty
(Lưu ý: Vì là dự án nội bộ nên tôi không thể quay video hoặc chụp màn hình.)

Cấu hình máy: Apple M4, Python 3.11
Bối cảnh dự án:

  • Dự án có một phần hoạt động giống VSCode.

  • Có một mô-đun xử lý Git, sử dụng GitPython để push các file thay đổi từ local lên GitHub.

  • Đang gặp một lỗi: khi người dùng chỉnh sửa file và chọn “Git push”, hệ thống báo lỗi conflict.

Tôi dùng cùng một prompt, mode: plan, model: Claude Sonnet 4.5 để so sánh.

Kết quả thử nghiệm

AntiGravity

  • Không sửa được lỗi conflict.

  • Tự ý chỉnh sửa thêm nhiều file không liên quan → phát sinh bug mới.

Cursor

  • Sửa được lỗi conflict.

  • Không tự động thay đổi những file không liên quan, tránh làm phát sinh lỗi mới.

2. Tự tạo một ứng dụng mới  theo yêu cầu đã được viết ở link sau:

Link: https://docs.google.com/document/d/1ZfW0Fdm3l-x4gKbf9e2q54o5OrMXrd-NS4QWyZZPLoA/edit?usp=sharing

Kết quả:

 

Kết luận bài test:

  • Tạo code tốt, ở mức ổn
  • Source code ổn
  • Lỗi: “Agent terminated due to error” (Tác nhân bị ngắt do lỗi). Tôi nhận được khá nhiều lỗi,
  • Frontend: Như shit vậy,
  • Giới hạn Quota: Rất dễ đạt giới hạn khi sử dụng mô hình Gemini 3 Pro

So sánh Anti-Gravity và Cursor

Tiêu chí Anti-Gravity Cursor
Tính ổn định Kém (Thường xuyên lỗi Tác nhân) Tốt (Sản phẩm trưởng thành, ít lỗi)
Trải nghiệm sử dụng Phức tạp, mang tính quản lý. Dễ dùng, tích hợp AI mượt mà trong IDE truyền thống.
Tầm nhìn Thay đổi mô hình lập trình (Agent Manager). Nâng cao hiệu suất lập trình (AI Assistant).
Khuyến nghị hiện tại Chỉ nên thử nghiệm, không dùng cho công việc. Lựa chọn hàng đầu cho lập trình AI chuyên nghiệp.

Ý kiến cá nhân:

  • Cursor vẫn là lựa chọn tốt hơn và đáng tin cậy hơn cho bất kỳ ai muốn sử dụng AI để xây dựng ứng dụng. Anti-Gravity, mặc dù có tầm nhìn tiên phong, vẫn chỉ là một sản phẩm thử nghiệm còn nhiều lỗi và cần thời gian để phát triển
  • Anh/Em Dev vẫn nên sử dụng Claude Sonnet hơn là sử dụng Gemini 3 Pro
  • Khi dùng cursor nếu hết token có thẻ qua sử dụng Antigravity để fix bug các bug nhỏ, cần review cẩn thận, vì có thể Antigravity sẽ thay đổi code ở nhưng files không mong muốn, prompt phải chuẩn chỉ.

 

Figma Make: Những Hạn Chế Cần Biết

Sau khi tự khám phá, Figma Make vừa khiến tôi ấn tượng, vừa khiến tôi không muốn sử dụng nó.
Lời hứa về tự động hóa thiết kế bằng AI là có thật, nhưng những giới hạn của nó cũng rõ ràng. Dưới đây là những điều tôi rút ra sau tháng đầu tiên trải nghiệm Figma Make: điểm mạnh, điểm yếu, và lý do tại sao workflow của bạn có thể cần điều chỉnh.

1. Sử dụng chung: khi AI chưa thực sự hiểu thiết kế

Điểm mạnh:
Tính năng nổi bật của Figma Make giống như khoa học viễn tưởng trở thành hiện thực: tạo prototyping hoạt động chỉ với một prompt đơn giản hoặc bằng cách import một frame có sẵn. Muốn một microinteraction hay một chuyển tiếp đơn giản giữa các trạng thái? Chỉ cần mô tả, Make sẽ tạo ra thứ gì đó có thể dùng được. Đây là công cụ nhanh nhất mà tôi từng tìm thấy để tạo một prototype tương tác nhanh, đặc biệt hữu ích cho các ý tưởng giai đoạn đầu hoặc pitch deck.

Điểm yếu (hiện tại):
Nếu bạn mong Figma Make tái hiện những flow tinh tế của sản phẩm đã sẵn sàng sản xuất, bạn sẽ gặp rào cản nhanh chóng.

Các tương tác phức tạp nhiều bước, điều hướng lồng nhau hay bất cứ thứ gì đòi hỏi logic mạnh mẽ đều nằm ngoài khả năng. Nó giống “wireframe cơ bản có thêm chút gia vị” hơn là “prototype đạt chuẩn sản xuất”.

Giới hạn thiết kế cũng hiện hữu. Nếu bạn làm việc với màn hình lớn hoặc cần breakpoint tùy chỉnh, bạn sẽ phải liên tục di chuyển quanh canvas, hoặc tệ hơn, phải dựng lại thiết kế để vừa với viewport của Make.

2. Import hệ thống thiết kế: Có điểm tốt, có điểm chưa tốt

Hầu như hoạt động:
Import từ thư viện design system cơ bản nhất. Nó có thể chuyển màu, khoảng cách và style cơ bản, nhưng không hỗ trợ font tùy chỉnh — điều này là vấn đề lớn nếu muốn tạo prototype độ trung thực cao. Và đừng mong dùng Glass UI, cũng không được hỗ trợ.

Điểm thiếu sót:
Make cho phép dán từng component riêng lẻ cho prototype, nhưng không import được component tùy chỉnh từ thư viện của bạn. Thay vào đó, nó dùng thư viện component bên thứ ba (đáng chú ý là shadcn/ui) rồi áp style của bạn lên, giống như phủ icing lên bánh.

3. Prototyping nâng cao: Tuyệt với sự đơn giản, không với quy mô lớn

Nơi Make tỏa sáng:
Microinteraction khả thi nếu bạn biết cách prompt đúng và giữ mọi thứ đơn giản. Make rất giỏi tạo hover effect và transition accordion mà các designer chúng ta yêu thích.

Nơi Make gặp trục trặc:
– Chuyển tiếp phức tạp, flow lồng nhau hay layout hơi phức tạp thường dễ bị lỗi. Dán một frame chi tiết từ file chính và xem layout tan rã, đặc biệt khi độ phức tạp tăng.
– Chưa hỗ trợ tốt cho autolayout (Mobile view)
– Figma Make sử dụng Claude AI hoặc một LLM tương tự, được huấn luyện trên code. Nó không được huấn luyện trên engine chỉnh sửa của Figma mà bạn dùng để thiết kế, nên đối với nó đó như một ngôn ngữ hoàn toàn xa lạ.
Họ không thể vượt qua vấn đề này nếu không:
+ Viết lại hoàn toàn Figma kèm với nâng cấp hiệu năng web mang tính cách mạng.
+ Huấn luyện một LLM mới trên các prototype của Figma, nhưng hầu như không có dữ liệu sẵn có trên Internet để làm việc này.
Ngay cả nếu hai cách trên khả thi, engine prototyping của Figma rất hạn chế, không giống như code. Nó sẽ không thể “tạo ra mọi thứ”, mà sẽ rất cồng kềnh và khó dùng.

4. Prompt và tham chiếu hình ảnh: Là một cuộc trò chuyện

Mẹo prompt:
Figma Make nhận hai loại input chính:

Directional prompt — Càng có cấu trúc càng tốt. Chia hướng dẫn thành các phần như: context, platform, visual style, và UI components.

Visual reference — Import một component cụ thể hoặc dán frame để Make có khởi đầu. Tránh chọn nhiều frame hoặc section cùng lúc, có thể gây lỗi hoặc bị kẹt trong upload.

Muốn tham chiếu website trong prompt? Hiện tại phải chờ. Figma chưa thể duyệt web để lấy tham chiếu, ý tưởng hay pattern thiết kế.

5. Bức tranh tổng thể: Figma Make có ý nghĩa gì với designer

Figma Make là cách nhanh nhất để biến một ý tưởng thô thành hiện thực, nhưng chưa thể thay thế Figma truyền thống. Hãy coi nó như một công cụ rapid ideation, cầu nối giữa bản phác thảo trên khăn giấy và wireframe độ trung thực cao.

Nếu workflow của bạn phụ thuộc vào thư viện component sâu, breakpoint pixel-perfect hay hiệu ứng trực quan tinh tế, bạn sẽ cảm thấy bực bội. Nhưng với những khám phá giai đoạn đầu hoặc ý tưởng tương tác nhanh, Figma Make đã đi trước nhiều công cụ khác.

Tóm tắt:

Tốc độ và khả năng tiếp cận: Không đối thủ cho prototype đơn giản và ý tưởng giai đoạn đầu.

Hỗ trợ hệ thống thiết kế: Ổn với style và token, nhưng không với component tùy chỉnh.

Sức mạnh prototyping: Tốt cho flow cơ bản, không đáng tin với flow nâng cao.

Prompting: Prompt có cấu trúc và tham chiếu rõ ràng là hiệu quả nhất.
Idea: Figma sẽ lấy các mẫu có sẵn được tạo bởi các nhà thiết kế chứ không thực sự sáng tạo, nó thực sự là điểm yếu lớn khi sử dụng.

6. Thực hành Figma maker.
Tôi đã tạo một ứng dụng nhỏ tên là: Funny Sticker Generator App

1. Mục tiêu: Ứng dụng cho phép người dùng tạo các sticker vui nhộn theo mô tả text. Người dùng nhập mô tả, chọn số lượng sticker muốn tạo, app sẽ tạo sticker và hiển thị để tải về hoặc mua nâng cấp.

2. Chức năng chính:

– Nhập mô tả và số lượng sticker: Người dùng gõ mô tả sticker (ví dụ: “con mèo mặt buồn uống trà sữa”).
– Chọn số lượng sticker muốn tạo (1–10).
– Button “Generate”
Mô tả:
Khi nhấn, app gửi yêu cầu đến API Gemini để tạo sticker.
Hiển thị trạng thái đang tạo sticker (loading).
Hiển thị danh sách sticker
Sticker hiển thị dạng lưới (grid).
Người dùng có thể nhấn xem full-size.

– Tải về sticker: Tải từng sticker hoặc tải tất cả.

Mobile: lưu trực tiếp vào thư viện ảnh.

Thanh toán In-App Purchase

Mua gói premium để tạo nhiều sticker hơn, tốc độ nhanh hơn hoặc chất lượng cao hơn.
và tôi đã public nó, bạn có. hể xem theo link sau: https://bagel-math-58475315.figma.site/
Một số hình ảnh của ứng dụng:

Đây là video demo ứng dụng:

Screen Recording 2025-11-15 at 11.59.00

Kết luận:
Figma Make giống như một intern AI mà designer luôn muốn: nhanh, nhiệt tình và tuyệt vời cho mockup, nhưng chưa đủ khả năng “làm chủ”. Hãy tận dụng điểm mạnh, chú ý giới hạn, và bạn sẽ thấy đây là một công cụ hữu ích (dù chưa hoàn hảo) trong bộ toolkit của mình.

Ý kiến cá nhân:
1. Tôi thấy sử dụng nó không hiệu quả, chỉ phù hợp cho các dụng dụng nhỏ và gặp rất nhiều lỗi.
2. Tương tự với cá AI khác, bạn phải ghi đầy đủ và thật chi tiết trong prompt của mình để Figma tạo UI tốt hơn.
3. Néu muốn sử dụng để tạo ra các file code, tôi sẽ chọn claude code, cursor hơn là sử dụng Figma Make
4. Tôi muốn chuyển từ Figma Design sang Make, chứ không phải ngược lại

Context Engineering: Chìa khóa xây dựng AI Agent hiệu quả

Context Engineering là chiến lược quản lý toàn bộ thông tin (context) cho AI Agent, khác với Prompt Engineering. Tìm hiểu 3 kỹ thuật cốt lõi giúp Agent thông minh hơn và duy trì sự tập trung dài hạn.

Trong những năm đầu của kỷ nguyên AI tạo sinh, Prompt Engineering từng là kỹ năng được săn đón, giúp chúng ta tìm ra những từ ngữ và cấu trúc tốt nhất để khai thác sức mạnh của mô hình ngôn ngữ lớn (LLM). Tuy nhiên, khi chúng ta chuyển từ các tác vụ một lần (one-shot task) sang xây dựng các AI Agent (Tác nhân AI) có khả năng hoạt động tự chủ, thực hiện nhiều bước và ghi nhớ thông tin trong thời gian dài, một khái niệm mới đã nổi lên và trở nên quan trọng hơn: Context Engineering (Kỹ thuật Ngữ cảnh).
Bài viết này sẽ làm rõ Context Engineering là gì, nó khác biệt như thế nào so với Prompt Engineering và những chiến lược cốt lõi mà các kỹ sư AI tại Anthropic đang áp dụng để xây dựng các Agent thông minh và đáng tin cậy.

1. Context Engineering là gì?

Context (Ngữ cảnh) đề cập đến toàn bộ tập hợp các tokens được đưa vào khi lấy mẫu (sampling) từ một LLM. Nó là nguồn tài nguyên quan trọng, nhưng có giới hạn, cung cấp cho mô hình mọi thứ nó cần để đưa ra quyết định hoặc tạo ra đầu ra mong muốn.

Context Engineering (CE) là tập hợp các chiến lược nhằm quản lý và tối ưu hóa tiện ích của các tokens đó, chống lại các giới hạn cố hữu của LLM (như cửa sổ ngữ cảnh giới hạn), nhằm mục đích:

Tìm ra cấu hình ngữ cảnh nào có khả năng tạo ra hành vi mong muốn của mô hình nhất. Nói cách khác, CE không chỉ là về việc bạn viết gì trong prompt, mà là về việc bạn sắp xếp và duy trì toàn bộ trạng thái thông tin có sẵn cho LLM tại bất kỳ thời điểm nào.

2. Khác biệt cốt lõi giữa Context Engineering và Prompt Engineering

Anthropic xem Context Engineering là sự tiến hóa tự nhiên của Prompt Engineering.

| Tiêu chí | Prompt Engineering | Context Engineering |
| ————- | ——————————– | —————————————- |
| **Trọng tâm** | Viết hướng dẫn (prompt) hiệu quả | Quản lý toàn bộ ngữ cảnh của mô hình |
| **Phạm vi** | Một tác vụ đơn lẻ | Nhiều vòng tương tác, trạng thái dài hạn |
| **Cách làm** | Tối ưu từng câu | Tối ưu toàn bộ luồng thông tin |
| **Khi dùng** | Một câu hỏi – một câu trả lời | Agent tự hoạt động, tự học, tự nhớ |

Prompt Engineering đề cập đến các phương pháp viết và tổ chức hướng dẫn cho mô hình ngôn ngữ lớn (LLM) nhằm đạt được kết quả tối ưu (bạn có thể tham khảo thêm trong tài liệu hướng dẫn của chúng tôi về các chiến lược Prompt Engineering hiệu quả).

Trong khi đó, Context Engineering là tập hợp các chiến lược nhằm lựa chọn và duy trì tập hợp token (thông tin) tối ưu trong quá trình suy luận (inference) của LLM — bao gồm toàn bộ thông tin khác có thể được đưa vào ngữ cảnh, không chỉ riêng phần prompt.

Trong giai đoạn đầu của việc phát triển ứng dụng với LLM, prompting chiếm phần lớn công việc của kỹ sư AI, vì phần lớn các trường hợp sử dụng (ngoài trò chuyện thông thường) yêu cầu prompt được tối ưu cho các tác vụ một lần như phân loại hoặc sinh văn bản.

Đúng như tên gọi, trọng tâm chính của Prompt Engineering là cách viết prompt hiệu quả, đặc biệt là system prompt (hướng dẫn hệ thống).
Tuy nhiên, khi chúng ta tiến tới việc xây dựng các tác nhân AI (AI Agents) có khả năng mạnh mẽ hơn — hoạt động qua nhiều vòng suy luận (multi-turn inference) và thời gian dài hơn (long-horizon tasks) — chúng ta cần có các chiến lược để quản lý toàn bộ trạng thái ngữ cảnh, bao gồm:
– System instructions (hướng dẫn hệ thống)
– Tools (công cụ mà agent có thể gọi)
– Model Context Protocol (MCP)
– Dữ liệu bên ngoài
– Lịch sử tin nhắn

Một Agent hoạt động theo vòng lặp sẽ liên tục tạo ra ngày càng nhiều dữ liệu có thể liên quan đến các vòng suy luận tiếp theo. Những thông tin này phải được tinh lọc một cách tuần hoàn để giữ lại các phần quan trọng nhất.
Context Engineering chính là nghệ thuật và khoa học của việc chọn lọc những gì sẽ được đưa vào cửa sổ ngữ cảnh giới hạn từ “vũ trụ thông tin” liên tục mở rộng đó.

3. Các yếu tố cốt lõi cần chú ý khi phát triển AI Agent
Nguyên tắc vàng của Context Engineering là: Tìm tập hợp tokens có tín hiệu cao (high-signal tokens) nhỏ nhất để tối đa hóa xác suất đạt được kết quả mong muốn.

3.1. Coi Context là Tài nguyên Hữu hạn
Các nghiên cứu cho thấy, giống như con người có giới hạn bộ nhớ làm việc (working memory), LLM cũng có một “ngân sách chú ý” (Attention Budget) và gặp hiện tượng Context Rot (khả năng nhớ lại thông tin giảm khi số lượng tokens tăng lên).

Do đó, các kỹ sư cần:
– Tối giản hóa: Chỉ đưa vào thông tin thực sự cần thiết.
– Tinh gọn Tools: Thiết kế các công cụ (Tools) không bị chồng chéo chức năng, rõ ràng và tạo thành một bộ tối thiểu để tránh gây mơ hồ cho Agent khi ra quyết định.
Sử dụng ví dụ (Few-shot) chọn lọc: Thay vì nhồi nhét một danh sách dài các trường hợp biên, hãy chọn lọc các ví dụ điển hình, đa dạng (canonical examples) để minh họa hành vi mong đợi.

3.2. Tối ưu Hướng dẫn Hệ thống (System Prompts)
Prompt ban đầu là một phần không thể thiếu của ngữ cảnh. Nó cần đạt đến “độ cao phù hợp” (Right Altitude) – trạng thái cân bằng hoàn hảo:
– Tránh quá cứng nhắc: Không nên mã hóa logic phức tạp, dễ gãy (brittle, hardcoded logic) vào prompt.
– Tránh quá mơ hồ: Không cung cấp hướng dẫn quá chung chung, thiếu tín hiệu cụ thể.
– Tối ưu: Sử dụng ngôn ngữ đơn giản, trực tiếp. Tổ chức prompt thành các phần riêng biệt (, ) bằng thẻ XML hoặc Markdown để mô hình dễ dàng phân tách thông tin.

3.3. Chiến lược quản lý Ngữ cảnh cho Tác vụ dài hạn (Long-Horizon Tasks)
Đối với các Agent cần hoạt động liên tục trong thời gian dài (như di chuyển codebase lớn, nghiên cứu chuyên sâu), vượt quá giới hạn của cửa sổ ngữ cảnh, Context Engineering cung cấp ba kỹ thuật chính:

Vì sao Context Engineering lại quan trọng trong việc xây dựng AI Agent mạnh mẽ

Mặc dù các mô hình ngôn ngữ lớn (LLM) có tốc độ xử lý cao và khả năng quản lý khối lượng dữ liệu ngày càng lớn, nhưng chúng – giống như con người – vẫn có giới hạn về khả năng tập trung và dễ bị “rối loạn thông tin” khi ngữ cảnh trở nên quá lớn. Các nghiên cứu dạng “needle-in-a-haystack” (tìm kim trong đống rơm) đã phát hiện ra một hiện tượng gọi là context rot — tức là khi số lượng token trong cửa sổ ngữ cảnh tăng lên, khả năng của mô hình trong việc ghi nhớ và truy xuất chính xác thông tin từ ngữ cảnh đó lại giảm xuống.

1. Context là tài nguyên có giới hạn

Dù một số mô hình có thể suy giảm chậm hơn, nhưng hiện tượng này xảy ra ở tất cả các LLM. Vì vậy, ngữ cảnh phải được xem như một tài nguyên hữu hạn, có lợi ích giảm dần theo từng token thêm vào.Giống như con người chỉ có một dung lượng bộ nhớ làm việc (working memory) nhất định, LLM cũng có “ngân sách chú ý” (attention budget) mà nó sử dụng khi xử lý khối lượng lớn ngữ cảnh. Mỗi token mới được thêm vào đều “tiêu tốn” một phần ngân sách đó, khiến việc chọn lọc thông tin đưa vào mô hình trở nên vô cùng quan trọng.

2. Giới hạn bắt nguồn từ kiến trúc Transformer

Nguồn gốc của sự khan hiếm “chú ý” này nằm ở kiến trúc Transformer – nền tảng của các LLM hiện nay. Trong kiến trúc này, mỗi token có thể “chú ý” đến mọi token khác trong toàn bộ ngữ cảnh, tạo ra n² mối quan hệ cặp đôi cho n token. Khi độ dài ngữ cảnh tăng lên: Khả năng của mô hình trong việc duy trì các mối quan hệ này bị kéo căng, dẫn đến sự đánh đổi tự nhiên giữa kích thước ngữ cảnh và độ tập trung của sự chú ý. Ngoài ra, LLM được huấn luyện chủ yếu trên các chuỗi ngắn, vì vậy chúng có ít kinh nghiệm và ít tham số chuyên biệt hơn cho các mối quan hệ phụ thuộc dài hạn trên toàn ngữ cảnh.

3. Giải pháp kỹ thuật giúp mở rộng ngữ cảnh (nhưng không hoàn hảo)

Một số kỹ thuật như position encoding interpolation (nội suy mã hóa vị trí) giúp mô hình xử lý chuỗi dài hơn bằng cách thích ứng chúng với phạm vi ngữ cảnh ngắn hơn mà mô hình đã được huấn luyện. Tuy nhiên, điều này có thể làm giảm độ chính xác trong việc hiểu vị trí token, khiến hiệu năng giảm dần chứ không sụp đổ hoàn toàn.

Kết quả là: Mô hình vẫn hoạt động tốt với ngữ cảnh dài, nhưng có thể mất độ chính xác trong việc truy xuất thông tin hoặc suy luận dài hạn, so với khi làm việc với ngữ cảnh ngắn hơn.

Giải phẫu của một ngữ cảnh hiệu quả

Vì các mô hình ngôn ngữ lớn (LLM) bị giới hạn bởi “ngân sách chú ý” (attention budget) hữu hạn, kỹ thuật xây dựng ngữ cảnh hiệu quả là tìm ra tập hợp nhỏ nhất của các token có giá trị cao (high-signal tokens) — tức là những phần thông tin cô đọng, quan trọng — sao cho tối đa hóa khả năng đạt được kết quả mong muốn.
Tuy nhiên, việc áp dụng nguyên tắc này trong thực tế không hề đơn giản. Dưới đây là những hướng dẫn cụ thể về cách áp dụng nó cho các thành phần khác nhau trong ngữ cảnh:

1. System prompt — phải cực kỳ rõ ràng và đúng “độ cao”

Phần system prompt nên được viết bằng ngôn ngữ đơn giản, trực tiếp, truyền đạt ý tưởng ở đúng “độ cao” (altitude) phù hợp cho tác nhân (agent).
“Độ cao phù hợp” ở đây chính là vùng Goldilocks — không quá cụ thể, cũng không quá mơ hồ. Hai sai lầm phổ biến khi viết system prompt là:

Quá chi tiết:
Một số kỹ sư cố gắng mã hóa những logic phức tạp vào trong prompt để điều khiển hành vi của agent một cách chính xác tuyệt đối. Cách làm này dễ gãy và khó bảo trì, vì chỉ cần thay đổi nhỏ cũng khiến toàn bộ hệ thống phản ứng sai.

Quá chung chung:
Ngược lại, có những prompt chỉ cung cấp hướng dẫn mơ hồ, không đưa ra tín hiệu cụ thể cho mô hình về loại kết quả mong đợi. Trong trường hợp này, mô hình giả định sai ngữ cảnh chia sẻ và dễ sinh ra phản hồi lệch hướng.

***** Giải pháp tối ưu ******
Tạo prompt ở “độ cao vừa phải” — đủ cụ thể để hướng dẫn hành vi rõ ràng, nhưng đủ linh hoạt để mô hình có thể suy luận và thích ứng.
Nói cách khác, hãy đưa ra heuristics mạnh (nguyên tắc định hướng) thay vì “kịch bản cứng nhắc”.

2. Cấu trúc prompt rõ ràng, gọn gàng

Chúng tôi khuyến khích tổ chức prompt thành các phần riêng biệt, ví dụ như:

## Tool guidance
## Output description

Bạn có thể dùng XML tag hoặc tiêu đề Markdown để phân tách rõ ràng từng phần.Tuy nhiên, khi các mô hình ngày càng thông minh hơn, cách định dạng có thể sẽ dần ít quan trọng hơn — trọng tâm vẫn là nội dung và tính rõ ràng giữ lượng thông tin ở mức “tối thiểu đầy đủ”

Bất kể bạn chọn cấu trúc như thế nào, mục tiêu chính là:
“Cung cấp lượng thông tin nhỏ nhất nhưng vẫn đủ để mô hình hiểu và thực hiện đúng hành vi mong muốn.”
“Tối thiểu” không có nghĩa là ngắn gọn đến mức thiếu thông tin. Agent vẫn cần được cung cấp đầy đủ dữ kiện ban đầu để hành xử đúng.

Cách làm tốt nhất:

Bắt đầu bằng một prompt tối giản, thử nghiệm nó với mô hình tốt nhất hiện có, sau đó bổ sung hướng dẫn hoặc ví dụ cụ thể dựa trên những lỗi phát sinh trong giai đoạn thử nghiệm đầu tiên.
Thiết kế công cụ (Tools) cho Agent các công cụ cho phép agent tương tác với môi trường và lấy thêm ngữ cảnh mới trong quá trình làm việc.

Vì công cụ là “hợp đồng” giữa agent và thế giới bên ngoài, nên việc thiết kế chúng cần ưu tiên hiệu quả, cụ thể:
Trả về thông tin một cách tiết kiệm token, hướng dẫn hành vi của agent sao cho hiệu quả và hợp lý.
Trong bài “Writing tools for AI agents – with AI agents”, Anthropic khuyến nghị rằng:
– Công cụ nên dễ hiểu đối với mô hình,
– Có ít chồng chéo chức năng,
– Giống như các hàm trong codebase tốt — tự chứa, rõ ràng, chịu lỗi tốt,

Các tham số đầu vào nên mô tả rõ ràng, không nhập nhằng, và phù hợp với khả năng của mô hình.

Sai lầm phổ biến:
Một bộ công cụ “phình to” quá mức — chứa quá nhiều chức năng hoặc khiến agent bối rối khi chọn công cụ nào để dùng.
Nếu một kỹ sư con người còn không chắc nên dùng công cụ nào, thì đừng mong một AI agent làm tốt hơn.

Giải pháp: Xây dựng một tập công cụ tối thiểu khả dụng (minimal viable toolset) — điều này giúp việc bảo trì dễ hơn và ngữ cảnh gọn hơn trong các tương tác dài hạn.

5. Ví dụ minh họa (Few-shot prompting)

– Cung cấp ví dụ — hay còn gọi là few-shot prompting — là một thực hành tốt đã được chứng minh qua thời gian.
Nhưng: Đừng “nhồi nhét” hàng loạt tình huống ngoại lệ (edge cases) vào prompt để cố gắng bao phủ mọi quy tắc có thể xảy ra.
Thay vào đó, hãy chọn lọc một bộ ví dụ tiêu biểu, đa dạng và mang tính chuẩn mực (canonical), thể hiện hành vi mong muốn của agent.
Với một mô hình ngôn ngữ, “một ví dụ hay đáng giá hơn cả ngàn dòng hướng dẫn”.
– Giữ ngữ cảnh gọn mà tinh dù bạn đang làm việc với system prompt, công cụ, ví dụ, hay lịch sử hội thoại, hãy nhớ nguyên tắc vàng: “Giữ cho ngữ cảnh có thông tin, nhưng chặt chẽ.”

Mục tiêu của context engineering không phải là nhồi nhét dữ liệu,
mà là chọn lọc thông minh — sao cho mỗi token đều có giá trị đóng góp rõ ràng.

Sự tiến hóa của agent và tầm quan trọng của ngữ cảnh. Khi các mô hình nền tảng (base models) ngày càng thông minh hơn, mức độ tự chủ của agent cũng tăng lên.
Một agent có thể tự điều hướng trong những không gian vấn đề phức tạp, phục hồi sau lỗi, và tự học từ môi trường — điều mà trước đây phải dựa vào kỹ sư con người.

Cùng với sự tiến hóa đó, tư duy thiết kế ngữ cảnh (context design) cũng thay đổi.
Nếu trước đây, nhiều ứng dụng AI chỉ sử dụng kỹ thuật truy xuất ngữ cảnh trước khi suy luận (pre-inference retrieval) — ví dụ, dùng embeddings để lấy ra những đoạn thông tin quan trọng trước khi gửi vào model — thì nay, xu hướng mới là “just-in-time context retrieval”.

– “Just-in-time” – Cung cấp ngữ cảnh đúng lúc thay vì tải trước toàn bộ dữ liệu liên quan, các agent hiện đại chỉ lưu lại những “định danh nhẹ” (lightweight identifiers) như:
– Đường dẫn tệp (file paths),
– Câu truy vấn đã lưu (stored queries),
– Liên kết web (URLs), v.v.
=> Rồi khi cần, agent sẽ tự động gọi công cụ để tải dữ liệu vào ngữ cảnh tại thời điểm runtime.

Ví dụ:
👉 Claude Code – giải pháp “agentic coding” của Anthropic – sử dụng chiến lược này để phân tích dữ liệu phức tạp trên cơ sở dữ liệu lớn. Thay vì nạp toàn bộ dataset, mô hình chỉ viết các truy vấn có mục tiêu, lưu kết quả, và dùng lệnh Bash như head hay tail để xem xét các phần cần thiết.

Cách tiếp cận này bắt chước nhận thức của con người:
chúng ta không ghi nhớ toàn bộ dữ liệu, mà dùng hệ thống tổ chức bên ngoài — như thư mục, hộp thư, hay bookmark — để truy xuất đúng thông tin khi cần. Metadata – Cấu trúc giúp agent hiểu ngữ cảnh: Không chỉ tiết kiệm dung lượng, metadata của các tệp và tham chiếu còn cung cấp tín hiệu quan trọng giúp agent suy luận.

Ví dụ:
Một tệp tên test_utils.py nằm trong thư mục tests/ mang ý nghĩa khác hoàn toàn so với tệp cùng tên trong src/core_logic/.
Cấu trúc thư mục, quy ước đặt tên, và dấu thời gian (timestamp)
→ tất cả đều giúp agent hiểu mục đích và mức độ liên quan của thông tin.

Khả năng tự khám phá ngữ cảnh (Progressive disclosure). Khi cho phép agent tự do điều hướng và truy xuất dữ liệu, ta mở ra khả năng “khám phá ngữ cảnh dần dần” — nghĩa là agent tự tìm ra ngữ cảnh liên quan thông qua trải nghiệm.

Mỗi hành động tạo ra thêm dữ kiện cho vòng suy luận kế tiếp:
– Kích thước file → gợi ý độ phức tạp,
– Tên file → ám chỉ mục đích,
– Thời gian cập nhật → chỉ ra mức độ mới và liên quan.

Agent dần xây dựng bức tranh hiểu biết từng lớp một, chỉ giữ lại thông tin cần thiết trong “bộ nhớ làm việc”, và dùng chiến lược ghi chú (note-taking) để lưu lại phần còn lại.

Kết quả là: Agent tập trung vào phần ngữ cảnh liên quan nhất, thay vì bị “chìm” trong lượng thông tin khổng lồ và nhiễu.

Hiệu năng vs. Tự chủ – Bài toán đánh đổi

Tất nhiên, truy xuất ngữ cảnh lúc runtime chậm hơn so với việc dùng dữ liệu đã được tính toán sẵn.
Hơn nữa, cần kỹ sư giàu kinh nghiệm để thiết kế công cụ và chiến lược điều hướng hợp lý.
Nếu không có định hướng rõ ràng, agent có thể:
– Dùng sai công cụ,
– Đi vào ngõ cụt,
– Hoặc bỏ lỡ thông tin quan trọng.
=> Do đó, trong nhiều tình huống, chiến lược lai (hybrid) là tối ưu:
Một phần ngữ cảnh được tải sẵn để đảm bảo tốc độ, phần còn lại được agent tự truy xuất khi cần.

Ví dụ:
👉 Claude Code nạp sẵn các tệp CLAUDE.md vào ngữ cảnh, nhưng vẫn có thể dùng glob hoặc grep để tự tìm file đúng lúc, tránh lỗi chỉ mục cũ hoặc cây cú pháp phức tạp. Chiến lược này đặc biệt phù hợp với môi trường ổn định như pháp lý hay tài chính, nơi dữ liệu ít thay đổi nhưng vẫn cần độ chính xác cao.Kỹ thuật context engineering cho tác vụ dài hạn

Các tác vụ “dài hơi” — như chuyển đổi toàn bộ codebase hoặc dự án nghiên cứu dài hạn — đòi hỏi agent phải:
– Duy trì tính mạch lạc và mục tiêu trong suốt quá trình, Làm việc qua hàng ngàn bước, vượt xa giới hạn context window của mô hình.
– Chờ đợi “context window lớn hơn” không phải là lời giải duy nhất. Bởi vì, dù dài đến đâu, ngữ cảnh vẫn có thể bị nhiễm nhiễu (context pollution) hoặc chứa thông tin lỗi thời.

Anthropic đề xuất 3 kỹ thuật giúp agent làm việc hiệu quả hơn với thời gian dài:
– Compaction – nén và tổng hợp thông tin cũ để tiết kiệm context,
– Structured note-taking – ghi chú có cấu trúc, giúp agent nhớ lại logic,
– Multi-agent architectures – chia tác vụ lớn thành nhiều agent nhỏ cùng phối hợp.

Compaction – Nén ngữ cảnh thông minh

Compaction là kỹ thuật tóm tắt và nén lại nội dung khi cuộc hội thoại hoặc tác vụ của agent bắt đầu chạm đến giới hạn context window.
Cụ thể, thay vì để mô hình phải “mang vác” toàn bộ lịch sử tương tác dài, ta tạo một bản tóm tắt trung thực (high-fidelity summary), rồi khởi tạo lại ngữ cảnh mới bằng chính bản tóm tắt đó.

Mục tiêu: Giúp agent duy trì mạch logic và độ chính xác lâu dài, mà không bị giảm hiệu suất do giới hạn token.

Ví dụ trong Claude Code, Anthropic thực hiện compaction bằng cách:
Gửi toàn bộ lịch sử tin nhắn cho mô hình, dể mô hình tự tóm tắt và nén lại thông tin quan trọng nhất.bản tóm tắt này thường giữ lại:
– Các quyết định kiến trúc,
– Lỗi chưa xử lý,
– Chi tiết triển khai quan trọng, và loại bỏ những phần dư thừa như kết quả của các lệnh công cụ (tool outputs).
=> Sau đó, agent tiếp tục làm việc với ngữ cảnh đã nén cộng thêm 5 file được truy cập gần nhất — giúp người dùng có cảm giác liền mạch, không lo ngại về giới hạn context.

Điểm tinh tế trong compaction:

Chính là chọn cái gì giữ, cái gì bỏ.Nếu nén quá tay, agent có thể mất những chi tiết nhỏ nhưng quan trọng về sau. Anthropic khuyên kỹ sư nên:
Tối đa hóa recall trong giai đoạn đầu (đảm bảo mọi thông tin quan trọng đều được giữ lại),
Sau đó tối ưu precision, loại bỏ phần dư thừa để tinh gọn hơn.

Ví dụ dễ hiểu: Kết quả của một tool đã được gọi nhiều bước trước hầu như không cần giữ lại.
Anthropic thậm chí đã thêm “tool result clearing” – một dạng compaction nhẹ và an toàn – vào Claude Developer Platform.

Structured Note-Taking – Ghi chú có cấu trúc (Bộ nhớ agentic)

Structured note-taking, hay còn gọi là bộ nhớ agentic, là kỹ thuật mà agent thường xuyên ghi chú các thông tin quan trọng ra ngoài context window.
Những ghi chú này sẽ được gọi lại vào ngữ cảnh khi cần thiết trong các bước sau.

Mục tiêu: Cung cấp cho agent một dạng “bộ nhớ dài hạn” mà không tốn nhiều token.
Ví dụ: Claude Code có thể tạo file TODO.md hoặc NOTES.md để lưu danh sách việc cần làm. Các agent tùy chỉnh có thể ghi chú tiến độ, trạng thái, hoặc các dependency quan trọng giữa các bước phức tạp. Anthropic minh họa bằng ví dụ thú vị: Claude chơi Pokémon 🎮 — Agent này ghi nhớ chính xác hàng ngàn bước chơi:
“Trong 1.234 bước qua, tôi đã luyện Pikachu ở Route 1, tăng 8 cấp, còn 2 cấp nữa đạt mục tiêu.”
Không cần hướng dẫn thêm, Claude tự phát triển bản đồ, nhớ vùng đã khám phá, lưu chiến lược đánh boss hiệu quả nhất, và tiếp tục từ chỗ dừng trước đó sau khi context được reset.

Kết quả: Claude duy trì sự mạch lạc xuyên suốt hàng giờ hoạt động, Thực hiện được chiến lược dài hạn mà không cần giữ mọi thông tin trong context window.
Anthropic đã ra mắt “Memory Tool” (bản beta) trong Claude Developer Platform, cho phép agent lưu trữ và truy xuất ghi chú từ hệ thống file —tức là agent có thể: Xây dựng knowledge base cá nhân, Giữ trạng thái dự án giữa các phiên, Và truy cập lại công việc cũ mà không cần giữ toàn bộ trong context hiện tại.

Sub-Agent Architectures – Kiến trúc đa agent chuyên biệt

Sub-agent architecture là chiến lược phân tán công việc giữa nhiều agent nhỏ, mỗi agent đảm nhận một nhiệm vụ cụ thể trong ngữ cảnh riêng biệt (clean context window).Thay vì để một agent phải “gánh” toàn bộ dự án, Anthropic chia nhỏ thành: Agent chính (lead agent): định hướng tổng thể, ra kế hoạch.Các sub-agent: thực hiện các phần việc kỹ thuật sâu, hoặc dùng tool để tìm thông tin liên quan.Mỗi sub-agent có thể “làm việc” rất sâu (vài chục nghìn token), nhưng chỉ trả lại bản tóm tắt súc tích 1.000–2.000 token cho agent chính.
Ưu điểm:
– Tách biệt rõ ràng giữa “ngữ cảnh chi tiết” và “ngữ cảnh tổng hợp”,
– Giúp agent chính tập trung vào phân tích, tổng hợp và ra quyết định.
Anthropic cho biết mô hình này đã tăng hiệu suất đáng kể trong các tác vụ nghiên cứu phức tạp
(ví dụ: hệ thống nghiên cứu đa agent trong bài How We Built Our Multi-Agent Research System).

Kết luận

Kỹ thuật ngữ cảnh (context engineering) đại diện cho một bước chuyển mình căn bản trong cách chúng ta xây dựng các ứng dụng dựa trên mô hình ngôn ngữ lớn (LLM). Khi các mô hình ngày càng trở nên mạnh mẽ hơn, thách thức không chỉ nằm ở việc tạo ra một prompt hoàn hảo — mà là việc lựa chọn có chủ đích những thông tin nào sẽ được đưa vào trong “ngân sách chú ý” (attention budget) giới hạn của mô hình tại mỗi bước.
Dù bạn đang triển khai compaction cho các tác vụ dài hạn, thiết kế các công cụ tiết kiệm token, hay giúp các tác nhân (agent) khám phá môi trường của mình một cách vừa đúng lúc (just-in-time), thì nguyên tắc cốt lõi vẫn không đổi:
Tìm ra tập hợp nhỏ nhất các token có giá trị thông tin cao nhất để tối đa hóa khả năng đạt được kết quả mong muốn.

Những kỹ thuật được trình bày ở đây sẽ còn tiếp tục phát triển cùng với sự tiến bộ của các mô hình. Chúng ta đã bắt đầu thấy rằng các mô hình thông minh hơn sẽ cần ít kỹ thuật “ép buộc” hơn, cho phép các tác nhân hoạt động tự chủ hơn. Tuy nhiên, ngay cả khi năng lực của mô hình tiếp tục mở rộng, việc xem ngữ cảnh như một nguồn tài nguyên quý giá và hữu hạn vẫn sẽ là yếu tố trung tâm để xây dựng các tác nhân đáng tin cậy và hiệu quả.
Hãy bắt đầu khám phá kỹ thuật context engineering trên nền tảng Claude Developer Platform ngay hôm nay, và tham khảo thêm “Memory and Context Management Cookbook” để tìm hiểu những mẹo và phương pháp thực hành tốt nhất.

Shipping with Codex

Codex: Kỹ Sư Phần Mềm AI Đã Tạo Ra “Sự Thay Đổi Cảm Hứng Lớn” (Vibe Shift) Trong Lập Trình

Gần đây, tại OpenAI, chúng ta đã chứng kiến một điều phi thường: một “sự thay đổi cảm hứng lớn” (vibe shift) trong cách chúng tôi xây dựng phần mềm. Kể từ tháng Tám, mức độ sử dụng Codex—kỹ sư phần mềm AI của chúng tôi—đã tăng gấp mười lần. Codex không chỉ là một công cụ; nó giống như một đồng nghiệp con người mà bạn có thể lập trình đôi, giao phó công việc hoặc đơn giản là để nó tự động thực hiện các nhiệm vụ phức tạp.

Sự bùng nổ này không phải ngẫu nhiên. Nó là kết quả của hàng loạt cập nhật lớn, biến Codex thành một tác nhân mạnh mẽ, an toàn và trực quan hơn, hoạt động trên mọi nền tảng mà bạn xây dựng.

1. Những Cập Nhật Đã Tạo Nên Sự Thay Đổi Lớn

Đại Tu Hoàn Toàn Tác Nhân (Agent Overhaul)

Chúng tôi định nghĩa tác nhân Codex là sự kết hợp của hai yếu tố: mô hình lý luậnbộ công cụ (harness) cho phép nó hành động và tạo ra giá trị.

  • Mô Hình Nâng Cấp: Ban đầu, chúng tôi đã ra mắt GPT-5, mô hình tác nhân tốt nhất của mình. Dựa trên phản hồi, chúng tôi tiếp tục tối ưu hóa và cho ra mắt GPT-5 Codex, một mô hình được tinh chỉnh đặc biệt cho công việc mã hóa. Người dùng mô tả nó như một “kỹ sư cấp cao thực thụ” vì nó không ngại đưa ra phản hồi thẳng thắn và từ chối những ý tưởng tồi.
  • Hệ Thống Công Cụ Mới (Harness): Chúng tôi đã viết lại hoàn toàn bộ công cụ để tận dụng tối đa các mô hình mới. Hệ thống này bổ sung các tính năng quan trọng như lập kế hoạch (planning), nén tự động bối cảnh (autoco compaction)—cho phép các cuộc trò chuyện và tương tác cực kỳ dài—và hỗ trợ cho MCP (Multi-Context Protocol).

Trải Nghiệm Người Dùng Được Tinh Chỉnh

Dù mô hình và tác nhân mạnh mẽ, phản hồi ban đầu cho thấy giao diện dòng lệnh (CLI) còn “sơ khai”.

  • CLI Revamp: Chúng tôi đã đại tu CLI, đơn giản hóa chế độ phê duyệt (approvals modes), tạo ra giao diện người dùng dễ đọc hơn và thêm nhiều chi tiết tinh tế. Quan trọng nhất, Codex CLI hiện mặc định hoạt động với sandboxing (môi trường hộp cát), đảm bảo an toàn theo mặc định trong khi vẫn trao toàn quyền kiểm soát cho người dùng.
  • Tiện Ích Mở Rộng IDE: Để hỗ trợ người dùng muốn xem và chỉnh sửa code cùng lúc với việc cộng tác với Codex, chúng tôi đã phát hành một extension bản địa (native extension) cho IDE. Tiện ích này hoạt động với VS Code, Cursor và các bản fork phổ biến khác. Nó đã bùng nổ ngay lập tức, thu hút 100.000 người dùng trong tuần đầu tiên—bằng cách sử dụng cùng một tác nhân mạnh mẽ và bộ công cụ mã nguồn mở (open-source harness) đã cung cấp sức mạnh cho CLI.
  • Codex Cloud Nhanh Hơn: Chúng tôi đã nâng cấp Codex Cloud để chạy nhiều tác vụ song song, tăng tốc độ tác vụ Cloud lên 90%. Tác vụ Cloud giờ đây có thể tự động thiết lập các phụ thuộc, thậm chí xác minh công việc bằng cách chụp ảnh màn hình và gửi cho bạn.

Codex Hoạt Động Mọi Nơi

Codex giờ đây hoạt động tích hợp sâu vào quy trình làm việc của bạn:

  • Slack và GitHub: Codex có thể được giao nhiệm vụ trực tiếp trong các công cụ cộng tác như Slack. Nó nhận toàn bộ bối cảnh từ luồng trò chuyện, tự mình khám phá vấn đề, viết code, và đăng giải pháp cùng với bản tóm tắt chỉ sau vài phút.
  • Review Code Độ Tin Cậy Cao: Việc đánh giá và duyệt code đang trở thành nút thắt cổ chai lớn. Chúng tôi đã huấn luyện GPT-5 Codex đặc biệt để thực hiện review code cực kỳ kỹ lưỡng (ultra thorough). Nó khám phá toàn bộ code và các phụ thuộc bên trong container của mình, xác minh ý định và việc triển khai. Kết quả là những phát hiện có tín hiệu rất cao (high signal), đến mức nhiều đội đã bật nó theo mặc định, thậm chí cân nhắc bắt buộc.

2. Codex Đang Thúc Đẩy OpenAI Như Thế Nào

Kết quả nội bộ tại OpenAI là minh chứng rõ ràng nhất cho sức mạnh của Codex:

  • 92% nhân viên kỹ thuật của OpenAI sử dụng Codex hàng ngày (tăng từ 50% vào tháng Bảy).
  • Các kỹ sư sử dụng Codex nộp 70% nhiều PR (Pull Requests) hơn mỗi tuần.
  • Hầu như tất cả các PR đều được Codex review. Khi nó tìm thấy lỗi, các kỹ sư cảm thấy hào hứng vì nó giúp tiết kiệm thời gian và tăng độ tin cậy khi triển khai.

3. Các Quy Trình Làm Việc Thực Tế Hàng Ngày

Các kỹ sư của chúng tôi đã chia sẻ những ví dụ thực tế về cách họ sử dụng Codex để giải quyết các vấn đề phức tạp.

Trường Hợp 1: Lặp Lại Giao Diện Người Dùng (UI) Với Bằng Chứng Hình Ảnh (Nacho)

Nacho, kỹ sư iOS, đã chia sẻ quy trình làm việc tận dụng tính năng đa phương thức (multimodal) của Codex:

  • Vấn Đề: Trong công việc front-end, 10% công việc đánh bóng cuối cùng—như căn chỉnh header/footer—thường chiếm đến 90% thời gian.
  • Giải Pháp: Nacho giao cho Codex nhiệm vụ triển khai UI từ một bản mockup. Khác với các agent cũ (được ví như “kỹ sư tập sự”), Codex (được ví như “kỹ sư cấp cao”) xác minh công việc của nó.
  • Quy Trình TDD & Multimodal:
    1. Nacho cung cấp cho Codex một công cụ đơn giản: một script Python (do Codex viết) để trích xuất các snapshot (ảnh chụp giao diện) từ các SwiftUI Previews.
    2. Nó được hướng dẫn sử dụng công cụ này để xác minh trực quan code UI mà nó viết.
    3. Codex lặp đi lặp lại: Viết code > Chạy test/Snapshot > Sửa lỗi cho đến khi giao diện đạt đến độ hoàn hảo về pixel (pixel perfect).
  • Kết Quả: Nacho có thể để Codex làm việc trên những chi tiết nhỏ (10% độ đánh bóng) trong khi anh làm những việc khác, biết rằng nó sẽ tự kiểm tra công việc của mình bằng hình ảnh.

Trường Hợp 2: Mở Rộng Giới Hạn Tác Vụ Lớn (Fel)

Fel, được biết đến là người có phiên làm việc Codex lâu nhất (hơn bảy giờ) và xử lý nhiều token nhất (hơn 150 triệu), đã chứng minh cách anh thực hiện các tác vụ refactor lớn chỉ với vài lời nhắc.

  • Vấn Đề: Thực hiện một refactor lớn (như thay đổi 15.000 dòng code) trong các dự án phức tạp (như bộ phân tích JSON cá nhân của anh) thường dẫn đến việc tất cả các bài kiểm tra thất bại trong thời gian dài.
  • Giải Pháp: Kế Hoạch Thực Thi (Exec Plan):
    1. Fel yêu cầu Codex viết một đặc tả (spec)—được gọi là plans.md—để triển khai tính năng, giao cho nó nhiệm vụ nghiên cứu thư viện và cách tích hợp.
    2. Anh định nghĩa plans.md là một “tài liệu thiết kế sống” (living document) mà Codex phải liên tục cập nhật, bao gồm mục tiêu lớn, danh sách việc cần làm, tiến trình, và nhật ký quyết định (decision log).
    3. Anh sử dụng thuật ngữ neo “exec plan” để đảm bảo mô hình biết khi nào cần tham chiếu và phản ánh lại tài liệu này.
    4. Sau khi Fel phê duyệt kế hoạch, anh ra lệnh: “Implement” (Thực thi).
  • Kết Quả: Codex có thể làm việc một cách hiệu quả trong nhiều giờ (thậm chí hơn một giờ trong buổi demo) trên một tính năng lớn, sử dụng plans.md như bộ nhớ và kim chỉ nam. Trong một phiên, nó đã tạo ra 4.200 dòng code chỉ trong khoảng một giờ—mọi thứ đều được kiểm tra và vượt qua.

Trường Hợp 3: Vòng Lặp Sửa Lỗi và Review Tại Chỗ (Daniel)

Daniel, một kỹ sư trong nhóm Codex, đã giới thiệu quy trình làm việc slash review mới, đưa khả năng review code chất lượng cao của GPT-5 Codex xuống môi trường cục bộ (local).

  • Vấn Đề: Ngay cả sau khi hoàn thành code, các kỹ sư cần một bộ mắt mới không bị thiên vị để tìm ra các lỗi khó.
  • Giải Pháp: Slash Review: Trước khi gửi PR, Daniel sử dụng lệnh /review trong CLI.
    • Anh chọn duyệt so với nhánh gốc (base branch), tương tự như một PR.
    • GPT-5 Codex bắt đầu luồng review chuyên biệt: Nó nghiên cứu sâu các tập tin, tìm kiếm các lỗi kỹ thuật, và thậm chí viết/chạy các script kiểm tra để xác minh các giả thuyết lỗi trước khi báo cáo.
    • Mô hình thiên vị: Luồng review chạy trong một luồng riêng biệt, có bối cảnh mới mẻ (fresh context), loại bỏ bất kỳ thiên vị triển khai (implementation bias) nào từ cuộc trò chuyện trước.
  • Vòng Lặp Sửa Lỗi: Khi Codex tìm thấy một vấn đề P0/P1, Daniel chỉ cần gõ “Please fix”.
  • Kết Quả: Codex sửa lỗi, và Daniel có thể chạy /review lần nữa cho đến khi nhận được “thumbs up” (chấp thuận) cuối cùng. Điều này đảm bảo code được kiểm tra kỹ lưỡng, được sửa lỗi cục bộ trước khi push, tiết kiệm thời gian và đảm bảo độ tin cậy cao hơn.

 

Ba chức năng chính của Codex, được nhấn mạnh trong bài thuyết trình, là:

  1. Lập Trình Đôi và Triển Khai Code (Implementation & Delegation):
    • Codex hoạt động như một đồng đội lập trình đôi trong IDE/CLI, giúp bạn viết code nhanh hơn.
    • Nó có thể nhận ủy quyền (delegate) các tác vụ lớn hơn (như refactor hoặc thêm tính năng) và tự thực hiện trong môi trường Cloud/Sandboxing, bao gồm cả việc tự thiết lập dependencies và chạy song song.
  2. Xác Minh và Kiểm Thử Tự Động (Verification & TDD):
    • Codex tích hợp sâu với quy trình Test-Driven Development (TDD).
    • Nó không chỉ viết code mà còn tự động chạy các bài kiểm thử (unit tests) và xác minh đa phương thức (ví dụ: tạo và kiểm tra snapshot UI) để đảm bảo code hoạt động chính xác và đạt độ hoàn hảo về mặt hình ảnh (pixel perfect).
  3. Review Code Độ Tin Cậy Cao (High-Signal Code Review):
    • Sử dụng mô hình GPT-5 Codex được tinh chỉnh, nó thực hiện review code cực kỳ kỹ lưỡng (ultra thorough) trên GitHub PR hoặc cục bộ thông qua lệnh /review.
    • Chức năng này giúp tìm ra các lỗi kỹ thuật khó và có thể được sử dụng trong vòng lặp Review -> Fix -> Review để đảm bảo chất lượng code trước khi merge, tiết kiệm thời gian và tăng độ tin cậy khi triển khai.

Link video: https://www.youtube.com/watch?v=Gr41tYOzE20