PlutoJoshua

Orchestrator는 Agent가 아니다

작성자:

멀티 에이전트에서 ‘통제자’의 역할을 분리하며 배운 것들 지난 글에서 State와 Message Bus의 역할을 혼동하며 겪었던 혼란을 정리했다. 그 글 마지막에 이렇게 썼다. “다음 글에서는 이 State를 누가 관리해야 하는지, 이 역할의 경계를 중심으로 정리해보려 한다. 이번 글은 그 이야기다. 1. “누가 이걸 결정한 거지?”가 반복되는 순간 멀티 에이전트를 만들다 보면 처음에는 역할 분담이 깔끔해 보인다. … 더 읽기

에이전트는 생각보다 ‘대화’가 어렵다

작성자:

— 멀티 에이전트에서 State와 메시지 버스로 상태를 관리하며 겪은 혼란 멀티 에이전트를 설계하기 시작하면자연스럽게 이런 생각이 든다. “각자 역할을 나눠서 서로 이야기하게 하면 되지 않을까?” 사람 팀처럼 말이다. 내가 만들던 멀티 에이전트 구조도 그랬다.Planner가 계획을 세우고,Executor가 코드를 실행하고,Reviewer가 결과를 검토한다. 겉으로 보면 꽤 그럴듯한 협업 구조다.단일 Agent보다 더 똑똑해 보이기도 하고실제로 역할 분담도 명확해 보였다. … 더 읽기

Agent 설계에서 LLM에게 맡기면 안 되는 판단 3가지

작성자:

LLM은 “판단하는 도구”이지,시스템의 규칙과 책임까지 대신 설계해주지는 않는다. LangChain으로 Agent를 설계하다 보면 어느 순간부터 이런 프롬프트를 쓰고 있는 나를 발견하게 된다 “적절히 판단해서 처리해줘” “상황에 맞게 알아서 결정해줘” 이게 나만의 문제는 아니라고 생각한다 LLM은 너무 똑똑해보이고 실제로 웬만한 질문에는 그럴듯한답을 내놓기 때문이다. 특히 멀티 에이전트 구조를 만들 때는 더 그렇다 각 에이전트가 역할을 나눠서 추론하고, … 더 읽기

LangChain으로 Agent를 만들 때, 왜 항상 ‘구조’에서 막힐까

작성자:

튜토리얼은 따라가는데 혼자 설계하려면 손이 멈추는 이유 AI 개발자에 입문하면 가장 많이 듣는 툴, LangChain. LangChain 공식 튜토리얼을 보면 에이전트를 만드는 건 생각보다 쉬워 보인다. Tool 붙이고, Memory 추가하고, Agent를 하나 선언하면 끝이다. 그런데 막상 내 문제를 풀어보려고 하면 손이 멈춘다. “뭐부터 해야 하지?” 이 글은 에이전트가 무엇인지 설명하려는 글이 아니다. 왜 혼자 설계하려고 하면 … 더 읽기