4.1 Bộ điều phối thực sự làm gì
Bộ điều phối (orchestrator) là agent nhận công việc, chia nhỏ và chịu trách nhiệm về kết quả. Bỏ đi ẩn dụ sơ đồ tổ chức, bộ điều phối có năm việc:
Helper mở rộng bộ điều phối, không bao giờ cạnh tranh với bộ điều phối. Điều đó cho bạn một dấu vết audit, một bề mặt phê duyệt và một nơi có thể trả lời “hệ thống đang làm gì ngay lúc này?”
Bằng chứng đã công bố cho thấy cả hai chiều (nguồn trong Phụ lục D). Anthropic báo cáo rằng một hệ thống đa agent (Claude Opus 4 dẫn dắt cùng các helper Claude Sonnet 4) vượt trội một agent Claude Opus 4 đơn lẻ 90,2% trong bài đánh giá nghiên cứu nội bộ, trong khi hệ thống đa agent dùng khoảng 15 lần nhiều token hơn chat. Nhóm Azure SRE Agent của Microsoft đi theo hướng ngược lại, gộp nhiều micro-agent và hơn một trăm công cụ thành một vài agent tổng quát với các công cụ cốt lõi.
Áp dụng cả hai bài học:
- Chia theo ranh giới credential và lĩnh vực như cloud, bảo mật, cơ sở dữ liệu và Kubernetes. Những cách chia này tự bù đắp nhờ quyền tối thiểu và độ sâu chuyên môn.
- Đừng chia nhỏ hơn nữa. Mỗi agent thêm vào đều thêm chi phí điều phối, ngữ cảnh trùng lặp và thêm một thứ cần đánh giá.
4.2 Bàn giao là hợp đồng
Hệ thống đa agent hiếm khi thất bại vì một helper làm kém. Hệ thống thất bại ở khâu bàn giao. Hãy coi bàn giao là một hợp đồng có kiểu dữ liệu, không phải một tin nhắn chat:
Với kết quả trả về có cấu trúc, bước tích hợp có thứ cụ thể để dung hòa, và dấu vết audit ghi lại ai kết luận gì từ bằng chứng nào. Một chuỗi suy luận dài duy nhất sẽ che mất những thông tin đó.
Từ đó, song song hóa đến một cách tự nhiên. Các tác vụ con độc lập có thể chạy đồng thời để giảm độ trễ, nhưng chỉ khi chúng không thể ghi vào cùng một thứ. Hai helper cùng thay đổi một hệ thống là một race condition.
TRONG THỰC TẾ: SUBAGENT TRONG CLOUDTHINKERCloudThinker dùng một trợ lý tích hợp sẵn, cũng tên là CloudThinker, làm bộ điều phối. Với công việc tập trung, CloudThinker tạo các subagent tạm thời: helper ngắn hạn, mỗi helper nhận một mục tiêu có giới hạn và không bao giờ nói chuyện trực tiếp với bạn. Xem Agent.
- Trong một cuộc điều tra sự cố, CloudThinker giao các kiểm tra tập trung (log, metric, trace, thay đổi gần đây, dependency) cho subagent và hợp nhất kết quả thành một kết luận. Xem Điều tra và RCA.
- Mặc định, subagent bị từ chối mọi công cụ làm thay đổi hệ thống của bạn. Thay đổi thuộc về bộ điều phối, nơi Approvals áp dụng.
- Khi một subagent thất bại, agent cha nhận một mã lỗi cố định, một thông báo ngắn đã được ẩn thông tin nhạy cảm và một hành động tiếp theo được đề xuất, để agent cha có thể phục hồi thay vì đoán:
4.3 Kinh tế học hai động cơ, định lượng
Leadership Edition đã mô tả mô hình bằng lời: một động cơ cảm biến rẻ, luôn bật và một động cơ xử lý đắt, chạy theo yêu cầu. Ở đây bạn sẽ tính toán cụ thể. Thiết kế đơn giản nhất chạy suy luận bằng model tiên tiến nhất trên mọi signal. Với hàng nghìn signal mỗi ngày, mỗi signal một lượt suy luận nhiều bước, hóa đơn model xóa sạch lợi nhuận trước cả lần gia hạn đầu tiên. Chi tiêu model không giới hạn là một trong những nguyên nhân đã được ghi nhận khiến các dự án agent bị hủy. Hai động cơ thay đổi hình dạng của chi phí:Đo tại điểm nối
Ba con số là kinh tế đơn vị của bạn. Đưa chúng lên dashboard ở Chương 8:
Một ví dụ với số tròn giả định (không phải giá của CloudThinker):
Giảm một nửa tỷ lệ nâng cấp xuống 0,25% và chi tiêu động cơ xử lý giảm còn $100, nên chi phí mỗi sự cố được giải quyết giảm về gần $3,75 nếu vẫn bắt được đúng những sự cố thật như trước. Tăng lưu lượng signal lên mười lần ở cùng tỷ lệ nâng cấp và hóa đơn cảm biến gần như không đổi, nhưng chi tiêu động cơ xử lý tăng lên $2.000 mỗi ngày. Đó là lý do tỷ lệ nâng cấp là núm điều chỉnh cần theo dõi.
Đòn bẩy thứ hai trên cùng điểm nối, như một mô hình chung: công việc hằng ngày thường lệ, đã hiểu rõ không cần suy luận tiên tiến nhất. Model nhỏ được fine-tune có thể xử lý các trường hợp có lưu lượng lớn, còn model tiên tiến nhất dành cho các cuộc điều tra mới lạ. Các nhóm trong ngành có quy định thường kết hợp điều này với triển khai tự host để kiểm soát hoàn toàn model. Trong CloudThinker, các đòn bẩy gần nhất là model tier (giữ công việc thường lệ ở Light, xem Mức sử dụng và credit) và triển khai tự host hoặc air-gapped, hiện đang ở giai đoạn truy cập sớm qua chương trình đối tác thiết kế (Tùy chọn triển khai).
TRONG THỰC TẾ: PULSE VÀ ĐIỀU TRA TRONG RESOLVEResolve, module ứng phó sự cố của CloudThinker, cung cấp sẵn cách chia này.
- Cảm biến: Pulse. Pulse nhận mọi cảnh báo mà công cụ của bạn gửi, loại nhiễu bằng bốn kiểm tra theo thứ tự (khử trùng lặp, giới hạn tốc độ, snooze và phán quyết nhiễu đã học; xem lọc nhiễu), nhóm các signal liên quan thành cluster, phân loại từng cluster, và ghi nhận cluster cần xử lý thành sự cố với trạng thái Open. Pulse dừng ở đó: Pulse không bao giờ phân loại hay điều tra.
- Xử lý: điều tra. Điều tra chỉ chạy trên sự cố. Bạn kiểm soát điều gì đánh thức động cơ xử lý bằng Auto-investigate và Only from a minimum severity trên mỗi webhook trong Resolve → Integrations, và công tắc On duty trong Resolve → Investigation. Xem Cài đặt Resolve.
- Đo lường. Mở Resolve → Insights và tab Pulse analysis (Phân tích Pulse). Signals ingested là mẫu số của bạn. Correlation yield (số signal có cluster được liên kết với sự cố hoặc đã giải quyết, chia cho tổng signal) là con số tích hợp sẵn gần nhất với tỷ lệ nâng cấp; con số này cũng tính cả cluster được giải quyết mà không có sự cố. Noise suppressed cho thấy những gì động cơ cảm biến đã lọc bỏ.
- Tính chi phí. Credit không hiển thị theo từng cuộc điều tra. Admin Settings → Usage, trong By Feature, cho thấy tính năng nào đã dùng credit trong một khoảng thời gian; chia cho số cuộc điều tra trong khoảng đó để có chi phí trung bình mỗi cuộc điều tra (Mức sử dụng và credit).
- Giới hạn chi tiêu. Giới hạn credit đặt ngân sách hằng tháng cho mỗi workspace, với Throttle hoặc Notify only khi đạt ngưỡng.
4.4 Trạng thái: hồ sơ sự cố là sự thật dùng chung
Hệ thống đa agent cần một bản ghi bền vững, chỉ ghi thêm cho mỗi tác vụ. Bản ghi chứa dòng thời gian của signal, giả thuyết, lệnh gọi công cụ, bằng chứng, quyết định, phê duyệt, hành động và xác minh. Mọi agent đọc từ và ghi vào đó. Một người tham gia giữa chừng thấy cùng sự thật mà các agent thấy. Hãy xây dựng hồ sơ này dưới dạng event log, không phải trạng thái chat có thể thay đổi. Điều đó mang lại ba thứ:- Phát lại để đánh giá (Chương 7): chạy lại một sự cố cũ với model hoặc prompt mới và so sánh.
- Tài liệu audit miễn phí (Chương 6): ai làm gì, dựa trên bằng chứng nào, với sự phê duyệt của ai.
- Tiếp tục an toàn sau khi bị sập: agent bị dừng giữa cuộc điều tra sẽ tiếp tục từ bản ghi thay vì bắt đầu lại.
TRONG THỰC TẾ: MỘT HỒ SƠ CHO MỖI SỰ CỐTrong Resolve, mỗi sự cố có một hồ sơ điều tra. Mỗi phiên mới, do một người hoặc tự động bắt đầu, thêm các bước của phiên đó vào cùng Investigation timeline dưới một dấu mốc phiên. Nếu kết luận thay đổi, dòng thời gian ghi lại một lần sửa đổi nguyên nhân gốc thay vì tạo báo cáo thứ hai, và các phiên trước nằm trong More actions → Earlier sessions. Nhấn Watch live để theo dõi cuộc hội thoại nơi CloudThinker đang làm việc. Xem Điều tra và RCA.
Bước tiếp theo
Chương 5 · Mô hình mối đe dọa
Vì sao agent vận hành là một bề mặt tấn công, và các lớp phòng thủ kiềm chế rủi ro đó.
Tổng quan Pulse
Xem cách Resolve lọc cảnh báo trước khi bất kỳ cuộc điều tra nào bắt đầu.