Từ Bản Chất Của Phần Mềm Đến Đại Tái Cấu Trúc Ngành Công Nghệ Hướng Tới Kỷ Nguyên Siêu Trí Tuệ (2006 – 2046)

Khi đứng trước ngưỡng cửa của trí tuệ nhân tạo tổng quát (AGI) và xa hơn là siêu trí tuệ (Superintelligence), tôi buộc phải quay lại đặt cho mình những câu hỏi nguyên bản nhất: Bản chất của phần mềm thực sự là gì? Vì sao loài người lại cần đến phần mềm? Và bức tranh ấy đã, đang và sẽ biến đổi ra sao trong suốt 40 năm — từ 2006, 2016, 2026 cho tới 2036 và 2046?

Ở góc độ cốt lõi nhất, bản chất của phần mềm là biến một cách xử lý công việc thành một năng lực mà máy móc có thể thực hiện, lặp lại nhất quán và nhân rộng ở quy mô lớn. Khi chưa có AI, con người phải chỉ dẫn từng bước cứng nhắc cho máy. Khi có AI, máy bắt đầu học được cách xử lý và tự lựa chọn các bước trung gian để đạt tới mục tiêu. Nhưng dù AI có thông minh đến đâu, nhu cầu về phần mềm vẫn tồn tại nguyên vẹn — bởi bản thân AI cũng cần một hệ thống chặt chẽ để ghi nhớ trạng thái, tính toán chính xác, giao tiếp với thế giới thực và chịu sự kiểm soát.

1. Phía sau một nút bấm "Duyệt đơn hàng" là cả một thể chế doanh nghiệp

Sai lầm phổ biến nhất của dân kỹ thuật là nhìn phần mềm chỉ như "code và màn hình". Hãy gọi đúng giá trị hệ thống đang cung cấp: ghi nhận (Record) dữ liệu, giúp hiểu (Insight) tình hình, điều phối (Operate) workflow, hoặc ủy quyền (Delegate) hành động theo mục tiêu. Ở mức sâu nhất, phần mềm còn mã hóa quy tắc, quyền hạn, bằng chứng và trách nhiệm của tổ chức.

Hãy thử nhìn vào một chức năng tưởng chừng tầm thường nhất trong mọi hệ thống ERP hay TMS: nút bấm "Duyệt đơn hàng". Thực chất, bên dưới nút bấm đó đang chứa đựng hàng loạt thỏa thuận ngầm và tường minh của doanh nghiệp:

• Thế nào được coi là một đơn hàng hợp lệ về mặt thương mại?
• Ai trong công ty được quyền thay đổi giá bán hoặc áp dụng chiết khấu ngoại lệ?
• Hạn mức công nợ nào thì nhân viên được tự quyết, hạn mức nào bắt buộc Giám đốc phải phê duyệt?
• Khi nào thì kho thực sự được phép xuất hàng ra khỏi cổng?
• Và khi xảy ra tranh chấp với đối tác, bản ghi nào trong hệ thống được công nhận làm bằng chứng pháp lý?

Như vậy, một hệ thống phần mềm doanh nghiệp không chỉ lưu dữ liệu; nó đang lưu giữ quy tắc, quyền hạn và bằng chứng về những gì đã xảy ra. Một thay đổi nhỏ trên màn hình đôi khi tương ứng với một cuộc dịch chuyển lớn về quyền lực: trước đây nhân viên tự quyết theo cảm tính, nay họ phải tuân theo một quy trình có kiểm soát. Đó chính là lý do vì sao rất nhiều dự án phần mềm thất bại hoặc đình trệ ở khâu thống nhất cách vận hành giữa con người với con người, dù phần viết code hoàn toàn không phức tạp.

Nhìn rộng ra, con người tìm đến phần mềm để giải quyết 6 nhu cầu căn bản: (1) Ghi nhớ trạng thái và lịch sử vượt quá trí nhớ cá nhân (ai đang nợ tiền, lô hàng nào đã giao); (2) Xử lý tính toán nhanh và lặp lại nhất quán (tính lương, đối soát hàng triệu giao dịch); (3) Phối hợp cho phép kinh doanh, kho và kế toán cùng làm việc trên một thông tin thống nhất; (4) Kiểm soát nhằm thực thi đúng quyền hạn (chỉ người được cấp quyền mới được giải ngân); (5) Khám phá thông qua mô phỏng, dự báo lịch sản xuất hoặc tuyến vận chuyển; và (6) Sáng tạo trải nghiệm mới chưa từng tồn tại trong thế giới vật lý.

2. Hành trình 40 năm (2006 → 2046): Cùng một bài toán Điều xe, 5 thế giới khác biệt

Khi đặt các cột mốc 2006 → 2016 → 2026 → 2036 → 2046 cạnh nhau, điểm thay đổi sâu sắc nhất không phải là ngôn ngữ lập trình, mà là phạm vi công việc mà con người có thể ủy quyền cho máy. Trước đây, ta phải chỉ đạo máy cực kỳ chi tiết: lấy dữ liệu ở ô nào, bấm nút nào, xuất báo cáo nào. Khi trí tuệ máy tăng lên, ta giao một mục tiêu lớn hơn và để hệ thống tự tìm đường đi.

Hãy lấy cùng một bài toán Điều phối xe giao hàng (TMS) với mục tiêu "Giao hàng đúng hạn với chi phí hợp lý" để thấy sự lột xác qua 5 thời kỳ:

3. Năm hướng biến đổi cấu trúc phần mềm & Câu hỏi cốt tử trước ngưỡng Siêu trí tuệ

Từ sự dịch chuyển trên, cấu trúc phần mềm đang và sẽ biến đổi theo 5 hướng lớn:

1. Giao diện chuyển từ "chỗ để thao tác" thành "chỗ để giao việc, quan sát và can thiệp": Thay vì bấm qua 10 màn hình, người dùng yêu cầu "Kiểm tra các khoản phải thu tuần này, xác định khoản có nguy cơ chậm và chuẩn bị phương án xử lý". Tuy nhiên, bảng biểu, lịch và bản đồ trực quan vẫn giữ nguyên giá trị vì nhìn một bảng so sánh 30 phương án vẫn hiệu quả hơn hỏi đáp 30 lượt.
2. Phần mềm dùng một lần (Disposable / Ephemeral Software): Khi chi phí tạo và kiểm thử phần mềm giảm mạnh, những nhu cầu nhỏ trước đây không đáng mở dự án nay sẽ được tạo riêng rồi hủy sau khi xong việc (như một công cụ đối chiếu dữ liệu phục vụ riêng một kỳ kiểm toán). Nhưng lớp bản ghi chính thức (System of Record), danh tính và lịch sử giao dịch ở bên dưới vẫn phải duy trì ổn định tuyệt đối[cite: 5, 6].
3. Người dùng trực tiếp của nhiều hệ thống sẽ là AI Agent: Thay vì nhân viên mở CRM nhập liệu, Agent sẽ tự thu thập thông tin và cập nhật CRM. Chất lượng một phần mềm lúc này được đo bằng việc: Agent có hiểu đúng dữ liệu không, có được cấp đúng quyền không, có biết thao tác thành công hay chưa, và có truy vết/phục hồi được khi sai sót không[cite: 5, 6].
4. Tạo phần mềm và vận hành phần mềm tiến sát lại nhau: Hệ thống có thể tự phát hiện lỗi vận hành, đề xuất bản vá, chạy kiểm thử và triển khai trong phạm vi cho phép.
5. Đơn vị bán hàng chuyển từ "Chức năng/Tài khoản" sang "Công việc được hoàn thành": Khách hàng mua khả năng xử lý một loại hồ sơ hay năng lực đối soát một khối lượng giao dịch trong cam kết SLA[cite: 5].

Và khi chúng ta nói về Siêu trí tuệ (Superintelligence) — một hệ thống vượt xa con người trong phần lớn các hoạt động trí tuệ — chúng ta không thể tự trấn an bằng câu nói quen thuộc: "AI chỉ viết code thôi, còn con người chắc chắn giữ phần phân tích nghiệp vụ (BA), kiến trúc (SA) và chiến lược". Một siêu trí tuệ đúng nghĩa hoàn toàn có thể làm tốt cả những việc ấy.

Khi đó, nút thắt không còn nằm ở trí tuệ tính toán, mà chuyển hẳn sang quyền sở hữu, thể chế và trách nhiệm: Mục tiêu của ai được ưu tiên (tối đa lợi nhuận quý này hay bảo vệ việc làm và an toàn dài hạn)? Ai sở hữu dữ liệu và tài nguyên? Ai có thẩm quyền cam kết thay mặt tổ chức? Và khi xảy ra thiệt hại, ai chịu trách nhiệm trước pháp luật[cite: 1, 2, 5, 6]? Trí tuệ mạnh đến mấy cũng không tự tạo ra thông tin thực tế chưa được quan sát (xe thực sự đang ở đâu, kho còn hàng hay không) và càng không tự sinh ra quyền hạn chưa được cấp.

Bài 1 hỏi phần mềm là gì: một cách làm được đóng gói để mở rộng năng lực con người. Bài 2 chuyển câu hỏi sang thực tế: người dùng đang cần hệ thống ghi lại điều gì, giúp họ hiểu điều gì, làm thay bước nào, hay được phép tự theo đuổi mục tiêu nào?

Để thấy khác biệt, theo dõi cùng một công việc: giao một đơn hàng đúng hẹn. Bốn lớp dưới đây không phải bốn màn hình bắt buộc hay một lộ trình mọi doanh nghiệp phải hoàn thành; chúng là bốn mức độ giá trị và quyền hành động khác nhau.

Một đơn giao hàng qua bốn lớp giá trị

Điểm khác biệt không chỉ là “có AI hay chưa”. Mỗi lớp trả lời một câu hỏi lớn hơn và cho hệ thống thêm quyền hành động: từ lưu sự thật, sang làm rõ tình hình, rồi điều phối công việc, cuối cùng mới là theo đuổi mục tiêu trong giới hạn được giao.

Sơ đồ tổng quan: Bốn lớp phần mềm bao quanh nhu cầu, quyền quyết định và kết quả của khách hàng. 🔍 Click để phóng to

Đừng mặc định rằng mọi tổ chức phải đi thẳng đến Agent

Bốn lớp có thể cùng tồn tại trong một công ty và thậm chí trong cùng một sản phẩm. Một quy trình có thể cần dashboard để quản lý nhìn thấy rủi ro, workflow để đội vận hành phối hợp, nhưng chỉ cho Agent tự xử lý những bước lặp lại và có thể đảo ngược. Mức tự chủ phù hợp phụ thuộc vào độ tin cậy của dữ liệu, quyền được cấp, hậu quả nếu sai và khả năng con người can thiệp.

Chọn điểm bắt đầu bằng câu hỏi về công việc

1. Dữ liệu và trạng thái có đáng tin không? Nếu mọi người chưa thống nhất đơn hàng nào là đúng hoặc trạng thái lấy ở đâu, hãy sửa lớp Ghi nhận trước.
2. Người ra quyết định có nhìn thấy điều cần biết không? Nếu dữ liệu có nhưng vấn đề chỉ lộ ra khi đã trễ, ưu tiên lớp Insight.
3. Công việc đang mắc ở bàn giao hay chờ phê duyệt nào? Nếu nhiều người phải phối hợp qua nhiều hệ thống, ưu tiên lớp Operate và làm rõ người chịu trách nhiệm.
4. Mục tiêu, quyền hạn và ngoại lệ đã đủ rõ để ủy quyền chưa? Chỉ thử Delegate ở việc có thể kiểm soát, đo lường và dừng hoặc hoàn tác; giữ người trong vòng quyết định khi rủi ro cao.

Khi code rẻ hơn, phần khó chuyển sang đâu?

