Tag: AI Agent

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

Posted on by Dai Ha

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.

Context Engineering cho AI Agents – Tóm tắt từ Anthropic

Posted on by Cuong Dinh

 

Context Engineering cho AI Agents

Tóm tắt từ bài viết của Anthropic về nghệ thuật quản lý context trong phát triển AI

🎯 Context Engineering là gì?

Context Engineering là tập hợp các chiến lược để tuyển chọn và duy trì bộ tokens (thông tin) tối ưu trong quá trình AI agents hoạt động.

Nó bao gồm việc quản lý toàn bộ trạng thái context như:

  • System prompts (hướng dẫn hệ thống)
  • Tools (công cụ)
  • Model Context Protocol (MCP)
  • External data (dữ liệu bên ngoài)
  • Message history (lịch sử hội thoại)
  • Các thông tin khác trong context window

💡 Bản chất: Context Engineering là nghệ thuật và khoa học về việc tuyển chọn thông tin nào sẽ đưa vào context window giới hạn từ vũ trụ thông tin liên tục phát triển của agent.

🔄 Khác biệt giữa Context Engineering và Prompt Engineering

📝 Prompt Engineering

  • Focus: Cách viết instructions (hướng dẫn)
  • Phạm vi: Tối ưu hóa system prompts
  • Use case: Tác vụ đơn lẻ, one-shot
  • Tính chất: Rời rạc, tĩnh

Ví dụ: “Tóm tắt văn bản này thành 3 điểm chú trọng số liệu tài chính”

🧠 Context Engineering

  • Focus: Model nhìn thấy gì trong context window
  • Phạm vi: Toàn bộ trạng thái thông tin
  • Use case: Multi-turn, tác vụ dài hạn
  • Tính chất: Lặp lại, động, liên tục

Ví dụ: Quyết định agent nên xem toàn bộ tài liệu, 3 phần cuối, hay bản tóm tắt đã chuẩn bị?

🎭 Ẩn dụ: Prompt engineering là “nói cho ai đó biết phải làm gì”, còn context engineering là “quyết định nên cung cấp nguồn lực gì cho họ”.

⚡ Tại sao Context Engineering quan trọng hơn?

Khi AI agents thực hiện các tác vụ phức tạp trên nhiều vòng lặp, chúng tạo ra ngày càng nhiều dữ liệu. Thông tin này phải được tinh chỉnh theo chu kỳ. Context engineering xảy ra mỗi khi chúng ta quyết định đưa gì vào model – đây là quá trình lặp đi lặp lại, không phải một lần.

⚠️ Những điều cần chú ý khi phát triển AI Agents

1. 🎯 Vấn đề “Goldilocks Zone” cho System Prompts

System prompts cần nằm ở “vùng vừa phải” giữa hai thái cực:

❌ Quá cứng nhắc: Hardcode logic if-else phức tạp → agent dễ vỡ, khó bảo trì

❌ Quá mơ hồ: Hướng dẫn chung chung, giả định context chung → thiếu tín hiệu cụ thể

✅ Vùng tối ưu: Đủ cụ thể để dẫn dắt hành vi, nhưng đủ linh hoạt để cung cấp heuristics mạnh mẽ

2. 🧹 “Context Rot” – Sự suy giảm độ chính xác

Khi context window dài ra, độ chính xác của model giảm xuống:

  • Giới hạn chú ý: LLMs giống con người – không thể nhớ mọi thứ khi quá tải. Nhiều tokens ≠ chính xác hơn
  • Context rot: Context càng dài, độ chính xác truy xuất càng giảm. Thêm 100 trang logs có thể che mất chi tiết quan trọng duy nhất
  • Kiến trúc transformer: Tạo n² mối quan hệ giữa các tokens (10K tokens = 100M quan hệ, 100K tokens = 10B quan hệ)

💡 Giải pháp: Implement pagination, range selection, filtering, truncation với giá trị mặc định hợp lý

3. 🔧 Quản lý Tools hiệu quả

  • Giữ tools riêng biệt: Không tạo 2 tools cùng làm việc giống nhau (VD: cùng fetch news)
  • Mô tả rõ ràng: Viết tool descriptions như hướng dẫn nhân viên mới – rõ ràng, tránh mơ hồ
  • Token-efficient: Giới hạn tool responses (VD: Claude Code giới hạn 25,000 tokens mặc định)
  • Error handling tốt: Error messages phải cụ thể, actionable, không phải error codes mơ hồ

4. 📊 Just-in-Time Context Retrieval

