Loop Engineering - Thiết kế hệ thống prompt cho agent

• Chấm dứt cách mỗi lượt đều trực tiếp prompt cho coding agent, và chuyển sang cách làm là thiết kế một hệ thống prompt thay cho agent
• Loop là một mục tiêu đệ quy trong đó AI lặp lại cho đến khi hoàn thành khi ta định nghĩa mục tiêu, và gồm khoảng năm thành phần
• Năm thành phần là Automations, Worktrees, Skills, Plugins·connectors, Sub-agents; hiện cả Claude Code lẫn Codex đều có đủ cả năm
• Thành phần thứ sáu là memory, có thể là file markdown hoặc bảng Linear lưu trạng thái bên ngoài một cuộc hội thoại đơn lẻ, nhằm bù cho mô hình vốn quên sau mỗi lần chạy
• Vẫn còn ở giai đoạn đầu nên bắt buộc phải chú ý chi phí token; việc kiểm chứng và thấu hiểu vẫn là phần việc của con người (build the loop, stay the engineer)

---

Định nghĩa Loop Engineering và bối cảnh xuất hiện

• Loop engineering là thay vị trí của con người đang prompt cho agent bằng một hệ thống, và tự tay thiết kế hệ thống làm việc đó
  • Loop là một mục tiêu đệ quy (recursive goal): khi định nghĩa mục tiêu, AI sẽ lặp lại cho đến khi hoàn tất
  • Đây có thể là cách làm việc tương lai với coding agent, nhưng vẫn còn ở giai đoạn đầu và bắt buộc phải chú ý chi phí token (mô hình sử dụng sẽ rất khác tùy bạn token rich hay token poor)
• Trích dẫn
  • Peter Steinberger: "Đừng prompt cho coding agent nữa, hãy thiết kế loop prompt cho agent"
  • Boris Cherny (người phụ trách Claude Code tại Anthropic): "Giờ tôi không còn prompt Claude nữa, mà vận hành một loop vừa prompt Claude vừa quyết định phải làm gì. Việc của tôi là viết loop"
• Khoảng 2 năm qua, cách làm là đưa prompt tốt và đủ ngữ cảnh, trao đổi từng lượt một, và trực tiếp cầm agent như một công cụ; nhưng cách đó đang dần kết thúc
• Giờ đây là lúc tạo ra một hệ thống nhỏ có thể tìm việc, phân phối việc, kiểm chứng, ghi lại phần đã xong và quyết định việc tiếp theo, rồi để hệ thống đó thúc agent làm việc
  • Nó nằm ở tầng cao hơn các bài trước về agent harness engineering (môi trường để một agent chạy) và factory model (hệ thống tạo phần mềm)
  • Một harness chạy bằng timer, tạo helper nhỏ và tự nuôi chính nó
• Đây không còn là vấn đề công cụ nữa — 1 năm trước, nếu muốn có loop thì phải tự viết và duy trì đống bash tạm bợ; còn bây giờ 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ư khớp chính xác với app Codex và cũng gần như giống Claude Code, nên thay vì tranh luận công cụ nào hơn, hãy thiết kế loop chạy được trên cả hai

Năm thành phần của loop và memory

• Một loop cần năm thứ, và thêm một nơi để ghi nhớ trạng thái
  • Automations — kích hoạt theo lịch để tự khám phá và phân loại (triage)
  • Worktrees — giúp hai agent làm việc song song không va chạm nhau
  • Skills — lưu lại tri thức dự án để agent không phải đoán mò bù vào
  • Plugins·connectors — kết nối agent với các công cụ bạn đang dùng
  • Sub-agents — một bên nghĩ giải pháp, bên kia kiểm chứng
• Thành phần thứ sáu là memory, như file markdown hoặc bảng Linear, tồn tại bên ngoài một cuộc trò chuyện đơn lẻ và giữ lại phần đã hoàn thành cùng việc cần làm tiếp
  • Trông có vẻ quá đơn giản, nhưng đây chính là thủ thuật mà mọi long-running agent đều dựa vào (bài trước về long-running agents)
  • Mô hình quên mọi thứ giữa các lần chạy, nên memory không thể nằm trong context mà phải nằm trên đĩa — agent có thể quên, repo thì không
• Hiện cả hai sản phẩm đều đã có đủ cả năm thành phần, chỉ khác chút về tên gọi nhưng năng lực thì giống nhau

Automations — nhịp tim của loop

• Automations là yếu tố biến loop từ một lần chạy thành một loop thật sự
  • Trong app Codex, tạo ở tab Automations, chọn project, prompt sẽ chạy, chu kỳ, và chạy trên local checkout hay background worktree
  • Những lần chạy phát hiện được gì đó sẽ đi vào Triage inbox, còn các lần không tìm ra gì thì tự được archive
  • OpenAI dùng nội bộ cho các việc nhàm chán như triage issue hằng ngày, tóm tắt lỗi CI, viết bản tóm lược commit, hoặc săn bug mới xuất hiện trong tuần qua
  • Automation có thể gọi skill, nên thay vì dán cả bức tường chỉ dẫn, chỉ cần kích hoạt $skill-name để giữ cho công việc lặp lại vẫn dễ bảo trì
• Claude Code đi đến cùng đích bằng scheduling và hooks
  • Với /loop, có thể chạy prompt hoặc lệnh theo khoảng thời gian định sẵn, lên lịch cron job, và bắn shell command bằng hooks ở những thời điểm cụ thể trong vòng đời agent
  • Nếu muốn nó tiếp tục chạy ngay cả khi đã gập laptop, có thể chuyển toàn bộ sang GitHub Actions
• Primitive thứ hai trong phiên làm việc là tính năng gần như cốt lõi của bài viết này
  • /loop chạy lại theo chu kỳ cố định
  • /goal tiếp tục cho đến khi điều kiện bạn viết ra thực sự trở thành đúng; sau mỗi lượt, một model nhỏ riêng biệt sẽ kiểm tra việc đã hoàn tất hay chưa, để agent viết code không tự chấm bài của chính mình
    • Ví dụ: đặt điều kiện như "mọi test trong test/auth đều pass, lint sạch" rồi rời máy
  • Codex cũng có /goal, hoạt động bằng cách chuyển lượt cho đến khi điều kiện dừng có thể kiểm chứng được thỏa mãn, và hỗ trợ pause·resume·clear

Worktrees — để song song không biến thành hỗn loạn

• Ngay khi chạy nhiều hơn một agent, file sẽ bắt đầu xung đột, và đây là điểm dễ thất bại
  • Hai agent cùng ghi vào một file cũng đau đầu như hai kỹ sư âm thầm commit cùng một dòng mà không nói với nhau
  • git worktree giải quyết việc này — cùng chia sẻ lịch sử của một repo nhưng mỗi bên có thư mục làm việc riêng trên nhánh của mình, nên phần chỉnh sửa của một agent không thể chạm vào checkout của bên kia
• Codex tích hợp sẵn hỗ trợ worktree nên nhiều luồng có thể động vào cùng một repo mà không va nhau
• Claude Code cũng cung cấp mức cô lập tương tự với git worktree, cờ --worktree để mở session trên checkout riêng, và cấu hình isolation: worktree gắn cho subagent (mỗi helper nhận một checkout mới và tự dọn dẹp khi xong)
• Worktree loại bỏ va chạm cơ học, nhưng giới hạn vẫn là bạn — số lượng thực sự có thể chạy không do công cụ quyết định mà do băng thông review của chính bạn (bài trước về the orchestration tax)

Skills — để không phải giải thích lại dự án mỗi lần

• Skill là cách chấm dứt chuyện mỗi session lại phải giải thích lại cùng một context dự án như cá vàng mất trí nhớ
  • Cả hai công cụ dùng cùng một format — một thư mục chứa SKILL.md với chỉ dẫn và metadata, cùng các script, tài liệu tham chiếu và asset tùy chọn
  • Codex gọi bằng $ hoặc /skills, hoặc tự chạy nếu công việc khớp với mô tả của skill, nên mô tả ngắn gọn và nhàm chán lại tốt hơn kiểu mô tả quá thông minh
  • Claude Code cũng hoạt động y như vậy (bài trước về agent skills)
• Skill là nơi ý định (intent) không trở thành chi phí lặp lại
  • Agent luôn bắt đầu mỗi session ở trạng thái lạnh và lấp chỗ trống của ý định bằng những phỏng đoán đầy tự tin (bài trước về the intent debt)
  • Skill là chỗ ghi ý định đó ra bên ngoài — convention, các bước build, hay kiểu "vì vụ việc kia nên ở đây không làm theo cách này"; viết một lần thì agent sẽ đọc ở mọi lần chạy
  • Không có skill, loop sẽ phải suy diễn lại toàn bộ dự án từ con số 0 ở mỗi chu kỳ; có skill thì tri thức tích lũy và sinh lãi kép
• Skill là format để viết, còn plugin là cách phân phối — khi muốn chia sẻ hoặc đóng gói cho nhiều repo thì đóng gói thành plugin (Codex và Claude Code đều như nhau)

Plugins·connectors — để loop chạm được vào công cụ thật

• Một loop chỉ nhìn thấy filesystem thì chỉ là loop nhỏ
  • Connector dựa trên MCP cho phép agent đọc issue tracker, query DB, gọi staging API, gửi tin nhắn Slack
  • Cả Codex lẫn Claude Code đều nói ngôn ngữ MCP, nên connector viết cho bên này thường cũng chạy nguyên vẹn ở bên kia
  • Plugin gói connector và skill lại với nhau để đồng đội có thể cài một lần thay vì phải dựng lại toàn bộ từ trí nhớ
• Đây là khác biệt giữa một agent chỉ nói "đây là bản sửa" với một loop có thể mở PR, liên kết Linear ticket, và ping vào kênh khi CI xanh
  • Connector là lý do loop không chỉ dừng ở việc nói về khả năng, mà còn thực sự hành động trong môi trường thật

Sub-agents — tách bên làm ra khỏi bên kiểm tra

• Cấu trúc hữu ích nhất trong loop rõ ràng là tách bên viết code khỏi bên kiểm tra
  • Model viết code quá dễ dãi khi tự chấm bài của mình
  • Một agent thứ hai với chỉ dẫn khác, thậm chí model khác, sẽ bắt được những gì agent đầu tiên đã tự thuyết phục rằng ổn
• Codex chỉ tạo subagent khi được yêu cầu, chạy đồng thời rồi gộp kết quả thành một câu trả lời
  • Định nghĩa agent riêng bằng file TOML trong .codex/agents/ (name·description·instructions, tùy chọn model·reasoning effort)
  • Ví dụ: security reviewer dùng model mạnh với high effort, còn explorer dùng model nhanh chỉ đọc
• Claude Code làm điều tương tự với subagents trong .claude/agents/ và agent teams để giao việc qua lại
  • Cách phân công thường thấy ở cả hai công cụ là một agent khám phá, một agent triển khai, và một agent kiểm tra so với spec (bài trước về the code agent orchestra, adversarial code review)
• Vì loop chạy khi bạn không nhìn vào nên phải có verifier đáng tin để bạn có thể rời chỗ
  • Subagent có model riêng và thao tác công cụ riêng nên tốn thêm token, hãy dùng ở nơi mà ý kiến thứ hai thực sự đáng giá
  • Đây cũng là điều /goal của Claude Code làm ở bên trong — một model mới quyết định công việc đã xong hay chưa thay cho model thực hiện, tức áp dụng tách maker·checker ngay vào điều kiện dừng

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

• Khi ghép lại, một thread đơn lẻ biến thành một bảng điều khiển nhỏ; đây là một mẫu được dùng lặp đi lặp lại
  • Automation chạy trên repo mỗi sáng, prompt của nó gọi triage skill để đọc lỗi CI của hôm qua, issue đang mở và commit gần đây, rồi ghi kết quả vào file markdown hoặc bảng Linear
  • Với mỗi mục đáng làm, thread mở một worktree cô lập và giao cho sub-agent phác thảo bản sửa; một sub-agent thứ hai review bản đó đối chiếu với project skill và các test hiện có
  • Connector cho phép loop mở PR và cập nhật ticket; phần nào loop không xử lý được thì đi vào triage inbox
  • State file là xương sống của toàn bộ hệ thống — nó nhớ đã thử gì, đã pass gì và còn gì đang mở, để lần chạy sáng hôm sau tiếp tục từ đúng chỗ hôm nay dừng lại
• Điểm cốt lõi là không phải prompt từng bước trong số đó mà là thiết kế một lần — dù là Codex hay Claude Code thì các thành phần vẫn giống nhau, nên loop cũng là cùng một loop

Những gì loop vẫn chưa thể làm thay

• Loop thay đổi bản chất công việc chứ không xóa con người; thậm chí loop càng tốt thì ba vấn đề sau càng trở nên sắc nét
• Việc kiểm chứng vẫn là của bạn
  • Một loop chạy không người giám sát cũng là một loop phạm lỗi mà không ai giám sát
  • Lý do tách verifier sub-agent khỏi maker là để câu "xong rồi" của loop có ý nghĩa hơn, nhưng ngay cả vậy thì "done" vẫn là một tuyên bố chứ không phải bằng chứng (bài trước về code review in the age of AI — công việc là xuất xưởng đoạn code đã được xác nhận là hoạt động)
• Sự thấu hiểu sẽ mục ruỗng nếu bị bỏ mặc
  • Loop càng nhanh xuất xưởng đoạn code mà bạn không tự viết, khoảng cách giữa cái đang tồn tại và cái bạn thực sự hiểu càng lớn
  • Đó là comprehension debt; một loop trơn tru sẽ làm khoảng cách đó nở nhanh hơn nếu bạn không đọc những gì loop tạo ra
• Tư thế thoải mái là tư thế nguy hiểm
  • Khi loop tự chạy, rất dễ ngừng có chính kiến và chấp nhận nguyên xi thứ nó trả về (cognitive surrender)
  • Thiết kế loop là thuốc chữa nếu làm với sự phán đoán, nhưng là chất xúc tác nếu làm để né suy nghĩ — cùng một hành động, kết quả trái ngược hoàn toàn

Hãy xây loop, nhưng vẫn là kỹ sư

• Đây có vẻ là phần xem trước của cách công việc sẽ tiến hóa, nhưng nếu không trực tiếp review code hoặc chỉ dựa vào loop tự động thì bạn có thể mắc kẹt trong vòng xoáy đi xuống nơi chất lượng sản phẩm giảm và cái hố ngày càng sâu hơn
• Hãy thiết lập loop, nhưng việc trực tiếp prompt cho agent vẫn hiệu quả; điều cốt lõi là tìm được thế cân bằng phù hợp
• Loop có thể mang lại kết quả hoàn toàn trái ngược tùy người dùng — trong hai người tạo cùng một loop, một người dùng nó để đi nhanh hơn trên phần việc mình hiểu sâu, người kia dùng nó để tránh phải hiểu công việc
  • Loop không biết khác biệt đó, nhưng bạn biết
• Đây là lý do thiết kế loop không hề dễ hơn prompt engineering mà còn khó hơn — ý của Cherny không phải công việc đã dễ đi, mà là điểm tạo đòn bẩy đã dịch chuyển
• Kết luận: hãy xây loop, nhưng hãy xây như một người sẽ tiếp tục là kỹ sư chứ không chỉ là người bấm nút Start

[shakespeares]

Việc kiểm chứng vẫn là phần của chính bạn

Sự hiểu biết nếu bị bỏ mặc sẽ mục ruỗng

Tư thế thoải mái là tư thế nguy hiểm

=> Cuối cùng, cần tự mình xác nhận và cần cách viết prompt để giảm thiểu công việc lặp lại.