Agent đáng tin nhờ quầy giao việc rõ

Agent đáng tin nhờ quầy giao việc rõ

Một case study giả định từ team Việt: vì sao agent production cần MCP server, orchestration và guardrail rõ hơn là model mới nhất.

“Em vừa bảo agent cập nhật task QA, nó lại tạo thêm ba sheet mới tên gần giống nhau. Giờ ai xóa đây chị?”

Đó là tin nhắn lúc 9:17 tối của Nam, tech lead một team SaaS giả định ở Sài Gòn mà mình sẽ gọi là Đội Mây. Team này không thiếu người giỏi. Họ có product manager chăm, QA kỹ, backend vững, và một con agent nội bộ được kỳ vọng sẽ “giảm việc điều phối dự án”.

Tuần đầu demo rất vui. Gõ tiếng Việt, agent đọc backlog, tóm tắt sprint, nhắc task trễ. Sang tuần thứ ba, mọi thứ bắt đầu giống đi chợ gặp sạp treo bảng giá mềm nhưng cân lúc nào cũng lệch: nhìn thì tiện, về nhà mới phát hiện thiếu nửa ký rau.

Vấn đề của Đội Mây không phải model dở. Vấn đề là họ cho agent đi thẳng vào hệ thống nghiệp vụ mà không có quầy giao việc đủ rõ: tool nào được gọi, dữ liệu nào được thấy, thao tác nào cần xác nhận, lỗi nào phải dừng.

Sơ đồ minh họa cho bài Agent đáng tin nhờ quầy giao việc rõ

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

Cảnh nền: agent không cần thêm quyền, nó cần đường đi

Đội Mây dùng một hệ thống quản lý công việc kiểu bảng/sheet: task, deadline, owner, status, attachment, comment. Ban đầu họ nối agent trực tiếp vào vài API nội bộ:

Nghe ổn. Nhưng chỉ sau vài ngày, agent bắt đầu vấp những ca rất đời:

MCP — Model Context Protocol, hiểu là giao thức để AI client nói chuyện có cấu trúc với tool và dữ liệu — xuất hiện đúng chỗ này. Case Smartsheet xây remote MCP server trên AWS đáng chú ý không phải vì “ồ, thêm một server MCP nữa”, mà vì họ coi MCP như lớp sản phẩm production: dùng chung cho AI trong app lẫn AI client bên ngoài, đi qua cùng tool, cùng tối ưu, cùng governance.

Đây là điểm nhiều team dễ bỏ qua: MCP server không chỉ là adapter nối model với API. Với hệ thống thật, nó là nơi bạn đóng gói orchestration — điều phối nhiều bước/tool — và guardrail — hàng rào giới hạn hành vi — thành hợp đồng vận hành.

Quyết định sai đầu tiên: để agent tự kỳ kèo với API

Đội Mây có ba lựa chọn.

| Lựa chọn | Cách làm | Ưu điểm | Rủi ro |
|---|---|---|---|
| Nối thẳng model vào API | Tool schema mỏng, model tự suy luận | Nhanh có demo | Dễ gọi sai tool, tốn token, khó kiểm soát quyền |
| Viết workflow cứng | Backend định nghĩa từng flow | Dễ audit, ổn định | Kém linh hoạt, mỗi intent mới lại code thêm |
| Dựng remote MCP layer | Một lớp tool AI-optimized nằm giữa client và hệ thống | Dùng chung cho nhiều agent, kiểm soát tốt hơn | Cần thiết kế schema, auth, logging, versioning nghiêm túc |

Ban đầu họ chọn cách một. Vì nhanh. Vì demo đẹp. Vì ai cũng muốn khoe “agent đã biết thao tác trong hệ thống”.

Nhưng production không thưởng cho demo nhanh. Production thưởng cho thứ chạy hôm nay, tuần sau vẫn đoán được nó sẽ làm gì.

Nói thẳng ra thì: agent càng tự do ở tầng API, bạn càng phải trả nợ ở tầng vận hành.

Cú xoay: MCP server không bán API thô, nó bán hành động an toàn

Sau hai sprint dọn lỗi, Đội Mây đổi cách nghĩ. Họ không expose API nội bộ y nguyên nữa. Họ thiết kế lại tool theo hành động mà người dùng thật sự muốn.

Thay vì:

{
  "tool": "update_task",
  "params": {
    "task_id": "string",
    "fields": "object"
  }
}

Họ tách thành:

{
  "tool": "mark_tasks_done_for_scope",
  "params": {
    "project_id": "string",
    "scope": "current_sprint | previous_week | explicit_list",
    "task_type": "qa | dev | docs",
    "requires_confirmation": true
  }
}

Khác biệt nằm ở chỗ: tool thứ hai không bắt model tự đoán toàn bộ nghiệp vụ. Nó ép model nói rõ phạm vi, loại task, và có cờ xác nhận trước khi ghi dữ liệu.

Hình dung thế này: nếu API thô là để agent tự đi từng sạp hỏi giá, MCP tool tốt giống một quầy đã phân loại hàng, niêm yết rõ cân nào, món nào phải hỏi chủ sạp trước khi lấy. Vẫn linh hoạt, nhưng bớt cảnh mua nhầm.

Trong case Smartsheet, điều mình thấy đáng học là họ đặt một lớp AI-optimized interface lên trên API có sẵn. Lớp này không chỉ “dịch câu chữ thành endpoint”; nó còn được tối ưu để giảm token, hạn chế hallucination — tức model bịa nhưng nói như thật — và giúp LLM làm việc đáng tin hơn với dữ liệu enterprise. Theo bài của AWS, Smartsheet ghi nhận tiết kiệm hơn 3 tỷ token dựa trên telemetry nội bộ sau các tối ưu này. Con số này không nên bị đọc như benchmark phổ quát, nhưng nó nhắc một chuyện rất thực tế: schema tốt và context gọn có thể tiết kiệm tiền thật.

