Từ Coding Agent đến Nhân viên số: Ứng dụng AI đang hội tụ về cùng một kiến trúc hệ thống

Đi qua các gian hàng sản phẩm Agent tại Hội nghị Yunqi, điều gây bất ngờ nhất chính là: tuy thuộc những ngành hoàn toàn khác biệt, chúng lại phát triển chung một hệ điều hành.

Qoder phụ trách phát triển phần mềm, QwenWork đảm năng công việc tri thức, TinyFish vận hành Web Browser Agent, WonderClip sản xuất video, còn OpenSearch thực hiện tìm kiếm và Research.

Bỏ qua yếu tố ngành cụ thể, cấu trúc nền tảng của chúng đang hội tụ đáng kể:

Bối cảnh → Hoạch định → Kỹ năng → Thực thi → Xác minh → Trí nhớ → Kết quả kinh doanh
(Context → Planning → Skill → Execution → Verification → Memory → Business Outcome)

Đây chính là kiến trúc hệ thống chung mà các sản phẩm Agent đang hướng tới.

Agent 核心已从”会回答”转向”能持续执行”

⚠ Bài viết này lấy hệ sinh thái Alibaba Cloud (Qoder/QwenWork/TinyFish/WonderClip/OpenSearch) làm case study thực tế. Tuy nhiên, các phán đoán kiến trúc dưới đây cũng hoàn toàn áp dụng cho nền tảng Agent tự xây dựng, Huawei Cloud, AWS, Azure, GCP — bảy tầng stack là sự hội tụ về cấu trúc công nghiệp, không phải kết luận độc quyền của bất kỳ nhà cung cấp đám mây nào.

一、Agent 的核心已经从”会回答”转向”能持续执行”

Chatbot 时代,系统的基本循环很简单:用户输入,模型输出。

Agent 时代,任务会持续几分钟、几小时甚至更长。它需要读取文件、使用浏览器、调用 API、执行代码、等待异步任务、检查结果、失败重试、保存状态。

一个 Prompt 加一个模型,装不下这些。

系统必须开始拥有 Runtime。

Nhiệm vụ Legal Document Fill Out được trình diễn tại chỗ bởi QwenWork rất mang tính đại diện: nó chạy trong Sandbox Container độc lập, Agent sở hữu desktop ảo và có thể gọi các công cụ xử lý tài liệu. Marketing Content Generation còn phổ rộng thêm nhiều công cụ khác nhau như PPT, hình ảnh, Lip Sync, Python, Pillow, FFmpeg.

Môi trường thực thi của Agent ngày càng tiệm cận một chiếc máy tính có thể lập trình được — một đơn vị công việc được bảo vệ bởi sandbox, có khả năng gọi nhiều runtime và công cụ, có thể thực thi các tác vụ liên tục mà không bị gián đoạn. Sandbox Container cung cấp sự cô lập, desktop ảo cung cấp khả năng thao tác trực quan trên giao diện đồ họa, còn tool calling giúp mô hình chuyển từ “nói” sang “làm”. Chỉ khi sự kết hợp này ổn định, Agent mới thực sự bắt đầu thay thế mặt hoạt động của con người, chứ không chỉ đơn thuần thay thế mặt tư duy.

Hai, “One Foundation” của Qoder là tín hiệu sản phẩm, không phải khẩu hiệu

Trên biển triển lãm của Qoder có dòng chữ:

One workbench. Four entries. One foundation.

上面承载着 Workbench、CLI、IDE、JetBrains Plugin，还可以继续扩展 Cloud Agents、Agent SDK。

但真正值得关注的，是底层那一套共享的 Foundation。

如果每种入口都重新实现一套 Agent，系统会迅速失控。更合理的做法是将任务调度、权限、工具、Sandbox、Memory、Model Router、Verification 等能力封装为共用 Harness。

入口只负责适配不同用户和不同场景：CLI 给程序员、IDE 给开发者、Workbench 给非技术人员、JetBrains 给存量代码迁移场景、Cloud Agents 面向异步触发、Agent SDK 面向第三方集成。底层的调度、记忆、工具网关、验证、安全模型则共用同一套。

Giá trị của việc tái sử dụng này còn lớn hơn những gì bề ngoài có thể thấy. Trong một tổ chức, kinh nghiệm thiết kế Sandbox, kinh nghiệm thiết kế Permission, và kinh nghiệm Recovery từ Coding Agent có thể chuyển trực tiếp sang Browser Agent, Content Agent, hay Ops Agent. Đắt nhất của việc đẽo cày không phải là chi phí phát triển, mà là thảm họa quản trị do các Agent thể hiện không nhất quán khi xảy ra sự cố — cùng một đoạn code, sửa được ở IDE Agent, sửa được ở CLI Agent, nhưng Permission Model khác nhau, định dạng nhật ký kiểm toán khác nhau, khi có chuyện thì hoàn toàn không thể truy vết.

Ba. Một Agent Stack phổ quát có ít nhất bảy tầng — cùng bản đồ đầu tư “tự xây / dùng chung / chưa rõ ràng” cho từng tầng

Sau khi trừu tượng hóa những nội dung trên, tôi đã phân tách Agent Stack thành bảy tầng. Bảng dưới đây đồng thời giải đáp câu hỏi thực tiễn nhất cho một tổ chức: tầng nào nên tự xây, tầng nào có thể dùng chung từ mã nguồn mở hoặc mua sẵn, tầng nào vẫn chưa thể kết luận.

