Giảm hạn mức Claude Code: Liệu các tác nhân có đang tạo ra những “ngọn núi mã kế thừa” mới?

Việc kéo dài hạn mức hàng tuần của Claude Code thu hút sự chú ý, bài viết phân tích cơ chế tiêu tốn Token của chương trình Agent. Việc Agent chạy trong thời gian dài sẽ khiến working set liên tục phình to, từng bước tích lũy trạng thái lịch sử, cộng với đặc điểm vẫn chiếm dụng context ngay cả sau khi cache hit, khiến chi phí tính toán tăng tích lũy. Xóa bỏ quá nhiều sẽ gây ra “thiếu trang ngữ nghĩa”, buộc Agent phải lấy lại thông tin. Bài viết chỉ ra sự không nhất quán giữa trạng thái mã và độ chính xác lưu trữ trạng thái thiết kế có thể dẫn đến việc AI tạo ra “mã truyền thống”: các Agent sau này không thể hiểu được nguyên nhân - hệ quả trong thiết kế mã giai đoạn đầu, cuối cùng hình thành mã phức tạp với queue, bypass, retry bù đắp lẫn nhau.

Tác giả bài viết, nguồn: LeFengwang

Mã thực sự do Agent viết ra, nhưng các Agent sau này đã không còn biết tại sao Agent trước đó lại viết như vậy.

Mức tăng 50% cho hạn mức tuần của Claude Code, vốn dự kiến kết thúc vào ngày 19 tháng 8, đã được Anthropic kéo dài đến ngày 31 tháng 8. Vào khoảng thời gian trước và sau ngày kết thúc ban đầu, một cuộc thảo luận về chi phí sử dụng Claude Code đã xuất hiện trên Hacker News: nhiều người phát hiện rằng, ngay cả một nhiệm vụ không quá phức tạp, khi Agent chạy vài vòng, hạn mức đã giảm nhanh chóng.

Vấn đề nằm ở chỗ, Claude Code không chỉ tiêu tốn những dòng mã cuối cùng được tạo ra. Việc đọc tệp, tìm chuỗi gọi, chạy kiểm thử và xử lý nhật ký, mỗi bước đều tiếp tục bổ sung vào ngữ cảnh sau đó. Nhiệm vụ càng dài, lịch sử mà Agent phải mang theo càng nặng, hệ thống cũng càng phụ thuộc vào việc làm sạch và nén.

Mã nguồn có thể được giữ nguyên đầy đủ trong kho lưu trữ, nhưng lý do thiết kế ban đầu có thể dần mờ nhạt trong quá trình nén. Vì vậy, việc tiêu hao Token và đống mã rác bắt đầu hội tụ tại cùng một nơi.

Giới hạn tính toán của Chat coding thông thường rất rõ ràng. Nhập một đoạn mã, mô hình đọc xong sẽ đưa ra giải thích hoặc phương án sửa đổi, vòng lặp này cơ bản kết thúc.

Đơn vị cơ bản của Claude Code đã được thay đổi thành vòng lặp agent. Mô hình trước tiên quan sát trạng thái hiện tại, quyết định tệp nào cần đọc hoặc lệnh nào cần thực hiện; sau khi công cụ trả về kết quả, mô hình sẽ thực hiện vòng phán đoán tiếp theo.

Đọc mã nguồn, tìm kiếm tham chiếu, chạy kiểm thử, xem Git diff, sửa đổi tệp — trông giống như một hành động liên tục, nhưng trên phía mô hình thực chất là một chuỗi các yêu cầu suy luận độc lập. Tài liệu chính thức của Claude Code cũng coi chu trình “mô hình đưa ra phán đoán — gọi công cụ — dựa trên kết quả tiếp tục phán đoán” này là cốt lõi trong cách thức hoạt động của Agent.

