Kỹ sư Google dạy bạn Loop Engineering là gì? Năm khối xây dựng + bộ nhớ bên ngoài, môn học bắt buộc về AI năm 2026

Loop Engineering là một hệ thống tự thực thi prompt proxy, nó gồm năm khối xây dựng: Automations, Worktrees, Skills, Plugins/Connectors, Sub-agents, cùng với một bộ nhớ bên ngoài. Bài viết này xuất phát từ kỹ sư phần mềm của Google, Addy Osmani.
（Tiền đề: Anthropic trong Claude Fable 5 đã thêm chức năng phát hiện蒸餾, có thể chặn các mô hình mã nguồn mở của Trung Quốc?）
（Bổ sung nền: Anthropic: dẫn đầu AI mô hình ở Mỹ để bảo vệ dân chủ, đề xuất coi蒸餾 tấn công là tội hình sự）

Mục lục bài viết

Toggle

• Năm khối xây dựng, kèm một số chú thích
• Automations: nhịp đập của vòng lặp
• Worktrees: đừng để song song biến thành hỗn loạn
• Skills: cuối cùng bạn không cần phải kể lại dự án của mình mỗi lần
• Plugins và connectors: vòng lặp vươn tay chạm vào công cụ thực sự của bạn
• Sub-agents: tách người làm và người kiểm tra ra
• Một vòng lặp trông như thế nào
• Vòng lặp vẫn chưa làm giúp bạn những việc gì
• Xây dựng vòng lặp, nhưng vẫn giữ vai trò kỹ sư

Loop engineering là thay thế "người prompt proxy" tự tay bạn bằng hệ thống do chính bạn thiết kế để làm việc đó. Khái niệm "vòng lặp" ở đây có thể hiểu là một mục tiêu đệ quy: bạn xác định mục đích, AI lặp đi lặp lại cho đến khi hoàn thành. Tôi tin rằng đây có thể chính là cách chúng ta hợp tác với các proxy mã hóa trong tương lai.

Nhưng nói trước, đây còn rất sơ khai, tôi cũng còn nghi ngờ, và bạn chắc chắn phải cẩn thận với chi phí token. Tôi muốn phân tích rõ hơn: nó là gì, và ý nghĩa của nó là gì.

Peter Steinberger gần đây nói: "Bạn không nên prompt proxy mã của mình nữa. Bạn nên thiết kế vòng lặp sẽ prompt proxy của bạn." Boris Cherny, trưởng nhóm Claude Code của Anthropic, cũng nói tương tự: "Tôi đã không còn prompt Claude nữa. Tôi để vòng lặp chạy để prompt Claude, vòng lặp tự quyết định làm gì."

Gần hai năm trước, để lấy kết quả từ một proxy mã, bạn phải viết một prompt tốt và cung cấp đủ ngữ cảnh. Bạn gõ đoạn này, đọc phản hồi, rồi gõ đoạn tiếp theo. Proxy là công cụ, và bạn kiểm soát nó từ đầu đến cuối, từng vòng một. Giai đoạn đó gần như đã kết thúc, ít nhất một số người nghĩ vậy.

Bây giờ, bạn xây dựng một hệ thống nhỏ: nó tìm việc, phân công việc, kiểm tra công việc, ghi lại những gì đã hoàn thành, rồi quyết định bước tiếp theo, hệ thống này sẽ tác động vào proxy chứ không phải bạn trực tiếp. Tôi đã viết về "agent harness engineering" gần đây, đó là xây dựng môi trường vận hành cho một proxy duy nhất, tức là mô hình "nhà máy" của phần mềm.

Loop engineering cao cấp hơn harness một tầng: harness vẫn còn đó, nhưng nó chạy theo lịch trình, sinh ra trợ lý nhỏ, tự cung cấp dữ liệu cho chính nó.

