Automating Large Scale Refactors with Parallel Agents - Robert Brennan, OpenHands

• OpenHands tập trung vào việc tự động hóa các công việc kỹ thuật phần mềm quy mô lớn, đặc biệt là các tác vụ liên quan đến nợ kỹ thuật, bảo trì và hiện đại hóa mã nguồn, thông qua điều phối tác nhân.
• Sự phát triển của AI trong kỹ thuật phần mềm đã tiến hóa từ sinh mã không nhận biết ngữ cảnh đến tác nhân lập trình tự trị, và hiện tại là điều phối tác nhân để xử lý các nhiệm vụ quá lớn cho một tác nhân đơn lẻ.
• Mặc dù tác nhân tự động hóa công việc, vai trò của con người vẫn rất quan trọng trong việc phân rã nhiệm vụ, cung cấp trực giác, đánh giá trung gian và xác định mục tiêu hoàn thành cho các quy trình điều phối phức tạp.

• Điều phối tác nhân (Agent Orchestration): Là phương pháp để nhiều tác nhân AI làm việc song song, đôi khi giao tiếp với nhau, hoặc thậm chí tạo ra các tác nhân con để giải quyết các tác vụ kỹ thuật phần mềm quy mô lớn và phức tạp.
• Lịch sử tiến hóa của AI trong kỹ thuật phần mềm: Từ các đoạn mã không nhận biết ngữ cảnh, đến sinh mã nhận biết ngữ cảnh (ví dụ: GitHub Copilot), sau đó là tác nhân lập trình tự trị (Devin, OpenHands), và cuối cùng là điều phối tác nhân.
• Các trường hợp sử dụng chính: Gồm bảo trì mã nguồn (cập nhật phần phụ thuộc, vá lỗ hổng bảo mật như CVE), hiện đại hóa mã nguồn (chuyển đổi monolith sang microservices, di chuyển framework lớn), và xử lý các mẫu lỗi dữ liệu.
• Hạn chế của tác nhân đơn lẻ: Chúng có ngữ cảnh hạn chế, thiếu trực giác về cơ sở mã, và có thể tích lũy lỗi nhanh chóng khi gặp các vấn đề phức tạp, đòi hỏi sự can thiệp và kiểm tra của con người.
• Vai trò thiết yếu của con người: Cần thiết trong việc phân rã các nhiệm vụ lớn thành các phần nhỏ hơn, cung cấp định hướng và trực giác, thực hiện xem xét trung gian và phê duyệt các bước tiến của tác nhân.
• Ưu điểm của tác nhân dựa trên đám mây: Cung cấp khả năng mở rộng (chạy nhiều tác nhân song song) và an toàn hơn (môi trường biệt lập/containerized) so với tác nhân chạy cục bộ.
• Mức độ chấp nhận: Hiện tại, chỉ một tỷ lệ nhỏ các kỹ sư hàng đầu đang áp dụng điều phối tác nhân, đạt được những bước nhảy vọt đáng kể về năng suất trong việc giải quyết các tồn đọng nợ kỹ thuật khổng lồ.

• agent — tác nhân
• agent orchestration — điều phối tác nhân
• technical debt — nợ kỹ thuật
• code modernization — hiện đại hóa mã nguồn
• autonomous coding agents — tác nhân lập trình tự trị
• Large Language Models (LLM) — Mô hình Ngôn ngữ Lớn
• Integrated Development Environment (IDE) — môi trường phát triển tích hợp
• sandbox — môi trường biệt lập
• microservices — vi dịch vụ
• task decomposition — phân rã nhiệm vụ

Giới thiệu về OpenHands và Điều phối Tác nhân

Cảm ơn quý vị đã tham gia buổi nói chuyện về "Tự động hóa các đợt xử lý hàng loạt lớn với agent thực của chúng tôi". Tôi rất vui được chia sẻ với các bạn hôm nay về những gì chúng tôi đang làm với OpenHands để thực sự tự động hóa các công việc kỹ thuật phần mềm quy mô lớn. Rất nhiều công việc liên quan đến nợ kỹ thuật, bảo trì mã nguồn, hiện đại hóa mã nguồn. Đây là những tác vụ có khả năng tự động hóa rất cao. Bạn có thể giao chúng cho agent, nhưng chúng thường quá lớn để một agent xử lý chỉ trong một lần duy nhất. Vì vậy, điều này đòi hỏi rất nhiều điều mà chúng tôi gọi là điều phối tác nhân (agent orchestration). Chúng tôi sẽ nói một chút về cách chúng tôi thực hiện điều đó với OpenHands và cả những cách tổng quát hơn.

Giới thiệu về diễn giả và Nguồn gốc của OpenHands

Tôi xin giới thiệu một chút về bản thân: tên tôi là Eric Brennan, tôi là người đồng sáng lập và CEO của OpenHands. Nền tảng của tôi là về công cụ phát triển. Tôi đã làm việc trong lĩnh vực DevTools mã nguồn mở hơn một thập kỷ. Tôi cũng đã làm việc trong lĩnh vực xử lý ngôn ngữ tự nhiên trong khoảng thời gian tương tự. Trong vài năm qua, tôi thực sự vui mừng khi thấy hai lĩnh vực này đột nhiên hội tụ. Tôi vẫn rất giỏi viết mã và rất hào hứng khi làm việc trong lĩnh vực này.

OpenHands là một tác nhân lập trình được cấp phép MIT. OpenHands bắt đầu được phát triển khoảng một năm rưỡi trước. Khi Devin ra mắt video về DevTools của họ, mô tả một tác nhân kỹ thuật phần mềm hoàn chỉnh, người đồng sáng lập của tôi và tôi đã thấy điều đó. Tôi cực kỳ hào hứng về những gì có thể thực hiện được với tương lai của công việc kỹ thuật phần mềm. Tôi nhận ra rằng điều đó không nên xảy ra trong một môi trường "hộp đen" (like box). Nếu công việc của chúng ta sẽ thay đổi, chúng ta muốn sự thay đổi đó là nơi bạn tìm thấy phần mềm trong toàn bộ cộng đồng. Chúng ta muốn có tiếng nói trong sự thay đổi đó. Vì vậy, chúng tôi đã bắt đầu OpenHands như một cách để cộng đồng cùng nhau định hướng tương lai của kỹ thuật phần mềm trong một thế giới được hỗ trợ bởi AI.

Hy vọng rằng, không gây tranh cãi khi nói rằng phát triển phần mềm đang thay đổi. Tôi biết công việc của mình đã thay đổi rất nhiều trong một năm rưỡi qua. Tôi sẽ nói rằng bây giờ, hầu như mọi dòng mã tôi viết đều thông qua một tác nhân. Thay vì tự mình mở IDE và bắt đầu viết mã, tôi giờ đây yêu cầu một tác nhân làm công việc đó cho tôi. Tôi vẫn thực hiện rất nhiều tư duy phản biện. Phần lớn tư duy của công việc không thay đổi, nhưng hình thức công việc thực tế đã thay đổi khá nhiều.

Tuy nhiên, điều tôi muốn nhấn mạnh là nó vẫn đang thay đổi. Chúng ta vẫn chỉ ở giai đoạn đầu của sự thay đổi này. Chúng ta vẫn chưa nhận ra tất cả những tác động mà các mô hình dữ liệu của chúng ta đã mang lại cho công việc và sẽ tiếp tục mang lại khi chúng được cải thiện. Tôi sẽ nói rằng ngay cả khi bạn giữ nguyên các Mô hình Ngôn ngữ Lớn (LLM) như hiện tại và chúng không tốt hơn nữa, công việc kỹ thuật phần mềm vẫn sẽ thay đổi rất đáng kể trong hai đến ba năm tới khi chúng ta tìm ra cách để vận hành công nghệ này. Tôi vẫn nghe thấy rất nhiều rào cản tâm lý và tổ chức trong việc áp dụng các Mô hình Ngôn ngữ Lớn vào kỹ thuật phần mềm. Chúng tôi đang thấy nhiều rào cản đó biến mất theo thời gian.

Lịch sử phát triển của AI trong Kỹ thuật Phần mềm

Để nhìn lại lịch sử, cách chúng ta đến được đây, tôi sẽ nói rằng mọi thứ bắt đầu với cái mà tôi gọi là đoạn mã không nhận biết ngữ cảnh (context-unaware code snippets). Một số Mô hình Ngôn ngữ Lớn đầu tiên đã chứng tỏ rất tốt trong việc viết các đoạn mã, đặc biệt là những thứ chúng đã thấy lặp đi lặp lại. Bạn có thể yêu cầu nó viết bubble sort. Bạn có thể yêu cầu nó viết các thuật toán nhỏ, cách truy cập một cơ sở dữ liệu SQL, những thứ tương tự. Nó có thể sinh mã một chút. Nó có thể hiểu logic ở một mức độ nào đó. Nhưng điều này hoàn toàn không nhận biết ngữ cảnh. Nó chỉ đơn thuần đưa mã vào cửa sổ trò chuyện mà bạn yêu cầu. Nó không hề biết bạn đang làm việc trên dự án nào hoặc ngữ cảnh liên quan.

Ngay sau đó, chúng ta có sinh mã nhận biết ngữ cảnh (context-aware code generation). GitHub Copilot rõ ràng là ví dụ tốt nhất ở đây. Nó thực sự nằm trong môi trường phát triển tích hợp (IDE) của bạn, nó có thể thấy bạn đang gõ gì, mã bạn đang làm việc là gì. Nó có thể sinh mã cụ thể cho cơ sở mã của bạn, dựa trên việc tham chiếu tên biến cục bộ, tham chiếu tên bảng trong cơ sở dữ liệu của bạn, một cải tiến lớn cho năng suất của chúng ta. Thay vì sao chép và dán qua lại giữa cửa sổ ChatGPT và IDE của bạn, giờ đây bạn có thể thấy robot nhỏ có thể nhìn thấy bên trong cơ sở mã của bạn, nó thực sự có thể sinh mã phù hợp cho cơ sở mã của bạn.

