Blog / Series AI Agents Thực Chiến

State of AI Engineering 2026: vì sao observability đang trở thành control plane ngầm của agent production

Vì sao báo cáo này đang nóng đúng lúc

Phần lớn tin tức AI hàng ngày xoay quanh model mới, benchmark mới hoặc một demo gây choáng. Nhưng bước sang 2026, một câu hỏi thực tế hơn đang nổi lên rất nhanh: sau khi agent được đưa vào production, đội ngũ nào giữ được nó ổn định, rẻ, có thể kiểm soát và có thể giải thích?

Báo cáo State of AI Engineering 2026 của Datadog gây chú ý vì trả lời câu hỏi đó bằng telemetry vận hành thay vì bằng cảm tính. Một vài số liệu đáng chú ý:

• hơn 70% tổ chức trong mẫu đang dùng từ ba model trở lên;
• tỷ lệ dùng framework agent gần như tăng gấp đôi theo năm;
• 69% token đầu vào đang bị tiêu cho system prompts, policy và tool guidance;
• chỉ khoảng 28% các lượt gọi model có dấu hiệu tận dụng prompt caching;
• context size trung bình tiếp tục tăng mạnh khi đội ngũ nhồi thêm lịch sử, tài liệu, policy và tool output vào cùng một run.

Nếu đọc kỹ, đây không phải chỉ là báo cáo về hiệu năng model. Nó là báo cáo về sự phình to của hệ thống bao quanh model. Và khi hệ thống phình to, lợi thế không còn nằm ở việc viết prompt khéo nhất. Lợi thế chuyển sang đội ngũ nào nhìn thấy được toàn bộ run của agent như một hệ phân tán có state, policy, cost, retries và failure boundaries.

Điểm này nối rất tự nhiên với bài Model Routing 2026: khi doanh nghiệp không còn đặt cược vào một model duy nhất, họ buộc phải xây một lớp quan sát và điều phối tốt hơn. Còn nếu đi xa hơn tới hành động thật, bài Agent Reliability 2026 cho thấy cùng một vấn đề dưới góc độ niềm tin vận hành.

Observability trong agent không còn là chuyện log cho đẹp

Với phần mềm truyền thống, observability thường được hiểu là metrics, logs, traces để debug sự cố. Với agent, định nghĩa này còn đúng nhưng chưa đủ. Agent có control flow do model quyết định, context thay đổi theo từng bước, tool fan-out động và kết quả phụ thuộc vào prompt layout lẫn dữ liệu bên ngoài. Vì vậy observability của agent phải trả lời thêm bốn câu hỏi:

• agent đã thấy chính xác ngữ cảnh nào trước khi ra quyết định;
• nó chọn model, prompt, tool và nhánh workflow nào, vì sao;
• chi phí, độ trễ và failure rate phát sinh ở bước nào trong chuỗi;
• nếu kết quả cuối cùng sai, sai do model, do dữ liệu, do policy hay do orchestration.

Nói ngắn gọn, observability trong kỷ nguyên agent không còn là kính chiếu hậu. Nó là bảng điều khiển trung tâm để đội ngũ quyết định có nên cho agent đi tiếp, đổi model, giảm quyền, bật approval hay rollback chiến lược prompt.

Đó cũng là lý do bài workflow, memory, approval vẫn rất quan trọng. Workflow cho biết run đang ở đâu. Memory cho biết agent đang mang theo ràng buộc nào. Approval cho biết đâu là điểm dừng an toàn. Observability là lớp gắn cả ba thứ đó thành một vòng phản hồi vận hành.

Vì sao thời điểm này khác 12 tháng trước

Một năm trước, nhiều đội ngũ còn ở giai đoạn “cắm model vào sản phẩm” và đo thành công bằng số lượt dùng thử. Hiện nay, nhiều hệ thống đã đi sang mức agent có quyền gọi API, truy cập tool, thay đổi dữ liệu hoặc phối hợp qua nhiều service boundary. Chỉ riêng việc framework adoption tăng nhanh đã đủ để chứng minh một thực tế: nhiều team đang mua tốc độ phát triển bằng độ mờ trong runtime.

