【Bắt buộc phải xem khi làm Skill/Acoding】Workflow của Agent bạn đã bỏ sót một bước then chốt

Chuyên mục: WaytoAGI · Tác giả / Nguồn: · Cập nhật:

Tóm tắt cốt lõi: Nhiều người khi xây dựng Agent chỉ chú trọng mở rộng năng lực mà bỏ qua ranh giới ràng buộc, khiến Agent rất dễ bị chệch hướng nhiệm vụ bởi những câu lệnh bộc phát của người dùng. Tác giả đưa ra một phương án thiết kế khép kín có thể triển khai thực tế, thiết lập cơ chế ranh giới thông qua việc định nghĩa mục tiêu, định tuyến trạng thái, khắc phục sai lệch và phán đoán điểm kết thúc, đi kèm cấu trúc file Skill và tư duy kiểm thử ngoại lệ.

Bản đồ hoạ thông tin (AI tạo)
Bản đồ hoạ thông tin (AI tạo)

Link bài viết gốc: https://mp.weixin.qq.com/s/rZ4VI8MUH-GDZ...

Ngải Tiếu teacherAi · Official Account · Ngải Tiếu AI · 2026-10-22 06:58

Bài viết này được chia sẻ lại, bản quyền thuộc về tác giả gốc, toàn văn căn cứ theo link bài gốc

Nhiều người khi làm Skill, dựng Agent đã mắc một sai lầm: chỉ dạy nó phải làm thế nào, mà không dạy nó điều gì không nên làm.

Trong trò chuyện thông thường, AI cuốn theo người dùng thì thường không thành vấn đề. Nhưng một khi Agent đang xử lý bán hàng, nghiên cứu, nhu cầu hay ra quyết định, mà nó vẫn bị một câu nói bâng quơ của người dùng dẫn dắt đi lệch hướng, thì điều lộ ra không phải là “nói chuyện rất giống người”, mà là Agent nghiệp vụ này căn bản chưa được hoàn thiện thiết kế.

Mô hình lớn (LLM) trước hết là mô hình ngôn ngữ, không phải là một quy trình nghiệp vụ vốn có sẵn ranh giới lập trình. Nó rất giỏi bắt lời tiếp theo, nhưng không tự nhiên biết được câu này có thuộc về nhiệm vụ hiện tại hay không. Năng lực quyết định nó có thể làm gì; ràng buộc quyết định nó hiện tại không được làm gì; nắn chỉnh quyết định khi nó đi lệch thì kéo lại thế nào; và phán đoán kết thúc quyết định thời điểm nó bàn giao kết quả.

01

Một video hài hước đã bộc lộ lỗ hổng sản phẩm của Agent nghiệp vụ

001-a0.png
001-a0.png

Trước tiên hãy xem video này.

Một AI gọi điện bán hàng (telesale), khi giao tiếp bình thường thì không nhận ra điểm bất thường. Người dùng đột ngột bắt nó đọc thuộc lòng một đoạn văn, tính phép nhân phức tạp, nó lập tức làm theo, thế là mọi người cười vì nó đã “lộ tẩy”.

Là một AI builder và FDE chuyên triển khai thực tế các dự án, phản ứng đầu tiên khi xem video này không nên là cười như người dùng phổ thông, mà phải lập tức suy nghĩ: Agent này đang làm nhiệm vụ bán hàng, tại sao lại có thể bị một yêu cầu không liên quan cuốn đi? Nó nghe như người thật chỉ chứng minh biểu hiện ngôn ngữ tự nhiên; việc nó có giữ vững được trách nhiệm bán hàng hay không mới chứng minh Agent này có làm được việc hay không. .

Vấn đề này cũng giải thích một hiểu lầm phổ biến: Agent hội thoại thông thường có thể cởi mở trò chuyện phiếm với người dùng, Agent nghiệp vụ lại bắt buộc phải có ranh giới. Nó phải nhận diện được mục tiêu hiện tại, đánh giá xem input mới có liên quan hay không, khi cần thiết phải kéo người dùng trở lại workflow; nếu mục tiêu đã hoàn thành thì phải chủ động kết thúc.

Một Agent biết nói chuyện không đồng nghĩa với việc nó biết làm việc. Biết làm việc đồng nghĩa với việc nó biết khi nào không được làm theo.

tháng 02