Và sau đó, tôi nghĩ bước nhảy vọt lớn mà chúng ta đã có vào đầu năm 2024 với Devin, và sau đó là OpenDevin và OpenHands. Đây là lúc chúng ta lần đầu tiên bắt đầu thấy các tác nhân lập trình tự trị (autonomous coding agents). Đây là khi AI không chỉ viết mã, mà nó còn có thể chạy mã trong một vòng lặp. Nó có thể Google một thông báo lỗi xuất hiện, tìm một câu trả lời trên Stack Overflow, và nó có thể áp dụng điều đó vào mã. Nó có thể thêm một câu lệnh debug vào mã, chạy nó và xem điều gì xảy ra. Về cơ bản, nó tự động hóa toàn bộ vòng lặp phát triển nội bộ. Đây là một bước tiến lớn. Bạn có thể thấy robot nhỏ có thêm cánh tay trong bức ảnh này.

Đây là một bước nhảy vọt lớn. Ít nhất là nó có thể không cần phải đọc một vài tấn tiếng Anh, giao nó cho một tác nhân và để nó thực hiện nhiệm vụ này cho đến khi nó có thứ gì đó thực sự hoạt động, chạy, kiểm thử. Và sau đó, điều chúng ta đang thấy bây giờ là các cuộc họp song song, chúng tôi gọi là điều phối tác nhân (agent orchestration). Đó là việc tìm cách để nhiều tác nhân làm việc song song, đôi khi nói chuyện với nhau, đôi khi tạo ra các tác nhân mới bên dưới. Bạn có thể tự tạo tác nhân. Tôi sẽ nói rằng đây là một loại công nghệ tiên tiến. Điều gì có thể xảy ra? Mọi người mới bắt đầu thử nghiệm với điều này. Họ mới bắt đầu thấy thành công với điều này ở quy mô lớn. Nhưng có một số tác vụ thực sự tốt rất phù hợp với quy trình làm việc này. Và nó có tiềm năng thực sự để giải quyết một lượng lớn dữ liệu trong mọi loại công ty phần mềm khác nhau.

Bối cảnh thị trường và Mức độ chấp nhận tác nhân

Một chút về bối cảnh thị trường ở đây. Một lần nữa, bạn có thể thấy sự tiến hóa tương tự từ trái sang phải, từ nơi chúng ta bắt đầu với các plugin IDE, ví dụ Copilot bên trong các IDE hiện có của chúng ta. Chúng ta đã có các IDE được hỗ trợ bởi AI với công nghệ AI tích hợp. Tôi sẽ nói rằng bạn đang gặp gỡ các nhà phát triển đang áp dụng tác nhân cục bộ, có thể chạy Claude Code cục bộ cho một hoặc hai việc, có thể một số tác vụ nhỏ.

Tuy nhiên, những người dùng sớm (early adopters) đang bắt đầu xem xét các tác nhân dựa trên đám mây, các tác nhân có môi trường biệt lập (sandbox) riêng của chúng, chạy trên đám mây. Điều này cho phép những người dùng sớm đó chạy bao nhiêu tác nhân tùy thích song song. Họ cũng sẽ chạy những tác nhân đó an toàn hơn so với việc chúng chạy trên máy tính xách tay cục bộ của họ, đúng không? Nếu nó chạy trên máy tính xách tay cục bộ của bạn, không có gì ngăn cản tác nhân thực hiện lệnh rm -rf /, cố gắng xóa mọi thứ trong thư mục của bạn, hoặc bất cứ điều gì nó có thể làm, cài đặt một số phần mềm lạ. Trong khi đó, bạn có môi trường vùng chứa (containerized environment) riêng của mình ở đâu đó trên đám mây. Bạn có thể chạy an toàn hơn một chút khi biết rằng điều tệ nhất nó có thể làm là phá hỏng môi trường của chính nó. Bạn không cần phải ngồi đó, trông chừng nó, nhấn phím trắng mỗi khi nó muốn bắt đầu một lệnh. Vì vậy, những môi trường dựa trên đám mây đó trông có vẻ dễ mở rộng hơn, chúng an toàn hơn.

Và sau đó, tôi sẽ nói ở phía ngoài cùng bên phải, điều chúng ta thực sự đang thấy là 1% những người dùng sớm hàng đầu đang tìm kiếm và thử nghiệm điều phối tác nhân (orchestration). Ý tưởng này không chỉ có các tác nhân chạy trên đám mây, mà chúng còn nói chuyện với nhau. Bạn đang điều phối những tác nhân đó trên một lộ trình lớn hơn. Có thể những tác nhân đó đang tạo ra một số tác nhân bên trong đám mây có môi trường biệt lập riêng của chúng. Có một số điều thực sự thú vị đang xảy ra ở đó. Tôi sẽ nói với OpenHands, chúng tôi thường bắt đầu với tác nhân đám mây. Chúng tôi đã quay lại một chút, chúng tôi có các giao diện dòng lệnh (CLI) cục bộ và mã đám mây cục bộ để đáp ứng nhu cầu của các nhà phát triển ngày nay. Những loại trải nghiệm này thoải mái hơn nhiều cho các nhà phát triển. Chúng ta đã sử dụng IDE trong nhiều thập kỷ. Nó đã trở nên tốt hơn hàng triệu lần với GitHub Copilot. Tôi sẽ nói rằng những trải nghiệm này là đúng đắn và rất quan trọng đối với các nhà phát triển.

Cảm giác rất lạ khi giao một nhiệm vụ cho một tác nhân hoặc một đội tác nhân và để chúng làm việc cho bạn. Đối với tôi, ít nhất, cảm giác giống như bước nhảy vọt mà tôi đã thực hiện khi chuyển từ thành viên đóng góp cá nhân (IC) sang quản lý là cảm giác khi chuyển từ việc tự mình viết mã sang giao mã đó cho các tác nhân. Đó là một cách làm việc rất, rất khác biệt. Tôi nghĩ rằng một trong những nhà phát triển đã rất chậm trong việc chấp nhận điều này. Một lần nữa, cả 1% kỹ sư hàng đầu mà chúng tôi đã thấy chấp nhận những thứ ở phía bên phải của bối cảnh này, họ đã đạt được những bước nhảy vọt lớn về năng suất và xử lý được các tồn đọng nợ kỹ thuật khổng lồ mà các nhóm khác không thể giải quyết được.

Các trường hợp sử dụng Điều phối Tác nhân

Một số ví dụ về nơi bạn muốn sử dụng điều phối tác nhân thay vì một tác nhân đơn lẻ. Thông thường, đây là các tác vụ rất dễ lặp lại và rất dễ tự động hóa. Vì vậy, một số ví dụ là những thứ như các tác vụ bảo trì mã nguồn cơ bản. Mọi cơ sở mã đều có một lượng công việc nhất định để duy trì hoạt động. Để giữ cho các phần phụ thuộc (dependencies) luôn cập nhật, để đảm bảo rằng mọi lỗ hổng bảo mật (vulnerability) đều được giải quyết. Chúng tôi muốn tìm, chẳng hạn, một công ty đang sử dụng OpenHands để đọc CVE trên toàn bộ cơ sở mã của họ. Họ có hàng chục nghìn nhà phát triển, hàng chục nghìn kho lưu trữ (repositories). Về cơ bản, mỗi khi một lỗ hổng bảo mật mới được công bố trong một dự án mã nguồn mở, họ phải đi qua toàn bộ cơ sở mã của họ, tìm ra repo nào dễ bị tổn thương, gửi pull request tới cơ sở mã đó để thực sự giải quyết CVE, cập nhật bất kỳ phần phụ thuộc nào, sửa lỗi thay đổi API gây phá vỡ. Họ đã thấy sự cải thiện gấp 30 lần về thời gian giải quyết cho các CVE này bằng cách thực hiện điều phối tác nhân (orchestration) ở quy mô lớn. Về cơ bản, họ đã thiết lập hệ thống mà mỗi khi một CVE được công bố, vào một ngày đẹp trời, họ sẽ khởi động một phiên OpenHands để quét repo đó tìm lỗ hổng bảo mật, thực hiện bất kỳ thay đổi mã nào cần thiết, và nó sẽ tạo ra pull request và tất cả những gì nhóm downstream phải làm là hợp nhất các thay đổi đó. Bạn cũng có thể làm điều này cho tài liệu và ghi chú phát hành đã lỗi thời.

Có rất nhiều thách thức hiện đại hóa mã nguồn mà các công ty phải đối mặt. Chẳng hạn, bạn có thể muốn thêm chú thích (annotations) vào cơ sở mã Python của mình nếu bạn đang làm việc với Python 3. Bạn có thể muốn tách hệ thống monolith Java của mình thành các vi dịch vụ. Đây là những loại tác vụ vẫn sẽ đòi hỏi nhiều tư duy của một kỹ sư. Bạn không thể chỉ đơn thuần viết một dòng mã và nói "tái cấu trúc mô hình của tôi thành các vi dịch vụ". Đó vẫn là một công việc phát triển (growth work) rất lớn, đúng không? Vì vậy, nó giống như sao chép và dán rất nhiều mã xung quanh. Vì vậy, nếu bạn nghĩ chúng ta đang tạo ra các tác nhân cùng nhau, chúng có thể làm điều này. Rất nhiều di chuyển (migrations) cũng vậy, chẳng hạn di chuyển từ phiên bản Java cũ sang Java mới hơn. Chúng tôi đang làm việc với một khách hàng để di chuyển từ Java 2 sang Java 3. Chúng tôi đã sử dụng OpenHands để di chuyển toàn bộ frontend của chúng tôi từ React, từ Redux sang Zustand. Vì vậy, bạn có thể thực hiện những di chuyển rất lớn này. Một lần nữa, trong cả hai trường hợp, công việc phát triển rất lớn vẫn đòi hỏi nhiều tư duy để tạo ra nhiều dữ liệu điều phối tác nhân khác nhau.