Thay vì load toàn bộ dữ liệu trước, hãy fetch dữ liệu động khi cần:

  • Tránh overload context window
  • Giảm token costs
  • Ngăn context poisoning (nhiễu thông tin)
  • Tương tự cách con người dùng hệ thống indexing bên ngoài

5. 🎨 Ba chiến lược cho tác vụ dài hạn

📦 Compaction (Nén thông tin)

Tóm tắt context cũ, giữ lại thông tin quan trọng

📝 Structured Note-Taking

Agent tự ghi chú có cấu trúc về những gì đã làm

🤖 Multi-Agent Architecture

Spawn sub-agents nhỏ cho các tác vụ hẹp, trả về kết quả ngắn gọn

6. 🎯 Ưu tiên Context theo tầm quan trọng

🔴 High Priority (luôn có trong context): Tác vụ hiện tại, kết quả tool gần đây, hướng dẫn quan trọng

🟡 Medium Priority (khi có không gian): Examples, quyết định lịch sử

⚪ Low Priority (on-demand): Nội dung file đầy đủ, documentation mở rộng

7. 📈 Monitoring và Iteration

Theo dõi liên tục:

  • Token usage per turn
  • Tool call frequency
  • Context window utilization
  • Performance ở các độ dài context khác nhau
  • Recall vs Precision khi rút gọn context

💡 Quy trình: Bắt đầu đơn giản → Test → Xác định lỗi → Thêm hướng dẫn cụ thể → Loại bỏ redundancy → Lặp lại

💡 Kết luận

Context engineering là kỹ năng then chốt để xây dựng AI agents hiệu quả. Khác với prompt engineering tập trung vào “cách viết instructions”, context engineering quan tâm đến “môi trường thông tin toàn diện” mà agent hoạt động.

Thành công không nằm ở việc tìm từ ngữ hoàn hảo, mà là tối ưu hóa cấu hình context để tạo ra hành vi mong muốn một cách nhất quán.

🎯 Nguyên tắc cốt lõi: Tìm bộ tokens nhỏ nhất có tín hiệu cao nhất để tối đa hóa khả năng đạt được kết quả mong muốn. Mỗi từ không cần thiết, mỗi mô tả tool thừa, mỗi dữ liệu cũ đều làm giảm hiệu suất agent.

AgentKit vs Dify: A Comprehensive Analysis for AI Agent Development

Posted on by Phat Ly

I. Introduction

In the rapidly evolving landscape of AI agent development, two prominent platforms have emerged as key players: AgentKit by OpenAI and Dify as an open-source alternative. This comprehensive analysis explores their capabilities, differences, and use cases to help developers and businesses make informed decisions.

II. What is AgentKit?

AgentKit is OpenAI’s comprehensive toolkit for building AI agents, designed to provide developers with the tools and infrastructure needed to create sophisticated AI-powered applications. It represents OpenAI’s vision for the future of AI agent development, offering both foundational components and advanced capabilities.

Core Components

  • Agent Builder: Visual interface for creating and configuring AI agents
  • ChatKit: Pre-built chat interfaces and conversation management
  • Connector Registry: Library of pre-built integrations with popular services
  • Evals: Comprehensive evaluation framework for testing agent performance
  • Guardrails: Safety and compliance tools for production deployments

III. What is Dify?

Dify is an open-source platform that enables users to build AI applications without extensive coding knowledge. It focuses on providing a visual, user-friendly interface for creating AI-powered workflows and applications.

Key Features

  • Visual Workflow Builder: Drag-and-drop interface for creating AI workflows
  • Multi-Model Support: Integration with various AI models and providers
  • Template Library: Pre-built templates for common use cases
  • API Management: RESTful APIs for integration

IV. Detailed Comparison: AgentKit vs Dify

Feature AgentKit Dify
Target Audience Developers & Enterprises Non-technical users & Startups
Learning Curve Steep (requires coding knowledge) Gentle (visual interface)
Customization Level High (full code control) Medium (template-based)
Integration Depth Deep API integration Surface-level integration
Scalability Enterprise-grade Small to medium projects
Cost Model Usage-based pricing Open-source + hosting costs
Support Enterprise support Community-driven
Deployment Cloud-first Self-hosted or cloud
Security Built-in enterprise security Basic security features
Performance Optimized for production Suitable for prototyping

Table 1: Feature Comparison Overview

V. Technical Implementation Comparison

Architecture and Deployment

Aspect AgentKit Dify
Architecture Microservices, cloud-native Monolithic, containerized
Deployment OpenAI cloud platform Self-hosted or cloud
Scaling Auto-scaling, enterprise-grade Manual scaling, limited
Monitoring Advanced analytics and logging Basic monitoring
Backup Automated, enterprise backup Manual backup solutions

