การสร้างพื้นที่ทำงานร่วมกันสำหรับผู้คนและเอเจนต์

เราเพิ่งเปิดตัว โปรเจกต์ ซึ่งผู้คนและเอเจนต์ทำงานร่วมกันในงานระยะยาวใน Perplexity Computer แต่ละโปรเจกต์ตั้งอยู่บนพื้นที่ทำงานร่วมกันที่มีระบบไฟล์ซึ่งสะสมบริบทข้ามเซสชัน เอเจนต์ และผู้ใช้ การทำงานร่วมกันแบบผู้ใช้หลายคนที่กินเวลาหลายเดือนต้องอาศัยความคงทนถาวร การทำงานพร้อมกัน และการตรวจสอบย้อนกลับได้:

• ความคงทนถาวร: งานควรคงอยู่ได้ยาวนานกว่าเซสชันหรือแซนด์บ็อกซ์ของเอเจนต์แต่ละรายการ เพื่อให้ผู้ใช้หรือเอเจนต์รายเดิมสามารถทำงานต่อในอนาคต และผู้ทำงานร่วมกันทุกคนสามารถต่อยอดได้
• การทำงานพร้อมกัน: ผู้ใช้หลายคนในโปรเจกต์เดียวกันสามารถมีเอเจนต์หลายตัวที่แก้ไขพร้อมกันแบบขนาน โดยผลักดันสถานะที่ใช้ร่วมกันให้ก้าวหน้าแทนที่จะเขียนทับกันเอง
• การตรวจสอบย้อนกลับได้: ทั้งผู้ใช้และเอเจนต์ควรดูประวัติได้ เพื่อตรวจสอบว่าใครเปลี่ยนแปลงอะไรไปบ้างตั้งแต่เซสชันล่าสุดโดยไม่ต้องอ่านทั้งโปรเจกต์ซ้ำ และย้อนกลับการแก้ไขได้เมื่อจำเป็น

ความท้าทายเหล่านี้ดูคุ้นเคยสำหรับวิศวกรซอฟต์แวร์ Git forge ถือกำเนิดขึ้นเมื่อหลายสิบปีก่อนเพื่อตอบโจทย์ข้อกำหนดเหล่านี้ นั่นคือบริการแบบโฮสต์ที่ครอบระบบควบคุมเวอร์ชันด้วยฟีเจอร์การทำงานร่วมกัน เพื่อให้ผู้มีส่วนร่วมจำนวนมากมาบรรจบกันที่แหล่งข้อมูลจริงเพียงแหล่งเดียว ระบบไฟล์ที่ขับเคลื่อนโปรเจกต์ก็คือ Git forge ลักษณะนี้ที่สร้างขึ้นเพื่อการทำงานร่วมกันระหว่างมนุษย์กับเอเจนต์ และระหว่างเอเจนต์กับเอเจนต์

ขยาย

สถาปัตยกรรม

Git รองรับความคงทนถาวร การทำงานพร้อมกัน และการตรวจสอบย้อนกลับได้อยู่แล้ว Git ระบุแต่ละไฟล์จากเนื้อหาของไฟล์ ไฟล์ที่ไม่มีการเปลี่ยนแปลงจึงถูกจัดเก็บเพียงครั้งเดียว และสำเนาที่บันทึกไว้จะไม่มีวันล้าสมัย แต่ละคอมมิตจะบันทึกไฟล์ที่อัปเดตทั้งหมดในคราวเดียว ผู้ทำงานร่วมกันจึงไม่เคยเห็นสถานะที่เสร็จเพียงครึ่งเดียว เมื่อผู้เขียนสองรายชนกัน ฝ่ายที่แพ้สามารถนำการเปลี่ยนแปลงของตนไปใช้ใหม่บนเวอร์ชันใหม่แล้วลองอีกครั้ง สายของคอมมิตแสดงให้เห็นว่าใครเปลี่ยนแปลงอะไร และทำให้กู้คืนเวอร์ชันก่อนหน้าได้ง่าย สิ่งที่เอเจนต์ไม่จำเป็นต้องใช้คือส่วนอื่นๆ ของ forge ที่สร้างมาเพื่อมนุษย์ เช่น หน้าจอตรวจทาน การจัดการบรานช์ และการแจ้งเตือน