Vibe coding có thể làm prototype nhanh hơn hàng chục lần trong một số tác vụ; điều đó không đồng nghĩa toàn bộ hệ thống vận hành được giao nhanh hơn cùng tỷ lệ. Khi chi phí tạo màn hình và CRUD giảm, tỷ trọng công việc chuyển sang hiểu domain, làm sạch dữ liệu, tích hợp hệ thống cũ, xử lý ngoại lệ, phân quyền, đánh giá chất lượng, quan sát vận hành, quản lý token/thiết bị, khôi phục và xác định ai chịu trách nhiệm. Ước lượng theo chức năng vẫn hữu ích, nhưng chỉ còn phản ánh một phần của bài toán.

Bốn lớp giá trị cũng không đồng nghĩa với bốn mode giao diện. Người dùng có thể xem báo cáo, trực tiếp vận hành, hoặc giao việc cho Agent rồi theo dõi và can thiệp khi cần. Bài 03 sẽ đi tiếp vào ba mode đó và ranh giới tự chủ giữa người với máy.

Domain giúp chọn bối cảnh, không thay thế mạch lập luận

Cùng tên sản phẩm không có nghĩa là cùng quy trình hay cùng mức rủi ro: CRM bán lẻ khác CRM tài chính; MES dệt may khác MES dược phẩm. Bản đồ 46 domain bên dưới là phần tra cứu để kiểm tra độ đa dạng đó — không phải danh sách người đọc phải đi qua trước khi hiểu bốn lớp.

Mở bản đồ tham khảo: 46 domain trong 4 landscape

Đây là bản đồ chiến lược, không phải một bảng phân loại loại trừ lẫn nhau: một tên như OMS có thể xuất hiện trong thương mại điện tử lẫn logistics vì quy trình và người mua khác nhau theo bối cảnh.

Landscape 1/4: Doanh nghiệp nền tảng, bán hàng & khách hàng (11 domain)

Gồm ERP, CRM, HRM/HCM, DMS/ECM, BPM/Case Management, BI/Analytics, OMS/E-commerce, POS/Retail, Contact Center, Marketing Automation/CDP và Hospitality/PMS. Khi Form, CRUD và dashboard trở thành hàng hóa phổ thông, khác biệt chuyển sang workflow, tích hợp sâu, dữ liệu và policy theo ngành, hiểu ngữ cảnh địa phương, cùng khả năng vận hành Agent có kiểm soát.

Landscape 1: 11 domain doanh nghiệp nền tảng — cùng một domain không đồng nghĩa cùng một sản phẩm. 🔍 Click để phóng to

Landscape 2/4: Logistics, chuỗi cung ứng & sản xuất (12 domain; 10 phân khúc MES)

Gồm TMS, WMS, SCM/SRM, Fleet/Telematics, Yard/Port/Terminal, OMS; cùng MES, APS, QMS, EAM/CMMS, PLM và Traceability/Serialization. MES dệt may, cơ khí, điện tử, ô tô, thực phẩm, dược phẩm, hóa chất, xi măng, nhựa và đóng gói phải phản ánh quy trình cùng thiết bị thật của từng nhà máy. Càng gần tài sản vật lý và rủi ro vận hành cao, càng cần telemetry và người xử lý trong vòng quyết định.

Landscape 2: 12 domain logistics và sản xuất, cùng 10 phân khúc MES. 🔍 Click để phóng to

Landscape 3/4: Năng lượng, tiện ích, tài chính & khu vực quản lý chặt (12 domain)

Gồm Utility Billing, ADMS/SCADA/EMS, MDMS/Smart Metering, GIS/Field Service, Oil & Gas, Energy Management/BMS, Core Banking/Loan, Insurance/Claims, Accounting/FP&A, GRC/Audit/Compliance, dịch vụ công và thuế/hải quan. Báo cáo có thể tự động hóa ở rủi ro thấp; quyết định như cấp tín dụng, đổi biểu giá hay điều khiển thiết bị cần policy rõ, bằng chứng, người có thẩm quyền và phê duyệt kép khi hành động khó đảo ngược.

Landscape 3: 12 domain có yêu cầu cao về độ đúng, kiểm toán và trách nhiệm. 🔍 Click để phóng to

Landscape 4/4: Con người, giáo dục, y tế, xây dựng & dịch vụ (12 domain)

Gồm LMS/LXP, SIS, HIS/LIS/PACS, Recruitment/ATS, Workforce Performance, dịch vụ xã hội, BIM, bất động sản, nông nghiệp, thủy sản, truyền thông và dịch vụ pháp lý. Các hệ thống này lệ thuộc mạnh vào ngữ cảnh địa phương, đạo đức, mùa vụ và hiện trường vật lý; Agent có thể hỗ trợ xử lý hồ sơ nhưng không thay bác sĩ, luật sư hay kỹ sư trưởng chịu trách nhiệm.

Landscape 4: 12 domain phụ thuộc nhiều vào con người, tài sản và vận hành thực tế. 🔍 Click để phóng to

Khi suy ngẫm về cách con người thực sự làm việc với các hệ thống phần mềm trong giai đoạn chuyển tiếp sắp tới, tôi nhận ra cấu trúc chia menu kiểu cũ (Module Đơn hàng, Module Kho, Module Xe, Module Báo cáo) đã không còn phù hợp. Trong đầu người dùng doanh nghiệp, họ chỉ có ba nhu cầu tương tác cốt lõi tương ứng với 3 Mode giao diện: Mode Báo cáo (xem tình trạng), Mode Vận hành (làm phần việc của tôi) và Mode AI Agent (giảm vận hành trực tiếp, chuyển sang duyệt và theo dõi nhiều hơn, nhưng vẫn có thể can thiệp trực tiếp bất cứ lúc nào chứ không phải "chịu chết").

