AI agent đang rời khỏi ô chat

AI agent đang rời khỏi ô chat

Tín hiệu đáng chú ý không phải model nào mới hơn, mà là workflow AI đang chuyển từ trả lời sang giao thành phẩm, có kiểm soát rủi ro và chi phí.

Có một tín hiệu hơi lạ tuần này: các release đáng chú ý không còn khoe nhiều về việc model trả lời hay hơn trong ô chat. Chúng khoe chuyện khác: agent làm xong việc trên desktop, plugin quét bảo mật ngay trong terminal, model nhỏ tìm file lỗi trong repo, router chọn model theo từng request, text-to-SQL biết soi database trước khi viết query.

Nếu nhìn từng món riêng lẻ, bạn sẽ thấy một rổ tool mới. Nếu nhìn như tín hiệu thị trường, chấn tâm đang dịch chuyển: giá trị không nằm ở model nói gì, mà ở hệ thống quyết định khi nào đọc, khi nào làm, khi nào hỏi lại, và khi nào dừng.

Nói thẳng ra thì: team build AI năm nay không nên hỏi trước tiên “dùng model nào?”, mà nên hỏi “workflow nào đủ rõ để AI chịu trách nhiệm một phần kết quả?”.

Sơ đồ minh họa cho bài AI agent đang rời khỏi ô chat

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

Tín hiệu lạ: ô chat không còn là mặt đất chính

OpenWorker là ví dụ rất rõ cho cú dịch này. Nó không định vị mình như chatbot. Nó là một desktop agent — agent chạy trên máy người dùng, làm việc với file local và app kết nối — nhận mục tiêu đầu ra như tài liệu hoàn chỉnh, email đã phân loại, lịch đã cập nhật, hay Slack reply có số liệu thật.

Chi tiết đáng để builder chú ý không phải tên tuổi đứng sau, mà là kiến trúc:

Điểm mình khoanh đỏ: approval không bị xem như nút bấm phụ trong UI. Mỗi tool call được phân lớp rủi ro: đọc, ghi local, ghi external, hoặc hành động nguy hiểm hơn. Đây là khác biệt giữa demo chạy được và sản phẩm có thể ngồi chung với dữ liệu thật.

Đứt gãy nằm ở đây: trước giờ nhiều team nghĩ agent là model mạnh cộng thêm tool calling. Nhưng khi agent chạm vào file, repo, calendar, email, Slack, shell, thì vấn đề chính không còn là văn hay chữ tốt. Vấn đề là quyền, rủi ro, audit, và rollback.

Mổ lớp đầu: thành phẩm thay cho hội thoại

Chat interface từng rất tiện để khám phá. Nhưng nó cũng tạo một thói quen xấu: người dùng phải tự làm project manager cho AI. Bạn hỏi, AI trả lời, bạn copy, bạn sửa, bạn chạy, bạn phát hiện thiếu, lại hỏi tiếp.

OpenWorker đảo thứ tự: user đưa outcome, hệ thống tự chia bước, gọi tool, và check-in trước hành động quan trọng. Đây là orchestration — điều phối nhiều bước, nhiều tool, nhiều quyết định — chứ không chỉ là prompt dài hơn.

Ví dụ cụ thể: giả sử team bạn cần chuẩn bị bản tổng hợp bug tuần này từ repo, issue tracker và vài file log local. Cách chat cổ điển là paste từng mẩu, nhờ tóm tắt, rồi tự ráp lại. Cách agent-first là giao mục tiêu: “tạo báo cáo bug tuần này, nhóm theo severity, kèm file liên quan và đề xuất owner”. Agent cần đọc repo, tìm issue, chạy search, viết draft, rồi hỏi bạn trước khi gửi ra Slack.

Câu hỏi dành cho builder không phải “agent có làm được không?”. Câu hỏi là:

  1. Nó có biết thao tác nào chỉ đọc và thao tác nào tạo side effect không?
  2. Nó có lưu lại trace để debug không?
  3. Nó có thể dừng ở điểm cần người duyệt không?
  4. Nó có trả về artifact dùng được, hay chỉ thêm một đoạn chat nữa?

Nếu câu trả lời mơ hồ, bạn chưa có coworker. Bạn có một cái tab chat mặc áo khoác desktop.

Mổ lớp hai: inspection đang thắng translation

Một tín hiệu khác đến từ SQRL, dòng text-to-SQL của Feyn AI. Text-to-SQL là bài toán biến câu hỏi tự nhiên thành truy vấn SQL. Nhiều hệ thống xem việc này như dịch thuật: câu người → câu SQL.

SQRL chọn hướng khác: nếu thiếu thông tin, nó chạy read-only queries để soi database trước. Vì schema chỉ nói có cột county, chứ không nói dữ liệu ghi là Alameda, Alameda County, hay ALAMEDA. Một query hợp lệ vẫn có thể trả sai nếu join nhầm, filter nhầm, hoặc hiểu nhầm giá trị.

Đây không chỉ là câu chuyện SQL. Nó là mẫu hình rộng hơn: AI đáng tin hơn khi được phép kiểm tra hiện trường trước khi kết luận.

Claude Security plugin cũng đi cùng hướng đó. Nó chạy trong Claude Code, có command /claude-security, chia scan thành nhiều pha: inventory, threat model, research, sweep, panel, adversarial. Nghĩa là nó không chỉ nói “repo có thể có lỗi”. Nó ép workflow phải đi qua từng lớp kiểm tra: component nào được scan, trust boundary ở đâu, entry point nào đáng đọc, finding nào sống sót qua phản biện.