Và sau đó là rất nhiều yếu tố trong việc phát hiện mã mới, loại bỏ nó, bạn biết đấy, chúng tôi đã có thể giúp một khách hàng đang sử dụng RSCK để quét nhật ký dữ liệu (data logs). Mỗi khi bạn thấy một mẫu lỗi (error pattern), hãy đi vào cơ sở mã và thêm xử lý lỗi (error handling), sửa bất kỳ vấn đề nào nó đang gây ra. Vì vậy, rất nhiều thứ quá lớn để một tác nhân duy nhất chỉ xử lý trong một lần, RSCK hoặc điều khiển âm thanh không phải là những câu lệnh tốt để hỏi, nếu họ có thể theo dõi sự suy nghĩ của bạn về việc điều phối chúng.

Hạn chế của Tác nhân đơn lẻ: Vấn đề công nghệ và con người

Một chút về lý do tại sao những tác vụ này không phải là một lần duy nhất giải quyết được: một số là vấn đề về cấu trúc (topological problems), một số là vấn đề tâm lý con người. Về mặt công nghệ, bạn có một lượng ngữ cảnh hạn chế mà bạn có thể cung cấp cho tác nhân. Vì vậy, các tác vụ chạy cực kỳ dài, các tác vụ trải rộng trên một cơ sở mã rất lớn. Thông thường, bạn sẽ không có đủ không gian, bạn không cần phải nén (compact) ngữ cảnh đó. Tôi thực sự sẽ đi đến điểm mà tác nhân có thể bị lạc.

Thách thức của Tác nhân và Vai trò của Trực giác Con người

Chúng ta đều thấy vấn đề dễ nhất. Tôi thực sự muốn kiểm tra một số tập hợp này để vượt qua và sau đó tôi có thể nói: "Được rồi, tôi đã di chuyển ba trong số một trăm service của bạn. Tôi cần thuê thêm một vài người trong số sáu người để làm phần còn lại." Các tác nhân, do thiếu kiến thức trong cơ sở mã của bạn, chúng không có cùng trực giác mà bạn có đối với vấn đề. Và các lỗi tích tụ khi bạn đi sâu vào những "lãnh thổ" thực sự khó hiểu với tác nhân. Một lỗi nhỏ ở ban đầu sẽ, theo thời gian, khiến các tác nhân lặp lại lỗi đó liên tục cho mỗi tập hợp mà nó xử lý nhanh chóng.

Và về phía con người, chúng ta có trực giác tích lũy mà chúng ta không thể truyền đạt. Bạn muốn đánh giá mô hình của mình dưới dạng các microservice. Bạn có thể có một mô hình trong đầu về cách nó sẽ hoạt động. Bạn chỉ cần nói với tác nhân là chuyển đổi tất cả thành microservice. Tác nhân sẽ chỉ thực hiện một cách mò mẫm dựa trên dữ liệu đã qua mà không có sự hiểu biết thực sự về cơ sở mã của bạn.

Phân rã Nhiệm vụ và Đánh giá Trung gian

Chúng tôi gặp khó khăn trong việc phân tách nhiệm vụ cho các tác nhân và hiểu được tác nhân có thể thực hiện được gì trong một lần. Ngoài ra, bạn thực sự cần sự xem xét trung gian, kiểm tra trung gian từ con người khi các tác nhân đang làm việc. Chúng tôi sẽ nói chi tiết hơn về điều đó sau. Một lần nữa, đây không phải là thứ mà bạn chỉ cần ra lệnh cho tác nhân làm và mong đợi kết quả cuối cùng. Bạn phải phê duyệt mọi thứ khi tác nhân tiến hành.

Xác định "Hoàn thành" và Điều phối Tác nhân

Và sau đó là việc không có một giai đoạn bổ sung nào cho điều đó. Tôi nghĩ rằng nếu bạn không thực sự biết "kết thúc" trông như thế nào đối với dự án này, thì rất khó để hướng dẫn tác nhân. Tất cả các loại nhiệm vụ orchestration này sẽ rất rõ ràng rằng chúng tôi không mong đợi mọi nhà phát triển đều thực hiện orchestration tác nhân. Chúng tôi nghĩ rằng hầu hết các nhà phát triển sẽ sử dụng một tác nhân duy nhất cục bộ cho các tác vụ nhỏ lẻ, những tác vụ hỗ trợ kỹ sư, xây dựng tính năng mới, kết hợp mọi thứ tương tự. Tôi nghĩ việc chạy một sản phẩm cục bộ, tôi đã có một công việc quen thuộc cùng với một IDE. Đây có lẽ sẽ là một quy trình làm việc phổ biến trong vài năm tới.

Điều chúng ta đang thấy là một tỷ lệ nhỏ các kỹ sư là những người sớm áp dụng các tác nhân và thực sự hứng thú với chúng đang tìm cách orchestration các tác nhân để giải quyết những khối lượng lớn công việc kỹ thuật ở quy mô lớn. Và tuy nhiên, một năng suất tăng đột biến lớn hơn nhiều cho những nhóm tài sản chọn lọc nhỏ hơn đó, phải không? Bạn sẽ không thấy năng suất tăng 3000% cho toàn bộ kỹ thuật phần mềm, mà có lẽ sẽ nhận được mức tăng 20% mà mọi người vẫn thường báo cáo. Đối với một số tài sản chọn lọc như khắc phục CD remediation hoặc tổ chức dựa trên bằng chứng, bạn có thể đạt được một sự nâng cao đáng kể, bạn có thể hoàn thành công việc của bất kỳ người dùng nào trong vài tuần.

Quy trình làm việc của Tác nhân: Cục bộ và Điều phối

Tôi muốn nói một chút về các quy trình làm việc này trông như thế nào trong thực tế. Vì vậy, loop này có lẽ khá quen thuộc. Bạn đã quen làm việc với các tác nhân cục bộ. Đây là một loop rất điển hình, trông giống như phát triển lặp đi lặp lại hoặc, bạn biết đấy, mã hóa không AI vậy. Nhưng về cơ bản, bạn giao cho các tác nhân một số vấn đề. Nếu đó là công việc chạy ngầm, có thể bạn sẽ "trông chừng" và theo dõi, bạn biết đấy, mọi thứ đang diễn ra, nhấn phím walk nếu cần, bạn không muốn bỏ qua điều gì. Khi hoàn thành, bạn xem output, bạn thấy test vượt qua và bạn xem liệu điều này có thực sự thỏa mãn, điều mà bạn đang tìm kiếm, và sau đó có thể bạn sẽ tiếp tục để tiến gần hơn đến câu trả lời cho kết quả phụ của mình. Bạn, bạn biết đấy, bạn đã commit kết quả và push cho các tác vụ orchestration lớn hơn.

Điều này trở nên phức tạp hơn một chút. Về cơ bản, điều bạn cần làm là bạn hoặc có thể cùng với pod, bạn muốn phân rã thành một loạt các nhiệm vụ có thể được thực hiện riêng lẻ bởi các tác nhân. Sau đó, bạn sẽ gửi một tác nhân cho mỗi nhiệm vụ riêng lẻ đó. Và cuối cùng, vào cuối quá trình, bạn, có thể với sự giúp đỡ của một tác nhân, sẽ cần phải tập hợp tất cả output từ tất cả các tác nhân riêng lẻ đó thành một thay đổi duy nhất và merge vào cơ sở mã của bạn.

Vai trò của Con người trong Quy trình Điều phối

Điều rất quan trọng là vẫn có rất nhiều con người tham gia vào quy trình ở đây. Bạn cần xem xét không chỉ output cuối cùng của kết quả đã tập hợp, mà còn cả các output trung gian để sửa đổi. Theo quan điểm của chúng tôi, mục tiêu không phải là tự động hóa 100% quy trình này, mà là khoảng 90% tự động hóa. Đó vẫn là một mức tăng năng suất đáng kinh ngạc. Tôi nghĩ rằng điều này thực sự khó để thực hiện đúng. Đây là nơi cần rất nhiều suy nghĩ vào quy trình, chẳng hạn như làm thế nào để tôi đi đúng vào kiểu tác vụ để có thể xác minh bước ban đầu và để tôi thực sự tự động hóa toàn bộ quy trình này mà không chỉ kết thúc với mã nguồn phù hợp để tích hợp.

Quy trình Git điển hình với Tác nhân

Đây là quy trình làm việc Git điển hình mà tôi thích sử dụng cho các tác vụ như thế này. Thông thường, chúng tôi sẽ bắt đầu một branch mới trên kho lưu trữ của mình. Thay vì cung cấp hướng dẫn từng bước chi tiết thông qua agent-tool hoặc Open Hands (do chi phí của micro agent nội bộ), tôi chỉ đơn giản mark down và giải thích, bạn biết đấy, đây là những gì chúng tôi đang làm ở đây để tác nhân biết: được rồi, chúng tôi đang di chuyển từ re-excess us sang end hoặc chúng tôi sẽ di chuyển các công việc phần hai này sang phần ba.

Bạn có thể muốn đặt một loại scaffolding nào đó vào vị trí. Chúng ta sẽ nói thêm một chút về các ví dụ về scaffolding sau. Bạn sẽ tạo một loạt các tác nhân dựa trên branch đầu tiên đó. Ý tưởng là chúng sẽ đủ lớn để hoạt động trên branch đó và về cơ bản sẽ tích lũy công việc của chúng ta theo thời gian, và cuối cùng, hầu hết khi hoàn thành, chúng ta có thể loại bỏ scaffolding và merge branch ứng dụng đã phát triển vào main.

Mở rộng Quy mô Điều phối Tác nhân