Table 2: Architecture and Deployment Comparison

Security and Compliance

Security Feature AgentKit Dify
Authentication Enterprise SSO, MFA Basic auth, OAuth
Data Encryption End-to-end encryption Basic encryption
Compliance SOC 2, GDPR, HIPAA Basic compliance
Audit Logging Comprehensive audit trails Limited logging
Access Control Role-based, fine-grained Basic permission system

Table 3: Security and Compliance Comparison

Performance and Optimization

Metric AgentKit Dify
Response Time < 100ms (optimized) 200-500ms (standard)
Throughput 10,000+ requests/second 1,000 requests/second
Concurrent Users Unlimited (auto-scaling) Limited by infrastructure
Uptime 99.9% SLA Depends on hosting
Caching Advanced caching strategies Basic caching

Table 4: Performance and Optimization Comparison

VI. Cost and ROI Analysis

AgentKit Cost Analysis

Initial Costs

  • Setup and configuration: $5,000 – $15,000 USD
  • Team training: $10,000 – $25,000 USD
  • Integration development: $20,000 – $50,000 USD

Monthly Operating Costs

  • API usage: $0.01 – $0.10 USD per request
  • Enterprise support: $2,000 – $10,000 USD/month
  • Infrastructure: $1,000 – $5,000 USD/month

ROI Timeline: 6-12 months for enterprise projects

Dify Cost Analysis

Initial Costs

  • Setup: $0 USD (open source)
  • Basic configuration: $500 – $2,000 USD
  • Custom development: $2,000 – $10,000 USD

Monthly Operating Costs

  • Hosting: $100 – $1,000 USD/month
  • Maintenance: $500 – $2,000 USD/month
  • Support: Community-based (free)

ROI Timeline: 1-3 months for small projects

VII. Getting Started (Terminal Walkthrough)

The following screenshots demonstrate the complete setup process from scratch, showing each terminal command and its output for easy replication.

Step 1 — Clone the repository

Shows the git clone command downloading the AgentKit sample repository from GitHub with progress indicators and completion status.

Step 2 — Install dependencies

Displays the npm install process installing required packages (openai, express, cors, dotenv) with dependency resolution and warnings about Node.js version compatibility.

Step 3 — Configure environment (.env)

Demonstrates creating the .env file with environment variables including OPENAI_API_KEY placeholder and PORT configuration.

Step 4 — Run the server

Shows the server startup process with success messages indicating the AgentKit sample server is running on localhost:3000 with available agents and tools.

Step 5 — Verify health endpoint

Displays the API health check response using PowerShell’s Invoke-WebRequest command, showing successful connection and server status.

Step 6 — Verify port (optional)

Shows netstat command output confirming port 3000 is listening and ready to accept connections.

VIII. Demo Application Features

The following screenshots showcase the key features of our AgentKit sample application, demonstrating its capabilities and user interface.

Main Interface

Shows the main application interface with agent selection dropdown, tools toggle, chat messages area, and input section with modern gradient design.

Agent Switching

Demonstrates switching between different agent types (General, Coding, Creative) with dynamic response styles and specialized capabilities.

Tool Integration

Shows the calculator tool in action, displaying mathematical calculations with formatted results and tool usage indicators.

Conversation Memory

Illustrates conversation history and context awareness, showing how the agent remembers previous interactions and maintains coherent dialogue.

Mobile Responsive

Displays the mobile-optimized interface with responsive design, touch-friendly controls, and adaptive layout for smaller screens.

Error Handling

Shows graceful error handling with user-friendly error messages, retry options, and fallback responses for failed requests.

IX. Conclusion

Key Takeaways

  • AgentKit is ideal for enterprise applications requiring high performance, security, and scalability
  • Dify is perfect for rapid prototyping, small projects, and teams with limited technical expertise
  • Both platforms have their place in the AI development ecosystem
  • Choose based on your specific requirements, team capabilities, and budget constraints

The choice between AgentKit and Dify ultimately depends on your specific needs, team capabilities, and project requirements. AgentKit offers enterprise-grade capabilities for complex, scalable applications, while Dify provides an accessible platform for rapid development and prototyping.

As the AI agent development landscape continues to evolve, both platforms will likely see significant improvements and new features. Staying informed about their capabilities and roadmaps will help you make the best decision for your projects.

This analysis provides a comprehensive overview to help you choose the right platform for your AI agent development needs. Consider your specific requirements, team capabilities, and long-term goals when making your decision.

 