Tuy nhiên, khi đào sâu và phản biện lại chính ý tưởng này, có một điểm kiến trúc tối quan trọng cần phải làm rõ: Ba mode này không phải là ba hệ thống rời nhau, càng không chỉ là ba màn hình riêng biệt. Chúng là ba cách con người tương tác với cùng một "sự thật vận hành" (Single Operational Truth) của doanh nghiệp. Cùng một đơn hàng, một chuyến xe hay một lệnh sản xuất phải được nhìn xuyên suốt dưới cả ba góc độ:

1. Thiết kế chống "Chịu chết": Can thiệp trực tiếp phải là đường đi bình thường

Nỗi sợ lớn nhất của doanh nghiệp khi áp dụng AI Agent là mất quyền kiểm soát khi hệ thống gặp tình huống thực tế nằm ngoài dự kiến. Vì vậy, trong Mode AI Agent, câu nói "con người vẫn có thể can thiệp trực tiếp" không được phép thiết kế như một tính năng cứu hộ khẩn cấp giấu sâu trong màn hình Admin. Các nút thao tác sau đây phải nằm ngay trên bảng điều khiển chính của người dùng nghiệp vụ:

• Duyệt / Sửa phương án: Chỉnh lại một phần kế hoạch của AI trước khi cho chạy.
• Tạm dừng (Pause) / Dừng hẳn (Kill): Đóng băng ngay lập tức chuỗi hành động của Agent khi thấy dấu hiệu bất thường.
• Chuyển về thực hiện thủ công (Takeover) / Giao lại cho người khác: Rút quyền của Agent ở một ca khó để điều phối viên trực tiếp xử lý trên Mode Vận hành.
• Hoàn tác / Bù trừ (Rollback / Compensate) & Xem bằng chứng: Đảo ngược trạng thái giao dịch và kiểm tra toàn bộ log dữ liệu mà AI đã dựa vào để ra quyết định[cite: 5].

2. Phản biện cốt lõi: Đừng biến AI Agent thành một "Hàng đợi bấm duyệt mới"

Để giải quyết triệt để mâu thuẫn này, chúng ta không được phép đánh đồng "Mode AI Agent" với một mức độ tự động hóa cố định. Kiến trúc trải nghiệm chuẩn phải tách thành Hai trục độc lập:

• Trục thứ nhất — Người dùng muốn tương tác thế nào? (1) Xem tình hình (Observe) → (2) Tự làm việc (Operate) → (3) Giao AI làm và giám sát (Delegate & Control)[cite: 5].
• Trục thứ hai — Hệ thống được phép tự chủ đến đâu (Autonomy Level)?
  1. Thủ công (Read-only): AI chỉ cung cấp dữ liệu và gợi ý; con người tự làm.
  2. Trợ lý (Copilot): AI đề xuất thao tác; con người xem và xác nhận từng lệnh.
  3. Agent có giám sát (Supervised Agent): AI tự chạy chuỗi công việc trong phạm vi cho phép; con người chỉ duyệt tại các điểm chốt quan trọng (Approval Gates)[cite: 2, 5].
  4. Tự chủ có giới hạn (Bounded Autonomy): AI tự thực hiện toàn bộ việc ít rủi ro; con người theo dõi và xử lý ngoại lệ bị đẩy lên[cite: 5].
  5. Tự hành theo chính sách (Autonomous): AI tự vận hành liên tục theo chính sách; con người chỉ can thiệp khi vượt ngưỡng an toàn.

Với khung tư duy Observe → Operate → Delegate & Control kết hợp cùng ma trận tự chủ này, mọi sản phẩm từ TMS, Quản lý sản xuất (MES), ERP cho đến hệ thống điều hành nội bộ đều có chung một ngôn ngữ thiết kế mạch lạc: giúp con người chuyển mượt mà từ nhìn thấy vấn đề → bắt tay hành động → ủy quyền có kiểm soát[cite: 5].

Sau khi hoàn thiện mô hình 3 Mode giao diện ở Bài 3, tôi tự đặt câu hỏi phản biện cho chính mình: Liệu chúng ta có đang bị mô hình 3 Mode dẫn dắt quá đà mà bỏ sót các xu thế công nghệ cốt lõi khác?

Câu trả lời thẳng thắn là: Có. Ba mode Báo cáo – Vận hành – AI Agent thực chất chỉ là 3 "bề mặt điều khiển" (Control Surfaces) ở lớp trải nghiệm người dùng. Nó chưa phải là toàn bộ kiến trúc của phần mềm tương lai. Trong thực tế vận hành doanh nghiệp, rất nhiều công việc diễn ra mà không hề có người dùng nào đang mở màn hình Agent Mode:

• Ambient / Event-driven Agents (Agent chạy nền theo sự kiện): Agent tự động kích hoạt ngay khi có đơn hàng mới đổ về, khi cảm biến báo dây chuyền sản xuất dừng đột ngột, khi có email khiếu nại hoặc khi chỉ số KPI lệch khỏi ngưỡng[cite: 3, 4].
• Durable Workflows (Quy trình bền vững chạy dài ngày): Một quy trình mua sắm hay vận chuyển có thể kéo dài hàng giờ, hàng ngày hoặc hàng tháng — phải tạm dừng chờ đối tác xác nhận, chờ webhook trả về hoặc chờ thiết bị hoàn tất, đòi hỏi cơ chế lưu trạng thái (checkpoint), hàng đợi (queue), thử lại (retry) và phục hồi (resume).
• Physical / Edge AI & Resource Governance: Agent không chỉ sinh chữ trên màn hình mà còn tác động đến xe tải, ngăn xe bồn, camera, PLC nhà máy và tranh chấp quyết liệt các nguồn tài nguyên hữu hạn (Token, API quota, GPU, kết nối cơ sở dữ liệu)[cite: 2, 3].

1. "Harness" thực sự là gì? Bài học từ những bộ khung thực thi tốt nhất hiện nay