สถาปัตยกรรมของเราทำงานทั้งกระบวนการบนคลาวด์และรองรับงานความรู้ทุกรูปแบบ ไม่ใช่แค่การเขียนโค้ด ทุกโปรเจกต์ใน Computer ทำงานบนรีโพสิทอรี Git ที่ให้บริการโดยคอมโพเนนต์ 5 ส่วน:

• CLI ดูแลการเช็กเอาต์ในเครื่อง ซิงก์การอัปเดต และส่งการเปลี่ยนแปลงของเอเจนต์ในแต่ละแซนด์บ็อกซ์
• คอนโทรลเพลน ระบุตำแหน่งรีโพสิทอรีของโปรเจกต์และออกข้อมูลประจำตัวอายุสั้นสำหรับเข้าถึงรีโพสิทอรีนั้น
• บริการ Git ส่งข้อมูลรีโพสิทอรีไปยังแซนด์บ็อกซ์ รับการส่งจากแซนด์บ็อกซ์ และตัดสินว่าการส่งใดจะกลายเป็นคอมมิตล่าสุดที่ได้รับการยอมรับ
• พื้นที่จัดเก็บข้อมูลที่ทำงานบน AWS S3 จัดเก็บข้อมูลของรีโพสิทอรีอย่างคงทนถาวร
• การประมวลผลปลายน้ำ ดึงข้อความและข้อมูลที่เป็นประโยชน์อื่นๆ จากเอกสารที่บันทึกไว้ และทำให้พร้อมใช้งานเมื่อเอเจนต์โหลดหรือรีเฟรชโปรเจกต์

เอเจนต์แต่ละตัวมีแซนด์บ็อกซ์แยกเป็นของตัวเอง ภายในแซนด์บ็อกซ์นั้น เอเจนต์ทำงานกับสำเนาของรีโพสิทอรีในเครื่อง ซึ่งจัดการโดย CLI ขนาดเล็ก CLI จะขอให้คอนโทรลเพลนระบุตำแหน่งของรีโพสิทอรี จากนั้นจึงดึงข้อมูลและส่งการเปลี่ยนแปลงผ่านบริการ Git พร็อกซีเอเจนต์จะตรวจสอบสิทธิ์การเข้าถึงของคำขอจากแซนด์บ็อกซ์ก่อนที่คำขอจะไปถึงบริการ Git บริการ Git อ่านและเขียนรีโพสิทอรีบนระบบไฟล์ที่ใช้ร่วมกัน และตัดสินว่าการส่งแต่ละครั้งจะกลายเป็นคอมมิตล่าสุดที่ได้รับการยอมรับหรือไม่ ระบบไฟล์ดังกล่าวให้บริการโดย AWS S3Files ซึ่งทำให้เข้าถึงพื้นที่จัดเก็บข้อมูลที่ทำงานบน S3 ได้เหมือนไฟล์และไดเรกทอรีทั่วไป พื้นที่จัดเก็บข้อมูลแบ่งออกเป็นเซลล์ที่แยกออกจากกัน โดยแต่ละเซลล์มีระบบไฟล์และเรพลิกาของบริการ Git เป็นของตัวเอง หลังจากคอมมิตได้รับการยอมรับ เวิร์กเกอร์เบื้องหลังจะดึงข้อความและข้อมูลที่เป็นประโยชน์อื่นๆ จากเอกสารที่เปลี่ยนแปลง จัดเก็บผลลัพธ์แยกต่างหากจากประวัติของรีโพสิทอรี และทำให้ผลลัพธ์พร้อมใช้งานเมื่อเอเจนต์โหลดหรือรีเฟรชโปรเจกต์

ต่อไป เราจะอธิบายคอมโพเนนต์ทีละส่วน

ขยาย

CLI: การทำงานกับไฟล์ในเครื่องภายในแซนด์บ็อกซ์