Event-Driven Multi-Agent Systems: Let Agents Act, Not Wait

Posted on by Long Dang

AI is no longer just about single-use automation. The real power lies in multi-agent systems, networks of AI agents that work together, each specializing in a task but coordinating as part of a larger, intelligent system.

The fastest way to turn promising multi-agent prototypes into production systems is to make them event-driven. Replace brittle request/response chains with a shared event log and topic-based messaging so agents can react in real time, scale independently, and recover from failure by replay. Four field-tested patterns—orchestrator-worker, hierarchical, blackboard, and market-based—map cleanly onto streams (e.g., Kafka topics) and solve most coordination problems you’ll hit in the wild.

The Challenges of Multi-Agent Collaboration

AI agents don’t operate in isolation.

They need to share context, coordinate actions, and make real-time decisions — all while integrating with external tools, APIs, and data sources. When communication is inefficient, agents end up duplicating work, missing critical updates from upstream agents, or worse, creating bottlenecks that slow everything down.

Beyond communication, multi-agent systems introduce additional scaling challenges:

  • Data Fragmentation — Agents need access to real-time data, but traditional architectures struggle with ensuring consistency without duplication or loss.
  • Scalability and Fault Tolerance — As the number of agents grows, failures become more frequent. A resilient system must adapt without breaking.
  • Integration Overhead — Agents often need to interact with external services, databases, and APIs, but tightly coupled architectures make this difficult to scale.
  • Delayed Decision-Making — Many AI-driven applications, from fraud detection to customer engagement, require real-time responsiveness. But conventional request/response architectures slow this down.

 

Why multi-agent systems struggle in production

Multi-agent AI shines when specialized agents collaborate: one reasons over intent, another calls tools, another validates outputs, another enforces policy. But the moment you wire them together with synchronous calls, you create tight coupling, cascading timeouts, and opaque failure modes—exactly the problems early microservices faced before they moved to events. Agents need to react to what happened, not block each other waiting for RPCs.

Key pain points you’ll see at scale:

  • Communication bottlenecks and tangled dependencies

  • Data staleness and inconsistent context across agents

  • Fragile scaling & fault tolerance when agents come and go

  • Debuggability—it’s hard to reconstruct “who did what, when, and why” without an immutable log of event

These are precisely what event-driven design addresses.

Core idea: Agents as event processors + a shared log

Switch the mental model from “agents calling agents” to agents that consume commands/events and emit new events. Give them:

  • Input: subscriptions to topics (events/commands)

  • Processing: reasoning + tool use + retrieval over state

  • Output: new events (facts, decisions, tool results) appended to the log

With a durable, immutable event log (e.g., Kafka), you gain replay, time-travel debugging, and fan-out (many agents can react to the same event). Loose coupling drops operational complexity and lets you add/remove agents without re-wiring peers.

Four event-driven patterns you can ship today

These patterns come from distributed systems and MAS research, adapted to an event streaming backbone. Use them as building blocks rather than a religion—most real systems combine two or more.

1. Orchestrator-Worker

A central orchestrator breaks work into tasks and publishes them to a commands topic using a keying strategy (e.g., by session or customer). Workers form a consumer group, pull tasks, and publish results to a results topic. Scaling up = adding workers; failure recovery = replay from the last committed offset.

Use when: you need ordered handling per key, clear ownership of “who decides next,” and easy horizontal scale.

2. Hierarchical Agents

A tree of orchestrators: higher-level agents decompose goals into sub-goals for mid-level agents, which orchestrate leaf agents. Each layer is just a specialized orchestrator-worker pattern with its own topics, so you can evolve the tree without bespoke glue code.

Use when: problems decompose naturally (e.g., “Plan → Research → Draft → Review → Approve”).

3. Blackboard (Shared Memory)

Agents collaborate by reading/writing to a shared blackboard topic (or set of topics). Instead of point-to-point calls, each agent posts partial findings and subscribes to the evolving “state of the world.” Add lightweight schema tags (origin, confidence, step) for downstream filtering.

Use when: contributions are incremental and loosely ordered (perception → hypotheses → refinement).

4. Market-Based (Bidding)

Agents “bid” on a task by posting proposals; an aggregator selects winners after N rounds. Moving bids and awards onto topics prevents the O(N²) web of direct connections between solvers and keeps negotiation auditable.

Use when: you want competition among diverse solvers (planning, routing, pricing, ensemble reasoning).

Architecture sketch

