Agent loop qua một bug: từ prompt tới tool call và workspace

1. Một bug, một câu giao việc

Video được Coder tài trợ.

ByteMonk mở đầu bằng một tình huống: giả sử giao cho một coding agent nhiệm vụ này. "Orders API của chúng ta chậm với các khách hàng lớn. Tìm ra vấn đề, sửa nó, chạy test, và chuẩn bị các thay đổi để review." Sau đó ta ngồi nhìn agent tìm kiếm trong repository, đọc file, sửa code và chạy lệnh trong terminal. Test fail, agent đọc lỗi, đổi cách implement rồi thử lại (theo ví dụ trong video đăng ngày 28/10/2026).

Sơ đồ: câu giao việc cho coding agent nối tới ba bước Search, Read and use, Execute — Câu hỏi mở đầu của video (đăng ngày 28/10/2026): cái gì nối câu giao việc "Our Orders API is slow for large customers" với các action? Bên phải là ba bước minh hoạ: tìm "orders" trong repository, đọc `OrderService.java`, rồi chạy `./gradlew test` trong terminal và thấy BUILD SUCCESSFUL.

Nhưng thứ gì thực sự nối câu nói của người dùng với tất cả những action đó? Làm sao model lấy được đúng file? Ai là người thực thi các lệnh mà nó yêu cầu? Video (đăng ngày 28/10/2026) đi theo đúng một bug đó, từ prompt đầu tiên tới code diff cuối cùng. Người xem sẽ thấy cái gì được đưa vào model, các câu trả lời của model biến thành action ra sao, các action đó chạy ở đâu, và phần nào vẫn cần con người review. Sau đó ByteMonk lấy cùng workflow ấy và hỏi: điều gì thay đổi khi một team chạy 10 coding agent cùng lúc?

2. Từ autocomplete tới coding agent: agent software gửi gì cho model

ByteMonk bắt đầu bằng một phép so sánh. Với một công cụ autocomplete, model gợi ý code. Bạn chấp nhận gợi ý, lưu file và tự chạy nó. Một coding agent thì khác: nó nối model với các tool có thể tự thực hiện những action đó (theo video đăng ngày 28/10/2026).

Quay lại task orders API. Theo cách video đăng ngày 28/10/2026 mô tả, agent software gửi cho model bốn thứ: yêu cầu của bạn, các chỉ dẫn của project, phần context đang có, và mô tả của các tool mà model được dùng. Những tool này có thể là tìm kiếm trong repository, đọc một file, sửa code, hoặc chạy một lệnh shell.

Sơ đồ Model và Agent software, ô trên ghi Request, Instructions, Context, Tools; ô dưới là một structured request bắt đầu bằng tool search — Gói gửi tới model trong ví dụ của video (đăng ngày 28/10/2026): Request là "Orders API is slow for large customers", Instructions là `AGENTS.md` và các convention, Context là repo map và các file đang mở, Tools là search, read, edit, shell. Chiều ngược lại, model trả cho agent một structured request, bắt đầu bằng `{ "tool": "search",`.

Model sau đó có thể trả về một structured request, ví dụ "tìm phần code xử lý đơn hàng của khách". Request đó chứa tên một tool và input mà tool cần. Agent software kiểm tra xem action đó có được phép không, thực thi việc tìm kiếm, rồi gửi kết quả ngược lại cho model. Lúc này model đã có một số tên file để điều tra (theo video đăng ngày 28/10/2026).

3. Tool call, kết quả, test fail: agent loop

Trong ví dụ của video đăng ngày 28/10/2026, model tiếp tục yêu cầu đọc một file. Nội dung file quay về, và model dùng thông tin đó để chọn action kế tiếp. Rồi tới một lúc, nó yêu cầu sửa code và chạy test.

Giờ giả sử test fail vì thay đổi đó làm hỏng pagination. Theo video đăng ngày 28/10/2026, lỗi này trở thành một phần của context cho request kế tiếp gửi tới model. Model có thể dựa vào nó để đề xuất một lần sửa khác, rồi lại yêu cầu chạy test thêm lần nữa.