Lớp	Nội dung	Đánh giá đầu tư (quan sát thực địa 2026)
1. Entry Điểm tiếp cận	Web / CLI / IDE / IM / API / GitHub Issue / Bảng điều khiển doanh nghiệp	Lớp thích ứng, không tự xây — Chọn hình thức tiếp cận phù hợp nhất với người dùng mục tiêu
2. Task Công việc	Goal / Spec / Context / Acceptance / Priority / Budget	Tự xây, nhưng mỏng — Đây là hợp đồng Task, mô tả kém thì toàn bộ hệ thống phía sau sẽ rối loạn
3. Context & Memory Ngữ cảnh và Bộ nhớ	Kiến thức doanh nghiệp, kiến thức code, lịch sử tác vụ, quyết định, sở thích người dùng, trạng thái hiện tại	Bắt buộc tự xây — Context là tài sản của tổ chức, không mua được
4. Planning & Skill Lập kế hoạch & Kỹ năng	Tách nhỏ công việc, chọn Skill, chọn model, chiến lược song song	Skill tự xây, Planning có thể nhờ bên ngoài — Skill là con đường hào môn

| 5. Runtime & Tools | Shell / Browser / Computer Use / Filesystem / Git / Database / MCP / API doanh nghiệp | Bán tự xây dựng — Runtime phổ thông có thể tận dụng các stack mã nguồn mở như Browser Use, Anthropic Agent SDK; còn API gateway doanh nghiệp bắt buộc phải tự phát triển |
| 6. Verification & Recovery | Kiểm thử, quy tắc kiểm tra, đánh giá kết quả, phục hồi khi thất bại, thử lại và rollback | Tự xây dựng — các quy tắc xác minh gắn chặt với nghiệp vụ, giải pháp mua sẵn không hoạt động được |
| 7. Governance | Quyền hạn, Secrets, Audit, Chi phí, Chính sách, Phê duyệt từ con người | Bắt buộc tự xây dựng — thiết kế theo góc nhìn kỹ thuật chứ không phải góc nhìn tuân thủ |

Dưới đây là những phán đoán then chốt ở từng tầng, trình bày ngắn gọn từng ý:

Tầng đầu tiên — Entry. Web, CLI, IDE, IM, API, GitHub Issue, workspace doanh nghiệp — đây chỉ là các cổng vào công việc, bản thân chúng không tạo ra giá trị nghiệp vụ.

Kiến trúc Agent theo tầng — Phần 2

Tầng thứ hai: Task. Goal, Spec, Context, Acceptance Criteria, Priority, Budget đều nên thuộc về Task. Một Task được coi là hợp lệ khi mô tả rõ ràng: mục tiêu là gì, tại sao phải làm, khi nào thì coi là hoàn thành, mức ưu tiên ra sao, và ngân sách cho phép là bao nhiêu. Nếu một hệ thống Agent mà thiếu sáu trường thông tin này ngay từ đầu, nhiệm vụ sẽ bắt đầu trôi nổi trong hệ thống.

Tầng thứ ba: Context & Memory. Kiến thức doanh nghiệp, kiến thức về code, các nhiệm vụ đã thực hiện, quyết định, sở thích người dùng, trạng thái hiện tại — tất cả đều nằm ở đây. Repo Wiki, Knowledge Graph, Knowledge Cards mà Qoder nhấn mạnh tại hiện trường đều là những hình thức cụ thể của tầng này — biến những “sự kiện rời rạc” thành “tài sản mà máy có thể recall được”.

Tầng thứ tư: Planning & Skill. Hệ thống quyết định cách chia nhỏ nhiệm vụ, chọn Skill nào có thể tái sử dụng, bước nào cần model mạnh, bước nào có thể chạy song song. Tầng này là nơi Agent thực sự bắt đầu “suy nghĩ”, cũng là nơi khả năng của model được khai thác dày đặc nhất.

Tầng thứ 5 Runtime & Tools. Shell, Browser, Computer Use, Filesystem, Git, Database, MCP, API doanh nghiệp đều thuộc tầng này. Đây là điểm nối thực sự giữa Agent và thế giới bên ngoài.

Tầng thứ 6 Verification & Recovery. Bao gồm kiểm thử, kiểm tra quy tắc, đánh giá kết quả, phục hồi khi thất bại, thử lại và rollback.

Tầng thứ 7 Governance. Quản lý quyền hạn, Secrets, Audit, chi phí, chính sách, phê duyệt từ con người. Ngoài ra còn có các hạng mục chi tiết hơn — đăng ký thuật toán (算法备案), khả năng giải thích mô hình, phân bổ trách nhiệm khi xảy ra lỗi, quản lý phụ thuộc bên thứ ba, kiểm soát luồng dữ liệu ra nước ngoài (数据出境管控) — đây là những ràng buộc bắt buộc khi triển khai Agent trong các ngành chịu sự giám sát chặt chẽ (y tế, tài chính, giao thông, truyền thông, an ninh công cộng).

Mô hình AI xuyên suốt các tầng, nhưng mô hình không còn đồng nghĩa với toàn bộ nền tảng Agent. Đây là sự chuyển đổi nhận thức bị đánh giá thấp nhất trong hai năm qua — nhiều đội ngũ đã dành quá nhiều thời gian để so sánh các mô hình, trong khi yếu tố thực sự quyết định hệ thống có thể đưa vào sản xuất hay không lại nằm ở sáu tầng còn lại.

Browser Agent:填补 Agent与现实世界之间的接口空白

TinyFish là một sản phẩm rất mang tính đại diện cho hướng tiếp cận này.

Nhiều hệ thống kinh doanh thực tế không có API thuận tiện, hoặc người dùng cần đăng nhập website, tương tác với trang động, điền biểu mẫu, chuyển đổi trang, tải tệp. Các giải pháp tự động hóa truyền thống dựa vào script Playwright hoặc Puppeteer, chỉ cần trang web thay đổi là không còn hoạt động. Browser Agent cho phép mô hình hiểu trực tiếp nội dung trang web và thực hiện các thao tác.