เอเจนต์ทำงานใน SPACE ซึ่งเป็นแพลตฟอร์มแซนด์บ็อกซ์ที่เราพัฒนาขึ้นเอง แต่ละแซนด์บ็อกซ์มี CLI ขนาดเล็กที่สร้างรีโพสิทอรีขึ้นมาในเครื่องและคอยซิงก์ให้เป็นปัจจุบัน สำหรับงานที่มีความหมายแต่ละหน่วยที่เอเจนต์ทำ CLI จะส่งการเปลี่ยนแปลงเป็นคอมมิต

โดยทั่วไปเอเจนต์จะเข้าถึงไฟล์โปรเจกต์เพียงส่วนน้อย จึงไม่จำเป็นต้องสร้างรีโพสิทอรีทั้งหมดขึ้นมาล่วงหน้า ด้วยเหตุนี้ CLI จึงสร้างไฟล์ขึ้นมาแบบ lazy: ไฟล์ขนาดใหญ่และไฟล์ไบนารีที่จัดเก็บผ่าน Git Large File Storage (LFS) จะมาถึงในรูปของไฟล์ตัวชี้ขนาดเล็กที่เก็บขนาดจริงของออบเจกต์ไว้ เอเจนต์จึงใช้ชื่อและขนาดเพื่อตัดสินใจได้ว่าคุ้มค่าที่จะดาวน์โหลดหรือไม่ สำหรับเอกสารอย่าง PDF เอเจนต์จะอ่านข้อความที่แยกวิเคราะห์แล้วก่อน และจะดาวน์โหลดไฟล์ต้นฉบับเฉพาะเมื่อจำเป็นเท่านั้น

อีกทางเลือกหนึ่งที่ดูเป็นธรรมชาติคือการใช้ระบบไฟล์เสมือน เราได้ทดสอบการใช้งานที่ทำงานบน FUSE แต่พบว่าช้ากว่าไฟล์ในเครื่องประมาณ 400 เท่าสำหรับเวิร์กโหลดที่ใช้งานระบบไฟล์หนัก เนื่องจากทุกคำขอต้องเดินทางไปกลับผ่านเครือข่าย นอกจากนี้ยังมักต้องใช้สิทธิ์ระดับสูงจากโฮสต์ ทำให้เอเจนต์ทุกตัวต้องทำงานในแซนด์บ็อกซ์ที่มีสิทธิ์ระดับสูง

ขยาย

คอนโทรลเพลน: การระบุตำแหน่งรีโพสิทอรีและการออกสิทธิ์การเข้าถึง

คอนโทรลเพลนจะระบุตำแหน่งที่จัดเก็บแต่ละรีโพสิทอรีและออกสิทธิ์การเข้าถึง เมื่อมีการสร้างรีโพสิทอรี คอนโทรลเพลนจะกำหนดรีโพสิทอรีนั้นให้กับเซลล์จัดเก็บข้อมูล ซึ่งเป็นหน่วยจัดเก็บข้อมูลที่แยกออกจากกันและมีเรพลิกาของบริการ Git เป็นของตัวเอง เมื่อเอเจนต์เริ่มทำงานในโปรเจกต์ CLI จะสอบถามคอนโทรลเพลนว่ารีโพสิทอรีจัดเก็บอยู่ที่ใด คอนโทรลเพลนจะส่งตำแหน่งและข้อมูลประจำตัวชั่วคราวสำหรับบริการ Git กลับมา คอนโทรลเพลนไม่เคยอ่านหรือเขียนข้อมูลของรีโพสิทอรี บริการ Git เป็นผู้ตัดสินว่าสิ่งใดจะเข้าสู่รีโพสิทอรี

บริการ Git: การย้ายข้อมูลและการประสานการอัปเดต