Ô Sent to the model có thêm dòng đỏ test failed: pagination broke; bên phải là bốn tool — Cùng gói gửi tới model ở vòng sau, giờ có thêm một dòng màu đỏ "test failed: pagination broke" (ví dụ trong video đăng ngày 28/10/2026). Bên phải là bốn tool mà agent software nắm: Search the repository, Read a file, Edit code, Run a shell command.

Chuỗi trao đổi lặp đi lặp lại này chính là agent loop. Vì vậy, theo ByteMonk (video đăng ngày 28/10/2026), khi bạn thấy một agent làm việc suốt 20 phút, thứ bạn đang xem là một chuỗi gồm các request tới model, các action của tool, và các kết quả. Và điều đó dẫn tới câu hỏi tiếp theo: những action đó nên chạy ở đâu?

4. Các action chạy ở đâu, và bài toán N+1 query

Với một coding agent chạy local, theo video đăng ngày 28/10/2026, các action có thể chạy thẳng trên laptop của bạn. File tool đọc bản checkout của bạn, shell tool khởi chạy bản build của bạn, test runner của bạn chạy test.

Để cụ thể hơn, ByteMonk dựng một demo: một orders API viết bằng Java, một database PostgreSQL, và một vấn đề hiệu năng. Một khách hàng yêu cầu danh sách đơn hàng của mình, kiểu "lấy các đơn hàng của khách 123". Ứng dụng chạy một query tới database để tải các đơn hàng. Rồi với mỗi đơn hàng, nó lại chạy thêm một query nữa để tải các line item của đơn đó. Vậy với 100 đơn hàng, ta có 101 query. Đây là bài toán N+1 query. Khi số đơn hàng tăng lên, ứng dụng phải đi lại với database nhiều lượt hơn (ví dụ trong video đăng ngày 28/10/2026).

Hộp Orders API Java với endpoint GET /customers/{id}/orders, mũi tên tới PostgreSQL và một bộ đếm queries — Demo trong video đăng ngày 28/10/2026: Orders API viết bằng Java, endpoint `GET /customers/{id}/orders` đi qua `OrderController` và `OrderRepository`, gắn nhãn đỏ "performance problem". Dưới logo PostgreSQL là một bộ đếm query, với các mũi tên đỏ dồn về database.

Hình 4.1Bài toán N+1 query trong ví dụ của video đăng ngày 28/10/2026: một query tải danh sách đơn hàng, rồi thêm một query cho line item của từng đơn, nên 100 đơn hàng thành 101 lượt đi lại với database.

5. Agent đi tìm bằng chứng, rồi bốn agent trên một máy

Prompt trong ví dụ của video (đăng ngày 28/10/2026) chỉ mô tả triệu chứng: "Các khách hàng lớn đang thấy response chậm. Điều tra nguyên nhân, sửa nó, và kiểm chứng thay đổi." Vì vậy agent phải tự gom bằng chứng. Nó có thể tìm endpoint, đọc phần code truy cập database, và xem các câu SQL được sinh ra trong lúc chạy test. Khi đã xác định được các query lặp lại, nó có thể thử sửa. Sau đó nó kiểm tra rằng số query đã giảm và endpoint vẫn trả về đúng kết quả.

Theo ByteMonk (video đăng ngày 28/10/2026), các coding agent dạng CLI chạy local có thể chạy thẳng trên máy của bạn, và với một developer làm việc trên một repository, cách đó có thể chạy cực kỳ tốt. Nhưng giờ hãy hình dung bốn agent làm việc cùng lúc.

Ta có thể đưa cho mỗi agent một bản copy riêng của code, nhưng tất cả vẫn chạy trên cùng một máy tính. Các bản build của chúng có thể làm chậm lẫn nhau. Và nếu hai agent cùng khởi động một test server trên cùng một port, một trong hai sẽ không khởi động được (theo video đăng ngày 28/10/2026).

Hình 5.1Bốn agent, bốn bản copy của orders-api, nhưng vẫn chung một máy: build tranh nhau tài nguyên, và hai test server trên cùng một port thì một cái không khởi động được (theo video đăng ngày 28/10/2026).

6. Mỗi agent một môi trường cách ly

