Case Study: Content Production Agent #14

Trả lời ngắn: Content production agent là runtime hỗ trợ các bước content trong scope và tool được phép: đọc brief, gom evidence, dựng outline, tạo draft và đưa vào review. Nó không sở hữu editorial judgment và không tự publish. Muốn dùng an toàn, ta cần brief contract, evidence packet, acceptance criteria, revision state, owner và publish gate.

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

• Cách biến một brief content thành contract có thể kiểm.
• Cách nối research packet, draft, claim check và revision loop.
• Vì sao publish là side effect cần approval và idempotency.
• Cách luyện bằng một brief giả trong 15 phút.

Lưu ý giáo dục: Ví dụ dùng brief giáo dục giả, public source hoặc fixture. Không đưa credentials, PII, customer content, private prompt hay publish token vào bài. Draft AI không phải editorial, legal, medical, financial hoặc compliance approval; không có cam kết traffic, ranking hay accuracy.

1. Case study: content production agent làm gì?

Content production agent là runtime hỗ trợ các bước content trong scope và tool được phép. Case giả của ta là một bài giáo dục cho người mới: chủ đề đã chọn, audience là beginner, outcome là hiểu một khái niệm và tự làm một bài tập nhỏ. Agent cần tạo draft có cấu trúc, nguồn và cảnh báo; reviewer mới quyết định có dùng.

Đừng bắt đầu bằng “cho agent viết bài”. Hãy chốt:

• Audience: người mới hoàn toàn, không giả định họ biết jargon.
• Intent: giải thích và thực hành, không biến bài thành quảng cáo.
• Scope: một concept, một ví dụ giả, một free practice.
• Acceptance: answer-first, heading rõ, source inline, glossary, disclaimer, 5 ý summary và không có claim thiếu căn cứ.
• Side effect: tạo draft là được; publish chỉ là queue sau approval.

Generator có thể tạo đoạn text. Workflow là chuỗi bước định trước. Agent có thể chọn search, gọi validator hoặc yêu cầu thêm input trong scope. Ba thứ này không giống nhau. Với bài giáo dục, một workflow cố định thường đủ cho format và acceptance; agent chỉ nên linh hoạt ở phần research hoặc repair khi có rule rõ.

Ví dụ đời thường: brief giống phiếu đặt món có số người và khẩu vị; research packet là túi nguyên liệu có nhãn; outline là khung bài; reviewer là người nếm và ký; publish queue là khay chờ phục vụ. Nhân viên bếp không tự mang món ra bàn chỉ vì đã nấu xong.

Hình 1 — Pipeline editorial đi từ brief tới publish queue; approval nằm trước side effect.

2. Brief contract và research packet

Brief contract là điều kiện input về audience, intent, format, scope và outcome. Một brief tối thiểu có thể ghi:

Thiếu audience hoặc scope không phải lỗi nhỏ. Agent có thể viết bài nghe mượt nhưng sai altitude, lấn sang topic kế tiếp hoặc dùng ví dụ không phù hợp. State nên là NEEDS_INPUT, không phải DRAFTED.

Evidence packet là gói source, excerpt, date và claim support. Content agent nên nhận research packet với claim nhỏ, không chỉ một danh sách link. Một claim “sản phẩm có capability X” cần link official và phạm vi rõ; một số “80%” trong bài practice phải ghi là demo, không được khoác áo fact.

Microsoft mô tả skill và tool như capability có thể gọi khi cần; deterministic steps hữu ích cho việc tìm tài liệu, kiểm schema và giảm lặp. Content agent nên dùng logic đó để giữ format ổn định, thay vì để model tự đoán mọi rule. Microsoft search and tool use architectures

3. Draft flow, state và revision loop

Revision loop là vòng feedback, sửa có lý do và kiểm lại. Một state flow đơn giản:

BRIEFED → RESEARCHED → OUTLINED → DRAFTED → CLAIM_CHECKED → REVIEW → APPROVED → PUBLISH_QUEUE

Nếu reviewer trả về lỗi, đi tới CHANGES_REQUESTED, không quay về BRIEFED mù mờ. Mỗi feedback nên có field, reason, expected fix và người chịu trách nhiệm. Nếu model change làm giọng lệch, chạy lại Golden Example/voice check, không tự sửa toàn bài theo cảm giác.

Tool boundary:

• read_source: read-only, trả title, excerpt, date, URL.
• build_outline: tạo outline theo brief contract.
• draft_article: viết bản nháp, không được gọi publish.
• validate_claims: đánh dấu supported, missing hoặc review.
• enqueue_publish: chỉ nhận bài đã APPROVED, có reviewer và idempotency key.

Idempotency nghĩa là retry không tạo cùng publish action hai lần. Nếu network timeout sau khi enqueue, agent phải kiểm article_id và state trước khi retry. Không kiểm mà gọi lại có thể tạo duplicate draft, duplicate publish hoặc notification lặp.

Hình 2 — State giúp biết draft đang ở đâu, feedback nào còn mở và tool nào được phép chạy tiếp.

4. Quality, safety và publish gate

Acceptance criteria là điều kiện bài phải đạt trước review hoặc publish. Checklist nên có cả content và process:

1. Answer-first trả lời đúng câu hỏi trong 40–60 words.
2. Brief/audience/scope không bị lệch.
3. Claim quan trọng có evidence phù hợp; fact, inference và demo được tách.
4. Thuật ngữ có định nghĩa; ví dụ không hứa kết quả.
5. H2, summary 5 ý, quiz, glossary, disclaimer và navigation đủ.
6. Hình đúng concept, alt/caption có nghĩa, không chứa PII hoặc logo sai.
7. Validator, reviewer và source check đều có evidence.

