Loop Engineering.
Tác giả gốc: Addy Osmani
Biên dịch: Peggy, BlockBeats

Biên tập viên: Cách sử dụng AI coding agent đang chuyển từ “người viết prompt thủ công, từng bước thực hiện nhiệm vụ” sang “người thiết kế vòng lặp để hệ thống tự động phân bổ nhiệm vụ cho agent”. Loop Engineering (kỹ thuật vòng lặp) theo Addy Osmani tập trung vào việc xây dựng một luồng công việc tự động phát hiện nhiệm vụ, phân bổ nhiệm vụ, kiểm tra kết quả, ghi lại tiến độ và quyết định bước tiếp theo.

Quy trình này bao gồm năm mô-đun chính: Automations (tự động phát hiện và phân loại nhiệm vụ), Worktrees (cô lập nhiều môi trường phát triển song song), Skills (lưu trữ kiến thức dự án và thông lệ nhóm), Plugins/Connectors (kết nối với các công cụ thực tế như GitHub, Linear, Slack, cơ sở dữ liệu), Sub-agents (tách biệt người thực hiện và người kiểm duyệt), cùng một lớp bộ nhớ bên ngoài như tệp Markdown hoặc bảng Linear để lưu trạng thái và tiến độ.

Bài viết nhấn mạnh rằng ý nghĩa của Loop Engineering không chỉ là “để AI chạy thêm vài vòng”, mà là đưa sự phán đoán của kỹ sư vào ngay trong thiết kế hệ thống. Các vòng lặp có thể khuếch đại đáng kể hiệu quả làm việc của nhà phát triển, nhưng không thay thế được việc xác minh, hiểu và phán đoán. Rủi ro thực sự không nằm ở việc sử dụng vòng lặp, mà ở việc dùng vòng lặp như một lý do để tránh hiểu mã và hệ thống. Kỹ năng then chốt để hợp tác với AI trong lập trình trong tương lai có lẽ không còn chỉ là viết một Prompt tốt, mà là thiết kế các luồng làm việc Agent đáng tin cậy, có thể xác minh và vận hành bền vững.

The following is the original text:

Loop engineering (công trình vòng lặp) đang thay thế vai trò của bạn với tư cách là “người viết lời nhắc cho tác nhân”. Bạn cần thiết kế một hệ thống để hệ thống này thay bạn đưa lời nhắc cho tác nhân. Ở đây, loop (vòng lặp) có thể được hiểu là một mục tiêu đệ quy: bạn xác định một mục đích, AI sẽ liên tục lặp lại cho đến khi hoàn thành nhiệm vụ. Nó gồm năm thành phần chính, và hiện nay Claude Code và Codex đều đã sở hữu năm thành phần này.

Tôi tin rằng đây có thể là cách chúng ta hợp tác với các tác nhân mã hóa trong tương lai. Tuy nhiên, tất cả những điều này vẫn ở giai đoạn đầu và tôi vẫn giữ thái độ nghi ngờ. Bạn tuyệt đối cần cẩn trọng với chi phí token, vì chi phí có thể chênh lệch rất lớn tùy theo mô hình sử dụng, đặc biệt là khi bạn đang ở trạng thái “giàu token” hay “khan hiếm token”. Bạn cũng cần có cơ chế nào đó để đảm bảo chất lượng không suy giảm. Những lo ngại về “hàng giả AI” (slop) cũng hoàn toàn hợp lý. Dù vậy, hãy cùng xem xét xem thực chất đây là gì.

@steipete gần đây đã nói một câu: “Bạn không nên nữa viết prompt cho các tác nhân mã hóa. Bạn nên thiết kế một số vòng lặp để những vòng lặp đó đưa prompt cho tác nhân của bạn.” Tương tự, trưởng nhóm Claude Code của Anthropic @bcherny cũng nói: “Bây giờ tôi đã không còn đưa prompt cho Claude nữa. Tôi có một loạt vòng lặp đang chạy, chúng sẽ đưa prompt cho Claude và tự quyết định bước tiếp theo nên làm gì. Công việc của tôi chỉ là viết vòng lặp.”

Vậy thì điều này có nghĩa là gì?

