Claude Agent SDK [Full Workshop] — Thariq Shihipar, Anthropic

• Claw 2 Agent SDK là một bộ công cụ phát triển tác nhân AI tự hành, được thiết kế để đơn giản hóa việc xây dựng các tác nhân phức tạp bằng cách đóng gói các thành phần chung và tích hợp các bài học kinh nghiệm từ Claw Code.
• SDK này có quan điểm mạnh mẽ về việc sử dụng công cụ bash và hệ thống tập tin làm cốt lõi cho tác nhân, cho phép tác nhân tự xây dựng ngữ cảnh, thực hiện sinh mã và kết hợp các công cụ hiệu quả cho cả tác vụ lập trình và phi lập trình.
• Để đảm bảo an toàn, các tác nhân được xây dựng trên SDK áp dụng cơ chế phòng thủ nhiều lớp kiểu "phô mai Thụy Sĩ", bao gồm điều chỉnh mô hình, hàng rào bảo vệ ở tầng harness, và sandbox mạnh mẽ để cô lập môi trường thực thi.

• Các tính năng AI đang phát triển từ các LLM đơn lẻ sang workflow có cấu trúc và hiện tại là các tác nhân tự chủ cao, có khả năng tự xây dựng ngữ cảnh và quyết định quỹ đạo hành động của mình.
• Claw Agent SDK ra đời để giải quyết sự lặp lại trong việc xây dựng các thành phần tác nhân (như tool, lời nhắc cốt lõi, hệ thống tập tin, skill, tác nhân phụ, bộ nhớ), giúp các nhà phát triển tập trung vào logic nghiệp vụ.
• SDK này tích hợp best practices và các giải pháp cho các lỗi phổ biến về tool use và context crafting đã được học từ việc triển khai Claw Code, mang lại một cách tiếp cận "có chủ kiến" để xây dựng tác nhân.
• Công cụ bash được coi là tool mạnh mẽ nhất của tác nhân, cho phép lưu trữ kết quả, tạo script động, kết hợp các chức năng Unix (như tail, grep), và sử dụng các phần mềm hiện có để thực hiện nhiều hành động đa dạng.
• Khái niệm "sinh mã cho tác vụ không liên quan đến lập trình" cho phép tác nhân tạo script (ví dụ: gọi API thời tiết, phân tích email) để giải quyết các vấn đề phi lập trình, tận dụng sức mạnh của bash để xử lý và kiểm tra dữ liệu động.
• Mỗi tác nhân cần được lưu trữ và hoạt động trong một vùng chứa (container) hoặc môi trường cục bộ với quyền truy cập vào hệ thống tập tin và bash để thực thi các lệnh và tương tác với môi trường.
• Bảo mật cho tác nhân được đảm bảo thông qua một "phòng thủ kiểu phô mai Thụy Sĩ", bao gồm: mô hình được điều chỉnh tốt, harness với hàng rào bảo vệ và phân tích công cụ bash, cùng với sandboxing (cô lập hệ thống tập tin và mạng) để ngăn chặn vector tấn công.

• Claw 2 Agent SDK — Bộ công cụ phát triển tác nhân Claw 2
• Tác nhân — Agent (Đại diện AI tự hành)
• LLM framework — Khung LLM (Khung công việc Mô hình Ngôn ngữ Lớn)
• Tool — Công cụ (mà tác nhân sử dụng)
• Khung điều khiển — Harness (Khung điều khiển tác nhân)
• Hệ thống tập tin — File system (Hệ thống tệp)
• Công cụ bash — Bash tool (Công cụ dòng lệnh Bash)
• Sinh mã — Code generation (Tạo mã tự động)
• Vùng chứa — Container (Môi trường vùng chứa)
• Sandbox — Sandbox (Môi trường hộp cát an toàn)

Giới thiệu và Chương trình Nghị sự

Cảm ơn các bạn đã tham gia. Tôi hiện vẫn đang theo giờ Bờ Tây, nên cảm giác như tôi đang thực hiện buổi nói chuyện này lúc 7 giờ sáng. Nhưng rất vui được nói chuyện với các bạn về Claw 2 Agent SDK. Tôi nghĩ đây sẽ là một chương trình nghị sự sơ bộ, chúng ta sẽ nói về: Claw 2 Agent SDK là gì? Tại sao lại sử dụng nó, khi có quá nhiều LLM framework khác? Tác nhân là gì? Một LLM framework cho tác nhân là gì? Làm thế nào để thiết kế một tác nhân bằng cách sử dụng Agent SDK hoặc nói chung? Sau đó, tôi sẽ thực hiện một số đoạn mã trực tiếp, hoặc Claw sẽ thực hiện một số đoạn mã trực tiếp về việc tạo mẫu một tác nhân. Tôi có một số mã khởi đầu, nhưng mục tiêu chung của buổi này là trong hai giờ, chúng ta sẽ hợp tác hết sức, đặt câu hỏi. Đây cũng sẽ không phải là một buổi demo được chuẩn bị sẵn theo kiểu mọi câu trả lời đều có ngay lập tức. Chúng ta sẽ cùng nhau suy nghĩ trong thời gian thực. Tôi nghĩ đó sẽ là một cách tốt để xây dựng vòng lặp tác nhân (agent loop), vì tôi nghĩ nó rất giống một loại hình nghệ thuật hoặc tầm nhìn. Vâng, trước khi bắt đầu, tôi chỉ tò mò muốn hỏi, bao nhiêu người ở đây đã từng nghe về Claw 2 Agent SDK? Tuyệt vời. Bao nhiêu người đã dùng thử? Rất tốt. Vậy là có khá nhiều người đã biết đến.

Sự Phát triển của Tính năng AI: Từ LLM Đơn lẻ đến Tác nhân

Vâng, tôi sẽ bắt đầu với cái nhìn tổng quan về tác nhân. Tôi nghĩ đây là điều mà có thể nhiều người đã thấy trước đây, nhưng vẫn cần thời gian để thực sự hiểu sâu về cách các tính năng AI đang phát triển. Khi GPT-3 ra mắt, nó thực sự chỉ xoay quanh các tính năng LLM đơn lẻ. Bạn sẽ hỏi, "Này, bạn có thể phân loại cái này và trả về phản hồi trong một trong các danh mục này không?". Và sau đó, chúng ta có những thứ giống như workflow hơn, ví dụ: "Này, bạn có thể tạo email này và gắn nhãn cho nó không?", hoặc "Đây là cơ sở mã của tôi, hãy lập chỉ mục nó thông qua RAG. Bạn có thể cho tôi biết phần bổ sung tiếp theo hoặc tập tin tiếp theo cần chỉnh sửa không?". Đó là những gì chúng tôi gọi là một workflow mà bạn rất có cấu trúc, kiểu như "Này, đưa cho tôi đoạn mã này, hãy trả lại mã".

Và bây giờ chúng ta đang đi đến các tác nhân. Tác nhân kinh điển được gọi là Claw Code. Claw Code là một tool mà bạn không thực sự nói cho nó biết những gì nó có thể làm; chúng tôi không giới hạn nó. Bạn chỉ nói chuyện với nó bằng văn bản và nó sẽ thực hiện rất nhiều hành động khác nhau. Vì vậy, các tác nhân tự xây dựng ngữ cảnh của riêng mình, tự quyết định quỹ đạo của mình và hoạt động rất, rất tự chủ. Và tôi nghĩ rằng trong tương lai, các tác nhân sẽ ngày càng tự chủ hơn. Chúng tôi đang ở một thời điểm tuyệt vời để bắt đầu xây dựng các tác nhân này. Chúng không hoàn hảo, nhưng chắc chắn đây là thời điểm thích hợp để bắt đầu.

Claw Agent SDK là gì?

Claw Code, tôi chắc chắn nhiều bạn đã dùng thử, là tác nhân đầu tiên thực sự. Đó là lần đầu tiên tôi thấy một AI hoạt động trong 10, 20, 30 phút. Vâng, đó là một tác nhân lập trình, và Claw Agent SDK thực sự được xây dựng trên Claw Code. Lý do chúng tôi làm điều đó là vì về cơ bản, chúng tôi nhận thấy rằng khi xây dựng các tác nhân tại Anthropic, chúng tôi liên tục phải xây dựng lại các phần giống nhau hết lần này đến lần khác.

Để bạn hình dung nó trông như thế nào: tất nhiên, có các mô hình để bắt đầu. Sau đó, trong khung điều khiển (harness), bạn có các tool. Đó là bước đầu tiên rõ ràng: hãy thêm một số tool vào khung điều khiển này. Sau này, chúng tôi sẽ đưa ra một ví dụ về việc cố gắng tự xây dựng khung điều khiển của riêng bạn từ đầu và điều đó trông như thế nào và khó khăn đến mức nào. Nhưng tool không chỉ là custom tool của riêng bạn; chúng có thể là tool để theo dõi hệ thống thử nghiệm, giống như với Claw Code.

[transcript bị gián đoạn]

Vâng, có các tool, các tool mà bạn chạy trong một vòng lặp tác nhân, và sau đó bạn có các lời nhắc cốt lõi của tác nhân, các lời nhắc mà... dường như vậy. Và cuối cùng, bạn có hệ thống tập tin (file system). Hệ thống tập tin (file system) là một cách để xử lý ngữ cảnh (context handling) mà chúng ta sẽ nói nhiều hơn về sau. Tôi nghĩ một trong những hiểu biết quan trọng mà chúng tôi có được qua Claw Code là việc suy nghĩ nhiều hơn về ngữ cảnh không chỉ là một lời nhắc. Nó còn là tool, các tệp và trang web mà tác nhân có thể sử dụng.

Và sau đó có các skill mà chúng tôi đã triển khai gần đây, và chúng tôi có thể nói thêm về skill nếu các bạn quan tâm. Và vâng, những thứ như tác nhân phụ, tìm kiếm web, nghiên cứu, context crafting (tạo ngữ cảnh), hook (điểm móc), memory (bộ nhớ). Có những thứ khác xung quanh khung điều khiển (harness) nữa. Và cuối cùng, nó trở thành khá nhiều thứ. Vì vậy, Claw Agent SDK là tất cả những điều này được đóng gói sẵn để bạn sử dụng. Vâng, bạn có ứng dụng của mình.

Tại sao nên sử dụng Claw Agent SDK?

Để bạn hình dung tại sao Claw Agent SDK lại hữu ích, rất nhiều người đang xây dựng các tác nhân phần mềm trên SDK: các tác nhân về độ tin cậy, bảo mật phần mềm, để phân loại lỗi và tìm lỗi, cũng như các nhà phát triển bảng điều khiển. Chúng cực kỳ phổ biến. Nếu bạn đang sử dụng chúng, bạn chắc chắn nên sử dụng SDK. Và đó là các tác nhân văn phòng, nếu bạn đang thực hiện bất kỳ công việc văn phòng nào, có rất nhiều ví dụ ở đó. Chúng tôi có một số ví dụ về pháp lý, tài chính, y tế. Vì vậy, có rất nhiều người đang xây dựng dựa trên nó.

Nhưng tại sao lại là Claw Agent SDK? Tại sao chúng tôi làm theo cách này? Tại sao chúng tôi xây dựng nó dựa trên Claw Code? Chúng tôi nhận ra rằng ngay khi chúng tôi phát hành Claw Code, các kỹ sư bắt đầu sử dụng nó. Nhưng sau đó, các chuyên gia tài chính bắt đầu sử dụng nó, và các chuyên gia khoa học dữ liệu bắt đầu sử dụng nó, và các chuyên gia marketing bắt đầu sử dụng nó. Và vâng, chúng tôi nhận ra rằng mọi người đang sử dụng Claw Code cho các tác vụ không liên quan đến lập trình. Và chúng tôi cảm thấy rằng, khi chúng tôi xây dựng các tác nhân không liên quan đến lập trình, chúng tôi vẫn luôn quay trở lại với nó. Và chúng ta sẽ đi sâu hơn vào lý do tại sao điều đó lại hiệu quả, tại sao chúng ta có thể sử dụng Claw Code cho các tác vụ không liên quan đến lập trình. (Tiết lộ trước: đó là công cụ bash (bash tool)). Nhưng vâng, đó là điều mà chúng tôi thấy là một mẫu hình nổi lên mà chúng tôi muốn sử dụng, và chúng tôi đã xây dựng các tác nhân của mình dựa trên nó. Và đây là những bài học mà chúng tôi đã học được từ việc triển khai Claw Code mà chúng tôi đã tích hợp vào Claw Agent SDK.

Các lỗi tool use, hoặc context crafting, hoặc những thứ tương tự. Đó là những thứ cần rất nhiều quy mô để tìm ra những best practices (thực hành tốt nhất). Chúng tôi đã tích hợp chúng vào Claw Agent SDK. Kết quả là, chúng tôi có rất nhiều quan điểm mạnh mẽ về cách tốt nhất để xây dựng tác nhân. Tôi nghĩ Claw Agent SDK khá "có chủ kiến" (opinionated). Chúng tôi sẽ thảo luận về một số quan điểm này và lý do tại sao chúng tôi chọn chúng. Nhưng vâng, một trong những quan điểm lớn là công cụ bash (bash tool) là tool mạnh nhất của tác nhân.

Cách Anthropic xây dựng Tác nhân

Vậy, tôi sẽ mô tả cách Anthropic xây dựng tác nhân là gì? Và tôi không nói rằng bạn chỉ có thể xây dựng tác nhân bằng API theo cách này. Nhưng đây là nếu bạn đang sử dụng stack "có chủ kiến" của chúng tôi trên Agent SDK, nó là gì?

Đại khái là các nguyên thủy Unix, như bash và hệ thống tập tin (file system). Và bạn biết đấy, chúng ta sẽ xem xét việc tạo mẫu một tác nhân bằng Claw Code, và mục tiêu của tôi thực sự là cho bạn thấy điều đó trông như thế nào trong thời gian thực. Tại sao bash hữu ích? Tại sao hệ thống tập tin (file system) hữu ích? Tại sao không chỉ sử dụng các tool? Vâng, tác nhân – tôi nghĩ bạn cũng có thể đưa ra đề xuất để nói về điều đó sau một chút – các tác nhân tự xây dựng ngữ cảnh của riêng mình. Suy nghĩ về sinh mã (code generation) cho các tác vụ không liên quan đến lập trình. Ví dụ, chúng tôi sử dụng sinh mã (code generation) để tạo tài liệu cho web, thực hiện phân tích dữ liệu, thực hiện các hành động không có cấu trúc. Vì vậy, có rất nhiều điều này có thể khá phản trực giác đối với một số người, và một lần nữa, trong phần tạo mẫu, chúng tôi sẽ xem xét cách sử dụng sinh mã (code generation) cho các tác nhân không liên quan đến lập trình.

Và vâng, mỗi tác nhân đều có một vùng chứa (container) hoặc được lưu trữ cục bộ, bởi vì đây là Claw Code. Nó cần một hệ thống tập tin (file system) và cần bash; nó cần có khả năng hoạt động trên đó. Và vì vậy, nó là một phần rất khác của kiến trúc. Tôi không định nói nhiều về kiến trúc hôm nay. Nhưng chúng ta có thể làm điều đó vào cuối buổi nếu mọi người quan tâm. Hoặc xin lỗi, ý tôi là kiến trúc lưu trữ, như cách bạn lưu trữ tác nhân và những best practices nào ở đó. Chúng ta có thể nói về điều đó vào cuối buổi. Vâng, hãy để tôi tạm dừng ở đó, bởi vì tôi cảm thấy như tôi đã trình bày rất nhiều rồi. Có câu hỏi nào cho đến nay về Agent SDK, tác nhân không? Vâng, những gì bạn nhận được từ nó.

Hỏi & Đáp: Sinh mã cho Tác vụ phi lập trình

Vâng, bạn có thể giải thích sinh mã (code generation) cho các tác vụ không liên quan đến lập trình nghĩa là gì không? Vâng, điều này là về cơ bản khi bạn yêu cầu Claw Code thực hiện một việc gì đó. Chẳng hạn, bạn yêu cầu nó tìm thời tiết ở San Francisco và bạn biết đấy, nói cho bạn biết tôi nên mặc gì hay gì đó. Nó có thể bắt đầu viết một script để tìm nạp API thời tiết. Và sau đó bắt đầu, có thể nó muốn script đó có thể tái sử dụng, có thể bạn muốn thực hiện việc này khá thường xuyên. Vì vậy, nó có thể tìm nạp API thời tiết và sau đó lấy vị trí của bạn một cách động dựa trên địa chỉ IP của bạn, và sau đó nó sẽ kiểm tra thời tiết và sau đó có thể gọi một tác nhân phụ để đưa ra khuyến nghị cho bạn. Có thể có một API cho tủ quần áo của bạn. Đó là một ví dụ. Tôi nghĩ rằng đối với bất kỳ ví dụ đơn lẻ nào, chúng ta có thể nói về cách bạn có thể sử dụng Claw Code.