Cần phải phân biệt thật sắc: Một Model (LLM) tự nó chỉ biết sinh token tiếp theo. Một Tool chỉ là một hàm thực hiện hành động. Một MCP Server chỉ là lớp giao thức công bố và kết nối công cụ (nó không phải là workflow engine hay hệ thống phân quyền doanh nghiệp). Một Skill là gói tri thức mô tả cách giải quyết một loại việc. Còn Harness (Execution Kernel) mới chính là bộ khung vận hành bao quanh model — kiểm soát vòng lặp suy luận (Agent loop), trạng thái phiên (Session/State), bộ nhớ ngữ cảnh (Memory/Context), danh mục công cụ (Tool registry), chính sách quyền hạn (Policy), bộ định tuyến mô hình (Model router), hàng đợi bền vững (Durability), quản trị tài nguyên (Resource governor) và lưu vết bằng chứng (Evidence/Trace)[cite: 5, 6].

Tuyệt đối không bao giờ để Model tự ý viết câu lệnh SQL chạy thẳng vào cơ sở dữ liệu, gọi API tùy tiện hay ghi trực tiếp vào thanh ghi PLC của nhà máy. Khi mổ xẻ các kiến trúc hàng đầu thế giới hiện nay, chúng ta thấy không có một "siêu harness" duy nhất, mà phải kết hợp tinh hoa của từng tầng:

• Từ Claude Code / Claude Agent SDK: Học cách khoanh vùng năng lực (capability scoping), sử dụng lifecycle hooks, tách subagent chuyên môn với context riêng và cơ chế nén lịch sử (compaction).
• Từ OpenAI Agents SDK: Học sự tối giản của các nguyên hàm (agent, tool, handoff, guardrail, tracing) trong khi ứng dụng lõi vẫn giữ toàn quyền kiểm soát lưu trữ và phê duyệt.
• Từ LangGraph: Học cách biến trạng thái thực thi (Execution State) thành tài sản hạng nhất với cơ chế Checkpoint và Interrupt/Resume thực sự khi chờ con người phê duyệt.
• Từ Google ADK: Học cách tách bạch rạch ròi giữa Session hiện tại, State tạm thời và Memory dài hạn có thể tìm kiếm xuyên suốt nhiều phiên.
• Từ Temporal: Học kiến trúc Durable Execution — tách biệt Client, Server lưu Event History và các Task Queue/Worker chuyên biệt theo tài nguyên (CPU, GPU, High-memory) để worker có sập thì quy trình vẫn tiếp tục chính xác từ bước dừng.
• Từ LiteLLM Gateway: Học cách quản trị nhiều model qua một cổng tập trung với khóa ảo, ngân sách (budget), giới hạn tốc độ (rate limit), theo dõi chi phí (spend tracking) và tự động chuyển đổi dự phòng (fallback).

2. Ba đường dữ liệu tách biệt & Quản trị 5 loại Ngân sách Token

Trong kiến trúc hoàn chỉnh, 3 Mode giao diện ở mặt trước phải đi qua các đường dữ liệu có kỷ luật chặt chẽ: Báo cáo đọc từ Read Model / OLAP / Materialized View[cite: 5]; Vận hành đi qua Command API và Transaction Workflow[cite: 5]; và AI Agent cũng bắt buộc phải gọi vào chính Command API đó với các năng lực có ngữ nghĩa nghiệp vụ nhỏ gọn (như gọi propose_delivery_plan() hoặc confirm_delivery() kèm bằng chứng và khóa chống lặp idempotency key, chứ không bao giờ gọi một hàm update_transport_plan() khổng lồ ghi đè trực tiếp vào bảng điều xe).

Đồng thời, ở tầng FinOps & Resource Governance, Token không chỉ là tiền API mà là tài nguyên sống còn của hệ thống[cite: 5, 6]. Một phiên chạy của Agent không thể chỉ đặt max_tokens, mà phải được kiểm soát bởi 5 loại ngân sách và ghi log chi tiết từng lần gọi:

3. Điều phối tài nguyên vật lý & Đặt lại đúng vị trí của "Skill"

Trong các bài toán vận tải (TMS), nhà máy sản xuất (MES) hay xi măng, tài nguyên cần điều phối không chỉ có Token và GPU, mà còn là xe tải, tài xế, ngăn xe bồn, dây chuyền máy móc, khuôn đúc, thiết bị PLC và thời gian của người phê duyệt[cite: 2, 3]. Khi Agent tương tác với thiết bị vật lý, nó phải đi qua chuỗi: Agent đề xuất → Policy kiểm tra → Device Command Service → Edge Gateway → Thiết bị → Telemetry Feedback → Cập nhật trạng thái[cite: 2, 3]. Agent tuyệt đối không được coi "đã gọi xong API" là "thiết bị đã thực hiện", mà phải theo dõi đủ 6 trạng thái: command_accepted → command_queued → device_acknowledged → operation_started → operation_completed → operation_verified.

Cuối cùng, chúng ta cũng phải định nghĩa lại Skill. Skill không phải là một đoạn prompt văn bản dài dòng. Một Skill chuẩn công nghiệp phải là một gói cấu trúc được quản lý phiên bản trong Skill Registry:
Skill = Instructions + Tool Permissions + Input Contract + Output Contract + Business Constraints + Escalation Rules + Evaluation Cases + Version.

Nhìn tổng thể, mô hình kiến trúc hoàn chỉnh của chúng ta gồm 3 Mặt phẳng Trải nghiệm (Insight, Execution, Delegation Surface) nằm trên 6 Tầng Nền tảng (Reality & Integration Plane, System of Record & State Plane, Policy & Authority Plane, Agent Harness Plane, Resource & FinOps Plane, và Evidence & Evaluation Plane)[cite: 5, 6]. Siêu trí tuệ trong tương lai có thể thay đổi hoàn toàn "ai nghĩ ra cách làm", nhưng không bao giờ xóa bỏ được nhu cầu về trạng thái chuẩn, quyền hạn, tài nguyên vật lý, giao dịch bất biến và bằng chứng kiểm toán[cite: 2, 5, 6].

