YouMind
Đăng nhập

Nhập môn Kỹ thuật Triển khai Tiền tuyến (Forward Deployed Engineering)

@vasuman
TIẾNG ANH20 thg 5, 2026
681K
1.6K
181
41
5.1K

TL;DR

Hướng dẫn này chia vai trò Kỹ sư Triển khai Tiền tuyến thành ba giai đoạn—Kiểm định (Audit), Đánh giá (Evals) và Triển khai (Deployment)—đồng thời cung cấp lộ trình 30 ngày cho các kỹ sư và quản lý sản phẩm (PM) để chuyển hướng sang ngành công nghiệp AI.

<code-segment id="0" lang="text">

Sau khi đọc bài viết này, bạn sẽ hiểu tại sao Anthropic, OpenAI, Google và các công ty AI khác đang tìm kiếm FDE, và làm thế nào để bạn tận dụng được nhu cầu này.

Tôi đã từng làm công việc này, từng thuê một số người giỏi nhất thế giới để xây dựng đội ngũ FDE tại Varick, và nhận thấy không có một hướng dẫn thực sự rõ ràng nào cho vai trò hot nhất trong ngành công nghệ hiện nay. Đây chính là hướng dẫn đó.

Tại sao các công ty AI cần FDE

Để trở thành một FDE, bước đầu tiên là thấu hiểu lý do tại sao các công ty AI lại đang rất cần họ.

Nếu bạn tin rằng trí thông minh đang trở thành một mặt hàng phổ biến, thì lợi thế cạnh tranh duy nhất là cách thức và nơi bạn sử dụng nó. Thực tế, tôi sẽ đi xa hơn khi nói rằng không có lợi thế cạnh tranh nào chỉ từ riêng trí thông minh. Do đó, việc xác định cách thức và nơi các công ty sử dụng nó trở thành vai trò quan trọng nhất, và đó chính là vai trò của một forward deployed engineer.

Các doanh nghiệp thuê một công ty Applied AI (như Varick), nơi triển khai các FDE để giúp họ tận dụng tối đa công nghệ. Làm như vậy giúp họ tiếp cận một đội ngũ đã thực hiện các chuyển đổi AI quy mô lớn, giúp khách hàng di chuyển nhanh hơn nhiều so với đối thủ cạnh tranh, và nhờ đó mang lại hiệu quả vượt trội.

FDE là một kỹ sư có tay nghề cao, có thể hiểu rất sâu vấn đề của khách hàng, viết code vào một code base mà họ có thể chưa từng thấy trước đây, và truyền đạt tác động kinh doanh đến người ra quyết định phi kỹ thuật để chốt giao dịch. Đây là một sự tuyển dụng triệu đô.

Vai trò này đòi hỏi những gì

Làm FDE đòi hỏi bạn phải có mặt tại chỗ với khách hàng. CTO của Palantir nói rằng bạn không thể xây dựng sản phẩm cho một môi trường mà không thực sự ở trong môi trường đó. Chúng tôi cũng thấy điều tương tự nội bộ.

Thuật ngữ FDE thực ra bắt nguồn từ Palantir, và họ rất coi trọng việc có mặt tại chỗ. Năm 2010, họ làm việc với nhóm Special Forces ở Afghanistan. Lực lượng Special Forces đi làm nhiệm vụ ban ngày, nhận phản hồi, và chuyển tiếp cho các FDE, những người sẽ ship code vào ban đêm.

Việc có mặt trong môi trường là cần thiết cho việc triển khai phần mềm quân sự cũng như triển khai AI. Để thấy được những cải thiện về hiệu quả thực sự, một công ty cần được xây dựng lại từ nền tảng xoay quanh AI. Và điều đó chỉ có thể thực hiện được thông qua việc ngồi làm việc với khách hàng và xây dựng các agent tùy chỉnh được thiết kế trên dữ liệu cụ thể của công ty, với ngữ cảnh cụ thể của công ty.

Về vai trò này

Theo quan điểm của chúng tôi, có ba phần chính trong công việc của một Applied AI FDE: Audit (Kiểm toán), Evals (Đánh giá), và Deployment (Triển khai). Hãy cùng phân tích từng phần.

Audit: Bạn có mặt tại chỗ với khách hàng, lập bản đồ các quy trình/luồng công việc trong các nhóm khác nhau của công ty. Ví dụ: hai tuần với rev ops, một tuần với procurement, và cả tháng với finance.

Với mỗi nhóm bạn làm việc cùng, bạn học được một vài điều: công việc của họ trông như thế nào, các điểm nghẽn ở đâu, và bạn có thể tạo ra các agent nào để mang lại giá trị.

