Context Is the New Code — Patrick Debois, Tessl

• "Ngữ cảnh là mã nguồn mới" là chủ đề chính, tập trung vào sự thay đổi từ lập trình truyền thống sang việc quản lý và tối ưu hóa "ngữ cảnh" (như lời nhắc, kỹ năng) được cung cấp cho các tác nhân AI mã hóa.
• Sự thay đổi này đòi hỏi một "Vòng đời Phát triển Ngữ cảnh" (CDLC) tương tự như SDLC, bao gồm việc tạo, kiểm thử, phân phối và quan sát ngữ cảnh.
• Áp dụng CDLC giúp nâng cao hiệu quả, khả năng tái sử dụng và giải quyết các thách thức về phiên bản, phụ thuộc và bảo mật trong phát triển AI, giống như cách chúng ta quản lý mã nguồn truyền thống.

• Ngữ cảnh là Mã nguồn Mới: Nhận thức rằng các yếu tố như lời nhắc, kỹ năng, tài liệu và dữ liệu bên ngoài đóng vai trò là "mã nguồn" mới cho tác nhân AI, yêu cầu một tư duy phát triển khác biệt.
• Áp dụng Vòng đời Phát triển Ngữ cảnh (CDLC): Triển khai một chu trình có cấu trúc (Generate, Test, Distribute, Observe) để quản lý ngữ cảnh, phản ánh các phương pháp phát triển phần mềm truyền thống.
• Tạo Ngữ cảnh Hiệu quả: Chuyển từ việc tạo lời nhắc thủ công sang sử dụng lời nhắc tái sử dụng, biến các đoạn mã lớn thành "kỹ năng" và tích hợp tài liệu thư viện hoặc dữ liệu nội bộ (Git, Slack, ticket) làm ngữ cảnh.
• Kiểm thử Ngữ cảnh Nghiêm ngặt: Phát triển "eVals" (hệ thống đánh giá tự động) để kiểm thử ngữ cảnh, bao gồm kiểm tra cú pháp, độ rõ ràng (như Grammarly cho ngữ cảnh) và kiểm thử chức năng (ví dụ: xác minh tiền tố API, chạy end-to-end trong môi trường sandbox).
• Tích hợp CI/CD cho Ngữ cảnh: Đưa việc kiểm thử ngữ cảnh vào quy trình CI/CD, có tính đến tính không xác định của kết quả AI (sử dụng "ngân sách lỗi" hoặc nhiều lần chạy) để liên tục tối ưu hóa ngữ cảnh.
• Phân phối và Tái sử dụng Ngữ cảnh: Đóng gói các phần ngữ cảnh có thể tái sử dụng (kỹ năng) thành thư viện và registry để chia sẻ, đồng thời quản lý các phụ thuộc giữa chúng để tránh "dependency hell".
• Bảo mật và Khả năng Quan sát Ngữ cảnh: Áp dụng các biện pháp bảo mật cho các gói ngữ cảnh (ví dụ: quét lỗ hổng, tạo AI SBOM) và sử dụng nhật ký tác nhân để quan sát, thu thập phản hồi nhằm cải thiện ngữ cảnh liên tục.

• AI agent — tác nhân AI
• context — ngữ cảnh
• prompt — lời nhắc
• skill — kỹ năng
• context development lifecycle (CDLC) — vòng đời phát triển ngữ cảnh
• evaluation (eVal) — hệ thống đánh giá tự động (eVals)
• observability — khả năng quan sát
• dependency hell — địa ngục phụ thuộc
• SBOM (Software Bill of Materials) — SBOM (danh sách nguyên vật liệu phần mềm)
• coding agent — tác nhân mã hóa

Lời mở đầu Hội nghị và Chủ đề chính

Có một vài người muốn bắt đầu sớm hơn. Tôi sẽ tận dụng cơ hội này để chính thức khai mạc chuyên đề kiến trúc sư. Không có người dẫn dắt chuyên đề này, vì vậy tôi tự mình đảm nhận. Cảm ơn các bạn đã đến đây. Tôi hy vọng các bạn đã có một hội nghị tốt đẹp. Thật tuyệt vời khi có nhiều người đến tham dự. Có lẽ trước khi tôi bắt đầu, ai trong số các bạn đã từng sử dụng bất kỳ tác nhân AI mã hóa nào trong phòng này? Xin hãy giơ tay. Hãy hạ tay xuống. Ai chưa từng sử dụng? Xin hãy giơ tay. Ok, những người cùng chí hướng với tôi. Hoàn hảo.

Chủ đề của chúng ta là "Ngữ cảnh là mã nguồn mới" hay "vòng đời phát triển ngữ cảnh". Tôi cảm thấy vinh dự khi được ở đây. Mỗi lần, tôi cố gắng trình bày một chủ đề khác tại hội nghị kỹ thuật AI. Vì vậy, đây là một chút suy nghĩ tiến xa hơn. Đây là một ý tưởng chưa hoàn thiện, không phải mọi thứ đều đã được định hình, nhưng liệu có điều gì đã hoàn thiện trong AI không?

