Databricks hướng dẫn xây dựng AI Agent bền bỉ với Temporal và Lakehouse

Một tác nhân thẩm định khoản vay cá nhân thực hiện thu thập bằng chứng, áp dụng chính sách và có thể phải chờ đợi người đánh giá trong nhiều ngày. Trong khoảng thời gian đó, các worker có thể khởi động lại và các lệnh gọi công cụ (tool calls) có thể thất bại. Ứng dụng phải bảo toàn được công việc đã hoàn thành, tiếp tục thực thi và giữ cho bằng chứng luôn sẵn sàng cho người đánh giá.

Triển khai tham chiếu này sử dụng Temporal cho việc thực thi bền vững (durable execution) và Lakebase Postgres cho trạng thái vận hành có thể truy vấn. Một bảng được đồng bộ hóa giúp chính sách thẩm định từ Unity Catalog có sẵn trong Lakebase. Các Temporal Activity ghi lại bằng chứng, quyết định và số liệu vào Lakebase; sau khi được kích hoạt, Lakebase Change Data Feed có thể xuất bản các thay đổi đó sang các bảng lịch sử Delta được quản lý bởi Unity Catalog. Sự kết hợp này đặc biệt hữu ích khi Databricks đã quản lý các đầu vào và phân tích hạ nguồn của tác nhân.

Thách thức với các tác nhân đám mây chạy dài hạn

Một tác nhân đám mây có thể tồn tại lâu hơn cả yêu cầu, worker, container hoặc quá trình triển khai đã khởi tạo nó. Người dùng có thể bắt đầu một phiên, quay lại vào ngày hôm sau và tiếp tục trên một worker khác. Việc triển khai và lỗi tiến trình là chuyện thường ngày, vì vậy tiến trình của tác nhân phải tồn tại độc lập với tiến trình đang thực thi nó. Việc khôi phục đòi hỏi cả kết quả của các thao tác đã hoàn thành và trạng thái luồng điều khiển (control-flow state) cần thiết để xác định điều gì sẽ xảy ra tiếp theo.

Đối với tác nhân thẩm định này, điều đó tạo ra sáu yêu cầu:

Bản ghi cuộc hội thoại chỉ bao gồm một phần của trạng thái này. Việc khôi phục cũng đòi hỏi lịch sử luồng điều khiển: những thao tác nào đã được lên lịch, kết quả nào đã được ghi lại, tác nhân đang chờ đợi điều gì và những lệnh nào nó đã chấp nhận.

Temporal đơn giản hóa việc quản lý các hệ thống phân tán. Khi xây dựng với Temporal, một Workflow là luồng điều khiển bền vững cho một lần chạy tác nhân. Một Activity là một lệnh gọi đến mô hình, công cụ hoặc cơ sở dữ liệu mà kết quả của nó được ghi lại trong Event History của Workflow; các Activity có thể được thử lại. Một Signal là một lệnh bất đồng bộ được gửi đến một Workflow đang chạy, chẳng hạn như quyết định của người thẩm định. Triển khai tham chiếu Temporal Lakebase AgentWorkflow là một tác nhân thẩm định khoản vay cá nhân có thể chạy được. Nó gọi một vài công cụ, đọc chính sách được quản trị, đưa ra đề xuất và chờ đợi người thẩm định.

Lakebase Postgres cũng giúp các nhà phát triển quản lý những vấn đề này, nhưng Temporal và Lakebase lưu trữ các trạng thái khác nhau cho những người tiêu dùng khác nhau. Event History của Temporal thúc đẩy quá trình phát lại (replay). Lakebase lưu trữ chế độ xem hướng ứng dụng: trạng thái chạy hiện tại, tin nhắn, bằng chứng, trạng thái đánh giá và số liệu. Unity Catalog vẫn là nguồn chính sách; một bảng được đồng bộ hóa giúp chính sách đó có thể truy vấn trong Postgres, và Change Data Feed cung cấp đường dẫn phản hồi cho lịch sử vận hành. Các hệ thống không chia sẻ một giao dịch (transaction). Các bản ghi Lakebase chạy dưới dạng các Temporal Activity theo cơ chế thực thi ít nhất một lần (at-least-once). Các định danh xác định, ràng buộc, cập nhật có bảo vệ và các lệnh upsert của Postgres đảm bảo rằng các lần thử Activity lặp lại đều nhắm vào cùng một bản ghi logic.