บริการ Git ดำเนินการ Git และถ่ายโอนเนื้อหาของรีโพสิทอรีและประวัติเวอร์ชันระหว่างแซนด์บ็อกซ์กับพื้นที่จัดเก็บข้อมูล บริการนี้เป็นเพียงตัวครอบบางๆ รอบคำสั่งให้บริการของ Git เอง โดยรองรับการค้นหา ref เพื่อบอกไคลเอนต์ว่า head ของรีโพสิทอรีอยู่ที่ใด upload-pack สำหรับการโคลนและการดึงข้อมูล และ receive-pack สำหรับการรับออบเจกต์ใหม่และคำขอให้เลื่อน head ของรีโพสิทอรีไปข้างหน้า นอกจากนี้ยังให้บริการ Git LFS API ด้วย: สำหรับไฟล์ขนาดใหญ่และไฟล์ไบนารี บริการจะออกลิงก์อายุสั้นเพื่อให้แซนด์บ็อกซ์อัปโหลดและดาวน์โหลดไฟล์เหล่านั้นจาก S3 ได้โดยตรง

เราเริ่มต้นด้วยเซิร์ฟเวอร์ forge สำเร็จรูป เพื่อให้สามารถสร้างต้นแบบอินเทอร์เฟซสำหรับเอเจนต์และผู้ใช้ไปพร้อมกับการสร้าง forge น้ำหนักเบาของเราเอง ซึ่งมุ่งเน้นเฉพาะการดำเนินการ Git ที่เราต้องการเท่านั้น

บริการนี้ประกอบด้วยกลุ่มเรพลิกา ซึ่งแต่ละตัวเป็นอินสแตนซ์ที่กำลังทำงานของเซิร์ฟเวอร์เดียวกัน เซลล์จะจัดกลุ่มพื้นที่จัดเก็บข้อมูลที่ใช้ร่วมกันเข้ากับชุดเรพลิกาและบริการสนับสนุนของเรพลิกาเหล่านั้น เรพลิกาภายในเซลล์จึงเข้าถึงระบบไฟล์ที่ใช้ร่วมกันชุดเดียวกันได้ แทนที่จะต้องดูแลสำเนาของทุกรีโพสิทอรีแยกกัน

พื้นที่จัดเก็บข้อมูลที่ใช้ร่วมกันนี้ทำให้เรพลิกาไม่ต้องเก็บสถานะ (stateless) เรพลิกาใดก็ได้ในเซลล์สามารถให้บริการรีโพสิทอรีใดก็ได้ของเซลล์นั้น การเปลี่ยนหรือเพิ่มเรพลิกาจึงไม่ต้องย้ายข้อมูลรีโพสิทอรีระหว่างเซิร์ฟเวอร์ โดยปกติคำขอสำหรับรีโพสิทอรีหนึ่งๆ จะถูกส่งไปยังเรพลิกาเดิมเพื่อให้แคชยังคงมีประโยชน์ แต่รีโพสิทอรีไม่ได้ขึ้นอยู่กับว่าอินสแตนซ์นั้นจะต้องพร้อมใช้งานอยู่เสมอ

ขั้นตอนการยอมรับจะตรวจสอบค่าคงที่ (invariant) ของรีโพสิทอรีเพื่อให้มั่นใจว่าคอมมิตที่ได้รับการยอมรับเป็นสถานะของรีโพสิทอรีที่ถูกต้อง เรากำหนดข้อตกลงที่ชัดเจนสำหรับทุกรีโพสิทอรี เพื่อให้การตรวจสอบเชิงกลไกป้องกันไม่ให้รีโพสิทอรีมีขนาดใหญ่เกินไป ไฟล์ขนาดใหญ่และไฟล์ไบนารี เช่น PDF และรูปภาพ จะถูกจัดเก็บผ่าน Git LFS แทนที่จะเป็น Git blob ดิบ การบีบอัด (compaction) ช่วยให้ประวัติล่าสุดยังคงเข้าถึงได้ ขณะเดียวกันก็จำกัดขนาดของรีโพสิทอรี หลังจากส่งสำเร็จ CLI จะสอบถามบริการ Git ว่ารีโพสิทอรีจำเป็นต้องบีบอัดหรือไม่ หากจำนวนคอมมิตที่เก็บไว้เกินเกณฑ์ที่กำหนด บริการ Git จะเก็บไว้เฉพาะคอมมิตล่าสุดชุดที่เล็กลง ประวัติที่เก่ากว่าจะถูกแทนที่ด้วยสแนปช็อตเริ่มต้นเพียงชุดเดียว และคอมมิตล่าสุดจะถูกนำมาเล่นซ้ำ (replay) เพื่ออัปเดตตัวระบุคอมมิต

ขยาย

ขั้นตอนการซิงโครไนซ์ที่เรียบง่ายช่วยควบคุมผู้เขียนที่ทำงานพร้อมกัน โดยจะติดตามคอมมิตล่าสุดที่ได้รับการยอมรับ หรือ head เมื่อได้รับการส่ง ระบบจะยอมรับก็ต่อเมื่อการส่งนั้นสร้างขึ้นบน head ดังกล่าวเท่านั้น หากไม่ใช่ ระบบจะส่งการตอบกลับ stale-base แบบมีโครงสร้าง จากนั้นฝ่ายที่แพ้จะต้องเล่นซ้ำการเปลี่ยนแปลงของตนบน head ใหม่แล้วส่งอีกครั้ง การออกแบบนี้ช่วยให้มั่นใจได้ว่าเอเจนต์ที่ทำงานพร้อมกันจะไม่เขียนทับงานของกันและกันโดยไม่รู้ตัว โดยไม่ทำให้ระบบช้าลงอย่างมีนัยสำคัญ ในเวิร์กโฟลว์การใช้งานจริงของเรา มีการส่งน้อยกว่า 2% ที่ถูกปฏิเสธเนื่องจากล้าสมัย โดยรวมแล้ว ค่ามัธยฐานของเวลาแฝงในการส่งอยู่ที่ต่ำกว่า 1.7 วินาที และเวลาแฝงที่ p99 อยู่ที่ต่ำกว่า 8 วินาที

ขยาย

บริการ Git ยังบันทึกการเปลี่ยนแปลงทุกรายการที่ได้รับการยอมรับด้วย สำหรับการเขียนแต่ละครั้งที่ได้รับการยอมรับ บริการจะเพิ่มรายการลงใน outbox ซึ่งเป็นบันทึกที่ระบุรีโพสิทอรี คอมมิตใหม่ ผู้ใช้ที่ทำการเปลี่ยนแปลง และพาธที่เปลี่ยนแปลง บริการปลายน้ำอย่างตัวแยกวิเคราะห์จะอ่านบันทึกนี้เพื่อค้นหางานใหม่

เมื่อรวมกันแล้ว ส่วนประกอบเหล่านี้จะกลายเป็นเลเยอร์การจัดการรีโพสิทอรีที่ตัดส่วนที่เอเจนต์ไม่จำเป็นต้องใช้ออกไป ไม่จำเป็นต้องมี pull request เพราะไม่มีมนุษย์คนใดตรวจทานการเปลี่ยนแปลงแต่ละรายการ แต่บริการ Git จะตรวจสอบข้อตกลงในขณะที่ส่ง เอเจนต์ที่แพ้ในการแข่งกันเขียนจะนำการเปลี่ยนแปลงของตนไปใช้ใหม่ และประวัติคอมมิตจะบันทึกว่าใครเปลี่ยนแปลงอะไร การตรวจสอบแบบกำหนดผลได้แน่นอน (deterministic) ช่วยให้แต่ละรีโพสิทอรีอยู่ภายในข้อตกลงของตน แทนที่จะต้องพึ่งพาผู้ดูแลที่เป็นมนุษย์ในการจัดการการเติบโต

พื้นที่จัดเก็บข้อมูล: การรักษางานให้คงทนถาวร

เลเยอร์พื้นที่จัดเก็บข้อมูลบันทึกข้อมูลรีโพสิทอรีอย่างคงทนถาวร โดยเป็นอิสระจากแซนด์บ็อกซ์และเรพลิกาของบริการ Git รีโพสิทอรีอยู่บน AWS S3Files ซึ่งเปิดให้เข้าถึงพื้นที่จัดเก็บข้อมูลที่ทำงานบน S3 ผ่านอินเทอร์เฟซระบบไฟล์ที่ Git มาตรฐานใช้งานได้โดยไม่ต้องดัดแปลง แต่ละรีโพสิทอรีเป็น bare Git repository บนระบบไฟล์ที่ใช้ร่วมกัน ซึ่งประกอบด้วยออบเจกต์และการอ้างอิง (reference) ของรีโพสิทอรี แทนที่จะเป็นสำเนาเช็กเอาต์สำหรับทำงาน