Ngữ cảnh là Mã nguồn Mới

Vậy thì hãy bắt đầu. Tôi cho rằng tất cả các bạn hiện đang vibe coding (lập trình theo cảm hứng) với các lời nhắc. Tôi hầu như không còn phải chạm vào mã nguồn nữa; tôi chỉ cần yêu cầu AI thực hiện điều gì đó khác biệt. Vì vậy, tôi sẽ nói rằng ngữ cảnh là mã nguồn mới vì nó đang được tạo ra.

Một điểm tiến bộ hơn mà tôi nhận thấy ở bản thân là tôi có những đoạn mã lớn mà tôi thường sử dụng, có thể là một số helper và các đoạn mã khác. Tôi đã biến chúng thành một kỹ năng. Chúng tôi đã có điều đó trong sản phẩm của mình. Đó là một quá trình onboarding từ các tác nhân AI. Mọi người có Python, Node.js và tất cả các thứ khác. Sau đó, họ có các công cụ khác nhau để đóng gói, và việc thực sự mã hóa điều đó là không thể. Nó sẽ đòi hỏi rất nhiều mã hóa. Nhưng nếu tôi chỉ nói một kỹ năng rằng: "Hãy tìm ra trình quản lý gói của họ trước, sau đó tìm ra hệ sinh thái của họ, và sau đó thực hiện các bước này cùng với người dùng." Nó đã giải quyết nhiều vấn đề hơn những gì chúng ta có thể mã hóa. Vì vậy, đó là một phần khác mà tôi muốn nói rằng mã nguồn cũng đang biến đổi trở lại thành ngữ cảnh như một kỹ năng, cũng như một quy trình làm việc có thể tái sử dụng.

Tôi muốn các bạn suy nghĩ về điều đó. Tôi thích suy nghĩ song song. Vào năm 2009, tôi không biết có ai làm DevOps ở đây không. Lúc đó tôi đã từng nói: "Điều gì sẽ xảy ra nếu vận hành trông giống phát triển hơn?" Và sau đó chúng ta có sự cộng tác, triển khai, và tất cả những thứ đó. Vì vậy, năm ngoái, tôi bắt đầu suy nghĩ, điều gì sẽ xảy ra nếu ngữ cảnh là mã nguồn? Làm thế nào để chúng ta xử lý điều này một cách nhất quán hơn? Về cơ bản, nó đang nói rằng nếu chúng ta có một vòng đời phát triển phần mềm, thì vòng đời phát triển ngữ cảnh sẽ trông như thế nào? Bởi vì về cơ bản chúng ta đang chuyển sang một nơi khác. Đó là ngữ cảnh, không phải mã nguồn.

Vòng đời Phát triển Ngữ cảnh

Nó trông như thế nào? Tôi đã nghĩ ra điều này, tất nhiên là một vòng lặp vô hạn với một số kiến thức nền về DevOps. Nhưng toàn bộ ý tưởng là chúng ta tạo ra rất nhiều ngữ cảnh. Sau đó, hy vọng chúng ta kiểm thử ngữ cảnh đó. Chúng ta phân phối ngữ cảnh có thể cho một số đồng nghiệp, cho một số bộ phận khác trong tổ chức. Chúng ta quan sát xem liệu nó có hoạt động hay không, và nếu nó không hoạt động hoặc hoạt động, chúng ta gọi là điều chỉnh và tạo lại ngữ cảnh và sau đó tiếp tục từ đó. Vì vậy, đó là Agent Loop mà tôi sẽ trình bày cùng với một số ví dụ. Vậy hãy đi từng bước một.

Tạo Ngữ cảnh (Generate)

Phần tạo có lẽ là phần mà tất cả các bạn quen thuộc nhất. Bởi vì tất cả các bạn đều đang tạo lời nhắc. Các bạn đang tạo ngữ cảnh thủ công, nhập mọi thứ, đúng không? Tôi thực sự ngạc nhiên khi tôi chỉ cần hỏi AI "cho tôi biết bài nói của tôi tại AI engineer là khi nào", và nó sẽ tìm nạp trang web và chỉ nói, "Đây là bài nói của bạn." Nó làm tôi kinh ngạc. Nhưng này, tôi đã cung cấp ngữ cảnh cho nó rằng tôi là Patrick, và tất cả những thứ đó, đúng không? Vì vậy, đây là ngữ cảnh rất đơn giản. Đây là điều mà có lẽ bạn làm rất nhiều trong thiết lập của mình.

Nếu bạn tiến bộ hơn một chút, bạn sẽ thấy rằng việc tạo lời nhắc là tẻ nhạt. Tôi muốn có những lời nhắc có thể tái sử dụng. Vì vậy, tùy thuộc vào khung làm việc của tác nhân mã hóa của bạn, họ gọi đó là hướng dẫn. May mắn thay, hiện nay có một chút tiêu chuẩn hóa đang diễn ra, nơi nó giống như một tệp agent.md và một số phần tương tự. (Thật đáng tiếc cho Claude vẫn gọi nó là Claude.md, nhưng dù sao, bạn hiểu ý tôi). Có những lời nhắc có thể tái sử dụng, những phần ngữ cảnh có thể tái sử dụng mà chúng ta đang tạo.

