English version: Forward Deployed Engineer: The Role That Gets AI Agents Into Production. Phần 6 của series. Phần trước: Đánh giá agent. Phần sau: MCP.

Lần đầu tôi làm công việc này, nó chưa có tên. Một khách hàng mua của chúng tôi một pilot xử lý tài liệu, và sau hai tháng họp hằng tuần, độ chính xác trên tài liệu thật của họ còn xa mới bằng demo. Thế là tôi đến ngồi ở văn phòng họ một tuần. Đến thứ tư tôi đã hiểu vấn đề: một phần ba số "PDF" của họ là ảnh chụp giấy bằng điện thoại, cấu trúc thư mục mã hoá thông tin mà không ai viết ra, và những người sẽ dùng hệ thống không mở email, họ mở ổ đĩa dùng chung. Không có điều nào trong số đó nằm trong brief. Tất cả quyết định dự án có chạy hay không.

Tuần đó là Forward Deployed Engineering. Giờ vai trò này có tên, có trang Wikipedia, có một làn sóng tuyển dụng ở mọi AI lab, và một đống bình luận ngày càng dày. Bài này là điều tôi nghĩ về nó từ bên trong, nó không phải là gì, và làm sao làm tốt khi bạn không có ngân sách của một frontier lab.

Vai trò là gì, và từ đâu ra#

Forward Deployed Engineer là một kỹ sư phần mềm làm việc bên trong môi trường của khách hàng để sản phẩm tạo ra giá trị ở đó, và mang những gì học được ngược về sản phẩm. Hai nửa quan trọng ngang nhau. Thiếu nửa đầu thì đó là việc của product engineer. Thiếu nửa sau thì đó là consulting.

Palantir phát minh ra cách làm này; lần dùng thuật ngữ sớm nhất được đăng mà tôi tìm được là một bài TechCrunch năm 2010 về công ty, và các deployment ban đầu của họ nằm trên mạng chính phủ bảo mật, thường cách ly hoàn toàn, nơi cách duy nhất để ship là có mặt tại chỗ. Palantir vẫn gọi vai trò này là Forward Deployed Software Engineer. Suốt một thập kỷ nó là thứ lạ của riêng Palantir. Rồi các mô hình ngôn ngữ lớn xuất hiện với một đặc tính cụ thể: chúng dùng được cho mọi mục đích, còn giá trị chúng tạo ra thì hoàn toàn đặc thù cho dữ liệu, quy trình và hệ thống của một tổ chức. Khoảng cách giữa "model làm được" và "chạy được ở đây" trở thành cả cuộc chơi, và FDE là công việc khép khoảng cách đó.

Đến 2025 OpenAI đã dựng một tổ chức FDE, Anthropic tuyển cho vị trí này, và đến 2026 chức danh xuất hiện ở Databricks, Google Cloud, Stripe và một dải dài startup. Một phân tích tôi đọc ước mức tăng lượng tìm kiếm thuật ngữ này trong mười hai tháng tới tháng 8/2026 là hơn 1.300%, và Business Insider đưa tin số tin tuyển FDE trên Indeed tăng mạnh giữa tháng 4/2025 và tháng 4/2026. Dữ liệu lương hiện có chỉ ở Mỹ và do người dùng tự khai (Levels.fyi ghi median tổng thu nhập ở Palantir khoảng 211.000 USD, còn các mức lương cơ bản công bố ở các lab chạy từ khoảng 185.000 đến 320.000 USD), nên hãy coi nó là tín hiệu rằng các công ty đánh giá cao vai trò này, không phải thước đo cho nơi khác.

Vì sao AI làm nó trở nên cần thiết#

Ba thứ đã đổi với LLM khiến FDE thành vai trò nút cổ chai thay vì "có thì tốt".

Bề mặt tích hợp phình ra gấp nhiều lần. Sản phẩm SaaS cổ điển có một API và một UI. Sản phẩm agent chạm vào tài liệu của khách, database của họ, hệ thống ticket, email, mô hình phân quyền, và phải cư xử đúng trên tất cả (harness ở phần 2, dựng trên những hệ thống bạn không kiểm soát). Không ai ở phía vendor biết các hệ thống đó trông ra sao. Phải có người đi mà tìm hiểu.