Ví dụ như một vấn đề trạng thái đăng nhập bị mất ngẫu nhiên. Agent trước tiên tìm điểm vào, phát hiện trạng thái đến từ service, nên tiếp tục đọc service; thấy bộ nhớ đệm thì tìm xem ai đang ghi vào nó; sau đó chạy kiểm thử, kiểm thử phát sinh một ngoại lệ khác, nên xem fixture; sửa xong rồi kiểm tra lại, kiểm thử cũ lại phơi bày vấn đề tương thích.

Có thể đến lúc này, nó mới thực sự bắt đầu viết những dòng mã đó. Do đó,diff giữa kích thước thay đổi và khối lượng tính toán gần như không có tỷ lệ ổn định. Một patch 5 dòng có thể chỉ trải qua 3 lần suy luận, hoặc đã qua 30 lần tương tác công cụ.

Nếu chia một nhiệm vụ Agent thành các phần, bạn có thể nhận được hai biến: một là số bước, tức là Agent đã thực hiện bao nhiêu bước để hoàn thành nhiệm vụ;另一个 là tập làm việc, tức là khi đạt đến bước hiện tại, mô hình cần nắm giữ bao nhiêu trạng thái mục tiêu.

Chỉ tăng số bước đã đủ làm tăng mức tiêu thụ. Nếu working set vẫn đang tiếp tục mở rộng trong quá trình đồng bộ, tình huống sẽ hoàn toàn khác biệt. Bước thứ 3 có thể chỉ cần xử lý vài nghìn Token, nhưng bước thứ 30 có thể đã mang theo quy tắc dự án, mã nguồn liên quan, kết quả kiểm thử, lịch sử chỉnh sửa và công cụ để tiếp tục suy luận.

Đây cũng là điểm khởi đầu cho sự thay đổi trong cơ cấu chi phí của Coding Agent: lượng tính toán bắt đầu phụ thuộc vào “số bước đi × trọng lượng mỗi bước”, thay vì phụ thuộc vào số dòng mã đã viết.

Chia một yêu cầu mô hình của Agent thành các phần, có thể xem sơ bộ thành ba khối. Các phần tương đối ổn định bao gồm system prompt, CLAUDE.md, định nghĩa công cụ và quy tắc dự án; các phần thay đổi liên tục bao gồm tệp mã, kết quả tìm kiếm, nhật ký kiểm thử, Git diff và lịch sử nhiệm vụ trước đó; cuối cùng là phần lý luận, văn bản và mã do mô hình tạo ra trong vòng này.

Ở đây dễ xảy ra một hiểu lầm: chỉ cần nội dung phía trước đã được đọc qua, thì không nên tạo ra quá nhiều chi phí lặp lại. Vấn đề nằm ở chỗ, LLM không có bộ nhớ nội bộ có thể truy cập tùy ý giữa hai lần yêu cầu như một chương trình truyền thống. Thông tin được biết trong vòng trước đó, nếu vòng tiếp theo vẫn phụ thuộc vào nó, thì trạng thái liên quan vẫn phải tiếp tục xuất hiện trong context khả dụng.

Prompt cache có thể làm giảm vấn đề này. Tài liệu chính thức của Claude Code nêu rõ rằng, nếu không có cache prompt, mỗi yêu cầu đều cần xử lý lại toàn bộ lịch sử; sau khi cache được sử dụng, các tiền tố ổn định đã được xử lý có thể được tái sử dụng, từ đó giảm thiểu tính toán và chi phí lặp lại.

Nhưng bộ nhớ đệm giải quyết vấn đề “liệu có thể tái sử dụng lại lịch sử giống nhau với chi phí thấp hơn không”, chứ không giải quyết vấn đề “liệu lịch sử này còn cần tiếp tục tồn tại không”. Sau khi trạng thái cũ của 100K Token được tìm thấy trong bộ nhớ đệm và giảm chi phí, nó vẫn chiếm dụng context và vẫn là trạng thái trên đó quá trình suy luận hiện tại được xây dựng.

Do đó, có thể mô tả sơ bộ một nhiệm vụ dài như sau: kích thước đầu vào ở bước t khoảng bằng tiền tố ổn định S, cộng với tập công việc hiệu quả hiện tại W_t, cộng thêm thông tin mới được tạo ra trong vòng này Δ_t.

Điều thực sự gây phiền toái là W_t. Nếu mỗi bước đi, Agent lại đọc thêm một chút mã nguồn, thu thêm một chút nhật ký và để lại một quyết định mới, trong khi thông tin cũ không được xóa kịp thời, thì W_t sẽ liên tục tăng lên theo tiến trình của nhiệm vụ.

Trong một mô hình cực kỳ đơn giản hóa, không có bộ nhớ đệm và dọn dẹp nào, nếu mỗi vòng thêm vào một lượng trạng thái hợp lệ gần như tương đương, tổng lượng xử lý sẽ tạo thành cấu trúc tích lũy gần với 1 + 2 + 3 + … + n. Nói cách khác, số bước chỉ tăng gấp đôi, nhưng tổng số trạng thái lịch sử đã được xử lý có thể tăng nhanh hơn nhiều.

Hệ thống thực tế có cache, chỉnh sửa context và nén, nên không tuân theo đường cong tăng trưởng này một cách máy móc, nhưng hình dạng của vấn đề không thay đổi: càng chạy lâu, mỗi hành động mới của Agent càng có khả năng dựa trên một khối lịch sử nặng nề hơn.

Vì vậy, prompt người dùng rất ngắn trong các tác vụ dài sẽ nhanh chóng mất đi sự hiện diện. Điều thực sự bắt đầu chi phối chi phí là tập công việc mà mô hình phải liên tục mang theo để duy trì tính liên tục của tác vụ.

Tại sao working set lại tăng nhanh như vậy, công cụ đầu ra là một nguồn lớn. Mã nguồn ít nhất có cấu trúc, còn nhật ký thường không có.

Một lần grep có thể trả về hàng trăm tham chiếu, một lần xây dựng có thể tạo ra hàng loạt cảnh báo, một lần kiểm tra thất bại có thể kèm theo toàn bộ stack trace, Docker, trình biên dịch và trình quản lý gói cũng tạo ra rất nhiều văn bản không có giá trị lâu dài cho nhiệm vụ.

Giả sử bước kiểm tra thứ 10 tạo ra nhật ký 8K Token. Khi lần đầu tiên được đưa vào context, nó chỉ là 8K Token. Tuy nhiên, Agent vẫn cần tiếp tục kiểm tra mã nguồn, chỉnh sửa và kiểm tra lại; miễn là nhật ký này vẫn nằm trong lịch sử hợp lệ, nó sẽ làm tăng trọng số cơ sở cho nhiều yêu cầu sau đó.

Điều này rất giống với hiện tượng write amplification trong hệ thống lưu trữ: một lần ghi logic gây ra nhiều xử lý nền hơn sau đó. Trong trường hợp của Agent, một lần đầu ra công cụ được ghi vào lịch sử thực thi, sau đó di chuyển cùng với các bước suy luận tiếp theo.

Do đó, cùng là 8K Token, đặt vào vòng trước khi kết thúc nhiệm vụ và đặt vào lúc bắt đầu nhiệm vụ sẽ mang lại ảnh hưởng tổng thể hoàn toàn khác nhau. Claude Code hiện cũng đang chủ động giảm thiểu sự ô nhiễm này. Chính thức khuyến nghị sử dụng sub-agent để cô lập các nhiệm vụ có đầu ra cao, đồng thời rõ ràng nêu rằng kết quả tìm kiếm, nhật ký và nội dung tệp lớn sẽ tiêu tốn context của phiên chính; chính định nghĩa công cụ cũng chiếm không gian, do đó bộ công cụ quá lớn cũng sẽ làm tăng gánh nặng trạng thái.

