Tác giả: Claude AI, dưới sự dẫn dắt và những chỉnh sửa cùa Học Trò.
Dựa trên workshop lập trình viên một ngày do Anthropic tổ chức. Diễn giả: Thariq Shihipar, Anthropic. Bản ghi âm gốc đã được tái cấu trúc và mọi khái niệm kỹ thuật đều được giải thích bằng ngôn ngữ đơn giản.
Mở Đầu — Tác Nhân Là Gì?
Để hiểu những gì Thariq đang dạy, trước tiên bạn cần hiểu ba thế hệ công cụ AI mà ông trình bày, vì hầu hết mọi điều ông nói đều được xây dựng trên nền tảng đó.
Thế hệ đầu tiên là lệnh gọi AI đơn. Bạn có một mô hình AI — hãy nghĩ về mô hình như "bộ não" AI, một chương trình được huấn luyện trên lượng văn bản khổng lồ có thể hiểu và tạo ra ngôn ngữ — và bạn gửi cho nó một câu hỏi rồi nhận lại một câu trả lời. "Phân loại email này là spam hay không phải spam." Chỉ vậy thôi. Một lệnh nhắc vào, một câu trả lời ra. Nó hữu ích nhưng hạn chế. AI không có bộ nhớ về những gì nó vừa làm, không có khả năng tra cứu bất cứ điều gì và không có cách nào để thực hiện hành động trong thế giới thực.
Thế hệ thứ hai là luồng làm việc (workflow). Luồng làm việc là một chuỗi các lệnh gọi AI có cấu trúc, được lập kế hoạch trước, được ghép lại với nhau bởi một lập trình viên. Hãy nghĩ nó như một công thức nấu ăn: "Bước một, lấy email của người dùng. Bước hai, yêu cầu AI gán nhãn cho nó. Bước ba, lưu nhãn vào cơ sở dữ liệu." Mỗi bước được lập trình viên xác định trước. AI không có lựa chọn về việc làm tiếp theo — nó chỉ đơn giản hoàn thành phần của mình trong dây chuyền lắp ráp. Luồng làm việc mạnh mẽ hơn, nhưng chúng cứng nhắc. Nếu xuất hiện một tình huống mới mà lập trình viên chưa dự kiến, luồng làm việc sẽ gãy.
Thế hệ thứ ba — và là thế hệ mà toàn bộ workshop này đề cập — là tác nhân (agent). Tác nhân là một AI tự mình quyết định những bước cần thực hiện, theo thứ tự nào, trong bao lâu. Thariq nói rõ: "Các tác nhân tự xây dựng ngữ cảnh của riêng họ, tự quyết định hành trình của mình và hoạt động rất tự chủ." Ngữ cảnh ở đây là từ bạn sẽ thấy liên tục trong lĩnh vực này. Mô hình AI chỉ có thể thấy một lượng văn bản hạn chế tại một thời điểm — về cơ bản đó là bộ nhớ làm việc của nó. Điều này được gọi là cửa sổ ngữ cảnh (context window). Một lệnh gọi AI đơn chỉ thấy câu hỏi của bạn. Một tác nhân chủ động đi ra ngoài thu thập thông tin nó cần, tải vào cửa sổ ngữ cảnh đó, xử lý vấn đề, thực hiện hành động và kiểm tra kết quả của chính mình. Nó không theo công thức; nó đang tự tìm ra công thức khi tiến hành.
Ví dụ mà Thariq sử dụng là Claude Code — trợ lý lập trình của chính Anthropic. Claude Code là tác nhân đầu tiên ông thấy chạy liên tục mười, hai mươi, ba mươi phút mà không cần con người điều khiển. Bạn nói với nó bằng tiếng Anh thông thường điều bạn muốn — "thêm tính năng đăng nhập người dùng vào ứng dụng của tôi" — và nó đọc codebase của bạn, tìm ra những gì cần thay đổi, viết code, chạy các bài kiểm thử và sửa lỗi, tất cả một mình. Đó là điều làm cho nó trở thành tác nhân thay vì luồng làm việc: nó đưa ra quyết định ở mọi bước, không thực thi một kịch bản được định nghĩa trước.
Claude Agent SDK — chủ đề của toàn bộ workshop này — là một bộ công cụ mà Anthropic xây dựng đặc biệt để giúp các lập trình viên khác dễ dàng xây dựng tác nhân của riêng họ hơn. Không phải tác nhân lập trình như Claude Code, mà là bất kỳ loại tác nhân nào: tác nhân dịch vụ khách hàng, tác nhân tài chính, tác nhân nghiên cứu pháp lý, tác nhân chăm sóc sức khỏe. SDK đóng gói tất cả những bài học kinh nghiệm quý báu từ việc xây dựng Claude Code để bạn không phải tự giải quyết những vấn đề đó.
I. Claude Agent SDK — Tại Sao Chúng Tôi Xây Dựng Nó
SDK là viết tắt của Bộ Công Cụ Phát Triển Phần Mềm (Software Development Kit). Hãy nghĩ nó như một hộp công cụ mà ai đó đã chuẩn bị sẵn cho bạn. Thay vì phải đến cửa hàng phần cứng, mua từng dụng cụ riêng lẻ, tìm hiểu thương hiệu nào tốt nhất và học cách sử dụng từng cái từ đầu, bạn nhận được một hộp công cụ đã đóng gói sẵn với mọi thứ được tổ chức và sẵn sàng sử dụng. Claude Agent SDK là hộp công cụ đóng gói sẵn của Anthropic để xây dựng các tác nhân AI.
Thariq giải thích lý do nó tồn tại theo một cách thẳng thắn đáng ngạc nhiên: các kỹ sư của Anthropic liên tục phải xây dựng lại những phần giống nhau. Mỗi lần họ muốn xây dựng một tác nhân mới cho một dự án nội bộ — theo dõi lỗi, xem xét code, giúp đỡ nhóm tài chính — họ lại thấy mình đang giải quyết những vấn đề cơ sở hạ tầng tương tự. Làm thế nào để xử lý khi AI gặp lỗi khi gọi công cụ? Làm thế nào để ngăn cuộc hội thoại cạn kiệt bộ nhớ? Phải làm gì khi tác nhân chạy một giờ và cửa sổ ngữ cảnh đầy? Mỗi nhóm đang giải quyết những vấn đề này một cách độc lập, viết code trùng lặp và mắc phải những sai lầm tương tự.
Một khi Claude Code được phát hành cho công chúng, điều bất ngờ đã xảy ra. Các kỹ sư bắt đầu sử dụng nó cho công việc của họ, điều đó có lý — nó là công cụ lập trình. Nhưng sau đó nhóm tài chính bắt đầu sử dụng nó. Nhóm marketing. Các nhà khoa học dữ liệu. Mọi người đang sử dụng một tác nhân lập trình để thực hiện các nhiệm vụ không liên quan gì đến code, và nó hoạt động vì cách tiếp cận cơ bản đủ tổng quát. Quan sát đó đã làm rõ cơ hội: nếu kiến trúc của Claude Code có thể được trích xuất và đóng gói, bất kỳ ai cũng có thể xây dựng một tác nhân có năng lực trên đó mà không cần giải quyết lại các vấn đề nền tảng.
SDK tích hợp những bài học khó khăn nhất của Anthropic. Lỗi sử dụng công cụ — tức là các tình huống mà AI cố gọi một trong các hàm có sẵn của nó và có điều gì đó không ổn — được xử lý khéo léo. Nén ngữ cảnh được tích hợp sẵn; đây là quá trình tóm tắt các phần cũ hơn của cuộc hội thoại khi cửa sổ ngữ cảnh bắt đầu đầy, để tác nhân có thể tiếp tục làm việc trong các nhiệm vụ dài mà không mất phương hướng. Các thực tiễn tốt nhất cho các nhiệm vụ chạy dài — tác nhân có thể chạy một giờ hoặc hơn — được mã hóa vào các giá trị mặc định của SDK. Khi bạn xây dựng trên SDK, bạn thừa hưởng tất cả điều này miễn phí.
Thariq nói thẳng về một điều: SDK có quan điểm riêng (opinionated). Có quan điểm riêng có nghĩa là nó đưa ra lựa chọn cho bạn và hướng bạn đến một cách thực hiện cụ thể. Điều này trái ngược với bộ công cụ trung lập, làm theo ý bạn. SDK có quan điểm mạnh mẽ về cách xây dựng tác nhân, vì Anthropic tin rằng quan điểm đó dẫn đến kết quả tốt hơn. Quan điểm lớn nhất mà nó giữ — và Thariq quay lại nhiều lần — là dòng lệnh, cụ thể là bash shell, là công cụ mạnh mẽ nhất bạn có thể trao cho một tác nhân.
II. Khung Hỗ Trợ — Nhiều Hơn Chỉ Là Một Mô Hình
Một trong những ý tưởng quan trọng nhất trong workshop này là một tác nhân AI có năng lực không chỉ là một mô hình AI ngồi một mình. Mô hình là bộ não, nhưng một bộ não không có thân xác, không có không gian làm việc và không có bộ công cụ thì không thể thực hiện được nhiều. Toàn bộ cơ sở hạ tầng xung quanh — mọi thứ hỗ trợ và trao quyền cho mô hình — là thứ mà Thariq gọi là Khung Hỗ Trợ (Harness).
Hãy tưởng tượng một nhân viên mới tại một công ty. Nhân viên đó (mô hình AI) có thể rất tài năng, nhưng vào ngày đầu tiên họ không thể làm được nhiều nếu không có bàn làm việc, máy tính, quyền truy cập vào các tệp của công ty, danh sách trách nhiệm và đồng nghiệp để hỏi khi cần. Khung hỗ trợ là tất cả những thứ đó — bàn làm việc, máy tính, quyền truy cập, hướng dẫn. Không có khung hỗ trợ, mô hình ngồi trong phòng với một câu hỏi mà không có cách nào để điều tra, hành động hay xác minh bất cứ điều gì.
Khung hỗ trợ có nhiều thành phần, và Thariq liệt kê chúng một cách rõ ràng. Đầu tiên là các công cụ — đây là những hành động cụ thể mà AI được phép thực hiện, như đọc tệp, tìm kiếm web hoặc gửi tin nhắn. Hãy nghĩ các công cụ như các nút trên bảng điều khiển: AI biết các nút tồn tại, biết mỗi nút làm gì và có thể nhấn chúng khi cần. Sau đó là hệ thống tệp (file system), đơn giản là bộ nhớ lưu trữ của máy tính — các thư mục và tệp mà tác nhân có thể đọc, ghi vào và sắp xếp. Thariq đặt ra rằng hệ thống tệp không chỉ là bộ nhớ lưu trữ; nó là một dạng kỹ thuật ngữ cảnh. Thay vì cố giữ mọi thứ trong bộ nhớ làm việc của AI cùng một lúc, bạn có thể chuyển thông tin sang tệp và để tác nhân đọc lại những gì nó cần khi cần.
Ngoài ra còn có các lệnh nhắc cốt lõi của tác nhân — những hướng dẫn thường trực cho tác nhân biết nó là ai và nên hành xử như thế nào. Một tệp đặc biệt gọi là CLAUDE.md phục vụ chức năng này trong hệ thống của Anthropic. Mỗi khi tác nhân khởi động hoặc khởi động lại, nó đọc CLAUDE.md trước tiên. Bạn có thể nghĩ nó như sổ tay nhân viên: nó cho tác nhân biết các quy tắc của công việc cụ thể này, những công cụ nào có sẵn, những gì nó nên và không nên làm.
Ngoài những yếu tố cơ bản đó, khung hỗ trợ bao gồm các kỹ năng (skills) — các gói hướng dẫn có thể tái sử dụng mà tác nhân có thể tải theo yêu cầu khi gặp phải nhiệm vụ chuyên biệt. Nó bao gồm các tác nhân phụ (sub-agents) — các tác nhân nhỏ mà tác nhân chính có thể tạo ra để làm việc song song trên các vấn đề con. Nó bao gồm tìm kiếm web, nén ngữ cảnh (quá trình tóm tắt cuộc hội thoại cũ để giải phóng bộ nhớ), móc nối (hooks — các điểm kiểm tra tự động chạy các kiểm tra xác minh) và bộ nhớ (lưu trữ thông tin liên tục qua các phiên). Mỗi thứ trong số này sẽ được giải thích trong chương của riêng nó. Điểm quan trọng bây giờ chỉ đơn giản là: một tác nhân mạnh mẽ là một hệ thống, không chỉ là một mô hình. Claude Agent SDK đóng gói toàn bộ hệ thống đó để bạn có thể triển khai mà không cần tự xây dựng từng phần.
III. Bash Là Tất Cả Những Gì Bạn Cần
Nếu có một ý tưởng nào trong workshop này mà Thariq đam mê nhất, đó chính là ý tưởng này. Bash là shell dòng lệnh — giao diện dựa trên văn bản nơi bạn gõ lệnh trực tiếp vào hệ điều hành. Đó là cửa sổ đen trên màn hình của lập trình viên nơi bạn có thể thấy các dòng như ls, grep hoặc cd. Nếu bạn chưa bao giờ sử dụng nó, bạn có thể nghĩ nó như "bảng điều khiển của lập trình viên" dành cho máy tính. Nó có trước các giao diện đồ họa, nó cực kỳ mạnh mẽ và hầu như mọi máy tính trên thế giới đều có nó.
Lập luận của Thariq là việc cho tác nhân AI quyền truy cập vào bash về cơ bản mạnh mẽ hơn so với việc cho nó một danh sách các công cụ tùy chỉnh. Đây là lý do. Khi bạn cho tác nhân một danh sách công cụ — chẳng hạn, công cụ searchEmail, công cụ calculateSum, công cụ downloadFile — bạn, với tư cách lập trình viên, đang quyết định trước những gì tác nhân được phép làm. Mỗi khả năng mới đòi hỏi bạn phải đi viết thêm một công cụ. Bạn luôn đi sau một bước so với nhu cầu của tác nhân. Nhưng khi bạn cho tác nhân quyền truy cập bash, bạn cấp cho nó quyền truy cập vào mọi phần mềm đã được cài đặt trên máy tính. Tác nhân có thể dùng grep để tìm kiếm một mẫu trong hàng nghìn tệp. Nó có thể dùng ffmpeg — một chương trình để xử lý video và âm thanh — để trích xuất các đoạn clip. Nó có thể dùng jq để phân tích dữ liệu có cấu trúc. Nó có thể cài đặt phần mềm mới nếu cần. Nó có thể kết hợp nhiều chương trình với nhau bằng toán tử pipe, chuyển đầu ra của một lệnh trực tiếp vào đầu vào của lệnh khác. Tính khả kết hợp đó chính là chìa khóa.
Thariq đưa ra một ví dụ cụ thể để làm cho điều này trở nên rõ ràng. Giả sử bạn có một tác nhân email và người dùng hỏi: "Tháng này tôi đã chi bao nhiêu tiền cho dịch vụ đặt xe?" Không có bash, tác nhân lấy mọi email đề cập đến Uber hay Lyft — có thể là hàng trăm email — và sau đó phải suy luận qua tất cả chúng cùng một lúc, cố gắng trích xuất số tiền và cộng chúng lại. Điều đó tốn kém về mặt nhận thức và dễ mắc lỗi, giống như đưa cho một người một chồng một trăm tờ giấy và nói "đọc hết tất cả rồi cho tôi biết tổng số." Với bash, tác nhân có thể dùng grep để trích xuất chỉ những dòng trong các email đó chứa số tiền, lưu chúng vào một tệp tạm, dùng lệnh khác để cộng chúng lại, và sau đó kiểm tra chéo một vài kết quả để xác nhận chúng hợp lý. Nhiệm vụ mơ hồ và ngập tràn trở thành một phép tính chính xác, có thể xác minh được.
Cách tiếp cận này hoạt động tốt như nhau cho các nhiệm vụ không liên quan đến kỹ thuật. Một tác nhân xử lý video có thể dùng ffmpeg để cắt một đoạn ghi âm cuộc họp mỗi khi từ "doanh thu" được phát hiện. Một tác nhân dữ liệu có thể đưa kết quả API qua jq để trích xuất chỉ những trường nó cần. Một tác nhân email có thể kết hợp API hộp thư đến với API danh bạ bằng bash scripting. Nguyên tắc cơ bản là bash coi mọi phần mềm hiện có như một khối xây dựng tiềm năng. Thay vì xây dựng lại bánh xe mỗi khi bạn cần một khả năng mới, tác nhân dùng bất kỳ công cụ nào đã tồn tại trên máy tính và kết hợp nó với mọi thứ khác.
Thariq cũng nêu ra một điểm thực tế về bộ nhớ. Khi tác nhân tính toán điều gì đó — chẳng hạn, danh sách chi phí đặt xe — nó có thể ghi kết quả đó vào một tệp trên đĩa. Sau này, nếu nó muốn kiểm tra lại công việc của mình hoặc thêm dữ liệu, nó không cần phải làm lại phép tính. Nó chỉ cần đọc tệp trở lại. Hệ thống tệp, kết hợp với bash, trở thành bộ nhớ linh hoạt, bền vững tồn tại bên ngoài cửa sổ ngữ cảnh. Đây là triết lý thiết kế trung tâm của Claude Agent SDK: hệ thống tệp không chỉ là bộ nhớ lưu trữ, nó là sự mở rộng của tư duy của tác nhân.
IV. Luồng Làm Việc và Tác Nhân
Thariq vạch ra ranh giới giữa hai loại thứ bạn có thể xây dựng với SDK: luồng làm việc và tác nhân. Hiểu sự phân biệt này sẽ giúp bạn không áp dụng sai công nghệ và không bị nhầm lẫn khi thấy từ "agent" được dùng để có nghĩa rất khác nhau.
Một tác nhân, như được mô tả trong phần mở đầu, là tự chủ. Nó tự quyết định các bước của mình. Bạn cho nó một mục tiêu bằng ngôn ngữ tự nhiên — "giúp tôi phân tích dữ liệu kinh doanh của mình và tạo bảng điều khiển" — và nó tự tìm ra cách đạt được điều đó. Nó có thể grep qua các tệp của bạn, viết một số code, chạy code, xem đầu ra, nhận thấy điều gì đó bất ngờ, hỏi bạn một câu hỏi làm rõ, rồi tiếp tục. Con đường không được biết trước. Tác nhân xây dựng nó khi tiến hành, phản hồi với những gì nó khám phá trên đường đi.
Luồng làm việc giống như máy bán hàng tự động hơn. Bạn xác định rõ đầu vào, bạn xác định rõ đầu ra, và các bước ở giữa phần lớn là cố định. Thariq đưa ra ví dụ về luồng làm việc GitHub Actions — một công cụ tự động hóa phổ biến được các nhóm phần mềm sử dụng. Bạn xác định: "Khi một pull request đến, chạy các bước này theo thứ tự này và tạo ra đầu ra này." Nó có cấu trúc, bị ràng buộc và có thể dự đoán được. Đầu ra có cấu trúc — tức là các phản hồi được định dạng theo cách cụ thể, có thể đọc được bằng máy — phù hợp tự nhiên ở đây. Nếu bạn muốn AI xem xét một đoạn code và luôn trả về đối tượng JSON với các trường như rating, summary và suggested_changes, đó là tư duy luồng làm việc.
Nhưng đây là sắc thái mà Thariq muốn bạn nắm giữ: ranh giới giữa luồng làm việc và tác nhân trong thực tế rất mờ nhạt. Ông đưa ra ví dụ về bot phân loại lỗi. Nhìn bề ngoài nghe có vẻ như một luồng làm việc đơn giản: một issue mới đến trên GitHub, bot đọc nó, gán nhãn và phân công cho đội ngũ đúng. Đầu vào, xử lý, đầu ra — sạch sẽ và có cấu trúc. Nhưng thực sự làm tốt công việc đòi hỏi bot phải sao chép kho mã nguồn, khởi tạo container Docker (một môi trường ảo độc lập nơi code có thể chạy an toàn), chạy code để tái tạo lỗi, kiểm tra xem các lỗi tương tự đã xuất hiện trước đây chưa, và sau đó đưa ra phán đoán về mức độ nghiêm trọng. Có rất nhiều bước linh hoạt, mở ở giữa, ngay cả khi đầu ra cuối cùng là một nhãn có cấu trúc. Sự phân biệt luồng làm việc-tác nhân ít liên quan đến định dạng đầu ra hơn và liên quan nhiều hơn đến mức độ tự do mà AI có trong việc quyết định cách đến đó.
Hướng dẫn thực tế của Thariq là mặc định chuyển sang tác nhân khi vấn đề lộn xộn và không được xác định rõ ràng, và sử dụng luồng làm việc — với đầu ra có cấu trúc — khi vấn đề được xác định rõ và các bước đã biết. Hầu hết các vấn đề kinh doanh trong thế giới thực, ông gợi ý, phức tạp hơn bề ngoài, và một luồng làm việc hoàn toàn cứng nhắc cuối cùng sẽ gãy khi thực tế không khớp với kế hoạch. SDK hỗ trợ cả hai mẫu, và cơ sở hạ tầng cơ bản giống nhau phục vụ cả hai cách tiếp cận.
V. Thiết Kế Vòng Lặp Tác Nhân
Mọi tác nhân, bất kể làm gì, đều hoạt động trong một vòng lặp. Nó không nhận một câu hỏi và trả về một câu trả lời. Nó đi qua một quy trình — thu thập thông tin, thực hiện hành động, kiểm tra kết quả — lặp đi lặp lại cho đến khi hoàn thành công việc hoặc bị kẹt. Thariq gọi đây là vòng lặp tác nhân, và hiểu ba giai đoạn của nó là khuôn khổ thực tế nhất ông cung cấp cho bất kỳ ai muốn xây dựng tác nhân của riêng họ.
Giai đoạn đầu tiên là thu thập ngữ cảnh. Ngữ cảnh, theo thuật ngữ AI, có nghĩa là tất cả thông tin mà mô hình hiện có để suy luận. Trước khi tác nhân có thể làm bất cứ điều gì hữu ích, nó cần phải hiểu tình huống. Đối với tác nhân lập trình như Claude Code, thu thập ngữ cảnh có nghĩa là tìm và đọc các tệp mã nguồn có liên quan. Đối với tác nhân email, nó có nghĩa là tìm kiếm hộp thư đến cho các tin nhắn có liên quan. Đối với tác nhân hỗ trợ khách hàng, nó có nghĩa là lấy lịch sử tài khoản của khách hàng. Thariq nói rằng bước này bị đánh giá thấp hơn bất kỳ bước nào khác — hầu hết các lập trình viên vội qua nó để đến phần thú vị (thực hiện hành động), nhưng mức độ tác nhân thu thập ngữ cảnh của nó gần như hoàn toàn quyết định chất lượng của những gì nó làm tiếp theo. Bác sĩ nắm rõ tiền sử bệnh nhân đưa ra chẩn đoán tốt hơn so với người đoán mò. Tác nhân thu thập ngữ cảnh có liên quan kỹ lưỡng cho kết quả tốt hơn so với tác nhân vội thực hiện hành động với thông tin không đầy đủ.
Giai đoạn thứ hai là thực hiện hành động. Đây là nơi tác nhân thực sự làm gì đó: viết code, gửi tin nhắn, sửa đổi tệp, gọi API, tạo báo cáo. Chất lượng của giai đoạn này phụ thuộc nhiều vào các công cụ và khả năng mà tác nhân được trao — đó là lý do tại sao sự lựa chọn giữa các công cụ được định nghĩa trước, bash và tạo code (được thảo luận trong chương tiếp theo) quan trọng đến vậy.
Giai đoạn thứ ba là xác minh. Sau khi thực hiện hành động, tác nhân nên kiểm tra xem nó có thực sự hoạt động không. Đây là giai đoạn Thariq nói hầu hết người mới bắt đầu bỏ qua hoàn toàn, và đó là điều phân biệt tác nhân đồ chơi với tác nhân đáng tin cậy. Đối với tác nhân lập trình, xác minh có thể có nghĩa là chạy code để xem nó có biên dịch không, sau đó chạy các bài kiểm thử tự động để xem nó có vượt qua không. Biên dịch là nhị phân — code hoặc biên dịch được hoặc không — điều này làm cho nó trở thành bước xác minh cực kỳ đáng tin cậy. Đối với tác nhân nghiên cứu, xác minh có thể có nghĩa là kiểm tra rằng mọi tuyên bố trong báo cáo được tạo ra đều được hỗ trợ bởi trích dẫn nguồn. Đối với tác nhân bảng tính, nó có thể có nghĩa là kiểm tra rằng các tổng cộng lại chính xác trước khi trả kết quả cho người dùng.
Thariq đưa ra quan sát quan trọng về những nhiệm vụ nào là ứng viên tốt cho các tác nhân: những nhiệm vụ có xác minh dễ dàng và đáng tin cậy. Code rất tốt vì bạn có thể lint nó (một linter là chương trình tự động kiểm tra code về các lỗi phổ biến và vi phạm phong cách), biên dịch nó và chạy nó. Các bước xác minh là khách quan và rẻ. Nghiên cứu chuyên sâu khó khăn hơn — bạn có thể yêu cầu trích dẫn, nhưng trích dẫn không chứng minh văn bản đại diện chính xác cho nguồn. Bạn càng gần được với xác minh tự động, khách quan thì tác nhân của bạn sẽ hoạt động đáng tin cậy hơn theo thời gian.
Một thành viên khán giả hỏi về lập kế hoạch — khi nào tác nhân nên viết ra kế hoạch trước khi hành động? Thariq đặt lập kế hoạch giữa việc thu thập ngữ cảnh và thực hiện hành động: tác nhân thu thập thông tin, xây dựng kế hoạch, sau đó thực thi. Các kế hoạch giúp AI suy nghĩ từng bước, cải thiện độ chính xác trên các nhiệm vụ phức tạp. Nhưng chúng thêm độ trễ, có nghĩa là thêm thời gian trước khi có bất cứ điều gì có thể nhìn thấy xảy ra. SDK hỗ trợ lập kế hoạch, và quyết định có bao gồm bước lập kế hoạch hay không phụ thuộc vào nhiệm vụ có đủ phức tạp để được hưởng lợi hay không. Thariq cũng lưu ý rằng SDK đi kèm với các công cụ danh sách việc cần làm — tác nhân có thể duy trì danh sách kiểm tra các nhiệm vụ con và đánh dấu chúng hoàn thành khi tiến hành, cho người dùng cập nhật tiến độ trực tiếp theo thời gian thực.
VI. Công Cụ, Bash và Tạo Code
Khi bạn xây dựng tác nhân, bạn có ba cách về cơ bản khác nhau để trao cho nó khả năng hành động trong thế giới: các công cụ được định nghĩa trước, lệnh bash và tạo code. Hầu hết các lập trình viên chỉ biết về lựa chọn đầu tiên. Thariq đi qua cả ba, giải thích khi nào mỗi cái là lựa chọn đúng.
Các công cụ được định nghĩa trước là các hàm bạn xác định trước với tư cách lập trình viên. Bạn viết một hàm gọi là searchDatabase, đưa cho nó một mô tả và nói với AI rằng nó có thể gọi hàm đó khi cần tìm kiếm cơ sở dữ liệu. AI gọi nó, nhận kết quả và tiếp tục suy luận. Các công cụ là tùy chọn có cấu trúc và đáng tin cậy nhất trong ba lựa chọn — AI luôn nhận kết quả có thể dự đoán, được xác định rõ. Chúng lý tưởng khi bạn cần phản hồi nhanh, không có lỗi và biết chính xác những hành động nào tác nhân sẽ cần thực hiện. Nhược điểm là các công cụ tốn kém về mặt ngữ cảnh. Mỗi công cụ bạn xác định tiêu thụ một phần bộ nhớ làm việc của AI chỉ bằng cách tồn tại, vì AI cần giữ toàn bộ danh sách các công cụ có sẵn trong đầu. Nếu bạn có năm mươi hoặc một trăm công cụ, chúng chiếm không gian có thể được dùng cho lý luận thực tế. Còn có một vấn đề sâu hơn nữa: các công cụ không thể kết hợp. Bạn không thể kết hợp công cụ tìm kiếm và công cụ tính toán thành một thao tác linh hoạt duy nhất theo cách bạn có thể xâu chuỗi các lệnh trong bash.
Bash là đầu kia của phổ. Như đã thiết lập trong chương trước, bash cho tác nhân quyền truy cập vào toàn bộ hệ sinh thái phần mềm của máy nó đang chạy trên. Nó có thể kết hợp — bạn có thể xâu chuỗi các lệnh với nhau. Nó hiệu quả về bộ nhớ — AI không cần giữ danh sách các lệnh có thể trong đầu, vì nó có thể chạy --help trên bất kỳ chương trình nào để tìm hiểu những gì nó có thể làm ngay lập tức. Điều này có nghĩa là có chi phí độ trễ nhỏ: tác nhân dành một chút thời gian để tìm hiểu những công cụ nào có sẵn thay vì biết trước. Nhưng đổi lại, tác nhân có thể xử lý các tình huống mà nhà thiết kế của nó chưa bao giờ dự kiến. Nó có thể tìm kiếm, chuyển đổi, kết hợp và xác minh dữ liệu theo những cách mà không danh sách công cụ cố định nào có thể hỗ trợ.
Tạo code là tùy chọn mạnh mẽ nhất và tốn kém nhất. Thay vì gọi một hàm được định nghĩa trước hoặc chạy một lệnh một dòng, tác nhân viết toàn bộ chương trình — bằng Python, TypeScript hoặc bất kỳ ngôn ngữ nào phù hợp — và sau đó thực thi nó. Điều này cho phép logic cực kỳ động, linh hoạt: lặp qua hàng nghìn bản ghi, kết hợp dữ liệu từ nhiều API, thực hiện các phép tính thống kê, tạo biểu đồ. Sự đánh đổi là thời gian: viết và thực thi code mất nhiều thời gian hơn một lệnh gọi công cụ hoặc lệnh bash. Nó cũng có thể yêu cầu lint code được tạo ra trước để bắt lỗi trước khi chạy, và trong các ngôn ngữ biên dịch cần bước biên dịch. Nhưng khi nhiệm vụ thực sự phức tạp — xây dựng quy trình dữ liệu tùy chỉnh, chuyển đổi tập dữ liệu lộn xộn, tạo tài liệu được định dạng — tạo code là công cụ duy nhất đủ mạnh.
Tổng hợp của Thariq rất thực tế và rõ ràng. Sử dụng các công cụ được định nghĩa trước cho các hành động nguyên tử nơi bạn muốn tối đa kiểm soát và khả năng hiển thị. Trong Claude Code, thao tác ghi tệp là công cụ được định nghĩa trước — không phải lệnh bash — cụ thể vì Anthropic muốn người dùng thấy những gì sắp được viết và phê duyệt trước khi xảy ra. Bất kỳ hành động nào không thể đảo ngược (bạn không thể hoàn tác nó) hoặc hiển thị bên ngoài (nó gửi email, đăng tin nhắn, tính tiền thẻ tín dụng) nên là công cụ được định nghĩa trước, vì điều đó cho bạn điểm kiểm tra tự nhiên nơi con người có thể xem xét trước khi tiến hành. Sử dụng bash cho các thao tác có thể kết hợp, khám phá như tìm kiếm thư mục, grep qua nhật ký, quản lý tệp tạm hoặc kiểm tra xem điều gì đó có hoạt động không. Sử dụng tạo code cho các nhiệm vụ đòi hỏi tính linh hoạt và trí tuệ thực sự: kết hợp dữ liệu từ nhiều API, thực hiện phân tích hoặc tạo đầu ra phong phú như tài liệu được định dạng hay bảng điều khiển.
Một thành viên khán giả đặt câu hỏi thông minh tiếp theo: điều gì về việc ngăn chặn sự bùng nổ ngữ cảnh khi một lệnh gọi công cụ trả về lượng dữ liệu khổng lồ? Câu trả lời của Thariq đơn giản và thực tế: lưu đầu ra công cụ vào tệp ngay lập tức, và để công cụ chỉ trả về đường dẫn tệp. Bằng cách này kết quả lớn tồn tại trên đĩa thay vì trong cửa sổ ngữ cảnh. Tác nhân có thể đọc các phần cụ thể của nó sau khi cần, thay vì giữ tất cả trong bộ nhớ làm việc cùng một lúc.
VII. Kỹ Năng — Tiết Lộ Ngữ Cảnh Dần Dần
Kỹ năng là một trong những tính năng mới nhất của Claude Agent SDK — được phát hành chỉ hai tuần trước workshop này — và chúng đại diện cho một giải pháp thông minh cho một vấn đề chỉ trở nên rõ ràng khi bạn bắt đầu xây dựng các tác nhân phức tạp hơn.
Vấn đề là thế này: bạn không thể cung cấp cho tác nhân tất cả các hướng dẫn mà nó có thể cần ngay từ đầu. Nếu bạn cố gắng, những hướng dẫn đó sẽ tiêu thụ lượng lớn không gian cửa sổ ngữ cảnh, chiếm chỗ của công việc thực tế. Nhưng nếu bạn không cung cấp cho tác nhân đủ hướng dẫn, nó sẽ không biết cách xử lý các nhiệm vụ chuyên biệt. Làm thế nào để bạn cung cấp cho tác nhân chuyên môn chi tiết khi nó cần, mà không tải xuống mọi thứ ngay từ đầu?
Câu trả lời là tiết lộ ngữ cảnh dần dần — một cụm từ chỉ đơn giản có nghĩa là hiển thị cho tác nhân thêm thông tin dần dần khi nó trở nên liên quan. Kỹ năng là cách SDK thực hiện ý tưởng này. Một kỹ năng về cơ bản là một thư mục tệp nằm trên hệ thống tệp. Bên trong thư mục đó là các hướng dẫn chi tiết, ở cấp độ chuyên gia về cách làm điều gì đó cụ thể — cách tạo tệp DOCX được định dạng đúng cách, cách thực hiện thiết kế web front-end, cách gọi một API cụ thể một cách chính xác. Khi tác nhân gặp một nhiệm vụ đòi hỏi chuyên môn đó, nó đọc kỹ năng — nó "mở thư mục" và tải vào những hướng dẫn đó — và sau đó tiến hành với đầy đủ kiến thức về cách thực hiện công việc.
Thariq đưa ra một ví dụ sinh động về lý do tại sao điều này có giá trị. Anthropic gần đây đã phát hành kỹ năng thiết kế front-end. Nó được viết bởi một trong những kỹ sư AI giỏi nhất của Anthropic chuyên về thiết kế front-end, và nó mã hóa mọi thứ kỹ sư đó biết về việc tạo ra giao diện tốt: nguyên tắc bố cục, lựa chọn màu sắc, các mẫu thiết kế đáp ứng, cân nhắc về khả năng tiếp cận, cách cấu trúc HTML và CSS để tạo bằng AI. Kiến thức đó bây giờ tồn tại trong tệp kỹ năng, và bất kỳ tác nhân nào tải nó đều ngay lập tức có quyền truy cập vào cùng một chuyên môn. Kỹ năng là cách nắm bắt chuyên môn của con người ở dạng có thể truy xuất, có thể kết hợp.
Một thành viên khán giả đặt câu hỏi cấu trúc tốt: thứ tự ưu tiên là gì khi tệp kỹ năng và tệp CLAUDE.md chính đều chứa hướng dẫn? Câu trả lời thành thật của Thariq là chưa có thực tiễn tốt nhất rõ ràng — công nghệ còn quá mới. Mô hình tư duy hiện tại của ông là CLAUDE.md chứa các quy tắc thường trực luôn áp dụng, trong khi kỹ năng chứa chuyên môn theo tình huống mà tác nhân tải khi cần. Phép tương tự đúng có thể là sổ tay chính sách công ty (CLAUDE.md, luôn có hiệu lực) so với sổ tay chuyên gia mà một thành viên nhóm mở khi họ đảm nhận một loại dự án cụ thể (kỹ năng, được tải theo yêu cầu).
Ông cũng trả lời câu hỏi về việc liệu kỹ năng cuối cùng có được tích hợp vào chính mô hình hay không — có nghĩa là các mô hình AI tương lai sẽ chỉ biết cách làm tất cả những điều này mà không cần tệp hướng dẫn riêng biệt? Câu trả lời rộng rãi là có: khi các mô hình cải thiện, chúng sẽ xử lý nhiều nhiệm vụ hơn mà không cần hướng dẫn rõ ràng. Nhưng kỹ năng là giải pháp tốt nhất hiện tại cho các nhiệm vụ nằm ngoài những gì mô hình xử lý tự nhiên tốt. Thariq đưa ra một lời khuyên thẳng thắn và quan trọng: xem xét lại và viết lại code tác nhân của bạn mỗi sáu tháng, vì mô hình cơ bản sẽ thay đổi đủ để nhiều cách giải quyết và hướng dẫn rõ ràng bạn đã tích hợp có thể không còn cần thiết nữa, hoặc thậm chí có thể cản trở khả năng gốc được cải thiện của mô hình. Các tác nhân tốt nhất là các tác nhân gọn nhẹ tin tưởng mô hình làm những gì nó giỏi và chỉ thêm hướng dẫn rõ ràng nơi thực sự có khoảng trống.
VIII. Bảo Mật và Quyền Hạn — Phòng Thủ Phô Mai Thụy Sĩ
Một thành viên khán giả đặt ra điều mà có lẽ là mối lo ngại rõ ràng nhất về toàn bộ triết lý bash-first: nếu tác nhân có thể chạy bất kỳ lệnh nào trên máy tính, điều gì ngăn kẻ xấu chiếm đoạt nó? Đây là một câu hỏi hợp lý và nghiêm trọng, và câu trả lời của Thariq giới thiệu một khuôn khổ gọi là phòng thủ phô mai Thụy Sĩ.
Phòng thủ phô mai Thụy Sĩ là một khái niệm kinh điển từ kỹ thuật an toàn. Hãy tưởng tượng một chồng các lát phô mai Thụy Sĩ, mỗi lát đầy lỗ hổng. Không có lát nào đặc hoàn toàn — mỗi lát đều có điểm yếu. Nhưng khi bạn xếp đủ lát lại với nhau, các lỗ hiếm khi thẳng hàng và cùng nhau chúng chặn hầu hết mọi thứ đi qua. Bảo mật trong một hệ thống phức tạp hoạt động theo cùng một cách: không có lớp nào hoàn hảo, nhưng nhiều lớp không hoàn hảo cùng nhau tạo ra bảo vệ hiệu quả.
Đối với Claude Agent SDK, các lớp hoạt động như sau. Ở lớp mô hình — bên trong chính AI — Anthropic thực hiện công việc căn chỉnh rộng rãi. Căn chỉnh là quá trình huấn luyện AI hành xử theo những cách an toàn và có lợi, từ chối các yêu cầu có hại và gắn cờ các hướng dẫn đáng ngờ. Mô hình đã được dạy để nhận ra khi nào nó đang bị thao túng để làm điều gì đó nguy hiểm. Ở lớp khung hỗ trợ — cơ sở hạ tầng phần mềm xung quanh mô hình — SDK bao gồm hệ thống cấp quyền riêng và các lệnh nhắc an toàn của nó. Một cách quan trọng, nó chạy bộ phân tích cú pháp (parser) trên mọi lệnh bash mà tác nhân cố gắng thực thi. Bộ phân tích cú pháp là một chương trình đọc và diễn giải code hoặc lệnh để hiểu những gì chúng thực sự làm. Vì SDK phân tích cú pháp các lệnh bash, nó có thể phát hiện các mẫu đáng ngờ — như nỗ lực xóa các tệp hệ thống hoặc gửi dữ liệu đến máy chủ không xác định — trước khi chúng xảy ra. Thariq nhấn mạnh rằng bộ phân tích cú pháp này không phải là thứ bạn muốn tự xây dựng; đó là một trong những tính năng an toàn có giá trị nhất của SDK.
Lớp thứ ba là sandboxing (hộp cát). Sandbox là môi trường chứa, cô lập nơi code có thể chạy mà không ảnh hưởng đến bất cứ điều gì bên ngoài các bức tường của nó. Nếu một tác nhân bị xâm phạm chạy trong sandbox với quyền truy cập mạng bị hạn chế và không có quyền truy cập vào các tệp ngoài thư mục được chỉ định của nó, thiệt hại mà nó có thể gây ra bị hạn chế nghiêm trọng. Thariq mô tả điều ông gọi là "bộ ba chết chóc" của các rủi ro bảo mật tác nhân: khả năng thực thi code, khả năng sửa đổi hệ thống tệp và khả năng đánh cắp dữ liệu — tức là bí mật sao chép và gửi dữ liệu đó đến máy chủ bên ngoài. Nếu bạn sandbox kết nối mạng để tác nhân không thể thực hiện yêu cầu đi ra ngoài đến các máy chủ tùy ý, chân thứ ba của bộ ba đó bị cắt đứt, và một cuộc tấn công thành công trở nên ít nguy hiểm hơn nhiều.
Thariq cũng đề cập đến kiểm soát truy cập dựa trên vai trò — thực hành cấp cho người dùng hoặc dịch vụ khác nhau các mức quyền khác nhau. Khuyến nghị của ông là xử lý điều này ở cấp độ cơ sở hạ tầng, không phải bên trong chính tác nhân. Bạn cung cấp khóa API (thông tin xác thực truy cập) được giới hạn chỉ trong các thao tác cần thiết. Bạn có thể tạo các máy chủ proxy ngăn chặn các yêu cầu API và thực thi chính sách trước khi chúng đến dịch vụ cơ bản. Và bạn có thể tận dụng sự nhạy cảm của mô hình đối với phản hồi: nếu backend của bạn ném ra thông báo lỗi — "quyền bị từ chối khi truy cập bản ghi này" — tác nhân sẽ đọc lỗi đó, hiểu nó và ngừng thử. Khả năng tích hợp của mô hình để đọc và phản hồi các thông báo lỗi tự nó là một cơ chế bảo mật có thể được thiết kế một cách có chủ ý.
IX. Demo Trực Tiếp — Tác Nhân Pokémon
Để làm cho mọi thứ trở nên cụ thể, Thariq xây dựng một tác nhân trực tiếp từ đầu trong workshop. Ông chọn Pokémon làm miền chủ đề một cách cố ý — nó có API lớn, có sẵn công khai (giao diện web để yêu cầu dữ liệu theo chương trình) với hàng nghìn bản ghi và các mối quan hệ phức tạp, mô phỏng loại nguồn dữ liệu lộn xộn trong thế giới thực mà khán giả của ông phải đối mặt trong kinh doanh của họ. Và vì ông không phải là chuyên gia về Pokémon thi đấu, tác nhân phải thực sự tìm hiểu thay vì chỉ xác nhận những gì Thariq đã biết.
Bước đầu tiên của ông là để Claude Code — trợ lý lập trình AI — xây dựng thư viện cho ông. Ông đưa cho nó một lệnh nhắc đơn giản: "Tìm kiếm PokéAPI, hiểu cách nó hoạt động và tạo một thư viện TypeScript bọc nó lại." TypeScript là ngôn ngữ lập trình thường được sử dụng cho các ứng dụng web. Thư viện, trong lập trình, là tập hợp các hàm được xây dựng sẵn giúp một nhiệm vụ phức tạp trở nên dễ dàng hơn — trong trường hợp này, thay vì tác nhân phải tìm hiểu API thô mỗi lần, nó có thể gọi một hàm sạch như getByName("pikachu") và nhận lại kết quả có cấu trúc. Claude Code khám phá API, đọc tài liệu của nó và tạo ra một thư viện với các hàm để tìm nạp Pokémon theo tên, liệt kê tất cả Pokémon, lấy chi tiết loài, tra cứu khả năng và nhiều thứ khác.
Sau đó đến phần quan trọng: Claude Code cũng tạo ra tệp CLAUDE.md cho dự án cụ thể này. CLAUDE.md này nói với tác nhân Pokémon các quy tắc của môi trường của nó — cụ thể, rằng nó nên sử dụng thư viện TypeScript này, rằng nó nên viết các script có thể thực thi trong thư mục examples để trả lời các truy vấn thay vì chỉ trả lời từ bộ nhớ, và rằng nó nên chạy những script đó và sử dụng dữ liệu thực tế. Tệp CLAUDE.md đó, kết hợp với thư viện TypeScript, về cơ bản là toàn bộ thiết kế tác nhân. Không có code điều phối phức tạp. Chỉ có một tệp hướng dẫn rõ ràng và một bộ công cụ gọn gàng. Đây là điều Thariq muốn nói khi ông nói về kỹ thuật ngữ cảnh: hành vi của tác nhân được hình thành chủ yếu bởi những gì có trong tệp hướng dẫn và những công cụ nào có sẵn cho nó, không phải bởi logic phức tạp trong code xung quanh.
Sau đó ông trình diễn sự khác biệt giữa cách tiếp cận bash-và-tạo-code và cách tiếp cận chỉ sử dụng công cụ truyền thống. Đối với phiên bản chỉ sử dụng công cụ, ông đã định nghĩa trước năm hàm: getPokemon, getPokemonSpecies, getPokemonAbility, getPokemonType và getMove. Khi người dùng hỏi "các Pokémon nước thế hệ 2 là gì?" phiên bản chỉ sử dụng công cụ gặp khó khăn — truy vấn cụ thể đó đòi hỏi phải lặp qua hàng trăm Pokémon và lọc theo cả thế hệ lẫn loại, đây không phải là điều mà bất kỳ công cụ nào trong năm công cụ được định nghĩa trước được xây dựng để làm. Phiên bản bash-và-tạo-code, ngược lại, viết một script, lặp qua danh sách Pokémon của PokéAPI, kiểm tra loại và thế hệ của từng cái và trả về kết quả đã lọc. Nó xử lý một truy vấn chưa bao giờ được dự kiến trong thiết kế ban đầu.
Phần ấn tượng nhất của demo liên quan đến phân tích Pokémon thi đấu sử dụng dữ liệu từ Smogon, một cơ sở dữ liệu trực tuyến lớn về chiến lược Pokémon thi đấu. Dữ liệu này không có sẵn qua PokéAPI — Thariq chỉ đơn giản tải xuống một tệp văn bản Smogon và đặt nó vào thư mục dữ liệu của dự án. Không có phân tích cú pháp đặc biệt, không có cơ sở dữ liệu có cấu trúc, chỉ là tệp văn bản thô. Khi được hỏi "Tôi muốn xây dựng đội dựa trên Venusaur — hãy đưa cho tôi gợi ý dựa trên dữ liệu Smogon," tác nhân bắt đầu grep qua tệp văn bản. Nó tìm thấy hồ sơ của Venusaur, sau đó tìm kiếm các Pokémon khác đề cập đến Venusaur như là lựa chọn hỗ trợ, chạy script để đếm tần suất các đối tác khác nhau xuất hiện cùng nhau và tập hợp đề xuất đội đầy đủ. Tác nhân không cần API Smogon. Nó cần bash và một tệp văn bản. Đó là sức mạnh của cách tiếp cận: tác nhân đã tìm ra cách trích xuất thông tin chi tiết có cấu trúc từ dữ liệu phi cấu trúc, sử dụng các công cụ đã tồn tại hàng thập kỷ.
X. Bài Tập Tác Nhân Bảng Tính
Thay vì chỉ trình diễn tác nhân của mình, Thariq biến workshop thành tương tác bằng cách yêu cầu khán giả cùng suy nghĩ về tác nhân bảng tính. Tác nhân bảng tính là trường hợp sử dụng thực tế, dễ hiểu — hầu hết các doanh nghiệp vận hành trên bảng tính — và nó minh họa vòng lặp tác nhân ba giai đoạn (thu thập ngữ cảnh, thực hiện hành động, xác minh) trong một miền mà mọi người đều hiểu.
Câu hỏi đầu tiên là: tác nhân tìm kiếm bảng tính như thế nào? Bảng tính là cấu trúc hai chiều — hàng và cột — điều này làm cho nó phức tạp hơn so với việc tìm kiếm tệp văn bản phẳng. Khán giả suy nghĩ. Ai đó gợi ý chuyển đổi tệp sang định dạng CSV (định dạng văn bản thuần túy nơi các giá trị được phân cách bằng dấu phẩy) và sử dụng grep. Khởi đầu tốt — tác nhân có thể nhanh chóng quét để tìm từ khóa. Nhưng Thariq chỉ ra giới hạn: nếu người dùng hỏi "tổng doanh thu năm 2026 là bao nhiêu?" tác nhân cần tìm cột doanh thu và sau đó lọc hàng theo năm. Chỉ có tiêu đề cột, được khám phá bằng grep, không cho bạn biết hàng nào tương ứng với năm 2026.
Gợi ý khác: sử dụng AWK, lệnh Unix cũ và mạnh mẽ để xử lý các tệp văn bản có cấu trúc. AWK có thể khớp các mẫu trong các cột cụ thể và thực hiện số học kịp thời, làm cho nó có năng lực đáng kể hơn grep cho dữ liệu dạng bảng. Sau đó ai đó đề xuất giải pháp thanh lịch nhất: tải CSV vào SQLite và truy vấn nó bằng SQL. SQLite là một công cụ cơ sở dữ liệu nhẹ có thể chạy hoàn toàn trên một tệp duy nhất — không cần máy chủ. SQL là ngôn ngữ tiêu chuẩn để truy vấn dữ liệu có cấu trúc, và các mô hình AI được huấn luyện vô cùng tốt trên SQL vì có rất nhiều SQL trên internet. Thariq sáng lên khi nghe gợi ý này: nếu bạn có thể dịch nguồn dữ liệu của mình thành giao diện SQL, tác nhân có thể truy vấn nó với độ chính xác cao và xử lý hầu hết mọi câu hỏi mà người dùng có thể đặt ra. Bước chuyển đổi đó — chuyển đổi nguồn dữ liệu lộn xộn thành thứ gì đó có thể truy vấn được — là một trong những cách tiếp cận kiến trúc mạnh mẽ nhất bạn có thể thực hiện khi thiết kế giao diện dữ liệu tác nhân.
Cách tiếp cận thứ tư xuất hiện khi Thariq nhắc nhở khán giả rằng các tệp XLSX — định dạng Excel tiêu chuẩn — thực sự là các tệp ZIP chứa các tệp XML. XML là định dạng văn bản có cấu trúc, và bạn có thể chạy các truy vấn dựa trên đường dẫn trực tiếp trên nó, hoặc sử dụng các thư viện hiểu định dạng Excel gốc. Vì vậy, bạn có ít nhất bốn cách tiếp cận cho tác nhân bảng tính: grep trên tiêu đề, AWK cho việc lọc cấp độ hàng, wrapper SQLite hoặc truy vấn đường dẫn XML. Lời khuyên của Thariq: đừng dừng lại ở cách tiếp cận đầu tiên hoạt động. Thử nhiều chiến lược, chạy các bài kiểm thử, xem các bản ghi tác nhân đang chạy của bạn và xem cách nào nó xử lý tốt nhất.
Đối với giai đoạn hành động — thực hiện thay đổi đối với bảng tính — các giao diện trông rất giống với các giao diện tìm kiếm. Chèn một hàng trông giống như viết mảng hai chiều. Chạy SQL UPDATE sửa đổi các bản ghi. Chỉnh sửa XML cơ bản hoạt động cho cả đọc và ghi. Tính đối xứng giữa đọc và ghi là một nguyên tắc thiết kế hữu ích: nếu bạn xây dựng giao diện tìm kiếm tốt, bạn có thể đã có hầu hết những gì bạn cần cho giao diện hành động.
Xác minh cho tác nhân bảng tính đòi hỏi sự chú ý cụ thể. Tác nhân nên kiểm tra các giá trị null — ô trống nơi dữ liệu được mong đợi. Nó nên tìm kiếm các bất thường, như ô thay đổi bất ngờ hoặc tổng không cộng lại đúng. Một mẫu mạnh mẽ mà Thariq mô tả là tác nhân phụ đối kháng: sau khi tác nhân chính hoàn thành công việc, khởi tạo tác nhân thứ hai không biết gì về những gì tác nhân đầu tiên đã làm, cho nó thấy đầu ra và yêu cầu nó phê bình kết quả. Vì tác nhân thứ hai không gắn bó với công việc, nó sẽ nhận thấy những điểm không nhất quán và lỗi mà tác nhân đầu tiên có thể đã hợp lý hóa. Khi lý luận AI cải thiện, bước xác minh đối kháng này trở nên ngày càng đáng tin cậy hơn.
Một thành viên khán giả đặt ra vấn đề quan trọng về khả năng đảo ngược — điều gì xảy ra nếu tác nhân xóa toàn bộ bảng tính? Thariq coi đây là câu hỏi thiết kế cơ bản, không chỉ là câu hỏi kỹ thuật. Miền bạn đang xây dựng có thể đảo ngược như thế nào? Code có thể đảo ngược cao vì mọi thay đổi được git theo dõi, một hệ thống kiểm soát phiên bản ghi lại lịch sử đầy đủ của mọi sửa đổi. Claude Code sử dụng git liên tục — Thariq đề cập rằng ông không còn tự gõ lệnh git nữa; tác nhân xử lý chúng. Các tác nhân sử dụng máy tính nhấp xung quanh giao diện đồ họa gần như không thể đảo ngược, vì mỗi nhấp chuột làm tăng thêm trạng thái. Tác nhân bảng tính nằm ở giữa. Khuyến nghị của ông: thiết kế khả năng đảo ngược từ đầu. Lưu trữ các điểm kiểm tra trạng thái để nếu có điều gì đó không ổn, người dùng có thể nói "quay lại trước thay đổi đó." Ông đề cập rằng ai đó đã xây dựng công cụ "du hành thời gian" cho tác nhân lập trình cho phép chính xác loại khôi phục này. Nguyên tắc cơ bản — rằng các tác nhân nên có thể hoàn tác hành động của họ, ít nhất cho các thao tác quan trọng — áp dụng cho bất kỳ miền nào có thể xảy ra sai sót, tức là mọi miền.
XI. Tác Nhân Phụ và Quản Lý Ngữ Cảnh
Một thành viên khán giả đặt câu hỏi đến gần một trong những hạn chế thực tế quan trọng nhất của các tác nhân AI: "Tất cả các tác nhân có chia sẻ cùng cửa sổ ngữ cảnh không?" Câu trả lời dẫn Thariq vào một trong những phần thú vị nhất về mặt kỹ thuật của workshop.
Để nhắc lại cửa sổ ngữ cảnh là gì: đó là bộ nhớ làm việc của AI. Mọi thứ tác nhân đang "suy nghĩ về" hiện tại — hướng dẫn của nó, lịch sử cuộc hội thoại, kết quả của các lệnh gọi công cụ, các tệp nó đã đọc, code nó đã viết — phải vừa trong cửa sổ này. Hầu hết các mô hình AI hiện tại có cửa sổ ngữ cảnh được đo bằng hàng trăm nghìn token (một token xấp xỉ một từ hoặc một vài ký tự). Điều đó nghe có vẻ lớn, nhưng một tác nhân chạy lâu có thể tiêu thụ nó nhanh chóng: đọc một trăm tệp, chạy hàng chục script, xem lại đầu ra của từng cái và bạn đã tiêu thụ một lượng bộ nhớ khổng lồ. Khi cửa sổ ngữ cảnh đầy, tác nhân mất suy nghĩ trước đó của mình trừ khi có điều gì đó được làm để bảo toàn các phần quan trọng.
Các tác nhân phụ là một trong những công cụ quan trọng nhất để quản lý ngữ cảnh. Tác nhân phụ đơn giản là một phiên bản AI mới mà tác nhân chính tạo ra để xử lý một nhiệm vụ con cụ thể. Tác nhân phụ bắt đầu với cửa sổ ngữ cảnh sạch, thực hiện công việc của nó và chỉ trả về câu trả lời — một bản tóm tắt chắt lọc về những gì nó tìm thấy — cho tác nhân chính. Tác nhân chính không bao giờ phải giữ tất cả những suy nghĩ khám phá, đang tiến hành của nhiệm vụ con trong bộ nhớ của chính nó. Nó chỉ nhận kết quả.
Thariq đưa ra ví dụ bảng tính: nếu bạn có một sổ làm việc với ba trang và cần phân tích cả ba, tác nhân chính có thể tạo ra ba tác nhân phụ song song — một cho mỗi trang. Mỗi tác nhân phụ đọc trang của nó đầy đủ, suy luận trên nó và trả về một bản tóm tắt. Tác nhân chính sau đó suy luận trên ba bản tóm tắt thay vì ba trang đầy đủ. Công việc khám phá tốn kém được phân phối; tác nhân chính vẫn gọn nhẹ. Chạy các tác nhân phụ song song có nghĩa là tất cả ba có thể làm việc đồng thời, điều này cũng giảm tổng thời gian.
Điều này nghe có vẻ đơn giản, nhưng Thariq chỉ ra rằng các tác nhân phụ song song với quyền truy cập bash thực sự là một trong những vấn đề kỹ thuật khó khăn hơn trong thiết kế tác nhân. Race conditions — tình huống mà hai tiến trình cố gắng đọc hoặc ghi cùng một tệp tại cùng một thời điểm và tạo ra kết quả bị hỏng — là rủi ro thực sự. Xung đột hệ thống tệp đòi hỏi điều phối cẩn thận. Claude Agent SDK xử lý sự phức tạp này nội bộ, sử dụng kiến trúc được mượn trực tiếp từ việc triển khai đa tác nhân của Claude Code. Thariq nói ông chưa thấy framework nào khác xử lý các tác nhân phụ bash song song một cách mạnh mẽ như vậy.
Quản lý ngữ cảnh cũng có chiều hướng trải nghiệm người dùng trực tiếp. Thariq quan sát rằng khi ông nói chuyện với những người dùng Claude Code nâng cao, một số trong số họ đề cập đến việc đang ở "compact thứ năm." Nén (compaction), còn gọi là nén ngữ cảnh, là quá trình tóm tắt các phần cũ hơn của cuộc hội thoại để giải phóng chỗ cho công việc mới. Bản tóm tắt thay thế lịch sử đầy đủ, bảo tồn các sự kiện chính trong khi loại bỏ những trao đổi chi tiết. Thariq bản thân nói ông hiếm khi nén — đối với công việc lập trình, trạng thái tồn tại trong các tệp của codebase, không phải trong lịch sử chat. Nếu ông hoàn thành một nhiệm vụ và bắt đầu nhiệm vụ mới, Claude Code có thể nhìn vào git diff (tóm tắt những gì đã thay đổi trong code) và hiểu trạng thái hiện tại mà không cần toàn bộ lịch sử cuộc hội thoại.
Đối với các tác nhân được triển khai cho người dùng không chuyên kỹ thuật — tác nhân dịch vụ khách hàng, trợ lý bảng tính — thách thức quản lý ngữ cảnh phức tạp hơn, vì người dùng không hiểu khái niệm cửa sổ ngữ cảnh và không nên cần phải hiểu. Thách thức thiết kế trải nghiệm người dùng là: bạn có thể đặt lại hoặc nén trạng thái cuộc hội thoại một cách khéo léo mà người dùng không nhận thấy không? Trong tác nhân bảng tính, hầu hết trạng thái nằm trong chính bảng tính, không phải trong lịch sử cuộc hội thoại, vì vậy tác nhân có thể không cần mang nhiều thứ qua các lượt. Lưu trữ sở thích người dùng vào tệp khi chúng được diễn đạt — để tác nhân nhớ chúng trong các phiên tương lai mà không cần bản ghi đầy đủ — là một cách tiếp cận thực tế. Mục tiêu cơ bản là giảm thiểu sử dụng ngữ cảnh mà không làm giảm trải nghiệm của người dùng.
XII. Móc Nối — Xác Minh Xác Định
Một thành viên khán giả hỏi về hooks, và Thariq nói ông chưa nói về chúng đủ nhiều. Hooks là một trong những tính năng bị đánh giá thấp nhất trong SDK, và chúng giải quyết một vấn đề trở nên rất rõ ràng khi tác nhân của bạn đang chạy trong thế giới thực: tác nhân có tính xác suất, có nghĩa là nó không luôn hành xử theo cùng một cách, nhưng đôi khi bạn cần một số thứ xảy ra với sự chắc chắn tuyệt đối.
Một hook là một đoạn code thực thi tự động tại một thời điểm cụ thể trong hoạt động của tác nhân — trước lệnh gọi công cụ, sau lệnh gọi công cụ, khi một phản hồi được tạo ra. Bạn đăng ký trình xử lý hook trong SDK, và mỗi khi sự kiện đó kích hoạt, trình xử lý của bạn chạy. Không giống như lý luận của chính AI — linh hoạt và đôi khi không thể đoán trước — hooks là xác định. Chúng luôn chạy. Chúng luôn làm chính xác những gì bạn đã lập trình chúng làm.
Thariq đưa ra một số ví dụ làm cho khái niệm này trở nên cụ thể ngay lập tức. Giả sử bạn có tác nhân bảng tính và bạn muốn chạy kiểm tra xác thực sau mỗi thay đổi mà tác nhân thực hiện — xác nhận rằng các tổng vẫn cộng lại, rằng không có ô bắt buộc nào trống, rằng các giá trị nằm trong phạm vi mong đợi. Bạn đăng ký một hook kích hoạt sau mỗi lệnh gọi công cụ và chạy xác thực đó. Tác nhân không thể bỏ qua nó. Nó chạy mỗi lần, dù tác nhân vừa làm gì. Một ví dụ khác: người dùng đang chỉnh sửa bảng tính trong thời gian thực trong khi tác nhân cũng đang làm việc trên nó. Một hook có thể phát hiện rằng tệp đã thay đổi từ bên ngoài, tạm dừng tác nhân và đưa tin nhắn vào ngữ cảnh nói "người dùng đã sửa đổi cột C — vui lòng đọc lại trạng thái hiện tại trước khi tiếp tục." Tác nhân nhận được cập nhật trực tiếp về môi trường của nó mà không cần liên tục kiểm tra.
Hooks cũng giải quyết một trong các chế độ lỗi cụ thể mà Thariq quan sát trong demo Pokémon của mình. Miền Pokémon là thứ mà các kỹ sư gọi là "in-distribution" đối với mô hình — có nghĩa là mô hình được huấn luyện trên rất nhiều dữ liệu Pokémon và có nhiều sự kiện được ghi nhớ. Đôi khi tác nhân sẽ chỉ đơn giản trả lời từ bộ nhớ thay vì chạy script để kiểm tra dữ liệu thực tế. Đây là vấn đề vì tác nhân có thể trả lời dựa trên dữ liệu huấn luyện cũ, không phải tệp Smogon cập nhật trên đĩa. Một hook có thể ngăn chặn phản hồi trước khi đến người dùng, kiểm tra xem phản hồi có dựa trên việc thực thi script thực tế không, và nếu không, đưa phản hồi vào: "Vui lòng đảm bảo bạn đã viết script và đọc từ tệp dữ liệu thực tế." Tác nhân nhận phản hồi đó, xem xét lại cách tiếp cận của mình và thử lại. Đây là hành vi xác định được áp đặt lên trên lý luận xác suất — và đó là giải pháp đáng tin cậy hơn nhiều so với việc cố gắng ngăn hành vi thông qua kỹ thuật lệnh nhắc đơn thuần.
Thariq chỉ đến việc Claude Code sử dụng hooks như một minh họa. Claude Code kích hoạt hook bất cứ khi nào tác nhân cố gắng ghi vào tệp mà nó chưa đọc. Hook ném ra lỗi: "Bạn chưa đọc tệp này. Hãy thử đọc nó trước." Điều này ngăn một lỗi phổ biến và tốn kém — tác nhân ghi đè lên tệp dựa trên các giả định thay vì kiến thức thực tế về nội dung hiện tại của nó. Một quy tắc xác định đó tiết kiệm vô số giờ gỡ lỗi các ghi đè không chính xác. Hooks, theo nghĩa này, là cơ chế mà bạn có thể lấy những thực tiễn tốt nhất bạn phát hiện qua quan sát và đưa chúng vào hệ thống một cách cứng rắn để chúng luôn được thực thi, bất kể mô hình đang cảm thấy thế nào trong bất kỳ phiên nào.
XIII. Hỏi & Đáp — Mở Rộng Quy Mô, Tái Tạo và Thế Giới Thực
Phần cuối của workshop mở ra thành phiên hỏi đáp bao gồm các câu hỏi thực tế mà bất kỳ lập trình viên hay doanh nhân nào sẽ phải đối mặt khi họ chuyển từ workshop sang thực sự vận chuyển sản phẩm. Các câu hỏi tiết lộ khoảng cách giữa sự thanh lịch lý thuyết của kiến trúc tác nhân và thực tế lộn xộn của các hệ thống sản xuất.
Từ Nguyên Mẫu Đến Sản Xuất
Câu hỏi đầu tiên là cơ bản nhất: bạn đã xây dựng nguyên mẫu hoạt động. Bây giờ làm thế nào để bạn làm cho nó có thể tái tạo và đáng tin cậy? Câu trả lời của Thariq bắt đầu với CLAUDE.md. Tệp hướng dẫn là nơi quan trọng nhất để mã hóa những gì bạn học được trong quá trình tạo nguyên mẫu. Trong demo Pokémon của ông, tác nhân đã bỏ qua thư viện TypeScript được xây dựng trước của ông trong một lần chạy và viết JavaScript thuần túy thay thế. Điều đó xảy ra vì CLAUDE.md không nói rõ ràng "bạn phải sử dụng thư viện này." Bài học: bất cứ điều gì tác nhân làm sai trong nguyên mẫu của bạn do hướng dẫn không rõ ràng nên được sửa bằng cách thêm quy tắc rõ ràng, cụ thể vào CLAUDE.md. Tệp hướng dẫn nên phát triển khi bạn phát hiện ra các trường hợp ngoại lệ, không chỉ đóng vai trò giới thiệu mơ hồ.
Phần thứ hai của câu trả lời là các script trợ lý. Khi bạn tìm thấy một cách tiếp cận hoạt động — chẳng hạn, tải CSV vào SQLite và truy vấn nó — hãy viết script thực hiện thiết lập đó và ghi chú trong CLAUDE.md rằng script tồn tại và khi nào sử dụng nó. Các script trợ lý tốt phục vụ hai mục đích: chúng cung cấp cho tác nhân một con đường nhanh, đáng tin cậy đến cách tiếp cận đúng, và chúng ghi lại những gì bạn học được trong quá trình tạo nguyên mẫu để các tác nhân tương lai (và phiên bản tương lai của chính bạn) có thể hưởng lợi từ nó.
Khi Tác Nhân Gian Lận
Một thành viên khán giả mô tả trải nghiệm điên rồ: tác nhân Pokémon của họ cố chạy script, thất bại vài lần, và sau đó chỉ đơn giản trả về bảng thống kê Pokémon từ bộ nhớ. Tác nhân đã ngừng cố gắng sử dụng dữ liệu thực tế và bắt đầu bịa đặt từ dữ liệu huấn luyện của mình. Thariq thừa nhận đây là thách thức thực sự. Dữ liệu huấn luyện của mô hình là kiến thức nền tảng của nó, và đối với các miền phổ biến như Pokémon — hoặc các chủ đề kinh doanh thông thường — kiến thức nền tảng đó thường đủ gần với đúng để mô hình đi đường tắt. Điều này được gọi là "in-distribution": nhiệm vụ quá giống với những gì mô hình đã thấy trước đây đến mức nó không cảm thấy cần phải đi tra cứu.
Giải pháp mà Thariq khuyến nghị là hooks, như đã thảo luận trong chương trước. Bạn viết một hook ngăn chặn mọi phản hồi trước khi đến người dùng và kiểm tra bằng chứng rằng tác nhân thực sự đã chạy script. Nếu không có script nào được chạy, hook đưa phản hồi vào: "Bạn phải viết script và sử dụng dữ liệu thực tế. Đừng trả lời từ bộ nhớ." Đây là rào chắn xác định làm cho việc gian lận trở nên không thể thay vì chỉ khó có thể xảy ra. Không có lượng lệnh nhắc nào một mình có thể ngăn hành vi này một cách đáng tin cậy — mô hình đôi khi sẽ bỏ qua các hướng dẫn khi sự tự tin vào kiến thức của chính nó cao. Hook không thể bị bỏ qua.
Codebase Khổng Lồ
Một lập trình viên đặt ra vấn đề thực tế đáng lo ngại: họ đang làm việc với codebase hơn năm mươi triệu dòng code. Các công cụ tiêu chuẩn như grep trở nên chậm đau đớn ở quy mô đó. Họ đang xây dựng hệ thống lập chỉ mục ngữ nghĩa của riêng họ — hệ thống tìm kiếm tìm code dựa trên ý nghĩa thay vì chỉ khớp văn bản chính xác — và họ muốn biết liệu Anthropic có kế hoạch làm điều gì đó như vậy thành gốc trong SDK không.
Thariq đưa ra câu trả lời thẳng thắn, hai phần. Đầu tiên, phần trung thực: có, bất cứ điều gì bạn xây dựng cho vấn đề này hôm nay có thể sẽ bị làm lỗi thời bởi những cải tiến trong các công cụ trong sáu đến mười hai tháng tới. Lĩnh vực đang di chuyển đủ nhanh để cơ sở hạ tầng tùy chỉnh được xây dựng để bù đắp cho các hạn chế hiện tại thường trở nên không cần thiết. Thứ hai, phần thực tế: Anthropic không sử dụng lập chỉ mục ngữ nghĩa cho chính Claude Code. Thay vào đó, họ dựa vào các tệp CLAUDE.md được cấu trúc tốt cho biết tác nhân biết mọi thứ tồn tại ở đâu trong codebase — thư mục nào chứa loại code nào, quy ước đặt tên là gì — để tác nhân có thể điều hướng hiệu quả mà không cần tìm kiếm mọi thứ. Và họ thường khởi động tác nhân trong một thư mục con cụ thể có liên quan đến nhiệm vụ, thay vì thả nó ở thư mục gốc của kho tài nguyên năm mươi triệu dòng và mong nó tìm đường. Kỹ thuật ngữ cảnh tốt — cho tác nhân biết nơi cần tìm — thường vượt trội so với cơ sở hạ tầng tìm kiếm phức tạp. Tuy nhiên, Thariq cẩn thận không tuyên bố điều này giải quyết hoàn toàn vấn đề. Đối với các codebase thực sự khổng lồ, vẫn còn lãnh thổ chưa được khám phá.
Kiếm Tiền
Câu hỏi cuối cùng là về tiền bạc. Các tác nhân rất tốn kém để chạy — họ thực hiện nhiều lệnh gọi API, họ chạy lâu và chi phí mỗi nhiệm vụ có thể đáng kể. Với tất cả chi phí chảy về Anthropic, làm thế nào các lập trình viên phải xây dựng một doanh nghiệp khả thi?
Câu trả lời của Thariq là lời khuyên kinh doanh phần mềm cổ điển được áp dụng vào bối cảnh mới: tìm những vấn đề thực sự khó khăn và thực sự có giá trị, và tính phí phù hợp. Kinh tế học của các tác nhân hoạt động khi vấn đề chúng giải quyết đủ tốn kém để chi phí mỗi nhiệm vụ là một món hời. Nếu một tác nhân tiết kiệm cho một luật sư bốn giờ xem xét tài liệu, tính hai mươi đô la cho nhiệm vụ đó không chỉ khả thi — đó là rẻ mạt. Thất bại đến từ việc cố gắng tính những khoản tiền nhỏ cho các nhiệm vụ không đủ có giá trị để biện minh cho chi phí. Về cơ cấu giá, Thariq lưu ý rằng Claude Code sử dụng mô hình kết hợp: đăng ký hàng tháng cố định cho việc sử dụng tiêu chuẩn, với giá dựa trên sử dụng cho người dùng nặng vượt quá giới hạn. Điều này cân bằng tính có thể đoán trước (người dùng biết đại khái họ sẽ trả bao nhiêu) với sự công bằng (người dùng nặng trả nhiều hơn). Ông khuyến nghị nghĩ về cơ cấu giá từ sớm, vì việc thay đổi sau khi người dùng đã quen với một mô hình cụ thể khó khăn hơn nhiều.
Workshop kết thúc bằng tiếng vỗ tay. Thông điệp trung tâm của Thariq — rằng kiến trúc đúng đắn cho các tác nhân AI là triết lý Unix về các công cụ có thể kết hợp, ưu tiên tệp, được hỗ trợ bởi bash — ban đầu có thể cảm thấy không trực quan. Nó có vẻ quá đơn giản, quá lỗi thời, quá phụ thuộc vào công nghệ có trước AI hàng thập kỷ. Nhưng đó chính xác là điểm mấu chốt. Những công cụ bền vững nhất là những công cụ đã tồn tại lâu nhất. Hệ thống tệp và dòng lệnh đã tồn tại vì chúng thực sự là mục đích chung. Việc cho AI quyền truy cập vào chúng không hạn chế những gì AI có thể làm — nó khuếch đại nó.