ไม่มีใครไว้ใจเพื่อนร่วมทีมคนใหม่เพราะเรซูมู่ของเขา ความไว้วางใจมาจากโครงสร้างต่างหาก นั่นคือ ขอบเขตความรับผิดชอบที่ชัดเจน งานที่ทำในที่ที่ทีมมองเห็นได้ และการรีวิวก่อนที่อะไรจะถูกส่งออกไป ถ้าตัดสิ่งใดสิ่งหนึ่งออกไป ต่อให้เป็นเพื่อนร่วมงานที่เก่งแค่ไหนก็กลายเป็นความเสี่ยงได้ หลักการเดียวกันนี้ใช้กับ AI agent ในฐานะเพื่อนร่วมทีมเช่นกัน คำถามไม่เคยใช่ "โมเดลฉลาดพอไหม" แต่คือ "ฉันรู้ไหมว่าสิ่งนี้ได้รับอนุญาตให้แตะต้องอะไรได้บ้าง ฉันเห็นได้ไหมว่ามันทำอะไรไป และมีอะไรถูกปล่อยออกไปโดยไม่มีคนกดอนุมัติหรือไม่"
Sharkly ตอบคำถามเหล่านั้นด้วยการตั้งค่า ไม่ใช่คำสัญญา Agent ใน Sharkly คือชุดการตั้งค่าการทำงานที่บันทึกไว้ ไม่ใช่พรอมป์ต์แบบใช้ครั้งเดียวทิ้ง คำสั่งการทำงาน Runtime, Skills, repository, environment และการตั้งค่าการรันของมัน ล้วนกำหนดว่ามันจัดการงานอย่างไร พรอมป์ต์หายไปเมื่อปิดเทอร์มินัล แต่การตั้งค่าเปิดให้ตรวจสอบได้ แชร์ได้ และคงที่ในทุกรอบการรัน
ถ้าคุณอยากดูภาพรวมแพลตฟอร์มก่อน เริ่มจาก Sharkly คืออะไร แล้วค่อยกลับมาอ่านต่อ
สรุปสั้น ๆ
Agent ใน Sharkly คือชุดการตั้งค่าการทำงานที่บันทึกไว้และนำกลับมาใช้ซ้ำได้สำหรับผู้ปฏิบัติงาน AI ประกอบด้วยคำสั่งการทำงาน การผูกกับ Computer และ Runtime, Skills ที่แนบไว้, Git repository, ตัวแปร environment และการตั้งค่าการรัน เช่น จำนวนงานที่รันพร้อมกัน ไทม์เอาต์ และโหมด working directory คุณไว้ใจมันแบบเดียวกับที่ไว้ใจเพื่อนร่วมทีม คืออาศัยโครงสร้างไม่ใช่ความศรัทธา ขอบเขตของมันระบุไว้ชัดเจนในการตั้งค่า สถานะการทำงานและ trace ของมันมองเห็นได้ และผลลัพธ์ของมันกลับมาที่ Task ซึ่งมีคนคอยรีวิวและยอมรับ Agent ค้นคว้า ลงมือทำ ทดสอบ และรายงาน ส่วนคนเป็นผู้กำหนดทิศทาง มอบอำนาจ และยอมรับผลลัพธ์
Agent คืออะไร (และไม่ใช่อะไร)
Agent คือผู้ปฏิบัติงาน AI ที่ตั้งค่าไว้ให้จัดการงานใน Sharkly มันสามารถรับ Task ที่ได้รับมอบหมาย เขียนคอมเมนต์ อัปเดตสถานะ Task ผ่านเวิร์กโฟลว์ที่มีอยู่ และสร้าง trace การทำงานได้ เพราะการตั้งค่าถูกบันทึกไว้ ทีมจึงดูแล Agent แยกกันสำหรับการแก้โค้ด การรีวิว การทดสอบ เอกสาร หรือการคัดกรองงานปฏิบัติการได้ โดยไม่ต้องเขียนคำสั่งเดิมซ้ำสำหรับทุก Task
มีสองขอบเขตที่ต้องเข้าใจตั้งแต่แรก
Agent ไม่ใช่โฮสต์ที่ใช้รันงาน งานของมันรันผ่าน Runtime ที่เลือกไว้บน Computer ที่เชื่อมต่ออยู่ Agent กำหนดว่าควรจัดการงานอย่างไร Computer เป็นผู้จัดหาโฮสต์ Runtime เป็นผู้ดำเนินเซสชันจริง และ Task ยังคงเป็นบันทึกที่แชร์ร่วมกัน แต่ละบทบาทมีหน้าที่เดียว ซึ่งเป็นเหตุผลว่าทำไม Computer เครื่องเดียวจึงให้บริการ Agent ได้หลายตัว
Agent ไม่ได้เลือกโมเดลด้วยตัวเอง มันใช้โมเดลเริ่มต้นของ Runtime โดยไม่มีตัวเลือกโมเดลหรือการควบคุมระดับความลึกในการคิดบนตัว Agent ถ้าต้องการใช้โมเดลอื่น ให้เปลี่ยนในการตั้งค่าเครื่องมือของ Runtime หรือ Computer เช่นใน Claude Code หรือ Codex เอง
ความไว้วางใจเป็นคุณสมบัติของระบบ ไม่ใช่ของโมเดล
นี่คือแก่นที่บทความนี้ตั้งอยู่บน: agent จะน่าเชื่อถือก็ต่อเมื่องานของมันมีขอบเขตชัดเจน มองเห็นได้ และรีวิวได้ ไม่ใช่เพราะโมเดลน่าประทับใจ
มีขอบเขต หมายความว่าอำนาจของ Agent ถูกเขียนระบุไว้ก่อนที่มันจะรัน: มันแตะต้อง repository ใดได้บ้าง รันบน Computer เครื่องไหน คำสั่งของมันอนุญาตอะไรได้บ้าง รัน Task พร้อมกันได้กี่งาน และหนึ่งรอบการรันนานได้แค่ไหน มองเห็นได้ หมายความว่าสถานะการรัน เหตุการณ์ใน trace และผลลัพธ์จะกลับมาที่ Task ซึ่งใครก็ตรวจสอบได้ แทนที่จะหายไปในเทอร์มินัลส่วนตัว และรีวิวได้ หมายความว่ามีคนอยู่ที่ปลายวงจร: Agent สามารถทิ้ง Task ให้รอการตอบกลับจากคน หรือรอการรีวิวจากคนได้ และสัญญาณเหล่านั้นจะไปถึง Inbox ของผู้รับผิดชอบ
นั่นคือสัญญาระหว่างคนกับ agent ในทางปฏิบัติ ระบบอัตโนมัติจะหยุดตรงจุดที่ต้องใช้วิจารณญาณของทีม ถ้าคุณยังชั่งน้ำหนักเรื่องเวิร์กโฟลว์อยู่ บทความปูพื้นฐานเกี่ยวกับ agentic coding ของเราครอบคลุมการเปลี่ยนแปลงจากการพรอมป์ต์ไปสู่การมอบหมายงาน
ขอบเขตการตั้งค่าของ Agent
Agent หนึ่งตัวประกอบด้วยชื่อ คำอธิบาย รูปโปรไฟล์ และเจ้าของ; คำสั่งการทำงาน; การตั้งค่าการมองเห็นและตำแหน่งใน Space; การเชื่อมต่อ Computer และผู้ให้บริการ Runtime; Skills ที่มอบหมาย; Git repository เฉพาะของ Agent; ตัวแปร environment แบบธรรมดาและแบบความลับ; อาร์กิวเมนต์เพิ่มเติมของ Runtime; การตั้งค่า Task Working Directory; และจำนวนสูงสุดของ Task ที่รันพร้อมกัน พร้อมไทม์เอาต์ต่อ Task แต่ละส่วนล้วนเป็นคันโยกของความไว้วางใจ
คำสั่ง (Instructions) จะถูกใส่ไปในทุกรอบการรัน ใช้สำหรับพฤติกรรมที่ควรคงอยู่กับทุก Task: ขอบเขตและบทบาท วิธีตรวจสอบ Task ก่อนลงมือ เมื่อใดควรขอความเห็นจากคน การตรวจสอบที่คาดหวัง และรูปแบบการรายงาน เอกสารได้วางเส้นแบ่งสามทางที่มีประโยชน์ไว้: ข้อกำหนดเฉพาะของ Task ไปอยู่ในคำอธิบาย Task หรือคอมเมนต์ ขั้นตอนที่นำกลับมาใช้ซ้ำได้และ Agent หลายตัวอาจแชร์กัน ไปอยู่ใน Skill ส่วนคำสั่งของ Agent เองถืออัตลักษณ์ที่มั่นคงของมัน ประโยคอย่าง "อ่านคำอธิบาย Task และคอมเมนต์ล่าสุดก่อนแก้ไข จำกัดการเปลี่ยนแปลงไว้ที่พฤติกรรมที่ขอไว้ รันการตรวจสอบที่เกี่ยวข้องใกล้ที่สุด แล้วรายงานความล้มเหลวโดยไม่ปกปิด" ควรอยู่ใน Agent เพราะมันควรเป็นจริงทั้งวันจันทร์และยังจริงในเดือนมีนาคม คำอธิบายมีผู้อ่านอีกกลุ่มหนึ่ง: มันบอกคนว่าควรมอบหมายอะไร ส่วนคำสั่งบอก Agent ว่าต้องทำงานอย่างไร
การมองเห็น (Visibility) มีสองแบบ คือ Personal ซึ่งเปิดให้เฉพาะเจ้าของปัจจุบัน หรือ Space ซึ่งเปิดให้คนที่เข้าถึง Space ของ Agent ได้ นอกจากนี้ยังควบคุมว่าใครสามารถมอบหมายงานให้ Agent เริ่ม Agent Chat กับมัน หรือกระตุ้นมันผ่านคอมเมนต์หรือการ mention ได้ เริ่มจาก Personal ระหว่างปรับแต่ง แล้วเลื่อนเป็น Space เมื่อการตั้งค่าคุ้มค่าพอที่จะแชร์ การเลื่อนระดับนี้คือช่วงเวลาที่วิธีทำงานของนักพัฒนาคนหนึ่งกลายเป็นโครงสร้างพื้นฐานของทีม
Computer และ Runtime รวมกันเป็นเป้าหมายในการรันงาน การที่ Computer ออนไลน์อยู่ แปลว่าบริการภายในเครื่องของมันกำลังส่ง heartbeat อยู่เท่านั้น ไม่ได้แปลว่า Runtime ที่เลือกไว้สามารถรัน Task ได้ ถ้า Computer ออฟไลน์ การรันใหม่โดยปกติจะรอจนกว่ามันจะเชื่อมต่อกลับมา ถ้า Runtime ที่เลือกหายไป ให้เลือกตัวอื่นที่เข้าเงื่อนไข รายละเอียดการตั้งค่าทั้งหมดอยู่ใน Computers ใน Sharkly
Skills รวบรวมคำสั่งที่นำกลับมาใช้ซ้ำได้และไฟล์ประกอบ: กฎการรีวิว เช็กลิสต์การส่งมอบ กระบวนการของทีม Skill ของ Runtime ภายในเครื่องจะพร้อมใช้งานโดยอัตโนมัติบน Computer เครื่องนั้น ส่วน Skill ที่แชร์ใน Space ต้องมอบหมายอย่างชัดเจน มีข้อควรระวังที่ควรย้ำ: หลีกเลี่ยงการผูก Skill ที่ทับซ้อนกันหลายตัว เพราะคำสั่งที่ขัดแย้งกันทำให้การทำงานคาดเดาได้ยากขึ้น อ่านเจาะลึกได้ที่ Skills ใน Sharkly
Repositories คือคันโยกกำหนดขอบเขตที่สะอาดที่สุดที่คุณมี ผูก repository เข้ากับ Agent เมื่อมันต้องการขอบเขตโค้ดที่แคบกว่าค่าเริ่มต้นของ Space ถ้าไม่ผูกอะไรเลย Sharkly จะถอยไปใช้ repository ที่ตั้งค่าไว้สำหรับ Space ของ Task นั้น Agent ด้านเอกสารที่ผูกกับ repository ของ docs ย่อมไม่มีเส้นทางไปถึงบริการชำระเงินของคุณ
Environment และการตั้งค่าการรัน เป็นตัวจำกัดว่าการรันหนึ่งครั้งเข้าถึงอะไรได้บ้าง ตัวแปร environment แบบธรรมดาและแบบความลับ รวมถึงอาร์กิวเมนต์เพิ่มเติมของ Runtime ช่วยให้การรันพกการตั้งค่าไปได้โดยไม่ต้องมีใครคัดลอกข้อมูลรับรองไปวางใน Task ห้ามใส่ token ของ repository, private key หรือ install token ลงในคำอธิบาย Task, คอมเมนต์, คำสั่งของ Agent หรือ Skill เด็ดขาด Task Run Settings ควบคุมจำนวน Task ที่รันพร้อมกัน ระยะเวลารันสูงสุด และโหมด working directory:
| โหมดชั่วคราว | โหมดระบุตำแหน่ง | |
|---|---|---|
| สิ่งที่การรันได้รับ | ไดเรกทอรีแยกต่างหากต่อ Task; การรันที่อิง repository สามารถเตรียม worktree ใหม่ได้ | ไดเรกทอรีภายในเครื่องแบบ absolute ที่ตั้งค่าไว้หนึ่งไดเรกทอรีจาก pool ไดเรกทอรีของ Agent |
| การทำงานพร้อมกัน | การรันขนานที่ปลอดภัยกว่า ค่าเริ่มต้นคือ 50% ของขีดจำกัดของ Computer | หนึ่งการรันต่อไดเรกทอรีในแต่ละครั้ง ค่าเริ่มต้นเท่ากับจำนวนไดเรกทอรี |
| ความพร้อมใช้งาน | Computer ที่เชื่อมต่ออยู่เครื่องใดก็ได้ | เฉพาะ Computer ภายในเครื่องเท่านั้น |
| เหมาะที่สุดสำหรับ | งานที่เกี่ยวกับ repository ส่วนใหญ่ และทุกครั้งที่ Task หลายตัวอาจแก้ไขโค้ดเบสเดียวกันพร้อมกัน | repository ขนาดใหญ่มาก แคชภายในเครื่องที่มีต้นทุนสูง หรือ Task ที่ผูกกับบริการภายในเครื่อง |
ถ้าตั้งค่าจำนวนการทำงานพร้อมกันแบบ manual สูงกว่าจำนวนไดเรกทอรี ผลิตภัณฑ์จะเตือนว่าการเขียนอาจชนกัน กลไกการแยกส่วนนี้เป็นหัวข้อของ วิธีที่ Sharkly รัน Agent แบบขนานโดยไม่เกิด merge conflict
Chat กับ Task: สองช่องทาง หนึ่งกติกา
Agent Chat คือบทสนทนาแยกต่างหากสำหรับถามคำถาม สืบค้นหัวข้อ หรือร่างแผนก่อนที่อะไรจะต้องกลายเป็น Task ที่ติดตามได้ Chat รองรับสามโหมด: Explore สำหรับการสืบค้นแบบอ่านอย่างเดียว, Plan สำหรับข้อเสนอที่คุณรีวิวและยืนยันก่อนที่ Sharkly จะสร้าง task และ subtask ตามแผน และ Execute สำหรับลงมือทำโดยตรงผ่าน CLI ที่ตั้งค่าไว้ใน Agent แต่ละเซสชันเป็นของคนที่สร้างมันขึ้นมา
Task คือที่ที่งานไปอยู่เมื่อมันต้องการเจ้าภาพ สถานะ ประวัติการทำงาน หรือการรีวิว คู่การตัดสินใจคือ: ใช้ Chat เพื่อสำรวจ วางแผน หรือลงมือก่อนที่งานจะต้องมี Task ให้ติดตาม และใช้ Task เมื่องานต้องการผู้รับผิดชอบ สถานะ เกณฑ์การยอมรับ หรือบันทึกถาวร
มีเส้นแบ่งหนึ่งที่ช่วยไม่ให้ทีมสูญเสียบริบท การส่งข้อความใน Agent Chat ไม่ได้สร้างคอมเมนต์ใน task และข้อความใน Agent chat ของ task จะไม่ปรากฏใน Activity ในฐานะคอมเมนต์ ถ้าทีมต้องเห็นข้อสรุป ให้คัดลอกลงในคำอธิบาย task หรือคอมเมนต์ ความไว้วางใจขึ้นอยู่กับบันทึกที่แชร์ร่วมกัน และบันทึกที่แชร์ร่วมกันนั้นคือ Task
สถานะต่าง ๆ บอกอะไรกับคุณ
ความโปร่งใสในที่นี้คือชุดสถานะที่เจาะจงซึ่งคุณอ่านได้ ไม่ใช่สโลแกนบนแดชบอร์ด
การรัน Task จะไล่ผ่านสถานะ queued, dispatched, waiting for local directory, running, completed, failed และ canceled สถานะการรันแยกจากสถานะเวิร์กโฟลว์ของ Task: การรันอาจล้มเหลวในขณะที่ Task ยังเปิดอยู่เพื่อลองใหม่ได้ บันทึกการทำงาน (execution log) บันทึกว่าเหตุใดการรันจึงถูกจัดคิว เริ่มและสิ้นสุดเมื่อใด การเรียกใช้เครื่องมือและเหตุการณ์ของ Runtime แหล่งที่มาของการกระตุ้น และรายละเอียดความล้มเหลว
ความพร้อมใช้งานของ Agent เป็นสัญญาณที่สามที่แยกออกไป Agent ที่ออนไลน์อาจยังมีงานค้างอยู่ในคิวเพราะจำนวนงานที่รันพร้อมกันหรือความจุของไดเรกทอรีเต็ม และ Backlog ทำหน้าที่เป็นที่พักงาน: Task ที่มอบหมายให้ Agent จะรออยู่ตราบใดที่ยังอยู่ใน Backlog และการย้ายมันไปยังสถานะที่พร้อมทำงานคือสิ่งที่เริ่มการรัน การมอบหมายงานให้ Agent ไม่เคยเริ่มงานแบบไม่ทันตั้งตัว
Agent ตัวแรกของคุณ: เดินตามขั้นตอนที่คุณวางใจได้
วิธีที่เร็วที่สุดในการสร้างความไว้วางใจคือวงจรเล็ก ๆ ที่มีประโยชน์จาก เอกสาร Sharkly: เชื่อมต่อ Computer หนึ่งเครื่อง สร้าง Agent หนึ่งตัว และมอบหมาย Task ความเสี่ยงต่ำหนึ่งงาน
- เชื่อมต่อ Computer เปิด Settings จากนั้น Computers แล้วเลือก Connect Computer รอจนกว่ามันจะแสดงว่าเชื่อมต่อแล้วพร้อม Runtime ที่ใช้งานได้อย่างน้อยหนึ่งตัว
- สร้าง Agent ด้วยบทบาทที่แคบ ชื่อ: Code Reader คำอธิบาย: อ่าน repository อธิบายการทำงานปัจจุบัน และรายงานความเสี่ยงโดยไม่แก้ไขไฟล์ การมองเห็น: Personal
- เขียนคำสั่งที่บังคับขอบเขต: "อ่าน Task ทั้งหมดและคอมเมนต์ที่เกี่ยวข้องก่อนลงมือ จำกัดขอบเขตไว้ที่คำขอ สำหรับ Task แรก ห้ามแก้ไขไฟล์ รายงานสิ่งที่คุณตรวจสอบ หลักฐานประกอบข้อสรุปแต่ละข้อ และสิ่งที่ยังไม่แน่ชัด"
- ผูกโค้ด แนบ Git repository หรือตั้งค่าไดเรกทอรีภายในเครื่องแบบระบุตำแหน่งที่มีโค้ดอยู่แล้ว Skills รอไว้ก่อนได้
- สร้าง Task เล็ก ๆ แบบข้อความล้วน: รีวิวเส้นทางข้อผิดพลาดของการยืนยันตัวตน ระบุกรณีล้มเหลวที่ผู้ใช้มองเห็นสามกรณี อ้างอิงไฟล์ที่เกี่ยวข้องของแต่ละกรณี และไม่เปลี่ยนแปลงอะไรเลย
- มอบหมายและเริ่มงาน โดยใช้สถานะที่พร้อมทำงานแทน Backlog สังเกตสถานะการรันเปลี่ยนจาก queued เป็น running แล้วอ่านผลลัพธ์บน Task
- รีวิวอย่างจริงจัง ตรวจสอบว่า Agent ตรวจโค้ดที่ตั้งใจไว้จริง อยู่ในขอบเขตห้ามแก้ไข ให้หลักฐาน และบันทึกความไม่แน่ใจแทนที่จะเดา
ขั้นตอนสุดท้ายนั่นแหละคือประเด็นทั้งหมด Task แรกแบบอ่านอย่างเดียวทำให้ Agent ได้สร้างความน่าเชื่อถือก่อนที่จะมีอำนาจใด ๆ เมื่อวงจรนี้ทำงานได้แล้ว ค่อยขยายขอบเขตอย่างตั้งใจ กลไกการมอบหมายงานแบบครบถ้วนอยู่ใน วิธีมอบหมาย Task แรกให้ AI coding Agent
และถ้า Agent หยุดสร้างความไว้วางใจนั้น การถอนอำนาจก็สะอาด การเก็บถาวร (archive) จะนำมันออกจากการมอบหมายงานและการ mention และยกเลิกงานที่กำลังรันอยู่ ขณะที่ Task, คอมเมนต์ และประวัติการรันก่อนหน้าของมันยังคงเข้าถึงได้ เพื่อนร่วมทีมที่คุณถอดออกจากทีมได้โดยไม่สูญเสียบันทึกการทำงานของเขา คือเพื่อนร่วมทีมที่คุณรับเข้ามาได้อย่างสบายใจ
คำถามที่พบบ่อย
Agent ใน Sharkly คืออะไรกันแน่?
Agent คือผู้ปฏิบัติงาน AI ที่ตั้งค่าไว้ให้จัดการงานใน Sharkly: ชุดการตั้งค่าที่บันทึกไว้ซึ่งประกอบด้วยคำสั่ง การผูกกับ Computer และ Runtime, Skills, repository, ตัวแปร environment และการตั้งค่าการรัน มันสามารถรับ Task ที่ได้รับมอบหมาย เขียนคอมเมนต์ อัปเดตสถานะ Task และสร้าง trace การทำงานได้ เพราะการตั้งค่าถูกบันทึกไว้ วิธีทำงานของคนคนหนึ่งจึงนำกลับมาใช้ซ้ำได้เมื่อแชร์ Agent ไปยัง Space
Sharkly Agent ใช้โมเดลอะไร?
Agent ใช้โมเดลเริ่มต้นของ Runtime ที่เลือกไว้ เช่น Claude Code หรือ Codex และไม่แสดงหรือรับปากชื่อโมเดลใดเป็นเฉพาะ ไม่มีตัวเลือกโมเดลหรือการควบคุมระดับความลึกในการคิดบนตัว Agent ถ้าต้องการเปลี่ยนโมเดล ให้อัปเดตการตั้งค่าเครื่องมือของ Runtime หรือ Computer
การแชตกับ Agent กับการมอบหมาย Task ให้มันต่างกันอย่างไร?
Agent Chat คือบทสนทนาแยกต่างหากสำหรับสำรวจ วางแผน หรือลงมือก่อนที่งานจะต้องมีบันทึกให้ติดตาม ส่วน Task คือหน่วยงานที่แชร์ร่วมกัน ซึ่งมีผู้รับผิดชอบ สถานะ ประวัติการทำงาน และการรีวิว ข้อความใน Chat ไม่กลายเป็นคอมเมนต์ใน task ดังนั้นข้อสรุปที่ทีมควรเห็นจึงต้องอยู่บน Task
จะจำกัดสิ่งที่ Agent ทำได้อย่างไร?
ขอบเขตกำหนดไว้ในการตั้งค่า: คำสั่งนิยามบทบาทและกฎความระมัดระวัง การผูก repository จำกัดว่า Agent เห็นโค้ดใดได้บ้าง และ Task Run Settings จำกัดจำนวน Task ที่รันพร้อมกันและระยะเวลาการรัน โหมด working directory แบบชั่วคราวเพิ่มการแยกส่วนด้วยการให้แต่ละ Task มีไดเรกทอรีของตัวเอง การยอมรับขั้นสุดท้ายยังคงเป็นของคน
ทำไม Task ที่มอบหมายไปแล้วไม่เริ่มทำงาน?
ตรวจสอบสามอย่าง หนึ่ง Task ที่อยู่ใน Backlog จะรอตามการออกแบบ ให้ย้ายไปยังสถานะที่พร้อมทำงาน สอง การที่ Computer ออนไลน์หมายความแค่ว่ามี heartbeat ส่งมา จึงต้องยืนยันว่า Runtime ที่เลือกแสดงว่าพร้อมใช้งาน และสาม Agent ที่ออนไลน์อาจยังจัดคิวงานอยู่เมื่อจำนวนงานที่รันพร้อมกันหรือไดเรกทอรีแบบระบุตำแหน่งเต็ม
