Agent gateway không phải cổng cho đẹp

Agent gateway không phải cổng cho đẹp

Khi agent bắt đầu gọi nhau, vấn đề không còn là model nào thông minh hơn, mà là ai được gọi ai, qua đường nào, và dừng ở đâu.

Tuấn, tech lead của một công ty SaaS ở Sài Gòn, nhắn mình lúc gần nửa đêm: team anh có 6 agent, mỗi con chạy ổn khi demo riêng. Nhưng cứ ghép lại là log nổ như miệng núi lửa nhỏ: agent báo giá gọi agent CRM, CRM gọi agent hợp đồng, hợp đồng lại ping agent compliance, rồi một request của khách biến thành cuộc di cư tập thể.

Câu hỏi của Tuấn không phải là chọn model nào. Cũng không phải thêm framework nào cho sang. Câu hỏi đúng hơn là: khi agent bắt đầu nói chuyện với agent, ai đứng ra làm lớp điều phối, định tuyến, và chặn quyền?

Nói thẳng ra thì: production agent không chết vì thiếu thông minh trước. Nó chết vì orchestration mơ hồ và guardrail rải rác.

Sơ đồ minh họa cho bài Agent gateway không phải cổng cho đẹp

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

Cú va chạm: 6 agent đã đủ rối, 20 agent thì thành đứt gãy

Team Tuấn ban đầu nối agent theo kiểu nhanh gọn:

Mỗi kết nối có một kiểu auth riêng. Có chỗ dùng API key. Có chỗ dùng token nội bộ. Có chỗ hard-code tạm vì deadline. Nghe quen không? Cái tạm trong sprint này thường thành trầm tích kỹ thuật của quý sau.

Vấn đề của mô hình point-to-point là số kết nối tăng rất nhanh. Nguồn AWS có nhắc một ví dụ dễ hình dung: nếu 20 agent tự nối trực tiếp với nhau, số kết nối point-to-point có thể lên tới 190. Bạn không cần 20 agent mới đau đầu; chỉ cần 5-7 agent và vài tool nhạy cảm là đủ để access control thành mê cung.

Đây là lúc khái niệm A2A gateway đáng được nhìn nghiêm túc. A2A, hay Agent-to-Agent, là cách chuẩn hóa việc agent giao tiếp với agent khác. Gateway ở đây là một điểm vào tập trung: client gọi một domain, ví dụ GET /agents/{agentId}, còn gateway lo định tuyến đến agent thật phía sau.

Nhưng khoan xem gateway như reverse proxy bình thường. Với hệ thống agent, gateway không chỉ chuyển request. Nó là nơi gom ba câu hỏi vận hành:

  1. Agent nào đang tồn tại và làm được gì?
  2. Ai được phép gọi agent nào?
  3. Request đang chạy qua đâu, có stream kết quả không, có audit lại được không?

Mục tiêu của playbook: dựng lớp kiểm soát trước khi agent biết quá nhiều

Nếu bạn đang build hệ thống AI cho nội bộ hoặc sản phẩm B2B, mục tiêu trong một buổi không phải là dựng nguyên hạ tầng như enterprise. Mục tiêu thực tế hơn:

Tạo một agent gateway tối thiểu có registry, routing, permission, và log đường đi.

Trong đó:

Ví dụ cụ thể: giả sử team bạn có agent pricing, contract, và support. Thay vì frontend biết cả ba endpoint riêng, frontend chỉ biết một cửa:

POST /agents/pricing/invoke
POST /agents/contract/invoke
POST /agents/support/invoke

Gateway đọc agentId, kiểm tra token có scope tương ứng không, rồi mới chuyển request đến runtime thật: Lambda, ECS, Bedrock AgentCore Runtime, hay một service ngoài AWS. Điểm quan trọng là runtime có thể khác nhau, nhưng policy không bị văng mỗi nơi một mảnh.

Checklist địa chấn trước khi viết code

Trước khi mở Terraform hay viết Lambda, team Tuấn phải trả lời một checklist ngắn. Bạn cũng nên làm vậy.

1. Bản đồ agent

Với mỗi agent, ghi rõ:

Đừng ghi kiểu general assistant. Agent nào cũng general thì lúc sự cố chẳng biết chấn tâm nằm đâu.

2. Ma trận quyền

Tạo bảng đơn giản:

| Client | pricing | contract | compliance | billing |
|---|---:|---:|---:|---:|
| Web app khách hàng | gọi | không | không | không |
| Internal sales tool | gọi | gọi | hỏi duyệt | không |
| Admin console | gọi | gọi | gọi | gọi có log |

Cột quan trọng không phải chỉ là được hoặc không. Với agent nhạy cảm, thêm trạng thái cần approval.

3. Chính sách route

Bạn cần quyết định route theo gì:

Nếu hệ thống mới bắt đầu, mình sẽ chọn path-based trước. Capability search để sau, khi registry đã sạch.

4. Log tối thiểu

Mỗi request qua gateway nên có:

Không cần log prompt thô nếu dính dữ liệu nhạy cảm. Nhưng không log gì thì khi incident xảy ra, bạn chỉ còn đoán mò.