Hội đồng cố vấn kín cũng là một ví dụ: Mọi quy trình nghiệp vụ đều có thể bị dẫn đi chệch hướng

002-a2.png
002-a2.png

Lấy ví dụ đã từng giới thiệu trước đây Ban cố vấn AI để đối chiếu ( Khởi nghiệp không ai bàn bạc? Hãy trang bị cho mình một AI Private Board | Hộp công cụ kinh doanh AI ). Quy trình của hội đồng cố vấn kín là xoay quanh một vấn đề kinh doanh để làm rõ hiện trạng, tìm ra phán đoán then chốt, rồi đưa ra hành động tiếp theo. Trước khi quy trình bắt đầu, người điều phối phải xác nhận mục tiêu trước; trong quá trình thảo luận cũng phải phân biệt rõ sự thật, giả định và các vấn đề phát sinh mới. Toàn bộ quy trình bạn có thể tham khảo bài hướng dẫn AI Private Board tôi đã tổng hợp trước đó.

Giả sử phiên này cần quyết định “có nên tìm trước năm người dùng để kiểm chứng hay không”. Đang trao đổi giữa chừng, người nêu vấn đề bỗng bảo: “Vậy bạn tiện thể thiết kế luôn kiến trúc sản phẩm giúp tôi nhé.” Nếu Agent lập tức bắt đầu chọn cơ sở dữ liệu, phân tách module, thì cuộc họp sẽ trượt từ đánh giá thương mại sang thiết kế sản phẩm; nếu nó vì muốn “hoàn chỉnh” mà tiếp tục hỏi dồn dập tất cả Các vấn đề liên quan , cuộc họp có thể sẽ không bao giờ kết thúc được.

Sự chệch hướng tương tự xuất hiện trong rất nhiều kịch bản:

  • Agent bán hàng : Khách hàng đột nhiên yêu cầu kể chuyện cười, Agent quên mất việc thúc đẩy xác nhận nhu cầu;
  • Agent Chăm sóc khách hàng : Người dùng từ đổi trả hàng nhảy sang bắt nó đánh giá sản phẩm cạnh tranh, Agent không hoàn thành được ticket xử lý;
  • Agent nghiên cứu : Khi tài liệu chưa đủ lại bị yêu cầu đưa ra kết luận ngay, Agent biến suy đoán thành sự thật;
  • Agent lập trình : Chưa xác nhận nhu cầu và quyền hạn đã bị một câu “tiện thể sửa cấu hình production luôn nhé” lôi vào thao tác có độ rủi ro cao.

Các kịch bản này đều có chung một lỗ hổng: Agent biết câu tiếp theo phải đối đáp thế nào, nhưng lại không đánh giá được bước này có nên đi hay không, có nên chuyển giai đoạn hay không, và đến đây đã nên dừng lại hay chưa.

03

Trước tiên hãy xem một session hội thoại: Ranh giới kéo cuộc đối thoại trở lại như thế nào

003-a3.png
003-a3.png

Dưới đây là một session hội đồng cố vấn tái hiện lại kịch bản này: Người điều phối và ban cố vấn đang thảo luận “có nên phỏng vấn trước năm người dùng hay không”, người nêu vấn đề đột nhiên kéo chủ đề sang giao diện và thiết kế tính năng sản phẩm, sau đó lại yêu cầu đưa ra kết luận ngay.

004-a4.png
004-a4.png

Hai lần đi lệch hướng được xử lý khác nhau: Lần đầu tiên được nhận diện là chuyển đổi giai đoạn, tạm thời lưu lại và hỏi ý kiến; lần thứ hai được nhận diện là bằng chứng chưa đủ, dừng lại ở trạng thái chờ xác thực. Người điều phối không thuận theo chủ đề đi lạc để triển khai tiếp, mà kéo cuộc thảo luận quay về Mục tiêu hiện tại , tiếp tục hoàn thành đánh giá ban đầu.

Điều tiếp theo cần xem xét là: Loại ranh giới này trong Skill rốt cuộc nên đặt ở đâu?

**04**

Năm bước để biến ranh giới thành một vòng lặp khép kín có thể vận hành

005-a5.png
005-a5.png