Nhưng ở đây lại xuất hiện một vấn đề ngược lại: không thể vì nhật ký quá đắt nên loại bỏ tất cả chúng. Trong một đoạn nhật ký 3000 dòng, có thể chỉ có 20 dòng liên quan đến nguyên nhân gốc. Hệ thống không biết trước đó là 20 dòng nào. Nếu dọn dẹp quá sớm, Agent sau này nếu cần một chi tiết cụ thể nào đó, chỉ có thể chạy lại bài kiểm tra hoặc mở lại tệp.

Điều này có thể được gọi là semantic page fault, thiếu trang ngữ nghĩa. Trong bộ nhớ ảo truyền thống, khi chương trình truy cập một trang đã không còn trong bộ nhớ, hệ thống sẽ tải lại từ đĩa; tương tự, khi Coding Agent loại bỏ một số bằng chứng sớm, hiện tượng tương tự cũng xảy ra, chỉ là biểu hiện dưới dạng tìm kiếm lại kho lưu trữ, đọc lại tệp tin, chạy lại lệnh, hoặc thậm chí suy luận lại một vấn đề đã được phân tích trước đó.

Do đó, nhiệm vụ dài bị mắc kẹt trong tình thế tiến thoái lưỡng nan: lưu lại quá nhiều lịch sử khiến từng bước tiếp theo ngày càng nặng nề; nếu dọn dẹp quá tích cực, Agent lại liên tục lấy lại các thông tin đã từng thấy trước đó.

Điều này cũng giải thích tại sao quản lý ngữ cảnh không thể đơn giản hóa thành “giảm bớt Token”. Vấn đề thực sự cần giải quyết là lựa chọn tập làm việc: những thông tin nào hiện tại phải được giữ lại trong vùng làm việc, và những thông tin nào chỉ là sản phẩm trung gian đã hoàn thành nhiệm vụ.

Tới đây, compaction, memory và sub-agent mới thực sự có lý do tồn tại.

Claude Code khi gần đến giới hạn context sẽ tự động nén phiên làm việc và đồng thời xóa một số kết quả công cụ cũ hơn. Nhà phát hành cũng lưu ý rằng các cuộc hội thoại không liên quan, nội dung tệp và kết quả lệnh trong phiên dài có thể làm đầy cửa sổ và gây nhiễu đến hiệu suất mô hình.

Từ góc độ hệ thống, compaction giống như một lần thu gom rác mang tính ngữ nghĩa. Vấn đề nằm ở chỗ, thu gom rác thông thường đánh giá “đối tượng này còn có tham chiếu nào không”, trong khi Agent phải xác định “thông tin này có còn ý nghĩa trong tương lai không”.

Sau này khó hơn nhiều. Ví dụ, trong giai đoạn đầu có một kết luận thiết kế như sau: một module không thể tự lưu bộ nhớ đệm trạng thái người dùng, vì hệ thống yêu cầu trạng thái chỉ có một chủ sở hữu và mọi thay đổi đều phải đi qua service.

Sau vài chục bước, nếu thông tin này được tóm tắt thành: “Vấn đề trạng thái đã được giải quyết thông qua điều chỉnh service.” Thực tế không sai, nhưng thông tin đã thay đổi. Nội dung gốc chứa constraint, trong khi bản tóm tắt sau này chỉ lưu lại event.

Lần tiếp theo Agent gặp vấn đề hiệu năng, thấy gọi dịch vụ chậm, rất có thể lại thêm bộ nhớ đệm vào mô-đun. Nó không vi phạm thông tin hiện tại mà nó nắm giữ; mối quan hệ nhân quả từng cấm bộ nhớ đệm đã không còn hiệu lực.

Tài liệu ngữ cảnh của Claude Code thậm chí còn chỉ rõ rằng một số quy tắc được giới hạn theo đường dẫn và CLAUDE.md lồng ghép sẽ bị nén và tóm tắt theo phiên hội thoại, và cần đọc lại tệp phù hợp để tải lại.