Trong khoảng hai năm qua, để yêu cầu một tác nhân mã hóa thực hiện điều gì đó, cách cơ bản là viết một lời nhắc tốt và cung cấp đủ ngữ cảnh. Bạn nhập một câu, đọc kết quả trả về, rồi nhập câu tiếp theo. Tác nhân là một công cụ, và bạn luôn nắm giữ công cụ này, từng vòng một, thúc đẩy nó. Giai đoạn này phần nào đã kết thúc, ít nhất một số người cho rằng nó sắp kết thúc.

Bây giờ, bạn đang xây dựng một hệ thống nhỏ: nó tự mình phát hiện công việc, phân bổ nhiệm vụ, kiểm tra kết quả, ghi lại tình trạng hoàn thành, sau đó quyết định bước tiếp theo cần làm. Nói cách khác, bạn để hệ thống này điều khiển các tác nhân, thay vì phải tự mình nhắc nhở nó từng lần một. Trước đây, tôi đã từng viết về “người họ hàng gần” của nó — agent harness engineering (kỹ thuật khung chạy tác nhân), tức là xây dựng môi trường chạy cho một tác nhân đơn lẻ; và factory model (mô hình nhà máy), tức là hệ thống xây dựng phần mềm. Loop engineering nằm ở cấp độ cao hơn harness. Nó giống như harness, nhưng chạy theo bộ định thời, tạo ra các trợ lý nhỏ và tự nuôi dưỡng chính nó.

Điều khiến tôi bất ngờ là giờ đây vấn đề này đã không còn chỉ là vấn đề ở cấp độ “công cụ” nữa. Một năm trước, nếu bạn muốn tạo một vòng lặp, bạn phải viết rất nhiều script bash và mãi mãi duy trì đống script đó. Đó là thứ thuộc về bạn và chỉ thuộc về bạn. Bây giờ, các thành phần này đã được tích hợp trực tiếp vào sản phẩm. Những khả năng Steinberger liệt kê gần như có thể tương ứng từng mục một với ứng dụng Codex, và cũng gần như tương ứng hoàn toàn với Claude Code. Một khi bạn nhận ra hình thái của chúng là giống nhau, bạn sẽ không còn băn khoăn nên dùng công cụ nào nữa, mà sẽ thiết kế một vòng lặp: bất kể bạn đang ngồi trong công cụ nào, nó vẫn có thể tiếp tục vận hành.

Năm thành phần, cùng một số hướng dẫn

Một vòng lặp cần năm yếu tố, cộng thêm một nơi để ghi nhớ thông tin. Tôi sẽ liệt kê trước, sau đó逐一 đối ứng.

Đầu tiên, Automations (nhiệm vụ tự động hóa): được kích hoạt theo lịch trình, tự động phát hiện và phân luồng.

Thứ hai, Worktrees (cây làm việc): Giúp hai tác nhân đang làm việc song song không ghi đè lên tệp của nhau.

Thứ ba, Skills (kỹ năng): Ghi lại kiến thức về dự án để tránh việc tác nhân phải đoán mỗi lần.

Thứ tư, Plugins and connectors (插件和连接器): Cho phép agent kết nối với các công cụ bạn đang sử dụng.

Thứ năm, Sub-agents (sub-agent): Một cái chịu trách nhiệm đề xuất phương án, cái còn lại chịu trách nhiệm kiểm tra phương án.

Sau đó là thứ thứ sáu: memory (trí nhớ). Nó có thể là một tệp Markdown, một bảng Linear, hoặc bất kỳ nơi nào độc lập với cuộc hội thoại đơn lẻ, có khả năng lưu trữ các “việc đã hoàn thành” và “việc tiếp theo”. Nghe có vẻ đơn giản đến mức không giống như một việc quan trọng, nhưng đây chính là kỹ thuật mà mọi tác nhân chạy dài hạn đều dựa vào. Tôi cũng đã viết chi tiết về điều này trong các long-running agents: mô hình sẽ quên đi giữa các lần chạy, vì vậy trí nhớ phải được lưu trên đĩa, chứ không phải trong ngữ cảnh. Tác nhân sẽ quên, nhưng kho mã nguồn thì không.

Bây giờ, cả hai sản phẩm đều đã có đủ năm thành phần này.