Năm bước này không phải quy trình độc quyền của hội đồng cố vấn, cũng không phải để bắt người điều phối mỗi vòng phải đọc thuộc lòng “bây giờ không được làm gì”. Nó là một bộ ràng buộc chung: Giúp bất kỳ Agent nghiệp vụ nào cũng đều biết mình đang giải quyết việc gì, khi input thay đổi thì xử lý ra sao, và khi nào nên dừng lại.

Bước 1: Định nghĩa mục tiêu và điều kiện bàn giao của nhiệm vụ hiện tại.

Trước tiên hãy viết rõ vấn đề duy nhất mà Agent cần giải quyết tại thời điểm này, và kết quả như thế nào thì được coi là hoàn thành. Mục tiêu phải nghiệm thu được, không thể chỉ viết chung chung là “giúp người dùng nghĩ thông suốt” hay “đưa ra lời khuyên chuyên nghiệp”. Nếu không có điều kiện bàn giao, Agent sẽ không thể phán đoán nên tiếp tục hỏi sâu hơn, hay đã có thể chốt lại.

Bước 2: Viết ranh giới thành các trạng thái và quy tắc chuyển đổi (transition rules).

Ranh giới không phải là một “danh sách điều cấm”, mà là Trạng thái hiện tại cho phép những hành động nào, input nào sẽ kích hoạt chuyển đổi nào. Quy tắc cần mô tả: thông tin nào có thể đưa vào đánh giá hiện tại, yêu cầu nào nên tạm lưu lại, điều kiện nào thì được chuyển giai đoạn, trường hợp nào bắt buộc phải dừng lại ở trạng thái chờ xác thực. Như vậy, “không làm gì” sẽ không còn phụ thuộc vào trí nhớ tức thời của model, mà biến thành các điều kiện routing có thể phán đoán được.

Bước 3: Mọi input đều phải qua routing trước khi đi vào phần phản hồi.

Input mới của người dùng không thể lập tức biến thành câu trả lời. Agent phải phán đoán trước xem input đó đang bổ sung cho nhiệm vụ hiện tại, đưa ra yêu cầu của giai đoạn mới, thay đổi mục tiêu, đi chệch phạm vi, hay yêu cầu đưa ra kết luận khi chưa đủ bằng chứng. Kết quả routing quyết định hành động tiếp theo , model chỉ chịu trách nhiệm diễn đạt hành động đó ra.

Bước 4: Khi bị lệch hướng, thực hiện hành động nắn chỉnh hiển thị rõ ràng.

Nắn chỉnh không đơn giản chỉ là nói “xin hãy quay lại chủ đề”, mà phải để người dùng nhìn thấy bốn điều: Yêu cầu vừa rồi thuộc loại nào, nó có làm thay đổi mục tiêu hiện tại không, hệ thống dự định tạm lưu lại hay chuyển đổi, và tiếp theo sẽ hỏi câu hỏi liên quan nào. Câu hỏi liên quan bắt buộc phải phục vụ cho mục tiêu ban đầu, đưa cuộc đối thoại quay lại nhiệm vụ chứ không phải đẩy người dùng ra ngoài.

Bước 5: Ghi phán đoán trở lại trạng thái và thiết lập điều kiện kết thúc.

Sau mỗi vòng xử lý, hãy cập nhật mục tiêu, giai đoạn, sự thật đã xác nhận, các hạng mục chờ kiểm chứng và yêu cầu tạm lưu; khi đạt điều kiện bàn giao thì xuất kết quả và kết thúc; nếu bằng chứng chưa đủ thì dừng ở trạng thái chờ xác thực; khi người dùng yêu cầu dừng rõ ràng hoặc cạn ngân sách thì cũng phải kết thúc. Một Agent không có điều kiện kết thúc sẽ coi mọi câu hỏi mới đều là lý do để tiếp tục làm việc.

Cốt lõi của năm bước này, chính là đưa các ràng buộc vào trong mục tiêu, trạng thái, routing, nắn chỉnh và điều kiện kết thúc. Code chịu trách nhiệm thực thi, trạng thái chịu trách nhiệm ghi nhớ (memory), còn kiểm thử chịu trách nhiệm xác thực xem chúng có còn hiệu lực khi gặp input bất thường hay không. .

**05**

Đưa năm bước này vào cấu trúc của Skill

006-a6.png
006-a6.png