Memory cố gắng giải quyết vấn đề lưu trữ kiến thức dài hạn. Các tệp CLAUDE.md và auto memory trong thư mục gốc dự án có thể trích xuất các lệnh xây dựng, thông số kỹ thuật dự án, kinh nghiệm gỡ lỗi khỏi các cuộc hội thoại ngắn hạn và tải lại chúng khi bắt đầu phiên trò chuyện. Tuy nhiên, Anthropic cũng đã nêu rõ vị trí của chúng: những memory này vẫn là context, không phải cấu hình bắt buộc.

Sự khác biệt này rất quan trọng. Nếu chỉ ghi “Không thể truy cập trực tiếp cơ sở dữ liệu tại đây” vào bộ nhớ, nó vẫn chỉ là một câu ngôn ngữ tự nhiên mà mô hình cần hiểu và tuân theo. Nếu cùng một quy tắc này được viết dưới dạng dependency lint, ràng buộc kiểu dữ liệu hoặc kiểm tra CI, nó mới trở thành một bất biến phần mềm không thể dễ dàng bỏ qua.

Sub-agent giải quyết một khía cạnh khác: cô lập tập làm việc. Việc để một Agent độc lập quét kho lưu trữ hoặc phân tích nhật ký dài, sau đó trả lại kết quả đã nén cho Agent chính, có thể ngăn ngừa nhiễu gốc xâm nhập vào luồng chính. Một trong những mục đích được Claude Code đưa ra cho sub-agent chính là cô lập ngữ cảnh.

Chi phí của nó cũng rất thú vị: Agent chính nhận được trạng thái sạch sẽ hơn, nhưng lại mất đi một phần bằng chứng gốc; khi nhiều Agent chạy đồng thời, chúng sẽ tạo ra các context riêng biệt. Do đó, khi xem xét cùng nhau, compaction, memory và sub-agent thực chất đã rất giống một cấp bộ nhớ thời kỳ Agent:

Context hiện tại là bộ nhớ làm việc đắt tiền, compaction chịu trách nhiệm nén, memory lưu trạng thái xuyên phiên, sub-agent sử dụng không gian địa chỉ độc lập để cô lập nhiễu. Vấn đề cũng đã chuyển từ “context có đủ lớn không” sang một cấp độ khác:

Những trạng thái nào cần được lưu giữ với độ trung thực cao, những trạng thái nào chỉ cần lưu lại bản tóm tắt. Câu hỏi này sẽ ảnh hưởng trực tiếp đến chất lượng mã sau này.

Sau khi hiểu cấu trúc thực thi phía trên, khi xem xét hạn mức hàng tuần của Claude Code, sẽ thấy rằng nền tảng khó có thể tiếp tục tính toán Agent theo “số tin nhắn”, vì một tin nhắn đã mất đi ý nghĩa ổn định.

Đổi tên biến là một tin nhắn,重构整个认证模块 cũng là một tin nhắn.前者 có thể kết thúc trong vài bước,后者 có thể chạy hàng chục vòng, đọc hàng chục tệp tin, rồi khởi động nhiều Agent. Cùng một request, nhu cầu tài nguyên phía sau có thể hoàn toàn không cùng mức độ.

Claude Code đóng gói việc giới hạn cuộn và hạn mức hàng tuần; Codex hiện đã rõ ràng tính credits dựa trên input token, cached input token và output token; các gói của Cursor cung cấp các pool sử dụng khác nhau cho Agent, và việc tiêu thụ mô hình bên thứ ba sẽ chịu ảnh hưởng bởi giá API mô hình.

Giao diện của ba sản phẩm có ngôn ngữ khác nhau, nhưng vấn đề cốt lõi cần giải quyết lại rất gần nhau: làm thế nào để phân bổ tài nguyên suy luận cho một chương trình thông minh mà đường dẫn thực thi không thể xác định trước. Một Coding Agent sẽ chạy trong bao lâu khó có thể xác định ngay từ khi bắt đầu nhiệm vụ.