Hệ quả: lỗi không biến mất, nhưng lỗi có địa chỉ

Sau khi dựng MCP layer, Đội Mây không biến agent thành thiên tài. Nhưng họ đổi được loại lỗi.

Trước đó, khi agent làm sai, team phải hỏi:

Sau đó, lỗi có chỗ để soi:

Đây là bước trưởng thành của hệ thống agent: từ “model có thông minh không?” sang “khi nó sai, mình khoanh vùng được sai ở đâu không?”.

Với builder, đây là khác biệt cực lớn. Một lỗi hallucination trong chat có thể sửa bằng prompt. Một lỗi agent cập nhật nhầm dữ liệu khách hàng thì cần permission boundary — ranh giới quyền rõ ràng — và idempotency — gọi lại không gây tác dụng phụ ngoài ý muốn.

Ví dụ cụ thể: nếu agent attach test result vào task, tool nên nhận artifact_id và task_id, rồi server kiểm tra artifact thuộc đúng project. Đừng để model gửi đường dẫn file tự do rồi backend tin luôn. Agent không nên được cầm túi tiền đi kỳ kèo mọi sạp trong chợ chỉ vì nó nói năng lễ phép.

Framework cho team builder: 4 cửa trước khi mở tool

Nếu bạn đang build agent/automation cho hệ thống nội bộ, mình sẽ dùng khung 4 cửa MCP này trước khi expose bất kỳ tool nào.

1. Cửa ý định: tool đại diện cho việc gì?

Đừng bắt model ghép API vụn nếu user chỉ muốn một hành động nghiệp vụ.

Sai hướng:

get_sheet -> filter_rows -> update_cell -> add_comment

Tốt hơn:

move_ready_qa_tasks_to_done(project_id, sprint_id, confirmation_token)

Tool nên nói bằng ngôn ngữ workflow, không phải bằng mảnh endpoint.

2. Cửa dữ liệu: trả vừa đủ context

Context window là vùng ngữ cảnh model còn giữ trong một lượt xử lý. Nhồi quá nhiều comment, history, attachment text vào tool response sẽ làm model rối và tốn token.

Một response tốt nên có:

Đừng trả toàn bộ sheet nếu model chỉ cần 12 task đang overdue.

3. Cửa quyền: ai được làm gì, trong ngữ cảnh nào?

Remote MCP server phải coi auth là chuyện lõi, không phải middleware trang trí. Nếu agent đại diện cho user, quyền của agent nên bị giới hạn theo user đó. Nếu agent chạy nền, nó cần service identity riêng, scope riêng, audit riêng.

Hai câu hỏi đáng hỏi trước khi ship:

Không phải mọi thứ đều cần hỏi lại user. Nhưng những thao tác tạo mới, xóa, đổi trạng thái hàng loạt, gửi thông báo ra ngoài nên có cơ chế xác nhận hoặc dry-run.

4. Cửa quan sát: lỗi được nhìn thấy ở đâu?

Telemetry — dữ liệu quan sát hệ thống khi chạy — không chỉ để vẽ dashboard. Với agent, telemetry giúp bạn biết tool nào tốn token, intent nào thất bại, client nào gọi sai phiên bản, guardrail nào chặn nhiều nhất.

Log tối thiểu nên có:

Không có lớp này, bạn đang vận hành bằng cảm giác.

Áp dụng trong một buổi: audit 5 tool nguy hiểm nhất

Bạn không cần dựng lại toàn bộ platform ngay. Một buổi chiều đủ để soi những điểm dễ gây cháy.

Chọn 5 tool có quyền ghi dữ liệu hoặc ảnh hưởng workflow, rồi điền bảng này:

| Câu hỏi | Ghi chú |
|---|---|
| Tool này phục vụ intent nghiệp vụ nào? | Nếu trả lời bằng tên API, cần viết lại |
| Input nào do model suy luận? | Cái gì suy luận thì có nguy cơ sai |
| Có thao tác hàng loạt không? | Nếu có, cần dry-run hoặc confirmation |
| Response có dư context không? | Dư context là dư tiền và dư nhiễu |
| Có audit trail đủ đọc lại sau 1 tuần không? | Không nhớ được thì không debug được |

Sau đó, ưu tiên sửa một tool có tần suất dùng cao nhất. Đừng cố “MCP hóa” cả công ty trong một lần. Làm một quầy rõ ràng trước, rồi mới mở thêm sạp.

Điều nên nghĩ khác sau bài này

Nếu trước đây bạn xem MCP server như lớp kết nối để agent gọi tool, hãy nâng nó lên thành control plane mini cho hành động AI: nơi định nghĩa intent, quyền, context, logging và giới hạn tác dụng phụ.

Smartsheet đáng học ở điểm họ không tách trải nghiệm AI nội bộ và AI client bên ngoài thành hai đường vận hành rời rạc. Một MCP layer dùng chung giúp tool, tối ưu và governance đi cùng nhau. Với team nhỏ hơn, bài học không phải “hãy copy kiến trúc AWS của họ”, mà là: đừng để mỗi agent tự học cách cư xử với dữ liệu production.

Agent giỏi không phải agent được thả vào kho API rộng nhất. Agent giỏi là agent biết đi đúng quầy, hỏi đúng món, cân đúng ký — và nếu lỡ mua nhầm, còn có hóa đơn để bạn quay lại bắt đền.

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

Nguồn tham khảo