Agent overlay: thêm lớp, đừng phá sân

Agent overlay: thêm lớp, đừng phá sân

Legacy REST không cần bị đập đi để chạy agent. Cái cần là lớp overlay đủ rõ: contract, guardrail, orchestration và quan sát được lỗi.

“Hay mình viết lại service cũ thành agent luôn?” — câu này nghe trong phòng họp là mình muốn giơ thẻ vàng nhẹ.

Không phải vì rewrite luôn sai. Mà vì với hệ thống enterprise đã chạy ổn nhiều năm, rewrite thường là cách biến một vấn đề tích hợp thành một mùa giải kéo dài vô tận: đổi API, đổi auth, đổi monitoring, đổi ownership, rồi cuối cùng team quên mất mục tiêu ban đầu là gì.

Luận điểm của mình hôm nay rất gọn: agent production không bắt đầu bằng việc biến mọi service thành agent, mà bắt đầu bằng việc đặt một lớp agentic overlay đủ mỏng, đủ đo được, đủ có guardrail lên trên thứ đang chạy tốt.

Nói thẳng ra thì, bạn không cần phá sân bóng chỉ để đội hình biết chuyền cho nhau.

Sơ đồ minh họa cho bài Agent overlay: thêm lớp, đừng phá sân

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

Mục tiêu thật: cho service cũ tham gia cuộc chơi mới

Nhiều hệ thống hiện tại vẫn xoay quanh REST API: client gọi endpoint, gửi tham số, nhận response. Rõ ràng, dễ test, dễ vận hành. Nhưng agent lại cần kiểu giao tiếp khác: khám phá năng lực, gọi tool, phối hợp nhiều bước, đôi khi giao việc cho agent khác.

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

Điểm dễ nhầm: overlay không phải là “dán AI lên API”. Nếu chỉ tạo một prompt rồi cho model gọi endpoint, bạn mới có một demo biết lên bóng. Production cần đội hình: ai được gọi ai, gọi trong điều kiện nào, lỗi trả về ra sao, rollback thế nào, log nằm ở đâu.

Mổ lớp hệ thống: overlay nên nằm ở đâu?

Một agentic overlay đáng tin thường không phải một cục code thần bí. Nó là vài lớp nhỏ, mỗi lớp giữ một trách nhiệm rõ.

1. Lớp mô tả năng lực

Service cũ thường có OpenAPI spec hoặc tài liệu endpoint. Overlay cần biến phần đó thành “agent card” hoặc metadata để agent hiểu: service này làm gì, input nào bắt buộc, output ra sao, giới hạn là gì.

Nếu thiếu lớp này, agent sẽ đoán. Mà agent đoán trên production thì giống trung vệ tự dưng dâng cao phút bù giờ: có thể đẹp, nhưng tim ops team rớt xuống bàn phím.

2. Lớp chuyển đổi giao thức

REST vốn là request-response. A2A và MCP lại cần cách đóng gói lời gọi thành tool, task, hoặc message có cấu trúc. Overlay nên làm nhiệm vụ dịch giữa hai thế giới này: agent gọi tool, overlay chuyển thành REST call, rồi chuẩn hóa response trả về.

Ví dụ cụ thể: service customer-risk đang có endpoint POST /risk/score. Thay vì rewrite thành agent, bạn tạo overlay expose tool calculate_customer_risk, schema input gồm customer_id, transaction_context, requested_limit. Bên trong vẫn gọi REST cũ.

3. Lớp kiểm soát quyền và phạm vi

Đây là chỗ nhiều demo bỏ qua. Một API vốn được gọi bởi backend có auth rõ ràng. Khi đưa agent vào, bạn phải trả lời: agent này đại diện cho ai? Được đọc gì? Được ghi gì? Có cần human approval cho hành động rủi ro không?

Đừng để overlay thành cửa phụ không có bảo vệ. Với nghiệp vụ tài chính, HR, billing, support, quyền sai một chút là thành incident thật.

4. Lớp quan sát và đánh giá

Nếu agent gọi sai API, bạn cần biết sai ở đâu: model chọn tool sai, overlay map input sai, service trả lỗi, hay guardrail chặn đúng? Observability ở đây không chỉ là log HTTP 500. Nó cần trace theo phiên agent, tool call, input đã được redact, output, latency, decision reason nếu có.

Đây cũng là nơi bài toán agentic cloud operations trở nên thực tế: insight phải nối được với action, nhưng action phải nằm trong vòng kiểm soát khép kín, không phải chạy tự do ngoài tầm nhìn.

Checklist trước khi bọc REST bằng agent

Trước khi viết dòng overlay đầu tiên, mình sẽ bắt team trả lời checklist này. Không cần họp cả tuần, nhưng phải có câu trả lời đủ rõ để người trực production không phải đoán.

| Câu hỏi | Nếu chưa trả lời được thì sao? |
|---|---|
| API này chỉ đọc hay có ghi dữ liệu? | Chưa cho agent tự gọi hành động ghi |
| Input nào có thể gây thiệt hại nếu sai? | Thêm validation và approval |
| Response có chứa dữ liệu nhạy cảm không? | Redact trước khi đưa lại cho model |
| Ai sở hữu overlay khi lỗi xảy ra? | Không deploy nếu ownership mơ hồ |
| Có idempotency không? | Cẩn thận với retry tự động |
| Có log đủ để replay lỗi không? | Bổ sung trace trước khi mở rộng |
| Tool này có cần được discovery runtime không? | Cân nhắc registry hoặc ARD |

ARD, Agentic Resource Discovery, là lớp khám phá tài nguyên cho agent: thay vì developer cài sẵn mọi tool, agent có thể tìm năng lực phù hợp trong registry. Ý này hấp dẫn, nhưng với team đang có legacy REST, đừng nhảy ngay sang “agent tự tìm mọi thứ”. Bắt đầu bằng catalog nội bộ có kiểm duyệt trước đã.

Làm trong một buổi chiều: bản overlay tối thiểu

Hình dung thế này: team bạn có một service nội bộ ticket-service, chuyên tạo ticket hỗ trợ. Bạn muốn agent support có thể tạo ticket, nhưng không muốn rewrite service.

Trong một buổi chiều, bản tối thiểu nên có 5 phần.

Bước 1: chọn một endpoint ít rủi ro

Đừng bắt đầu bằng “refund tiền”, “xóa user”, hay “đổi hạn mức”. Chọn việc có rollback hoặc hậu quả thấp, ví dụ tạo draft ticket.

Bước 2: viết contract tool thật chặt

Ví dụ minh họa:

{
  "name": "create_support_ticket_draft",
  "description": "Tạo bản nháp ticket hỗ trợ, chưa gửi cho khách hàng",
  "input_schema": {
    "type": "object",
    "required": ["customer_id", "issue_summary", "priority"],
    "properties": {
      "customer_id": { "type": "string" },
      "issue_summary": { "type": "string", "maxLength": 1000 },
      "priority": { "type": "string", "enum": ["low", "normal", "high"] }
    }
  }
}

Điểm quan trọng không phải JSON đẹp. Điểm quan trọng là giảm không gian đoán mò của model.

Bước 3: tạo policy trước khi gọi REST

Ví dụ:

if user.role not in ["support_agent", "support_lead"]:
    deny("insufficient_role")

if priority == "high" and missing(issue_summary.evidence):
    require_human_review("high_priority_needs_evidence")

call POST /tickets/drafts

Guardrail nên nằm ngoài prompt. Prompt có thể hướng dẫn, nhưng policy phải là code hoặc rule có thể test.

Bước 4: chuẩn hóa lỗi trả về cho agent

Đừng ném nguyên stack trace hoặc message mơ hồ. Overlay nên trả lỗi có dạng:

{
  "status": "blocked",
  "reason": "high_priority_needs_evidence",
  "next_action": "Ask user for supporting evidence before creating high priority ticket"
}

Agent cần biết phải làm gì tiếp theo, không chỉ biết “fail”.

Bước 5: trace từng lượt gọi

Tối thiểu log các trường: session_id, tool_name, caller_agent, user_id_hash, policy_result, rest_status, latency_ms, error_code. Nếu dữ liệu nhạy cảm, hash hoặc redact. Đừng lưu nguyên PII chỉ vì “để debug cho tiện”.

Bẫy hay gặp: overlay dày thành hệ thống mới

Overlay nên mỏng. Nhưng trong thực tế, nó rất dễ phình lên.

Ban đầu chỉ định map tool sang REST. Sau đó thêm cache, thêm business rule, thêm retry phức tạp, thêm workflow riêng. Một tháng sau, team có hai nơi chứa logic nghiệp vụ: service cũ và overlay mới. Lúc đó bạn không retrofit nữa, bạn đang xây song song một hệ thống khó bảo trì hơn.

Dấu hiệu cần dừng lại:

Với tác vụ phân loại, triage issue, route ticket, local model trong agent harness có thể là lựa chọn hợp lý nếu team đã có hạ tầng và muốn kiểm soát stack. Nhưng với hành động ghi dữ liệu doanh nghiệp, model nào không quan trọng bằng việc overlay có chặn được cú gọi sai hay không.

Khi nào nên dùng overlay, khi nào nên rebuild?

Mình sẽ quyết định theo khung 3 câu hỏi.

Service hiện tại còn khỏe không? Nếu REST API ổn định, có test, có owner, có monitoring, hãy overlay trước. Đừng rewrite chỉ vì agent trend đang ồn.

Nghiệp vụ có thay đổi vì agent không? Nếu agent chỉ là kênh gọi mới, overlay đủ. Nếu agent làm xuất hiện workflow hoàn toàn mới, cần thiết kế lại orchestration, có thể tách service mới.

Rủi ro nằm ở giao thức hay ở logic? Nếu rủi ro là “agent chưa biết gọi đúng cách”, overlay giải quyết tốt. Nếu rủi ro là logic cũ không còn phù hợp, overlay chỉ che bụi lên vấn đề.

Sau bài này, mình muốn bạn đổi một cách nghĩ: agent không phải vai chính thay thế hệ thống cũ; agent chỉ là một cầu thủ mới, còn orchestration và guardrail mới là ban huấn luyện quyết định đội có đá được production hay không.

Nếu là mình, mình sẽ retrofit endpoint đọc trước, draft trước, approval trước; khi trace đã đủ sạch mới cho agent chạm vào hành động ghi thật. Đội hình thắng không phải vì ai cũng lao lên bóng, mà vì biết lúc nào phải giữ vị trí.

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

Nguồn tham khảo