Agent platform không thắng ở model

Đừng chọn nền tảng agent vì demo ồn ào. Builder nên nhìn vào quyền truy cập, quan sát vận hành, chi phí model và đường thoát khi hệ thống sai.

Niềm tin phổ biến tuần này: nền tảng nào nói “agent-native” to nhất thì chắc đang dẫn đầu cuộc chơi.

Mình thấy câu này hơi giống đưa một bị cáo ra trước hội đồng xét xử chỉ vì… mặc áo vest đẹp. Có thể người đó rất ổn, nhưng muốn kết luận thì phải xem chứng cứ: agent chạy ở đâu, được phép chạm vào gì, ai chịu trách nhiệm khi nó làm sai, và team có nhìn thấy chi phí lẫn hành vi của nó không.

Vercel Ship 2026 đáng chú ý không phải vì họ nói nhiều về agent. Điều đáng bàn là họ đang cố chuyển cuộc đua từ “model nào thông minh hơn” sang “hạ tầng nào khiến agent sống được trong production”. Với builder, đây mới là điểm làm mình đổi cách nghĩ.

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

Khái niệm: agent platform không chỉ là chỗ deploy

Trước giờ nhiều team nghĩ đơn giản: agent là một app có thêm LLM, vậy cứ deploy như app web là xong. Có endpoint, có database, có cron, thêm vài tool calling là chạy.

Nhưng agent khác app web ở một điểm khó chịu: nó tự quyết định bước tiếp theo trong một phạm vi nào đó. Vì vậy nền tảng cho agent không chỉ cần hosting, mà còn cần các lớp kiểm soát quanh nó.

Trong ngữ cảnh này, vài thuật ngữ cần neo nhanh:

• Agent Stack: bộ primitive, tức các khối nền tảng để xây và chạy agent từ đầu đến cuối.
• Vercel Connect: lớp kết nối an toàn để agent chạm vào hệ thống bên ngoài.
• Scoped credentials: thông tin đăng nhập có phạm vi hẹp, chỉ cho phép làm đúng việc được giao.
• Identity provider: hệ thống định danh như Okta, Microsoft Entra, Auth0; dùng để biết ai được vào đâu.
• Observability: khả năng quan sát hệ thống qua logs, traces, metrics để biết chuyện gì đang xảy ra.
• Anomalies: hành vi bất thường, ví dụ request tăng đột biến hoặc agent lặp lại cùng một thao tác.

Nói thẳng ra thì, agent platform tốt không phải nơi agent “nghĩ hay”, mà là nơi agent bị ràng buộc đúng cách.

Vì sao chuyện này đáng quan tâm với team builder

Tại Ship 2026, Vercel định vị mình theo ba hướng: nơi coding agents deploy software, nơi bạn build và deploy agent của riêng mình, và nơi chính Vercel dùng agent để tự động hóa vận hành. Họ cũng nói về việc agent có thể dùng dữ liệu production như traffic, traces, observability, anomalies để tự điều tra và đề xuất pull request, thay vì chỉ bắn alert.

Điểm này nghe hấp dẫn, nhưng phần đáng soi không nằm ở chữ “autonomous”. Nó nằm ở câu hỏi: agent có đủ ngữ cảnh vận hành để hành động, nhưng có bị giới hạn đủ chặt để không phá nhà không?

Nguồn enterprise của Vercel còn làm rõ hơn vấn đề sau khi agent đã vào nội bộ công ty:

• Làm sao giữ internal agents thật sự internal?
• Agent được phép chạm vào data và system nào?
• Agent đang dùng model nào, tốn bao nhiêu?
• Ai sở hữu lifecycle của user, app, agent?

Đây là những câu hỏi ít sexy hơn demo, nhưng lại là phần quyết định agent có được sống lâu trong công ty hay bị khóa lại sau một buổi review bảo mật.

Với team Việt Nam, nhất là team 5–20 dev đang build internal tools, chatbot support, sales assistant, hoặc agent phân tích dữ liệu, bài toán không phải “có agent chưa?”. Bài toán là: nếu ngày mai agent dùng sai quyền, gọi nhầm API, hoặc đội chi phí model lên, ai phát hiện và chặn?