Antares của Cisco thì hẹp hơn nữa: model nhỏ chuyên tìm file chứa lỗ hổng dựa trên mô tả CWE và repo. Open-weight nghĩa là trọng số model được mở để cộng đồng dùng/tự triển khai theo giấy phép. Điều thú vị là mục tiêu không phải thay toàn bộ AppSec, mà giảm chi phí đoạn triage đầu: từ mô tả lỗ hổng đến danh sách file đáng xem.

Hình dung thế này: bạn không thuê AI làm bác sĩ phẫu thuật ngay. Bạn cho nó đọc phim, khoanh vùng chỗ nghi ngờ, rồi bác sĩ quyết định. Với code security cũng vậy: khoanh vùng đúng đã tiết kiệm rất nhiều công đào.

Mổ lớp ba: model mạnh nhất không còn là default kinh tế

Cursor Router là mảnh còn lại của bức tranh. Nó không bán một model mới. Nó bán quyết định: request nào đáng gửi cho model đắt, request nào nên gửi cho model rẻ hơn.

Request-level classifier là bộ phân loại từng yêu cầu trước khi chạy model. Cursor nói router của họ nhìn vào query, context, độ phức tạp, domain, rồi chọn model phù hợp. Điểm đáng chú ý: họ nhấn mạnh router có tính đến prompt cache — cache ngữ cảnh để giảm chi phí/lặp xử lý — vì đổi model giữa chừng có thể làm mất cache và ăn ngược phần tiết kiệm.

Đây là chỗ nhiều team Việt Nam rất dễ hiểu sai. Routing không phải cứ nhét 5 model vào rồi gọi là tiết kiệm. Nếu mỗi lần route làm cache miss, tăng latency, phá consistency, hoặc khiến output style nhảy lung tung, bạn chỉ vừa tạo thêm một tầng trầm tích vận hành: nhìn trên dashboard thì sâu sắc, đào xuống mới thấy toàn công nợ.

Framework thực dụng mình đề xuất cho builder: 3 câu hỏi trước khi thêm model/router/agent mới.

| Câu hỏi | Nếu câu trả lời là có | Nếu câu trả lời là không |
|---|---|---|
| Task có artifact rõ không? | Có thể build agent trả thành phẩm | Giữ ở dạng copilot/chat hỗ trợ |
| Task có bước inspection an toàn không? | Cho AI đọc/query trước khi viết | Hạn chế AI kết luận từ context tĩnh |
| Task có phân tầng chi phí rõ không? | Dùng router hoặc model matrix | Chọn một model ổn định, đo trước |

Khung này nghe đơn giản, nhưng nó đổi thứ tự quyết định. Bạn không chọn tool trước. Bạn chọn điểm chịu trách nhiệm trước.

Điều đáng giữ: local-first, typed approval, narrow loop

Từ các release này, mình sẽ giữ lại ba thứ.

Một là local-first cho workflow nhạy cảm. Local-first nghĩa là ưu tiên chạy gần dữ liệu người dùng, trên máy hoặc trong môi trường kiểm soát, thay vì đẩy mọi thứ lên service trung tâm. OpenWorker không có inference service riêng; người dùng tự chọn API key hoặc local runtime. Với team có repo nội bộ, tài liệu khách hàng, dữ liệu vận hành, đây không phải chi tiết phụ.

Hai là typed approval. Approval phải gắn với loại hành động, không chỉ là popup “Allow?”. Đọc file khác với sửa file. Tạo patch khác với push code. Soạn Slack reply khác với gửi Slack reply. Nếu không phân loại, audit về sau sẽ giống đi tìm dấu nứt sau khi núi lửa đã phun.

Ba là narrow loop cho tác vụ hẹp. Antares không cố làm “AI security toàn năng”. SQRL không cố trả lời SQL bằng linh cảm. Claude Security plugin không biến scan thành một câu trả lời dài. Các hệ thống tốt đang thu hẹp vòng lặp: đọc đúng thứ, kiểm tra đúng bước, trả artifact đúng dạng.

Điều nên bỏ qua: FOMO model matrix

OpenWorker có model matrix khá rộng, Cursor có router, các tool khác cũng sẽ ngày càng đa provider. Nhưng đừng để danh sách model làm bạn quên việc chính.

Với team 5-20 dev ở Việt Nam, mình sẽ không bắt đầu bằng việc tích hợp đủ mọi provider. Mình sẽ chọn một workflow có pain rõ trong một buổi chiều:

Sau đó đo ba thứ rất đời:

  1. Artifact có giảm việc tay thật không?
  2. Người duyệt có hiểu vì sao AI làm vậy không?
  3. Khi sai, team có biết sai ở tool, retrieval, model, hay approval policy không?

Nếu chưa trả lời được ba câu này, thêm model mới chỉ làm mặt đất rung mạnh hơn chứ chưa chắc xây được gì.

Sau bài này, nên nghĩ khác điều gì?

Đừng nhìn các release AI như cuộc đua ai thông minh hơn. Hãy đọc chúng như tín hiệu incentive: vendor muốn kéo AI ra khỏi ô chat, vào workflow có artifact; enterprise muốn kiểm soát rủi ro và chi phí; builder phải thiết kế lớp kiểm tra, quyền hạn, routing, và review trước khi khoe demo.

Nếu là mình, mình sẽ chọn một workflow nhỏ, có đầu ra rõ, thêm inspection trước generation, thêm approval theo rủi ro, rồi mới nghĩ tới router nhiều model. Agent tốt không cần gây chấn động; nó chỉ cần không làm sập nhà khi mặt đất khẽ rung.

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

Nguồn tham khảo