Xây dựng agent: Khi nào nên gộp subagent vào vòng lặp agent chính

Link bài viết gốc： Xây dựng agent: Khi nào nên gộp subagent vào vòng lặp agent chính

Diane Sarkis · Anthropic · 2026-10-22 08:00

Bài viết này được chia sẻ lại, bản quyền thuộc về tác giả gốc, toàn văn căn cứ theo link bài gốc

Nếu bạn đã xây dựng một agent gồm nhiều subagent trên Claude Platform, bạn có thể xem xét những subagent nào phù hợp để gộp vào vòng lặp agent chính bằng cách tham khảo bộ công cụ di chuyển của chúng tôi. Bộ công cụ này sẽ chạy một workflow có hướng dẫn nhằm giúp bạn xác định các pattern hiện có, đánh giá các phương án thay thế và xác thực các best practice. Trong bộ công cụ còn đi kèm một bản demo để bạn có thể chạy thử trên một hệ thống mô phỏng trước khi áp dụng vào agent của mình.

Các subagent — vốn sở hữu context window, công cụ và chỉ dẫn riêng, được điều phối tập trung bởi một coordinator — là thành phần cốt lõi trong thiết kế agent. Chúng thể hiện xuất sắc ở khâu xác thực, xử lý công việc song song và quản lý quyền hạn theo dạng mô-đun. Chúng tôi đã áp dụng subagent trong nhiều agent được xây dựng bằng Claude Platform, chẳng hạn như hệ thống nghiên cứu multi-agent .

của chúng tôi. Tuy nhiên, gần đây đội ngũ Applied AI nhận thấy rằng một số triển khai agent cấp doanh nghiệp thu được lợi ích rõ rệt sau khi gộp router, planner và các subagent theo domain vào vòng lặp agent chính. Trong bản so sánh của chúng tôi trên nhiều lượt triển khai doanh nghiệp , agent đơn lẻ tích hợp kỹ năng thường vượt trội về chất lượng so với các thiết kế "một prompt duy nhất cho tất cả" lẫn thiết kế subagent, đồng thời chi phí và độ trễ trên mỗi tác vụ thường cũng thấp hơn.

Ví dụ, một công ty nhận thấy rằng hơn chục subagent chuyên biệt trong agent phục vụ khách hàng của họ khiến việc duy trì trải nghiệm thương hiệu nhất quán trở nên khó khăn, và độ trễ tăng thêm đã làm tổn hại đến trải nghiệm người dùng.

Chúng tôi cũng thường xuyên bắt gặp những phương án thiết kế agent đi theo lộ trình quen thuộc: một bộ phân loại ý định (intent classifier), một pipeline suy luận nhiều bước cố định, các bucket phân khúc người dùng, các nhánh gợi ý độc lập, cộng thêm một multi-agent orchestrator ở tầng trên cùng.

Trong những trường hợp này, phản hồi thường là: phần lớn công việc trong các cấu trúc đó không còn cần model phải xử lý theo cách này nữa, chỉ cần một system prompt rõ ràng, 4-5 công cụ dữ liệu gọn nhẹ cùng các guardrail đầu ra chặt chẽ là đã có thể đáp ứng hầu hết trường hợp sử dụng.

Cần làm rõ rằng, subagent vẫn có đất dụng võ, đặc biệt là ở tiền tuyến nghiên cứu. Bạn nên sử dụng chúng trong các trường hợp sau:

• Vòng lặp agent đơn lẻ bị suy giảm hiệu năng rõ rệt do context bị phình to (context bloat), hoặc
• Nhiều tác vụ cần được xử lý song song trong các context window hoàn toàn mới và có thể hủy bỏ sau khi tác vụ hoàn thành, hoặc
• Agent đơn lẻ gặp khó khăn trong việc chọn công cụ phù hợp, hoặc xuất hiện các chỉ dẫn xung đột lẫn nhau bên trong system prompt.