Khi nhìn vào 6 tầng nền tảng phức tạp ở Bài 4, tôi chợt nhận ra một nghịch lý đang diễn ra hàng ngày trên thị trường: Nếu toàn bộ các tầng Workflow, Harness, FinOps, Policy và Assurance mới là phần cốt lõi của một hệ thống thông minh, còn nếu chỉ dừng ở CRUD thì chẳng khác nào những phần mềm nhập liệu ngây thơ của năm 2006 — vậy chẳng phải cách chúng ta vẫn Estimate (dự toán) dựa trên danh sách yêu cầu chức năng đang chỉ phản ánh được một phần rất nhỏ của bài toán hay sao?

Và điều này cũng giải thích trọn vẹn hiện tượng đang gây sốt hiện nay: Tại sao những người không chuyên (tay mơ) dùng "Vibe Coding" lại có thể tạo ra một bản Prototype hoặc PoC nhanh gấp 30 đến 50 lần trước đây?

1. Vì sao Vibe Coding tăng tốc "tạo hình" x50, nhưng không tăng tốc "sự tin cậy" x50?

Câu trả lời nằm ở chỗ: người làm bản mẫu bằng Vibe Coding chỉ giải quyết một bài toán tuyến tính cực kỳ đơn giản: Ý tưởng → Giao diện → CRUD → Dữ liệu mẫu → Demo. AI hiện tại đã tự động hóa gần như 100% những việc tốn thời gian trước kia như dựng khung dự án, viết giao diện component, tạo form, nối cơ sở dữ liệu và chạy các luồng thành công (happy path)[cite: 6]. Nhờ đó, thời gian ra bản demo đầu tiên (Time-to-first-demo) giảm xuống hàng chục lần.

Nhưng một bản demo chạy mượt trên máy cá nhân hoàn toàn chưa phải trả bất kỳ một "hóa đơn" nào trong số 70–90% khối lượng công việc thực sự để biến nó thành một hệ thống Production có trách nhiệm:

• Một tay mơ có thể dựng "Ứng dụng quản lý điều xe" trong một buổi sáng. Nhưng hệ thống đó chưa hề có luật tương thích hàng hóa – xe – ngăn chứa, chưa kiểm tra điều kiện bằng lái tài xế, chưa tính giờ cấm đường, chưa có cơ chế giữ chỗ (reservation state) để chống hai người hoặc hai Agent phân bổ trùng một chiếc xe cùng lúc[cite: 3].
• Nó chưa phải xử lý cảnh API định vị GPS bị lỗi phải retry ra sao, dữ liệu thực tế lệch khỏi kế hoạch thì đối soát thế nào, hủy chuyến giữa chừng thì rollback hay bù trừ (compensate) công nợ ra sao[cite: 5, 6].
• Nó chưa phải đối mặt với dữ liệu lịch sử bẩn của 10 năm trước, chưa có phân quyền đa đơn vị (multi-tenant), chưa có giới hạn ngân sách Token chống lặp vô tận, chưa kết nối với trạm cân hay PLC nhà máy, và chưa có nhật ký bằng chứng (audit trail) khi xảy ra gian lận[cite: 2, 3, 5, 6].

2. Không phải mọi thứ ngoài CRUD đều là "Yêu cầu phi chức năng" (NFR)

Một sự nhầm lẫn nguy hiểm khác trong các tài liệu báo giá hiện nay là gom toàn bộ phần chìm kể trên vào khái niệm "Yêu cầu phi chức năng" (Non-Functional Requirements). Đúng là hiệu năng, bảo mật, độ sẵn sàng hay độ trễ thuộc về NFR. Nhưng những khả năng như: "AI tự động phát hiện nguy cơ trễ chuyến, lập 3 phương án điều xe thay thế không vượt tải, không trùng lịch và tự động đẩy yêu cầu xin trưởng bộ phận phê duyệt nếu chi phí phát sinh vượt ngưỡng 10%" — đó không phải là NFR, mà là Chức năng nghiệp vụ bậc cao (Agentic Functional Capability) của hệ thống thế hệ mới[cite: 3, 5]!

Khi phần mềm tiến hóa qua 6 tầng — từ (1) Record → (2) Transaction → (3) Workflow → (4) Decision Support → (5) Supervised Agent → (6) Bounded Autonomy — tỷ trọng công sức kỹ thuật dịch chuyển một cách căn bản:

3. Bức tranh Kiến trúc Giá trị mới & Công thức Estimate 6 lớp

Hãy quan sát kỹ bản đồ "Khách hàng ở tâm — Kiến trúc giá trị của phần mềm tương lai" dưới đây[cite: 6]. Sáu vòng tròn đồng tâm thể hiện rõ: Lớp 5 (Build, Test, Documentation, Migration) có khối lượng công việc rất lớn nhưng đang bị Agent hóa mạnh mẽ làm chi phí giảm sâu[cite: 6]. Ngược lại, độ phức tạp và giá trị kinh doanh dồn mạnh về Lớp 1 (Ngữ cảnh & Mục tiêu), Lớp 2 (Nghiệp vụ & Chính sách), Lớp 3–4 (System of Record, Workflow, Tích hợp) và Lớp 6 (Runtime, Monitoring, FinOps, Security, Evidence)[cite: 6]:

Bản đồ Chiến lược 06: Bốn trục đánh giá 6 lớp kiến trúc giá trị và sự dịch chuyển sang Onshore Accountability + Agentic Delivery[cite: 6]. 🔍 Click để phóng to

Như vậy, khối lượng code giao diện (Code volume) giảm hoàn toàn không đồng nghĩa với độ phức tạp hệ thống (System complexity) giảm. Nếu công ty phần mềm vẫn báo giá theo kiểu cũ (đếm số màn hình và số API CRUD), chúng ta sẽ tự sát vì phần khách hàng nhìn thấy để trả tiền đang co lại, trong khi phần ngầm quyết định hệ thống chạy đúng lại phình to.

Từ nay, cấu trúc WBS và báo giá bắt buộc phải tách thành 6 nhóm hạng mục với đơn vị đo mới:

