Trả lời ngắn: Workflow, copilot và agent không phải ba nhãn làm bài thuyết trình hấp dẫn. Chúng là ba mức cách system đi qua công việc và sử dụng quyền. Chọn theo mức input thay đổi, nhu cầu phán đoán của người, side effect, evidence và khả năng dừng; mode nhỏ nhất đủ dùng thường là nơi bắt đầu an toàn hơn.

Đọc xong, bạn sẽ hiểu:

  • Workflow, copilot và agent khác nhau ở đâu.
  • Năm câu hỏi giúp chọn mode phù hợp với use case.
  • Khi nào nên giữ bước cố định, thêm người duyệt hoặc giao điều phối có giới hạn.
  • Cách chấm một case giả bằng decision matrix trước khi build.

Lưu ý giáo dục: Ví dụ dùng content, support, research và invoice giả. Không đưa secrets, PII, customer data, API key, tiền thật hoặc production prompt vào bài. Agent có quyền gọi tool phải có owner, allowlist, max steps, approval và fallback phù hợp.

1. Ba mode trả lời ba nhu cầu khác nhau

Workflow là chuỗi bước được định trước và kiểm soát. Copilot là AI đề xuất, còn người vẫn quyết định hành động. Agent là system điều phối nhiều bước trong scope được giao, có thể chọn tool hoặc thứ tự bước nhưng không có nghĩa là tự do vô hạn.

Ví dụ content pipeline của AI79 có thể là workflow: Planner → Writer → Reviewer → Validator → release gate. Support assistant có thể là copilot: AI gợi ý route hoặc draft reply, nhân viên sửa và duyệt. Research assistant có thể là agent giới hạn: tìm nguồn, mở trang, ghi provenance, tóm tắt rồi chuyển NEEDS_REVIEW khi thiếu evidence.

Đừng nhảy từ “có nhiều bước” sang “cần agent”. Một dây chuyền nhiều công đoạn vẫn là workflow nếu đường đi biết trước. Ngược lại, một copilot có tool tìm kiếm và approval vẫn cần boundary rõ. Autonomy là mức system tự chọn bước hoặc hành động; nó cần được ghi như một rủi ro và quyền, không phải huy hiệu trưởng thành.

Hình 1 — Mức tự điều phối tăng dần, nhưng approval, evidence và stop gate phải đi cùng.

Ví dụ đời thường: workflow giống dây chuyền có công đoạn cố định; copilot giống trợ lý đưa vài lựa chọn để chủ quầy quyết; agent giống điều phối viên chọn đường giữa nhiều bước. Cả ba đều cần người chịu trách nhiệm và giới hạn công việc.

2. Năm câu hỏi trước khi chọn mode

a. Input thay đổi đến mức nào?

Variability là mức input hoặc đường đi thay đổi giữa các case. Nếu input có schema ổn định, rule rõ và output cố định, workflow thường đủ. Nếu có vài nhánh cần diễn giải nhưng người vẫn muốn kiểm, copilot hợp lý. Nếu đường đi phụ thuộc nguồn và mục tiêu thay đổi, agent có thể hữu ích nhưng phải giới hạn.

b. Sai thì có đảo ngược được không?

Side effect là thay đổi bên ngoài như gửi email, ghi, xoá hoặc gọi API. Một gợi ý route có thể sửa trước khi gửi; một giao dịch ghi sổ hoặc thay đổi quyền có thể khó đảo ngược hơn. Càng khó đảo ngược, càng cần workflow kiểm soát hoặc copilot approval; agent không nên tự quyết chỉ vì có tool.

c. Người cần phán đoán ở đâu?

Nếu người chỉ cần xem thông tin, workflow có thể xử lý. Nếu người cần so sánh, sửa draft hoặc duyệt ngoại lệ, copilot tạo giá trị. Nếu người phải lập kế hoạch từng case, agent có thể đề xuất chuỗi bước; vẫn phải ghi điểm bàn giao và điều kiện dừng.

d. Evidence và owner có đủ chưa?

Evidence là artifact hoặc quan sát kiểm lại được; owner là người chịu trách nhiệm cho quyết định hoặc kiểm soát. Nếu không biết agent đã gọi tool nào, dùng nguồn nào, ai nhận alert và cách rollback, chưa nên tăng autonomy. Microsoft mô tả AI observability cần telemetry và tín hiệu chất lượng để hiểu run; nhãn “agent” không thay được evidence. Microsoft AI observability

e. Chi phí thay đổi và vận hành là gì?