At minimum you’ll want:

  1. Topics: agent.commands.*, agent.events.*, agent.results.*, plus domain streams (orders, alerts, leads).

  2. Schemas: JSON/Avro with versioned envelopes (type, source_agent, correlation_id, causation_id, ttl, safety_level, confidence).

  3. State: local caches or stateful processors (Flink/ksqlDB) for per-key context, backed by a durable changelog.

  4. Governance: central registry for schemas, PII tags, retention, and ACLs; redaction at the edge.

  5. Observability: trace by correlation_id; attach decision summaries to each event for auditability and evals.

From request/response to events: a practical migration path

  1. Define the agent interface as events. List the event types each agent consumes and emits. Treat these as public contracts.

  2. Introduce topics alongside your existing RPCs. Start publishing key milestones (task-created, tool-called, output-ready) even while calls remain.

  3. Move coordination out of code and into the stream. Replace “call Agent B, wait” with “publish Need:SummaryDraft and subscribe to SummaryDrafted.”

  4. Add replay-based testing. Re-feed yesterday’s log into a staging cluster to regression-test new agent policies without touching prod.

  5. Evolve toward patterns. As volume and agent count grow, snap into orchestrator-worker or blackboard to keep complexity in check.

Real-world payoffs

  • Parallelism: multiple agents respond to the same event—no coordinator bottleneck.

  • Resilience: if one agent dies, events aren’t lost; it resumes from the last offset.

  • Adaptability: add a new “critic” or “safety” agent by subscribing it to existing topics.

  • Traceability: every decision is a line in the log; audits and RCA stop being archaeology.

Pitfalls & how to avoid them

  • Schema drift → Use a schema registry and contract testing; never break consumers.

  • Unbounded topics → Set retention & compaction by domain (minutes for hot signals, days for ops, long-term in the data lake).

  • Chatty agents → Introduce back-pressure (quotas), batch low-value events, and enforce ttl.

  • Hidden coupling → If an agent can’t act without a specific peer, you’ve snuck in a request/response dependency. Refactor to events.

Example: Minimal event envelope (pseudocode)

When to pick which pattern

  • Highly structured workflows → Orchestrator-Worker

  • Goal decomposition → Hierarchical

  • Collaborative sense-making → Blackboard

  • Competitive ensemble solving → Market-Based

In practice, start orchestrator-worker for reliability, add a blackboard for shared context, then scale into hierarchical as teams/features grow

The bottom line

If you’re serious about production-grade agents, architecture matters more than model choice. Event-driven design gives agents the freedom to act while staying coordinated, observable, and resilient—mirroring the same evolution that made microservices workable at scale. Now is the time to formalize your agent interfaces as events and adopt patterns that have already proven themselves in distributed systems.

Further reading

  • Four Design Patterns for Event-Driven, Multi-Agent Systems (Confluent, Feb 19, 2025). Clear, concrete mappings of MAS patterns onto Kafka. Confluent

  • AI Agents Must Act, Not Wait (Medium, Jul 9, 2025). A crisp case for event-driven MAS and the shift away from request/response. Medium

Exploring Claude Code Subagents: A Demo Setup for a RAG-Based Website Project

Posted on by Hieu Pham Pro

1. Introduction

Recently, Anthropic released an incredible new feature for its product Claude: subagents — secondary agents with specific tasks for different purposes within a user’s project.

2. Main Content

a. How to Set It Up:
First, install Claude using the following command in your Terminal window:

npm i @anthropic-ai/claude-code

If Claude is already installed but it’s an older version, it won’t have the subagent feature.

to update claude, command : claude update

Launch Claude Code in your working directory, then run the command:
/agents

Press Enter, and a management screen for agents will appear, allowing you to start creating agents with specific purposes for your project.

Here, I will set it up following Claude’s recommendation.

After the setup, I have the following subagents:

I will ask Claude to help me build a website using RAG with the following prompt:

The first subagents have started working.

The setup of the RAG project has been completed.

However, I noticed that the subagent ‘production-code-reviewer (Review RAG system code)’ didn’t function after the coding was completed. It might be an issue with my prompt, so I will ask Claude to review the code for me

After the whole working process, Claude Code will deliver an excellent final product.
Link: https://github.com/mhieupham1/claudecode-subagent

3. Conclusion

Through the entire setup process and practical use in a project, it’s clear how powerful and beneficial the Sub-agents feature introduced by Anthropic for Claude Code is. It enables us to have AI “teammates” with specialized skills and roles that operate independently without interfering with each other — allowing projects to be organized, easy to understand, and efficient.

Combining tmux and Claude to Build an Automated AI Agent System (for Mac & Linux)

Posted on by Hieu Pham Pro

1. Introduction