1. Functional Surface (Lớp Giao diện & CRUD nền): Đo bằng số màn hình, biểu mẫu, API giao dịch và báo cáo chuẩn. (Không bỏ CRUD vì nó là System of Record và điểm can thiệp thủ công, nhưng không để nó đại diện cho cả dự án).
2. Operational Core (Lớp Vận hành & Quy trình): Đo bằng số trạng thái (States), bước chuyển (Transitions), luật nghiệp vụ, vai trò và luồng ngoại lệ[cite: 5, 6].
3. Intelligence Layer (Lớp Trí tuệ & Agent): Đo bằng số tác vụ tự chủ, số Skill/Tool, số vòng lặp suy luận và cổng bàn giao (Handoff/Approval gates)[cite: 5, 6].
4. Assurance Layer (Lớp Bảo đảm & Bằng chứng): Đo bằng số kịch bản kiểm thử (Eval scenarios), ngưỡng nghiệm thu, lưu vết kiểm toán (Audit trail) và kịch bản hoàn tác (Rollback/Compensation)[cite: 5, 6].
5. Runtime & FinOps Layer (Lớp Vận hành & Tài nguyên): Đo bằng thiết kế Worker queue, giới hạn đồng thời, Model routing, ngân sách Token và tích hợp thiết bị vật lý (Device protocol/Telemetry)[cite: 3, 5, 6].
6. Transition Layer (Lớp Chuyển đổi): Đo bằng số bảng dữ liệu lịch sử cần làm sạch, thời gian chạy song song với hệ thống cũ (Legacy coexistence) và đào tạo vận hành[cite: 6].

Đơn vị bán hàng của chúng ta phải dứt khoát bước qua cuộc chuyển dịch: từ bán "40 màn hình và 120 API" sang bán "Năng lực xử lý trọn vẹn một quy trình trong ranh giới chính sách, với mức tự chủ xác định, chi phí kiểm soát và bằng chứng thành công rõ ràng"[cite: 5, 6].

Trong suốt hai thập kỷ qua, ngành gia công phần mềm châu Á nói chung và Việt Nam nói riêng đã phát triển rực rỡ dựa trên mô hình Labor Arbitrage (Chênh lệch giá nhân công): Khách hàng ở Nhật, Mỹ, Âu thuê một công ty tư vấn đầu chuỗi (Prime/Onshore); công ty đó lại qua một vài tầng môi giới (Broker/SI) để thuê tiếp các đội Offshore giá rẻ hơn, bán lại số người/tháng (Man-Month) và số giờ công lập trình[cite: 5, 6].

Nhưng khi lắp ghép tất cả những gì chúng ta đã phân tích ở 5 bài luận trước — từ sự sụt giảm tỷ trọng code CRUD, tốc độ tạo hình của AI cho đến kiến trúc Agent Harness — chuỗi cung ứng kiểu cũ (Khách hàng → Broker 1 → Broker 2 → SI → Công ty Offshore → Freelancer) lộ rõ tử huyệt: mỗi tầng trung gian làm rơi rụng ngữ cảnh nghiệp vụ, cộng thêm một lớp biên lợi nhuận và làm loãng hoàn toàn trách nhiệm khi hệ thống chạy sai.

1. "Context Onshore, Execution Agentic": Vì sao Onshore SE tăng lên nhưng không đẩy việc về Offshore như trước?

Hãy nhìn thẳng vào hành vi thực tế đang hình thành: Đội ngũ Kỹ sư giải pháp và Tư vấn làm việc trực tiếp với khách hàng (Onshore SE / Local Consultants) không những không giảm đi mà còn tăng mạnh cả về quy mô lẫn vị thế[cite: 5, 6]. Tại sao? Vì AI dù thông minh đến mấy cũng không tự có được:

• Ngữ cảnh chính trị ngầm và sự giằng co lợi ích giữa các phòng ban trong nội bộ khách hàng[cite: 6].
• Ý định thực sự đằng sau những lời mô tả mơ hồ và những ngoại lệ chưa từng được viết thành tài liệu[cite: 6].
• Quyền truy cập hợp pháp vào hệ thống dữ liệu lõi, sự tin cậy trực tiếp của lãnh đạo khách hàng và tư cách chịu trách nhiệm pháp lý tại chỗ[cite: 1, 2, 6].

Nhưng điều làm đảo lộn toàn bộ ngành Offshore nằm ở bước tiếp theo: Sau khi Onshore SE nắm bắt và chốt được bài toán với khách hàng, họ sẽ trực tiếp sử dụng hệ thống AI Agent (cả Common Agent và Private Agent) để lập kế hoạch, dựng giao diện, viết code CRUD, sinh kịch bản test và kiểm chứng ngay lập tức — thay vì đóng gói tài liệu rồi đẩy về cho một đội Offshore đông đảo ở nước ngoài như trước[cite: 5, 6]!

2. Bàn cờ Lợi ích nhóm & Ba giai đoạn chuyển dịch của thị trường

Sự va chạm lợi ích giữa các bên tham gia sẽ đẩy thị trường đi qua 3 giai đoạn tất yếu:

1. Giai đoạn 1 — Dùng AI kín trong nội bộ (Arbitrage ngầm): Nhà cung cấp vẫn ký hợp đồng báo giá theo Man-Month (MD) như cũ, nhưng bên dưới âm thầm dùng Agent để giảm 50–70% công sức thực thi và hưởng trọn phần chênh lệch năng suất.
2. Giai đoạn 2 — Khách hàng đòi minh bạch và chia sẻ năng suất: Bộ phận mua hàng (Procurement) và IT của khách hàng nhận ra tốc độ của AI. Họ bắt đầu hỏi "Agent của các anh ở đâu?", ép giảm đơn giá MD, yêu cầu hợp đồng trọn gói (Fixed-price), đòi quyền xem log kiểm chứng và kiểm soát chi phí model.
3. Giai đoạn 3 — Mua "Năng lực vận hành có kiểm soát" (Operating Capability): Khách hàng không còn mua "20 lập trình viên" nữa[cite: 5, 6]. Họ mua một kết quả vận hành trọn gói: phí khám phá bài toán + phí nền tảng/Harness + phí triển khai tích hợp + phí vận hành định kỳ (Runtime/FinOps) gắn với cam kết SLA/KPI[cite: 5, 6].