การแยกพื้นที่จัดเก็บข้อมูลออกจากการประมวลผลทำให้แซนด์บ็อกซ์เป็นแบบชั่วคราวได้ เอเจนต์แต่ละตัวมีแซนด์บ็อกซ์เป็นของตัวเอง และเอเจนต์จำนวนมากสามารถทำงานในโปรเจกต์เดียวกันได้โดยไม่ต้องใช้เครื่องร่วมกัน หากแซนด์บ็อกซ์ขัดข้อง จะมีความเสี่ยงเฉพาะงานที่ยังไม่ได้ส่งเท่านั้น

อีกทางเลือกหนึ่งคือการให้แต่ละโปรเจกต์มีแซนด์บ็อกซ์อายุยาวที่เอเจนต์ทั้งหมดของโปรเจกต์ใช้ร่วมกัน ไฟล์ของโปรเจกต์จึงจะอยู่บนดิสก์ของเครื่องนั้น อย่างไรก็ตาม วิธีนี้จะผูกการประมวลผลของเอเจนต์ไว้กับตำแหน่งที่เครื่องนั้นทำงานอยู่ และต้องกำหนดขนาดเครื่องให้รองรับช่วงเวลาที่มีการใช้งานหนักที่สุด นอกจากนี้ เครื่องยังต้องอยู่ในสภาพดีต่อเนื่องเป็นเวลาหลายเดือน โดยต้องจัดการการสำรองข้อมูลและการกู้คืนเป็นส่วนหนึ่งของระบบจัดเก็บข้อมูลของโปรเจกต์

ขยาย

การประมวลผลปลายน้ำ: การทำให้เอเจนต์อ่านเอกสารได้

คอมโพเนนต์ปลายน้ำหลักคือไปป์ไลน์ตัวแยกวิเคราะห์ (parser) ที่ดึงข้อความและเมตาดาตาจากเอกสารที่เพิ่มใหม่หรืออัปเดต เพื่อให้เอเจนต์อ่านไฟล์โปรเจกต์ได้ง่าย เวิร์กเกอร์ตัวแยกวิเคราะห์จะรับการอัปเดตจากคิวสตรีมการเปลี่ยนแปลง ระบุไฟล์ที่เปลี่ยนแปลงจากเมตาดาตาของคอมมิต และดึงไบต์ดิบโดยใช้แฮชของเนื้อหา จากนั้นจึงแยกวิเคราะห์เอกสารเพื่อสร้างข้อความที่ดึงออกมาและเมตาดาตาของเอกสาร

ผลลัพธ์จากการแยกวิเคราะห์อยู่ภายนอกรีโพสิทอรี ในที่จัดเก็บที่ใช้แฮชของเอกสารต้นฉบับเป็นคีย์ อาร์ทิแฟกต์เหล่านี้จะไม่ถูกคอมมิตกลับเข้าไปในรีโพสิทอรี เพราะจะทำให้ประวัติรกโดยไม่จำเป็นและเพิ่มจำนวนการเขียนพร้อมกัน ผลลัพธ์จากการแยกวิเคราะห์จะไปถึงแซนด์บ็อกซ์ผ่านการเช็กเอาต์และการซิงก์แทน เช็กเอาต์แต่ละชุดมีไดเรกทอรีสงวนที่ CLI ใช้สำหรับสร้างอาร์ทิแฟกต์ขึ้นมาในเครื่อง การแยกวิเคราะห์เกิดขึ้นแบบอะซิงโครนัส เวิร์กเกอร์ตัวแยกวิเคราะห์เบื้องหลังจึงไม่ขัดขวางการเช็กเอาต์

วิธีที่เอเจนต์ใช้พื้นที่ทำงาน