Điều làm tôi ngạc nhiên là, điều này đã không còn là vấn đề của công cụ nữa. Một năm trước, bạn muốn viết một vòng lặp, bạn phải xếp chồng nhiều bash, tự duy trì, đó là thứ của riêng bạn. Giờ đây, các thành phần đó đã được tích hợp sẵn trong sản phẩm. Danh sách của Steinberger gần như hoàn toàn phù hợp với Codex app, rồi gần như phù hợp với Claude Code. Một khi bạn nhận ra hình dạng thực ra giống nhau, bạn sẽ không còn tranh cãi về "dùng công cụ nào nữa", mà chỉ cần thiết kế một vòng lặp có thể chạy bất kể trong công cụ nào.

Năm khối xây dựng, kèm một số chú thích

Một vòng lặp cần năm thành phần, cộng thêm một bộ nhớ. Tôi liệt kê rồi đối chiếu.

2. Automations: theo lịch trình kích hoạt, tự động thực hiện discovery và triage.
3. Worktrees: cách để hai proxy chạy song song không gây xung đột.
4. Skills: ghi lại kiến thức dự án mà proxy vốn chỉ có thể đoán mò.
5. Plugins và connectors: kết nối proxy với các công cụ bạn đã dùng.
6. Sub-agents: một người nảy ra ý tưởng, người khác kiểm tra.

Và thành phần thứ sáu: bộ nhớ. Một file markdown, hoặc bảng Linear, bất cứ thứ gì tồn tại ngoài cuộc đối thoại một lần, dùng để ghi lại "đã làm gì, bước tiếp theo là gì". Nghe có vẻ ngu ngốc, chẳng ai muốn dùng. Nhưng đó chính là trò chơi mà mọi proxy chạy lâu dài đều dựa vào, tôi đã đề cập trong bài viết về long-running agents: mô hình sẽ quên sạch mọi thứ giữa các lần chạy, nên bộ nhớ phải nằm trên đĩa, không nằm trong ngữ cảnh. Proxy quên, repo thì không.

Hiện tại, có hai sản phẩm đã tích hợp đủ năm thành phần này.

| Nguyên ngữ | | --- | Vai trò trong vòng lặp | Codex app | Claude Code | | --- | --- | --- | --- | | Automations | Lập lịch phát hiện và phân luồng | Trang Automations: chọn dự án, prompt, tần suất, môi trường; kết quả vào hộp triage; /goal dùng để chạy đến khi xong | Nhiệm vụ theo lịch, cron, /loop, /goal, hooks, GitHub Actions | | Worktrees | Phân tách phát triển song song | Mỗi thread có worktree riêng | git worktree, --worktree, isolation: worktree trên subagent | | Skills | Ghi lại kiến thức dự án | Agent Skills (SKILL.md), gọi bằng $name hoặc ẩn danh | Agent Skills (SKILL.md) | | Plugins / connectors | Kết nối công cụ của bạn | Connectors (MCP) cộng với plugins phân phát | MCP servers cộng plugins | | Sub-agents | Ý tưởng và xác thực | Định nghĩa trong .codex/agents/ bằng TOML | Trong .claude/agents/ có Task subagents, agent teams | | State | Theo dõi trạng thái hoàn thành | Markdown hoặc qua connector kết nối Linear | Markdown (AGENTS.md, tiến trình) hoặc qua MCP kết nối Linear |

Tên gọi có thể khác nhau chút ít, nhưng bản chất năng lực là như nhau. Tôi sẽ lần lượt mở rộng, vì thật lòng, ma quỷ nằm trong chi tiết: vòng lặp có ổn định hay sẽ rò rỉ, tất cả đều phụ thuộc vào các chi tiết này.

Automations: nhịp đập của vòng lặp

Automations chính là giúp "vòng lặp" thực sự trở thành vòng lặp, chứ không phải "đã chạy qua một lần". Trong Codex app, bạn tạo một Automations trong trang Automations, chọn dự án, prompt cần chạy, tần suất, chạy cục bộ hay background worktree. Các phát hiện sẽ vào hộp triage, không phát hiện thì tự đóng, rất tiện.