Khi đó, log thông thường không còn đủ. Đội ngũ cần trace theo run, theo step, theo tool, theo prompt version, theo policy decision và theo model route. Nếu không, mọi lỗi đều trông giống nhau ở bề mặt: “agent vừa làm gì đó không đúng”.

Use case end-to-end: agent hỗ trợ on-call cho hệ thống SaaS

Hãy lấy một use case thực tế hơn cả chatbot hỗ trợ: một agent on-call nội bộ cho đội vận hành SaaS. Nhiệm vụ của nó là đọc alert, gom logs, query dashboard, tra playbook và đề xuất hoặc thực hiện một số hành động an toàn như restart worker, giảm traffic, tạm tắt rollout hay escalte sang người trực.

Bước 1: nhận tín hiệu sự cố và dựng đúng ngữ cảnh ban đầu

Alert chỉ là điểm bắt đầu. Agent phải biết đây là lỗi latency tăng, error rate tăng hay queue backlog. Nó phải kéo thêm dấu vết từ metrics, logs, traces, deployment timeline và status của các service phụ trợ. Nếu ngữ cảnh dựng sai ngay từ đầu, mọi reasoning phía sau đều trở thành reasoning trên dữ liệu sai.

Đây là nơi bài MCP là gì rất hữu ích như một nền tảng kết nối tool. Nhưng có tool chưa đủ. Bạn còn phải biết mỗi tool được gọi khi nào, dữ liệu nào được coi là nguồn chân lý và công cụ nào chỉ mang tính tham khảo.

Bước 2: quyết định tuyến điều tra

Một incident thật không đi theo một kịch bản duy nhất. Có lúc nguyên nhân nằm ở rollout mới, có lúc là nhà cung cấp model chậm, có lúc là cache miss tăng vì prompt layout vừa thay đổi. Agent phải chọn một nhánh điều tra phù hợp thay vì gọi hàng loạt tool vô tội vạ.

Nếu không có observability tốt, đội ngũ sẽ không biết agent đang lãng phí thời gian ở đâu: query dashboard quá rộng, retry cùng một truy vấn, gọi model đắt cho tác vụ tóm tắt đơn giản, hay kéo cả transcript khổng lồ vào mỗi lần suy luận.

Bước 3: đề xuất hoặc thực thi hành động

Đây là chỗ ranh giới giữa “trợ lý hữu ích” và “tự động hóa nguy hiểm” lộ rõ nhất. Ví dụ:

• restart worker có thể an toàn nếu đã qua ngưỡng alert chuẩn hóa;
• rollback deployment có thể cần approval vì tác động rộng hơn;
• chuyển toàn bộ lưu lượng sang model khác có thể cứu SLA nhưng làm chi phí tăng vọt;
• tắt một bước guardrail để giảm latency có thể khiến rủi ro an toàn tăng mạnh.

Observability lúc này không chỉ ghi nhận agent đã làm gì. Nó là cơ sở để policy engine quyết định agent được phép làm gì trong bối cảnh cụ thể. Nếu không có đầy đủ trace của tình huống, approval của con người cũng dễ trở thành một cú bấm mù.

Bước 4: hậu kiểm và biến incident thành dữ liệu học

Một agent on-call chỉ đáng giá nếu sau mỗi lần xử lý, hệ thống trở nên tốt hơn. Nghĩa là incident phải được nén thành regression suite, routing rule, playbook hoặc policy mới. Nếu không làm được bước này, observability chỉ giúp chữa cháy chứ chưa trở thành lợi thế hệ thống.

Đây là khác biệt lớn giữa tổ chức “có log” và tổ chức “có learning loop”. Bên thứ nhất nhớ sự cố đã xảy ra. Bên thứ hai khiến cùng kiểu sự cố đó khó lặp lại hơn ở lần sau.

Tầng hệ thống: trace, state, evaluation, routing và approval

Nếu nhìn agent như một hệ thống sản xuất thực thụ, observability phải bám vào ít nhất năm lớp sau.

1. Trace theo run, không chỉ theo request

Nhiều đội ngũ vẫn quan sát AI bằng từng API call rời rạc. Cách này bỏ lỡ bản chất của agent: giá trị và rủi ro nằm ở chuỗi quyết định. Một run cần trace được từ đầu đến cuối: input nào khởi tạo nó, prompt version nào được dùng, model nào được route tới, tool nào được gọi, state nào đã đổi và approval nào đã xảy ra.