Chúng ta cũng có thể đưa các ngữ cảnh khác vào. Nếu chúng ta có tài liệu về các thư viện mà chúng ta sử dụng hàng ngày, chúng ta muốn đưa chúng vào vì các Mô hình Ngôn ngữ Lớn (LLM) có thể không có tài liệu mới nhất. Và vì vậy, nó đang tạo ra "ảo giác". Đó là phiên bản hai hay phiên bản ba? Chúng ta không biết. Vì vậy, chúng ta cung cấp cho nó một ngữ cảnh và nói: "Vui lòng tải xuống tài liệu." Hy vọng sau đó tác nhân được tối ưu hóa. Và sau đó chúng sẽ làm tốt hơn trong việc sinh mã cho phiên bản đó của thư viện. Đây là một phần khác để có được ngữ cảnh tốt hơn và tạo ngữ cảnh từ thư viện.

Và tất nhiên, sẽ không đầy đủ nếu chúng ta nói rằng hãy lấy ngữ cảnh từ bất cứ đâu. Lấy nó từ GitLab, GitHub, Slack của bạn. Tất cả ngữ cảnh mà chúng ta đang kéo vào, chúng ta đang tạo ra. Ngay cả một ticket cũng đang tạo ra ngữ cảnh bởi vì chúng ta đang kéo nó vào khi chúng ta làm việc.

Và sau đó, có thể một xu hướng mới là: "Điều gì sẽ xảy ra nếu chúng ta bắt đầu viết các lời nhắc của mình dưới dạng đặc tả, tức là phát triển dựa trên đặc tả, sau đó được tác nhân chia nhỏ thành một chế độ lập kế hoạch thành các lời nhắc từng bước mà sau đó nó thực hiện?" Vì vậy, có rất nhiều sự sáng tạo đang diễn ra trong lĩnh vực đó. Các bạn biết đấy, đơn giản. Đây có lẽ là điều mà bạn gần gũi nhất.

Kiểm thử Ngữ cảnh (Test)

Nhưng khi bạn đang nhập tất cả ngữ cảnh đó và tạo tất cả ngữ cảnh đó, bạn thay đổi hai dòng trong Claude.md của mình. Bạn có biết tác động là gì không? Nó có giống như YOLO không? Trông có vẻ tốt với tôi. Hãy làm đi. Bạn phải nghĩ về cách chúng ta kiểm thử mọi thứ. Nó không chỉ là việc chúng ta có một đoạn mã và chúng ta có một đoạn ngữ cảnh bây giờ. Chúng ta cần viết các kiểm thử để xem tác động là gì. Tác nhân mã hóa mới? Chúng ta không biết các dòng có còn hoạt động không.

Bây giờ, điều này không phải là mới trong thế giới kỹ thuật AI nhưng nó chưa phổ biến trong thế giới lập trình với AI khi bạn bắt đầu viết các eVals (hệ thống đánh giá tự động), là các kiểm thử cho ngữ cảnh mã của bạn. Hơi khó đọc một chút, nhưng các bạn biết đấy, nếu các bạn suy nghĩ song song, chúng ta có các cấp độ kiểm thử khác nhau trong mã nguồn, và một cách đơn giản có thể là kiểm tra cú pháp (linting). IDE của bạn có những dòng gợn sóng như, "Này, điều này không phải là đúng cú pháp hoặc bạn có thể làm tốt hơn như vậy." Đây là một ví dụ về xác thực của một kỹ năng nơi chúng ta nói, bạn cần phải có mô tả. Nó chỉ có thể dài đến thế. Vì vậy, nó đang xác thực theo đặc tả của định dạng ngữ cảnh trong trường hợp này. Một analogy đơn giản, một công cụ kiểm tra cú pháp (linter) đơn giản mà bạn có thể chạy.

Và sau đó bạn có thể làm những thứ khác như và tôi có thể chưa tìm thấy cái tương đương tốt trong mã hóa, nhưng hãy nghĩ về điều này như một Grammarly. Đúng không? Vì vậy, nếu bạn viết ngữ cảnh, tác nhân có thực sự hiểu những gì bạn đang viết không? Nếu bạn viết hai từ, nó không đủ chi tiết để thực sự hiểu ngữ cảnh. Vì vậy, những gì bạn có thể làm là bạn có thể hỏi: "Ok, với ngữ cảnh này, bạn nghĩ gì? Bạn có hiểu điều này không?" Và sau đó bạn có thể nhận được phản hồi như, "Ồ, nó không được viết đủ rõ ràng" hoặc "nó không hoàn chỉnh. Bạn đang thiếu các phần." Vì vậy, đó cũng là từ các công cụ. Vì vậy, bất cứ khi nào bạn viết ngữ cảnh của mình bây giờ, bạn sẽ nhận được một Grammarly nói: "Này, hãy làm điều này." Đó là lý do tại sao tôi thích lập trình bằng giọng nói (voice code). Vì một lý do nào đó, tôi chi tiết hơn rất nhiều khi lập trình bằng giọng nói so với khi gõ. Tôi là một người gõ kém, vẫn gõ bằng hai ngón sau rất nhiều năm. Nhưng khi tôi nói, tôi như là, các câu xuất hiện trên màn hình, nhưng nó giúp tôi có được ngữ cảnh tốt ở đó.