3. Offshore sẽ chết ở đâu và sẽ sống (thậm chí bứt phá) ở đâu?

Vậy Offshore có biến mất hoàn toàn không? Câu trả lời sắc bén nhất là: Offshore không biến mất vì địa lý không còn quan trọng; nó chỉ suy tàn ở những nơi bán công việc lập trình lặp lại, và sẽ chuyển hóa từ bán "Capacity (Số lượng người)" sang bán "Capability (Năng lực chuyên sâu)"[cite: 5, 6]:

• Nơi Offshore truyền thống sẽ chết (Rent-a-developer): Cắt giao diện theo thiết kế, viết CRUD tiêu chuẩn, xử lý ticket đơn giản, viết testcase cơ bản, chuyển đổi ngôn ngữ code cơ học và cung cấp số lượng lớn nhân sự Junior[cite: 4, 5, 6]. Toàn bộ phần này Common Agent và Onshore SE sẽ nuốt trọn[cite: 5, 6].
• Nơi Remote Specialist Pods sẽ sống khỏe và tăng trưởng cao:
  1. Giải phẫu và tích hợp hệ thống cũ (Legacy ERP/MES/TMS): Những hệ thống 10–20 năm tuổi không có tài liệu, cấu trúc dữ liệu chồng chéo và đầy rẫy các bản vá ngầm mà không một AI phổ thông nào tự hiểu được[cite: 3, 5, 6].
  2. Thế giới vật lý & Hiện trường: Kết nối PLC, cảm biến IoT, camera, thiết bị đo đếm điện/nước, định vị xe bồn và các hệ thống đòi hỏi khóa an toàn phần cứng[cite: 2, 3, 6].
  3. Xây dựng Agent Harness, Private Agent & Kiểm chứng độc lập: Thiết kế bộ Skill chuyên ngành, xây dựng bộ dữ liệu kiểm thử (Evaluation Sets), tinh chỉnh FinOps và rà soát bảo mật độc lập[cite: 5, 6].
  4. Vận hành liên tục 24/7 (Managed Operations): Nơi các Agent tự động theo dõi hệ thống ngày đêm và đội ngũ kỹ sư chuyên gia từ xa xử lý các sự cố, ngoại lệ vượt ngưỡng theo cam kết SLA[cite: 5, 6].

Lời kết cho Sáu bài đầu: Định vị để Dẫn dắt cuộc chơi

Nhìn lại toàn bộ hành trình tư duy từ Bài 1 đến Bài 6, chúng ta thấy một bức tranh vô cùng nhất quán. Khi tiến tới kỷ nguyên của AI Agent và Siêu trí tuệ, tài sản khan hiếm nhất không còn là khả năng viết ra những dòng code. Thứ khan hiếm thực sự là quyền truy cập hệ thống, dữ liệu chuẩn xác, ngữ cảnh doanh nghiệp, năng lực tích hợp với thế giới vật lý, bằng chứng kiểm chứng được và bản lĩnh đứng ra chịu trách nhiệm pháp lý cuối cùng[cite: 1, 2, 3, 5, 6].

Đối với một doanh nghiệp công nghệ như Fabbi hay bất kỳ tổ chức nào muốn vươn lên dẫn đầu trong thập kỷ tới, vị thế chiến thắng không nằm ở việc cố giữ vai trò "trung gian bán đội ngũ Offshore giá rẻ", mà là chuyển mình quyết liệt thành một Onshore Accountable Operator vận hành trên mạng lưới Agentic Delivery Network[cite: 6] — nơi hội tụ đủ 6 trụ cột:

Tương lai không xóa bỏ phần mềm, cũng không xóa bỏ việc thuê ngoài. Tương lai chỉ đào thải những ai coi phần mềm là việc gõ code vô hồn, và trao vương miện cho những kiến trúc sư biết kết hợp trí tuệ của máy với thể chế, niềm tin và trách nhiệm của con người[cite: 5, 6].

Để chuyển đổi một hệ thống phần mềm truyền thống lên kiến trúc 2036 và hướng tới 2046 mà không làm đứt gãy vận hành, doanh nghiệp cần thực thi Playbook 5 bước (Agentic Strangler Fig): (1) Tách Read Model mở khóa Mode Báo cáo/Insight; (2) Bọc Command API có ngữ nghĩa nghiệp vụ và dựng cổng Policy/Authority; (3) Thay thế các màn hình CRUD phân mảnh bằng Workbench theo vai trò trên nền Durable Workflow; (4) Cấy Agent Harness và mở khóa tự chủ qua 4 nấc (Shadow → Copilot → Supervised → Bounded Autonomy); và (5) Tách rời lớp lập kế hoạch để sẵn sàng cắm Siêu trí tuệ vào năm 2046 trong khi giữ nguyên 8 trụ cột trường tồn bên dưới.

Infographic minh họa: Lộ trình chuyển đổi không gián đoạn từ Legacy tới kiến trúc 2036 và 2046. 🔍 Click để phóng to

Khi đóng gói Agent Skill chuyển đổi UX 3 Mode theo cấu trúc Skill = Instructions + Tool Permissions + Input Contract + Output Contract + Business Constraints + Escalation Rules + Evaluation Cases + Version, chúng ta tự động hóa được việc phân rã các màn hình CRUD cũ thành 3 mặt phẳng tương tác chuẩn mực. Song song đó, đội ngũ kỹ sư con người phải nâng cấp theo 2 nhánh: Onshore SE / Accountable Architect và Deep-Tech / Harness & Integration Engineer.

Infographic minh họa: Cấu trúc hợp đồng Agent Skill và khung năng lực hai nhánh của kỹ sư thế hệ mới. 🔍 Click để phóng to