Không có run trace, bạn rất khó phân biệt lỗi của model với lỗi của orchestration. Và khi lỗi bị gộp nhầm, biện pháp sửa thường sai theo.

2. State phải là đối tượng hạng nhất

Một agent production nên luôn có state rõ ràng như alert_received, context_built, hypothesis_ranked, action_pending_approval, rollback_executed hoặc escalated_to_human. State làm hai việc cùng lúc: nó giúp con người hiểu run đang ở đâu, và giúp máy áp policy theo từng chặng.

Bài Agentic Cloud 2026 đi rất sâu vào tầng hạ tầng này: càng nhiều agent chạy dài hơi, state càng trở thành phần không thể đính kèm tạm bợ trong prompt.

3. Evaluation phải đi cùng observability

Rất nhiều đội ngũ thu log rất đẹp nhưng không kết nối log đó với đánh giá chất lượng. Khi đó observability chỉ trả lời “đã xảy ra chuyện gì”, chứ không trả lời “chuyện đó tốt hay xấu theo mục tiêu kinh doanh”.

Một lớp evaluation thực dụng cho agent nên đo:

• tỷ lệ run đạt outcome đúng;
• tỷ lệ escalation sang người thật;
• số tool call trung bình trên một run thành công;
• chi phí token theo từng stage;
• tỷ lệ retry và rollback;
• độ lệch giữa confidence của agent và kết quả thật.

Nếu observability là mắt, evaluation là thước đo. Chỉ có mắt mà không có thước, đội ngũ vẫn khó biết nên tối ưu chỗ nào trước.

4. Routing và prompt caching là bài toán vận hành, không chỉ tối ưu chi phí

Một insight rất đáng giá từ báo cáo Datadog là 69% token đầu vào rơi vào system prompts, trong khi prompt caching vẫn bị bỏ phí nhiều. Đây không chỉ là câu chuyện tiền bạc. Nó là dấu hiệu cho thấy rất nhiều agent đang được scaffold quá nặng, dẫn tới latency tăng, prompt khó kiểm soát và thay đổi nhỏ cũng có thể phá cache prefix.

Khi đội ngũ xem prompt như code sống, observability cần chỉ ra block nào ổn định, block nào thường xuyên thay đổi, block nào đang làm cache miss tăng. Kết hợp với model routing, điều này mở ra một đòn bẩy rất thực dụng: model nhẹ cho bước phân loại, model mạnh cho synthesis, và chỉ đưa context thật sự cần thiết vào từng chặng.

5. Approval và audit trail phải bám vào action boundary

Với agent có quyền hành động, observability không dừng ở “nó đã gọi tool”. Bạn còn phải có audit trail cho biết ai cấp quyền, điều kiện gì thỏa mãn, payload nào đã được gửi đi và hành động đó có thể đảo ngược hay không. Nếu không, sau một sự cố bạn sẽ chỉ có một đống log kỹ thuật nhưng không có chuỗi trách nhiệm rõ ràng.

Điểm này chạm trực tiếp tới bài Agent Security 2026 và bài MCP Authorization 2026: khi agent kết nối ra ngoài và chạm vào hệ thống thật, observability phải đi cùng least privilege, consent và ranh giới hành động.

Trade-off, failure modes và nơi nhiều đội ngũ đang tự tạo tech debt

1. Framework giúp ship nhanh, nhưng rất dễ che giấu chi phí thực

Framework agent hấp dẫn vì chỉ vài import là có planner, memory, tool-use, retries và branching. Nhưng sự tiện lợi đó thường che đi số bước thừa, số lần model bị gọi lặp và số trạng thái trung gian không ai thật sự hiểu. Báo cáo Datadog cho thấy adoption tăng mạnh; điều này vừa là tín hiệu trưởng thành, vừa là cảnh báo về tech debt đang được tích lũy theo kiểu rất mới.

2. Multi-model làm hệ thống linh hoạt hơn, nhưng governance khó hơn

Dùng ba hay sáu model giúp tối ưu chất lượng theo workload. Nhưng mỗi model thêm vào là một biến số mới về latency, failure profile, prompt behavior và vòng đời deprecation. Nếu observability không đủ sâu, tổ chức dễ rơi vào trạng thái “fleet model đông nhưng không ai dám bỏ model cũ”, đúng như logic tech debt mà báo cáo nêu ra.

