Plan or Retrieve First? A Scale Study of Tool Discovery Architectures Tác giả Mingfei Zhang, Amit Surana, Ziauddin Majid, Chenxi Wang, Michael Xu Các LLM agent được tăng cường công cụ khám phá các API liên quan từ các registry lớn trước khi lên kế hoạch thực thi, nhưng cửa sổ ngữ cảnh hữu hạn ngăn cản việc chèn tất cả định nghĩa công cụ vào một prompt duy nhất. Cách tiếp cận chiếm ưu thế, mà chúng tôi gọi là Retrieve-then-Plan (RtP), mã hóa truy vấn người dùng và truy xuất các công cụ tương tự thông qua tìm kiếm nearest-neighbor gần đúng. Chúng tôi nghiên cứu một lối mới Plan-then-Retrieve (PtR) mà LLM đầu tiên tạo ra các Abstract Tool Stubs (các chữ ký hàm giả thuyền mô tả khả năng cần thiết) sau đó dùng làm truy vấn truy xuất trên registry. Đánh giá trên ToolBench (46.984 endpoint API duy nhất, 50 danh mục) trên các tập truy vấn single-tool (G1), intra-category multi-tool (G2), và cross-category multi-tool (G3), chúng tôi tìm thấy một crossover phụ thuộc độ phức tạp rõ rệt: RtP vượt trội hơn PtR trên truy vấn single-tool trong khi PtR vượt trội hơn RtP trên truy vấn multi-tool. Crossover này giữ nguyên ở mọi ngân sách truy xuất (k=1 đến 20), vững chắc trên các kích thước registry từ 1k đến 47k API, và nhất quán trên các gia đình mô hình (Gemini 2.5 Flash và gpt-oss-120b). Chúng tôi mô tả một chế độ lỗi stub-hallucination (LLM phát minh tên API có vẻ hợp lý nhưng không tồn tại) hoạt động như một con dao hai lưỡi: trên truy vấn đơn giản, các stub của PtR che giấu tín hiệu danh từ riêng mà RtP khớp trực tiếp, trong khi trên truy vấn phức tạp, cơ chế tương tự phân tích ý định đa chiều thành các nhu cầu chức năng con.