OpenAI dùng nó để chạy các việc nhàm chán nhưng cần thiết: phân luồng issue hàng ngày, tóm tắt CI thất bại, briefing commit, tìm bug trong tuần trước đã bị ai đưa vào. Automation có thể gọi skill, nên nhiệm vụ chu kỳ của bạn có thể duy trì: chỉ cần kích hoạt $skill-name, chứ không phải dán một đống lệnh vào lịch trình không ai cập nhật.

Claude Code cũng đi theo hướng này nhưng khác đường đi: qua lịch trình và hooks. Bạn có thể dùng /loop để lặp prompt hoặc lệnh theo chu kỳ, đặt cron, dùng hooks để kích hoạt shell tại điểm nhất định trong vòng đời proxy, hoặc đẩy toàn bộ lên GitHub Actions để chạy sau khi bạn tắt laptop. Ý tưởng hoàn toàn giống nhau: xác định một nhiệm vụ tự động, cho nó nhịp điệu, tự động gửi kết quả đến bạn, bạn không cần phải mở ra xem.

Còn một lệnh nữa trong session cần biết, và nó gần hơn với nội dung bài viết này: /loop là lặp theo nhịp, còn /goal là chạy đến khi điều kiện viết ra thành công, mỗi vòng kết thúc sẽ do một mô hình nhỏ đánh giá xem đã hoàn thành chưa, chứ không phải "viết code" là "đánh giá".

Bạn đưa ra điều kiện như "tất cả test trong auth đều pass, lint sạch" thì nó dừng. Codex cũng có /goal tương tự, chạy qua nhiều vòng đến khi điều kiện dừng xác thực được, có thể tạm dừng, tiếp tục, xóa. Cùng một nguyên ngữ, hai công cụ đều có, và đây chính là pattern của toàn bài viết.

Vì vậy, phần này chính là "hiện thực hóa công việc". Các phần còn lại của vòng lặp là "làm gì với những công việc đó".

Worktrees: đừng để song song biến thành hỗn loạn

Chỉ cần chạy quá nhiều proxy cùng lúc, các file sẽ bắt đầu xung đột, đó là cách nó hỏng. Hai proxy ghi đè cùng một file, giống như hai kỹ sư cùng commit trên cùng một dòng code mà không trao đổi trước. git worktree giải quyết chuyện này: nó là một thư mục làm việc riêng biệt, một branch riêng, cùng chia sẻ lịch sử repo, nên một proxy chỉnh sửa không thể chạm vào checkout của proxy khác.

Codex tích hợp sẵn support cho worktree, nên nhiều thread có thể cùng lúc làm việc trên cùng repo mà không va chạm. Claude Code dùng git worktree, --worktree flag (cho phép một session mở trong checkout riêng), và thiết lập isolation: worktree trên subagent (mỗi trợ lý có một checkout mới, chạy xong sẽ xóa). Trong bài viết về orchestration tax, tôi đã viết từ góc độ con người: worktree giải quyết va chạm cơ học, còn giới hạn là khả năng review của bạn, số lượng proxy thực sự chạy được phụ thuộc vào bandwidth review của bạn, chứ không phải công cụ.

Skills: cuối cùng bạn không cần phải kể lại dự án mỗi lần

Skill giúp bạn không phải kể lại dự án trong từng session như cá vàng. Hai công cụ đều dùng cùng một định dạng: một thư mục chứa SKILL.md, ghi lệnh và metadata, kèm scripts, references, assets nếu cần. Codex khi gọi $ hoặc /skills sẽ chạy skill, hoặc tự động chạy khi nhiệm vụ phù hợp mô tả skill — đó là lý do một mô tả chính xác, đơn giản lại hiệu quả hơn mô tả đẹp đẽ, thông minh. Claude Code cũng theo pattern này, tôi đã viết trong bài về agent skills.