Chúng có cách đặt tên khác nhau ở một số nơi, nhưng về bản chất, khả năng là như nhau. Dưới đây tôi sẽ giải thích từng điểm, bởi vì thành thật mà nói, một vòng lặp cuối cùng hoạt động ổn định hay rò rỉ âm thầm khắp nơi, then chốt đều nằm ở chi tiết.

Automations là yếu tố biến loop trở thành một loop thực sự, thay vì chỉ là một tác vụ một lần mà bạn từng chạy thủ công. Trong ứng dụng Codex, bạn có thể tạo một tác vụ tự động hóa trên tab Automations, chọn dự án, prompt mà nó sẽ chạy, tần suất thực hiện, cũng như xác định liệu nó sẽ chạy trong local checkout của bạn hay trong worktree nền. Những kết quả chạy phát hiện ra vấn đề sẽ được chuyển vào Triage inbox, trong khi những lần chạy không phát hiện vấn đề sẽ tự động được lưu trữ — điều này rất hữu ích. OpenAI cũng sử dụng nó để thực hiện những công việc nhàm chán nhưng cần thiết, chẳng hạn như phân loại issue hàng ngày, tổng hợp nguyên nhân thất bại của CI, viết bản tin commit và theo dõi các bug do người khác giới thiệu vào tuần trước. Các tác vụ tự động hóa còn có thể gọi đến skill, giúp bạn duy trì khả năng bảo trì cho những tác vụ lặp lại: kích hoạt $skill-name thay vì dán nguyên một dãy hướng dẫn dài vào một lịch trình mà sau này không ai còn cập nhật nữa.

Claude Code cũng đạt được hiệu quả tương tự, chỉ khác ở cách thức thực hiện: nó sử dụng lịch trình và hooks. Bạn có thể sử dụng /loop để chạy một lệnh hoặc prompt theo khoảng thời gian cố định, lên lịch một tác vụ cron, hoặc kích hoạt lệnh shell tại các điểm nhất định trong vòng đời của tác nhân. Nếu bạn muốn nó tiếp tục chạy sau khi đóng máy tính, bạn cũng có thể triển khai toàn bộ hệ thống lên GitHub Actions. Ý tưởng hoàn toàn giống nhau: bạn định nghĩa một tác vụ tự chủ, đặt nhịp độ cho nó, để kết quả tự động xuất hiện trước mặt bạn, thay vì phải tự đi kiểm tra khắp nơi.

Một nguyên ngữ trong phiên làm việc khác cũng đáng để tìm hiểu, nó gần với trọng tâm thực sự mà bài viết này đang thảo luận. /loop sẽ chạy lặp lại theo nhịp điệu; /goal thì sẽ tiếp tục thực thi cho đến khi điều kiện bạn đặt ra thực sự được đáp ứng. Sau mỗi vòng lặp, một mô hình nhỏ riêng biệt sẽ đánh giá xem nhiệm vụ đã hoàn thành chưa, do đó, tác nhân viết mã không phải là người tự chấm điểm cho chính mình. Bạn có thể đưa ra một điều kiện, ví dụ: “tất cả các bài kiểm tra trong test/auth đều vượt qua và lint sạch sẽ”, rồi để nó tự chạy. Codex cũng có khả năng tương tự, cũng được gọi là /goal. Nó sẽ tiếp tục làm việc xuyên suốt các vòng lặp cho đến khi một điều kiện dừng có thể xác minh được được đáp ứng, và hỗ trợ tạm dừng, khôi phục và xóa. Cùng một nguyên ngữ này, cả hai công cụ đều có. Đây cơ bản là mô hình lặp lại xuyên suốt bài viết.

Vì vậy, Automations chịu trách nhiệm đưa công việc lên bề mặt, còn phần còn lại của vòng lặp sẽ xử lý những công việc đó.

Khi bạn chạy nhiều hơn một tác nhân, xung đột tệp sẽ trở thành điểm thất bại. Hai tác nhân cùng viết vào một tệp cùng lúc, về cơ bản cũng giống như hai kỹ sư sửa cùng một dòng mã mà không có sự liên lạc với nhau. Git worktree có thể giải quyết vấn đề này. Nó là một thư mục làm việc riêng biệt trên nhánh độc lập, nhưng chia sẻ cùng lịch sử kho mã nguồn, do đó các thay đổi của một tác nhân không thể nào chạm đến bản checkout của tác nhân khác về mặt vật lý.

