Claude Fable 5: Hướng dẫn thực hành về quy trình làm việc AI trong sản xuất

Claude Fable 5 phù hợp thực tế cho các nhóm muốn tác nhân AI xử lý quy trình mã hóa, báo cáo và vận hành dài hơn nhưng chỉ khi công việc có phạm vi, có thể quan sát và xem xét được. Hướng dẫn Claude Fable 5 này cung cấp cho người sáng lập, người lãnh đạo dữ liệu và nhóm sản phẩm AI một kế hoạch sản xuất: chọn quy trình làm việc phù hợp, xác định các bước chuyển giao, thêm rào chắn và đo lường xem tác nhân có vượt qua quy trình hiện tại hay không.

Vấn đề của người mua không phải là “mô hình có thể làm được việc ấn tượng không?” Vấn đề là liệu nhóm của bạn có thể tin cậy một tác nhân chạy dài hạn để xử lý mã, dữ liệu, bảng thông tin, tài liệu hướng tới khách hàng hoặc hoạt động nội bộ mà không tạo ra gánh nặng rà soát ẩn hay không.

Tại Van Data Team, chúng tôi bắt đầu bằng việc lập bản đồ quy trình làm việc kinh doanh trước khi chọn mô hình. Đối với kiểu triển khai này, điều đó thường có nghĩa là sự kết hợp của phát triển tác nhân AI, thiết kế truy cập dữ liệu, tự động hóa quy trình làm việc, báo cáo, cổng đánh giá và tiêu chuẩn phân phối. Mô hình là một phần của hệ thống. Lớp vận hành xung quanh nó là thứ quyết định liệu công việc có trở nên hữu ích hay không.

Bài học chính

• Sử dụng Fable cho công việc có giới hạn trong thời gian dài chứ không phải các thử nghiệm "tác nhân tự trị" mơ hồ với tiêu chí chấp nhận không rõ ràng.
• Mẫu quy trình công việc an toàn nhất là lập kế hoạch, thực hiện theo từng giai đoạn, tự kiểm tra, đánh giá của con người, sau đó phát hành hoặc sửa đổi.
• Chi phí, độ trễ, ngân sách mã thông báo, khả năng quan sát, gánh nặng đánh giá và khả năng khắc phục lỗi phải được đo lường trong quá trình thí điểm.
• Các biện pháp bảo vệ tích hợp rất hữu ích nhưng chúng không thay thế các quyền, ghi nhật ký, cổng phê duyệt và quy tắc leo thang của riêng bạn.
• Việc triển khai mạnh mẽ bắt đầu bằng một quy trình công việc trong đó chất lượng đầu ra có thể được so sánh với quy trình thủ công hiện tại.

Truyện ngụ ngôn Claude 5 là gì?

Claude Fable 5 là mô hình Claude thế hệ tiếp theo của Anthropic dành cho công việc đòi hỏi kiến thức cứng, mã hóa và các nhiệm vụ tác nhân dài hạn. Anthropic định vị nó cho những công việc đầy tham vọng như dự án mã hóa nhiều giai đoạn, quy trình làm việc của doanh nghiệp, phân tích nặng về tài liệu và các tác nhân có thể lập kế hoạch, ủy quyền và kiểm tra công việc của chính họ.

Trang Truyện ngụ ngôn nhân loại mô tả nó được xây dựng để giải quyết các vấn đề về kiến thức và mã hóa khó, bao gồm cả các nhiệm vụ không đồng bộ mà các mô hình trước đây không thể duy trì được. Thẻ mẫu của Amazon Bedrock xoay quanh hoạt động tự chủ bền vững, lập kế hoạch theo giai đoạn, ủy quyền đại lý phụ và tự xác minh.

Chi tiết triển khai chính là Fable không chỉ đơn giản là bản nâng cấp mô hình trò chuyện. Nó được định vị xung quanh một phong cách điều hành tác nhân hơn. Điều đó thay đổi thiết kế dự án. Thay vì hỏi "Chúng ta nên viết lời nhắc nào?" câu hỏi hay hơn là "Quy trình làm việc nào có thể được ủy quyền, giám sát, đánh giá và cải thiện một cách an toàn?"

