Thiên Thành
VIEN

Operator Notes

Làm rõ workflow trước khi thêm nhiều AI agent

Khi đầu vào, trạng thái và quyền hành động còn chưa rõ, nhiều agent chỉ làm một quyết định sai đi qua hệ thống nhanh hơn.

Engineering · 13 tháng 10, 2026

Một GitLab issue đã đi sai dự án

Khi xây Intake, Thành từng nghĩ đến việc chia luồng tiếp nhận yêu cầu cho nhiều AI agent. Một agent đọc nội dung, một agent tìm phần còn thiếu, một agent viết yêu cầu và một agent điều phối quyết định bước tiếp theo.

Ý tưởng này trông hợp lý khi nhìn từng khả năng riêng lẻ. Nhưng một lần kiểm thử đã chỉ ra vấn đề nằm ở workflow, không phải ở số lượng agent.

Project owner mô tả một vấn đề cần xử lý. AI phân tích nội dung theo sai ngữ cảnh và tạo một GitLab issue liên quan đến dự án khác. Issue vẫn có cấu trúc và đọc khá hợp lý, nhưng không phản ánh đúng vấn đề người gửi muốn giải quyết. Project owner phải mô tả lại lần nữa để làm rõ.

Một đầu ra có vẻ hoàn chỉnh vẫn có thể sai từ ngữ cảnh ban đầu. Nếu hệ thống tiếp tục đưa đầu ra đó qua nhiều agent, mỗi bước sau chỉ làm cho quyết định sai trở nên khó phát hiện hơn.

Vấn đề không phải thiếu thêm agent

Intake nhận thông tin từ nhiều nguồn khác nhau. Nội dung ban đầu có thể thiếu bối cảnh dự án, phạm vi, người chịu trách nhiệm hoặc điều kiện để xem công việc là hoàn thành.

Khi các dữ kiện này chưa rõ, một agent điều phối không có đủ cơ sở để quyết định nên hỏi lại, nên chuyển sang dự án nào hoặc đã được phép tạo công việc chính thức hay chưa. Thêm agent không tạo ra phần ngữ cảnh còn thiếu. Nó chỉ tạo thêm điểm chuyển giao và thêm nơi phải truy vết khi kết quả sai.

Thành quay lại một nguyên tắc đơn giản:

Trước khi chia workflow cho nhiều agent, mỗi bước phải có đầu vào, đầu ra, điều kiện hợp lệ, quyền hành động và đường xử lý lỗi đủ rõ để một người khác có thể kiểm tra.

Hợp đồng đầu ra trước khi điều phối

AI trong Intake không được tạo một đoạn mô tả tự do rồi tự quyết định bước kế tiếp. Đầu ra được chuẩn hóa theo một cấu trúc gồm:

  • Vấn đề cần giải quyết.
  • Kết quả mong đợi.
  • Phạm vi thực hiện.
  • Người chịu trách nhiệm.
  • Điều kiện hoàn thành.

Structured output được kiểm tra bằng schema trước khi đi tiếp. Thiếu trường bắt buộc hoặc sai cấu trúc không được xem là một yêu cầu hợp lệ.

Schema chỉ kiểm tra được hình dạng của dữ liệu. Nó không thể tự xác nhận AI đã hiểu đúng dự án hoặc đúng ý của project owner. Vì vậy, hệ thống vẫn phải giữ nội dung nguồn, phiên bản bản nháp, thay đổi của người dùng và lịch sử duyệt để người phụ trách đối chiếu.

Schema validation bảo vệ cấu trúc. Human review bảo vệ ngữ cảnh và trách nhiệm. Hai lớp này giải quyết hai loại lỗi khác nhau.

Luồng kiểm soát công khai

Sau khi bỏ phương án nhiều agent ở giai đoạn này, Thành thu gọn workflow về một luồng có thể quan sát:

Đầu vào từ nhiều nguồn
    -> AI trích xuất bản yêu cầu có cấu trúc
    -> Schema validation
    -> Người phụ trách đối chiếu với nội dung gốc
    -> Hỏi lại hoặc chỉnh sửa nếu còn thiếu
    -> Người phụ trách duyệt hành động
    -> Tạo GitLab issue

Có hai hành động được kiểm soát riêng:

  1. Gửi câu hỏi làm rõ cho người yêu cầu.
  2. Tạo GitLab issue từ bản yêu cầu đã được duyệt.

AI có thể đề xuất câu hỏi và chuẩn bị nội dung issue. AI không tự gửi câu hỏi và không tự tạo công việc chính thức nếu chưa qua bước duyệt tương ứng.

Đây là mô hình trách nhiệm công khai, không phải sơ đồ kiến trúc nội bộ của Intake.

Trạng thái phải có ý nghĩa vận hành

Thay vì dùng một trạng thái chung như “đã xử lý”, workflow phân biệt các bước có ý nghĩa khác nhau:

received
  -> extracting
  -> needs_clarification
  -> review_ready
  -> awaiting_approval
  -> creating_gitlab_issue
  -> completed

failure paths
  -> validation_failed
  -> integration_failed