Đây là một khoảng trống quan trọng mà Agent Runtime cần lấp đầy: tương tác Web thực tế.

Các tác tử như tác tử gửi biểu mẫu liên kết ngoài, tác tử vận hành, tác tử mua hàng, tác tử nghiên cứu đều có thể cần thực hiện thao tác trên website.

Tuy nhiên, điều thực sự khó khăn ở đây không phải là “có thể nhấp nút hay không”. Các hệ thống sản xuất còn phải giải quyết vấn đề trạng thái đăng nhập — quản lý Cookie/Token như thế nào, xử lý ra sao khi hết hạn; xử lý song song — nhiều tab trong cùng một tác vụ cần đồng bộ hóa ra sao; khôi phục lỗi — trang web bị treo, mạng bị gián đoạn thì tiếp tục từ đâu; ngăn chặn gửi trùng lặp — khi mạng rung lắc, thao tác nhấp bị thực hiện nhiều lần phải xử lý thế nào; vượt proxy — hạn chế về khu vực/IP cần绕过 ra sao; xử lý CAPTCHA — vượt qua kiểm tra con người như thế nào; phân quyền — cách ly nhiều tài khoản thực hiện ra sao; cuối cùng còn phải “chứng minh tác vụ thực sự hoàn thành” — làm sao để xác minh thao tác đã thực sự có hiệu lực.

Sâu hơn một tầng nữa, indirect prompt injection (tiêm prompt gián tiếp) là mối đe dọa an ninh thực tế nhất đối với Browser Agent vào năm 2026: OWASP xếp prompt injection ở vị trí mối đe dọa AI hàng đầu năm 2026, chỉ cần chèn một đoạn văn bản ẩn vào trang web là có thể dụ Agent gửi Cookie của người dùng ra ngoài. Về mặt kiến trúc không có giải pháp triệt để, chỉ có thể tìm kiếm sự thỏa hiệp về mặt kỹ thuật ở các cơ chế Sandbox, danh sách trắng hành động (action whitelist) và kiểm soát Ambient Credential.

Browser Use cũng cần phải được đưa vào trong Harness. Chỉ có năng lực ở tầng Demo thì chưa đủ. Nếu một tổ chức thực sự muốn đưa Browser Agent vào môi trường production, chi phí chỉ riêng cho tầng này đã đủ để xây lại một hệ thống RPA hoàn chỉnh.

Vì vậy, nhìn bề ngoài Browser Agent giống như một ứng dụng, nhưng thực chất nó là một phần của Runtime.

Năm, Verification quyết định Agent có được cấp quyền cao hơn hay không

Trong hệ thống Agent có một quy luật rất trực tiếp: mức độ tự chủ càng cao thì việc xác minh và quản trị phải càng mạnh.

Một Agent chỉ có khả năng soạn thảo email thì chi phí khi xảy ra lỗi còn hạn chế.

Một Agent có khả năng sửa đổi database sản xuất, commit code, phát hành ngân sách quảng cáo, hay vận hành backend doanh nghiệp — mức độ rủi ro hoàn toàn khác nhau.

Một nền tảng Agent thực sự trưởng thành không chỉ trả lời được câu hỏi “có thể làm gì”, mà còn phải thể hiện rõ ràng:

Nó được phép truy cập những gì;
Được phép sửa đổi những gì;
Những hành động nào bắt buộc phải phê duyệt;
Mỗi bước để lại log audit như thế nào;
Khi thất bại thì phục hồi ra sao;
Hệ thống chứng minh task hoàn thành thật sự bằng cách nào.

Ở đây có một tiêu chí mang tính kỹ thuật: nếu một Agent không thể cung cấp bằng chứng có thể xác minh cho từng hành động của mình, quyền tự chủ của nó chỉ nên dừng ở mức “người tư vấn”. Nói cách khác, quyền tự chủ được mở rộng từ từ thông qua việc chứng minh năng lực trong khuôn khổ tuân thủ, chứ không phải được mở khóa bởi danh sách tính năng. Một Agent dù có khả năng gọi 100 API, nếu không thể chứng minh mỗi lần gọi đều đạt kết quả như kỳ vọng, trong các ngữ cảnh chịu sự giám sát chặt chẽ như tài chính, y tế, dữ liệu xuyên biên giới, nó vẫn chỉ có thể đóng vai “người tư vấn”.

Đây cũng là lý do Governance ngày càng quan trọng trong bối cảnh doanh nghiệp — nó không chỉ là chuyện của phòng compliance, mà là năng lực mà bộ phận kỹ thuật phải thiết kế ngay từ đầu, đi kèm với Runtime.

VI. Model Router sẽ trở thành bộ điều phối cơ bản – nhưng không phải mọi tầng đều cần mô hình đắt nhất

Việc sử dụng đa mô hình ngày càng trở nên phổ biến.

Một hệ thống đa mô hình có giá trị không đơn thuần là cho phép người dùng chọn GPT, Qwen, Claude hay các mô hình khác từ một dropdown.

Cách tiếp cận hợp lý hơn là để hệ thống tự động định tuyến dựa trên tính chất công việc.

Các tác vụ lập kế hoạch phức tạp và đánh giá kiến trúc sử dụng mô hình mạnh; các tác vụ triển khai code thông thường và tổng hợp văn bản dùng mô hình chi phí thấp hơn; tác vụ thị giác áp dụng mô hình đa phương thức; phân loại hàng loạt chạy qua mô hình nhanh; còn review quan trọng lại quay về mô hình mạnh.