3. Failure modes phổ biến nhất của agent production

• Invisible cost creep: chất lượng không tăng bao nhiêu nhưng token, tool fan-out và latency tăng dần qua từng bản phát hành.
• Policy drift: prompt nói một đằng, policy thật ở backend làm một nẻo.
• Trace gap: run hỏng nhưng không thể tái dựng đủ ngữ cảnh để postmortem.
• Approval theater: con người vẫn phải bấm duyệt, nhưng không có đủ tín hiệu để duyệt có chất lượng.
• Cache miss by design: prompt layout thay đổi liên tục, khiến hệ thống luôn trả giá inference như thể mọi thứ đều mới.
• Tool sprawl: agent có quá nhiều công cụ na ná nhau, dẫn tới chọn sai đường mà không ai nhận ra sớm.

4. Không phải nơi nào cũng nên theo đuổi observability tối đa

Quan sát sâu hơn đồng nghĩa với thêm instrumentation, thêm storage, thêm chi phí xử lý và thêm bề mặt dữ liệu nhạy cảm cần bảo vệ. Một agent viết gợi ý nội dung nội bộ có thể không cần full-fidelity tracing như một agent có quyền hoàn tiền, rollback deployment hay sửa CRM. Bài toán đúng không phải là “trace tất cả bằng mọi giá”, mà là trace đủ sâu ở nơi hậu quả khi sai đủ lớn.

Checklist triển khai thực dụng trong 90 ngày

30 ngày đầu: dựng xương sống quan sát

• Chuẩn hóa khái niệm run, step, tool call, approval trong toàn hệ thống.
• Gắn trace ID xuyên suốt từ request người dùng tới mọi model call và action.
• Lưu prompt version, model route, token cost và latency theo từng bước.
• Chọn 1 workflow hẹp nhưng có giá trị thật để làm chuẩn đo đầu tiên.

30 ngày tiếp theo: nối observability với evaluation

• Xây dashboard outcome thay vì chỉ dashboard hạ tầng.
• Biến lỗi production thật thành regression suite.
• Đo cache-hit rate, escalation rate, retry rate và rollback rate.
• Phân tách lỗi do model, lỗi do dữ liệu và lỗi do orchestration.

30 ngày cuối: dùng tín hiệu để kiểm soát quyền và chi phí

• Thiết kế action tiers: chỉ đọc, đề xuất, auto-execute có điều kiện, bắt buộc approval.
• Route model theo stage thay vì dùng một model cho mọi bước.
• Tối ưu prompt layout để tăng khả năng caching cho phần scaffold ổn định.
• Loại bỏ tool trùng chức năng hoặc ít dùng để giảm nhánh quyết định vô ích.
• Chỉ mở rộng autonomy sau khi có đủ bằng chứng reliability từ trace và evaluation.

Insight cuối cùng: trong làn sóng agent mới, ai nhìn thấy hệ thống rõ hơn sẽ đi xa hơn ai có demo đẹp hơn

Báo cáo Datadog đáng chú ý không phải vì nó kể lại một tin AI giật gân. Nó đáng chú ý vì nó xác nhận một chuyển động sâu hơn của thị trường: AI engineering đang dần giống platform engineering hơn là prompt tinkering. Đội ngũ thắng cuộc sẽ không chỉ là đội có model tốt nhất, mà là đội dựng được vòng phản hồi tốt nhất giữa quan sát, đánh giá, điều phối và kiểm soát quyền.

Với agent production, observability không phải một phụ kiện DevOps gắn sau cùng. Nó là lớp giúp doanh nghiệp trả lời những câu hỏi sống còn: khi nào nên tin agent, khi nào nên giảm quyền, khi nào nên route sang model khác, khi nào cần con người vào cuộc và lần thất bại này phải biến thành học hỏi hệ thống ra sao.

Nếu 2025 là năm của “agent có làm được không”, thì 2026 đang rất nhanh trở thành năm của một câu hỏi sắc hơn nhiều: bạn có nhìn thấy agent của mình đủ rõ để cho nó quyền hành động hay không. Đó mới là control plane thật của agent production.