Cùng với việc hiểu luồng công việc của từng nhóm trong công ty, một phần quan trọng của giai đoạn audit là xác định những gì nên được tự động hóa và những gì không nên. Có những lúc agent có thể tạo ra nhiều vấn đề hơn là giải quyết.

Dưới đây là ba nguyên tắc chung bạn có thể làm theo để giúp bạn quyết định.

Nếu một luồng công việc có thể được tóm gọn trong các quy tắc nhưng đầu vào lại khác nhau (một đầu vào là email, đầu vào tiếp theo có thể là PDF, tiếp theo là hình ảnh được quét), và công việc liên quan đến việc gọi các công cụ, hãy đặt một agent vào. Nếu các quy tắc và đầu vào đều có thể dự đoán được, code sẽ nhanh hơn và rẻ hơn. Nếu quyết định cần nhận dạng mẫu và chuyên môn lĩnh vực, hãy để nó thủ công.

Khách hàng của bạn sẽ không có ROI tốt nếu agent chạy năm lần một tháng. Hãy tìm kiếm các tự động hóa dài hạn, khối lượng lớn. Cần có đủ khối lượng để tạo ra sự khác biệt.

Đừng lạm dụng AI khi xây dựng các agent của bạn. Hầu hết các tác vụ tự động hóa có thể được thực hiện với một loạt các lệnh gọi công cụ và chỉ một lần gọi LLM làm lớp điều phối. Quá nhiều AI dẫn đến chi phí token không cần thiết (sẽ tích lũy khi mở rộng quy mô) và thường cho đầu ra chất lượng thấp hơn.

Phần cuối cùng của giai đoạn Audit là tạo nguyên mẫu (prototyping). Xem Agents 101 để học cách xây dựng một agent, và Agents 102 để đưa agent đó từ bản demo lên production.

Evals: Nếu một khách hàng chi hàng triệu đô cho việc triển khai AI, họ cần biết nó đang hoạt động. Để làm điều đó, một FDE xây dựng các evals chi tiết.

Một eval tốt không chỉ kiểm tra xem câu trả lời cuối cùng mà agent đưa ra có đúng không, mà còn xác minh AI đang suy nghĩ như con người. Để làm được điều đó, hãy làm hai việc:

Theo dõi các bước của con người và chấm điểm AI ở mỗi bước: Một con người không giải quyết vấn đề trong một bước duy nhất. Đó là một quá trình nhiều bước. Hãy lập bản đồ các bước đó và xem liệu AI có đạt được các điểm kiểm tra tương tự trên đường đi không.

Bắt đầu từ những ví dụ nhỏ, tuyệt vời về kết quả mong muốn, sau đó đo lường mọi thứ so với chúng: Nếu bạn đang xây dựng một agent hỗ trợ khách hàng, hãy ngồi với một người và tìm ra câu trả lời tốt nhất có thể cho truy vấn của người dùng là gì. Lặp lại điều đó vài lần qua một vài tác vụ. Bây giờ bạn đã biết "tuyệt vời" trông như thế nào và có thể giữ các agent ở tiêu chuẩn đó.

Evals chứng minh giá trị cho khách hàng. Trong khi mọi người đều nói họ muốn AI trong công ty của mình, vẫn còn nhiều người hoài nghi về việc liệu nó có hoạt động hay không. Một đánh giá agent tốt là thứ mà một giám đốc điều hành cần để tin tưởng rằng agent sẽ mang lại ROI.

Deployment: Tránh việc di chuyển dữ liệu quy mô lớn. Thay vào đó, hãy xây dựng các API trên lớp dữ liệu hiện có (SharePoint hoặc cơ sở dữ liệu) và đặt một mô hình lên trên làm bộ điều phối để truy vấn qua nó. Điều này tiết kiệm thời gian và tiền bạc, và quan trọng hơn, giúp bạn tránh khỏi cơn ác mộng kinh hoàng khi phải loại bỏ các hệ thống hiện tại. Các khách hàng của chúng tôi đã chi hàng triệu đô la và nhiều năm để di chuyển lên ERP mới nhất của họ. Điều cuối cùng họ muốn là thay thế nó một lần nữa.

Khi tất cả những điều trên đã hoàn thành, hãy tạo một môi trường thực thi để kiểm tra agent một cách an toàn. Đây là một sandbox trực tiếp trong hạ tầng của công ty để bạn có thể chạy, kiểm tra và gỡ lỗi agent trước khi đưa lên production.