เอเจนต์สำรวจเวอร์ชันของรีโพสิทอรีที่โหลดเข้าสู่แซนด์บ็อกซ์โดยใช้เครื่องมือระบบไฟล์มาตรฐาน แทนที่จะทำตามไปป์ไลน์ตายตัวแบบค้นหาแล้วอ่าน เอเจนต์จะแสดงรายการโฟลเดอร์ ค้นหาเนื้อหาไฟล์ด้วย grep อ่านข้อความที่เกี่ยวข้อง และใช้สิ่งที่พบเพื่อตัดสินใจว่าจะค้นหาที่ใดต่อไป

Search ใช้แนวทางเดียวกันกับ Computer ผ่านเครื่องมือไฟล์มาตรฐาน เอเจนต์สำรวจที่แยกต่างหากจะค้นหาภายในโปรเจกต์ด้วยงบประมาณที่จำกัดกว่า และส่งคืนพาธไฟล์ที่เกี่ยวข้องพร้อมข้อความที่ตัดตอนมาประกอบ จากนั้นโมเดลที่ตอบคำถามจะอ่านไฟล์ที่เลือกและสร้างคำตอบ การนำแซนด์บ็อกซ์ของโปรเจกต์ที่มีอยู่แล้วกลับมาใช้ซ้ำช่วยลดเวลาในการตั้งค่า โดยการเชื่อมต่อกับเช็กเอาต์ที่พร้อมใช้งานอยู่แล้ว (warm) ใช้เวลาประมาณ 2.9 วินาที เทียบกับราว 8 วินาทีสำหรับการเริ่มต้นแบบ cold start

ขยาย

ข้อความที่แยกวิเคราะห์แล้วทำให้เอกสารขนาดใหญ่ เช่น PDF และไฟล์ Office ค้นหาได้ด้วยเครื่องมือชุดเดียวกัน เอเจนต์จะตรวจสอบแมนิเฟสต์ก่อน ซึ่งเป็นรายการที่แสดงว่าเอกสารใดมีข้อความที่ดึงออกมาแล้วพร้อมใช้งาน จากนั้นจึงค้นหาและอ่านข้อความนั้นเหมือนไฟล์ทั่วไป เอเจนต์จะดาวน์โหลดเอกสารต้นฉบับเฉพาะเมื่อข้อความไม่เพียงพอเท่านั้น เช่น เพื่อตรวจดูภาพประกอบ เลย์เอาต์ หรือข้อมูลที่ฝังอยู่

เราได้ทดสอบเปรียบเทียบแนวทางนี้กับการค้นหาเชิงความหมายบนดัชนี โดยใช้คำถามด้านการเงินแบบเอกสารเดียว 150 ข้อบนคลังข้อมูลชุดเดียวกัน เอเจนต์สำรวจได้คะแนน 0.867 ในการดึงเอกสารที่ถูกต้อง และ 0.627 ในการตอบได้ถูกต้อง เทียบกับประมาณ 0.39 และ 0.37 สำหรับการค้นหาเชิงความหมาย ซึ่งดีกว่าราว 1.7 เท่าในด้านคำตอบ และ 2 เท่าในด้านการดึงข้อมูล โดยมีเวลาแฝงต่ำกว่าประมาณ 25% เอเจนต์สำรวจทำงานกับข้อความที่ดึงออกมาเป็นหลัก และแทบไม่ดาวน์โหลด PDF ต้นฉบับ

ขยาย

โครงสร้างพื้นฐานที่ใช้ร่วมกันเพียงหนึ่งเดียว

หน่วยความจำถาวรของ Computer ใช้โครงสร้างพื้นฐานระบบไฟล์เดียวกัน Perplexity Brain ซึ่งเป็นวิกิความรู้ของ Computer จัดเก็บหน่วยความจำไว้ในรีโพสิทอรีความรู้ที่มีประวัติและนโยบายเป็นของตัวเอง การแยกความรู้ออกจากไฟล์โปรเจกต์ทำให้การอัปเดตหน่วยความจำเบื้องหลังไม่แย่งชิงกับการแก้ไขไฟล์เหล่านั้น เซสชันที่ต้องใช้ทั้งสองอย่างจะโหลดทั้งสองรีโพสิทอรี

