Hướng dẫn Prompting cho Claude Opus 5.5: Sự khác biệt và cách tối ưu từ bản Opus 5

Những khác biệt về hành vi so với Claude Opus 5 và các mô hình prompting cũng như harness để giải quyết chúng: hiệu chỉnh nỗ lực (effort calibration), hành vi tư duy trong tích hợp API và chat, cập nhật tiến độ, các tác vụ không cần giám sát và đa tác nhân, từ chối do cơ chế bảo vệ (safeguard refusals), thiết kế giao diện, đầu vào hình ảnh phức tạp, quy trình làm việc đa ứng dụng và văn bản được dán trong tin nhắn người dùng.

Hướng dẫn này bao gồm các mô hình prompting dành riêng cho Claude Opus 5.5. Để biết về khả năng của mô hình và các thay đổi API, xem Có gì mới trong Claude Opus 5.5. Đối với các kỹ thuật áp dụng cho tất cả các mô hình Claude hiện tại, xem Các phương pháp prompting tốt nhất.

Claude Opus 5.5 tạo token đầu ra nhanh hơn hơn 30 phần trăm so với Claude Opus 5 và có xu hướng hoàn thành cùng một tác vụ với ít token hơn. Các prompt hiện có của Claude Opus 5 sẽ hoạt động tốt mà không cần thay đổi, và các mô hình trong Prompting Claude Opus 5 vẫn là điểm khởi đầu hợp lý. Hãy bắt đầu với phần phù hợp với những gì bạn quan sát được:

• Không chắc chắn nên chạy ở mức nỗ lực nào, hoặc các lượt chạy dài hơn và tốn kém hơn so với trên Claude Opus 5: Hiệu chỉnh nỗ lực
• Tích hợp Claude Opus 5 của bạn đã chạy với tính năng tư duy bị tắt: Các prompt được viết cho chế độ tắt tư duy
• Một tác nhân không cần giám sát dừng lại giữa chừng trong một tác vụ dài sau khi báo cáo tiến độ: Các lượt chạy tác nhân không cần giám sát
• Các yêu cầu trả về stop_reason: "refusal": Từ chối do cơ chế bảo vệ
• Các lượt tác nhân dài trông có vẻ im lặng, hoặc bạn muốn cập nhật tại các thời điểm có thể dự đoán được: Cập nhật tiến độ hướng tới người dùng
• Một tác nhân hoạt động trên nhiều ứng dụng được kết nối bỏ lỡ thông tin mà tác vụ không chỉ ra: Khám phá ngữ cảnh trong quy trình làm việc đa ứng dụng
• Bạn điều hành một nhóm tác nhân và muốn nó hoàn thành sớm hơn: Tín hiệu thời gian cho các harness đa tác nhân
• Phản hồi trong ứng dụng chat bắt đầu chậm vì mô hình suy nghĩ quá lâu trước: Hướng dẫn tư duy trong system prompt của chat
• Mô hình tuân theo các hướng dẫn nằm trong văn bản mà người dùng đã dán: Đánh dấu văn bản được dán trong tin nhắn người dùng
• Các câu trả lời về biểu đồ dày đặc, sơ đồ hoặc ảnh chụp màn hình thiếu chi tiết: Công cụ cho đầu vào hình ảnh phức tạp
• Đầu ra giao diện trông chung chung: Mặc định thiết kế giao diện

Các khả năng liên quan đến prompting

Các khả năng quan trọng nhất đối với prompting là:

• Lập trình và đánh giá mã nguồn bằng tác nhân: Mô hình mạnh nhất trong công việc nhiều bước trên một kho lưu trữ thực tế, chẳng hạn như thực hiện thay đổi qua một cơ sở mã lớn cho đến khi các bài kiểm tra vượt qua. Trong thử nghiệm của Anthropic, ở mức nỗ lực trung bình mặc định, mô hình đã ngang bằng hoặc vượt qua Claude Opus 5 ở mức nỗ lực cao trong các tác vụ như vậy, với ít bước hơn và ít token hơn. Nó cũng duy trì công việc tự chủ dài hạn tốt hơn Claude Opus 5, chẳng hạn như kiểm toán kéo dài nhiều giờ và di chuyển các cơ sở mã lớn được chạy từ đầu đến cuối với các tác nhân phụ song song và ít sự giám sát. Những người thử nghiệm sớm cũng báo cáo khả năng đánh giá mã tốt hơn, bắt được nhiều lỗi hơn so với Claude Opus 5 và ít báo động giả hơn, đồng thời nó giải thích các thay đổi của mình bằng ngôn ngữ đơn giản.
• Công việc tri thức: Mô hình ít có khả năng đưa ra số liệu không chính xác hoặc trích dẫn sai nguồn hơn nhiều. Nó tốt hơn trong các tác vụ mô hình tài chính, chẳng hạn như xây dựng mô hình tài chính và bản tóm tắt một trang cho một giao dịch hoặc tìm và sửa lỗi trong sổ làm việc định giá, và nó nắm bắt được các chi tiết dễ bị bỏ sót trong các đầu vào lớn, chẳng hạn như một ngày trong chuỗi lập kế hoạch dài rơi vào ngày trong tuần không chính xác hoặc một biểu đồ trong slide không khớp với các số liệu cơ bản. Các bảng tính, slide và tài liệu mà nó tạo ra cần ít chỉnh sửa hơn trước khi bạn chia sẻ chúng.
• Giao tiếp: Các báo cáo của nó về công việc tác nhân, cả các cập nhật trong khi làm việc và bản tóm tắt khi hoàn thành, đều nói rõ ràng những gì nó đã làm, những gì nó tìm thấy và những gì nó cần từ bạn. Xem Cập nhật tiến độ hướng tới người dùng.
• Biểu đồ, sơ đồ, ảnh chụp màn hình và sử dụng máy tính: Mô hình đọc tài liệu hình ảnh chính xác hơn Claude Opus 5 mà không cần công cụ bổ sung: trong thử nghiệm của Anthropic, ngay cả ở mức nỗ lực thấp nhất, nó đã đọc các giá trị từ các biểu đồ dày đặc chính xác hơn Claude Opus 5 ở mức cao nhất, sử dụng một phần nhỏ token đầu ra. Nó cũng tốt hơn ở những nơi ý nghĩa phụ thuộc vào vị trí thay vì văn bản: các ô nào được kết nối bởi một mũi tên trong lưu đồ, những gì đã thay đổi giữa hai phiên bản của sơ đồ, hoặc chính xác khi nào một cuộc họp bắt đầu và kết thúc trong ảnh chụp màn hình lịch. Nó cũng đáng tin cậy hơn trong việc sử dụng máy tính, nơi nó vận hành các ứng dụng từ ảnh chụp màn hình qua nhiều bước: ở mức nỗ lực mặc định, nó đã đạt được tỷ lệ thành công mà Claude Opus 5 chỉ đạt được ở mức nỗ lực cao hơn nhiều. Xem Công cụ cho đầu vào hình ảnh phức tạp.

Hiệu chỉnh nỗ lực

Nỗ lực là quyền kiểm soát chính đối với mức độ suy nghĩ của Claude Opus 5.5, và vì tư duy luôn được bật, đây là cài đặt đầu tiên cần điều chỉnh khi cân nhắc giữa trí thông minh, độ trễ và chi phí. Hãy bắt đầu ở mức trung bình, mặc định trên Claude Opus 5.5 (Claude Opus 5 mặc định là cao), đặt nó một cách rõ ràng và kiểm tra nhiều mức độ dựa trên các đánh giá của riêng bạn thay vì áp dụng cài đặt bạn đã sử dụng trên Claude Opus 5. Tên mức nỗ lực không tương ứng với cùng một lượng tư duy trên các mô hình: trong thử nghiệm của Anthropic, Claude Opus 5.5 ở mức trung bình ngang bằng hoặc vượt qua Claude Opus 5 ở mức cao trong các đánh giá về lập trình và công việc tri thức, và trong một số đánh giá lập trình, mức thấp cũng gần đạt được kết quả tương tự với chi phí thấp hơn nhiều. Xem Các mức nỗ lực được khuyến nghị cho Claude Opus 5.5.

Ở một mức nhất định, Claude Opus 5.5 có xu hướng suy nghĩ nhiều hơn mỗi lượt so với Claude Opus 5, đặc biệt là ở mức xhigh và max. Nếu bạn giữ giá trị nỗ lực đã đặt cho Claude Opus 5, hãy dự đoán các lượt chạy dài hơn và nhiều token đầu ra hơn. Ba điều chỉnh sẽ hữu ích:

• Đặt max_tokens đủ cao để chừa chỗ cho các token tư duy của mô hình và phản hồi. Tư duy được tính vào max_tokens ngay cả khi nội dung tư duy không được trả về cho bạn, vì vậy giới hạn được đặt cho Claude Opus 5 khi tắt tư duy có thể làm cắt đứt các phản hồi. Đối với các lượt chạy dài mà lập trình tác nhân có thể tạo ra, max_tokens là 128.000, mức tối đa của mô hình, đã hoạt động tốt trong thử nghiệm của Anthropic.
• Dành riêng xhigh và max cho công việc mà bạn đã đo lường được sự cải thiện về chất lượng.
• Để có ít tư duy hơn, trước tiên hãy giảm mức nỗ lực. Giảm nỗ lực làm giảm tư duy, và cùng với đó là chi phí và độ trễ, đáng tin cậy hơn so với các hướng dẫn trong prompt.

Thay đổi giá trị nỗ lực cấp cao nhất giữa các yêu cầu sẽ làm mất hiệu lực bộ nhớ đệm prompt (prompt cache). Để chạy các lượt riêng lẻ ở một mức khác, hãy sử dụng thay đổi nỗ lực mỗi tin nhắn (beta) thay thế, giúp giữ nguyên bộ nhớ đệm.

Các prompt được viết cho chế độ tắt tư duy

Claude Opus 5 chấp nhận thinking: {"type": "disabled"} ở mức nỗ lực cao hoặc thấp hơn; Claude Opus 5.5 thì không, và hướng dẫn di chuyển bao gồm thay đổi yêu cầu này. Nếu tích hợp Claude Opus 5 của bạn đã chạy với tính năng tư duy bị tắt, bốn thay đổi sẽ đi kèm với nó:

• Bắt đầu ở mức nỗ lực thấp và đo lường. Ở mức thấp, mô hình giữ cho tư duy của nó ngắn gọn. Tần suất nó bỏ qua tư duy hoàn toàn phụ thuộc vào các prompt của bạn, vì vậy hãy đo lường độ trễ và chất lượng trên lưu lượng truy cập của riêng bạn và chuyển sang mức trung bình nếu chất lượng giảm. Nếu thời gian đến token đầu tiên vẫn quan trọng sau đó, một dòng system prompt như "Answer directly without deliberating." có thể giảm tư duy hơn nữa; hãy đo lường chất lượng khi bạn thêm nó, vì ít tư duy hơn có thể làm giảm chất lượng.
• Loại bỏ các hướng dẫn thay thế cho tư duy. Nếu prompt của bạn yêu cầu mô hình viết ra lập luận trong phản hồi để thay thế cho việc tư duy, hãy xóa hướng dẫn đó và đọc lập luận từ các khối tư duy tóm tắt (thiết lập hiển thị: "summarized"); một prompt thúc ép mô hình tái hiện lập luận trong văn bản phản hồi có thể bị từ chối với danh mục từ chối reasoning_extraction.
• Kiểm tra lại các biện pháp giảm thiểu khi tắt tính năng tư duy. Chạy với tính năng tư duy bị tắt khuyến nghị một hướng dẫn kết hợp (cho phép phản hồi trước khi gọi công cụ, cách xử lý khi không có công cụ phù hợp, không sử dụng thẻ nội bộ) và loại bỏ bất kỳ quy tắc nào yêu cầu mô hình không được tư duy. Cả hai đều giải quyết các lỗi hiển thị trên Claude Opus 5 chỉ khi tính năng tư duy bị tắt. Khi tính năng tư duy luôn bật, hãy kiểm tra xem bạn có còn cần hướng dẫn đó không và xóa quy tắc không-tư-duy trong mọi trường hợp.
• Đọc phản hồi theo loại khối. Kiểm tra loại của từng khối thay vì mặc định khối nội dung đầu tiên là văn bản: một phản hồi có thể bắt đầu hoặc không bắt đầu bằng khối tư duy, với trường tư duy trống ở chế độ hiển thị mặc định: "omitted".

Các tác vụ đại diện (agentic) không có sự giám sát

Đối với các tác vụ dài gồm nhiều phần, Claude Opus 5.5 cập nhật cho người dùng khi nó làm việc, và một số cập nhật kết thúc lượt bằng văn bản thay vì gọi công cụ (stop_reason: "end_turn"). Một vòng lặp đại diện không có sự giám sát nếu coi lượt đó là kết thúc tác vụ sẽ dừng lại tại đó. Một vài thay đổi về harness và prompt sẽ giúp nó tiếp tục chạy.

Hãy coi việc kết thúc lượt chỉ bằng văn bản là một báo cáo thay vì bằng chứng cho thấy tác vụ đã hoàn thành. Giữ các phần của tác vụ trong một danh sách kiểm tra mà mô hình cập nhật, chẳng hạn như công cụ to-do hoặc tệp tin. Nếu một lượt kết thúc với các mục vẫn còn mở và không có rào cản nào được nêu, hãy gửi một tin nhắn ngắn cho người dùng liệt kê chúng, như ví dụ sau. Bạn cũng có thể nêu trước điều kiện hoàn thành và để một mô hình nhỏ hơn kiểm tra cuộc hội thoại dựa trên điều kiện đó ở mỗi cuối lượt, trả về lý do của nó dưới dạng tin nhắn người dùng tiếp theo khi điều kiện không được đáp ứng. Dù thế nào, hãy dừng lại sau hai hoặc ba lần tự động tiếp tục trên cùng một tác vụ thay vì lặp lại vô thời hạn, để một tiến trình thực sự bị kẹt có thể kết thúc và được xem xét lại.

Nếu một tiến trình mà mô hình đã bắt đầu vẫn đang chạy, chẳng hạn như lệnh nền hoặc subagent, đừng coi tác vụ đã hoàn thành: hãy đợi nó kết thúc và trả kết quả về cho mô hình dưới dạng tin nhắn người dùng tiếp theo.

Việc bổ sung system prompt cũng có thể làm giảm tần suất dừng sớm này. Claude Opus 5.5 phản hồi tốt với các hướng dẫn nêu rõ loại dừng sớm mà bạn muốn tránh, chẳng hạn như kết thúc lượt bằng một bản tóm tắt thông báo bước tiếp theo thay vì thực hiện nó. Việc nêu rõ các điểm dừng bạn mong muốn cũng hữu ích, ví dụ như khi không có công việc nào có thể tiến triển nếu thiếu đầu vào từ người dùng.

Đoạn văn sau là một ví dụ về phần bổ sung như vậy, được viết cho các tác nhân chạy hoàn toàn không có sự giám sát, nơi bạn muốn mô hình tiếp tục làm việc thay vì dừng lại để báo cáo. Hãy coi đây là điểm khởi đầu: bạn có thể cần điều chỉnh nó cho ứng dụng của riêng mình. Thêm nó vào cuối system prompt từ yêu cầu đầu tiên của phiên: việc thêm vào giữa chừng sẽ thay đổi system prompt và làm mất hiệu lực các khối tư duy trước đó của cuộc hội thoại (xem Tư duy được bảo toàn). Vì nó yêu cầu mô hình đặt các ghi chú trạng thái vào cùng một tin nhắn với lệnh gọi công cụ tiếp theo, các ghi chú đó sẽ xuất hiện giữa các lệnh gọi công cụ dưới dạng cập nhật tiến độ, với văn bản trả về trống ở chế độ hiển thị tư duy mặc định; hãy đặt hiển thị: "updates" để nhận bản tóm tắt của từng ghi chú (xem Cập nhật tiến độ hướng tới người dùng). Với phần bổ sung này, mô hình sẽ tiếp tục ở nơi mà lẽ ra nó đã dừng lại để kiểm tra, vì vậy hãy giữ bước xác nhận của riêng bạn cho các hành động rủi ro hoặc không thể đảo ngược, và bỏ phần bổ sung này trong các ứng dụng có sự tham gia của con người (human-in-the-loop), nơi có người sẵn sàng phản hồi. Hãy dự kiến số lượng lệnh gọi công cụ và token đầu ra mỗi tác vụ sẽ nhiều hơn một chút.

Từ chối bảo mật

Claude Opus 5.5 chạy các bộ phân loại an toàn, bao gồm cả về sinh học, an ninh mạng và trích xuất lập luận.

• Sinh học: Các biện pháp bảo vệ sinh học giống như của Claude Fable 5.1 và là tính năng mới nếu bạn chuyển từ Claude Opus 5. Các câu hỏi về sức khỏe và giáo dục hàng ngày không bị ảnh hưởng. Nếu bộ phân loại sinh học gây cản trở công việc khoa học sự sống của tổ chức bạn, hãy đăng ký Chương trình Xác minh Khoa học Sự sống.
• An ninh mạng: Việc tìm kiếm lỗ hổng trong mã nguồn được cho phép. Các hoạt động an ninh mạng lưỡng dụng rủi ro cao thì không.
• Trích xuất lập luận: Các yêu cầu thúc ép mô hình tái hiện lập luận nội bộ trong văn bản phản hồi có thể bị từ chối với danh mục reasoning_extraction, đây là tính năng mới nếu bạn chuyển từ Claude Opus 5. Nếu prompt của bạn yêu cầu mô hình viết ra lập luận trong phản hồi, hãy xóa các hướng dẫn đó, đặt hiển thị: "summarized" và đọc lập luận tóm tắt từ các khối tư duy thay thế; xem Prompt được viết cho chế độ tắt tư duy.

Một từ chối từ bộ phân loại sẽ đến dưới dạng phản hồi bình thường với stop_reason: "refusal" và đối tượng stop_details nêu tên danh mục. Bạn có thể yêu cầu thử lại tự động trên một mô hình dự phòng, ngoại trừ các từ chối reasoning_extraction, vốn sẽ được phía máy chủ trả về cho bạn thay vì thử lại; xem Từ chối và dự phòng.

Cập nhật tiến độ hướng tới người dùng

Giữa các lệnh gọi công cụ, Claude Opus 5.5 viết các cập nhật tiến độ ngắn cho người dùng: những gì nó vừa tìm thấy và những gì nó sẽ làm tiếp theo. Bốn đòn bẩy kiểm soát những gì người dùng của bạn thấy.

Đầu tiên, kiểm tra xem client của bạn có nhận được chúng không: trên Claude Opus 5.5, các ghi chú này trả về dưới dạng khối tư duy cập nhật tiến độ thay vì khối văn bản, và văn bản của chúng trống ở chế độ hiển thị tư duy mặc định, vì vậy một client chỉ hiển thị các khối văn bản có thể trông như bị im lặng trong một lượt đại diện dài. Đặt hiển thị: "updates" (beta, header thinking-display-updates-2026-08-18) để nhận bản tóm tắt ngắn của từng ghi chú; hướng dẫn di chuyển chỉ cách hiển thị chúng.

Thứ hai, nếu mô hình có thể cần cung cấp cho người dùng nội dung nguyên văn giữa một lượt dài, chẳng hạn như đoạn mã, hãy cung cấp cho nó một công cụ đơn giản để gửi tin nhắn cho người dùng và yêu cầu nó dành riêng công cụ đó cho nội dung đó. Khai báo công cụ trong tools từ yêu cầu đầu tiên của phiên: việc thêm nó vào tools sau đó sẽ chỉnh sửa tiền tố của cuộc hội thoại và làm mất hiệu lực các khối tư duy trước đó (xem Tư duy được bảo toàn).

Thứ ba, nếu bạn muốn các cập nhật thường xuyên hoặc có thể dự đoán được hơn, chẳng hạn như một câu tuyên bố ý định trước lệnh gọi công cụ đầu tiên và một bản tóm tắt ngắn ở cuối, hãy nêu rõ trong system prompt; mô hình phản hồi tốt với các hướng dẫn như vậy. Điều này hữu ích nhất trong công việc có sự tham gia của con người.

Thứ tư, nếu các lượt gọi công cụ (tool-calling) kéo dài vẫn im lặng lâu hơn mức bạn muốn, hãy để hệ thống của bạn yêu cầu cập nhật. Với thiết lập display: "updates" (đòn bẩy đầu tiên), hãy đếm các bước gọi công cụ liên tiếp không hiển thị nội dung gì cho người dùng: không có khối văn bản và không có văn bản cập nhật tiến độ. Sau vài lần liên tiếp (ví dụ: năm lần), hãy thêm một lời nhắc như sau vào sau kết quả công cụ mới nhất, dưới dạng một tin nhắn hệ thống theo phạm vi lượt (clear_at: "next_user_message"; tiêu đề beta, mid-conversation-system-clear-at-2026-08-21). Nếu lượt đó vẫn im lặng, hãy dừng lại sau hai hoặc ba lời nhắc thay vì gửi thêm. Vì mỗi lời nhắc được thêm vào và giữ nguyên tại chỗ, thay vì chèn vào cho một yêu cầu rồi xóa đi ở yêu cầu tiếp theo, bộ nhớ đệm prompt (prompt cache) sẽ tiếp tục khớp và các khối suy nghĩ (thinking blocks) theo sau nó vẫn giữ nguyên hiệu lực. Trong các thử nghiệm của Anthropic trên các tác vụ lập trình đại lý (agentic coding tasks), điều này đã giảm khoảng một nửa tỷ lệ các tác vụ có khoảng lặng dài mà không làm thay đổi chi phí một cách đáng kể.

Khám phá ngữ cảnh trong quy trình làm việc đa ứng dụng

Trong tự động hóa quy trình làm việc trên nhiều ứng dụng được kết nối, chẳng hạn như email, tài liệu, bảng tính và hồ sơ CRM, thông tin mà một tác vụ phụ thuộc vào thường nằm ở nơi mà yêu cầu không đề cập rõ ràng: ví dụ, một chính sách trong chuỗi email cũ, một quy tắc trên tab bảng tính khác hoặc một ghi chú trên hồ sơ khách hàng. Claude Opus 5.5 có xu hướng bắt tay vào việc nhanh chóng, và đối với các tác vụ được chỉ định lỏng lẻo, việc yêu cầu mô hình tìm kiếm qua các nguồn liên quan trước khi thực hiện sẽ rất hữu ích. Nếu đại lý của bạn hoạt động trên nhiều ứng dụng với các tác vụ như thế này, một câu trong system prompt sẽ khiến nó quan sát xung quanh trước khi thay đổi bất cứ điều gì:

Trong các thử nghiệm của Anthropic về các tác vụ tự động hóa đa ứng dụng, Claude Opus 5.5 đã hoàn thành chính xác nhiều tác vụ hơn đáng kể với hướng dẫn này, ở cả mức nỗ lực trung bình và tối đa, với cái giá phải trả là số lượng lệnh gọi công cụ và token tăng nhẹ. Vì nó yêu cầu mô hình hành động dựa trên những gì tìm thấy, hãy giữ nội dung không đáng tin cậy bên ngoài các hồ sơ mà nó tìm kiếm.

Tín hiệu thời gian cho các hệ thống đa đại lý (multiagent harnesses)

Claude Opus 5.5 chú ý kỹ đến thông tin về thời gian đã trôi qua, và trong thiết lập đa đại lý, ví dụ như một đại lý chính ủy quyền cho các đại lý phụ, bạn có thể sử dụng điều đó để tăng tốc công việc thông qua việc song song hóa tốt hơn. Nếu bạn có thể ước tính thời gian tác vụ sẽ mất, hãy cung cấp cho mô hình một ngân sách thời gian: yêu cầu hệ thống của bạn thêm một dòng ngắn ở cuối mỗi tin nhắn gửi lại cho mô hình, cung cấp thời gian đã trôi qua so với ngân sách đó, tính bằng giây, ví dụ: elapsed 340s / 1200s. Mô hình sẽ điều chỉnh tốc độ làm việc để hoàn thành trong ngân sách và thường hoàn thành sớm hơn nhiều, vì vậy hãy đặt ngân sách cao hơn một chút so với thời gian bạn thực sự muốn dành ra và tinh chỉnh nó trên mẫu các tác vụ của riêng bạn. Nếu bạn không thể dự đoán một ngân sách hợp lý, chỉ cần hiển thị thời gian đã trôi qua và thêm một câu vào system prompt:

Trong các đánh giá của Anthropic về các nhóm đại lý nhỏ thực hiện tác vụ nghiên cứu, cả hai tín hiệu đều giúp các nhóm hoàn thành sớm hơn so với một đại lý đơn lẻ làm việc mà không có chúng. Các nhóm được cấp ngân sách duy trì chất lượng câu trả lời tương đương với đại lý đơn lẻ trong khi hoàn thành sớm hơn đáng kể. Ngân sách chặt chẽ hơn có tác động khác với cài đặt nỗ lực thấp hơn: giảm nỗ lực làm giảm chính khối lượng công việc, trong khi ngân sách chủ yếu giữ cho nhiều đại lý làm việc song song hơn. Ngân sách chỉ mang tính chất tư vấn và không có gì ngăn cản mô hình tại giới hạn đó, vì vậy nếu bạn cần một điểm dừng cứng, hãy tự duy trì bộ đếm thời gian (timeout) của riêng bạn. Ngoài ra, hãy kiểm tra chất lượng câu trả lời trên các tác vụ của riêng bạn, vì dưới áp lực thời gian, mô hình có thể tìm kiếm và xác minh ít hơn một chút.

Hướng dẫn suy nghĩ trong system prompt của trò chuyện

Trong các ứng dụng trò chuyện, nếu system prompt của bạn chứa các hướng dẫn yêu cầu Claude suy nghĩ cẩn thận trước khi trả lời, hãy cân nhắc xóa chúng đối với Claude Opus 5.5. Mô hình tự quyết định mức độ suy nghĩ và nỗ lực là quyền kiểm soát chính. Trong thử nghiệm của Anthropic trên một sản phẩm trò chuyện, việc xóa dòng như vậy giúp các phản hồi bắt đầu sớm hơn mà không có sự suy giảm rõ rệt nào về chất lượng phản hồi.

Bài gốc còn tiếp — xem tiếp tại bài gốc ↗