การประสานงาน

เอเจนต์ตัวเดียวเก่งได้แค่เรื่องเดียว บางคำขอใหญ่กว่านั้น เช่น “ค้นหาตลาดของ X แล้วเขียนเอกสารวางตำแหน่งผลิตภัณฑ์” “ส่งฟีเจอร์นี้ให้เสร็จครบวงจร” “ตรวจสอบ โมดูลนี้แล้วแก้สิ่งที่พบ” การประสานงาน คือวิธีที่ Control Center รับมือกับคำขอ แบบนั้น: ตัวประสานงาน (โดยปกติคือเอเจนต์ CEO ของคุณ) เสนอแผนของทั้งทีม คุณอนุมัติ ครั้งเดียว แล้วตัวจัดทำแบบดีเทอร์มินิสติกจะแปลงมันเป็นไปป์ไลน์ที่ลงมือทำงานนั้น

มันวางตัวอยู่ระหว่างสองวิธีทำงานที่มีอยู่แล้ว:

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

รูปร่างหน้าตาของข้อเสนอ

เมื่อคุณให้เป้าหมายกับตัวประสานงาน มันจะคืน OrchestrationProposal ที่มี โครงสร้าง: แผนแบบมีชนิดที่แอปตรวจสอบและรันได้ แทนที่จะเป็นข้อความร้อยเรียงอิสระ ข้อเสนอหนึ่งชุดมี:

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

งบประมาณเป็นเพียงคำแนะนำ

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

จุดที่คุณตรวจสอบ

มีสองพื้นผิวที่แสดงการประสานงานเดียวกัน

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

Plan Studio คือตัวแก้ไข: แคนวาส DAG ตัวตรวจสอบโหนด ลิ้นชักฉบับแก้ไขและ diff และแถบอนุมัติที่พกค่าประมาณการ มันเปิดเป็นแท็บตัวแก้ไขได้จาการ์ดนั้นโดยตรง จงใจ ไม่มีรายการ “แผน” ในแถบข้าง; /plans และ /plans/:kind/:id มีอยู่เป็นดีปลิงก์ สำหรับแชร์

การอนุมัติเป็นหน้าที่ของโอเปอเรเตอร์เท่านั้น ไม่มีเครื่องมือ MCP สำหรับการนี้: เอเจนต์เสนอได้ (propose_orchestration) ส่งแผนได้ (submit_plan) หรือสร้าง อินสแตนซ์ของเพลย์บุ๊กได้ (run_playbook) แต่มีแค่มนุษย์เท่านั้นที่อนุมัติ ฉบับแก้ไขที่เอเจนต์เป็นผู้ริเริ่มยังถูกจำกัดอัตราเพิ่มด้วยคูลดาวน์สองนาที ลูปการ วางแผนใหม่จึงรวมตัวกันแทนที่จะท่วมฟีดของคุณ

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

กรณีมีตัวแก้ไขสองตัวบนแผนเดียวจะถูกจัดการด้วยการควบคุมการทำงานพร้อมกันแบบ optimistic ไม่ใช่การผสาน การแก้ไขทุกครั้งแนบ base_revision ที่มันใช้เป็นฐานมา เสมอ การแก้ไขที่อิงฉบับแก้ไขที่ล้าสมัยจะถูกปฏิเสธด้วยข้อความ “แผนเดินหน้า ต่อไปแล้ว” แทนที่จะทับงานของคนอื่นอย่างเงียบ ๆ การย้อนกลับก็ไม่ใช่การลบเช่นกัน — มันต่อท้ายข้อเสนอเก่าเป็นฉบับแก้ไขใหม่ ไทม์ไลน์ของฉบับแก้ไขจึงมีแต่เพิ่มขึ้น

ประมาณการที่ซื่อตรง หรือไม่ก็ไม่มีเลย

ค่าประมาณการบนแถบอนุมัติสร้างจากประวัติการรันที่เสร็จจริงของแต่ละบทบาท ในรูปช่วง อินเทอร์ควอไทล์ (p25–p75) ยอดรวมค่าใช้จ่ายบวกจากโหนดที่ประมาณการได้ ส่วน ระยะเวลาใช้เส้นทางวิกฤตผ่าน DAG แทนการบวก (สาขาที่ขนานกันทับซ้อนกัน)