Hỏi & Đáp: Workflow so với Tác nhân

Vâng, tất nhiên. Câu hỏi là về workflow so với tác nhân, và liệu bạn có vẫn sử dụng nó không? Vâng, câu hỏi là về workflow so với tác nhân, và liệu bạn có vẫn sử dụng nó không? Vâng, tất nhiên. Câu hỏi là về workflow so với tác nhân, và liệu bạn có vẫn sử dụng Claw Agent SDK cho workflow không? Có phải vậy không? Vâng, và vì vậy, ý tôi là, chúng tôi chỉ nói với bạn những gì chúng tôi làm nội bộ. Về cơ bản, chúng tôi đã thực hiện rất nhiều tự động hóa (automations) trên GitHub và tự động hóa (automations) trên Slack được xây dựng trên Claw Agent SDK. Vì vậy, bạn biết đấy, chúng tôi có một bot phân loại các vấn đề khi chúng đến, đó là một việc rất giống workflow. Nhưng chúng tôi vẫn nhận thấy rằng, để phân loại các vấn đề, chúng tôi muốn nó có thể sao chép cơ sở mã (codebase) và đôi khi tạo một vùng chứa Docker (Docker container) và kiểm tra nó, và những thứ tương tự. Và vì vậy, nó vẫn kết thúc là một quá trình rất, rất nhiều bước ở giữa cần phải được thực hiện một cách trôi chảy. Và sau đó bạn đưa ra kết quả có cấu trúc ở cuối. Vâng.

Hỏi & Đáp: Bảo mật và Hàng rào bảo vệ (Guardrails)

Được rồi, chúng ta sẽ nhận thêm một câu hỏi nữa và sau đó tôi sẽ tiếp tục. Vâng, bạn có thể nói về bảo mật và hàng rào bảo vệ (guardrails) không? Nếu chúng ta đang sử dụng Claw Agent SDK và bạn đang hướng tới việc sử dụng bash làm tool đa năng, quyền hạn thuộc về nhà phát triển tác nhân để đảm bảo rằng bạn đang chống lại các vector tấn công phổ biến, hay đó là điều mà mô hình đang thực hiện? Vâng, tôi nghĩ điều này giống như phòng thủ kiểu "phô mai Thụy Sĩ". Vâng, tôi nghĩ câu hỏi là về quyền hạn trên công cụ bash (bash tool) hoặc cách bạn suy nghĩ về quyền hạn và hàng rào bảo vệ (guardrails), và khi tác nhân có nhiều quyền lực như vậy đối với môi trường và máy tính của bạn, làm thế nào bạn đảm bảo nó được điều chỉnh đúng cách? Và vì vậy, cách chúng tôi nghĩ về điều này là một phòng thủ kiểu "phô mai Thụy Sĩ". Tức là, ở mỗi lớp có một số cơ chế phòng thủ, và cùng nhau chúng tôi hy vọng nó sẽ chặn mọi thứ. Vì vậy, rõ ràng ở lớp mô hình, chúng tôi thực hiện rất nhiều điều chỉnh ở đó.

Các Lớp Bảo Mật Tác nhân AI

Chúng tôi vừa phát hành một bài viết rất hay về reward hacking – rất khuyến khích các bạn tìm đọc. Vì vậy, đối với các mô hình trên Claude, chúng tôi cố gắng làm cho chúng được căn chỉnh rất tốt. Vâng, có một mô hình hành vi được căn chỉnh. Sau đó là bản thân harness. Chúng tôi có rất nhiều quyền và lời nhắc, và chúng tôi thực hiện phân tích st pass parser trên công cụ Bash chẳng hạn, vì vậy chúng tôi biết khá đáng tin cậy về những gì công cụ Bash đang thực sự làm – đây chắc chắn không phải là thứ bạn muốn tự mình xây dựng. Và cuối cùng, lớp cuối cùng là sandboxing. Giả sử ai đó đã chiếm quyền điều khiển tác nhân của bạn một cách độc hại, nó thực sự có thể làm gì? Chúng tôi đã bao gồm một sandbox nơi bạn có thể cô lập các yêu cầu, các hoạt động của hệ thống tệp bên ngoài hệ thống tệp. Và vâng, cuối cùng thì đó là cái mà họ gọi là "bộ ba sát thủ" (lethal trifacta): khả năng thực thi mã trong một môi trường, thay đổi hệ thống tệp và exfiltrate (trích xuất) mã. Tôi nghĩ mình đang diễn giải "bộ ba sát thủ" hơi sai ở đây. Về cơ bản, ý tưởng là nếu họ có thể exfiltrate thông tin của bạn ra ngoài, đó là lúc họ vẫn cần có khả năng trích xuất thông tin. Và nếu bạn sandbox mạng, đó là một cách tốt để làm điều đó. Nếu bạn đang host trên một vùng chứa được sandbox như Cloudflare Modal hoặc E2B Data Tonal, tất cả những nhà cung cấp sandbox này đều đã thực hiện một mức độ bảo mật nhất định. Bạn không host nó trên máy tính cá nhân của mình hoặc trên một máy tính chứa các bí mật sản xuất (prod secrets) của bạn. Vâng, có rất nhiều lớp khác nhau, và chúng ta có thể nói sâu hơn về việc host sau.

Sức Mạnh của Bash trong Phát triển Agent

Bây giờ, tôi sẽ nói một chút về "Bash là tất cả những gì bạn cần". Tôi nghĩ đây là điều mà tôi cứ nói đi nói lại cho đến khi mọi người đồng ý với tôi. Hoặc tôi nghĩ đây là điều chúng tôi tìm thấy ở Anthropic, một điều tôi đã khám phá ra trước đây. Bash là thứ làm cho tác nhân AI như CodeX trở nên tốt đến vậy. Tôi nghĩ các bạn có thể đã thấy chế độ mã hóa (code mode) hoặc việc sử dụng công cụ có lập trình (programmatic tool use) – những cách khác nhau để kết hợp các ứng dụng. Công ty Conformal đã đăng một số bài viết blog về điều đó, chúng tôi cũng đã đăng một số bài viết blog. Cách tôi nghĩ về chế độ mã hóa, hay Bash nói đúng hơn, là nó giống như chế độ mã hóa đầu tiên. Công cụ Bash cho phép bạn lưu trữ kết quả gọi công cụ của mình vào tệp, lưu trữ bộ nhớ động và tạo script rồi gọi chúng, kết hợp các chức năng như tail, grep. Nó cho phép sử dụng các phần mềm hiện có như FFmpeg hoặc Graphviz. Vì vậy, công cụ Bash có rất nhiều điều thú vị và mạnh mẽ có thể làm được.

Hãy nghĩ lại, điều gì đã làm cho tác nhân AI như CodeX trở nên tốt đến vậy? Nếu bạn đang thiết kế một harness tác nhân, có lẽ bạn sẽ có một công cụ tìm kiếm, một công cụ liên kết và một công cụ thực thi, v.v. Cứ mỗi khi bạn nghĩ ra một trường hợp sử dụng mới, bạn lại nghĩ: "Mình cần một công cụ khác ngay bây giờ." Thay vào đó, giờ đây CodeX sử dụng grep và duyệt qua các trình quản lý gói (package managers), hoặc chạy npm run test.ts hoặc index.ts hay bất cứ thứ gì. Bạn lint (kiểm tra lỗi cú pháp) mã của mình, và bạn có thể tìm ra cách lint, rồi chạy npm run lint. Nếu bạn không có linter (công cụ kiểm tra lỗi cú pháp), bạn có thể nói: "Hay là tôi cài đặt ESLint cho bạn nhé?"

Đây giống như, như tôi đã nói, gọi công cụ có lập trình đầu tiên, chế độ mã hóa đầu tiên. Bạn có thể thực hiện nhiều hành động khác nhau một cách rất chung chung. Bây giờ, để nói về điều này một chút trong ngữ cảnh của các tác nhân không liên quan đến lập trình: Giả sử chúng ta có một tác nhân email và người dùng hỏi: "Tuần này tôi đã chi bao nhiêu tiền cho dịch vụ chia sẻ chuyến đi?" Một tác nhân như vậy thường có một lời gọi công cụ (tool call) hoặc khả năng tìm kiếm trong hộp thư đến (inbox). Vì vậy, nó có thể chạy một truy vấn (query) như: "Tìm kiếm Uber hoặc Lyft." Nếu không có Bash, nó chỉ tìm kiếm từ "Lyft" và nhận được khoảng 100 email, và bây giờ nó phải tự mình xử lý. Tôi nghĩ một phép so sánh tốt sẽ là: Hãy tưởng tượng ai đó đến gặp bạn với một chồng giấy tờ và nói: "Tuần này tôi đã chi bao nhiêu tiền cho dịch vụ chia sẻ chuyến đi? Bạn có thể đọc qua email của tôi không?" Ý bạn là điều đó sẽ rất khó phải không? Bạn cần độ chính xác (precision) và khả năng thu hồi (recall) rất tốt để làm điều đó.

Hoặc với Bash: Giả sử có một script tìm kiếm Gmail nhận một hàm truy vấn. Sau đó, bạn có thể bắt đầu lưu hàm truy vấn đó vào một tệp hoặc pipe (chuyển kết quả sang) nó. Bạn có thể grep để tìm giá, sau đó cộng chúng lại. Bạn cũng có thể kiểm tra lại công việc của mình: "Được rồi, hãy grep tất cả các giá của tôi, lưu chúng vào một tệp với số dòng, và sau đó tôi có thể kiểm tra lại xem đây có thực sự là một mức giá không, mỗi giá tương ứng với cái gì?" Vì vậy, có rất nhiều thông tin động hơn bạn có thể làm để kiểm tra công việc của mình với công cụ Bash. Đây là một ví dụ đơn giản, nhưng hy vọng nó cho bạn thấy sức mạnh của khả năng Bash.

Có câu hỏi nào về "Bash là tất cả những gì bạn cần", công cụ Bash, hoặc bất cứ điều gì tôi có thể làm rõ hơn không?

(Có câu hỏi về thống kê số người sử dụng chế độ mã hóa.)

Chúng tôi có lẽ có thống kê về chế độ mã hóa (olem mode). Về mặt nội bộ thì không, nhưng đó chỉ là vì tôi nghĩ chúng tôi có tư thế bảo mật cao hơn. Tôi không chắc, có lẽ tôi có thể lấy được số liệu đó.

Ví dụ về Bash cho Agent Phi-mã hóa và Đa phương tiện

Chỉ để cung cấp thêm một số ví dụ: giả sử bạn có một API email và bạn muốn tìm hiểu xem "ai đã gửi email cho tôi trong tuần này?". Bạn có hai API: một API hộp thư đến (inbox API) và một API liên hệ (contact API). Đây là một cách bạn có thể thực hiện với Bash. Bạn cũng có thể làm điều đó thông qua tạo mã (code generation). Điều này giống như Bash đủ mạnh để trở thành tạo mã phải không, vì Bash rõ ràng là một công cụ tạo mã.

Và sau đó, giả sử bạn có một tác nhân họp video, bạn muốn nói: "Tìm tất cả các khoảnh khắc mà người nói đề cập đến 'kết quả hàng quý' trong cuộc gọi công bố thu nhập này". Bạn có thể sử dụng FFmpeg để cắt video. Bạn có thể sử dụng jq để bắt đầu phân tích thông tin sau đó. Vì vậy, có rất nhiều cách mạnh mẽ để sử dụng Bash.

Agent và Workflow: Khi nào nên sử dụng cái nào?

Được rồi, tôi sẽ nói một chút về workflow và tác nhân. Cả hai đều có thể được xây dựng bằng SDK tác nhân (agent SDK). Vâng, tác nhân giống như mã Claude. Vì vậy, nếu bạn đang xây dựng thứ gì đó mà bạn muốn trò chuyện bằng ngôn ngữ tự nhiên (natural language) và hành động một cách linh hoạt, thì đó là lúc bạn xây dựng một tác nhân. Chẳng hạn, bạn có một tác nhân trò chuyện với dữ liệu kinh doanh của bạn. Bạn muốn nhận thông tin chi tiết hoặc dashboard, hoặc trả lời câu hỏi, hoặc viết mã – đó là một tác nhân.

Và sau đó, một workflow thì giống như, ví dụ, chúng tôi thực hiện rất nhiều GitHub Actions. Bạn xác định đầu vào và đầu ra rất chặt chẽ. Vì vậy, bạn sẽ nói: "Được rồi, bạn có thể lấy một PR (Pull Request) và cung cấp cho tôi một bài đánh giá mã (code review) không?" Và vâng, cả hai điều này bạn đều có thể sử dụng SDK tác nhân để xây dựng. Khi xây dựng workflow, bạn có thể sử dụng đầu ra có cấu trúc (structured outputs) mà chúng tôi vừa phát hành. Vâng, bạn có thể tìm kiếm trên Google agent SDK structured outputs. Nhưng vâng, bạn có thể làm cả hai. Tôi sẽ chủ yếu nói về tác nhân bây giờ. Rất nhiều điều bạn có thể học từ đây cũng có thể áp dụng cho workflow.

Vâng, chúng ta sẽ nói về điều này. Cho tôi hỏi, bao nhiêu người đã từng thiết kế một agent loop (vòng lặp tác nhân) trước đây? Được rồi, tốt, tuyệt vời!

Ba Phần của một Agent Loop Hiệu quả

Vâng, tôi nghĩ điều quan trọng nhất, "học cách học" (meta-learning) để thiết kế một agent loop đối với tôi chỉ là đọc lại các transcript nhiều lần. Mỗi khi bạn thấy tác nhân chạy, hãy đọc nó và tìm hiểu: "Nó đang làm gì? Tại sao nó làm điều này? Tôi có thể giúp nó bằng cách nào đó không?" Và chúng ta sẽ thực hiện một số điều đó sau. Chúng ta sẽ xây dựng một agent loop.

Đây là ba phần của một agent loop:

1. Thu thập ngữ cảnh (gather context): Đây là bước đầu tiên.
2. Thực hiện hành động (taking action): Bước thứ hai.
3. Xác minh công việc (verifying the work): Và bước thứ ba.

Đây không phải là cách duy nhất để xây dựng một tác nhân, nhưng tôi nghĩ đó là một cách khá tốt để suy nghĩ về nó. Thu thập ngữ cảnh giống như, đối với CodeX, là grep và tìm các tệp cần thiết. Đối với một tác nhân email, đó là tìm các email liên quan. Và đây là tất cả những điều khá quan trọng. Tôi nghĩ việc suy nghĩ về cách nó tìm thấy ngữ cảnh này là rất quan trọng, và tôi nghĩ nhiều người thường bỏ qua bước này hoặc đánh giá thấp nó. Bước này có thể rất, rất quan trọng.

Sau đó là hành động: Làm thế nào để nó thực hiện công việc của mình? Nó có đúng công cụ để làm điều đó không? Tạo mã (code generation), Bash là những cách linh hoạt hơn để thực hiện hành động.

Và xác minh là một bước thực sự quan trọng khác. Về cơ bản, điều tôi muốn nói bây giờ là: nếu bạn đang nghĩ đến việc xây dựng một tác nhân, hãy suy nghĩ về việc liệu bạn có thể xác minh công việc của nó hay không. Nếu bạn có thể xác minh công việc của nó, đó là một ứng cử viên tuyệt vời cho một tác nhân. Nếu bạn không thể xác minh công việc của nó, thì... Giống như lập trình, bạn có thể xác minh bằng cách lint, và bạn có thể ít nhất đảm bảo nó biên dịch (compiles). Điều đó thật tuyệt. Nếu bạn đang thực hiện nghiên cứu chuyên sâu chẳng hạn, thực ra rất khó để xác minh công việc của bạn. Một cách bạn có thể làm là trích dẫn các nguồn (citing sources), vì vậy đó là một bước trong xác minh. Nhưng rõ ràng, nghiên cứu ít có khả năng xác minh hơn mã ở một số khía cạnh, bởi vì mã có một bước biên dịch. Bạn cũng có thể thực thi nó và xem nó làm gì.

Vì vậy, tôi nghĩ, khi chúng ta xây dựng các tác nhân, những tác nhân gần nhất với việc trở nên rất tổng quát là những tác nhân có bước xác minh rất mạnh mẽ.

Vâng, tôi nghĩ có một câu hỏi ở đây. Vâng, bạn có thể, ồ vâng, xin lỗi, câu hỏi là khi nào bạn tạo một kế hoạch (plan), nơi bạn chạy qua nó? Trong CodeX, bạn không phải lúc nào cũng tạo một kế hoạch, nhưng nếu bạn muốn, bạn sẽ làm điều đó giữa bước thu thập ngữ cảnh và thực hiện hành động. Kế hoạch giúp tác nhân suy nghĩ từng bước, nhưng chúng cũng làm tăng độ trễ (latency). Vì vậy, có một sự đánh đổi ở đó. Nhưng vâng, SDK tác nhân có thể giúp bạn thực hiện một số kế hoạch nữa.

Vâng, bạn có thể khiến tác nhân tạo danh sách việc cần làm (to-do list) để đảm bảo 100% mọi người tạo danh sách việc cần làm đó rồi duyệt qua nó. Vâng, câu hỏi là liệu tác nhân có tạo danh sách việc cần làm mà bạn làm việc cùng không? Có. Nếu bạn đang sử dụng SDK tác nhân, chúng tôi có một số công cụ về việc cần làm đi kèm, vì vậy nó sẽ duy trì và đánh dấu hoàn thành các việc cần làm, và bạn có thể hiển thị điều đó trong giao diện người dùng. Vâng.

Có câu hỏi nào khác về điều này không? Được rồi, tốt.

Các Công Cụ Chính để Xây Dựng Tác nhân

Tôi sẽ nhanh chóng nói về cách thực hiện những điều này, hay nói cách khác, các công cụ bạn có để thực hiện chúng. Có ba công cụ bạn có thể sử dụng: tools, Bash và code generation. Tôi nghĩ theo truyền thống, nhiều người chỉ nghĩ về tools. Về cơ bản, đó là một trong những kết nối, ít nhất là hiện tại, để suy nghĩ rộng hơn.

Tools được cấu trúc rất chặt chẽ và cực kỳ đáng tin cậy. Nếu bạn muốn có một đầu ra nhanh nhất có thể với ít lỗi và ít lần thử lại nhất, tools rất tuyệt vời. Nhược điểm của chúng là việc sử dụng context cao. Nếu bất kỳ ai đã xây dựng một tác nhân với 50 hoặc 100 tools, chúng chiếm rất nhiều context trong mô hình và mô hình có thể hơi bối rối. Không có khả năng khám phá tools, và chúng không có khả năng composable (có thể kết hợp). Tôi nói tools theo nghĩa nếu bạn đang sử dụng Messages hoặc completion API hiện tại. Đó là cách các tools hoạt động. Tất nhiên, có code mode và programming tool calling để bạn có thể kết hợp một số trong số này.

Về Bash, Bash rất composable, chẳng hạn như các script tĩnh, sử dụng context thấp. Nó có thể mất nhiều thời gian khám phá hơn, ví dụ, nếu bạn có playwright CLI hoặc Bash tool của Playwright. Bạn có thể dùng playwright --help để tìm hiểu tất cả những gì bạn có thể làm. Nhưng tác nhân cần thực hiện điều đó mỗi lần. Vì vậy, nó cần khám phá những gì nó có thể làm, điều này khá mạnh mẽ vì nó giúp loại bỏ một số việc sử dụng context cao nhưng lại làm tăng latency (độ trễ). Tốc độ gọi có thể hơi thấp hơn vì tác nhân cần thêm thời gian để tìm các tools và những gì nó có thể làm. Tuy nhiên, điều này chắc chắn sẽ cải thiện theo thời gian.

Cuối cùng là code generation (tạo mã). Đây là các script động có khả năng composable cao. Chúng mất thời gian thực thi lâu nhất, vì vậy chúng cần linking pots, week compilation. API design trở thành một bước rất thú vị ở đây, và tôi sẽ nói thêm về cách nghĩ về API design trong một tác nhân. Nhưng vâng, đây là ba công cụ bạn có.

Lựa Chọn và Ứng Dụng Công Cụ

Về việc sử dụng tools, bạn vẫn muốn có một số tools nhưng bạn muốn coi chúng như những atomic actions (hành động nguyên tử) mà tác nhân của bạn thường cần thực hiện theo trình tự, và bạn cần rất nhiều quyền kiểm soát đối với chúng. Ví dụ, trong Claude Code, chúng tôi không sử dụng Bash để ghi một tệp. Chúng tôi có write file tool của riêng mình, bởi vì chúng tôi muốn người dùng có thể xem đầu ra và phê duyệt nó, và chúng tôi không thực sự kết hợp write file với những thứ khác. Nó giống như một atomic action duy nhất. Gửi email là một ví dụ khác. Bất kỳ thay đổi nào không có tính phá hủy, có tính phá hủy, hoặc không thể hoàn tác đều là một trường hợp tốt để sử dụng tool.

Tiếp đến là Bash. Chẳng hạn, có những composable actions như chuyển đổi thư mục bằng GitHub, nâng cấp code và kiểm tra lỗi hoặc memory. Vâng, bạn có thể ghi các tệp vào memory và đó có thể là Bash của bạn, như Bash trở thành memory system của bạn.

Và cuối cùng, bạn có code generation. Nếu bạn đang cố gắng thực hiện logic rất động, rất linh hoạt này, kết hợp APIs như bạn làm trong phân tích dữ liệu, nghiên cứu sâu hoặc tái sử dụng các patterns. Vâng, chúng ta sẽ nói thêm về code generation sau một chút.

Xử Lý Đầu Ra Lớn của Công Cụ

Có câu hỏi nào về SDK loop hoặc tools so với Bash so với code gen không? Vâng. À, việc tải lên kết quả tools vào file system hoặc đó là Bash và context bị tràn. Hừm. Có giống như gõ lệnh để làm mọi thứ không? Hoặc nếu không thì chỉ là các đầu ra dài nằm trong lịch sử của bạn. Chắc chắn rồi. Vâng. Luôn tải chúng lên các tệp. Vâng. Vâng, tôi nghĩ đó là một thực tiễn tốt. Tôi nhớ đã thấy một số PRs về vấn đề này rất gần đây trên Claude Code về việc xử lý các đầu ra rất dài. Và tôi không biết chính xác, tôi nghĩ chúng ta đang hướng tới một nơi mà nhiều thứ hơn được lưu trữ trong file system. Và đây là một ví dụ tốt, vâng, như việc lưu trữ các đầu ra dài theo thời gian. Tôi nghĩ rằng nhìn chung, việc phức tạp hóa để thực hiện điều này là một cách tốt để suy nghĩ về nó. Hoặc ngay cả khi bạn có, tôi nghĩ một điều tôi luôn làm là bất cứ khi nào tôi có một tool call, tôi lưu trữ kết quả của tool call vào file system để bạn có thể tìm kiếm nó. Và sau đó, tool call trả về đường dẫn của kết quả. Chỉ vì điều đó giúp nó kiểm tra lại công việc của mình. Vì vậy, vâng.

Kỹ Năng (Skills) và Vai Trò của Chúng

Vâng, câu hỏi là về skills và việc sử dụng skills để sử dụng Bash tốt hơn. Vâng, để rõ hơn về context skills, skills về cơ bản là một cách để tác nhân của chúng ta thực hiện các tác vụ phức tạp, dài hơn và tải mọi thứ thông qua context. Ví dụ, chúng tôi có một loạt docx skills và những docx skills này cho tác nhân biết cách thực hiện code generation để tạo ra các tệp này. Vì vậy, nhìn chung, skills về cơ bản chỉ là một "điểm tựa" trong các tệp. Chúng cũng là một ví dụ về việc được "đóng gói công cụ" dưới dạng file system hoặc Bash. Bởi vì chúng thực sự chỉ là các thư mục mà tác nhân của bạn có thể cd vào và đọc.

Những gì chúng tôi đã tìm thấy là skills thực sự tốt cho các hướng dẫn có thể lặp lại mà cần nhiều expertise (chuyên môn) trong đó. Ví dụ, chúng tôi gần đây đã phát hành một front-end design skill mà tôi thực sự rất thích. Và nó thực sự chỉ là một lời nhắc rất chi tiết và tốt về cách thực hiện front-end design, nhưng nó đến từ kỹ sư front-end AI giỏi nhất của chúng tôi. Anh ấy thực sự đã đặt rất nhiều suy nghĩ và iteration (lặp lại) vào đó. Đó là một cách sử dụng skills.

Tương Lai của Mô hình và Chiến Lược Phát triển Tác nhân AI

Vậy câu hỏi là về skill.md so với CLAUDE.md và cách suy nghĩ về điều đó. Tôi nghĩ rằng tất cả những khái niệm này còn quá mới, bạn hiểu ý tôi không? Ngay cả Claude Code cũng chỉ được phát hành khoảng tám hoặc chín tháng trước, và skills mới được phát hành cách đây hai tuần. Tôi sẽ không giả vờ biết tất cả các best practices (thực tiễn tốt nhất) cho mọi thứ. Tôi nghĩ nhìn chung, skills là một hình thức của progressive context disclosure (tiết lộ ngữ cảnh dần dần), và đó là một pattern (mẫu hình) mà chúng ta đã nói nhiều. Với Bash và việc tham chiếu nó hơn là các tool calls thông thường, đó là cách để tác nhân nghĩ: "Được rồi, tôi cần làm điều này. Hãy để tôi tìm hiểu cách làm điều này." Và sau đó, khi bạn đọc skill.md, bạn yêu cầu nó tạo một tệp docx, và sau đó nó cd vào thư mục, đọc cách làm, viết một số script và tiếp tục.

Vì vậy, tôi nghĩ vẫn còn một số intuition (trực giác) cần xây dựng xung quanh việc chính xác bạn định nghĩa điều gì là một skill và cách bạn chia nhỏ nó. Nhưng vâng, tôi nghĩ vẫn còn rất nhiều best practices cần học hỏi ở đó.

Câu hỏi là liệu skills cuối cùng có phải là một phần của mô hình không, và liệu có cách nào để thu hẹp khoảng cách không? Tôi đã bỏ lỡ bài nói chuyện của Barry hôm qua, nhưng vâng, tôi nghĩ ý tưởng chung là mô hình sẽ ngày càng giỏi hơn trong việc thực hiện nhiều loại tác vụ khác nhau. Và skills là cách tốt nhất để cung cấp cho mô hình các out-of-distribution tasks (tác vụ nằm ngoài phân phối dữ liệu huấn luyện). Nhưng tôi sẽ nói một cách tổng quát rằng, thực sự rất khó, đặc biệt nếu bạn không ở trong một lab, để biết chính xác các mô hình đang đi đến đâu. Rule of thumb (nguyên tắc chung) của tôi là tôi cố gắng suy nghĩ lại hoặc viết lại mã tác nhân của mình khoảng sáu tháng một lần. Bởi vì tôi nghĩ rằng nó có thể đã thay đổi đủ để tôi đã đưa vào một số assumptions (giả định) ở đây.

Và tôi nghĩ rằng agent SDK (Bộ công cụ phát triển phần mềm tác nhân) của chúng tôi được xây dựng để càng nhiều càng tốt để advance with capabilities (tiến bộ cùng với các khả năng). Bash tool sẽ ngày càng tốt hơn. Chúng tôi đang xây dựng nó trên nền tảng Claude Code, vì vậy khi Claude Code phát triển, bạn sẽ nhận được những lợi ích đó ngay từ đầu. Nhưng đồng thời, mọi thứ bây giờ rất khác so với một năm trước trong AI engineering (kỹ thuật AI). Và tôi nghĩ một best practice chung đối với tôi là: "Này, chúng ta có thể viết code nhanh gấp 10 lần. Chúng ta cũng nên vứt bỏ code nhanh gấp 10 lần."

Và tôi nghĩ việc suy nghĩ về không phải quá Hege and your events về tương lai hiện tại ở đâu, mà là những gì chúng ta có thể làm hôm nay thực sự hiệu quả? Và hãy giành market share (thị phần) ngay hôm nay và đừng ngại vứt bỏ code sau này. Nếu bạn là một startup, đây có lẽ là advantage (lợi thế) lớn nhất mà bạn có so với các competitors (đối thủ). Các công ty lớn hơn có incubation cycles (chu kỳ ủ bệnh) sáu tháng. Và vì vậy, họ luôn bị mắc kẹt trong quá khứ về agent capabilities. Và advantage của bạn là bạn có thể nói, "Này, agent capabilities đang ở đây ngay bây giờ. Hãy để tôi xây dựng thứ gì đó sử dụng điều này ngay bây giờ."

Câu Hỏi Thảo Luận

Có bất kỳ câu hỏi nào khác về skills và Bash không? Có vẻ như có rất nhiều câu hỏi về skill. Vâng, tôi nghĩ ở phía sau, ai đó có thể phải hét lên. Vậy tại sao không dùng skill so với API? Chúng trông rất giống nhau. Vâng, câu hỏi là tại sao sử dụng skill so với API? Một câu hỏi hay.

Progressive Disclosure và Skills

Tôi nghĩ rằng, về cơ bản, tất cả những điều này là các hình thức của progressive disclosure giúp tác nhân xác định những gì cần làm. Tôi sẽ đi qua các ví dụ như việc bạn chỉ có một API trong phiên tạo prototype của chúng tôi — điều này hoàn toàn phụ thuộc vào trường hợp sử dụng. Tôi không nghĩ có một quy tắc chung. Tôi nghĩ rằng bạn nên đọc transcript và xem tác nhân của mình muốn gì. Nếu tác nhân của bạn luôn muốn những thứ liên quan đến API, tốt nhất là có một tệp API.ts hoặc API.py hoặc tương tự. Điều đó rất tuyệt.

Tôi nghĩ skills giống như một sự giới thiệu để suy nghĩ về hệ thống tệp như một cách lưu trữ context. Chúng là một trừu tượng tuyệt vời, nhưng có nhiều cách để sử dụng hệ thống. Tôi cũng nên nói rằng, với skills, bạn cần bash tool và một hệ thống tệp ảo (virtual file system) cùng những thứ tương tự. Vì vậy, Agent SDK về cơ bản là cách duy nhất để thực sự sử dụng skills ở mức độ tối đa hiện tại.

Marketplace cho Skills và Plugins

Câu hỏi đặt ra là liệu chúng ta có thể mong đợi một marketplace cho skills hay không. Vâng, Claude Code có một plugin marketplace mà bạn cũng có thể sử dụng với Agent SDK. Chúng tôi đang phát triển nó theo thời gian; đó là một phiên bản v0 rất sơ khai. Và về marketplace, tôi không chắc mọi người sẽ tính phí cho điều này, nó chỉ giống như một hệ thống khám phá (discovery system) nhiều hơn. Nhưng vâng, nó hiện có sẵn. Bạn có thể gõ /plugins trong Claude Code và tìm thấy một số plugins.

Khi Nào Dùng Agent SDK?

Câu hỏi là khi nào tôi nên sử dụng Agent SDK để giải quyết một vấn đề. Về cơ bản, nếu tôi đang xây dựng một tác nhân. Niềm tin chung của tôi là đối với bất kỳ tác nhân nào, bash tool mang lại rất nhiều sức mạnh và tính linh hoạt. Việc sử dụng hệ thống tệp cũng mang lại rất nhiều sức mạnh và tính linh hoạt. Bạn luôn có thể tối ưu hóa để tăng hiệu suất trên đó.

Trong phần tạo prototype của buổi nói chuyện này, chúng ta sẽ xem xét một ví dụ chỉ với tools và một ví dụ khác có bash và hệ thống tệp để so sánh hai cách tiếp cận này. Đó là ý của tôi khi nói về bashful built. Tôi thường bắt đầu với Agent SDK. Và tôi nghĩ rất nhiều người đã tiếp cận chủ đề này và bắt đầu làm như vậy.

Tất nhiên, tôi cũng muốn nói rằng có nhiều lúc Agent SDK khá khó chịu vì bạn có một network sandbox container và bạn cảm thấy khó chịu vì không muốn thực hiện điều đó. Ý tôi là, tôi muốn chạy nó trên trình duyệt cục bộ của mình. Tôi hoàn toàn hiểu điều đó. Tôi nghĩ có một sự đánh đổi thực sự về hiệu suất. Cách tôi nghĩ về nó giống như React so với jQuery. Khi tôi mới bắt đầu, tôi rất thích phát triển web. Bạn có thể dùng jQuery và Backbone, rồi React xuất hiện, do Facebook phát triển, và họ nói: "Đây là JSX, chúng tôi vừa tạo ra nó." Và bây giờ có lỗi bundle. Tôi thấy nó thật khó chịu. Nhưng nhìn chung, chúng giúp mô hình hoặc ứng dụng web mạnh mẽ hơn. Và tôi nghĩ rằng Agent SDK giống như React của các framework tác nhân đối với tôi, bởi vì chúng tôi xây dựng những thứ riêng của mình trên đó. Vì vậy, những phần thực sự khó chịu của nó chỉ là những điều chúng ta khó chịu khi cố gắng làm cho nó hoạt động.