Mô hình có thể nhanh chóng tìm ra nguyên nhân gốc rễ, hoặc đưa ra một loạt giả định sai; có thể vượt qua chỉ sau một lần kiểm tra, hoặc rơi vào vòng lặp debug kéo dài; có thể chỉ cần một Agent, hoặc tách ra thành nhiều sub-agent.

API truyền thống thích tính phí theo yêu cầu vì sự biến động tài nguyên của một yêu cầu vẫn có thể kiểm soát trong phạm vi nhất định. Agent đã làm tan rã sự ổn định này. Do đó, Token ở đây bắt đầu mang một chút sắc thái thời gian CPU.

Sự so sánh này không thể coi là tương đương. Các mô hình khác nhau có chi phí tính toán khác nhau khi xử lý cùng một lượng token, và chi phí cho input, cached input và output cũng khác nhau. Nhưng ở phía nhà phát triển, chức năng của chúng ngày càng trở nên tương tự: đều mô tả lượng tài nguyên tính toán bị tiêu tốn để một nhiệm vụ tiếp tục chạy.

Khi Anthropic tăng giới hạn sử dụng Claude Code trong năm nay, họ cũng trực tiếp liên kết việc tăng hạn mức với việc bổ sung công suất tính toán. Điều này sẽ mang lại một sự thay đổi chỉ số rất thú vị. Trước đây, khi xem xét Coding Agent, người ta thường so sánh “ai giải được cùng một bài toán trong một lần viết tốt hơn”. Về sau, có thể điều mang ý nghĩa hơn là: hoàn thành cùng một thay đổi trạng thái dự án, ai tiêu tốn ít tính toán hiệu quả hơn.

Nếu một Agent tiêu tốn một lượng lớn Token chỉ để lặp lại việc mở tệp, chạy lại bài kiểm tra và khôi phục lại ngữ cảnh đã bị mất, thì những Token đó đã không mang lại sự tiến bộ tương ứng trong quá trình kỹ thuật.

Và tình trạng phục hồi kém hiệu quả này đúng lúc sẽ gặp phải nợ kỹ thuật ở tầng dưới.

Ở đây, một phần mềm được duy trì bởi một Coding Agent có thể được trừu tượng thành hai trạng thái cùng phát triển. Một là trạng thái mã R_t. Các tệp, kiểu dữ liệu, giao diện, bài kiểm tra, Git commit đều thuộc lớp này. Dòng retry mà Agent thêm vào ở bước thứ 20, nếu chưa bị xóa, thì khi mở tệp ở bước thứ 100 vẫn còn nguyên vẹn. Mã nguồn lưu trữ chính xác các thay đổi trong quá khứ.

Một bộ khác là trạng thái thiết kế M_t. Tại sao ở đây cần retry, tại sao bộ nhớ đệm chỉ có thể đặt trong service, tại sao trạng thái này không thể có hai chủ sở hữu, tại sao phép kiểm tra dường như thừa thãi này hiện tại không thể xóa bỏ, những thông tin này thuộc về nguyên nhân - hệ quả thiết kế.

M_tKhông có cách lưu trữ không mất mát tự nhiên như Git. Nó được phân tán trong các cuộc hội thoại, suy luận, kết quả công cụ, bộ nhớ, tệp quy tắc và tóm tắt nén. Sau khi nhiệm vụ tiếp tục tiến triển, một số nội dung đã bị xóa, một số đã được tóm tắt, và một số cần được truy xuất lại.

Do đó sẽ tạo ra một sự bất đối xứng rất quan trọng: kết quả đạt được có thể được tích lũy với độ trung thực cao, trong khi các mối quan hệ nhân quả tạo ra những kết quả này lại liên tục bị giảm mẫu. Điều này nghiêm trọng hơn nhiều so với việc chỉ đơn giản nói rằng “Agent sẽ quên đi những thứ”.

