- Đưa các tác nhân (
agent) LLM vào môi trường sản phẩm (production) đối mặt với các thách thức về chi phí, độ trễ và độ tin cậy, đặc biệt với các tác nhân chạy dài tích lũy ngữ cảnh. - Kỹ thuật quan trọng nhất là
Prompt Caching, giúp giảm 90% chi phíinput tokens, tăng tốc độ phản hồi và cải thiện quản lýrate limitbằng cách lưu đệm các phần lời nhắc phổ biến. Context Engineeringlà kỷ luật tối ưu hóa ngữ cảnh của mô hình thông qua ba kỹ thuật:Tool Search Tool(hoãn tải công cụ),Programmatic Tool Calling(trích xuất có chọn lọc kết quả công cụ) vàCompaction(tóm tắt các lượt hội thoại cũ) để giảm token và tăng cường trí thông minh của mô hình.
Getting more out of the Claude Platform
- Triển khai Prompt Caching bắt buộc: Đây là kỹ thuật hàng đầu để giảm đáng kể chi phí, độ trễ và quản lý
rate limitcho các tác nhân chạy dài bằng cách lưu đệm các phầnpromptchung. - Theo dõi và Tối ưu hóa Tỷ lệ Cache Hit: Sử dụng
Claude console analyticsvàprompt cache dashboardđể kiểm tra tỷ lệcache hitcủa tác nhân trongproductionvà đặt mục tiêu đạt trên 90%. - Sử dụng Claude Code để Hỗ trợ Cache: Tận dụng
skillchuyên gia vềprompt cachingtrongClaude Codebằng cách ra lệnh "improve my cache hit rate" để nhận hướng dẫn về việc thêmcache control markersvà sắp xếp lạiprompt. - Thực hành Kỹ thuật Ngữ cảnh (Context Engineering): Chủ động kiểm soát và quyết định những gì đưa vào
contextcủa mô hình, tránh các lớp trừu tượng che khuất, để tối ưu hóa hiệu suất và chi phí. - Áp dụng Tool Search Tool: Đối với các tác nhân có nhiều công cụ, hoãn tải các khai báo công cụ vào
promptcho đến khi mô hình thực sự cần chúng, giúp tiết kiệm token và tăng cường sự thông minh của mô hình. - Triển khai Programmatic Tool Calling: Thay vì đưa toàn bộ kết quả công cụ vào
context, hãy để mô hình viết mãPythonđể chọn lọc và chỉ trích xuất những phần dữ liệu cần thiết từ kết quả công cụ. - Sử dụng Compaction cho Tác nhân Dài hạn: Áp dụng
compactionđể tóm tắt các lượt hội thoại không còn cần thiết, nén chúng thành một bản tóm tắt ngắn gọn, giúp quản lýcontext windowvà duy trì mạch câu chuyện cho mô hình.
Agent— tác nhânProduction— môi trường sản phẩm / sản xuấtPrompt Caching— bộ nhớ đệm lời nhắcLatency— độ trễCost— chi phíContext Window— cửa sổ ngữ cảnhTool Call— gọi công cụRate Limit— giới hạn tỷ lệContext Engineering— kỹ thuật ngữ cảnhCompaction— nén/thu gọn (ngữ cảnh)
Chào mừng và Giới thiệu Agent trong Production
Chào mừng trưởng nhóm quản lý sản phẩm nền tảng Claude của Anthropic, Brad Abrams. Cảm ơn. Chào buổi chiều, các bạn đã gần đi đến cuối sự kiện Code with Claude. Cảm ơn vì đã ở lại với chúng tôi. Nhưng tôi phải nói rằng đây là buổi quan trọng nhất trong ngày. Vì vậy, các bạn đã có một lựa chọn đúng đắn khi ở đây. Cảm ơn. Đây là một buổi quan trọng vì chúng ta sẽ nói về việc đưa các agent vào production. Vì vậy, các bạn sẽ có một trường hợp thực tế về các agent trong production. Để bắt đầu, có bao nhiêu người trong số các bạn đã có một agent đang chạy trong production? Không phải một bản demo hay proof of concept mà thực sự đang hoạt động trong production. Được rồi, hãy giữ tay lên. Giữ tay lên nếu bạn hài lòng với cost (chi phí), reliability (độ tin cậy), latency (độ trễ). Bạn có thể hạ tay xuống, nhưng nếu bạn đang ngồi cạnh một trong những người này, bạn nên nói chuyện với họ sau để nhận được những mẹo thực tế. Trong buổi này, chúng ta sẽ thảo luận một vài điều sẽ giúp bạn quản lý những thứ như cost, latency và reliability thông qua một vài kỹ thuật. Vì vậy, hãy cùng đi sâu vào đây.
Kỹ thuật quan trọng nhất: Prompt Caching
Hóa ra kỹ thuật quan trọng nhất cần suy nghĩ là prompt caching. Tôi đã tham dự một vài buổi và rất nhiều người đang nhắc đến nó. Nhưng nếu bạn chưa thực hiện prompt caching, thì bạn tuyệt đối nên làm. Và tôi sẽ nói cho bạn biết, tôi có thể xem dữ liệu phân tích và tôi biết một số bạn chưa thực hiện prompt caching. Vì vậy, điều này hoàn toàn xứng đáng được nhắc đến. Với các agent chạy dài (long running agents), prompt caching rất quan trọng vì context tiếp tục tăng lên sau mỗi lượt tool call. Bạn có tool call, tool resolve, rồi lại tool call và tool resolve. Và tất cả những điều đó được thêm vào prompt. Vì vậy, có rất nhiều yếu tố chung trong prompt đó mà nếu bạn không thực hiện prompt caching, chúng tôi sẽ xử lý lại chúng mỗi lần.
Lợi ích và Cơ chế của Prompt Caching
Với prompt caching, nếu bạn đánh dấu các phần chung trong prompt của mình, chúng tôi có thể tính toán các giá trị KV về cơ bản là lưu đệm trước (pre-cache) các model, tức là một phần đầu vào cho các model dưới dạng KV và lưu chúng lại. Điều đó giúp tiết kiệm rất nhiều latency khi xảy ra và rất nhiều thời gian xử lý. Chúng tôi bỏ qua toàn bộ phần đầu tiên của quá trình inference khi bạn làm điều đó. Và đó là một khoản tiết kiệm chi phí lớn. Trên thực tế, đó là một mức giảm giá 90%. Vì vậy, nếu bạn đang chạy một agent dài và không thực hiện prompt caching, bạn đang bỏ lỡ mức giảm giá 90% cho input tokens, vốn là phần lớn chi phí đối với hầu hết khách hàng. Bạn cũng nhận được thời gian phản hồi nhanh hơn, đặc biệt là time to first token (thời gian đến token đầu tiên). Và một sự thật ít người biết là các prompt cache tokens cũng không bị tính vào giới hạn rate limit của API của bạn. Vì vậy, nếu bạn có một rate limit và bạn muốn quản lý rate limit đó tốt nhất có thể, các cache tokens sẽ không bị tính vào đó. Chúng tôi đã gần như tăng giới hạn rate limit lên 10 lần hôm nay, nhưng nếu bạn vẫn muốn quản lý chúng, bạn có thể làm điều đó với kỹ thuật này.
Thành công thực tế và Công cụ hỗ trợ Prompt Caching
Một số khách hàng của chúng tôi đã làm rất tốt với prompt caching. Tôi muốn nêu bật một vài cái tên như Cursor, Replete, Perplexity, tất cả đều đạt hiệu suất trên 90%. Và họ đã nỗ lực kỹ thuật đáng kể. Tôi đã ngồi với một số nhóm kỹ thuật này và tôi có thể nói rằng họ đã bỏ rất nhiều công sức để đưa prompt caching lên mức trên 90%. Nhưng tôi sẽ cho bạn một gợi ý. Chúng tôi có một vài tool hiện có sẵn để bạn sử dụng, giúp việc này dễ dàng hơn nhiều. Đầu tiên là trên màn hình đây, bạn có thể kiểm tra chuyên sâu những gì đang xảy ra với prompt caching trong ứng dụng của mình. Vì vậy, tôi khuyến khích bạn cứ tự nhiên nếu muốn mở laptop của mình, vào Claude console và kiểm tra prompt cache dashboard mới trong phần analytics. Và bạn thực sự có thể xem agent đang chạy trong production của mình đang làm gì về prompt caching. Và nếu nó không đạt mức trên 90%, bạn có một số việc phải làm. Đó là điều đầu tiên. Điều thứ hai là chúng tôi gần đây đã ra mắt một skill cho Claude Code là một chuyên gia về prompt caching. Và nó được cài đặt mặc định với Claude Code. Vì vậy, tất cả những gì bạn cần làm là vào Claude Code và nói "improve my cache hit rate" (cải thiện tỷ lệ cache hit của tôi). Và Claude sẽ hướng dẫn bạn qua quá trình thêm các cache control markers vào đó, có thể sắp xếp lại một số prompt. Chỉ cần hướng dẫn bạn qua quá trình đó để bạn có thể đạt được tỷ lệ cache hit rất cao. Vì vậy, đó là một điều tuyệt đối nên làm. Tôi nghĩ bạn nên thử xem xét.
Trình diễn Prompt Caching
Vì vậy, hãy cùng xem một bản demo về cách prompt caching hoạt động. Tôi sẽ mời Bin lên sân khấu, Bin, hãy ra đây. Và chúng ta sẽ xem bản demo này. Bin và tôi đã làm việc trên bản demo này. Đó là một executive dashboard (bảng điều khiển dành cho giám đốc điều hành). Giả sử bạn là CEO của một công ty và bạn có tất cả các mục tiêu này và chúng ta đang chạy nó. Khoan đã, Bin, đây có phải là bản demo chúng ta đã thống nhất không? Chúng ta đang ở Code with Claude. Cái này trông giống giao diện SharePoint cuối thập niên 90. Tôi không biết nữa. Bạn có Claude Code không? Được rồi, mở Claude Code lên. Hãy xem chúng ta có thể làm gì. Được rồi, Bin có Claude Code. Và nó được đính kèm. Anh ấy có mã nguồn cho cái này. Và chúng ta sẽ xem liệu chúng ta có thể cải thiện giao diện này không. Vậy có bao nhiêu người muốn có một giao diện tốt hơn? Được rồi, đây rồi. Được rồi, một giao diện tốt hơn có lẽ phù hợp hơn một chút với địa điểm chúng ta đang ở. Chúng ta bây giờ không phải là một CEO nhàm chán của những năm 90 nữa. Chúng ta là CEO của Hero Corp AI. Và những gì Hero Corp làm là tuyển dụng siêu anh hùng để chiến đấu với kẻ ác và bảo vệ đô thị, đến dự tiệc sinh nhật của con bạn, bất cứ điều gì họ làm. Và sau đó chúng ta đang xem các mục tiêu. Đây là mục tiêu một. Tôi được biết rằng việc giữ chân các siêu anh hùng là một điều rất quan trọng. Và vì vậy mục tiêu một là xoay quanh việc giữ chân họ. Và Bin, tôi không biết nữa. Có lẽ chúng ta không trả lương đủ cho các siêu anh hùng. Có vẻ như tỷ lệ này hơi thấp ở đây. Và bạn có thể thấy một số cập nhật từ mỗi siêu anh hùng. Và sau đó là CEO, một số nhiệm vụ mà chúng ta có thể thực hiện. Vậy, Bin, bạn có biết tỷ lệ cache hit trên cái này là bao nhiêu không? Không, không, được rồi, được rồi. Bạn không biết tỷ lệ cache hit. Được rồi, được rồi. Vậy trước tiên, bạn phải biết tỷ lệ cache hit là bao nhiêu. Vì vậy, những gì chúng tôi đã làm là triển khai một dev console cho bản demo nhỏ này, hoặc kéo bảng điều khiển dành cho nhà phát triển ra. Và hãy cùng xem. Trong bảng điều khiển dành cho nhà phát triển nhỏ này, những gì bạn thấy ở đây là context usage, tool calls của chúng ta. Và sau đó có bản ghi agentic transcript này đang diễn ra. Bạn có ước rằng tất cả các ứng dụng của bạn đều đi kèm với bảng điều khiển dành cho nhà phát triển tuyệt đẹp này không. Nhưng tôi nhận thấy trong bảng điều khiển này, một điều đập vào mắt tôi ngay lập tức là tỷ lệ cache hit gần như bằng 0. Ý tôi là, tôi không biết nữa. Vậy, Bin, chúng ta có thể làm gì để cải thiện tỷ lệ cache hit không? Vì vậy, anh ấy sẽ mở Claude Code, quay lại đó và chỉ cần cải thiện tỷ lệ cache hit. Và bây giờ chúng ta sẽ chạy lại. Và hãy chú ý khi chúng ta chạy lại, chúng ta đang gọi lại tất cả các tool call đó. Nhưng lần này trong agentic transcript, bạn đang thấy cache writes và cache hits. Vì vậy, lần đầu tiên hệ thống inference nhìn thấy một phân đoạn prompt, nó sẽ ghi nó vào bộ đệm. Chúng tôi lưu trữ các giá trị KV đó trong năm phút theo mặc định. Bạn có thể kéo dài thời gian đó với một số tùy chọn. Và sau đó, lần tiếp theo khi một vòng lặp đến, đó trở thành một cache hit. Vì vậy, trong một vòng lặp agentic loop thông thường, bạn sẽ thấy một số cache hits và một số cache reads. Vì vậy, chúng ta đang làm tốt hơn một chút ở đây. Và tôi nghĩ bạn sẽ thấy tỷ lệ cache hit sẽ tốt hơn trong suốt quá trình demo. Được rồi, đó là prompt caching.
Kỹ thuật Context Engineering
Nhưng nếu bạn cuộn xuống một chút, hãy xem xét một số mục tiêu khác này. Ben, nhìn này, Ben, tôi đã cung cấp cho bạn một triệu token context, một triệu token trong Opus 4.7 triệu token. Và rõ ràng là không đủ. Với tất cả các tool call mà chúng ta đang thực hiện để lấy thông tin từ Slack, từ bản ghi Gong, từ Salesforce, tất cả các sự thật, tại sao bạn không có một bản sao của một trong số đó và chỉ cho thấy có một lượng lớn dữ liệu đang tràn ngập vào context. Vì vậy, ngay cả với một triệu token context, chúng ta đã hết trước khi chúng ta hoàn thành mục tiêu thứ nhất. Vì vậy, chúng ta nên suy nghĩ về cách chúng ta muốn xử lý vấn đề này. Như bạn có thể đoán, tôi có một vài kỹ thuật để xử lý vấn đề này. Hãy quay lại các slide và để tôi mô tả một số kỹ thuật cho context engineering. Được rồi, context engineering thực sự là một kỷ luật. Đó là kỷ luật quyết định những gì thuộc về context của Claude. Một lỗi tôi thấy các nhà phát triển thường mắc phải là sử dụng các lớp trừu tượng trên nền tảng làm che khuất những gì có trong context. Và sau đó, với tư cách là một nhà phát triển, bạn không thực sự biết Claude đang nhìn thấy gì trong context của nó. Và điều đó làm cho bạn khó tối ưu hóa, khó trở thành một kỹ sư context. Vì vậy, tôi khuyến khích bạn thực sự chú ý nhiều đến việc xem xét toàn bộ bản ghi mà Claude có quyền truy cập, mà Claude đang sử dụng vì nó sẽ rất sâu sắc. Và kỷ luật là bạn đưa ra một quyết định chủ động để quyết định những gì nên có trong đó. Và tôi sẽ nói ở đây về ba tool khác nhau mà chúng ta có sẵn hôm nay trong production để bạn sử dụng nhằm giúp quản lý context. Đầu tiên là về việc giảm các khai báo tool có trong nền tảng, có trong context của bạn. Thứ hai là về việc giảm các kết quả tool làm "ô nhiễm" context. Và cuối cùng, compaction giảm tất cả các lượt không còn cần thiết. Vì vậy, hãy cùng đi sâu vào từng cái này và xem chúng trông như thế nào.
Giảm khai báo Tool với Tool Search Tool
Vì vậy, với Tool Search Tool, chúng tôi có nhiều khách hàng có hàng chục, thậm chí hàng trăm tool được tải. Nếu bạn có một agent chạy dài, đa mục đích (long running multi-use agent), nó thường cần nhiều tool để hoàn thành công việc của mình. Đó là một trong những điểm hay của LLM là chúng có mục đích chung và có thể làm nhiều việc khác nhau. Vì vậy, chúng tôi muốn khuyến khích bạn có nhiều tool. Nhưng nếu bạn nhìn vào trường hợp "không có Tool Search Tool", nếu bạn tải tất cả các tool đó lên trước trong system prompt, thì điều đó để lại rất ít không gian để thực hiện công việc thực tế của bạn. Vì vậy, nếu chúng ta nhìn vào trường hợp "với Tool Search Tool", những gì chúng ta đang làm là hoãn tải (defer loading) tất cả các tool đó. Bạn vẫn khai báo chúng trước, nhưng chúng ta chưa đưa chúng vào prompt. Chúng ta hoãn tải chúng. Và sau đó chúng ta tải chúng đúng lúc, ngay khi model cần chúng. Vì vậy, nếu model, trong một lộ trình agentic trajectory cụ thể, không bao giờ cần tool đó, thì nó sẽ không bao giờ được tải. Và điều đó thực sự tối ưu hóa context khá tốt. Và chúng tôi thấy các khách hàng như Lovable đã giảm việc sử dụng token của họ 10%. Và điều đó không chỉ giúp bạn tiết kiệm tiền và giảm latency, mà những gì Lovable đã thấy, và tôi nghĩ nhiều người cũng sẽ thấy, nó thực sự tăng cường sự thông minh của model để cẩn thận hơn về những gì đi vào context. Đó là Tool Search Tool.
Giảm kết quả Tool với Programmatic Tool Calling
Kỹ thuật tiếp theo cần xem xét là programmatic tool calling (gọi tool theo lập trình). Đầu tiên, bạn có thích những animation này không? Bạn có thể biết rằng tôi có token miễn phí từ Claude để tạo những animation này không? Vậy programmatic tool calling làm gì? Nó giải quyết vấn đề các tool trả về quá nhiều dữ liệu. Và nhiều tool mà chúng tôi vừa trình bày cho bạn trả về lượng lớn văn bản mà chỉ đơn giản là được nhồi nhét vào prompt. Và bạn biết đấy, điều đó hoạt động tốt nếu bạn đang xây dựng một bản demo nhỏ. Nhưng ở buổi này, chúng ta đang nói về việc đưa vào production, không phải xây dựng demo. Vì vậy, để đưa vào production, bạn cần suy nghĩ kỹ hơn một chút về điều này. Và bạn có thể thử điều chỉnh các tool để chúng trả về ít dữ liệu hơn. Nhưng thường thì điều xảy ra khi đó là bạn bỏ lỡ một trường hợp. Có một trường hợp mà model cần dữ liệu đó. Và sau đó bạn đã xóa nó. Và bây giờ model không có nó. Vì vậy, suy nghĩ đột phá mà chúng tôi có ở đây là model thực sự khá giỏi trong việc viết mã Python. Tôi không biết bạn có nhận thấy điều đó không, nhưng các model thực sự rất giỏi trong việc viết Python. Vì vậy, những gì chúng tôi làm là chúng tôi cung cấp cho model một tập hợp các tool có sẵn ngay bây giờ trong context. Và nó viết mã Python. Bạn sẽ nhận thấy lần đầu tiên nó viết mã để kiểm tra schema của những gì được trả về. Và sau đó lần thứ hai như bạn đang thấy ở đây, nó biết schema. Vì vậy, thực sự, tool trả về tất cả dữ liệu của nó. Dữ liệu này nằm trong bộ nhớ (in memory).
Kỹ thuật Compaction và Tiết kiệm Chi phí
Sau đó, mô hình viết mã để chỉ trích xuất những phần nhỏ. Ví dụ, chỉ một byte ở đây, vài từ ở kia, và nó chỉ sử dụng những phần đó trong context của mình. Như vậy, mô hình tự quyết định những gì nó cần trong context của chính nó. Với kỹ thuật này, Kora đang tiết kiệm rất nhiều chi phí và nhận thấy sự gia tăng về độ thông minh cho Python cũng như trong việc phân tích cú pháp HTML mà họ đang thực hiện. Cuối cùng, tôi gọi kỹ thuật này là "cái búa tạ" (sledgehammer technique) vì ngay cả khi bạn làm rất tốt việc quản lý khai báo tool và kết quả tool, nếu bạn có một agent chạy đủ lâu, bạn vẫn sẽ chạm đến giới hạn context window.
Vì vậy, compaction có chức năng loại bỏ tất cả các lượt không sử dụng, tất cả các lượt của cuộc hội thoại không cần thiết nữa. Nó chỉ nén chúng thành một bản tóm tắt ngắn gọn. Và bản tóm tắt đó rất quan trọng. Trên thực tế, có rất nhiều trí tuệ được đầu tư vào việc tạo ra bản tóm tắt đó để mô hình có thể tiếp tục. Vì vậy, khi bạn mất đi mạch câu chuyện, nó vẫn biết những gì cần tiếp tục làm với compaction. Và chúng tôi thấy Hex hiện đang sử dụng kỹ thuật này trong sản xuất.
Demo: Kết hợp các Kỹ thuật Tối ưu Context
Được rồi, tôi biết bạn đang rất muốn xem, hãy quay lại demo và xem agent của công ty siêu anh hùng Hero Corp của chúng ta. Và hãy xem. Chúng ta nên thêm tool search tool. Này, bạn biết không, hãy thêm tất cả chúng. Vì vậy, chúng ta sẽ thêm tool search tool, programmatic tool calling và compaction trong một lần. Bây giờ, khi chúng ta tải lại trang, hãy chú ý theo dõi thanh context khi nó tăng lên. Đầu tiên, hãy để ý rằng nó di chuyển chậm hơn nhiều so với trước đây. Hãy nhớ trước đó, nó đã tải mục tiêu đầu tiên và chúng ta đã đạt tới một triệu token. Chúng ta đang gọi chính xác các tool trả về chính xác cùng dữ liệu, nhưng chúng ta đang làm một cách thông minh. Chúng ta đang sử dụng context engineering để hiểu những gì cần đưa vào. Vì vậy, với ít context hơn nhiều, chúng ta có thể tải toàn bộ trang. Và tôi biết một số bạn chuyên tính toán đã nhận thấy rằng chi phí đã giảm đáng kể khi chúng ta thực hiện điều đó.
Hoạt động của Tool Search Tool
Nhưng hãy xem xét từng cái một để đảm bảo chúng ta hiểu chính xác từng cái làm gì. Vì vậy, hãy bắt đầu với tool search tool ở đây. Đây là những gì tool search tool trả về. Một lần nữa, mô hình đã xem xét vấn đề chúng ta đưa ra và nói, "Ồ, tôi sẽ cần một tool làm việc này, ví dụ như tính toán hero retention metrics." Và sau đó hệ thống của chúng tôi đã xem xét tất cả hàng trăm tool có sẵn và chọn ra, tôi không biết, ba hoặc bốn cái và trả về chúng. Vì vậy, thay vì có 100 tool trong context, chúng ta chỉ có ba hoặc bốn. Và vì vậy, một thứ như hero retention metrics được gọi. Và sau đó tôi đoán sau này, chúng ta sẽ thấy nó. Chúng ta thấy nó chứ? Chúng ta thấy cái nào? Bạn có thấy không? Ồ, phải rồi, nó đây rồi. Xin lỗi, tôi đã bỏ lỡ. Hero retention metrics nằm ngay đó. Vì vậy, chúng ta đã thêm tool này một cách linh hoạt kịp thời. Và ngay sau khi chúng ta thêm nó, mô hình đã quay lại và gọi tool đó, và chúng ta đã nhận được toàn bộ dữ liệu từ nó.
Hoạt động của Programmatic Tool Calling
Được rồi, đó là tool search tool. Cái tiếp theo chúng ta đã nói đến là programmatic tool calling. Trong phần này, chúng ta đánh dấu nó là code execution trong giao diện này và chỉ xem xét đoạn mã mà mô hình viết. Và đây không phải là một điều đặc biệt nào đó mà tôi có. Chúng tôi cung cấp cho bạn chính xác đoạn mã mà mô hình viết để bạn có thể hiểu điều gì đang thực sự xảy ra. Bạn thấy nó đang gọi các phương thức đó. Nếu bạn nhìn vào results = async_gather, nó đang gọi từng tool đó. Các tool tương tự chúng ta đã thấy trước đây, nó đang gọi chúng với các tham số tương tự. Nhưng lần này, chúng ta không tải tất cả những thứ đó vào context. Mô hình đang tải chúng vào một đối tượng JSON và in ra rất rõ ràng. Bạn thấy context pipeline, gong, chính xác nguồn gốc của nó. Và sau đó bạn thấy dấu hai chấm, 2500, như thế. Mô hình biết chính xác đối tượng nào mà nó cần. Vì vậy, nó không cần tất cả những thứ rác rưởi chúng ta đã tải trong lượt đầu tiên. Nó chỉ cần một phần nhỏ này. Vì vậy, nó đang trích xuất phần đó. Nó đang in ra. Và sau đó đó là những gì được tải vào context của mô hình.
Hoạt động của Compaction trong Demo
Được rồi, đó là tool search tool. Và cuối cùng, cái cuối cùng chúng ta nói đến là compaction. Thực ra, đối với compaction, tại sao chúng ta không xem nó được gọi. Phải, phải, nó được gọi vài lần ở đây. Vì lý do demo, chúng tôi đã đặt compaction threshold khá nhỏ, như khoảng 500k token chẳng hạn. Và đó là một kỹ thuật phổ biến mà bạn không cần phải đi đến giới hạn. Tôi thích việc có context một triệu token, nhưng bạn có thể không cần tất cả số đó. Nó có thể giúp bạn tiết kiệm chi phí và độ trễ. Và nó có thể mang lại trí thông minh hơn nếu giữ mô hình ở ngưỡng thấp hơn. Đó là những gì chúng tôi đã làm ở đây. Chúng tôi giữ nó ở ngưỡng thấp hơn. Và khi context tăng lên đến ngưỡng đó, chúng tôi tạm dừng thực thi mô hình, gửi toàn bộ transcript đến một lời gọi mô hình khác, mô hình đó đã tóm tắt và đưa ra bản tóm tắt này. Vì vậy, hãy mở rộng bản tóm tắt. Bạn có thể thấy đây là bản tóm tắt của tất cả những gì đã diễn ra. Vì vậy, nó đã lấy hàng trăm lời gọi tool với tất cả kết quả của chúng và mọi thứ đang diễn ra, và chỉ nén nó xuống thành: "Đây là vài điều bạn cần biết để tiếp tục" để mô hình có thể tiếp tục.
Giới thiệu Chiến lược Advisor
Nhưng tôi nhận thấy vẫn tốn 10 đô la để chạy thứ này. Ý tôi là, tôi phải nói với bạn, kinh doanh token là một ngành tuyệt vời. Sau đó là bán siêu anh hùng, đó cũng là một ngành kinh doanh rất tốt, nhưng vẫn 10 đô la mỗi lần tải. Ý tôi là, chúng ta sẽ gặp rắc rối vì điều này. Vì vậy, tôi nhận thấy rằng bạn đang sử dụng Opus. Phải, nó nói điều này ở đâu? Vì vậy, mô hình đang được sử dụng là Opus một lần nữa, Opus 4, 7, một mô hình tuyệt vời. Nhưng nó đắt tiền. Và có thể tốt hơn nếu sử dụng một mô hình nhỏ hơn. Vì vậy, hóa ra một mô hình nhỏ như Sonnet có thể thực hiện tool calling tốt không kém, viết mã tốt không kém. Nhưng có một vài điều nó không làm tốt bằng. Và chúng ta sẽ nói về cách tận dụng điều đó. Vì vậy, hãy quay lại các slide. Và chúng ta sẽ nói về chiến lược Advisor.
Vấn đề chúng ta đang cố gắng giải quyết với Advisor là chúng ta muốn có trí thông minh cấp độ Opus, nhưng với chi phí cấp độ Haiku hoặc Sonnet. Nghe có vẻ tuyệt vời đúng không? Vì vậy, ý tưởng đằng sau đây thực sự đến từ các nhóm kỹ thuật. Bạn biết đấy, nếu bạn đã làm việc với các nhóm kỹ thuật, bạn sẽ so sánh một kỹ sư junior với một kỹ sư senior. Và kỹ sư junior đó sẽ trở nên tốt hơn rất nhiều. Bởi vì kỹ sư senior sẽ không làm tất cả công việc, họ sẽ không trực tiếp thực hiện công việc cho họ. Nhưng họ sẽ đánh giá mã, họ sẽ xem xét các tài liệu thiết kế, họ sẽ huấn luyện. Và điều đó cũng đúng với các mô hình. Điều chúng ta thấy là nếu chúng ta cho Haiku một cách, nó có thể gọi Opus và yêu cầu giúp đỡ. Sau đó, một Opus có thể quét transcript và xem điều gì đang xảy ra. Sau đó, nó có thể đưa ra một số lời khuyên cho Haiku, điều này thực sự hữu ích rất nhiều. Và vì vậy, bạn lại thấy một hình ảnh động đẹp khác ở đây. Bạn thấy rằng executor với Haiku biết mọi hình dạng. Nó biết chính xác phải làm gì với mỗi hình dạng, ngoại trừ hình dạng kỳ lạ này. Và đối với hình dạng kỳ lạ đó, nó phải đi hỏi advisor. Advisor biết, và sau đó advisor nói cho executor biết phải làm gì với hình dạng kỳ lạ đó. Và chúng tôi thấy các khách hàng như Bolt đang sử dụng điều này để giúp quản lý chi phí của họ.
Demo: Triển khai Chiến lược Advisor
Được rồi, hãy quay lại demo và chúng ta sẽ xem xét bước này. Vậy thì, tại sao chúng ta không thêm Advisor vào đây. Việc thêm Advisor sẽ chuyển mô hình từ Opus. Bây giờ bạn thấy dòng mô hình. Nó ghi: Sonnet 4.6 cộng với Opus làm advisor. Ngay lập tức, tôi lại thấy mắt các kế toán viên sáng lên vì giá đã giảm đáng kể. Ngay lập tức, bởi vì tất cả các lời gọi tool và mã Python, tất cả đều được thực hiện bằng Sonnet, rẻ hơn nhiều so với Opus. Vì vậy, bạn có được khoản tiết kiệm ngay lập tức.
Nhưng câu hỏi là, bạn có nhận được trí thông minh tương tự không? Có một mục tiêu thực sự quan trọng mà chúng ta có ở đây, đó là hợp đồng gia hạn Metropolis. Đây là một hợp đồng mà tôi rất lo lắng cho Hero Corp. Họ phải thắng hợp đồng gia hạn Metropolis. Và nếu chúng ta xem xét lời gọi advisor này, cách nó hoạt động là Sonnet đã xem xét tất cả các transcript của gong, tất cả dữ liệu về việc gia hạn Metropolis và Sonnet nói, "Tuyệt vời, cái này trông tốt. Đang đúng tiến độ." Nhưng sau đó, nó nói, "Ồ, có lẽ tôi sẽ gọi advisor và chỉ để chắc chắn vì đây là một giao dịch có tác động lớn." Và Opus đã xem xét cùng một transcript. Nó đã xem xét cùng một transcript đó và nó nói, "Ồ, Sonnet, bạn đã bỏ lỡ một điều được chôn vùi sâu trong transcript. Chúng ta thấy rằng Cryo Thing thực sự cần thiết mà thị trưởng thực sự muốn Cryo Thing." Và điều này rất chi tiết mà Sonnet đã bỏ lỡ. Vì vậy, Sonnet nói đang đúng tiến độ, nhưng Opus đã phát hiện ra.
Vì vậy, bây giờ bạn thấy lợi thế không chỉ là bạn đang sử dụng Sonnet vì nó không đắt. Ồ, đội ngũ tiếp thị bảo tôi không được nói là nó rẻ. Nó không rẻ, nó không đắt. Vì vậy, Sonnet không đắt. Và vì vậy, chúng ta có thể sử dụng nó, điều này rất tuyệt. Nhưng bạn vẫn nhận được trí thông minh của Opus, nhưng chỉ theo yêu cầu, chính xác những gì cần thiết. Và nó đã phát hiện ra vấn đề Cryo Thing này.
Hành động và Tầm nhìn của Agentic World
Được rồi, chúng ta đã phát hiện ra điều đó. Và bây giờ bạn có thể thấy nó hiển thị màu đỏ. Nó không ổn. Chúng ta cần làm gì đó. Và tôi không biết bạn thì sao, nhưng tôi có chút lo lắng về điều này. Tôi muốn đảm bảo rằng chúng ta có thể thắng hợp đồng Metropolis. Vì vậy, nếu bạn cuộn xuống một chút, có một việc mà CEO có thể làm. Đó là "khóa" Cryo Thing. Tôi cũng thích những cái tên siêu anh hùng này. Hóa ra đội pháp lý không cho phép tôi sử dụng bất kỳ tên siêu anh hùng thật nào. Vì vậy, chúng ta phải sử dụng Cryo Thing. Chúng ta có thể khóa điều này lại. Vậy chúng ta có nên cứu các hợp đồng không? Ai đồng ý cứu hợp đồng ở đây? Vâng. Được rồi, tuyệt vời! Cảm ơn bạn. Bạn đồng tình với tôi. Được rồi, hãy nhấp vào đó và khóa Cryo Thing. Chúng ta đã có nó. Được rồi, đây là trong thế giới agentic. Đây là tất cả những gì bạn làm với tư cách là một CEO. Chỉ cần nhấp vào nút và bạn đã hoàn thành. Mọi thứ đã được cứu.
Tổng kết và Các Tính năng Mới của Nền tảng
Được rồi, chúng ta chỉ còn một phút. Cảm ơn bạn, Ben. Hãy để tôi kết thúc. Vậy thì, quay lại các slide. Những gì chúng ta đã thấy ở đây là điều rất quan trọng là phải thực hiện prompt caching. Nếu bạn chưa làm điều đó, hãy bỏ qua phần còn lại của bài nói chuyện và đi làm điều đó. Nếu bạn đang làm điều đó, hãy thực sự chú ý đến context engineering. Đảm bảo bạn nhận thức được những gì có trong context và sau đó tối ưu hóa nó cho những gì thực sự cần thiết. Và cuối cùng, chúng ta đã nói về việc sử dụng chiến lược Advisor. Vì vậy, đó thực sự là trí thông minh theo yêu cầu.
Nhưng đó chưa phải là tất cả những điều tuyệt vời mà chúng tôi đã cung cấp trên nền tảng trong vài tháng qua. Vì vậy, tôi muốn nêu bật những điều yêu thích của mình. Đây là Workload Identity Federation. Vì vậy, nếu bạn lo lắng, nếu đội ngũ an ninh của bạn lo lắng về việc mất API key, bạn không cần phải lo lắng nữa. WIF là một câu trả lời tuyệt vời cho điều đó. Và sau đó tôi chỉ yêu thích công cụ dòng lệnh Ants CLI này. Mọi thứ bạn có thể làm trong bảng điều khiển đều có sẵn thông qua công cụ dòng lệnh. Và điều tuyệt vời nhất về công cụ dòng lệnh là Claude rất thích các công cụ dòng lệnh. Vì vậy, Claude. Nếu bạn sử dụng nó thông qua Claude Code, chỉ cần nói cho nó biết về công cụ Ants CLI và nó sẽ quản lý mọi thứ cho bạn và làm một công việc tuyệt vời. Và điều thực sự cần lưu ý ở đây là đặt cược vào nền tảng có nghĩa là nền tảng sẽ tiếp tục tốt hơn và agent của bạn sẽ tiếp tục tốt hơn khi những điều mới tiếp tục ra mắt trên nền tảng. Đó là tất cả. Cảm ơn rất nhiều. Tôi rất trân trọng.
TL;DR
- Đưa các tác nhân (
agent) LLM vào môi trường sản phẩm (production) đối mặt với các thách thức về chi phí, độ trễ và độ tin cậy, đặc biệt với các tác nhân chạy dài tích lũy ngữ cảnh. - Kỹ thuật quan trọng nhất là
Prompt Caching, giúp giảm 90% chi phíinput tokens, tăng tốc độ phản hồi và cải thiện quản lýrate limitbằng cách lưu đệm các phần lời nhắc phổ biến. Context Engineeringlà kỷ luật tối ưu hóa ngữ cảnh của mô hình thông qua ba kỹ thuật:Tool Search Tool(hoãn tải công cụ),Programmatic Tool Calling(trích xuất có chọn lọc kết quả công cụ) vàCompaction(tóm tắt các lượt hội thoại cũ) để giảm token và tăng cường trí thông minh của mô hình.
Điểm chính
- Triển khai Prompt Caching bắt buộc: Đây là kỹ thuật hàng đầu để giảm đáng kể chi phí, độ trễ và quản lý
rate limitcho các tác nhân chạy dài bằng cách lưu đệm các phầnpromptchung. - Theo dõi và Tối ưu hóa Tỷ lệ Cache Hit: Sử dụng
Claude console analyticsvàprompt cache dashboardđể kiểm tra tỷ lệcache hitcủa tác nhân trongproductionvà đặt mục tiêu đạt trên 90%. - Sử dụng Claude Code để Hỗ trợ Cache: Tận dụng
skillchuyên gia vềprompt cachingtrongClaude Codebằng cách ra lệnh "improve my cache hit rate" để nhận hướng dẫn về việc thêmcache control markersvà sắp xếp lạiprompt. - Thực hành Kỹ thuật Ngữ cảnh (Context Engineering): Chủ động kiểm soát và quyết định những gì đưa vào
contextcủa mô hình, tránh các lớp trừu tượng che khuất, để tối ưu hóa hiệu suất và chi phí. - Áp dụng Tool Search Tool: Đối với các tác nhân có nhiều công cụ, hoãn tải các khai báo công cụ vào
promptcho đến khi mô hình thực sự cần chúng, giúp tiết kiệm token và tăng cường sự thông minh của mô hình. - Triển khai Programmatic Tool Calling: Thay vì đưa toàn bộ kết quả công cụ vào
context, hãy để mô hình viết mãPythonđể chọn lọc và chỉ trích xuất những phần dữ liệu cần thiết từ kết quả công cụ. - Sử dụng Compaction cho Tác nhân Dài hạn: Áp dụng
compactionđể tóm tắt các lượt hội thoại không còn cần thiết, nén chúng thành một bản tóm tắt ngắn gọn, giúp quản lýcontext windowvà duy trì mạch câu chuyện cho mô hình.
Từ vựng
Agent— tác nhânProduction— môi trường sản phẩm / sản xuấtPrompt Caching— bộ nhớ đệm lời nhắcLatency— độ trễCost— chi phíContext Window— cửa sổ ngữ cảnhTool Call— gọi công cụRate Limit— giới hạn tỷ lệContext Engineering— kỹ thuật ngữ cảnhCompaction— nén/thu gọn (ngữ cảnh)
Nội dung chi tiết
Chào mừng và Giới thiệu Agent trong Production
Chào mừng trưởng nhóm quản lý sản phẩm nền tảng Claude của Anthropic, Brad Abrams. Cảm ơn. Chào buổi chiều, các bạn đã gần đi đến cuối sự kiện Code with Claude. Cảm ơn vì đã ở lại với chúng tôi. Nhưng tôi phải nói rằng đây là buổi quan trọng nhất trong ngày. Vì vậy, các bạn đã có một lựa chọn đúng đắn khi ở đây. Cảm ơn. Đây là một buổi quan trọng vì chúng ta sẽ nói về việc đưa các agent vào production. Vì vậy, các bạn sẽ có một trường hợp thực tế về các agent trong production. Để bắt đầu, có bao nhiêu người trong số các bạn đã có một agent đang chạy trong production? Không phải một bản demo hay proof of concept mà thực sự đang hoạt động trong production. Được rồi, hãy giữ tay lên. Giữ tay lên nếu bạn hài lòng với cost (chi phí), reliability (độ tin cậy), latency (độ trễ). Bạn có thể hạ tay xuống, nhưng nếu bạn đang ngồi cạnh một trong những người này, bạn nên nói chuyện với họ sau để nhận được những mẹo thực tế. Trong buổi này, chúng ta sẽ thảo luận một vài điều sẽ giúp bạn quản lý những thứ như cost, latency và reliability thông qua một vài kỹ thuật. Vì vậy, hãy cùng đi sâu vào đây.
Kỹ thuật quan trọng nhất: Prompt Caching
Hóa ra kỹ thuật quan trọng nhất cần suy nghĩ là prompt caching. Tôi đã tham dự một vài buổi và rất nhiều người đang nhắc đến nó. Nhưng nếu bạn chưa thực hiện prompt caching, thì bạn tuyệt đối nên làm. Và tôi sẽ nói cho bạn biết, tôi có thể xem dữ liệu phân tích và tôi biết một số bạn chưa thực hiện prompt caching. Vì vậy, điều này hoàn toàn xứng đáng được nhắc đến. Với các agent chạy dài (long running agents), prompt caching rất quan trọng vì context tiếp tục tăng lên sau mỗi lượt tool call. Bạn có tool call, tool resolve, rồi lại tool call và tool resolve. Và tất cả những điều đó được thêm vào prompt. Vì vậy, có rất nhiều yếu tố chung trong prompt đó mà nếu bạn không thực hiện prompt caching, chúng tôi sẽ xử lý lại chúng mỗi lần.
Lợi ích và Cơ chế của Prompt Caching
Với prompt caching, nếu bạn đánh dấu các phần chung trong prompt của mình, chúng tôi có thể tính toán các giá trị KV về cơ bản là lưu đệm trước (pre-cache) các model, tức là một phần đầu vào cho các model dưới dạng KV và lưu chúng lại. Điều đó giúp tiết kiệm rất nhiều latency khi xảy ra và rất nhiều thời gian xử lý. Chúng tôi bỏ qua toàn bộ phần đầu tiên của quá trình inference khi bạn làm điều đó. Và đó là một khoản tiết kiệm chi phí lớn. Trên thực tế, đó là một mức giảm giá 90%. Vì vậy, nếu bạn đang chạy một agent dài và không thực hiện prompt caching, bạn đang bỏ lỡ mức giảm giá 90% cho input tokens, vốn là phần lớn chi phí đối với hầu hết khách hàng. Bạn cũng nhận được thời gian phản hồi nhanh hơn, đặc biệt là time to first token (thời gian đến token đầu tiên). Và một sự thật ít người biết là các prompt cache tokens cũng không bị tính vào giới hạn rate limit của API của bạn. Vì vậy, nếu bạn có một rate limit và bạn muốn quản lý rate limit đó tốt nhất có thể, các cache tokens sẽ không bị tính vào đó. Chúng tôi đã gần như tăng giới hạn rate limit lên 10 lần hôm nay, nhưng nếu bạn vẫn muốn quản lý chúng, bạn có thể làm điều đó với kỹ thuật này.
Thành công thực tế và Công cụ hỗ trợ Prompt Caching
Một số khách hàng của chúng tôi đã làm rất tốt với prompt caching. Tôi muốn nêu bật một vài cái tên như Cursor, Replete, Perplexity, tất cả đều đạt hiệu suất trên 90%. Và họ đã nỗ lực kỹ thuật đáng kể. Tôi đã ngồi với một số nhóm kỹ thuật này và tôi có thể nói rằng họ đã bỏ rất nhiều công sức để đưa prompt caching lên mức trên 90%. Nhưng tôi sẽ cho bạn một gợi ý. Chúng tôi có một vài tool hiện có sẵn để bạn sử dụng, giúp việc này dễ dàng hơn nhiều. Đầu tiên là trên màn hình đây, bạn có thể kiểm tra chuyên sâu những gì đang xảy ra với prompt caching trong ứng dụng của mình. Vì vậy, tôi khuyến khích bạn cứ tự nhiên nếu muốn mở laptop của mình, vào Claude console và kiểm tra prompt cache dashboard mới trong phần analytics. Và bạn thực sự có thể xem agent đang chạy trong production của mình đang làm gì về prompt caching. Và nếu nó không đạt mức trên 90%, bạn có một số việc phải làm. Đó là điều đầu tiên. Điều thứ hai là chúng tôi gần đây đã ra mắt một skill cho Claude Code là một chuyên gia về prompt caching. Và nó được cài đặt mặc định với Claude Code. Vì vậy, tất cả những gì bạn cần làm là vào Claude Code và nói "improve my cache hit rate" (cải thiện tỷ lệ cache hit của tôi). Và Claude sẽ hướng dẫn bạn qua quá trình thêm các cache control markers vào đó, có thể sắp xếp lại một số prompt. Chỉ cần hướng dẫn bạn qua quá trình đó để bạn có thể đạt được tỷ lệ cache hit rất cao. Vì vậy, đó là một điều tuyệt đối nên làm. Tôi nghĩ bạn nên thử xem xét.
Trình diễn Prompt Caching
Vì vậy, hãy cùng xem một bản demo về cách prompt caching hoạt động. Tôi sẽ mời Bin lên sân khấu, Bin, hãy ra đây. Và chúng ta sẽ xem bản demo này. Bin và tôi đã làm việc trên bản demo này. Đó là một executive dashboard (bảng điều khiển dành cho giám đốc điều hành). Giả sử bạn là CEO của một công ty và bạn có tất cả các mục tiêu này và chúng ta đang chạy nó. Khoan đã, Bin, đây có phải là bản demo chúng ta đã thống nhất không? Chúng ta đang ở Code with Claude. Cái này trông giống giao diện SharePoint cuối thập niên 90. Tôi không biết nữa. Bạn có Claude Code không? Được rồi, mở Claude Code lên. Hãy xem chúng ta có thể làm gì. Được rồi, Bin có Claude Code. Và nó được đính kèm. Anh ấy có mã nguồn cho cái này. Và chúng ta sẽ xem liệu chúng ta có thể cải thiện giao diện này không. Vậy có bao nhiêu người muốn có một giao diện tốt hơn? Được rồi, đây rồi. Được rồi, một giao diện tốt hơn có lẽ phù hợp hơn một chút với địa điểm chúng ta đang ở. Chúng ta bây giờ không phải là một CEO nhàm chán của những năm 90 nữa. Chúng ta là CEO của Hero Corp AI. Và những gì Hero Corp làm là tuyển dụng siêu anh hùng để chiến đấu với kẻ ác và bảo vệ đô thị, đến dự tiệc sinh nhật của con bạn, bất cứ điều gì họ làm. Và sau đó chúng ta đang xem các mục tiêu. Đây là mục tiêu một. Tôi được biết rằng việc giữ chân các siêu anh hùng là một điều rất quan trọng. Và vì vậy mục tiêu một là xoay quanh việc giữ chân họ. Và Bin, tôi không biết nữa. Có lẽ chúng ta không trả lương đủ cho các siêu anh hùng. Có vẻ như tỷ lệ này hơi thấp ở đây. Và bạn có thể thấy một số cập nhật từ mỗi siêu anh hùng. Và sau đó là CEO, một số nhiệm vụ mà chúng ta có thể thực hiện. Vậy, Bin, bạn có biết tỷ lệ cache hit trên cái này là bao nhiêu không? Không, không, được rồi, được rồi. Bạn không biết tỷ lệ cache hit. Được rồi, được rồi. Vậy trước tiên, bạn phải biết tỷ lệ cache hit là bao nhiêu. Vì vậy, những gì chúng tôi đã làm là triển khai một dev console cho bản demo nhỏ này, hoặc kéo bảng điều khiển dành cho nhà phát triển ra. Và hãy cùng xem. Trong bảng điều khiển dành cho nhà phát triển nhỏ này, những gì bạn thấy ở đây là context usage, tool calls của chúng ta. Và sau đó có bản ghi agentic transcript này đang diễn ra. Bạn có ước rằng tất cả các ứng dụng của bạn đều đi kèm với bảng điều khiển dành cho nhà phát triển tuyệt đẹp này không. Nhưng tôi nhận thấy trong bảng điều khiển này, một điều đập vào mắt tôi ngay lập tức là tỷ lệ cache hit gần như bằng 0. Ý tôi là, tôi không biết nữa. Vậy, Bin, chúng ta có thể làm gì để cải thiện tỷ lệ cache hit không? Vì vậy, anh ấy sẽ mở Claude Code, quay lại đó và chỉ cần cải thiện tỷ lệ cache hit. Và bây giờ chúng ta sẽ chạy lại. Và hãy chú ý khi chúng ta chạy lại, chúng ta đang gọi lại tất cả các tool call đó. Nhưng lần này trong agentic transcript, bạn đang thấy cache writes và cache hits. Vì vậy, lần đầu tiên hệ thống inference nhìn thấy một phân đoạn prompt, nó sẽ ghi nó vào bộ đệm. Chúng tôi lưu trữ các giá trị KV đó trong năm phút theo mặc định. Bạn có thể kéo dài thời gian đó với một số tùy chọn. Và sau đó, lần tiếp theo khi một vòng lặp đến, đó trở thành một cache hit. Vì vậy, trong một vòng lặp agentic loop thông thường, bạn sẽ thấy một số cache hits và một số cache reads. Vì vậy, chúng ta đang làm tốt hơn một chút ở đây. Và tôi nghĩ bạn sẽ thấy tỷ lệ cache hit sẽ tốt hơn trong suốt quá trình demo. Được rồi, đó là prompt caching.
Kỹ thuật Context Engineering
Nhưng nếu bạn cuộn xuống một chút, hãy xem xét một số mục tiêu khác này. Ben, nhìn này, Ben, tôi đã cung cấp cho bạn một triệu token context, một triệu token trong Opus 4.7 triệu token. Và rõ ràng là không đủ. Với tất cả các tool call mà chúng ta đang thực hiện để lấy thông tin từ Slack, từ bản ghi Gong, từ Salesforce, tất cả các sự thật, tại sao bạn không có một bản sao của một trong số đó và chỉ cho thấy có một lượng lớn dữ liệu đang tràn ngập vào context. Vì vậy, ngay cả với một triệu token context, chúng ta đã hết trước khi chúng ta hoàn thành mục tiêu thứ nhất. Vì vậy, chúng ta nên suy nghĩ về cách chúng ta muốn xử lý vấn đề này. Như bạn có thể đoán, tôi có một vài kỹ thuật để xử lý vấn đề này. Hãy quay lại các slide và để tôi mô tả một số kỹ thuật cho context engineering. Được rồi, context engineering thực sự là một kỷ luật. Đó là kỷ luật quyết định những gì thuộc về context của Claude. Một lỗi tôi thấy các nhà phát triển thường mắc phải là sử dụng các lớp trừu tượng trên nền tảng làm che khuất những gì có trong context. Và sau đó, với tư cách là một nhà phát triển, bạn không thực sự biết Claude đang nhìn thấy gì trong context của nó. Và điều đó làm cho bạn khó tối ưu hóa, khó trở thành một kỹ sư context. Vì vậy, tôi khuyến khích bạn thực sự chú ý nhiều đến việc xem xét toàn bộ bản ghi mà Claude có quyền truy cập, mà Claude đang sử dụng vì nó sẽ rất sâu sắc. Và kỷ luật là bạn đưa ra một quyết định chủ động để quyết định những gì nên có trong đó. Và tôi sẽ nói ở đây về ba tool khác nhau mà chúng ta có sẵn hôm nay trong production để bạn sử dụng nhằm giúp quản lý context. Đầu tiên là về việc giảm các khai báo tool có trong nền tảng, có trong context của bạn. Thứ hai là về việc giảm các kết quả tool làm "ô nhiễm" context. Và cuối cùng, compaction giảm tất cả các lượt không còn cần thiết. Vì vậy, hãy cùng đi sâu vào từng cái này và xem chúng trông như thế nào.
Giảm khai báo Tool với Tool Search Tool
Vì vậy, với Tool Search Tool, chúng tôi có nhiều khách hàng có hàng chục, thậm chí hàng trăm tool được tải. Nếu bạn có một agent chạy dài, đa mục đích (long running multi-use agent), nó thường cần nhiều tool để hoàn thành công việc của mình. Đó là một trong những điểm hay của LLM là chúng có mục đích chung và có thể làm nhiều việc khác nhau. Vì vậy, chúng tôi muốn khuyến khích bạn có nhiều tool. Nhưng nếu bạn nhìn vào trường hợp "không có Tool Search Tool", nếu bạn tải tất cả các tool đó lên trước trong system prompt, thì điều đó để lại rất ít không gian để thực hiện công việc thực tế của bạn. Vì vậy, nếu chúng ta nhìn vào trường hợp "với Tool Search Tool", những gì chúng ta đang làm là hoãn tải (defer loading) tất cả các tool đó. Bạn vẫn khai báo chúng trước, nhưng chúng ta chưa đưa chúng vào prompt. Chúng ta hoãn tải chúng. Và sau đó chúng ta tải chúng đúng lúc, ngay khi model cần chúng. Vì vậy, nếu model, trong một lộ trình agentic trajectory cụ thể, không bao giờ cần tool đó, thì nó sẽ không bao giờ được tải. Và điều đó thực sự tối ưu hóa context khá tốt. Và chúng tôi thấy các khách hàng như Lovable đã giảm việc sử dụng token của họ 10%. Và điều đó không chỉ giúp bạn tiết kiệm tiền và giảm latency, mà những gì Lovable đã thấy, và tôi nghĩ nhiều người cũng sẽ thấy, nó thực sự tăng cường sự thông minh của model để cẩn thận hơn về những gì đi vào context. Đó là Tool Search Tool.
Giảm kết quả Tool với Programmatic Tool Calling
Kỹ thuật tiếp theo cần xem xét là programmatic tool calling (gọi tool theo lập trình). Đầu tiên, bạn có thích những animation này không? Bạn có thể biết rằng tôi có token miễn phí từ Claude để tạo những animation này không? Vậy programmatic tool calling làm gì? Nó giải quyết vấn đề các tool trả về quá nhiều dữ liệu. Và nhiều tool mà chúng tôi vừa trình bày cho bạn trả về lượng lớn văn bản mà chỉ đơn giản là được nhồi nhét vào prompt. Và bạn biết đấy, điều đó hoạt động tốt nếu bạn đang xây dựng một bản demo nhỏ. Nhưng ở buổi này, chúng ta đang nói về việc đưa vào production, không phải xây dựng demo. Vì vậy, để đưa vào production, bạn cần suy nghĩ kỹ hơn một chút về điều này. Và bạn có thể thử điều chỉnh các tool để chúng trả về ít dữ liệu hơn. Nhưng thường thì điều xảy ra khi đó là bạn bỏ lỡ một trường hợp. Có một trường hợp mà model cần dữ liệu đó. Và sau đó bạn đã xóa nó. Và bây giờ model không có nó. Vì vậy, suy nghĩ đột phá mà chúng tôi có ở đây là model thực sự khá giỏi trong việc viết mã Python. Tôi không biết bạn có nhận thấy điều đó không, nhưng các model thực sự rất giỏi trong việc viết Python. Vì vậy, những gì chúng tôi làm là chúng tôi cung cấp cho model một tập hợp các tool có sẵn ngay bây giờ trong context. Và nó viết mã Python. Bạn sẽ nhận thấy lần đầu tiên nó viết mã để kiểm tra schema của những gì được trả về. Và sau đó lần thứ hai như bạn đang thấy ở đây, nó biết schema. Vì vậy, thực sự, tool trả về tất cả dữ liệu của nó. Dữ liệu này nằm trong bộ nhớ (in memory).
Kỹ thuật Compaction và Tiết kiệm Chi phí
Sau đó, mô hình viết mã để chỉ trích xuất những phần nhỏ. Ví dụ, chỉ một byte ở đây, vài từ ở kia, và nó chỉ sử dụng những phần đó trong context của mình. Như vậy, mô hình tự quyết định những gì nó cần trong context của chính nó. Với kỹ thuật này, Kora đang tiết kiệm rất nhiều chi phí và nhận thấy sự gia tăng về độ thông minh cho Python cũng như trong việc phân tích cú pháp HTML mà họ đang thực hiện. Cuối cùng, tôi gọi kỹ thuật này là "cái búa tạ" (sledgehammer technique) vì ngay cả khi bạn làm rất tốt việc quản lý khai báo tool và kết quả tool, nếu bạn có một agent chạy đủ lâu, bạn vẫn sẽ chạm đến giới hạn context window.
Vì vậy, compaction có chức năng loại bỏ tất cả các lượt không sử dụng, tất cả các lượt của cuộc hội thoại không cần thiết nữa. Nó chỉ nén chúng thành một bản tóm tắt ngắn gọn. Và bản tóm tắt đó rất quan trọng. Trên thực tế, có rất nhiều trí tuệ được đầu tư vào việc tạo ra bản tóm tắt đó để mô hình có thể tiếp tục. Vì vậy, khi bạn mất đi mạch câu chuyện, nó vẫn biết những gì cần tiếp tục làm với compaction. Và chúng tôi thấy Hex hiện đang sử dụng kỹ thuật này trong sản xuất.
Demo: Kết hợp các Kỹ thuật Tối ưu Context
Được rồi, tôi biết bạn đang rất muốn xem, hãy quay lại demo và xem agent của công ty siêu anh hùng Hero Corp của chúng ta. Và hãy xem. Chúng ta nên thêm tool search tool. Này, bạn biết không, hãy thêm tất cả chúng. Vì vậy, chúng ta sẽ thêm tool search tool, programmatic tool calling và compaction trong một lần. Bây giờ, khi chúng ta tải lại trang, hãy chú ý theo dõi thanh context khi nó tăng lên. Đầu tiên, hãy để ý rằng nó di chuyển chậm hơn nhiều so với trước đây. Hãy nhớ trước đó, nó đã tải mục tiêu đầu tiên và chúng ta đã đạt tới một triệu token. Chúng ta đang gọi chính xác các tool trả về chính xác cùng dữ liệu, nhưng chúng ta đang làm một cách thông minh. Chúng ta đang sử dụng context engineering để hiểu những gì cần đưa vào. Vì vậy, với ít context hơn nhiều, chúng ta có thể tải toàn bộ trang. Và tôi biết một số bạn chuyên tính toán đã nhận thấy rằng chi phí đã giảm đáng kể khi chúng ta thực hiện điều đó.
Hoạt động của Tool Search Tool
Nhưng hãy xem xét từng cái một để đảm bảo chúng ta hiểu chính xác từng cái làm gì. Vì vậy, hãy bắt đầu với tool search tool ở đây. Đây là những gì tool search tool trả về. Một lần nữa, mô hình đã xem xét vấn đề chúng ta đưa ra và nói, "Ồ, tôi sẽ cần một tool làm việc này, ví dụ như tính toán hero retention metrics." Và sau đó hệ thống của chúng tôi đã xem xét tất cả hàng trăm tool có sẵn và chọn ra, tôi không biết, ba hoặc bốn cái và trả về chúng. Vì vậy, thay vì có 100 tool trong context, chúng ta chỉ có ba hoặc bốn. Và vì vậy, một thứ như hero retention metrics được gọi. Và sau đó tôi đoán sau này, chúng ta sẽ thấy nó. Chúng ta thấy nó chứ? Chúng ta thấy cái nào? Bạn có thấy không? Ồ, phải rồi, nó đây rồi. Xin lỗi, tôi đã bỏ lỡ. Hero retention metrics nằm ngay đó. Vì vậy, chúng ta đã thêm tool này một cách linh hoạt kịp thời. Và ngay sau khi chúng ta thêm nó, mô hình đã quay lại và gọi tool đó, và chúng ta đã nhận được toàn bộ dữ liệu từ nó.
Hoạt động của Programmatic Tool Calling
Được rồi, đó là tool search tool. Cái tiếp theo chúng ta đã nói đến là programmatic tool calling. Trong phần này, chúng ta đánh dấu nó là code execution trong giao diện này và chỉ xem xét đoạn mã mà mô hình viết. Và đây không phải là một điều đặc biệt nào đó mà tôi có. Chúng tôi cung cấp cho bạn chính xác đoạn mã mà mô hình viết để bạn có thể hiểu điều gì đang thực sự xảy ra. Bạn thấy nó đang gọi các phương thức đó. Nếu bạn nhìn vào results = async_gather, nó đang gọi từng tool đó. Các tool tương tự chúng ta đã thấy trước đây, nó đang gọi chúng với các tham số tương tự. Nhưng lần này, chúng ta không tải tất cả những thứ đó vào context. Mô hình đang tải chúng vào một đối tượng JSON và in ra rất rõ ràng. Bạn thấy context pipeline, gong, chính xác nguồn gốc của nó. Và sau đó bạn thấy dấu hai chấm, 2500, như thế. Mô hình biết chính xác đối tượng nào mà nó cần. Vì vậy, nó không cần tất cả những thứ rác rưởi chúng ta đã tải trong lượt đầu tiên. Nó chỉ cần một phần nhỏ này. Vì vậy, nó đang trích xuất phần đó. Nó đang in ra. Và sau đó đó là những gì được tải vào context của mô hình.
Hoạt động của Compaction trong Demo
Được rồi, đó là tool search tool. Và cuối cùng, cái cuối cùng chúng ta nói đến là compaction. Thực ra, đối với compaction, tại sao chúng ta không xem nó được gọi. Phải, phải, nó được gọi vài lần ở đây. Vì lý do demo, chúng tôi đã đặt compaction threshold khá nhỏ, như khoảng 500k token chẳng hạn. Và đó là một kỹ thuật phổ biến mà bạn không cần phải đi đến giới hạn. Tôi thích việc có context một triệu token, nhưng bạn có thể không cần tất cả số đó. Nó có thể giúp bạn tiết kiệm chi phí và độ trễ. Và nó có thể mang lại trí thông minh hơn nếu giữ mô hình ở ngưỡng thấp hơn. Đó là những gì chúng tôi đã làm ở đây. Chúng tôi giữ nó ở ngưỡng thấp hơn. Và khi context tăng lên đến ngưỡng đó, chúng tôi tạm dừng thực thi mô hình, gửi toàn bộ transcript đến một lời gọi mô hình khác, mô hình đó đã tóm tắt và đưa ra bản tóm tắt này. Vì vậy, hãy mở rộng bản tóm tắt. Bạn có thể thấy đây là bản tóm tắt của tất cả những gì đã diễn ra. Vì vậy, nó đã lấy hàng trăm lời gọi tool với tất cả kết quả của chúng và mọi thứ đang diễn ra, và chỉ nén nó xuống thành: "Đây là vài điều bạn cần biết để tiếp tục" để mô hình có thể tiếp tục.
Giới thiệu Chiến lược Advisor
Nhưng tôi nhận thấy vẫn tốn 10 đô la để chạy thứ này. Ý tôi là, tôi phải nói với bạn, kinh doanh token là một ngành tuyệt vời. Sau đó là bán siêu anh hùng, đó cũng là một ngành kinh doanh rất tốt, nhưng vẫn 10 đô la mỗi lần tải. Ý tôi là, chúng ta sẽ gặp rắc rối vì điều này. Vì vậy, tôi nhận thấy rằng bạn đang sử dụng Opus. Phải, nó nói điều này ở đâu? Vì vậy, mô hình đang được sử dụng là Opus một lần nữa, Opus 4, 7, một mô hình tuyệt vời. Nhưng nó đắt tiền. Và có thể tốt hơn nếu sử dụng một mô hình nhỏ hơn. Vì vậy, hóa ra một mô hình nhỏ như Sonnet có thể thực hiện tool calling tốt không kém, viết mã tốt không kém. Nhưng có một vài điều nó không làm tốt bằng. Và chúng ta sẽ nói về cách tận dụng điều đó. Vì vậy, hãy quay lại các slide. Và chúng ta sẽ nói về chiến lược Advisor.
Vấn đề chúng ta đang cố gắng giải quyết với Advisor là chúng ta muốn có trí thông minh cấp độ Opus, nhưng với chi phí cấp độ Haiku hoặc Sonnet. Nghe có vẻ tuyệt vời đúng không? Vì vậy, ý tưởng đằng sau đây thực sự đến từ các nhóm kỹ thuật. Bạn biết đấy, nếu bạn đã làm việc với các nhóm kỹ thuật, bạn sẽ so sánh một kỹ sư junior với một kỹ sư senior. Và kỹ sư junior đó sẽ trở nên tốt hơn rất nhiều. Bởi vì kỹ sư senior sẽ không làm tất cả công việc, họ sẽ không trực tiếp thực hiện công việc cho họ. Nhưng họ sẽ đánh giá mã, họ sẽ xem xét các tài liệu thiết kế, họ sẽ huấn luyện. Và điều đó cũng đúng với các mô hình. Điều chúng ta thấy là nếu chúng ta cho Haiku một cách, nó có thể gọi Opus và yêu cầu giúp đỡ. Sau đó, một Opus có thể quét transcript và xem điều gì đang xảy ra. Sau đó, nó có thể đưa ra một số lời khuyên cho Haiku, điều này thực sự hữu ích rất nhiều. Và vì vậy, bạn lại thấy một hình ảnh động đẹp khác ở đây. Bạn thấy rằng executor với Haiku biết mọi hình dạng. Nó biết chính xác phải làm gì với mỗi hình dạng, ngoại trừ hình dạng kỳ lạ này. Và đối với hình dạng kỳ lạ đó, nó phải đi hỏi advisor. Advisor biết, và sau đó advisor nói cho executor biết phải làm gì với hình dạng kỳ lạ đó. Và chúng tôi thấy các khách hàng như Bolt đang sử dụng điều này để giúp quản lý chi phí của họ.
Demo: Triển khai Chiến lược Advisor
Được rồi, hãy quay lại demo và chúng ta sẽ xem xét bước này. Vậy thì, tại sao chúng ta không thêm Advisor vào đây. Việc thêm Advisor sẽ chuyển mô hình từ Opus. Bây giờ bạn thấy dòng mô hình. Nó ghi: Sonnet 4.6 cộng với Opus làm advisor. Ngay lập tức, tôi lại thấy mắt các kế toán viên sáng lên vì giá đã giảm đáng kể. Ngay lập tức, bởi vì tất cả các lời gọi tool và mã Python, tất cả đều được thực hiện bằng Sonnet, rẻ hơn nhiều so với Opus. Vì vậy, bạn có được khoản tiết kiệm ngay lập tức.
Nhưng câu hỏi là, bạn có nhận được trí thông minh tương tự không? Có một mục tiêu thực sự quan trọng mà chúng ta có ở đây, đó là hợp đồng gia hạn Metropolis. Đây là một hợp đồng mà tôi rất lo lắng cho Hero Corp. Họ phải thắng hợp đồng gia hạn Metropolis. Và nếu chúng ta xem xét lời gọi advisor này, cách nó hoạt động là Sonnet đã xem xét tất cả các transcript của gong, tất cả dữ liệu về việc gia hạn Metropolis và Sonnet nói, "Tuyệt vời, cái này trông tốt. Đang đúng tiến độ." Nhưng sau đó, nó nói, "Ồ, có lẽ tôi sẽ gọi advisor và chỉ để chắc chắn vì đây là một giao dịch có tác động lớn." Và Opus đã xem xét cùng một transcript. Nó đã xem xét cùng một transcript đó và nó nói, "Ồ, Sonnet, bạn đã bỏ lỡ một điều được chôn vùi sâu trong transcript. Chúng ta thấy rằng Cryo Thing thực sự cần thiết mà thị trưởng thực sự muốn Cryo Thing." Và điều này rất chi tiết mà Sonnet đã bỏ lỡ. Vì vậy, Sonnet nói đang đúng tiến độ, nhưng Opus đã phát hiện ra.
Vì vậy, bây giờ bạn thấy lợi thế không chỉ là bạn đang sử dụng Sonnet vì nó không đắt. Ồ, đội ngũ tiếp thị bảo tôi không được nói là nó rẻ. Nó không rẻ, nó không đắt. Vì vậy, Sonnet không đắt. Và vì vậy, chúng ta có thể sử dụng nó, điều này rất tuyệt. Nhưng bạn vẫn nhận được trí thông minh của Opus, nhưng chỉ theo yêu cầu, chính xác những gì cần thiết. Và nó đã phát hiện ra vấn đề Cryo Thing này.
Hành động và Tầm nhìn của Agentic World
Được rồi, chúng ta đã phát hiện ra điều đó. Và bây giờ bạn có thể thấy nó hiển thị màu đỏ. Nó không ổn. Chúng ta cần làm gì đó. Và tôi không biết bạn thì sao, nhưng tôi có chút lo lắng về điều này. Tôi muốn đảm bảo rằng chúng ta có thể thắng hợp đồng Metropolis. Vì vậy, nếu bạn cuộn xuống một chút, có một việc mà CEO có thể làm. Đó là "khóa" Cryo Thing. Tôi cũng thích những cái tên siêu anh hùng này. Hóa ra đội pháp lý không cho phép tôi sử dụng bất kỳ tên siêu anh hùng thật nào. Vì vậy, chúng ta phải sử dụng Cryo Thing. Chúng ta có thể khóa điều này lại. Vậy chúng ta có nên cứu các hợp đồng không? Ai đồng ý cứu hợp đồng ở đây? Vâng. Được rồi, tuyệt vời! Cảm ơn bạn. Bạn đồng tình với tôi. Được rồi, hãy nhấp vào đó và khóa Cryo Thing. Chúng ta đã có nó. Được rồi, đây là trong thế giới agentic. Đây là tất cả những gì bạn làm với tư cách là một CEO. Chỉ cần nhấp vào nút và bạn đã hoàn thành. Mọi thứ đã được cứu.
Tổng kết và Các Tính năng Mới của Nền tảng
Được rồi, chúng ta chỉ còn một phút. Cảm ơn bạn, Ben. Hãy để tôi kết thúc. Vậy thì, quay lại các slide. Những gì chúng ta đã thấy ở đây là điều rất quan trọng là phải thực hiện prompt caching. Nếu bạn chưa làm điều đó, hãy bỏ qua phần còn lại của bài nói chuyện và đi làm điều đó. Nếu bạn đang làm điều đó, hãy thực sự chú ý đến context engineering. Đảm bảo bạn nhận thức được những gì có trong context và sau đó tối ưu hóa nó cho những gì thực sự cần thiết. Và cuối cùng, chúng ta đã nói về việc sử dụng chiến lược Advisor. Vì vậy, đó thực sự là trí thông minh theo yêu cầu.
Nhưng đó chưa phải là tất cả những điều tuyệt vời mà chúng tôi đã cung cấp trên nền tảng trong vài tháng qua. Vì vậy, tôi muốn nêu bật những điều yêu thích của mình. Đây là Workload Identity Federation. Vì vậy, nếu bạn lo lắng, nếu đội ngũ an ninh của bạn lo lắng về việc mất API key, bạn không cần phải lo lắng nữa. WIF là một câu trả lời tuyệt vời cho điều đó. Và sau đó tôi chỉ yêu thích công cụ dòng lệnh Ants CLI này. Mọi thứ bạn có thể làm trong bảng điều khiển đều có sẵn thông qua công cụ dòng lệnh. Và điều tuyệt vời nhất về công cụ dòng lệnh là Claude rất thích các công cụ dòng lệnh. Vì vậy, Claude. Nếu bạn sử dụng nó thông qua Claude Code, chỉ cần nói cho nó biết về công cụ Ants CLI và nó sẽ quản lý mọi thứ cho bạn và làm một công việc tuyệt vời. Và điều thực sự cần lưu ý ở đây là đặt cược vào nền tảng có nghĩa là nền tảng sẽ tiếp tục tốt hơn và agent của bạn sẽ tiếp tục tốt hơn khi những điều mới tiếp tục ra mắt trên nền tảng. Đó là tất cả. Cảm ơn rất nhiều. Tôi rất trân trọng.