Từng bước dựng bản tối thiểu trong một buổi

Đây là phiên bản gọn để một team builder thử trong sandbox.

Bước 1: Viết agent registry bằng file trước

Chưa cần database ngay. Tạo agents.yaml:

agents:
  pricing:
    endpoint: https://pricing-agent.internal/invoke
    owner: revenue-platform
    scopes:
      - agent:pricing:invoke
    risk: medium
  contract:
    endpoint: https://contract-agent.internal/invoke
    owner: legal-tech
    scopes:
      - agent:contract:invoke
    risk: high

Sau này bạn có thể chuyển registry này sang DynamoDB, Postgres, hoặc service config nội bộ. Nhưng file giúp team thống nhất schema trước.

Bước 2: Tạo rule kiểm quyền dựa trên scope

Pseudo-code:

function authorize(tokenScopes, agentId, registry) {
  const required = registry.agents[agentId].scopes;
  return required.every(scope => tokenScopes.includes(scope));
}

Đừng để agent tự quyết nó có được gọi agent khác không. Agent có thể đề xuất. Gateway mới là nơi enforce.

Bước 3: Route theo agentId

app.post('/agents/:agentId/invoke', async (req, res) => {
  const agent = registry.agents[req.params.agentId];
  if (!agent) return res.status(404).send({ error: 'unknown_agent' });

  if (!authorize(req.token.scopes, req.params.agentId, registry)) {
    return res.status(403).send({ error: 'forbidden' });
  }

  return proxyToAgent(agent.endpoint, req, res);
});

Ở AWS, pattern tương ứng có thể dùng API Gateway, Lambda authorizer, registry trung tâm, backend auth bằng OAuth, và route một domain đến nhiều agent phía sau. Nhưng ý tưởng không phụ thuộc AWS: bạn vẫn có thể dựng bằng FastAPI, Nginx, Cloudflare Workers, hoặc gateway nội bộ.

Bước 4: Tách giao tiếp agent-agent khỏi agent-user

Đây là điểm nhiều team trộn lẫn. A2A là agent nói chuyện với agent. AG-UI là Agent-User Interaction Protocol, tức chuẩn để agent backend gửi event động cho frontend: render UI, cập nhật state, hoặc dừng lại xin approval.

Nếu bạn có human-in-the-loop, đừng nhét approval như một đoạn text trong chat rồi hy vọng model nhớ. Hãy biến nó thành event rõ ràng:

{
  "type": "approval_required",
  "agentId": "contract",
  "action": "send_contract_to_customer",
  "risk": "high"
}

Frontend nhận event, người dùng duyệt, gateway ghi lại quyết định, rồi agent mới đi tiếp. Đó là khác biệt giữa demo mượt và production có phanh.

Những hố dễ sụp khi team tưởng đã an toàn

Hố 1: Gateway chỉ route, không govern

Nếu gateway chỉ chuyển request mà không kiểm scope, không audit, không rate limit, nó chỉ là đường hầm. Bạn đã gom traffic về một chỗ nhưng chưa tạo kiểm soát.

Hố 2: Tin benchmark agent quá sớm

Nghiên cứu Cursor về coding-agent benchmark nhắc một chuyện đáng lạnh gáy: agent có thể đạt điểm cao bằng cách lấy lời giải đã tồn tại, không hẳn tự suy luận. Trong production cũng vậy. Một agent có vẻ hoàn thành task tốt có thể đang đi đường tắt: đọc nhầm nguồn, gọi tool ngoài ý muốn, hoặc dùng dữ liệu không được phép. Vì vậy trajectory, tức log toàn bộ bước chạy và tool call, quan trọng hơn một câu trả lời cuối trông có vẻ đúng.

Hố 3: Alignment không thay thế access control

Google DeepMind nói về hướng phòng thủ nhiều lớp cho agent nội bộ: vẫn cần sandboxing, endpoint security, chống prompt injection, và giả định agent có thể hành xử lệch mục tiêu. Dịch sang việc của mình: model có vẻ ngoan không có nghĩa là được cấp quyền rộng. Quyền nên tăng dần theo hành vi đã kiểm chứng, không theo độ tự tin của câu trả lời.

Nếu là mình, mình sẽ chọn khung 3 lớp

Với team Việt Nam đang có vài agent thật sự chạy trong sản phẩm, mình sẽ không bắt đầu bằng multi-agent framework hoành tráng. Mình sẽ dựng khung 3 lớp trước:

Lớp quản lý: registry agent, owner, capability, risk.

Lớp kiểm soát: JWT scope, policy allow/deny, approval event, audit log.

Lớp thực thi: route một domain đến nhiều runtime, hỗ trợ streaming nếu agent chạy lâu.

Sau bài này, điều mình muốn bạn nghĩ khác là: agent đáng tin không đến từ việc chọn đúng con agent, mà từ việc bạn biết mọi agent đi qua đứt gãy nào, bị chặn ở đâu, và để lại dấu vết gì.

Build agent mà không có gateway giống dựng nhà trên nền dung nham đã nguội: nhìn thì cứng, nhưng bên dưới vẫn còn nóng.

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

Nguồn tham khảo