Được rồi, một loại kiểm thử khác. Hãy tưởng tượng bạn đưa vào Claude.md hoặc agent.md của bạn, tôi nên nói như vậy. Bây giờ, mọi điểm cuối API phải sử dụng tiền tố awesome. Đúng không? Bạn có một số quy ước trong công ty của mình. Đúng không? Thật tuyệt vời. Vì vậy, người tạo lời nhắc của bạn sau đó sẽ là, "thêm cho tôi một điểm cuối mới để lưu một người dùng." Và bạn thực sự mong đợi tác nhân mã hóa của mình chỉ nói mã được tạo có /awesome/user. Thật tuyệt vời.

Nhưng cách chúng ta có thể kiểm thử điều này là bằng cách hỏi Mô hình Ngôn ngữ Lớn (LLM) rằng mã được tạo có thực sự bắt đầu bằng /awesome không? Bây giờ, bạn có thể làm điều đó bằng regex, tôi biết. Đây chỉ là để minh họa, nhưng bạn có thể yêu cầu nó đánh giá mã của bạn dựa trên tiêu chí của bạn và liệu nó có làm đúng việc không. Đúng không? Vì vậy, hãy tưởng tượng bạn sẽ hỏi cùng một câu hỏi mà không có ngữ cảnh ở trên. Không LLM nào sẽ tự động thêm tiền tố awesome vào URL của bạn. Vì vậy, đó là nơi nội dung của bạn hoặc các thứ đặc trưng của công ty, đặc trưng của nhóm của bạn xuất hiện, và đó là lý do tại sao bạn vẫn viết các kiểm thử đó để xem liệu điều này có còn hoạt động không. Bây giờ, có thể Gemini phản ứng khác với Copilot hoặc một cái gì đó, và trong công ty của bạn, bạn cần làm cho nó có thể chuyển đổi ngữ cảnh hơn. Với điều này, bạn chạy các kiểm thử, và bạn thực sự có thể biết. Đó là sự khác biệt. Và sau đó bạn có thể tạo ra toàn bộ các bộ kiểm thử, và tôi sẽ so sánh điều đó gần như với kiểm thử đơn vị. Tôi có một loạt các kiểm thử này, và chúng cho tôi biết liệu đó có thực sự là mã tốt, mã có tuân thủ các quy tắc không, và mọi thứ đều ổn không. Trong trường hợp này, nó thậm chí còn là hạ tầng dưới dạng mã. Nó không cần phải chỉ là mã. Nó có thể là nhiều thứ khác nhau. Cũng có thể là các tệp cấu hình. Và tôi chỉ có (khó đọc), nhưng một loạt các tiêu chí mà tôi chỉ chạy mỗi lần để làm điều đó.

Nhưng, nếu bạn muốn kiểm thử xem một điểm cuối có /awesome/user không, có một kiểm thử thực sự mà chúng ta muốn chạy, đó là tôi muốn kiểm thử điểm cuối đó. Tôi không chỉ muốn kiểm tra mã. Tôi muốn nó chạy. Vì vậy, khi bạn đưa cho giám khảo một công cụ, và giám khảo trở thành một tác nhân, và nó có thể làm mọi thứ trong một môi trường biệt lập (sandbox) và thực thi mọi thứ. Nó thực sự có thể thực hiện curl. Vì vậy, bạn có thể liên kết LLM làm giám khảo với một số bộ công cụ, và sau đó bạn có thể có rất nhiều kiểm thử, trong trường hợp này, nó kết thúc là một kiểm thử đầu cuối, đúng không? Bởi vì nó không chỉ nhìn vào tệp, nó thực sự đang chạy phần đó với mọi thứ mà nó phải làm. Và sau đó tôi có thể làm điều này giống như với một commit nhất định trong kho lưu trữ của tôi, tôi muốn chạy kịch bản này với ngữ cảnh này, nó có tạo ra sự khác biệt không? Có hay không? Vì vậy, bạn đang xây dựng điều này trong khi bạn cũng đang commit ngữ cảnh vào kho lưu trữ của mình.

