Claude Fable 5 và Thay đổi API Mythos: Những tính năng còn hoạt động và Cách kiểm tra

Anthropic đã ra mắt các dòng mô hình Fable và Mythos với một bộ quy tắc khác so với những gì các nhà phát triển đã quen, và phản ứng rất dữ dội. Hai chủ đề chính thống trị cuộc thảo luận: yêu cầu lưu giữ dữ liệu 30 ngày mới cho lưu lượng truy cập Fable và Mythos, và một loạt các thay đổi về rào chắn bảo vệ (guardrail) đã được áp dụng mà không có nhiều cảnh báo. Nếu bạn đang chạy bất kỳ thứ gì chống lại API Claude trong môi trường sản xuất, những thay đổi này sẽ ảnh hưởng trực tiếp đến bạn.

Bài đăng này sẽ tách biệt những thông tin nhiễu loạn khỏi những phần ảnh hưởng đến mã của bạn. Bạn sẽ thấy những gì được báo cáo đã thay đổi, những gì vẫn hoạt động như tuần trước, và cách xác minh tích hợp của riêng bạn với Apidog thay vì phỏng đoán. Nếu bạn đang duy trì một tích hợp Claude, động thái an toàn nhất hiện nay là kiểm tra các giả định của bạn, chứ không phải tin tưởng chúng.

Những gì thực sự đã thay đổi

Ba điều đang bị lẫn lộn trong cuộc thảo luận. Tách chúng ra và bức tranh sẽ trở nên rõ ràng hơn.

Lưu giữ dữ liệu. Thay đổi nổi bật là cửa sổ lưu giữ 30 ngày được áp dụng cho các yêu cầu Fable và Mythos. Trên thực tế, điều này có nghĩa là dữ liệu yêu cầu và phản hồi liên quan đến các mô hình đó được giữ lại trong một khoảng thời gian cố định thay vì bị xóa ngay lập tức. Các nhóm có cam kết nghiêm ngặt về xử lý dữ liệu quan tâm đến điều này vì nó thay đổi những gì bạn có thể hứa với người dùng của mình. Nếu chính sách quyền riêng tư của bạn nói “chúng tôi không lưu giữ lời nhắc,” thì hành vi lưu giữ của nhà cung cấp upstream của bạn giờ đây là một phần của tuyên bố đó.

Rào chắn bảo vệ (Guardrails). Một chủ đề riêng đã đề cập đến các thay đổi về rào chắn bảo vệ (guardrail) trên Fable mà một số nhà nghiên cứu bảo mật đã phản đối. Khiếu nại không phải là việc các rào chắn bảo vệ tồn tại; mà là hành vi của chúng đã thay đổi một cách âm thầm, do đó các phản hồi đã vượt qua hôm qua có thể bị lọc hoặc định hình lại hôm nay. Đối với một ứng dụng phụ thuộc vào đầu ra nhất quán, một thay đổi âm thầm trong hành vi từ chối là một nguồn lỗi thực sự.

Truy cập lập trình. Đây là phần mà hầu hết các nhà phát triển thực sự cần hành động. Bề mặt API, mô hình xác thực và cấu trúc yêu cầu cốt lõi chưa bị thay thế. Các khóa hiện có của bạn, các cuộc gọi messages của bạn và lược đồ sử dụng công cụ của bạn vẫn hoạt động. Điều có thể thay đổi bên dưới bạn là hành vi: những lời nhắc nào bị từ chối, các cuộc gọi mất bao lâu dưới tải, và một phản hồi được truyền trực tiếp trông như thế nào khi một rào chắn bảo vệ bị kích hoạt giữa quá trình tạo.

Tóm lại: hợp đồng ổn định, hành vi không được đảm bảo ổn định, và chính sách về dữ liệu của bạn nghiêm ngặt hơn. Sự kết hợp đó chính xác là mục đích của việc kiểm thử.

Những gì vẫn hoạt động

Trước khi bạn viết lại bất cứ điều gì, hãy xác nhận những gì không thay đổi để bạn không phải sửa những vấn đề không tồn tại.