Codex đã tích hợp sẵn hỗ trợ worktree, vì vậy nhiều luồng có thể xử lý cùng một kho lưu trữ mà không gây xung đột lẫn nhau. Claude Code cũng có thể đạt được sự cô lập tương tự thông qua git worktree: bạn có thể sử dụng cờ --worktree để mở một phiên trong một checkout độc lập, hoặc thiết lập isolation: worktree trên subagent để mỗi tiểu trợ nhận một checkout hoàn toàn mới và tự động dọn dẹp sau khi hoàn tất. Tôi đã đề cập đến khía cạnh con người về vấn đề này trong the orchestration tax: worktrees có thể loại bỏ xung đột ở cấp độ cơ học, nhưng bạn vẫn là giới hạn. Điều thực sự quyết định số lượng tác nhân bạn có thể chạy đồng thời không phải là công cụ, mà là băng thông đánh giá (review bandwidth) của bạn.

Skill là một cơ chế giúp bạn không cần phải giải thích lại cùng một ngữ cảnh dự án trong mỗi phiên giao tiếp như cá vàng. Hai công cụ này sử dụng cùng một định dạng: một thư mục chứa tệp SKILL.md lưu trữ hướng dẫn và siêu dữ liệu; ngoài ra có thể có các tập lệnh tùy chọn, tài liệu tham khảo và tệp tài nguyên. Codex sẽ chạy một skill khi bạn gọi bằng $ hoặc /skills, đồng thời tự động chạy khi nhiệm vụ của bạn khớp với mô tả của skill đó. Đó cũng là lý do tại sao một mô tả ngắn gọn, đơn giản thường hiệu quả hơn một mô tả thông minh nhưng rườm rà. Claude Code cũng thực hiện tương tự, và tôi đã từng viết về mô hình này trong agent skills.

Skills cũng là nơi giúp ý định không phải liên tục tiêu tốn năng lượng của bạn. Tôi đã nói trong intent debt rằng, mỗi lần bắt đầu hội thoại, tác nhân đều khởi động từ đầu; chỉ cần trong ý định của bạn còn khoảng trống, nó sẽ dùng những phỏng đoán tự tin để lấp đầy chúng. Skill chính là việc ghi lại những ý định này ở bên ngoài: các thỏa thuận dự án, các bước xây dựng, “chúng ta không làm thế vì trước đây đã xảy ra sự cố đó” — tất cả đều được ghi lại một lần tại một nơi mà tác nhân sẽ đọc mỗi khi chạy. Không có skills, mỗi vòng lặp đều phải suy luận lại toàn bộ dự án từ đầu; có skills, nó giống như đang tăng trưởng theo lãi kép.

Cần phân biệt rõ: skill là định dạng mã hóa, còn plugin là cách phân phối. Khi bạn muốn chia sẻ một skill giữa nhiều kho mã nguồn, hoặc đóng gói vài skill lại với nhau, bạn sẽ bao bọc chúng thành một plugin. Codex cũng vậy, Claude Code cũng vậy.

Một vòng lặp chỉ có thể truy cập hệ thống tệp tin là một vòng lặp rất nhỏ. Các connector được xây dựng dựa trên MCP, cho phép tác nhân đọc issue tracker của bạn, truy vấn cơ sở dữ liệu, gọi API staging hoặc gửi tin nhắn trên Slack. Codex và Claude Code đều hỗ trợ MCP, vì vậy connector bạn viết cho một trong hai thường cũng có thể sử dụng được trên cái còn lại. Plugins đóng gói các connector và skills lại với nhau, giúp đồng đội của bạn cài đặt toàn bộ cấu hình chỉ trong một lần, thay vì phải ghi nhớ và tái tạo toàn bộ hệ thống.

Đó là sự khác biệt giữa việc “một tác nhân thông báo cho bạn ‘đây là giải pháp sửa chữa’” và “một vòng lặp tự động mở PR, liên kết với ticket Linear, và thông báo cho kênh sau khi CI thành công”. Connectors quan trọng vì chúng cho phép loop hành động trong môi trường thực tế của bạn, chứ không chỉ nói rằng “nếu tôi có thể làm, tôi sẽ làm”.

