Workflow เดินตาม code path ที่กำหนด ส่วน agent เลือก process / tool แบบไดนามิก และ autonomy แลกกับ predictability, latency และ cost [4]
งานวิจัย
ข้อเสนอที่ต้องทนต่อทางเลือกที่แข็งแรงที่สุด
หลักฐานรองรับองค์ประกอบ แต่ยังไม่พิสูจน์ความจำเป็นหรือความเหนือกว่าของ HelmLoop
เวอร์ชัน Markdown ↗HelmLoop
เหตุผลเชิงวิวัฒนาการ
Runtime สมัยใหม่มี graph routing, persistence, interrupts, replay, handoffs, guardrails และ traces อยู่แล้ว [1][2][3][5][7][8]
HelmLoop เสนอ portable contract boundary สำหรับ authority, evidence freshness, promotion และ observed outcomes เมื่อ graph completion ตัดสินเรื่องสำคัญไม่ได้ [9][11]
HelmLoop
ทางเลือกการออกแบบ
เก็บ control ไว้ใน graph
เหมาะที่สุดเมื่อ runtime, team และ risk model เดียวเป็นเจ้าของ lifecycle ทั้งหมด และเป็นทางเลือกที่แข็งแรงที่สุด
ใช้ durable workflow engine
เหมาะเมื่อ replay, queue, timer และความน่าเชื่อถือของงานระยะยาวเป็นปัญหาหลัก
ใช้เฉพาะ assurance SOP
เหมาะเมื่อ validation และ release governance สำคัญ แต่ไม่ต้องเรียนรู้ outcome ข้ามรอบ
ใช้ HelmLoop contract
อาจมีประโยชน์เมื่อหลาย runtime ใช้ accountable promotion และ outcome policy ร่วมกัน แต่ยังไม่พิสูจน์แบบ cross-runtime
HelmLoop
ข้อโต้แย้งและ failure modes
Over-engineering
ต้นทุน L2/L3 governance อาจมากกว่าคุณค่าของ task ที่ย้อนกลับได้
Self-confirming loop
ผู้เสนอ ผู้ตรวจ และผู้เรียนอาจใช้ model หรือ context เดียวกัน
State explosion
Receipt, retry, exception และ nested instance อาจควบคุมยากกว่า graph
Verification cost
Fresh independent evidence เพิ่ม latency และค่า provider
Vendor coupling
Checkpoint หรือ tracing semantics อาจรั่วผ่าน adapter และทำลาย portability
Category inflation
HelmLoop อาจเป็นเพียงการตั้งชื่อใหม่ให้ application architecture ที่ดี หาก portability test ล้มเหลว ต้องยุบคำอ้างเรื่องหมวดแยก
HelmLoop
อ่านหลักฐานตามขอบเขตจริง
fixture ไม่รับรอง runtime จริง portability ความพร้อม production หรือคุณค่าทางธุรกิจ
- ยังไม่มีคู่ runtime observation ที่เป็นอิสระ fresh ผ่าน host attestation และ source-bound โดย fixture กับ runtime alias ไม่มีสิทธิ์นับ
- ยังไม่มี production control plane หรือ live provider reconciliation service
- Semantic review หลายภาษาตรวจอัตโนมัติเฉพาะ shape และ terminology ยังไม่มี human attestation อิสระ
- ยังไม่ได้วัด outcome benefit เทียบกับต้นทุน governance ที่เพิ่มขึ้น
HelmLoop
แหล่งข้อมูลปฐมภูมิ
External claims ใช้เฉพาะเอกสารทางการ องค์กรมาตรฐาน และงานวิจัยต้นฉบับ คำอธิบายไม่ใช่หลักฐานการ implement
- 01 / OpenAI
Agent orchestration ↗
อธิบายว่า specialist ที่ manager ควบคุมและ handoff เป็นตัวเลือก orchestration ที่ต่างกัน
- 02 / OpenAI
Guardrails — OpenAI Agents SDK ↗
Guardrail ผูกกับ boundary ของ agent และ tool บางจุด ไม่ได้ครอบทุกเส้นทางอัตโนมัติ
- 03 / OpenAI
Tracing — OpenAI Agents SDK ↗
Trace บันทึก event ของ model, tool, handoff และ guardrail เพื่อ debugging และ monitoring
- 04 / Anthropic
Building Effective AI Agents ↗
แยก workflow ออกจาก agent และแนะนำให้เพิ่ม complexity เมื่อ outcome คุ้มค่าเท่านั้น
- 05 / LangChain
LangGraph overview ↗
อธิบาย durable stateful graph orchestration และ human-in-the-loop capability
- 06 / LangChain
LangGraph interrupts ↗
Interrupt เก็บ state และรัน node ซ้ำ ทำให้ idempotency เป็นเรื่องสำคัญ
- 07 / Temporal
Temporal Workflow ↗
Event history และ deterministic replay แยก workflow code ออกจาก external activity
- 08 / Google
Template agent workflows — ADK ↗
บันทึกโครงสร้าง sequential, loop, parallel และ graph workflow
- 09 / Model Context Protocol
MCP Architecture ↗
วาง consent, security policy และ authorization decision ไว้ที่ host boundary
- 11 / NIST
AI Risk Management Framework ↗
จัดงาน lifecycle risk ด้วย Govern, Map, Measure และ Manage
- 12 / ICLR / arXiv
ReAct: Synergizing Reasoning and Acting in Language Models ↗
สลับ reasoning กับ action และใช้ observation ปรับ plan แต่ไม่พิสูจน์ business outcome