คุณเพิ่มเซิร์ฟเวอร์เพราะงานหนึ่งต้องใช้ แล้วอีกงานหนึ่ง ไม่นานเอเจนต์เขียนโค้ดก็เริ่มทุกเซสชันโดยแบกแผนที่เครื่องมือที่อาจไม่เคยเรียกใช้ และผลลัพธ์ยาว ๆ ทุกอันก็ถูกยัดเข้าบทสนทนาอยู่ดี
คำตอบสั้น ๆ: การรันโค้ดด้วย MCP ให้เอเจนต์เรียกเครื่องมือจากโค้ดที่สร้างขึ้นมาได้ มันจึงประกอบชุดการเรียกและกรองข้อมูลขั้นกลางก่อนแสดงผลลัพธ์ให้โมเดลเห็น มันเล็งไปที่ต้นทุนโทเคนสองแบบที่ต่างกัน: นิยามเครื่องมือที่โหลดเข้าบริบท และผลลัพธ์เครื่องมือที่ส่งกลับผ่านบริบท วัดแต่ละอย่างก่อนเปลี่ยนการตั้งค่าของคุณ: การค้นหาเครื่องมือเลื่อนนิยามออกไป ขณะที่การรันโค้ดมีประโยชน์ที่สุดเมื่อการเรียกหลายครั้งรวมเข้าด้วยกันได้ หรือผลลัพธ์ขนาดใหญ่ย่อลงได้ก่อนโมเดลเห็น การออกแบบดั้งเดิมของ Anthropic อธิบายแพตเทิร์นนี้ คู่มือนี้วัดมันจากฝั่งของเอเจนต์เขียนโค้ด
การรันโค้ดด้วย MCP เปลี่ยนอะไร?
มันเปลี่ยนวิธีที่เอเจนต์ใช้เครื่องมือ ไม่ใช่ตัวโปรโตคอล MCP เอง ในแพตเทิร์นแบบเรียกตรง ไคลเอนต์แสดงชื่อ คำอธิบาย และสกีมาของเครื่องมือแต่ละตัวให้โมเดลเห็น แล้วคืนผลลัพธ์ให้โมเดลหลังทุกการเรียก การรันโค้ดวางอินเทอร์เฟซโค้ดเล็ก ๆ ไว้หน้าการเรียกเหล่านั้น: โมเดลเขียนสคริปต์ รันไทม์เรียกเครื่องมือ MCP และมีเพียงเอาต์พุตที่เลือกไว้เท่านั้นที่กลับสู่โมเดล
เซิร์ฟเวอร์ MCP คงสภาพเดิมได้ทุกประการ ขณะที่เอเจนต์เปลี่ยนวิธีค้นพบและเรียกเครื่องมือของเซิร์ฟเวอร์ เอเจนต์ยังต้องมีสิทธิ์เข้าถึงเซิร์ฟเวอร์ และรันไทม์โค้ดต้องมีที่ปลอดภัยให้รัน คำอธิบายของ Anthropic ใช้ระบบไฟล์ของตัวห่อ TypeScript ฟีเจอร์ API ใหม่กว่าอย่างการค้นหาเครื่องมือและการเรียกเครื่องมือแบบโปรแกรมให้วิธีอื่นในการเลื่อนเครื่องมือออกไปหรือรันการเรียกเครื่องมือจากโค้ด
ขอบเขตการทำงานคือ: เอเจนต์เขียนโค้ด → โค้ดเรียกเครื่องมือ MCP → แซนด์บ็อกซ์เก็บข้อมูลขั้นกลาง → โมเดลรับเฉพาะค่าที่คืนกลับมา ถ้าไม่มีแซนด์บ็อกซ์ ขั้นการรันโค้ดคือขอบเขตโค้ดที่ไม่น่าเชื่อถือ ไม่ใช่การปรับโทเคนให้เหมาะสมที่เปิดใช้ตามใจชอบ
โทเคน MCP ไปอยู่ที่ไหนในเซสชันของเอเจนต์เขียนโค้ด?
มันลงไปในสองถัง: นิยามเครื่องมือที่ใช้ได้ และผลลัพธ์ที่คืนสู่โมเดล ปัญหาที่สาม การเรียกเก็บเงินซ้ำสำหรับคำนำหน้านิยามที่คงที่ ถูกกระทบโดยแคชพรอมป์แต่ไม่ได้ทำให้คำนำหน้านั้นหายไปจากหน้าต่างบริบท คู่มือบริบทของ Anthropic แยกการควบคุมเหล่านี้ออกจากกันด้วยเหตุผลเดียวกัน
| ถังโทเคน | สิ่งที่ควรนับ | การควบคุมแรกที่ควรลอง |
|---|---|---|
| นิยามที่โหลดก่อนเริ่มงาน | ชื่อ คำอธิบาย และสกีมาอาร์กิวเมนต์ของเครื่องมือที่เอเจนต์มองเห็น | ตัดออกหรือทำ allowlist เครื่องมือ ใช้การโหลดแบบเลื่อนออกไปถ้าส่วนใหญ่แทบไม่จำเป็น |
| ผลลัพธ์ที่คืนระหว่างงาน | เอาต์พุตเครื่องมือ บวกกับข้อมูลขั้นกลางใด ๆ ที่โมเดลต้องส่งเข้าการเรียกอื่น | กรอง แบ่งหน้า หรือสรุปที่ต้นทาง ใช้โค้ดแปลงผลลัพธ์ขั้นกลางขนาดใหญ่ |
| การเรียกเก็บอินพุตซ้ำ | นิยามเครื่องมือที่คงที่และข้อความพรอมป์ที่ถูกส่งซ้ำในคำขอ API ครั้งถัด ๆ ไป | แคชพรอมป์ สิ่งนี้ลดต้นทุนอินพุตซ้ำ ไม่ใช่ขนาดบริบท |
อย่าตีความว่าจำนวนเครื่องมือของเซิร์ฟเวอร์เท่ากับรอยเท้าโทเคนของมัน สกีมายาวเหยียดสิบตัวอาจแพงกว่าตัวเล็กห้าสิบตัว และการเรียก get_document ครั้งเดียวที่คืนทั้งอาร์ไคฟ์อาจแพงกว่านิยามของมันหลายเท่า
จะวัดต้นทุนโทเคน MCP ใน Claude Code และ Codex ได้อย่างไร?
ใช้มุมมองบริบทของไคลเอนต์เพื่ออ่านค่าระดับเซสชัน แล้วแยกเซิร์ฟเวอร์ทีละตัวด้วยการเปรียบเทียบเซสชันใหม่ สำหรับการพรีไฟลต์ API แบบแม่นยำ ให้นับคำขอเดิมครั้งหนึ่งแบบไม่มีเครื่องมือ และอีกครั้งพร้อมอาเรย์ tools ของเซิร์ฟเวอร์
Claude Code: เริ่มเซสชันสะอาด รัน /context และบันทึกส่วนของ MCP/นิยามเครื่องมือก่อนทำงาน รันงานเดิมโดยเชื่อมเซิร์ฟเวอร์ MCP ที่เกี่ยวข้อง แล้วเช็ก /context อีกครั้ง ด้วยการค้นหาเครื่องมือของ Claude Code เวอร์ชันปัจจุบัน เครื่องมือ MCP จะถูกเลื่อนออกไปและค้นพบตามต้องการโดยค่าเริ่มต้นบนการตั้งค่า first-party ที่รองรับ ดังนั้นนิยามอาจปรากฏขึ้นหลังเอเจนต์ค้นหามัน จดค่าทั้งก่อนและหลังทำงาน เอกสารอ้างอิงคำสั่ง บันทึก /context ไว้ และเอกสารอ้างอิง MCP บันทึกพฤติกรรมการค้นหาเครื่องมือโดยค่าเริ่มต้นและข้อยกเว้นของมัน
นี่คือหน้าตาของค่าที่อ่านได้ครั้งแรก ในการทดสอบแบบสะอาดเมื่อวันที่ 4 ตุลาคม 2026 (Claude Code 2.1.289 โปรเจกต์ว่าง เชื่อมห้าเซิร์ฟเวอร์) claude -p "/context" ลิสต์เครื่องมือ MCP ทุกตัวพร้อมขนาดนิยามโดยประมาณก่อนที่งานใดจะรัน:
| เซิร์ฟเวอร์ | เครื่องมือ | โทเคนนิยาม | เครื่องมือที่ใหญ่ที่สุด |
|---|---|---|---|
| Playwright MCP 0.0.83 | 25 | ~6.8k | browser_take_screenshot, 578 |
| Octobrain 0.14.4 | 4 | ~4.2k | memorize, 1.7k |
| Octocode 0.26.4 | 4 | ~3.5k | structural_search, 1.8k |
| Octofs 0.16.0 | 6 | ~3.3k | view, 1.0k |
| เซิร์ฟเวอร์ระบบไฟล์อ้างอิง MCP 2026.8.31 | 14 | ~3.1k | read_text_file, 321 |
โทเคนนิยามทั้งหมด 20.8k ตัวนั้นอยู่ในแถว deferred นอกยอดรวมเริ่มต้น 12.5k ของเซสชัน การรันสองครั้งต่างกัน 1–3% ต่อเซิร์ฟเวอร์ จำนวนเครื่องมือเป็นตัวแทนต้นทุนที่แย่ในที่นี้: เครื่องมือสั้น ๆ 14 ตัวของเซิร์ฟเวอร์ระบบไฟล์อ้างอิงถูกกว่า 6 ตัวของ Octofs และคำอธิบายยาว ๆ หนึ่งอันอาจหนักกว่าคำอธิบายสั้น ๆ เป็นโหล
สำหรับการตั้งค่าไคลเอนต์เอง ใช้คู่มือ MCP สำหรับ Claude Code และ Codexของเรา ขั้นตอนการวัดนี้สมมติว่าเซิร์ฟเวอร์เชื่อมต่ออยู่แล้ว
Codex: ในเธรดใหม่ บันทึก /status และ /mcp รันงานที่เป็นตัวแทน แล้วเปรียบเทียบ /status หลังเริ่มเธรดใหม่โดยปิดเซิร์ฟเวอร์เดิมหรือหดลิสต์เครื่องมือของมัน เปลี่ยนทีละเซิร์ฟเวอร์
Codex บันทึกการใช้บริบทของเซสชันไว้ใน /status และเซิร์ฟเวอร์ที่เชื่อมต่อไว้ใน /mcp สถานะที่บันทึกไว้เป็นตัวเลขทั้งเซสชันและไม่ได้แยกโทเคนสกีมาให้แต่ละเซิร์ฟเวอร์ ถือว่าผลต่างระหว่างการรันแบบควบคุมเป็นค่าประมาณ เพราะคำสั่งของโปรเจกต์ ประวัติพรอมป์ และเครื่องมืออื่นก็ครองบริบทด้วย เอกสารอ้างอิงปัจจุบันของ Codex ลิสต์คำสั่งเหล่านั้นไว้
สำหรับคำขอ Messages API ใช้เอนด์พอยต์ POST /v1/messages/count_tokens ของ Anthropic พร้อมอาเรย์ tools และซิสเทมพรอมป์จริงของคุณ นับหนึ่งครั้งพร้อมเครื่องมือ และอีกครั้งด้วยคำขอเดิมที่ตัดเครื่องมือเหล่านั้นออก ลบยอดรวมเพื่อประมาณโอเวอร์เฮดของนิยาม
เอนด์พอยต์คืนจำนวนโทเคนของข้อความ ซิสเทมพรอมป์ และเครื่องมือรวมกัน และไม่สร้างการตอบกลับของโมเดล เพื่อวัดต้นทุนผลลัพธ์ด้วย ให้ทำซ้ำการนับโดยใส่เนื้อหา tool_result ที่เป็นตัวแทนลงไป นี่คือการนับแบบพรีไฟลต์ เปรียบเทียบมันกับการใช้งานจริงของการตอบกลับเมื่อจูนเวิร์กโฟลว์จริง เอกสารอ้างอิงการนับโทเคนของ Anthropic ให้นิยามคำขอและฟิลด์ input_tokens ที่คืนกลับมา
จดตัวเลขสี่ตัว: บริบทเริ่มต้นก่อนใช้ MCP บริบทหลังทำงาน นิยามที่โหลด และโทเคนผลลัพธ์ที่คืนมา ทำซ้ำกับงานเดิมทีละเซิร์ฟเวอร์ นั่นให้เส้นฐานที่คุณเช็กได้หลังเปลี่ยนเครื่องมือ
Anthropic ปล่อยการค้นหาเครื่องมือออกมาแล้วหรือยังนับจากบทความ MCP ปี 2025?
ปล่อยแล้ว ณ วันที่ 4 ตุลาคม 2026 Anthropic บันทึกการโหลดเครื่องมือแบบเลื่อนออกไปใน Messages API และระบุว่า Claude Code เปิดการค้นหาเครื่องมือ MCP โดยค่าเริ่มต้นบนการตั้งค่า first-party ที่รองรับ เวอร์ชัน API ต้องใช้เครื่องมือค้นหาเครื่องมือและทำเครื่องหมายนิยามที่เข้าเกณฑ์ด้วย defer_loading Claude Code จัดการเส้นทางนั้นให้เซิร์ฟเวอร์ MCP ที่เชื่อมต่อ คู่มือ API อธิบายรูปทรงคำขอ ขณะที่เอกสาร MCP ปัจจุบันของ Claude Code อธิบายว่าเมื่อไรมันถอยกลับไปโหลดเครื่องมือตั้งแต่ต้น
นั่นเป็นการอัปเดตที่มีความหมายต่อโพสต์เก่า แต่การค้นหาเครื่องมือไม่ได้ลบนิยามเครื่องมือทุกตัวออกจากคำขอ: API ยังรับนิยามที่ถูกเลื่อนออกไปเพื่อจะได้ค้นหาและขยายมันเมื่อจำเป็น มันกันนิยามส่วนใหญ่ khỏiบริบทเริ่มต้นของโมเดลและแลกพื้นที่นั้นกับขั้นค้นพบที่เพิ่มมา คู่มือการค้นหาเครื่องมือของ Anthropic ระบุว่าการเรียกเครื่องมือแบบธรรมดาก็เหมาะกว่าเมื่อมีเครื่องมือน้อยกว่า 10 ตัว เมื่อคุณใช้ทุกเครื่องมือในทุกคำขอ หรือเมื่อนิยามทั้งหมดรวมกันต่ำกว่า 100 โทเคน ภาพรวมบริบทเครื่องมือของมันวางการค้นหาเครื่องมือไว้ที่ชุด 20 ตัวขึ้นไป ระหว่างสองหมุดนั้น วัดก่อนเปลี่ยน
OpenAI เปิดเส้นทาง tool_search ที่คล้ายกันใน Responses API คู่มือปัจจุบันระบุว่ารองรับบน gpt-5.4 ขึ้นไปและใช้ defer_loading: true บนนิยามเครื่องมือ MCP นั่นคือฟีเจอร์ API ใน Codex CLI ใช้ /status เพื่อตรวจบริบทเซสชันโดยรวม และหดเครื่องมือเซิร์ฟเวอร์ที่เปิดเผยด้วยการตั้งค่า MCP ของมัน คู่มือการค้นหาเครื่องมือของ OpenAI อธิบายฟีเจอร์ API เอกสารอ้างอิงการตั้งค่า Codex ลิสต์ enabled_tools ไว้
ควรเลือกอะไร: การเรียก MCP ตรง ๆ การค้นหาเครื่องมือ หรือการรันโค้ด?
เลือกตามจุดที่การวัดของคุณเจอต้นทุน และระดับการควบคุมที่คุณต้องการต่อการกระทำแต่ละอย่าง แนวทางเหล่านี้ยังรวมกันได้: การค้นหาช่วยกันสกีมาที่แทบไม่ใช้ออกจากบริบท และโค้ดช่วยกรองผลลัพธ์ของเวิร์กโฟลว์หลายการเรียก
| เลือก | เมื่อไหร่ที่เหมาะ | ข้อแลกเปลี่ยนที่ต้องวางแผนรับ |
|---|---|---|
| การเรียกตรง ๆ | ชุดเครื่องมือเล็กและเสถียรถูกใช้ในแทบทุกงาน หรือมนุษย์ควรตรวจทานการกระทำแต่ละครั้ง | นิยามพร้อมใช้เสมอ เอาต์พุตขนาดใหญ่และการไปกลับทีละการเรียกยังใช้บริบท |
| การค้นหาเครื่องมือ / การโหลดแบบเลื่อนออกไป | แคตตาล็อกใหญ่แต่แต่ละงานใช้เครื่องมือเพียงไม่กี่ตัว | มีขั้นค้นพบหนึ่งขั้น API ยังรับนิยามไว้สำหรับค้นหา |
| การรันโค้ด | งานหนึ่งต่อเครื่องมือหลายตัว วนลูปเหนือเรคคอร์ด หรือคืนสรุปย่อแทนข้อมูลขั้นกลางดิบได้ | ต้องมีสภาพแวดล้อมรันโค้ดพร้อมแซนด์บ็อกซ์ ขีดจำกัด และการมอนิเตอร์ โค้ดเรียกเครื่องมือหลายครั้งในการรันเดียวได้ |
กฎง่าย ๆ: ถ้าส่วน MCP ในเส้นฐานใหญ่ ลองการโหลดแบบเลื่อนออกไปก่อน ถ้าเส้นฐานเล็กแต่ผลลัพธ์งานครองส่วนใหญ่ ให้หดหรือสรุปเอาต์พุต ถ้าเวิร์กโฟลว์คัดลอกผลลัพธ์ขนาดใหญ่จากเครื่องมือหนึ่งไปอีกตัวหนึ่ง ให้ทำต้นแบบเส้นทางโค้ดและเปรียบเทียบกับงานจริง — ไม่ใช่แค่นับจำนวนสกีมา เก็บการเรียกตรง ๆ ไว้สำหรับการกระทำที่ต้องมีการตัดสินใจหรืออนุมัติของมนุษย์แยกต่างหาก
ตัวเลขต้นทางมีประโยชน์ในฐานะตัวอย่าง ไม่ใช่คำพยากรณ์ โพสต์วิศวกรรมปี 2025 ของ Anthropic รายงานการลดจาก 150,000 เหลือ 2,000 โทเคน (98.7%) ในตัวอย่างการออกแบบของมัน โพสต์เดือนกุมภาพันธ์ 2026 ของ Cloudflare รายงานราว 1,000 โทเคนสำหรับ Cloudflare API Code Mode สองเครื่องมือของมัน เทียบกับ 1.17 ล้านสำหรับชุดเครื่องมือเนทีฟที่เทียบเท่า Cloudflare ระบุว่าการเปรียบเทียบนั้นใช้ tiktoken เหล่านั้นคือผลลัพธ์ที่แต่ละเวนเดอร์รายงานเอง และเซิร์ฟเวอร์ สกีมา รันไทม์ และรูปทรงงานก็ต่างกัน โพสต์ของ Anthropic และโพสต์ของ Cloudflare ไม่ได้กำหนดค่าประหยัดที่คาดหวังได้สำหรับการตั้งค่าของคุณ
เบนช์มาร์กแยกต่างหากของ AIMultiple อัปเดตสิงหาคม 2026 รายงานโทเคนอินพุตน้อยลง 78.5% และค่าเฉลี่ยความหน่วงสูงขึ้น 7% ในการทดสอบ Bright Data MCP / GPT-4.1 ของมัน โทเคนเอาต์พุตเพิ่มขึ้นในเบนช์มาร์กนั้น นี่เป็นเครื่องเตือนให้ติดตามอินพุต เอาต์พุต ความหน่วง และความสำเร็จของงานแยกกัน "โทเคนที่น้อยลง" อย่างเดียวไม่ใช่ผลลัพธ์ที่สมบูรณ์
จะจำกัดเพดานเอาต์พุตเครื่องมือโดยไม่ซ่อนข้อมูลที่มีประโยชน์ได้อย่างไร?
จำกัดเอาต์พุตที่ชั้นที่รู้ว่างานต้องการอะไร เซิร์ฟเวอร์แบ่งหน้าหรือคืนข้อความบางส่วนได้ ไคลเอนต์ MCP จำกัดผลลัพธ์เครื่องมือรายตัวได้ โมเดลสั่งให้โค้ดเลือกฟิลด์และรวมแถวได้ก่อนพิมพ์ผลลัพธ์
Claude Code เตือนเมื่อเครื่องมือ MCP คืนมากกว่า 10,000 โทเคน และมีค่าสูงสุดเริ่มต้น 25,000 โทเคนในกรณีที่เครื่องมือไม่ได้ประกาศขีดจำกัดขนาดผลลัพธ์ของตัวเอง Codex เปิด output_token_limit รายเครื่องมือและ tool_output_token_limit แบบทั่วไปสำหรับเอาต์พุตที่เก็บในประวัติ ขีดจำกัดเหล่านี้กำหนดขอบเขตสิ่งที่ไปถึงบริบทบทสนทนา มันไม่ได้ทำให้สกีมาเครื่องมือที่กว้างเล็กลง ดูการควบคุมเอาต์พุต MCP ของ Claude Code และเอกสารอ้างอิงการตั้งค่าของ Codex
ตัวอย่าง TOML ของ Codex พร้อมชุดเครื่องมือเปิดเผยขนาดเล็กและงบเอาต์พุตรายเครื่องมือ เพื่อยืนยันว่า allow-list มีผล codex mcp get <server> --json จะพิมพ์ enabled_tools ที่ resolve แล้ว (เช็กบน Codex CLI 0.160.0) มันยังพิมพ์ตัวแปรสภาพแวดล้อมของเซิร์ฟเวอร์แบบไม่ปิดบังด้วย ดังนั้นเก็บเอาต์พุตนั้นออกจากตั๋วงานและล็อกแชต:
[mcp_servers.example]
enabled_tools = ["search", "read"]
[mcp_servers.example.tools.read]
output_token_limit = 2000
ขีดจำกัดที่ตั้งค่าคืองบประมาณ ไม่ใช่เพดานแข็งและไม่ใช่เป้า: Codex ใช้ output_token_limit ก่อนค่าเผื่อ serialization มาตรฐาน 20% ดังนั้นผลลัพธ์ที่เก็บไว้อาจเกินมันไปบ้าง รักษาโครงสร้างผลลัพธ์ให้มีประโยชน์: ขอเฉพาะฟิลด์ที่จำเป็น แบ่งหน้าเรคคอร์ด และคืนจำนวนนับหรือแถวตัวแทนไม่กี่แถวเมื่อไม่ต้องการข้อมูลเต็ม คู่มือ MCP ของ OpenAI ยังรองรับฟิลเตอร์ allowed_tools ของ Responses API ด้วย
การรันโค้ดเปลี่ยนอะไรเรื่องความปลอดภัยและการอนุมัติ?
มันย้ายงานบางส่วนจากการเรียกเครื่องมือที่มองเห็นได้ทีละครั้ง ไปเป็นโปรแกรมที่โมเดลเขียนและรันไทม์รัน นั่นกันข้อมูลขั้นกลางที่เป็นส่วนตัวออกจากบริบทของโมเดลได้ แต่ก็หมายความว่าสภาพแวดล้อมโค้ดเป็นส่วนหนึ่งของขอบเขตความปลอดภัยของคุณด้วย
API ของ Anthropic ตอนนี้มีโปรแกรมเมติกทูลคอลลิงในแซนด์บ็อกซ์แบบจัดการให้ สำหรับการอิมพลิเมนต์เอง Anthropic เตือนว่าการรันฝั่งไคลเอนต์รันโค้ดที่ไม่น่าเชื่อถือนอกแซนด์บ็อกซ์และอาจเป็นช่องทาง code injection การทำแซนด์บ็อกซ์เองเพิ่มการแยกส่วนแต่ต้องลงแรงด้านโครงสร้างพื้นฐาน Code Mode บนฐาน Worker ของ Cloudflare สำหรับ MCP ปฏิเสธการเข้าถึงเครือข่ายทั่วไปโดยค่าเริ่มต้นและเปิดบริการเฉพาะอย่างเป็น bindings ตัวอย่างเหล่านี้แสดงสองแพตเทิร์น: แยกการรันโค้ดออก และให้ขีดความสามารถขอบเขตแคบแก่มัน ดูคู่มือโปรแกรมเมติกทูลคอลลิงของ Anthropic และการออกแบบ Code Mode ดั้งเดิมของ Cloudflare
อย่าส่งการเขียนที่ย้อนกลับไม่ได้ผ่านเครื่องมือโค้ดกว้าง ๆ เพียงเพื่อประหยัดหนึ่งเทิร์นของโมเดล เก็บสิทธิ์เขียนให้แคบ รักษาขอบเขตการยืนยันที่มนุษย์ต้องอนุมัติการกระทำ และบันทึกว่าโค้ดเรียกเครื่องมือพื้นฐานตัวไหนบ้าง ถ้าออดิตหรือทำแซนด์บ็อกซ์เส้นทางโค้ดไม่ได้ การเรียกตรง ๆ พร้อมการอนุมัติให้เหตุผลได้ง่ายกว่า
หน้าตาเป็นอย่างไรสำหรับพื้นผิวเครื่องมือ MCP ขนาดเล็ก?
พื้นผิวขนาดเล็กยังได้ประโยชน์จากการจัดรูปเอาต์พุต แต่อาจไม่ต้องการการรันโค้ด เราสร้าง octofs เซิร์ฟเวอร์ MCP ระบบไฟล์ที่มีหกเครื่องมือ ในนั้นมี view และ batch_edit โดย batch_edit ใช้การแก้ไขที่ไม่ซ้อนทับกันสูงสุด 50 รายการกับไฟล์เดียวในหนึ่งการเรียกและคืน line id ใหม่ เอเจนต์จึงไม่ต้องอ่านไฟล์ซ้ำ Octocode เซิร์ฟเวอร์ค้นหาโค้ดของเรา เปิดสี่เครื่องมือโดยค่าเริ่มต้น (การค้นหาเชิงความหมาย การค้นหาเชิงโครงสร้าง มุมมองลายเซ็น และกราฟโค้ด) และเพิ่มหกเครื่องมือ LSP เฉพาะเมื่อคุณตั้งค่า language server Octobrain เซิร์ฟเวอร์หน่วยความจำของเรา มีสี่ตัว ในการวัดข้างบนพวกมันอยู่ที่ราว 3.3k, 3.5k และ 4.2k โทเคนนิยาม: ต่อเครื่องมือมากกว่าเซิร์ฟเวอร์ระบบไฟล์อ้างอิง และทั้งหมดถูกเลื่อนออกไปจนกว่างานจะต้องการ สำหรับขอบเขตความปลอดภัยที่กว้างขึ้นเมื่อให้เอเจนต์เข้าถึงระบบไฟล์ ดูคู่มือความปลอดภัยระบบไฟล์ของเรา
การวัดเป็นตัวตัดสินก้าวถัดไป ถ้านิยามครองส่วนใหญ่ เปิดเครื่องมือน้อยลงหรือเลื่อนมันออกไป ถ้าเอาต์พุตครองส่วนใหญ่ กรองมันให้ใกล้เซิร์ฟเวอร์ขึ้น ถ้าข้อมูลขั้นกลางครองส่วนใหญ่ตลอดทั้งเชน ทำต้นแบบการรันโค้ดหลังแซนด์บ็อกซ์และเปรียบเทียบกับงานเดิมภายใต้การเรียกตรง ๆ
— Don
ลองการวัดนี้กับงานที่เกิดซ้ำหนึ่งงาน และเก็บตัวเลขก่อน-หลังไว้ข้างการตั้งค่าเซิร์ฟเวอร์ของคุณ Octofs และ Octocode เป็นโอเพนซอร์ส ถ้าพื้นผิวเครื่องมือของมันกินบริบทมากกว่าที่ควรในการตั้งค่าของคุณ เปิด issue พร้อมตัวเลขของคุณ