Đánh giá cần kiến thức miền. Bạn không thể biết agent trích xuất có đúng về một hợp đồng xây dựng tiếng Việt hay không nếu thiếu người đọc hợp đồng xây dựng tiếng Việt (bộ eval ở phần 5 được xây từ lỗi của khách, và lỗi của khách chỉ nhìn thấy được từ bên trong). FDE là người biến câu "thấy sai sai" của một nhân viên vận hành thành một task trong bộ eval.

Sản phẩm học từ deployment. Mọi tính năng trong một sản phẩm agent trưởng thành đều bắt đầu từ thứ một FDE dựng cho một khách hàng: một tool, một file skill, một guardrail, một quy tắc compaction. Các lab nói thẳng điều này; FDE là bộ phận khám phá sản phẩm của họ. Ở công ty nhỏ hơn của chúng tôi, điều tương tự cũng đúng: harness nội bộ và thư viện eval của chúng tôi chính là phần cặn tổng quát hoá từ các dự án khách hàng.

Còn một lý do kém đẹp hơn. Các lab bán hợp đồng theo mức dùng, mức dùng theo mức áp dụng, và mức áp dụng tắc ở chặng cuối. Một FDE là cách rẻ nhất để gỡ tắc một hợp đồng bảy chữ số. Đó không phải hoài nghi, đó là bài toán kinh tế trả lương cho vai trò này, và là lý do FDE được cấp quyền truy cập production và ảnh hưởng tới roadmap mà consultant không bao giờ có.

Vòng lặp#

Công việc có một hình dạng, và khi đã thấy nó bạn phân biệt được FDE thật với professional services đổi tên.

Ngồi với công việc. Không phải với người tài trợ dự án, mà với những người sẽ dùng hệ thống. Quan sát họ làm việc một ngày. Tìm ổ đĩa dùng chung, file spreadsheet chứa quy trình thật, bước mà mỗi người làm một kiểu. Trong tuần tại chỗ của tôi, đây là toàn bộ giá trị; phần kỹ thuật sau đó khá đơn giản một khi đã biết vấn đề thật là gì.

Dựng tại chỗ. Trong môi trường của họ, trên dữ liệu của họ, với ràng buộc của họ. Đây là lúc bộ máy của series vào việc: harness cấu hình cho hệ thống của họ, policy tool khớp khẩu vị rủi ro của họ, sandbox làm hài lòng team bảo mật của họ. Sản phẩm bàn giao không phải một slide. Là một thứ đang chạy.

Đưa lên production. Người dùng thật, dữ liệu thật, một con số dịch chuyển. Định nghĩa "xong" tôi dùng là đi mượn và tôi nghĩ nó đúng: team của khách dựa vào nó trong production, và sản phẩm đã học được điều gì đó. So với product engineer (xong khi merge), solutions architect (xong khi deal chốt và thiết kế được bàn giao) và consultant (xong khi deliverable được chấp nhận và giờ được tính tiền).

Tổng quát hoá ngược về. Lấy thứ đã dựng cho một khách và quyết định cái gì thành sản phẩm: tool, task eval, skill, tích hợp. Đây là bước thường xuyên không xảy ra nhất, vì FDE đã bị kéo sang khách tiếp theo và không ai sở hữu nó. Nếu tổ chức của bạn không có cơ chế tường minh cho bước này, bạn không có FDE, bạn có một nhánh consulting với chức danh đẹp hơn.

Một tuần tốt#

Một tuần khi mọi thứ suôn sẻ, lấy từ một dự án gần đây chứ không phải phiên bản lý tưởng hoá.

Thứ hai là quyền truy cập. Nửa ngày ngồi với IT của khách để có một user database read-only, một service account chỉ có quyền trên một mailbox, và một VM bên trong mạng của họ, đúng kỷ luật sandbox ở phần 4 áp lên hạ tầng của người khác. Nửa ngày còn lại ngồi cạnh hai nhân viên vận hành khi họ xử lý tài liệu buổi sáng, với một cuốn sổ.