Và bởi vì chúng ta hiện có các kiểm thử, và nó cung cấp cho chúng ta phản hồi liệu nó có hoạt động hay không, hoặc nó đang thiếu gì, chúng ta có thể tối ưu hóa ngữ cảnh. Vì vậy, đó là loại, các bạn biết đấy, chúng ta có thể đưa điều đó vào một hành động mã hoặc một cái gì đó nói rằng, "Được rồi, hãy sửa ngữ cảnh này. Cải thiện ngữ cảnh này." Với tất cả phản hồi mà LLM đã cung cấp cho chúng ta để cải thiện điều đó. Vì vậy, các bạn biết đấy, một lần nữa, các cải tiến về mã hóa, nhưng chúng ta bắt đầu suy nghĩ nhiều hơn về việc kiểm thử phần đó nữa.

Kiểm thử Ngữ cảnh trong CI/CD

Bây giờ, một trong những phản ứng đầu tiên là một khi bạn có các kiểm thử và tối ưu hóa, liệu chúng ta có thể chạy điều này trong một hệ thống CI/CD không vì điều đó là hoàn hảo, đúng không? Đó là nơi chúng ta chạy tất cả các kiểm thử và bộ kiểm thử của chúng ta và làm điều đó. Bây giờ, có một điều hơi kỳ lạ. Nếu bạn chạy eVals, bạn chạy nó một lần, bạn chạy nó lần khác, nó có thể không cho cùng một kết quả. Hãy nhớ, các yếu tố không xác định. Vì vậy, bạn không thể nói: "Chà, hãy chạy nó một lần, và sau đó nếu nó vượt qua hay không." Bạn sẽ gặp rắc rối vì nó giống như, "À, tôi không thể gỡ lỗi điều đó." Vì vậy, hãy nghĩ về điều này giống như bạn chạy nó năm lần, và trong số năm lần, bao nhiêu lần nó thành công? Và, các bạn biết đấy, có thể trong một số trường hợp, nó đạt 100% mọi lúc, điều đó thật tuyệt. Nhưng, trong những trường hợp khác thì không. Và tùy thuộc vào cách bạn thay đổi ngữ cảnh của mình, nó sẽ ảnh hưởng đến kiểm thử nào thực sự hoạt động hay không. Cá nhân tôi thấy hữu ích khi nghĩ về điều này như ngân sách lỗi. Tôi đưa cho một bộ kiểm thử một ngân sách lỗi mà tôi thực sự quan tâm, vì vậy nó chỉ được phép thất bại tối thiểu, và các phần khác thì ổn. Vì vậy, đó là cách bạn phải nghĩ về kiểm thử ngữ cảnh. Bạn không thể luôn luôn thực hiện kiểm thử chính xác. Đó là một cách hoạt động khác.

Phân phối Ngữ cảnh (Distribute)

Được rồi. Vậy là tạo. Hy vọng bạn hiểu những gì việc kiểm thử có thể làm cho bạn. Và phân phối. Có lẽ đó cũng là điều bạn đã làm. Nếu bạn đã kiểm tra ngữ cảnh vào kho lưu trữ của mình, đúng không? Điều đó thật tuyệt, các bạn biết đấy, đột nhiên nó trở nên có sẵn, đồng nghiệp của bạn kiểm tra nó.

Chia sẻ và Tái sử dụng Ngữ cảnh

Với mức độ không ma sát, tôi có thể đẩy và chia sẻ. Tuy nhiên, chúng ta có một cơ chế khác để thực hiện mọi việc. Hãy tưởng tượng điều này giống như việc bạn có một ngữ cảnh có thể tái sử dụng mà bạn muốn sử dụng lại trên nhiều dự án, trên nhiều nhóm. Chúng ta có khái niệm về một thư viện. Vậy thì, điều gì sẽ xảy ra nếu chúng ta đóng gói các phần của ngữ cảnh, và sau đó chúng ta có thể cài đặt các phần ngữ cảnh cần thiết cho dự án này? Các hướng dẫn, giao diện người dùng. Điều đó không quan trọng. Và nếu chúng ta nâng cấp điều đó lên một bậc, làm thế nào để khám phá những package nào tồn tại? Đó chính là một registry. Đúng không?

Theo cách đó, không có gì ngạc nhiên khi bạn sẽ thấy những thứ như kỹ năng và kiểu registry của Tesla trên thị trường, nơi bạn có thể tìm thấy vô số kỹ năng. Thực tế là 99.9%, và tôi thực sự nghiêm túc về điều này, các kỹ năng đều là rác rưởi. Nhưng thật tốt khi học hỏi từ người khác để xem họ đang làm gì. Tuy nhiên, hiếm có kỹ năng nào, nếu bạn chạy bất kỳ bộ eVals nào trên đó, thực sự đạt đến một tiêu chuẩn chất lượng. Điều đó có thể sẽ cải thiện. Nhưng cũng có một xu hướng là nhiều kỹ năng và các mảnh ghép, mọi người thực sự muốn đưa chúng vào registry của riêng họ. Tôi sẽ quay lại vấn đề này sau.

Định dạng gói kỹ năng và Quản lý phụ thuộc