Khi chuyển sang production, hãy bắt đầu chậm. Lấy một luồng công việc nhỏ, làm cho nó hoạt động, sau đó thêm dần các khả năng bổ sung. Ví dụ: bắt đầu với một agent bắt lỗi, điều tra và viết một ticket tóm tắt những gì nó nghĩ đã sai. Nếu điều đó hoạt động, chỉ sau đó mới cho nó khả năng viết code và push PR.

Bắt đầu với đơn vị tự chủ nhỏ nhất; chỉ sau đó mới cho nó khả năng hành động.

Đó là cách bạn đi từ audit đến deployment với tư cách là một FDE. Học các bước này chính là toàn bộ công việc.

Làm thế nào để trở thành FDE trong 30 ngày

Thường có ba nền tảng tìm thấy nhiều thành công nhất với tư cách là FDE: Nhà tư vấn (Consultants), Quản lý sản phẩm (Product Managers), và Kỹ sư phần mềm (Software Engineers). Ngay cả khi bạn không thuộc bất kỳ nhóm nào trong số này, việc làm theo lộ trình 30 ngày ở cuối phần này sẽ tăng cơ hội nhận được vai trò lên gấp bội. Hãy làm những điều này song song với việc nộp đơn và phỏng vấn.

Consultants/PMs

Là một consultant hoặc PM, bạn hẳn đã có khả năng chuyển đổi dữ liệu thành ROI. Đó là một nửa công việc. Nhưng rào cản lớn nhất đối với người có nền tảng này là thiếu kinh nghiệm kỹ thuật.

Một portfolio chất lượng cao có thể giảm thiểu điều này. Hãy chọn hai trong số các dự án phụ sau đây và tập trung toàn lực:

  • Một AI agent sẵn sàng cho production có thể thực hiện toàn bộ quy trình mà bạn từng làm thủ công trong công việc cũ. Nó sẽ có thể gọi API, tự động ghi lại quá trình suy nghĩ và có cơ chế xử lý lỗi.
  • Một pipeline RAG được xây dựng trên một tập dữ liệu (chọn một tập dữ liệu tùy chỉnh cho ngành bạn muốn gia nhập: tài liệu pháp lý, hồ sơ y tế, hồ sơ tài chính, v.v.).
  • Một framework eval do bạn tự xây dựng, chấm điểm đầu ra của agent trên nhiều khía cạnh (tính đúng đắn, định dạng, chi phí, độ trễ) cho các quy trình kinh doanh khác nhau (procurement, accounts payable, v.v.).
  • Một MCP nơi bạn có thể kết nối LLM với phần mềm cũ chưa hỗ trợ tích hợp AI.

Đừng ủy thác sự hiểu biết của bạn cho AI. Nếu bạn thực hiện từng bước một, những khái niệm này sẽ khá dễ hiểu. Có lý do tại sao phần này được đặt tên là 30 ngày, không phải 30 phút.

Software Engineers

Có thể nói phần quan trọng nhất của việc làm FDE là giao tiếp. Bạn cần dịch những gì AI có thể và không thể làm thành điều có ý nghĩa với một VP phi kỹ thuật. Nếu bạn không thể làm điều đó, bạn không thể trở thành FDE.

SWEs nên xây dựng các dự án tương tự như những dự án được đề cập trong phần consulting/PM, nhưng giải thích từng thành phần của những gì bạn vừa xây dựng. Tech stack, kết quả, các lần lặp bạn đã thực hiện, kết quả kinh doanh. Quan trọng nhất, bạn cần có lý do để xây dựng các agent đó ngay từ đầu: vấn đề khó khăn bạn đang giải quyết là gì, và điều này sẽ diễn ra như thế nào trong một tương tác khách hàng thực tế?

Lộ trình 30 ngày bất kể vai trò nào

Để có một thứ cụ thể hơn, hãy làm theo kế hoạch 30 ngày này, nó sẽ chuẩn bị cho bạn hầu hết mọi thứ:

Điểm kiểm tra 1 (7 ngày):

  • Agent là gì và vòng lặp agent hoạt động như thế nào: đọc bài viết Building Effective Agents của Anthropic, sau đó viết một script chạy vòng lặp: prompt → model → response → bước tiếp theo.
  • Cách để agent gọi một công cụ: thêm hai lệnh gọi công cụ (một lệnh gọi API và một tìm kiếm web) bằng các hướng dẫn sử dụng công cụ của Anthropic/OpenAI.
  • Cách xây dựng guardrails phù hợp: thêm xác thực đầu vào, giới hạn số bước tối đa và lọc đầu ra trước khi bất cứ thứ gì đến tay người dùng.
  • Khi nào sử dụng context window so với bộ nhớ ngoài: mặc định dùng context trừ khi trạng thái cần tồn tại lâu hơn thời gian chạy.
  • Audit trail là gì và cách xây dựng nó: ghi lại mọi prompt, lệnh gọi công cụ và phản hồi kèm dấu thời gian. Điều này giúp tìm và gắn cờ lỗi agent.

