hãy giao cho Claude một nhiệm vụ đủ lớn và nó sẽ bỏ dở giữa chừng, tự tin rằng nó đã hoàn thành. công việc chưa xong. nó chỉ không nhớ rằng mình đã bắt đầu.
một agent không làm việc với một nhiệm vụ dài hơi theo cách bạn nghĩ. nó làm việc theo ca.
hãy tưởng tượng một dự án phần mềm với đội ngũ kỹ sư làm việc theo ca, nơi mỗi người mới đến không hề biết chuyện gì đã xảy ra trong ca trước. đó không phải là phép ẩn dụ cho cảm giác của các agent. về mặt kỹ thuật, chúng đúng là như vậy. cửa sổ ngữ cảnh có hạn, hầu hết công việc thực tế không nằm gọn trong một cửa sổ, vì vậy agent làm việc trong các phiên riêng biệt - và mỗi phiên mới bắt đầu mà không có ký ức về phiên trước đó.
Anthropic đã thực hiện chính xác thí nghiệm này và công bố những gì đã hỏng. đó là phần đáng đọc, bởi vì nó không phải là một blogger nói rằng công cụ này yếu. đó là nhóm phát triển Claude ghi lại những điểm Claude thất bại.
Tại Sao Một Cửa Sổ Không Thể Hoàn Thành Công Việc
hãy giao cho một mô hình mã nguồn tiên tiến một prompt cấp cao - "xây dựng một bản sao của claude.ai" - đặt nó trong một vòng lặp qua nhiều cửa sổ ngữ cảnh, và nó sẽ thất bại trong việc tạo ra một ứng dụng hoạt động. không phải thỉnh thoảng, mà là chắc chắn. và đây là Opus chạy trên framework agent của chính Anthropic, với tính năng nén ngữ cảnh được bật, toàn bộ thiết lập được xây dựng để giữ cho nó tiếp tục.
nó thất bại theo hai cách cụ thể, và cả hai đều là vấn đề về bàn giao ca.
cách thứ nhất: agent cố gắng làm mọi thứ cùng một lúc. nó cố gắng hoàn thành toàn bộ ứng dụng trong một cửa sổ duy nhất, hết ngữ cảnh giữa chừng khi đang xây dựng một tính năng, và phiên làm việc kết thúc với một thứ nửa vời và không có tài liệu. ca tiếp theo vào việc, thấy một mớ hỗn độn mà nó không tạo ra, và phải đoán xem chuyện gì đang xảy ra. vì vậy nó dành toàn bộ phiên của mình chỉ để làm cho ứng dụng cơ bản hoạt động trở lại, thay vì tiến lên phía trước.
cách thứ hai xuất hiện sau đó, khi một số tính năng đã tồn tại. một agent mới nhìn quanh, thấy rằng đã có tiến triển thực sự, và quyết định rằng mọi thứ đã hoàn thành. nhưng thực tế không phải vậy - một nửa số tính năng chưa bao giờ được xây dựng, và không ai ghi lại cái nào. ca đó cho rằng đã xong việc mà không kiểm tra danh sách.
cả hai thất bại đều có cùng một gốc rễ. ca đi không để lại gì, vì vậy ca đến đang bay mù. giải pháp không phải là một mô hình thông minh hơn. đó là những gì ca đi ghi lại trước khi kết thúc ca.
Những Gì Ca Đi Ghi Lại
câu trả lời mà Anthropic tìm ra có hai phần: một agent thiết lập trang web trước khi bất kỳ công việc nào bắt đầu, và sau đó các công nhân theo ca xuất hiện hết phiên này đến phiên khác để tạo ra tiến triển.
agent thiết lập chạy một lần, ngay từ đầu. toàn bộ công việc của nó là để lại môi trường ở trạng thái mà mọi ca trong tương lai đều biết "hoàn thành" trông như thế nào. phần quan trọng mà nó viết là một danh sách tính năng - một tệp có cấu trúc nêu rõ từng thứ một mà ứng dụng hoàn chỉnh cần phải làm.
đối với bản sao claude.ai, điều đó có nghĩa là hơn 200 tính năng. những thứ như "người dùng có thể mở một cuộc trò chuyện mới, gõ truy vấn, nhấn Enter và thấy phản hồi." mỗi tính năng đều được đánh dấu là thất bại ngay từ đầu. mỗi mục nhập trông đại khái như thế này:
1{2 "description": "Nút trò chuyện mới tạo một cuộc trò chuyện mới",3 "steps": ["nhấp vào Trò chuyện mới", "xác minh cuộc trò chuyện mới", "kiểm tra trạng thái chào mừng"],4 "passes": false5}
"passes": false trên mỗi mục nhập chính là toàn bộ vấn đề. đó là một ô chưa được đánh dấu, và có 200 ô như vậy.
danh sách thất bại đó là thứ ngăn một agent tuyên bố chiến thắng sớm. một ca không thể nhìn quanh và quyết định rằng công việc đã xong, bởi vì có một tệp nằm ngay đó với 200 ô chưa được đánh dấu. công việc được xác định trước khi dòng đầu tiên của nó được viết.
một chi tiết nhỏ cho bạn thấy điều này phải cẩn thận đến mức nào: họ đã sử dụng JSON cho tệp đó, không phải markdown. lý do là mô hình ít có khả năng âm thầm viết lại hoặc xóa một tệp JSON hơn là một tệp markdown. và các hướng dẫn xung quanh nó có chủ đích thẳng thừng - việc xóa hoặc sửa đổi bài kiểm tra là không thể chấp nhận được, bởi vì xóa một bài kiểm tra là cách một tính năng âm thầm biến mất. ca được phép đánh dấu một ô. nó không được phép xóa một ô.
Ghi Chú Trên Bàn
thiết lập công việc là một nửa của vấn đề. nửa còn lại là đảm bảo mỗi ca để lại nơi làm việc đủ sạch sẽ cho ca tiếp theo bước vào.
hai điều làm được điều đó. agent commit công việc của nó vào git với một thông điệp thực tế mô tả những gì đã thay đổi, và nó viết một tệp tiến độ đơn giản - một nhật ký chạy về những gì đã được thực hiện. nhật ký đó cùng với lịch sử git là thứ cho phép một agent mới, bắt đầu từ đầu, hiểu được trạng thái của mọi thứ trong vài phút thay vì mất một giờ để dịch ngược.
git cũng làm một điều khác ở đây. khi một ca thực hiện một thay đổi tồi, ca tiếp theo có thể rollback về phiên bản hoạt động cuối cùng thay vì cố gắng gỡ rối thiệt hại. tệp tiến độ cho biết chúng ta đang ở đâu. lịch sử commit là nút hoàn tác.
và "sạch sẽ" có một ý nghĩa cụ thể. nó có nghĩa là loại mã mà bạn sẽ sẵn sàng merge vào một nhánh chính - không có lỗi lớn, có trật tự, có tài liệu. không phải "về mặt kỹ thuật là tôi đã có tiến triển." tiêu chuẩn là: người tiếp theo có thể bắt đầu một tính năng mới mà không cần dọn dẹp mớ hỗn độn của bạn trước.
Cách Ca Tiếp Theo Vào Việc
đặt hai thứ đó vào vị trí và mỗi ca đều bắt đầu theo cùng một cách. trước khi chạm vào bất cứ điều gì mới, agent chạy một quy trình mở đầu cố định để định hướng - điều tương tự mà một kỹ sư giỏi làm khi bước vào một dự án mà họ chưa thấy trong một thời gian dài.
1chạy pwd để xem bạn đang ở thư mục nào - đó là nơi duy nhất bạn có thể chỉnh sửa2đọc tệp tiến độ và nhật ký git để xem những gì vừa xảy ra3đọc danh sách tính năng và chọn thứ ưu tiên cao nhất chưa được hoàn thành4khởi động ứng dụng và chạy kiểm tra cơ bản xem các tính năng cốt lõi còn hoạt động không5chỉ sau đó, mới bắt đầu xây dựng
bước thứ tư quan trọng hơn vẻ ngoài của nó. trước khi viết một tính năng mới nào, agent khởi động ứng dụng và xác nhận các chức năng cơ bản vẫn hoạt động - mở một cuộc trò chuyện, gửi một tin nhắn, nhận được phản hồi. nếu ca trước để lại thứ gì đó bị hỏng, điều này sẽ phát hiện ra ngay lập tức, trước khi ca mới chất thêm công việc mới lên một nền móng hỏng và làm cho mọi thứ tồi tệ hơn.
đây là toàn bộ thủ thuật, và nó gần như nhàm chán vì đơn giản đến mức nào. ca đi ghi lại những gì nó đã làm và những gì còn lại. ca đến đọc điều đó trước khi làm bất cứ điều gì. việc bàn giao là toàn bộ trò chơi.
Các Nhiệm Vụ Dài Hơi Của Bạn Cũng Có Ca
không có điều nào trong số này thực sự là về việc xây dựng ứng dụng web. Anthropic đã thử nghiệm nó trên mã nguồn vì mã nguồn dễ kiểm chứng, nhưng hình dạng bên dưới là hình dạng của mọi nhiệm vụ dài hơi mà bạn giao cho một agent.
bất cứ thứ gì không nằm gọn trong một cửa sổ đều có ca. viết một báo cáo dài từng chương một. chạy một dự án nghiên cứu qua hàng tá cuộc trò chuyện. làm việc thông qua một phân tích lớn trong nhiều ngày. mỗi lần bạn bắt đầu một phiên mới trên cùng một nhiệm vụ, một công nhân mới đang vào việc mà không có ký ức về người trước - và nếu bạn không để lại một sự bàn giao, nó sẽ bắt đầu bằng cách phỏng đoán.
vì vậy, hãy để lại một cái. trước khi một phiên dài kết thúc, hãy yêu cầu mô hình ghi lại những gì đã được thực hiện, những gì vẫn còn mở, và phiên tiếp theo nên bắt đầu với cái gì. giữ ghi chú đó ở một nơi mà nó có thể đọc được khi vào việc. đó là sự khác biệt giữa một dự án tiến triển qua mỗi phiên và một dự án cứ xây đi xây lại cùng một thứ.
cùng một mô hình tối nay và ngày mai. điều duy nhất thay đổi là liệu phiên ngày mai bước vào trong mù mịt, hay bước vào đọc ghi chú của đêm qua.
vấn đề chưa bao giờ là về mức độ thông minh của ca. mà là về những gì nó để lại cho người đến sau.
thêm những phân tích như thế này - https://t.me/+xYv1MgmIuds5YTli