Nhưng rất nhiều khi, chúng tôi thấy các doanh nghiệp để mỗi nhóm hoặc mỗi loại vấn đề sở hữu một subagent riêng, khiến kiến trúc agent trở thành bản sao của sơ đồ tổ chức (Định luật Conway đang phát huy tác dụng).

Dựa trên kinh nghiệm xây dựng agent trong các tổ chức quy mô lớn, bài viết này sẽ phân tích khi nào bạn nên cân nhắc gộp subagent vào vòng lặp agent chính, đồng thời chia sẻ những best practice hiệu quả.

Agent building failure modes for large organizations (Các dạng thất bại khi xây dựng agent ở các tổ chức quy mô lớn)

Các doanh nghiệp thường mong muốn xây dựng một agent có thể tích hợp nhiều sản phẩm và năng lực vào một giao diện khách hàng thống nhất.

Thông thường, mỗi năng lực do một nhóm độc lập phụ trách, vì vậy ban đầu doanh nghiệp sẽ để mỗi nhóm tự xây dựng agent của riêng mình, sau đó đội ngũ nền tảng trung tâm sẽ dựng một orchestrator ở tầng trên cùng. Điều này có thể mang nhiều cấu trúc khác nhau, bao gồm mô hình orchestrator - subagent, hoặc hiển thị các agent chuyên biệt dưới dạng công cụ MCP cho một agent duy nhất.

Đây có vẻ là giải pháp đơn giản nhất, nhưng ngay lập tức sẽ kéo theo sự phức tạp ở các khía cạnh sau:

• Quản lý ngữ cảnh: Bạn phải quyết định xem cần trao đổi context nào giữa các agent, và các chi tiết thường bị thất lạc trong quá trình truyền qua truyền lại.
• Tràn lan subagent: Mỗi nhóm đều tự phát hành subagent của riêng mình, dẫn đến việc doanh nghiệp sở hữu hàng trăm subagent chồng chéo, không có tiêu chuẩn bắt buộc và cũng không có chủ sở hữu rõ ràng.
• Frankenprompt: Mỗi nhóm lại thêm một câu vào system prompt, kết quả là dẫn đến các quy tắc xung đột nhau và phong cách không nhất quán.
• Các đánh giá chưa qua kiểm duyệt, bị cục bộ hóa quá mức: Ai cũng thêm các bộ eval của riêng mình, và những đánh giá này lại bị tối ưu hóa quá mức cho các tác vụ con của họ. Không ai sở hữu hay duy trì toàn bộ bộ eval, khiến ban lãnh đạo chỉ có thể đưa ra quyết định dựa trên những điểm số bị pha loãng và mang tính cục bộ.
• Độ trễ: Sự phức tạp của kiến trúc multi-agent làm gia tăng độ trễ. Một khách hàng đã so sánh framework multi-agent của họ với một vòng lặp agent đơn lẻ và nhận thấy vòng lặp đơn lẻ chạy nhanh hơn khoảng 2 lần.

Using an agent loop with progressive disclosure (Sử dụng vòng lặp agent với cơ chế tiết lộ tăng dần)

Thiết kế orchestrator - subagent kể trên là một phương pháp hợp lý để phối hợp các chuyên gia liên nhóm, nhưng cách làm thường hiệu quả hơn là tiết lộ context tăng dần thông qua các skill và tiết lộ công cụ tăng dần thông qua tìm kiếm công cụ . Nói cách khác, agent trước tiên chỉ nhìn thấy các mô tả ngắn gọn về skill và công cụ, và chỉ tải đầy đủ khi thực sự cần.

Cách tiếp cận này hợp lý vì ba lý do sau:

• Context dùng chung mang lại câu trả lời tốt hơn: Đối với các agent chạy trong thời gian dài, chúng ta muốn context của nhiều tác vụ khác nhau đều nằm trong context window chính. Một agent có thể thấy kết quả của từng bước trước đó sẽ có khả năng xâu chuỗi chúng lại, từ đó tạo ra kết quả phong phú hơn và hiểu biết sâu sắc hơn so với một tập hợp các bản tóm tắt do các subagent gửi về. Điều này cũng đồng nghĩa với việc ít context window hơn và giảm thiểu các khâu bàn giao gây suy hao thông tin .
• Cơ chế tiết lộ tăng dần giúp ngăn ngừa phình to context: Kỹ thuật này cho phép các nhóm xây dựng một agent đơn lẻ có thể hoàn thành nhiều tác vụ khác nhau mà không cần tải ngay toàn bộ context vào một system prompt dài dòng. Điều này loại bỏ lý do chính khiến các nhóm trước đây phải chia nhỏ công việc cho các subagent. Trên thực tế, chúng tôi đã giảm hơn 80% system prompt của Claude Code cho các model tiên tiến hơn , trong đó bao gồm các đợt cắt giảm liên quan đến việc tiết lộ tăng dần các skill và công cụ.
• Model ngày càng mạnh mẽ hơn: Kể từ Opus 4.5, khối lượng nội dung mà model có thể xử lý trong một vòng lặp đơn lẻ đã vượt xa kỳ vọng của hầu hết các nhóm. Opus 5.5 và Fable 5.1 không thể tắt chế độ suy nghĩ, đồng thời các model gần đây ngày càng có xu hướng tự thuật lại tiến độ và tự kiểm tra trong quá trình chạy, khiến cho một số thành phần trong framework trở nên thừa thãi. Mỗi thế hệ model mới đều cho phép bạn chuyển giao nhiều quyền ra quyết định hơn từ framework sang chính model. Một vòng lặp đơn giản hơn cũng dễ dàng migrate sang thế hệ model tiếp theo; trong các đợt migration mà chúng tôi hỗ trợ khách hàng, cấu trúc multi-agent cứng nhắc thường chính là rào cản ngăn model mới đảm nhận nhiều công việc hơn.

Thiết kế vòng lặp agent đơn lẻ đòi hỏi tính kỷ luật: một system prompt được quản lý cẩn thận, phần mô tả skill và công cụ có thể kích hoạt đúng lúc, cùng với việc xử lý có chủ đích đối với context window, memory và ghi chú. Các phần tiếp theo của bài viết sẽ đi sâu vào việc migration và những cân nhắc trong thiết kế.

Nên có một nhóm trung tâm chịu trách nhiệm về chất lượng end-to-end cùng system prompt, đồng thời review mọi công cụ và eval mới trước khi đưa vào hoạt động. Giữ cho nhóm trung tâm tinh gọn sẽ giúp lặp nhanh và giảm chi phí phối hợp trong các tổ chức lớn.

Nếu bạn chọn hướng đi multi-agent, hãy bắt đầu từ mô hình khả thi đơn giản nhất (generator - verifier, orchestrator - subagent hoặc mô hình khác). Bằng cách phân chia theo context để phân định ranh giới một cách hiệu quả: hãy giao cho mỗi subagent một phần việc ít liên kết với phần còn lại của hệ thống, và để nó trả về kết quả cô đọng (các ứng viên sáng giá bao gồm các luồng nghiên cứu độc lập, các thành phần riêng biệt có interface rõ ràng, hoặc kiểm thử hộp đen). Khi các agent bị phân chia theo loại vấn đề, chúng sẽ rơi vào trò chơi "truyền tin", và mỗi lần bàn giao đều làm suy giảm độ chuẩn xác của thông tin.

How to fold subagents into the main agent loop (Cách gộp subagent vào vòng lặp agent chính)

Nhiều nhóm đã có sẵn một orchestrator và một tập hợp các agent chuyên gia trong môi trường production. Dưới đây là thiết kế vòng lặp đơn mà chúng tôi khuyên bạn nên từng bước hiện thực hóa:

• Một model và một context window chạy một vòng lặp công cụ mở, với các giới hạn được thiết lập trong framework (ngân sách về số lượt và chi phí, cổng kiểm soát ghi).
• Ở mỗi lượt, model phát ra một loạt lệnh gọi công cụ. Framework sẽ chạy song song các lệnh gọi này và trả kết quả thô về cho cùng model đó để nó quyết định bước tiếp theo: phát thêm một loạt lệnh gọi nữa, đặt câu hỏi cho người dùng, hoặc đưa ra câu trả lời.
• Khi model đưa ra câu trả lời hoặc đạt đến Ngân sách thì vòng lặp dừng lại. Có thể tùy chọn chạy thêm bước kiểm tra mục tiêu hoặc validator sau câu trả lời.
• Model sẽ viết kế hoạch vào context ngay từ lượt đầu tiên, rồi sửa đổi kế hoạch khi các kết quả lần lượt gửi về. Đây là điểm khác biệt cốt lõi so với mô hình orchestrator + agent chuyên gia: model viết kế hoạch cũng chính là model thực thi kế hoạch, vì vậy nó có thể thay đổi kế hoạch ngay giữa quá trình chạy.
• Context vẫn sẽ được tải vào và do chính agent quản lý: không còn cần đến các bước code viết lại kế hoạch từ danh mục quy tắc nữa, bởi model sẽ tự mình quyết định từng bước. Trình tự và quy trình theo domain được chuyển vào Kỹ năng . Các giới hạn cứng (xác thực, cổng phê duyệt) cũng như bất kỳ nội dung nào khác xuất hiện trong quá trình hội thoại (như tra cứu memory) được chuyển vào Công cụ . Code vẫn có thể được sử dụng để tải các nội dung chi phí thấp và hầu như luôn liên quan (chẳng hạn như các bước phân giải thực thể), cũng như xử lý các phần mang tính máy móc bên trong các công cụ được vòng lặp gọi (xây dựng payload, phân tích cú pháp stream, khôi phục làm rõ).

Thiết kế vòng lặp đơn này cũng góp phần hướng tới trạng thái đích mà nhiều nhóm đang nỗ lực đạt được (một agent hiểu được các mục tiêu cấp cao của người dùng và hành động thay cho họ), vì nó lưu giữ mọi thứ mà agent học được trong một context duy nhất.

Các khuyến nghị dưới đây mô tả cách các nhóm có thể chuyển đổi theo từng giai đoạn từ hệ thống multi-agent sang vòng lặp agent đơn lẻ, cũng như cách nhiều nhóm có thể tiếp tục đóng góp cho agent này trong suốt lộ trình.

Task-completion evals (Đánh giá mức độ hoàn thành tác vụ)

Bước đầu tiên là tạo một bộ eval giúp bạn xác định xem có nên gộp subagent vào vòng lặp agent chính hay không. Cấu trúc đánh giá hiệu quả mà chúng tôi quan sát được là: một bộ eval end-to-end dùng chung do nhóm trung tâm sở hữu, cộng thêm các bộ eval nhỏ hơn do từng nhóm sở hữu skill phát hành đi kèm với chính skill đó. Thậm chí chỉ cần 10 ví dụ mẫu chuẩn (golden example) là đã đủ để bắt đầu.

Chấm điểm tin nhắn cuối cùng của agent theo bộ tiêu chí (rubric) là điểm khởi đầu tốt để theo dõi chất lượng câu trả lời. Khi bạn vẫn đang dùng orchestrator, bạn cũng nên theo dõi độ chính xác trong định tuyến (nó có chọn đúng subagent không?). Một khi subagent đã được gộp vào, bạn nên chuyển sang kiểm tra xem agent có tải đúng skill hoặc gọi đúng công cụ hay không. Theo thời gian, việc hướng tới các bài đánh giá mức độ hoàn thành tác vụ là rất hữu ích, bởi đây chính là yếu tố quan trọng nhất khi so sánh giữa các kiến trúc khác nhau.

Trong môi trường mà các hệ thống nội bộ khó phát lại và sự tương tác của người dùng khó mô phỏng, điều này có thể khá phức tạp. Một phương pháp hiệu quả mà nội bộ chúng tôi áp dụng là ghi lại timestamp cho các sự kiện quan trọng để có thể phát lại sau đó và chạy dưới dạng các eval có mục tiêu.

