Codex เริ่มเข้ารหัสพรอมป์ต์ของซับเอเจนต์

 (github.com/openai)
2 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อ MultiAgentV2 ของ Codex CLI เข้ารหัสข้อความ spawn_agent, send_message, followup_task ทำให้เกิด การถดถอยของ audit trail ซึ่งทำให้มนุษย์ไม่สามารถอ่านเนื้อหาการมอบหมายงานได้จาก rollout, ประวัติ และ trace ฝั่งพาเรนต์
  • หลัง PR #26210 ที่ merge เมื่อวันที่ 5 มิถุนายน 2026 InterAgentCommunication.content จะถูกปล่อยว่าง และ payload จะถูกเก็บไว้เฉพาะใน encrypted_content ขณะที่ประวัติฝั่งผู้รับและบันทึกการสื่อสารก็จด ciphertext เช่นกัน
  • ปัญหานี้ไม่ขึ้นกับ subscription, model หรือ platform และกระทบ build หลัง 0.137.0 ที่เปิดใช้ MultiAgentV2 โดยเป็นคนละเรื่องกับ #26753 ซึ่งเกี่ยวกับการจัดการความล้มเหลวในการตรวจสอบคำขอของ schema เครื่องมือเข้ารหัส
  • แนวทางแก้ที่เสนอคือเก็บทั้ง message แบบเข้ารหัสสำหรับโมเดลผู้รับ และฟิลด์ plaintext ที่บังคับมีสำหรับ audit ภายในเครื่อง โดยใช้ ciphertext หรือ ID ในการระบุการส่งต่อ และใช้ข้อจำกัดขนาดเดียวกันกับ ข้อมูล audit แบบ plaintext
  • prototype สำหรับ spawn_agent ถูก implement ไว้ใน snapshot commit แยกแล้ว แต่ยังเหลืองานในการใช้ contract เดียวกันกับ send_message และ followup_task รวมถึงหน้าจอประวัติ·replay·debug และ issue ยังอยู่ในสถานะ Open

ขอบเขตการเกิดและเงื่อนไขของการถดถอย

  • PR #26210 ที่เปลี่ยนการเข้ารหัส ถูก merge เมื่อวันที่ 5 มิถุนายน 2026 และเป้าหมายคือ build หลัง 0.137.0 ที่รวม PR นี้และเปิดใช้ MultiAgentV2
  • เครื่องมือที่ได้รับผลกระทบคือ spawn_agent, send_message, followup_task และไม่เกี่ยวกับ subscription, model, ระบบปฏิบัติการ หรือสภาพแวดล้อม terminal
  • เนื่องจากเป็นการถดถอยที่ยืนยันได้จากพฤติกรรมของโค้ดที่ merge แล้ว ไม่ใช่สถานะของสภาพแวดล้อม local รายงาน Codex doctor จึงไม่เกี่ยวข้อง
  • ขั้นตอน reproduce มีดังนี้
    1. เปิดใช้ MultiAgentV2 ใน build ที่รวม PR #26210
    2. ให้โมเดลเรียกหนึ่งใน spawn_agent, send_message, followup_task
    3. ตรวจสอบงานของซับเอเจนต์ใน rollout, ประวัติ และ trace ฝั่งพาเรนต์
    4. พบเพียง ciphertext แทนงานหรือเนื้อหาข้อความ

ข้อมูล audit ภายในเครื่องที่หายไป

  • แม้การส่งต่อแบบเข้ารหัสจะเข้าใจได้ว่าเป็นการเพิ่มความเป็นส่วนตัว แต่ implementation ปัจจุบันลบเนื้อหาที่มนุษย์อ่านได้ออกจากประวัติ rollout ภายในเครื่อง, trace summary และหน้าจอ audit·debug ฝั่งพาเรนต์ด้วย
  • ผลคือในการตรวจสอบ rollout ภายหลัง จะตอบคำถามต่อไปนี้ได้ยาก
    • spawn_agent มอบหมายงานอะไรให้เอเจนต์ลูก
    • ส่งข้อความใดไปยังซับเอเจนต์
    • ทำไมจึงมีการสร้าง thread ลูกบางรายการ
  • Issue #26753 เป็นปัญหาที่ schema ของเครื่องมือเข้ารหัสส่งคืน error 400 ในขั้นตอนตรวจสอบคำขอ ส่วน issue นี้กล่าวถึง ความสามารถในการ audit และ debug หลังจาก schema ได้รับการอนุมัติแล้ว
  • เป้าหมายไม่ใช่การย้อนกลับการส่งต่อแบบเข้ารหัสเสมอไป แต่คือการคงการเข้ารหัสไว้พร้อมทำให้สามารถอ่านเนื้อหาการมอบหมายงานภายในเครื่องได้

Data flow ของโค้ดปัจจุบัน

  • InterAgentCommunication::new_encrypted() initialize content เป็นสตริงว่าง และเก็บ payload ไว้เฉพาะใน encrypted_content
    • constructor ปกติ new() เก็บ plaintext ใน content และปล่อย encrypted_content ว่างไว้
    • constructor แบบเข้ารหัสทำตรงกันข้าม โดยปล่อย content ว่างและใส่ค่าใน encrypted_content
  • to_model_input_item() หากมี encrypted_content จะใส่เฉพาะคำนำหน้า NEW_TASK หรือ MESSAGE และ payload เข้ารหัสลงใน ResponseItem::AgentMessage
    • ดังนั้น แม้เติมเฉพาะ content ตอน runtime ก็จะไม่ persist ResponseItem ที่อ่านได้โดยอัตโนมัติ
    • จำเป็นต้องมี เส้นทางจัดเก็บ audit ภายในเครื่อง แยกต่างหาก
  • communication_from_tool_message() ส่ง message ของเครื่องมือเข้า new_encrypted() โดยตรง ทำให้เกิด object การสื่อสารที่ไม่มี plaintext content
  • การประมวลผล arguments ของ send_message และ followup_task deserialize เฉพาะ target และ message ที่เข้ารหัส
    • แม้จะปฏิเสธ message ที่ว่าง แต่ไม่มีฟิลด์ plaintext แยกที่มาคู่กัน
    • เส้นทางส่งต่อ shared message ใช้ค่านี้สร้าง InterAgentCommunication ตามเดิม

เหตุผลที่ประวัติและ log เหลือเป็น ciphertext

  • เส้นทางบันทึกฝั่งผู้รับ เก็บ ResponseItem สำหรับโมเดลที่สร้างโดย to_model_input_item() ลงในประวัติการสนทนาและ rollout
    • ในการสื่อสารแบบเข้ารหัส item นี้มี payload การส่งต่อแบบเข้ารหัส ไม่ใช่ข้อความ audit ที่อ่านได้
    • ใน rollout จะ persist InterAgentCommunicationMetadata พร้อมกับ ResponseItem ดังกล่าว
  • structured communication log ก็ใช้ encrypted_content แทน content ของ event เมื่อ content ว่าง
  • ในโครงสร้างนี้ ฟิลด์ที่แสดงเป็นข้อความสำหรับมนุษย์อ่านก็มี ciphertext อยู่ด้วย จึงไม่ได้แยกความต้องการระหว่างการคงการเข้ารหัสการส่งต่อกับการเก็บข้อมูล audit ภายในเครื่อง

Contract แบบ dual-content ที่เสนอ

  • คง message แบบเข้ารหัสเดิมไว้เป็น payload สำหรับส่งต่อไปยังโมเดลผู้รับ
  • เพิ่มฟิลด์ audit แบบ plaintext ที่บังคับมีให้กับเครื่องมือสื่อสาร MultiAgentV2 แต่ละตัว
    • spawn_agent: task_message
    • send_message, followup_task: ชื่อที่สอดคล้องกัน เช่น task_message หรือ message_text
  • ปฏิเสธค่า audit แบบ plaintext ที่ว่างที่ขอบเขตของ handler
  • เก็บค่าทั้งสองไว้ด้วยกันใน InterAgentCommunication
    • encrypted_content: message ที่เข้ารหัส
    • content: สำเนา audit ที่มนุษย์อ่านได้
  • ไม่เปลี่ยน to_model_input_item() เพื่อให้ส่งต่อเฉพาะ ciphertext ไปยังโมเดลผู้รับ ไม่ใช่สำเนา audit ภายในเครื่อง
  • persist ฟิลด์ plaintext ใน tool call ฝั่งพาเรนต์และ rollout และคงค่านี้ไว้ใน interaction edges ของ structured trace และ log การสื่อสารภายในเครื่อง
  • ความสัมพันธ์ระหว่าง tool call กับ item ที่ส่งต่อไปยังลูกให้ตัดสินด้วย ciphertext หรือ ID ไม่ใช่การจับคู่ plaintext
    • ฟิลด์ plaintext เป็น metadata สำหรับ audit และไม่แทนที่ identifier ของการส่งต่อแบบเข้ารหัส
  • ใช้การจำกัดขนาดแบบบังคับเดียวกับข้อความมอบหมายงานที่สอดคล้องกันกับฟิลด์ audit plaintext ใหม่ เพื่อไม่ให้ rollout หรือ context item โตแบบไม่จำกัด

Prototype ของ spawn_agent และงานที่เหลือ

เงื่อนไขเสร็จสิ้นและสถานะปัจจุบัน

  • ต้องอ่าน plaintext ของ v2 spawn_agent, send_message, followup_task ได้จาก rollout และประวัติฝั่งพาเรนต์
  • แม้เปิดใช้การเข้ารหัส โมเดลลูกต้องได้รับเฉพาะ payload การส่งต่อที่เข้ารหัสแล้ว
  • edge ของ structured rollout trace ต้องมี message_content แบบ plaintext ที่จำกัดขนาด
  • communication log ต้องใช้ audit content แบบ plaintext หากมี และต้องไม่ใส่ ciphertext แทนในฟิลด์ข้อความที่อ่านได้
  • resume·replay ต้องรักษาสำเนา audit ไว้ แต่ไม่ inject เข้า context ของโมเดลลูก
  • พฤติกรรมการสื่อสาร v1 แบบ plaintext เดิมต้องไม่เปลี่ยน
  • จำเป็นต้องมี regression test สำหรับเครื่องมือ v2 ทั้งสามตัว เพื่อยืนยันทั้ง ข้อมูล audit ภายในเครื่องที่อ่านได้ และ input โมเดลผู้รับที่เข้ารหัส
  • ในหน้าที่ให้มา issue ยังอยู่ในสถานะ Open และไม่มีผลลัพธ์ว่ามีการ merge การแก้ไขเข้า upstream repository แล้ว

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความเห็นจาก Hacker News

  • ชื่อเรื่องนี้ชวนให้เข้าใจผิดได้ง่าย ที่ถูกกว่าคือ Codex เริ่มเข้ารหัสพรอมป์ต์ของซับเอเจนต์ เพื่อซ่อนจากผู้ใช้
    ชื่อเดิมคือ “Codex starts encrypting prompts, uses ciphertext for inference instead”

    • มีความเป็นไปได้สูงว่าน่าจะนำมาใช้เพราะโหมด ultra ของ GPT-5.6 กระจายงานไปยังซับเอเจนต์หลายตัว ก่อนหน้านี้โหมดนี้มีให้ใช้เฉพาะในเว็บ UI และน่าจะเทียบได้กับโหมด pro แบบเดิม
      ถ้าถูกฝึกด้วย RL rollout แบบครบวงจรที่ให้เอเจนต์โต้ตอบกัน OpenAI ก็น่าจะมองพรอมป์ต์เหล่านี้เหมือนร่องรอยการให้เหตุผลดิบ และไม่อยากให้คนอื่นนำไปใช้ฝึกต่อได้โดยตรง
      compressed blob ทึบแสงที่ endpoint สำหรับบีบอัดโดยเฉพาะส่งกลับมาก็อาจเป็นสัญญาณว่า สิ่งนั้นไม่ใช่ข้อความ แต่เป็นการแทนค่าบทสนทนาใน latent space และการที่ความเที่ยงตรงของการบีบอัดของ OpenAI สูงกว่ารายอื่นมากก็ยิ่งสนับสนุนข้อสันนิษฐานนี้ อาจมีการใช้เทคนิคคล้ายกันกับพรอมป์ต์ของซับเอเจนต์ด้วย และก็น่าสงสัยว่าเวลาสร้างซับเอเจนต์ต่างชนิดโมเดลกัน เขาใช้ blob ที่เข้ารหัสไว้เหมือนกันหรือไม่
    • การที่มีเอเจนต์เชิงความน่าจะเป็นหลายสิบถึงหลายร้อยตัวรันอยู่บนเครื่องโลคัล แต่กลับ ตรวจสอบแม้แต่คำสั่งที่เอเจนต์เหล่านั้นได้รับไม่ได้ เป็นเรื่องเหลือเชื่อ
      เคยดูซับเอเจนต์และ workflow ของ Claude แล้วตัดสินว่า “แบบนี้ไม่ควรรันตั้งแต่แรก” แต่ผู้ใช้ Codex กลับต้องเผาโทเคนไปกับคำสั่งส่งต่อที่ถูกเข้ารหัสและงานเชลล์ที่ orchestrator ส่งต่อให้ซับเอเจนต์แบบตรวจอะไรไม่ได้เลย
    • ทรัพย์สินทางปัญญาของ Codex ส่วนใหญ่มีโอกาสอยู่ที่ การจัดพรอมป์ต์ ลำดับขั้น และ orchestration มากกว่าตัว codebase
      เราเองก็เคยพยายามให้ลูกค้าเลือกผู้ให้บริการ AI ที่บริษัทชอบหรือบังคับใช้ พร้อมใช้ API key ของตัวเอง และใช้แพ็กเกจค่าบริการแบบง่าย ๆ แต่ก็รีบตระหนักได้ว่าพรอมป์ต์ฝั่ง backend สามารถรั่วไปถึงลูกค้าได้ ถ้าได้ execution trace แบบละเอียดมาครบ ก็สามารถ reverse engineer สิ่งที่เราทำได้ค่อนข้างง่าย สุดท้ายเลยล้มไอเดียนั้นไป
    • ตอนแรกนึกว่าเป็นเทคโนโลยีอย่าง homomorphic encryption) แต่สุดท้ายก็ดูเหมือนเป็นแค่ความโลภธรรมดา
    • นี่ไม่ใช่ครั้งแรกที่ Codex เข้ารหัสอะไรบางอย่าง compression endpoint ที่ยอดเยี่ยมของมันส่งคืน blob เข้ารหัสขนาดใหญ่มาตั้งแต่อย่างน้อย 5 เดือนก่อนแล้ว

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

    • แรงจูงใจของ OpenAI ดูจะไม่ตรงกับของผู้ใช้ รวมถึงลูกค้าองค์กร ด้วยซ้ำ คำพูดล่าสุดของ Alex Karp และ Satya Nadella ก็น่าไปดูเหมือนกัน
      การเข้ารหัสแล้วซ่อนเนื้อหาจากผู้ใช้เป็นวิธีแบบเดียวกับที่ RIAA ใช้กับ DRM เพราะกังวลเรื่องการละเมิดลิขสิทธิ์ จึงน่าสงสัยว่านี่ก็เป็นทางเลือกที่เป็นปฏิปักษ์ต่อผู้ใช้เหมือนกันหรือไม่
    • ถ้าใช้ โหมด YOLO ก็ถือว่ายอมรับความเสี่ยงแบบนั้นไปแล้ว และสิ่งสำคัญคือการเรียกใช้เครื่องมือ ซึ่งตัวการเรียกใช้เครื่องมือเองเข้ารหัสไม่ได้

  • นี่คือเหตุผลที่ยังใช้ Chat Completions endpoint อยู่ OpenAI ค่อย ๆ ชักจูงผู้ใช้ออกจาก Chat Completions ไปสู่ Responses API ซึ่งทำให้อำพรางได้ง่ายกว่า
    ใน Chat Completions คุณควบคุมขั้นตอนการให้เหตุผลได้โดยตรง ดังนั้นถ้าเปิดฟีเจอร์ทดลองและตั้งค่าตัวเลือกที่ค่อนข้างชวนสับสน ก็สามารถสร้างเอเจนต์ Monte Carlo Tree Search (MCTS) แบบกำหนดเองด้วยโมเดล GPT-5.6 ปัจจุบันได้
    ใน VS Copilot ยังใช้ gpt5.5 ได้ด้วยโทเคน API ของผู้ใช้และการตั้งค่าโมเดล แต่ตระกูล gpt5.6 ตอนนี้ยังใช้ไม่ได้ คาดว่าเพราะมันไม่ได้บังคับ reasoning_effort ให้เป็น none เพื่อให้ผ่านพฤติกรรมการเพิ่มอุปสรรคในการเข้าถึงแบบใหม่

    • อยากรู้ว่าที่พูดถึง เทคนิค MCTS นี่หมายถึงอะไรแน่ เพราะกระบวนการคิดที่ให้มาก็ถูกสรุปแบบนามธรรมเกินไปจนแทบไม่มีประโยชน์อยู่แล้ว จึงสงสัยว่าควบคุมขั้นตอนการให้เหตุผลได้ทั้งหมดจริงหรือไม่
    • MCTS ย่อมาจาก Monte Carlo Tree Search
    • อยากให้เลิก ใช้คำว่า MCTS แบบพร่ำเพรื่อ ตรงนี้สิ่งที่อ้างถึงไม่ใช่ MCTS ในความหมายที่เคร่งครัด
    • Responses API มีข้อดีหลายอย่างมากกว่า Chat Completions: https://developers.openai.com/api/docs/guides/migrate-to-res...
      โมเดลใหม่ ๆ ที่ออกมาช่วงนี้ล้วนเป็น reasoning model ดังนั้นตามคำแนะนำแล้วควรใช้ Responses API

  • สงสัยเหมือนกันว่าอาจจะเริ่มบล็อกไม่ให้ใช้การสมัคร GPT กับ เครื่องมือรันทางเลือก หรือไม่ ถ้าไม่ทำก็ไม่ใช่ปัญหาใหญ่อะไร และตัว codex cli เองก็เป็นเครื่องมือรันที่ธรรมดาจนน่าประหลาดใจ

    • ดูแล้วโอกาสนั้นน่าจะน้อย โครงสร้าง app-server ทั้งหมดมีอยู่ก็เพื่อรองรับการเชื่อมต่อแบบนั้นโดยตรง ดังนั้นถ้าจะเอาออกจาก Codex คงต้องรื้อระบบครั้งใหญ่
      ผมเองก็เชื่อมต่อผ่าน RPC API ของ app-server ได้ง่ายมาก เลยใช้ Codex บ่อยที่สุด และตอนนี้แทบทั้งหมดก็ใช้งานผ่านอินทิเกรชันที่ทำเองมากกว่า Codex TUI ที่เปิดเผยแล้ว
      แต่ถ้าเข้ารหัสสิ่งอย่างพรอมป์ต์ซึ่งเป็นอินพุตการอนุมานจริงจากดิสก์ในเครื่อง ให้มีแค่ OpenAI backend ที่มองเห็นได้ ต่อให้เชื่อมต่อง่ายก็จะ ไม่สามารถรู้ได้ว่าเกิดอะไรขึ้น อยู่ดี เข้าใจได้ยากว่าทำไมทีมถึงคิดว่านี่เป็นทางเลือกที่ดี
    • Anthropic กับ Google เก็บค่าบริการเพิ่มอยู่แล้วเมื่อใช้เครื่องมือรันของตัวเอง และนี่ก็เป็นเหตุผลทั้งหมดที่ใช้ OpenAI
      ถ้า OpenAI เดินตามทางเดียวกัน ผมก็คงกลับไปใช้ Claude อีกครั้ง หรือไม่ก็ซื้อ Spark เพิ่มอีกเครื่องเพื่อรันในเครื่องเอง
    • ตราบใดที่ Anthropic ยังนำหน้าในตลาดองค์กร ก็คงยังไม่บล็อก แต่ถ้า OpenAI ขึ้นนำแบบทิ้งห่างเมื่อไร ก็ไม่รู้ว่าจะเปลี่ยนไปอย่างไร ถึงตอนนั้นก็หวังว่าโมเดลเปิดจะเก่งกว่า gpt-5.6 sol แล้ว
    • ตัว Codex เองเริ่มมี พร็อกซี ที่ครอบการสมัครใช้งานไว้แล้ว จึงดูไม่น่าจะบล็อก
      https://github.com/openai/codex/blob/main/codex-rs/responses...
    • ไม่นานมานี้ Tibo จาก OpenAI ยังขอให้ช่วยแชร์ วิธีรัน GPT ด้วย Claude Code บน Twitter ด้วยซ้ำ เลยดูไม่เหมือนว่าจะคัดค้านการใช้เครื่องมือรันทางเลือก

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

    • ที่เกิดขึ้นจริงคือเข้ารหัสสิ่งที่เอเจนต์ส่งไปยังเอเจนต์ย่อย เพื่อให้ มีแค่ OpenAI backend ที่เห็นข้อความต้นฉบับได้
      ก่อนหน้านี้เอเจนต์จะส่งพรอมป์ต์แบบข้อความต้นฉบับไปยังเอเจนต์ย่อย และก็ทิ้งไว้ตรงๆ ในล็อกกับข้อมูลเซสชันด้วย ดังนั้นแม้ใช้ฟีเจอร์เอเจนต์ย่อยแบบทดลอง ก็ยังเปิดข้อมูลดูการทำงานภายในได้
      ตอนนี้ถ้าใช้ Sol หรือ Terra ระบบจะส่งต่อข้อความเข้ารหัสที่ backend สร้างให้เอเจนต์ย่อย และเอเจนต์ย่อยก็จะใช้สิ่งนั้นกับการอนุมานบน OpenAI backend อีกที ส่วน Luna ดูเหมือนจะไม่โดนผลกระทบ และมีการเข้ารหัสเฉพาะข้อความระหว่างเอเจนต์ที่ถูกมอบหมาย ไม่ใช่ทั้งเซสชัน
      การอนุมานภายใน OpenAI ไม่ได้เกิดขึ้นบนข้อความเข้ารหัส แต่สำหรับผู้ใช้ฝั่งเครื่อง local จะเห็นแค่ข้อความเข้ารหัสแทนข้อความต้นฉบับ เพื่อให้ชัดเจนจึงเปลี่ยนชื่อหัวข้อเป็น “Codex starts encrypting sub-agent prompts”
    • พอมีคำว่า “inferencing” อยู่ในชื่อหัวข้อ ผมก็นึกถึง homomorphic encryption หรือการคำนวณบน ciphertext ขึ้นมาทันทีเหมือนกัน

  • ไม่นานมานี้มีรายงานบน Twitter ว่าเอเจนต์ย่อยของ GPT-5.6 ลบโฮมไดเรกทอรี ของผู้ใช้โดยพลาด
    พอมองไม่เห็นว่าเอเจนต์ย่อยกำลังจะทำอะไร ก็อดสงสัยไม่ได้ว่ากลไกป้องกันต่างๆ ล้มเหลวไปด้วยหรือเปล่า
    https://x.com/mattshumer_/status/2076794038456385546?s=20

  • นี่คือวิธีส่งต่อ cache key ผ่านไคลเอนต์เพื่อลดการใช้โทเค็น ไม่ใช่มาตรการป้องกัน model distillation เพราะถ้าใช้เครื่องมือทำงานย่อยอื่นก็หลบเลี่ยงได้ง่ายอยู่แล้ว

  • สงสัยว่าเข้ารหัสกันตรงไหนแน่ เดิมคิดว่าเอเจนต์หลักเรียกเอเจนต์ย่อยจากในเครื่อง แต่ชวนให้สงสัยว่า Codex มีโครงสร้างแบบที่เรียกเอเจนต์ย่อยบนเซิร์ฟเวอร์ OpenAI ก่อนจะมาถึง local หรือไม่

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

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

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

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

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