# Prompt engineering thôi là chưa đủ

[Ysology](https://homus.dev/speakers/ysology) · [Ysology](https://homus.dev/orgs/ysology)

> Sáu lớp quanh một coding agent qua cùng một task thêm authentication: prompt, context, MCP, harness, loop, graph, và khi nào mới cần lớp tiếp theo.

Topics: Coding Agents, Context Engineering, Agents, Workflow

Canonical: https://homus.dev/talks/prompt-engineering-is-not-enough-anymore

## 1. Một coding agent thật ra làm gì, và sáu khái niệm

Video mở đầu bằng một tình huống: bạn giao cho một AI coding agent đúng một task, "add authentication to my application" (thêm authentication vào ứng dụng của tôi). Theo Ysology (video đăng ngày 28/10/2026), agent sẽ đọc code của bạn, sửa file, chạy lệnh, và khi có gì hỏng thì có khi nó còn tự sửa lỗi của chính mình.

![Hộp coding agent nối mũi tên sang một cửa sổ terminal đang gõ dở Add authentication](https://homus.dev/photos/K_hdgY-KsdU-0003.jpg)

Cảnh mở đầu: một khối "coding agent" và cửa sổ terminal nơi câu lệnh "Add authentication" đang được gõ ra. Đây là task được dùng xuyên suốt video (video đăng ngày 28/10/2026).

Câu hỏi video đặt ra: tất cả những việc đó thực sự vận hành thế nào? Và điều gì tách một AI chatbot đơn giản khỏi một hệ thống có thể build và ship phần mềm một cách đáng tin cậy? Ysology nói model đương nhiên quan trọng, nhưng phần lớn khác biệt nằm ở thứ chúng ta build xung quanh model (video đăng ngày 28/10/2026).

Theo video, có sáu khái niệm đáng hiểu: prompt engineering, context engineering, MCP, harness engineering, loop engineering và graph engineering. Video giữ nguyên task authentication đó từ đầu tới cuối và cho thấy mỗi lớp thêm vào được gì. Phần mô tả video tóm lại cùng ý: mỗi lớp lấp một khoảng trống mà lớp trước để lại (video đăng ngày 28/10/2026).

## 2. Prompt engineering: task, constraint và thế nào là xong

Khái niệm đầu tiên là prompt engineering. Ysology định nghĩa đó là việc đưa cho một AI model đúng chỉ dẫn (video đăng ngày 28/10/2026). Nhìn lại task: "add authentication". Với bạn, câu đó mang theo rất nhiều context. Với model, theo video, nó còn bỏ ngỏ hoàn toàn.

Dùng session hay token? Đăng nhập bằng mật khẩu hay "sign in with Google"? Framework nào? Code nên nằm ở đâu? Có cần test không? Theo Ysology (video đăng ngày 28/10/2026), mọi câu hỏi bạn không trả lời thì model sẽ trả lời thay bạn.

Vì vậy, thay vì chỉ bảo AI "build authentication", bạn có thể nói rõ: dùng JWT, theo đúng kiến trúc NestJS sẵn có của project, validate input và viết kèm test. Ví dụ này là của video (đăng ngày 28/10/2026). Làm vậy là bạn đang định nghĩa ba thứ:

- **Task**: việc cần làm là gì (theo video đăng ngày 28/10/2026).

- **Constraint**: những gì model phải làm và không được làm (theo video đăng ngày 28/10/2026).

- **Một kết quả tốt trông thế nào**, để model tự biết lúc nào nó đã xong (theo video đăng ngày 28/10/2026).

Ba thứ một prompt rõ ràng định nghĩa, theo Ysology, kèm ví dụ JWT/NestJS của video (video đăng ngày 28/10/2026).

Bạn có thể có một model cực kỳ giỏi, nhưng nếu chỉ dẫn mơ hồ thì vẫn có thể nhận kết quả kém. Video gói lại thành một câu: một model xuất sắc mà nhận chỉ dẫn mơ hồ thì vẫn đang đoán (video đăng ngày 28/10/2026).

## 3. Context engineering: model nhận gì, khi nào, quản lý ra sao

Tuy vậy, theo Ysology (video đăng ngày 28/10/2026), chỉ dẫn thôi chưa đủ. Prompt nói "theo đúng kiến trúc NestJS sẵn có". Nhưng kiến trúc nào? Video đặt câu hỏi từ góc nhìn của model: nó chưa từng thấy kiến trúc đó. Model còn cần đúng thông tin để làm việc, và đó là chỗ context engineering bước vào.

Ysology định nghĩa context engineering là việc quyết định model nhận thông tin gì, nhận lúc nào, và thông tin đó được quản lý ra sao trong suốt một task (video đăng ngày 28/10/2026).

![Ba nhãn what it receives, when it receives it, how it's managed bên cạnh khung context window chứa files và instructions, mũi tên sang model](https://homus.dev/photos/K_hdgY-KsdU-0203.jpg)

Bên trái là ba câu hỏi của context engineering: what it receives, when it receives it, how it's managed. Bên phải, khung "context window" đã có "instructions" và "files", và mũi tên dẫn vào model (video đăng ngày 28/10/2026).

Hãy hình dung một coding agent làm việc trong một codebase lớn. Theo video (đăng ngày 28/10/2026), nó có thể cần project instructions của bạn, các file source liên quan, tài liệu API, kết quả của những tool nó đã chạy trước đó, và ghi chú về các quyết định đã đưa ra dọc đường.

## 4. Nhiều context không có nghĩa là context tốt

Vậy sao không đưa hết cho nó? Đổ cả repository và toàn bộ lịch sử hội thoại vào model? Ysology trả lời (video đăng ngày 28/10/2026): vì context window của model có giới hạn. Và ngay cả trước khi chạm giới hạn đó, quá nhiều thông tin không liên quan có thể làm model sao nhãng. Nó chiếm dung lượng context, và làm cho những chi tiết quan trọng khó dùng hơn.

![Một khối the whole repository bên trái, khung context window trống ở giữa, model bên phải](https://homus.dev/photos/K_hdgY-KsdU-0223.jpg)

Ý tưởng "đổ cả repository vào": một khối "the whole repository" đứng cạnh khung context window và model, trước khi video giải thích vì sao cách đó không hiệu quả (video đăng ngày 28/10/2026).

Video đưa một ví dụ cụ thể: dòng duy nhất trong config nói token được ký thế nào bị chôn dưới 10.000 dòng code chẳng liên quan gì tới authentication. Câu chốt của đoạn này: more context is not better context, nhiều context hơn không phải là context tốt hơn (video đăng ngày 28/10/2026).

![Một file auth.config.ts ngắn đăng ký JwtModule, dòng signOptions expiresIn 15m được tô sáng](https://homus.dev/photos/K_hdgY-KsdU-0243.jpg)

File ví dụ `auth.config.ts` trên màn hình: `JwtModule.register` với `secret` lấy từ `process.env.JWT_SECRET`, và dòng được tô sáng `signOptions: { expiresIn: '15m' }`, chính là "một dòng" quyết định cách ký token mà video nói tới (video đăng ngày 28/10/2026).

## 5. Ba động tác: select, retrieve, summarize

Theo Ysology (video đăng ngày 28/10/2026), context engineering gồm ba động tác:

- **Select**: chọn những thông tin liên quan (theo video đăng ngày 28/10/2026).

- **Retrieve**: lấy thêm khi cần, chứ không lấy hết ngay từ đầu (theo video đăng ngày 28/10/2026).

- **Summarize** hoặc bỏ đi những gì không còn hữu ích khi task tiến triển (theo video đăng ngày 28/10/2026).

![Ba cột SELECT, RETRIEVE, SUMMARIZE · REMOVE với chú thích only what's relevant, when it's needed, what's no longer useful](https://homus.dev/photos/K_hdgY-KsdU-0303.jpg)

Ba động tác trên màn hình: SELECT (only what's relevant), RETRIEVE (when it's needed, kèm biểu tượng kính lúp) và SUMMARIZE · REMOVE (what's no longer useful), theo video đăng ngày 28/10/2026.

Áp vào task của chúng ta, video mô tả (đăng ngày 28/10/2026): agent có thể bắt đầu với project instructions của bạn, sau đó search module user đang có, chỉ đọc những file nó tìm thấy ở đó. Và khi đã vào task được một tiếng, nó giữ một bản tóm tắt ngắn về những gì đã quyết, thay vì giữ mọi bước nó đã đi qua để đi tới quyết định đó.

![Khung context window xếp từ dưới lên: project instructions, search users module, users.module.ts, users.service.ts, summary JWT guard in auth; dòng not every step it took bị gạch; nhãn an hour in](https://homus.dev/photos/K_hdgY-KsdU-0323.jpg)

Context window sau "an hour in": từ dưới lên là project instructions, kết quả "search: users module", hai file `users.module.ts` và `users.service.ts`, rồi một dòng tóm tắt "summary: JWT, guard in auth/". Dòng "not every step it took" bị gạch đỏ (video đăng ngày 28/10/2026).

Gói lại hai lớp đầu, theo video (đăng ngày 28/10/2026): prompt engineering nói cho model biết phải làm gì; context engineering quyết định model có sẵn những thông tin gì để làm việc đó.

## 6. MCP và bài toán tích hợp

Câu hỏi tiếp theo: model thật sự tương tác với tool và hệ thống bên ngoài bằng cách nào? Agent của chúng ta có thể cần xem một GitHub repository, query bảng users trong database, hoặc tìm chính sách bảo mật trong tài liệu nội bộ của công ty (ví dụ của video đăng ngày 28/10/2026).

Theo Ysology (video đăng ngày 28/10/2026), nếu không có một giao diện chuẩn, mỗi thứ đó là một integration viết riêng. Một cái cho GitHub trong ứng dụng AI này, một cái khác cho GitHub trong ứng dụng kia. Một cái cho database ở đây, một cái khác ở chỗ kia. Mỗi tool mới nhân lên với mỗi ứng dụng mới.

Bài toán integration Ysology mô tả: không có chuẩn chung thì mỗi tool mới nhân lên với mỗi ứng dụng mới; với MCP, integration được viết một lần ở phía server (video đăng ngày 28/10/2026).

## 7. Model Context Protocol: client, server, và MCP không phải là gì

Đó là lúc MCP xuất hiện. MCP là viết tắt của Model Context Protocol. Ysology mô tả nó là một open protocol chuẩn hoá cách các ứng dụng AI kết nối với tool và nguồn dữ liệu bên ngoài (video đăng ngày 28/10/2026). Trang giới thiệu chính thức của MCP gọi nó là "an open-source standard for connecting AI applications to external systems" (đọc ngày 29/10/2026).

Theo video (đăng ngày 28/10/2026), một bên là MCP server, phơi ra một số capability: một server cho GitHub, một server cho database, một server cho tài liệu. Bên kia là MCP client nằm trong ứng dụng AI, kết nối tới server đó.

Qua protocol này, client và server tương thích có thể phơi ra và khám phá capability của nhau, truy cập resource và trao đổi thông tin. Vì vậy integration chỉ cần viết một lần ở phía server, và bất kỳ ứng dụng tương thích nào cũng dùng được (theo Ysology, video đăng ngày 28/10/2026).

Hai phía của MCP theo cách Ysology kể: client trong ứng dụng AI, server phơi ra capability (video đăng ngày 28/10/2026). Trang kiến trúc chính thức mô tả thêm rằng ứng dụng (host) tạo một MCP client cho mỗi MCP server (đọc ngày 29/10/2026).

Rồi tới điểm phân biệt mà video nhấn là quan trọng (đăng ngày 28/10/2026): MCP không làm cho model thông minh hơn, và nó không tự động biến một AI thành agent. Nó cung cấp một lớp integration chuẩn mà các ứng dụng AI có thể dùng. Câu chốt của Ysology: MCP không làm model giỏi hơn, nó làm model được kết nối tốt hơn.

## 8. Harness engineering: ai thực thi hành động của model

Nhưng ngay cả khi model đã có chỉ dẫn tốt, context liên quan và quyền truy cập tool, theo Ysology (video đăng ngày 28/10/2026) vẫn còn một vấn đề. Tự bản thân một model chỉ tạo ra text. Khi nó quyết định sửa một file hay chạy một lệnh, quyết định đó chỉ là một yêu cầu. "Chạy database migration": phải có thứ gì đó thực sự làm việc này.

Vậy làm sao thực thi hành động của model, kiểm soát nơi nó được truy cập, và kiểm chứng việc nó làm là đúng? Video trả lời: đó là chỗ của harness engineering (video đăng ngày 28/10/2026).

Theo Ysology (video đăng ngày 28/10/2026), harness là hệ thống bao quanh, cho phép model vận hành bên trong một môi trường phần mềm. Nó có thể quản lý:

- việc thực thi tool (theo video đăng ngày 28/10/2026);

- permission (theo video đăng ngày 28/10/2026);

- cập nhật context (theo video đăng ngày 28/10/2026);

- quyền truy cập file và sandboxing (theo video đăng ngày 28/10/2026);

- feedback từ test hoặc các hệ thống kiểm chứng khác (theo video đăng ngày 28/10/2026).

Những gì harness có thể quản lý theo danh sách của Ysology (video đăng ngày 28/10/2026): model ở giữa chỉ đưa ra yêu cầu, harness bao quanh lo phần thực thi và kiểm soát.

## 9. Một lần đổi database schema đi qua harness

Ví dụ của video (đăng ngày 28/10/2026): agent đề xuất đổi database schema, thêm một cột password hash vào bảng users. Theo Ysology, harness có thể:

- kiểm xem hành động đó có được phép không (theo video đăng ngày 28/10/2026);

- thực thi các lệnh liên quan trong một môi trường được kiểm soát, không phải database production của bạn (theo video đăng ngày 28/10/2026);

- chạy test suite (theo video đăng ngày 28/10/2026);

- thu kết quả (theo video đăng ngày 28/10/2026);

- đưa kết quả đó ngược lại cho model (theo video đăng ngày 28/10/2026).

Đường đi của một thay đổi schema qua harness trong ví dụ của Ysology (video đăng ngày 28/10/2026): kiểm quyền, chạy ở môi trường kiểm soát, chạy test, rồi trả kết quả về cho model.

Theo video (đăng ngày 28/10/2026), harness không đơn giản là để model tự hành động; nó cung cấp hạ tầng cần thiết để kiểm soát và đánh giá những hành động đó. Ysology tóm bằng một câu: "The model proposes, the harness disposes", model đề xuất, harness quyết định.

## 10. Loop engineering: thử nhiều lần cho tới khi xong

Từ đó video sang khái niệm tiếp theo, loop engineering. Theo Ysology (video đăng ngày 28/10/2026), một model có thể sinh code trong một lần trả lời, nhưng build được phần mềm chạy đúng thường cần nhiều lần thử. Bạn không viết authentication một lần, chạy nó, rồi bỏ đi. Agent cũng vậy.

Theo video (đăng ngày 28/10/2026), một agent loop thường theo một khuôn đơn giản: nhận một goal, thực hiện một action, quan sát kết quả, quyết định làm gì tiếp.

Ví dụ của video (đăng ngày 28/10/2026): agent sửa hàm login, chạy test, phát hiện một test fail, "expected 401, received 500". Nó xem xét lỗi đó và thử một cách sửa khác.

![Vòng lặp receive a goal, take an action, observe the result, decide what next; ba mũi tên tới stopping conditions: tests pass, budget runs out, human approval](https://homus.dev/photos/K_hdgY-KsdU-0723.jpg)

Vòng agent loop bốn bước (receive a goal, take an action, observe the result, decide what next) và ba "stopping conditions" bên phải: tests pass, budget runs out (time · money · attempts) và human approval (video đăng ngày 28/10/2026).

## 11. Điều kiện dừng và trigger

Theo Ysology (video đăng ngày 28/10/2026), chu kỳ này tiếp diễn cho tới khi chạm một điều kiện dừng: test pass; ngân sách cho phép cạn, dù là thời gian, tiền hay số lần thử; hoặc bước tiếp theo cần con người phê duyệt.

Video nói phần cuối này quan trọng hơn ta tưởng (đăng ngày 28/10/2026). Một agent không bao giờ dừng có thể cứ sửa mãi cùng một test đang fail, viết đi viết lại cùng một hàm.

Theo Ysology (video đăng ngày 28/10/2026), loop engineering tập trung vào việc thiết kế những chu kỳ lặp đó và các điều kiện chi phối chúng. Nó cũng có thể bao gồm các trigger tự khởi động công việc. Một GitHub issue mới có thể kích hoạt một agent đi điều tra bug. Một scheduled job có thể yêu cầu một agent tạo báo cáo mỗi sáng.

Hai ví dụ trigger Ysology đưa ra (video đăng ngày 28/10/2026): một GitHub issue mới và một scheduled job, mỗi cái khởi động một agent loop, thay vì developer tự tay prompt model ở từng bước.

Thay vì developer phải tự tay prompt model ở từng bước, theo video (đăng ngày 28/10/2026), hệ thống có thể khởi động và duy trì workflow theo những quy tắc định sẵn.

## 12. Graph engineering: chia việc cho nhiều agent

Nhưng chuyện gì xảy ra khi một agent là không đủ? Câu hỏi đó dẫn tới graph engineering. Theo Ysology (video đăng ngày 28/10/2026), graph engineering là tổ chức task, agent và các phụ thuộc thành một graph, thay vì coi mọi thứ là một đường thẳng hay một chuỗi tuần tự.

Video lấy lại task authentication (đăng ngày 28/10/2026). Một agent có thể xem codebase hiện có. Một agent khác phân tích yêu cầu và liệt kê từng trường hợp: token hết hạn, tài khoản bị khoá, đặt lại mật khẩu. Hai việc này không phụ thuộc nhau, nên có thể chạy cùng lúc.

Khi cả hai xong, kết quả của chúng được chuyển cho một agent implementation. Agent này phải chờ, nó không thể bắt đầu khi chưa có hai kết quả đó. Sau bước implementation, các agent riêng có thể review code và phân tích test fail. Và nếu review tìm ra vấn đề, workflow có thể quay ngược về agent implementation (theo video đăng ngày 28/10/2026).

![Graph: inspect codebase và analyze requirements cùng trỏ vào implement; implement trỏ ra review code và analyze test failures; mũi tên đỏ từ review code quay về implement](https://homus.dev/photos/K_hdgY-KsdU-0903.jpg)

Graph của task authentication trên màn hình: "inspect codebase" và "analyze requirements" chạy song song rồi cùng đổ vào "implement"; từ đó sang "review code" và "analyze test failures", với mũi tên đỏ từ review quay lại implement (video đăng ngày 28/10/2026).

Theo Ysology (video đăng ngày 28/10/2026), có task chạy song song, có task phải chờ những task nó phụ thuộc làm xong. Graph định nghĩa các task nối với nhau ra sao, thông tin chảy đi đâu, và bước nào phụ thuộc bước nào.

## 13. Cái giá của nhiều agent

Theo video (đăng ngày 28/10/2026), cách này có thể làm workflow phức tạp dễ quản lý hơn, nhưng nó cũng kéo theo chi phí điều phối (coordination overhead), thêm các lần gọi model, và thêm nhiều chỗ để hỏng. Mỗi lần bàn giao giữa các agent là một chỗ thông tin có thể bị rơi mất.

Hai mặt của graph engineering theo Ysology (video đăng ngày 28/10/2026): dễ quản lý hơn và chạy song song được, đổi lại là chi phí điều phối, thêm lần gọi model và thêm chỗ để hỏng.

Vì thế, theo Ysology (video đăng ngày 28/10/2026), graph engineering không phải là dùng càng nhiều agent càng tốt. Nó là chia việc ở những chỗ mà việc chia đó mang lại lợi thế thật.

## 14. Sáu lớp ghép lại thành một stack

Đây là cách sáu khái niệm khớp với nhau, theo Ysology (video đăng ngày 28/10/2026):

- Prompt engineering định nghĩa chỉ dẫn (theo video đăng ngày 28/10/2026).

- Context engineering cung cấp thông tin liên quan (theo video đăng ngày 28/10/2026).

- MCP kết nối ứng dụng AI với các capability bên ngoài (theo video đăng ngày 28/10/2026).

- Harness engineering cung cấp hạ tầng thực thi và kiểm soát (theo video đăng ngày 28/10/2026).

- Loop engineering cho phép hành động lặp lại và nhận feedback (theo video đăng ngày 28/10/2026).

- Graph engineering điều phối nhiều task hoặc nhiều agent thành workflow lớn hơn (theo video đăng ngày 28/10/2026).

![Sáu hàng màu với tiêu đề not entirely new: Prompt engineering defines the instructions, Context engineering supplies the relevant information, MCP connects to external capabilities, Harness engineering executes and controls, Loop engineering repeats action and feedback, Graph engineering coordinates tasks and agents](https://homus.dev/photos/K_hdgY-KsdU-1003.jpg)

Cả stack trên một màn hình, dưới dòng chữ "not entirely new": mỗi hàng là một lớp kèm vai trò của nó, từ "defines the instructions" tới "coordinates tasks and agents" (video đăng ngày 28/10/2026).

Theo Ysology (video đăng ngày 28/10/2026), không cái nào trong số này là phát minh hoàn toàn mới. Kỹ sư phần mềm đã làm việc với protocol, runtime, feedback loop và dependency graph hàng chục năm nay. Điều đang thay đổi là cách chúng ta áp những ý tưởng đó vào một hệ thống mà một số quyết định và hành động được giao cho AI model.

## 15. Bắt đầu từ đâu

Và theo video (đăng ngày 28/10/2026), bạn không cần cả sáu lớp cho mọi project. Bạn không cần một kiến trúc multi-agent phức tạp để tóm tắt một tài liệu. Một prompt đơn giản và một lần gọi model có thể là tất cả những gì bạn cần.

![Stack sáu lớp với chỉ hàng Prompt engineering sáng, ghi a simple prompt; bên dưới là câu summarize a document?](https://homus.dev/photos/K_hdgY-KsdU-1023.jpg)

Với câu hỏi "summarize a document?", chỉ hàng Prompt engineering còn sáng, ghi "a simple prompt"; năm lớp còn lại mờ đi (video đăng ngày 28/10/2026).

Lời khuyên của Ysology (video đăng ngày 28/10/2026): bắt đầu từ đỉnh stack và chỉ đi xuống tiếp khi bạn đụng tường.

- Kết quả mơ hồ: sửa prompt (theo video đăng ngày 28/10/2026).

- Thiếu thông tin: sửa context (theo video đăng ngày 28/10/2026).

- Không với tới một hệ thống: kết nối nó (theo video đăng ngày 28/10/2026).

- Hành động không an toàn hoặc chưa được kiểm chứng: build harness (theo video đăng ngày 28/10/2026).

- Một lần thử là không đủ: thêm loop (theo video đăng ngày 28/10/2026).

- Một agent không gánh nổi tất cả: chỉ đến lúc đó mới vẽ graph (theo video đăng ngày 28/10/2026).

![Stack sáu lớp với mũi tên start here từ trên xuống; các hàng ghi Vague results fix the prompt, Missing information fix the context, Can't reach a system connect it, Unsafe or unverified build the harness](https://homus.dev/photos/K_hdgY-KsdU-1043.jpg)

Mũi tên "start here" chạy từ trên xuống, mỗi lớp ghép với một triệu chứng và cách xử lý: "Vague results? fix the prompt", "Missing information? fix the context", "Can't reach a system? connect it", "Unsafe or unverified? build the harness"; hai lớp loop và graph chưa sáng lên ở thời điểm này (video đăng ngày 28/10/2026).

Theo Ysology (video đăng ngày 28/10/2026), khi ứng dụng AI của bạn ngày càng có năng lực hơn, những khái niệm này giúp bạn đi xa hơn việc chỉ yêu cầu một model viết code, và bắt đầu thiết kế những hệ thống thực sự làm xong việc.

![Sáu vòng tròn đồng tâm nhiều màu quanh biểu tượng model, mỗi vòng có một icon; dòng chữ Engineering systems that get work done](https://homus.dev/photos/K_hdgY-KsdU-1103.jpg)

Khung kết: sáu vòng tròn đồng tâm, mỗi vòng một lớp với icon riêng, bao quanh model ở giữa, và dòng chữ "Engineering systems that get work done." (video đăng ngày 28/10/2026).

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

- Tên gốc: Prompt Engineering Is Not Enough Anymore
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=K_hdgY-KsdU](https://www.youtube.com/watch?v=K_hdgY-KsdU)

- Kênh YouTube Ysology (Ysology): [youtube.com/channel/UCpuxg2VmKqGjfCVFXRIgg_w](https://www.youtube.com/channel/UCpuxg2VmKqGjfCVFXRIgg_w)

- Model Context Protocol, trang giới thiệu chính thức ("an open-source standard for connecting AI applications to external systems", đọc ngày 29/10/2026): [modelcontextprotocol.io/docs/getting-started/intro](https://modelcontextprotocol.io/docs/getting-started/intro)

- Model Context Protocol, trang kiến trúc (host, client, server; mỗi MCP server có một MCP client riêng, đọc ngày 29/10/2026): [modelcontextprotocol.io/docs/learn/architecture](https://modelcontextprotocol.io/docs/learn/architecture)

Nguồn: https://homus.dev/talks/prompt-engineering-is-not-enough-anymore · cập nhật 2026-10-29