Reducing subagents over time (Từng bước giảm bớt subagent)

Việc chuyển đổi sang vòng lặp agent đơn lẻ đòi hỏi bạn phải gộp các subagent vào công cụ và skill. Điều này có thể được thực hiện bằng cách hợp nhất các subagent theo domain, gọi chúng dưới dạng công cụ, hoặc thay thế chúng bằng các skill và công cụ.

Combining domain agents (Hợp nhất các agent theo domain)

Hãy xây dựng một bộ đánh giá end-to-end quy mô nhỏ trước lần sáp nhập đầu tiên. Sau đó tiến hành sáp nhập thông qua việc chia sẻ context, bắt đầu từ subagent được dùng nhiều nhất.

Hãy sáp nhập các expert có đầu ra liên kết với nhau, cùng thao tác trên một dữ liệu hoặc thường xuyên được gọi cùng lúc. Ví dụ, nếu phần lớn lưu lượng truy cập production là một expert chạy tiếp nối ngay sau một expert khác, thì đó là một cặp liên kết chặt chẽ (tightly coupled), khiến chúng trở thành ứng viên sáng giá để sáp nhập thành một domain agent duy nhất.

Subagents called as tools (Gọi subagent dưới dạng tool)

Khi một trong ba điều kiện trên xảy ra và bạn vẫn giữ lại các subagent, việc để agent chính gọi subagent dưới dạng tool có thể rất hiệu quả, giúp agent chính tiếp tục duy trì cuộc đối thoại với người dùng.

Chúng tôi chỉ khuyến nghị bàn giao hoàn toàn (full handoff) — tức subagent tiếp quản cuộc trò chuyện — khi subagent đó cần nói chuyện trực tiếp với người dùng. Mọi trường hợp khác đều có thể quy về skill kết hợp với tool trong vòng lặp chính (main loop).

Cách này cho phép bạn định nghĩa một response schema dùng chung cho các subagent, để agent chính đối chiếu và xác thực kết luận với dữ liệu thực tế (ground truth), đồng thời tinh gọn đầu vào cho bất kỳ bước tổng hợp cuối cùng nào. Đây là bước đầu tuyệt vời vì bạn không cần viết lại subagent. Nó cũng cung cấp một baseline để đánh giá mức độ hoàn thành nhiệm vụ trước khi quyết định sáp nhập bất kỳ subagent nào vào agent chính.

Tuy nhiên, một số dạng lỗi (failure mode) vẫn tồn tại:

• Mỗi expert đều có prompt, context, đội ngũ phụ trách và bộ đánh giá riêng
• Mỗi lần gọi vẫn trả về một bản tóm tắt bị mất mát thông tin (lossy summary)
• Mỗi lần gọi là một vòng lặp model lồng nhau, làm tăng độ trễ (latency)

Folding subagents into the main agent via skills and tools (Sáp nhập subagent vào agent chính thông qua skill và tool)

Hãy sáp nhập từng subagent một vào agent chính, chuyển đổi prompt của mỗi subagent thành skill, và biến các lệnh gọi API của nó thành MCP tool. So sánh hiệu năng đánh giá (eval) khi có và không có subagent đó, rồi quyết định nên giữ lại những gì.

Khi so sánh, đừng chỉ nhìn vào điểm số cuối cùng, hãy kiểm tra xem những tác vụ nào đã thay đổi. Khi chúng tôi thử nghiệm trên một support agent mẫu, việc sáp nhập một subagent vào subagent khác đã giúp giảm độ trễ, nhưng cũng làm hỏng một quy trình vốn đang hoạt động bình thường. Agent chính nắm giữ tool tra cứu đơn hàng và tự trả lời, thay vì hỏi expert logistics về ngày giao hàng.