Trong một sự cố đồng thời, sau khi phân tích, Agent đã thêm vào một hàng đợi. Lúc đó, kết luận đầy đủ mà nó nắm được là: chỉ có đường ghi A tồn tại cạnh tranh, do đó hàng đợi chỉ có thể bao gồm A; đường ghi B cần độ trễ thấp và không thể đưa vào hàng đợi này.

Mã đã lưu toàn bộ queue. Sau khi thực thi trong thời gian dài, trạng thái thiết kế có thể chỉ còn lại “sử dụng queue để giải quyết race condition”.

Sau đó, B cũng xuất hiện một lỗi ngẫu nhiên. Khi Agent đọc lại mã, họ một cách tự nhiên đã kết nối B vào hàng đợi hiện có.

Sau đó, độ trễ tăng lên, nên thêm bypass. Bypass lại gây ra tình trạng bất nhất ngẫu nhiên, nên bổ sung retry ở bên ngoài. Đến đây, không có lần sửa đổi nào là hoàn toàn phi lý. Mỗi bản vá đều có thể trông rất hợp lý trong trạng thái cục bộ tại thời điểm đó. Nhưng mã đã từ “một mô hình đồng thời rõ ràng” trở thành sự bù trừ lẫn nhau giữa queue, bypass và retry.

Bãi rác mã AI rất có thể đã hình thành theo cách này. Nó không nhất thiết thể hiện dưới dạng mô hình đột ngột tạo ra một đống rác, mà có thể thể hiện qua việc các phần nhỏ đúng liên tục tích lũy, trong khi mô hình tổng thể dần dần biến mất.

Trong phần mềm truyền thống, những vấn đề này thường hình thành dần qua quá trình chuyển giao nhân sự. Người viết ban đầu rời đi, các nhà phát triển mới nhìn vào mã cũ nhưng không biết tại sao nó tồn tại, nên họ thêm vào một lớp logic tương thích bên ngoài.

Coding Agent đã chuyển “giao tiếp nhân sự” thành “giao tiếp ngữ cảnh”. Bước thứ 20 và bước thứ 100 vẫn trông như cùng một phiên Claude Code, nhưng trạng thái thiết kế mà chúng nhận được đã không còn hoàn toàn giống nhau. Về mặt thông tin, nó giống như hai kỹ sư đang duy trì cùng một kho lưu trữ thông qua một tài liệu giao tiếp ngày càng bị rút ngắn.

Kiểm thử chỉ có thể giải quyết một phần trong số đó. Kiểm thử giỏi trong việc bảo vệ hành vi: giao diện nên trả về gì, một số đầu vào không được gây sụp đổ, các lỗi trước đây không được xuất hiện lại. Nhiều ràng buộc kiến trúc lại không tự nhiên thể hiện dưới dạng đầu vào đầu ra.

Chỉ có một chủ sở hữu cho trạng thái, lớp lĩnh vực không được phụ thuộc ngược lại vào UI, một package nào đó không được kết nối trực tiếp với cơ sở dữ liệu, mọi thao tác ghi đều phải đi qua ranh giới giao dịch thống nhất; những ràng buộc này nếu chỉ tồn tại trong tài liệu hoặc bộ nhớ của Agent thì rất dễ bị bỏ qua trong các lần sửa chữa cục bộ.

Kết quả sẽ dẫn đến một trạng thái kỹ thuật rất rắc rối: bài kiểm tra vẫn xanh, nhưng mã nguồn ngày càng khó giải thích. Nguy hiểm hơn, ở đây tồn tại vòng lặp phản hồi.

Kiến trúc bắt đầu trở nên hỗn loạn, lần tiếp theo Agent hiểu chức năng cần đọc nhiều tệp hơn; mối quan hệ phụ thuộc càng phức tạp, tập làm việc càng lớn; tập làm việc càng nặng, hệ thống càng cần được dọn dẹp và nén; thiết kế lưu giữ nguyên nhân - kết quả càng mỏng, các thay đổi sau này càng dễ phụ thuộc vào mã hiện tại và kiểm thử cục bộ.