With the rapid growth of AI, multi-agent systems are attracting more attention due to their ability to coordinate, split tasks, and handle complex automation. An “agent” can be an independent AI responsible for a specific role or task.

In this article, I’ll show you how to combine tmux (a powerful terminal multiplexer) with Claude (Anthropic’s AI model) to build a virtual organization. Here, AI agents can communicate, collaborate, and work together automatically via the terminal.

 

2. What is tmux?

tmux lets you split your terminal into multiple windows or sessions, each running its own process independently. Even if you disconnect, these sessions stay alive. This is super useful when you want to run several agents in parallel, each in their own terminal, without interfering with each other.

 

3. What is Claude?

Claude is an advanced language AI model developed by Anthropic. It can understand and respond to text requests, and it’s easy to integrate into automated systems—acting as a “virtual employee” taking on part of your workflow.

 

4. Why combine tmux and Claude?

Parallel & Distributed: Each agent is an independent Claude instance running in its own tmux session.

Workflow Automation: Easily simulate complex workflows between virtual departments or roles.

Easy Debug & Management: You can observe each agent’s logs in separate panes or sessions.

 

5. System Architecture

Let’s imagine a simple company structure:

PRESIDENT: Project Director (sets direction, gives instructions)

boss1: Team Leader (splits up tasks)

worker1, worker2, worker3: Team members (do the work)

Each agent has its own instruction file so it knows its role when starting up.

Agents communicate using a script:

./agent-send.sh [recipient] “[message]”

Workflow:

PRESIDENT → boss1 → workers → boss1 → PRESIDENT

 

6. Installation

Since the code is a bit long, I’ll just share the GitHub link to keep things short.

tmux:
Install guide: tmux Installing Guide

Claude:
Install guide: Claude Setup Guide

Git:
Install guide: Git Download

Clone the project:

bash
git clone https://github.com/mhieupham1/claudecliagent

 

Inside, you’ll find the main folders and files:

CLAUDE.md: Describes the agent architecture, communication, and workflows.

instructions/: Contains guidance for each role.

.claude/: JSON files to manage permissions for bash scripts.

setup.sh: Launches tmux sessions for PRESIDENT, boss1, worker1, worker2, worker3 so agents can talk to each other.

agent-send.sh: Script for sending messages between agents.

 

7. Deployment

Run the setup script:

bash
./setup.sh
This will create tmux sessions for PRESIDENT and the agents (boss1, worker1, worker2, worker3) in the background.

To access the PRESIDENT session:

bash
tmux attach-session -t president


To access the multiagent session:

bash
tmux attach-session -t multiagent


In the PRESIDENT session, run the claude command to set up the Claude CLI.

Do the same for the other agents.

Now, in the PRESIDENT window, try entering a request like:

you are president. create a todo list website now
PRESIDENT will start the to-do list. PRESIDENT will send instructions to boss1, boss1 will assign tasks to worker1, worker2, and worker3.

You can watch boss1 and the workers do their jobs, approve commands to create code files, and wait for them to finish.

Result:

8. Conclusion

Combining tmux and Claude lets you create a multi-agent AI system that simulates a real company: communicating, collaborating, and automating complex workflows. Having each agent in its own session makes it easy to manage, track progress, and debug.

This system is great for AI research, testing, or even real-world workflow automation, virtual team assistants, or teamwork simulations.

If you’re interested in developing multi-agent AI systems, try deploying this model, customize roles and workflows to your needs, and feel free to contribute or suggest improvements to the original repo!

Bước tiến của AI Agent: Khả năng lập luận, lập kế hoạch, thực thi trong kỷ nguyên mới

Posted on by Quynh Nga

Xin chào các bạn, tôi là Quỳnh Nga!

AI đang là một chủ đề cực kỳ nóng hổi, thu hút sự quan tâm trên toàn cầu. Hòa cùng tinh thần “tự học” sôi nổi tại công ty, tuần này tôi đã tìm hiểu về Bước tiến của AI Agent trong kỷ nguyên mới – một chủ đề đầy thú vị và hứa hẹn nhiều đột phá. Hãy cùng khám phá trong bài viết này nhé!

1. Khả năng và hạn chế hiện tại của các hệ thống AI Agent

AI Agent, hay tác tử AI, đang nổi lên như một bước tiến quan trọng trong lĩnh vực trí tuệ nhân tạo. Không còn dừng lại ở những tác vụ đơn giản, AI Agent được thiết kế để thực hiện các mục tiêu phức tạp, đòi hỏi khả năng lập luận, lập kế hoạch và tương tác với môi trường bên ngoài thông qua các công cụ (tool).