Kiến trúc này bổ sung hai hệ thống được quản lý và một hợp đồng dự báo giữa chúng. Cùng nhau, chúng cải thiện khả năng phục hồi và khả năng mở rộng của tác nhân trong khi vẫn giữ chi phí vận hành ở mức thấp. Sự kết hợp giữa Temporal và Lakebase hữu ích nhất khi một phiên tác nhân cần tồn tại sau khi thay thế worker, chấp nhận đầu vào sau thời gian chờ đợi dài, hiển thị trạng thái quan hệ cho ứng dụng và áp dụng dữ liệu được quản trị trong khi nó vẫn đang mở.

Trường hợp sử dụng thẩm định

Tôi chọn thẩm định khoản vay vì cùng một lần chạy phải thu thập bằng chứng, áp dụng chính sách, đưa ra đề xuất và chờ đợi một người. Một worker có thể thất bại giữa bất kỳ bước nào trong số đó. Chính sách có thể thay đổi mà không cần triển khai ứng dụng, và giao diện người dùng (UI) cần bằng chứng hiện tại trước khi Workflow đóng lại.

Các ứng viên giả lập thay thế cho các cơ quan tín dụng và nhà cung cấp thu nhập thực tế, và trình tự công cụ là xác định để đơn giản hóa. Mỗi yêu cầu chứa ID người dùng, ID ứng viên, số tiền, mục đích, lựa chọn mô hình và giới hạn lượt. FastAPI gán run_id, khởi động LoanUnderwritingWorkflow và sử dụng cùng ID đó trên API, quá trình thực thi Temporal và các hàng trong Lakebase.

Ở lượt đầu tiên, credit_check trả về điểm số, các dòng tín dụng, các khoản nợ quá hạn và nợ hiện tại. income_verification trả về bằng chứng thu nhập và việc làm. debt_to_income_calc tính toán tỷ lệ nợ trên thu nhập. policy_lookup tải chính sách cho mục đích vay và đánh giá bằng chứng dựa trên các ngưỡng phê duyệt, chuyển tiếp và từ chối cứng.

Ứng viên ranh giới trong mẫu có điểm tín dụng 665, thu nhập hàng năm đã xác minh là 76.000 đô la, nợ hàng tháng 2.400 đô la và một cờ nợ quá hạn không trọng yếu. Kết quả chính sách ghi lại mọi quy tắc, ngưỡng, giá trị thực tế, kết quả đạt/không đạt, nguồn, đề xuất và lý do. Mô hình có thể đề xuất nhưng không thể quyết định. Người thẩm định phê duyệt, từ chối hoặc yêu cầu thêm thông tin. Một yêu cầu thêm thông tin trở thành một tin nhắn người dùng khác và một lượt tác nhân khác. Trường hợp này kiểm tra lỗi worker sau khi các lệnh gọi công cụ hoàn tất, một bản ghi Lakebase đã commit nhưng việc hoàn thành Activity bị mất, một đánh giá bị để mở trong nhiều ngày, một quyết định trình duyệt cũ và thay đổi chính sách trong quá trình thực thi.

Kiến trúc

Để triển khai tác nhân thẩm định, React và FastAPI xử lý công việc HTTP và UI: bắt đầu các lần chạy, hiển thị bằng chứng, liệt kê các trường hợp và gửi quyết định đánh giá. Temporal Cloud lưu trữ Event History và điều phối các Task. Các worker phát lại mã Workflow và thực thi các Activity của mô hình, công cụ và Lakebase; I/O mạng và cơ sở dữ liệu nằm ngoài mã Workflow xác định.

Một lần chạy bắt đầu khi FastAPI khởi động một Workflow. Worker lên lịch các Activity, Temporal ghi lại kết quả của chúng và tác nhân cuối cùng đạt đến trạng thái AWAITING_REVIEW. Phản hồi của người thẩm định quay lại thông qua một Signal. Phê duyệt hoặc từ chối sẽ đóng lần chạy; yêu cầu thêm thông tin sẽ tiếp tục vòng lặp tác nhân.