Xử lý Bash Tools Tùy chỉnh

Câu hỏi là nếu bạn có bash tools tác nhân tùy chỉnh, làm thế nào để tác nhân có thể phát hiện chúng? Ý bạn là bash scripts phải không?

Vâng, tôi nghĩ rằng bạn chỉ cần đặt nó vào hệ thống tệp và nói với tác nhân rằng: "Này, đây là một script. Bạn có thể gọi nó." Tôi thường nghĩ trong context của Claude Agent SDK nơi hệ thống tệp và bash tools được liên kết với nhau. Đôi khi tôi thấy một anti-pattern là mọi người nói: "Ồ, chúng tôi sẽ lưu trữ bash tool ở một nơi ảo hóa này và nó sẽ không tương tác với các phần khác của agent loop." Điều đó gây khó khăn, vì nếu bạn có kết quả từ một tool lưu một tệp, thì bash tool của bạn không thể đọc nó, trừ khi tất cả nằm trong một container.

Vậy điều đó có trả lời câu hỏi của bạn không? Bạn chỉ cần đặt nó vào hệ thống tệp và nói với tác nhân rằng nó có quyền truy cập vào đó. Tôi sẽ thiết kế tất cả các CLI scripts của mình để có tùy chọn --help hoặc tương tự, để mô hình có thể gọi nó và sau đó nó có thể progressively disclose từng sub-command bên trong script.

Agent SDK và Chatbot truyền thống

Câu hỏi là khi nào chúng ta nên sử dụng Agent SDK? Chúng ta có nên sử dụng Agent SDK để xây dựng clonk.ai – một chatbot truyền thống hơn Claude Code không? Tôi nghĩ rằng Claude Code có giao diện rất giống với giao diện chatbot truyền thống. Nhưng đầu vào và đầu ra thực sự là bạn nhập mã vào, bạn có thể bảo vệ nó, bạn nhận được văn bản ra và bạn có thể thực hiện các hành động trên đường đi.

Bạn có thể đã thấy rằng khi chúng tôi triển khai tính năng tạo tài liệu cho clonk.ai, giờ đây nó có khả năng khởi tạo một hệ thống tệp và tạo bảng tính, tệp PowerPoint và những thứ tương tự bằng cách generating code. Và đó là, bạn biết đấy, chúng tôi đang trong quá trình hợp nhất các agent loop của chúng tôi và những thứ tương tự. Nhưng nhìn chung, clonk.ai ngày càng trở nên "dựa trên hệ thống tệp" nhiều hơn, bạn thấy điều đó với skills và memory tool và những thứ khác. Vì vậy, chúng tôi nghĩ đây là một điều rộng lớn mà bạn có thể sử dụng nói chung và tôi rất sẵn lòng thảo luận qua các ví dụ.

Truy cập Database: Tool, Bash hay Codegen?

Một câu hỏi nữa. Tôi đang cố gắng hiểu quy tắc chung về khi nào nên xây dựng tool hoặc sử dụng tool, khi nào nên đóng gói thứ gì đó bằng script hoặc chỉ để tác nhân tự do làm việc với bash. Ví dụ: tôi cần truy cập database. Đôi khi tôi có thể sử dụng MCP. Tôi có thể gói nó trong một script và tôi có thể chỉ để tác nhân gọi trực tiếp một endpoint từ đó bằng bash, phải không?

Đó là một câu hỏi tuyệt vời! Câu hỏi vẫn là khi nào nên sử dụng tools so với bash với codegen. Anh ấy đã đưa ra một ví dụ: "Tôi có một database và tôi muốn tác nhân có thể truy cập nó theo một cách nào đó. Tôi nên làm gì? Tôi có nên tạo một tool truy vấn database theo một cách nào đó không? Tôi có nên sử dụng bash hay codegen không?" Đây là ba cách để làm điều đó.

Tôi nghĩ rằng bạn có thể sử dụng bất kỳ cách nào trong số chúng. Và tôi nghĩ rằng một phần của vấn đề là không có một phương pháp hay nhất duy nhất. Đây là một vấn đề thiết kế hệ thống (system design problem).

Nhưng giả sử bạn muốn tác nhân truy vấn database thông qua một tool. Bạn sẽ làm điều đó nếu database của bạn rất có cấu trúc và bạn phải rất cẩn thận về việc đánh giá thông tin nhạy cảm của người dùng (Personally Identifiable Information - PII) hoặc những thứ tương tự. Bạn sẽ nói: "Này, tôi chỉ có thể nhận đầu vào này và tôi cần cung cấp đầu ra này, và tôi phải che giấu mọi thứ khác về database khỏi tác nhân." Rõ ràng, điều đó hạn chế những gì tác nhân có thể làm. Nó không thể viết một truy vấn rất động.

Nếu bạn đang viết một truy vấn SQL đầy đủ, tôi chắc chắn sẽ sử dụng bash hoặc codegen chỉ vì khi mô hình viết truy vấn SQL, nó có thể mắc lỗi. Và cách nó sửa lỗi là bằng cách thay đổi hoặc viết tệp, xem xét đầu ra, xem có lỗi nào không và sau đó lặp lại.

Vì vậy, nhìn chung, nếu tôi đang xây dựng một tác nhân ngày nay, tôi sẽ cấp cho nó quyền truy cập database nhiều nhất có thể và sau đó đặt hàng rào bảo vệ (guardrails). Tôi có thể sẽ hạn chế quyền ghi (write access) của nó theo nhiều cách khác nhau. Nhưng điều tôi có thể làm là tôi sẽ cấp cho nó quyền ghi và đặt các quy tắc cụ thể, sau đó đưa ra phản hồi nếu nó cố gắng làm điều gì đó mà nó không thể làm. Tôi biết đây là một vấn đề khá khó, nhưng tôi nghĩ đây là tập hợp các vấn đề chúng ta cần giải quyết. Chúng tôi đã xây dựng một trình phân tích bash tool. Đó là một vấn đề cực kỳ khó chịu, nhưng chúng tôi cần giải quyết nó để tác nhân có thể hoạt động một cách tổng quát. Điều tương tự cũng xảy ra với database: Vâng, khá khó để hiểu truy vấn đang làm gì. Nhưng nếu bạn có thể giải quyết điều đó, bạn có thể để tác nhân của mình hoạt động tổng quát hơn theo thời gian.

Vì vậy, tôi nghĩ rằng việc suy nghĩ một cách linh hoạt nhất có thể và giữ cho tools là các hành động rất cơ bản (atomic actions) mà bạn cần rất nhiều sự đảm bảo xung quanh.

Kiểm soát truy cập dựa trên vai trò (RBAC)

Vâng, câu hỏi là làm thế nào để đảm bảo rằng các kiểm soát truy cập dựa trên vai trò (role-based access controls) được xử lý. Thông thường, điều đó nằm trong cách bạn cấp khóa API (API Key) hoặc các máy chủ backend của bạn hoặc những thứ tương tự. Tôi nghĩ rằng điều tôi có thể làm là tạo các khóa API tạm thời tuyệt vời. Đôi khi mọi người tạo các proxy ở giữa để chèn các khóa API nếu bạn lo ngại về việc bị lạm dụng. Nhưng vâng, tôi sẽ tạo các khóa API cho các tác nhân của bạn được giới hạn theo những cách nhất định. Và sau đó ở backend, bạn có thể kiểm tra những gì nó đang cố gắng làm và nếu đó là một tác nhân, bạn có thể đưa ra phản hồi khác nhau.

Memory Tool và Hệ thống tệp

Vâng, tôi muốn hỏi một câu hỏi khác. Bạn có thể cho chúng tôi biết gì về memory tool nói chung không? Tôi không cố gắng giữ bí mật điều gì. Tôi không biết chính xác, tôi đã chạy mã. Nhưng tôi nghĩ rằng nó thường hoạt động trên hệ thống tệp và do đó được cho là sẽ có những người chăm sóc nó. Tôi muốn nói rằng chúng tôi đã nhận được câu hỏi này rất nhiều. Tôi sẽ chỉ sử dụng hệ thống tệp trong Claude Agent SDK. Tôi sẽ chỉ tạo một thư mục memories hoặc tương tự và yêu cầu nó ghi memories vào đó. Tôi không biết cách triển khai chính xác của memory tool, nhưng nó sử dụng hệ thống tệp theo cách đó.

Tính tái sử dụng và Giao tiếp giữa các Tác nhân

Vâng, câu hỏi cuối cùng về vấn đề này. Làm thế nào để bạn quản lý tính tái sử dụng? Giả sử cùng một tác nhân tương tác với hàng trăm người dùng khác nhau và mỗi lần nó tạo và thực thi. Làm thế nào chúng ta có thể tận dụng tính tái sử dụng đó?

Đó là một câu hỏi rất hay. Giả sử bạn có hai tác nhân tương tác với hai người khác nhau. Câu hỏi là làm thế nào để bạn suy nghĩ về tính tái sử dụng giữa các tác nhân hoặc làm thế nào các tác nhân giao tiếp?

Tôi nghĩ rằng đây là một điều cần được khám phá. Nhưng tôi nghĩ có rất nhiều phương pháp hay nhất và thiết kế hệ thống cần được thực hiện, bởi vì theo truyền thống với các ứng dụng web, bạn phục vụ một ứng dụng cho một triệu người. Còn với các tác nhân như với Claude Code, chúng tôi phục vụ một container một đối một. Khi bạn sử dụng Claude Code trên web, đó là container của riêng bạn. Vì vậy, không có nhiều giao tiếp giữa các container.

Các Mô hình Giao tiếp và Thiết kế Tác nhân

Đây là một mô hình rất, rất khác biệt. Tôi sẽ không nói rằng tôi biết chính xác thiết kế hệ thống tốt nhất để làm điều đó. Và tôi nghĩ có rất nhiều thực tiễn tốt nhất về việc: "Các tác nhân này đang tái sử dụng công việc. Làm thế nào chúng ta có thể cung cấp cho chúng các script tổng quát kết hợp công việc chúng đã thực hiện? Làm thế nào chúng ta có thể làm cho chúng chia sẻ công việc đó?"

Tôi thường nghĩ đây giống như một đoạn lạc đề về các khung làm việc giao tiếp tác nhân (Agent communication frameworks). Tôi sẽ nói rằng chúng ta có lẽ không cần phải... tôi nghĩ đây là một ý kiến cá nhân... chúng ta có lẽ không cần phải tái tạo một hệ thống giao tiếp mới. Các tác nhân giỏi trong việc sử dụng những thứ chúng ta đã có, như HTTP request, hash tools, API keys và các công cụ như name to pipe synology. Vì vậy, có lẽ các tác nhân chỉ đơn giản là thực hiện các HTTP request qua lại với nhau, sử dụng HTTP server. Có rất nhiều công việc thú vị ở đó. Tôi đã thấy mọi người tạo ra một diễn đàn ảo để các tác nhân của họ giao tiếp, nơi chúng đăng chủ đề, trả lời, v.v. Khá thú vị. Tôi nghĩ có rất nhiều điều để khám phá và phát hiện ở đó.

Thiết kế Tác nhân Bảng tính: Giới thiệu

Chúng ta sẽ tiếp tục một chút. Về thời gian thì sao? Vẫn còn đủ thời gian. Tuyệt. Vậy, một ví dụ về thiết kế một tác nhân. Đây không phải là buổi tạo prototype, nhưng tôi nghĩ đây sẽ là một cách tốt để chúng ta bắt đầu. Giả sử chúng ta đang tạo một tác nhân bảng tính (spreadsheet agent). Đâu là cách tốt nhất để tìm kiếm trong một bảng tính? Đâu là cách tốt nhất để thực thi mã trong một bảng tính? Đâu là cách tốt nhất để thực hiện hành động trong một bảng tính? Đâu là cách tốt nhất để liên kết các bảng tính? Tất cả những điều này đều rất thú vị. Tôi sẽ sử dụng Figma và chúng ta có thể xem xét nó.

Hãy cùng thảo luận. Hoặc bạn có thể dành vài phút để tự suy nghĩ về câu hỏi này. Bạn có một tác nhân bảng tính, bạn muốn nó có thể tìm kiếm, thu thập ngữ cảnh, thực hiện hành động, xác minh công việc của mình. Bạn sẽ nghĩ về nó như thế nào? Hãy dành chút thời gian để suy nghĩ và ghi chú. Mọi người đã có chút thời gian để suy nghĩ chưa? Có muốn thêm thời gian không?

Thảo luận về Tìm kiếm trên Bảng tính

Đâu là cách tốt nhất để một tác nhân tìm kiếm trong một bảng tính?

Việc tìm kiếm trong một bảng tính. Có ý tưởng nào không? Làm thế nào bạn tìm kiếm một bảng tính? Bạn sẽ làm gì? CSV. Okay, bạn có một CSV. Bây giờ, tác nhân của bạn muốn tìm kiếm CSV đó. Nó làm gì? Grep nó. Okay. Grep sẽ trông như thế nào? Bạn chỉ nhìn vào tất cả các tiêu đề. Nhìn vào các tiêu đề. Okay, các tiêu đề của tất cả các sheet. Tuyệt vời.

Giả sử tôi đang tìm kiếm doanh thu năm 2024 hoặc một cái gì đó. Bây giờ tôi đã có các tiêu đề của mình. Giả sử doanh thu nằm trong một cột doanh thu và sau đó có một... Okay, vậy giả sử nó giống như thế này, làm thế nào để tôi có được doanh thu vào năm 2026? Đây là một vấn đề khá phổ biến. Có doanh thu ở đây và cũng có 2026 ở đây. Vậy, nó giống như một bước đa chiều. Chúng ta có thể xem xét các tiêu đề, điều đó sẽ cung cấp cho chúng ta, ví dụ, nếu bạn chỉ kéo cái này, bạn sẽ nhận được 123 trăm. Vậy, chúng ta cần nhiều hơn một chút. Có ý tưởng nào khác không?

Phương pháp Tìm kiếm Nâng cao và Chuyển đổi Dữ liệu

Vâng, có một batch để sử dụng Arc, nó sẽ ổn thôi. Tôi nghĩ Arc. Vâng, và nó sẽ Arc cho cái gì? Tùy thuộc vào những gì bạn đang tìm kiếm. Vâng, đó là một câu hỏi, phải không? Người dùng đang tìm kiếm cái gì? Họ có lẽ đang tìm kiếm thứ gì đó như thế này: doanh thu năm 2026. Có lẽ sử dụng các API để sử dụng các công cụ Google và kết hợp tất cả các con số lại với nhau, hoặc chúng ta sẽ đề cập đến một số. Vâng, đó là việc sử dụng các API, như sử dụng các API Google để tra cứu. Điều đó thật tuyệt, nhưng giả sử chúng ta đang làm việc cục bộ. Chúng ta cần phải thiết kế các API này. Vâng, SQLite iter có thể so sánh CSV trực tiếp và hoạt động. Oh, thú vị. Okay. Vâng, tôi không biết điều đó. Tuyệt vời.

Vậy, vâng, bạn sử dụng SQLite để truy vấn CSV. Đó là một cách rất sáng tạo để suy nghĩ về các giao diện lập trình ứng dụng (API interface), phải không? Nếu bạn có thể dịch một cái gì đó thành một giao diện mà tác nhân biết rất rõ, thì điều đó thật tuyệt. Và vì vậy, nếu bạn có một nguồn dữ liệu, nếu bạn có thể chuyển đổi nó thành một SQL query, thì tác nhân của bạn thực sự biết cách tìm kiếm SQL. Vì vậy, suy nghĩ về những việc chuyển đổi này thực sự rất thú vị. Đó là một cách tuyệt vời để thiết kế một pha tìm kiếm tác nhân.

Vâng, rất tốt để xếp hạng trong công cụ với Claude smartness này để bắt đầu xếp hạng. Bởi vì đó là điều chúng ta đang nói đến ở đây là công cụ phù hợp. Vâng, Claude smartness để xếp hạng đúng công cụ cho một công việc. Vâng, nếu bạn nhắc lệnh nó, bạn biết đấy, hoặc tôi nghĩ đây là một trong những điều mà, tôi không biết, hãy tìm hiểu. Hãy đọc transcript nếu nó không phải là cách bạn có thể giúp nó. Vâng, tất cả những điều này giống như một trực giác, bạn biết đấy, giống như cưỡi ngựa. Không phải tôi đã từng cưỡi ngựa, nhưng tôi biết rằng bạn đang đưa ra những tín hiệu cho con ngựa hoặc cố gắng tìm hiểu cách làm thế nào để thúc nó nhanh hơn, bạn biết không? Ý tôi là, nó giống như một thứ rất hữu cơ, phải không? Tôi nghĩ chúng ta thích nói rằng các mô hình được "nuôi dưỡng" chứ không phải được "thiết kế", phải không? Vì vậy, chúng ta giống như đang tìm hiểu các khả năng của chúng.

