Đã đăng vào about 5 hours ago 15 phút đọc

90 Ngày Xây Agent Thực Chiến: Lộ Trình Cho Kỹ Sư Không Muốn Demo Suông

Công ty bạn đã có một cái copilot đâu đó. Leadership đã xem demo. Mọi người gật đầu trong các cuộc họp. Nhưng câu hỏi khiến bạn mất ngủ đã chuyển từ "Agentic AI có thú vị không?" thành "Làm sao để build thứ gì đó chạy được trong production mà không tạo ra cơn ác mộng governance?"

Hầu hết các pilot AI doanh nghiệp thất bại vì cùng một lý do: kỷ luật vận hành đến quá muộn. Một số team lao vào build demo mà không có baseline nào để đo lường. Số khác ngồi hàng tháng trong các phiên chiến lược và không bao giờ chạm vào một API thật. Cả hai con đường đều dẫn đến ngõ cụt — rất nhiều hoạt động, rất ít bằng chứng.

Chuyển đổi agentic không đến từ slide deck. Nó đến từ những pilot vận hành có giới hạn, có thể đo lường, và được review nghiêm ngặt. Đây là lộ trình 90 ngày dành cho kỹ sư muốn build một pilot như vậy.

Nguyên tắc cốt lõi: chọn một domain có giá trị, giới hạn phạm vi để rủi ro có thể quản lý được, thiết kế agent và controls một cách tường minh, test trên workflow thật (không chỉ prompt), và sau đó đưa ra quyết định cứng — scale, redesign, hoặc dừng — dựa trên những gì bạn thực sự học được.

Lộ trình này hoạt động tốt nhất khi bạn đã có quy trình ổn định, một business sponsor rõ ràng, và sự sẵn sàng tối thiểu về data, integration, và governance. Nếu những nền tảng đó còn thiếu, 90 ngày vẫn hữu ích — đầu ra của bạn có thể chỉ là quyết định sửa nền móng trước.

Sơ đồ ba vùng: chọn workflow ở trên, vòng lặp điều khiển agent ở giữa, và cổng quyết định 90 ngày ở dưới. Ba vùng của một pilot agentic có kỷ luật: chọn domain, thiết kế controls, sau đó thực thi và quyết định.

Tại Sao Lại Là 90 Ngày?

Với một pilot agentic trong doanh nghiệp, 90 ngày là khoảng thời gian lý tưởng. Quá ngắn, bạn chỉ kịp làm một demo bóng bẩy. Quá dài, pilot biến thành một chương trình chuyển đổi thu nhỏ, mất focus và tích lũy technical debt.

Trong 90 ngày, team của bạn phải trả lời được năm câu hỏi kỹ thuật quan trọng:

Workflow được chọn có value pool thực sự, có thể đo lường được không?
Agent có thể vận hành an toàn trong ranh giới autonomy của nó không?
Người dùng có thực sự được giúp đỡ, hay chỉ bị ấn tượng bởi sự mới lạ?
Controls, audit trails, và monitoring có đủ cho production giới hạn không?
Kinh tế học và operating fit có đủ mạnh để biện minh cho việc scale không?

Nếu bạn không trả lời được những câu này sau 90 ngày, bạn không có cơ sở lành mạnh để mở rộng mô hình agentic sang bất kỳ đâu khác trong tổ chức.

Ngày 1–15: Chọn Chiến Trường và Thiết Lập Baseline

Giai đoạn đầu tiên không phải về công nghệ. Nó là về việc chọn đúng domain. Sai lầm phổ biến nhất là chọn use case quá dễ (và do đó không quan trọng) hoặc quá tham vọng (và do đó chắc chắn thất bại trước khi dạy bạn bất cứ điều gì).

Một pilot domain tốt có những đặc điểm sau:

Workflow diễn ra thường xuyên (ít nhất vài chục lần mỗi tuần)
Có bottleneck hoặc backlog thực sự
Có nhiều bước bàn giao thủ công hoặc xử lý ngoại lệ
Hệ thống nguồn và dữ liệu có thể truy cập hợp lý qua API
Chủ quy trình có thể xác định và sẵn sàng tham gia
Thất bại của pilot không tạo ra rủi ro vật chất không kiểm soát được

Ứng viên tốt:

Hỗ trợ chốt sổ tài chính (thu thập bằng chứng, phân tích variance, soạn thảo commentary)
Tiếp nhận yêu cầu mua sắm (phân loại yêu cầu, kiểm tra chính sách, định tuyến)
Vận hành khách hàng (tóm tắt case, soạn thảo phản hồi, phân loại escalation)
Vận hành IT (phân loại incident, đề xuất runbook)
Xử lý ngoại lệ chuỗi cung ứng