Nó cũng nằm gần Mythos 5 trong dòng sản phẩm kiểu mẫu. Báo cáo từ TechCrunch mô tả Fable là một phiên bản công khai, được bảo vệ của khả năng cấp Mythos, với các giới hạn xung quanh các lĩnh vực có rủi ro cao như an ninh mạng, sinh học và hóa học. Đối với người vận hành, những giới hạn đó không phải là chú thích cuối trang. Chúng là một phần của thiết kế sản xuất.

Nó phù hợp ở đâu trong kiến trúc sản xuất

Hình minh họa sau đây tóm tắt quy trình sản xuất xung quanh mô hình:

Quy trình làm việc của tác nhân sản xuất có nhiều phần hơn lệnh gọi mô hình. Một kiến trúc khả thi thường bao gồm năm lớp:

1. Lớp đầu vào: yêu cầu của người dùng, tóm tắt nhiệm vụ, tài liệu nguồn, bảng kho, kho lưu trữ mã, bảng điều khiển hoặc phiếu.
2. Lớp lập kế hoạch: mô hình biến yêu cầu thành các bước, rủi ro, công cụ cần thiết, giả định và điểm đánh giá.
3. Lớp thực thi: tác nhân sử dụng các công cụ, đọc dữ liệu, viết mã, phân tích bản nháp hoặc tạo các tạo phẩm của quy trình công việc.
4. Lớp xác thực: kiểm tra, kiểm tra lược đồ, kiểm tra truy xuất, kiểm tra trang tổng quan, đánh giá của con người và bộ lọc chính sách.
5. Lớp phân phối: kéo yêu cầu, báo cáo, ghi chú trên trang tổng quan, cập nhật phiếu, bản ghi nhớ nội bộ hoặc bàn giao vận hành.

Sai lầm mà chúng tôi thấy là các nhóm coi quyền tự chủ như một sự thay thế cho việc thiết kế quy trình làm việc. Điều đó dẫn đến các bản demo trông ấn tượng và các hoạt động khó có thể tin cậy được. Một mô hình có thể thực hiện nhiều bước hơn nhưng tổ chức của bạn vẫn cần phải quyết định những gì nó có thể truy cập, những gì nó có thể thay đổi, khi nào nó phải dừng và ai phê duyệt kết quả.

Đây là lý do tại sao bối cảnh nền tảng lại quan trọng. Thông báo của Microsoft về Fable in Microsoft Foundry nhấn mạnh đến việc quản trị, bảo mật, khả năng quan sát và tích hợp quy trình làm việc của doanh nghiệp. Đó không phải là đồ trang trí doanh nghiệp. Chúng là sự khác biệt giữa một người trợ lý thông minh và một hệ thống sản xuất được quản lý.

Đối với các nhóm có quy trình làm việc nặng về dữ liệu, lớp tác nhân thường phụ thuộc vào kỹ thuật đường ống dữ liệu. Nếu tác nhân đang đọc các bảng cũ, số liệu không có tài liệu hoặc luồng sự kiện không nhất quán thì chất lượng lý luận của mô hình sẽ không lưu được quy trình làm việc.

Cách sử dụng nó cho người phi công đầu tiên

Phi công đầu tiên phù hợp đủ nhàm chán để kiểm soát và đủ giá trị để đo lường. Tránh bắt đầu bằng việc tự động hóa tác động đến khách hàng, phê duyệt tài chính, quyết định tuân thủ, thay đổi cơ sở hạ tầng sản xuất hoặc các nhiệm vụ bảo mật nhạy cảm. Bắt đầu với quy trình làm việc mà người có kỹ năng có thể xem xét kết quả một cách nhanh chóng.

Một phi công giỏi tuân theo trình tự sau:

1. Chọn quy trình làm việc có giới hạn. Các ví dụ bao gồm soạn thảo kế hoạch di chuyển, điều tra điểm bất thường trong báo cáo, tạo danh sách kiểm tra QA trên trang tổng quan hoặc chuẩn bị yêu cầu kéo từ một vấn đề rõ ràng.
2. Xác định đầu ra trước khi chạy. Đầu ra phải cụ thể: kế hoạch, danh sách kiểm tra, bản vá, bảng điều khiển có chú thích, giải thích số liệu hoặc bản ghi nhớ quyết định.
3. Viết tiêu chí chấp nhận. Quyết định những gì được coi là chính xác, không đầy đủ, rủi ro hoặc bị từ chối trước khi tác nhân bắt đầu.
4. Thêm điểm kiểm tra. Yêu cầu phê duyệt sau kế hoạch, sau khi lựa chọn công cụ, trước những thay đổi cuối cùng và trước khi phát hành.
5. Ghi lại quá trình chạy. Ghi lại lời nhắc, tệp nguồn, lệnh gọi công cụ, quyết định, lỗi xác thực, từ chối, dự phòng và ghi đè của con người.
6. So sánh với đường cơ sở. Đo lường chất lượng, nỗ lực xem xét, thời gian đã trôi qua, tỷ lệ thất bại và liệu quy trình làm việc có làm giảm công việc hay chỉ di chuyển nó.

Quy trình làm việc Fable thực tế sẽ giúp việc xem xét dễ dàng hơn chứ không khó hơn. Nếu người đánh giá phải chạy lại từng bước từ đầu thì quá trình triển khai chưa sẵn sàng.

Nếu nhóm của bạn đang đánh giá điều này để đưa vào sản xuất, Nhóm Van Data có thể biến thí điểm thành một bản đánh giá quy trình làm việc có phạm vi: bản đồ quy trình làm việc, các điểm rủi ro, sự phụ thuộc dữ liệu, thiết kế lan can, cổng đánh giá, khoảng trống trên trang tổng quan và tồn đọng triển khai. Chiến lược chạy nước rút của chúng tôi được thiết kế cho loại kết quả lập kế hoạch có giới hạn đó.

Thành phần triển khai: Mẫu tóm tắt nhiệm vụ

Đối với công việc kéo dài, một bản tóm tắt nhiệm vụ có cấu trúc sẽ tốt hơn một bản nhắc nhở lỏng lẻo. Mục tiêu là cung cấp cho tổng đài viên đủ bối cảnh hoạt động trong khi vẫn giữ cho công việc có thể kiểm tra được.

1. Define the Claude Fable 5 decision.
2. List required inputs, owner, and stop conditions.
3. Run the smallest safe workflow.
4. Validate output quality before publishing or deployment.
5. Escalate unresolved risk to a human reviewer.

Định dạng này hoạt động vì nó tách biệt hành vi khách quan, quyền, bằng chứng, đánh giá và lỗi. Nó cũng cung cấp cho nhóm của bạn một tạo phẩm có thể tái sử dụng. Theo thời gian, mỗi quy trình làm việc thành công sẽ trở thành một mẫu mà tổng đài viên của bạn có thể chạy mà ít mơ hồ hơn.

Ví dụ thực tế của nhóm

Nhóm phần mềm có thể sử dụng Fable để xử lý quá trình di chuyển cơ sở mã nhiều giai đoạn. Tác nhân đọc vấn đề, đề xuất kế hoạch triển khai, xác định các mô-đun bị ảnh hưởng, viết bài kiểm tra, tạo bản vá và tóm tắt các cân bằng. Cổng đánh giá xuất hiện trước khi hợp nhất, không phải sau khi triển khai. Nhóm vẫn phải yêu cầu CI thông thường, đánh giá mã, đánh giá bảo mật nếu có liên quan và ghi chú khôi phục.

Nhóm dữ liệu có thể sử dụng nó để điều tra sự cố bảng điều khiển. Tác nhân kiểm tra định nghĩa số liệu, những thay đổi gần đây về quy trình, độ mới của kho, độ trễ của hệ thống nguồn và bộ lọc bảng thông tin. Đầu ra không phải là "câu trả lời". Đầu ra là một gói bằng chứng: các nguyên nhân có thể xảy ra, các truy vấn hỗ trợ, mức độ tin cậy và danh sách kiểm tra xác thực. Đây là lúc quy trình báo cáo tự động có thể trở nên hữu ích: trang tổng quan có thể giải thích những điều bất thường, nhưng những phát hiện không chắc chắn vẫn được chuyển đến người đánh giá.

Nhóm vận hành có thể sử dụng nó để điều phối quy trình làm việc nội bộ định kỳ. Ví dụ: tổng đài viên có thể thu thập thông tin cập nhật từ trình theo dõi dự án, điều chỉnh các trường bị thiếu, soạn thảo bản tóm tắt điều hành và gắn cờ các mục bị chặn. Tác nhân không nên phát minh ra trạng thái. Nó sẽ hiển thị những thông tin đầu vào còn thiếu, liên kết tới các hồ sơ nguồn và yêu cầu xem xét khi bằng chứng không đầy đủ.

Những ví dụ này có cùng một mô hình. Mô hình này hoạt động hiệu quả hơn nhưng hệ thống vẫn rõ ràng về quyền, bằng chứng và phê duyệt.

Thực tiễn tốt nhất cho quy trình làm việc an toàn hơn

Các phương pháp thực hành tốt nhất là vận hành chứ không phải vẻ đẹp.

Sử dụng bản tóm tắt có cấu trúc. Lời nhắc mơ hồ tạo ra sự kiểm soát mơ hồ. Bản tóm tắt có cấu trúc xác định mục tiêu kinh doanh, công cụ được phép, nguồn dữ liệu, điểm đánh giá và hành vi lỗi.

Chia công việc dài thành các hiện vật. Yêu cầu lập kế hoạch, sau đó là bằng chứng, sau đó là bản phác thảo đầu ra, sau đó xác nhận. Mỗi giai đoạn nên được xem xét riêng.

Giữ con người trong những con đường nhạy cảm. Các kết quả đầu ra liên quan đến khách hàng, tài chính, tuân thủ, bảo mật, pháp lý và hoạt động không thể đảo ngược cần được xem xét. Tự xác minh là hữu ích, nhưng nó không phải là sự đảm bảo độc lập.

Thiết kế hành vi dự phòng. Tác nhân có thể từ chối, đánh vào các biện pháp bảo vệ, mất ngữ cảnh, gọi sai công cụ hoặc đưa ra những phát hiện không chắc chắn. Xác định xem có nên dừng, chuyển tiếp, sử dụng mô hình khác, đặt câu hỏi làm rõ hay tạo một phần báo cáo hay không.

Đo lường gánh nặng đánh giá. Một quy trình làm việc giúp tiết kiệm hai giờ soạn thảo nhưng tạo ra ba giờ kiểm tra không phải là một cải tiến. Thời gian rà soát nằm trong kế hoạch đánh giá.

Xác minh các giới hạn nền tảng hiện tại. Thẻ mô hình AWS liệt kê khoảng thời gian ngữ cảnh mã thông báo 1M và mã thông báo đầu ra tối đa 128K, cùng với mức giới hạn kiến thức vào tháng 1 năm 2026. Những thông số kỹ thuật đó ảnh hưởng đến kiến ​​trúc nhưng chúng vẫn phải được kiểm tra dựa trên tài liệu hiện tại của nhà cung cấp trước khi triển khai.

Những sai lầm phổ biến cần tránh

Sai lầm đầu tiên là sử dụng quyền tự chủ làm chiến lược. Các mô hình có khả năng hơn giúp thiết kế quy trình làm việc yếu kém trở nên rõ ràng hơn. Nếu quy trình này không rõ ràng đối với con người thì thông thường nó cũng sẽ không rõ ràng đối với tác nhân.