Trước mỗi lần thay đổi, hãy đảm bảo bộ đánh giá của bạn bao gồm các tác vụ cho từng chuỗi agent cùng chạy trong môi trường production, cũng như mọi quy tắc mà agent tuyệt đối không được vi phạm. Đồng thời, hãy chạy mỗi tác vụ nhiều lần, bởi vì những lỗi như thế này đôi khi chỉ xuất hiện ở một trong hai lần chạy.

How several teams can contribute to a single agent (Cách nhiều nhóm cùng đóng góp vào một agent duy nhất)

Suy luận theo lĩnh vực (domain reasoning) có thể được truy xuất từ kho tri thức, skill và MCP tool. Các nhóm riêng lẻ có thể chuyển quyền sở hữu từ agent sang skill và tool, trong khi một nhóm phụ trách chung (central team) tinh gọn sẽ nắm quyền sở hữu system prompt và chất lượng tổng thể end-to-end. Điều này bao gồm việc kiểm duyệt các skill, tool và bộ đánh giá trước khi phát hành.

MCP tools (MCP tool)

Tool sẽ thích hợp khi agent cần thực thi tác vụ, đọc dữ liệu thời gian thực từ hệ thống hoặc trả về kết quả theo định dạng cố định. Bạn cũng có thể dùng tool trong quá trình di chuyển (migration) để tiếp tục gọi các subagent. Chúng tôi khuyến nghị nên nhóm các tool theo ý định của người dùng (user intent) thay vì mỗi API một tool, bởi khi số lượng định nghĩa tool trong system prompt vượt quá 30–50, khả năng lựa chọn tool thường sẽ bị suy giảm.

Hãy áp dụng cơ chế tìm kiếm tool với tính năng trì hoãn tải (deferred loading), hạn chế các điều kiện tiên quyết cứng (hard precondition) và chuyển các điều kiện cần thiết vào bên trong chính tool đó. Ví dụ, nếu Y cần đầu ra của X, tool của Y sẽ kiểm tra đầu ra đó và trả về các chỉ dẫn mà model có thể thực thi. Quyền hạn của người dùng cũng được thiết lập theo cách tương tự. Mỗi tool sẽ kiểm tra xem người dùng hiện tại có thể xem hoặc thực hiện những gì, rồi trả về thông báo từ chối rõ ràng để model có thể đọc được. Nhờ đó, một vòng lặp duy nhất có thể phục vụ người dùng ở nhiều cấp độ phân quyền khác nhau mà không cần dựng riêng agent cho từng cấp độ.

Skills (Kỹ năng)

Skill sẽ thích hợp khi agent cần hiểu cách thức một nhóm xử lý công việc, chẳng hạn như các bước, quy tắc và phán đoán từng nằm trong prompt của các expert subagent trước đây.

Phương pháp mở rộng thư viện skill của chúng tôi là giao lại việc bảo trì cho chính những người viết skill. Claude có thể đảm nhận các tác vụ nặng nhọc thông qua việc xây dựng, kiểm thử và tinh gọn các skill khác.

Để ngăn chặn tình trạng phình to skill (skill bloat), hãy phân công DRI của mỗi nhóm quản lý các skill của họ, đảm bảo skill được thiết kế cẩn thận, có tính riêng biệt và được phát hành kèm theo các bộ đánh giá phù hợp.

• /skill-creator cho phép bạn tạo các skill mới đúng chuẩn, đồng thời rà soát các skill hiện có để tinh gọn, loại bỏ trùng lặp và tái cấu trúc.
• /skill-doctor cho phép bạn xem chi phí của từng skill trong thư viện cũng như tần suất sử dụng thực tế của nó, từ đó loại bỏ những nội dung không cần thiết.

Knowledge bases (Kho tri thức)

Kho tri thức sẽ thích hợp khi agent chỉ thỉnh thoảng mới cần tra cứu tài liệu tham khảo. Các dữ kiện và tài liệu tham khảo (chính sách, định nghĩa chỉ số, thông số sản phẩm) có thể được đặt sau một tool tìm kiếm hoặc truy vấn mà model gọi tới, hoặc đính kèm dưới dạng tệp tài liệu tham chiếu bên trong skill. Tránh để code tự động truy xuất rồi dán thẳng context này vào prompt.