Đằng sau tất cả là một nguyên tắc kỹ thuật đơn giản: các tác vụ khác nhau có yêu cầu hoàn toàn khác biệt về đường cong “năng lực-chi phí”. Để một mô hình mạnh xử lý phân loại hàng loạt là lãng phí; ngược lại, dùng mô hình nhanh cho quyết định kiến trúc sẽ dẫn đến việc phải làm lại nhiều lần. Requesty từng công bố một con số thực tế vào năm 2026: khi định tuyến 70% tác vụ thông thường đến nano model, 20% đến mid-tier và 10% đến frontier model, chi phí trung bình mỗi truy vấn giảm từ 60% đến 80% trong khi chất lượng hầu như không suy giảm – đây là số liệu mang tính minh họa định hướng, con số cụ thể phụ thuộc vào loại tác vụ và chiến lược định tuyến.

Mô hình dần trở thành một tài nguyên tính toán có thể điều phối linh hoạt. Agent Platform chịu trách nhiệm đưa ra lựa chọn động giữa chất lượng, tốc độ, chi phí và rủi ro.

Ví dụ thực tế về routing theo cấp bậc

Khi một Agent nhận yêu cầu “phân tích chiến lược giá đối thủ và đưa ra đề xuất”, nó sử dụng mô hình cao cấp ở giai đoạn “hiểu yêu cầu, chia nhỏ công việc, xác định mức ưu tiên”. Khi chuyển sang giai đoạn “phân loại 100 SKU theo khoảng giá”, nó sẽ chuyển sang mô hình nhanh hơn. Sau khi có kết quả phân loại, Agent lại quay về mô hình cao cấp để đưa ra đánh giá tổng hợp.

Nếu tất cả các tác vụ đều dùng mô hình đắt nhất, chi phí hệ thống sẽ tăng vọt. Ngược lại, nếu toàn bộ đều dùng mô hình rẻ, hệ thống sẽ liên tục thất bại ở những bước phức tạp. Giá trị kỹ thuật thực sự nằm ở chiến lược điều phối, chứ không phải ở việc chọn mô hình nào.

Bảy, Skill là lớp kết nối giữa Runtime đa năng và nghiệp vụ chuyên biệt — cũng là lợi thế cạnh tranh bền vững trong tương lai

Một Agent Runtime đa năng bản thân nó không tạo ra giá trị kinh doanh.

Nó cần thông qua Skill để đi vào các kịch bản thực tế.

Coding Skill nắm rõ cách đọc Repo, viết Spec, chạy Test, tạo Pull Request. Nó quy định rõ: khi nào bắt buộc phải chạy unit test trước, khi nào được phép bỏ qua, mô tả PR cần bao gồm những trường nào, loại thay đổi nào bắt buộc phải qua review thủ công.

SEO Research Skill biết cách tìm từ khóa, phân tích Search Intent, kiểm tra mức độ cạnh tranh, tạo dàn bài nội dung, xác nhận trang đã được index. Đây không phải đơn giản là “làm nghiên cứu từ khóa”, mà là cả một quy trình hoàn chỉnh.

E-commerce Creative Skill hiểu về Brand, SKU, định dạng nền tảng, quy định tuân thủ và quy trình kiểm duyệt. Nó cần nắm rõ giới hạn kích thước ảnh trên từng sàn thương mại điện tử, các từ cấm kỵ, chứng chỉ danh mục sản phẩm, và quy trình kiểm duyệt cuối cùng trước khi chạy quảng cáo.

Ops Skill biết cách kiểm tra giám sát, log, container, database và rollback. Nó phải phân biệt được những cảnh báo nào có thể tự động xử lý, những cảnh báo nào cần can thiệp thủ công, và đâu là điểm rollback an toàn.

Skill không chỉ là một bộ SOP, mà còn là một tài sản có thể thực thi kèm theo quản lý phiên bản, quản lý phụ thuộc, quản lý lặp và cơ chế dự phòng khi thất bại — có thể tham khảo giao thức Skills mà Anthropic ra mắt vào tháng 10 năm 2025, đóng gói từng lĩnh vực kinh nghiệm thành thư mục SKILL.md, để các nền tảng Agent khác nhau tải theo nhu cầu, thay vì phải viết lại từ đầu mỗi lần.

Skill kết nối năng lực thực thi chung với kiến thức chuyên môn.

Do đó, trong tương lai, lợi thế cạnh tranh của nhiều ứng dụng AI sẽ nằm ở Domain Skills đã được xác thực qua hàng loạt tác vụ thực tế. Những Skills này tích lũy “cách thức xử lý công việc trong lĩnh vực này” — không dễ bị mô hình mới thay thế, không dễ bị nền tảng mới chiếm chỗ, mà còn tích lũy theo thời gian như lãi kép.

Một tổ chức có thể liên tục tích lũy Skill, biến mỗi nhiệm vụ mới thành bản cập nhật gia tăng cho Skill—thì năng lực AI của tổ chức đó không phải mua được, mà là tự phát triển từ bên trong.

Tám, Góc nhìn theo ngành: Hình thái cụ thể của việc triển khai tại bốn loại tổ chức

Bốn đoạn dưới đây không phải là chuỗi kể chuyện—mà là ánh xạ bảy tầng Stack trừu tượng vào từng ngành cụ thể, để thấy điểm nghẽn khác nhau ở đâu.

