> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloudthinker.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Chương 11 · Danh mục lỗi, và tự xây hay mua dành cho kỹ sư

> Nhận ra mười hai kiểu lỗi production của agent vận hành qua tín hiệu sớm, áp dụng cách khắc phục cho từng kiểu và quyết định tự xây hay mua.

*Các chương trình agent hiếm khi thất bại một cách chung chung. Chúng thất bại theo những cách cụ thể, lặp lại được. Đây là mười hai cách, mỗi cách kèm tín hiệu xuất hiện đầu tiên và cách khắc phục, tiếp theo là câu hỏi tự xây hay mua đúng như kỹ sư thực sự đối mặt.*

## 11.1 Danh mục

Đọc mỗi hàng theo cách: nếu thấy tín hiệu, hãy áp dụng cách khắc phục trước khi tín hiệu đó biến thành sự cố ngừng dịch vụ. Chương trong ngoặc là nơi cách khắc phục được xây dựng.

| Kiểu lỗi | Biểu hiện | Tín hiệu sớm | Cách khắc phục |
| - | - | - | - |
| 1. Cuộc điều tra vô tận | Agent liên tục thăm dò, không kết luận được gì và đẩy chi phí lên | Số bước và chi phí mỗi cuộc điều tra tăng dần; thời gian đến phát hiện đầu tiên kéo dài | Giới hạn bước, token và thời gian; bộ phát hiện vòng lặp; chuyển cấp kèm các phát hiện dở dang khi hết ngân sách (Ch. 1) |
| 2. Ngập ngữ cảnh | Chất lượng giảm khi output thô của công cụ lấp đầy cửa sổ ngữ cảnh | Số token mỗi bước tăng; độ chính xác giảm với sự cố kéo dài | Giới hạn kích thước kết quả công cụ; nén kèm con trỏ về bằng chứng; xếp hạng lại kết quả truy xuất (Ch. 2, 3) |
| 3. Sai một cách tự tin | Kết luận trôi chảy, dẫn chứng đầy đủ nhưng sai cơ chế | Các khẳng định không truy về được bằng chứng; các lần từ chối gắn tag "wrong diagnosis" | Mọi khẳng định liên kết với bằng chứng; chấm điểm eval theo lớp; con người chấm một mẫu (Ch. 7) |
| 4. Xác minh hình thức | Được đánh dấu "đã sửa" vì cảnh báo đã hết, nhưng lỗi vẫn còn | Sự cố lặp lại; chênh lệch giữa điểm chẩn đoán và điểm khắc phục trong eval | Xác minh theo trạng thái hệ thống, không theo cảnh báo; cửa sổ theo dõi sau sửa; chấm điểm khắc phục riêng (Ch. 1, 7) |
| 5. Bão cảnh báo thành bão chi phí | Một đợt sự cố đánh thức bộ điều tra hàng trăm lần | Số event được đẩy lên điều tra tăng vọt; chi tiêu nhảy vọt ở điểm nối đó | Tương quan và giảm chấn bão cảnh báo trước khi điều tra; giới hạn số cuộc điều tra trong mỗi khoảng thời gian (Ch. 4) |
| 6. Sự cố injection | Agent làm theo chỉ dẫn tìm thấy trong log, ticket hoặc output công cụ | Phát hiện mẫu injection; đích đến outbound mới; chuỗi gọi công cụ bất thường | Toàn bộ lớp phòng thủ của Ch. 5; chạy red-team định kỳ; theo dõi nguồn gốc của từng memory |
| 7. Mệt mỏi phê duyệt | Người duyệt phê duyệt mà không đọc; cổng kiểm soát trở thành hình thức | Trên 95% phê duyệt với thời gian review gần bằng không. Trên 95% với thời gian review thực và thời gian chờ dài là tín hiệu ở Chương 6 để nâng cấp lớp hành động đó | Nâng cấp lớp hành động đó, hoặc làm yêu cầu phê duyệt dễ đánh giá hơn; đo lường cổng kiểm soát (Ch. 6) |
| 8. Đầu độc memory | Một kết luận sai dẫn dắt các sự cố sau này | Cờ mâu thuẫn; cùng một chẩn đoán sai lặp lại cho một lớp | Ghi nguồn gốc; để memory cũ phai dần; giữ một tầng do con người tuyển chọn; review theo lịch (Ch. 2, 9) |
| 9. Công cụ tràn lan | Hàng chục công cụ mỏng, chọn sai công cụ, prompt dễ vỡ | Lỗi chọn công cụ tăng; chi phí ngữ cảnh mỗi bước leo thang | Gộp thành ít công cụ hơn, được định hình quanh ý định (Ch. 3) |
| 10. Thay đổi vô hình | Hành vi thay đổi mà không gì trong diff giải thích được | Metric drift thay đổi dù không có release | Đánh phiên bản mọi thứ như một artifact; ghim phiên bản; kiểm soát deploy (Ch. 9) |
| 11. Suy giảm khi đổi mô hình | Nâng cấp mô hình âm thầm làm hỏng một lớp bạn đã nâng cấp | Diff bộ kiểm thử theo từng lớp; số bước trôi dạt sau khi đổi | Playbook chuyển đổi; luồng canary; chạy song song cũ và mới (Ch. 9) |
| 12. Pilot đóng băng | Mãi chỉ tư vấn; không có bằng chứng để nâng cấp; hợp đồng không được gia hạn | Quyền tự chủ đi ngang nhiều quý; không có thay đổi MTTR được đo | Tiêu chí nâng cấp được ký kết; bắt đầu ở lĩnh vực rủi ro thấp; các cổng trong [Phụ lục A](https://docs.cloudthinker.io/vi/learn/aio-engineer/appendix-a-poc-test-plan.md) |

Hai bài học từ bảng.

* **Mỗi lỗi này đều xuất hiện trên dashboard trước khi xuất hiện thành sự cố**, nhưng chỉ khi bạn đã xây dựng đánh giá và khả năng quan sát từ [Chương 7](https://docs.cloudthinker.io/vi/learn/aio-engineer/chapter-7-evaluating-agents.md) và [Chương 8](https://docs.cloudthinker.io/vi/learn/aio-engineer/chapter-8-observing-the-observer.md). Bỏ qua chúng không giúp tránh được các lỗi này. Bạn chỉ gặp chúng mà không có công cụ đo.
* **Dùng danh mục làm kịch bản phỏng vấn.** Hỏi bất kỳ nhà cung cấp nào xem họ đã gặp lỗi nào trong mười hai lỗi này trên production và họ đã phát hành gì để ứng phó. Trong một lĩnh vực còn non trẻ như vậy, lịch sử sự cố thực là bằng chứng năng lực có giá trị.

## 11.2 Tự xây hay mua, phiên bản dành cho kỹ sư

Nhóm có năng lực hoàn toàn có thể tự xây agent vận hành. Chỉ cần một cuối tuần với mô hình frontier, một vòng lặp ReAct (suy luận, hành động, quan sát, lặp lại) và `kubectl` sẽ tạo ra bản demo gây ấn tượng với lãnh đạo. Câu hỏi thực sự là bạn có nên sở hữu harness xung quanh nó hay không.

Đây là những gì cuốn sách này đã đặc tả vượt ra ngoài bản demo:

| Hệ thống con | Bao gồm | Chương |
| - | - | - |
| Vòng lặp agent | Bản thân vòng lặp, giới hạn bước và chi phí, xác minh độc lập | [1](https://docs.cloudthinker.io/vi/learn/aio-engineer/chapter-1-agent-anatomy.md) |
| Ngữ cảnh | Discovery, ngân sách, memory, nguồn gốc | [2](https://docs.cloudthinker.io/vi/learn/aio-engineer/chapter-2-context-engineering.md) |
| Công cụ và skill | Metadata rủi ro, contract test | [3](https://docs.cloudthinker.io/vi/learn/aio-engineer/chapter-3-tools-skills-protocol.md) |
| Điều phối | Handoff có kiểu, kiểm soát chi phí hai engine | [4](https://docs.cloudthinker.io/vi/learn/aio-engineer/chapter-4-orchestration-economics.md) |
| Phòng thủ injection | Sandboxing, kiểm soát egress, tokenization | [5](https://docs.cloudthinker.io/vi/learn/aio-engineer/chapter-5-threat-model.md) |
| Chính sách và an toàn thực thi | Policy as code, phê duyệt, bản ghi audit có thể phát lại | [6](https://docs.cloudthinker.io/vi/learn/aio-engineer/chapter-6-policy-approvals.md) |
| Đánh giá | Bộ kiểm thử từ sự cố của bạn, giám khảo, cổng chặn suy giảm | [7](https://docs.cloudthinker.io/vi/learn/aio-engineer/chapter-7-evaluating-agents.md) |
| Khả năng quan sát | Trace các quyết định, không chỉ request | [8](https://docs.cloudthinker.io/vi/learn/aio-engineer/chapter-8-observing-the-observer.md) |
| Vận hành ngày 2 | Đánh phiên bản, chuyển đổi mô hình, vệ sinh memory | [9](https://docs.cloudthinker.io/vi/learn/aio-engineer/chapter-9-agentops-day-2.md) |

Bản demo là phần nhỏ nhất và thú vị nhất trong danh sách đó. Phần còn lại là công việc nặng nhọc không tạo khác biệt cho phần lớn công ty, và đó chính là nơi mười hai kiểu lỗi trú ngụ.

Dùng quy tắc quyết định này:

* **Tự xây** nếu vận hành agent là sản phẩm của bạn, hoặc ràng buộc của bạn khác thường đến mức không mô hình tin cậy nào của nền tảng phù hợp. Bố trí nhân sự như một nhóm sản phẩm có roadmap, không phải dự án phụ.
* **Mua** nếu lợi thế của bạn nằm ở chỗ khác. Dành nguồn lực kỹ thuật cho những gì không nhà cung cấp nào làm thay được: bộ kiểm thử, việc tuyển chọn ngữ cảnh, thiết kế chính sách và kỷ luật vận hành của bạn.

Dù chọn cách nào, hãy giữ cùng một tiêu chuẩn. [Phụ lục B](https://docs.cloudthinker.io/vi/learn/aio-engineer/appendix-b-engineering-checklist.md) chấm điểm nhà cung cấp và xác định phạm vi tự xây với cùng các mục, và [Phụ lục A](https://docs.cloudthinker.io/vi/learn/aio-engineer/appendix-a-poc-test-plan.md) kiểm thử con đường bạn chọn trên chính sự cố của bạn.

> [!NOTE]
>
> **Trong thực tế: nơi CloudThinker cung cấp cơ chế kiểm soát**
>
> Nếu bạn đánh giá CloudThinker theo danh mục này, đây là cơ chế kiểm soát cho từng kiểu lỗi, hoặc cách bao quát kiểu lỗi đó khi không có cơ chế nào.
>
> | Kiểu lỗi | Xem ở đâu |
> | - | - |
> | 1. Cuộc điều tra vô tận | Không có giới hạn bước, token hoặc thời gian theo từng cuộc điều tra mà bạn đặt được. [Credit limits](https://docs.cloudthinker.io/vi/guide/billing/credit-limits.md) (gói Scale trở lên) giới hạn chi tiêu hằng tháng mỗi workspace, và **Stop** trong chat dừng một câu trả lời đang chạy. |
> | 2. Ngập ngữ cảnh | Thước đo **Context window** trong ô prompt cho thấy những gì đang lấp đầy ngữ cảnh của cuộc hội thoại. Cuộc hội thoại dài sẽ tóm tắt các tin nhắn trước đó thay vì tăng mãi đến khi chạm giới hạn mô hình. Không có giới hạn kích thước kết quả mà bạn đặt được. |
> | 3. Sai một cách tự tin | Chấm điểm sự cố trong **Was Resolve's diagnosis right?**, và chọn **Wrong root cause** khi sai. **Resolve → Insights → Accuracy & trust** theo dõi **Root-cause accuracy** ([Resolve Insights](https://docs.cloudthinker.io/vi/guide/incident/insights.md)). |
> | 4 và 12. Chứng minh kết quả | Bản sửa đã ghi nhận giữ trạng thái **Unverified** cho đến khi một kiểm tra tiếp theo đánh dấu **Verified** hoặc **Failed** ([Incident memory](https://docs.cloudthinker.io/vi/guide/incident/incident-memory.md)). **Resolve → Insights → Accuracy & trust** hiển thị **Root-cause accuracy** từ phán quyết của nhóm bạn. Trang [Activity](https://docs.cloudthinker.io/vi/guide/activity.md) và [Audit Logs](https://docs.cloudthinker.io/vi/guide/security/audit-logs.md) (gói Scale, Scale Plus và Enterprise) cho thấy các lượt chạy đã diễn ra, không phải bản sửa đã hiệu quả. |
> | 5. Bão chi phí | [Credit limits](https://docs.cloudthinker.io/vi/guide/billing/credit-limits.md) (gói Scale trở lên) giới hạn chi tiêu hằng tháng mỗi workspace, với chế độ throttle hoặc chỉ thông báo. |
> | 6. Sự cố injection | Không phải một cài đặt đơn lẻ. Mọi thao tác ghi do chỉ dẫn bị chèn kích hoạt vẫn đi qua Rule và Approval mode, và [Guardrails](https://docs.cloudthinker.io/vi/guide/security/custom-guardrails.md) cho agent thấy placeholder thay vì định danh nhạy cảm. Xem [Chương 5](https://docs.cloudthinker.io/vi/learn/aio-engineer/chapter-5-threat-model.md) để biết toàn bộ lớp phòng thủ. |
> | 7. Mệt mỏi phê duyệt | **Approve and draft rule** trên thẻ phê duyệt biến một phê duyệt lặp lại thành [Rule](https://docs.cloudthinker.io/vi/guide/approvals/rules.md) mà bạn chỉ review một lần. **Approvals → Activity** đếm số lần phê duyệt và từ chối theo từng Rule, nhưng không hiển thị độ trễ phê duyệt hay thời gian review, nên hãy tự đo các chỉ số đó. |
> | 8. Đầu độc memory | Admin workspace có thể mở, sửa hoặc xóa bất kỳ mục [memory](https://docs.cloudthinker.io/vi/guide/memory.md) nào. Bản tóm tắt lượt chạy [Dreaming](https://docs.cloudthinker.io/vi/guide/memory-dreaming.md) nêu rõ mỗi lượt chạy hằng đêm đã thay đổi gì. |
> | 9. Công cụ tràn lan | Không phải cơ chế kiểm soát của sản phẩm. Chỉ cấp cho mỗi custom agent các kết nối nó cần ([Custom agent](https://docs.cloudthinker.io/vi/guide/agents/customize.md)). |
> | 10 và 11. Thay đổi vô hình và đổi mô hình | Không có thời hạn báo trước nào được công bố cho thay đổi mô hình trong cùng một tier. Theo dõi [changelog](https://docs.cloudthinker.io/changelog.md) và RSS feed của nó, và chạy lại golden set sau các bản phát hành. Với [BYOK](https://docs.cloudthinker.io/vi/guide/byok.md), Owner của tổ chức chọn chính xác mô hình trên key của riêng bạn. |

> [!TIP]
>
> **Điều cần nhớ**
>
> Các lỗi đều cụ thể, đo lường được và phần lớn là tự gây ra ở tầng harness. Dù tự xây hay mua, bạn vẫn sở hữu bộ kiểm thử, chính sách, ngữ cảnh và kỷ luật. Hãy hỏi bất kỳ ai muốn sở hữu phần còn lại về lịch sử sự cố thực, không phải slide. Với CloudThinker, [changelog](https://docs.cloudthinker.io/changelog.md) liệt kê các bản sửa đã phát hành trong mỗi release.

## Bước tiếp theo

Đọc [Chương 12](https://docs.cloudthinker.io/vi/learn/aio-engineer/chapter-12-autonomous-mission-loop.md) để xem các trụ cột này trở thành nhiệm vụ thường trực giành quyền tự chủ theo thứ tự như thế nào. Nếu bạn đang đánh giá một nền tảng, hãy mang [Phụ lục A](https://docs.cloudthinker.io/vi/learn/aio-engineer/appendix-a-poc-test-plan.md) vào proof of concept của mình.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.