Tránh các domain nơi:

Quy trình cơ bản hỗn loạn hoặc không được tài liệu hóa
Chính sách chỉ tồn tại trong đầu mọi người
Dữ liệu phân tán không có chủ sở hữu rõ ràng
Các quyết định quá quan trọng để có guardrails rõ ràng

Khi đã chọn domain, hãy map workflow thực tế end-to-end. Không chỉ nơi AI có thể phù hợp — mọi bước, mọi bàn giao, mọi ngoại lệ, mọi điểm chạm hệ thống, mọi điểm phê duyệt. Đây là sơ đồ kiến trúc hệ thống của bạn.

Sau đó thiết lập baseline metrics:

Thời gian xử lý mỗi case
Chi phí mỗi case
Tỷ lệ lỗi
Kích thước backlog
Tỷ lệ escalation
Điểm hài lòng của người dùng

Không có baseline, pilot của bạn sẽ chạy dựa trên ý kiến, không phải bằng chứng.

Quan trọng nhất, hãy thống nhất về thành công trông như thế nào trước khi build bất cứ thứ gì. Xác định ngưỡng giảm cycle time, tỷ lệ correction chấp nhận được, mục tiêu áp dụng người dùng, và ranh giới rủi ro. Nếu thành công không được định nghĩa ngay từ đầu, bạn sẽ không bao giờ có thể kết thúc pilot một cách khách quan.

Ngày 16–35: Thiết Kế Agent, Ranh Giới, và Controls

Bây giờ bạn thiết kế agent. Trọng tâm không phải là làm cho nó thông minh. Mà là làm cho nó rõ ràng, có giới hạn, và có thể kiểm toán.

Thẻ Agent (Agent Card)

Mỗi pilot cần một agent card — một trang tài liệu xác định danh tính vận hành của agent. Bao gồm:

Kết quả nó nhắm tới
Phạm vi case nó có thể và không thể xử lý
Các công cụ và API nó có thể gọi
Các nguồn dữ liệu nó có thể truy cập
Chủ sở hữu kinh doanh và chủ sở hữu rủi ro
Bậc rủi ro (thấp, trung bình, cao)
Tiêu chí thành công cho giá trị, chất lượng, áp dụng, và rủi ro

Agent card buộc tổ chức của bạn ngừng nói về những điều trừu tượng. Nó biến một ý tưởng thành một đối tượng vận hành mà business, IT, security, và risk đều có thể review cùng nhau.

Mức Độ Autonomy

Một trong những quyết định quan trọng nhất trong 90 ngày đầu là agent được bao nhiêu autonomy. Một tiến trình lành mạnh:

Đọc/giám sát — quan sát workflow, không hành động
Soạn thảo/đề xuất — đưa ra gợi ý, con người review trước khi thực thi
Thực thi với phê duyệt — hành động, nhưng cần con người ký xác nhận
Thực thi với giám sát — hành động tự động, con người giám sát ngoại lệ

Với pilot đầu tiên, hầu hết các công ty nên dừng ở mức soạn thảo hoặc đề xuất.

Ba Câu Hỏi Kiểm Soát

Một pilot agentic lành mạnh luôn có câu trả lời rõ ràng cho ba câu hỏi:

Khi nào con người phải phê duyệt? (dựa trên giá trị giao dịch, độ tin cậy của agent, loại case, độ nhạy cảm của dữ liệu, hoặc tác động vận hành)
Khi nào case phải được escalation? (đến con người thực, không phải hộp tổ chức trừu tượng)
Những gì phải được ghi lại để kiểm toán? (mọi quyết định, mọi lời gọi công cụ, mọi điểm số tin cậy)

Nền Tảng Vận Hành Tối Thiểu

Nhiều pilot thất bại không phải vì model tồi, mà vì nền tảng vận hành chưa sẵn sàng. Bốn thành phần tối thiểu:

Kiến thức nền sạch: SOP, chính sách, runbook ở định dạng có thể truy xuất
Truy cập API giới hạn: đến các hệ thống cốt lõi, với quyền hạn được phạm vi
Tool registry: xác định agent có thể gọi gì, với versioning và deprecation
Môi trường sandbox: để test thực tế mà không có rủi ro production

Sự đánh đổi rõ ràng: bạn càng muốn go live nhanh, càng dễ cắt góc trong thiết kế control. Điều đó hầu như luôn trở thành món nợ đắt đỏ trong những tuần sau đó.

Ngày 36–65: Build MVP và Test Nghiêm Túc

