Chuyển đến nội dung chính
Giai đoạn thí điểm kết thúc nhưng đội agent ở lại. Ngày thứ 2 là quản lý phiên bản, di chuyển model, bảo trì memory và postmortem cho một kiểu đồng đội mới, và chương này cung cấp cho bạn một quy trình làm việc cụ thể cho từng việc.

​
9.1 Mọi thứ đều là artifact, và mọi thay đổi đều là một lần deploy

Đơn vị bạn vận hành là một gói có phiên bản: Phát hành gói giống như phát hành một dịch vụ. Review gói trong một pull request, cho gói đi qua các cổng eval của Chương 7, triển khai dần dần, và rollback cả gói như một đơn vị. Hãy truy lùng thay đổi vô hình: một prompt được sửa trong console, một model được cập nhật từ phía nhà cung cấp, một mô tả công cụ được chỉnh tại chỗ. Nếu một thay đổi không thể diff, chặn cổng và hoàn tác, sớm muộn thay đổi đó sẽ trở thành nguyên nhân gốc mà bạn không tìm ra, trong một hệ thống có nhiệm vụ chính là tìm nguyên nhân gốc.

​
9.2 Quy trình di chuyển model

Model thay đổi theo lịch của người khác: ngừng hỗ trợ, nâng cấp, thay đổi giá. Đổi model là thay đổi có độ biến động cao nhất trong toàn bộ stack, vì vậy hãy triển khai việc đổi model như một dự án:
  1. Ghim phiên bản một cách tường minh. Không bao giờ trỏ production vào “latest”.
  2. Chạy toàn bộ golden set trên ứng viên và so sánh kết quả theo từng loại sự cố, không chỉ trung bình.
  3. Canary trên các loại rủi ro thấp và theo dõi metric trực tuyến: tỷ lệ chấp nhận, rollback, số bước và chi phí. Thay đổi về số bước là dấu hiệu kinh điển của hành vi đã thay đổi.
  4. Giữ khả năng chạy song song để các loại nhạy cảm có thể chạy model cũ và mới cạnh nhau và so sánh.
  5. Thỏa thuận trước khung thời gian ngừng hỗ trợ với nhà cung cấp, để việc di chuyển là công việc có kế hoạch, không phải tình huống khẩn cấp.
Có đội agent kết hợp nhiều model: model nhỏ đã tinh chỉnh cho các loại thường gặp, frontier model cho các cuộc điều tra mới lạ. Áp dụng cùng quy trình cho từng luồng. Bạn cũng có thêm khả năng chống chịu, vì một cú sốc giá hoặc hồi quy ở một model chỉ trở thành vấn đề của một luồng, không phải toàn bộ đội agent.

​
9.3 Bảo trì memory và tri thức

Chương 2 đã thiết kế memory. Vào ngày thứ 2, bạn bảo trì memory. Một chu kỳ hằng tháng hiệu quả như sau:
  1. Xem xét các memory mới được ghi từ chu kỳ trước. Lấy mẫu, bắt đầu từ các loại sự cố có tác động cao.
  2. Giải quyết mâu thuẫn khi bằng chứng mới phản bác một kết luận đã lưu.
  3. Cắt bỏ hoặc cho hết hạn các memory tham chiếu đến hệ thống đã ngừng hoạt động.
  4. Lập chỉ mục lại lớp tri thức sau các thay đổi lớn trong hệ thống của bạn.
Hãy giao cho lớp tri thức một người phụ trách có tên. Đây là thành phần production thực thụ, không phải một wiki làm cho có. Và hãy khép vòng: postmortem của mọi sự cố đã giải quyết nên kết thúc bằng một dòng tường minh, “Chúng ta đã dạy hệ thống điều gì?“

​
9.4 Postmortem cho agent

Agent sẽ sai. Phản xạ bạn muốn có là phản xạ mà văn hóa SRE đã có: postmortem không đổ lỗi, tập trung vào cơ chế, giờ được áp dụng cho các đồng đội phần mềm. Khi một agent mắc một lỗi có hậu quả, hãy dựng lại sự kiện từ trace và bản ghi audit với bốn câu hỏi: Sau đó hãy gọi tên cơ chế, vì mỗi cơ chế có cách sửa khác nhau: “AI đã mắc lỗi” không phải là một cơ chế. Hãy thêm mọi sự kiện vào golden set dưới dạng một kịch bản mới, để cùng một lỗi không thể được phát hành hai lần. Giữ cùng một lập trường công khai cho cả con người và agent: lỗi được loại bỏ bằng kỹ thuật với cùng một kỷ luật, và không bên nào bị săn phù thủy. Không gì giết chết một chương trình agentic nhanh hơn một sự cố tồi tệ bị coi là sự phản bội thay vì một khiếm khuyết.

​
9.5 Vai trò, cụ thể hóa

Field Guide gọi tên kỹ sư vận hành agent (§7): người vận hành hệ thống vận hành hạ tầng của bạn. Đây là một tuần điển hình:
TRONG THỰC TẾ: NGÀY THỨ 2 TRONG CLOUDTHINKERCloudThinker chạy như một đội agent theo thiết kế: một trợ lý tích hợp sẵn, CloudThinker, tạo các subagent tạm thời cho công việc chuyên môn, và các agent này dùng chung skill và memory của workspace. Vì vậy, bản sửa skill đến được mọi agent cùng lúc. Dưới đây là nơi áp dụng từng thói quen ngày thứ 2:

​
Giờ đầu tiên của ngày thứ 2

1

Đưa custom skill vào Git

Mở Settings của workspace, rồi Skills. Nhấn Download trên từng custom skill và commit các tệp .zip, hoặc các tệp SKILL.md đã giải nén, vào một repository có người phụ trách.Trạng thái thành công: mọi custom skill trong workspace đều có một bản sao trong Git mà bạn có thể diff.
2

Kiểm tra Dreaming đã thay đổi gì

Mở More → Workspace settings → Memory. Trong Run history, mở rộng lượt chạy Succeeded gần nhất và đọc bản tóm tắt.Trạng thái thành công: bạn biết lượt chạy gần nhất đã ghi, hợp nhất hoặc xóa những mục memory và skill nào, và bạn đã tắt việc xóa skill nếu có skill bị xóa mà quan trọng.
3

Xem xét công việc theo lịch của tuần trước

Mở Automations, rồi tab Runs. Mở mọi lượt chạy thất bại, hoặc mọi lượt chạy đã thay đổi gì đó, và đọc cuộc hội thoại của lượt chạy.Trạng thái thành công: mỗi lượt chạy thất bại hoặc có thao tác ghi trong tuần trước đều có người phụ trách và bước tiếp theo.
ĐIỀU CẦN NHỚNgày thứ 2 là một kỷ luật. Phát hành các gói có phiên bản qua cổng eval, chạy di chuyển model như các dự án với diff theo từng loại, bảo trì memory theo lịch với người phụ trách có tên, và thực hiện postmortem không đổ lỗi để gọi tên cơ chế và mở rộng golden set. Giao cho một kỹ sư một tuần làm việc biến tất cả những điều này thành thường lệ. Những đội agent làm được điều này sẽ tiến bộ theo thời gian; những đội không làm sẽ suy thoái trở lại thành chính công việc lặp lại mà chúng đã thay thế.

​
Bước tiếp theo

Chương 10 · Các trụ cột theo chiều dọc

Áp dụng cùng phương pháp kỹ thuật cho độ phức tạp, chi phí và bảo mật.

Dreaming

Xem xét việc bảo trì memory hằng đêm và lịch sử các lượt chạy.