Thứ ba và thứ tư là dựng. Harness được clone từ template của chúng tôi: vòng lặp, lớp policy, trace, eval runner. Phần việc là lớp đặc thù khách hàng: một bản đồ kiểu CLAUDE.md về hệ thống của họ, bốn tool trên dữ liệu của họ (hai đọc, một ghi hoàn tác được, một cần phê duyệt), một file skill cho các loại tài liệu của họ. Tối thứ tư agent xử lý trọn một tài liệu end-to-end trên VM của họ.

Thứ năm là eval. Ba mươi tài liệu của tháng trước, với câu trả lời của nhân viên vận hành làm ground truth, thành bộ task đầu tiên. Agent được 22 trên 30. Mỗi cái trong tám lần fail thành một task có nhãn. Hai trong số đó là một loại tài liệu mới không ai nhắc tới; một là tool trả ngày sai định dạng. Cả tám được sửa hoặc ghi nhận trước khi hết tuần.

Thứ sáu là con người. Demo cho người tài trợ với con số thật, kể cả phần fail. Đào tạo hai nhân viên sẽ làm "champion", với quy tắc họ có thể đánh dấu bất kỳ output nào là "sai" bằng một cú click và phản hồi đó đi thẳng vào bộ eval. Một bản bàn giao bằng văn bản: cái gì chạy ở đâu, gọi ai, agent không được phép làm gì.

Để ý tỷ lệ. Có lẽ một phần ba tuần đó là kỹ thuật theo cách một product team nhận ra. Phần còn lại là quyền truy cập, quan sát, đánh giá và giao tiếp, và đó là lý do product engineer giỏi đôi khi chật vật với vai trò này còn kỹ sư có đầu óc vận hành thì phát huy.

Điều gì làm một người giỏi việc này#

Những kỹ sư làm tốt việc này có vài đặc điểm chung không hiện ra trong một vòng phỏng vấn tiêu chuẩn.

Họ ship được end-to-end một mình: backend, một chút frontend, hạ tầng, dữ liệu. Tại chỗ không có team nào để chuyền bóng.

Họ thực dụng với hệ thống của người khác. Schema database của khách sẽ không được thiết kế lại. Việc là làm với cái đang có, ghi lại các cạnh sắc, và để harness hấp thụ chúng.

Họ tò mò về lĩnh vực. Một trong những kỹ sư giỏi nhất tôi từng làm cùng ở vai trò này dành hai ngày đầu ở một khách hàng logistics để học tờ khai hải quan thực sự di chuyển thế nào, và agent cô ấy dựng phản ánh điều đó theo những cách không spec nào ghi nổi.

Họ nói chuyện với người không làm kỹ thuật mà không kẻ cả hay đầy thuật ngữ, và họ nói được "model đúng 22 trên 30 và đây là 8 cái sai" với người tài trợ mà không chùn.

Họ có phán đoán về tổng quát hoá: bản năng nhận ra thứ vừa dựng cho khách này là lần thứ ba mình dựng nó, và biến nó thành sản phẩm.

Nếu bạn tuyển cho vai trò này, bài phỏng vấn hiệu quả với chúng tôi là nửa ngày với một dataset thật, lộn xộn, đã ẩn danh, kèm yêu cầu "tìm hiểu đây là gì và nói cho chúng tôi bạn sẽ dựng gì". Nó kiểm tra cả năm đặc điểm cùng lúc và rất khó giả.

Những phê bình xác đáng#

Vai trò này đang thời thượng, và thứ thời thượng thu hút phê bình, trong đó có phần đúng.

Andrew Ng lập luận rằng sẽ có nhiều việc AI engineering hơn việc FDE rất nhiều, và vai trò này không thay thế kỹ thuật bình thường. Tôi đồng ý; FDE là vai trò nút cổ chai, không phải vai trò đa số, và một công ty có nhiều FDE hơn product engineer là công ty dịch vụ dù có thừa nhận hay không.

Chi phí là thật. Dành một kỹ sư giỏi cho một khách hàng suốt một quý rất tốn, và mô hình chỉ hiệu quả khi giá trị hợp đồng hoặc bài học cho sản phẩm bù lại được. Dự án ngắn hơn khoảng một quý hiếm khi bù được, vì không đủ thời gian học lĩnh vực trước khi rời đi.