Vâng, đó là một mẫu hình tuyệt vời khác, đó là: "Bạn có thể thêm metadata vào bảng tính không?" Vì vậy, đây là một số câu hỏi mà bạn có thể muốn suy nghĩ trước khi, ví dụ, khi bạn đang nghĩ về tìm kiếm, đó là: "Bạn có thể thực hiện tiền xử lý (pre-processing) nào để làm cho việc tìm kiếm tốt hơn không?" Và một ví dụ là bạn dịch nó sang định dạng SQL hoặc một cái gì đó mà bạn có thể truy vấn được. Đó là một bước chuyển đổi. Một bước khác là có thể bạn có một công cụ hoặc một bước tiền xử lý nơi một tác nhân khác đã thêm vào bảng tính và thêm thông tin để tác nhân có thể tìm kiếm thông tin đó tốt hơn.

Khai thác Kiến thức và Khả năng Sáng tạo của Tác nhân

Vâng, một điều nữa. Tôi tò mò. Ý tôi là, tất cả những công cụ đó nghe có vẻ tuyệt vời, nhưng tác nhân không thể chỉ đơn giản là làm theo những gì đã được đề xuất, đọc tiêu đề và sau đó lấy ngày sao? Nhưng tôi cảm thấy đó nên là một tái nhiệm vụ tốt. Vâng, có lẽ tôi nên chuẩn bị cái này bằng mã. Nhưng vâng, tôi đã xây dựng một loại tác nhân bảng tính trước đây. Về cơ bản, nó không hoạt động. Khá khó để làm được điều đó.

Và vì vậy, về cơ bản, điều tôi sẽ nghĩ là, chúng ta có... tôi có nên gợi ý và đi và làm thế nào có thể nói và mã cùng lúc không? Ồ, làm việc nó được ưu tiên hay gì đó. Có một nút micrô ở phía sau, dán đèn vào áo sơ mi của bạn. Ồ, vậy thì, một cách để làm điều đó là, bạn thấy trong bảng tính, phải không? Bạn có thể nói ở đây, bạn có thể thiết kế công thức, phải không? Như B2. Đây là cú pháp mà tác nhân khá quen thuộc, ví dụ: B3 đến B5. Và vì vậy, bạn có thể thiết kế một giao diện tìm kiếm tác nhân (agentic search interface) giống như thế này, phải không? Như B3, B5 hoặc một cái gì đó, phải không? Vì vậy, giao diện tìm kiếm tác nhân của bạn có thể nhận vào một phạm vi (range), phải không? Nhận vào một chuỗi phạm vi (range string), phải không? Và đây là những thứ mà tác nhân biết khá rõ, phải không? Bạn có thể thực hiện các SQL query, phải không? Các tác nhân thực hiện các SQL query khá tốt, phải không? Và, bạn cũng có thể thực hiện XML hoặc nó ở trên cái này nhỏ? Okay. Vâng, bạn cũng có thể thực hiện XML. Tôi không chắc bạn có biết không nhưng các tệp XSLT là XML ở phần backend, phải không? Và XML rất có cấu trúc. Bạn có thể thực hiện một truy vấn tìm kiếm XML. Và có các thư viện khác nhau có thể làm điều đó.

Vì vậy, đó là một ví dụ, phải không? Là làm thế nào để bạn tìm kiếm và thu thập ngữ cảnh? Và tôi hy vọng điều này phần nào minh họa cho bạn rằng việc thu thập ngữ cảnh thực sự rất sáng tạo, phải không? Và có rất nhiều lần lặp lại và nếu bạn chỉ, nếu bạn chỉ thử một lần lặp, có lẽ không đủ để bạn nghĩ về càng nhiều cách khác nhau càng tốt. Hãy thử những điều này, phải không? Hãy thử SQL, thử tìm kiếm, thử grep trong Excel và tất cả những điều này và cách một vài thử nghiệm chúng đã thử nghiệm trên các thứ khác nhau và xem tác nhân thích gì và không thích gì. Nó sẽ khác nhau cho mỗi trường hợp.

Vâng, kiến thức. Vâng, câu hỏi là kiến thức đến từ đâu? Nó có trong mô hình không? Hay ý tôi là tác nhân là gì? Vâng, nhìn chung, điều tôi nghĩ bạn đang tìm kiếm là bạn có một vấn đề. Bạn muốn làm cho nó càng trong phân phối (in distribution) càng tốt cho tác nhân, phải không? Và vì vậy, tác nhân biết rất nhiều về rất nhiều thứ khác nhau. Nó biết rất nhiều về, ví dụ, tài chính, phải không? Vì vậy, nếu bạn yêu cầu nó tạo một mô hình DCF, nó biết DCF là gì, phải không? Và bạn có thể, nếu bạn muốn cung cấp thêm thông tin, bạn có thể tạo một kỹ năng. Nhưng vì vậy, bạn có thể biết DCF là gì, nó biết SQL là gì. Liệu nó có thể kết hợp những thứ đó lại với nhau không? Và vì vậy, lý tưởng nhất là bạn muốn... vấn đề của bạn sẽ ngoài phân phối (out of distribution) theo một cách nào đó, phải không? Giống như có một số thông tin không có trên internet hoặc một cái gì đó bạn có, hoặc một cái gì đó hơi độc đáo đối với bạn và bạn muốn cố gắng "xoa bóp" nó để trở thành trong phân phối càng nhiều càng tốt. Và vâng, nó rất, rất sáng tạo. Tôi nghĩ rằng, bạn biết đấy, nó không phải là một khoa học để có mặt ở đó. Rất giống một nghệ thuật.

Thực hiện Hành động và Xác minh Công việc

Okay, vậy chúng ta đã thử thu thập ngữ cảnh, sau đó thực hiện hành động. Chúng ta có thể làm nhiều điều tương tự ở đây như chúng ta đã làm trước đây, phải không? Như chúng ta có thể thực hiện insert vào mảng, phải không? Nếu bạn có một giao diện SQL, phải không, chúng ta có thể, chúng ta có thể thực hiện truy vấn SQL, chúng ta có thể chỉnh sửa XML. Những điều này thường rất giống nhau, phải không? Như thực hiện hành động và thu thập ngữ cảnh, bạn có lẽ muốn một API tương tự qua lại.

Và sau đó điều cuối cùng là xác minh công việc, phải không? Bạn nghĩ về điều đó như thế nào? Kiểm tra các con trỏ null (null pointers), phải không, là một trong những cách để làm điều đó. Có ý tưởng nào khác về xác minh không?

Xác minh Công việc của Tác nhân và Tác nhân QA

Vâng, xin lỗi, tôi hơi bối rối. Khi bạn đang sử dụng cái khác, đó có phải là trường hợp để xây dựng tác nhân không? Vâng, tôi không cần phải nói cho nó biết cách thu thập ngữ cảnh. Chắc chắn, tôi chỉ cung cấp ngữ cảnh và giải thích đây là những gì như tiếng Anh đơn giản, vâng, điều này có nghĩa là gì, vâng. Và điều tôi thường làm, và bạn hãy nói cho tôi biết nếu tôi sai, tôi thực sự tạo ra một tác nhân riêng biệt cho QA. Ồ, tôi chỉ nói để xác minh vì tôi không tin tưởng tác nhân tự xác minh. Nhưng tôi chỉ... tôi chỉ... tôi nghĩ là bối rối về mức độ chi tiết tôi cần cung cấp cho tác nhân trong ví dụ đó.

Vâng, okay, vậy câu hỏi là về việc bạn cung cấp ngữ cảnh cho tác nhân hay để nó tự thu thập ngữ cảnh của mình. Bạn đã đề cập rằng đôi khi bạn sử dụng một tác nhân QA. Tôi có thể hỏi bạn đang làm tác nhân B-Liger trong lĩnh vực nào hoặc không phải, an ninh mạng. Okay, chắc chắn. Vâng, tôi nghĩ rằng tôi cần tìm hiểu thêm các chi tiết cụ thể, nhưng Claude Agent SDK rất tuyệt cho an ninh mạng và tôi thường khuyến khích mọi người hãy để tác nhân thu thập ngữ cảnh càng nhiều càng tốt, bạn biết đấy, hãy để nó tự tìm công việc của mình càng nhiều càng tốt. Bạn đang cố gắng cung cấp cho nó các công cụ để tự tìm công việc của mình. Cách tôi nghĩ về điều này giống như giả sử ai đó nhốt bạn vào một căn phòng và họ giao cho bạn các nhiệm vụ, bạn biết đấy, vì vậy đó là công việc của bạn. Giống như một Ông. [transcript bị gián đoạn]

Tác nhân và Công cụ

Hãy hình dung một kịch bản: bạn sẽ nhận được năm tấn đô la nếu bạn ở trong căn phòng này sáu tháng. Vậy thì, nếu ai đó đưa cho bạn một thông điệp, bạn sẽ muốn có những công cụ nào để thực hiện nhiệm vụ đó? Bạn có chỉ muốn một danh sách các tài liệu, hay bạn muốn một máy tính, hoặc một máy tính để bàn? Có lẽ tôi sẽ muốn một máy tính để bàn, đúng không? Tôi sẽ muốn Google, tôi sẽ muốn tất cả những thứ đó. Vì vậy, tôi sẽ không muốn người đó gửi cho tôi một chồng giấy tờ và nói, "Chà, đây có lẽ là tất cả thông tin bạn cần." Thay vào đó, tôi muốn nói, "Hãy đưa cho tôi một máy tính, đưa cho tôi vấn đề. Hãy để tôi tìm kiếm và tự giải quyết." Đó cũng là cách tôi nghĩ về các tác nhân. Giống như, bạn biết đấy, chúng bị kẹt trong một căn phòng, tôi cần cung cấp cho chúng các công cụ. Vì vậy, nếu bạn có thể quay lại các slide, quay lại biểu đồ bạn có. Quay lại biểu đồ này. Về cơ bản, ngữ cảnh được thu thập chính là các công cụ mà tôi đang cung cấp. Vâng, chính xác. Tôi đang cung cấp cho nó một API để tạo mã, có thể tôi đang cung cấp một công cụ SQL, có thể tôi đang cung cấp một huy hiệu. Đây đều là những ví dụ.

Quản lý Ngữ cảnh bằng Sub agent

Họ sẽ không đặt câu hỏi. Thật thú vị. Vâng, vậy các tác nhân có chia sẻ ngữ cảnh cho bạn không? Tôi nghĩ đây là một câu hỏi thú vị về cách bạn quản lý ngữ cảnh nói chung. Tôi nghĩ — và tôi chưa nói nhiều về điều này — nhưng các sub agent (tác nhân con) là một cách rất quan trọng để quản lý ngữ cảnh. Tôi nghĩ rằng chúng ta đang sử dụng ngày càng nhiều sub agent trong Claude Code. Và tôi sẽ nghĩ về việc triển khai các sub agent một cách rất tổng quát. Ví dụ, đối với tác nhân gian lận này, có thể chúng ta có một sub agent tìm kiếm, phải không? Các sub agent rất hữu ích khi bạn cần thực hiện nhiều công việc và trả về một câu trả lời cho tác nhân chính. Ví dụ về tìm kiếm, giả sử câu hỏi là, "Làm thế nào để tìm doanh thu của tôi vào năm 2026?" Có thể bạn cần thực hiện một loạt các thao tác tìm kiếm. Có thể bạn cần tìm kiếm trên internet. Có thể bạn cần tìm kiếm trong bảng tính và những thứ tương tự. Và có nhiều thứ không cần thiết phải đi vào ngữ cảnh của tác nhân chính. Tác nhân chính chỉ cần xem kết quả cuối cùng, đúng không? Và đó là một nhiệm vụ tuyệt vời cho sub agent. Tôi không có slide riêng về sub agent ở đây, nhưng chúng thực sự rất hữu ích và tôi nghĩ đó là một cách tuyệt vời để suy nghĩ về mọi thứ.

Sub agent cho Xác minh và Hàng rào bảo vệ

Vâng, để mở rộng câu hỏi đó, thực ra, đối với xác minh chẳng hạn, bạn có thể hình dung việc thực hiện nó thông qua một kỹ năng hoặc một sub agent. Bạn thậm chí có thể muốn có một ví dụ bảo mật đối kháng. Vậy thì, một câu hỏi hay. Tôi không đi sâu vào nó và không thực sự có mối quan hệ đồng cảm với công việc đã hoàn thành. Vì vậy, tôi biết tôi đi đến nhiều khía cạnh, nhưng bạn có, bạn đang nói là có? Bạn thực hiện sub agent ở đây, bạn thực hiện kỹ năng. Bạn sẽ nghĩ về điều này như thế nào? Vâng, chắc chắn. Vậy thì, câu hỏi là, liệu một số tác nhân hay tôi chắc chắn nó sẽ hoạt động, để nó đảm bảo. Ồ, chắc chắn rồi, cảm ơn. Vâng, bạn có thể sử dụng sub agent cho xác minh không? Có, tôi nghĩ đây là một mô hình. Tôi nghĩ rằng, lý tưởng nhất, hình thức xác minh tốt nhất là dựa trên quy tắc, đúng không? Bạn sẽ nghĩ, "Có con trỏ null hay gì đó không?" Đó là xác minh dễ dàng. Nó không kiểm tra độ dài hoặc biên dịch. Bạn hãy cố gắng chèn càng nhiều quy tắc càng tốt, và một lần nữa, hãy sáng tạo, phải không? Ví dụ, trong Claude Code, nếu tác nhân cố gắng ghi vào một tệp mà chúng ta biết nó chưa đọc — như chúng ta chưa thấy nó đi vào bộ nhớ đệm đọc — chúng ta sẽ báo lỗi. Chúng ta sẽ nói với nó, "Này, bạn chưa đọc tệp này; hãy thử đọc nó trước," phải không? Và đó là một ví dụ về một công cụ xác định mà chúng ta chèn vào bước xác minh. Và vì vậy, càng nhiều càng tốt, bất cứ khi nào bạn nghĩ về xác minh, bước đầu tiên là, "Bạn có thể làm gì một cách xác định? Bạn có thể tạo ra những loại đầu ra nào?" Và một lần nữa, khi bạn chọn loại tác nhân nào để tạo, các tác nhân có nhiều quy tắc xác định hơn sẽ tốt hơn. Bạn biết đấy, điều đó rất hợp lý, phải không? Vì vậy, tất nhiên, khi các mô hình ngày càng tốt hơn trong việc suy luận, thì bạn có thể có các sub agent này để kiểm tra công việc của tác nhân chính. Điều chính ở đây là tránh ô nhiễm ngữ cảnh (context pollution), vì vậy bạn có lẽ sẽ không muốn phân tách ngữ cảnh. Bạn có lẽ sẽ muốn bắt đầu một phiên ngữ cảnh mới và chỉ cần nói, "Này, hãy kiểm tra đối kháng công việc của, ví dụ, đầu ra này được tạo bởi một nhà phân tích cấp dưới tại McKinsey hoặc một cái gì đó; họ tốt nghiệp từ, giống như, không phải một trường cấp một, giống như hai năm học piano của bạn." Kiểu như, bạn chỉ cần nạp một loạt thứ vào và sau đó yêu cầu nó phê bình, đúng không? Đó là một trong những công cụ của sub agent, phải không? Và vì vậy, vâng, càng nhiều bạn càng, vâng, các mô hình càng ngày càng tốt hơn, và loại xác minh đó cũng sẽ trở nên tốt hơn. Nhưng việc thực hiện nó một cách xác định là một khởi đầu tuyệt vời.

Quản lý Trạng thái và Khả năng Hoàn tác