Trong một vòng lặp, thiết kế cấu trúc hữu ích nhất là tách biệt người viết và người kiểm tra. Mô hình viết mã quá dễ dàng trở nên khoan dung khi tự chấm điểm công việc của chính mình. Một tác nhân khác với chỉ lệnh khác biệt, đôi khi thậm chí sử dụng mô hình khác, có thể phát hiện ra những vấn đề mà tác nhân đầu tiên bỏ qua sau khi tự thuyết phục bản thân.

Codex chỉ tạo subagents khi bạn yêu cầu, chúng sẽ chạy song song và sau đó hợp nhất kết quả thành một câu trả lời. Bạn có thể định nghĩa các agent của riêng mình bằng tệp TOML trong thư mục .codex/agents/: mỗi agent đều có tên, mô tả, hướng dẫn, cùng với mô hình và cường độ suy luận tùy chọn. Do đó, người kiểm duyệt bảo mật của bạn có thể là một mô hình mạnh với cường độ suy luận cao, trong khi người khám phá của bạn có thể là một mô hình nhẹ, nhanh và chỉ đọc. Claude Code cũng cung cấp khả năng tương tự thông qua subagents và các đội agent trong .claude/agents/, cho phép nhiều agent truyền công việc cho nhau. Phân công phổ biến nhất trên cả hai nền tảng là: một agent khám phá, một agent thực hiện, và một agent xác minh theo tiêu chuẩn.

Tôi đã trình bày quan điểm này hai lần: một lần tại code agent orchestra, và một lần tại adversarial code review. Nó đặc biệt quan trọng trong loop, vì loop sẽ chạy khi bạn không giám sát, nên một verifier (người xác minh) mà bạn thực sự tin tưởng là lý do duy nhất khiến bạn dám rời đi. Subagents thực sự tiêu tốn nhiều token hơn, vì mỗi agent đều phải thực hiện các cuộc gọi mô hình và công cụ riêng, do đó bạn nên sử dụng chúng ở những nơi mà “ý kiến thứ hai đáng để trả tiền”. Về cơ bản, đây cũng chính là điều mà /goal của Claude Code đang làm ở cấp độ nền tảng: sử dụng một mô hình mới để đánh giá xem loop đã hoàn thành chưa, thay vì để mô hình thực hiện công việc tự đánh giá. Nói cách khác, nó áp dụng sự tách biệt giữa “người tạo” và “người kiểm tra” ngay vào chính điều kiện dừng.

Một loop trông như thế nào

Ghép những thứ này lại, một luồng riêng lẻ sẽ trở thành một bảng điều khiển nhỏ. Dưới đây là cấu trúc mà tôi thường sử dụng.

Mỗi sáng, một tác vụ tự động chạy trên kho mã nguồn. Lệnh nhắc của nó gọi đến kỹ năng phân loại, đọc các lỗi CI ngày hôm qua, các vấn đề đang mở và các commit gần đây, sau đó ghi lại phát hiện vào tệp Markdown hoặc bảng Linear. Đối với mỗi vấn đề đáng được xử lý, luồng sẽ mở một worktree cô lập, cử một sub-agent soạn thảo giải pháp khắc phục, rồi cử một sub-agent thứ hai xem xét giải pháp này dựa trên kỹ năng của dự án và các bài kiểm tra hiện có.

Connectors cho phép loop tự động mở PR và cập nhật ticket. Mọi thứ loop không xử lý được sẽ được chuyển vào hộp thư triage để tôi xử lý. Tệp trạng thái là xương sống của toàn bộ hệ thống: nó ghi nhớ những gì đã thử, những gì đã thành công và những gì vẫn còn chưa hoàn thành. Do đó, việc chạy vào buổi sáng hôm sau sẽ tiếp tục từ vị trí mà hôm nay dừng lại.

Hãy chú ý đến những gì bạn thực sự đã làm. Bạn chỉ mới thiết kế một lần. Những bước đó không phải là bạn từng hướng dẫn từng bước một. Đó chính là phiên bản thực tế của câu nói Steinberger. Và cùng một vòng lặp đó có thể chạy trên Codex hoặc Claude Code, vì các thành phần cấu tạo vốn là cùng một bộ thành phần.

Loop vẫn sẽ không làm gì thay cho bạn

