Agent bền vững phải xem mô hình là thành phần có thể thay thế
Tích hợp AI agent là cách kết nối mô hình với công cụ, dữ liệu và trạng thái qua giao diện ổn định để agent hoàn thành công việc mà không phụ thuộc vào một nhà cung cấp duy nhất. Đây nên là điểm xuất phát của mọi kiến trúc agent doanh nghiệp, không phải một lớp vá thêm sau khi hệ thống đã gắn chặt với một mô hình.
Thị trường thay đổi nhanh đến mức lựa chọn mô hình hôm nay khó có thể là lựa chọn lâu dài. Ngày 15 tháng 6 năm 2026, Anthropic ngừng cung cấp Claude Sonnet 4 và Claude Opus 4 qua API sau khi báo trước từ ngày 14 tháng 4; ứng dụng còn gọi các mã mô hình này bắt đầu gặp lỗi. Cuối tháng đó, OpenAI đóng Assistants API và hướng nhà phát triển sang Responses API. Những thay đổi có thông báo trước, nhưng hệ thống xây mô hình làm nền móng vẫn có thể buộc đội ngũ sửa lại agent.
Giải pháp không phải né tránh việc chọn mô hình, mà là đặt mô hình sau một hợp đồng ổn định, giữ công cụ và trạng thái bên ngoài hệ sinh thái riêng của nhà cung cấp, đồng thời đánh giá mỗi lần đổi mô hình bằng phép đo đáng tin cậy. Khi đó, đổi mô hình AI vì chi phí vận hành, năng lực, quyền riêng tư hay hiệu suất trở thành quyết định có thể kiểm chứng, thay vì dự án xây lại.
Ánh xạ từng API thành công cụ tạo ra sự phức tạp
Một API cho AI agent không nên chỉ là bản sao của giao diện dành cho lập trình viên. Jira có khoảng 725 thao tác REST API nếu tính riêng từng tổ hợp endpoint và phương thức HTTP. Đưa mỗi thao tác thành một MCP tool có vẻ là đường tắt để phủ rộng chức năng, nhưng danh sách công cụ phình to sẽ làm tăng chi phí lựa chọn và khiến agent khó hoàn thành trọn vẹn mục tiêu.
Công việc thực tế hiếm khi gói gọn trong một lệnh gọi. Đóng một vấn đề Jira có thể cần đáp ứng điều kiện chuyển trạng thái, cung cấp thông tin bắt buộc hoặc có quyền phù hợp. Nếu agent chỉ thấy một endpoint chuyển trạng thái, nó dễ gửi yêu cầu thiếu dữ liệu, gặp lỗi rồi thử lại hoặc báo sai rằng hệ thống bị hỏng.
Hàng trăm lược đồ còn chiếm cửa sổ ngữ cảnh trước khi agent kịp suy luận; các công cụ gần giống nhau khiến nó chọn sai. Cách phủ API tối đa có thể hấp dẫn với đội muốn mở rộng nhanh, nhưng đó là lựa chọn kém bền vững khi số tích hợp, quy tắc nghiệp vụ và người quản trị cùng tăng.
MCP server Jira nên bắt đầu từ việc người dùng muốn làm
Thiết kế tốt hơn bắt đầu từ tác vụ: đóng một vấn đề, khởi chạy sprint hay tìm việc cần ưu tiên hôm nay. Thay vì để agent tự ghép nhiều endpoint theo đúng thứ tự, máy chủ MCP điều phối các lời gọi cần thiết để agent tập trung vào kết quả. Đó là khác biệt giữa phơi bày khả năng của API và tạo ra một tích hợp AI agent hữu ích.
Phiên bản đầu của Atlassian MCP chọn cách làm tối thiểu để đưa công cụ đến tay khách hàng và học từ nhu cầu sử dụng. Khi cân nhắc mở rộng, nhóm đối mặt với hai cực: một máy chủ phơi bày phần lớn API rộng lớn, hoặc một tập công cụ hẹp cho vài trường hợp cụ thể. Hướng hợp lý hơn là chọn các tác vụ phổ biến, nhưng vẫn để độ sâu cấu hình sẵn có khi cần.
Kết quả hiện được mô tả là 52 công cụ Jira gọi hơn 100 API riêng biệt. Theo dữ liệu nội bộ được công bố, mức sử dụng tăng đều, tỷ lệ lỗi công cụ giảm rõ rệt và nhóm tiếp tục đánh giá tác động lên ngữ cảnh, chi phí cũng như khả năng đạt đúng kết quả người dùng mong muốn. Đây là bằng chứng ủng hộ thiết kế theo công việc, dù việc đo lường cần tiếp tục khi phạm vi sử dụng mở rộng.
Ít công cụ hơn không có nghĩa là ít kiểm soát hơn
Thu gọn bề mặt công cụ chỉ giải quyết một phần bài toán. Với tác vụ nhiều bước, chạy mã do agent viết có thể giảm lượng nội dung đưa vào ngữ cảnh: một thử nghiệm ghi nhận quy trình dùng khoảng 120.000 token khi gọi công cụ theo cách thông thường chỉ cần khoảng 1.200 token ở chế độ mã. Nhưng tiết kiệm token không tự động tạo ra an toàn.
Thực thi mã cần môi trường cách ly đáng tin cậy và khả năng quan sát đầy đủ những lời gọi thực tế. Tương tự mọi API cho AI agent truy cập hệ thống sản xuất, tích hợp phải có xác thực, phân quyền, giới hạn tốc độ và nhật ký kiểm toán. Đây là yêu cầu nền tảng ngay từ đầu, không phải phần việc để dành đến sau khi chạy thử.
MCP server Jira cũng phải tôn trọng quyền hiện có: agent không thể làm điều người dùng không được phép làm. Quản trị viên có thể chặn truy cập của agent vào dự án hoặc nội dung nhạy cảm; vì thế, người dùng có thể mở một vấn đề bị hạn chế trong trình duyệt nhưng agent làm việc thay họ vẫn không được đọc nội dung đó.
Nguyên tắc đáng theo là kết hợp hợp đồng mô hình ổn định, công cụ được đặt tên theo tác vụ, đánh giá định lượng và lớp quyền truy cập có kiểm toán. Không nên chọn giữa phủ kín mọi endpoint và khóa agent vào vài thao tác cứng nhắc; hãy tập trung vào công việc phổ biến, giữ các quyền nhạy cảm dưới kiểm soát của quản trị viên và mở rộng khi dữ liệu sử dụng chứng minh nhu cầu. Đó là con đường giúp agent dễ đổi mô hình mà không phải xây lại, đồng thời đủ an toàn để vận hành ở quy mô doanh nghiệp.