Năm bước trước đã làm rõ cách thiết kế ràng buộc, tiếp theo chúng ta sẽ đưa chúng vào Cấu trúc tệp và entry point của Skill, để model biết ở mỗi giai đoạn nên đọc gì, mỗi vòng nên gọi tài nguyên nào.

Mối quan hệ tương ứng giữa năm bước và các file được minh họa như sau:

yếu tố

Mục tiêu và điều kiện bàn giao → SKILL.md

Ranh giới và trạng thái → references/boundary-routing.md + templates/session-state.md

Routing cho input → scripts/session_router.py

Nắn chỉnh đi lệch → Hành động chuyển đổi trong boundary-routing.md

Kết thúc và bàn giao → session-state.md + session_router.py

Ba khối code, hãy xem tiếp cấu trúc cụ thể:

yếu tố

private-board/

├── SKILL.md # Vai trò người điều phối, mục tiêu, entry point

├── references/

│ └── boundary-routing.md # Ranh giới và quy tắc kéo về luồng chính

├── scripts/

│ └── session_router.py # Phán đoán routing cho input mỗi vòng

└── templates/

└── session-state.md # Mục tiêu, giai đoạn, bằng chứng, hạng mục chờ kiểm chứng

markdown

# Người điều phối Hội đồng cố vấn

Mục tiêu: Xoay quanh vấn đề kinh doanh hiện tại để đưa ra phán đoán và hành động tiếp theo.

Mỗi vòng: Trước tiên đọc trạng thái, tiếp theo phán đoán ranh giới, cuối cùng mới sinh câu trả lời.

Cấm: Chuyển giai đoạn khi chưa được xác nhận; đưa ra kết luận trực tiếp khi chưa đủ bằng chứng.

python

def route(message, state):

# state lưu trữ: mục tiêu hiện tại, giai đoạn, sự thật đã xác nhận, hạng mục chờ kiểm chứng, yêu cầu tạm lưu

intent = classify(message, state.stage) # Phán đoán input trước, không trả lời trực tiếp

if intent == "continue":

return {"action": "tiếp tục giai đoạn hiện tại"} # Bổ sung dữ kiện cần thiết cho câu hỏi hiện tại

if intent == "switch":

return {"action": "yêu cầu xác nhận chuyển đổi"} # Không thể âm thầm bước sang giai đoạn tiếp theo

if intent == "out_of_scope":

state.parked.append(message)

return {"action": "tạm lưu và kéo về", "goal": state.goal}

if intent == "insufficient_evidence":

state.pending.append(message)

return {"action": "dừng ở chờ xác minh", "next": "liệt kê hành động thu thập chứng cứ"}

if state.done:

return {"action": "bàn giao và kết thúc"} # Đạt điều kiện kết thúc, ngừng hỏi thêm

Thứ tự gọi chính là: Input của người dùng → Đánh giá định tuyến → Tiếp tục, tạm lưu, kéo về hoặc chuyển đổi → Tạo câu trả lời → Cập nhật trạng thái.

**06**

Kiểm thử không thể chỉ chạy luồng thông thường, mà cần chủ động tạo ra sai lệch

007-a7.jpg
007-a7.jpg

Nhiều người khi nghiệm thu Skill chỉ kiểm thử xem có chạy hết quy trình khi người dùng hợp tác hay không. Điều này tương đương với việc chỉ kiểm thử happy path của chương trình mà không kiểm thử input bất thường.

Agent nghiệp vụ khi gặp bất thường không nhất thiết là báo lỗi hệ thống. Việc người dùng đột ngột đổi chủ đề, yêu cầu bỏ qua các bước cần thiết, giục ra kết luận khi chưa đủ bằng chứng, hay tiếp tục nhồi câu hỏi mới khi đã có thể bàn giao, đều là những input bất thường đối với ranh giới phản hồi .

Do đó, kiểm thử tối thiểu phải bao quát các trường hợp sau:

  • Người dùng đột ngột đưa ra một yêu cầu không liên quan, Agent có giữ lại mục tiêu ban đầu và tạm lưu yêu cầu đó hay không;
  • Người dùng yêu cầu bỏ qua bước then chốt, Agent có giải thích rủi ro và từ chối vượt rào hay không;
  • Người dùng thay đổi rõ ràng mục tiêu, Agent có cập nhật trạng thái thay vì cố chấp bám lấy quy trình cũ hay không;
  • Khi chưa đủ bằng chứng, Agent có đưa ra các hành động thu thập chứng cứ thay vì bịa ra câu trả lời hay không;
  • Sau khi đạt điều kiện kết thúc, Agent có bàn giao và dừng hỏi thêm hay không;
  • Khi cạn kiệt ngân sách, Agent có phân biệt rõ giữa "đã hoàn thành" và "bị buộc phải dừng" hay không.