Điểm kiểm tra 2 (14 ngày):

  • Cách thực thi đầu ra có cấu trúc: luôn trả về JSON. Đọc qua trang developer của OpenAI.
  • Cách đưa bản demo lên prod và những gì thường bị hỏng: Đọc Agents 102.
  • Cách checkpoint: lưu trạng thái agent mỗi n bước vào một file để nó có thể khởi động lại từ checkpoint cuối cùng.

Điểm kiểm tra 3 (21 ngày):

  • Logic retry và exponential backoff hoạt động như thế nào: mọi lệnh gọi bên ngoài đều cần retry. Khi thất bại, chờ 1s, 2s, 4s, 8s, giới hạn ở 16s.
  • Cách tối ưu chi phí khi triển khai agent: ba thứ: mô hình rẻ hơn cho các tác vụ phụ rẻ (Opus chỉ nên dùng cho lý luận), cache các prompt phổ biến, giới hạn max tokens. Theo dõi chi phí mỗi truy vấn.
  • Cách xây dựng một bộ dữ liệu vàng (golden dataset) cho evals: bắt đầu với 20 truy vấn thực tế, tự gắn nhãn đầu ra hoàn hảo. Bài viết "Demystifying evals for AI agents" của Anthropic bao gồm mọi thứ.
  • Các pipeline đa agent và kiến trúc song song hoạt động như thế nào: chia công việc khi một agent không thể xử lý. Một agent lập kế hoạch, các agent khác thực thi, một agent tổng hợp.

Điểm kiểm tra 4 (Tuần cuối):

Xem lại những điều trên và truyền đạt mọi thứ bằng lời nói. Kết nối mọi thứ bạn có thể với các chỉ số kinh doanh.

TLDR

FDE là vai trò được săn đón nhất trong ngành công nghệ hiện nay. Mọi công ty đều cần AI, nhưng không ai biết cách triển khai nó.

Công việc có ba giai đoạn (audit, evals, deployment). Công việc của bạn là hiểu từng giai đoạn và mục đích của nó.

Portfolio của bạn và khả năng nói về nó là những yếu tố quyết định. Hãy xây dựng các agent, pipeline RAG, framework eval, MCP, v.v., và quan trọng nhất, có thể tự tin trình bày trường hợp sử dụng kinh doanh đằng sau mọi thứ bạn đang xây dựng.

Thiếu khả năng giao tiếp là rào cản lớn cho vai trò FDE. Nếu bạn không thể giải thích AI có thể và không thể làm gì cho một người ra quyết định phi kỹ thuật, sẽ không có việc triển khai.

Biết khi nào AI không phải là câu trả lời; điều này xây dựng lòng tin với khách hàng và quan trọng hơn là ROI cho các agent trong production.

Thực hiện các bước này và cơ hội gia nhập của bạn sẽ cao hơn gấp bội.

Nếu bạn muốn chuyển sang công ty Applied AI phát triển nhanh nhất ở SF, Varick đang tuyển dụng. Chúng tôi đang xây dựng đội ngũ FDE ưu tú nhất ở Thung lũng Silicon, dẫn đầu bởi một cựu COO của Citadel Securities. Nộp đơn trực tiếp tại https://www.varickagents.com/careers.

</code-segment>

Lưu một chạm

Đọc sâu bài viết viral bằng AI trong YouMind

Lưu nguồn, đặt câu hỏi tập trung, tóm tắt lập luận và biến một bài viết viral thành các ghi chú có thể tái sử dụng trong một không gian làm việc AI duy nhất.

Khám phá YouMind
Dành cho nhà sáng tạo

Biến Markdown của bạn thành bài viết 𝕏 gọn gàng

Khi bạn đăng bài viết dài của riêng mình, việc định dạng hình ảnh, bảng và khối mã cho 𝕏 rất mệt mỏi. YouMind biến cả bản nháp Markdown thành một bài viết 𝕏 gọn gàng, sẵn sàng để đăng.

Thử Markdown sang 𝕏

Thêm pattern để giải mã

Bài viết viral gần đây

Khám phá thêm bài viết viral