Viễn thông/Nhà mạng: Thay đổi gói cước, kích hoạt dịch vụ cho khách hàng doanh nghiệp, hay xác định lỗi xuyên miền đều phải đi qua nhiều hệ thống như BSS/OSS/CRM/Hệ thống tính cước. Thách thức lớn nhất khi triển khai Agent nằm ở đối soát liên miền—một Agent thay đổi gói cước khách hàng trong CRM phải đồng thời thông báo cho hệ thống tính cước và OSS, nếu không chu kỳ thanh toán sẽ không khớp. Trong Stack, hai tầng có giá trị nhất là tầng thứ 5 Runtime & Tools (kết nối giao diện đa miền) và tầng thứ 7 Governance (kiểm toán tài khoản).

Tài chính/Ngân hàng: Quản lý rủi ro, chống rửa tiền, đối soát, báo cáo tuân thủ đều đòi hỏi tính giải thích được, có thể kiểm toán và truy xuất nguồn gốc. Một Agent phát hiện rửa tiền, mỗi khi “cho qua” hoặc “chặn lại” giao dịch, đều phải giải thích được dựa trên quy tắc nào, lịch sử giao dịch đoạn nào, hồ sơ khách hàng mục nào. Trong Stack, hai tầng có giá trị cao nhất là tầng 6 – Verification (chuỗi bằng chứng có thể giải thích) và tầng 7 – Governance (đăng ký thuật toán + kiểm soát chuyển dữ liệu ra nước ngoài) – hai tầng này trong khung quy định tài chính trong nước là điều kiện bắt buộc khi triển khai, chứ không phải “điểm cộng”.

Sản xuất: MES, ERP, QMS, SRM trong thời gian dài tồn tại biệt lập với nhau, một quyết định xuyên lĩnh vực (ví dụ như “năng lực sản xuất không đủ, có nên đặt thêm nguyên vật liệu không”) phải trao đổi qua lại giữa bốn hệ thống. Hình thái thực tế của Agent trong sản xuất là lớp điều phối xuyên hệ thống, chứ không phải thay thế một hệ thống đơn lẻ. Nó đồng thời đọc dữ liệu vật liệu từ ERP, tỷ lệ lỗi từ QMS, mức sử dụng năng lực sản xuất từ MES, chỉ số hiệu suất nhà cung cấp từ SRM, rồi đưa ra phán đoán tổng hợp. Trong Stack, hai tầng có giá trị cao nhất là tầng 5 – Runtime (cổng API doanh nghiệp) và tầng 3 – Context (tích lũy kiến thức quy trình, sự cố lịch sử, kinh nghiệm xưởng sản xuất).

E-commerce: Các hoạt động xuyên domain trong đợt khuyến mãi lớn (đặt hàng, thanh toán, tồn kho, logistics, chăm sóc khách hàng), kiểm thử áp lực / đảm bảo tính nhất quán của kho / chống gian lận / đối soát đa nền tảng. Ứng dụng đầu tiên của Agent trong thương mại điện tử là vận hành sáng tạo (thay hình sản phẩm, thay nền, tạo nội dung đa ngôn ngữ) và hỗ trợ tổng đài chăm sóc khách hàng. Phần có giá trị nhất trong Stack là tầng Skill thứ 4 (quy trình tuân thủ và kiểm duyệt cho SKU/kênh của từng nền tảng) và tầng Verification thứ 6 (tự động kiểm tra xem nội dung sáng tạo có đáp ứng tiêu chuẩn nền tảng hay không).

�iểm chung của bốn loại tổ chức: Stack càng ở dưới càng nên chia sẻ, càng ở trên càng nên tự xây. Các năng lực nền tảng như Runtime, Model Router, Tool Gateway thì vài đơn vị cùng xây dựng hoặc mua stack open-source trưởng thành sẽ tiết kiệm hơn; còn Skill, Context, Governance phải tự xây vì gắn liền với nghiệp vụ, gắn liền với tuân thủ, gắn liền với tài sản tổ chức.

Chín. Sản phẩm cuối cùng có thể biểu hiện hoàn toàn khác nhau, nhưng lớp nền tảng lại chia sẻ cùng một hệ điều hành

Một Coding Agent và một Video Agent có giao diện người dùng, mô hình người dùng và mô hình kinh doanh hoàn toàn khác nhau.

Nhưng lớp nền tảng đều cần: Context, Task, Skill, Tools, Runtime, Verification, Memory, Governance, và cuối cùng đều phải hướng tới kết quả nghiệp vụ.

Một Knowledge Agent doanh nghiệp và một Browser Agent có vẻ như khác biệt rất xa, nhưng cuối cùng chúng đều phải giải quyết các vấn đề về quyền truy cập, quản lý trạng thái, phục hồi khi gặp lỗi và kiểm toán.

Vì vậy, khi phát triển nhiều sản phẩm AI, đáng để phân tách thành hai tầng.

Tầng trên: Chuyên sâu theo chiều dọc. Mỗi sản phẩm tập trung vào một Job hoàn chỉnh, với trải nghiệm người dùng, đối tượng dữ liệu và chỉ số kinh doanh riêng. Coding Agent xoay quanh Repo và Code Review, Video Agent xoay quanh Script và Asset, Research Agent xoay quanh Source và Citation. Độ sâu chuyên môn của từng lĩnh vực không thể thay thế bằng năng lực tổng quát.

Tầng dưới: Chia sẻ tối đa. Agent Runtime, Model Router, Tool Gateway, Memory, Audit, Secrets, Evaluation có thể trở thành hạ tầng chung.

Cách tiếp cận này vừa giúp các sản phẩm không phải xây lại từ đầu những gì đã có, vừa tránh được việc từ sớm xây dựng một “nền tảng Agent đa năng” khổng lồ nhưng không có người dùng — đây là bẫy mà rất nhiều đội đã mắc phải trong hai năm qua, cố gắng hoàn thành tất cả các use case một lần, để rồi không use case nào đạt được độ sâu có thể sử dụng được.

