Infrastructure patterns for agentic applications

Render · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài khái niệm của nhà cung cấp nền tảng, kết thúc bằng giới thiệu Render Workflows (Beta); không kể sự cố hay số liệu production. Mọi nhận định là theo Render.

Bối cảnh

• Cách làm agent đầu tiên thường là bọc model trong một route handler và chờ response. Theo Render, đó là thứ hỏng đầu tiên ở production: agent chạy lâu (giờ, có khi ngày), có trạng thái (mục tiêu, kế hoạch, kết quả tool, retry, quyết định), và không tất định (model chọn bước tiếp lúc chạy; một lần chạy có thể ba bước hay ba mươi). Gắn agent vào một HTTP request là gắn độ tin cậy của ứng dụng vào thời gian chạy của một vòng lặp không tất định.

Thay đổi chính

• Mẫu 1: tách lần chạy khỏi request. Request chỉ tạo bản ghi run bền, đẩy việc vào queue, trả về run ID ngay; worker làm việc; DB ghi tiến độ; client xem trạng thái, subscribe hay nhận callback. Bẫy: queue biết có một job, không biết job thuộc tiến trình logic nào (hai mươi bước phụ thuộc, ba lần retry, hai nhánh, một lần chờ người duyệt là thứ phải tự viết).
• Mẫu 2: chạy bền vững. Queue thường là at-least-once nên job có thể chạy hai lần; agent gọi tool có tác dụng phụ (trừ tiền, cấp tài nguyên, gửi email) thì retry trở thành một phần của mô hình đúng đắn:
  • Idempotency cho một bước chạy hai lần: kiểm bản ghi đã xong, upsert "đang chạy", gọi tool, đánh dấu xong.
  • Compensation (saga) cho một lần chạy dừng giữa chừng: mỗi hành động có hành động bù (trừ tiền ↔ hoàn tiền, email ↔ email đính chính), chạy ngược thứ tự khi thất bại vĩnh viễn. Hành động bù cũng phải idempotent, cũng có thể lỗi, nên cần retry có trần, dead-letter và lối thoát bằng tay; không thì lần chạy thành "hoàn tác dở" thay vì "làm dở". Bù không phải mặc định: bốn trên năm đơn con thành công thì giữ bốn thường tốt hơn.
• Mẫu 3: workflow engine cho điều phối. Engine lưu lịch sử của run (bước nào bắt đầu, xong, lỗi, retry, chờ). Mã chia hai vai: coordinator ra quyết định và step làm việc thật. Khi phục hồi, engine chạy lại logic quyết định từ đầu và thay kết quả đã ghi cho bước đã xong, nên coordinator phải tất định: gọi model, đọc giờ, số ngẫu nhiên, gọi service ngoài đều phải nằm trong step. Durable execution cho biết run dừng ở đâu nhưng không thay được idempotency. Workflow là chỗ tự nhiên cho saga vì đã biết bước nào xong.
• Fan-out/fan-in: agent chính chia việc cho subagent rồi tổng hợp; khó là fan-in (nhánh lỗi thì sao, bao nhiêu lỗi chấp nhận được, có tổng hợp từ kết quả dở không, tránh chờ mãi). Promise.allSettled + ngưỡng thành công làm chính sách lỗi một phần thành tường minh. Fan-out sinh tranh chấp: ba subagent chạy được mà mười một thì hỏng dù tổng capacity của nhà cung cấp còn dư, vì đụng cùng rate limit, cùng pool kết nối, cùng lúc retry; cần trần concurrency, token bucket, backoff.
• Queue (đặt việc ở đâu) và workflow (bước tiếp theo là gì, khi đã có lịch sử này) là hai tầng khác nhau; ở quy mô lớn có ba mặt phẳng: API, điều phối, thực thi.
• Phần quảng bá: Render Workflows bọc hàm TypeScript/Python bằng task(), mỗi lần gọi là một task run trên instance riêng với retry và compute riêng, một lần chạy agent là một cây task run; Render tự nói nền tảng chưa lo idempotency, compensation, lưu artifact, truyền trace, cổng duyệt, kiểm soát chi phí, rate limit.

Vì sao

• Theo Render, các tính chất của agent (lâu, có trạng thái, không tất định) chính là các bài toán của hệ phân tán, nên lời giải là các mẫu đã có của hệ phân tán, không phải thứ mới.

Bài học cho SWE

• Retry chỉ là chiến lược phục hồi khi thao tác được retry an toàn.
• Phân biệt "bước chạy hai lần" (idempotency) với "lần chạy dừng giữa chừng" (bù); cả hai cần thiết khi có tác dụng phụ ra ngoài.
• Mọi thứ trả lời khác nhau ở lần chạy lại phải được ghi lại lần đầu và đọc lại từ lịch sử.
• Capacity tổng còn dư không có nghĩa là song song thêm được: giới hạn dùng chung (rate limit, pool) quyết định.

Liên quan

• Giao dịch phân tán và nhất quán xuyên service · Event-driven, message queue và Kafka
• Cùng công ty: Render 2026 · Render 2025
• Cùng bài toán: Inngest 2023 · Coinbase 2026 · Anthropic 2025 (fan-out cho subagent)