Nếu bạn mới bắt đầu với điều này, tôi khuyên bạn nên giới hạn bản thân ở khoảng ba đến năm tác nhân đồng thời. Nếu nhiều hơn thế, bộ não của bạn sẽ bắt đầu "đình trệ", nhưng đối với những người đã thực sự áp dụng orchestration ở quy mô lớn, chúng tôi thấy rằng họ chạy hàng trăm đến hàng ngàn tác nhân đồng thời. Thông thường, một con người không thể xem xét từng tác nhân một trong loop, nhưng có thể các tác nhân đó đang gửi yêu cầu call đến các nhóm kỹ thuật số, và những thứ tương tự. Vì vậy, bạn có thể mở rộng quy mô rất nhanh chóng khi bạn bắt đầu nắm bắt được cách hoạt động của tất cả các công việc đó và bạn cảm thấy mình có một cách rất tốt để đưa con người tham gia vào quy trình.

Ví dụ: Di chuyển Mã Snow quy mô lớn

Tôi sẽ chuyển lời cho đồng nghiệp của tôi, Howard. Anh ấy sẽ nói về một cuộc di chuyển mã snow rất lớn, về cơ bản là loại bỏ các đoạn mã snow khỏi cơ sở dữ liệu Open Hands mà anh ấy đã thực hiện bằng cách sử dụng re-backer STA của chúng tôi, tại buổi hội thảo này. Open Hands xuất sắc trong việc giải quyết các vấn đề tập trung. Hãy đưa cho nó một vấn đề trọng tâm, chẳng hạn như khắc phục CI đang gặp sự cố của tôi và debug lỗi này tại các điểm nhất định. Nhưng giống như tất cả các tác nhân, nó có thể gặp khó khăn khi phạm vi quá lớn.

Giả sử tôi muốn tái cấu trúc mã thuộc loại có thể liên quan đến việc kiểm tra tag bốn sọc, cập nhật dependency hoặc thậm chí là một framework nhỏ nếu bạn muốn áp dụng nó. Những thay đổi này không nhỏ. Chúng lan rộng khắp hệ thống, những thay đổi có thể ảnh hưởng đến hàng trăm file. Để giải quyết các vấn đề ở quy mô này, chúng tôi đang sử dụng Open Hands Agent SDK để xây dựng các công cụ nhằm orchestration sự hợp tác giữa con người và nhiều tác nhân. Lấy ví dụ, chúng ta hãy cùng loại bỏ các mùi mã trong Open Hands trong toàn đội.

Trực quan hóa Phụ thuộc Mã để Tái cấu trúc

Đây là cấu trúc repository. Chỉ riêng định nghĩa tác nhân cốt lõi đã có 380 file với 60.000 dòng mã. Có rất nhiều về khối lượng mã nhưng không nhiều về cấu trúc. Vì vậy, hãy sử dụng các công cụ mới của chúng tôi để trực quan hóa biểu đồ phụ thuộc của phần repository này. Ở đây, mỗi node đại diện cho một file. Các agent hiển thị các dependency mà chúng ta đang quan tâm. Và khi chúng ta tiếp tục zoom out, rõ ràng là mạng lưới rối rắm này khiến việc tái cấu trúc trở nên khó khăn.

Để làm cho điều này dễ quản lý, chúng ta cần điều chỉnh đường dẫn thành các chunk có kích thước phù hợp với con người. Các batch có kích thước PR mà một tác nhân có thể xử lý và một con người có thể hiểu. Có nhiều cách để batch dựa trên những gì quan trọng đối với bạn. Về mặt đồ họa, tất cả các nhóm đều đưa ra những đảm bảo mạnh mẽ về cấu trúc và các cạnh ở giữa, và thực hiện các patch. Nhưng đối với mục đích của chúng tôi, chúng ta có thể đơn giản sử dụng thư mục easy state để đảm bảo rằng các file có liên quan về mặt ngữ nghĩa xuất hiện trong cùng một batch.

Bây giờ, chúng ta quay lại biểu đồ phụ thuộc. Chúng ta có thể thấy rằng các điểm nút không còn được phân phối ngẫu nhiên nữa. Thay vào đó, khi chúng ta zoom out và zoom in, chúng ta thấy chúng tương ứng với batch mà mỗi node (file) được liên kết. Chúng ta thường tìm thấy một cụm các g-stop có cùng màu, điều này cho thấy một tác nhân không đánh giá tất cả các file đó trên TNC. Tất nhiên, phạm vi vẫn lớn và nó đã gặp khó khăn nghiêm trọng. Bạn có thể bắt đầu với một chế độ xem đơn giản hơn, chúng tôi sẽ xây dựng một biểu đồ mới trong đó các node là các batch và các cạnh giữa các node đó là các dependency được kế thừa từ các file mà chúng ta không cần xử lý. Chế độ xem này đơn giản nhất, chúng ta có thể thấy toàn bộ cấu trúc gần như tương tự. Nhưng đây là điều mà chúng ta sẽ có thể batch. Sử dụng một biểu đồ, chúng ta có thể xác định các batch không có dependency phức tạp mà chúng ta cần xử lý các file bên trong.

Hợp tác Con người-AI và Ưu tiên Batch

Mẫu vá lỗi này có 16 node màu vàng. Chúng ta sẽ nói thêm về điều đó một chút, file có lẽ chỉ có vài cái. Hãy kiểm tra. Đây là ý định của công cụ cho sự hợp tác giữa con người và AI. Vì vậy, một khi chúng ta biết file này là FDVMite, hãy xác định rằng tốt hơn là nên làm việc với nó. Chúng ta có thể sẽ định vị được patch SIDS và tất cả những gì chúng ta muốn làm là bổ sung nó hoặc xem xét batch. Vì vậy, bạn biết đấy, nội dung.

Tất nhiên, khi chúng ta tiến hành, điều quan trọng là phải xem xét độ phức tạp của những gì bạn đang di chuyển. Batch này rất đơn giản. Hãy tìm một cái phức tạp hơn một chút. Đây là batch có bốn file mà chúng tôi vừa nói với bạn, và độ phức tạp sau khi phân tách là hợp lý. Những batch này thường mất hai ngày để một người hoàn thành, chúng ta nên cẩn thận hơn với khả năng kiểm tra và trước hết, lý do tại sao chúng ta cần thực hiện nó.

Quy trình Khắc phục Mùi Mã Hai bước

Vậy, làm thế nào chúng ta thực sự thực hiện điều đó với mã nguồn? À, đó là một quy trình gồm hai bước mà tôi thấy xuất hiện trong nhiều trường hợp khác. Trước khi chúng ta có thể sửa mã bằng cách loại bỏ các mùi mã, bạn cần xác định điều gì sai với cái đầu tiên. Và thông qua việc kiểm tra. Có một số cách khác nhau để định nghĩa việc xác minh dựa trên những gì bạn quan tâm. Bạn có thể thiết lập chương trình để kiểm tra các định dạng phù hợp. Điều này hữu ích nếu quá trình xác minh của bạn đang kiểm tra unit test, chạy linter hoặc kiểm tra attention. Thay vì sử dụng các code style, tôi sẽ sử dụng mô hình ngôn ngữ để xem xét mã và cố gắng xác định bất kỳ vấn đề nào mà nó có dựa trên danh sách các quy tắc được cung cấp.

Xác minh các Batch Đơn giản

Bây giờ, hãy quay lại batch đầu tiên của chúng ta, thực tế là để sử dụng xác minh này. Hãy nhớ rằng, batch này rất đơn giản và quá trình xác minh nhận ra giả định đó. Nó đi đến loại báo cáo tiếp theo cho biết điều gì khác đang diễn ra. Và trạng thái đang bắt đầu được hoàn thành, màu xanh lá, tốt. Sự thay đổi trạng thái này cũng là điều chúng đang theo dõi trong track đối sánh. Bây giờ, tôi quay lại và nói về việc chúng ta có thể thấy rằng chúng ta có chính xác một node ở trạng thái hoàn thành và phần còn lại vẫn chưa được xử lý. Nhưng điều này đã cho thấy một cái nhìn tổng quan tuyệt vời về công việc mà chúng ta đã làm và vị trí của nó trong bức tranh tổng thể.

Xác minh lặp lại và Chế độ lỗi

Vì vậy bây giờ, tôi chắc rằng bạn không chắc rằng không có mùi mã nào trong các repository quan trọng. Chúng ta chỉ cần đảm bảo rằng, à không, chúng ta không có batch track này cho nhóm này. Vì vậy, hãy quay lại các batch của chúng ta và tiếp tục xác minh cho đến khi chúng ta gặp lỗi. Chúng ta sẽ tiếp tục và xem xét dependency, đảm bảo rằng chúng ta chọn các node không có dependency phức tạp để chúng ta có thể phân tích rõ ràng. Batch tiếp theo là batch đơn lẻ cuối cùng giống như batch đầu tiên, nhưng vì unit file có một chút đủ phức tạp, báo cáo được tạo ra mạnh mẽ hơn một chút. Tiếp tục danh sách, chúng ta gặp batch mà chúng ta đã xác định trước đó với một số file lớn có độ phức tạp cao.

Xác minh Hàng loạt và Khắc phục Vấn đề

Và lô này tình cờ là một điểm khởi đầu giữa các tập hợp các xu hướng trạng thái, đúng không? Thay vì theo nhóm, lô này hiện có nhiều tệp hơn những gì chúng ta đã thấy trước đây. Vì vậy, báo cáo xác minh dài hơn tương ứng. Xem xét kỹ, báo cáo liệt kê từng tệp một, mã của tập hợp tệp trong đó nó hoạt động. Tôi thấy một tệp đặc biệt đã được rút gọn xuống năm mong muốn. Chà, tôi phải quay lại chỗ đó. Và nếu chúng ta thu nhỏ lại toàn bộ xuống bản nháp lô và xem xét các chỉ báo trạng thái, chúng ta sẽ thấy hai nút màu xanh lá cây đại diện cho các lô chúng ta đã xác minh thành công cho đến nay. Chúng ta cũng sẽ thấy nút màu đỏ đại diện cho lô mà chúng ta vừa thấy bị lỗi.