Vì vậy, bạn bắt đầu hình dung ra ý chính, một kỹ năng không chỉ chứa ngữ cảnh, nó có thể chứa các tập lệnh, tài liệu, và nhiều thứ khác. Vậy, đây có phải là loại package format không? Có lẽ, plugin giờ đây cũng có thể chứa MCP, nhưng bạn thấy có một tiêu chuẩn đang hình thành. Các kỹ năng bỗng nhiên, khi chúng xuất hiện, tất cả các tác nhân mã hóa (coding agents) đều nói, "Chúng tôi đang hỗ trợ điều này gần như là một package format để mọi người phân phối ngữ cảnh của họ."

Và khi tôi có một mảnh ngữ cảnh, tôi có các dependency (phụ thuộc). Tôi xin lỗi, nhưng với ngữ cảnh chúng ta cũng sẽ gặp vấn đề "dependency hell" (địa ngục phụ thuộc). Đúng không? Tôi sẽ tải cái này cho giao diện người dùng, và có thể nó đang xung đột với những gì có trong package ngữ cảnh của React. Và bạn bắt đầu phải giải quyết vấn đề đó. Vì vậy, bạn bắt đầu thấy các package cũng phản ánh các phiên bản thư viện, phiên bản mã nguồn, phiên bản ngữ cảnh của bạn, và cũng kéo những thứ đó vào.

Bảo mật và SBOM của AI

Tất nhiên, khi chúng ta có package và mọi người đang xuất bản nội dung trong registry, chúng ta cần bảo mật. Đúng không? Open Claw. Cảm ơn vì điều đó. Mọi người đột nhiên nhận ra rằng chúng ta cần những thứ an toàn hơn bởi vì chúng ta có thể chạy những thứ trên máy tính xách tay của mình mà không an toàn và đến từ những người lạ. Đúng không? Vì vậy, Snyk có một cách để quét ngữ cảnh, đúng không? Nó đang xử lý một số thông tin xác thực. Nó đang tiết lộ một số phần của bên thứ ba. Vì vậy, bạn bắt đầu thấy các trình quét trên ngữ cảnh nữa.

Và khi bạn nghĩ về bảo mật, ai thực sự đã xây dựng kỹ năng này? Nó được xây dựng như thế nào? Với mô hình nào? Vì vậy, tất cả những gì chúng ta học được có thể với đóng gói, như SBOM, là loại AI SBOM, giống như package của ngữ cảnh mà chúng ta đưa vào. Vì vậy, bạn vẫn thấy trên lộ trình, đúng không? Bạn tạo, đánh giá, phân phối.

Khả năng quan sát và Vòng lặp phản hồi

Hãy chuyển sang khả năng quan sát. Khi bạn tạo thư viện của các kỹ năng và ngữ cảnh cho người khác, và tôi không có ý là sao chép và dán qua Slack hay gì đó. Nhưng khi bạn thực sự muốn duy trì điều này như một thứ mà người khác có thể sử dụng, tương tự như một thư viện — khi họ bắt đầu sử dụng nó, làm thế nào để bạn nhận được phản hồi xem liệu nó có còn hoạt động không?

Một nơi tuyệt vời để nhận phản hồi thực sự là bằng cách xem nhật ký Agent. Vì vậy, hãy tưởng tượng lập trình viên đang mã hóa trên dự án, và Tác nhân không làm điều họ muốn. Họ có thể đưa điều này vào ngữ cảnh của họ, điều này thật tuyệt, đúng không? Được thôi, hãy để tôi thực hiện TDD gần như thế, bạn biết đấy, tôi gặp một vấn đề. Đó không phải là TDD, nhưng bạn hiểu ý tôi. Hoặc điều gì sẽ xảy ra nếu chúng ta ở cấp độ nhóm hoặc tổ chức xem xét nhật ký mỗi khi một Tác nhân nói, "Chúng ta thiếu phần này." Và chúng ta đưa điều đó lên và nói, "Nếu mọi người đều thiếu phần này, chúng ta nên tạo ngữ cảnh cho nó." Và sau đó chúng ta phân phối ngữ cảnh cho mọi người, và đột nhiên tác động của việc cải thiện là cho tất cả mọi người. May mắn thay, giống như Agent và D, hiện có các tiêu chuẩn đang hình thành cho nhật ký. Vì vậy, chúng ta có thể đọc từ nhật ký, và đó là một phần của kênh phản hồi của chúng ta để xem liệu Tác nhân có thực sự đang sử dụng hay thiếu một số ngữ cảnh nào đó không.

Bất kỳ phản hồi nào bạn nhận được trên một PR không hoàn chỉnh, đó là phản hồi về ngữ cảnh của bạn bởi vì PR đó được tạo với những phần ngữ cảnh nhất định. Nếu bạn nói điều này không đúng, bạn có thể tiếp tục tranh luận trên PR, hoặc bạn có thể nói, "Hãy cải thiện ngữ cảnh." Để lần lặp tiếp theo thực sự cải thiện, và bạn không gặp lại cùng một vấn đề.