Khả năng

  • Lập luận (Reasoning): Các AI Agent hiện đại, đặc biệt là những agent dựa trên mô hình ngôn ngữ lớn (LLM), có khả năng suy luận logic, giải quyết vấn đề và đưa ra quyết định dựa trên thông tin đầu vào.
  • Lập kế hoạch (Planning): AI Agent có thể xây dựng kế hoạch hành động chi tiết để đạt được mục tiêu, bao gồm việc chia nhỏ mục tiêu lớn thành các nhiệm vụ nhỏ hơn, sắp xếp thứ tự thực hiện và điều chỉnh kế hoạch khi có thông tin mới.
  • Gọi công cụ (Tool Calling): Khả năng tương tác với các công cụ bên ngoài (ví dụ: API, cơ sở dữ liệu, ứng dụng) cho phép AI Agent mở rộng phạm vi hoạt động, truy cập thông tin và thực hiện các hành động trong thế giới thực.
  • Tự học và Thích ứng: Một số AI Agent có khả năng học hỏi từ kinh nghiệm, tự cải thiện hiệu suất và thích ứng với các tình huống mới.

Hạn chế

  • Phụ thuộc vào Dữ liệu Huấn luyện: Hiệu suất của AI Agent phụ thuộc rất nhiều vào chất lượng và số lượng dữ liệu huấn luyện. Dữ liệu thiên vị hoặc không đầy đủ có thể dẫn đến kết quả không chính xác hoặc không mong muốn.
  • Khả năng Giải thích (Explainability): Việc hiểu rõ quá trình ra quyết định của AI Agent, đặc biệt là các agent dựa trên mô hình học sâu (deep learning), vẫn còn là một thách thức lớn.
  • Khả năng Tổng quát hóa (Generalization): AI Agent có thể hoạt động tốt trong các tình huống đã được huấn luyện, nhưng gặp khó khăn khi đối mặt với các tình huống mới, chưa từng gặp.
  • Vấn đề về An toàn và Đạo đức: Cần có các biện pháp kiểm soát chặt chẽ để đảm bảo AI Agent hoạt động an toàn, tuân thủ các quy tắc đạo đức và không gây hại cho con người.

2. Những hiểu biết sâu sắc từ việc quan sát các hệ thống AI Agent trong thực tế

Sơ đồ phương pháp AutoGPT+P

Việc triển khai AI Agent trong các ứng dụng thực tế đã mang lại nhiều bài học quý giá:

  • Tầm quan trọng của ngữ cảnh: Hiệu suất của AI Agent phụ thuộc rất nhiều vào ngữ cảnh cụ thể của ứng dụng. Việc hiểu rõ yêu cầu, ràng buộc và mục tiêu của bài toán là yếu tố then chốt để thiết kế và triển khai AI Agent thành công.
  • Sự tương tác giữa Con người và AI Agent: Trong nhiều trường hợp, sự hợp tác giữa con người và AI Agent mang lại kết quả tốt nhất. Con người có thể cung cấp hướng dẫn, giám sát và can thiệp khi cần thiết, trong khi AI Agent đảm nhận các tác vụ lặp đi lặp lại, tốn thời gian hoặc đòi hỏi khả năng xử lý dữ liệu lớn.
  • Vòng lặp phản hồi (Feedback Loop): Việc thu thập phản hồi từ người dùng và môi trường là rất quan trọng để cải thiện hiệu suất của AI Agent. Phản hồi có thể được sử dụng để điều chỉnh kế hoạch, cập nhật kiến thức và khắc phục các lỗi sai.
  • Tính linh hoạt và khả năng mở rộng: Các hệ thống AI Agent cần được thiết kế để có thể dễ dàng thích ứng với các thay đổi trong môi trường, yêu cầu của người dùng và sự phát triển của công nghệ.

3. Những cân nhắc quan trọng cho sự phát triển AI Agent trong tương lai