Mục tiêu: Chuyển toàn bộ biểu đồ sang màu xanh lá

Mục tiêu của chúng ta là biến toàn bộ biểu đồ này thành màu xanh lá cây, vì hiện tại nó đang gặp một chút vấn đề. Để làm được điều này, chúng ta cần giải quyết tập hợp các vấn đề đã tìm thấy bằng cách sử dụng bước tiếp theo của việc chỉ ra fixture. Cũng giống như tệp thứ ba, fixture có thể được xử lý theo nhiều cách khác nhau. Nhà sản xuất chương trình có thể chạy một lệnh hàng loạt, hoặc bạn có thể xem cách lô sẽ chạy thử và giải quyết các vấn đề theo từng bước. Nhưng tính năng mạnh mẽ nhất mà chúng ta có cho đến nay là Open-Hand State SDK để biến nút màu xanh lá cây thành các tác nhân độc lập của SXS-2, cũng như các công cụ để chạy thử nghiệm, mã mẫu, xem tài liệu trên internet và làm bất cứ điều gì cần thiết để giải quyết các vấn đề này.

Chạy Fixture và Tác nhân của Open-Hand

Vậy hãy quay lại màn hình trên bảng điều khiển và chạy fixture để xem điều gì xảy ra. Phần demo này được thiết lập đáng kể, nhưng vì chúng ta đang khám phá các lô và sự phụ thuộc về phía trước, tất cả những gì chúng ta đang chờ đợi là tiếp tục duyệt qua danh sách, chạy các tệp lỗi và tạo các phiên bản mới bằng tác nhân Open-Hand sử dụng SDK, cho đến khi chúng ta gặp một nút bị chặn vì một trong những cơ quan bảo mật vẫn còn tồn tại. Khi fixture được thiết lập và các lô được sử dụng, chúng ta sẽ cần phải xác minh lại hệ thống bảo mật để được mở ra và xuyên suốt đến cuối.

Báo cáo VR và Hành động của Tác nhân

Xem xét báo cáo mà fixture đã chuẩn bị, không có nhiều thông tin ngoài tiêu đề VR. Chúng ta đã thiết lập sao cho mỗi fixture tạo ra một yêu cầu pull request chất lượng cao, sẵn sàng để con người phê duyệt. Chỉ thực hiện điều này với các bộ reflector tự động không có nghĩa là nó cần phải là một vài. Và đây là VR đã tạo. Tác nhân đang ở chiếc máy tính xách tay tiếp theo, dựa trên Sonoma, mã hiện đã được xác định, cơ quan được tạo ra để giải quyết các công cụ có thể ở bên trong và sau đó. Nó cũng ít hữu ích cho người đánh giá, và đó là một nút tiến lên nếu bất cứ ai làm việc trên phần mã này trong tương lai, các tính năng cho lần chạy đó. Và khi chúng ta xem xét nội dung của VR, chúng ta thấy một điều rất gần đây. Tất cả các thay đổi đều tập trung chặt chẽ vào việc giải quyết phân tích mã mà chúng tôi đã cung cấp ở đây, và chúng tôi đã sửa đổi một vài mục trong danh sách, phần lớn trong số đó thực sự là một sự thật và mọi người đã đầu tư rất nhiều vào chức năng âm thanh. Không phải tất cả các lỗi đều nhỏ như thế này, nhưng chiến lược phân lô và hướng dẫn của chúng tôi đảm bảo rằng mã này sẽ thay đổi khi thế giới của chúng ta được tự do. Đây là một cách viết tắt nhất định của một dạng không chính thức, nhưng nó cũng sẽ dễ dàng hơn để tham chiếu đến nó. Từ đây, toàn bộ quy trình cho mã phòng và các thứ khác cho toàn bộ khu vực của con người và mã nguồn sẽ được thực hiện cho sự nghiệp. Được sử dụng để xác định các vấn đề, được sử dụng fixer để kích hoạt các cánh tay và giải quyết các vấn đề đó, xem xét và hợp nhất các VR đó, các bản sửa lỗi mới không bị chặn, lặp lại cho đến khi mục tiêu đó xảy ra với tôi. Chúng tôi đã sử dụng toàn bộ cơ sở mã này để xem liệu nó có thể thay đổi cơ sở dữ liệu hay không, bao gồm thời gian bắt đầu và bất kỳ lực lượng đặc nhiệm trước đó nào. Chúng tôi không thể làm được nếu không có Open-Hand HDSDK cấp nguồn cho mọi thứ trong mã. Vậy đó là Open-Hand, refactor SDK, power bi-art, urbanization SDK. Chúng tôi sẽ đi qua một chút trong buổi workshop để xây dựng một cái gì đó đơn giản hơn một chút, nhưng rất giống. Chúng tôi có một vài tác nhân làm việc cùng nhau để sửa các nhiệm vụ đã được một tác nhân ban đầu phát hiện.

Chiến lược Phân tách Nhiệm vụ cho Tác nhân

Tôi muốn nói một chút về chiến lược để phân tách nhiệm vụ và chia sẻ ngữ cảnh giữa các tác nhân này. Đây là một phần lớn của tổ chức tác nhân. Vì vậy, để phân tách nhiệm vụ hiệu quả, bạn thực sự cần chia vấn đề rất lớn của mình thành các bài kiểm tra mà một tác nhân duy nhất có thể giải quyết, một tác nhân duy nhất có thể thực hiện "một lần bắn" (one-shot) một thứ có thể nằm gọn trong một lời nhắc duy nhất, một yêu cầu kéo duy nhất, điều này cực kỳ, cực kỳ quan trọng bởi vì bạn không muốn bị, bạn biết đấy, hấp dẫn và sớm trong mỗi tác nhân phụ. Bạn muốn mỗi tác nhân, bạn muốn có một sự đảm bảo khá tốt rằng mỗi tác nhân sẽ chỉ thực hiện "một lần bắn" thứ đó, bạn sẽ có thể hiểu nó và hợp nhất nó vào cơ sở mã có thể chấp nhận được của mình. Bạn muốn tìm những thứ có thể được song song hóa. Đây sẽ là một cách rất lớn để tăng tốc độ của nhiệm vụ. Bạn biết đấy, nếu bạn chỉ thực hiện một loạt các tác nhân khác nhau một cách tuần tự, bạn cũng có thể chỉ có một tác nhân duy nhất di chuyển qua nhiệm vụ một cách tuần tự. Càng song song hóa được nhiều, càng có nhiều tác nhân nhỏ làm việc cùng lúc, bạn sẽ di chuyển qua nhiệm vụ và lặp lại nhanh hơn. Bạn muốn những thứ bạn có thể xác minh là đúng một cách rất dễ dàng và nhanh chóng. Lý tưởng nhất là bạn sẽ có một thứ mà bạn chỉ cần nhìn vào trạng thái CI/CD và có độ tin cậy tốt rằng mọi thứ đều ổn, bạn ổn. Có thể bạn sẽ cần chạy nó qua chính ứng dụng, đại loại như vậy, tự mình chạy và đề xuất để xác minh rằng mọi thứ trông tốt đối với bạn. Nhưng bạn muốn có thể nhanh chóng hiểu được liệu một tác nhân đã hoàn thành công việc bạn yêu cầu hay chưa. Và bạn muốn có một sự phụ thuộc rõ ràng để thực hiện một số nhiệm vụ. Bạn nhận thấy những tiêu chí này khá giống với cách bạn chia nhỏ công việc cho nhóm của mình, đúng không? Bạn cần đảm bảo rằng bạn có các nhiệm vụ có thể tách rời được, những người khác nhau trong nhóm của bạn có thể thực hiện toàn bộ vai trò và sau đó kết hợp các kết quả lại với nhau. Bạn muốn biết khi tôi hoàn thành một nhiệm vụ và sau đó tôi không biết liệu nó có vượt qua CI/CD hay không, và sau khi những thứ đó được thực hiện, chúng ta có thể làm E. Vì vậy, nó rất giống với việc chia nhỏ công việc cho một nhóm kỹ sư.

Chiến lược Phân tách Nhiệm vụ: Tiếp cận Đa dạng