Chỉ một câu hỏi về công việc của bearer. Vâng. Đó là nơi chúng tôi tìm thấy con trỏ null. Có lẽ dễ dàng để chỉ khắc phục nó. Nhưng, bạn biết đấy, đó là thứ chúng ta có thể đưa vào sản xuất và cho khách hàng. Vì vậy, bạn biết đấy, điều đó không phải... Bằng cách nào đó chúng ta có thể rơi vào tình huống toàn bộ bảng tính bị xóa. Vậy thì, ở cấp độ nào chúng ta cần tích hợp khả năng hoàn tác? Bởi vì, ví dụ, tác nhân QA xác định rằng bảng tính của họ trống rỗng. Vâng, không nhất thiết là có khả năng. Vậy lời khuyên của bạn là gì? Vâng, câu hỏi là, "Bạn nghĩ thế nào về trạng thái và việc hoàn tác cũng như làm lại để có thể sửa lỗi, về cơ bản, đúng không?" Tôi nghĩ đây là một câu hỏi thực sự hay. Và thành thật mà nói, một loại khác, khi bạn nghĩ về tác nhân giỏi điều gì, phải không? Hoặc tác nhân giỏi trong các miền vấn đề nào? Mức độ khả năng hoàn tác của công việc là một trực giác thực sự tốt, đúng không? Vì vậy, mã nguồn khá dễ dàng hoàn tác. Bạn chỉ cần quay lại và hoàn tác lịch sử git. Chúng ta có những thao tác nguyên tử này ngay từ đầu, phải không? Giống như, tôi liên tục sử dụng git thông qua Claude Code. Tôi không gõ lệnh nữa, đúng không? Vì vậy, đó là một ví dụ thực sự tốt. Một ví dụ thực sự tệ là sử dụng máy tính (computer use), bạn biết đấy, bởi vì sử dụng máy tính không có khả năng hoàn tác về trạng thái, đúng không? Ví dụ, bạn vào doordash.com và bạn thêm — giống như người dùng muốn bạn đặt một chai Coke, và bạn thêm — đặt một chai Pepsi. Bây giờ, bạn không thể chỉ quay lại và nhấp vào Coke. Bạn phải vào giỏ hàng và bạn phải loại bỏ Pepsi, đúng không? Và vì vậy lỗi của bạn đã bị chồng chất. Cái trạng thái và máy trạng thái này đã trở nên phức tạp hơn, đúng không? Và vì vậy, bất cứ khi nào chúng ta đối phó với các máy trạng thái rất, rất phức tạp mà bạn không thể hoàn tác hoặc làm lại, nó thực sự trở nên khó khăn hơn, đúng không? Và tôi nghĩ một trong những câu hỏi dành cho bạn với tư cách là một kỹ sư là, "Bạn có thể biến cái này thành một máy trạng thái có khả năng hoàn tác không, giống như bạn đã nói? Bạn có thể lưu trạng thái giữa các điểm kiểm tra sao cho người dùng có thể nói, 'Ồ, bảng tính của tôi đang bị lỗi; chỉ cần quay lại điểm kiểm tra trước đó,' phải không?" Thậm chí có thể mô hình và quay lại các điểm kiểm tra trước đó. Tôi nghĩ ai đó đã có công cụ du hành thời gian này mà họ đang cung cấp cho một trong các tác nhân lập trình, điều đó khá thú vị. Khi bạn nói, "Nó giống như bạn có thể du hành thời gian trở lại một điểm trước khi điều này xảy ra," bạn hiểu ý tôi chứ? Điều đó khá vui. Tôi nghĩ tất cả những công cụ này, một số trong số chúng chưa hoạt động tốt lắm, nhưng bạn biết đấy, chúng ta sẽ đạt được điều đó. Chúng ta cần suy nghĩ về trạng thái và xác minh rất hữu ích, đúng không?

Xử lý Dữ liệu Lớn và Context Window

Vâng, câu hỏi ở phía sau. Vâng, hơi tò mò về khả năng mở rộng. Vậy thì, nếu bảng tính này có hàng triệu hàng và hàng nghìn cột thì sao? Hoặc bất kỳ... Trong tình huống đó, bạn sẽ tìm kiếm như thế nào? Rõ ràng có một nút ngữ cảnh? Bạn phải gọi cho tôi. Vâng, điều này thật tuyệt vời. Lẽ ra tôi nên dùng ví dụ bảng tính làm ví dụ lập trình của mình. Để xem trước, tác nhân lập trình của tôi là một tác nhân Pokémon. Một bảng tính sẽ tốt hơn. Được rồi. Câu hỏi là, "Nếu bảng tính này rất lớn, nếu bạn có một triệu hàng? Bạn nghĩ gì về 100 cột?" Vâng, 100.000 cột hay 100 cột hay bất cứ thứ gì, bạn nghĩ sao về điều đó? Đúng vậy, giống như cơ sở dữ liệu của bạn cũng rất lớn, bạn làm điều đó như thế nào? Ừm, tôi nghĩ đối với tất cả những điều này, thứ nhất, tất nhiên, khi dữ liệu ngày càng lớn hơn, đó chỉ là một vấn đề khó hơn, bạn biết đấy. Chắc chắn là như vậy; độ chính xác của bạn sẽ giảm xuống, phải không? Giống như Claude Code hoạt động kém hơn trong các cơ sở mã lớn hơn so với các cơ sở mã nhỏ hơn. Đúng vậy, khi các mô hình trở nên tốt hơn, chúng sẽ tốt hơn trong tất cả những điều đó. Ừm, từ tất cả những điều này, tôi sẽ nghĩ về việc, tôi sẽ làm điều này như thế nào nếu tôi có một bảng tính với hàng triệu cột và hàng triệu hàng? Tôi sẽ làm gì? Ý tôi là, tôi sẽ cần bắt đầu tìm kiếm nó, phải không? Tôi sẽ giống như — nếu tôi đang tìm kiếm doanh thu, tôi sẽ tìm kiếm Ctrl + F revenue và sau đó tôi sẽ kiểm tra từng kết quả này, và tôi sẽ nói, "Điều này có đúng không?" Và sau đó, tôi sẽ xem, "Có số nào ở đây không?" Và sau đó tôi có thể sẽ giữ một bản nháp, giống như một trang tính mới nơi tôi nói, "Này, doanh thu bằng cái này," bạn biết đấy, và sau đó lưu trữ tham chiếu này và tiếp tục. Tôi nghĩ đó là một cách tốt nếu chúng xuất hiện. Giống như các mô hình nên — và bạn không bao giờ nên đọc toàn bộ bảng tính vào ngữ cảnh vì nó sẽ mất quá nhiều, phải không? Giống như, bạn muốn cung cấp cho nó một lượng ngữ cảnh khởi đầu. Và đó cũng là cách bạn làm việc, phải không? Ví dụ, giả sử bạn mở bảng tính, những gì bạn thấy là các hàng. Điều này có đúng không? Bạn thấy, giống như 10 hàng đầu tiên và khoảng 30 cột đầu tiên, đúng không? Đó là những gì bạn thấy. Bạn không tải tất cả vào ngữ cảnh ngay lập tức. Bạn có lẽ có trực giác rằng, "Này, tôi nên tải thêm cái này vào ngữ cảnh," phải không? Và, và như, "Ồ, tôi nên điều hướng đến trang tính khác này," phải không? Và trang tính khác này có nhiều dữ liệu hơn, phải không? Nhưng bạn cần, giống như, tự mình thu thập ngữ cảnh, phải không? Và vì vậy tác nhân có thể hoạt động theo cùng một cách. Nó có thể, giống như, điều hướng để xem các trang tính này, đọc chúng, giống như, cố gắng, giống như, giữ một bản nháp, giữ một số ghi chú và tiếp tục. Đó là những gì tôi sẽ nghĩ về nó.

Tối ưu hóa Sử dụng Context Window

À, vâng, ở phía sau. Vâng, câu hỏi của tôi là về việc quản lý ô nhiễm ngữ cảnh, và thực ra, tôi đoán nó liên quan đến câu hỏi trước đó. Ừm, bạn có quy tắc chung nào về, bạn biết đấy, tỷ lệ cửa sổ ngữ cảnh nên sử dụng là bao nhiêu trước khi bạn bắt đầu bất kỳ kích thước trả về nào hoặc chỉ đơn giản là nó trở nên kém hiệu quả hơn không? Vâng, câu hỏi là, "Vâng, quản lý ngữ cảnh, bạn có quy tắc chung nào về việc nên sử dụng bao nhiêu cửa sổ ngữ cảnh trước khi nó trở nên kém hiệu quả hơn không?" Đây thực sự là một vấn đề khá thú vị hiện nay. Ừm, tôi nghĩ rất nhiều lần khi tôi nói chuyện với những người đang sử dụng Claude Code, họ đều nói, "Tôi muốn nhỏ gọn lần thứ năm của mình."

Quản lý Cửa sổ Ngữ cảnh và Trải nghiệm Người dùng

Tôi như thể chưa bao giờ thực hiện một thao tác compact trước đây. Ý tôi là tôi phải tự mình kiểm tra trải nghiệm người dùng (UX) bằng cách ép mình phải thực hiện compact. Chỉ vì tôi có xu hướng xóa cửa sổ ngữ cảnh rất thường xuyên khi tự mình sử dụng Claude Code. Ít nhất là trong code, trạng thái nằm trong các tệp của cơ sở mã. Vì vậy, giả sử tôi đã thực hiện một số thay đổi, Claude Code có thể chỉ nhìn vào git diff của tôi và nói: "À, đây là những thay đổi bạn đã thực hiện." Nó không cần phải biết toàn bộ lịch sử trò chuyện (chat history) của tôi để tiếp tục một nhiệm vụ mới. Vì vậy, trong Claude Code, tôi xóa ngữ cảnh rất, rất thường xuyên và tôi nói: "Này, hãy xem các thay đổi git còn tồn đọng của tôi. Tôi đang làm việc với cái này. Bạn có thể giúp tôi mở rộng nó theo cách này không?" Đó là một cách để suy nghĩ về nó.

Khi bạn đang xây dựng tác nhân của riêng mình, chẳng hạn như chúng ta đang xây dựng một tác nhân bảng tính (spreadsheet agent), mọi thứ sẽ phức tạp hơn một chút vì người dùng của bạn ít hiểu biết về kỹ thuật hơn và họ không biết cửa sổ ngữ cảnh là gì. Đó là một vấn đề khó khăn. Tôi nghĩ có một số thiết kế trải nghiệm người dùng (UX design) ở đó, chẳng hạn như: "Bạn có thể đặt lại trạng thái cuộc trò chuyện không? Có thể mỗi khi người dùng hỏi một câu hỏi mới, bạn có thể tự mình thực hiện compact hoặc tương tự và tóm tắt ngữ cảnh không?" Trong một bảng tính, phần lớn trạng thái nằm trong chính bảng tính. Vì vậy, có lẽ nó không cần biết toàn bộ ngữ cảnh. Bạn có thể lưu trữ tùy chọn người dùng (user preferences) khi nó hoạt động để bạn nhớ một số thứ này. Có rất nhiều thứ, một lần nữa, đó là một nghệ thuật, có rất nhiều góc độ và cách khác nhau mà bạn có thể làm điều này. Nhưng bạn đang cố gắng giảm thiểu việc sử dụng ngữ cảnh. Bạn có lẽ không cần một triệu ngữ cảnh hay gì đó. Ý tôi là bạn chỉ cần quản lý ngữ cảnh tốt, thiết kế trải nghiệm người dùng (UX design). Đó chính xác là ngữ cảnh của bài thuyết trình (porridge).

Sử dụng Tác nhân phụ (sub-agents) cho Xử lý Song song

Tác nhân phụ (sub-agents) được tạo ra để tôi có thể sử dụng nhiều tác nhân phụ và cố gắng tạo ra một quy trình để chúng tôi chia nhỏ (chunk up) bảng tính này trong trường hợp nó siêu lớn, sau đó các tác nhân có thể chạy qua từng phần một cách song song. Đúng vậy, tôi muốn nói rằng, một trong những điều tôi yêu thích về Claude Code là chúng tôi mang lại trải nghiệm tốt nhất cho bạn trong tác nhân phụ. Đặc biệt là tác nhân phụ với bash, nó rất, rất tốt. Tôi không hoàn toàn nhận ra tất cả những khó khăn, tôi nghĩ nếu bất cứ ai đi đến KubeCon, tôi tin Adam Wolf sẽ có một bài nói chuyện tại KubeCon về cách chúng tôi đã thực hiện công cụ bash. Công cụ bash của Adam đã làm rất tốt.

Khi bạn chạy các tác nhân phụ song song (parallel sub-agents) cùng lúc, bash trở nên rất phức tạp và có rất nhiều điều kiện chạy đua (race conditions) và những thứ tương tự. Vì vậy, có rất nhiều công việc mà chúng ta đã giải quyết ở đó. Vì vậy, đây là một trong những điều tôi yêu thích về Claude Code là bạn có thể nói: "Này, hãy khởi tạo ba tác nhân phụ để thực hiện nhiệm vụ này." Và chúng tôi sẽ làm điều đó, và trong Agent SDK nữa, bạn có thể yêu cầu nó làm điều đó. Vì vậy, số một, tác nhân là một nguyên thủy (primitive) tuyệt vời trong Agent SDK và tôi chưa thấy ai làm tốt như vậy. Vì vậy, đó là một lý do lớn để sử dụng nó. Vâng, nói chung, bạn muốn các tác nhân phụ này làm phong phú thêm ngữ cảnh. Giả sử bạn có một bảng tính, bạn có thể có nhiều tác nhân phụ đọc đang hoạt động cùng một lúc.

Vì vậy, có lẽ tác nhân chính sẽ nói: "Này, tác nhân này có thể đọc và tóm tắt Trang một không? Tác nhân này có thể đọc và tóm tắt Trang hai trong khu vực này, tóm tắt Trang ba không?" Và sau đó chúng trả về kết quả của chúng, và sau đó tác nhân chính có thể khởi tạo thêm các tác nhân phụ nữa. Vì vậy, đây là một yếu tố điều khiển khác mà bạn có.

Trừu tượng hóa và Tập trung vào Vấn đề Cốt lõi

Và tôi nghĩ điều tôi muốn nói là chúng ta đã nói rất nhiều về tất cả các cách sáng tạo khác nhau mà bạn có thể làm mọi thứ. Đây là mức độ mà bạn nên suy nghĩ về vấn đề của mình. Theo ý kiến của tôi, bạn không nên thực sự nghĩ về việc: "Làm thế nào để tôi khởi tạo một tiến trình để tạo một tác nhân phụ?" hay, bạn biết đấy, kỹ thuật hệ thống (system engineering) giữa như thế nào, và "Một compact là gì?" Vì vậy, chúng tôi lo tất cả những điều này cho bạn trong khung điều khiển (harness) để bạn có thể suy nghĩ về việc: "Tôi cần khởi tạo những tác nhân phụ nào?" và "Làm thế nào để tôi tạo giao diện tìm kiếm tác nhân (agentic search interface)?" và "Làm thế nào để tôi xác minh công việc của nó?" Đây là những vấn đề thực sự cốt lõi và khó khăn mà bạn phải giải quyết, và bất cứ lúc nào bạn dành thời gian không giải quyết những vấn đề này mà giải quyết những vấn đề cấp thấp hơn, bạn có lẽ đang không mang lại giá trị (value) cho người dùng của mình. Và vì vậy, vâng, tôi nghĩ tác nhân phụ, tôi là một người hâm mộ lớn của Agent SDK và tác nhân phụ.

Các Chiến lược Xác minh

Vâng, chúng ta có hành động thứ ba này và đường dẫn xác minh. Vâng, chúng ta cần đặt xác minh chính xác ở đâu trong ví dụ này? Giả sử, sau khi tạo truy vấn X-12, tôi có thể xác minh xem đó có phải là truy vấn đúng được tạo hay không. Đó là một đường dẫn. Đường dẫn thứ hai là một quá trình tạo ra truy vấn và thực thi trực tiếp, và một khi tôi nhận được đầu ra, tôi sẽ thực hiện xác minh. Và làm thế nào để tác nhân có thể điều chỉnh động xem đường dẫn nào là đúng?

Vâng, câu hỏi là: "Bạn thực hiện xác minh ở đâu? Chỉ ở cuối cùng hay bạn thực hiện nó ở giữa?" Tôi sẽ nói: "Ở mọi nơi bạn có thể, bạn có thể liên tục xác minh." Như tôi đã nói, chúng ta thực hiện một số xác minh trong bước đọc (read step) của Claude Code. Vì vậy, đó là một ví dụ tuyệt vời. Bạn có thể làm điều đó ở cuối cùng, bạn chắc chắn nên làm điều đó ở cuối cùng. Nhưng tại bất kỳ điểm nào khác, nếu bạn có quy tắc (rules) hoặc thuật toán heuristic (heuristics), đặc biệt là nếu, ví dụ, bạn nói: "Này, quy tắc của tôi là tổng số cột bạn nên tìm kiếm phải dưới 10.000 hoặc dưới một nghìn." Đó là một cách hay để làm điều đó. Tương tự như vậy, có lẽ bạn nên đã phục vụ một hàng giá trị lớn, đưa ra phản hồi (feedback) cho mô hình (model), nói: "Này, chia nhỏ (chunk) cái này ra." Bạn đưa ra lỗi và đưa ra phản hồi, và điều tuyệt vời về mô hình là nó lắng nghe phản hồi, nó sẽ đọc các đầu ra lỗi (error outputs), và sau đó nó sẽ tiếp tục. Vì vậy, vâng, xác minh chắc chắn là, tôi biết tôi có nó trong cái này như một kiểu vòng lặp, nhưng nó chắc chắn giống như xác minh có thể xảy ra ở bất cứ đâu và nên xảy ra ở bất cứ đâu, hãy đặt nó vào nhiều nơi nhất có thể.