• Xác thực. Khóa API và tiêu đề x-api-key hoạt động như trước. Bạn không cần xoay vòng khóa vì những thay đổi này, mặc dù xoay vòng khóa là một thực hành tốt bất kể. Xem tài liệu tham khảo API của Anthropic để biết hợp đồng tiêu đề hiện tại.
• Cấu trúc API Messages. Phần thân yêu cầu, trường model, max_tokens, lời nhắc system và mảng messages không thay đổi. Mã được viết dựa trên API Messages vẫn tiếp tục chạy.
• Sử dụng công cụ. Các định nghĩa công cụ của bạn và hành trình khứ hồi tool_use / tool_result vẫn hoạt động như cũ. Nếu bạn đã xây dựng một tác nhân dựa trên việc gọi hàm, kết nối vẫn giữ nguyên.
• Streaming (Phát trực tiếp). Các sự kiện do máy chủ gửi vẫn phát trực tiếp các token theo cùng một cách. Điều có thể khác biệt là nội dung của luồng khi một rào chắn bảo vệ can thiệp giữa chừng.
• Bí danh mô hình. Nếu bạn ghim một mô hình bằng ID đầy đủ của nó thay vì một bí danh linh hoạt, bạn sẽ kiểm soát chính xác mô hình nào trả lời. Việc ghim là cách phòng thủ tốt nhất của bạn chống lại sự thay đổi hành vi âm thầm.

Vì vậy, không có gì buộc phải viết lại khẩn cấp. Công việc là xác minh: chứng minh rằng hành vi mà ứng dụng của bạn phụ thuộc vẫn được duy trì, và phát hiện các trường hợp nó âm thầm không còn nữa.

Cách kiểm tra tích hợp của bạn với Apidog

Đây là lúc một ứng dụng khách API thực sự phát huy tác dụng. Bạn có thể đọc nhật ký thay đổi cả ngày, nhưng cách duy nhất để biết tích hợp của bạn phản hồi như thế nào là gửi các yêu cầu và kiểm tra những gì trả về. Apidog cung cấp cho bạn một không gian làm việc để thiết kế các yêu cầu đó, lưu chúng, mô phỏng upstream và chạy chúng dưới dạng kiểm tra tự động. Nếu bạn đã chuyển khỏi Postman hoặc chưa từng tiêu chuẩn hóa, đây là một nơi khởi đầu sạch sẽ; đây là lý do rộng hơn cho kiểm thử API mà không cần Postman.

1. Ghi lại một cơ sở chuẩn được biết là tốt

Tạo một yêu cầu trong Apidog gửi đến API Messages với một lời nhắc mà bạn quan tâm; một lời nhắc sản xuất đại diện, không phải là một mẫu thử. Ghim ID mô hình đầy đủ. Lưu phản hồi. Đây là cơ sở chuẩn của bạn. Khi hành vi thay đổi sau này, bạn sẽ so sánh với phản hồi đã lưu này thay vì dựa vào trí nhớ.

POST https://api.anthropic.com/v1/messages
x-api-key: {{ANTHROPIC_API_KEY}}
anthropic-version: 2023-06-01
content-type: application/json

{
  "model": "claude-fable-5",
  "max_tokens": 1024,
  "messages": [
    { "role": "user", "content": "Summarize this support ticket and label its priority: ..." }
  ]
}

Lưu khóa API dưới dạng biến môi trường trong Apidog thay vì mã hóa cứng. Điều đó giúp giữ khóa ra khỏi các yêu cầu đã lưu của bạn và cho phép bạn chuyển đổi giữa môi trường staging và production chỉ với một menu thả xuống. Mẫu này hoạt động tương tự cho dù bạn đang kiểm tra Claude, SDK của Claude Code, hay bất kỳ mô hình nào khác đằng sau cùng một khóa.

2. Khẳng định trên phản hồi, đừng chỉ nhìn qua

Một cơ sở chuẩn chỉ hữu ích nếu bạn kiểm tra nó tự động. Trong Apidog, hãy thêm các khẳng định vào yêu cầu:

• Trạng thái là 200.
• stop_reason là end_turn, không phải max_tokens hay từ chối.
• Phần thân phản hồi chứa trường có cấu trúc mà ứng dụng của bạn phân tích (ví dụ: nhãn ưu tiên).
• Thời gian phản hồi nằm trong giới hạn thời gian chờ của bạn.