Khung 4 câu hỏi trước khi chọn nền tảng agent

Mình đề xuất nhìn các platform agent bằng bốn câu hỏi. Không cần biến thành procurement dài dòng; chỉ cần đủ để tránh bị cuốn theo launch mới.

1. Quyền truy cập có mặc định an toàn không?

Nếu mỗi app nội bộ phải nhớ bật private bằng tay, kiểu gì cũng có ngày một deployment bị lộ. Vercel nhấn mạnh hướng đặt internal app và agent sau identity provider theo mặc định. Đây là hướng đúng: bảo mật không nên phụ thuộc vào trí nhớ của dev lúc 6 giờ chiều.

Câu cần hỏi platform:

• Có bắt buộc đăng nhập qua hệ thống định danh công ty không?
• Có phân quyền theo nhóm, role, project không?
• Agent có được cấp quyền ngắn hạn và hẹp phạm vi không?

Nếu câu trả lời là “team tự làm thêm middleware”, hãy tính chi phí vận hành thật, không chỉ chi phí subscription.

2. Kết nối tool có bị khoanh vùng không?

Agent mà kết nối Slack, GitHub, Snowflake, Salesforce, Linear thì tiện thật. Nhưng tiện cũng đồng nghĩa với bề mặt rủi ro lớn hơn.

Điểm mình muốn thấy là short-lived, scoped credentials: quyền sống ngắn, phạm vi rõ. Agent phân tích issue không nên có quyền xóa repo. Agent trả lời câu hỏi sales không nên đọc bảng lương. Đây là lúc “chứng cứ” quan trọng hơn lời hứa marketing: platform có cơ chế cấp quyền cụ thể hay chỉ nói chung chung về secure integration?

3. Có nhìn được model usage và cost không?

Một agent chạy nội bộ thường bắt đầu rất vô tư: vài người dùng, vài prompt, vài model call. Rồi nó được share sang team khác, thêm retrieval, thêm tool call, thêm retry. Đến lúc hóa đơn phình ra mới đi tìm log thì hơi muộn.

Câu hỏi thực tế:

• Có biết agent nào đang gọi model nào không?
• Có tách usage theo app, user, team, environment không?
• Có đặt budget hoặc policy chọn model không?

Nếu không nhìn được chi phí theo đường đi của request, bạn chỉ đang quản lý bằng cảm giác.

4. Khi agent sai, hệ thống có để lại đường đối chất không?

Agent production cần trace đủ tốt để trả lời: input là gì, context nào được đưa vào, tool nào được gọi, output nào được tạo, ai phê duyệt bước cuối.

Vercel nói đến traces, observability, anomalies và khả năng agent điều tra rồi surface pull request. Ý tưởng này hợp lý nếu trace đủ chi tiết. Nhưng với team builder, đừng chỉ hỏi “có observability không?”. Hỏi sâu hơn:

• Trace có nối từ user request sang model call và tool call không?
• Có lưu phiên bản prompt, config, model không?
• Có phân biệt lỗi do retrieval, model, tool, hay permission không?

Không có đường đối chất, mọi sự cố agent sẽ biến thành cuộc họp đoán mò.

Ví dụ cụ thể: một agent nội bộ tưởng nhỏ nhưng không nhỏ

Ví dụ cụ thể: giả sử team bạn 8 người làm SaaS B2B, muốn build agent nội bộ để trả lời câu hỏi “khách hàng này đang bị gì?” Agent cần đọc ticket support, issue GitHub, log lỗi, và một ít dữ liệu billing.

Cách làm nhanh nhất là ghép LLM với vài API key rồi deploy. Demo sẽ chạy được.

Nhưng trước khi cho cả công ty dùng, hãy thử đi qua bốn câu hỏi ở trên:

• Nhân viên sales có được xem log kỹ thuật chi tiết không?
• Agent có quyền ghi comment vào GitHub hay chỉ đọc?
• Mỗi lần trả lời mất bao nhiêu model call, có gọi model đắt cho câu đơn giản không?
• Nếu agent nói “khách này churn vì bug A”, bạn có trace để kiểm tra nó dựa vào ticket nào không?