เอเจนต์เบื้องหลังจะอ่านความรู้ที่มีอยู่ ผสานข้อมูลใหม่ และบันทึกหน้าที่อัปเดตแล้วเป็นคอมมิต เอเจนต์อื่นๆ อ่านหน้าเหล่านั้นด้วยเครื่องมือไฟล์ทั่วไป และผู้คนก็แก้ไขหน้าเหล่านั้นได้เช่นกัน ผู้เขียนแบ่งปันงานผ่านรีโพสิทอรีแทนการประสานงานกับผู้อ่านแต่ละรายโดยตรง ประวัติคอมมิตจะบันทึกว่าใครเปลี่ยนแปลงอะไร ขณะที่ outbox จะรายงานการอัปเดตที่ได้รับการยอมรับไปยังบริการปลายน้ำ ผู้คนและเอเจนต์สามารถต่อยอดจากงานของกันและกันได้ พร้อมบันทึกว่าความรู้มีวิวัฒนาการมาอย่างไร

บทสรุป

เมื่อผู้คนและเอเจนต์ใช้โปรเจกต์ร่วมกัน พื้นที่ทำงานจะทำหน้าที่มากกว่าการจัดเก็บไฟล์ โดยเป็นพื้นที่ส่วนกลางสำหรับรวมผลงานที่แต่ละฝ่ายมีส่วนร่วมและติดตามว่ามีอะไรเปลี่ยนแปลงไปบ้าง Git ได้วางรากฐานดังกล่าวไว้มากแล้ว เราเพิ่มการประสานงานและการตรวจสอบอัตโนมัติ เพื่อให้เอเจนต์ส่งงานได้โดยไม่ต้องมีคนอนุมัติการอัปเดตแต่ละครั้ง ผลลัพธ์คือ forge ที่ลดทอนเหลือเพียงสิ่งที่จำเป็น เพราะโดยแก่นแท้แล้ว การทำงานร่วมกันระหว่างเอเจนต์และการพัฒนาซอฟต์แวร์ที่มีผู้มีส่วนร่วมหลายคนก็คือปัญหาเดียวกัน

เอเจนต์ทำงานในแซนด์บ็อกซ์ชั่วคราวที่แยกเป็นอิสระจากกัน ขณะที่มีส่วนร่วมกับรีโพสิทอรีที่คงทนถาวร ขีดจำกัดของรีโพสิทอรีช่วยให้การเติบโตอยู่ในระดับที่จัดการได้ การดาวน์โหลดแบบระบุชัดเจนช่วยให้เอเจนต์เลือกได้ว่าจะดึงข้อมูลใด และไฟล์ทั่วไปช่วยให้เอเจนต์สำรวจได้ด้วยเครื่องมือที่คุ้นเคย การอัปเดตเบื้องหลัง การแก้ไขแบบอินเทอร์แอกทีฟ และงานที่ตั้งเวลาไว้ สามารถต่อยอดจากงานของกันและกันได้โดยไม่ต้องประสานงานกันโดยตรง

เมื่อมีเอเจนต์จำนวนมากขึ้นทำงานอย่างอิสระภายในโปรเจกต์ พื้นที่ทำงานร่วมกันของเอเจนต์เหล่านั้นจะต้องเชื่อถือได้และเข้าใจได้สำหรับผู้คน เป้าหมายนั้นตรงไปตรงมา: การเปลี่ยนแปลงแต่ละครั้งควรคงอยู่ยาวนานกว่าเอเจนต์ที่สร้างมันขึ้นมา พร้อมให้ผู้ทำงานร่วมกันคนถัดไปใช้งานได้ และทิ้งบันทึกที่ชัดเจนว่ามีอะไรเปลี่ยนแปลงไปบ้าง

การอ้างอิง

@online{perplexity2026BuildingSharedWorkspacesForPeopleAndAgents,
  author = {{Perplexity} and Se Won Jang and Peter Hart and Kartik Kapur and Kevin Lau and Sidhant Rajadnya and Ishbir Singh and Thomas Wang and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Building shared workspaces for people and agents}},
  date = {2026-10-12},
  url = {https://www.perplexity.ai/hub/blog/building-shared-workspaces-for-people-and-agents}
}