Điều khiển và Trí thông minh của Tác nhân

Được rồi, tôi cần bắt đầu thực hiện một số khởi tạo mẫu (prototyping), nhưng tôi sẽ trả lời thêm một câu hỏi. Ngay tại đây. Làm thế nào chúng ta sắp xếp các bước? Làm thế nào chúng ta nói với tác nhân điều đó?

Bạn chỉ cần nói với nó, vâng, lời nhắc hệ thống (system prompt). Vâng, ví dụ, với Claude Code, chúng ta chỉ cung cấp cho nó công cụ bash và chúng ta nói: "Này, thu thập ngữ cảnh, đọc tệp của bạn, thực hiện công việc, chạy linters của bạn." Ý tôi là như vậy. Và vì vậy, một lần nữa, với tác nhân, bạn không cần phải ép buộc điều này, bạn không cần phải nói với nó rằng bạn cần làm điều này bởi vì đôi khi nó có thể không cần thiết. Ví dụ, nếu ai đó đang hỏi một câu hỏi chỉ đọc (read-only question) cho bảng tính của bạn, bạn không cần phải xác minh rằng bạn không có bất kỳ lỗi biên dịch nào, bởi vì bạn chưa thực hiện bất kỳ thao tác ghi (write operations) nào. Vì vậy, hãy để tác nhân thông minh và theo cách tương tự mà bạn sẽ có cùng sự tự do đó khi bạn làm công việc của mình. Bạn bị mắc kẹt trong hộp này hay bất cứ thứ gì, cũng theo cách đó.

Xây dựng Tác nhân Đơn giản và Thanh lịch

Được rồi, tôi muốn thử và xem liệu tôi có thể thực hiện một số khởi tạo mẫu (prototyping) ngay bây giờ khi chúng ta có người giữ vai trò này. Được rồi, vâng, chúng ta đã thực hiện rất nhiều Q&A trong quá trình thực thi. Được rồi, khởi tạo mẫu. Giả sử bạn có một tác nhân, bạn muốn xây dựng một tác nhân. Bạn ra khỏi bài nói chuyện này và bạn nói: "Tuyệt vời, tôi có rất nhiều ý tưởng. Làm thế nào để tôi làm điều này?"

Tôi nghĩ điều tôi nói chung là việc xây dựng một tác nhân nên đơn giản, hoặc tác nhân cuối cùng nên đơn giản, nhưng đơn giản không giống với dễ dàng. Vì vậy, việc bắt đầu nên rất đơn giản, và nó là như vậy, chỉ cần đến Claude Code, cung cấp cho Claude Code một số script và thư viện, và các hằng số trong Claude.env, yêu cầu chúng làm điều đó. Đó là điều chúng ta sẽ làm. Đó là việc nó nên dễ dàng như: "Này, đây là API của tôi. Đây là khóa API (API key). Bạn có thể tìm kiếm, bạn biết đấy, tôi không biết, các phiếu hỗ trợ khách hàng của tôi hoặc gì đó và sắp xếp chúng theo mức độ ưu tiên hoặc đại loại thế không?" Và sau đó hãy xem Claude Code làm gì và lặp lại (iterate) nó. Và đây là một cách tuyệt vời để bỏ qua các vấn đề đặc thù tên miền (domain-specific problems) khó khăn mà bạn có.

Vì vậy, bạn có rất nhiều vấn đề tên miền như làm thế nào để bạn tổ chức dữ liệu của mình, tìm kiếm tác nhân (agentic search) của bạn, làm thế nào để bạn có hàng rào bảo vệ (guardrails) trên cơ sở dữ liệu của bạn. Đây đều là những câu hỏi mà bạn có thể bắt đầu giải quyết ngay lập tức với Claude Code. Và vì vậy, hãy cố gắng xây dựng một cái gì đó có cảm giác khá tốt với Claude Code. Và tôi nghĩ nói chung, điều tôi đã thấy là bạn có thể làm điều này và nhận được kết quả thực sự tốt ngay lập tức bằng cách sử dụng Claude Code cục bộ. Và bạn nên có niềm tin cao vào cuối quá trình. Và vì vậy, vâng, tôi nghĩ và chúng ta sẽ chỉ xem bài nói chuyện A Engineer của tôi để biết thêm thông tin. Đây là một bộ tài liệu chúng tôi đang sử dụng nội bộ.

Được rồi, vâng, tôi sẽ chèn cái này vào để bạn, vâng, bạn đang nhận được những gì chúng tôi trình bày cho khách hàng. Vì vậy, được rồi, vâng, hãy sử dụng Claude Code một lần nữa, đơn giản. Nhưng đơn giản không dễ dàng. Vì vậy, lượng mã trong tác nhân của bạn không nên quá lớn. Không cần phải khổng lồ, không cần phải cực kỳ phức tạp. Nhưng nó cần phải thanh lịch. Nó cần phải giống như những gì mô hình mong muốn, bạn muốn có cái nhìn sâu sắc thú vị này. Hãy biến mô hình thành một truy vấn SQL. Ồ, hãy biến bảng tính này thành một truy vấn SQL và sau đó tiếp tục từ đó. Vì vậy, hãy suy nghĩ theo cách đó, và Claude Code là một cách tuyệt vời để làm điều đó.

Ví dụ: Tác nhân Pokemon

Được rồi, hãy tạo một tác nhân Pokemon. Đây là điều chúng ta sẽ làm. Pokemon là một trò chơi có rất nhiều thông tin.

Giới thiệu về PokeAPI và mục tiêu Tác nhân

Có hàng nghìn Pokémon, mỗi loài lại có vô số chiêu thức. Chúng tôi muốn tiếp cận một cách khá tổng quát, và thực sự có một API dành cho Pokémon, gọi là PokeAPI. Lý do tôi chọn Pokémon đơn giản là vì tôi biết rằng bạn cũng có các API riêng của mình, phải không? Và tất cả chúng đều rất độc đáo. Vì vậy, tôi muốn chọn một thứ có API phức tạp mà tôi chưa từng thử trước đây.

PokeAPI cho phép bạn tìm kiếm Pokémon như Ditto, tìm kiếm vật phẩm và những thứ tương tự. Nó có một API tùy chỉnh bao gồm tất cả mọi thứ trong trò chơi. Một trong những câu hỏi mà tác nhân của bạn hoặc người dùng của bạn có thể muốn hỏi là "tạo một đội Pokémon". Tôi rất yêu Pokémon nhưng lại biết rất ít về việc tạo một đội Pokémon thú vị để thi đấu cạnh tranh. Nếu tác nhân của tôi có thể giúp đỡ việc đó thì thật tuyệt vời. Vì vậy, mục tiêu của tôi là tạo ra một tác nhân có thể trò chuyện về Pokémon, và sau đó mọi người có thể xem chúng ta có thể làm được gì, và chúng ta sẽ đi được bao xa.

Khởi tạo Sinh mã và khám phá API

Tôi đã thực hiện một số công việc này rồi và tôi sẽ mở lên để cho bạn xem. Bước đầu tiên, và lời nhắc ở đây là, bước đầu tiên tôi sẽ chủ yếu sử dụng sinh mã (code generation) cho việc này.

Nó có trên GitHub repo không? Thực sự có, trên GitHub cá nhân của tôi. Tôi cũng sẽ commit tất cả những thứ này. GitHub cá nhân của tôi là... Chà, nếu GitHub của bạn không hiển thị nội dung, thì đó là lỗi của bạn, các bạn là kỹ sư AI mà.

Tôi đã lấy lời nhắc mà tôi đưa cho nó là "Hey, hãy tìm kiếm PokeAPI để lấy API của nó và tạo một thư viện TypeScript." Và tất cả điều này đều được sinh mã. Bạn có thể thấy ở đây rằng nó đã tạo ra một interface cho Pokémon. Nó đã tạo ra một API Pokémon để tôi có thể lấy Pokémon theo tên, liệt kê Pokémon, lấy tất cả Pokémon, lấy loài và khả năng, v.v. Đây chỉ là một lời nhắc tôi đưa cho nó, và nó đã sinh mã API TypeScript này, cũng làm tương tự cho các chiêu thức.

Và sau đó nó đã tạo ra một API mà bạn có thể import PokeAPI từ PokeAPI SDK. Bạn có thể thấy cách nó đã thiết lập điều này. Ngược lại với claud.mb này, đây là SDK TypeScript cho PokeAPI. Đây là các module trong PokeAPI, và đây là một số tính năng chính. Tôi yêu cầu nó viết các script trong thư mục ví dụ, và sau đó nó sẽ thực thi các script đó để giúp tôi với các truy vấn của mình. Và tôi đưa cho nó một số script ví dụ. Nó không phải lúc nào cũng cần tất cả thông tin này, nhưng việc tìm nạp Pokémon và liệt kê lý do nó lấy dữ liệu, v.v.

Tác nhân của tôi thực sự là một lời nhắc mà tôi đưa cho nó để sinh mã một thư viện TypeScript, và sau đó là claud.mb. Tôi có thể trò chuyện với nó trong Claw Code. Tôi cũng sẽ cho bạn xem một phiên bản chỉ dùng tools. Ở đây, tôi đang sử dụng API messages completion, và tôi đã cung cấp cho nó một loạt tools từ API: get Pokemon, get Pokemon species, get Pokemon ability, get Pokemon type, get move.

Minh họa Tool Calling và Sinh mã

Bạn định nghĩa tất cả các tools này và bạn có thể thấy rằng tôi cũng chỉ đưa cho nó một lời nhắc và bảo nó tạo các tools. Nó không muốn tạo hàng trăm tools, vì có rất nhiều dữ liệu từ PokeAPI. Nhưng nó chỉ có thể xử lý một số lượng tham số nhất định, vì vậy nó có tool call này. Tôi đã tạo một giao diện trò chuyện nhỏ với nó.

Hãy để tôi đi tới đây và nói, đây là tool calling của tôi. Được rồi, ở đây chúng ta có chat.ts. Tôi sử dụng Bun khi tôi prototype (tạo mẫu) mọi thứ, chỉ vì tôi không muốn compile (biên dịch) từ TypeScript sang JavaScript. Và Bun cũng có tính năng linting (kiểm tra cú pháp) được tích hợp sẵn. Đó là một cách để đơn giản hóa cho tác nhân để nó không cần phải nhớ biên dịch TypeScript tốt hơn cho việc sinh mã vì đó là các type (kiểu dữ liệu).

Vì vậy, tôi sẽ khởi động bun chat này, và sau đó tôi sẽ thử "Pokémon hệ nước thế hệ 2 là gì?" Bạn sẽ thấy rằng nó bắt đầu tìm kiếm, và tôi đang ghi nhật ký tất cả các tool call ở đây. Điều này rất, rất quan trọng, bởi vì nó cần thực hiện các tool call đó. Bạn có thể thấy những gì nó đang làm là tìm kiếm một loạt Pokémon. Và sau đó nó cho tôi biết, "Đây là các Pokémon hệ nước cho thế hệ 2:" Totodile, Croconaw, Feraligatr. Bạn có thể thấy cách nó dừng lại và suy nghĩ qua các bước trước đó sau mỗi bước.

Giờ đây, giả sử tôi muốn làm việc với Claw Code, tôi nghĩ tôi cần phải xóa ví dụ này. Câu hỏi nhỏ, làm thế nào để bạn ghi nhật ký các tool call? Chỉ có một đối số thôi. Vâng, đây là trong API thông thường. Vì vậy, tôi chỉ cần, mỗi khi nó ghi nhật ký, tôi gọi đây là trong API Anthropic thông thường. Trong SDK, tôi sẽ quay lại SDK, bạn chỉ cần ghi nhật ký mọi thông báo hệ thống. Điều đó có ý nghĩa không? Đây là một screenshot bạn đang hiển thị. Vâng, đó là sử dụng API thông thường, không phải Agent SDK.

Và những gì tôi sẽ làm ở đây là, tôi sẽ xóa script này. Tôi không muốn nó gian lận. Nhưng được rồi, ở đây bạn biết rằng tôi chỉ mở Claw Code. Tôi đã tạo một loạt file ở đây. Tôi sẽ nói, "Bạn có thể cho tôi biết tất cả Pokémon hệ nước thế hệ 2 không?" Và sau đó chúng ta sẽ xem nó có thể làm gì. Tôi quên mất liệu tôi có cần lời nhắc nó để đọc script hay không, tôi nghĩ là sẽ ổn thôi. Chúng ta sẽ xem điều gì xảy ra.

Bạn có thể đi đến file SDK cốt lõi và chỉ cho chúng tôi cách lấy context, sau đó action, và sau đó verification, và bạn có thể cho chúng tôi xem điều đó trong code và cách chúng tôi cấu hình tool description không? Vâng, chúng tôi chưa thực hiện phần SDK đó. Vì vậy, cho đến nay, tôi chỉ đặt một số API vào Claw Code.

Phân tích kết quả Claw Code và các trường hợp sử dụng nâng cao

Vâng, được rồi, bạn có thể thấy ở đây. Nó đã cung cấp cho tôi nhiều hơn. Nó nói có 21 Pokémon, và tôi nghĩ điều này khá chính xác. Nó đã làm gì vậy? Tôi nghĩ nó chỉ... không, được rồi. Dù sao thì, phân phối Pokémon có hơi khác một chút, điều đó tôi đoán là tốt. Nhưng vâng, những gì nó sẽ làm là nó sẽ cố gắng viết một script, bởi vì sau đó bạn không muốn nó suy nghĩ nhiều. Vì vậy, ở đây nó giống như, được rồi, những gì tôi sẽ làm là... hãy xem. Thế hệ 2. Được rồi, bạn có thể thấy ở đây nó biết, được rồi, bắt đầu của các thế hệ, nó tìm nạp những thứ này cho API. Tôi đoán nó đã quyết định không sử dụng API được xây dựng sẵn của tôi ở đây. Và sau đó nó chạy nó. Tôi nghĩ tôi cần cải thiện claud.mb cho cái này. Nhưng dù sao, bạn có thể thấy rằng nó có thể kiểm tra hơn 200 Pokémon và sau đó kiểm tra loại của chúng và lấy thông tin của chúng.

Vì vậy, đây là một ví dụ nhanh về cách thực hiện code generation và cách sử dụng Claw Code để làm điều đó. Chúng ta sẽ chạy script này và sau đó tiếp tục. Vâng, về cơ bản những gì tôi muốn hiển thị, chúng ta có khoảng 15 phút. Có chơi Pokémon không? Thực ra, đây là một trong những bản demo tôi đang nghĩ đến việc thực hiện. Claw Code chơi Pokémon. Giả sử bạn muốn tạo một phiên bản agentic của Claw Code chơi Pokémon, bạn sẽ làm thế nào? Điều bạn sẽ làm, tôi nghĩ là, bạn sẽ cấp cho nó quyền truy cập vào bộ nhớ trong của ROM. Và giả sử nó muốn tìm kiếm đội của mình, nó có thể tìm kiếm điều đó trong bộ nhớ. Pokémon Red là một trò chơi đã được reverse-engineered (kỹ thuật đảo ngược) rất tốt, và vì vậy nó có thể tìm kiếm trong bộ nhớ để biết "này, đây là những Pokémon, đây là cách tôi tìm ra bản đồ ở đâu, đây là cách tôi điều hướng nó." Vì vậy, đây có thể là... thực ra, tôi vẫn có trình đọc nếu bạn muốn thử nó, nó giống như một trình giả lập GBA Node.js. Tôi nghĩ tôi phải nói một cách hợp pháp rằng bạn phải mua Pokémon Red và thử nó. Nhưng vâng, tôi nghĩ là một ví dụ tốt.

Dù sao, ở đây, nó đã liệt kê tất cả chúng và liệt kê tất cả các loại của chúng. Và vâng, bạn có thể thấy cách nó đã sử dụng code generation để làm điều này. Vì vậy, một ví dụ nhanh về việc sử dụng Claw Code để prototype cái này.

