# Agentic engineering: 5 thuật ngữ mọi AI developer nên biết

[Cedric Clyburn](https://homus.dev/speakers/cedric-clyburn) · [IBM Technology](https://homus.dev/orgs/ibm-technology)

> Cedric Clyburn giải thích prompt, context, harness, loop/graph engineering và software factory, từ model nhỏ tới nhiều agent song song.

Topics: Agents, Context Engineering, Workflow, Software Factory

Canonical: https://homus.dev/talks/agentic-engineering-5-terms-every-ai-developer-should-know

## 1. Viết phần mềm mà không phải tự viết code

Cedric Clyburn, Sr. Developer Advocate tại Red Hat, mở đầu video trong series "think" của IBM Technology bằng một lời mời tưởng tượng: hãy hình dung bạn là một software developer mà không phải viết dòng code nào. Nghe thật dễ chịu, anh nói.

![Cedric Clyburn đứng trước nền đen, chú thích tên và chức danh Sr. Developer Advocate, Red Hat](https://homus.dev/photos/SIZsFGvtClM-0003.jpg)

Cedric Clyburn, Sr. Developer Advocate tại Red Hat, trong series "think" của IBM (video đăng ngày 26/10/2026).

Theo Cedric (video đăng ngày 26/10/2026), với các team ở những công ty search engine và music streaming phổ biến, đó đã là thực tế: 80% hoặc hơn số code của họ được viết bởi AI và bởi những AI coding assistant mới. Anh gọi con số đó là đáng kinh ngạc, nhưng nhấn mạnh rằng đó là thực tế.

Thực tế ấy đi cùng sự lên ngôi của các cách làm phần mềm có AI hỗ trợ (AI-assisted development), và của thứ được gọi là **agentic engineering**. Câu hỏi đặt ra là nó vận hành thế nào và bạn cần biết gì. Trong vài phút tiếp theo, Cedric muốn giải thích năm thuật ngữ mà anh cho là quan trọng nhất để build và dùng AI model, kèm ví dụ và best practice, để bạn tận dụng AI giống như những team hàng đầu kia (video đăng ngày 26/10/2026). Anh đi từ cơ bản rồi đi lên dần.

![Bảng đen với chữ 80% cạnh hình robot, chữ AGENTIC ENGINEERING và số 5 khoanh tròn](https://homus.dev/photos/SIZsFGvtClM-0043.jpg)

Cedric viết lên bảng con số 80% kèm hình một robot, cụm từ "AGENTIC ENGINEERING", và khoanh số 5 cho năm thuật ngữ sẽ nói tới (video đăng ngày 26/10/2026).

## 2. Prompt engineering: soạn đúng chỉ dẫn cho model

Thuật ngữ đầu tiên trong danh sách của Cedric (video đăng ngày 26/10/2026) là thứ có lẽ bạn đã nghe: **prompt engineering**. Anh định nghĩa đó là việc soạn ra đúng những chỉ dẫn (instructions) để model làm theo.

Chỉ dẫn kiểu gì? Anh lấy hai ví dụ: "hey, bạn là một chuyên viên technical support", hoặc một câu như "chỉ trả lời dựa trên tài liệu được cung cấp".

```
You're a technical support specialist.
Only answer based on the provided documentation.
```

![Bảng ghi Prompt Engineering, Crafting Instructions, câu answer based on documentation, hình robot và chữ A cộng, chữ Communicate](https://homus.dev/photos/SIZsFGvtClM-0143.jpg)

Trên bảng: tiêu đề "Prompt Engineering", dòng "Crafting Instructions", ví dụ "answer based on documentation", một robot cạnh điểm A+ tượng trưng cho model rất giỏi, và chữ "Communicate" (video đăng ngày 26/10/2026).

## 3. Giao tiếp và domain expertise quan trọng hơn chính model

Điều có thể bạn chưa biết, theo Cedric (video đăng ngày 26/10/2026): kể cả khi bạn có một LLM cực kỳ mạnh, anh nói là loại frontier nhất, model được chấm điểm cao nhất, thì việc biết cách giao tiếp, giải thích được bạn muốn gì từ model và model nên làm gì cho bạn, vẫn quan trọng hơn bản thân model.

Và đi kèm khả năng giao tiếp ấy là nhu cầu về **domain expertise** (trên bảng anh viết tắt "D.E."), tức chuyên môn trong lĩnh vực bạn đang làm, dù đó là lĩnh vực gì. Theo Cedric (video đăng ngày 26/10/2026), nhiều người nghĩ "mình phải là developer mới dùng được các model này". Không hẳn, anh nói, nhưng bạn cần có kinh nghiệm trong chính việc bạn đang nhờ model làm.

Để giao tiếp cho tốt khi làm prompt engineering, một số người dùng microphone: họ có thể nói vài phút liền với LLM bằng dictation (đọc chính tả). Theo Cedric (video đăng ngày 26/10/2026), cách này hiệu quả một cách ngoạn mục, vì các model tiên tiến thật sự có khả năng nắm được bạn đang muốn làm gì. Trên bảng, anh vẽ một chiếc microphone cạnh dòng "Communicate + D.E.".

## 4. Model nhỏ: few-shot prompt và chain of thought

Tiếp theo, Cedric nói về các model nhỏ hơn: model chạy local hoặc ở edge, thậm chí trên điện thoại di động, như anh mô tả trong video đăng ngày 26/10/2026. Với prompt engineering cho các model nhỏ này, điều anh thường thấy là đưa ví dụ dạng **few-shot prompt**: những cặp câu hỏi và câu trả lời mà bạn muốn model bắt chước theo.

Bạn đưa các ví dụ ấy (gọi là few-shot prompting) cùng với prompt bạn muốn giao cho model, kiểu "hey, tôi muốn bạn giải bài này" hoặc "lấy thông tin user mới này và đưa ra phản hồi". Bạn còn có thể đưa thêm cái gọi là ví dụ **chain of thought** (trên bảng viết tắt CoT). Theo Cedric (video đăng ngày 26/10/2026), chain of thought tạo khác biệt rất lớn khi bạn lấy phản hồi từ một LLM cỡ nhỏ, loại bạn có thể chạy ngay trên laptop hay smartphone.

![Bảng prompt engineering hoàn chỉnh với ô Q + A ba dòng, dấu cộng, một prompt trong ngoặc kép, ô CoT và hình điện thoại](https://homus.dev/photos/SIZsFGvtClM-0303.jpg)

Phần dưới bảng: một ô ba dòng "Q + A" (ví dụ few-shot), cộng với prompt chính trong ngoặc kép, cộng với ô "CoT" cho chain of thought; phía trên là hình một chiếc điện thoại tượng trưng cho model nhỏ chạy trên thiết bị (video đăng ngày 26/10/2026).

Vậy tuỳ loại model bạn định dùng, chỉ dẫn của bạn có thể khác đi một chút. Nhưng rốt cuộc, Cedric nói với người xem (video đăng ngày 26/10/2026), tất cả là chuyện giao tiếp.

## 5. Context engineering: mọi thứ model nhìn thấy

Nhưng model không chỉ nhìn thấy chỉ dẫn bạn đưa, và đó là lúc **context engineering** vào cuộc. Cedric muốn bạn nghĩ về mọi thứ model đang thấy trong context window của nó. Theo danh sách anh đưa ra (video đăng ngày 26/10/2026), trong đó có system prompt, kiểu "đây là việc model phải làm cho use case này"; có tools, MCP server và skill được nạp vào; có PDF và thông tin kéo vào qua retrieval augmented generation (RAG) để trả lời câu hỏi về một chủ đề; và với coding agent, cả codebase của bạn cũng được thêm vào context window.

![Bảng ghi Context Engineering và một thanh dài chia ô: dòng chữ, nét vẽ đỏ, tài liệu, ký hiệu code](https://homus.dev/photos/SIZsFGvtClM-0403.jpg)

Cedric vẽ context window thành một thanh dài chia ô: các ô lần lượt tượng trưng cho system prompt, tools, tài liệu và code, phần cuối còn trống (video đăng ngày 26/10/2026).

Và điều cần nhớ, theo Cedric (video đăng ngày 26/10/2026): kể cả khi model có context window rất lớn, chất lượng sẽ giảm đi ngay cả trước khi bạn chạm tới giới hạn được quảng cáo.

## 6. Compact, summarize và sub-agent

Đó là lý do bạn thấy các kỹ thuật như compact (compacting) hay summarize nội dung context window thành một prompt mới, sạch cho model. Ví dụ Cedric đưa ra (video đăng ngày 26/10/2026): tóm các hoạt động đã diễn ra trong cuộc hội thoại với model vào một phần nhỏ hơn, rồi chuyển phần đó sang một prompt mới tinh. Đây là những cách quản lý context window.

Bạn cũng sẽ thường thấy **sub-agent** được dùng. Theo Cedric (video đăng ngày 26/10/2026), sub-agent cho phép làm những việc như research, xem xét một thư viện hay đọc tài liệu mà không thêm bao nhiêu vào context window gốc. Các sub-agent này thường nhỏ hơn và có mục đích cụ thể hơn; khi làm xong, chúng đưa thông tin trở lại context window và giúp ta tiết kiệm một chút "chỗ chứa" (anh dùng chữ storage) trong lúc làm việc. Đó là toàn bộ ý của context engineering.

![Bảng Context Engineering: thanh context window, mũi tên xuống chữ Summarize, một thanh ngắn hơn và hai ô subagent](https://homus.dev/photos/SIZsFGvtClM-0523.jpg)

Bảng context engineering hoàn chỉnh: từ context window đầy, một mũi tên dẫn tới "Summarize" và một thanh mới chỉ còn phần tóm tắt; bên dưới là hai ô "subagent" tách việc ra khỏi context chính (video đăng ngày 26/10/2026).

## 7. Harness engineering: mọi thứ bao quanh model

Dù context window được quản lý tốt, Cedric cho rằng bạn có lẽ vẫn nhận ra còn thiếu gì đó (video đăng ngày 26/10/2026). Với đủ thông tin liên quan, một LLM cực kỳ mạnh sẽ đưa ra được câu trả lời rất chính xác. Nhưng làm sao biết câu trả lời đó thật sự chạy được?

Đó chính là toàn bộ ý tưởng của **harness engineering**. Định nghĩa của Cedric (video đăng ngày 26/10/2026): harness là mọi thứ bao quanh model, cho phép nó hành động, rồi kiểm chứng việc nó vừa làm, và tiếp tục nhận output, input quay trở lại. Đó là runtime thật sự thực thi lệnh bạn muốn, chẳng hạn sửa file bằng tools.

Harness cũng quản lý context window. Giả sử ta làm quá tải context window ban đầu, thì làm sao vẫn giữ được cùng memory, cùng prompt và cùng quá trình thực thi? Đồng thời, ta muốn có sandbox, vì ta không muốn LLM được làm mọi thứ trên máy tính của mình. Theo Cedric (video đăng ngày 26/10/2026), harness cung cấp được những khả năng đó, cộng với orchestration, tức điều phối các sub-agent đã nói ở phần trước.

![Bảng Harness Engineering: ô LLM và ô HARNESS nối bằng mũi tên vòng, danh sách Tools, Context, Sandbox, Orchestration, dòng Did tests pass](https://homus.dev/photos/SIZsFGvtClM-0643.jpg)

Bên trái bảng: ô "LLM" và ô "HARNESS" nối với nhau bằng mũi tên hai chiều, cạnh đó là bốn mục Tools, Context, Sandbox, Orchestration, và câu hỏi "Did tests pass?"; bên phải vẫn còn sơ đồ context engineering (video đăng ngày 26/10/2026).

## 8. Feedback để agent tự lặp

Như Cedric mô tả (video đăng ngày 26/10/2026), harness là thứ cho phép ta tương tác với chính máy của mình, và cũng là thứ báo lại cho model. Ví dụ: khi ta dùng tool đó, test suite có pass sau thay đổi model đề xuất không? Hay: khi đưa code đó trở lại repository, giờ có merge conflict không? Trên bảng, anh ghi hai câu "Did tests pass?" và "Conflict?".

Chính feedback này cho phép một agent tự lặp lại (iterate) thay vì bạn phải approve từng bước. Theo Cedric (video đăng ngày 26/10/2026), phần lớn các AI harness ngoài kia đã kết nối với các tool và tiện ích như CI pipeline, observability stack và mọi thành phần bạn đang có sẵn.

Vòng feedback theo cách Cedric giải thích: model đề xuất thay đổi, harness chạy nó qua tools, rồi trả về kết quả như test có pass không, có merge conflict không, để agent tự lặp tiếp (video đăng ngày 26/10/2026).

## 9. Agent loop: một AI agent thực chất là gì

Bạn có thể cũng đã nghe nói về loop và **loop engineering**. Use case rõ nhất mà Cedric đưa ra là chính agent loop (video đăng ngày 26/10/2026). Bắt đầu từ một goal ban đầu (nhiều người chỉ đơn giản dùng prompt), loop cho phép agent hành động (act) bằng đủ loại tools, quan sát (observe) output, và tại điểm đó quyết định (decide) đó là thành công hay tiếp tục vòng lặp.

Và theo Cedric (video đăng ngày 26/10/2026), về cơ bản một AI agent chỉ là thế: vòng lặp này cứ tiếp diễn mãi.

![Bảng Loop Engineering: chữ Trigger chỉ vào ô Goal, vòng Goal, Act, Observe, Decide và chữ AI AGENT màu đỏ](https://homus.dev/photos/SIZsFGvtClM-0803.jpg)

Goal, Act, Observe, Decide nối thành vòng tròn, dưới ghi "AI AGENT"; chữ "Trigger" được thêm vào phía trên, chỉ vào Goal (video đăng ngày 26/10/2026).

## 10. Loop engineering: trigger thay cho người prompt

Rồi tới ý tưởng loop engineering. Theo Cedric (video đăng ngày 26/10/2026), thay vì một con người như bạn hay anh liên tục prompt agent, ta gắn vào đó một trigger. Trigger có thể là bất kỳ thứ gì:

- Mỗi sáng lúc 9 giờ, thứ được gọi là cron job.

- Ai đó mở một pull request trong repository.

- Một issue được tạo về một bug, hoặc một alert.

Loop engineering, theo định nghĩa của Cedric (video đăng ngày 26/10/2026), chỉ có nghĩa là thứ ta đang build là một hệ thống điều phối các agent cho bạn, hướng tới goal đã định.

Anh nói thêm rằng thường có một human in the loop để approve các thay đổi xảy ra. Bạn có thể đặt điểm duyệt đó sau khi agent đã bắt đầu hành động và dùng tools, hoặc sau khi nó đã quan sát output. Như vậy bạn cũng kiểm được những gì đang diễn ra trong workflow, và làm việc cùng agent để ship phần mềm hiệu quả hơn, chất lượng cao hơn và nhanh hơn, theo lời Cedric trong video đăng ngày 26/10/2026. Trên bảng, lúc này xuất hiện hai ký hiệu nhỏ màu đỏ, một trên mũi tên sau Act, một trên mũi tên sau Observe.

Loop engineering theo ba ví dụ trigger Cedric nêu (cron job 9 giờ sáng, pull request, issue hoặc alert), và hai chỗ có thể đặt human in the loop: sau bước Act hoặc sau bước Observe (video đăng ngày 26/10/2026).

## 11. Graph engineering: nhiều agent chạy song song

Bây giờ bạn có nhiều agent làm được việc này, và từ đó có khái niệm **graph engineering**. Theo Cedric (video đăng ngày 26/10/2026), graph engineering là lấy cùng khái niệm loop nhưng nối song song nhiều agent với nhau. Từ một goal, một điểm bắt đầu hay một trigger, ta có thể có hai sub-agent: một làm market research, một tìm hiểu repository được tổ chức ra sao. Hai sub-agent này chuyển kết quả cho một agent sẽ thực sự implement.

![Dưới sơ đồ loop là một nhánh: ô Goal tách thành hai ô, một ô hình bóng đèn và một ô ký hiệu code, cả hai dồn vào ô thứ ba](https://homus.dev/photos/SIZsFGvtClM-0923.jpg)

Bên dưới sơ đồ loop, Cedric vẽ một graph nhỏ: ô "Goal" tách thành hai nhánh song song (một ô hình bóng đèn, một ô ký hiệu code), cả hai dồn vào một ô thứ ba, tượng trưng cho agent implement (video đăng ngày 26/10/2026).

Như vậy ta lấy ý tưởng loop rồi rẽ nhánh ra thành đủ loại cấu trúc graph. Nhưng, theo Cedric (video đăng ngày 26/10/2026), trừ khi bạn có token không giới hạn, bạn sẽ thấy cách triển khai này có thể khá tốn kém. Vì thế bạn không phải lúc nào cũng làm vậy, nhưng đó là khái niệm loop engineering và graph engineering.

## 12. Software factory: isolation, identity, observability

Cuối cùng là thứ được gọi là **software factory**. Theo định nghĩa của Cedric (video đăng ngày 26/10/2026), đó là tự động hoá vòng đời phát triển phần mềm (software development lifecycle) bằng AI agent: dựng những pipeline vững chắc cho các việc phát triển phần mềm truyền thống như quản lý task, implement code hay testing, việc gì cũng được.

Thay vì chỉ có một agent đa năng cố gắng xử lý mọi thứ, software factory dùng các agent riêng, mỗi agent cho một task. Theo Cedric (video đăng ngày 26/10/2026), mỗi agent đó cần ba thành phần:

- **Isolation**: cô lập, bằng container hay sandbox hay bất cứ thứ gì phù hợp (theo Cedric, video đăng ngày 26/10/2026).

- **Identity**: agent là ai và được truy cập những gì, ví dụ với Git hay với môi trường cloud của ta (theo Cedric, video đăng ngày 26/10/2026).

- **Observability**: trong lúc agent làm việc, nếu đêm qua chúng chạy lúc 3 giờ sáng, ta phải trace lại được mọi thứ một agent trong factory đã làm (theo Cedric, video đăng ngày 26/10/2026).

![Bảng Software Factory: hình nhà máy có ba ô bên trong, một người bên trái, cạnh đó ghi Isolation và Identity](https://homus.dev/photos/SIZsFGvtClM-1023.jpg)

Cedric vẽ software factory thành một nhà máy chứa ba agent riêng, một người đứng bên cạnh, và liệt kê các thành phần mỗi agent cần, lúc này mới có "Isolation" và "Identity" (video đăng ngày 26/10/2026).

Theo Cedric (video đăng ngày 26/10/2026), nhiều team đang bắt đầu dựng những AI software factory như vậy, và khi model ngày càng tốt hơn, anh thấy chuyện này sẽ chỉ ngày càng phổ biến.

## 13. Ý tưởng cũ được làm mới, và ai cần biết gì

Vậy là năm thuật ngữ. Nếu bạn đã làm kỹ sư, Cedric nói, bạn sẽ nhận ra đây không hẳn là những ý tưởng mới. Graph, feedback loop, distributed system đều là những thực hành điện toán đã có, chỉ là giờ chúng đang được tái phát minh, theo nhận định của anh trong video đăng ngày 26/10/2026.

![Cedric đứng giữa bảng, quanh anh là các chữ Feedback Loops, Graphs, Distributed Systems và sơ đồ Software Factory với Isolation, Identity, Observe](https://homus.dev/photos/SIZsFGvtClM-1103.jpg)

Phần kết: sơ đồ software factory nay có đủ Isolation, Identity, Observe, và quanh Cedric là ba cụm "Feedback Loops", "Graphs", "Distributed Systems", những ý tưởng điện toán cũ mà anh nói đang được làm mới (video đăng ngày 26/10/2026).

Nhưng anh nhấn mạnh: bạn không cần là chuyên gia ở tất cả những thứ này. Theo Cedric (video đăng ngày 26/10/2026), nếu bạn chỉ là một solo developer, bạn không cần một software factory. Còn những khái niệm như prompt, context window và harness engineering thì áp dụng cho tất cả mọi người, dù bạn là sinh viên, designer, manager hay bất kỳ ai.

Cedric kết video bằng lời mong mọi người đã học được điều gì đó hôm nay, và một tiếng "Cheers".

## Nguồn và liên kết

- Tên gốc: Agentic Engineering: 5 Terms Every AI Developer Should Know
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=SIZsFGvtClM](https://www.youtube.com/watch?v=SIZsFGvtClM)

- Kênh YouTube IBM Technology (Cedric Clyburn): [youtube.com/channel/UCKWaEZ-_VweaEx1j62do_vQ](https://www.youtube.com/channel/UCKWaEZ-_VweaEx1j62do_vQ)

Nguồn: https://homus.dev/talks/agentic-engineering-5-terms-every-ai-developer-should-know · cập nhật 2026-10-26