Agent support cần đường may chắc

Agent support cần đường may chắc

Một playbook cho team builder: đừng bắt agent AWS làm anh hùng, hãy thiết kế orchestration, guardrail và bằng chứng trước khi cho nó tạo ticket thật.

“Em ơi, production đang đỏ CloudWatch, nhưng ticket support chưa tạo vì anh còn đang copy log.”

Nếu bạn từng trực incident, câu này nghe quen đến mức hơi đau. Một tab là AWS Management Console, một tab là CloudWatch, thêm vài tab docs, re:Post, Slack, rồi cuối cùng là support case. Tới lúc gom đủ bằng chứng, người trực đã mất một mớ năng lượng vào việc khâu nối thông tin thủ công.

AWS có một hướng khá thực dụng: dựng một support companion bằng Amazon Bedrock AgentCore, dùng Strands Agents để điều phối, nối vào dịch vụ AWS qua MCP, rồi cho agent đọc CloudWatch, tìm docs, tra re:Post và tạo support case từ một giao diện chat.

Nhưng bài học đáng giữ không phải là “hãy làm y chang stack này”. Luận điểm của mình gọn hơn: agent trong production chỉ đáng tin khi orchestration và guardrail được thiết kế như phần chính của sản phẩm, không phải lớp vá sau demo.

Sơ đồ minh họa cho bài Agent support cần đường may chắc

Sơ đồ tóm tắt ý chính của bài viết.

Câu chuyện của team Nâu: bot biết nhiều nhưng chưa đáng giao quyền

Team Nâu là một team giả định, nhưng mình cá là bạn đã gặp phiên bản nào đó ngoài đời.

Họ có 6 developer, chạy vài workload trên AWS. Mỗi lần service lỗi, người trực phải:

Một bạn trong team đề xuất: “Hay làm agent cho nó tự tra hết đi?” Nghe hợp lý. Họ dựng prototype rất nhanh: chat hỏi lỗi, agent trả lời, thậm chí biết tạo draft ticket.

Va chạm bắt đầu khi lead hỏi ba câu:

  1. Agent có được tự tạo support case severity cao không?
  2. Nếu log chứa dữ liệu nhạy cảm, nó có gửi nguyên văn đi không?
  3. Khi agent kết luận sai, mình audit lại bằng cách nào?

Không ai trả lời được trọn vẹn. Bot không hỏng vì model kém. Nó hỏng vì đường đi của công việc chưa được may chắc: mũi nào là đọc, mũi nào là suy luận, mũi nào là hành động thật chưa tách ra.

Mục tiêu không phải “chat với AWS”, mà là giảm chuyển cảnh có kiểm soát

Điểm hay trong mô hình support companion là nó gom các thao tác rời rạc vào một conversational interface. Nhưng với team builder, mục tiêu nên viết lại như sau:

Giảm context switching cho người trực incident, trong khi vẫn giữ quyền kiểm soát ở các bước có rủi ro.

Ở đây có vài thuật ngữ cần neo nhanh:

Nói thẳng ra thì: agent support không nên được đánh giá bằng việc “trả lời nghe thông minh không”, mà bằng việc nó có biến một quy trình hỗn loạn thành chuỗi bước kiểm soát được không.

Framework 3 lớp: đọc, đề xuất, hành động

Nếu team bạn đang muốn build agent support kiểu này, mình sẽ không bắt đầu bằng chọn model. Mình sẽ bắt đầu bằng phân quyền workflow thành 3 lớp.

| Lớp | Agent được làm gì | Guardrail tối thiểu | Dấu hiệu nên dừng lại |
|---|---|---|---|
| Đọc | Query CloudWatch, lấy metric, tìm docs, đọc re:Post | Scope IAM hẹp, mask dữ liệu nhạy cảm | Query quá rộng, log chứa secret |
| Đề xuất | Tóm tắt nguyên nhân khả dĩ, liệt kê bằng chứng, đề xuất bước xử lý | Bắt buộc trích dẫn nguồn nội bộ hoặc log liên quan | Kết luận không có evidence |
| Hành động | Tạo draft support case, gợi ý severity, chuẩn bị nội dung gửi | Human approval, policy theo môi trường | Production impact chưa được xác nhận |

Đây là chỗ nhiều team hiểu sai: họ cho agent nhảy thẳng từ “đọc log” sang “làm việc thay người trực”. Với demo thì đã mắt. Với production thì dễ thành vá víu: hôm nay thêm prompt cấm cái này, mai thêm regex chặn cái kia, tuần sau không ai nhớ vì sao prompt dài như khăn len mùa đông.

Cách sạch hơn là thiết kế agent như một workflow có trạng thái rõ ràng:

Incident reported
  -> Collect evidence
  -> Retrieve known guidance
  -> Compare symptoms
  -> Draft diagnosis
  -> Ask for confirmation
  -> Create or update support case