Vì thế, theo ByteMonk (video đăng ngày 28/10/2026), cần cho mỗi agent một môi trường riêng, với code riêng, tool riêng và test database riêng. Kiến trúc giờ trông như sau: task ở trên cùng, rồi tới agent, rồi tới một môi trường cách ly gồm repository, build tool, dependency, test và vân vân.

Bốn task Fix orders latency, Add API tests, Spring Boot upgrade, Fix retry bug, mỗi task một môi trường container, Kubernetes pod, VM, container — Bốn task, bốn môi trường cách ly trong ví dụ của video (đăng ngày 28/10/2026): container, Kubernetes pod, VM, container. Mỗi môi trường có repository `orders-api`, JDK và Gradle, dependency từ Maven, test database PostgreSQL. Dòng dưới cùng ghi việc mỗi agent làm mà không đụng tới agent khác: `npm install`, "edited its own copy", `postgres :5432` ở hai môi trường khác nhau.

Môi trường đó có thể là một container, một Kubernetes pod hay một VM. Lúc này điều đó chưa thật sự quan trọng. Điều quan trọng là sự cách ly (isolation). Agent 1 có thể cài thứ gì đó mà không làm hỏng Agent 2. Agent 2 có thể sửa bản copy repository của riêng nó. Agent 3 có thể khởi động một database local trên một port mà không va chạm với agent khác (theo video đăng ngày 28/10/2026).

7. Môi trường được phép chạm tới đâu

Cách ly giải quyết được một vấn đề, nhưng ByteMonk chỉ ra (video đăng ngày 28/10/2026) rằng một vấn đề khác xuất hiện ngay: môi trường này được phép truy cập chính xác những gì? Orders agent có lẽ cần GitHub. Nó có thể cần Maven Central. Nó có thể cần một test database. Nhưng nó có cần truy cập production không? Chắc chắn là không. Nó có cần truy cập Internet không giới hạn không? Có lẽ không. Còn API key của LLM có cần nằm bên trong môi trường đó không? ByteMonk gọi đó là một câu hỏi thú vị.

Hình 7.1Câu hỏi "nó nên được phép chạm tới đâu" trong video đăng ngày 28/10/2026: GitHub, Maven Central và test database thì cần; production thì không; Internet không giới hạn thì có lẽ không.

Tới đây, theo ByteMonk (video đăng ngày 28/10/2026), chuyện này bắt đầu trông ít giống một bài toán AI hơn, và giống một bài toán platform engineering hơn nhiều.

Lời giải hiển nhiên là permission prompt. "Tôi chạy lệnh này được không?" Approve. "Tôi sửa file này được không?" Approve. "Tôi cài package này được không?" Approve.

8. Permission prompt, approval fatigue và network policy

Nhưng theo ByteMonk (video đăng ngày 28/10/2026), con người là những security policy rất tệ. Video nêu rằng người dùng Claude Code đã approve khoảng 93% số permission prompt, và Anthropic gọi vấn đề nảy sinh từ đó là approval fatigue. Bài "How we built Claude Code auto mode" của Anthropic (đăng 25/03/2026, đọc ngày 30/10/2026) ghi đúng con số này: người dùng Claude Code approve 93% permission prompt.

ByteMonk thấy điều đó hợp lý (video đăng ngày 28/10/2026): sau khi bấm Allow nhiều lần, bạn không còn thật sự audit nữa, bạn chỉ đang bấm. Vì vậy, thay vì hỏi "lệnh cụ thể này có nên được phép không", một câu hỏi hữu ích hơn là: toàn bộ môi trường này nên có khả năng chạm tới những gì?

Bảng Sample agent workspace: network policy với cột ALLOW và BLOCK, bên phải agent workspace bị chặn tới Production DB — Câu hỏi cũ bị gạch đi, thay bằng "What should this environment be capable of reaching?" (video đăng ngày 28/10/2026). Network policy mẫu cho phép GitHub, package registry, test database, để dấu hỏi ở staging API, và chặn production DB cùng internal HR API; mũi tên từ agent workspace tới Production DB bị chặn lại.

Ví dụ, với một agent workspace mẫu trong video đăng ngày 28/10/2026, ta cho phép GitHub, package registry, test database, có thể cả staging API, nhưng chặn truy cập tới production DB và internal HR API. Lúc này, kể cả khi model ra một quyết định tồi, vẫn có một ranh giới nằm bên dưới nó. Lời khuyên của ByteMonk trong video đăng ngày 28/10/2026: đừng dựa vào việc AI cư xử đúng; hãy dựng một môi trường mà ở đó action sai khó thực hiện hơn.

