Agent thoại cần kịch bản vận hành

Agent thoại cần kịch bản vận hành

Đừng chọn agent vì demo nói mượt. Với hệ thống production, thứ cần chốt trước là orchestration, guardrail, latency và tiêu chí dừng.

“Con bot nghe khách nói đặt bàn 7 giờ tối, rồi tự book nhầm 7 người.”

Nếu bạn từng ngồi trong một buổi demo voice agent, câu này nghe hơi buồn cười cho đến khi nó chạm vào production. Demo thì như trailer phim: nhạc lên, cảnh đẹp, nhân vật nói tròn vai. Nhưng hệ thống thật giống phòng dựng hậu kỳ hơn: từng phân cảnh phải nối đúng, âm thanh không được lệch, và có cảnh hỏng là phải cắt trước khi ra rạp.

Luận điểm của mình trong bài này rất gọn: agent chỉ đáng tin khi workflow vận hành của nó rõ hơn độ “thông minh” của model. Với developer hoặc tech lead đang build agent thoại, thứ nên hỏi không phải “dùng model nào mới nhất?”, mà là “agent được phép làm gì, khi nào phải dừng, đo lỗi ở đâu, và ai chịu trách nhiệm khi nó gọi sai tool?”.

Sơ đồ minh họa cho bài Agent thoại cần kịch bản vận hành

Sơ đồ tóm tắt ý chính của bài viết.

Mục tiêu: dựng một agent nhỏ nhưng có đường biên rõ

Lấy use case đặt bàn nhà hàng làm ví dụ. Đây là bài toán đủ đời thường nhưng không hề đơn giản: khách gọi vào, hỏi giờ mở cửa, đặt bàn, đổi lịch, đọc mã đặt chỗ, hoặc đòi gặp người thật. Một voice agent production phải đi qua nhiều lớp:

Patter SDK đáng chú ý ở chỗ nó gom các mảnh này vào một pipeline agent thoại có thể mô phỏng trước khi nối vào telephony thật. Nhưng mình không muốn bạn nhìn nó như “tool mới nên thử”. Hãy nhìn nó như một lời nhắc: voice agent không phải một prompt biết nói, mà là một hệ thống vận hành có kịch bản, quyền hạn và kiểm thử.

Checklist trước khi viết dòng code đầu tiên

Trước khi team bạn mở editor, hãy chốt 6 câu hỏi này. Nếu chưa trả lời được, đừng vội chạy demo cho sếp, vì rất dễ có một cảnh quay đẹp nhưng không dùng được trong phim chính.

  1. Agent được phép hoàn tất việc gì?

Ví dụ: được đặt bàn mới, nhưng không được hủy đặt bàn nếu thiếu mã xác nhận.

  1. Tool nào là nguồn sự thật?

Nếu model nói còn bàn nhưng backend nói hết bàn, backend thắng.

  1. Khi nào phải chuyển người thật?

Ví dụ: khách phàn nàn, yêu cầu hoàn tiền, nói thông tin nhạy cảm, hoặc agent không hiểu sau 2 lượt.

  1. Output nào bị cấm?

Không đọc customer ID nội bộ, không hứa ưu đãi ngoài chính sách, không trả lời câu hỏi lạc đề.

  1. Độ trễ tối đa chấp nhận được là bao nhiêu?

Không cần bịa một con số chuẩn ngành. Hãy tự đo với người dùng thật của bạn. Voice khác chat ở chỗ im lặng vài nhịp đã khiến khách tưởng cuộc gọi rớt.

  1. Test nào phải qua trước khi deploy?

Ít nhất phải có smoke test cho luồng đặt bàn, tra cứu booking, hỏi giờ mở cửa, và chuyển người thật.

Nói thẳng ra thì: nếu team chỉ có prompt mà chưa có checklist này, bạn chưa build agent; bạn mới build một diễn viên ứng biến.

Làm trong một buổi: bản thử có guardrail và eval

Đây là playbook mình sẽ dùng nếu phải dựng bản thử trong một buổi chiều cho team 4-6 người. Không cần nối tổng đài thật ngay. Mục tiêu là kiểm chứng workflow, không phải khoe giọng đọc.

Bước 1: khóa phạm vi bằng state machine nhỏ

Đừng để agent “tự suy nghĩ mọi thứ”. Hãy định nghĩa các trạng thái hội thoại rõ ràng:

START
  -> ASK_PARTY_SIZE
  -> ASK_DATE_TIME
  -> CHECK_AVAILABILITY
  -> COLLECT_NAME
  -> CREATE_RESERVATION
  -> CONFIRM
  -> END

ANY_STATE
  -> HUMAN_TRANSFER
  -> FALLBACK

State machine ở đây chỉ là bản đồ trạng thái: agent đang ở đâu, được đi tiếp sang đâu. Với voice agent, bản đồ này giúp bạn tránh cảnh khách hỏi giờ mở cửa mà agent lại đòi tên để đặt bàn.

Bước 2: viết tool như hợp đồng, không như helper tùy hứng

Ví dụ cụ thể:

def check_availability(date: str, time: str, party_size: int) -> dict:
    return {
        "available": True,
        "slot": "19:00",
        "alternatives": ["18:30", "20:00"]
    }

def create_reservation(name: str, phone: str, slot: str, party_size: int) -> dict:
    return {
        "confirmation_code": "R1234",
        "status": "confirmed"
    }

