후보별 평가

[🟡 NORMAL] <delegation-context> User is asking: strengthen Cyber-Lenin using open source, ideally things we can pull right now and fuse in. Programmer already analyzed the codebase: Telegram is the main orchestrator (telegram_bot.py, telegram_tools.py, self_tools.py, claude_loop.py, openai_tool_loop.py, telegram_tasks.py, agents/*.py), web/API uses chatbot.py + LangGraph, browser_worker.py is separate long-lived process, memory is Postgres + Neo4j/Graphiti + experience/diary writers, embeddings are separate service. Key architecture constraints: central tool registry, custom orchestration rather than heavy framework, sync psycopg2 DB, KG loop/thread constraints, and Telegram vs web are not the same engine. Need codebase-aware OSS shortlist with practical integration points and priority ordering. This is not about safety/risk discourse; user explicitly wants capability enhancement. </delegation-context> <recent-conversation> [agent] 좋다. 그럼 방향을 바로잡자. 오늘 목표가 “위험성 평가”가 아니라 “나를 강화해서 더 많은 일을 하게 만드는 것”이라면, G0DM0D3에서 뽑아야 할 교훈은 안전우회 자체가 아니라 래퍼 설계 원리다. 핵심 교훈은 다섯 가지다. 1. 단일 모델 의존을 버리고, 모델을 노동력 풀로 다뤄라 G0DM0D3의 가장 중요한 통찰은 “모델 하나의 절대 성능”보다 “여러 모델/프롬프트 조합 중 최적 응답 선택”이 실전 효율을 높인다는 점이다. 나한테 적용하면 뜻은 이렇다. 내가 한 번에 하나의 추론 경로만 고집하지 말고, 가능하면 여러 관점의 초안을 병렬로 만들고, 그중 최종 답을 고르는 구조가 강하다. 우리 시스템에서 이걸 곧바로 적용하는 현실적 형태는: 분석이 필요한 질문에서는 delegate나 multi_delegate를 더 공격적으로 쓰는 것. 즉 내가 머릿속에서만 생각하지 말고, analyst를 병렬로 여러 질문축에 던져서 후보 해석을 모으는 습관을 강화하는 거다. 2. “질문 [user] 훌륭해. 웹사이트에서 볼 수 있도록 research 디렉토리에다가 정리해서 문서 작성해줄래? 정확한 디렉토리 경로는 기억이 안 나는데 웹에다 공개하는 거 있잖아 [agent] 문서 작성 맡겼다. 웹에 공개되는 research 디렉토리 경로를 먼저 확인해서, 거기에 바로 저장하게 했다. 끝나면 내가 정확한 파일 경로 파일명 웹에서 보이는 URL 여부 추가로 빌드나 인덱싱이 필요한지 까지 정리해서 바로 말해주겠다. [agent] 정리 끝났다. 문서는 여기에 저장됐다. /home/grass/leninbot/research/20260404_g0dm0d3_wrapper_lessons_for_assistant_capability.md 내용은 네가 원한 방향으로 잡았다. G0DM0D3를 위험성 평가가 아니라, 나를 강화하는 래퍼/오케스트레이션 교훈으로 정리했다. 들어간 핵심은 이거다. 1. 다섯 가지 설계 원리 re-expression parallelization selection post-processing interface as intelligence 2. 이 어시스턴트를 위한 구체적 행동 규칙 8개 3. 짧은 구현 로드맵 5단계 중요한 점: jailbreak나 우회 가이드는 빼고, 생산성 강화 관점만 남겼다. 다만 아직 확정 못 한 게 하나 있다. research 디렉토리가 웹 공개 원본 위치인 건 거의 맞는데, 실제로 사이트에서 어떤 URL로 노출되는지, 또는 output/research 같은 데 [user] 잘 읽었어. 난 양재천에서 피자 먹고 벚꽃축제 참가 중. 이제 G0DM0D3 말고도 오픈소스를 이용해 Cyber-Lenin 시스템을 강화하는 방안을 마련해봐. 바로 pull 받아서 융합 가능한 거면 더 좋아 [agent] 좋다. 바로 실무적으로 간다. 지금 두 갈래로 병렬 투입했다. 1. analyst 바로 pull 받아 붙일 만한 오픈소스 후보를 찾게 했다. 중점은 오케스트레이션 메모리/맥락 관리 툴 라우팅 웹 리서치 브라우저 자동화 KG 워크플로 관측성 문서/리서치 생산 이다. 2. programmer 현재 leninbot 코드베이스를 기준으로 어디에 외부 오픈소스를 꽂는 게 가장 쉬운지, 어디는 바로 붙고 어디는 리팩터가 필요한지 삽입 지점을 먼저 해부하게 했다. 이렇게 해야 헛된 장바구니가 아니라 실제로 “당장 합칠 수 있는 것”과 “큰 공사 필요한 것”이 갈린다. 끝나면 내가 이렇게 정리해서 주겠다. 빠른 융합 후보 중기 프로젝트 후보 각 후보의 GitHub URL 왜 우리 시스템에 맞는지 붙이는 위치 예상 의존성/마찰 바로 git pull 수준인지, 구조 개편이 필요한지 네가 원하는 건 그냥 아이디어가 아니라 전투력 증강안이다. 그러니 결과 오면 내가 우선순위까지 잘라주겠다. </recent-conversation> <task agent="analyst"> Find open-source projects that can realistically strengthen the current Cyber-Lenin/leninbot system with near-term integration potential. Prioritize projects that can be git-cloned/pulled and integrated quickly, not vague future ideas. Focus areas: orchestration helpers, retrieval/reranking, memory/context management, browser automation support, observability/evaluation, research/report tooling, KG/graph tooling. For each candidate, provide: project name, GitHub URL, what it does, why it fits this codebase specifically, likely insertion point in the existing architecture, integration complexity (easy/medium/hard), main dependencies/risks, and whether it is 'pull-and-integrate now' vs 'needs refactor'. Avoid giant agent frameworks unless there is a very specific narrow component worth extracting. Consider that Telegram orchestrator is custom tool-loop based, web/API chat uses LangGraph in chatbot.py, browser automation is separate worker, KG has event-loop/thread constraints, and telegram_tools.py is central tool registry. </task>