Một MVP agentic không phải là chatbot trả lời câu hỏi. Nó là một workflow hẹp hoạt động trên các case thực tế.

Phạm vi MVP của bạn thật chặt:

Một loại ngoại lệ hóa đơn
Một danh mục incident
Một tuyến mua sắm
Một khu vực
Một nhóm tài khoản

Test trên các case lịch sử, bao gồm cả những case lộn xộn và mơ hồ. Kiểm tra:

Chất lượng truy xuất — agent có tìm đúng tài liệu chính sách không?
Hành vi công cụ — nó có gọi đúng API với đúng tham số không?
Tuân thủ chính sách — nó có tôn trọng guardrails bạn đã định nghĩa không?
Logic escalation — nó có biết khi nào bàn giao cho con người không?
Chất lượng đầu ra — kết quả có thực sự giúp ích cho người dùng không?

Mục tiêu không phải là sự hoàn hảo. Mục tiêu là một agent đủ hữu ích, đủ an toàn, và đủ nhất quán để có thể đo lường.

Ngày 66–90: Chạy Pilot Có Giới Hạn, Giám Sát Chặt, và Đưa Ra Quyết Định

Chạy pilot trong vận hành giới hạn. Một team. Một thực thể. Một khu vực. Một danh mục giao dịch. Một loại case.

Đo lường không ngừng:

Giá trị: giảm cycle time, tiết kiệm chi phí, giảm backlog
Chất lượng: tỷ lệ correction, sự hài lòng của người dùng, tỷ lệ escalation
Rủi ro: số lượng incident, suýt xảy ra, vi phạm chính sách
Áp dụng: tỷ lệ phần trăm case đủ điều kiện được agent xử lý
Chi phí: chi phí mỗi kết quả thành công so với xử lý thủ công

Quyết Định Ngày 90

Vào ngày 90, đưa ra quyết định thực sự:

Scale — nếu giá trị rõ ràng và rủi ro được kiểm soát
Redesign — nếu ý tưởng đúng nhưng data, workflow, hoặc controls chưa chín muồi
Dừng — nếu use case không đủ giá trị hoặc quá rủi ro

Kéo dài pilot vô thời hạn là kết quả tồi tệ nhất. Nó bảo tồn hoạt động mà không có học tập.

Điều Gì Thường Giết Chết Một Pilot 90 Ngày

Hầu hết các pilot 90 ngày thất bại vì những lý do có thể dự đoán và tránh được:

Team bắt đầu với công nghệ thay vì workflow
Không có baseline, nên thành công trở thành vấn đề ý kiến
Phạm vi leo thang từ một workflow lên ba
Governance đến muộn, sau khi agent đã được build
Business sponsor có mặt ở kickoff nhưng vắng mặt khi cần quyết định trade-off vận hành

Giải pháp là kỷ luật: một workflow, một baseline, giới hạn autonomy rõ ràng, controls hiển thị, và một quyết định ngày 90 thực sự.

Không phải pilot nào cũng nên scale. Một số nên được redesign. Một số nên dừng. Đó không phải thất bại — đó là bằng chứng đang làm nhiệm vụ của nó.

Áp Dụng Vào Hệ Thống Thật

Đối với team engineering, lộ trình này dịch thành một tập các deliverable cụ thể:

Tuần 1-2: Workflow map + tài liệu baseline metrics + tiêu chí thành công
Tuần 3-5: Agent card + thiết kế control + thiết lập knowledge base + môi trường sandbox
Tuần 6-9: MVP agent + test trên case lịch sử + lặp lại trên các thất bại
Tuần 10-13: Chạy production giới hạn + dashboard giám sát + báo cáo quyết định

Mỗi giai đoạn có tiêu chí thoát rõ ràng. Nếu bạn không thể đáp ứng tiêu chí, bạn dừng và học, thay vì đẩy tiếp với nền tảng không ổn định.

Ví dụ thực tế: một team xử lý incident IT có thể chọn "phân loại incident mức P2 cho hệ thống ERP" làm workflow pilot. Họ map quy trình hiện tại (tốn 45 phút mỗi incident, 30% bị phân loại sai), thiết lập baseline, build agent chỉ đọc ticket và đề xuất phân loại, test trên 200 ticket lịch sử, sau đó chạy pilot 4 tuần với một team support. Kết quả: giảm thời gian phân loại xuống 5 phút, tỷ lệ sai giảm còn 8%. Họ scale lên toàn bộ incident P2 sau khi xác nhận controls hoạt động.

Lời Kết

Nếu trong 90 ngày bạn chỉ có thể ch

AI architecture Machine Learning