9. Coder Agents: tách agent loop, LLM và execution environment

Tới đây video chuyển sang Coder. Theo video đăng ngày 28/10/2026, nền tảng sẵn có của Coder tạo ra các remote development workspace, tức VM, Kubernetes pod hay container, dựa trên các template do platform team quản lý. Developer vẫn có thể kết nối vào bằng VS Code, JetBrains, Cursor, SSH hoặc trình duyệt. Và giờ Coder đã thêm Coder Agents.

ByteMonk kể một điều làm mình bối rối lúc đầu (video đăng ngày 28/10/2026): Coder Agents không đơn giản là chạy thêm một coding CLI bên trong một máy remote. Bạn vẫn có thể chạy các coding agent dạng terminal bên trong Coder workspace, nhưng Coder Agents là một kiến trúc riêng. Coder implement agent loop trong control plane, còn workspace chủ yếu là execution environment.

Vì vậy, theo video đăng ngày 28/10/2026, kiến trúc này tách ra ba thứ mà rất dễ bị trộn lẫn trong đầu: agent loop, LLM, và execution environment. Vòng orchestration chạy trong control plane của Coder. Vòng đó gửi context tới LLM, nhận về các tool call, quyết định cái gì cần thực thi, và gửi các operation đó tới một workspace. Bản thân LLM có thể là Claude, GPT, Gemini, một model chạy qua các nền tảng cloud, hoặc thậm chí một endpoint tương thích OpenAI. Còn code thực tế thì chạy trong một Coder workspace bình thường. Trang tài liệu Coder Agents (đọc ngày 30/10/2026) cũng ghi rằng agent loop chạy trong control plane: control plane gửi prompt tới LLM provider đã cấu hình, nhận các tool call trong response, rồi thực thi chúng bằng cách kết nối tới một Coder workspace.

Sơ đồ Developer tới Control plane gồm agent loop, model config, API key; Control plane trao đổi context và tool calls với LLM, gửi operations tới Coder workspace — Kiến trúc Coder Agents theo video đăng ngày 28/10/2026: Developer gửi yêu cầu vào control plane, nơi giữ agent loop, model config và API key. Control plane gửi context lên LLM (logo các hãng model, kèm "any OpenAI-compatible endpoint") và nhận tool call về, rồi gửi operation sang Coder workspace, nơi code chạy: git checkout, Java và Gradle, PostgreSQL, `./gradlew test`, với hai nhãn xanh "no agent process" và "no provider key".

10. API key không nằm trong workspace, và self-hosted không có nghĩa là private

Với ví dụ orders, theo video đăng ngày 28/10/2026, mọi thứ trông đại khái thế này: một developer yêu cầu sửa độ trễ của orders, rồi tới Coder agent, LLM, tool call, và Coder workspace, nơi có Git, Java, Postgres và test. Chi tiết quan trọng là model không SSH thẳng vào máy. Control plane đứng giữa điều phối workflow. Theo những gì Coder nói, được nêu trong video đăng ngày 28/10/2026, bản thân workspace không có process agent nào dành riêng cho AI và không cần API key của LLM provider. Đọc file, chạy lệnh shell, build và test đều diễn ra trong workspace. Agent loop và cấu hình model thì nằm lại ở control plane.

Theo ByteMonk (video đăng ngày 28/10/2026), sự tách biệt này có ích. Giả sử ngược lại, mỗi môi trường agent đều chứa một OpenAI API key hay Anthropic API key. Giờ hình dung repository có một dependency đã bị xâm nhập, hoặc agent cài phải một package độc hại. Process đó có thể đọc các biến môi trường và lấy cắp credential của model. Với kiến trúc này, workspace hoàn toàn không cần credential của provider.

Control plane nói chuyện với model, workspace thực thi code, nên theo video đăng ngày 28/10/2026, ta có thể thu nhỏ mạng của workspace lại nhiều hơn.

