ผู้ช่วยที่มีกระบวนการ: การรวมปฏิทินและ Gmail อย่างปลอดภัย

คำกล่าวอ้างของฉัน: การสร้างผู้ช่วยที่มีกระบวนการซึ่งปลอดภัยและใช้งานได้ ซึ่งทำงานบนปฏิทิน, Gmail และแอปเชื่อมต่อ ต้องการการออกแบบระบบดำเนินการที่มุ่งเน้นการอนุญาต, แยกการวางแผนออกจากการดำเนินการ, และการฝังการตรวจสอบและการย้อนกลับลงในชั้นการดำเนินการตั้งแต่วันแรก บทความนี้ให้เช็คลิสต์ทางวิศวกรรมที่ชัดเจนและการเรียกใช้งานได้เพื่อไปถึงจุดนั้น。

การออกแบบการอนุญาตสำหรับผู้ช่วยที่มีกระบวนการ

เริ่มต้นด้วย OAuth ต่อผู้ใช้และขอบเขตที่มีสิทธิ์น้อยที่สุด ใช้ OAuth ที่ผูกกับผู้ใช้แทนที่จะเป็นบัญชีบริการที่ใช้ร่วมกัน ยกเว้นเมื่อผู้ดูแลระบบต้องการการลงนามในโดเมนอย่างชัดเจน เอกสารของ Google เกี่ยวกับขอบเขตที่ละเอียดเป็นมาตรฐาน; เชื่อมโยงความสามารถของแต่ละผู้ช่วยกับขอบเขต OAuth เดียวและเอกสารเจตนาที่อ่านได้โดยมนุษย์สำหรับขอบเขตนั้น ให้วางโทเค็นให้ออกจากคำสั่ง เก็บในตู้เก็บของและฉีดข้อมูลรับรองเพียงแค่ในเวลาที่เรียกใช้ภายในบริการที่บังคับนโยบาย。

เราสังเกตเห็นว่าทีมที่มองว่าอนุญาตเป็น UX ของผลิตภัณฑ์โดยมีหน้าจอการยินยอมและภาพรวมของขอบเขตที่ชัดเจนจะได้รับตั๋วสนับสนุนที่น้อยกว่ามาก หนึ่งปัญหาที่เราเจอคือการแพร่หลายของโทเค็นจากกลไกการรีเฟรชที่ไร้เดียงสา; รวมศูนย์การรีเฟรชและเปลี่ยนโทเค็นการรีเฟรชเป็นประจำ。

การวางแผนเทียบกับการดำเนินการ

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

การแลกเปลี่ยนที่ปฏิบัติได้: ความหน่วงเวลาที่นานขึ้นสำหรับการอนุมัติของมนุษย์เปรียบเทียบกับความเสี่ยงที่ต่ำกว่า สำหรับหลายๆ การดำเนินการในปฏิทินและอีเมล, การหยุดพักคนในวงจร 30 ถึง 60 วินาทีถือว่าเป็นที่ยอมรับได้ สำหรับงานที่ทำซ้ำบ่อย, การอนุมัติแบบกลุ่มจะดีกว่าการคลิกต่อการดำเนินการ。

การทดสอบ, บันทึก และการกู้คืน

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

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

เช็คลิสต์สำหรับผลิตภัณฑ์และวิศวกรรม

1. OAuth ต่อผู้ใช้พร้อมขอบเขตน้อยที่สุดและข้อความยินยอมที่ชัดเจน 2. ตู้เก็บโทเค็นและบริการดำเนินการที่ฉีดข้อมูลรับรองในเวลาประมวลผล 3. การแยกวางแผน/นักแสดงพร้อมการตรวจสอบนโยบาย 4. การประท้วงของมนุษย์ในการดำเนินการที่ละเอียดอ่อน 5. บันทึกตรวจสอบที่ไม่สามารถเปลี่ยนแปลงและรูปแบบการดำเนินการที่เล่นซ้ำได้ 6. การย้อนกลับและการดำเนินการทดแทนที่มี UI ที่ชัดเจน

เชื่อมโยง UX ผลิตภัณฑ์กับรูปแบบการทำงานที่อธิบายไว้ใน การออกแบบเวิร์กโฟลว์ระหว่างมนุษย์- AI และใช้บทนำเกี่ยวกับความแตกต่างของผู้ช่วยใน ผู้ช่วย AI กับแชทบอท เพื่ออธิบายการแยกนักวางแผน/นักแสดง

ลองทำด้วยตัวเอง คำสั่งด้านล่างจะแสดงผลผลิตจากผู้วางแผนเทียบกับคำแนะนำที่ปลอดภัยจากนักแสดง คาดหวังแผนจากผู้วางแผนในรูปแบบ JSON ที่กระชับและการยืนยันที่สั้นจากนักแสดง。

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

คุณเป็นผู้วางแผนการประชุม ผู้ใช้งานมีช่องว่างว่าง 3 ช่องในวันนี้: 10:00 น., 14:30 น., 16:00 น. ส่งคืนเวลาประชุมที่เป็นไปได้สามเวลาตามรูปแบบ ISO พร้อมเหตุผลหนึ่งบรรทัดสำหรับแต่ละเวลา, และหมายเหตุความเป็นส่วนตัวหนึ่งบรรทัดที่บอกว่าเชิญชวนมีอีเมลภายนอกหรือไม่

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

นักแสดง: เมื่อต้องมีโทเค็นการยืนยันจากผู้ใช้ X และแผน Y จากผู้วางแผน, เรียกใช้ Calendar.CreateEvent ด้วยฟิลด์ {start,end,attendees,summary} เฉพาะเมื่อ policy_check(policy_id:calendar_write) คืนค่าผ่าน หาก policy_check ล้มเหลว, คืนค่ารหัสความล้มเหลวและการกระทำที่ต้องการจากมนุษย์

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