Build a Working AI Agent: A Practical Glossary

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

ลูปหลัก

Every agent ไม่ว่าจะโปรโมต อย่างไร ก็ทำงานในรูปแบบลูปเดียวกัน: สังเกต คิด กระทำ ทำซ้ำ อย่างชัดเจน:

1. Agent ได้รับงาน ("หาตั๋วเครื่องบินที่ถูกที่สุดไปลิสบอนเดือนหน้า และเขียนอีเมลสรุป").
2. มันเรียก LLM ด้วยงานบวกกับคำอธิบายเครื่องมือที่มีอยู่.
3. โมเดลส่งคืนคำตอบสุดท้ายหรือเรียกใช้เครื่องมือ เช่น search_flights(destination="Lisbon", month="2025-06").
4. โค้ดของคุณเรียกใช้ฟังก์ชันนั้น ได้ผลลัพธ์จริง และให้อาหารเข้าไปในบริบทของโมเดล.
5. โมเดลตัดสินใจว่าต่อไปจะทำอะไร: เรียกเครื่องมืออื่น ขอคำชี้แจง หรือเสร็จสิ้น.

รูปแบบนี้เรียกว่า ReAct loop (reason plus act) มักจะ และเป็นกระดูกสันหลังของเฟรมเวิร์ก เช่น LangChain's agent executors, LlamaIndex agents, และ OpenAI's function-calling API คุณสามารถเขียนทั้งหมดเองได้ในน้อยกว่า 100 บรรทัดของ Python ด้วย LLM API และ while loop เท่านั้น — เฟรมเวิร์กเพิ่มความสะดวก ไม่ใช่มmagic

เครื่องมือคือสิ่งที่ทำให้มันเป็น agent

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

def get_weather(city: str) -> str:
    """Return current weather for a given city."""
    resp = requests.get(f"https://api.weather.example/v1/{city}")
    return resp.json()["summary"]

ด้วย OpenAI's function-calling คุณส่ง JSON schema ไปพร้อมกับฟังก์ชันนี้ และโมเดลส่งออกการเรียกแบบโครงสร้าง เช่น {"name": "get_weather", "arguments": {"city": "Lisbon"}} แทนข้อความอิสระ โค้ดของคุณแยก วิเคราะห์ เรียกใช้ฟังก์ชันจริง และส่งคืนผลลัพธ์เป็นข้อความใหม่ในการสนทนา ทำซ้ำจนกว่าโมเดลมีข้อมูลเพียงพอสำหรับการตอบ

หน่วยความจำและสถานะ

การเรียก API ครั้งเดียวไม่มีหน่วยความจำเกินกว่า context window ของมัน Agent ต้องมีสถานะที่ชัดเจน: รายการข้อความที่กำลังทำงาน (ประวัติการสนทนา) และมักจะมีพื้นเก็บข้อมูลแยกต่างหากสำหรับข้อเท็จจริงระยะยาว สำหรับงานสั้นๆ รายชื่อ Python ของ dicts ที่แสดงการสนทนาก็พอเพียง สำหรับ agent ที่ต้องจำสิ่งต่างๆ ระหว่างเซสชัน คุณจะใช้ vector database (Chroma, Pinecone, Qdrant) เพื่อเก็บและเรียกข้อมูลอดีตที่เกี่ยวข้องผ่าน embeddings

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

ตัวอย่างการทำงานขั้นต่ำ

นี่คือรูปแบบของ agent พื้นฐานที่ใช้ OpenAI's API โดยไม่มีเฟรมเวิร์ก:

messages = [{"role": "user", "content": "What's the weather in Lisbon?"}]

while True:
    response = client.chat.completions.create(
        model="gpt-4o",
        messages=messages,
        tools=[weather_tool_schema],
    )
    msg = response.choices[0].message
    if msg.tool_calls:
        for call in msg.tool_calls:
            result = get_weather(**json.loads(call.function.arguments))
            messages.append(msg)
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": result,
            })
    else:
        print(msg.content)
        break

นั่นคือ agent ที่ทำงานได้จริง ส่วนที่เหลือ — ลักษณะการวางแผน การประสานงาน multi-agent การดึงข้อมูล — สร้างขึ้นจากลูปนี้

จุดที่มันล้มเหลว

Agent ล้มเหลวในรูปแบบที่สามารถคาดการณ์ได้: ลูปการเรียกเครื่องมือไม่สิ้นสุดเมื่อโมเดลไม่สามารถบอกได้ว่าประสบความสำเร็จ การโต้แย้งฟังก์ชันที่ประดิษฐ์ขึ้น และค่าใช้จ่ายที่วิ่งออกมาจากการเรียกเครื่องมือที่มีค่าแพงซ้ำแล้วซ้ำเล่า ป้องกันลูปด้วยข้อจำกัดการวนซ้ำที่ยากเหล่านั้น (เช่น 10 ขั้น) และบันทึกทุกการเรียกเครื่องมือระหว่างการพัฒนา ยืนยันอาร์กิวเมนต์ก่อนเรียกใช้สิ่งใดที่เกี่ยวข้องกับระบบจริง — agent ที่สามารถส่งอีเมลหรือเรียกใช้คำสั่ง shell ต้องการการทำความสะอาดอินพุตแบบเดียวกับที่คุณใช้กับโค้ดที่มองเห็นผู้ใช้ เพราะ LLM เป็นผู้ใช้ที่ไม่น่าเชื่อถือโดยพื้นฐานในการสร้างอินพุตนั้น

ที่ไหนต่อไป

เมื่อลูปทำงาน ปัญหาที่น่าสนใจเริ่มต้นขึ้น: การเลือกระหว่างการออกแบบ single-agent และ multi-agent การตัดสินใจว่าให้สิทธิอิสระเพียงใด และการทดสอบ agent อย่างน่าเชื่อถือเมื่อผลลัพธ์ไม่ใช่เรื่องกำหนด Korra Studio's AI และ Python tracks ครอบคลุม retrieval-augmented generation เรื่องการออกแบบ prompt และรูปแบบ tool-calling ในรายละเอียดเพิ่มเติมถ้าคุณต้องการเก่งขึ้นจากที่นี่