review_ready chỉ có nghĩa bản nháp đã đủ cấu trúc để con người kiểm tra. Nó chưa có nghĩa nội dung đã đúng. awaiting_approval cho biết hành động vẫn chưa được phép thực thi. completed chỉ xuất hiện khi hành động tạo GitLab issue đã hoàn thành.

Việc tách trạng thái giúp người vận hành biết công việc đang chờ AI, chờ người duyệt hay đang lỗi ở tích hợp đích. Nó cũng ngăn giao diện hứa “hoàn tất” khi hệ thống mới chỉ tạo được một bản mô tả nghe có vẻ hợp lý.

Các cơ chế bảo vệ đã có

Luồng hiện tại sử dụng các cơ chế khác nhau cho từng loại rủi ro:

  • Structured output và schema validation để chặn đầu ra sai hình dạng hoặc thiếu trường bắt buộc.
  • Versioning để phân biệt bản AI đề xuất với bản đã được người dùng chỉnh sửa.
  • Audit log để biết ai đã thay đổi, duyệt hoặc kích hoạt một hành động.
  • Idempotency để cùng một yêu cầu không tạo nhiều GitLab issue khi thao tác được gửi lại.
  • Human approval trước khi gửi câu hỏi hoặc tạo công việc chính thức.

Không cơ chế nào trong số này tự chứng minh nội dung đúng. Chúng làm cho quyết định có thể kiểm tra, truy vết và phục hồi khi có lỗi.

Failure mode đã được kiểm thử

Team đã kiểm thử thực tế các tình huống sau:

Tình huống Rủi ro Phản ứng mong đợi
AI trả sai cấu trúc Thành phần sau đọc sai dữ liệu Schema validation từ chối đầu ra
Thiếu trường bắt buộc Yêu cầu chưa đủ điều kiện tạo việc Chuyển sang làm rõ hoặc chờ người phụ trách bổ sung
AI tạo câu hỏi không phù hợp Gửi một câu hỏi gây nhiễu cho người yêu cầu Người duyệt sửa hoặc từ chối trước khi gửi
Người dùng sửa bản AI đề xuất Bản cũ có thể bị dùng nhầm Tạo phiên bản mới và chỉ duyệt phiên bản hiện tại
Cùng một thao tác được gửi nhiều lần Tạo GitLab issue trùng Idempotency giữ một hành động tạo việc
Tích hợp GitLab bị lỗi Yêu cầu đã duyệt nhưng chưa tạo được việc Giữ trạng thái lỗi và dấu vết để thử lại hoặc phục hồi

Sự cố AI chọn sai dự án cho thấy một failure mode khác: đầu ra đúng schema nhưng sai ngữ cảnh. Trường hợp này không thể được giải quyết chỉ bằng validation kỹ thuật. Người duyệt cần nhìn thấy nội dung gốc, dự án đích, bản AI đã tạo và hành động sắp xảy ra trong cùng một màn hình.

Khi nào một agent mới có lý do để xuất hiện

Nhiều agent không phải là lựa chọn sai. Nhưng mỗi agent mới phải tương ứng với một trách nhiệm độc lập, không chỉ là một prompt khác.

Trước khi thêm một agent, Thành kiểm tra:

  1. Phần việc có đầu vào và đầu ra riêng đủ rõ không?
  2. Đầu ra có thể được kiểm tra bằng schema, quy tắc hoặc bằng chứng nào?
  3. Agent được đề xuất hay được phép thực hiện hành động nào?
  4. Khi agent không chắc hoặc thất bại, workflow chuyển cho ai?
  5. Có failure mode riêng đủ lớn để cần tách trách nhiệm không?
  6. Việc tách agent có giúp quan sát và phục hồi tốt hơn một luồng tập trung không?

Nếu chưa trả lời được những câu hỏi này, thêm agent thường chỉ làm tăng số điểm chuyển giao.

Điều bạn có thể áp dụng

Khi thiết kế một workflow có AI, bạn có thể bắt đầu bằng một hành động thật thay vì bắt đầu bằng số lượng agent:

  1. Xác định hành động nào sẽ tạo thay đổi trong hệ thống hoặc ảnh hưởng đến người khác.
  2. Viết rõ dữ liệu tối thiểu cần có trước hành động đó.
  3. Tách kiểm tra cấu trúc khỏi kiểm tra ngữ cảnh.
  4. Chỉ định người có quyền duyệt và thông tin họ cần nhìn thấy.
  5. Đặt trạng thái riêng cho chờ làm rõ, chờ duyệt và tích hợp thất bại.
  6. Kiểm thử thao tác gửi trùng, đầu ra sai và hệ thống đích không phản hồi.

Một agent mới chỉ nên được thêm khi workflow đã chỉ ra một trách nhiệm mới cần tách. Nếu workflow còn chưa rõ, việc cần làm trước là làm rõ đầu vào, quyền quyết định và bằng chứng kiểm tra được.

Phạm vi công bố

Bài viết mô tả ranh giới trách nhiệm và các failure mode đã được kiểm thử. Nó không công bố prompt nội bộ, schema chi tiết, thông tin xác thực, topology triển khai, dữ liệu khách hàng hoặc cấu hình GitLab riêng tư.