Giám sát AI agent chạy trên serverless function

Hãy coi mỗi lần gọi serverless là một bước của lần chạy agent. Ở mỗi bước, theo dõi ba thứ: lỗi kèm cùng một trace id cho cả lần chạy, lần chạy có bắt đầu và kết thúc đúng hạn không, và những lỗi code tự bắt hoặc giao cho việc chạy nền. Loại lỗi cuối cùng không bao giờ tới được handler, nên dễ bị bỏ sót nhất.

Một agent biết lập kế hoạch, gọi tool, chờ rồi thử lại hiếm khi gói gọn trong một lần gọi function. Nó thành một chuỗi: handler nhận request, consumer đọc queue, cron Worker đánh thức những lần chạy bị kẹt, và một tool nằm sau một lời gọi HTTP khác. Mắt xích nào cũng có thể hỏng riêng, và mỗi mắt xích lại có cách hỏng âm thầm của riêng nó.

Vì sao agent trên serverless hỏng theo kiểu khác#

Một server chạy lâu dài giữ bộ nhớ và log ở cùng một chỗ. Agent trên serverless thì không. Lần chạy của nó trải ra qua nhiều lần gọi, mỗi lần khởi động lạnh, kết thúc khi hết hạn và không chia sẻ gì ngoài những thứ bạn tự truyền đi.

Từ đó sinh ra ba vấn đề.

1. Lần chạy dài hơn bất kỳ bước nào. Nếu một bước bị dừng vì hết giới hạn, không gì bên trong bước đó báo được việc này.
2. Các bước không biết chúng thuộc cùng một lần chạy. Không có id chung, lỗi ở tool và lỗi ở bước agent trông như hai issue chẳng liên quan.
3. Nhiều việc diễn ra sau khi đã trả phản hồi. Việc chạy nền chính là nơi lỗi bị nuốt mất.

Biết hạn chót của từng bước#

Trước khi chọn theo dõi gì, hãy ghi ra mỗi bước được chạy tối đa bao lâu. Dưới đây là các giới hạn mình đọc trong tài liệu ngày 25/10/2026. Chúng thay đổi theo gói và cấu hình, nên bạn nhớ kiểm lại của mình.

Có hai điều rút ra từ bảng. Bước nào có thể chạy lâu hơn giới hạn thì cần một monitor có thời gian chạy tối đa, vì nền tảng sẽ dừng nó trước khi nó kịp báo gì. Và giới hạn CPU tách biệt với giới hạn thời gian thực: một bước có thể bị dừng vì tính toán quá lâu dù vẫn còn xa mới hết thời lượng.

Cho cả lần chạy một trace id#

Chuẩn W3C Trace Context định nghĩa header traceparent mang trace id từ dịch vụ này sang dịch vụ kế tiếp. Nếu mọi bước đều chuyển tiếp nó, mọi lỗi của lần chạy sẽ mang cùng một id và bạn đọc được cả lần chạy như một câu chuyện liền mạch.

Mình thử xem việc này có tự xảy ra không. Một bước agent trong Worker thứ nhất gọi tool ở Worker thứ hai qua HTTP; tool ném lỗi, và bước agent báo lại lời gọi thất bại. Cả hai dùng cùng một SDK theo dõi lỗi. Mình chạy ba lần khi tắt trace propagation và ba lần khi bật.

Request đến vốn đã mang traceparent, và Worker đầu tiên giữ nó mà không cần cấu hình gì. Lần chạy bị đứt ở chặng thứ hai: lời gọi đi ra không mang header trace nào cho tới khi mình khai URL của tool làm propagation target. Vậy nên hãy khai mọi dịch vụ agent gọi tới, và chỉ dịch vụ của bạn thôi, vì thêm header vào API của bên thứ ba có thể làm request đó trượt kiểm tra CORS.

Bắt những lỗi không bao giờ tới handler#