Agent thường có nhiều đường đi, tool call và failure mode hơn. Latency, chi phí, retry, context và log cũng khó đoán hơn. Hãy hỏi mode nào đáp ứng outcome với effort kiểm thử và vận hành chấp nhận được, không chỉ mode nào nghe hiện đại.

Decision matrix mẫu

Câu hỏi Workflow Copilot Agent
Đường đi Biết trước Vài nhánh Nhiều nhánh có giới hạn
Người quyết định Ngoài bước Ở approval Ở checkpoint/ngoại lệ
Side effect Tách và kiểm Sau duyệt Mặc định chặn/allowlist
Evidence Log bước Output + decision Trace/tool/source
Bắt đầu Rule + test Read-only + review Max steps + sandbox

Hình 2 — Decision matrix giúp chọn mode theo tính chất công việc thay vì theo tên sản phẩm.

3. Workflow: khi đường đi đã biết

Workflow phù hợp khi các bước, điều kiện và output có thể viết rõ. Content pipeline là ví dụ: Planner tạo plan, Writer tạo draft, Reviewer kiểm, Validator chạy gate. Mỗi bước có input/output, owner và điều kiện fail. Không cần agent chọn thứ tự nếu thứ tự đã là một phần của policy.

Một workflow tốt không có nghĩa là workflow cứng nhắc. Có thể thêm retry giới hạn, fallback và nhánh NEEDS_REVIEW. Invoice giả có thể dùng bước trích field → kiểm schema → so tổng → người duyệt khi field thiếu. Rule rõ giúp test deterministic, dễ audit và dễ biết lỗi ở đâu.

Không nên dùng workflow giả nếu mỗi case cần lập kế hoạch khác nhau mà bạn cứ viết hàng trăm nhánh khó bảo trì. Dấu hiệu cần xem lại là rule phình to, nhiều ngoại lệ không có owner hoặc reviewer liên tục sửa đường đi. Khi đó, thử copilot ở một điểm hẹp trước khi giao quyền điều phối cho agent.

4. Copilot: AI đề xuất, người quyết định

Copilot hợp khi AI giúp đọc, tìm, so sánh, phân loại hoặc draft nhưng người có quyền quyết định cuối. Support assistant có thể đọc ticket giả, tìm policy, gợi ý route và draft reply. Nhân viên kiểm source, sửa giọng và bấm gửi. Content QA có thể gợi ý term/claim cần kiểm, nhưng reviewer giữ quyết định publish.

Hãy thiết kế approval như một bước thật:

  1. AI hiển thị output và evidence, không chỉ một nhãn.
  2. Người thấy input, policy/version và phần chưa chắc.
  3. Hệ thống ghi decision, owner và timestamp giả.
  4. Không có approval thì không gọi tool có side effect.

Copilot cũng có failure mode: người tin output vì nó viết trôi chảy, approval thành thủ tục, hoặc UI che mất nguồn. Vì vậy, guardrail vẫn cần giới hạn dữ liệu/tool; review phải có expected behavior và cách từ chối. Microsoft nhấn mạnh prompt nên nói rõ task, context và expected output; copilot càng cần format và điều kiện này để người review dễ kiểm. Microsoft prompt engineering

Hình 3 — Tách đề xuất, approval và side effect để không nhầm copilot với agent tự hành động.

5. Agent: khi cần điều phối có giới hạn

Agent hữu ích khi mục tiêu rõ nhưng đường đi thay đổi: research assistant tìm vài nguồn phù hợp, gọi công cụ đọc, kiểm provenance rồi tổng hợp. Nó có thể chọn bước kế tiếp dựa trên kết quả, nhưng system phải giới hạn tool, đích, dữ liệu, số bước và thời gian.

Guardrail là rào chắn giới hạn input, output, tool hoặc quyền. Allowlist là danh sách tool hoặc đích được phép. Một agent học tập nên bắt đầu read-only, allowlist domain giả, max_steps, timeout, log/trace, và chuyển người khi không đủ evidence. OpenAI Agents SDK mô tả tools, guardrails, state và tracing cùng nhau; khả năng gọi tool không tự tạo ra an toàn. OpenAI Agents SDK

Một agent không được tự gọi “mọi API cho tiện”. Tool contract phải có input schema, side effect, permission, expected output và error. Khi tool trả lỗi, fallback phải rõ: retry giới hạn, bỏ qua bước, quay về workflow hoặc NEEDS_REVIEW. NIST AI RMF đặt risk management và accountability trong vòng đời; owner phải biết agent đang làm gì và ai dừng được nó. NIST AI Risk Management Framework

Không nên dùng agent khi rule đơn giản, side effect cao mà chưa có approval, data boundary mơ hồ, hoặc không dựng được trace. “Nhiều agent” cũng không tự động tốt hơn một agent có scope nhỏ; mỗi thêm agent là thêm giao tiếp, state và failure mode.

6. Practice Bridge 15 phút

Bắt đầu từ đâu

Mở Google Sheets hoặc notes. Chọn một case research giả: thu thập ba nguồn, viết summary có provenance và chuyển người khi thiếu nguồn. Chấm năm câu hỏi: variability, reversibility, human judgment, tool/evidence và owner. Không dùng API key, PII, tiền thật hay production.

Mẫu đối chiếu đã điền

Tiêu chí Quan sát giả Chọn mode Boundary/next test
Input 3 câu hỏi, nguồn thay đổi Copilot → agent nhỏ Allowlist 5 domain
Side effect Chỉ đọc web, không ghi Agent read-only Max 6 bước
Human judgment Duyệt summary và source Copilot checkpoint NEEDS_REVIEW khi thiếu nguồn
Evidence URL, run_id, timestamp giả Bắt buộc trace Test source mismatch
Owner Research lead Người chịu trách nhiệm Ghi stop/rollback

Sau 15 phút, thử hạ mode xuống một bậc: nếu copilot với search read-only vẫn đạt outcome, không cần agent. Nếu workflow với 3 bước cố định đã đủ, đừng thêm autonomy. Kết quả mong đợi là một lựa chọn có lý do, boundary và next test, không phải demo.

Hình 4 — Practice card buộc lựa chọn mode đi cùng boundary và bài test nhỏ.

7. Tổng kết: chọn mode nhỏ nhất đủ dùng

a. Năm ý chính

  • Workflow cố định đường đi; copilot đề xuất để người quyết; agent điều phối nhiều bước trong scope giới hạn.
  • Chọn mode theo variability, khả năng đảo ngược, human judgment, side effect và evidence/owner.
  • Workflow dễ test/audit khi rule rõ; copilot cần approval thật; agent cần allowlist, max steps và trace.
  • Tăng autonomy làm tăng tool call, latency, cost và failure mode; “agent” không phải mặc định trưởng thành hơn.
  • Khi chưa rõ risk, data boundary hoặc stop action, giữ read-only, workflow nhỏ hoặc NEEDS_REVIEW.

b. Câu hỏi tự kiểm tra

  • Khi nào một quy trình nhiều bước vẫn chỉ cần workflow?
  • Vì sao approval của copilot phải là bước có evidence?
  • Một agent tối thiểu cần giới hạn những gì?
  • Nếu copilot đã đạt outcome, vì sao chưa cần tăng lên agent?

c. Gợi ý đáp án

Xem gợi ý câu 1

Khi thứ tự, điều kiện và output biết trước; có thể thêm retry/fallback mà không cần system tự chọn đường. Xem lại mục 1 và mục 3.

Xem gợi ý câu 2

Không có approval thật thì đề xuất có thể biến thành side effect; cần ghi output, evidence, owner và decision. Xem lại mục 4.

Xem gợi ý câu 3

Tool allowlist, data boundary, max steps, timeout, guardrail, trace, owner và stop/fallback rule. Xem lại mục 5.

Xem gợi ý câu 4

Autonomy thêm cost, latency và failure mode; mode nhỏ hơn đã đạt outcome thì dễ kiểm soát hơn. Xem lại mục 2 và mục 6.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
Workflow Chuỗi bước được định trước và kiểm soát.
Copilot AI đề xuất, người vẫn quyết định hành động.
Agent System điều phối nhiều bước trong scope được giao.
Autonomy Mức system tự chọn bước hoặc hành động.
Variability Mức input/đường đi thay đổi giữa các case.
Side effect Thay đổi bên ngoài như gửi, ghi, xoá hoặc gọi API.
Guardrail Rào chắn giới hạn input, output, tool hoặc quyền.
Allowlist Danh sách tool hoặc đích được phép.
Fallback Đường thay thế khi mode chính không đạt.

e. Nguồn tham khảo

Bài trước là Từ Business Problem đến AI Use Case #7. Bài tiếp theo là Thiết kế Context, Memory và Retrieval #9.

Lưu ý giáo dục: Workflow, copilot hay agent đều cần evaluation, boundary và owner. Hãy bắt đầu read-only, dùng dữ liệu giả và mở autonomy từng bước khi evidence đủ.