Sơ đồ your network chứa Control plane có API key và Workspace no provider key; mũi tên model requests đi ra ngoài tới Model provider — "Self-hosted ≠ private by default" (video đăng ngày 28/10/2026): control plane và workspace nằm trong mạng của bạn, workspace có nhãn "no provider key", nhưng mũi tên "model requests" vẫn đi ra ngoài tới Model provider.

Nhưng ByteMonk nêu một phân biệt quan trọng (video đăng ngày 28/10/2026): tự host workflow của agent không tự động có nghĩa là prompt hay code của bạn không bao giờ rời khỏi mạng. Nếu bạn cấu hình Anthropic, OpenAI hay Google làm model provider, thì control plane của Coder vẫn phải gửi các request tới provider đó.

11. Ba câu hỏi và kiến trúc private hoàn toàn

Thật ra, theo ByteMonk (video đăng ngày 28/10/2026), ở đây có ba câu hỏi riêng biệt. Agent loop chạy ở đâu? Code được thực thi ở đâu? Và model chạy ở đâu?

Với Coder Agents, theo video đăng ngày 28/10/2026, agent loop và execution environment đều có thể chạy bên trong hạ tầng do bạn kiểm soát. Nghĩa là kiến trúc private hoàn toàn có thể trông như sau: một mạng private, trong đó có control plane của Coder, một LLM nội bộ, và một workspace cách ly với Git private và các service nội bộ. Không cần API model bên ngoài nếu bạn tự cung cấp model ở bên trong. Video cũng nêu rằng Coder hỗ trợ cả các triển khai air-gapped hoàn toàn, nơi môi trường có thể vận hành mà không có truy cập Internet ra ngoài.

Khung private network air-gapped chứa Control plane, Isolated workspace và Internal LLM; Model provider bên ngoài bị làm mờ với nhãn not required — Kiến trúc private hoàn toàn trong video đăng ngày 28/10/2026: trong khung "private network · air-gapped" là control plane, một isolated workspace (git, Java, tests, no provider key, private git, internal services) và Internal LLM ("your model, your hardware"); Model provider bên ngoài bị làm mờ với nhãn đỏ "not required".

12. Quay lại bug orders: điều tra, sửa, test fail, lặp lại

Rồi ByteMonk quay lại order service. Trong ví dụ của video đăng ngày 28/10/2026, task được gửi đi và Coder có thể dựng một workspace từ một template. Template đó có thể đã chứa sẵn JDK, Gradle, PostgreSQL, cấu hình Git của bạn, các chứng chỉ của công ty, network rule, giới hạn tài nguyên, và đủ thứ khác.

Agent vào workspace và bắt đầu điều tra (demo trong video đăng ngày 28/10/2026). Có thể nó tìm trong repository, chạy benchmark, xem các câu SQL, và phát hiện việc tải 100 đơn hàng sinh ra 101 query tới database. Sau đó nó đổi method trong repository để lấy dữ liệu cần thiết một cách hiệu quả. Nó chạy lại benchmark và đưa cho người dùng bản diff.

Orders workspace với ba bước Investigate, Change, Test; ô Agent to you: diff for review ghi Changed OrderRepository.java, Queries 101 to 2 — Ba bước trong Orders workspace (demo trong video đăng ngày 28/10/2026): Investigate (search the repository, run the benchmark, look at the SQL, 100 orders → 101 queries), Change (`OrderRepository`, fetch the data efficiently), Test (benchmark again). Màn hình ghi kết quả "2 queries", và ô diff gửi để review ghi file đổi là `OrderRepository.java`, số query từ 101 xuống 2; con số sau khi sửa chỉ có trên màn hình, không được nói ra.

Và một lần nữa, theo video đăng ngày 28/10/2026, agent đôi khi có thể tạo ra một thay đổi tồi. Có thể bản sửa đầu tiên loại bỏ được N+1 query nhưng lại làm hỏng pagination. Thế là test fail. Agent thấy lỗi, đổi cách implement, và chạy lại test.

Theo ByteMonk (video đăng ngày 28/10/2026), giá trị của một agent không nằm ở việc sinh code hoàn hảo. Nó nằm ở khả năng quan sát môi trường và lặp lại.

13. Mười agent và một bản kế hoạch upgrade Spring Boot

