- Banking Circle, một công ty fintech xử lý hàng nghìn tỷ euro thanh toán, đã xây dựng nền tảng Atlas để giúp hơn 250 kỹ sư của mình tập trung vào phát triển sản phẩm bằng cách đơn giản hóa sự phức tạp của cơ sở hạ tầng và đám mây.
- Quy trình phát triển truyền thống thường gây thất vọng cho con người và là thách thức gần như bất khả thi cho các tác nhân AI, do sự phụ thuộc vào kiến thức ngầm, hỗ trợ ad-hoc và quy trình thủ công chậm trễ.
- Để khắc phục, các nền tảng cần ưu tiên tự phục vụ thông qua API, tài liệu rõ ràng (bao gồm cả hướng dẫn cụ thể cho tác nhân AI), và áp dụng các nguyên tắc "shift left" cùng với các hàng rào bảo vệ.
Platforms for Humans and Machines: Engineering for the Age of Agents — Juan Herreros Elorza
- Triển khai các khả năng tự phục vụ toàn diện: Đảm bảo mọi tài nguyên và quy trình của nền tảng (từ cấp phát tính toán, lưu trữ đến quản lý bí mật) có thể được kích hoạt và quản lý hoàn toàn tự động, loại bỏ mọi sự phụ thuộc vào can thiệp thủ công.
- Thiết kế nền tảng theo nguyên tắc "API-first": Xây dựng các API được định nghĩa rõ ràng, có khả năng khám phá, xác thực lược đồ, và xác thực/ủy quyền mạnh mẽ để tác nhân AI có thể tương tác hiệu quả và an toàn.
- Áp dụng phương pháp "Shift Left": Cho phép xác thực và kiểm thử cục bộ các thay đổi trước khi đưa vào hệ thống kiểm soát phiên bản hoặc quy trình làm việc, giúp phát hiện lỗi sớm và giảm thiểu lãng phí thời gian.
- Cung cấp khả năng quan sát dành cho tác nhân: Đảm bảo nhật ký, số liệu và dấu vết có thể truy cập được thông qua API hoặc CLI để tác nhân AI có thể tự động xác minh kết quả và đóng vòng lặp tác vụ.
- Xây dựng tài liệu có cấu trúc và tập trung: Tổ chức tài liệu (API-first) theo cách dễ dàng cho tác nhân AI khám phá và tiêu thụ, bao gồm các tệp
agents.mdhoặccopilot.mdđể cung cấp hướng dẫn cụ thể cho tác nhân. - Khuyến khích đóng góp với hàng rào bảo vệ thông minh: Mở cửa cho các đóng góp từ cộng đồng nhà phát triển trong nội bộ, nhưng đồng thời thiết lập các chính sách và hướng dẫn (thông qua tài liệu cho tác nhân) để đảm bảo tuân thủ các tiêu chuẩn và bảo mật.
Claude Native Technology— Công nghệClaude Nativefintech— công nghệ tài chínhplatform engineering team— nhóm kỹ thuật nền tảngTác nhân AI— AI Agenttự phục vụ— self-serviceAPI first— ưu tiên APIShift Left— Chuyển trái (phương phápShift Left)observability— khả năng quan sáttài liệu— documentationHàng rào bảo vệ— Guardrails
Giới thiệu về Banking Circle và Nền tảng Atlas
Xin chào mọi người, cảm ơn rất nhiều vì đã theo dõi và chào mừng đến với buổi nói chuyện của tôi về "Nền tảng cho Con người và Máy móc." Tôi là Juan, trưởng nhóm Claude Native Technology tại một công ty tên là Banking Circle. Có lẽ các bạn chưa biết về chúng tôi, vì vậy hãy để tôi giới thiệu đôi chút về những gì chúng tôi làm. Chủ yếu, chúng tôi là nhà cung cấp dịch vụ thanh toán xuyên biên giới toàn cầu, bên cạnh quản lý tài khoản và thanh khoản. Chúng tôi xử lý hơn một nghìn tỷ euro mỗi năm và cung cấp dịch vụ ngân hàng cho hơn 700 tổ chức tài chính được quản lý. Chúng tôi là một công ty fintech chính hiệu, và trên thực tế, rất nhiều thành viên của chúng tôi đang làm việc trong các vai trò kỹ thuật khác nhau. Chính vì vậy, vài năm trước, chúng tôi đã quyết định thành lập một nhóm kỹ thuật nền tảng (platform engineering team) tại Banking Circle, nơi tôi đang làm việc. Hơn 250 người tại Banking Circle đang xây dựng các loại hệ thống kỹ thuật khác nhau. Điều này bao gồm các API mà khách hàng của chúng tôi đang sử dụng, các hệ thống ngân hàng cốt lõi, một số công cụ nội bộ, khoa học dữ liệu và kỹ thuật dữ liệu, và tất nhiên là tích hợp với các hệ thống thanh toán bù trừ nơi chúng tôi xử lý tất cả các khoản thanh toán. Vì lý do đó, chúng tôi đã quyết định xây dựng một nền tảng mà tất cả các nhóm này có thể sử dụng để chúng tôi có thể đơn giản hóa sự phức tạp trong một số cơ sở hạ tầng và các vấn đề về đám mây cơ bản. Nhờ đó, các kỹ sư có thể tập trung vào việc xây dựng các hệ thống mà họ phải xây dựng. Chúng tôi gọi nền tảng đó là Atlas. Atlas có một số nền tảng con. Chúng tôi có một nền tảng compute nơi mọi người chạy ứng dụng của họ dựa trên Kubernetes. Chúng tôi có một nền tảng infrastructure mà mọi người có thể sử dụng để cấp phát dịch vụ lưu trữ blob, cơ sở dữ liệu, và hệ thống quản lý bí mật. Chúng tôi có các nền tảng messaging để các ứng dụng và hệ thống khác nhau giao tiếp với nhau. Và chúng tôi có các nền tảng observability để chúng tôi có thể biết điều gì đang xảy ra với tất cả các ứng dụng và tất cả các khoản thanh toán mà chúng tôi đang xử lý.
Bài học từ câu chuyện phát triển ứng dụng
Chúng tôi đã đi một chặng đường dài trong hành trình kỹ thuật nền tảng này, nhưng mọi thứ không phải lúc nào cũng dễ dàng. Tôi muốn bắt đầu buổi nói chuyện của mình bằng một câu chuyện nhỏ, sử dụng các tên và nhân vật hư cấu, nhưng dựa trên kinh nghiệm của tôi khi làm việc tại Banking Circle. Tôi chắc chắn nhiều bạn cũng sẽ thấy mình trong câu chuyện này.
Giả sử chúng ta có một nhà phát triển mới, đúng không? Họ vừa gia nhập công ty, vào một nhóm. Họ bắt đầu làm việc và xây dựng ứng dụng đầu tiên của mình. Nhà phát triển này rất giỏi, họ viết mã ứng dụng rất tốt, có thể là cho một hệ thống thanh toán nào đó. Nhưng cuối cùng, họ gặp phải một trở ngại. Họ có mã nguồn, nhưng cần triển khai ứng dụng đó ở đâu đó. Khi đó, nhà phát triển sẽ tự nhiên hỏi một người trong nhóm, "Này, tôi nên làm gì với ứng dụng này? Làm sao để triển khai nó?" Và rồi người trong nhóm có thể nói với nhà phát triển, "Ồ, bạn biết không? Thật ra, tôi đã làm rồi, và nó đã được thiết lập trong pipeline này. Sao bạn không sao chép nó từ đó?"
Nhà phát triển có thể sao chép pipeline. Sau đó, có thể họ phải điều chỉnh một chút. Trong trường hợp này, nó không hoàn toàn giống nhau vì ứng dụng có một số yêu cầu cụ thể. Rồi họ sẽ cố gắng chạy pipeline này. Có thể pipeline sẽ thất bại. Và cuối cùng, nhà phát triển không biết tại sao nó lại thất bại, vì lỗi không liên quan gì đến ứng dụng mà họ đã viết mã. Có thể họ quay lại hỏi đồng đội, "Này, tôi có thể làm gì với cái này?" Và đồng đội có thể nói, "Bạn biết mình nên làm gì không? Bạn nên nói chuyện với người này đang làm việc trong nhóm infrastructure. Họ sẽ giúp bạn."
Bây giờ, nhà phát triển này sẽ đi, có thể họ sẽ nói chuyện với người đó. Cuối cùng, họ sẽ nói, "Ồ vâng, tất nhiên rồi, đây là một lỗi rất hay xảy ra. Tôi có thể giải quyết nó giúp bạn ngay." Lỗi sẽ được giải quyết và nhà phát triển sẽ triển khai ứng dụng. Và rồi việc triển khai đó có thể thành công. Chỉ để nhận ra cuối cùng rằng, trên thực tế, ngoài ứng dụng đó, nhà phát triển còn cần một cơ sở dữ liệu hoặc có thể một số lưu trữ khối. Trở lại vạch xuất phát, nhà phát triển sẽ đến gặp người trong nhóm infrastructure để hỏi, "Này, tôi có thể nhờ bạn tạo cơ sở dữ liệu này hoặc lưu trữ khối này giúp tôi được không?" Và có thể người đó, giả sử với ý định tốt nhất, tất nhiên. Có thể họ muốn giúp. Nhưng họ sẽ nói, "Bạn biết không? Tôi thực sự có rất nhiều việc khác đang làm. Tôi sẽ giúp bạn, nhưng đó sẽ là tuần tới."
Vì vậy, rõ ràng nhà phát triển sẽ cảm thấy thất vọng vì họ đã hoàn thành phần việc của mình. Nhưng rồi họ lại phải vật lộn rất nhiều trong quá trình triển khai ứng dụng và để ứng dụng chạy với tất cả các phụ thuộc mà nó cần. Có lẽ họ đã làm theo một số tài liệu, thứ mà ai đó đã viết trên đường đi. Nhưng sau đó họ cũng phải dựa vào việc hỏi đồng đội và hỏi người ở nhóm khác.
Thách thức đối với Tác nhân AI
Đây là một tình huống tồi tệ mà tôi nghĩ tất cả chúng ta đã từng trải qua ở một thời điểm nào đó. Đó là một tình huống tồi tệ đối với một con người. Nhưng ngày nay, tất cả chúng ta đều đang sử dụng các Mô hình Ngôn ngữ Lớn (LLM). Chúng ta đang sử dụng các tác nhân AI để hỗ trợ công việc hàng ngày của mình. Và nếu tình huống này khó khăn đối với một nhà phát triển, thì nó về cơ bản là bất khả thi đối với một cỗ máy, bởi vì cỗ máy sẽ không thể "đi thử pipeline rồi lên tầng hai nói chuyện với người ở nhóm khác". Tất nhiên, một tác nhân có thể sử dụng các ứng dụng như Teams hoặc thậm chí sử dụng một mô hình giọng nói nào đó để gọi điện thoại. Nhưng nhìn chung, một tác nhân mã hóa sẽ không thể thực hiện tất cả những điều này. Vì vậy, những vấn đề mà các nhà phát triển đang gặp phải đột nhiên trở nên rõ ràng hơn rất nhiều khi một tác nhân phải đối mặt với chúng. Và chúng là một yếu tố hạn chế đối với năng suất của tác nhân mã hóa này hoặc năng suất của nhà phát triển khi sử dụng tác nhân mã hóa. Những gì tôi sắp trình bày sẽ giải quyết một số điểm trong câu chuyện này. Nhưng điều cốt lõi là các thực hành tốt nhất vẫn là các thực hành tốt nhất. Chúng ta đã biết từ lâu rằng một số điều này, như dựa vào đồng đội để hướng dẫn cách triển khai một ứng dụng hoặc phải liên hệ với một người ở nhóm khác, hoặc phải chờ đợi một pipeline chỉ để nhận ra rằng nó không phải là thứ chúng ta thực sự cần, chưa bao giờ là tốt. Chúng chỉ trở nên rõ ràng hơn và có lẽ đau đớn hơn nhiều khi chúng ta có những tác nhân mã hóa này làm việc bên cạnh chúng ta.
Các thực hành tốt nhất cho việc xây dựng nền tảng thân thiện với Tác nhân AI
Vậy chúng ta có thể làm gì về điều đó? Đối với tôi, điều đầu tiên phải là tự phục vụ (self-service). Nếu tôi cần bất kỳ tài nguyên nào từ nền tảng này, nếu tôi cần có thể làm bất cứ điều gì thông qua các nền tảng này, tôi phải có khả năng tự mình làm điều đó. Tương tự, nếu tác nhân của tôi cần có khả năng làm bất cứ điều gì trên nền tảng, nó phải có khả năng tự mình làm điều đó. Không nên có quy trình nào yêu cầu nói chuyện với một người cụ thể hoặc chờ đợi một người cụ thể làm điều gì đó. Tác nhân phải có khả năng kích hoạt mọi thứ nó cần. Và để làm được điều đó, tất nhiên, điều quan trọng là luồng tự phục vụ hoặc quy trình tự phục vụ phải trực quan. Tất nhiên, chúng ta cần tài liệu hóa cách những điều này hoạt động, và tôi sẽ đề cập đến điều đó ngay sau đây. Nhưng chúng ta càng làm cho nó dễ dàng, thì nó càng thực sự là tự phục vụ. Bởi vì nếu nó về mặt kỹ thuật là tự phục vụ, nhưng lại yêu cầu tìm kiếm các khối xây dựng từ năm nơi khác nhau và ghép chúng lại, sau đó kích hoạt một luồng ở một nơi khác, thì nó không thực sự là tự phục vụ. Vì vậy, hãy làm cho nó tự động, loại bỏ con người khỏi quy trình và làm cho nó dễ dàng nhất có thể.
Ưu tiên API và Giao diện dòng lệnh
Điểm thứ hai mà tôi nghĩ là quan trọng là làm cho nó dựa trên API. Tự phục vụ có thể trông theo nhiều cách khác nhau, và nó cũng có thể là thứ gì đó dựa trên việc gửi văn bản ở đâu đó. Nó có thể dựa trên việc nhấp vào một nút. Nó có thể dựa trên nhiều thứ, nhưng các tác nhân rất giỏi trong việc gọi các Giao diện lập trình ứng dụng (API) được định nghĩa rõ ràng. Tất nhiên, nó cũng có thể là một giao diện dòng lệnh (CLI) trên nền API. Nó có thể là một máy chủ MCP xoay quanh API mà các tác nhân sử dụng. Tất cả những điều đó cũng là những ý tưởng hay. Nhưng nhìn chung, bên dưới tất cả những điều đó, bạn nên có một API được định nghĩa rõ ràng. Điều này có tính khả năng khám phá (discoverable). Vì vậy, khi tương tác với nó, tác nhân sẽ khám phá ra những gì nó có thể làm và các tùy chọn có sẵn. Nó có xác thực lược đồ (scheme validation). Vì vậy, một cách tự nhiên, tác nhân sẽ chỉ gửi những thứ sẽ hoạt động. Nó cũng có xác thực (authentication) hoặc có thể có, tùy thuộc vào những gì bạn đang xây dựng, ủy quyền (authorization) tại chỗ. Vì vậy, nhờ đó, tác nhân của bạn sẽ được phép sử dụng thông tin xác thực của bạn với tư cách là một nhà phát triển, hoặc có thể nếu tác nhân đang ở trong một luồng cụ thể, nó sẽ có thông tin xác thực riêng của mình. Nhưng nó sẽ có thể thực hiện tất cả những điều này một cách an toàn và nó sẽ biết mình đang làm gì. Và với điều này, tác nhân có thể tương tác qua lại. Nó có thể cố gắng làm điều gì đó. API sẽ nhận được phản hồi, và tác nhân có thể bắt đầu làm việc theo cách này nơi nó đi vào một vòng lặp (loop) cho đến khi nó đạt được những gì nó cần hoặc những gì nó được yêu cầu làm.
Shift Left và Vòng lặp tác nhân
Điều đó đưa tôi đến điểm tiếp theo. Một tác nhân thường chạy trên máy của bạn. Bạn cũng có thể có nó trên một máy chủ nào đó ở đâu đó, và bạn có thể có open-close hoặc gì đó và bạn đang giao tiếp với một tác nhân ở đó. Nhưng thông thường, một tác nhân là cục bộ (local) với máy. Tất nhiên, các mô hình đang chạy ở nơi khác, nhưng công việc mà tác nhân đang làm là cục bộ. Vì vậy, hãy làm cho tác nhân dễ dàng làm điều đó. Trước hết, shift left. Nếu một thứ gì đó sẽ thất bại, nó nên thất bại càng sớm càng tốt. Vì vậy, đừng để tác nhân đẩy một thứ gì đó vào hệ thống kiểm soát phiên bản (version control system) của bạn chỉ để rồi thất bại trong một quy trình làm việc (workflow) sau vài phút. Nếu bạn có thể xác thực mọi thứ ngay từ đầu, nếu bạn có thể chạy chúng cục bộ, một lần nữa bằng cách gọi các API đó, hoặc có thể sử dụng một loại wrapper nào đó xung quanh chúng, hãy làm điều đó. Shift left càng nhiều càng tốt.
Sau đó, như tôi đã nói, các tác nhân sẽ đi vào một vòng lặp. Vì vậy, nếu tác nhân ở trên máy của bạn và nó có thể làm mọi thứ nó cần ở đó, và bạn xác định rõ ràng đây là những gì tôi cần, tác nhân sẽ lặp lại cho đến khi nó đạt được điều đó. Bây giờ điều quan trọng là bạn phải cung cấp cho nó các hướng dẫn chính xác (precise instructions) mà bạn mô tả nhiệm vụ, bạn nói với tác nhân đây là những gì tôi cần bạn làm. Và điều quan trọng nữa là bạn phải nói với tác nhân đây là cách bạn biết mình đã hoàn thành nhiệm vụ thành công. Điều này hơi quan trọng khi làm việc với các tác nhân vì với tư cách là con người, chúng ta có thể xác minh điều này theo nhiều cách khác nhau. Và chúng ta có rất nhiều hệ thống khả năng quan sát (observability) nơi có lẽ chúng ta muốn kiểm tra xem ứng dụng đã được triển khai chưa và các số liệu/thước đo (metrics) có ổn không. Có thể chúng ta sẽ xem xét một số bảng điều khiển (dashboards). Các tác nhân sẽ không xem xét các giao diện đồ họa đó. Vì vậy, bạn cũng cần nghĩ xem khả năng quan sát trông như thế nào nếu người dùng chính là một tác nhân. Hãy làm cho các nhật ký (logs), số liệu/thước đo (metrics), dấu vết (traces), mọi thứ có thể giúp ích, có sẵn thông qua một API hoặc thông qua CLI hoặc một máy chủ MCP hoặc một thứ gì đó tương tự. Bằng cách đó, bạn đang cho phép tác nhân đóng vòng lặp. Bạn đang nói cho nó cách làm mọi thứ và cách xác minh rằng mọi thứ đã được thực hiện chính xác.
Tầm quan trọng của tài liệu
Và vì tôi đang nói về việc hướng dẫn tác nhân cách làm mọi việc, một điều cực kỳ quan trọng là tài liệu. Tất nhiên bạn đã có tài liệu rồi. Tôi nghĩ nhiều người trong chúng ta đã viết tài liệu, đặt nó ở đâu đó và sau đó không thể tìm thấy nó. Khi chúng ta cần tiết lộ (expose) tài liệu này cho các tác nhân, nhưng điều này cũng đã đúng với con người, chúng ta cần phải có cấu trúc xung quanh nó. Vì vậy, có nhiều chiến lược khác nhau mà bạn có thể muốn thực hiện. Một trong số đó có thể là, đặc biệt nếu bạn đang làm việc trong các kho lưu trữ (repositories) nhỏ hơn, hãy giữ tài liệu của bạn bên cạnh mã nguồn mà nó đang tài liệu hóa. Bằng cách đó, nếu một tác nhân đang làm việc trong thư mục hoặc kho lưu trữ cụ thể đó, nó có mọi thứ cần thiết. Nó có mã nguồn cần làm việc và tài liệu mô tả nó. Nếu bạn đang làm việc trên một thứ gì đó lớn hơn hoặc có thể là một nhóm nền tảng (platform team), nếu bạn cần tiết lộ tất cả tài liệu về nền tảng mà một tác nhân có thể cần, ý tưởng tốt hơn là đặt nó ở một nơi tập trung (centralized place) để tác nhân có thể đến đó và bắt đầu khám phá tài liệu nào có sẵn.
Ưu tiên API và Tài liệu cho Tác nhân
Một lần nữa, hãy nghĩ đến API first (ưu tiên API) bởi vì tác nhân sẽ tốt hơn nhiều trong việc tiêu thụ trang web theo cách đó. Cụ thể, nếu bạn có thể cung cấp các phần tài liệu cụ thể mà nó cần để tương tác qua API thì càng tốt, thay vì tải toàn bộ trang HTML vào bộ nhớ và cố gắng tìm ra những phần liên quan ở đó.
Tất nhiên, khi chúng ta nói về tài liệu, chúng ta cũng có thể nghĩ về tài liệu dành riêng cho tác nhân. Tôi cho rằng nhiều bạn đã quen thuộc với điều này, nhưng bạn có thể sử dụng các tệp agent.md hoặc clot.md (hướng dẫn cho copilot, .md) tùy thuộc vào tác nhân bạn chọn. Bằng cách đó, bạn cũng có thể mô tả cho tác nhân cách nó nên hoạt động trong một repository cụ thể. Bạn có thể hướng dẫn nó, "Bạn nên luôn xây dựng theo cách này, kiểm thử theo cách này, triển khai theo cách này. Bạn có thể xác minh theo cách này." Bạn có thể bao gồm tất cả những điều đó trong tệp agents.md của mình. Bạn cũng có thể áp dụng một trong những tài liệu này rộng rãi hơn cho các hệ thống khác nhau, sau đó thêm một tệp agents.md cụ thể hơn cho một dự án hoặc repository cụ thể.
Bạn cũng có thể sử dụng kỹ năng nếu bạn tuân thủ một số quy ước hoặc có một cách tương tác đã được xác định rõ ràng với một số nền tảng của bạn. Bạn có thể mã hóa những điều đó trong một kỹ năng, mà một lần nữa, chỉ là một tài liệu Markdown. Và bằng cách đó, bạn đang nói với tác nhân, "Khi bạn thực hiện loại nhiệm vụ này, bạn nên làm theo cách đó."
Khuyến Khích Đóng Góp và Hàng rào Bảo vệ
Cuối cùng nhưng không kém phần quan trọng, bạn cũng nên khuyến khích sự đóng góp vào các nền tảng của mình. Nếu bạn đang xây dựng các nền tảng dành cho nhà phát triển nội bộ, chúng sẽ phục vụ các nhà phát triển trong tổ chức của bạn. Và bạn muốn họ đóng góp vì bằng cách đó, họ cũng có thể giúp bạn; họ có thể giúp bạn giúp họ. Vì vậy, bạn nên khuyến khích họ, bạn nên chào đón các đóng góp, và vì họ đang sử dụng các tác nhân, rào cản gia nhập sẽ thấp hơn. Và vì vậy, tôi mong đợi — và đó là điều tôi đã thấy — rằng mọi người sẽ sẵn lòng đóng góp vào các nền tảng hơn.
Tuy nhiên, đây là một con dao hai lưỡi bởi vì cuối cùng, với tư cách là cá nhân hoặc nhóm sở hữu nền tảng, bạn chịu trách nhiệm bảo trì nó. Vì vậy, bạn nên suy nghĩ kỹ về những điều cần xem xét khi đóng góp vào nền tảng. Bạn cần có một số Hàng rào bảo vệ (suy nghĩ về bảo mật hoặc tuân thủ) hoặc chỉ đơn giản là tuân theo một bộ tiêu chuẩn được xác định rõ ràng, điều này sau đó giúp bạn duy trì nền tảng. Nếu bạn muốn đảm bảo tác nhân luôn tuân theo các quy ước đó, bạn có thể thực hiện điều này bằng một số chính sách, có lẽ trong hệ thống của bạn, nhưng bạn cũng có thể dựa vào việc cung cấp ngữ cảnh cho tác nhân. Một lần nữa, bạn có thể sử dụng agents.md, bạn có thể sử dụng một số kỹ năng để khi mọi người muốn đóng góp vào nền tảng của bạn, họ cũng có thể hướng dẫn tác nhân của mình đến các tệp Markdown này và tham khảo chúng như tài liệu về cách đóng góp.
Nói chung, tôi khuyến khích sự kết hợp của cả hai: thiết lập Hàng rào bảo vệ cho mọi thứ bạn tuyệt đối không muốn xảy ra. Sử dụng một số loại chính sách cho điều đó, nhưng sau đó, hãy sử dụng các tệp Markdown để giúp các tác nhân hoạt động theo cách bạn muốn.
Đo lường Hiệu quả của Nền tảng AI
Và sau đó chúng ta đi đến một câu hỏi rất quan trọng, đó là: "Được rồi, chúng ta đã làm tất cả những điều này, phải không?" Mọi người đang sử dụng AI trong tổ chức. Họ đang tuân theo những thực hành mà chúng ta đã khuyến nghị. Chúng ta đã xây dựng một nền tảng có thể được sử dụng bởi AI, nhưng liệu nó có hiệu quả không? Và tôi nghĩ cách để biết liệu nó có hoạt động hay không là bằng cách đo lường xem nó có hiệu quả hay không.
Tất nhiên, bạn có thể đo lường những điều này trước và sau khi thực hiện một số thay đổi trong nền tảng của mình để xem chúng có ảnh hưởng hay không. Và tùy thuộc vào những gì bạn muốn làm, bạn có thể muốn tập trung vào loại số liệu này hay loại số liệu khác. Bây giờ, chúng ta biết rằng có các số liệu về phân phối ứng dụng và chúng ta có toàn bộ Dora metrics về vấn đề đó: Tần suất thay đổi, thời gian trung bình để phục hồi, thời gian chờ, và một cái khác mà tôi hiện không thể nhớ. Nhưng những số liệu đó đang đo lường tần suất các nhà phát triển của bạn có thể phát hành và mức độ thành công của các bản phát hành đó.
Bạn cũng có thể đo lường độ tin cậy; có lẽ đó là mối quan tâm chính. Chắc chắn là như vậy trong các tổ chức FinTech. Vậy bạn có thể kiểm tra, "Ứng dụng của tôi có đáng tin cậy hơn trước không? Tôi có ít lỗi hơn trước không? Lưu lượng truy cập có hoạt động theo bất kỳ cách khác biệt nào không?" Hoặc bạn có thể muốn xem xét các số liệu cụ thể hơn về nền tảng, chẳng hạn như: "Tôi đã nhận được bao nhiêu yêu cầu hỗ trợ?" Nếu mọi người và tác nhân của họ có thể tự làm mọi thứ vì đó là self-service (tự phục vụ), liệu tôi có còn cần phải hỗ trợ họ nữa không? Hoặc liệu tôi có đang nhận được nhiều yêu cầu hỗ trợ hơn vì cách tôi triển khai điều này gây nhầm lẫn?
Bạn cũng có thể sử dụng một số frameworks khác về developer satisfaction (mức độ hài lòng của nhà phát triển) và developer experience (trải nghiệm của nhà phát triển), chẳng hạn như SPACE. Nhưng quan điểm chung của tôi là: Hãy suy nghĩ về những gì bạn muốn đạt được với điều này — làm cho việc đóng góp của tác nhân AI dễ dàng hơn — và sau đó đo lường xem bạn có thực sự thành công hay không.
Tóm tắt Lời khuyên và Cơ hội tận dụng AI
Và với điều đó, tôi sẽ tóm tắt lời khuyên của mình, một lần nữa, đến từ kinh nghiệm của tôi. Có thể có nhiều điểm hơn trong danh sách này, nhưng tôi nghĩ đây là một khởi đầu tốt. Nếu bạn muốn nền tảng của mình sẵn sàng cho các tác nhân AI để tận dụng tối đa chúng, hãy đảm bảo nền tảng của bạn là self-service, dựa trên API và local first. Đảm bảo bạn có tài liệu tốt và khả năng quan sát trong nền tảng đó để dễ dàng cho AI biết phải làm gì, làm thế nào để làm và làm thế nào để xác minh rằng nó đã hoàn thành. Và khuyến khích/chào đón các đóng góp vào nền tảng của bạn bởi vì bằng cách đó, bạn cũng có thể di chuyển nhanh hơn và triển khai các tính năng mà người dùng của bạn cần. Cuối cùng nhưng không kém phần quan trọng, hãy đo lường xem tất cả những điều này thực sự có hiệu quả hay không.
Và có thể một lời khuyên bổ sung: Có thể tổ chức của bạn đã chống lại một số best practices (thực hành tốt nhất) này. Có thể bạn đã cố gắng thúc đẩy các nền tảng API first này hoặc làm cho chúng thân thiện hơn với môi trường local hoặc có thời gian để viết tài liệu đúng cách. Nhưng sau đó bạn đã gặp phải một số sự phản đối vì mọi người tập trung vào các ưu tiên khác. Hãy tận dụng điều này. Mọi người, từ cấp điều hành đến những người đóng góp cá nhân, đều đang quan tâm đến AI hiện nay. Đây là một chủ đề rất nóng. Vì vậy, bạn có thể sử dụng AI như một cái cớ để triển khai một số best practices mà thực ra luôn là best practices, nếu bạn chưa có cơ hội thực hiện chúng cho đến bây giờ.
Lời Cảm Ơn
Cảm ơn bạn rất nhiều vì đã lắng nghe. Tên tôi là Juan Herrera Salorza. Ở đây bạn có các liên kết đến LinkedIn của tôi, trang web cá nhân và GitHub của tôi. Và nếu bạn thích nó, vui lòng kết nối ở đó. Cảm ơn và chúc bạn có một sự kiện AI Engineered Europe tuyệt vời.
TL;DR
- Banking Circle, một công ty fintech xử lý hàng nghìn tỷ euro thanh toán, đã xây dựng nền tảng Atlas để giúp hơn 250 kỹ sư của mình tập trung vào phát triển sản phẩm bằng cách đơn giản hóa sự phức tạp của cơ sở hạ tầng và đám mây.
- Quy trình phát triển truyền thống thường gây thất vọng cho con người và là thách thức gần như bất khả thi cho các tác nhân AI, do sự phụ thuộc vào kiến thức ngầm, hỗ trợ ad-hoc và quy trình thủ công chậm trễ.
- Để khắc phục, các nền tảng cần ưu tiên tự phục vụ thông qua API, tài liệu rõ ràng (bao gồm cả hướng dẫn cụ thể cho tác nhân AI), và áp dụng các nguyên tắc "shift left" cùng với các hàng rào bảo vệ.
Điểm chính
- Triển khai các khả năng tự phục vụ toàn diện: Đảm bảo mọi tài nguyên và quy trình của nền tảng (từ cấp phát tính toán, lưu trữ đến quản lý bí mật) có thể được kích hoạt và quản lý hoàn toàn tự động, loại bỏ mọi sự phụ thuộc vào can thiệp thủ công.
- Thiết kế nền tảng theo nguyên tắc "API-first": Xây dựng các API được định nghĩa rõ ràng, có khả năng khám phá, xác thực lược đồ, và xác thực/ủy quyền mạnh mẽ để tác nhân AI có thể tương tác hiệu quả và an toàn.
- Áp dụng phương pháp "Shift Left": Cho phép xác thực và kiểm thử cục bộ các thay đổi trước khi đưa vào hệ thống kiểm soát phiên bản hoặc quy trình làm việc, giúp phát hiện lỗi sớm và giảm thiểu lãng phí thời gian.
- Cung cấp khả năng quan sát dành cho tác nhân: Đảm bảo nhật ký, số liệu và dấu vết có thể truy cập được thông qua API hoặc CLI để tác nhân AI có thể tự động xác minh kết quả và đóng vòng lặp tác vụ.
- Xây dựng tài liệu có cấu trúc và tập trung: Tổ chức tài liệu (API-first) theo cách dễ dàng cho tác nhân AI khám phá và tiêu thụ, bao gồm các tệp
agents.mdhoặccopilot.mdđể cung cấp hướng dẫn cụ thể cho tác nhân. - Khuyến khích đóng góp với hàng rào bảo vệ thông minh: Mở cửa cho các đóng góp từ cộng đồng nhà phát triển trong nội bộ, nhưng đồng thời thiết lập các chính sách và hướng dẫn (thông qua tài liệu cho tác nhân) để đảm bảo tuân thủ các tiêu chuẩn và bảo mật.
Từ vựng
Claude Native Technology— Công nghệClaude Nativefintech— công nghệ tài chínhplatform engineering team— nhóm kỹ thuật nền tảngTác nhân AI— AI Agenttự phục vụ— self-serviceAPI first— ưu tiên APIShift Left— Chuyển trái (phương phápShift Left)observability— khả năng quan sáttài liệu— documentationHàng rào bảo vệ— Guardrails
Nội dung chi tiết
Giới thiệu về Banking Circle và Nền tảng Atlas
Xin chào mọi người, cảm ơn rất nhiều vì đã theo dõi và chào mừng đến với buổi nói chuyện của tôi về "Nền tảng cho Con người và Máy móc." Tôi là Juan, trưởng nhóm Claude Native Technology tại một công ty tên là Banking Circle. Có lẽ các bạn chưa biết về chúng tôi, vì vậy hãy để tôi giới thiệu đôi chút về những gì chúng tôi làm. Chủ yếu, chúng tôi là nhà cung cấp dịch vụ thanh toán xuyên biên giới toàn cầu, bên cạnh quản lý tài khoản và thanh khoản. Chúng tôi xử lý hơn một nghìn tỷ euro mỗi năm và cung cấp dịch vụ ngân hàng cho hơn 700 tổ chức tài chính được quản lý. Chúng tôi là một công ty fintech chính hiệu, và trên thực tế, rất nhiều thành viên của chúng tôi đang làm việc trong các vai trò kỹ thuật khác nhau. Chính vì vậy, vài năm trước, chúng tôi đã quyết định thành lập một nhóm kỹ thuật nền tảng (platform engineering team) tại Banking Circle, nơi tôi đang làm việc. Hơn 250 người tại Banking Circle đang xây dựng các loại hệ thống kỹ thuật khác nhau. Điều này bao gồm các API mà khách hàng của chúng tôi đang sử dụng, các hệ thống ngân hàng cốt lõi, một số công cụ nội bộ, khoa học dữ liệu và kỹ thuật dữ liệu, và tất nhiên là tích hợp với các hệ thống thanh toán bù trừ nơi chúng tôi xử lý tất cả các khoản thanh toán. Vì lý do đó, chúng tôi đã quyết định xây dựng một nền tảng mà tất cả các nhóm này có thể sử dụng để chúng tôi có thể đơn giản hóa sự phức tạp trong một số cơ sở hạ tầng và các vấn đề về đám mây cơ bản. Nhờ đó, các kỹ sư có thể tập trung vào việc xây dựng các hệ thống mà họ phải xây dựng. Chúng tôi gọi nền tảng đó là Atlas. Atlas có một số nền tảng con. Chúng tôi có một nền tảng compute nơi mọi người chạy ứng dụng của họ dựa trên Kubernetes. Chúng tôi có một nền tảng infrastructure mà mọi người có thể sử dụng để cấp phát dịch vụ lưu trữ blob, cơ sở dữ liệu, và hệ thống quản lý bí mật. Chúng tôi có các nền tảng messaging để các ứng dụng và hệ thống khác nhau giao tiếp với nhau. Và chúng tôi có các nền tảng observability để chúng tôi có thể biết điều gì đang xảy ra với tất cả các ứng dụng và tất cả các khoản thanh toán mà chúng tôi đang xử lý.
Bài học từ câu chuyện phát triển ứng dụng
Chúng tôi đã đi một chặng đường dài trong hành trình kỹ thuật nền tảng này, nhưng mọi thứ không phải lúc nào cũng dễ dàng. Tôi muốn bắt đầu buổi nói chuyện của mình bằng một câu chuyện nhỏ, sử dụng các tên và nhân vật hư cấu, nhưng dựa trên kinh nghiệm của tôi khi làm việc tại Banking Circle. Tôi chắc chắn nhiều bạn cũng sẽ thấy mình trong câu chuyện này.
Giả sử chúng ta có một nhà phát triển mới, đúng không? Họ vừa gia nhập công ty, vào một nhóm. Họ bắt đầu làm việc và xây dựng ứng dụng đầu tiên của mình. Nhà phát triển này rất giỏi, họ viết mã ứng dụng rất tốt, có thể là cho một hệ thống thanh toán nào đó. Nhưng cuối cùng, họ gặp phải một trở ngại. Họ có mã nguồn, nhưng cần triển khai ứng dụng đó ở đâu đó. Khi đó, nhà phát triển sẽ tự nhiên hỏi một người trong nhóm, "Này, tôi nên làm gì với ứng dụng này? Làm sao để triển khai nó?" Và rồi người trong nhóm có thể nói với nhà phát triển, "Ồ, bạn biết không? Thật ra, tôi đã làm rồi, và nó đã được thiết lập trong pipeline này. Sao bạn không sao chép nó từ đó?"
Nhà phát triển có thể sao chép pipeline. Sau đó, có thể họ phải điều chỉnh một chút. Trong trường hợp này, nó không hoàn toàn giống nhau vì ứng dụng có một số yêu cầu cụ thể. Rồi họ sẽ cố gắng chạy pipeline này. Có thể pipeline sẽ thất bại. Và cuối cùng, nhà phát triển không biết tại sao nó lại thất bại, vì lỗi không liên quan gì đến ứng dụng mà họ đã viết mã. Có thể họ quay lại hỏi đồng đội, "Này, tôi có thể làm gì với cái này?" Và đồng đội có thể nói, "Bạn biết mình nên làm gì không? Bạn nên nói chuyện với người này đang làm việc trong nhóm infrastructure. Họ sẽ giúp bạn."
Bây giờ, nhà phát triển này sẽ đi, có thể họ sẽ nói chuyện với người đó. Cuối cùng, họ sẽ nói, "Ồ vâng, tất nhiên rồi, đây là một lỗi rất hay xảy ra. Tôi có thể giải quyết nó giúp bạn ngay." Lỗi sẽ được giải quyết và nhà phát triển sẽ triển khai ứng dụng. Và rồi việc triển khai đó có thể thành công. Chỉ để nhận ra cuối cùng rằng, trên thực tế, ngoài ứng dụng đó, nhà phát triển còn cần một cơ sở dữ liệu hoặc có thể một số lưu trữ khối. Trở lại vạch xuất phát, nhà phát triển sẽ đến gặp người trong nhóm infrastructure để hỏi, "Này, tôi có thể nhờ bạn tạo cơ sở dữ liệu này hoặc lưu trữ khối này giúp tôi được không?" Và có thể người đó, giả sử với ý định tốt nhất, tất nhiên. Có thể họ muốn giúp. Nhưng họ sẽ nói, "Bạn biết không? Tôi thực sự có rất nhiều việc khác đang làm. Tôi sẽ giúp bạn, nhưng đó sẽ là tuần tới."
Vì vậy, rõ ràng nhà phát triển sẽ cảm thấy thất vọng vì họ đã hoàn thành phần việc của mình. Nhưng rồi họ lại phải vật lộn rất nhiều trong quá trình triển khai ứng dụng và để ứng dụng chạy với tất cả các phụ thuộc mà nó cần. Có lẽ họ đã làm theo một số tài liệu, thứ mà ai đó đã viết trên đường đi. Nhưng sau đó họ cũng phải dựa vào việc hỏi đồng đội và hỏi người ở nhóm khác.
Thách thức đối với Tác nhân AI
Đây là một tình huống tồi tệ mà tôi nghĩ tất cả chúng ta đã từng trải qua ở một thời điểm nào đó. Đó là một tình huống tồi tệ đối với một con người. Nhưng ngày nay, tất cả chúng ta đều đang sử dụng các Mô hình Ngôn ngữ Lớn (LLM). Chúng ta đang sử dụng các tác nhân AI để hỗ trợ công việc hàng ngày của mình. Và nếu tình huống này khó khăn đối với một nhà phát triển, thì nó về cơ bản là bất khả thi đối với một cỗ máy, bởi vì cỗ máy sẽ không thể "đi thử pipeline rồi lên tầng hai nói chuyện với người ở nhóm khác". Tất nhiên, một tác nhân có thể sử dụng các ứng dụng như Teams hoặc thậm chí sử dụng một mô hình giọng nói nào đó để gọi điện thoại. Nhưng nhìn chung, một tác nhân mã hóa sẽ không thể thực hiện tất cả những điều này. Vì vậy, những vấn đề mà các nhà phát triển đang gặp phải đột nhiên trở nên rõ ràng hơn rất nhiều khi một tác nhân phải đối mặt với chúng. Và chúng là một yếu tố hạn chế đối với năng suất của tác nhân mã hóa này hoặc năng suất của nhà phát triển khi sử dụng tác nhân mã hóa. Những gì tôi sắp trình bày sẽ giải quyết một số điểm trong câu chuyện này. Nhưng điều cốt lõi là các thực hành tốt nhất vẫn là các thực hành tốt nhất. Chúng ta đã biết từ lâu rằng một số điều này, như dựa vào đồng đội để hướng dẫn cách triển khai một ứng dụng hoặc phải liên hệ với một người ở nhóm khác, hoặc phải chờ đợi một pipeline chỉ để nhận ra rằng nó không phải là thứ chúng ta thực sự cần, chưa bao giờ là tốt. Chúng chỉ trở nên rõ ràng hơn và có lẽ đau đớn hơn nhiều khi chúng ta có những tác nhân mã hóa này làm việc bên cạnh chúng ta.
Các thực hành tốt nhất cho việc xây dựng nền tảng thân thiện với Tác nhân AI
Vậy chúng ta có thể làm gì về điều đó? Đối với tôi, điều đầu tiên phải là tự phục vụ (self-service). Nếu tôi cần bất kỳ tài nguyên nào từ nền tảng này, nếu tôi cần có thể làm bất cứ điều gì thông qua các nền tảng này, tôi phải có khả năng tự mình làm điều đó. Tương tự, nếu tác nhân của tôi cần có khả năng làm bất cứ điều gì trên nền tảng, nó phải có khả năng tự mình làm điều đó. Không nên có quy trình nào yêu cầu nói chuyện với một người cụ thể hoặc chờ đợi một người cụ thể làm điều gì đó. Tác nhân phải có khả năng kích hoạt mọi thứ nó cần. Và để làm được điều đó, tất nhiên, điều quan trọng là luồng tự phục vụ hoặc quy trình tự phục vụ phải trực quan. Tất nhiên, chúng ta cần tài liệu hóa cách những điều này hoạt động, và tôi sẽ đề cập đến điều đó ngay sau đây. Nhưng chúng ta càng làm cho nó dễ dàng, thì nó càng thực sự là tự phục vụ. Bởi vì nếu nó về mặt kỹ thuật là tự phục vụ, nhưng lại yêu cầu tìm kiếm các khối xây dựng từ năm nơi khác nhau và ghép chúng lại, sau đó kích hoạt một luồng ở một nơi khác, thì nó không thực sự là tự phục vụ. Vì vậy, hãy làm cho nó tự động, loại bỏ con người khỏi quy trình và làm cho nó dễ dàng nhất có thể.
Ưu tiên API và Giao diện dòng lệnh
Điểm thứ hai mà tôi nghĩ là quan trọng là làm cho nó dựa trên API. Tự phục vụ có thể trông theo nhiều cách khác nhau, và nó cũng có thể là thứ gì đó dựa trên việc gửi văn bản ở đâu đó. Nó có thể dựa trên việc nhấp vào một nút. Nó có thể dựa trên nhiều thứ, nhưng các tác nhân rất giỏi trong việc gọi các Giao diện lập trình ứng dụng (API) được định nghĩa rõ ràng. Tất nhiên, nó cũng có thể là một giao diện dòng lệnh (CLI) trên nền API. Nó có thể là một máy chủ MCP xoay quanh API mà các tác nhân sử dụng. Tất cả những điều đó cũng là những ý tưởng hay. Nhưng nhìn chung, bên dưới tất cả những điều đó, bạn nên có một API được định nghĩa rõ ràng. Điều này có tính khả năng khám phá (discoverable). Vì vậy, khi tương tác với nó, tác nhân sẽ khám phá ra những gì nó có thể làm và các tùy chọn có sẵn. Nó có xác thực lược đồ (scheme validation). Vì vậy, một cách tự nhiên, tác nhân sẽ chỉ gửi những thứ sẽ hoạt động. Nó cũng có xác thực (authentication) hoặc có thể có, tùy thuộc vào những gì bạn đang xây dựng, ủy quyền (authorization) tại chỗ. Vì vậy, nhờ đó, tác nhân của bạn sẽ được phép sử dụng thông tin xác thực của bạn với tư cách là một nhà phát triển, hoặc có thể nếu tác nhân đang ở trong một luồng cụ thể, nó sẽ có thông tin xác thực riêng của mình. Nhưng nó sẽ có thể thực hiện tất cả những điều này một cách an toàn và nó sẽ biết mình đang làm gì. Và với điều này, tác nhân có thể tương tác qua lại. Nó có thể cố gắng làm điều gì đó. API sẽ nhận được phản hồi, và tác nhân có thể bắt đầu làm việc theo cách này nơi nó đi vào một vòng lặp (loop) cho đến khi nó đạt được những gì nó cần hoặc những gì nó được yêu cầu làm.
Shift Left và Vòng lặp tác nhân
Điều đó đưa tôi đến điểm tiếp theo. Một tác nhân thường chạy trên máy của bạn. Bạn cũng có thể có nó trên một máy chủ nào đó ở đâu đó, và bạn có thể có open-close hoặc gì đó và bạn đang giao tiếp với một tác nhân ở đó. Nhưng thông thường, một tác nhân là cục bộ (local) với máy. Tất nhiên, các mô hình đang chạy ở nơi khác, nhưng công việc mà tác nhân đang làm là cục bộ. Vì vậy, hãy làm cho tác nhân dễ dàng làm điều đó. Trước hết, shift left. Nếu một thứ gì đó sẽ thất bại, nó nên thất bại càng sớm càng tốt. Vì vậy, đừng để tác nhân đẩy một thứ gì đó vào hệ thống kiểm soát phiên bản (version control system) của bạn chỉ để rồi thất bại trong một quy trình làm việc (workflow) sau vài phút. Nếu bạn có thể xác thực mọi thứ ngay từ đầu, nếu bạn có thể chạy chúng cục bộ, một lần nữa bằng cách gọi các API đó, hoặc có thể sử dụng một loại wrapper nào đó xung quanh chúng, hãy làm điều đó. Shift left càng nhiều càng tốt.
Sau đó, như tôi đã nói, các tác nhân sẽ đi vào một vòng lặp. Vì vậy, nếu tác nhân ở trên máy của bạn và nó có thể làm mọi thứ nó cần ở đó, và bạn xác định rõ ràng đây là những gì tôi cần, tác nhân sẽ lặp lại cho đến khi nó đạt được điều đó. Bây giờ điều quan trọng là bạn phải cung cấp cho nó các hướng dẫn chính xác (precise instructions) mà bạn mô tả nhiệm vụ, bạn nói với tác nhân đây là những gì tôi cần bạn làm. Và điều quan trọng nữa là bạn phải nói với tác nhân đây là cách bạn biết mình đã hoàn thành nhiệm vụ thành công. Điều này hơi quan trọng khi làm việc với các tác nhân vì với tư cách là con người, chúng ta có thể xác minh điều này theo nhiều cách khác nhau. Và chúng ta có rất nhiều hệ thống khả năng quan sát (observability) nơi có lẽ chúng ta muốn kiểm tra xem ứng dụng đã được triển khai chưa và các số liệu/thước đo (metrics) có ổn không. Có thể chúng ta sẽ xem xét một số bảng điều khiển (dashboards). Các tác nhân sẽ không xem xét các giao diện đồ họa đó. Vì vậy, bạn cũng cần nghĩ xem khả năng quan sát trông như thế nào nếu người dùng chính là một tác nhân. Hãy làm cho các nhật ký (logs), số liệu/thước đo (metrics), dấu vết (traces), mọi thứ có thể giúp ích, có sẵn thông qua một API hoặc thông qua CLI hoặc một máy chủ MCP hoặc một thứ gì đó tương tự. Bằng cách đó, bạn đang cho phép tác nhân đóng vòng lặp. Bạn đang nói cho nó cách làm mọi thứ và cách xác minh rằng mọi thứ đã được thực hiện chính xác.
Tầm quan trọng của tài liệu
Và vì tôi đang nói về việc hướng dẫn tác nhân cách làm mọi việc, một điều cực kỳ quan trọng là tài liệu. Tất nhiên bạn đã có tài liệu rồi. Tôi nghĩ nhiều người trong chúng ta đã viết tài liệu, đặt nó ở đâu đó và sau đó không thể tìm thấy nó. Khi chúng ta cần tiết lộ (expose) tài liệu này cho các tác nhân, nhưng điều này cũng đã đúng với con người, chúng ta cần phải có cấu trúc xung quanh nó. Vì vậy, có nhiều chiến lược khác nhau mà bạn có thể muốn thực hiện. Một trong số đó có thể là, đặc biệt nếu bạn đang làm việc trong các kho lưu trữ (repositories) nhỏ hơn, hãy giữ tài liệu của bạn bên cạnh mã nguồn mà nó đang tài liệu hóa. Bằng cách đó, nếu một tác nhân đang làm việc trong thư mục hoặc kho lưu trữ cụ thể đó, nó có mọi thứ cần thiết. Nó có mã nguồn cần làm việc và tài liệu mô tả nó. Nếu bạn đang làm việc trên một thứ gì đó lớn hơn hoặc có thể là một nhóm nền tảng (platform team), nếu bạn cần tiết lộ tất cả tài liệu về nền tảng mà một tác nhân có thể cần, ý tưởng tốt hơn là đặt nó ở một nơi tập trung (centralized place) để tác nhân có thể đến đó và bắt đầu khám phá tài liệu nào có sẵn.
Ưu tiên API và Tài liệu cho Tác nhân
Một lần nữa, hãy nghĩ đến API first (ưu tiên API) bởi vì tác nhân sẽ tốt hơn nhiều trong việc tiêu thụ trang web theo cách đó. Cụ thể, nếu bạn có thể cung cấp các phần tài liệu cụ thể mà nó cần để tương tác qua API thì càng tốt, thay vì tải toàn bộ trang HTML vào bộ nhớ và cố gắng tìm ra những phần liên quan ở đó.
Tất nhiên, khi chúng ta nói về tài liệu, chúng ta cũng có thể nghĩ về tài liệu dành riêng cho tác nhân. Tôi cho rằng nhiều bạn đã quen thuộc với điều này, nhưng bạn có thể sử dụng các tệp agent.md hoặc clot.md (hướng dẫn cho copilot, .md) tùy thuộc vào tác nhân bạn chọn. Bằng cách đó, bạn cũng có thể mô tả cho tác nhân cách nó nên hoạt động trong một repository cụ thể. Bạn có thể hướng dẫn nó, "Bạn nên luôn xây dựng theo cách này, kiểm thử theo cách này, triển khai theo cách này. Bạn có thể xác minh theo cách này." Bạn có thể bao gồm tất cả những điều đó trong tệp agents.md của mình. Bạn cũng có thể áp dụng một trong những tài liệu này rộng rãi hơn cho các hệ thống khác nhau, sau đó thêm một tệp agents.md cụ thể hơn cho một dự án hoặc repository cụ thể.
Bạn cũng có thể sử dụng kỹ năng nếu bạn tuân thủ một số quy ước hoặc có một cách tương tác đã được xác định rõ ràng với một số nền tảng của bạn. Bạn có thể mã hóa những điều đó trong một kỹ năng, mà một lần nữa, chỉ là một tài liệu Markdown. Và bằng cách đó, bạn đang nói với tác nhân, "Khi bạn thực hiện loại nhiệm vụ này, bạn nên làm theo cách đó."
Khuyến Khích Đóng Góp và Hàng rào Bảo vệ
Cuối cùng nhưng không kém phần quan trọng, bạn cũng nên khuyến khích sự đóng góp vào các nền tảng của mình. Nếu bạn đang xây dựng các nền tảng dành cho nhà phát triển nội bộ, chúng sẽ phục vụ các nhà phát triển trong tổ chức của bạn. Và bạn muốn họ đóng góp vì bằng cách đó, họ cũng có thể giúp bạn; họ có thể giúp bạn giúp họ. Vì vậy, bạn nên khuyến khích họ, bạn nên chào đón các đóng góp, và vì họ đang sử dụng các tác nhân, rào cản gia nhập sẽ thấp hơn. Và vì vậy, tôi mong đợi — và đó là điều tôi đã thấy — rằng mọi người sẽ sẵn lòng đóng góp vào các nền tảng hơn.
Tuy nhiên, đây là một con dao hai lưỡi bởi vì cuối cùng, với tư cách là cá nhân hoặc nhóm sở hữu nền tảng, bạn chịu trách nhiệm bảo trì nó. Vì vậy, bạn nên suy nghĩ kỹ về những điều cần xem xét khi đóng góp vào nền tảng. Bạn cần có một số Hàng rào bảo vệ (suy nghĩ về bảo mật hoặc tuân thủ) hoặc chỉ đơn giản là tuân theo một bộ tiêu chuẩn được xác định rõ ràng, điều này sau đó giúp bạn duy trì nền tảng. Nếu bạn muốn đảm bảo tác nhân luôn tuân theo các quy ước đó, bạn có thể thực hiện điều này bằng một số chính sách, có lẽ trong hệ thống của bạn, nhưng bạn cũng có thể dựa vào việc cung cấp ngữ cảnh cho tác nhân. Một lần nữa, bạn có thể sử dụng agents.md, bạn có thể sử dụng một số kỹ năng để khi mọi người muốn đóng góp vào nền tảng của bạn, họ cũng có thể hướng dẫn tác nhân của mình đến các tệp Markdown này và tham khảo chúng như tài liệu về cách đóng góp.
Nói chung, tôi khuyến khích sự kết hợp của cả hai: thiết lập Hàng rào bảo vệ cho mọi thứ bạn tuyệt đối không muốn xảy ra. Sử dụng một số loại chính sách cho điều đó, nhưng sau đó, hãy sử dụng các tệp Markdown để giúp các tác nhân hoạt động theo cách bạn muốn.
Đo lường Hiệu quả của Nền tảng AI
Và sau đó chúng ta đi đến một câu hỏi rất quan trọng, đó là: "Được rồi, chúng ta đã làm tất cả những điều này, phải không?" Mọi người đang sử dụng AI trong tổ chức. Họ đang tuân theo những thực hành mà chúng ta đã khuyến nghị. Chúng ta đã xây dựng một nền tảng có thể được sử dụng bởi AI, nhưng liệu nó có hiệu quả không? Và tôi nghĩ cách để biết liệu nó có hoạt động hay không là bằng cách đo lường xem nó có hiệu quả hay không.
Tất nhiên, bạn có thể đo lường những điều này trước và sau khi thực hiện một số thay đổi trong nền tảng của mình để xem chúng có ảnh hưởng hay không. Và tùy thuộc vào những gì bạn muốn làm, bạn có thể muốn tập trung vào loại số liệu này hay loại số liệu khác. Bây giờ, chúng ta biết rằng có các số liệu về phân phối ứng dụng và chúng ta có toàn bộ Dora metrics về vấn đề đó: Tần suất thay đổi, thời gian trung bình để phục hồi, thời gian chờ, và một cái khác mà tôi hiện không thể nhớ. Nhưng những số liệu đó đang đo lường tần suất các nhà phát triển của bạn có thể phát hành và mức độ thành công của các bản phát hành đó.
Bạn cũng có thể đo lường độ tin cậy; có lẽ đó là mối quan tâm chính. Chắc chắn là như vậy trong các tổ chức FinTech. Vậy bạn có thể kiểm tra, "Ứng dụng của tôi có đáng tin cậy hơn trước không? Tôi có ít lỗi hơn trước không? Lưu lượng truy cập có hoạt động theo bất kỳ cách khác biệt nào không?" Hoặc bạn có thể muốn xem xét các số liệu cụ thể hơn về nền tảng, chẳng hạn như: "Tôi đã nhận được bao nhiêu yêu cầu hỗ trợ?" Nếu mọi người và tác nhân của họ có thể tự làm mọi thứ vì đó là self-service (tự phục vụ), liệu tôi có còn cần phải hỗ trợ họ nữa không? Hoặc liệu tôi có đang nhận được nhiều yêu cầu hỗ trợ hơn vì cách tôi triển khai điều này gây nhầm lẫn?
Bạn cũng có thể sử dụng một số frameworks khác về developer satisfaction (mức độ hài lòng của nhà phát triển) và developer experience (trải nghiệm của nhà phát triển), chẳng hạn như SPACE. Nhưng quan điểm chung của tôi là: Hãy suy nghĩ về những gì bạn muốn đạt được với điều này — làm cho việc đóng góp của tác nhân AI dễ dàng hơn — và sau đó đo lường xem bạn có thực sự thành công hay không.
Tóm tắt Lời khuyên và Cơ hội tận dụng AI
Và với điều đó, tôi sẽ tóm tắt lời khuyên của mình, một lần nữa, đến từ kinh nghiệm của tôi. Có thể có nhiều điểm hơn trong danh sách này, nhưng tôi nghĩ đây là một khởi đầu tốt. Nếu bạn muốn nền tảng của mình sẵn sàng cho các tác nhân AI để tận dụng tối đa chúng, hãy đảm bảo nền tảng của bạn là self-service, dựa trên API và local first. Đảm bảo bạn có tài liệu tốt và khả năng quan sát trong nền tảng đó để dễ dàng cho AI biết phải làm gì, làm thế nào để làm và làm thế nào để xác minh rằng nó đã hoàn thành. Và khuyến khích/chào đón các đóng góp vào nền tảng của bạn bởi vì bằng cách đó, bạn cũng có thể di chuyển nhanh hơn và triển khai các tính năng mà người dùng của bạn cần. Cuối cùng nhưng không kém phần quan trọng, hãy đo lường xem tất cả những điều này thực sự có hiệu quả hay không.
Và có thể một lời khuyên bổ sung: Có thể tổ chức của bạn đã chống lại một số best practices (thực hành tốt nhất) này. Có thể bạn đã cố gắng thúc đẩy các nền tảng API first này hoặc làm cho chúng thân thiện hơn với môi trường local hoặc có thời gian để viết tài liệu đúng cách. Nhưng sau đó bạn đã gặp phải một số sự phản đối vì mọi người tập trung vào các ưu tiên khác. Hãy tận dụng điều này. Mọi người, từ cấp điều hành đến những người đóng góp cá nhân, đều đang quan tâm đến AI hiện nay. Đây là một chủ đề rất nóng. Vì vậy, bạn có thể sử dụng AI như một cái cớ để triển khai một số best practices mà thực ra luôn là best practices, nếu bạn chưa có cơ hội thực hiện chúng cho đến bây giờ.
Lời Cảm Ơn
Cảm ơn bạn rất nhiều vì đã lắng nghe. Tên tôi là Juan Herrera Salorza. Ở đây bạn có các liên kết đến LinkedIn của tôi, trang web cá nhân và GitHub của tôi. Và nếu bạn thích nó, vui lòng kết nối ở đó. Cảm ơn và chúc bạn có một sự kiện AI Engineered Europe tuyệt vời.