Bây giờ bạn có một bài kiểm thử, chứ không phải một ảnh chụp màn hình. Chạy nó theo lịch trình và bạn sẽ biết ngày mà một thay đổi guardrail bắt đầu lọc một lời nhắc đã từng vượt qua. Đây là nguyên tắc tương tự đằng sau kiểm thử hợp đồng API; bạn đang ghim hành vi mà mã downstream của bạn giả định.

3. Cố ý kiểm tra các đường dẫn từ chối và rào chắn bảo vệ

Các khiếu nại về rào chắn bảo vệ quan trọng vì việc từ chối rất dễ bị bỏ qua cho đến khi chúng phá vỡ một quy trình làm việc. Xây dựng một bộ nhỏ các yêu cầu nằm gần ranh giới nội dung của bạn và lưu các phản hồi. Nếu một lời nhắc đã được chấp nhận trước đây bắt đầu bị từ chối hoặc định hình lại, khẳng định của bạn sẽ thất bại và bạn sẽ biết trước khi người dùng của bạn biết. Coi hành vi từ chối là một hợp đồng đã được kiểm thử, chứ không phải là một suy nghĩ sau.

4. Giả lập Anthropic để các bài kiểm thử của bạn không phụ thuộc vào API trực tiếp

Bạn không muốn bộ CI của mình gọi một upstream có trả phí, giới hạn tốc độ và thay đổi hành vi trong mỗi lần chạy. Máy chủ giả lập của Apidog cho phép bạn thiết lập một endpoint Messages giả mạo trả về các phản hồi đã được chuẩn bị sẵn; bao gồm cả các hình thức từ chối và lỗi mà bạn đã ghi lại ở trên. Hướng ứng dụng của bạn đến máy chủ giả lập trong quá trình phát triển và kiểm thử tích hợp. Mã của bạn sẽ thực hành cấu trúc phản hồi thực tế mà không tốn token hoặc vượt quá giới hạn tốc độ. Khi bạn muốn sử dụng API thực, hãy đổi lại URL cơ sở. Xây dựng một tác nhân dựa trên điều này? Mẫu giả lập tương tự là xương sống của một thiết lập kiểm thử tác nhân AI tốt.

5. Xác minh hành vi nhạy cảm với việc lưu giữ dữ liệu

Nếu cửa sổ lưu giữ dữ liệu 30 ngày quan trọng đối với câu chuyện tuân thủ của bạn, hãy ghi lại nó ở nơi nhóm của bạn có thể thấy và kiểm tra các kiểm soát mà bạn có. Xác nhận bạn gọi đến những endpoint nào, dữ liệu nào rời khỏi hệ thống của bạn trong mỗi yêu cầu, và liệu bạn có đang gửi nhiều hơn mức cần thiết hay không. Lịch sử yêu cầu của Apidog giúp dễ dàng kiểm tra chính xác những tải trọng mà tích hợp của bạn gửi đi, vì vậy bạn có thể cắt bỏ bất kỳ dữ liệu nhạy cảm nào không cần thiết trong lời nhắc. Bạn không thể thay đổi chính sách lưu giữ của Anthropic, nhưng bạn có thể kiểm soát những gì bạn cung cấp cho nó.

6. Kiểm tra dưới tải và thời gian chờ

Hành vi dưới tải là nơi những thay đổi âm thầm ẩn náu. Sử dụng Apidog để chạy cùng một yêu cầu lặp lại và theo dõi sự gia tăng độ trễ, luồng dữ liệu một phần hoặc các sự cố rào chắn bảo vệ không liên tục. Đặt một thời gian chờ thực tế và chính sách thử lại trong ứng dụng khách của bạn, sau đó kiểm tra xem việc thử lại của bạn có thực sự xử lý phản hồi chậm hoặc bị cắt ngắn hay không, thay vì làm trầm trọng thêm vấn đề. Nếu bạn đang gặp phải tình trạng chậm trễ từ upstream, phương pháp gỡ lỗi trong sửa lỗi thời gian chờ yêu cầu upstream áp dụng trực tiếp.

Danh sách kiểm tra thực tế

Chạy qua danh sách này một lần và bạn sẽ biết chính xác vị trí của mình:

• [ ] Ghim ID mô hình đầy đủ; ngừng dựa vào các bí danh linh hoạt cho các đường dẫn sản xuất.
• [ ] Lưu một phản hồi cơ sở chuẩn cho mỗi lời nhắc mà ứng dụng của bạn phụ thuộc.
• [ ] Thêm các khẳng định về trạng thái, stop_reason và các trường bạn phân tích cú pháp.
• [ ] Ghi lại các hình dạng từ chối và lỗi; khẳng định chúng không thay đổi âm thầm.
• [ ] Giả lập API Messages để CI không gọi đến endpoint trực tiếp.
• [ ] Kiểm tra các tải trọng gửi đi đối với cửa sổ lưu giữ 30 ngày.
• [ ] Kiểm tra hành vi thời gian chờ và thử lại dưới tải lặp lại.

Không có điều nào trong số này yêu cầu chờ Anthropic công bố thêm chi tiết. Bạn kiểm soát việc xác minh, và xác minh là thứ biến một tiêu đề chính sách thành một sự kiện không đáng kể đối với nhóm của bạn.

Câu hỏi thường gặp

Tôi có cần thay đổi khóa API của mình vì những thay đổi của Fable và Mythos không? Không. Xác thực không thay đổi. Xoay vòng khóa theo lịch trình vẫn là một thực hành tốt, nhưng những thay đổi này không bắt buộc phải làm vậy.

Mã API Messages và sử dụng công cụ hiện có của tôi có bị hỏng không? Hợp đồng yêu cầu và phản hồi ổn định, vì vậy mã của bạn vẫn tiếp tục chạy. Điều có thể thay đổi là hành vi; các trường hợp từ chối, độ trễ và nội dung được truyền trực tiếp dưới các rào chắn bảo vệ. Đó là vấn đề kiểm thử, không phải vấn đề viết lại.

Thay đổi về việc lưu giữ dữ liệu 30 ngày là gì? Các báo cáo mô tả một cửa sổ lưu giữ 30 ngày được áp dụng cho lưu lượng truy cập Fable và Mythos. Nếu các cam kết về quyền riêng tư của riêng bạn phụ thuộc vào hành vi lưu giữ của upstream, hãy xem xét điều này và xác nhận dữ liệu bạn thực sự gửi đi. Luôn kiểm tra tài liệu về việc sử dụng dữ liệu hiện tại của Anthropic để biết các điều khoản chính thức.

Làm thế nào để tôi phát hiện các thay đổi về rào chắn bảo vệ trước khi người dùng phát hiện? Lưu các phản hồi cơ sở chuẩn cho các lời nhắc gần ranh giới nội dung của bạn, thêm các khẳng định và chạy chúng theo lịch trình trong Apidog. Một khẳng định thất bại sẽ cho bạn biết ngày hành vi thay đổi.

Tôi có thể kiểm tra tất cả những điều này mà không tốn token không? Có. Sử dụng máy chủ giả lập của Apidog để phát lại các phản hồi đã ghi lại, bao gồm cả các trường hợp từ chối và lỗi, để các lần chạy phát triển và CI của bạn không bao giờ chạm vào API trực tiếp.

Kết luận

Những thay đổi của Fable và Mythos là có thật, nhưng đối với hầu hết các nhà phát triển, chúng là câu chuyện về hành vi và chính sách, chứ không phải câu chuyện về API bị hỏng. Khóa của bạn hoạt động, các cuộc gọi Messages của bạn hoạt động, công cụ của bạn hoạt động. Điểm yếu nằm ở những phần thay đổi âm thầm: từ chối, độ trễ và dữ liệu của bạn hoạt động như thế nào sau khi rời khỏi hệ thống của bạn. Ghim các mô hình của bạn, ghi lại các cơ sở chuẩn, khẳng định trên chúng và giả lập upstream để các bài kiểm thử của bạn vẫn rẻ và đáng tin cậy. Tải Apidog và biến “Tôi nghĩ nó vẫn hoạt động” thành “Tôi đã kiểm tra, và đây là bằng chứng.”