Sai lầm thứ hai là bỏ qua quá trình xác thực vì mô hình có thể tự kiểm tra. Tự xác minh rất hữu ích trong việc phát hiện những lỗ hổng rõ ràng, nhưng nó không thay thế các bài kiểm tra, đối chiếu nguồn, đánh giá tên miền hoặc phê duyệt kinh doanh.

Sai lầm thứ ba là trao quá nhiều quyền hạn cho người đại diện quá sớm. Truy cập chỉ đọc thường là điểm khởi đầu phù hợp. Quyền truy cập ghi, quyền truy cập triển khai và liên lạc với khách hàng sẽ được thực hiện sau, sau khi quy trình làm việc đã được chứng minh.

Sai lầm thứ tư là chỉ đo tốc độ. Một câu trả lời sai nhanh hơn còn tệ hơn một quá trình đúng chậm hơn. Theo dõi chất lượng, làm lại, độ tin cậy của người đánh giá và tác động tiếp theo.

Sai lầm thứ năm là xuất bản những tuyên bố không ổn định mà không kiểm tra nguồn trực tiếp. Giá cả, tình trạng sẵn có, hành vi dự phòng, điều khoản lưu giữ và giới hạn mẫu có thể thay đổi. Hãy coi những điều đó như những kiểm tra triển khai chứ không phải những giả định thường xanh. Ví dụ: trang Fable hiện tại của Anthropic thảo luận về các biện pháp bảo vệ, hành vi dự phòng, giá cả và lưu giữ dữ liệu theo các điều khoản mà các nhóm nên xem xét trước khi sử dụng sản xuất.

Khung thực hiện năm phần

Sử dụng khuôn khổ Claude Fable 5 này khi chuyển từ đánh giá sang triển khai.

Cấu trúc này giữ cho việc thực hiện có căn cứ. Nó cũng giúp các nhóm so sánh Fable với các mẫu đơn giản hơn: lệnh gọi LLM tiêu chuẩn, tự động hóa dựa trên quy tắc, SOP của con người hoặc mô hình ít tốn kém hơn. Nếu công việc ngắn, lặp đi lặp lại và mang tính quyết định thì tự động hóa đơn giản hơn có thể sẽ tốt hơn. Nếu công việc yêu cầu lập kế hoạch qua các giai đoạn, diễn giải bối cảnh lộn xộn, sử dụng các công cụ và tạo ra các sản phẩm có thể xem xét được thì quy trình làm việc của tác nhân theo phong cách Fable sẽ trở nên hấp dẫn hơn.

Kết luận

Claude Fable 5 quan trọng vì nó thúc đẩy các nhóm hướng tới quy trình làm việc AI tự chủ hơn: nhiệm vụ dài hơn, bối cảnh phong phú hơn, thực thi theo giai đoạn và hành vi tự kiểm tra. Nhưng mô hình chiến thắng không phải là thả lỏng mô hình. Đó là xây dựng quyền tự chủ có cấu trúc xung quanh một quy trình kinh doanh thực sự.

Bắt đầu với một quy trình công việc bị giới hạn. Xác định đầu vào, quyền, cổng xem xét, kiểm tra xác thực và hành vi dự phòng. Chạy thử nghiệm dựa trên đường cơ sở thủ công hiện tại. Sau đó quyết định xem mô hình, thiết kế quy trình làm việc và gánh nặng đánh giá có phù hợp với việc sử dụng sản xuất hay không.

Đối với các nhóm khám phá việc triển khai Claude Fable 5, Nhóm Van Data có thể giúp tạo ra các tài sản thực tế giúp đưa ra quyết định cụ thể: bản đồ quy trình làm việc, bản đồ tín hiệu, đánh giá khoảng cách trên bảng điều khiển, kế hoạch lan can, phiếu đánh giá đánh giá và phạm vi phân phối. Đó là công việc biến một mô hình đầy hứa hẹn thành một hệ điều hành để thực hiện hoạt động kinh doanh thực sự.