Skill còn giúp "ý định không cần phải trả phí lần nữa". Trong bài về debt ý định, tôi đã đề cập: proxy mỗi lần khởi động đều là cold start, nó sẽ dùng các dự đoán tự tin để điền vào các lỗ trong ý định của bạn. Skill là ghi lại ý định đó ra ngoài — theo quy ước, bước build, "chúng ta không làm như vậy vì lần trước đã có sự kiện đó" — viết một lần, proxy chạy nhiều lần sẽ đọc lại. Không có skill, vòng lặp mỗi vòng đều phải bắt đầu từ đầu, lặp có skill sẽ tích lũy theo thời gian.

Có một điều cần phân biệt rõ: skill là định dạng viết, plugin là cách phân phối. Khi bạn muốn chia sẻ một skill qua repo, hoặc đóng gói nhiều skill thành một bộ, bạn đóng gói thành plugin. Codex làm vậy, Claude Code cũng thế.

Plugins và connectors: vòng lặp vươn tay chạm vào công cụ thực sự của bạn

Chỉ có vòng lặp dựa trên filesystem là nhỏ. Connectors, xây dựng trên MCP, cho phép proxy đọc issue tracker, truy vấn database, gọi API staging, gửi tin Slack. Cả Codex lẫn Claude Code đều nói về MCP, nên connector bạn viết cho một trong hai thường dùng được cho cả hai. Plugins đóng gói connectors và skills thành một bộ, giúp đồng đội cài đặt toàn bộ cấu hình một lần, không phải nhớ từng bước.

Đây chính là sự khác biệt giữa "proxy nói với bạn 'đây là luật sửa đổi'" và "vòng lặp tự mở PR, liên kết ticket Linear, sau khi CI xanh sẽ gửi thông báo". Connectors là lý do vòng lặp có thể thao tác trong môi trường thực, không chỉ là báo "nếu có thể, nó sẽ làm gì".

Sub-agents: tách người làm và người kiểm tra ra

Cấu trúc hữu ích nhất trong vòng lặp chính là tách "người viết" và "người kiểm tra". Mô hình viết code tự cho điểm mình quá dễ dãi. Một proxy thứ hai, khác biệt về lệnh hoặc thậm chí mô hình, sẽ bắt được những điều proxy tự thuyết phục mình trước đó.

Codex chỉ tạo subagent khi bạn gọi, chạy song song, rồi gộp kết quả thành một câu trả lời. Trong .codex/agents/, bạn định nghĩa proxy bằng TOML, mỗi cái có tên, mô tả, instructions, tùy chọn model và reasoning effort — người kiểm tra an toàn của bạn có thể là một mô hình mạnh, dành nhiều ngân sách suy nghĩ, còn người khám phá có thể là thứ nhanh, chỉ đọc. Claude Code cũng dùng subagent và agent teams trong .claude/agents/ để truyền công việc giữa các proxy. Hai bên thường tách ra: một để khám phá, một để thực thi, một để xác nhận theo spec.

Tôi đã từng đề xuất hai pattern: một là code agent orchestra, hai là adversarial code review. Trong vòng lặp, điều này đặc biệt quan trọng vì vòng lặp sẽ chạy khi bạn không để ý — một verifier đáng tin cậy là lý do duy nhất bạn có thể yên tâm. Subagent sẽ tiêu tốn token hơn, vì mỗi cái đều phải chạy mô hình và công cụ riêng. Vì vậy, hãy dành nó cho những nơi cần "lấy ý kiến thứ hai". /goal của Claude Code về cơ bản chính là vậy: một mô hình mới quyết định vòng lặp đã hoàn tất hay chưa, chứ không phải mô hình viết code.

Một vòng lặp trông như thế nào

Kết hợp các thành phần này, một thread sẽ trở thành một bảng điều khiển nhỏ. Tôi thường hình dung như sau.

Một automation chạy hàng ngày sáng sớm trên repo. Nó gọi prompt qua một skill triage, đọc các CI thất bại hôm qua, issues mở, commits gần nhất, rồi ghi vào markdown hoặc bảng Linear. Với mỗi phát hiện đáng làm, thread mở một worktree cách ly, cử một sub-agent phác thảo sửa đổi, rồi cử một sub-agent khác xem xét dựa trên project skills và các test hiện có.

