Originally published on NextFuture
Bạn cắm thêm một MCP server nữa vào Claude Code, và agent bắt đầu gọi sai tool. Hoặc ngược lại: bạn tự viết vòng lặp agent, nó chạy hết vòng này sang vòng khác rồi vẫn báo "done" trong khi test đỏ. Hai sự cố đó không cùng một lỗi kiến trúc, và bài này chỉ ra chỗ nào thuộc MCP, chỗ nào thuộc agent loop.
MCP và agent loop không phải hai lựa chọn
Một bài phân tích kiến trúc trên Dev.to của Ama Senevirathne nói thẳng: coi hai thứ này là hai trường phái cạnh tranh là architectural anti-pattern. Theo tác giả, trong production MCP là lớp transport I/O có type, còn agent loop là lớp điều phối và kiểm chứng ("execution and verification governor").
Định nghĩa để khỏi lẫn. MCP, theo bài viết, là "an open standard (introduced by Anthropic)" dựng một giao thức client-server chung để model truy vấn context và gọi tool. Agent loop là vòng lặp đóng: đọc output của tool, kiểm tra negative assertion, phát hiện lặp vô hạn, rồi tự chữa.
Đọc lại hai sự cố ở đầu bài. Gọi sai tool là lỗi contract — thuộc MCP. Báo "done" khi test đỏ là lỗi verification — thuộc agent loop. Cắm thêm MCP server không sửa được lỗi thứ hai, và viết vòng lặp xịn hơn không sửa được lỗi thứ nhất.
Vì sao function calling tự viết vỡ khi lên quy mô
Trước MCP, mỗi team tự định nghĩa JSON schema để nối LLM với database, GitHub API và terminal. Bài viết liệt kê ba failure mode gặp trong production:
Context bloat — mỗi định nghĩa tool nhồi "400-800 tokens of schema instructions" vào system prompt của mỗi turn.
Schema drift — khi một API parameter đổi, prompt template "silently broke or induced hallucinations". Không có lỗi biên dịch, chỉ có output sai.
Security injection — expose raw bash mà không có typed capability boundary ở giữa thì indirect prompt injection chạy được lệnh phá hệ thống.
Con số 400-800 token/tool là chỗ đáng tính lại nếu bạn đang trả tiền theo token. Càng nhiều tool và càng nhiều turn, phần schema lặp lại càng chiếm chỗ trước khi model đọc tới câu hỏi thật. Cách MCP xử lý, theo bài: MCP server chạy trong container tách biệt và expose endpoint có type (tools/list, tools/call, resources/read), còn host harness lo capability negotiation, rate limiting và permission grant.
Bảng phân vai để tra khi thiết kế
Chiều kiến trúcMCPAgent loop
Trách nhiệm chínhContract chuẩn cho tool và contextĐiều phối feedback, phục hồi lỗi
TopologyJSON-RPC client-serverVòng thực thi có hướng (DAG hoặc while-loop)
Bề mặt bảo mậtCapability negotiation, biên authAST gating, sandbox subprocess
Giữ stateStateless request/responseBộ nhớ theo thời gian, đồ thị phụ thuộc nhân quả
Xử lý lỗiTrả structured error codePhát hiện lặp trong bộ nhớ, rollback
Dòng "giữ state" là dòng quyết định nhiều nhất. MCP stateless nghĩa là không có chỗ nào trong MCP biết rằng ba bước trước agent đã đọc file .env. Nếu bạn cần loại rủi ro tích lũy theo phiên, nó phải nằm ở lớp loop — không phải ở server.
Prompt filter chỉ là khuyến nghị, hãy chặn trên đường thực thi
Đây là chỗ hai nguồn gặp nhau. Một bài của nhóm Doberman dẫn khái niệm lethal trifecta của Simon Willison: private data, untrusted content, và một đường exfiltrate, cùng tồn tại trong một session. Bài viết lập luận rằng một coding agent trên laptop có đủ cả ba theo mặc định: nó đọc code của bạn, đọc README của dependency, và chạy được curl.
Lập luận tiếp theo đáng để dev đọc kỹ: phần lớn thứ được gọi là "AI guardrail" chỉ đọc prompt hoặc output rồi gắn cờ, nên theo tác giả nó là advisory — chạy trước hoặc sau khi model đã quyết định, và không có gì buộc tool call thật phải đi qua nó. Cách làm nhóm này đề xuất là chuẩn hoá mọi tool call (shell command, file write, MCP call) thành một object và đẩy qua một decision engine trước khi thực thi.
Hai thuộc tính họ nhấn mạnh, và cả hai đều dịch được thành yêu cầu kỹ thuật cho loop của bạn:
Fail closed — mọi lỗi, mọi trường hợp chưa xử lý đều thành từ chối, kể cả im lặng. Bài viết mô tả deadline cứng: 2 phút cho hộp thoại desktop, 20 phút làm mốc chặn cuối, sau đó deny và log riêng là timeout để phân biệt với deny tường minh.
Raise-only — policy tự thắt được nhưng không tự nới. Theo bài, mọi lần nới vĩnh viễn cần phê duyệt có possession factor (TOTP hoặc mật khẩu máy) và ghi vào ledger append-only.
Nhóm này cũng phân biệt sandbox với authorization, và đây là phần dùng được ngay cả khi bạn không dùng tool của họ: sandbox giới hạn thiệt hại đổ vào đâu khi một action đã chạy, còn authorization quyết định action có chạy hay không, kèm ngữ cảnh. Ví dụ họ đưa ra: cùng một lệnh curl tới cùng một host có thể PASS trong session sạch và BLOCK trong session vừa đọc .env. Sandbox không thấy được khác biệt đó vì nó không có bộ nhớ phiên. Lưu ý: Doberman tự mô tả là open source Apache-2.0, còn ở giai đoạn alpha và "defense-in-depth, not airtight" — nên coi đây là mô hình thiết kế, không phải bảo đảm.
Bốn invariant nên chốt trước khi lên production
Bài kiến trúc kết bằng bốn nguyên tắc, diễn giải lại theo việc bạn phải làm:
Protocol over prompts — đưa tool qua MCP server để có validation lúc dịch, thay vì tin model sinh JSON đúng schema.
Không tin agent tự đánh giá — tác giả viết agent "must never judge its own success"; điều kiện dừng phải là exit code xác định (0), không phải câu "done" của model.
AST gating thay vì regex — parse thay đổi code bằng AST parser (bài nhắc tree-sitter) để loại cú pháp sai trước khi file ghi xuống disk.
Nén token ở CLI — dùng proxy mức OS để bỏ ANSI code và log trùng trước khi nhồi output tool trở lại context.
Việc làm được ngay tuần này
Mở lại agent gần nhất bạn tự viết và trả lời ba câu. Điều kiện dừng của nó là exit code hay là một câu chữ do model sinh ra? Nếu là câu chữ, sửa trước tiên. Mỗi tool call có đi qua đúng một chokepoint, hay code có nhánh gọi thẳng subprocess ở đâu đó? Đếm số token schema bạn gửi lặp mỗi turn, rồi so với hoá đơn tháng trước.
Ba câu đó xác định bạn cần thêm lớp nào — chứ không phải cắm thêm MCP server nào.
This article was originally published on NextFuture. Follow us for more fullstack & AI engineering content.
Top comments (0)