Agent production cần tháp không lưu

Agent production cần tháp không lưu

Đừng chọn agent vì demo chạy được. Với builder, quyết định đúng nằm ở orchestration, guardrail và điểm dừng tự động hóa.

Có lần mình xem một team demo agent nội bộ: agent đọc issue, quét vài repo, sửa docs, tạo PR, rồi tự tin ping Slack báo “xong”. Cả phòng vỗ tay được khoảng 12 giây. Đến giây thứ 13, một anh backend hỏi: “Nếu nó sửa nhầm repo billing thì ai chịu?”

Không khí lúc đó giống máy bay vừa lăn ra đường băng mà tháp không lưu chợt phát hiện chưa ai kiểm tra gió ngang.

Đấy là điểm mình muốn chốt trong bài này: agent production không đáng tin vì nó biết làm nhiều việc; nó đáng tin khi orchestration và guardrail đủ rõ để biết việc nào được làm, việc nào phải dừng, và việc nào cần người ký tên.

Sơ đồ minh họa cho bài Agent production cần tháp không lưu

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

Quyết định đầu tiên: bạn đang tự động hóa việc gì?

GitHub đang đẩy mạnh hướng agentic workflows cho các việc kiểu cross-repo documentation — hiểu nôm na là agent có thể đi qua nhiều repository để cập nhật tài liệu, tạo thay đổi, mở PR. AWS thì có ví dụ support companion dùng Bedrock AgentCore để gom thao tác vận hành: xem CloudWatch logs, tìm tài liệu, tra AWS re:Post, tạo support case. Một nguồn khác đi sâu vào chuyện bảo vệ AgentCore Runtime bằng AWS WAF, ALB, VPC Endpoint, resource policy.

Nhìn ba mảnh đó cạnh nhau, mình thấy một quyết định thực dụng hơn câu hỏi “tool nào xịn hơn”: đây là workflow hỗ trợ con người, workflow bán tự động, hay workflow được phép tự chạy?

Ba mức này khác nhau rất xa:

| Mức | Agent được làm gì | Nên dùng khi | Rủi ro chính |
|---|---|---|---|
| Copilot mode | Gợi ý, soạn nháp, tóm tắt | Tài liệu, triage, điều tra ban đầu | Người dùng tin nhầm output |
| PR mode | Tạo thay đổi nhưng cần review | Cross-repo docs, refactor nhẹ, config ít rủi ro | Review hình thức, diff quá rộng |
| Runtime mode | Gọi tool/API thật trong production | Support ops, incident workflow, ticket automation | Quyền quá lớn, audit mù, bị abuse |

Nói thẳng ra thì: đừng hỏi agent có làm được không; hỏi sai thì nguy hiểm. Hãy hỏi nếu nó làm sai, hệ thống bắt lỗi ở đâu.

Framework 4 cổng trước khi cho agent cất cánh

Nếu bạn là tech lead đang cân nhắc agent workflow, mình đề xuất dùng khung 4 cổng này. Nó không phụ thuộc bạn dùng GitHub Agentic Workflows, Bedrock AgentCore, LangChain, hay tự ráp bằng service nội bộ.

Cổng 1: Scope — agent được chạm vào vùng nào?

Với cross-repo documentation, scope không chỉ là “được đọc nhiều repo”. Scope phải ghi rõ:

Ví dụ cụ thể: team bạn có 12 repo microservices. Agent được phép đọc toàn bộ repo để hiểu context, nhưng chỉ được mở PR thay đổi trong docs/ và README.md. Nếu agent phát hiện cần sửa file src/payment/discount.ts, nó phải tạo comment “manual follow-up”, không được commit.

Đây là guardrail — lớp rào chắn hành vi — đơn giản nhưng cứu bạn khỏi kiểu tự động hóa quá tay.

Cổng 2: Orchestration — ai điều phối từng bước?

Orchestration là cách điều phối nhiều bước, nhiều tool hoặc nhiều agent để hoàn thành việc. Trong công việc thật, đây là nơi demo đẹp biến thành hệ thống chịu được nhiễu động.

Một workflow docs qua nhiều repo thường có các bước:

  1. Lấy issue hoặc yêu cầu thay đổi.
  2. Tìm repo liên quan.
  3. Đọc tài liệu hiện có.
  4. Soạn diff.
  5. Chạy kiểm tra link/lint.
  6. Mở PR.
  7. Gắn reviewer.

