Trong một nhóm sử dụng nhiều coding agent, một Task liên tục được chuyển giao qua lại. Một worker dùng Sonnet viết mã thay đổi, rồi một reviewer dùng Opus kiểm tra lại. Một Claude Code Agent bị nghẽn và Task được chuyển sang cho Codex Agent. Claude Sonnet 5.5, ra mắt vào ngày 28 tháng 9, đã chính thức xác nhận bằng văn bản một điều vốn luôn đúng một phần: lập luận của mô hình không hề đi kèm theo kết quả công việc. Trang những điểm mới trong Sonnet 5.5 của Anthropic nêu rõ rằng mỗi thinking block đều “ghi lại mô hình nào đã tạo ra nó”, và không có mô hình nào khác đọc được các block của Sonnet 5.5.
Vấn đề nằm ở chỗ mọi thứ diễn ra quá âm thầm. Khi một yêu cầu mang theo một block mà mô hình không thể đọc, API sẽ loại bỏ nó trước khi mô hình kịp nhìn thấy. Yêu cầu vẫn thành công, các block bị bỏ không bị tính phí, và dấu vết duy nhất còn lại là một mục input_transformations—chỉ xuất hiện nếu bạn có gửi header beta thinking-binding-controls-2026-08-01. Reviewer Agent nhận được bản diff mà không hề biết lý do đằng sau, không có bất kỳ lỗi nào xuất hiện, và kết quả review trông có vẻ được nắm bắt tường tận hơn thực tế rất nhiều.
TL;DR
Đối với ngữ cảnh chuyển giao giữa các mô hình agent, chỉ có một quy tắc cốt lõi: ngữ cảnh duy nhất còn tồn tại sau khi chuyển giao là những gì đã được ghi lại trực tiếp trên Task. Các thinking block bị ràng buộc chặt chẽ với mô hình đã tạo ra chúng, với chính xác cuộc hội thoại đó, và riêng đối với Sonnet 5.5 là ràng buộc với cả tài khoản. Hãy yêu cầu mọi Agent kết thúc lượt chạy của mình bằng một bình luận chuyển giao: các quyết định kèm lý do, các giả định, những cách đã thử nhưng thất bại, các câu hỏi mở còn tồn đọng, các tệp đã chỉnh sửa, và những lượt kiểm tra đã chạy. Nếu bạn tự xây dựng harness cho riêng mình, hãy giữ lịch sử ở chế độ chỉ nối thêm (append-only).
Thinking block bị ràng buộc theo ba cách
Thinking block là phần lập luận mà mô hình tạo ra trong một lượt phản hồi, được trả về kèm theo chữ ký số mà API sẽ kiểm tra trước khi một yêu cầu sau có thể sử dụng lại. Tài liệu về preserved thinking mô tả ba loại ràng buộc, và mỗi loại đều tương ứng với một hình thức bàn giao mà nhóm của bạn vốn dĩ đã thực hiện.
Mô hình. Sonnet 5.5 đọc được các block từ Sonnet 5, Opus 4.8, Haiku 4.5 và các mô hình cũ hơn, nhưng không đọc được từ Opus 5, Opus 5.5, Fable hay Mythos. Chiều chuyển giao đóng vai trò quyết định: theo ghi chú của Anthropic về việc đổi mô hình giữa cuộc hội thoại, một cuộc trò chuyện chuyển từ Sonnet 5 sang Sonnet 5.5 sẽ giữ lại được lập luận, còn cuộc trò chuyện chuyển từ Sonnet 5.5 sang bất kỳ mô hình nào khác sẽ chạy các lượt tiếp theo mà không có phần lập luận đó. Điều này áp dụng cho cả cơ chế fallback phía server của chính Anthropic, vốn sẽ thử lại một số yêu cầu Sonnet 5.5 bị từ chối bằng Sonnet 5.
Cuộc hội thoại. Một block chỉ có thể sử dụng được khi nó tuân theo chính xác system prompt, các công cụ và các tin nhắn đã tạo ra nó. Phần FAQ của tài liệu nêu rõ hệ quả: lập luận không thể mang sang một cuộc hội thoại khác, vì vậy hãy bắt đầu cuộc hội thoại mới từ bản tóm tắt trạng thái của nhiệm vụ (mục tiêu, các quyết định đã đưa ra, các tệp và kết quả cho đến hiện tại, bước tiếp theo). Khi một Task được chuyển sang một Agent khác, Runtime sẽ khởi tạo một phiên mới—đồng nghĩa với một cuộc hội thoại mới ngay cả khi dùng chung mô hình. Đây cũng chính là lý do một phiên làm việc mới của một công cụ luôn khởi đầu từ con số không, như đã được đề cập trong bài viết về duy trì ngữ cảnh giữa các phiên AI.
Tài khoản. Các block của Sonnet 5.5 chỉ hoạt động trong tài khoản đã tạo ra chúng hoặc một tài khoản được liên kết với nó. Bài viết công bố ra mắt của Anthropic chỉ ra một trường hợp cụ thể: chuyển đổi tài khoản giữa chừng trong một phiên làm việc của Claude Code.
Tóm lại: giữa các Agent, lập luận chưa bao giờ được chuyển tiếp thành công. Sonnet 5.5 chỉ chính thức biến điều đó thành một điều khoản trong hợp đồng API.
Ba trường hợp bàn giao âm thầm làm mất lập luận
| Trường hợp bàn giao | Những gì được giữ lại | Những gì bị mất | Dấu hiệu nhận biết |
|---|---|---|---|
| Worker Agent Sonnet 5.5 chuyển giao cho reviewer Agent Opus 5.5 | Bản diff, kho lưu trữ, mô tả Task và các bình luận | Phần thinking của Sonnet 5.5. Không có mô hình nào khác đọc được nó, và đằng nào thì lượt review cũng là một phiên làm việc mới | Không có dấu hiệu gì giữa các Agent. Trong cùng một cuộc hội thoại API, xuất hiện mục model_binding_mismatch nếu có header beta |
| Claude Code Agent chuyển giao cho Codex Agent | Bản diff, nhánh (branch), bản ghi Task, tệp quy tắc chung của repo | Toàn bộ thinking của Claude và trạng thái phiên làm việc của Claude Code. Codex bắt đầu cuộc hội thoại riêng của nó | Không có gì cả |
| Cùng mô hình, khác tài khoản (đổi tài khoản giữa phiên trong Claude Code, hoặc chạy lại phiên đã lưu bằng thông tin xác thực của tài khoản khác) | Bản ghi có thể nhìn thấy: tin nhắn, lệnh gọi công cụ, kết quả | Mọi thinking block của Sonnet 5.5 được tạo ra dưới tài khoản đầu tiên | Xuất hiện mục organization_binding_mismatch nếu có header beta, trên Claude API và Google Cloud. Ngoài ra không có dấu hiệu nào khác |
Cột cuối cùng chính là nguồn cơn của vấn đề. Cả ba trường hợp bàn giao đều thực hiện thành công, và Agent tiếp nhận vẫn tự tin đưa ra câu trả lời dựa trên lượng thông tin ít ỏi hơn những gì Agent trước đó từng biết. Một reviewer chạy trên mô hình khác có thể phê duyệt một thay đổi mà worker từng hoài nghi, chỉ vì những hoài nghi đó nằm trong phần thinking mà reviewer chưa từng được thấy.
Trước đây, chúng tôi từng viết rằng việc chuyển đổi giữa các coding agent “giữ lại mã nguồn nhưng đánh mất lập luận.” Giờ đây điều đó cũng áp dụng ở cấp độ API, một chi tiết rất quan trọng đối với các nhóm chạy song song Claude Code và Codex trên cùng một codebase và cho các quy tắc điều phối nâng cấp. Nếu các Task phức tạp được chuyển từ worker Sonnet 5.5 lên Opus 5.5, như trong bài Sonnet 5.5 hay Opus 5.5: agent nào sẽ nhận task, thì mỗi lần nâng cấp đều là một ca bàn giao thuộc hàng đầu tiên trong bảng.
Ghi chú bàn giao cần truyền tải những gì khi lập luận không thể chuyển tiếp
Ghi chú bàn giao của coding agent chỉ có duy nhất một nhiệm vụ: diễn đạt lại bằng văn bản những lập luận quan trọng để worker tiếp theo có thể đọc được. Các trường thông tin dưới đây mở rộng cấu trúc tóm tắt của Anthropic với hai điều mà thinking block từng nắm giữ nhưng bản diff không bao giờ thể hiện: lý do vì sao một hướng đi được lựa chọn, và những hướng đi nào đã bị loại trừ trước đó. Hãy dán phần này vào phần chỉ dẫn của mọi Agent có khả năng chuyển giao Task:
Before you finish, post one comment on the Task that starts with "Handoff".
Write it for a reader who has this Task and the diff, and nothing else.
Decisions: each choice you made and the reason for it, one line each
Assumptions: what you took as true without verifying it
Tried, failed: approaches you ruled out and why, so nobody retries them
Open questions: what a person or the next Agent has to decide
Files touched: paths changed, and which ones are unfinished
Checks run: exact commands and their results; name any check you skipped
Next step: the one action you would take next
Ba chi tiết giúp bản ghi chú này luôn phản ánh đúng thực tế.
Yêu cầu đưa ra quyết định, chứ không phải bản thân quá trình suy luận. Sonnet 5.5 là phiên bản Sonnet đầu tiên được trang bị bộ phân loại an toàn chống trích xuất suy luận, và danh mục từ chối reasoning_extraction của mô hình sẽ áp dụng cho các yêu cầu tái hiện lại chuỗi suy luận nội bộ trong văn bản phản hồi. Yêu cầu kiểu “Hãy dán phần thinking của bạn vào bình luận” chính là loại yêu cầu đó. Trong khi đó, “Hãy liệt kê từng quyết định kèm lý do của nó” lại là một báo cáo thông thường.
Mục “Tried, failed” tiết kiệm thời gian nhất. Một ngõ cụt hoàn toàn vô hình trong bản diff. Nếu không có ghi chú này, Agent tiếp theo rất dễ đi lại đúng vào vết xe đổ đó.
Kiểm tra phải đi kèm lệnh và kết quả đầu ra. Câu nói “Các bài test đều vượt qua” chỉ là một lời khẳng định suông. Câu lệnh đã chạy cùng số liệu cụ thể mới là bằng chứng xác thực mà reviewer có thể chạy lại để đối chứng.
Hai tình huống cần cân nhắc: có thể bỏ qua ghi chú khi một Agent đảm nhận Task từ lúc phân công đến lúc review chỉ trong một lượt chạy duy nhất và người nghiệm thu đằng nào cũng sẽ đọc bản diff. Bắt buộc phải có ghi chú ngay khi Task thay đổi Assignee, thay đổi mô hình, hoặc được chuyển cho một reviewer Agent. Các mẫu bàn giao coding agent giải quyết điểm tiếp giáp giữa người và Agent; còn ghi chú này xử lý điểm tiếp giáp giữa hai Agent với nhau.
Nếu bạn tự xây dựng harness, việc chỉnh sửa lịch sử giờ đây sẽ bị báo lỗi
Hầu hết độc giả có thể bỏ qua phần này. Tài liệu preserved thinking cho biết sẽ không có gì thay đổi nếu Claude Code, claude.ai, Claude Managed Agents hoặc Claude Agent SDK trực tiếp khởi tạo các request cho bạn. Điều này chỉ quan trọng khi bạn tự viết mã để gọi Messages API.
Đối với các tài khoản được tạo vào hoặc sau 00:00 UTC ngày 31 tháng 8 năm 2026 trên Claude API, Amazon Bedrock và Google Cloud, việc gửi lại một thinking block của Sonnet 5.5 sau khi có bất kỳ thay đổi nào phía trước nó (system prompt, công cụ, hoặc một tin nhắn trước đó) sẽ trả về mã lỗi 400. Các tài khoản cũ hơn chỉ gặp phải cơ chế kiểm tra này nếu request chủ động kích hoạt, điều này tạo ra một cái bẫy: API key của chính bạn thì hoạt động bình thường, nhưng người dùng chạy công cụ của bạn với API key của tài khoản mới hơn lại dính lỗi 400 ngay. Cách khắc phục: hãy duy trì cuộc hội thoại ở chế độ chỉ nối thêm (append-only).
- Cố định system prompt và các công cụ ngay từ khi bắt đầu phiên. Thay đổi chỉ dẫn bằng cách nối thêm một tin nhắn system ở giữa cuộc trò chuyện—điều mà Sonnet 5.5 hỗ trợ còn Sonnet 5 thì không.
- Gửi lại từng lượt phản hồi của assistant chính xác như lúc nhận về, bao gồm cả các thinking block trống.
- Thu gọn ngữ cảnh thông qua API thay vì viết lại các lượt cũ. Tính năng thu gọn theo yêu cầu (beta
compact-2026-09-04) sẽ trả về một summary block có chữ ký số để bạn gửi thay cho các tin nhắn nằm trong phạm vi thu gọn. Phương pháp thu gọn đơn giản được tài liệu khuyến nghị là gửi một tin nhắn tóm tắt kèm theo chỉ thị tiếp theo, nhờ đó không có thinking cũ nào bị replay lại.
{ "role": "system", "content": "Review found a race in the retry path. Do not change the public API." }
Khi có header beta, thiết lập prefix_mismatch_behavior: "drop_block" sẽ loại bỏ các block không khớp thay vì trả về lỗi. Tài liệu nói rất rõ rằng tùy chọn này chỉ che giấu việc chỉnh sửa chứ không hề giải quyết được tận gốc vấn đề.
Hãy chú ý đến hình thức thu gọn mà Anthropic khuyến nghị. Khi chuỗi lập luận không thể phát lại, câu trả lời của Anthropic là một bản tóm tắt bằng văn bản: thực chất chính là một ghi chú bàn giao dưới một tên gọi khác.
Cơ chế bàn giao nằm ở đâu trong Sharkly
Task đóng vai trò là bản ghi chia sẻ chung, và việc bàn giao phải nằm ngay trên đó vì không có thứ gì khác tồn tại lâu hơn một phiên làm việc. Một Task lưu trữ Conversation (đối thoại thông qua bình luận), dòng thời gian Activity ghi lại các bình luận cùng thay đổi, và lịch sử Executions của từng lượt chạy. Nội dung của Agent gửi đến nhóm được lưu dưới dạng một bình luận liên kết với lượt chạy đó. Khi một Agent cần câu trả lời, câu hỏi sẽ được gửi lại Task dưới dạng bình luận, trạng thái Task sẽ hiển thị đang chờ phản hồi từ con người, và câu hỏi sẽ được chuyển đến Inbox của người đó.
Việc tái phân công chính là lúc cơ chế này phát huy tối đa giá trị. Khi chuyển Assignee từ một Agent Sonnet 5.5 sang reviewer Opus 5.5 hoặc sang một Agent Codex, lượt chạy tiếp theo sẽ bắt đầu từ chính Task chứ không phải từ một bản ghi cuộc hội thoại. Tài liệu của Sharkly liệt kê những gì một lượt chạy dựa trên Task có thể tiếp nhận: tiêu đề và mô tả, các bình luận gần đây và bình luận đã kích hoạt lượt chạy, chỉ dẫn của Agent, cùng các kho lưu trữ của nó. Bình luận bàn giao nằm trong danh sách đó. Còn phần thinking của Agent trước đó thì không, và nếu đổi mô hình thì API đằng nào cũng sẽ loại bỏ nó.
Từ đó hình thành nên hai thói quen làm việc. Tài liệu hướng dẫn ghi lại các kết luận mà toàn nhóm cần thấy vào phần bình luận hoặc phần mô tả Task, do đó bất kỳ điều gì đã được thống nhất trong cuộc trò chuyện riêng với một Agent đều cần đưa vào đó trước khi Task được chuyển tiếp. Và vì mỗi lượt chạy sẽ lấy vào các bình luận gần nhất, hãy đưa những quyết định có hiệu lực xuyên suốt toàn bộ Task vào ngay trong phần mô tả.
Đây chính là nơi tính độc lập với nhà cung cấp chứng minh giá trị của mình. Agent sẽ tuân theo mô hình mặc định của Runtime, vì vậy quy tắc bàn giao nằm ngay trong phần chỉ dẫn của Agent và hoạt động tương tự cho dù Runtime tiếp theo là Claude Code trên Sonnet 5.5 hay Codex trên một nền tảng nào khác. Hướng dẫn thiết lập có tại bài viết cách chạy các Claude Sonnet 5.5 agent trong Sharkly. Agent nghiên cứu, thực thi, kiểm thử và báo cáo. Con người định hướng, phân quyền và nghiệm thu kết quả dựa trên cùng một bản ghi bằng văn bản mà Agent tiếp theo sẽ đọc—đó cũng chính là nền tảng cốt lõi của quyền làm chủ của con người đối với công việc của agent.
Preserved thinking bắt đầu từ Fable 5.1 và hiện đã áp dụng cho Opus 5.5 cùng Sonnet 5.5. Hãy xây dựng các quy trình bàn giao không bao giờ phụ thuộc vào việc chuyển giao chuỗi suy luận, khi đó việc đổi mô hình trong tương lai sẽ không làm gián đoạn hệ thống của bạn. Nếu nhóm của bạn đã và đang vận hành nhiều agent, Sharkly cung cấp một không gian tập trung duy nhất để quản lý toàn bộ nhiệm vụ và kết quả của chúng.