Tools to accelerate this work (Các công cụ giúp đẩy nhanh công việc này)

Gần đây chúng tôi đã phát hành một bộ skill cho Claude API giúp hỗ trợ phần lớn các công việc nêu trên. Bộ công cụ di chuyển (migration kit) của chúng tôi kết nối các skill này vào một workflow có hướng dẫn từng bước nhằm đánh giá hệ thống đa agent (multi-agent) và chuyển đổi sang vòng lặp agent đơn (single-agent loop). Bộ công cụ đi kèm một bản demo để bạn có thể chạy thử nghiệm trước khi áp dụng vào hệ thống thực tế:

• /claude-api build-eval: Giúp tạo bộ đánh giá end-to-end đầu tiên do central team quản lý, hoặc các bộ đánh giá nhỏ được từng nhóm phát hành kèm theo skill của họ
• /claude-api prompt-audit: Có thể gắn cờ các chỉ dẫn trong prompt, skill và phần mô tả tool vốn được viết cho các model cũ hơn, đồng thời đề xuất bản sửa lỗi dưới dạng so sánh thay đổi (diff). Bạn có thể chạy lệnh này trên system prompt để phát hiện các quy tắc từng được thêm vào cho các model đời trước mà nay lại làm chậm agent hoặc khiến nó phản hồi cứng nhắc. DRI của mỗi nhóm cũng có thể chạy lệnh này trên phần mô tả skill và tool của chính họ.
• /claude-api hillclimb: Có thể cải thiện ứng dụng theo hình thức lặp (iterative) dựa trên bộ đánh giá hiện có. Tính năng này có thể được dùng để so sánh giữa "sáp nhập và giữ lại" (sau khi gộp một subagent thành skill kèm tool, hãy để lệnh này lặp lại trên các mô tả skill và tool xem phiên bản đã gộp có đạt kết quả tương đương hoặc vượt trội hơn subagent ban đầu hay không), cũng như dùng cho system prompt của bạn.
• /claude-api cost-optimize: Sẽ phân tích lưu lượng các lệnh gọi và đề xuất các phương án tiết kiệm dựa trên prompt caching, cắt giảm các token input/output không cần thiết, mức độ nỗ lực (effort level) và lựa chọn model, với nguyên tắc chỉ thay đổi từng yếu tố một mỗi lần. Điều này giúp cắt giảm chi phí và độ trễ cho một thiết kế cụ thể.

Khi các model ngày càng phát triển, hiểu biết của chúng ta về cách sử dụng chúng hiệu quả nhất cũng như các tài liệu hướng dẫn thực hành tốt nhất (best practices) cũng không ngừng thay đổi. Điều này khiến cho không có bất kỳ kiến trúc đơn lẻ nào quan trọng bằng các nguyên tắc cốt lõi đằng sau nó: đo lường, chỉ thay đổi một yếu tố mỗi lần và giữ lại những gì đã được kiểm chứng hiệu quả.

Đây chính là một trường hợp như vậy. Khi các model ngày càng có năng lực mạnh mẽ hơn và agent có thể chạy trong thời gian dài hơn, ngày càng nhiều subagent của bạn có thể chuyển đổi thành skill và tool. Tuy nhiên, bạn không cần phải làm tất cả cùng một lúc. Hãy xây dựng một bộ đánh giá end-to-end quy mô nhỏ, sáp nhập thử một subagent, chỉ giữ lại nó dưới dạng subagent nếu phiên bản sau sáp nhập có điểm số kém hơn, rồi sau đó lặp lại quy trình này.

Học tương tác với AI (NotebookLM)

Ngoài đọc , bạn có thể nghe , xem và xem hoạ thông tin ở đầu bài. Bài này còn có bộ công cụ tương tác do AI tạo: Bài kiểm tra trắc nghiệm, Thẻ ghi nhớ, Sơ đồ tư duy, Bản trình bày và Báo cáo chuyên sâu.

Mở không gian học tương tác