Có một vài chiến lược khác nhau để chia nhỏ một nhóm rất lớn trở lại một trong những album nói chuyện này, chỉ cần làm. Cách đơn giản nhất, như hầu hết các bạn muốn, là chỉ cần hiển thị những gì cần phải giống như miền Đông, bạn biết đấy, dù sao đi nữa, nếu bạn là một pilot bắt buộc, nếu bạn là một pilot, hoặc một redirectary, có thể là một refunction hoặc một class, bạn biết đấy, đây là một cách khá đơn giản để làm mọi thứ mà hoạt động tốt nếu những sự phụ thuộc đó có thể được thực hiện mà không phụ thuộc quá nhiều vào cái khác. Vì vậy, ví dụ tốt về việc làm điều đó trong type-meditation, start-up pipeline codebase. Sau đó, bạn biết đấy, ở phần cuối cùng khi bạn đã di chuyển mọi tệp, chẳng hạn, bạn có thể tập hợp tất cả các kết quả đó vào một PR duy nhất. Một điều hơi phức tạp hơn một chút sẽ là tạo cây phụ thuộc. Và ý tưởng ở đây là khi là một công nhân theo cách tiếp cận từng phần đó, bạn bắt đầu, bạn bắt đầu làm thế nào để bạn bắt đầu với các nút lá trong biểu đồ phụ thuộc của mình, đúng không? Bạn bắt đầu với có thể là các tệp tiện ích của bạn để những thứ đó có thể được xử lý, và sau đó bất cứ thứ gì phụ thuộc vào những thứ đó, bạn biết đấy, sẽ có những bản sửa lỗi ban đầu đó và các sự phụ thuộc có thể bắt đầu xử lý, bạn biết đấy, mọi thứ trong quá trình. Bạn về cơ bản quay ngược lại theo cách của mình để đến bất cứ thứ gì là điểm cuối của ứng dụng của bạn. Đây thường là một cách tốt hơn để tiến hành. Nó giống như một cách tiếp cận nguyên tắc hơn về cách bạn sẽ gom những thứ đó qua các nhiệm vụ này. Một ví dụ khác là tạo một loại scaffolding nào đó cho phép bạn sống trong cả thế giới trước di chuyển và sau di chuyển. Chúng tôi đã làm điều này, ví dụ, khi di chuyển hệ thống quản lý trạng thái React của chúng tôi. Chúng tôi về cơ bản đã có một tác nhân thiết lập một số scaffolding cho phép chúng tôi làm việc với cả hai sản phẩm, Redux và Zustan cùng một lúc. Khá xấu xí, không phải thứ bạn thực sự muốn làm, nhưng nó cho phép chúng tôi kiểm tra ứng dụng khi từng thành phần riêng lẻ được di chuyển từ hệ thống quản lý trạng thái cũ sang hệ thống quản lý trạng thái mới. Và sau đó chúng tôi đã gửi các tác nhân song song cho từng thành phần. Tôi đã hoàn thành từng thành phần, và sau đó ở phần cuối cùng, một khi tôi đã sử dụng Zustan, chúng tôi đã loại bỏ tất cả scaffolding, vì vậy không còn hỗn độn và các công việc trước di chuyển nữa. Nhưng việc có scaffolding đó cho phép chúng tôi xác thực, khi mỗi tác nhân hoàn thành công việc của mình, chỉ cho thành phần đó, chúng tôi đưa ra ứng dụng của stillwork, not-and-the-pone của stillworks. Chúng tôi không phải làm mọi thứ một lúc, nhưng chúng tôi đã nhận được một số loại phản hồi từ các tác nhân.

Chia sẻ Ngữ cảnh Giữa các Tác nhân

Tôi chỉ muốn nói về chia sẻ ngữ cảnh. Khi bạn thực hiện một dự án quy mô lớn như thế này, bạn sẽ học được điều này, đúng không? Bạn sẽ nhận ra rằng mô hình ban đầu của mình thực sự chưa hoàn chỉnh. Bạn thực sự, bạn biết đấy, chưa hiểu đúng vấn đề. Các tác nhân của bạn có thể gặp phải, bạn biết đấy, bạn có thể có một vài tác nhân, bạn đã có một tác nhân đang chạy, tất cả chúng đều gặp cùng một vấn đề, bạn muốn chia sẻ giải pháp cho những vấn đề đó, nhưng tất cả chúng đều bị kẹt, đúng không? Có nhiều chiến lược khác nhau để thực hiện chia sẻ ngữ cảnh này giữa các tác nhân. Một chiến lược, giống như điều đơn giản nhất bạn có thể làm, là chia sẻ mọi thứ. Về cơ bản, mọi tác nhân đều nhìn thấy ngữ cảnh của mọi tác nhân khác. Điều này không tốt. Về cơ bản, nó giống như việc chỉ nói chuyện với một tác nhân duy nhất làm việc để hoàn thành nhiệm vụ. Bạn biết đấy, chúng ta có thể ngữ cảnh lẫn nhau, nhưng bạn có thể làm điều gì đó như thế này. Vì vậy, đây không phải là những gì chúng ta có thể làm. Một cách tiếp cận giá trị tốt hơn là kiểu con người, sắp xếp thông tin thủ công và các tác nhân. Nếu bạn có một tin nhắn trò chuyện, một cuộc trò chuyện sẽ có thể dạy tác nhân. Bạn có thể chỉ cần dán một thư viện người dùng, một đến ba thay vì một đến hai. Con người cũng có thể mua tác nhân ra khỏi, hoặc nếu nó là một micro agent để chuyển chúng cho các tác nhân này. Điều này là một khối lượng nỗ lực thủ công của con người. Nó liên quan đến việc chăm sóc các tác nhân nhiều hơn. Vì vậy, nó không có khả năng mở rộng cao.

Bạn cũng có thể để các tác nhân về cơ bản chia sẻ ngữ cảnh thông qua một tệp như agent.js. Bạn có thể để nhiều tác nhân thực sự sửa đổi tệp này. Có thể có bốn câu hỏi trong tệp vì có nhiều thứ. Nhược điểm ở đây là đôi khi các tác nhân sẽ cố gắng học những điều quan trọng. Chúng có thể trở nên khá hung hãn trong việc đưa thông tin vào tệp này để làm một số việc hữu ích cho con người hoặc những điều mới. Và cuối cùng, đây có lẽ là ý tưởng tiên tiến nhất ở đây. Nhưng bạn về cơ bản có thể cung cấp cho bạn một công cụ cho phép nó gửi tin nhắn đến các tác nhân khác. Nó có thể là một tin nhắn broadcast gửi đến tất cả các tác nhân khác, hoặc nó có thể là một cuộc trò chuyện point-to-point. Điều này cực kỳ thú vị để thử nghiệm, hoặc để thử nghiệm điều này ngay bây giờ với SDK của chúng tôi. Nhưng nó rất khó kết hợp. Một khi bạn để các tác nhân nói chuyện với nhau, bạn đang tăng mức độ tính phi xác định trong hệ thống. Tôi có một ví dụ ở đây bên phải. Đây là từ các tài liệu của portfolio. Họ có hai tác nhân chỉ nói chuyện với nhau. Chúng chỉ đi vào một agent loop để mong muốn lẫn nhau và gửi sự hoàn hảo.

Bài Tập Workshop: Khắc phục Lỗ hổng Bảo mật Quy mô Lớn

Bây giờ tôi muốn thực hiện một bài tập. Tôi rất muốn tất cả các bạn cùng làm theo. Bạn có thể truy cập bài thuyết trình này cho mục đích sao chép tại duct.fh.openhands-workshop. Chúng ta sẽ thực hiện một số bài tập coding với OpenHands SDK đặc biệt để khắc phục lỗ hổng bảo mật ở quy mô lớn. Chúng ta sẽ viết một script mà nó sẽ nhận vào một kho lưu trữ, quét nó để tìm thư mục source hoặc CDs. Và sau đó sẽ gửi một tác nhân song song cho mỗi lỗ hổng bảo mật chúng ta tìm thấy để giải quyết nó trong một yêu cầu kéo. Vậy duct.fh.openhands-workshop. Hãy cho tôi biết nếu có ai đó có thể truy cập được. Nó đang hiển thị dưới dạng trình chiếu. Vì vậy, đó sẽ là trình chiếu. Sẽ có các lời nhắc và các lưới có thể sao chép được có thể đã xuất hiện ở slide 29. Tôi sẽ đến đó.

Quy trình Khắc phục Lỗ hổng Bảo mật Tự động

Về cách thức hoạt động của quy trình này, chúng ta sẽ bắt đầu với một tác nhân chạy quá trình quét CVE trên kho lưu trữ này. Tác nhân sẽ quét tìm các lỗ hổng bảo mật. Ưu điểm của việc sử dụng một tác nhân cho việc này là nó có thể xem xét kho lưu trữ và quyết định loại hình quét lỗ hổng bảo mật nào phù hợp. Ví dụ, tôi có thể sử dụng Trivy để quét một Docker image, hoặc chạy MDM trên một tệp package.json. Như vậy, tác nhân có thể tự động phát hiện ngôn ngữ lập trình và tìm ra cách để quét CVEs tại đó.

Sau khi có danh sách các lỗ hổng bảo mật, chúng ta sẽ chạy một tác nhân riêng biệt cho mỗi lỗ hổng. Mỗi tác nhân này sẽ nghiên cứu xem liệu lỗ hổng đó có thể giải quyết được hay không. Nó có thể cập nhật phiên bản của các thư viện phụ thuộc, khắc phục bất kỳ thay đổi API nào gây lỗi trong toàn bộ cơ sở mã, và sau đó tạo một pull request.

Lợi ích của Cách tiếp cận Tác nhân

Ưu điểm của cách tiếp cận này là chúng ta có thể gộp các pull request riêng lẻ khi chúng sẵn sàng. Việc giải quyết các lỗ hổng bảo mật song song mang lại nhiều PR khác nhau, cho phép chúng ta gộp chúng khi chúng hoàn tất. Nếu một tác nhân bị kẹt hoặc một lỗ hổng không thể giải quyết được, tất cả các tác nhân khác vẫn tiếp tục làm việc. Có thể chúng ta đạt được 90% hoặc 95% số lỗ hổng được giải quyết, mà không cần phải đạt 100% để có được giá trị.

Ví dụ về Tạo Tác nhân với Open-Hands SDK

Đây là một ví dụ nhanh về cách tạo một tác nhân bằng cách sử dụng Open-Hands SDK. Bạn có thể thấy chúng ta tạo mô hình ngôn ngữ của mình, sau đó chuyển mô hình ngôn ngữ đó cho một đối tượng tác nhân. Chúng ta cung cấp cho nó tất cả các công cụ như terminal, công cụ quản lý tệp và một abstractor để lập kế hoạch. Chúng ta cung cấp cho nó một không gian làm việc, sau đó chỉ cần cho nó biết chúng ta muốn làm gì và chạy. Đây là một ví dụ khá đơn giản, nhưng chúng ta sẽ thấy nó trở nên phức tạp hơn khi tiến hành nhiệm vụ cụ thể này. Lợi ích của tác nhân đầu tiên là nó sẽ lặp lại tất cả các lỗ hổng bảo mật để lấy ra dữ liệu. Mỗi lỗ hổng sẽ gửi một tác nhân mới để yêu cầu giải quyết dữ liệu đó.

Chuẩn bị Môi trường và Xác thực