Lakebase giữ hai lược đồ vận hành. agent_ops chứa trạng thái chạy, tin nhắn, lệnh gọi công cụ, bản ghi đánh giá, sự kiện và số liệu mà FastAPI có thể truy vấn bằng SQL. agent_policy chứa chính sách đồng bộ chỉ đọc được sử dụng bởi policy_lookup. Mỗi Activity ghi các bản ghi được khóa bởi cùng các định danh xác định được sử dụng bởi Workflow, vì vậy dự báo có thể bắt kịp sau khi thử lại mà không cần biến Lakebase thành một phần của cơ chế phát lại của Temporal.

Unity Catalog là nguồn cho các ngưỡng thẩm định. Một bảng đồng bộ hóa liên tục giúp chúng có sẵn cho tác nhân đang chạy. Các ngưỡng được áp dụng, bằng chứng và quyết định của con người sau đó được ghi vào agent_ops. Change Data Feed có thể xuất bản các thay đổi đó sang các bảng lịch sử được quản lý bởi Unity Catalog để kiểm toán và phân tích.

Khôi phục công việc đã hoàn thành sau lỗi Worker

Temporal giữ Event History theo thứ tự cần thiết để xây dựng lại trạng thái Workflow trên một Worker khác. Lịch sử đó bao gồm việc lên lịch Activity và kết quả, bộ hẹn giờ và Signal. Quá trình phát lại chạy mã Workflow dựa trên các Sự kiện đã ghi đó và tái tạo các biến như lượt hiện tại, các quyết định đánh giá đã chấp nhận, mức sử dụng token và bằng chứng đã thu thập.

Kết quả Activity đã ghi được trả về trong quá trình phát lại thay vì chạy lại Activity đó. Một kiểm tra tín dụng đã hoàn thành vẫn được coi là hoàn thành, và phản hồi mô hình đã ghi vẫn là phản hồi cho lần thực thi đó. Nếu một Activity đang chạy khi Worker thất bại và Temporal chưa bao giờ ghi lại việc hoàn thành của nó, Temporal có thể lên lịch một lần thử khác. Đối với một tác nhân, điều này bảo toàn các phản hồi mô hình đã được ghi trong Event History. Một lệnh gọi mô hình mà việc hoàn thành chưa được ghi lại vẫn có thể chạy lại, ngay cả khi nhà cung cấp đã xử lý xong nó.

Các Chính sách thử lại (Retry Policies) được gán ở mức độ chi tiết của từng thao tác riêng lẻ và có thể được tái sử dụng trong mã. Trong ví dụ, các Activity gọi mô hình cho phép tối đa bốn lần thử trong thời hạn schedule-to-close là ba phút. Các Activity gọi công cụ cho phép tối đa ba lần thử và có thời hạn start-to-close là 60 giây. Các Activity Lakebase cho phép tối đa năm lần thử với thời hạn start-to-close là 15 giây.

Làm cho các hiệu ứng bên ngoài an toàn để lặp lại

Một rủi ro là việc ghi kết quả công cụ vào Lakebase có thể commit trước khi Worker báo cáo hoàn thành Activity. Nếu kết nối bị ngắt trong khoảng thời gian đó, Temporal không có kết quả được ghi lại và lên lịch một lần thử khác. Cả hai lần thử đều đại diện cho cùng một bản ghi logic.

Mỗi bản ghi Lakebase có một định danh ổn định. run_id neo giữ lược đồ vận hành. message_id xác định một tin nhắn, tool_call_id xác định một lệnh gọi công cụ, event_id xác định một cột mốc, review_id xác định một vòng đánh giá và decision_id xác định một lệnh của người đánh giá. Các khóa chính và ràng buộc duy nhất của Postgres thực thi các định danh đó.

Bản ghi bắt đầu công cụ hiển thị cả định danh ổn định và bộ bảo vệ trạng thái cuối:

Một lần thử lại nhắm vào cùng một tool_call_id. Vị ngữ cuối cùng chỉ cho phép một hàng không kết thúc hiện có được ghi lại thành trạng thái "đã bắt đầu". Nếu hàng đó đã thành công hoặc thất bại, PostgreSQL sẽ ảnh hưởng đến không hàng nào. Nó không gây ra lỗi.