Nếu bạn để model tự quyết tất cả trong một prompt dài, bạn đang đặt cả chuyến bay vào tay một đoạn hội thoại. Builder nên tách orchestration thành state machine hoặc workflow engine rõ ràng: bước nào deterministic thì code xử lý, bước nào cần ngôn ngữ thì mới gọi model.

Một manifest tối thiểu có thể trông như thế này:

workflow: cross_repo_docs_update
allowed_read:
  - org/*
allowed_write:
  - service-a/docs/**
  - service-b/README.md
blocked_paths:
  - "**/src/**"
  - "**/.github/workflows/**"
checks_required:
  - markdown_lint
  - link_check
  - reviewer_required
human_approval:
  - any_file_outside_allowed_write
  - diff_over_500_lines
  - security_related_terms_detected

Đây không phải cấu hình thần thánh gì cả. Nhưng nó biến “agent thông minh” thành “workflow có luật”. Production thích luật hơn thích lời hứa.

Cổng 3: Identity — agent đang hành động bằng danh tính nào?

Khi agent chỉ chat, identity chưa quá căng. Khi agent gọi API, tạo PR, đọc logs, mở support case, identity trở thành câu hỏi sống còn.

Trong ví dụ support companion, agent kết nối nhiều nguồn: CloudWatch logs, tài liệu, community knowledge, support case. Nếu triển khai kiểu production, bạn cần phân biệt:

Session isolation — cô lập phiên làm việc — nghĩa là dữ liệu và quyền của phiên A không rò sang phiên B. Với team vận hành, đây không phải chi tiết phụ. Một agent support đọc nhầm log của account khác có thể biến “tiện lợi” thành sự cố bảo mật.

Hình dung thế này: một kỹ sư trực incident hỏi agent “tìm lỗi 5xx gần nhất”. Nếu agent dùng quyền quá rộng, nó có thể lục cả môi trường không liên quan. Nếu quyền quá hẹp, nó trả lời thiếu bằng chứng. Quyết định đúng thường là quyền theo vai trò, theo môi trường, theo thời hạn — không phải một token toàn năng nhét trong backend.

Cổng 4: Edge protection — ai đứng trước cửa API?

Khi agent runtime trở thành API endpoint, bạn không chỉ lo prompt injection. Bạn còn lo rate limit, bot traffic, audit, IP allowlist, auth flow, health check.

AWS có một chi tiết đáng chú ý: nếu đưa AgentCore Runtime ra production và muốn gắn AWS WAF — web application firewall, lớp lọc request ở biên — lựa chọn integration không hề “cứ cắm vào là xong”. CloudFront thiên về caching, nhưng agent invocation là tương tác động theo thời gian thực. API Gateway có thể tạo lớp xác thực chồng lên SigV4 hoặc OAuth. ALB — Application Load Balancer, bộ cân bằng tải tầng ứng dụng — trở thành điểm hợp lý để gắn WAF, nhưng health check của ALB lại không tự ký SigV4.

Điểm đáng học không phải “hãy dùng đúng pattern AWS này”. Điểm đáng học là: agent production sẽ lộ ra những va chạm rất đời giữa AI runtime và hạ tầng web cũ. Health check, header passthrough, VPC Endpoint, resource policy — mấy thứ nghe khô nhưng quyết định hệ thống có chạy an toàn không.

Nếu team bạn chưa trả lời được “request vào agent đi qua những lớp nào”, khoan mở public endpoint.

Chọn hướng nào: bảng quyết định cho builder

Dưới đây là cách mình sẽ quyết nếu đang ngồi với một team Việt Nam 5-15 dev, có vài repo, có nhu cầu tự động hóa docs hoặc support ops.

| Tình huống | Nên chọn | Vì sao |
|---|---|---|
| Docs lệch giữa nhiều repo, nhưng rủi ro thấp | PR mode cho cross-repo docs | Agent tạo diff, người review giữ quyền quyết định |
| Incident investigation mất thời gian vì đổi qua nhiều console | Support companion có tool calling | Gom context nhanh, nhưng action ghi cần approval |
| Muốn agent tự xử ticket production từ đầu đến cuối | Chưa nên nếu chưa có audit, rate limit, rollback | Tự động hóa trước khi có guardrail là mời rắc rối vào nhà |
| API agent cần public access | Thiết kế edge protection trước | WAF, auth, health check, resource policy không phải phần trang trí |
| Team chưa có owner rõ cho workflow | Bỏ qua hoặc làm bản internal-only | Agent không có chủ sở hữu thì lỗi cũng không có người nhận |

Quy tắc của mình: việc càng gần production, agent càng phải ít tự do hơn và nhiều dấu vết hơn.

Làm trong một buổi: bản thử nghiệm đủ nghiêm túc

Bạn không cần dựng cả nền tảng agent mới để kiểm tra quyết định. Một buổi chiều là đủ để làm bản thử nghiệm có ích.

Bước 1 — Chọn một workflow hẹp

Đừng bắt đầu bằng “agent quản lý toàn bộ docs”. Hãy chọn một việc như:

Bước 2 — Viết policy trước prompt

Tạo một file agent-policy.yaml với quyền đọc/ghi, điều kiện cần approval, giới hạn diff. Nếu policy viết không ra, workflow chưa đủ rõ.

Bước 3 — Tách planner và executor

Planner dùng model để đề xuất kế hoạch. Executor là code kiểm tra policy và gọi tool. Đừng để model tự gọi mọi thứ không qua lớp kiểm soát.

Bước 4 — Bắt buộc có dry run

Dry run — chạy thử không ghi thay đổi — nên in ra:

Bước 5 — Log như chuẩn bị postmortem

Ghi lại prompt, tool call, response, diff, reviewer, decision. Không phải để soi mói, mà để khi agent làm sai, bạn có hộp đen mà mở ra xem.

Những bẫy làm agent nhìn thông minh nhưng vận hành dở

Bẫy đầu tiên là diff quá rộng. Agent sửa 30 file docs trong 8 repo có thể nhìn rất năng suất, nhưng reviewer sẽ lướt qua cho xong. Guardrail nên giới hạn số file, số dòng, hoặc bắt chia PR.

Bẫy thứ hai là tool calling không phân cấp. Tool calling là khả năng model gọi công cụ hoặc API thay vì chỉ trả lời chữ. Nhưng không phải tool nào cũng ngang nhau. Đọc log khác với tạo support case. Search docs khác với sửa config.

Bẫy thứ ba là security đưa vào sau cùng. Với agent runtime, rate limiting, WAF, auth, resource policy, audit nên có trong thiết kế sớm. Nếu chờ tới lúc demo được rồi mới nhét bảo mật vào, bạn sẽ phát hiện có những lối đi tắt không dễ bịt.

Bẫy cuối cùng là đo sai thành công. Với agent docs, đừng chỉ đo số PR tạo ra. Hãy đo PR được merge không sửa nhiều, reviewer mất bao lâu, lỗi docs có giảm không. Với support companion, đừng chỉ đo số câu trả lời. Hãy xem điều tra có đủ bằng chứng, case tạo có đúng severity, và escalation có rõ không.

Nếu là mình, mình sẽ chọn thế này

Nếu workflow liên quan documentation, mình sẽ bắt đầu bằng PR mode: agent đọc rộng, ghi hẹp, mở PR nhỏ, bắt review thật. Đây là vùng có lợi ích rõ mà rủi ro kiểm soát được.

Nếu workflow liên quan incident/support, mình sẽ bắt đầu bằng copilot mode có tool đọc, chưa cho action ghi chạy tự động. Khi log, approval, identity, rate limit ổn hơn, mới nâng một số bước sang bán tự động.

Nếu workflow cần public API cho agent, mình sẽ coi edge protection là hạng mục nền tảng, không phải việc “để sprint sau”. Một agent không có WAF/rate limit/audit giống chuyến bay không có tháp không lưu: có thể vẫn bay, nhưng mình không muốn ngồi ghế 12A.

Điều bạn nên nghĩ khác sau bài này: đừng đánh giá agent bằng độ thông minh của câu trả lời; hãy đánh giá bằng chất lượng đường ray vận hành quanh nó — à không, hôm nay mình đang ở sân bay — bằng chất lượng đường băng, tín hiệu và quy trình hạ cánh.

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

Nguồn tham khảo