Để AI Agent có thể phát huy hết tiềm năng, cần tập trung vào các khía cạnh sau:

  • Nghiên cứu về các kiến trúc AI Agent mới: Cần tiếp tục khám phá các kiến trúc AI Agent tiên tiến, kết hợp các phương pháp học máy khác nhau (ví dụ: học tăng cường, học sâu, học quy nạp) để nâng cao khả năng lập luận, lập kế hoạch và ra quyết định.
  • Phát triển các công cụ và Framework hỗ trợ: Cần có các công cụ và framework mạnh mẽ để giúp các nhà phát triển xây dựng, kiểm thử và triển khai AI Agent một cách dễ dàng và hiệu quả.
  • Tăng cường khả năng Giải thích và tính Minh bạch: Cần có các phương pháp để làm cho quá trình ra quyết định của AI Agent trở nên dễ hiểu hơn đối với con người, giúp tăng cường sự tin tưởng và chấp nhận của người dùng.
  • Đảm bảo An toàn và Đạo đức: Cần có các quy tắc, tiêu chuẩn và cơ chế kiểm soát để đảm bảo AI Agent hoạt động an toàn, không gây hại và tuân thủ các giá trị đạo đức của xã hội.
  • Nghiên cứu về tương tác giữa Con người và AI Agent: Cần hiểu rõ hơn về cách con người và AI Agent có thể hợp tác hiệu quả, tận dụng thế mạnh của cả hai bên để giải quyết các vấn đề phức tạp.

4. So sánh và đối chiếu kiến trúc Single-Agent và Multi-Agent

Có hai kiến trúc chính cho AI Agent: Single-Agent (tác tử đơn) và Multi-Agent (đa tác tử). Mỗi loại có ưu điểm và nhược điểm riêng, phù hợp với các loại bài toán khác nhau.

  • Single-Agent:
    • Ưu điểm: Đơn giản, dễ triển khai, phù hợp với các bài toán có phạm vi hẹp, yêu cầu rõ ràng.
    • Nhược điểm: Khó giải quyết các bài toán phức tạp, đòi hỏi sự phối hợp của nhiều tác tử. Khó khăn trong việc mở rộng và thích ứng với các thay đổi.
    • Ví dụ: ReAct, RAISE, Reflexion, AutoGPT + P, LATS. (Xem Hình 2 ở trang 5, Hình 3 ở trang 5, Hình 4 ở trang 6 để biết thêm chi tiết).

Một ví dụ về phương pháp ReAct so với các phương pháp khác

  • Multi-Agent:
    • Ưu điểm: Có thể giải quyết các bài toán phức tạp, đòi hỏi sự phối hợp của nhiều tác tử. Dễ dàng mở rộng và thích ứng với các thay đổi. Tăng cường khả năng phục hồi và độ tin cậy.
    • Nhược điểm: Phức tạp hơn, khó triển khai hơn. Đòi hỏi cơ chế giao tiếp và phối hợp giữa các tác tử.
    • Phân loại:
      • Kiến trúc dọc (Vertical Architectures): Có một tác tử lãnh đạo điều phối các tác tử khác.
      • Kiến trúc ngang (Horizontal Architectures): Các tác tử bình đẳng, giao tiếp trực tiếp với nhau.

 

  • Ví dụ: Embodied LLM Agents Learn to Cooperate in Organized Teams, DyLAN, AgentVerse, MetaGPT.

Đội ngũ AI Agent với trưởng nhóm được chỉ định rõ ràng sẽ có hiệu năng cao hơn.

 

Sơ đồ phương pháp AgentVerse

5. Tầm quan trọng của Reasoning, Planning và Tool Calling trong hệ thống AI Agent

Sơ đồ thể hiện phương pháp RAISE

Reasoning (lập luận), Planning (lập kế hoạch) và Tool Calling (gọi công cụ) là ba thành phần cốt lõi của một hệ thống AI Agent mạnh mẽ.

  • Reasoning: Cho phép AI Agent suy luận logic, giải quyết vấn đề và đưa ra quyết định dựa trên thông tin đầu vào.
  • Planning: Cho phép AI Agent xây dựng kế hoạch hành động chi tiết để đạt được mục tiêu.
  • Tool Calling: Cho phép AI Agent tương tác với môi trường bên ngoài, truy cập thông tin và thực hiện các hành động.

Sự kết hợp của ba thành phần này cho phép AI Agent giải quyết các bài toán phức tạp trong thế giới thực, vượt xa khả năng của các hệ thống AI truyền thống.

6. Kết luận

AI Agent đang mở ra một kỷ nguyên mới cho trí tuệ nhân tạo, với tiềm năng ứng dụng rộng rãi trong nhiều lĩnh vực. Tuy nhiên, vẫn còn nhiều thách thức cần vượt qua, bao gồm việc cải thiện khả năng lập luận, lập kế hoạch, gọi công cụ, tăng cường khả năng giải thích, đảm bảo an toàn và đạo đức, và phát triển các kiến trúc AI Agent tiên tiến. Việc giải quyết những thách thức này sẽ giúp AI Agent trở thành một công cụ mạnh mẽ, hỗ trợ con người giải quyết các vấn đề phức tạp và thúc đẩy sự phát triển của xã hội.

© 2015 - 2025 Scuti. All rights reserved.