Để bắt đầu, bạn cần tạo một kho lưu trữ GitHub mới để lưu trữ công việc của mình. Bạn cũng sẽ cần cả GitHub token và LLM token. Nếu bạn đã đăng ký app.openhands.dev, bạn có thể nhận được 10 đô la tín dụng LLM miễn phí. Nếu bạn là người dùng hiện có, hãy cho tôi biết, tôi có thể tăng tín dụng hiện có của bạn cho mục đích của bài tập này.

Chúng ta sẽ khởi động một máy chủ tác nhân. Đây về cơ bản là một vùng chứa Docker sẽ chứa tất cả công việc mà các tác nhân của chúng ta đang thực hiện. Đây là một cách tuyệt vời để chạy các tác nhân một cách an toàn và có khả năng quan sát tốt hơn. Thay vì chạy các tác nhân trên máy cục bộ của chúng ta để giải quyết các CVEs, chúng ta sẽ chạy chúng bên trong vùng chứa của mình. Tôi nghĩ rằng nếu chúng ta xử lý hàng ngàn CVEs, chúng ta có thể chạy nó trong một Kubernetes cluster để có số lượng máy trạm tùy ý cho các tác nhân của chúng ta. Nhưng với mục đích của bài tập này, chúng ta sẽ chỉ chạy một vùng chứa Docker làm máy chủ duy nhất cho các tác nhân của chúng ta. Sau đó, chúng ta có thể tạo một tác nhân trong OpenHands để bắt đầu thực hiện nhiệm vụ này.

Sử dụng OpenHands CLI

Tôi sẽ sử dụng OpenHands CLI trong quá trình này. Bạn sẽ cần kiểm tra OpenHands CLI. Bạn cũng có thể sử dụng Cursor, Bot Code hoặc bất kỳ công cụ nào bạn thường dùng khi chúng ta thực hiện quá trình khắc phục CVE với OpenHands. Tôi sẽ dành vài phút để tạo kho lưu trữ GitHub, lấy GitHub token, v.v. Nếu bạn gặp bất kỳ vấn đề gì, vui lòng giơ tay và tôi sẽ đến giúp đỡ.

Được rồi, tôi đã có kho lưu trữ GitHub mới của mình ở đây. Tôi sẽ thêm một microagent OpenHands nhanh chóng ở đây. Tôi sẽ nói về việc xây dựng bất kỳ quy trình nào cho bất kỳ CVEs nào với các tác nhân. LLM tương tác qua OpenHands SDK.

Một chút ngữ cảnh. Bây giờ chúng ta đã có kho lưu trữ này. Để lấy token, tôi sẽ thực hiện ở đây. Như vậy tôi sẽ không để lộ token của mình, nhưng bạn có thể vào cài đặt GitHub, hồ sơ của bạn, sau đó vào cài đặt nhà phát triển, personal access tokens, và chọn classic tokens. Được rồi, classic tokens, đặt tên cho nó, và sau đó quyền truy cập kho lưu trữ – đó là tất cả những gì bạn cần. Bằng cách đó, chúng ta có thể mở một pull request để giải quyết các CVEs liên quan. Chúng ta có một classic token, không phải một cái mới. Tôi không biết mình quan tâm đến nó như thế nào. Tôi đã có một cái. Nó chỉ là một vài cái. Sử dụng cái tương tự. Bạn có thể làm như vậy. Tôi đoán bạn có thể tạo một kho lưu trữ mới. Tôi nghĩ tôi có thể sử dụng chúng. Vậy bạn... Vâng, hãy chồng các OpenHands cũ lên. Vậy chúng ta cần những quyền gì? Chỉ cần quyền truy cập kho lưu trữ. Tôi sẽ chỉ cho bạn một số bản sao lưu.

Được rồi, đó không phải là điều đó. Bạn không vào hồ sơ của mình ở đây. Bạn có thể lấy API key của OpenHands của bạn ở đây, API key của LLM của bạn ở đây. Tôi sẽ không hiển thị nó, nhưng... Đây là tất cả những gì tôi cần để sử dụng LLM của chúng tôi. Chỉ một chút ở đây để tôi có thể... các bước xuống.

Khởi động Agent Server và Thiết lập Ban đầu

Cuối cùng, tôi sẽ khởi động một số máy chủ tác nhân ở đây. Có lẽ tôi sẽ sao chép dán cái này từ bài thuyết trình. Tôi đã sao chép kho lưu trữ của mình và chạy vùng chứa máy chủ tác nhân. Nếu bạn muốn làm việc với OpenHands CLI, có thể cần cài đặt OpenHands CLI. Một lần nữa, bạn có thể sử dụng Bot Code, Cursor hoặc bất kỳ thứ gì khác nếu bạn muốn. Bạn chỉ cần thêm một chút thời gian để thiết lập. Tôi sẽ theo dõi API key, thiết lập token. Xin lỗi, hãy kiểm tra kỹ.

Thử nghiệm Kết nối LLM

Vì vậy, tôi sẽ bắt đầu với lời nhắc đầu tiên này. Về cơ bản, chúng ta sẽ trỏ tác nhân của mình vào OpenHands SDK, trỏ nó vào tài liệu, và chỉ yêu cầu nó kiểm tra xem API key của LLM có hoạt động hay không, rằng nó thực sự có thể hoạt động trong tổ chức của chúng ta. Vì vậy, nó sẽ giống như một ví dụ "hello world" rất cơ bản, chỉ để bắt đầu ở đây. Tôi sẽ nói với nó rằng tôi đang sử dụng API key của OpenHands mà tôi đã tạo tại app.openhands.dev, v.v.

Tôi đang nói với bạn để sử dụng OpenHands/bots trên một bot. Bạn có thể thay thế điều này bằng Anthropic. Nếu bạn muốn sử dụng API key Anthropic thông thường, bạn có thể cần đặt mô hình này khác một chút tùy thuộc vào người dùng OpenAI. Sử dụng trợ giúp của tôi, bạn có thể đặt tất cả trên tài liệu mà chúng ta nhận được. Nếu bạn có API key OpenAI, bạn có thể xem tất cả tài liệu mà họ có, mô hình nào mà tôi đang sử dụng cho chuỗi này. Và tôi sẽ chỉ sao chép điều này nguyên văn. Xin lỗi, cái gì cho agent.py, cái gì cho OpenHands? Vì vậy, nếu tôi tạo một tệp ngoài agent.py, nếu bạn đang làm việc với các công cụ để mô hình hóa với điều đó, OpenHands chúng tôi có một cái gọi là microagent. Để tôi đi sâu vào nó.

OpenHands/microagent là mô tả của kho lưu trữ bạn đang ở. Và tôi chỉ cung cấp cho nó một vài liên kết đến tài liệu SDK và kho lưu trữ cho SDK, để nó có quyền truy cập vào tài liệu API ở đó. Đây là một bước tùy chọn. Chỉ nghĩ rằng mọi thứ sẽ dễ dàng hơn một chút về các trang đang làm. Nó nghĩ rằng nó đã có một cái gì đó tốt. Vậy hãy xem điều gì đã xảy ra. Phần mềm CVE của tôi, biến môi trường sử dụng một công cụ để thiết lập môi trường của tôi ở đây, kiểm tra chúng. Phần mềm, có vẻ như tác nhân đã không hiểu đúng tài liệu API. Nó đang dán phản hồi của chúng tôi. Hãy kiểm tra lại, tất nhiên, máy tính xách tay không bao giờ hiển thị. Chúng ta đang sử dụng mã. Nó hơi quá nhiều. Chỉ là tôi. Chỉ là tôi. Nó chân thành. Nhưng bạn không thể chỉ đảm bảo cho nó, bạn cần theo dõi cái đó bị hỏng. Vâng. Bạn có thể đảo ngược nó nếu bạn đang ở 0.9.6. Bất cứ điều gì bạn sẽ biết. Tôi không biết tại sao. Bạn muốn làm một vài điều. Không, đó là một khởi đầu tồi tệ. Tôi chỉ muốn cung cấp nó bằng cách cat nếu bạn OpenHands, removing tool, error-failed to install entry points. Tôi là người mới trong thế giới Python, vì vậy tôi nghĩ mình đã đúng. Vì vậy, bạn có thể thử, nó tạo ra khoảng cuối Python 3.11. Chỉ là những gì tôi đang dùng, nhưng vâng, tôi sẽ thử. Không có câu hỏi. Vâng, vậy tôi đã có thể, bạn có chạy vào CLI không? Tôi đã có thể chạy cái này trên openhands.dev. Vâng, tốt. Và nó đã tạo một PR. Trông tốt. Tại sao bạn làm điều đó với CLI? Thực sự chỉ để. Bạn thấy?

Tương tác và Gỡ lỗi CLI

Thông thường, tôi thực sự thích làm việc thông qua giao diện web ở đây. Tôi nghĩ rằng việc có thể chạy và hiển thị script đang hoạt động cục bộ tốt hơn một chút. Tôi thực sự thích làm việc thông qua giao diện web và sau đó để tác nhân đẩy và hành động cục bộ. Nếu tôi thực sự muốn làm việc cục bộ, tôi nghĩ rằng đó chỉ là các bước bổ sung cho mục đích trình bày. Chúng ta phải trải qua để sử dụng web hoặc công cụ. Có vẻ như tôi đã thiết lập API key đúng ở đây. Chỉ cần sửa đầu ra. Nó phải là 200. Chúng ta sẽ nhận được 200 cho phản hồi và nó nói gì? Hãy xem. Vâng, bạn nên. Vâng, đại loại thế này. Cuối cùng tôi đã tìm ra nơi LLM nói "hello". Mở nó ra. Điều đó thực sự hoạt động như thế nào? Có ai quản lý để kết nối LLM hoạt động không? Cảm ơn. Tôi đã tạo tệp. Chỉ là rất tốt để báo cáo điều này trông như thế nào. Tôi có nó theo thứ tự. Vì vậy, nó chắc chắn cần phải ở đây. Về cơ bản, bạn có thể thấy chúng ta không tạo ra một. Rất nhiều thứ chúng ta muốn sử dụng. API key mà chúng ta muốn sử dụng. Bạn đặt nó vào. Điều đó có gửi một tin nhắn nhanh đến LLM để đảm bảo nó thực sự hoạt động không? Hãy nói rằng nó đã di chuyển ra ngoài để đến với bạn.