Loop đã thay đổi cách hoạt động, nhưng không xóa bạn khỏi công việc. Thực tế, khi loop trở nên mạnh hơn, ba vấn đề sẽ trở nên cấp bách hơn, chứ không dễ dàng hơn.

Việc xác minh vẫn phụ thuộc vào bạn. Một vòng lặp chạy không người giám sát cũng có thể đang mắc lỗi mà không ai phát hiện. Lý do bạn tách riêng verifier sub-agent và maker chính là để câu nói “đã hoàn thành” của vòng lặp có chút ý nghĩa. Dù vậy, “hoàn thành” vẫn chỉ là một tuyên bố, chứ không phải bằng chứng. Tôi đã lặp lại cùng một câu trong bài viết “Code review in the age of AI”: trách nhiệm của bạn là giao những mã đã được bạn xác nhận là hoạt động đúng.

Nếu bạn để mặc nó, sự hiểu biết của chính bạn vẫn sẽ bị thoái hóa. Loop càng nhanh giao cho bạn những mã mà bạn không tự viết ra, khoảng cách giữa những gì bạn thực sự hiểu và những gì thực sự tồn tại trong hệ thống sẽ càng lớn. Đó chính là comprehension debt (nợ hiểu biết). Nếu bạn không đọc những gì loop tạo ra, một loop trơn tru chỉ khiến khoản nợ này tăng nhanh hơn nữa.

Và đúng vậy, tư thế thoải mái nhất có lẽ cũng là tư thế nguy hiểm nhất. Khi loop có thể tự vận hành, bạn dễ dàng ngừng hình thành phán đoán của riêng mình và chỉ chấp nhận bất kỳ thứ gì nó trả về. Tôi gọi đây là sự đầu hàng nhận thức (cognitive surrender). Nếu bạn thiết kế loop với khả năng phán đoán, nó sẽ là liều thuốc giải; nếu bạn thiết kế loop chỉ để trốn tránh suy nghĩ, nó sẽ là chất tăng tốc. Cùng một hành động này có thể mang lại kết quả hoàn toàn đối lập.

Xây dựng loop, nhưng vẫn là kỹ sư

Tôi cho rằng, điều này dự báo hướng phát triển của công việc trong tương lai của chúng tôi. Tuy nhiên, nếu tôi không tự mình kiểm tra mã nguồn, hoặc hoàn toàn phụ thuộc vào vòng lặp tự động để sửa mã, chất lượng sản phẩm của tôi sẽ bị ảnh hưởng. Tôi rất có thể sẽ rơi vào một vòng xoáy tiêu cực: liên tục tự đào sâu hơn vào những rắc rối.

Vì vậy, bạn hoàn toàn có thể tự xây dựng vòng lặp của mình, nhưng đừng quên rằng việc nhắc nhở trực tiếp đến tác nhân thông minh của bạn vẫn hiệu quả. Điều quan trọng là tìm được sự cân bằng phù hợp.

Kết quả của Loop cũng sẽ khác nhau tùy người. Hai người có thể xây dựng cùng một loop nhưng lại đạt được kết quả hoàn toàn trái ngược. Một người dùng nó để tăng tốc trong công việc mà họ hiểu sâu sắc; người kia dùng nó để trốn tránh việc hiểu bản thân công việc. Loop không biết sự khác biệt giữa hai điều này. Bạn thì biết.

Đó là lý do tại sao loop design (thiết kế vòng lặp) khó hơn so với prompt engineering (kỹ thuật nhắc nhở), chứ không dễ hơn. Ý của Cherny không phải là công việc trở nên nhẹ nhàng hơn, mà là điểm đòn bẩy đã chuyển dịch.

Xây dựng loop. Nhưng hãy xây dựng nó như một người vẫn đang định trở thành kỹ sư, chứ không phải như một người chỉ có nhiệm vụ nhấn nút “bắt đầu”.

[Đường dẫn gốc]

Nhấp để tìm hiểu các vị trí đang tuyển của BlockBeats

Chào mừng bạn tham gia cộng đồng chính thức của律动 BlockBeats:

Nhóm Telegram đăng ký: https://t.me/theblockbeats

Nhóm giao lưu Telegram: https://t.me/BlockBeats_App

Tài khoản chính thức trên Twitter: https://twitter.com/BlockBeatsAsia