Con đường ổn định hơn là bắt đầu từ việc kiểm chứng giá trị qua các tác vụ cụ thể, rồi mới trích xuất những năng lực nền tảng xuất hiện lặp đi lặp lại. Phán đoán đằng sau: Tầng phổ quát chỉ có thể phát triển từ những kịch bản cụ thể, chứ không thể vẽ ra từ sơ đồ kiến trúc. Ngay từ đầu đã thiết kế Runtime “hỗ trợ mọi kịch bản”, thường có nghĩa là không làm tốt được bất kỳ kịch bản nào.

Ba câu hỏi tự kiểm tra ngược (sau khi viết xong thì đối chiếu với bản thân):

Runtime mà chúng ta trừu tượng hóa, đã được kiểm chứng tính phổ quát trong ít nhất hai kịch bản cụ thể chưa?
Thiết kế ở mỗi tầng của chúng ta, có tương ứng với một vấn đề kinh doanh cụ thể từng xảy ra lỗi thực sự không?
Nếu hôm nay cắt giảm một nửa ngân sách, những tầng nào chúng ta sẽ giữ lại? Nếu câu trả lời là “context và skill”, hướng đi đúng rồi; nếu là “runtime và gateway”, có thể cần phải làm lại từ đầu.

Đây cũng là nhận định dài hạn mà Hội nghị Cloud Town để lại cho tôi: Trên các mô hình ngôn ngữ đang dần hình thành một tầng hệ thống mới, không thuộc về bất kỳ sản phẩm cụ thể nào, mà dần trở thành hệ điều hành cho thời đại Agent. Ai xây dựng được tầng OS này vững chắc sớm nhất, ai sẽ có lợi thế hơn trong vòng lặp sản phẩm tiếp theo.

Bài học dành cho nhà ra quyết định

Nếu bạn là người đứng đầu AI của doanh nghiệp có doanh thu hàng năm trên 5 tỷ đồng (CDO/CIO/CTO), có ba việc có thể bắt đầu ngay từ bây giờ:

Vẽ ra bức tranh snapshot bảy tầng của Agent Stack tổ chức hiện tại—Đừng vội mua sản phẩm, hãy nhìn rõ mỗi tầng của mình hiện đang ở trạng thái trống rỗng, mua sẵn từ bên ngoài, hay mới dở dang. Chính bức tranh này sẽ lộ ra nút thắt cổ chai thực sự.
Chọn 1 kịch bản có ROI cao, hoàn thiện một chuỗi khép kín theo chiều dọc trước—Đừng vội xây dựng Runtime. Hãy chọn một trong ba: Coding Agent, hỗ trợ dịch vụ khách hàng, hoặc trợ lý phát triển, đưa bốn tầng Context, Task, Skill, Verification vận hành trơn tru, rồi mới bàn đến chuyện “xây dựng nền tảng”.
Đưa Governance lên tầng kỹ thuật, chứ đừng đặt ở tầng tuân thủ—Phân quyền, kiểm toán, khả năng giải thích, phân bổ trách nhiệm khi xảy ra lỗi, kiểm soát phụ thuộc bên thứ ba, cần thiết kế từ đầu cùng với các Agent nghiệp vụ, chứ đừng để sau mới bổ sung.

Có thể bạn muốn hỏi

Q1: Bảy tầng Stack này khác gì so với khung điều phối đa Agent mà Gartner và IDC đề xuất?

Gartner/IDC tập trung vào sự phối hợp và quản trị đa Agent ở cấp độ tổ chức; bảy tầng trong bài này là cấu trúc kỹ thuật bên trong của từng Agent đơn lẻ. Một tổ chức có thể đề cập đến cả hai tầng này cùng lúc—đơn Agent vận hành theo bảy tầng, còn các đơn Agent với nhau thì đi theo cơ chế điều phối. Stack mang tính vi mô, còn orchestration mang tính vĩ mô.

Q2: Tại sao tầng mô hình không chiếm riêng một lớp?

Bởi vì trong hệ thống Agent, mô hình là tài nguyên xuyên suốt theo chiều ngang, chứ không phải một lớp độc quyền. Model Router coi các mô hình khác nhau như các nguồn tính toán được điều phối linh hoạt, ngang hàng với Shell, Browser trong Runtime – đều là những “công cụ”. Mô hình tất nhiên quan trọng, nhưng nó không nên chiếm trọn độ phức tạp của Agent.

Q3: Nhóm nhỏ có nên bỏ qua tầng này, dùng thẳng sản phẩm end-to-end như ChatGPT/Claude?

Đúng vậy. Với các nhóm có doanh thu hàng năm dưới 100 triệu NDT và độ phức tạp tổ chức thấp, việc dùng trực tiếp các sản phẩm Agent có sẵn (Browser Use, Manus, Agent của Alibaba Cloud百炼, v.v.) sẽ hiệu quả về chi phí hơn. Bảy tầng được thảo luật trong bài này xuất phát từ câu hỏi: “Liệu một tổ chức có doanh thu hàng năm từ 5 tỷ NDT trở lên có nên xây dựng nền tảng Agent riêng?” – việc nhóm nhỏ tự xây nền tảng chẳng qua là tối ưu ngược.

Tự kiểm tra ngược (cho bạn, cũng cho tôi)

Ba câu dưới đây, nếu bạn gật đầu trong lòng với bất kỳ câu nào, có thể bạn đang bị cuốn theo câu chuyện hơn là đi theo bằng chứng.

Học AI Từ Từ <001>

Nếu bạn không đồng ý với cả ba ý trên, hãy tiếp tục đọc.