Tạo Tác nhân Quét CVE và Môi trường Agent

Ở đây, chúng ta sẽ bắt đầu làm nhiều hơn cho các tác nhân. Vì vậy, chúng ta sẽ nói với tác nhân mà chúng ta đang làm việc, chúng ta muốn sử dụng SDK để tạo một tác nhân mới. Nó sẽ yêu cầu bạn lấy kho lưu trữ. Nó sẽ kết nối với một không gian làm việc từ xa đang chạy tại localhost:8000. Một lần nữa, đó là lệnh khởi động Docker từ trước. Nếu bạn chưa chạy lệnh đó, đây là thời điểm tốt để chạy Docker: docker run máy chủ tác nhân này. Nó sẽ sao chép kho lưu trữ vào vùng chứa Docker đó. Chúng ta sẽ tạo một tác nhân sẽ làm việc bên trong vùng chứa Docker đó. Và chúng ta sẽ nói với tác nhân đó rằng nó sẽ quét kho lưu trữ này để tìm các lỗ hổng bảo mật.

Với OpenHands CLI, cách để ngắt và dừng nó là Ctrl+P, hoặc tạm dừng. Và sau đó tôi có thể chèn các sửa chữa của mình không? Hoặc bạn có thể nhập một tin nhắn hoặc chỉ nhập continue. Tôi đã cài đặt CLI ở phiên bản -AI. Có một số pipeline có phiên bản -AI. Và sau đó tài liệu nói rằng phiên bản AI sẽ được tách biệt. Nhưng nó là một CLI có thể sử dụng được. Bạn có thể chạy dịch vụ của mình từ một máy chủ, 13. Bạn đã làm cho phiên bản -AI hoạt động chưa? Bởi vì ngay khi tôi cố gắng chạy nó, nó đã bị lỗi. Ồ. Nó không giải quyết được vấn đề đó. Nhưng vâng, nó đã được cài đặt và sau đó nó hoạt động. Nó đưa ra cảnh báo không dùng nữa khi tôi xem phiên bản. Vâng, đó là nó. Nếu bạn muốn tải xuống một tệp thực thi nhị phân trên trang phát hành của chúng tôi, điều đó có thể đơn giản. Bạn cũng có thể chạy nó trong Docker. Nếu bạn đọc tài liệu CLI, tôi nghĩ cũng có lệnh uv run. uv run. Bạn có phiên bản không? Bạn có phiên bản không? Vâng. Bạn thấy. Ồ, thú vị. Được rồi. Hãy xem nếu bạn thử thêm một loại phiên bản. Đó là dành cho mô hình mà nó có. Giống như nó sẽ ở trên phiên bản. Được rồi. Ồ, cảm ơn bạn.

Giả sử chúng ta có một tác nhân đang hoạt động ở đây. Hãy xem tôi sẽ chạy nó với cái gì. Ảnh không gian. Bây giờ, chúng ta nên có một vài CVEs. Hãy xem liệu chúng ta có tìm thấy bất kỳ lỗ hổng nào không. false cuối cùng. OpenHands sẽ trực quan hóa đầu ra ở đây. Nó là một tác nhân CVE hoạt động ngay cả với SDK. Trước hết, chúng ta đã thấy CLI. Tôi không nghĩ đó là dữ liệu. Đó là danh sách tác vụ. Đó là. Tôi sẽ vào kho lưu trữ. Nó không có Trivy. Vì vậy, nó không phải là Trivy. Vì vậy, bạn đang làm việc với một tác nhân và các tác vụ. Chúng ta đã tham gia vào đó. Vì vậy, chúng ta đang chạy Trivy bây giờ.

Hãy cho bạn xem một chút về mã được tạo này trông như thế nào. Bạn có thể thấy, chúng ta có thể đã thiết lập mô hình ngôn ngữ của mình như bước đầu tiên. Bây giờ chúng ta thực sự đang chuyển cái này vào một tác nhân. Chúng ta cũng cung cấp một công cụ terminal và công cụ quản lý tệp. Chúng ta đang tạo không gian làm việc từ xa này được kết nối với vùng chứa Docker của chúng ta để nó bắt đầu làm việc trong môi trường riêng của nó.

Quản lý Ngữ Cảnh và Tác Vụ của Tác nhân

Chúng ta tạo ra cái gọi là một cuộc trò chuyện (conversation), về cơ bản đó là một khối ngữ cảnh mà tác nhân sẽ quản lý khi nó thực hiện công việc của mình. Tôi đã giao một tác vụ với hướng dẫn rõ ràng về những gì nó phải làm, sau đó gửi thông điệp (message) đó, tác vụ đó. Có vẻ như tác nhân quét ban đầu đó đã gần hoàn thành. Có vẻ như tác nhân đó đã chạy tốt, với những kết quả này. Đó là cách chúng ta duy trì... ở đây. Giờ thì chúng ta có ngay lập tức... nó đang kiểm soát các khả năng của chúng ta.

Trích xuất Danh sách Lỗ hổng

Vì vậy, điều tiếp theo tôi sẽ yêu cầu nó làm về cơ bản là chúng ta sẽ truy cập vào môi trường của nó để lấy danh sách lỗ hổng ra. Ý tưởng là chúng ta sẽ yêu cầu nó không chỉ lưu các lỗ hổng vào tệp JSON. Sau đó, trên đối tượng không gian làm việc đó bên trong Docker, chúng ta sẽ sử dụng một lệnh để lấy những lỗ hổng đó ra. Chúng tôi cũng có một số tùy chọn cho nhiều loại tệp khác nhau. Vì vậy, chúng ta sẽ truy cập vào không gian làm việc. Hiện tại, chúng ta sẽ chỉ lặp lại các lỗ hổng trong tệp JSON, chỉ để chúng ta có thể thấy rằng chúng ta đã có thể truy cập vào không gian làm việc này và lấy một số thông tin ra. Riêng biệt. Vậy đấy. Nó xảy ra. Cô ấy nói đúng. Vì vậy, chúng ta đã nhận được một số kết quả lỗ hổng. Tác nhân đã hoàn thành. Hãy xem tập lệnh của chúng ta có thể lấy nó về không.

Phân tích Hành động và Quan sát của Tác nhân

Vì vậy, có một hành động và một quan sát. Có lẽ nó đến từ lệnh và sau đó một quan sát đã quay lại với đầu ra. Nó còn hơn cả... Về cơ bản, toàn bộ... Bạn có thể lấy các sự kiện... sự kiện. Và sau đó có hai loại hành động và quan sát khác. Và chúng tôi nghĩ tất cả... toàn bộ... Nó quay lại với một hành động cần thực hiện, về cơ bản là một lời gọi công cụ. Và sau đó quan sát giống như một lời gọi công cụ. Nếu ai đó gặp khó khăn với bất cứ điều gì, tôi sẵn lòng ngắt lời bạn. Hãy cân nhắc giơ tay. Cái gì vậy? Số bốn. Tôi vừa làm số ba. Và... (tiếng nói không rõ). Tốt. Vâng. Có vẻ như nó đang in danh sách CVE. Vâng. Trông tốt đấy. Nó... Nó được cho là... (lời nói lặp lại, không rõ nghĩa)... Điều gì sẽ xảy ra...

Cải thiện Tổ chức Mã và Demo

Vì vậy, đó là năm phần nhỏ. Chắc chắn rồi. Vâng, vâng, vâng. Không, tôi nghĩ chắc chắn có những cách tốt hơn để tổ chức mã nguồn này hơn là chỉ có một tập lệnh duy nhất. Điều này chỉ dễ hơn cho mục đích demo. Tôi có một kho lưu trữ demo. Tôi nghĩ đó là open-hand/CVE demo sử dụng các lớp đặc biệt. Có một lớp con tác nhân CVE duy nhất mà chúng tôi vẫn nói trên Mô hình Ngôn ngữ Lớn. Nó mang tính khả năng chịu lỗi (forgiveness) hơn một chút so với tập lệnh này. Sam, có lẽ bạn dùng cho một số quy trình kiểm soát. Vì vậy, tôi sẽ sử dụng nó. Nó hoàn toàn khác.

Thảo luận và Kết thúc

Và chúng ta kết thúc với vài phút. Vì vậy bạn cần tiếp tục. Tôi sẽ rời đi. Đó là câu hỏi. Đó là câu hỏi. Vâng. Cái cuối cùng là về. Tôi sẽ cố gắng làm nó. Đó là cái đó. Phần cứng. Vâng. Có lẽ là vậy. Tôi xin lỗi. Tôi không muốn kết thúc ngay bây giờ. Lần này đây là một trong những giả định. Thực sự có những cách để dừng 1000. Nó nhanh hơn. Đúng. Không. Vâng. Phần cứng. Vâng. Nó sẽ có. Chúng tôi đã tạo ra một nỗ lực tốt đẹp để tạo ra một liên minh âm thanh nhỏ trên tất cả những cái nhỏ hơn. Chúng tôi có các nhóm khác nhau trong nhóm, chúng tôi đã ở xung quanh, vì vậy chúng tôi phải thử điều này. Rất nhiều đêm của chúng tôi, chúng tôi phải nói rằng chúng tôi, tổng quát hóa, thực sự là chia sẻ bạn bè của chúng tôi. Tất cả chúng tôi đã đạt đến cùng một cấp độ, đó là điều chúng tôi tìm thấy nhiều nhất trong công ty. Chúng tôi đã làm điều này được sáu năm. [transcript bị gián đoạn]