Công cụ theo dõi lỗi báo những gì handler ném ra. Agent lại làm rất nhiều việc không bao giờ ném ngược về handler. Ví dụ: một lời gọi tool bọc try/catch rồi trả về câu báo lỗi lịch sự, một lần ghi log giao cho waitUntil, một promise chạy rồi bỏ đó.

Mình đã đo chuyện này trên một Cloudflare Worker thật. Một promise bị reject trong waitUntil vẫn trả 200 cho client, Cloudflare đánh dấu lần gọi là ok và chỉ liệt kê lỗi kèm theo; SDK của chính mình cũng không báo lỗi đó, cho tới khi mình sửa ở bản 0.4.1. Một promise thả nổi thì không để lại dấu vết gì.

Với agent, quy tắc rất đơn giản: mọi catch biến lỗi thành thông điệp cho model cũng phải báo lỗi đó. Gắn tag tên bước và tên tool, không kèm prompt hay tham số của tool.

Biết lúc nào một lần chạy đã dừng#

Lỗi cho bạn biết có gì đó hỏng. Lỗi không cho biết một bước chưa từng chạy, hay chạy cho tới khi bị nền tảng giết. Muốn biết điều đó, bạn cần một monitor chờ cả tín hiệu bắt đầu lẫn kết thúc.

Chi tiết phụ thuộc vào việc ping được gửi từ đâu, mình đã thử trong bài cron job chạy mãi không xong. Ping gửi từ EXIT trap bên trong job bash báo thành công cho job đã bị SIGTERM dừng, cả 3/3 lần. Ping từ dòng cron thì báo đúng mã thoát thật. Agent cũng vậy. Hãy báo lúc bắt đầu thật sớm, báo lúc kết thúc từ phần code sống lâu hơn bước đó, và để thời gian chạy tối đa bắt mọi trường hợp còn lại.

Lần chạy agent không theo lịch cố định, ví dụ mỗi request của người dùng một lần, nên dùng monitor chạy khi có sự kiện, mỗi lần chạy agent là một run. Một lịch cố định cho loại việc này lúc nào trông cũng như đang trễ. Hướng dẫn việc chạy nền nói về queue consumer, webhook và worker chạy lâu theo cùng cách đó. Khi đã có monitor, burn rate trong SLO giúp bạn chỉ bị đánh thức khi tỉ lệ lỗi thật sự đáng lo.

Một cách thiết lập đứng vững#

1. Bọc mọi điểm vào: HTTP handler, queue consumer, cron handler.
2. Bật trace propagation cho URL của các bước và tool của chính bạn.
3. Báo mọi lỗi tự bắt có làm thay đổi bước tiếp theo của agent.
4. Gắn .catch() có báo lỗi cho mọi promise chạy nền, và cấm promise thả nổi bằng lint.
5. Mỗi loại lần chạy một monitor, với thời gian chạy tối đa dài hơn một chút so với lần chạy khoẻ chậm nhất.
6. Không đưa prompt và tham số tool vào tag. Dùng id và mã ngắn; chỉ gửi nội dung tới nơi bạn đã quyết định là được phép. Bài gửi lỗi production cho LLM an toàn nói rõ cần lọc gì trước.

Belvador giúp ở đâu#

SDK của Belvador tiếp nối traceparent đến từ request. Khi bạn khai URL của mình, SDK chuyển tiếp nó đi, nên lỗi và các run monitor của một lần chạy agent hiện cùng nhau trên issue, ở mục Same trace. SDK chỉ nối các lỗi với nhau; nó không tạo span hay đo thời gian. Muốn có những thứ đó, hãy gửi OpenTelemetry traces. Tài liệu trace propagation liệt kê các tuỳ chọn, còn ping URL monitor dùng được với mọi ngôn ngữ. Trang Cloudflare Workers có cách cài cho Worker, và theo dõi cron dành cho các bước chạy theo lịch.

Đọc tiếp#

• Cron job chạy mãi không xong: heartbeat thật ra nhìn thấy gì?
• Burn rate trong SLO, giải thích dễ hiểu