Đây là khác biệt giữa agent demo và agent có thể chịu audit nội bộ. Không nhất thiết phải dùng một vendor cụ thể. Nhưng nếu platform nào không giúp bạn trả lời các câu này, phần còn lại team bạn sẽ phải tự xây.

Qdrant hackathon nhắc thêm một điều: agent không chỉ là chat

Nguồn Qdrant về Vector Space Hackathon 2026 cho thấy các submission trải rộng từ phát hiện sớm tín hiệu sức khỏe tinh thần, mô phỏng phản ứng đám đông, tactical football search, đến stress-testing hạ tầng. Chi tiết từng dự án không phải trọng tâm ở đây. Tín hiệu đáng chú ý là: các use case AI đang rời khỏi khung “bot trả lời câu hỏi” để thành hệ thống có memory, search, phân tích, và hành động.

Vector search là tìm kiếm bằng vector, tức biểu diễn dữ liệu thành không gian số để tìm thứ gần nghĩa. RAG là retrieval-augmented generation, cách đưa tài liệu liên quan vào ngữ cảnh trước khi model trả lời. Hai thứ này thường là phần “nhớ và tìm” của agent.

Khi agent có memory và retrieval, câu hỏi governance càng căng hơn:

• Dữ liệu nào được index?
• Ai được truy xuất kết quả nào?
• Kết quả retrieval có được ghi lại để debug không?
• Memory có cơ chế xóa, cập nhật, hết hạn không?

Vậy nên chọn nền tảng agent mà chỉ nhìn model support là hơi thiếu hồ sơ vụ án.

Bẫy: nhầm “agent-ready” với “production-ready”

Có ba bẫy mình thấy builder dễ dính.

Bẫy một: thấy framework tạo agent trong vài phút là nghĩ vận hành cũng vài phút. Vercel có eve, một framework triển khai Agent Stack nhanh trong một directory. Tốc độ khởi tạo là tốt, nhưng production còn cần identity, permission, cost control, trace, rollout, rollback.

Bẫy hai: coi agent như feature riêng lẻ. Agent nội bộ thường chạm vào nhiều hệ thống hơn một app thường. Vì vậy nó cần owner rõ, policy rõ, và lifecycle rõ. Không thể để mỗi team tự cầm API key rồi deploy theo cảm hứng.

Bẫy ba: quên đường thoát. Nếu sau ba tháng bạn muốn đổi model, đổi vector database, hoặc chuyển một phần workload về hạ tầng riêng, platform có cho bạn tách lớp không? Hãy xem SDK, API, data export, logging format, và cách quản lý credential trước khi khóa kiến trúc.

Nếu là mình, mình sẽ chấm platform bằng “khả năng chịu sự cố”

Sau bài này, điểm mình muốn bạn nghĩ khác là: đừng hỏi platform agent nào hào nhoáng nhất; hãy hỏi platform nào giúp team chịu được ngày agent sai.

Trong một buổi chiều, bạn có thể làm bài kiểm tra nhỏ:

1. Chọn một agent nội bộ đang hoặc sắp build.
2. Vẽ danh sách system nó cần chạm: GitHub, Slack, database, CRM, warehouse.
3. Ghi quyền tối thiểu cho từng system: read, write, comment, create ticket, query data.
4. Kiểm tra platform hiện tại có cấp scoped credentials và identity mặc định không.
5. Chạy một request mẫu rồi xem trace: có đủ input, retrieval, tool call, model, output không?
6. Ước lượng điểm mù chi phí: request nào đang gọi model đắt, retry ở đâu, team nào dùng nhiều.

Nếu qua bài kiểm tra này mà bạn phải trả lời “chắc là có log đâu đó” quá nhiều lần, agent của bạn chưa thiếu trí thông minh. Nó thiếu hồ sơ vận hành.

Agent platform của thập kỷ tới có thể sẽ không thắng nhờ câu demo hay nhất, mà nhờ làm tốt những phần ít ai khoe trên sân khấu: quyền, trace, cost, lifecycle, và ranh giới an toàn. Tòa production không xử theo applause; nó xử theo log.

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