Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 7 — Ghép agent end-to-end: orchestration, guardrails và human-in-the-loop

Đã đọc 0/9 mục · còn khoảng 3 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Bài 7 — Ghép agent end-to-end

Giờ ta nối 4 khối (research → outreach → CRM → NBA) thành một agent chạy được, với guardrails và human-in-the-loop để an toàn trong thực tế.

Vòng lặp agent (agent loop)

Agent hoạt động theo vòng: nhận state → LLM chọn tool → chạy tool → cập nhật state → lặp cho đến khi "done".

state = {"lead": lead, "brief": None, "draft": None, "crm_id": None}
for step in range(MAX_STEPS):          # trần bước để chống loop vô hạn
    decision = llm.decide(state, tools)
    if decision.type == "final":
        break
    result = run_tool(decision.tool, decision.args)
    state = update(state, result)
    log_step(decision, result)         # ghi lại mọi bước để debug

MAX_STEPS (vd 12) là guardrail cơ bản: agent không được lặp vô tận đốt token.

Guardrails bắt buộc

  • Step limit: trần số bước mỗi lead.
  • Budget limit: trần token/chi phí mỗi lead; vượt thì dừng, cờ đỏ.
  • Action allowlist: chỉ tool trong danh sách mới chạy được.
  • Send gate: mọi email PHẢI qua hàng đợi duyệt (giai đoạn đầu).
  • Validation: kiểm email hợp lệ, không có {{placeholder}} sót, không trùng gửi.
  • Kill switch: một cờ tắt toàn bộ gửi khi có sự cố.

Human-in-the-loop: 3 mức

Mức 1 (mới bắt đầu): người duyệt 100% email trước khi gửi.
Mức 2 (đã tin cậy):  auto-gửi lead score thấp, người duyệt lead giá trị cao.
Mức 3 (trưởng thành): auto-gửi phần lớn, người xử lý ngoại lệ + reply.

Đừng nhảy thẳng lên Mức 3. Tăng dần theo số liệu tin cậy (tỉ lệ duyệt-không-sửa).

Ví dụ hàng đợi duyệt

{
  "review_id": "rv_882",
  "lead": "chị Lan - ABC Foods",
  "draft": {"subject": "...", "body": "..."},
  "research_summary": "tuyển 3 vị trí e-commerce",
  "actions_on_approve": ["send_email", "crm_log", "schedule_followup"],
  "buttons": ["Approve", "Edit & Approve", "Reject"]
}

Khi người bấm Approve, agent mới thực thi actions_on_approve. "Edit & Approve" cho phép sửa nhanh mà vẫn giữ luồng.

Khung tư duy: Fail-safe, không fail-open

Khi agent gặp bất định (thiếu dữ liệu, tool lỗi, không chắc), hành vi mặc định phải là DỪNG và hỏi người, không phải "cứ gửi đại". Trong sales, một email sai gửi ra ngoài không thu hồi được. Nghi ngờ = dừng.

Các bước ghép hệ thống

  • Chuẩn hóa state object đi xuyên các bước.
  • Viết agent loop có step limit + logging từng bước.
  • Cắm guardrails (budget, allowlist, validation, kill switch).
  • Chèn send gate → hàng đợi duyệt trước mọi lần gửi.
  • Xử lý lỗi tool: retry có backoff, quá số lần thì gắn cờ human.
  • Chạy thử 10 lead thật ở Mức 1, đọc kỹ từng draft.

Checklist go-live

  • [ ] Có MAX_STEPS và budget cap mỗi lead.
  • [ ] Send gate hoạt động: không email nào ra ngoài mà chưa duyệt.
  • [ ] Validation chặn placeholder sót và email trùng.
  • [ ] Kill switch tắt được toàn bộ gửi tức thì.
  • [ ] Mọi bước được log, tái hiện được (reproducible).
  • [ ] Lỗi tool → fail-safe (dừng + báo), không fail-open.

Sai lầm thường gặp

  • Không có step/budget limit: một lead lỗi làm agent lặp vô tận, cháy hóa đơn.
  • Bỏ send gate quá sớm: agent gửi email lỗi hàng loạt, hỏng reputation domain.
  • Không log từng bước: khi sai không biết agent đã quyết gì → không debug được.
  • Fail-open: gặp bất định vẫn gửi → rủi ro lớn. Luôn fail-safe.
  • Không có kill switch: sự cố xảy ra mà không tắt kịp.
  • Nhảy thẳng full-auto: chưa đủ dữ liệu tin cậy đã bỏ người ra khỏi vòng lặp.
Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi