รูปแบบการส่งต่อเอเจนต์: การกำหนดเส้นทางงานระหว่างเอเจนต์ AI

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

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

รูปแบบการส่งต่อมาตรฐานสี่แบบ

การส่งต่อแบบพุช: ผู้เรียกปลุกผู้รับโดยตรง

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

การส่งต่อแบบพุชคือรูปแบบที่ใช้โดยพรีมิทีฟ handoff() ของ OpenAI Agents SDK (27,133 ดาว GitHub, MIT) ผู้เรียกสามารถส่งฟังก์ชัน input_filter เพื่อลบหรือแปลงฟิลด์บริบทก่อนการถ่ายโอนได้ หากไม่มี input_filter หน้าต่างบริบททั้งหมด รวมถึงเนื้อหาที่ละเอียดอ่อนที่สะสม จะส่งไปยังผู้รับ

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

การจัดส่งแบบดึง: ผู้รับเรียกร้องจากคิวที่แชร์

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

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

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

การกำหนดเส้นทางกระดานดำ: การแยกบริบทตามตัวชี้

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

ฟังก์ชัน hand_off() ของ OpenLegion ใช้รูปแบบนี้โดยกำเนิด: เขียนข้อมูลเอาต์พุตไปยัง output/{agent_id}/{handoff_id} บนกระดานดำ สร้างรายการงานในกล่องจดหมายของผู้รับพร้อมตัวชี้ไปยังคีย์นั้น และปลุกผู้รับ ข้อมูลรับรองที่เก็บใน Vault ถูกฉีดโดยเมชในเวลาดำเนินการ

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

การส่งต่อแบบสตรีม: การถ่ายโอนบริบทแบบค่อยเป็นค่อยไป

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

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

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

มุมมองของ OpenLegion: เหตุใดการสูญเสียบริบทและการรั่วไหลของข้อมูลรับรองจึงเป็นบักส่งต่อที่แท้จริง

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

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

การรั่วไหลของข้อมูลรับรอง: OWASP LLM06:2025 (การเปิดเผยข้อมูลที่ละเอียดอ่อน) ครอบคลุมการขโมยข้อมูลรับรองผ่านการส่งข้อความระหว่างเอเจนต์อย่างชัดเจนว่าเป็นหนึ่งในช่องโหว่ LLM 10 อันดับแรก

ปัญหาการสูญเสียบริบท: อะไรถูกทิ้งที่ขอบเขต

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

การขโมยข้อมูลรับรองผ่านเพย์โหลดการส่งต่อ (OWASP LLM06:2025)

transfer_to_agent() ของ Google ADK ส่งอ็อบเจ็กต์ Session เต็มรูปแบบรวมถึงประวัติการสนทนาไปยังเอเจนต์รับ สร้างการถ่ายโอนบริบทสูงสุด 32K โทเค็นตามค่าเริ่มต้น ทีมต้องตรวจสอบการนำไปใช้งานการส่งต่อเทียบกับความปลอดภัยของเอเจนต์ AI: การแยกข้อมูลรับรองและการป้องกันการฉีดพร้อมต์

รูปแบบตัวชี้กระดานดำเป็นค่าเริ่มต้นที่ปลอดภัย

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

วิธีที่เฟรมเวิร์กหลักนำการส่งต่อไปใช้

OpenAI Agents SDK: handoff() พร้อม input_filter (27,133 ดาว)

openai/openai-agents-python (27,133 ดาว GitHub, ใบอนุญาต MIT) นำ handoff() ไปใช้เป็นรูปแบบพุช พารามิเตอร์ input_filter เพิ่มในเวอร์ชัน v0.0.5 (มีนาคม 2025) และต้องการการเลือกใช้อย่างชัดเจน

from agents import Agent, handoff, RunContextWrapper

def strip_credentials(ctx: RunContextWrapper, input_data: ResearchInput) -> ResearchInput:
    return ResearchInput(task=input_data.task, context=input_data.context)

researcher = Agent(
    name="researcher",
    handoffs=[handoff(writer_agent, input_filter=strip_credentials)]
)

Google ADK: transfer_to_agent() และการถ่ายโอนอ็อบเจ็กต์ Session (20,100 ดาว)

google/adk-python (20,100 ดาว GitHub, Apache-2.0) นำการส่งต่อไปใช้ผ่าน transfer_to_agent() ซึ่งส่งอ็อบเจ็กต์ Session เต็มรูปแบบรวมถึงประวัติการสนทนา เอเจนต์รับได้รับทุกอย่างและต้องละทิ้งประวัติที่ไม่เกี่ยวข้องอย่างชัดเจน

LangGraph: Command(goto=) พร้อมสถานะที่พิมพ์ร่วมกัน

LangGraph (langchain-ai/langgraph, Apache-2.0) นำการกำหนดเส้นทางเอเจนต์ไปใช้ผ่าน Command(goto='ชื่อโหนด') พร้อมการอัปเดตสถานะที่เป็นทางเลือก สถานะเป็น dict ที่พิมพ์ร่วมกันในโหนดทั้งหมดในกราฟ โมเดลสถานะร่วมกันของ LangGraph ไม่ได้ให้การแยกข้อมูลรับรองระหว่างโหนด

from langgraph.types import Command

def researcher_node(state: AgentState) -> Command:
    result = researcher.invoke(state)
    return Command(
        goto="writer",
        update={"research_output": result, "completed_steps": state["completed_steps"] + ["research"]}
    )

OpenLegion: hand_off() พร้อมตัวชี้กระดานดำและการส่งมอบกล่องจดหมาย

ฟังก์ชัน hand_off() ของ OpenLegion นำการส่งต่อตัวชี้กระดานดำไปใช้โดยกำเนิด

hand_off(
    to="writer",
    summary="การวิจัยเสร็จสมบูรณ์: langchain-alternative, เนื้อหาต้นฉบับ 2847 คำ",
    data='{"topic": "langchain-alternative", "sources_key": "research/langchain-alt-sources", "word_count_target": 3000}'
)

สัญญาข้อมูลการส่งต่อ

สิ่งที่ควรรวม: สรุปงาน คีย์เอาต์พุต ประวัติที่เกี่ยวข้อง

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

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

สิ่งที่ควรแยกออก: ข้อมูลรับรองดิบ หน้าต่างบริบทเต็ม สมุดบันทึกกลาง

แยกออกจากเพย์โหลดการส่งต่อ:

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

กลไกการกำหนดเส้นทางการส่งต่อ

การกำหนดเส้นทางแบบคงที่: ID เอเจนต์ที่กำหนดค่าตายตัว

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

การกำหนดเส้นทางแบบไดนามิก: ผู้เชี่ยวชาญที่เลือกโดย LLM

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

การกำหนดเส้นทางแบบมีเงื่อนไข: การขยับขยายตามกฎ

การกำหนดเส้นทางแบบมีเงื่อนไขใช้กฎแน่นอนเพื่อเลือกเอเจนต์เป้าหมาย คาดเดาได้มากกว่าการกำหนดเส้นทางตาม LLM แต่ต้องการการกำหนดกฎชัดเจนสำหรับทุกเงื่อนไขการกำหนดเส้นทาง

การจัดการ Fallback และการหมดเวลา

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

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

การเปรียบเทียบความปลอดภัยและความน่าเชื่อถือของรูปแบบการส่งต่อ

มิติ	การส่งต่อแบบพุช	การจัดส่งแบบดึง	การกำหนดเส้นทางกระดานดำ	การส่งต่อแบบสตรีม
กลไกการกำหนดเส้นทาง	การเรียกปลุกโดยตรงไปยังผู้รับ	คิวร่วม/การเรียกร้องกล่องจดหมาย	เขียนคีย์+ผู้รับเฝ้าดู	สตรีมโทเค็นแบบค่อยเป็นค่อยไป
การแยกบริบท	ผู้เรียกควบคุมเพย์โหลด ต้องการ input_filter	เฉพาะข้อความคิว	สูงสุด: ผู้รับอ่านเฉพาะคีย์ที่มีชื่อ	ต่ำสุด: บริบทเต็มข้ามขอบเขต
ความเสี่ยงการเปิดเผยข้อมูลรับรอง	ปานกลาง: ขึ้นอยู่กับการเลือกใช้ input_filter	ต่ำ: คิวมีเพียงตัวชี้งาน	ต่ำมาก: ข้อมูลรับรองไม่อยู่ในเพย์โหลดเลย	สูง: สตรีมอาจมีบริบทที่ละเอียดอ่อน
การสังเกตการณ์	เหตุการณ์ติดตามเดียวต่อการส่งต่อ	ความลึกคิว+เหตุการณ์การเรียกร้อง	ประวัติเวอร์ชันคีย์+เหตุการณ์กล่องจดหมาย	ต้องการการติดตามระดับโทเค็น
เวลาแฝง	ต่ำสุด	ต่ำ (ค่าใช้จ่ายการอ่านคิว)	ต่ำ (ค่าใช้จ่ายการอ่านกระดานดำ)	ต่ำสุดตลอดสาย (สตรีม)
เหมาะสำหรับ	การมอบหมายผู้เชี่ยวชาญที่เชื่อมโยงแน่น	พูลผู้ทำงานที่ปรับสมดุลโหลด	ไปป์ไลน์แบบอะซิงโครนัสที่แยกออก	การทำงานร่วมกันแบบเรียลไทม์

คำถามที่พบบ่อย

รูปแบบการส่งต่อเอเจนต์คืออะไร?

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

OpenAI Agents SDK นำการส่งต่อไปใช้อย่างไร?

OpenAI Agents SDK (27,133 ดาว GitHub, MIT) นำ handoff() ไปใช้เป็นรูปแบบพุช เอเจนต์ผู้เรียกเรียก handoff() พร้อมเอเจนต์เป้าหมายและฟังก์ชัน input_filter ที่เป็นทางเลือกซึ่งลบฟิลด์ออกจากบริบทก่อนการถ่ายโอน พารามิเตอร์ input_filter เพิ่มในเวอร์ชัน v0.0.5 (มีนาคม 2025) และต้องการการเลือกใช้อย่างชัดเจน หากไม่มี หน้าต่างบริบทเต็มจะส่งไปยังผู้รับ

Google ADK นำการส่งต่อเอเจนต์ไปใช้อย่างไร?

Google ADK (20,100 ดาว GitHub, Apache-2.0) ใช้ transfer_to_agent() ซึ่งส่งอ็อบเจ็กต์ Session เต็มรูปแบบรวมถึงประวัติการสนทนาไปยังเอเจนต์รับ ซึ่งสร้างการถ่ายโอนบริบทสูงสุด 32K โทเค็นตามค่าเริ่มต้น เอเจนต์รับได้รับประวัติเต็มและต้องละทิ้งบริบทก่อนหน้าที่ไม่เกี่ยวข้องอย่างชัดเจน

รูปแบบการส่งต่อด้วยตัวชี้กระดานดำคืออะไรและทำไมจึงปลอดภัยกว่า?

ในการส่งต่อด้วยตัวชี้กระดานดำ ผู้เรียกเขียนเอาต์พุตไปยังคีย์ที่มีชื่อในร้านค้าที่แชร์ (เช่น output/agent-id/task-id) จากนั้นส่งเฉพาะตัวชี้คีย์ไปยังผู้รับ ไม่ใช่ข้อมูลเอง ผู้รับอ่านเฉพาะฟิลด์ที่ต้องการ ข้อมูลรับรองไม่ปรากฏในข้อความส่งต่อเลย ซึ่งขจัดเวกเตอร์การขโมย OWASP LLM06:2025 ฟังก์ชัน hand_off() ของ OpenLegion นำรูปแบบนี้ไปใช้โดยกำเนิด

ความเสี่ยงด้านความปลอดภัยใดที่มีอยู่ในการส่งต่อเอเจนต์?

ความเสี่ยงหลักคือการขโมยข้อมูลรับรอง: เฟรมเวิร์กที่รวมตัวแปรสภาพแวดล้อม โทเค็นผู้ถือ หรือคีย์ API ในอ็อบเจ็กต์บริบทที่ส่งระหว่างการส่งต่อจะเปิดเผยต่อเอเจนต์รับที่อาจถูกบุกรุก OWASP LLM06:2025 ระบุว่านี่เป็นช่องโหว่ LLM 10 อันดับแรก ความเสี่ยงรองคือการวางยาพิษบริบท

จะจัดการความล้มเหลวในการส่งต่อและการหมดเวลาอย่างไร?

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

ควรรวมข้อมูลใดในเพย์โหลดการส่งต่อ?

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

การส่งต่อเอเจนต์ที่ปลอดภัยใน OpenLegion

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

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

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

สร้างไปป์ไลน์หลายเอเจนต์ที่ปลอดภัยบน OpenLegion →