Claim coverage là mức claim quan trọng có evidence phù hợp. Một bài có nhiều link vẫn claim coverage thấp nếu link không support đúng câu. Claim thiếu source chuyển CHANGES_REQUESTED hoặc NEEDS_REVIEW; không tự bịa citation.

Publish gate cần kiểm status=APPROVED, reviewer identity, validation report, asset watermark, slug và idempotency key. Nếu PII lọt vào draft, block và redaction; nếu source không đủ, return; nếu tone sai audience, revision; nếu tool publish timeout, kiểm state trước retry.

OpenAI Agents guide mô tả tools, guardrails, state và tracing cùng nhau; content flow cũng cần tách draft permission khỏi publish permission. OpenAI Agents guide

Hình 3 — Publish chỉ mở sau acceptance, claim/safety check và reviewer approval; fail thì return, block hoặc handoff.

5. Sai lầm, giới hạn và fallback

Một content agent có thể tạo rất nhiều chữ nhưng không tạo nhiều giá trị. Các lỗi và rủi ro thường gặp:

• Content sludge: bài dài, chung chung, không có outcome hoặc practice.
• Source laundering: copy claim từ một bài thứ cấp rồi gắn nguồn official không support.
• Style drift: đổi model/prompt làm giọng, heading hoặc format lệch Golden Example.
• Unsupported claim: câu chắc chắn hơn evidence, số demo bị hiểu thành fact.
• Over-editing: repair làm mất một caveat hoặc đổi scope gốc.
• Duplicate publish: retry không idempotent tạo hai bản cùng slug.
• SEO overclaim: agent thêm promise ranking, traffic hoặc “đảm bảo lên top”.
• Feedback mơ hồ: reviewer nói “viết hay hơn”, agent sửa ngẫu nhiên và không biết khi nào dừng.

Fallback phải rõ: thiếu source → CHANGES_REQUESTED; PII → BLOCKED; style drift → so với example và yêu cầu human edit; publish timeout → kiểm state; reviewer disagreement → handoff. NIST AI RMF nhấn mạnh govern, map, measure và manage xuyên vòng đời; ở đây owner và evidence không thể bị thay bằng một nút “auto”. NIST AI RMF Core

6. Practice Bridge 15 phút

Bắt đầu từ đâu

Mở Google Sheets hoặc notes miễn phí. Dùng brief giả: “Viết bài beginner giải thích một khái niệm AI, có ví dụ support và practice 15 phút.” Đặt timer: 3 phút điền brief, 4 phút ghi evidence, 4 phút viết acceptance, 4 phút quyết định state. Không dùng customer data, credentials, tiền thật hay publish token.

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

Kết quả mong đợi là một workflow nói được “đang ở state nào và bước tiếp là gì”. Nếu feedback chưa đủ cụ thể, ghi câu hỏi cho reviewer thay vì cho agent sửa vô hạn. Nếu một claim chưa có evidence, ghi UNKNOWN đáng tin hơn việc làm bài nhìn đầy đặn.

7. Tổng kết: draft nhanh, quyền chậm

a. Năm ý chính

• Content production agent hỗ trợ pipeline trong scope; draft không đồng nghĩa approval hoặc publish.
• Brief contract và evidence packet giữ audience, intent, scope, source và acceptance rõ từ đầu.
• State/revision loop biến feedback thành bước có lý do; tool publish cần idempotency và approval.
• Claim coverage, quality, safety, image và validator checks phải nối với reviewer owner.
• Thiếu evidence, PII, style drift, duplicate state hoặc feedback mơ hồ phải return, block hoặc handoff.

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

• Brief contract giúp content agent tránh lỗi gì?
• Vì sao draft state khác approved state?
• Claim coverage cần kiểm như thế nào?
• Khi publish timeout, vì sao không retry ngay?

c. Gợi ý đáp án

Xem gợi ý câu 1

Nó khóa audience, intent, format, scope, outcome và safety trước khi viết; thiếu field thì cần input thêm. Xem lại mục 2.

Xem gợi ý câu 2

Draft mới là text cần kiểm; approved có reviewer evidence và đủ điều kiện mở publish queue. Xem lại mục 3 và mục 4.

Xem gợi ý câu 3

Đối chiếu claim quan trọng với evidence phù hợp, không đếm số link tổng. Claim thiếu nguồn đi về changes requested. Xem lại mục 4.

Xem gợi ý câu 4

Timeout có thể xảy ra sau khi action đã thành công; kiểm state và idempotency key trước để tránh duplicate publish. Xem lại mục 3 và mục 5.

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

e. Nguồn tham khảo

• Microsoft search and tool use architectures — agent, skill và tool boundary.
• OpenAI Agents guide — tools, guardrails, state và tracing.
• NIST AI RMF Core — governance, measurement và lifecycle.
• Azure RAG evaluation — evaluation theo nhiều chiều.

Bài trước là Case Study: Research Agent #13. Bài tiếp theo là Case Study: Customer Support Copilot #15.

Lưu ý giáo dục: Hãy giữ agent ở draft/read-only cho tới khi brief, evidence, acceptance, reviewer và publish state đều rõ. Không dùng bài mẫu này để tự động phát hành nội dung production.