Đây chính là cách biến "ranh giới" thành hành vi có thể kiểm thử được. Lập trình thì phải throw exception, kiểm thử các luồng ngoại lệ; phát triển Agent cũng cần chủ động ném vào những input khiến nó lệch khỏi nhiệm vụ, quan sát xem nó có thể nhận diện, điều chỉnh và kết thúc hay không.

Giữ vững được luồng thông thường chỉ chứng minh nó biết thực thi; xử lý được các ranh giới bất thường mới chứng minh nó thực sự có thể làm việc.

**07**

Cốt lõi của AI Engineering là làm cho output đáng tin cậy về lâu dài

008-a8.png
008-a8.png

Từ Skill đến Coding Agent, từ chăm sóc khách hàng đến trợ lý nghiên cứu, điều thực sự cần kỹ nghệ hóa không phải là "làm cho AI thông minh hơn", mà là làm cho đầu ra của nó có căn cứ, có thể kiểm chứng và duy trì lâu dài.

Đây mới là AI Engineering thực thụ. Vì vậy, tôi đã xây dựng một nền tảng kỹ nghệ AEF nhằm giải quyết bài toán: gom yêu cầu, kiến trúc, quy tắc, tài liệu, kiểm thử, bàn giao và chốt chặn bảo mật vào cùng một trật tự làm việc. Đối với Agent, điều này có nghĩa là không chỉ quy định quy trình thông thường, mà còn phải quy định Đầu vào bất thường cách xử lý ra sao; không chỉ yêu cầu sinh kết quả, mà còn phải lưu lại căn cứ phán đoán và điều kiện nghiệm thu.

Tôi cũng đưa phương pháp luận này vào Trại huấn luyện AI Coding Engineering: Thực chiến phát triển sản phẩm, kiểm thử và triển khai . Khóa học không dạy bạn viết thêm vài prompt, mà ngay cả người mới bắt đầu không có bất kỳ nền tảng kỹ thuật nào cũng có thể mang dự án của mình đến để học cách phát triển, kiểm chứng và duy trì sản phẩm AI như một đội ngũ kỹ thuật chuyên nghiệp. Thay vì chỉ hào hứng dựng nhanh một trang web hay app đơn giản rồi đến khi phức tạp hơn một chút là hoàn toàn bế tắc.

Trại huấn luyện lấy nền tảng kỹ nghệ AEF làm điểm tựa cho các thực hành SDD, TDD và Agile, giúp chất lượng sản phẩm có căn cứ, lặp lại liên tục có phương pháp, rồi mới tiến vào bước kiểm chứng thương mại hóa. Nhưng bạn không cần phải học những kiến thức phức tạp khó nhằn, bởi toàn bộ phương pháp luận đã được tôi đóng gói thành bộ công cụ; bạn chỉ cần mang dự án của mình đến, gọi dùng theo quy trình và nhu cầu là có thể dễ dàng trở thành một "cao thủ công nghệ".

Giúp bạn làm AI coding một cách rõ ràng minh bạch, nhẹ nhàng thoải mái và bài bản chuyên nghiệp . Nhấp vào thẻ bên dưới để mua, từ một người mới trải nghiệm Vibe Coding tiến cấp thành một AI builder thực sự đáng tin cậy .

Trong kỷ nguyên AI, năng lực thực sự không phải là khiến Agent làm được mọi thứ, mà là để nó làm đúng nơi cần làm, dừng đúng chỗ cần dừng, và mỗi sản phẩm tạo ra đều vững vàng trước mọi khâu kiểm tra.

Học tương tác với AI (NotebookLM)

Ngoài đọc , bạn có thể nghe , xem và xem hoạ thông tin ở đầu bài. Bài này còn có bộ công cụ tương tác do AI tạo: Bài kiểm tra trắc nghiệm, Thẻ ghi nhớ, Sơ đồ tư duy, Bản trình bày và Báo cáo chuyên sâu.

Mở không gian học tương tác