# Parallel Tool Call เปลี่ยนความน่าเชื่อถือของ Coding Agent อย่างไร? > Parallel tool call ลด latency สำหรับ read ที่เป็นอิสระ แต่ลด reliability เมื่อ call ใช้ state ร่วมกัน พึ่งลำดับ หรือเขียนข้อมูล ใช้ dependency graph, resource lock, idempotency key และการ merge result แบบ deterministic Parallel tool call เป็น scheduling proposal ไม่ใช่สิทธิ์เริ่มทุกอย่างพร้อมกัน Repository search สองงานมัก overlap ได้ File edit กับ formatter อาจไม่ได้ และ dependency install กับ test run ไม่ควรเริ่มจาก pre-install state เดียวกัน Reliability เพิ่มเมื่อ concurrency ทำตาม resource และ dependency model แต่ลดเมื่อ executor มอง array ของ call เป็นหลักฐานว่า independent ## Classify call ตาม effect กำหนด behavior ให้แต่ละ tool ใน registry เพื่อให้ scheduler enforce ได้ | Effect class | ตัวอย่าง | Default policy | |---|---|---| | Pure read | อ่าน source file สองไฟล์ | Parallel allowed | | External read | Query API สองตัว | Parallel พร้อม limit | | Local write | Edit file | Serial ตาม resource | | Global write | Install dependency | Serial ทั้งหมด | | Irreversible action | Publish หรือ send | ต้องมี explicit gate | อย่าพึ่งชื่อ tool อย่างเดียว Command `inspect` อาจสร้าง cache และ test อาจเขียน snapshot หรือ database บันทึก side effect ใน registry ## สร้าง dependency graph ก่อน execute แทน call เป็น node และ required order เป็น edge Call เริ่มได้เมื่อ predecessor สำเร็จและ resource พร้อม ```text read_config ----+ +--> build --> test read_source ----+ search_docs ---------> summarize ``` Read สองงานแรกทำพร้อมกันได้ Build รอทั้งคู่ และ test รอ build Documentation search overlap กับ repository branch ได้หากไม่กระทบ build input เมื่อ model ไม่ให้ dependency ให้ infer อย่างระมัดระวังจาก tool metadata และ argument Write ที่กำกวมควรรัน serial ## Lock resource ไม่ใช่ agent ทั้งตัว Global single-call lock เชื่อถือได้แต่ช้า Resource-level lock รักษา safe concurrency Normalize path ก่อนเปรียบเทียบ การ edit `src/a.ts` conflict กับการ format `src` และการสร้าง lockfile conflict กับ package operation อื่น รวม database, browser session, terminal และ remote record ใน resource model | Resource | Lock scope | |---|---| | Source file | Canonical path | | Directory formatter | Directory subtree | | Package manager | Workspace และ lockfile | | Browser session | Tab หรือ authenticated workflow | | Deployment | Environment และ service | ## รักษา call identity ตลอด stream หลาย call อาจส่ง argument fragment สลับกัน Buffer ตาม call ID และ execute หลังแต่ละ call ได้ completion event เท่านั้น อย่าใช้ตำแหน่ง output เป็น identity ถาวร ส่ง result กลับด้วย opaque call ID เดิม แสดงผลตามลำดับ deterministic เช่น original call order แม้ completion order ต่างกัน Atlas Cloud ส่งต่อ `tools`, `tool_choice` และ `parallel_tool_calls` สำหรับ model ที่ประกาศ tool capability บน OpenAI Chat Completions ตรวจ model และ protocol ใน [คู่มือ LLM protocol](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=how-parallel-tool-calls-change-coding-agent-reliability) แทนการสมมติว่าทุก route รองรับ parallel call ## กำหนด partial-failure policy ใน parallel batch หนึ่ง call อาจเสร็จ หนึ่ง call validation fail และอีกหนึ่งยังรัน เลือก policy ตาม effect: * เก็บ successful independent read และรายงาน failed read * Cancel pending dependent หลัง prerequisite fail * อย่า retry completed write โดยไม่มี idempotency key * ใช้ compensation เมื่อ tool รองรับชัดเจนเท่านั้น * ส่ง structured batch result ให้ model Retry ควร target failed node ไม่ใช่ replay batch ทั้งหมด ## จำกัด concurrency และใช้ backpressure แม้แต่ independent call ก็ overload filesystem, API, test runner หรือ rate limit ได้ ตั้ง per-tool และ per-resource limit ใส่งานเกินใน queue และรองรับ cancellation วัด slowest call, queue time, retry count, duplicate suppression และ final task success เวลาที่สั้นลงมีค่าก็ต่อเมื่อ output ยังถูก ## ทดสอบ schedule ไม่ใช่แค่ output Race bug อาจหายไปใน completion order หนึ่ง รัน fixture เดิมพร้อม delay ที่บังคับ schedule ต่างกัน | Test | Forced order | Expected result | |---|---|---| | Read สองงาน | A แล้ว B, B แล้ว A | Merged evidence เหมือนกัน | | Read plus write | Write รอ | Read เห็น version ที่กำหนด | | Write file เดียวกันสองครั้ง | Proposal order ใดก็ได้ | Serialized plan เดียว | | Failure plus slow call | Failure ก่อน | Dependent call cancelled | | Disconnect หลัง write | Response lost | Write ไม่ duplicate | ใช้ fake executor ให้ CI reproduce schedule โดยไม่พึ่งโชคของ timing ## ตัดสินว่าเมื่อใด serial ดีกว่า Serial execution เหมาะกับ migration, package install, shared-file edit, publish step และ operation ที่ rollback ไม่ชัด Parallelism เหมาะกับ repository discovery, independent documentation read, isolated lint check และ disjoint test shard โมเดลใน [Atlas Cloud LLM catalog](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=how-parallel-tool-calls-change-coding-agent-reliability) อาจเสนอหลาย call แต่ executor ยังรับผิดชอบตัดสินว่าอะไรทำพร้อมกันได้จริง ## สรุป Parallel call ทำให้ coding agent เร็วเมื่อทำงาน independent และ read-heavy แต่ลด reliability เมื่อมองข้าม side effect, hidden resource หรือลำดับ Classify tool สร้าง dependency graph lock shared resource รักษา call ID retry เฉพาะ idempotent node และทดสอบหลาย schedule ให้ executor enforce ความปลอดภัยแม้ model เสนอ concurrency ## FAQ ### Tool call แบบใดปลอดภัยสำหรับรัน parallel? Independent read-only call บนคนละ resource ปลอดภัยที่สุด ตรวจว่าไม่เปลี่ยน cache, temporary file หรือ shared session ### ควรรัน file edit แบบ parallel หรือไม่? เฉพาะเมื่อ ownership แยกกันและ merge deterministic การรัน serial ปลอดภัยกว่าสำหรับ file เดียว generated artefact, lockfile หรือ shared build state ### จะเกิดอะไรขึ้นหาก parallel call หนึ่งล้มเหลว? Orchestrator ต้องมี policy ชัดเจน เช่น cancel dependent, เก็บ successful read, compensate write หรือ retry เฉพาะ idempotent call ### ควรส่ง result กลับให้ model อย่างไร? รักษา call ID ของแต่ละ call และ merge result ตามลำดับ deterministic พร้อมสถานะ success, error และ cancellation ที่ชัดเจน ### Parallel call ทำให้ agent ถูกลงได้หรือไม่? อาจลดเวลา แต่เพิ่ม token, งานซ้ำ หรือ retry ได้ วัด completed-task cost และ correctness แยกจาก latency ### ทุก model รองรับ parallel tool call หรือไม่? ไม่ ตรวจ selected model และ protocol บาง route รองรับ tool แต่ไม่รองรับหลาย call ใน turn เดียว