Mỗi bước cần input, output và điều kiện chuyển bước. Nếu thiếu evidence, agent không được “đoán cho vui”. Nếu người dùng chưa xác nhận impact, agent chỉ được tạo draft, không gửi case.

Làm trong một buổi: bản nháp đủ để kiểm tra thiết kế

Ví dụ cụ thể: giả sử team bạn muốn thử một support companion cho nhóm vận hành AWS, đừng cố dựng full frontend ngay. Một buổi chiều là đủ để kiểm tra phần quan trọng nhất: orchestration có hợp lý không.

Bước 1: Chọn một incident hẹp

Đừng bắt đầu bằng “mọi lỗi AWS”. Chọn một nhóm lỗi có lặp lại, ví dụ:

Viết rõ câu hỏi đầu vào:

Service X đang lỗi trong 30 phút gần đây. Hãy kiểm tra log, tìm pattern, đối chiếu docs, rồi tạo draft support case nếu cần.

Bước 2: Vẽ tool map trước khi code

Bạn cần liệt kê tool theo quyền, không theo độ tiện.

tools:
  cloudwatch_read:
    permission: read-only
    allowed_resources: selected_log_groups
  docs_search:
    permission: public_search
  repost_search:
    permission: public_search
  support_case_draft:
    permission: draft_only
  support_case_create:
    permission: requires_human_approval

Nếu dùng AgentCore và MCP, phần hấp dẫn là tool có thể được đóng gói gọn hơn. Nhưng nguyên tắc không đổi: tool nào đụng tới hành động thật thì phải có cửa kiểm duyệt.

Bước 3: Bắt agent xuất “evidence packet”

Đừng chỉ yêu cầu agent trả lời “nguyên nhân là gì”. Bắt nó xuất một gói bằng chứng có cấu trúc:

{
  "incident_summary": "...",
  "time_range_checked": "...",
  "signals": [
    {"source": "CloudWatch", "finding": "..."},
    {"source": "AWS Docs", "finding": "..."},
    {"source": "re:Post", "finding": "..."}
  ],
  "confidence": "low | medium | high",
  "recommended_next_step": "...",
  "requires_human_approval": true
}

Cái này giúp reviewer không phải đọc lại toàn bộ hội thoại. Nó cũng giúp bạn log lại quyết định sau incident.

Bước 4: Chạy test bằng incident cũ

Lấy 3-5 incident đã xử lý trước đây. Cho agent chạy lại trên dữ liệu tương ứng, rồi so với cách người trực đã làm.

Không cần bịa benchmark. Bạn chỉ cần trả lời vài câu:

Nếu bốn câu này chưa ổn, đừng vội gắn vào production workflow.

Những bẫy khiến agent support thành rủi ro vận hành

Có ba bẫy mình sẽ soi rất kỹ trước khi cho agent kiểu này vào ca trực.

Một là quyền quá rộng. Agent đọc được nhiều không có nghĩa là nên đọc tất cả. CloudWatch log có thể chứa token, email, payload nhạy cảm. Scope IAM và masking phải đi trước phần chat đẹp.

Hai là thiếu trạng thái. Nếu agent không biết mình đang ở bước “collect evidence” hay “create case”, nó sẽ cư xử như người đang vừa đọc log vừa viết kết luận. Workflow support cần sợi dọc là trạng thái, sợi ngang là tool; thiếu một bên là vải dễ xô.

Ba là không audit được. Khi support case được tạo, bạn cần biết agent đã dùng log nào, docs nào, reasoning nào, ai duyệt. Nếu chỉ lưu transcript chat, sau này debug rất mệt. Hãy log tool call, input đã mask, output chính, approval event và phiên làm việc.

Nếu là mình, mình sẽ triển khai theo mức độ tin cậy

Mình sẽ không cho agent tạo support case thật ngay ngày đầu. Lộ trình hợp lý hơn:

  1. Tuần đầu: agent chỉ đọc và tóm tắt, không hành động.
  2. Sau đó: agent tạo draft case, người trực chỉnh và gửi.
  3. Khi đã có log audit ổn: agent đề xuất severity và checklist bằng chứng.
  4. Cuối cùng mới cân nhắc: tự tạo case cho nhóm incident ít rủi ro, có policy rõ và approval rule.

Câu trả lời rõ nhất sau bài này nên là: đừng nghĩ agent support là một chatbot thông minh; hãy nghĩ nó là một quy trình vận hành được bọc bằng giao diện hội thoại.

Bedrock AgentCore, Strands Agents, MCP hay CloudFormation chỉ là vật liệu. Thứ quyết định hệ thống sống được qua ca trực là bạn có may đúng đường: tool nào được gọi, bằng chứng nào phải có, hành động nào cần người gật đầu.

Chốt lại: agent tốt không phải đứa nói hay nhất trong phòng incident, mà là đứa biết lúc nào nên im, lúc nào nên đưa bằng chứng, và lúc nào phải gọi người trực ký tên.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo