Xây dựng Agent AI mức Production-Ready với Claude Managed Agents

Bài viết này hướng dẫn bạn xây dựng một agent điều tra sự cố (SRE Incident Response Agent) hoàn chỉnh bằng Claude Managed Agents — loại agent có thể tự điều tra sự cố production thay cho kỹ sư bị đánh thức lúc 3 giờ sáng. Toàn bộ quá trình chỉ mất khoảng 15 phút, và kết quả là một agent chạy server-side, tự phục hồi lỗi, sẵn sàng scale tới hàng triệu người dùng.

Phần cuối bài có ví dụ thực tế từ Notion về cách vận hành nhiều agent phối hợp ở quy mô lớn.

Bạn cần gì trước khi bắt đầu

• Một API key của Anthropic.
• Clone repository workshop (link được cung cấp trong buổi webinar).
• Cài đặt và chạy được file Streamlit demo trên máy.

Bối cảnh: Vì sao cần Claude Managed Agents

Trước khi vào các bước, ta cần hiểu ngắn gọn tại sao công cụ này ra đời.

Từ 2023, cách xây dựng trên Claude đã tiến hoá qua nhiều tầng:

1. Messages API — tokens vào, tokens ra. Hỗ trợ các use case đơn giản.
2. Claude Agent SDK — chính là harness chạy Claude Code; cho Claude quyền truy cập một sandbox, kèm session management và observability, nhưng vẫn để lại nhiều việc hạ tầng cho developer.
3. Claude Managed Agents (CMA) — đóng gói sẵn phần lớn hạ tầng production: agentic loop, sandbox, credentials, session management, observability và hosting.

Nói cách khác, những bài toán mà team nào cũng gặp khi đưa agent lên production — hosting, scaling, khôi phục sau lỗi, cách ly thực thi, quản lý credentials — nay đã có sẵn. Bạn chỉ tập trung vào phần tạo ra sự khác biệt: context engineering và chuyên môn của agent.

Ba khái niệm cốt lõi cần nắm

Mọi thứ trong CMA xoay quanh ba primitive, được thiết kế để dễ thay thế khi model nâng cấp:

Chính phần cấu hình Agent (prompt, tools, skills…) là thứ phân biệt một agent pháp lý với một agent code hay agent bán hàng.

Các bước triển khai

Bước 1 — Chuẩn bị môi trường

Chạy lần lượt các lệnh sau trên máy của bạn.

1. Clone repo

git clone https://github.com/anthropics/cwc-workshops
cd cwc-workshops/ship-your-first-managed-agent

2. Tạo virtual env

python -m venv .venv
source .venv/bin/activate        # Windows: .venv\Scripts\activate

3. Cài đặt & chạy

pip install -r requirements.txt
cp .env.example .env             # rồi điền ANTHROPIC_API_KEY vào file .env
streamlit run app.py

Sau khi chạy, bạn sẽ thấy trang Incident Response Agent hiển thị đầy đủ metrics, logs và deployment của một sự cố đang diễn ra. Đây là bộ dữ liệu bạn sẽ giao cho agent xử lý.

Repo có sẵn hai file: một file chưa hoàn chỉnh để bạn thực hành, và một file hoàn chỉnh để đối chiếu. Bạn có thể copy dần từng phần từ file hoàn chỉnh, hoặc tự viết lại từ đầu nếu muốn thử thách.

Bước 2 — Định nghĩa Agent

Khai báo agent: đặt tên, chọn model, viết system prompt. Điểm quan trọng: prompt nên đơn giản, nhưng context phải đầy đủ. Ở đây chỉ cần nói với agent rằng nó là một SRE agent, rồi đưa cho nó toàn bộ logs, metrics và deployment — đúng những dữ liệu mà một kỹ sư SRE thật sẽ có khi xử lý sự cố.

Ngay khi khai báo xong, primitive Agent “sống dậy” trên giao diện.

Bước 3 — Định nghĩa Environment

Khai báo environment kiểu cloud cho đơn giản (chạy trên cloud của Anthropic). Nếu cần bảo mật cao, bạn có thể dùng self-hosted sandbox trong VPC riêng, kể cả qua các đối tác triển khai như Modal.

Trong lúc thử nghiệm có thể để network unrestricted; khi lên production thì siết chặt tuỳ mức độ an toàn mong muốn.

Bước 4 — Tạo Session

Cấp context cho agent bằng Files API để nó đọc được session logs. Sau đó tạo session bằng cách gắn agent_id + environment_id đã tạo ở trên, kèm resource là file log vừa mount.

Lúc này agent đã tồn tại nhưng vẫn đứng yên (idle), vì chưa có dữ liệu streaming và chưa có tool để hành động.

Bước 5 — Bật streaming và định nghĩa tool handlers

Streaming: bật để mọi tương tác giữa người dùng và agent — bao gồm các lần gọi tool, đọc kết quả, và các khối suy nghĩ (thinking blocks) — vừa được trả về cho người dùng, vừa được ghi vào observability console.

Tool handlers: đây là bước quan trọng nhất về mặt kỹ thuật. Bạn định nghĩa các công cụ để agent lấy dữ liệu và hành động. Chất lượng context engineering ở bước này quyết định agent mạnh tới đâu.

Bước 6 — Chạy thử

Gõ “hi” để kiểm tra — agent tự giới thiệu là SRE agent, có thể điều tra sự cố bằng cách đối chiếu app log với metrics, deployment gần đây và code diff.

Tiếp theo, yêu cầu: “yes, please help me debug this incident.” Quan sát agent làm việc:

• Chạy bash trong sandbox để xem các session upload.
• Lấy các deployment gần đây qua tool bạn vừa định nghĩa.
• Phân tích lỗi, đọc logs, dựng giả thuyết.
• Kiểm chứng bằng cách so sánh truy vấn trước và sau deploy.

Kết quả: agent xác định root cause — database connection pool bị cạn do một query regression ở phần checkout, đến từ bản deploy của một người tên Alice — kèm bằng chứng trước/sau và gợi ý cách rollback. Toàn bộ trong khoảng 10–15 phút.

Điều gì làm nên tính “production-ready”

Bí quyết nằm ở một quyết định kiến trúc: tách Bộ não (agent loop) khỏi Đôi tay (sandbox).

• Bộ não chạy server-side, lo suy luận và ra quyết định — và không bao giờ nhìn thấy credentials.
• Đôi tay là sandbox cô lập, chỉ được spin-up khi cần chạy tool.

Ban đầu đội kỹ thuật của Anthropic thử đặt cả hai trong cùng một container, nhưng gặp vấn đề khi lên production. Sau khi tách đôi, kiến trúc có ba lợi ích lớn:

1. Khả năng phục hồi. Sandbox chết? Bật cái mới và làm tiếp. Bộ não chết? Đọc lại session durable và tiếp tục mà không mất context. Điều này giữ an toàn cho các agent chạy dài, nhiều bước.
2. Tốc độ. Không phải chờ container dựng xong mới bắt đầu suy luận — thậm chí có thể bỏ qua việc dựng container nếu tác vụ không cần. Kết quả: thời gian tới token đầu tiên (TTFT) nhanh hơn ~60% ở p50 và hơn 90% ở p95.
3. Bảo mật credentials. Credentials được cất trong Vault và mã hoá. Agent dùng được tool cần credentials nhưng không bao giờ nhìn thấy hay làm lộ chúng.

Ngoài ra, mọi thứ đều được ghi vào observability console — bạn có thể xem lại từng lời chào, từng lệnh bash, từng tool call, phục vụ audit và debug (thậm chí nhờ chính Claude debug lại transcript).

Nâng cao: các tính năng ở “frontier”

Sau khi quen với ba primitive cơ bản, bạn có thể khám phá thêm các tính năng được thiết kế để bám theo tốc độ tiến hoá của model:

• Dreaming — agent tự cải thiện: chạy định kỳ để rà lại memory và session log, tái cấu trúc “trí nhớ” để các phiên sau thông minh hơn.

• Memory — cho agent học từ các tương tác trong quá khứ.
• Multi-agents & Outcomes — nhiều agent phối hợp, hướng tới kết quả cuối thay vì từng bước rời rạc.
• Web hook trigger — agent tự khởi động ngay khi phát hiện sự cố, kỹ sư không cần bị đánh thức lúc 3 giờ sáng.
• Self-hosted sandbox & MCP tunnels — chạy toàn bộ tool execution, file và network egress trong hạ tầng riêng của bạn.

Mục tiêu chung của CMA là thu hẹp khoảng cách giữa những gì model có thể làm và những gì các harness tĩnh cho phép — vốn thường “đóng khung” giả định về giới hạn của model.

Ví dụ thực tế: Claude Agents trong Notion

Tiếp theo là cách Notion được tích hợp Claude Agents để biến Notion thành “command center” cho agent. Chỉ sau 3 tuần ra mắt:

• ~18.000 Claude agent được tạo
• ~140.000 bước thực thi
• ~50 tỷ token phục vụ
• 90% lượt dùng đến từ automation (kích hoạt trên trang Notion, tin nhắn Slack, hoặc chạy theo lịch) chứ không phải chat trực tiếp

Cách Notion vận hành:

• Agent như một đồng đội. Bạn tag @Claude vào task y hệt một người thật; nó bình luận, viết spec và tạo file ngay trong Notion.
• Một đội agent chia vai. Investigator → Planner → Builder, mỗi agent có permission, context và automation riêng, cùng làm trên một task board chung.
• MCP làm nền, CLI trám chỗ thiếu. MCP xử lý phần lớn thao tác; CLI dùng cho file nhị phân/office (ví dụ PowerPoint thực chất là thư mục nhiều file, không phải text thuần nên không đi qua MCP được).
• Skills định nghĩa “phong cách” đầu ra. Không chỉ là biết tạo PowerPoint, mà là tạo đúng gu của từng đội; người dùng có thể tự publish skill riêng.

Ba cách áp dụng CMA (three flavors):

1. Claude-branded — hiển thị rõ “Claude Agents” trong sản phẩm (lựa chọn của Notion).
2. CMA làm harness ngầm — không gắn nhãn Claude, chỉ dùng phần “bộ não” bên dưới sản phẩm của bạn.
3. Công cụ nội bộ — tự động hoá quy trình riêng cho team/tổ chức.

Lưu ý về bảo mật và phân quyền

Vì phần lớn hoạt động là automation, việc phân quyền rất quan trọng. Cách Notion làm:

• Mỗi agent mặc định private khi tạo — phải chia sẻ tường minh mới dùng được.
• Phân quyền theo mức: có người chỉ được chat, có người được trigger, có người được edit.
• Scope quyền tới từng trang, tài nguyên và tool (ví dụ chỉ cho view-only một wiki quan trọng).

Điểm mấu chốt: giải bài toán automation cũng chính là giải bài toán permissions + collaboration — hai thứ đi liền với nhau.

Tổng kết

Chỉ với ba primitive — Agent, Environment, Session — và khoảng sáu hàm, bạn có thể xây một agent điều tra sự cố chạy server-side, tự phục hồi lỗi, cất credentials an toàn và sẵn sàng scale. Từ nền tảng đó, thêm dreaming, multi-agent và automation là có thể tiến tới các hệ thống phức tạp như cách Notion đang vận hành.

Các bước tiếp theo gợi ý: thử tự động hoá bằng web hook, thêm self-hosted sandbox cho môi trường bảo mật cao, và thiết kế thêm custom tools/skills để mở rộng khả năng của agent.