1.7 Session State and Resumption

Những gì cần nắm

Quản lý session quyết định cách agent giữ mạch công việc qua nhiều phiên làm việc. Với tác vụ chạy dài — debug một hệ thống phức tạp, review một codebase lớn, nghiên cứu kéo dài nhiều ngày — context của agent tích tụ tool result, các phân tích file và chuỗi suy luận. Task Statement 1.7 nói về cách quản lý đống state tích tụ đó: khi nào đi tiếp, khi nào rẽ nhánh, và khi nào làm lại từ đầu.

Ba lựa chọn quản lý session

Agent SDK và Claude Code cho bạn ba cách quản lý session. Mỗi cách làm một việc khác nhau, và đề thi muốn bạn chọn đúng cái hợp với tình huống trước mặt.

Lựa chọn 1: --resume <session-name>

Resume tiếp tục một session đã đặt tên, từ đúng chỗ đã dừng. Toàn bộ lịch sử hội thoại — gồm mọi tool result, phân tích và suy luận — được khôi phục.

Khi nào dùng: context cũ phần lớn vẫn còn đúng. File chưa thay đổi đáng kể kể từ phiên trước. Bạn muốn làm tiếp đúng chỗ đã dừng.

Khi nào KHÔNG dùng: file đã bị sửa kể từ phiên trước. Tool result trong lịch sử hội thoại không còn phản ánh trạng thái hiện tại của codebase. Đây chính là đường dẫn tới vấn đề stale context (nói ở dưới).

Lựa chọn 2: fork_session

Fork tạo một nhánh độc lập từ một nền phân tích chung. Sau khi fork, mỗi nhánh chạy độc lập — thay đổi ở nhánh này không ảnh hưởng nhánh kia, và các nhánh không thấy kết quả của nhau.

Trong SDK, bạn đặt nó cạnh resume chứ không phải thay cho resume: resume chọn session, còn fork_session: true mở một session mới từ bản sao lịch sử đó thay vì nối thêm vào nó. CLI ghép --fork-session với --resume theo đúng cách đó. (Agent SDK sessions guide, kiểm tra tháng 9/2026. Bài 1.3 có ghi chú đầy đủ.)

Khi nào dùng: bạn đã làm xong phần phân tích ban đầu và muốn thử các hướng khác nhau từ cùng điểm xuất phát đó. Ví dụ, sau khi phân tích codebase, bạn fork ra để so sánh hai chiến lược refactor. Mỗi fork dựa trên cùng một nền hiểu biết ban đầu nhưng đi theo hướng khác.

Khi nào KHÔNG dùng: bạn chỉ muốn đi tiếp cùng một mạch. Fork dành cho phân kỳ, không phải cho đi tiếp. Nếu bạn không so sánh phương án thay thế thì dùng resume.

Lựa chọn 3: mở session mới kèm summary injection

Mở hẳn một session mới nhưng tiêm vào context ban đầu một bản tóm tắt có cấu trúc về những gì phiên trước tìm được. Session mới không có tool result cũ nào — chỉ có bản tóm tắt bạn tự chọn lọc.

Khi nào dùng: tool result từ phiên trước đã cũ (file đã đổi, API đã cập nhật, dependency đã dịch chuyển). Context đã xuống cấp sau một phiên dài (quá nhiều tool result không liên quan làm rác lịch sử). Bạn cần một nền sạch nhưng vẫn giữ được kiến thức.

Khi nào KHÔNG dùng: context cũ vẫn còn đúng và bạn muốn giữ nguyên toàn bộ lịch sử hội thoại. Trường hợp này resume hiệu quả hơn.

Vấn đề stale context

Stale context là khái niệm trung tâm của task statement này. Nó xảy ra khi agent resume một session sau khi code đã bị sửa, rồi suy luận dựa trên tool result đã cache mà không còn phản ánh trạng thái hiện tại của file.

Biểu hiện: một developer dùng Claude Code phân tích codebase. Họ sửa 3 file rồi resume session. Claude đưa lời khuyên mâu thuẫn về các file đó — đề xuất những thay đổi đã làm rồi, hoặc nhắc tới đoạn code không còn tồn tại — vì nó đang suy luận trên tool result cũ vẫn nằm trong lịch sử hội thoại.

Vì sao xảy ra: khi resume một session, toàn bộ lịch sử hội thoại được khôi phục, gồm mọi tool result từ phiên trước. Nếu một file đã được đọc trong phiên trước và sau đó bị sửa thì nội dung file cũ vẫn nằm trong hội thoại dưới dạng tool result. Model suy luận trên dữ liệu cũ đó song song với dữ liệu mới, dẫn tới mâu thuẫn.

Cách sửa ngây thơ (và vì sao chưa đủ): cứ resume session rồi bảo agent đọc lại các file đã sửa. Cách này tốt hơn không làm gì, nhưng tool result cũ vẫn nằm trong lịch sử hội thoại. Model vẫn có thể tham chiếu thông tin cũ ở đoạn trước của context, nhất là với những quyết định tiếp tuyến không dính trực tiếp tới file đã sửa.

Cách sửa đúng: mở session mới kèm một bản tóm tắt có cấu trúc về kết quả trước đó. Nêu rõ file nào đã thay đổi để agent phân tích lại đúng những file đó. Session mới không có tool result cũ, còn bản tóm tắt được tiêm vào giữ lại kiến thức từ phiên trước mà không kéo theo dữ liệu lỗi thời.

Phân tích lại có trọng điểm so với khảo sát lại toàn bộ

Khi file thay đổi, agent không cần phân tích lại cả codebase. Làm vậy là phí. Đọc lại 50 file chỉ vì 3 file đổi là thời gian không lấy lại được.

Cách đúng là phân tích lại có trọng điểm: báo cho agent biết cụ thể file nào đã đổi và để nó phân tích lại đúng những file đó. Bản tóm tắt từ phiên trước lo phần không thay đổi.

Phân tích lại có trọng điểm trong thực tế trông thế nào:

Mở một session mới.
Tiêm vào một bản tóm tắt có cấu trúc: “Phân tích trước đã tìm ra X, Y, Z trên toàn codebase. Ba file sau đã bị sửa kể từ đó: auth.ts, database.ts, api-routes.ts.”
Agent đọc lại và phân tích lại đúng 3 file đã sửa.
Nó kết hợp phân tích mới của các file đã đổi với bản tóm tắt được giữ lại cho các file không đổi.

Cách này nhanh hơn khảo sát lại toàn bộ và đáng tin hơn việc resume với stale context.

Ma trận quyết định: dùng cái nào khi nào

Tình huống	Lựa chọn tốt nhất	Lý do
Làm tiếp việc của hôm qua, không file nào đổi	`--resume`	Context cũ còn đúng, giữ nguyên lịch sử là có ích
So sánh hai hướng refactor	`fork_session`	Khám phá phân kỳ từ một nền chung
Resume sau khi sửa 3 trong 50 file	Session mới + summary	Tool result cũ của file đã sửa sẽ gây mâu thuẫn
Phiên dài, lịch sử đầy rác	Session mới + summary	Context xuống cấp thì cần một nền sạch
Thử chiến lược testing so với chiến lược documentation	`fork_session`	Hai hướng độc lập từ cùng một phân tích
Resume sau khi cập nhật dependency	Session mới + summary	Nhiều file có thể đã đổi gián tiếp

Ví dụ thực tế: bug lời khuyên mâu thuẫn

Một developer dùng Claude Code phân tích codebase 50 file trong hai ngày. Ngày 1, họ phân tích module authentication và chỉ ra ba vấn đề. Tối đó, họ sửa cả ba bằng cách chỉnh auth.ts, session.ts và middleware.ts.

Ngày 2, họ resume session. Claude đề xuất sửa đúng ba vấn đề đã sửa rồi — vì tool result cũ, thứ vẫn chứa đoạn code chưa sửa, còn nằm trong lịch sử hội thoại. Tệ hơn, khi được hỏi về trạng thái hiện tại của auth.ts, Claude trả lời mâu thuẫn: lúc thì dẫn code cũ (từ tool result lỗi thời), lúc thì dẫn code mới (từ lần đọc mới).

Cách sửa: mở session mới kèm bản tóm tắt. “Phân tích trước đã chỉ ra ba vấn đề authentication ở auth.ts, session.ts và middleware.ts. Cả ba đã được sửa. Hãy phân tích lại ba file này để xác nhận các bản sửa và kiểm tra xem thay đổi có sinh ra vấn đề mới nào không.”

Session mới không có tool result lỗi thời. Agent đọc file hiện tại, xác nhận bản sửa, và đưa lời khuyên nhất quán dựa trên đúng trạng thái thật.

Bẫy thi

Tình huống luyện tập

Một developer resume session Claude Code sau khi sửa 3 file trong codebase 50 file. Agent đưa lời khuyên mâu thuẫn về các file đã sửa — đề xuất những thay đổi đã làm rồi và nhắc tới đoạn code không còn tồn tại. Cách xử lý phù hợp nhất là gì?

A. Mở session hoàn toàn mới, không mang theo context nào, và phân tích lại toàn bộ codebase 50 file từ đầu trước khi làm tiếp
B. Resume session hiện có và bảo agent đọc lại 3 file đã sửa, vẫn giữ phần còn lại của lịch sử hội thoại để có mạch
C. Mở session mới kèm bản tóm tắt kết quả trước đó và báo rõ 3 file đã thay đổi để phân tích lại có trọng điểm
D. Dùng fork_session rẽ nhánh session hiện có để đưa các thay đổi file vào một mạch làm việc riêng

Đáp án & giải thích

Đúng: C

A — Phân tích lại toàn bộ 50 file là phí khi chỉ 3 file đổi. Phân tích trước đó cho 47 file còn lại vẫn đúng. Phân tích lại có trọng điểm hiệu quả hơn.
B — Resume giữ nguyên tool result lỗi thời trong lịch sử hội thoại. Kể cả sau khi đọc lại 3 file, nội dung file cũ vẫn nằm trong context và vẫn ảnh hưởng suy luận của agent ở các quyết định liên quan. Mâu thuẫn tiếp tục.
C — Session mới kèm summary injection loại bỏ hoàn toàn tool result lỗi thời. Bản tóm tắt được tiêm vào giữ lại kiến thức từ phiên trước. Nêu rõ 3 file đã đổi cho phép phân tích lại có trọng điểm mà không phải khảo sát lại cả codebase.
D — fork_session tạo nhánh từ session hiện có, mà session đó vẫn chứa tool result lỗi thời. Fork kế thừa đúng đống context cũ đã gây ra mâu thuẫn. Fork dành cho khám phá phân kỳ, không dành để xử dữ liệu lỗi thời.

Nguồn

Claude Code Documentation — Anthropic
Claude Code in Action (Skilljar) — Anthropic
Claude Agent SDK Overview — Anthropic
Agent SDK: Work with sessions — Anthropic

Exam Simulator

Năm câu trắc nghiệm theo format đề thi về Session State and Resumption. Chọn đáp án trước, rồi mở phần giải thích.

Câu 1

Một developer resume session Claude Code sau khi sửa 3 file trong codebase 50 file. Agent đưa lời khuyên mâu thuẫn — đề xuất những thay đổi đã làm rồi và nhắc tới đoạn code không còn tồn tại. Cách xử lý phù hợp nhất là gì?

A. Mở session hoàn toàn mới và phân tích lại toàn bộ codebase 50 file từ đầu
B. Resume session và bảo agent chỉ đọc lại 3 file đã sửa để cập nhật hiểu biết
C. Dùng fork_session tạo nhánh mới để đưa các thay đổi file vào một cách độc lập
D. Mở session mới kèm bản tóm tắt kết quả trước đó và liệt kê 3 file đã thay đổi

Đáp án & giải thích

Đúng: D

D đúng vì session mới kèm summary injection loại bỏ hoàn toàn tool result lỗi thời. Bản tóm tắt giữ lại kiến thức từ phiên trước. Nêu rõ 3 file đã đổi cho phép phân tích lại có trọng điểm mà không phải khảo sát lại cả codebase.
A sai vì phân tích lại cả 50 file là phí khi chỉ 3 file đổi. Phân tích trước đó cho 47 file còn lại vẫn đúng.
B sai vì resume giữ nguyên tool result lỗi thời trong lịch sử. Kể cả sau khi đọc lại 3 file, nội dung cũ vẫn nằm trong context và vẫn ảnh hưởng suy luận ở các quyết định liên quan.
C sai vì fork_session tạo nhánh từ session hiện có, vốn vẫn chứa tool result lỗi thời. Fork kế thừa đúng đống context đã gây mâu thuẫn. Fork dành cho khám phá phân kỳ.

Câu 2

Sau khi phân tích codebase, một developer muốn so sánh hai chiến lược refactor: một hướng tối ưu hiệu năng, một hướng tối ưu khả năng đọc. Cách quản lý session nào phù hợp nhất?

A. Mở hai session hoàn toàn mới, mỗi chiến lược một session
B. Dùng –resume để tiếp tục cùng session và thử lần lượt cả hai chiến lược trên một nhánh
C. Dùng fork_session tạo hai nhánh độc lập từ nền phân tích chung
D. Mở session mới kèm summary injection cho từng chiến lược

Đáp án & giải thích

Đúng: C

C đúng vì fork_session tạo các nhánh độc lập từ một nền phân tích chung. Cả hai nhánh dựa trên cùng hiểu biết ban đầu về codebase nhưng đi hai hướng khác nhau một cách độc lập. Đây đúng là trường hợp fork sinh ra để giải quyết.
A sai vì mở session hoàn toàn mới làm mất phần phân tích ban đầu. Cả hai chiến lược đều hưởng lợi từ nền hiểu biết chung.
B sai vì thử cả hai chiến lược trong cùng session làm nhiễm bẩn quá trình khám phá. Lần thử thứ hai bị ảnh hưởng bởi phân tích và quyết định của lần thứ nhất.
D sai vì tuy summary injection giữ lại được một phần kiến thức, fork_session giữ nguyên toàn bộ context phân tích và là cơ chế sinh ra đúng cho khám phá phân kỳ.

Câu 3

Một developer hoàn tất phân tích codebase hôm qua. Qua đêm không file nào thay đổi. Hôm nay họ muốn làm tiếp từ chỗ đã dừng. Cách nào tốt nhất?

A. Dùng --resume <session-name> để tiếp tục session đã đặt tên
B. Mở session mới kèm summary injection
C. Dùng fork_session tạo nhánh từ phân tích hôm qua
D. Mở session hoàn toàn mới và phân tích lại cả module từ đầu

Đáp án & giải thích

Đúng: A

A đúng vì không file nào thay đổi nên context cũ vẫn đúng. –resume khôi phục toàn bộ lịch sử hội thoại và cho developer làm tiếp đúng chỗ đã dừng. Đây là tình huống lý tưởng cho resume.
B sai vì summary injection làm mất chi tiết so với lịch sử hội thoại đầy đủ. Khi context còn đúng, resume giữ được nhiều thông tin hơn bản tóm tắt.
C sai vì fork dành cho khám phá phân kỳ, không dành cho việc đi tiếp đơn thuần. Developer muốn tiếp tục cùng một mạch, không phải thử phương án thay thế.
D sai vì phân tích lại toàn bộ là phí khi phân tích cũ vẫn đúng. Resume hiệu quả hơn.

Câu 4

Vì sao resume một session sau khi file bị sửa lại rắc rối hơn là chỉ cần bảo agent đọc lại các file đã đổi?

A. Agent không đọc lại được file trong một session đã resume
B. Tool result lỗi thời vẫn nằm trong lịch sử và vẫn chi phối suy luận của agent
C. Session đã resume có context window bị thu nhỏ, không chứa nổi nội dung file mới
D. Agent sẽ từ chối phân tích nếu phát hiện file đã bị sửa

Đáp án & giải thích

Đúng: B

B đúng vì resume giữ nguyên toàn bộ lịch sử hội thoại, gồm cả tool result cũ chứa nội dung file trước khi sửa. Kể cả sau khi đọc lại file đã đổi, nội dung cũ vẫn nằm trong context. Agent có thể dẫn dữ liệu lỗi thời từ đoạn trước, nhất là với các quyết định tiếp tuyến không dính trực tiếp tới file đã sửa.
A sai vì agent đọc lại file được trong session đã resume. Vấn đề không nằm ở khả năng mà ở việc context bị nhiễm dữ liệu cũ.
C sai vì session đã resume không bị thu nhỏ context window. Vấn đề là dữ liệu lỗi thời trong lịch sử, không phải sức chứa context.
D sai vì agent không phát hiện rồi từ chối phân tích dựa trên việc file bị sửa. Nó chỉ đơn giản suy luận trên mọi dữ liệu đang có trong context, gồm cả dữ liệu lỗi thời.

Câu 5

Một developer dùng fork_session để xử stale context sau khi sửa file. Vì sao cách này sai?

A. fork_session không dùng được sau khi file bị sửa
B. fork_session xóa session gốc, làm mất toàn bộ phân tích trước đó
C. Nhánh fork kế thừa nguyên đống tool result lỗi thời
D. fork_session chỉ dùng được để so sánh chiến lược testing, không dùng chung được

Đáp án & giải thích

Đúng: C

C đúng vì fork_session rẽ nhánh từ trạng thái hiện tại của session, gồm cả mọi tool result lỗi thời. Fork kế thừa đúng đống context đã gây ra lời khuyên mâu thuẫn. Fork không tạo ra nền sạch — nó tạo bản sao của trạng thái hiện tại. Với stale context, cách đúng là mở session mới kèm summary injection.
A sai vì fork_session vẫn dùng được bất kể file có bị sửa hay không. Vấn đề không nằm ở việc có dùng được hay không mà ở việc kế thừa dữ liệu lỗi thời.
B sai vì fork_session không xóa session gốc. Nó tạo một nhánh độc lập trong khi giữ nguyên bản gốc.
D sai vì fork_session dùng được cho mọi tình huống khám phá phân kỳ. Nó chỉ sai đúng ở việc xử stale context, vì nó kế thừa dữ liệu lỗi thời.