- มีการเพิ่ม 3 ฟีเจอร์ใหม่ใน Claude Developer Platform เพื่อมอบ สถาปัตยกรรมการใช้เครื่องมือขั้นสูง ที่ช่วยให้โมเดลสามารถสำรวจ เรียกใช้ และเรียนรู้จากเครื่องมือภายนอกหลายพันรายการได้อย่างมีประสิทธิภาพ
- Tool Search Tool จะโหลดคำจำกัดความของเครื่องมือเฉพาะเมื่อจำเป็นเท่านั้น ทำให้ ลดการใช้โทเค็นได้สูงสุด 85% และเพิ่ม ความแม่นยำได้ราว 74~88% ในสภาพแวดล้อม MCP ขนาดใหญ่
- Programmatic Tool Calling เรียกใช้เครื่องมือแบบขนานในสภาพแวดล้อมการรันโค้ด เพื่อให้ได้ทั้ง การประหยัดโทเค็น (37%) , ลดเวลาแฝง และ เพิ่มความแม่นยำ
- Tool Use Examples ช่วยให้ระบบเรียนรู้ รูปแบบการใช้เครื่องมือและความสัมพันธ์ของพารามิเตอร์ ที่ไม่สามารถอธิบายได้ด้วย JSON Schema ผ่านตัวอย่างการเรียกใช้จริง
- ฟีเจอร์ทั้งสามนี้มอบ รากฐานสำหรับการ orchestration ของ AI agent ขนาดใหญ่ได้อย่างมีประสิทธิภาพ และเป็นองค์ประกอบหลักของการทำงานอัตโนมัติในเวิร์กโฟลว์ที่ซับซ้อน
การขยายการใช้เครื่องมือของ AI agent
- AI agent ในอนาคตจำเป็นต้องใช้งานเครื่องมือหลายร้อยถึงหลายพันรายการร่วมกันอย่างบูรณาการ
- ตัวอย่างที่ยกมาได้แก่เครื่องมือช่วย IDE, ตัวประสานงานปฏิบัติการ และการเชื่อมต่อกับ Slack, GitHub, Jira, Google Drive เป็นต้น
- วิธีเดิมต้องโหลดคำจำกัดความของเครื่องมือทั้งหมดล่วงหน้า จึงสิ้นเปลือง context window อย่างรวดเร็ว
- แนวทางใหม่นี้เน้น ค้นหาและโหลดเครื่องมือเมื่อจำเป็น พร้อมเพิ่มประสิทธิภาพผ่าน การเรียกใช้แบบอิงโค้ด และ การเรียนรู้จากตัวอย่าง
Tool Search Tool
- ในสภาพแวดล้อม MCP แบบเดิม การเชื่อมต่อกับหลายเซิร์ฟเวอร์ทำให้คำจำกัดความของเครื่องมือกินพื้นที่ มากกว่า 100,000 โทเค็น
- ตัวอย่าง: GitHub (26K), Slack (21K), Jira (17K) และเมื่อรวมกันอาจเกิน 134K โทเค็น
- Tool Search Tool ค้นหาและโหลดเครื่องมือแบบ on-demand
- ตอนโหลดเริ่มต้นใช้เพียงประมาณ 500 โทเค็น และโหลดเพิ่มเฉพาะเครื่องมือที่จำเป็น
- ลดการใช้โทเค็นรวมลงเหลือราว 8.7K พร้อม ประหยัดคอนเท็กซ์ได้ 95%
- ผลการทดสอบภายในแสดงให้เห็นว่าความแม่นยำในการประเมิน MCP ดีขึ้นเป็น Opus 4: 49%→74%, Opus 4.5: 79.5%→88.1%
- สามารถโหลดเครื่องมือแบบหน่วงเวลาได้ผ่านการตั้งค่า
defer_loading: true
- โหลดเฉพาะเครื่องมือที่ใช้บ่อยไว้เสมอ และเรียกเครื่องมือที่เหลือในตอนค้นหา
- มีเครื่องมือค้นหาที่ใช้ regex และ BM25 มาให้โดยค่าเริ่มต้น และยังรองรับการค้นหาแบบคัสตอมด้วย embedding
- เงื่อนไขที่แนะนำให้ใช้: มีเครื่องมือมากกว่า 10 รายการ, คำจำกัดความรวมเกิน 10K โทเค็น, หรือเกิดข้อผิดพลาดในการเลือกเครื่องมือบ่อย
Programmatic Tool Calling
- การเรียกใช้แบบภาษาธรรมชาติในรูปแบบเดิมไม่มีประสิทธิภาพ เพราะมี การสะสมผลลัพธ์ระหว่างทาง และ การทำ reasoning หลายรอบ
- ตัวอย่าง: การวิเคราะห์ล็อกขนาด 10MB ทำให้ข้อมูลทั้งหมดถูกใส่เข้าไปในคอนเท็กซ์และสิ้นเปลืองโทเค็น
- Programmatic Tool Calling (PTC) ช่วย เรียกใช้เครื่องมือแบบขนานในสภาพแวดล้อมการรันโค้ด
- Claude สามารถใช้โค้ด Python เพื่อทำลูป เงื่อนไข และการแปลงข้อมูล
- ผลลัพธ์ระหว่างทางจะไม่ถูกรวมอยู่ในคอนเท็กซ์ของโมเดล และ ส่งกลับเฉพาะผลลัพธ์สุดท้ายเท่านั้น
- ตัวอย่าง: งานค้นหาผู้ที่ใช้งบเกินรายไตรมาส ทำให้ต้องใส่เข้าไปในคอนเท็กซ์เพียงผลลัพธ์ 1KB แทนข้อมูล 2,000 รายการ
- ผลลัพธ์ที่ได้
- การใช้โทเค็นลดจาก 43,588→27,297 (ลดลง 37%)
- ลดเวลาแฝงลงได้ (ตัดการทำ reasoning ออก 19 ครั้งจากการเรียก 20 ครั้ง)
- ความแม่นยำดีขึ้น: internal search 25.6→28.5%, GIA benchmark 46.5→51.2%
- เงื่อนไขที่แนะนำให้ใช้
- งานสรุปข้อมูลขนาดใหญ่, การเรียกใช้แบบพึ่งพากันตั้งแต่ 3 ขั้นขึ้นไป, หรืองานที่ต้องรันแบบขนาน
- ไม่คุ้มค่าสำหรับการเรียกใช้ครั้งเดียวหรือคำตอบขนาดเล็ก
Tool Use Examples
- JSON Schema กำหนดได้เพียงโครงสร้าง แต่ไม่สามารถแสดง รูปแบบการใช้งาน กฎด้านรูปแบบ และความสัมพันธ์ของพารามิเตอร์ ได้
- ตัวอย่าง: รูปแบบวันที่, กฎของ ID, หรือช่วงเวลาที่ควรใช้อ็อบเจ็กต์ซ้อนกัน ยังไม่ชัดเจน
- Tool Use Examples เพิ่ม ตัวอย่างอินพุตจริง (input_examples) เข้าไปในคำจำกัดความของเครื่องมือ
- Claude จึงเรียนรู้รูปแบบวันที่ (YYYY-MM-DD), กฎของ ID (USR-XXXXX), และชุดพารามิเตอร์ทางเลือกต่าง ๆ ผ่านตัวอย่าง
- จากการทดสอบภายใน ความแม่นยำในการจัดการพารามิเตอร์ที่ซับซ้อนเพิ่มจาก 72%→90%
- เงื่อนไขที่แนะนำให้ใช้
- เครื่องมือที่มีโครงสร้างซ้อนกันหรือมีพารามิเตอร์ทางเลือกจำนวนมาก
- API ที่มีกฎเฉพาะโดเมนซึ่งอธิบายด้วย Schema ไม่ได้
- กรณีที่ต้องแยกความแตกต่างระหว่างเครื่องมือที่คล้ายกัน
การใช้งานร่วมกันของทั้งสามฟีเจอร์และ best practice
- ฟีเจอร์ทั้งสามทำงานแบบ เสริมกัน
- Tool Search Tool → ค้นหาเครื่องมือที่จำเป็น
- Programmatic Tool Calling → รันได้อย่างมีประสิทธิภาพ
- Tool Use Examples → เรียกใช้งานได้อย่างแม่นยำ
- ลำดับความสำคัญในการใช้งาน
- คอนเท็กซ์ล้น → Tool Search Tool
- ผลลัพธ์ระหว่างทางมากเกินไป → Programmatic Tool Calling
- พารามิเตอร์ผิดพลาด → Tool Use Examples
- เคล็ดลับการตั้งค่า
- เขียนชื่อและคำอธิบายของเครื่องมือให้ชัดเจนเพื่อเพิ่มความแม่นยำในการค้นหา
- เครื่องมือที่ใช้บ่อย 3~5 รายการควรโหลดไว้เสมอ ที่เหลือให้โหลดแบบหน่วงเวลา
- ระบุรูปแบบผลลัพธ์ที่ส่งกลับสำหรับเครื่องมือรันโค้ดให้ชัดเจน
- ข้อมูลตัวอย่างควรสมจริงและกระชับ (1~5 ตัวอย่าง)
เริ่มต้นใช้งาน
- ทั้งสามฟีเจอร์เปิดให้ใช้ในสถานะ เบตา
- ใช้งานได้โดยเพิ่มเฮดเดอร์
betas=["advanced-tool-use-2025-11-20"]
- เครื่องมือที่รวมมา ได้แก่
tool_search_tool_regex_20251119, code_execution_20250825 เป็นต้น
- มีเอกสารทางการและ cookbook บน GitHub สำหรับตัวอย่าง API และคู่มือการนำไปใช้งาน
- ฟีเจอร์เหล่านี้ถูกนำเสนอในฐานะเทคโนโลยีพื้นฐานที่พัฒนาต่อยอดจากการเรียกใช้ฟังก์ชันแบบเรียบง่ายไปสู่ intelligent orchestration
- ถูกเน้นว่าเป็นองค์ประกอบหลักที่ทำให้เกิด การค้นหาแบบไดนามิก การรันอย่างมีประสิทธิภาพ และการเรียกใช้ที่แม่นยำ ในเวิร์กโฟลว์ซับซ้อนและสภาพแวดล้อมข้อมูลขนาดใหญ่
5 ความคิดเห็น
แต่ตอนนี้ดูเหมือนว่ายังเป็นเพราะพลังของตัวโมเดลอยู่ คลาวด์ทำงานได้ดีแบบนี้ก็เพราะเป็นโมเดลที่ Claude ให้บริการอยู่ ส่วนโมเดลอื่น ๆ จะเป็นอย่างไรนั้น...ก็น่าคิดเหมือนกัน
ในบรรดาบริษัทอย่าง Anthropic, Google, OpenAI ผมรู้สึกว่า Anthropic ให้ความรู้สึกว่าใกล้เคียงกับ Agentic AI มากที่สุดนะครับ
ความคิดเห็นจาก Hacker News
กำลังหาวิธีลดการใช้ context ตอนสตรีม tool call หลายตัว
โดยออฟโหลดการประมวลผลบางส่วนไปไว้ที่ตัวทูลเอง ให้มันสรุป markdown ขนาด 200k โทเคนกลับมาเป็นโครงสร้างสรุป แต่แม้วิธีนี้ก็ยังมีกรณีที่ทำให้ context ของโมเดลหลักเต็มอย่างรวดเร็ว
คิดว่า Programmatic Tool Calling เป็นก้าวถัดไปที่เป็นธรรมชาติ
เพราะ LLM กำลังมุ่งไปในทิศทางที่จัดการโค้ดเหมือนภาษา ดังนั้นนิยามของภาษานั้นจึงสำคัญ
แต่คิดว่า tool search เป็นโอเวอร์เฮดที่ไม่จำเป็น เอาทูลที่ต้องใช้ใส่ไว้ใน context ล่วงหน้าจะมีประสิทธิภาพกว่า
สุดท้ายจึงต้องมี tool definition language ที่กระชับเหมือนนิยามฟังก์ชัน และอยากใส่อ็อบเจ็กต์ไว้ใน context ให้มันรับรู้ type และเมธอดที่เรียกใช้ได้
.d.tsก็พอดูแลรักษาและทดสอบก็ง่าย และถ้าจำเป็นก็ import แบบ
export * as Foo from '@foo/foo'ได้LLM ก็เขียนโค้ดเก่งอยู่แล้ว ถ้าให้สิทธิ์เขียน มันก็น่าจะสร้างหรือ import ทูลเองได้
ต่อไปแพลตฟอร์มความร่วมมือ AI↔มนุษย์แบบอินเทอร์แอ็กทีฟอย่าง Jupyter/Pluto/Mathematica น่าจะเหมาะกว่า
ถ้าเพิ่มอินพุตเสียงและทำให้ร่วมงานข้ามเซสชันได้ ก็น่าจะกลายเป็นระบบระดับ Skynet ได้เลย
เอเจนต์ที่ผมทำใช้แค่บางความสามารถของ Python SDK กับฟังก์ชัน custom ก็ทำงานได้เพียงพอแล้ว
โครงสร้าง pseudo-RPC แบบนี้ให้ความรู้สึกเหมือนพิธีกรรมที่ไม่จำเป็น
Smolagents ใช้สิ่งนี้เพื่อจัดการเอาต์พุตของทูลเป็นอ็อบเจ็กต์ (dict)
เลยสงสัยว่าแนวทางนี้ใกล้เคียงกับสิ่งที่ผมพูดหรือไม่
รายละเอียดอยู่ใน บทความบล็อกของ Hugging Face
สงสัยว่าเซิร์ฟเวอร์ MCP จะใส่ตัวอย่างการใช้งานไว้ในนิยามทูลหรือไม่
ถ้าใส่ ก็น่าจะใส่ตัวอย่างโค้ดด้วยเพื่อข้ามขั้นตอนสร้างโค้ดไปได้เลย แต่คงถูกกันไว้เพราะ ปัญหาด้านความปลอดภัย
การรันโค้ดที่บุคคลที่สามให้มานั้นอันตราย จึงเข้าใจการออกแบบแบบนี้
เสียดายที่ใช้ Python เป็นตัวแรปเปอร์
ถ้าใช้ Bash น่าจะมี ความเข้ากันได้ ข้ามภาษาสูงกว่า และเข้ากับเวิร์กโฟลว์ที่ไม่ใช้ Python ได้ด้วย
ความสามารถในการรันทูลภายนอกก็ไม่แพ้ Bash
ทิศทางแบบ “อนาคตที่โมเดลจัดการทูลหลายร้อยถึงหลายพันตัวได้อย่างลื่นไหล” น่าจะผิดทาง
ผมกลับมองว่า ทูลน้อยลง + ความสามารถในการใช้งานที่ดีกว่าเดิม คือทิศทางที่ถูกต้อง
ถ้ามองสุดทาง แค่ ShellTool ตัวเดียวก็อาจพอแล้ว
วิธีที่อุดมคติคือให้โมเดลเรียนรู้ที่จะสร้างและทดสอบทูลเองจนเชื่อถือได้
ecosystem ของคอนเน็กเตอร์เข้าใจง่ายและทำการตลาดง่าย แต่ในระดับพื้นฐานมันดูเป็นกระบวนทัศน์ที่ผิด
คิดว่าน่าจะดีถ้ามี โมเดล orchestration แบบโลคัลขนาดเล็ก
หลายครั้งการประสานเวิร์กโฟลว์ทั้งหมดแบบโปรแกรมนั้นไม่มีประสิทธิภาพ
ถ้าจะลดการปนเปื้อนของ context และเพิ่มความเร็ว โครงสร้างแบบ programmatic > tiny local LLM > frontier LLM น่าจะเหมาะที่สุด
โมเดลเล็กรีเซ็ต context บ่อย ๆ แล้วส่งเฉพาะผลลัพธ์ที่จำเป็นให้โมเดลใหญ่ก็พอ
เวลาใช้ AI assistant มักจะมีรูปแบบงานซ้ำ ๆ
ถ้าลงมือปรับปรุงวิธีที่ไม่มีประสิทธิภาพด้วยตัวเอง อีกไม่กี่เดือนก็จะมีทูลใหม่ออกมาทำให้งานที่ทำไปไร้ความหมาย
คิดว่านี่คือ ราคาของการไล่ตามเทคโนโลยีล่าสุด
สักวันหนึ่งทั้งเว็บน่าจะประกอบด้วยทูลนับพันล้านตัว
Google จะทำดัชนีสิ่งเหล่านี้ และ Gemini จะเลือกใช้แบบไดนามิกเพื่อไปลงมือทำสิ่งต่าง ๆ บนโลก
จริง ๆ แล้วผมคาดหวังอะไรแบบนี้จาก Gemini 3
ฟีเจอร์ #2 ที่พูดถึงตรงนี้ คือการนำแนวคิดที่กำลังเป็นประเด็นล่าสุดอย่าง “ไม่เรียกทูลโดยตรง แต่ เขียนโค้ดเพื่อเรียกมัน” มาทำจริง
มันทำงานใน Python sandbox เข้าถึงได้ผ่าน API และเปิดให้การเรียกทูลดูเหมือนการเรียก API ปกติ
Batch tool calling ช่วยเพิ่มความเร็ว AI assistant ในผลิตภัณฑ์ของเราไปมากแล้ว และฟีเจอร์นี้ก็ดูเหมือนเป็นวิวัฒนาการต่อจากนั้น
agentic builder ของเราใช้ทูลเพียงตัวเดียว — นั่นคือ GraphQL
เอเจนต์จะเขียน query แล้วรันมัน และใช้ introspection เพื่อดึงข้อมูลที่ต้องการ
รับเฉพาะข้อมูลขั้นต่ำเท่านั้น จึง ประหยัดโทเคน ได้
ไม่จำเป็นต้องโหลดทูลเกิน 50 ตัว และยังแก้ปัญหา N+1 ของ REST API ได้ด้วย
ด้วย GraphQL typed schema เอเจนต์จึงเขียนโค้ดได้ดีขึ้น
เมื่อก่อนผมไม่ชอบ GraphQL แต่พอดูสถานะปัจจุบันของ MCP แล้ว ผมคิดว่านี่เป็นหนึ่งในเทคโนโลยีที่เหมาะกับ AI agent มากที่สุด
รายละเอียดสรุปไว้ใน บทความนี้
เอเจนต์ของผมรันแค่ SPARQL query เดียว และสถานะมีอยู่แค่ใน graph DB
ontology ส่วนใหญ่เปิดเผยสาธารณะอยู่แล้ว จึงแทบไม่ต้องทำ schema introspection
ด้วย structured output จึงสามารถบังคับให้สร้างเฉพาะ RDF ที่ถูกต้องได้
คิดว่าใน GraphQL ก็น่าจะทำแบบคล้ายกันได้
ผมต้องทำงานหลายอย่างทั้งเว็บเสิร์ช เรียก local API และเชื่อมกับ Slack ดังนั้น GraphQL ตัวเดียวจึงไม่พอ
แม้จะมีปัญหาเรื่องสิทธิ์ แคช และ mutation แต่ก็แทบไม่กระทบกับ การโหลด context แบบเลือกเฉพาะส่วน
LLM เขียน GraphQL query ที่ตรงกับ schema ได้ค่อนข้างดี
ต่อให้พลาด ถ้าให้ข้อความ error ที่ดี มันก็จะแก้ได้อย่างรวดเร็ว
เหตุผลที่เกี่ยวข้องอยู่ใน บทความบล็อกนี้
ผมก็คิดว่า sonnet 4.5 ดีมากเหมือนกันนะ
แต่ opus 4.5 ดูเหมือนจะดีกว่ายิ่งกว่าอีก ว้าว
เหรอ? ส่วนใหญ่เป็นเรื่องไหนบ้าง?