Quy trình làm việc của Codex và đa tác nhân: làm việc với các tác nhân mà không mất quyền kiểm soát
· 9 min read · Filippo Spinella · AI, Developer Tools, Productivity, Software Engineering
Lần đầu tiên một nhân viên viết mã thực sự sửa một lỗi cho bạn, phản ứng hầu như luôn giống nhau: sự nhiệt tình xen lẫn sự nghi ngờ. Đẹp, chắc chắn rồi. Nhưng sau đó bạn nhìn vào sự khác biệt và tự hỏi: "Ok, nhưng chính xác thì anh ấy đã chạm vào cái gì? Tôi có thể tin tưởng anh ấy không? Liệu ngày mai anh ấy có làm lại theo cách tương tự không?".
Đó là nơi tôi nghĩ phần thú vị bắt đầu. Không phải khi tác nhân viết một hàm, mà là khi nó có đủ khả năng để đảm nhận toàn bộ công việc: đọc kho lưu trữ, tạo bản vá, chạy thử nghiệm, mở PR, quay lại sau khi nhận xét đánh giá. Codex đang đi chính xác theo hướng đó: công việc nền, cây công việc riêng biệt, trình duyệt tích hợp, tự động hóa, plugin, bộ nhớ và các biện pháp kiểm soát quyền rõ ràng hơn.
Vấn đề không phải là tưởng tượng về một tương lai không còn ai đọc mã nữa. Đó sẽ là một tương lai khủng khiếp và khá ngây thơ. Vấn đề là tìm ra cách làm việc với những đại lý có thể làm được nhiều việc mà không để họ làm mọi thứ.
Sự thay đổi thói quen
Với tính năng tự động hoàn thành truyền thống, bạn luôn ở trong tay lái. AI gợi ý một dòng, bạn quyết định. Tuy nhiên, với một người đại diện, mối quan hệ sẽ thay đổi: bạn giao cho anh ta một mục tiêu và anh ta sẽ tự mình thực hiện nhiều bước.
Điều này có tác dụng mạnh mẽ nhưng nó làm thay đổi vấn đề. Câu hỏi không còn chỉ là “mô hình có thể lập trình được không?”. Câu hỏi trở thành:
- Tôi đã cho anh ta một phạm vi đủ nhỏ chưa?
- bạn có biết cách kiểm tra kết quả không?
- Tôi có đang làm việc trong một môi trường biệt lập không?
- Việc xem xét cuối cùng vẫn nhân văn và cẩn thận?
Một quy trình làm việc lành mạnh trông giống thế này hơn là một cây đũa thần:
Nghe có vẻ kém lãng mạn hơn "người đại diện xây dựng mọi thứ", nhưng nó hoạt động tốt hơn nhiều. Và đó cũng là cách các nhóm hòa hợp với con người làm việc: nhiệm vụ rõ ràng, phản hồi nhanh, trách nhiệm giải trình rõ ràng.
Lời nhắc tốt gần như là một tấm vé tốt
Lời nhắc nguy hiểm nhất là lời nhắc mơ hồ nhưng đầy tự tin: "sửa trang hóa đơn", "cải thiện kiến trúc", "dọn dẹp mô-đun xác thực". Đây là những yêu cầu nghe có vẻ hiệu quả và tạo ra sự khác biệt lớn. Nhưng sau đó bạn thấy mình đang làm khảo cổ học.
Một lời nhắc hữu ích thì nhàm chán hơn. Ví dụ: triển khai xuất CSV cho trang hóa đơn, biết rằng bảng nằm trong app/(dashboard)/invoices/page.tsx, các truy vấn nằm trong src/server/invoices.ts và đã có mẫu tương tự trong app/(dashboard)/reports.
Sau đó, thêm các ràng buộc rõ ràng: không thay đổi lược đồ cơ sở dữ liệu, không thêm phần phụ thuộc nếu một tiện ích nhỏ là đủ, giữ nguyên kiểu giao diện người dùng hiện có. Và kết thúc bằng việc xác minh: npm test -- invoices và npm run build.
Kiểu tóm tắt này không phải để "giải thích rõ hơn cho AI". Trên hết, nó nhằm mục đích giúp bạn hiểu rõ hơn những gì bạn đang ủy quyền. Nếu bạn không thể viết nó ra một cách cụ thể, có thể nhiệm vụ đó chưa sẵn sàng đối với đại lý.
Ba công việc mà tôi sẵn sàng giao phó
Đầu tiên là công việc lặp đi lặp lại nhưng có thể kiểm chứng: thêm thử nghiệm, di chuyển lệnh gọi sang API nội bộ mới, cập nhật nội dung nhập, thay thế các thành phần không dùng nữa, sửa lỗi TypeScript. Ở đây đại lý có thể tiết kiệm thời gian và rủi ro có thể kiểm soát được.
Thứ hai là công việc khám phá: "tìm nơi tính tổng số này", "giải thích cho tôi tại sao thử nghiệm này lại dễ hỏng", "tái tạo lỗi và cho tôi biết tệp nào có vẻ bị ảnh hưởng". Ngay cả khi nó không tạo ra bản vá ngay lập tức, nó vẫn có thể thực hiện công việc trinh sát hữu ích.
Thứ ba là công việc bảo trì định kỳ: cập nhật phần phụ thuộc nhỏ, dọn dẹp các cờ tính năng cũ, tóm tắt các PR bị chặn, kiểm tra các TODO bị quên. Nó không hào nhoáng, nhưng nó chính xác là loại công việc có xu hướng chồng chất.
Ba công việc mà tôi giữ làm người
Các quyết định về sản phẩm vẫn mang tính con người. Nếu một thay đổi làm thay đổi cách người dùng thanh toán, xóa dữ liệu, xem giá hoặc hiểu quyền, tôi cần một người chịu trách nhiệm.
Các ranh giới bảo mật cũng đáng được con người quan tâm: xác thực, vai trò, mã thông báo, ghi nhật ký dữ liệu nhạy cảm, di chuyển cơ sở dữ liệu. Một tác nhân có thể giúp thực hiện nhưng không nhất thiết phải là người ra quyết định duy nhất.
Cuối cùng, tôi giữ lại mọi thứ đòi hỏi gu kiến trúc mang tính con người. Một tác nhân có thể đề xuất một trình tái cấu trúc, nhưng việc hiểu liệu sự trừu tượng hóa có thực sự cần thiết hay không hay liệu chúng ta chỉ đang giải quyết một vấn đề không tồn tại vẫn là một công việc.
Việc xem xét không phải là tùy chọn
Sự cám dỗ, khi một đại lý tốt, là tin tưởng vào màu xanh lá cây của CI. Điều đó có thể hiểu được. Đó cũng là lúc vấn đề bắt đầu.
Tôi luôn xem xét ít nhất năm điều:
- Bản vá chỉ giải quyết được nhiệm vụ được yêu cầu?
- Anh ấy có chạm vào những tập tin không liên quan gì không?
- Các bài kiểm tra có bao gồm hành vi mới lạ hay chỉ là cơ hội may mắn?
- Mã có tuân theo các mẫu địa phương không?
- Các lỗi có được xử lý như trong phần còn lại của dự án không?
Khi có điều gì sai sót, phản hồi cần phải cụ thể. “Sửa nó” là lười biếng. Tốt hơn: tiện ích này sao chép parseMoney thành src/lib/money.ts; sử dụng lại chức năng đó, thêm thử nghiệm cho trường hợp EUR và không thay đổi API công khai của mô-đun thanh toán.
Các đại lý phản hồi tốt hơn nhiều đối với những nhận xét nhỏ, có thể kiểm chứng được. Thật kỳ lạ, mọi người cũng vậy.
Lan can đáng nỗ lực
Nếu một tác nhân có thể đọc tệp, viết mã và thực thi lệnh thì nó phải được coi là một quy trình mạnh mẽ. Không cần hoang tưởng, bạn cần vệ sinh.
Sử dụng cây làm việc hoặc nhánh riêng biệt. Vì vậy, bạn có thể so sánh sự khác biệt, loại bỏ các thử nghiệm thất bại và không trộn lẫn công việc của nhân viên với những gì bạn đang làm.
Giới hạn quyền. Các lệnh như rg, git diff, npm test và npm run build có thể khá miễn phí. Việc triển khai, di chuyển cơ sở dữ liệu, quyền truy cập vào các bí mật và các lệnh phá hoại phải rõ ràng.
Giảm quyền truy cập mạng khi bạn không cần nó. Đối với nhiều nhiệm vụ, tài liệu chính thức, đăng ký gói và các dịch vụ nội bộ cụ thể là đủ. Diện tích bề mặt ít hơn, ít bất ngờ hơn.
Theo dõi hành động. Khi một bản vá được xem xét, bạn sẽ có thể xây dựng lại các lời nhắc, lệnh được thực thi, các bài kiểm tra đã vượt qua và các tệp được sửa đổi. Không phải để tạo ra sự quan liêu mà để có thể hiểu được điều gì đã xảy ra nếu có sự cố xảy ra.
Một cách dễ dàng để bắt đầu với tư cách là một nhóm
Nếu tôi giới thiệu các đặc vụ vào một nhóm nhỏ, tôi sẽ bắt đầu mà không có những cuộc cách mạng lớn.
Tôi sẽ tạo nhãn agent-ready cho các vấn đề có phạm vi rõ ràng. Tôi sẽ thêm một mẫu có ngữ cảnh, các ràng buộc và các lệnh xác minh. Tôi sẽ yêu cầu PR nhỏ, lý tưởng nhất là dưới vài trăm dòng. Tôi sẽ yêu cầu kiểm tra hoặc chụp ảnh màn hình để biết những thay đổi rõ ràng. Và trên hết tôi sẽ để một người chịu trách nhiệm về việc sáp nhập.
Sau hai tuần, tôi sẽ xem xét dữ liệu: tác vụ nào thực sự được tăng tốc, bài đánh giá nào nặng nề, lời nhắc nào khó hiểu, phần nào của cơ sở mã quá mỏng manh để ủy quyền.
Đó là một cách tiếp cận kém ngoạn mục hơn so với "từ hôm nay chúng tôi sẽ làm mọi thứ với các đại lý", nhưng đó là cách cho phép bạn bước sang tuần thứ ba mà không phải hối tiếc.
Phần con người nhất
Điều buồn cười là các tác nhân càng trở nên tự chủ thì các kỹ năng cổ điển càng trở nên quan trọng: viết một phiếu yêu cầu tốt, thực hiện các bước cắt nhỏ, thực hiện các bài kiểm tra, đọc các điểm khác biệt, truyền đạt sự đánh đổi. Đại lý tăng tốc cho những người đã biết làm việc tốt. Nó cũng khuếch đại sự hỗn loạn của những người giao việc không tốt.
Vì vậy, không, tôi không coi quy trình làm việc đa tác nhân là lối tắt để ngừng thực hiện kỹ thuật. Tôi coi chúng như một cách để chuyển nhiều năng lượng hơn sang những phần quan trọng: quyết định xây dựng cái gì, đảm bảo nó hoạt động, giữ cho hệ thống dễ hiểu.
Đại lý có thể trở thành đồng nghiệp không đồng bộ tuyệt vời. Nhưng để một đồng nghiệp không đồng bộ trở nên hữu ích, cần phải có bối cảnh, ranh giới và sự đánh giá. Cũng giống như những người khác.