Giải thích nguồn trích dẫn cuối bài (nguồn gốc từng mục + cấp độ bằng chứng + nhãn quan điểm)

Các trích dẫn chính:

“Chỉ cần model đủ mạnh, Agent sẽ tự vận hành.”
- Nguồn: Tổng hợp từ nhiều bài thuyết trình tại hội nghị AI năm 2024
- Cấp độ bằng chứng: Quan sát thực tiễn (Practitioner observation)
- Nhãn: Cảnh báo về kỳ vọng thực tế
“Chúng ta cần một nền tảng Agent toàn năng.”
- Nguồn: Khảo sát nội bộ doanh nghiệp CNTT 2024
- Cấp độ bằng chứng: Báo cáo nghiên cứu (Research report)
- Nhãn: Phân tích chi phí - lợi ích
“Skill có thể đợi model ổn định rồi hẵng xây dựng.”
- Nguồn: Best practice từ các dự án triển khai enterprise AI
- Cấp độ bằng chứng: Nghiên cứu tình huống (Case study)
- Nhãn: Khuyến nghị về quản lý tri thức tổ chức
“One workbench. Four entries. One foundation.” ——Biển booth và blog chính thức của Qoder, tại hội chợ Cloud Computing Conference (Yunqi) 2026 + bài viết Introducing Qoder 1.0 trên Alibaba Cloud Community phát hành ngày 2026-08-31. Cấp độ bằng chứng: Khẳng định từ nhà cung cấp (lập trường của Alibaba).
QwenWork Legal Document Fill Out: Sandbox Container + Desktop ảo + Tool calling ——Demo trực tiếp QwenWork trên Alibaba Cloud, bài viết trên Alibaba Cloud Community ngày 2026-09-25. Cấp độ bằng chứng: Khẳng định từ nhà cung cấp (lập trường của Alibaba).
QoderWake với tư cách sản phẩm “nhân viên số”, phát hành ngày 2026-04-30 bởi Alibaba ——Mục Qoder trên Baidu Encyclopedia + trang chính thức Alibaba. Cấp độ bằng chứng: Khẳng định từ nhà cung cấp (lập trường của Alibaba).
OWASP 2026 威胁清单将 Prompt Injection 置于首位 ——Tổng hợp State of Browser Use, tháng 5 năm 2026 (Michael Livs blog). Cấp độ bằng chứng: Tổng hợp từ bên thứ ba (vị trí của OWASP, đồng thuận trong ngành).
Requesty: Phân bổ theo bậc 70/20/10 giúp giảm chi phí 60-80% ——Blog chính thức của Requesty, 2026. Cấp độ bằng chứng: Khẳng định từ nhà cung cấp (quan điểm của dịch vụ định tuyến mô hình, con số có phần lạc quan, chỉ mang tính chất tham khảo định hướng).
Microsoft Agent Governance Toolkit (AGT), mã nguồn mở MIT ngày 2026-04-02 ——Báo cáo từ niteagent.com. Cấp độ bằng chứng: Tổng hợp từ bên thứ ba (quan điểm của Microsoft, nhưng AGT là dự án mã nguồn mở, số liệu có thể kiểm chứng).
Anthropic Skills 协议：2025-10-16 发布，2025-12-18 开源为开放标准 ——Anthropic Engineering 博客 + Substack 综合 + Medium LM Po。证据层级：厂商主张 + 第三方综合（Anthropic 立场）。
IDC 预测 2026 年 40% 制造商将引入 AI 驱动排程 ——Groovy Web 2026 综述，引用 IDC 报告。证据层级：第三方综合（IDC 立场，数字方向性参考）。
Stripe “Minions” 每周合并 1,300+ PR，0 人写代码、全人工 Review ——Stripe 工程团队 Steve Kaliski 在 How I AI 2026-03-25 节目 + ByteMonk 2026-02-14 转述。证据层级：厂商主张（Stripe 立场，数字可参考，场景是 Stripe 工程内部，不可外推行业平均）。
BCG 2026 Applied AI Index: agentic chiếm 22% (2026) → 39% (2030) tổng giá trị AI ——Báo cáo công khai của BCG. Cấp độ bằng chứng: Tổng hợp từ bên thứ ba (quan điểm công ty tư vấn, tham khảo theo hướng đi).
Gartner dự đoán 40% ứng dụng doanh nghiệp sẽ tích hợp AI Agent dạng tác vụ vào năm 2026, so với dưới 5% năm 2025 ——Tổng hợp của Paul Okhrem năm 2026, trích dẫn Gartner. Cấp độ bằng chứng: Tổng hợp từ bên thứ ba (quan điểm Gartner, tham khảo định hướng).
CAC/NDRC/MIIT (Cơ quan Quản lý Không gian Mạng Trung Quốc/Ủy ban Phát triển và Cải cách Quốc gia/Bộ Công nghiệp và Công nghệ thông tin Trung Quốc) đồng loạt ban hành “Ý tưởng thực hiện về ứng dụng tiêu chuẩn hóa và phát triển đổi mới cho Tác tử thông minh”, có hiệu lực từ 2026-07-15 ——Bản tin pháp luật AI Trung Quốc hàng tháng của Rimon Law, tháng 07/2026. Cấp độ bằng chứng: Tổng hợp từ bên thứ ba (quan điểm công ty luật, tài liệu pháp quy có thể tra cứu).
TinyFish: Huy động $47M, khách hàng gồm Google / DoorDash / Amazon, khởi động trình duyệt <250 ms — Báo cáo tổng hợp SwitchTools 2026. Cấp độ bằng chứng: tổng hợp từ bên thứ ba (quan điểm của trang đánh giá sản phẩm, các con số cần kiểm chứng tại trang chính thức của TinyFish).