Căng thẳng giữa giải quyết vấn đề của một khách và xây sản phẩm chuẩn là vĩnh viễn. FDE nào cũng sẽ bị yêu cầu dựng thứ không bao giờ nên thành sản phẩm, và tổ chức cần một cách nói "không" không đổ lên đầu người đang ngồi ở văn phòng khách.

Và vai trò này phụ thuộc vào quyền truy cập. Nếu khách không cấp quyền production, FDE là một người rất đắt tiền ngồi chờ ticket được duyệt. Thương lượng quyền truy cập trước khi dự án bắt đầu, không phải trong lúc.

Làm việc này từ một công ty dịch vụ ở Việt Nam#

Tôi dẫn dắt một team AI ở một công ty dịch vụ phần mềm, không phải lab, và phần lớn thứ tôi đọc về FDE giả định bài toán kinh tế của lab. Đây là cách chúng tôi điều chỉnh mô hình, cho ai ở vị trí tương tự.

Chúng tôi chạy deployment squad thay vì FDE đơn lẻ: một kỹ sư ở vai FDE, một domain analyst nói ngôn ngữ của khách (đôi khi theo nghĩa đen; khách của chúng tôi ở Việt Nam và Úc), và một platform team dùng chung phía sau. Analyst làm phần lớn việc "ngồi với công việc"; kỹ sư dựng; platform team sở hữu bước tổng quát hoá ngược để nó thực sự xảy ra.

Chúng tôi scope pilot tám đến mười hai tuần với production là đích tường minh, và định nghĩa metric thành công cùng trưởng bộ phận vận hành của khách, không phải người tài trợ, ngay tuần một. Pilot kết thúc bằng một bộ slide là pilot thất bại, dù người tài trợ nói gì.

Chúng tôi mang theo bộ máy của series. Vòng lặp, lớp policy, trace, eval runner và template harness là tài sản nội bộ tốt dần lên sau mỗi dự án. Lớp đặc thù khách hàng mỏng theo thiết kế. Đây là bước tổng quát hoá được làm thành cấu trúc: không phải ai đó nhớ ra mà tách phần tái sử dụng, mà là phần tái sử dụng chưa bao giờ đặc thù cho khách ngay từ đầu.

Và chúng tôi tính giá những tuần đầu như giai đoạn khám phá, một cách thẳng thắn. Tuần ở văn phòng khách mở đầu bài này khi ấy không tính tiền, và nó cứu một dự án đáng giá gấp nhiều lần chi phí. Giờ nó là một dòng trong báo giá, và khách nào từ chối nó là khách mà chúng tôi đã học được là không nên nhận dự án.

Series dừng ở đâu#

Sáu bài trước tôi nói model là phần đáng tin nhất của một agent còn giàn giáo quanh nó thì chưa. Harness, context, policy và eval là giàn giáo đó, và FDE là người lắp nó ở một nơi vendor chưa từng thấy, với dữ liệu vendor chưa từng đọc, cho những người vendor chưa từng gặp. Nếu agent sẽ làm việc thật trong các tổ chức thật, phải có ai đó đến tổ chức đó. Đó là toàn bộ công việc, và tôi nghĩ nó là công việc thú vị nhất trong ngành lúc này.

Sáu bài tiếp theo đi ra một tầng, tới những thứ nối các agent với nhau và với phần còn lại của doanh nghiệp: MCP, A2A, graph engineering, hai công cụ để chạy cả đội coding agent (Orca và Paseo), và n8n cho quy trình nghiệp vụ.

Tài liệu tham khảo#

• Wikipedia, Forward deployed engineer (nguồn gốc, mục phê bình)
• Valletta Software, What Is a Forward Deployed Engineer? The 2026 FDE Guide (dữ liệu nhu cầu, dải lương, công ty tuyển)
• OpenAI, Harness engineering (02/2026), về việc mã hoá bài học vào repo
• Anthropic, Effective harnesses for long-running agents (11/2025)