Do đó, độ phức tạp của mã bắt đầu làm tăng chi phí token, áp lực token lại ngược lại khuyến khích việc giữ trạng thái ngắn hơn và các bản vá cục bộ hơn. Đây mới là cơ chế đáng chú ý đằng sau hiện tượng “càng lặp lại càng nhiều vấn đề” trong Agent coding.

Đây không phải là vấn đề về năng lực của một mô hình riêng lẻ, mà là một vấn đề hệ thống do sự không nhất quán trong độ chính xác của việc lưu trữ trạng thái mã và trạng thái thiết kế.

Coding Agent đã ngày càng có thể hoạt động trong thời gian dài, nhưng “có thể chạy vài giờ” bản thân nó chưa chắc đã là một chỉ số khả năng tốt.

Nếu một Agent sau khi làm việc 3 giờ cần đọc lại tài liệu mà nó đã sửa 2 giờ trước, suy luận lại tại sao một khái niệm trừu tượng lại tồn tại, rồi chạy lại một lần nữa các bài kiểm tra đã từng chạy trước đó, thì trong 3 giờ đó, một phần đáng kể tính toán đã được dùng để khôi phục trạng thái.

Câu hỏi tiếp theo sẽ trở thành: Sau 50 bước, 100 bước, một Agent vẫn giữ được bao nhiêu thông tin nhân quả có giá trị cho các quyết định tiếp theo.

Có thể gọi nó là tỷ lệ duy trì trạng thái.

Vì nó không đo lường lượng token có thể nhét vào context, mà là sau khi gọi công cụ, nén, xuyên phiên và truy xuất bộ nhớ, có bao nhiêu thông tin thiết kế quan trọng vẫn còn tồn tại ở dạng có thể sử dụng. Điều này cũng có nghĩa là bộ nhớ dài hạn của Agent không thể chỉ dựa vào context dài hơn.

Một số kiến thức phù hợp để lưu trong memory, ví dụ như cách xây dựng dự án và thói quen phát triển; một số quyết định nên được ghi vào ADR có cấu trúc hoặc chỉ mục mã nguồn; còn những điều vi phạm sẽ phá vỡ ranh giới kiến trúc hệ thống thì nên được viết trực tiếp vào kiểu dữ liệu, bài kiểm tra, quy tắc lint, quy tắc phụ thuộc và CI.

Một quy tắc nếu đã trở thành ràng buộc có thể thực thi bởi phần mềm, thì Agent không cần “nhớ” nó. Trong vòng tiếp theo, Agent có thể quên một đoạn hội thoại, nhưng không thể dễ dàng vượt qua trình biên dịch và bài kiểm tra.

Nếu tỷ lệ xác thực thấp, Agent chạy càng lâu thì thực chất đang chôn nhiều mìn hơn cho hệ thống.

Đây cũng có thể là ranh giới mà Coding Agent cần vượt qua để từ “biết viết mã” tiến đến “có thể duy trì phần mềm lâu dài”: chuyển kiến thức thiết kế từ trí nhớ ngôn ngữ mang tính xác suất sang trạng thái phần mềm có thể truy xuất, xác minh và thực thi.

Nếu chạy tự chủ càng lâu, sẽ xuất hiện một cảnh tượng rất phi lý. Agent viết mã ngày càng nhanh, dự án cũng thay đổi nhanh chóng, nhưng sau mỗi khoảng thời gian, nó lại phải hiểu lại thế giới mà nó để lại trong khoảng thời gian trước đó.

Một câu thường thấy trong mã truyền thống là: “Đừng động vào đoạn này, không biết vì sao lại bị nổ.”

Mã nguồn di truyền của AI có thể còn kỳ lạ hơn: mã thật sự do Agent viết ra, nhưng các Agent sau này đã không còn biết tại sao Agent trước đó lại viết như vậy.