Giờ hình dung 10 agent làm 10 task khác nhau (ví dụ trong video đăng ngày 28/10/2026). Một số sửa bug hoặc thêm test, số khác điều tra.

Với một lần upgrade Spring Boot, ByteMonk nói có thể giao một yêu cầu chỉ để điều tra, không đụng code (ví dụ trong video đăng ngày 28/10/2026). Câu yêu cầu ByteMonk đọc:

Check what might break, show me the affected files, dependency issues, and an upgrade plan. Don't change any code.

Trong ví dụ của video đăng ngày 28/10/2026, agent xem xét project và trả về một bản báo cáo để một engineer review.

Bảng Agents 10 với cột Agent, Task, Workspace, Status từ Agent 01 tới Agent 10 — Bảng 10 agent trong minh hoạ của video (đăng ngày 28/10/2026): mỗi agent một task và một workspace riêng (ws-01 tới ws-10), với trạng thái running, testing hoặc review; Agent 07 làm "Spring Boot upgrade" có trạng thái "report ready".

14. Model, agent software, environment: ba phần tách rời và trade-off

Lúc này ta đang quản lý 10 agent, mỗi agent có task và workspace riêng. Theo ByteMonk (video đăng ngày 28/10/2026), ta cần biết mỗi agent được truy cập những gì, nó dùng model nào, nó đã chạy những lệnh nào, và khi nào thì tắt workspace của nó. Khi giao càng nhiều việc hơn, việc quản lý các môi trường đó trở thành một phần của việc xây hệ thống AI.

Team của bạn có thể dùng Claude hôm nay và chọn một model khác vào ngày mai. Vì vậy, theo ByteMonk (video đăng ngày 28/10/2026), giữ ba phần tách rời giúp chuyển đổi dễ hơn. Model quyết định làm gì. Agent software quản lý vòng lặp và các tool call. Còn environment chạy các lệnh, build và test. Như thế, đổi model không đòi hỏi phải dựng lại toàn bộ hệ thống.

Ba thẻ Model decides what to do, Agent software manages the loop and tool calls, Environment runs commands, builds, tests — Ba phần tách rời trong video đăng ngày 28/10/2026: Model "decides what to do", Agent software "manages the loop and tool calls", Environment "runs commands, builds, tests".

Nhưng vẫn có trade-off, theo video đăng ngày 28/10/2026. Các workspace này cần thời gian để khởi động, tốn compute, và cần setup nhiều hơn với các bộ dữ liệu lớn hay phần cứng đặc biệt. Với một thay đổi nhanh, một coding agent local có thể đơn giản hơn. Nhưng với các task dài hơn, nhiều agent làm cùng lúc, hoặc các team có quy định bảo mật chặt, các workspace được kiểm soát trở nên hữu ích hơn nhiều.

15. Bốn lớp của một agent architecture và câu hỏi cuối

ByteMonk quay lại câu hỏi từ đầu video: "AI, sửa orders API đi." Code thực sự chạy ở đâu? Theo ByteMonk (video đăng ngày 28/10/2026), câu trả lời không nên chỉ là "ở đâu đó mà model chạy được lệnh".

Theo video đăng ngày 28/10/2026, một agent architecture hữu ích có ít nhất bốn lớp. Model cung cấp trí tuệ. Agent biến trí tuệ đó thành một chuỗi action. Execution environment là nơi các action đó thật sự diễn ra. Và policy layer quyết định môi trường đó được phép chạm tới những gì.

Hình 15.1Bốn lớp tối thiểu của một agent architecture hữu ích theo ByteMonk (video đăng ngày 28/10/2026), mỗi lớp kèm vai trò đúng như video nêu.

Theo ByteMonk (video đăng ngày 28/10/2026), ban đầu AI giúp ta gõ code. Rồi AI bắt đầu sửa code của ta. Giờ ta đang bắt đầu giao trọn những task engineering.

ByteMonk kết bằng một lời nhắn (video đăng ngày 28/10/2026): lần tới khi ai đó cho bạn xem một AI agent tự mình sửa cả một repository, đừng chỉ hỏi "đó là model nào". Hãy hỏi câu hỏi engineering thú vị hơn: ta đang cho phép model đó chạy bên trong cái gì?