โหนดที่บทบาทของมันไม่มีประวัติการรันที่เสร็จจะรายงาน sampleSize: 0 และ ช่วงค่าเป็น null ซึ่งเรนเดอร์ออกมาตรง ๆ แบบนั้น — ไม่ทราบ — ไม่เคยเป็นค่าจุดที่ กุขึ้นมา เพราะประมาณการที่คุณเชื่อถือไม่ได้นั้นแย่กว่าไม่มีประมาณการเลย เมื่อบาง โหนดมีประวัติและบางโหนดไม่มี ยอดรวมจะถูกทำเครื่องหมายว่าบางส่วน รัศมีผลกระทบจะ ปรากฏเฉพาะเมื่อโหนดประกาศการอ้างอิงแหล่งที่มาแบบ symbol หรือ file เท่านั้น โหนดที่ไม่มีสิ่งเหล่านั้นจะคงเป็น “ไม่ทราบ” แทนที่จะอนุมานจากข้อความร้อยเรียง

อนุมัติครั้งเดียว แล้วรันแบบดีเทอร์มินิสติก

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

การอนุมัติยังสร้างโครงรองรับที่งานต้องใช้ด้วย:

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

วงจรชีวิต

proposed → approved → executing → synthesizing → completed
                  ↘                 ↘              failed
                   ↘                 ↘            cancelled

สถานะ	ความหมาย
proposed	แผนพร้อมแล้วและรอการอนุมัติล่วงหน้าครั้งเดียวของคุณ
approved	คุณอนุมัติแล้ว กำลังจัดทำ (การจ้าง ทีม โปรเจกต์ ไปป์ไลน์)
executing	ไปป์ไลน์ที่สร้างขึ้นกำลังรัน: ตั๋วงานย่อย การอภิปราย งาน
synthesizing	ตั๋วงานย่อยเสร็จแล้ว ขั้นตอนการสังเคราะห์กำลังผลิตสิ่งที่ส่งมอบ
completed	เสร็จสิ้น: ตั๋วงานหลักถูกทำเครื่องหมายว่าเสร็จ และสิ่งที่ส่งมอบถูกโพสต์ในสเปซที่แชร์กัน
failed	การจัดทำล้มเหลว หรือการรันไปป์ไลน์ที่สร้างขึ้นล้มเหลว
cancelled	คุณยกเลิกมัน

หมายเลขฉบับแก้ไขที่เพิ่มขึ้นทางเดียวจะติดตามข้อเสนอขณะตัวประสานงานแก้ไขมัน ในตอนที่สถานะยังเป็น proposed อยู่ แอปบันทึกว่าคุณอนุมัติฉบับแก้ไขใด propose_orchestration จะปฏิเสธฉบับแก้ไขเมื่อสถานะไม่ใช่ proposed อีกต่อไป

การประสานงานเปิดขึ้นบนตั๋วงานหลักเสมอและใช้สเปซอภิปรายร่วมกันหนึ่งสเปซ ความพยายามทั้งหมดจึงตามรอยกลับไปยังรายการงานเดียวได้ และทีมคุยกันในห้องเดียว

เกิดอะไรขึ้นเมื่อมันเสร็จสิ้น

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

คุณยกเลิกการประสานงานได้ทุกเมื่อ การยกเลิกจะรื้องานที่กำลังดำเนินอยู่ทิ้ง

หมายเหตุ

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

ดูเพิ่มเติม

• ไปป์ไลน์และระบบอัตโนมัติ: เอนจินที่การประสานงานที่จัดทำแล้วรันอยู่
• ตั๋วงานและการมอบหมาย: ตั๋วงานหลักที่การประสานงานยึดเกาะ
• โมเดลเอเจนต์: บทบาทที่การประสานงานเติมหรือจ้าง
• รันการประสานงาน
• ทำงานใน Plan Studio