useStream은 왜 이렇게 고집이 센가요?

맞아요, LangChain의 스트리밍 방식은 좀 이상할 정도로 고집이 세죠. 그냥 일반 엔드포인트 뒤에서 에이전트를 돌리고 싶다면, FastAPI(나 Next.js)에서 SSE를 사용하고 에이전트를 단순 비동기 제너레이터로 처리하는 게 제일 좋더라고요. 그 후 툴 이벤트를 간단한 이벤트 스키마(토큰, 툴 호출, 툴 결과, 최종 결과)로 감싸는 거죠. 별도의 서버를 강제하지 않으면서 에이전트 엔드포인트와 툴 라우팅을 구성하는 패턴을 참고하고 싶다면 이런 걸 북마크해두고 있습니다: https://

정보 감사합니다. 전 LangChain의 JS 라이브러리를 사용 중이에요. .streamEvents를 통해 스트리밍하고 그걸 ai-sdk UI 메시지 스트림으로 변환하고 있죠. 그게 제 현재 설정입니다.

ai-sdk 어댑터 쓰는 게 정답임. 나도 똑같이 빡쳐서 그렇게 해결했음. FastAPI 엔드포인트로 LangChain 에이전트 감싸고, ai-sdk langchain 어댑터 써서 SSE로 토큰 스트리밍하는 방식임. 원치 않는 LangGraph 서버 안 써도 깔끔하게 잘 돌아감. 팁 하나 주자면, useStream은 아예 건너뛰고 LangChain의 .stream() 이벤트를 FastAPI의 SSE 응답으로 바로 쏴버리는 게 나음. 프론트엔드는 EventSource나 ai-sdk의 useChat으로 받으면 되고.

너 구현할 때 메시지만 스트리밍했어, 아니면 상태(state)도 같이 스트리밍했어? 나도 상태까지 어떻게 포함시킬지 고민 중이라서.

LangChain이 고집 센 것처럼 느껴지는 건 스트리밍 설계 자체가 에이전트 오케스트레이션이나 상태 유지 워크플로우랑 너무 밀접하게 엮여 있어서 그래. 기본적으로 특정 서버 패턴을 강요하는 꼴이지. 그냥 프론트엔드 스트리밍만 하고 싶으면, 모델 토큰이나 이벤트를 SSE나 웹소켓으로 쏴주는 간단한 백엔드 엔드포인트만으로도 충분함. 굳이 풀 프레임워크 스택 다 가져올 필요 없음.