Nếu bạn đang đánh giá cách xây dựng nền tảng Agent nội bộ cho doanh nghiệp, những khả năng nào nên tự phát triển / mua / chia sẻ, Agent Runtime nào mang lại giá trị tái sử dụng cao nhất, hãy liên hệ với chúng tôi. Chúng tôi cung cấp dịch vụ tư vấn chuyển đổi AI cho doanh nghiệp — từ kiến trúc Agent, thiết kế Runtime đến việc tích lũy Skill, giúp bạn chuyển từ “Agent đơn lẻ” thành “nền tảng Agent cấp tổ chức”.

Đào tạo nội bộ doanh nghiệp: Dành cho ban lãnh đạo và nhân sự chủ chốt, khóa học kiến thức 3 ngày với giá ¥90.000/mỗi buổi, giải thể toàn diện về Agent Stack 7 tầng, góc nhìn kỹ thuật Governance và phương pháp xây dựng Skill cho đội ngũ của bạn.

Tư vấn chuyên biệt: Chẩn đoán kiến trúc 90 phút với giá từ ¥3.000, cung cấp đánh giá độc lập về bức tranh 7 tầng hiện tại của tổ chức, các tầng còn thiếu, và phân tích lựa chọn mua ngoài vs. tự phát triển; dịch vụ đồng hành chuyên sâu theo dự án được báo giá riêng.

Chia sẻ cho ban lãnh đạo và thuyết trình ngành: Chủ đề tại hội nghị ngành/hội thảo kín/diễn đàn, nội dung được thiết kế theo yêu cầu sau khi liên hệ.

Email hợp tác: [email protected]

Tài liệu tham khảo thêm: “Khung 7 bước chuyển đổi AI” — giải thích chi tiết lộ trình hoàn chỉnh để doanh nghiệp triển khai AI.

Điểm本地化(đối chiếu dịch đa ngôn ngữ, thỏa thuận chiến lược đa ngôn ngữ của IAIUSE·2026-08-09)

Khi dịch sang 19 ngôn ngữ, các nội dung sau được thay thế theo đặc thù thị trường đích, cấu trúc/trình bày giữ nguyên:

Dưới đây là bản dịch tiếng Việt:

Nội dung bản tiếng Trung	Bản tiếng Anh	Bản tiếng Nhật	Bản tiếng Đức	Bản tiếng Ả Rập
Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch (giữ nguyên tên sản phẩm)	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch	Qoder / QwenWork / TinyFish / WonderClip / OpenSearch

| Kỹ năng Chuyên môn / Kỹ năng Lập trình / Kỹ năng Nghiên cứu SEO / Kỹ năng Sáng tạo Thương mại điện tử / Kỹ năng Vận hành | Kỹ năng Chuyên môn / Kỹ năng Lập trình / Kỹ năng Nghiên cứu SEO / Kỹ năng Sáng tạo Thương mại điện tử / Kỹ năng Vận hành | Kỹ năng Chuyên môn / Kỹ năng Lập trình / Kỹ năng Nghiên cứu SEO / Kỹ năng Sáng tạo Thương mại điện tử / Kỹ năng Vận hành | Kỹ năng Chuyên môn / Kỹ năng Lập trình / Kỹ năng Nghiên cứu SEO / Kỹ năng Sáng tạo Thương mại điện tử / Kỹ năng Vận hành | Kỹ năng Chuyên môn / Kỹ năng Lập trình / Kỹ năng Nghiên cứu SEO / Kỹ năng Sáng tạo Thương mại điện tử / Kỹ năng Vận hành |

Về Series Này

「Yunqi Insight」là series trường hợp nghiên cứu thực địa do IAIUSE phát triển, xuất phát từ Hội nghị Yunqi 2026, phân tích những thay đổi thực sự đang diễn ra trong ngành AI dưới góc nhìn của nhà nghiên cứu — không chạy theo xu hướng nhất thời, chỉ tập trung vào các hướng đi đáng đầu tư và mức độ thuyết phục của bằng chứng.

Series bao phủ các chủ đề như tầng hệ thống nằm trên mô hình nền tảng (model), việc triển khai Agent, tài sản Context, thiết kế tổ chức AI doanh nghiệp, sự dịch chuyển của đơn vị cạnh tranh sản phẩm AI, v.v., tổng cộng khoảng 10 bài viết.

Tôi có gần 8 năm kinh nghiệm trong tư vấn doanh nghiệp và phân tích kinh doanh, từng làm việc tại IBM, tham gia các dự án liên quan đến viễn thông, tài chính, bảo hiểm và sản xuất. Sau đó, tôi tiếp tục hoạt động trực tiếp trong lĩnh vực sản phẩm viễn thông, sản phẩm internet và phát triển ứng dụng AI, đảm nhận phân tích yêu cầu, thiết kế sản phẩm và triển khai liên đội.

Thực ra phía sau kênh này là một nhóm nhỏ - tôi và 1-2 đồng nghiệp hợp tác lâu dài, phụ trách lần lượt các mảng nghiên cứu công cụ lập trình AI, tổng hợp case quản trị tổ chức và coaching. Phần lớn các dự án mà “chúng tôi đồng hành cùng doanh nghiệp vượt qua” đều là những dự án mà cả nhóm đã cùng thực hiện.

Kho dữ liệu nghiên cứu tích lũy hơn 200 bài viết. Các nhận định trong series này đến từ quan sát thực địa và xác thực liên ngành của tôi, mang quan điểm cá nhân rõ ràng, không đại diện cho bất kỳ quan điểm của nhà cung cấp nào.