Điều gì sẽ xảy ra khi chạy mã nguồn trong môi trường sản xuất được tạo ra từ ngữ cảnh? Và điều đó không đúng bởi vì vâng, chúng ta thực hiện đánh giá PR của mình và chúng ta nói đồng ý hoặc không đồng ý và chúng ta đưa ra phản hồi, nhưng phản hồi thực tế cũng nằm trong môi trường sản xuất khi nó đang chạy. Vì vậy, đây là một công cụ thực sự instrument (can thiệp) vào mã nguồn của bạn, đẩy nó ra, nó gần giống như một wrapper, nó đẩy nó ra môi trường sản xuất. Khi nó thất bại, nó nói, "Những phần mã nguồn này đã được thay đổi và đã thất bại. Này, trong trường hợp này, input, output, nó đã làm sai điều gì đó. Chúng ta có thể tạo một test case (trường hợp kiểm thử) cho điều này không? Để lần sau chúng ta không gặp lại vấn đề này trong môi trường sản xuất?" Vòng lặp phản hồi (Feedback loop).

Bảo mật tác nhân: Sandbox và Bộ lọc ngữ cảnh

Bây giờ, tất cả những điều này đều khá tầm thường như thiếu các mảnh ngữ cảnh hoặc cải tiến. Nhưng nếu bạn chạy Tác nhân và việc quét tương đương có thể, bạn biết đấy, trong CICD là bạn cần đảm bảo khi nó đang chạy trong môi trường sản xuất, nó có đang làm những điều kỳ lạ không? Vì vậy, chúng ta cần một cách để xem xét điều đó.

Bây giờ, tôi đã tự mình thử nghiệm với việc sandboxing tác nhân và nó rất tháo vát trong việc tìm kiếm mọi thứ. Tôi thích, được thôi, bạn biết đấy, chạy thứ này, cố gắng tìm ra bất kỳ điều gì hữu ích để thoát khỏi hệ thống. Và được thôi, nó sử dụng các biến môi trường của tôi. Được thôi, ngu ngốc. Hãy để tôi loại bỏ secret. Hãy để tôi xem các tệp bộ nhớ của bạn. Vì vậy, bạn thực sự phải đảm bảo rằng bất cứ điều gì nó đang làm, bạn có thể có một cách để theo dõi điều này. Và tôi xin lỗi một lần nữa về slide này, nhưng ý chính là chúng ta có thể có một môi trường biệt lập (sandbox) nơi Tác nhân chạy bên trong. Nhưng Tác nhân mã nguồn của bạn theo mặc định mà không có bất kỳ hạn chế nào sẽ tải agent.md của bạn, bạn tải skill.md của bạn. Không có gì ngăn chặn điều đó. Vì vậy, nếu bạn tải xuống thứ này, nó sẽ được tải ngay lập tức. Vì vậy, bạn không thể lọc điều đó bằng môi trường biệt lập. Bạn cần có một cách khác. Tôi gọi đó là context filter. Hãy nghĩ về điều này như một tường lửa ứng dụng web (web application firewall) chỉ lọc ra bất kỳ pattern (mẫu hình) nào hoặc tấn công prompt (prompt injections) hoặc những thứ đến trực tiếp trong phần đó.

Và nếu bạn xét điều đó, ở đây cũng có rất nhiều cuộc thảo luận về harness engineering. Harness engineering tự nó cũng có loại khả năng quan sát đầy đủ này, xem xét nhật ký, xem xét dấu vết, xem xét phản hồi. Vì vậy, nó khá hữu ích cho việc đào tạo các mảnh ghép, nhưng cũng hữu ích không kém cho việc chạy các mảnh ghép của riêng bạn.

Vòng lặp cải tiến ngữ cảnh và Quy mô Tổ chức

Đó là những phần dành cho tôi hôm nay. Tôi muốn nói rằng đối với nhiều người, có việc tạo ngữ cảnh, kiểm tra ngữ cảnh. Hãy nghĩ về điều này như vòng lặp công cụ (tool loop) viết thư viện của bạn. Và sau đó khi bạn đưa điều này vào doanh nghiệp, có một vòng lặp tổ chức. Này, tôi đã tạo một thư viện, người khác đang sử dụng nó. Tôi đang xem xét bất cứ điều gì hữu ích, liệu nó có còn hoạt động không, liệu nó có còn hoạt động cho tất cả các phần khác không. Vì vậy, đó là loại cải tiến gần như mô hình CICD của Sonar cho ngữ cảnh.

Và sau đó bạn hiện có thể đang làm rất nhiều ở mô hình cá nhân đơn độc, bạn đang cải thiện, bạn đang trau dồi, tạo ra markdown của riêng bạn. Điều gì sẽ xảy ra nếu bạn bắt đầu làm điều này nhiều hơn với nhóm của mình? Biến điều đó thành một phản xạ. Nếu thiếu, hãy thêm một số ngữ cảnh. Điều gì sẽ xảy ra nếu bạn đưa điều đó ra cho một nhóm các nhóm và bạn bắt đầu có một vòng quay liên tục (flywheel), bạn biết đấy, nếu bạn sửa nó ở đây, nhóm khác có thể sử dụng lại nó và đó là cách mở rộng mọi thứ trong tổ chức.