Connectors giúp mở PR, cập nhật ticket. Những việc vòng lặp không xử lý sẽ để vào hộp triage chờ xử lý. File trạng thái là trục sống của toàn bộ quá trình, ghi lại những gì đã thử, đã qua, còn mở gì — để sáng hôm sau, vòng lặp mới có thể tiếp tục từ điểm kết thúc hôm trước.

Nhìn lại, bạn chỉ cần thiết kế một lần duy nhất. Không có bước nào là prompt của bạn. Đó chính là câu nói của Steinberger, hiện thực rõ ràng. Và cùng một vòng lặp đó có thể chạy trong Codex lẫn Claude Code, vì các thành phần chính là giống nhau.

Vòng lặp vẫn chưa làm giúp bạn những việc gì

Vòng lặp đã thay đổi hình dạng công việc, nhưng chưa loại bỏ bạn khỏi quá trình. Và có ba vấn đề sẽ càng rõ nét hơn khi vòng lặp tiến bộ:

Xác thực vẫn là việc của bạn. Một vòng lặp không ai giám sát cũng là vòng lặp không ai sai lỗi. Mục đích của việc tách verifier thành sub-agent là để vòng lặp có ý nghĩa "đã hoàn tất"; dù vậy, "hoàn tất" chỉ là một tuyên bố, không phải bằng chứng. Tôi vẫn nhắc lại câu trong bài "code review in the age of AI": công việc của bạn là xuất hàng những đoạn code "bạn đã xác nhận chắc chắn chạy được".

Hiểu biết của bạn vẫn có thể mục nát, miễn là bạn cho phép. Vòng lặp xuất hàng "không phải do bạn viết code" càng nhanh, khoảng cách giữa "cái tồn tại" và "cái bạn thực sự có" càng lớn. Đó là debt về comprehension, nợ về hiểu biết. Một vòng lặp trôi chảy sẽ làm nó lớn hơn — trừ khi bạn đọc rõ những gì vòng lặp làm.

Tư thế thoải mái chính là tư thế nguy hiểm. Khi vòng lặp tự chạy, bạn sẽ rất muốn dừng mọi đánh giá, chấp nhận kết quả nó trả về. Tôi gọi đó là cognitive surrender (từ bỏ nhận thức). Thiết kế vòng lặp, khi bạn còn có khả năng phán đoán, là liều thuốc; khi bạn muốn tránh suy nghĩ, lại là chất xúc tác tăng tốc — cùng một hành động, nhưng kết quả trái ngược.

Xây dựng vòng lặp, nhưng vẫn giữ vai trò kỹ sư

Tôi nghĩ đây chính là dự báo về hướng đi của công việc trong tương lai. Nói lại: nếu tôi không tự xem xét code, hoặc hoàn toàn dựa vào vòng lặp tự động để sửa, chất lượng sản phẩm sẽ giảm. Tôi có thể rơi vào vòng xoáy xuống dốc, càng đào sâu càng khó thoát.

Nói cách khác, hãy xây dựng vòng lặp của bạn — nhưng đừng quên, prompt proxy của bạn vẫn là cách hiệu quả. Mọi thứ đều liên quan đến việc cân bằng.

Vòng lặp cũng sẽ mang lại kết quả khác nhau tùy thuộc vào "con người". Hai người dùng cùng một vòng lặp có thể nhận về 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 họ hiểu rõ, người kia dùng để tránh hiểu bất kỳ công việc nào. Nếu vòng lặp không phân biệt được sự khác biệt, bạn mới biết được.

Đây chính là lý do tại sao thiết kế vòng lặp còn khó hơn prompt engineering, chứ không dễ hơn. Cherny không nhấn mạnh rằng công việc trở nên đơn giản hơn, mà là điểm đòn bẩy đã dịch chuyển.

Hãy xây dựng vòng lặp như một người vẫn muốn tiếp tục làm kỹ sư, chứ đừng như người chỉ muốn nhấn nút khởi động.