Giờ đây, có thể có nhiều dữ liệu thú vị hơn ở đây. Tôi muốn dành thời gian cho các ví dụ. Vì vậy, tôi nghĩ tôi sẽ chỉ xem xét một ví dụ. Giả sử bạn đang tạo một đội Pokémon cạnh tranh. Pokémon cạnh tranh có rất nhiều biến và dữ liệu khác nhau. Đây là một text file từ một thư viện trực tuyến, về cơ bản lưu trữ tất cả Pokémon và các chiêu thức của chúng, những Pokémon nào kết hợp tốt với nhau và không tốt, và bạn biết đấy, những Pokémon nào bị khắc chế, và tất cả những điều này. Vì vậy, có rất nhiều dữ liệu ở đây và tất cả đều nằm trong text file, điều này thực sự khá tốt cho Claw Code, bởi vì tôi có thể nói rằng "Này, tôi sẽ lấy thêm một chút dữ liệu, thông thường sẽ đặt cái này vào thư mục dữ liệu. Hãy cho tôi biết tôi muốn tạo một đội xoay quanh Venusaur. Bạn có thể cho tôi một vài gợi ý dựa trên dữ liệu Smogon không?"

Và Smogon giống như một nguồn dữ liệu trực tuyến. Vì vậy, tôi không hoàn toàn chắc chắn chúng ta đang làm gì ở đây. Tôi chưa từng thực hiện truy vấn này trước đây, nhưng chúng ta sẽ xem sao, tôi nghĩ nó sẽ... Vâng, nhưng điều tôi muốn nó làm là grep (tìm kiếm) thông qua dữ liệu này và tự tìm ra, từ các nguyên tắc cơ bản, không cần xem dữ liệu này trước, làm thế nào tôi có thể trả lời truy vấn của mình?

Triển khai Tác nhân và Agent SDK

Trong khi nó làm điều đó, tôi sẽ nhận bất kỳ câu hỏi nào. Đây thực sự là trên Claw Code. Vì vậy, câu hỏi của tôi là làm thế nào để triển khai cái này cho khách hàng? Vâng, chúng ta nên chạy Claw Code trong một swarm (đàn/tập hợp các máy chủ) hay bằng cách nào đó?

Vậy, hãy để tôi chỉ cho bạn rất nhanh cách sử dụng Agent SDK ở đây. Tôi đã thực hiện file system này rồi. Và một lần nữa, tôi muốn bạn nghĩ về file system như một cách để thực hiện kỹ thuật ngữ cảnh (context engineering). Giống như đây là rất nhiều đầu vào cho tác nhân. Vì vậy, file tác nhân thực tế của tôi chỉ khoảng 60 dòng. Và nó chủ yếu chỉ là ngẫu nhiên cho trang. Vâng, tôi đoán nó đã quyết định ngăn nó viết script bên ngoài cây script tùy chỉnh đó một lần nữa. Vì vậy, hãy bỏ qua điều đó.

Vâng, bạn có thể thấy rằng nó chỉ chạy truy vấn này, lấy working directory (thư mục làm việc), và chạy nó trong một loop (vòng lặp). Và có lẽ tôi phải làm cho nó trở thành một số tools được phép ở đây, v.v. Nhưng nó rất đơn giản. Và vì vậy, nếu tôi productionize (đưa vào sản xuất) cái này, bước đầu tiên tôi làm là, được rồi, tôi đã thử nghiệm nó trên Claw Code. Nó dường như hoạt động khá tốt. Tôi viết file này, sau đó tôi đặt nó vào... có hai cách để làm điều đó.

[transcript bị gián đoạn]

Xu hướng Ứng dụng Cục bộ và Môi trường Sandbox cho Tác nhân

Một trong những điều tôi nghĩ là các ứng dụng cục bộ (local apps) có thể sẽ trở lại mạnh mẽ với AI, bởi vì tôi nghĩ có quá nhiều chi phí vận hành chúng. Ví dụ, Claude Code là một ứng dụng giao diện người dùng (frontend app), đúng không? Nó chạy trên máy tính của bạn. Vì vậy, có lẽ cách tôi phân phối một ứng dụng Pokemon là kiểu như, "Này, tôi có một ứng dụng bạn cài đặt và nó chạy cục bộ trên máy tính của bạn, và nó đang viết các script." Tôi nghĩ đó là một cách để thực hiện, đúng không?

Cách khác là bạn lưu trữ nó trong một sandbox. Và một lần nữa, có rất nhiều nhà cung cấp sandbox khác nhau giúp việc này thực sự dễ dàng, ví dụ như Howkler có một ví dụ hay, về việc sử dụng agent SDK và nó chỉ đơn giản là sandbox.start, bạn biết đấy, rồi kiểu như "Chạy Agent.ts." Và đó là tất cả những gì cần làm, đúng không? Nó giống như họ đã trừu tượng hóa rất nhiều thứ. Vì vậy, bạn chạy sandbox và sau đó bạn giao tiếp với nó.

Xây dựng Giao diện Người dùng động và Ví dụ về Tác nhân Pokemon

Vâng, tôi nghĩ có một số thứ rất thú vị mà tôi không chắc mình có thời gian để trình bày, nhưng... Như tôi nghĩ, một số câu hỏi thú vị là, làm thế nào để bạn triển khai loại dịch vụ mà chúng ta đang tạo ra, nơi chúng ta chỉ đơn thuần khởi tạo một sandbox cho mỗi người dùng? Có rất nhiều, tôi phải nói là, các thực tiễn tốt nhất cần giải quyết ở đây. Một điều tôi muốn các bạn lưu ý là nếu bạn đang tạo một tác nhân với giao diện người dùng (UI), ví dụ như bạn có tác nhân Pokemon của tôi và tôi muốn có một UI có thể thích ứng với người dùng, đúng không? Chẳng hạn, một số người dùng đang xây dựng đội hình, một số người dùng đang giúp nó với trò chơi của họ, một số người dùng chỉ muốn ảnh Pokemon. Làm thế nào để tôi có một tác nhân thích ứng theo thời gian thực với người dùng của tôi, đúng không?

Cách tôi làm là trong sandbox của mình, tôi sẽ có một dev server, đúng không? Và dev server đó sẽ phơi bày một cổng. Nó sẽ chạy trên "fun" hoặc "node" hoặc một cái gì đó. Nó sẽ phơi bày một cổng, tác nhân có thể chỉnh sửa mã và nó sẽ live refresh, và người dùng của bạn sẽ tương tác với trang web của chúng tôi. Đây là cách nhiều nhà xây dựng trang web như Lovable hoạt động, đúng không? Họ sử dụng các sandbox và về cơ bản, họ lưu trữ một dev server. Vì vậy, nếu bạn muốn một giao diện tùy chỉnh cho người dùng của mình, đây là một cách tuyệt vời để làm điều đó.

Tôi có thể, hãy xem, hãy xem nó đã làm gì. Được rồi, hay đấy. Vậy thì, nó đã viết script này để tạo ra, kiểu như "Cho tôi xem một số chỉ số cơ bản" và nó đã đề xuất một move set và một số đồng đội. Và bạn có thể thấy, kiểu như, xem nó đã làm gì. Kiểm soát... Vâng, được rồi, bạn có thể thấy ở đây điều nó bắt đầu làm là tìm kiếm Venusaur, đúng không? Và nó bắt đầu tìm những loại đó, những Pokemon đó. Và khi nó làm vậy, nó cũng lấy được các Pokemon khác có đề cập đến Venusaur, vì vậy nó lấy được đồng đội và kẻ khắc chế của nó, v.v., đúng không? Và trong suốt thời gian này, nó đã tìm thấy những Pokemon thú vị mà nó có thể hoạt động cùng, đúng không? Vì vậy, nó đã thực hiện một loạt các tìm kiếm này và nó có những hồ sơ này. Nó đã tìm thấy những đồng đội phổ biến nhất của nó và nó đã chạy một script để phân tích chúng, đúng không? Và tất cả điều này đều dựa trên một tệp văn bản. Tất nhiên, tôi có thể đã tiền xử lý tệp văn bản nhiều hơn một chút. Nhưng vâng, nó đã thực hiện một loại phân tích thú vị cho tôi. Và một lần nữa, tôi sẽ đẩy công việc lên GitHub repo và cũng sẽ đăng về điều này. Tôi ở trên Twitter, tôi là @tierQ212. Tôi đăng bài rất nhiều, chủ yếu là về các vấn đề agent SDK. Nhưng vâng, tôi còn khoảng tám phút nữa. Tôi muốn dành thời gian còn lại để trả lời các câu hỏi về bất cứ điều gì, bạn biết đấy. Và tôi xin lỗi, chúng ta không có thời gian để thực hiện nhiều prototyping hơn.

Chi phí, Kiếm tiền và Thiết kế Tác nhân

Vâng, tôi nghĩ nhìn chung, đặc biệt là hiện tại, các tác nhân khá đắt, bạn biết không? Ý tôi là, bởi vì các mô hình mới bắt đầu trở nên có tính chất tác nhân. Chúng tôi thực sự tập trung vào việc có những mô hình thông minh nhất, bạn biết đấy. Và như bạn biết, đây chỉ là một chiến lược kinh doanh SaaS tổng thể: bạn thà tính phí ít người hơn với số tiền lớn hơn cho những người thực sự có vấn đề khó giải quyết. Và vì vậy tôi nghĩ điều này vẫn tốt, bạn có lẽ nên tìm những use cases khó này. Nhưng tôi muốn nói rằng, thứ nhất, hãy đảm bảo bạn đang giải quyết một vấn đề mà mọi người muốn trả tiền. Đúng không? Đó là bước số một, đúng không? Và sau đó, thứ hai, vâng, tôi nghĩ bạn có thể thực hiện theo mô hình subscription (đăng ký) hoặc token-based (dựa trên mã thông báo). Tôi nghĩ điều này phụ thuộc vào việc bạn mong đợi mọi người sử dụng sản phẩm của mình nhiều đến mức nào so với việc bạn mong đợi họ sử dụng nó thỉnh thoảng. Như Claude Code rõ ràng là mọi người sử dụng rất nhiều, và để... chúng tôi kết hợp nhiều yếu tố như nếu bạn sử dụng vượt quá rate limit (giới hạn tỷ lệ), chúng tôi sẽ tính phí cao hơn. Tôi nghĩ rằng, vâng, nó phụ thuộc rất nhiều vào cơ sở người dùng của riêng bạn và những gì họ sẽ làm. Nhưng tôi phải nói rằng monetization (kiếm tiền) là thứ bạn nên nghĩ đến ngay từ đầu và thiết kế tác nhân của mình xung quanh nó, bởi vì rất khó để rút lại những lời hứa này.

Vâng, ở đằng kia. Vâng, tôi đã nói rất nhiều về, ừm, hooks rất tuyệt. Chúng tôi có tích hợp hooks. Hooks là một cách để thực hiện xác minh deterministic verification cụ thể hoặc chèn context. Bạn biết đấy, chúng tôi kích hoạt các hooks này như các sự kiện và bạn có thể đăng ký chúng trong agent SDK. Có một hướng dẫn về cách làm điều đó. Các ví dụ về những thứ bạn có thể sử dụng hooks cho là, ví dụ, vâng, bạn có thể chạy nó để xác minh một bảng tính mỗi lần. Bạn cũng có thể xem xét như khi Sam đang làm việc với một tác nhân và tác nhân đó đang thực hiện một số thao tác fetching operations và người dùng cũng đã thay đổi bảng tính này. Đây là một nơi thú vị và tuyệt vời để sử dụng hook bởi vì bạn có thể nói, "Này, sau mỗi tool call, hãy chèn các thay đổi mà người dùng đã thực hiện." Và như vậy, bạn đang thực hiện các thay đổi live context changes một cách thú vị. Vâng, tôi nghĩ, vâng, có thêm tài liệu về hooks trên các tài liệu. Tôi rất vui được nói chuyện về nó sau đó. Vâng, có câu hỏi nào nữa không?

Lời khuyên về Prototyping và Xử lý Determinism cho Tác nhân

Vâng, vâng, vâng, chắc chắn rồi. Vâng, giả sử bạn đã hoàn thành việc prototyping này, bạn đã tìm thấy một thứ hoạt động. Điều tôi sẽ làm là, như tôi đã ở đâu đó trong CLAUDE.md. Thực sự, rõ ràng là khi tôi thử làm điều này một lần, nó giống như việc gọi trực tiếp API của tôi và nó đã viết JavaScript. Tôi lẽ ra nên cụ thể hơn trong CLAUDE.md của mình, kiểu như, "Này, bạn nên sử dụng cái này." Vâng, tôi nghĩ đó là một điều. Điều thứ hai là, vâng, chỉ cần ở đâu đó trong CLAUDE.md có các helper scripts mà bạn cần, và sau đó như, viết một cái gì đó như agent.js này. Vâng, thêm câu hỏi hay nữa. Vâng, đây là một câu hỏi hay, và bạn biết đấy, tôi nghĩ có một số sự lộn xộn, đúng không? Như tôi nghĩ một trong những điều, nếu một tác nhân biết câu trả lời, và bạn muốn như, kiểu như đấu tranh với nó để kiểu như "Được rồi, không, thế hệ chín bây giờ," và như chúng ta biết các chỉ số thay đổi. Nếu có cái mới này, như ở đây, như, ừm... Cái này khó. Tôi thực sự nghĩ một trong những cách để làm điều đó là hooks. Vì vậy, bạn có thể nói, ví dụ như, "Này, đừng... nếu bạn đã trả về một phản hồi mà không viết script, bạn biết đấy, bạn có thể kiểm tra điều đó. Bạn có thể phản hồi kiểu như, 'Hãy đảm bảo bạn viết script. Hãy đảm bảo bạn đọc dữ liệu này.'" Đúng không? Và bạn có thể sử dụng hooks để đưa ra phản hồi đó theo cách tương tự như trong Claude Code, chúng tôi có những rules này như, "Hãy đảm bảo bạn đọc một tệp trước khi bạn ghi vào nó," đúng không? Vì vậy, hãy thêm một số determinism. Nó chắc chắn có thể là, như tôi đã nói, đó là một nghệ thuật, bạn biết đấy, đôi khi, vâng, có lẽ như việc viết một khóa học như chúng tôi, có lẽ.

Semantic Search trong Codebase lớn và Claude Code

Vâng, và các công ty lớn, nó giống như làm việc với hơn 50 triệu dòng mã. Và vì vậy, vâng, tool không thực sự hoạt động. Không, tôi rất vui khi xây dựng những thứ kiểu như semantic indexing của riêng mình để giúp ích cho điều đó, đúng không? Chắc chắn rồi. Kiểu như, những điều về cách điều đó có thể trở nên native hơn đối với sản phẩm, bạn biết đấy, trong vài tháng tới, tôi sẽ sẵn sàng từ bỏ nó, hay kiểu như các bạn đang nghĩ gì về điều đó? Được rồi, câu hỏi cuối cùng của bạn. Trong vài tháng tới, bạn nghĩ nó sẽ biến mất? Tôi chỉ nói chung là có về AI. Tôi nghĩ rằng semantic search... đây là một câu hỏi về Claude Code nhiều hơn là một câu hỏi liên quan đến tác nhân, nhưng tôi rất vui khi trả lời nó. Như, ừm, chúng ta, bạn biết đấy, chúng được đào tạo dựa trên. Vì vậy, semantic search dễ bị lỗi hơn (brittle). Tôi nghĩ bạn phải index và tìm kiếm, và không nhất thiết mô hình không được đào tạo về semantic search. Và vì vậy tôi nghĩ đó là một loại vấn đề, như, bạn biết đấy, Grab được đào tạo dựa trên vì nó dễ làm điều đó, nhưng như semantic search, bạn đang triển khai bespoke query của mình cho các codebases rất lớn, bạn biết đấy. Chúng tôi có rất nhiều khách hàng làm việc trong các codebases lớn. Tôi nghĩ điều tôi đã thấy là họ chỉ thực hiện checkout tốt ở những nơi bạn bắt đầu, bạn biết đấy, cố gắng đảm bảo bạn bắt đầu từ thư mục bạn muốn. Có các verifications tốt để thêm vào hooks và linters và những thứ tương tự. Và vì vậy, bạn biết đấy, đó là những gì chúng tôi làm. Chúng tôi không có, bạn biết đấy, tôi tùy chỉnh, chúng tôi dog food Claude Code, đúng không? Vâng. Được rồi, vâng, câu hỏi cuối cùng. Rất tiếc, chúng ta phải kết thúc. Vì vậy, tôi sẽ nhận nó để đọc cho mọi người.