Người gọi phải kiểm tra kết quả không hàng nào. LakebaseWriteResult trả về số hàng bị ảnh hưởng, nhưng trình bao bọc Activity hiện tại không biến số 0 thành một thất bại. Mã sản xuất nên phân loại số 0 là một thao tác không làm gì (no-op) dự kiến chỉ sau khi xác nhận trạng thái kết thúc đã lưu; nếu không, nó nên đưa ra lỗi hoặc ghi lại một xung đột. Quy tắc tương tự áp dụng cho các chuyển đổi chạy và đánh giá được bảo vệ.

Các lệnh upsert tương tự bao phủ các tin nhắn, kết quả công cụ và Sự kiện. Các ID xác định làm cho các lần thử lại hội tụ về cùng một hàng logic, trong khi mỗi bản ghi được bảo vệ xác định các chuyển đổi trạng thái nào là hợp pháp. API có thể hiển thị ngắn gọn trạng thái cũ hơn trong khi một bản ghi thử lại. Sau khi Activity thành công, hàng được chấp nhận có thể truy vấn được.

Mọi công cụ có tác dụng phụ đều cần một hợp đồng tương đương. Một API thanh toán có thể chấp nhận một khóa idempotency, một dịch vụ email chấp nhận một ID tin nhắn do người gọi cung cấp và cơ sở dữ liệu chấp nhận một ràng buộc duy nhất. Nếu hệ thống bên ngoài không cung cấp cơ chế khử trùng lặp, Activity cần bản ghi riêng hoặc quy trình đối soát. Temporal xác định khi nào cần thử lại. Activity xác định cách hệ thống bên ngoài xử lý lần thử lại đó.

Hiển thị trạng thái hiện tại và số liệu vận hành

Event History cung cấp ngữ nghĩa thực thi và chi tiết gỡ lỗi. Ứng dụng cần các truy vấn quan hệ được lập chỉ mục trên lần chạy hiện tại: liệt kê các trường hợp theo người dùng và trạng thái, tải một bản ghi với bằng chứng của nó, tìm các đánh giá đang chờ người thực hiện và tổng hợp các phép đo trên các lần thực thi.

Lakebase lưu trữ chế độ xem ứng dụng đó trong một lược đồ Postgres chuẩn hóa. agent_runs giữ trạng thái hiện tại, ID Workflow, yêu cầu, tổng token, dấu thời gian và siêu dữ liệu đề xuất. agent_messages bảo toàn bản ghi. agent_tool_calls ghi lại các đối số, trạng thái, kết quả có cấu trúc, lỗi và thời gian. agent_review_decisions kết nối đề xuất với một review_id ổn định, lệnh của người đánh giá, lý do và thời gian quyết định.

Lược đồ cũng ghi lại các Sự kiện và số liệu được đặt tên ở cấp độ Workflow, lượt và lần thử Activity. FastAPI hiển thị các điểm cuối run-detail, workflow-metrics và retry-metrics được hỗ trợ bởi các bảng này. UI có thể hiển thị một lần chạy đang thu thập bằng chứng, một lần khác đang chờ đánh giá và lần thứ ba đang thử lại một công cụ bị lỗi. Người vận hành có thể truy vấn cùng các hàng đó bằng SQL.

Bằng chứng có sẵn trước khi Workflow hoàn thành. Sau khi policy_lookup kết thúc, kết quả có cấu trúc của nó được lưu trữ cùng với lệnh gọi công cụ. Khi lần chạy đạt đến AWAITING_REVIEW, người thẩm định có thể thấy điểm tín dụng, DTI, các ngưỡng, kết quả quy tắc, lý do và nguồn chính sách đã tạo ra đề xuất.

Giữ cho đánh giá của con người bền vững và từ chối các lệnh cũ

Khi mô hình trả về một đề xuất, Workflow suy ra review_id từ run_id và lượt hiện tại. Nó ghi đánh giá đang chờ xử lý vào Lakebase, ghi lại một sự kiện agent.review_pending, đặt dự báo thành AWAITING_REVIEW và gọi workflow.wait_condition. Temporal giữ lại Workflow đang mở mà không cần giữ cho tiến trình Worker bị chiếm dụng.