Và vì vậy, có rất nhiều cuộc nói chuyện về Mô hình Ngôn ngữ Lớn (LLM) và tác nhân mã hóa (coding agents) và tôi đều yêu thích chúng, nhưng cách tôi nhìn nhận chúng là chúng chỉ là động cơ. Nếu bạn cung cấp cho động cơ nhiên liệu sai, đó là ngữ cảnh, chúng sẽ không hoạt động tốt. Và bạn không thể làm gì trên các Mô hình Ngôn ngữ Lớn, ít nhất là không phải tôi, đúng không? Tôi chỉ đang sử dụng tác nhân mã hóa, tôi đang sử dụng bất cứ thứ gì họ cung cấp cho tôi, nhưng tôi có thể tối ưu hóa ngữ cảnh của mình và đó tôi nghĩ là thông điệp – thực hiện điều này một cách có kỹ thuật hơn là chỉ sao chép và dán mọi thứ và hy vọng điều tốt đẹp nhất.

Nếu bạn thích buổi nói chuyện này, hãy kết nối trên LinkedIn để xem các slide. Hãy cho tôi một số phản hồi, tốt và xấu. Nếu bạn muốn thử Tessel, nơi chúng tôi triển khai một số phần của điều này, hãy thử. Và nếu bạn cũng quan tâm đến một hội nghị khác, tôi biết, bạn không bao giờ có đủ hội nghị, hãy ghé thăm AI DevCon, nơi tôi phụ trách nội dung, tại London vào ngày 1 và 2 tháng Sáu. Và đó là tất cả. Tôi có thể nhận một vài câu hỏi.

Hỏi & Đáp: Ngữ cảnh "Độc đáo" và Hệ thống đánh giá tự động

[tiếng vỗ tay] Có câu hỏi nào không? Chắc chắn rồi. Vì vậy, tôi tự hỏi liệu bạn có bất kỳ suy nghĩ nào về các hình thức ngữ cảnh "độc đáo" hơn như tôi không biết, những cái truyền thống. Ví dụ, một trong những điều tôi đang làm là một hệ thống tự động để scoping architectural problems (phác thảo các vấn đề kiến trúc) và cố gắng tạo ra các định nghĩa cứng nhắc cho chúng để bạn có thể cung cấp điều đó cho Tác nhân và, bạn biết đấy, tạo ra các mục tiêu thực tế. test. Hay. Vâng. Micrô.

Và một trong những điều tôi đã thử nghiệm là khả năng tạo sự nhất quán như một dạng ngữ cảnh hoặc một dạng eVals. Vì vậy, với định nghĩa rất lỏng lẻo này về kế hoạch là gì, nếu bạn có thể đặt điều đó nếu bạn thử hệ thống Tác nhân đó, biến điều đó thành một định nghĩa thực sự rõ ràng, và bạn chỉ cần thực hiện điều đó song song, bạn nhận được định nghĩa rõ ràng giống nhau thường xuyên như thế nào? Và nếu chúng ở khắp mọi nơi, thì định nghĩa ban đầu quá tệ, bạn cần quay lại các nguyên tắc cơ bản hoặc đến một kiến trúc sư. Nhưng nếu tất cả chúng đều giống nhau, thì đó có lẽ là một định nghĩa khá tốt và bạn có thể tiếp tục với quy trình downstream. Vì vậy, tôi nghĩ đó là ngoài mã nguồn và eVals điển hình, có bất kỳ nguồn ngữ cảnh nào khác để tạo ngữ cảnh mà bạn nghĩ là hữu ích không?

Tôi không có thể có một câu trả lời cụ thể cho trường hợp "độc đáo" của bạn, nhưng tôi muốn nói rằng có lẽ phần mà mọi người đang đánh giá thấp là một khi bạn, bạn biết đấy, bạn nghĩ bạn sẽ tiết kiệm thời gian bằng cách thực sự viết ngữ cảnh của mình thay vì tất cả mã nguồn của mình, nhưng nếu bạn thực hiện điều này một cách nghiêm ngặt, bạn sẽ dành thời gian để viết đúng eVals. Đúng không. Và đó là loại, bạn biết đấy, rất nhiều công việc để kiểu vì bây giờ bạn không chỉ có một lời nhắc mà bạn đang cố gắng làm cho đúng. Đó là tất cả các lời nhắc của eVals và điều đó giống như nếu mọi người làm gần như một, giống như những người tiên tiến hơn, họ gần như có quy trình riêng và họ xây dựng quy trình riêng của họ trên workflow để xây dựng đúng eVals trên trường hợp kinh doanh của bạn nữa. Vâng. Câu hỏi hay. Cảm ơn bạn.

Có câu hỏi nào khác không? Nếu không, tôi sẽ ở quanh đây. Hãy chào hỏi. Tôi cũng sẽ có mặt tại Tessel booth. Cảm ơn bạn rất nhiều và tôi sẽ nhường chỗ cho diễn giả tiếp theo. Cảm ơn bạn.

[âm nhạc]