Mỗi tool nên có input/output rõ. Nếu tool trả về mơ hồ, model sẽ tự lấp khoảng trống. Và khi model tự lấp khoảng trống trong cuộc gọi thật, bạn đang giao phòng vé cho người chưa đọc lịch chiếu.

Bước 3: thêm guardrail ở output, không chỉ ở prompt

Prompt có thể dặn “đừng nói thông tin nhạy cảm”, nhưng production cần lớp kiểm tra riêng. Ví dụ:

def output_guardrail(text: str) -> str:
    text = redact_internal_ids(text)
    text = remove_policy_violations(text)
    text = keep_phone_response_short(text, max_sentences=2)
    return text

Guardrail nên làm ít nhất 4 việc:

Điểm dễ sai: nhiều team đặt hết niềm tin vào system prompt. Prompt là chỉ đạo diễn xuất; guardrail là người duyệt cảnh cuối trước khi phát sóng.

Bước 4: mô phỏng hội thoại bằng script cố định

Hãy tạo một bộ cuộc gọi giả lập:

- name: book_table_happy_path
  turns:
    - user: "Tôi muốn đặt bàn cho 4 người tối nay lúc 7 giờ"
    - expect_tool: check_availability
    - expect_tool: create_reservation
    - expect_contains: "mã xác nhận"

- name: ask_hours_only
  turns:
    - user: "Nhà hàng mở cửa đến mấy giờ?"
    - expect_no_tool: create_reservation

- name: angry_customer_transfer
  turns:
    - user: "Tôi đã đặt rồi mà tới nơi không có bàn, cho gặp quản lý"
    - expect_tool: transfer_to_human

Đây là regression eval ở mức thực dụng: mỗi lần đổi prompt, model, tool schema hoặc guardrail, bạn chạy lại bộ script. Không cần hoàn hảo từ ngày đầu. Quan trọng là có đường baseline để biết mình vừa sửa hay vừa phá.

Bước 5: đo latency theo từng phân cảnh

Đừng chỉ đo tổng thời gian trả lời. Hãy tách:

Nếu tổng latency cao, bạn cần biết thủ phạm nằm ở đâu. Có thể model không chậm; API đặt bàn mới là đoạn nghẽn. Có thể TTS ổn; bước gọi tool bị retry âm thầm. Không có breakdown, mọi cuộc họp tối ưu sẽ biến thành đoán mò.

Pitfall: agent càng “tự chủ” càng khó vận hành

Hiểu nôm na: autonomy là quyền tự quyết của agent. Nghe hấp dẫn, nhưng trong production, quyền tự quyết phải đi kèm dấu vết kiểm toán.

Nguồn về multi-agent với LangGraph nhắc một điểm đáng giữ: khi workflow lớn, tách thành node, edge và shared state giúp hệ thống dễ hiểu hơn so với một prompt ôm hết. Nhưng đừng hiểu nhầm rằng nhiều agent hơn là tốt hơn. Với use case đặt bàn, bạn có thể chỉ cần một agent có state machine rõ. Multi-agent chỉ đáng dùng khi trách nhiệm thật sự khác nhau: một agent phân loại ý định, một agent xử lý booking, một agent kiểm tra chính sách, chẳng hạn.

Tương tự, các workflow agentic QA trong CI/CD cho thấy một nguyên tắc production rất quen: test phải chạy theo suite, có batch, có gate deploy. Nếu áp vào voice agent, câu hỏi là: bản build mới có được phép lên production nếu fail luồng chuyển người thật không? Với mình, câu trả lời là không.

Tiêu chí scale hoặc dừng

Sau bản thử một buổi, đừng hỏi “agent đã thông minh chưa?”. Hỏi 5 câu này:

| Tín hiệu | Nên scale khi | Nên dừng hoặc khoanh lại khi |
|---|---|---|
| Luồng chính | Happy path ổn định qua nhiều lần chạy script | Mỗi lần đổi prompt lại hỏng luồng cũ |
| Tool calling | Gọi đúng tool, đúng thứ tự, input hợp lệ | Hay gọi tool khi không cần hoặc thiếu tham số |
| Guardrail | Chặn được output cấm mà không làm bot cứng | Chặn quá tay hoặc lọt thông tin nội bộ |
| Latency | Biết rõ chặng nào chậm và có cách tối ưu | Chỉ biết “bot chậm” nhưng không trace được |
| Human handoff | Có trigger rõ, log rõ, người thật tiếp quản được | Bot cố xử lý khi khách đã cần con người |

Độc giả nên nghĩ khác điều gì sau bài này? Đừng xem agent framework là nơi bắt đầu. Hãy xem nó là phương tiện để thực thi một hợp đồng vận hành đã viết rõ. Patter SDK, LangGraph, hay bất kỳ stack nào cũng chỉ hữu ích khi bạn biết mình đang kiểm soát workflow nào.

Nếu là mình, mình sẽ chốt thế này

Mình sẽ bắt đầu bằng một agent thoại một nhiệm vụ: đặt bàn. Không upsell, không tư vấn thực đơn, không xử lý khiếu nại phức tạp. Sau đó thêm:

Khi các thứ này chạy ổn, mới bàn tới model mạnh hơn, multi-agent, MCP server, hay tích hợp sâu hơn với hệ thống backend. Còn nếu bản thử nhỏ đã không đo được lỗi, scale lên chỉ làm lỗi có thêm micro và ánh đèn.

Chốt một câu: agent production không cần diễn sâu; nó cần thuộc kịch bản, biết điểm dừng, và không phá cảnh quay của cả team.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo