재현 가능하지만 아직 수정되지 않은 프로덕션 버그입니다. 각 항목은 증상, 의심되는 영역, 해결 방법(있는 경우)을 명시합니다. 수정이 범위가 정해지고 일정이 잡히면 항목은 버전 섹션으로 이동합니다.
Agent 에디터가 편집 없이 저장되지 않은 변경 경고를 표시합니다./agents/[id]를 통해 기존 agent를 열고 즉시 뒤로 가기를 클릭하면 필드를 건드리지 않았는데도 “Unsaved changes” 대화가 나타납니다. dirty check는 20개 이상의 필드를 로드된 agent payload와 비교하므로, 상태 초기화와 dirty compare 사이의 하나의 비대칭 기본값만으로도 phantom mismatch를 유발하기에 충분합니다. 현재 의심은 중첩된 model_config_json / notification / approval-routing 필드 중 하나이며, 아마도 undefined vs null vs "" 정규화에서 비롯된 것입니다. 특히 org-scoped agent에서 재현됩니다. 해결 방법: 대화를 닫으세요(Discard and leave) — 실제로 변경된 것이 없으므로 데이터 손실이 없습니다. 시도된 수정(cb40c86a)은 resource picker의 관련 orphan-badge flicker를 제거했지만 이 문제를 해결하지 못했습니다.
Agent 편집 저장이 Input should be 'initiator', 'agent_owner' or 'org_members' 오류로 실패할 수 있습니다. Pydantic은 /api/agents/{id} PUT 경계에서 confirmation_approver_scope 필드를 거부합니다. 데이터베이스의 모든 저장된 값이 세 가지 유효한 리터럴 중 하나임에도 불구하고 말입니다. 의심: 프론트엔드 as "initiator" | "agent_owner" | "org_members" 캐스트는 컴파일 타임 전용 약속이므로, 레거시 또는 예상치 못한 런타임 문자열(템플릿, import, 또는 이전 마이그레이션에서 비롯된 것일 수 있음)이 setConfirmationApproverScope를 통과하여 그대로 다시 전송될 수 있습니다. 해결 방법: 저장하기 전에 Approval → Approver Scope 드롭다운에서 명시적으로 값을 다시 선택하세요.
Playground 중지 및 재시도가 페이지 새로 고침으로 항상 지워지는 일시적인 시각적 아티팩트를 표시합니다. 세 가지 동시 렌더 소스 — activeConversation.messages(DB 스냅샷), SSE messages 스트림, optimistic pendingQuery 플레이스홀더 — 가 단일 파생 상태로 축소되지 않으므로, “Retry”를 클릭한 후 쌍을 이루는 assistant 응답이 도착하기 전에 UI는 (a) 사전 스트림 윈도우에서 동일한 쿼리를 잠깐 두 번 렌더링하거나, (b) hasLiveMessages가 true이고 스냅샷이 다시 로드되기 전에 재시도 기록에서 이전 orphan user bubble을 삭제하거나, (c) SSE “done” 이벤트와 다음 selectConversation 새로 고침 사이의 좁은 윈도우에서 깜박일 수 있습니다. 데이터는 절대 손실되지 않습니다 — 모든 user 메시지(중단된 재시도 포함)는 conversation.messages에 지속되고, normalize_alternating_messages를 통해 다음 LLM 호출로 전달되며, 48ba08c6 렌더 수정에서 도입된 HistoryTurn.orphanUserContents를 통해 새로 고침 후 올바르게 렌더링됩니다. 참고로, Claude의 자체 웹 UI는 유사한 클래스의 버그를 나타냅니다 — 응답 중간에 중지하고 즉시 후속 쿼리를 보내면 때때로 후속 쿼리가 첫 번째 쿼리의 sibling-edit 분기로 포크되어 새로운 turn으로 추가되지 않습니다 — 따라서 이는 optimistic-UI + SSE + persisted-history 설계에서 알려진 어려운 문제이지, FIM One 특정 결함이 아닙니다. 적절한 수정은 세 가지 렌더 소스를 단일 파생 상태로 축소해야 하며, 더 광범위한 Playground 상태 머신 리팩토링까지 연기되었습니다.
확장 사고 / 추론 지원 (LLM_REASONING_EFFORT, LLM_REASONING_BUDGET_TOKENS) - OpenAI o-series, Gemini 2.5+, Claude
관리자 도구별 활성화/비활성화 (비활성화된 도구는 런타임에 채팅에서 제외)
MCP 서버 관리를 커넥터 페이지로 이동
이중 데이터베이스 지원: SQLite (제로 설정 기본값) + PostgreSQL (프로덕션); Docker Compose는 PostgreSQL 자동 프로비저닝
모델 구성 문서 페이지 (제공자별 확장 사고 설정 포함)
SSE Protocol v2: delta_reasoning, usage 필드를 포함한 실시간 답변 스트리밍, done/suggestions/title/end 이벤트 분할; SQLite 풀 크기 5 -> 20
AI Builder 확장: 7개의 새로운 빌더 도구 (GetSettings, TestConnection, ImportOpenAPI for connectors; ListConnectors, AddConnector, RemoveConnector, SetModel for agents), 에이전트의 is_builder 플래그, 빌더 프롬프트 자동 새로고침, SSRF 가드
SSE v2 프론트엔드: 스트리밍 점 펄스 커서, 축소 가능한 카드로 표시되는 DAG 재계획 라운드 스냅샷, DAG 레이아웃과 단계 상태 분리
AI Builder 개념 문서 페이지 (커넥터 및 에이전트 빌더 가이드 포함)
조직 시스템: 역할 기반 멤버십 (소유자/관리자/멤버)을 포함한 전체 CRUD, 관리자 관리 UI
에이전트, 커넥터, 지식 기반, MCP 서버에 대한 3단계 리소스 가시성 (개인/조직/전역)
모든 리소스 유형에 대한 게시/게시 취소 API; 게시된 에이전트에 대한 소유자 위임
관리자 설정 가시성 엔드포인트 (복제-전역 대체); 통합 build_visibility_filter() 쿼리 헬퍼
데이터베이스 커넥터 (1-3단계): PG/MySQL/Oracle/SQL Server + 중국 레거시 DB에 대한 직접 SQL 액세스; 스키마 내부 검사, AI 주석, 읽기 전용 쿼리 실행, 암호화된 자격 증명, 커넥터당 3개 도구 (list_tables, describe_table, query)
평가 센터: 정량적 에이전트 품질 벤치마킹 — 테스트 데이터셋 CRUD (프롬프트 + 예상 동작 + 어설션), 평가 실행 (병렬 실행 + LLM 채점자 + 케이스별 통과/실패/지연/토큰 결과), 자동 폴링을 포함한 결과 뷰어; 마이그레이션 r8t0v2x4z567
3가지 모델 역할 (General/Fast/Reasoning) (티어별 env 구성 격리 포함); 빠른 모델은 더 이상 주 모델 설정을 상속하지 않음
구조화된 데이터 및 아티팩트 전달을 위한 일반 문자열 단계 결과를 대체하는 StepOutput 데이터클래스
DAG 실행을 위한 도구 캐시 — 실행당 동일한 도구 호출 캐시 (비동기 잠금 스탬피드 방지 포함) (DAG_TOOL_CACHE)
실패 시 1회 재시도를 포함한 단계별 LLM 검증 (DAG_STEP_VERIFICATION)
자동 라우팅: 빠른 LLM이 쿼리를 ReAct 또는 DAG로 분류; /api/auto 엔드포인트; 프론트엔드 3방향 모드 토글 (AUTO_ROUTING)
Shadow Market 조직 + 리소스 구독: 기본 제공 Market 조직 (shadow, 자동 가입 없음)이 Platform 조직을 대체; 마켓플레이스 브라우징 및 명시적 구독을 통해 발견된 리소스 (풀 모델); 공유 리소스 구독을 위한 Market API; Market에 게시하려면 항상 검토 필요; 리소스 구독 테이블; 전역 가시성을 대체하는 조직 기반 리소스 공유
에이전트 자동 발견 및 하위 에이전트 바인딩: 에이전트의 discoverable 플래그; sub_agent_ids 화이트리스트; 전문가 에이전트에 작업을 위임하기 위한 CallAgentTool
MCP 서버 자격 증명 + 사용자별 재정의: mcp_server_credentials 테이블; PUT /api/mcp-servers/{id}/my-credentials 엔드포인트; 자격 증명 폴백 동작을 위한 allow_fallback 플래그
커넥터/KB 토글: 리소스 일시 중단/재개를 위한 POST /api/connectors/{id}/toggle 및 POST /api/knowledge-bases/{id}/toggle
게시 검토 UI: 조직 수준 게시 검토 시스템 — 조직별 검토 토글, 승인/거부 워크플로우가 있는 ReviewsSheet, 리소스 카드의 상태 배지, 게시 대화상자의 검토 알림, 거부된 리소스에 대한 재제출
연결기 점진적 공개 (Phase 1-2): 단일 ConnectorMetaTool이 작업별 도구를 대체; 시스템 프롬프트는 경량 스텁만 수신 (이름 + 1줄 설명, 연결기당 ~30 토큰 vs 작업당 ~250 토큰); 에이전트가 discover(connector)를 호출하여 전체 작업 스키마를 필요할 때 로드 — 스키마는 모델이 연결기를 선택할 때만 로드되어 캐싱을 위해 프롬프트 접두사를 안정적으로 유지. 최신 에이전트 프레임워크에서 일반적인 지연 도구 로딩 패턴을 따름. execute 부명령; 하위 호환성을 위한 기능 플래그.
에이전트 기술 시스템 + 간결한 지시사항: 에이전트 지시사항을 위한 온디맨드 기술 로딩 — Skill 모델 (이름, 콘텐츠/SOP, 선택적 스크립트)이 에이전트에 첨부됨; 시스템 프롬프트에서 이름으로만 참조됨 (~기술당 10 토큰); 에이전트가 read_skill(name)을 호출하여 전체 콘텐츠를 필요할 때 로드. ConnectorMetaTool의 점진적 공개를 지시사항 수준에 적용하여 대화당 지시사항 토큰 비용을 ~80% 감소. 더 풍부한 SOP 라이브러리 허용. “지시사항 + 도구 + 기술” 차별화 스토리를 활성화. 또한 Agent 모델에 compact_instructions 필드 추가 — 압축 시 ContextGuard에 주입된 에이전트별 압축 우선순위 목록 (예: “주문 ID 및 금액 보존, 원본 API 응답 삭제”), 현재의 정적 일반 프롬프트 대체. 최신 에이전트 프레임워크에서 널리 채택된 간결한 지시사항 규칙을 따름.
연결기 가져오기/내보내기: 연결기 템플릿 공유
연결기 포크: 기존 연결기 복제 + 사용자 정의
워크플로우 Phase 2 노드: Iterator, Loop, VariableAggregator, ParameterExtractor, ListOperation, Transform, DocumentExtractor, QuestionUnderstanding, HumanIntervention — 전체 프론트엔드 + 백엔드 + 150개의 새로운 테스트 (총 275개)가 있는 9가지 고급 노드 유형. 지수 백오프를 사용한 노드 재시도, 안전한 표현식 평가. 성공률 막대가 있는 통계 패널. 12개의 기본 제공 템플릿. 창 컨텍스트 메뉴 (붙여넣기, 모두 선택, 보기 맞추기, 자동 레이아웃).
워크플로우 Phase 3 노드: SubWorkflow + ENV — 2가지 새로운 노드 유형 (총 25개 노드), 14개의 새로운 테스트 (총 306개), 14개의 기본 제공 템플릿. SubWorkflow: 대상 워크플로우 선택, 변수 매핑, 무한 재귀 방지를 위한 구성 가능한 깊이 제한이 있는 전체 DB 지원 중첩 워크플로우 실행기. ENV: 키 선택기 및 폴백 기본값이 있는 암호화된 환경 변수 읽기. 전체 프론트엔드 (노드 구성 요소, 구성 패널, 팔레트 항목, 미니맵 색상). 노드별 실행 통계 패널 (성공률, 지속 시간, 실패 횟수 최악 우선 정렬). getNodeStats API 클라이언트 + NodeStatEntry 유형. 키보드 단축키 대화상자 (? 키).
워크플로우 예약된 트리거: 시간대, 기본 입력 및 다음 실행 시간 계산이 있는 워크플로우별 cron 구성. 사전 설정 cron 버튼, 30개 트리거 테스트.
워크플로우 API 트리거: 사용자 인증 없이 외부 실행을 위한 워크플로우별 공개 API 키 (wf_ 접두사), 속도 제한 포함. API 키 관리 대화상자 (생성/재생성/취소, 트리거 URL, cURL/JS 예제).
워크플로우 배치 실행: 최대 100개의 입력 세트, 구성 가능한 병렬 처리 (1-10), 축소 가능한 항목별 결과, JSON 내보내기가 있는 POST /batch-run. 14개의 배치 실행 테스트.
워크플로우 실행 로그 뷰어: 실행 패널의 실시간 시간순 SSE 이벤트 스트림 (타임스탬프, 색상 코드 배지, 이벤트 유형 필터 토글 포함).
워크플로우 실행 통계: 백엔드가 GROUP BY 부쿼리를 통해 실행 횟수 및 성공률을 배치 가져오기; 프론트엔드가 색상 코드 성공률 표시기가 있는 워크플로우 카드에 통계 표시.
워크플로우 가져오기 충돌 해석기: 가져오기 중 미해결 에이전트/연결기/KB/MCP 참조 감지. 가시성 필터링이 있는 배치 DB 쿼리, 프론트엔드 토스트 경고. 17개 테스트.
워크플로우 테스트 노드 실행: 모의 변수를 사용한 격리된 단일 노드 테스트, 편집기에 통합 (구성 패널 테스트 버튼 + 컨텍스트 메뉴). 23개 테스트.
워크플로우 버전 비교: 노드/엣지 변경 감지가 있는 나란히 블루프린트 비교, 색상 코드 표시기 (추가됨/제거됨/수정됨).
워크플로우 실행 관리: 개별 실행 삭제 (DELETE /runs/{run_id}) 및 완료된 모든 실행 지우기 (DELETE /runs), 프론트엔드 확인 대화상자 포함.
워크플로우 실행 재생 오버레이: 실행 기록의 “캔버스에서 보기” 버튼으로 과거 실행 결과를 캔버스에 오버레이하여 노드별 상태 및 출력 표시 (재실행 없음).
워크플로우 즐겨찾기/고정: 워크플로우를 목록 맨 위에 고정하도록 별/고정 (localStorage 지속성 포함).
워크플로우 실행 기록 내보내기: 전체 실행 메타데이터 및 노드별 결과가 있는 JSON 파일 다운로드로 실행 기록 내보내기.
관리자 워크플로우 관리: 사용자 전체의 모든 워크플로우를 관리하기 위한 관리 패널 탭 — 나열, 활성/비활성 토글, 확인과 함께 삭제. 삭제, 토글, 게시를 위한 배치 엔드포인트 (감사 로깅 포함).
워크플로우 템플릿 시스템: 관리자 CRUD, 공개 나열/복제 API, 첫 시작 시 자동 삽입되는 5개의 시드 템플릿이 있는 WorkflowTemplate ORM 모델.
워크플로우 인라인 검증 배지: 편집 중 즉각적인 시각적 피드백을 위해 오류/경고 도구 설명이 있는 캔버스의 노드별 실시간 ValidationBadge.
워크플로우 실행 추적 뷰어: 엔진 trace_level 매개변수 및 단계별 디버깅을 위한 노드별 변수 스냅샷이 있는 타임라인 기반 추적 뷰어 Sheet.
워크플로우 속도 제한 및 시간 초과: 사용자별 WorkflowRateLimiter (슬라이딩 윈도우 10 실행/분, 3개 동시) 및 기본 10분 전역 실행 시간 초과.
워크플로우 블루프린트 시스템: 다단계 자동화 블루프린트를 설계하고 실행하기 위한 시각적 워크플로우 편집기 — Workflow / WorkflowRun ORM 모델, 전체 CRUD + SSE 실행 API, 가져오기/내보내기, 복제, 블루프린트 검증 엔드포인트, 위상 정렬 + 세마포어 기반 동시성 + 조건 분기 및 12가지 노드 유형 (시작, 종료, LLM, ConditionBranch, QuestionClassifier, Agent, KnowledgeRetrieval, Connector, HTTPRequest, VariableAssign, TemplateTransform, CodeExecution)이 있는 WorkflowEngine, {{node_id.output}} 보간 및 env.* 네임스페이스가 있는 VariableStore, 노드별 오류 전략 (STOP_WORKFLOW / CONTINUE / FAIL_BRANCH) (노드별 시간 초과 및 고급 구성 UI 포함), 드래그 앤 드롭 팔레트 + 노드 구성 패널 + 변수 선택기 콤보박스 + 엣지에 노드 추가 + 자동 레이아웃 (ELK.js) + 실행 기록 Sheet가 있는 React Flow v12 시각적 편집기, 링 기반 실행 상태 스타일 및 애니메이션 엣지 전환이 있는 Dify 스타일 간결한 노드 설계, 템플릿 선택기 대화상자 및 GET /templates + POST /from-template API가 있는 4가지 기본 제공 시작 템플릿 (단순 LLM 체인, 조건부 라우터, 지식 증강 QA, HTTP API 파이프라인), 통계 엔드포인트, ?run=true URL 매개변수 자동 열기, 부프로세스 기반 코드 실행 보안, 105개 테스트 스위트 (템플릿, eval 네임스페이스 평탄화, 블루프린트 검증 경고, 노드/엣지 삭제, 가져오기/내보내기/복제, 교착 상태 감지, 다중 조건 분기)
에이전트 코어 Phase 0 — Compact 프롬프트가 9섹션 구조화 형식으로 업그레이드됨; 빈 도구 결과 보호 ((no output) 대신 설명적 메시지); 반복 방지 프롬프트 + 사이클 감지 임계값을 2로 낮춤; 도메인 분류기 + 사전 비행 DB 설정 해석 병렬화 (요청당 400–1100ms 절감); SSE end 이벤트가 답변 직후 즉시 전송되며, 제목/제안은 백그라운드 작업으로 이동
에이전트 코어 Phase 1 (컨텍스트 반-팽창) — MicroCompact 규칙 기반 이전 도구 결과 정리 (최근 6개 유지); REACT_TOOL_RESULT_BUDGET=40000 집계 상한; 컨텍스트 오버플로우 시 반응형 compact (자동으로 50% 예산으로 compact하고 재시도, 충돌 대신)
에이전트 코어 Phase 2 (속도) — 키워드 기반 도구 사전 선택 (명백한 일치 시 LLM 호출 건너뜀, 200–500ms 절감); SharedHttpClient LLM 연결 풀링; 200 토큰 이상의 답변에 대해 완료 확인 건너뜀; FallbackLLM이 기본+빠른 모델을 래핑하며 429/503/529/연결 오류 시 자동 장애 조치
지능형 문서 처리 (비전 인식) — 적응형 문서 처리: PDF 페이지가 비전 가능 모델(GPT-4o, Claude 3/4, Gemini)을 위해 PyMuPDF를 통해 이미지로 렌더링됨; pdfplumber를 통한 텍스트 전용 폴백. 모델별 supports_vision 플래그. DOCUMENT_PROCESSING_MODE, DOCUMENT_VISION_DPI, DOCUMENT_VISION_MAX_PAGES를 통한 모드. DOCX/PPTX 포함 이미지 추출. 대화 턴 전체에 걸친 다중 턴 비전 지속성. 스마트 PDF 처리 (텍스트 풍부 페이지는 텍스트 + 이미지 추출; 스캔된 페이지는 전체 페이지 PNG로 렌더링). --network=none 코드 실행을 위한 일반적인 데이터 과학 패키지가 포함된 사전 구축 샌드박스 이미지 (Dockerfile.sandbox)
범용 문서 변환 (convert_to_markdown + OCR) — Microsoft MarkItDown을 래핑하는 기본 제공 에이전트 도구; PDF, Word, Excel, PowerPoint, HTML, JSON, CSV, XML, ZIP, EPUB, Outlook .msg, 이미지, 오디오, YouTube URL을 Markdown으로 변환합니다. LiteLLMOpenAIShim은 모든 비전 지원 LLM(Claude, Gemini, Bedrock, Azure)을 통해 OCR을 활성화합니다. 텍스트 전용 폴백으로 회귀 없이 비전 인식 RAG 수집. 옵트아웃을 위한 LLM_SUPPORTS_VISION 환경 변수
에이전트 코어 Phase 3 (런타임 불변식 강화) — 대화 복구(끊어진 tool_use 자동 복구); 구조화된 컴팩트 작업 카드(WorkCard 압축 라운드 간 타입 병합); 턴 레벨 프로파일러(REACT_TURN_PROFILE_ENABLED); 사용자별 속도 제한(LLM_RATE_LIMIT_PER_USER); tool_calls가 있는 빈 콘텐츠 어시스턴트 메시지가 더 이상 삭제되지 않음
System prompt section registry with cache breakpoints — Memoized PromptRegistry splits system prompts into stable prefix + dynamic suffix; cache-capable providers (Claude, Bedrock Anthropic, Vertex Claude) receive cache_control: {"type": "ephemeral"} on the prefix for ~60-80% per-turn input token savings. Non-cache providers get a single concatenated message (zero behavior change)
Prompt cache observability — cache_read_input_tokens and cache_creation_input_tokens tracked through UsageSummary → TurnProfiler → done_payload.cache field. Structured turn_cache log line per turn. Doubles as relay cache-honesty probe
Conversation recovery MVP — Synthetic tool_result rows persist after interrupted turns; POST /chat/resume replays cached SSE events from a monotonic cursor; frontend useSseResume hook auto-reconnects with exponential backoff (300ms → 1s → 3s, max 3 attempts) and “Reconnecting…” indicator
Thinking-block persistence with signature — reasoning_content + Anthropic signature persisted in metadata_["thinking"] and replayed on subsequent turns; fixes HTTP 400 signature mismatch on Claude 4 multi-turn conversations
Provider-aware reasoning replay policy — Centralized reasoning_replay_policy() in core/prompt/reasoning.py gates serialization per provider family: Claude replays thinking blocks with signature; DeepSeek-R1/Qwen-QwQ/Gemini-thinking/o-series drop reasoning_content on outbound (previously leaked, breaking provider KV caches and violating API docs)
Feishu Channel (Phase 1 subset) — Org-scoped Channel 리소스(Fernet 암호화 자격증명 포함); FeishuChannel은 대화형 카드 전송 + 콜백 지원(서명 검증 + URL 챌린지); Settings → Channels 관리 UI(목록, 더티 상태 보호 포함 생성/편집, 복사 가능한 콜백 URL이 있는 상세 정보, 테스트 전송); CRUD API(/api/channels) 및 이벤트 콜백 엔드포인트(/api/channels/{id}/callback). 2026-04-24 로드쇼를 위해 조기 출시
Agent Hook System (ReAct + DAG 런타임에서 실시간) — src/fim_one/core/hooks/의 PreToolUseHook / PostToolUseHook 추상화; model_config_json에서 hooks.class_hooks를 선언하는 에이전트는 채팅 세션당 훅이 인스턴스화되고 등록됨. 첫 번째 소비자 FeishuGateHook은 에이전트가 requires_confirmation=True 도구를 호출할 때 연결된 Feishu 그룹에 승인/거부 카드를 게시하고, 실행을 차단한 후 판정에 따라 재개 또는 중단
구성 가능한 확인 게이트(인라인 또는 통로) — 모든 에이전트는 세 가지 라우팅 모드(자동 / 인라인만 / 통로만), 승인자 범위 선택기(개시자 / 소유자 / 조직의 누구나), 도구별 재정의, 명시적 승인 통로 선택기가 있는 승인 섹션을 가짐. 자동 모드는 연결된 통로가 없을 때 인라인 승인 카드로 우아하게 폴백. POST /api/confirmations/{id}/respond는 Feishu 웹훅과 단일 의사결정 기록 경로 공유
에이전트별 작업 완료 알림 — 장시간 실행되는 ReAct 또는 DAG 에이전트는 작업이 완료될 때 조직의 통로에 요약 카드를 푸시할 수 있음. 일반 아웃바운드 알림 패턴의 첫 번째 소비자
Hook 승인 Playground — Channels 상세 시트에는 전체 프로덕션 경로를 실행하는 “테스트 승인 흐름” 작업이 있음(진정한 ConfirmationRequest 행, 실제 Feishu 콜백, 상태 전환) — 프로덕션 훅이 사용하는 동일한 코드 경로
Contributor 친화적 i18n CI 폴백 — .github/workflows/i18n-sync.yml은 PR 병합 후 마스터에서 EN → ZH/JA/KO/DE/FR로 번역하고 [skip ci]로 자동 커밋; 기여자는 더 이상 로컬에서 LLM_API_KEY가 필요하지 않음. 생성된 로케일 파일에 대한 수동 편집을 거부하는 사전 커밋 로케일 편집 가드(ALLOW_LOCALE_EDIT=1 정당한 번역 수정을 위한 재정의). 스모크 테스트 푸시를 통해 엔드투엔드 검증됨
Exa 통합 문서 — 전체 Exa 검색 표면(신경망 / 빠른 / 심층 추론 / 즉시), 필터링, 콘텐츠 검색, 세 가지 조정된 사전 설정을 다루는 첫 번째 클래스 Exa 페이지가 있는 전용 통합 섹션
Xinchuang (信创) 데이터베이스 지원 — 데이터베이스 Connector는 이제 PostgreSQL/MySQL과 함께 KingbaseES (人大金仓), HighGo (瀚高), DM8 (达梦)을 나열. PG 호환 드라이버는 asyncpg 재사용; DM8은 dmPython 사용. scripts/test_xinchuang_dbs.py는 CLI에서 실시간 연결을 검증
Channels + Hook System 아키텍처 문서 — docs/architecture/hook-system.mdx는 세 가지 훅 포인트를 설명하고 FeishuGateHook을 엔드투엔드로 안내; 기존 아키텍처 페이지는 교차 링크; README는 메시징 통로를 첫 번째 클래스 기능으로 나열
강화 — 중복된 Feishu 콜백 클릭은 이중 결정 대신 교체 카드 생성; 동시 콜백 클릭은 조건부 UPDATE ... WHERE status='pending' 행 개수 확인을 통해 해결; 대기 중인 승인은 백그라운드 스위퍼를 통해 CHANNEL_CONFIRMATION_TTL_MINUTES(기본값 24시간) 후 자동 만료; Settings → Channels는 조직 역할 준수(멤버는 읽기 전용 UI 표시); 병렬 도구 호출 수집기는 모든 델타에 대해 index=0을 재사용하는 제공자 처리; 세션 만료 리디렉션은 쿼리 문자열 보존
목표: v0.9 프로덕션 강화 단계가 시작되기 전에 v0.8.5 채널 + 훅 출시의 미완료 항목을 정리합니다. 범위는 의도적으로 좁음 — 새로운 기능이 아닌 개선입니다.
훅별 설정 통과 — 현재 class_hooks 항목은 단순 문자열이며, FeishuGateHook.timeout_seconds, poll_interval_seconds 또는 callback_base_url을 에이전트별로 재정의하려면 스키마가 훅 팩토리에 kwargs로 전달되는 {"name": "feishu_gate", "config": {...}} 객체를 수용해야 합니다. 낮은 위험의 후속 작업이며, 현재 기본값(120초 타임아웃 / 1.5초 폴링 / 환경 변수 콜백 URL)은 당분간 수용 가능합니다.
DAG tools_used 정확성 — 완료 알림 카드는 현재 tools_used를 plan.steps[*].tool_hint(플래너의 제안)에서 파생하며, 단계별 ReAct 루프가 선택한 실제 도구 이름이 아닙니다. DAG 실행기의 단계 완료 콜백에서 실제 선택된 도구 이름을 추출하여 알림 카드가 실제로 실행된 내용을 반영하도록 합니다.
위임된 하위 에이전트 및 Workflow AGENT 노드에 대한 훅 상속 정책 — 현재 CallAgentTool 자식 및 Workflow AGENT 노드는 부모의 훅 레지스트리를 상속하지 않는 새로운 ReActAgents를 생성하므로, 위임을 통해 도달한 민감한 도구 호출은 feishu_gate를 조용히 우회합니다. 결정 및 문서화: 자식 에이전트가 상속(기본값-보안, 게이트 우회 방지)하거나 격리(팀이 승인 게이트가 없는 작업을 자식 에이전트에 위임 가능)합니까? Eval Center 실행은 설계상 옵트아웃 상태로 유지됩니다(자동화는 인간 승인을 차단할 수 없음).
Playground 후속 제안 복원, 에이전트별 옵트인 — v0.8.5 후처리 리팩토링은 제안 생성을 fire-and-forget 백그라운드 작업으로 이동하고 post_processing / suggestions SSE 이벤트를 삭제했으므로, 답변 아래의 칩 행이 나타나지 않았습니다. 제안은 이제 done과 end 사이에 인라인으로 스트리밍되며 새로운 에이전트별 suggest_followups 토글(기본값 꺼짐)로 제어됩니다 — 작업 스타일 에이전트는 조용히 유지되고, 명시적으로 옵트인한 대화형 에이전트는 하나의 빠른 모델 왕복을 지불하고 칩을 다시 받습니다.
여기의 모든 항목은 기존 추상화 뒤에 있고 추가적입니다 — 스키마 변경 없음, 호환성 손상 API 변경 없음, v0.8.5와 v0.9 사이에 단계적으로 안전하게 적용 가능합니다.
IM Channel 통합 (양방향): Phase 1 — 아웃바운드 푸시: Lark, WeCom, Slack, Email, Teams 알림 작업 (Agent/Workflow 결과로부터). Phase 2 — 인바운드 트리거: 사용자가 IM 그룹 채팅에서 Agent를 @mention하여 Portal을 열지 않고 작업 트리거; 채널별 webhook 수신기; 각 IM 채널은 양방향 작업(전송 + 수신)을 가진 Connector로 모델링됩니다. Hub 모드 킬러 기능
Feishu Channel (Phase 1 부분집합) — 조직 범위의 Channel 리소스 (Fernet 암호화된 자격증명 포함); 대화형 카드 전송 + 콜백 지원 FeishuChannel 구현 (서명 검증 + URL 챌린지); 확인 게이트와 통합되어 쓰기 작업 승인이 구성된 Feishu 그룹 채팅에 승인/거부 카드로 전달됨; Settings → Channels 관리 UI. 2026-04-24 로드쇼를 위해 조기 배포됨. 남은 것: WeCom, Slack, Email, Teams 아웃바운드 + Phase 2 인바운드 트리거.
아웃바운드 알림 패턴 (일반적이고 채널 유형 전체에서 재사용 가능): 동일한 BaseChannel 추상화는 승인 게이팅을 넘어 아웃바운드 사용 사례의 카탈로그를 지원합니다. 각 패턴은 BaseChannel에 대해 한 번 구현되고 모든 구체적인 채널(현재 Feishu; Slack/WeCom/Teams/Email이 추가될 때)에서 자동으로 작동합니다.
작업 완료 알림: 장기 실행 DAG / Workflow / 예약된 에이전트가 완료되면, 결과 스니펫 + 아티팩트 링크가 포함된 요약 카드를 조직 채널(또는 사용자가 선택한 채널)에 게시합니다. 최소 실행 가능한 “Channel 아웃바운드” 제품 — FeishuGateHook 이후 첫 번째 소비자
예외 / 실패 경고: 에이전트 추론 실패, LLM 제공자 오류, connector 5xx 발생, DAG 계획이 재계획 예산 소진 → 추적 ID 및 재시도 옵션이 있는 진단 카드를 ops 채널에 푸시
비용 / 예산 경고: 사용자별 또는 에이전트별 token/요청 예산이 80% / 100% 임계값에 도달 → 현재 사용량 대 상한선이 있는 관리자 채널에 푸시(또는 에이전트 소유자 @-mention)
예약된 요약: 에이전트 또는 워크플로우가 정기적(일일 / 주간) 요약 카드 발행 — KPI 롤업, 미해결 티켓 분류, 계약 갱신 목록 — Portal을 열 필요 없이 채널로 직접 전달
고착된 에이전트에 대한 에스컬레이션: 에이전트가 N개의 연속 반복에서 관찰 가능한 진행을 하지 않음(사이클 감지 또는 max_iterations 초과) → 현재 컨텍스트 및 “당신의 메모로 재개” 작업이 있는 카드를 게시하여 인간 운영자가 인수하도록 요청
민감한 도구 호출에 대한 감사 영수증: 승인 게이트와 독립적으로 — audit=true로 태그된 도구에 대한 모든 호출은 규정 준수 채널에 읽기 전용 영수증 카드(누가 / 무엇 / 언제 / 인수)를 발행하여 데이터베이스 외부에 지속 가능한 감사 추적을 제공합니다
승인 에스컬레이션: feishu_gate 승인 카드가 N분 내에 응답을 받지 못하면, 자동으로 그룹 소유자를 @-mention하거나 카드를 더 높은 계층의 채널로 전달; 도구/connector별로 구성 가능
기존 RBAC 제어는 리소스 가시성 (누가 커넥터를 볼 수 있는지)을 관리하지만, 실행 시간 인증 (호출자가 이를 통해 무엇을 할 수 있는지)은 관리하지 않습니다. 관리자가 높은 권한의 자격증명으로 DB/API를 연결하면, 해당 커넥터를 사용하는 모든 조직 구성원이 관리자의 권한 범위를 상속받습니다. 이 섹션은 세 가지 서로 다른 업스트림 기능 계층에서 이 격차를 해결합니다:
계층 1 — DB 모드 (전체 관리자 + 기본/레거시): 관리자가 단일 DB 자격증명(루트 또는 최소 권한 서비스 계정)을 제공합니다. 대부분의 레거시 시스템은 사용자별 DB 계정을 발급할 수 없기 때문입니다. 적용은 ConnectorScopeGuard — PreToolUse 훅을 통해 연결 위에서 발생하며, 호출자 신원에 따라 query / execute 호출을 필터링합니다. 기능: 파괴적 동사 차단(DROP, TRUNCATE, 범위 없는 DELETE/UPDATE); 테이블 수준 허용/거부 목록; pii=true 의미론적 주석으로 구동되는 열 마스킹; 범위 술어 자동 주입(예: 모든 SELECT에 AND dept_id = :caller_dept 추가). 설정은 커넥터의 scope_rules JSON 필드이며 역할 기반 매칭을 사용합니다. 기본값은 모호한 경우 거부입니다.
계층 2 — Open API 모드 (사용자별 API 키): 선호되는 경로입니다. 사용자가 자신의 API 키를 제공합니다(v0.8에서 배포됨 — connector_credentials + allow_fallback=false); 업스트림 시스템의 기본 인증이 범위를 자연스럽게 적용합니다. 남은 작업: 사용자별 자격증명을 요구하는 커넥터별 관리자 UI(전역적으로 관리자 폴백 비활성화) 및 조직 구성원 중 누가 아직 자신의 키를 바인딩하지 않았는지 보여주는 상태 대시보드.
계층 3 — 중간 계층 (로그인 티켓 교환): 사용자 범위 API 키가 없는 프론트엔드/백엔드 분할 시스템용입니다. 시스템의 로그인 엔드포인트를 사용자 제공 자격증명으로 호출하고, 반환된 단기 티켓을 캐시하며, 만료 시 자동 새로고침합니다. API 키 / OAuth와 함께 새로운 LoginTicketCredential 유형; 커넥터 스펙은 login_endpoint, ticket_field, refresh_strategy와 함께 auth_type: login_ticket을 선언합니다. 어댑터 계층은 요청당 티켓을 아웃바운드 인증 헤더로 변환합니다.
계층 간 감사 가능성: 모든 도구 호출은 ConnectorCallLog에서 caller_user_id, effective_credential_source(사용자 / 관리자 폴백 / 티켓), scope_rules_applied로 스탬프되므로, 운영팀은 사건 발생 후 “누가 실제로 누구로서 무엇을 실행했는가”에 답할 수 있습니다.
현재 Feishu는 Channel + Connector 쌍으로 연결되어 있습니다 — 전달 파이프와 API 표면입니다. 엔터프라이즈 롤아웃에는 세 번째 역할이 필요합니다: Integration (동일한 타사 바인딩이 SSO 및 조직 그래프 동기화도 제공합니다). v0.9에 도입되는 이유는 기존 Feishu 바인딩이 이미 필요한 4가지 측면 중 3가지를 다루고 있으며, 신원 스토리가 위의 Tier-2 인증을 차단 해제하기 때문입니다 (사용자는 API 키를 수동으로 프로비저닝하는 대신 로그인 시 자신의 업스트림 token을 얻을 수 있습니다).
Channel → Integration 모델: Channel을 “아웃바운드 전용 전달”에서 세 가지 선택적 하위 기능을 가진 ThirdPartyIntegration 부모로 승격 — (a) Delivery (기존 Channel 동작: 카드 전송, 확인 게이트); (b) Login (OIDC / 커스텀 SSO; “Feishu로 로그인”은 FIM 세션과 업스트림 플랫폼 token을 모두 생성); (c) Org graph sync (업스트림 부서/멤버를 FIM 조직 구조로 미러링; 스케줄 또는 webhook 기반). 관리자는 바인딩당 각 기능을 토글합니다.
Feishu SSO를 Integration 기능으로: 기존 Feishu 앱 바인딩 (Channel의 app_id/secret)을 재사용하여 Feishu 테넌트가 조직에 바인딩된 모든 사용자에게 “Feishu로 로그인”을 노출합니다. 로그인 시 얻은 token은 사용자의 Feishu Connector에 대한 기본 자격증명이 되어 Tier-2 시행을 위한 “자신의 API 키를 얻으러 가세요” 마찰을 제거합니다.
Org graph sync (Feishu → FIM org): Feishu 부서 + 멤버를 FIM으로 가져오기; Feishu 테넌트-관리자 / 부서-책임자 / 멤버 역할을 FIM owner/admin/member로 매핑합니다. 다음 WeCom 및 DingTalk의 기초이며, v1.0의 Kingdee / Yonyou / SAP ERP-OA 어댑터를 위한 기초입니다.
Agent Trace Layer (Observability++): 애플리케이션 수준의 run/trace/thread 계층 구조로 에이전트 디버깅 — 각 대화 → Trace, 각 LLM 호출 / 도구 호출 / DAG 스텝 → input/output/tokens/timing을 포함한 Span. 타임라인과 확장 가능한 LLM 호출 페이로드를 갖춘 프론트엔드 trace 뷰어. 이는 OTel(인프라 수준)을 넘어 개발자와 엔터프라이즈 클라이언트를 위한 실행 가능한 에이전트 루프 디버깅을 제공합니다. OpenTelemetry 내보내기를 데이터 싱크 옵션으로 제공. LangSmith의 run/trace/thread 개념을 모델로 함 — 에이전트 관찰성을 위한 업계 검증 패턴.
Metrics dashboard: 지연시간, 성공률, token 사용량, 커넥터 호출 분석 — 에이전트별, 사용자별, 조직별 분석
Workflow run 보존 정리: 구성 가능한 최대 나이 및 워크플로우당 최대 개수를 갖춘 백그라운드 정리 작업; 워크플로우별 재정의; 수동 트리거를 위한 관리자 엔드포인트(v0.8.1에서 배포됨)
Workflow 버전 변경 요약: compute_blueprint_diff()는 버전 저장 시 blueprint diff에서 인간이 읽을 수 있는 요약을 자동 생성(v0.8.1에서 배포됨)
DAG 품질 개선: 비fast 스텝을 위한 기본 모델 업그레이드; 계획에서 skill 자동 발견; 법률/의료/금융 도메인을 위한 citation 검증자; 구조화된 콘텐츠 컨텍스트 보존; 라우터의 도메인 분류 및 도메인 인식 모델 선택(v0.8.1에서 배포됨)
ReAct의 도메인 모델 에스컬레이션: 전문 도메인은 필수 웹 검색 및 citation 검증을 갖춘 추론 모델로 자동 에스컬레이션(v0.8.1에서 배포됨)
모델별 Native Function Calling 토글: tool_choice_enabled 설정으로 모델이 강제 도구 선택을 건너뛰고 JSON Mode로 직접 이동 가능(v0.8.1에서 배포됨)
DatabaseMetaTool (DB 커넥터를 위한 Progressive Disclosure): 단일 database 메타 도구로 list_tables/discover/query 서브명령이 데이터베이스 커넥터당 3N개의 개별 도구 대체; DATABASE_TOOL_MODE 환경 변수로 구성 가능(progressive 기본값, legacy 폴백)(v0.8.1에서 배포됨)
request_tools 메타 도구를 통한 온디맨드 도구 로딩: >12개의 도구가 스마트 선택 후 사용 가능할 때, LLM은 대화 중에 동적으로 추가 도구 로드 가능; JSON 및 native function-calling 모드 모두에서 작동(v0.8.1에서 배포됨)
MCPServerMetaTool (MCP를 위한 Progressive Disclosure): 단일 mcp 메타 도구로 discover/call 서브명령이 N*M개의 개별 MCP 도구 대체; MCP_TOOL_MODE 환경 변수로 구성 가능(progressive 기본값, legacy 폴백)(v0.8.1에서 배포됨)
Workflow Connection Dep 자동 구독: Market 구독 계단식을 확장하여 Workflow의 연결 종속성(API Connectors, MCP Servers)을 자동 구독. Workflow 노드는 Connectors, MCP Servers, Agents(더 많은 deps를 재귀적으로 참조), 서브 Workflows를 참조할 수 있으며 — 전체 트리의 모든 연결 deps는 구독 시 자동 구독되고 구독 해제 시 계단식 정리됨. 순환 감지를 갖춘 재귀적 서브 워크플로우 해석으로 인해 Skill/Agent보다 더 복잡함. Solution(Skill/Agent) 연결 dep 자동 구독의 대응(v0.8.1에서 배포됨)
Workflow 실제 실행자: MCP 및 BuiltinTool 노드 실행자 스텁을 전체 구현으로 대체(MCP 서버 발견 + 도구 호출; ToolRegistry 통합)(v0.8.1에서 배포됨)
Agent Hook System: LLM 루프 외부에서 실행되는 결정론적 강제 계층 — hook은 도구 이벤트에서 자동으로 실행되며 에이전트 지시사항으로 우회할 수 없습니다. 3개의 hook 포인트: PreToolUse(실행 전 검증 / 차단), PostToolUse(실행 후 부작용), SessionStart(동적 컨텍스트 주입). 내장 hook: 모든 커넥터 호출에서 ConnectorCallLog 자동 작성(현재 수동); 조직이 읽기 전용 모드일 때 쓰기 작업 차단; 에이전트에 도달하기 전에 oversized DB 쿼리 결과 자동 자르기; 커넥터별 호출 빈도 속도 제한. 사용자 정의 hook: 에이전트별 YAML 구성(hooks: 필드)으로 일치하는 도구 이벤트에서 트리거되는 shell 명령 또는 Python 호출 가능 선언 — 최신 에이전트 프레임워크 전체에서 공유되는 hook 기반 강제 패턴. 핵심 설계 원칙: hook은 LLM이 이를 기억하는 데 의존해서는 안 되는 “항상 발생해야 하는” 로직을 위한 것. 지시사항은 “모든 호출 기록”; hook은 실제로 기록합니다. 지시사항은 “읽기 전용 모드에서 쓰지 않음”; hook은 실제로 차단합니다.
Hook System 스켈레톤 + FeishuGateHook — 클래스 기반 PreToolUseHook / PostToolUseHook 추상화가 ReAct 루프 아래에 연결됨; 첫 번째 구체적 hook은 FeishuGateHook로, requires_confirmation=True로 표시된 도구를 가로채고 조직의 Feishu Channel을 통해 승인을 라우팅합니다. 전체 hook 생명주기(사용자 정의 YAML hook, 내장 감사/차단/자르기 hook, SessionStart)는 v0.9 범위로 남음. 2026-04-24 로드쇼를 위해 조기 배포.
Hook Approval Playground — UI 기반 왕복 테스터: Channels 세부 정보 시트는 이제 실제 ConfirmationRequest 행을 생성하는 대화 상자를 시작하고, 프로덕션 카드를 Feishu로 보내고, 결정을 실시간으로 폴링합니다. 프로덕션 hook이 사용할 정확한 코드 경로를 실행하여 사전 롤아웃 리허설 및 데모를 충실하게 만듭니다.
Hook System이 ReAct + DAG 런타임에서 실시간 작동 — build_hook_registry_for_agent는 모든 chat 세션에서 agent.model_config_json.hooks.class_hooks를 해석; ReAct 및 DAG 진입점 모두 도구 디스패치 전에 hook을 인스턴스화합니다. 도구 어댑터는 requires_confirmation을 공개 속성으로 노출하므로 hook 술어는 어댑터 결합 없이 duck-type할 수 있습니다. 승인 / 거부 경로를 통한 실제 에이전트 루프를 다루는 엔드투엔드 smoke 스크립트(scripts/smoke_feishu_gate.py)와 쌍을 이룸.
Hook별 구성 통과 — class_hooks 항목은 현재 단순 문자열; FeishuGateHook.timeout_seconds, poll_interval_seconds, 또는 callback_base_url을 에이전트별로 재정의하려면, 스키마는 hook 팩토리에 kwargs로 전달되는 {"name": "feishu_gate", "config": {...}} 객체를 수용해야 합니다. 낮은 위험 v0.8.5 후속; 현재 기본값(120s 타임아웃 / 1.5s 폴 / env-var 콜백 URL)은 v0.8에 허용됨.
Agent Workspace (Persistent Agent Desktop): 3개 계층: (1) Tool Output Offloading — oversized 도구 응답(>8K chars)을 workspace:// 파일로 자동 저장, 잘린 미리보기 + URI 반환; 선택적 액세스 및 에이전트 생성 아티팩트를 위한 내장 도구 read_workspace_file, list_workspace_files, write_workspace_file. (2) Handoff Notes — 컨텍스트 전환을 위한 write_handoff(summary) 압축/세션 전환 전체. (3) Workspace UI — 대화별 프론트엔드 파일 브라우저 패널(텍스트/JSON/CSV 미리보기, 다운로드, 삭제/이름 변경); 세션 간 파일 보존; 사용자별 저장소 할당량 통합. 어댑터의 truncate_tool_output() + GET /api/conversations/{id}/workspace 엔드포인트 확장
Smart File Content Injection + read_uploaded_file 도구: 작은 업로드된 파일(<32K chars)은 LLM 컨텍스트에 자동 인라인; 큰 파일은 메타데이터 + 도구 힌트 획득. 이중 모드 read_uploaded_file 도구(페이지 매김 읽기 + regex 검색). GET /api/files/{file_id}/content 엔드포인트, .content 사이드카 저장소, 파일 API 응답의 content_length
Intelligent Document Processing (Vision-Aware): 적응형 문서 처리 — PDF 페이지는 vision 가능 모델(GPT-4o, Claude 3/4, Gemini)을 위해 PyMuPDF를 통해 이미지로 렌더링; pdfplumber를 통한 텍스트 전용 폴백. Admin의 모델별 supports_vision 플래그. 2가지 모드(vision/text)는 DOCUMENT_PROCESSING_MODE 환경 변수로 구성 가능. 스마트 PDF 처리: 텍스트 풍부 페이지는 텍스트 + 포함된 이미지 추출(token 효율적), 스캔된 페이지는 전체 페이지 PNG로 렌더링. DOCX/PPTX 포함 이미지 추출. 다중 턴 vision 지속성. 사전 구축된 sandbox 이미지(Dockerfile.sandbox). .pages/ 사이드카를 갖춘 캐시된 페이지 렌더링.(v0.8.2에서 배포됨)
~~Universal Document Conversion (convert_to_markdown + OCR) — Microsoft MarkItDown을 래핑하는 내장 Agent 도구로 모든 에이전트에서 기본적으로 사용 가능. PDF, Word, Excel, PowerPoint, HTML, JSON, CSV, XML, ZIP, EPUB, Outlook .msg, 이미지, 오디오, YouTube URL, 데이터 URI를 대화 내 깨끗한 Markdown으로 변환. Office 파일 및 스캔된 PDF 페이지의
Prompt Cache + Reasoning Follow-ups (Batch A MVPs에서)
이 항목들은 Batch A에서 배포된 부분 작업(Conversation Recovery, System Prompt Registry, Thinking Blocks)을 완성하고 캐시 범위를 남은 제공자 계열로 확장합니다.
Gemini Context Cache Adapter: Google Gemini는 Anthropic이 사용하는 인라인 cache_control 마커와 달리 별도의 REST API(POST /v1beta/cachedContents → cacheName 반환 → 후속 generateContent 호출에서 cachedContent: "<cacheName>"으로 참조)를 사용합니다. 라이프사이클 관리(접두사 사전 등록 → cacheName 참조 → TTL 인식 무효화)를 포함하는 GeminiCacheAdapter가 필요하며, OpenAICompatibleLLM의 Gemini 경로 또는 LiteLLM의 Gemini 제공자에 통합되어야 합니다. 읽기 할인 약 0.25×, 최소 접두사 32,768 token(Gemini Pro) / 4,096(Flash) — 주요 수혜자는 장문맥 KB/RAG 에이전트 및 문서 집약적 워크플로우입니다.
Prompt registry 확장(planner / verifier / domain classifier): ReAct에서 PromptRegistry + DYNAMIC_BOUNDARY 패턴을 남은 LLM 호출 지점으로 확장: DAGPlanner, PlanAnalyzer, StepVerifier, CitationVerifier, DomainClassifier, ExecutionModeRouter, CompactUtils. 현재 이들은 매 호출마다 처음부터 프롬프트를 재구성합니다. ReAct보다 빈도가 낮아 ROI가 낮지만 캐시 스토리를 완성합니다.
에이전트별 cache_ttl 설정: 에이전트 소유자가 ephemeral(5분, 기본값, 저비용 쓰기)과 extended(1시간, 2× 쓰기 비용이지만 배치/스케줄 워크플로우에 더 나음) 중 선택할 수 있도록 합니다. Agent 모델의 필드로 표시하고 지원되는 곳에서 cache_control: {"type": "...", "ttl": "..."}을 통해 전달합니다.
DAG 단계 수준 checkpoint 테이블: 현재 A1 Conversation Recovery MVP는 합성 tool_results 및 캐시된 SSE 이벤트를 유지하지만 DAG 중간 단계 상태는 메모리에만 존재합니다. 새로운 dag_execution_step 테이블은 각 단계의 tool_calls, results, artifact 참조를 스냅샷하여 DAG 중간 연결 끊김 시 완료된 단계를 다시 실행하지 않고 재개할 수 있습니다. 프론트엔드 useSseResume 훅과 함께 엔드투엔드 연속성을 제공합니다.
Message의 전용 tool_call_id 열: 현재 tool_call_id는 metadata_ JSON에 있어 고아 도구 사용 쿼리에 json_extract(...) / ::json->>를 필요로 합니다. 높은 트래픽 배포의 경우 첫 번째 클래스 인덱싱된 열이 복구 패스를 O(n) 스캔 대신 O(log n)으로 실행할 수 있습니다. 규모가 요구할 때까지 낮은 우선순위입니다.
중간 스트림 thinking token 재구성: 현재 재개 세분성은 “다음 완전한 SSE 이벤트” — 드롭이 thinking delta 내부에서 발생하면 클라이언트는 다음 이벤트에서 재시작합니다. Token 수준 재개는 진행 중인 thinking 블록의 버퍼된 token을 다시 내보내야 합니다. 틈새 개선; 사용자가 불안정한 연결에서 thinking UX 지터를 보고하는 경우에만 추구할 가치가 있습니다.
API relay cache-honesty probe: 배경 도구(관리자 트리거 또는 스케줄됨)로 각 구성된 relay를 통해 두 개의 동일한 Claude 요청을 보내고, 실제 청구된 입력 vs cache_read_input_tokens을 비교하며, cache_control 마커를 제거하거나 0.10× 할인을 전달하지 않는 relay에 플래그를 지정합니다. Workspace 수준 “relay health” 신호로 표시 — 중국 API 프록시를 통해 라우팅하는 엔터프라이즈를 위한 유용한 운영 도구입니다.
Agent Core 통합 청사진의 대부분(Phase 0–3, I.1–I.16)이 v0.8.2 및 v0.8.3에서 출시되었습니다. 아래 항목들은 여전히 주의가 필요한 병렬 우선순위 매트릭스에서 나온 것입니다.
콘텐츠 교체 상태 지속성 (스트리밍 불변식 #2): “한 번 표시되면, 운명은 고정됨” — 이미 클라이언트에 전송된 메시지 콘텐츠는 resume / reload 전반에서 소급적으로 변경되어서는 안 됩니다. A1의 SSE 커서와 정렬된 교체 원장이 필요합니다. 실제 사용자에게 보이는 결함을 이해하는 것에 의해 차단됨; 활성 불만 없음.
첨부 파일 컨텍스트 라우터: alreadySurfaced + readFileState 중복 제거, 집계 첨부 파일 예산, 및 생존성 검사를 통한 더 스마트한 첨부 파일 주입. 매 턴마다 동일한 50KB PDF 추출을 재전송하는 것을 방지합니다. 워크스페이스 파일 오프로딩(이미 v0.9 계획에 있음)과 결합됩니다.
사이드 쿼리 워커 (prompt 워커 풀): 주 agent LLM 호출과 rate-limit 예산을 놓고 경합하지 않도록 recall / classification / summary / session-memory 쿼리를 위한 전용 경량 풀. 전제 조건: prompt 레지스트리 확장(위 참조).
스케줄된 작업 + 이벤트 트리거 에이전트 (Loop): cron 유사 백그라운드 작업 트리거; scheduled_jobs + job_runs DB 테이블; APScheduler 통합; 작업 CRUD API + 작업 이력 UI; 메시지 푸시 커넥터를 통한 결과 알림. 범위는 시간 기반 트리거(cron)와 이벤트 기반 트리거(webhook 인바운드) 패턴을 모두 포함 — 백그라운드에서 비동기로 실행되는 에이전트는 Hub 모드의 비동기 서브-에이전트 사용 사례입니다.
사전 구축된 솔루션 템플릿 (마켓 시드 콘텐츠): 첫 사용자 등록 시 마켓에 게시된 8개의 즉시 사용 가능한 수직 솔루션 — 재무 감사, 계약 검토, 데이터 보고, IT 헬프데스크, HR 온보딩, 영업 어시스턴트, 콘텐츠 작성자, 회의 요약. 각각은 에이전트 + 스킬과 중국어 SOP를 번들로 제공; ensure_solution_templates()를 통해 멱등성 있게 부트스트랩되고, 즉시 마켓플레이스 가용성을 위해 마켓 조직에 게시됨(v0.8.1에서 출시됨)
DB 스키마 고급 빌더: 대규모 데이터베이스를 위한 AI 기반 스키마 관리 에이전트 — 전략적 테이블 주석(패턴 기반, SQL 실행 정보 활용), 도메인 접두사별 대량 가시성 관리, 1K–7K+ 테이블 배포를 위한 반복적 다중 라운드 주석; 선택성과 비즈니스 컨텍스트 추론으로 기존 배치 주석 작업을 보완합니다.
리소스 포크 (패키지 단계 1 — v1.0 패키지 시스템의 전제 조건): 모든 리소스별 포크 엔드포인트 구현 — MCP Server, Skill, Agent, Connector, Workflow. KB 포크 제거(본질적으로 사용자 로컬). 각 POST /api/{type}/{id}/fork는 forked_from 계보 추적을 포함한 사용자 소유의 깊은 복사본을 생성합니다.(v0.8.1에서 완료됨)
워크플로우별 credential_policy 오버라이드 (owner | caller | auto): 5가지 워크플로우 트리거 경로는 현재 커넥터 작업을 실행할 신원을 하드코딩합니다 — webhook/cron은 wf.user_id(소유자)를 전달하고, 수동/배치는 current_user.id(호출자)를 전달합니다. 이는 일반적인 “자동화는 소유자로 실행, 수동 실행은 호출자로 실행” 예상과 일치하지만, 엔터프라이즈 배포는 때때로 워크플로우별로 오버라이드가 필요합니다(예: 현재 온콜 엔지니어로 실행해야 하는 cron, 또는 수동 실행 시에도 소유자의 자격 증명을 차용해야 하는 공유 템플릿). Workflow 모델에 credential_policy 필드를 추가하고, Schedule / API-Key 설정 옆의 UI에 표시하여 기본 trigger_source → identity 매핑을 오버라이드합니다. 전제 조건: 위의 trigger_source 관찰성.
영향: FIM One을 자신감 있게 규모에 맞게 실행합니다. 4가지 기둥: 추적 계층(무엇이 일어났는지 확인), 훅 시스템(반드시 일어나야 할 일 강제), 에이전트 워크스페이스(영구 파일 관리 + 인계), IM 채널(에이전트가 사용자가 일하는 곳에 존재). 사전 구축된 솔루션 템플릿은 콜드 스타트를 제거합니다; 대시보드 개선은 운영 상태를 표시합니다. “에이전트가 따를 수 있는 지침”과 “시스템이 강제하는 보장” 사이의 간격이 좁혀집니다 — 데모와 프로덕션 엔터프라이즈 도구 간의 차이입니다.
커넥터 점진적 공개 (Phase 5): 의미론적 가이드 도구 선택 (쿼리에서 엔티티 추출 → 온톨로지 레지스트리 조회 → 커넥터 세트 축소; 50개 이상 커넥터 배포 시 90% 이상 토큰 감소); 배치/ETL 커넥터용 스케일 모드; CLI 스타일 범용 connector <name> <action> <params> 인터페이스
크로스 커넥터 엔티티 정렬 (온톨로지 레지스트리): 공유 엔티티 타입(Customer, Order, Asset) 정의 및 커넥터 간 필드 매핑; DAGPlanner가 크로스 시스템 JOIN 키 자동 해결; 하드코딩된 필드명 없이 크로스 커넥터 쿼리 가능 (예: “Salesforce의 고객 중 Shopify에서 주문한 고객”)
핫플러그 커넥터: OpenAPI 스펙 업로드, AI가 설정 생성, 5분 내 라이브 (재시작 불필요)
마켓플레이스 재설계 Phase 1 — 솔루션 + 컴포넌트: 2단계 마켓 모델 (솔루션: 에이전트/스킬/워크플로우; 컴포넌트: 커넥터/MCP 서버); 범위 선택기 (글로벌 마켓 / 조직); 통합 구독 모델 (조직 자동 표시 제거); 마켓 범위에서 KB 제거; 기존 조직 구성원을 위한 데이터 마이그레이션 구독 백필
마켓 패키지 시스템: 마켓플레이스용 배포 가능한 리소스 번들 — 타입별 “마켓플레이스”를 통합 패키징 계층으로 대체. fim-package.yaml 매니페스트 선언: 메타데이터 (이름, 버전, 설명, 작성자, 라이선스, 태그, min_fim_version), 진입점 (기본 스킬 또는 에이전트), 리소스 목록 (에이전트, 스킬, 커넥터, KB, MCP 서버, 워크플로우) 및 설정 참조, 패키지 간 의존성 (semver 범위), 필수 자격증명 (설치 시 수집을 위해 커넥터 참조로 매핑), 기본값이 있는 사용자 구성 가능 변수. 두 가지 소비 모드: (1) 설치 — 모든 리소스 일괄 생성 + ID 치환을 통한 내부 참조 자동 연결; 설치가 버전 업데이트 알림을 위한 소스에 연결됨; POST /api/market/packages/{id}/install; (2) 포크 — 사용자 소유 편집 가능 복사본으로 복제, 업데이트 링크 없음 (이것이 템플릿 모드임); POST /api/market/packages/{id}/fork. 추가 엔드포인트: 게시 (POST /api/market/packages 검토 워크플로우 포함), 제거 (DELETE /packages/{id}/uninstall 의존성 확인 + 수정된 리소스 확인 포함), 버전 기록 (GET /packages/{id}/versions), 업그레이드 (POST /packages/{id}/upgrade 리소스별 diff 미리보기 포함). 중첩된 패키지 요구사항에 대한 의존성 해결자 및 충돌 감지. PackageInstallation 테이블은 제거/업그레이드를 위한 리소스 ID 매핑과 함께 사용자별 설치된 패키지를 추적. 개별 리소스 게시와 공존 — 패키지는 구성 계층이지 대체가 아님; 단일 커넥터는 여전히 독립적으로 게시 가능. 예시 의존성 트리: Package: contract-review → Skill: contract-review (진입점) → Agent: contract-analyst + Agent: risk-scorer → KB: legal-clauses + Connector: docusign-api + MCP: pdf-extractor + Workflow: contract-approval-flow
크리에이터 프로그램: 마켓플레이스 수익화 계층 — 포트폴리오 페이지가 있는 크리에이터 프로필, 패키지별 분석 (설치, 포크, 활성 사용자, 평점/리뷰), 패키지가 새 구독을 유도할 때 제휴 수수료 추적. 가격 책정, 구매 흐름, 승인 워크플로우가 있는 유료 패키지 계층. 설치 추세, 수익 보고, 사용자 피드백이 있는 크리에이터 대시보드. 프로그래밍 방식 패키지 게시를 위한 공개 크리에이터 API (패키지 작성자용 CI/CD). 커뮤니티 기능: 패키지 댓글, Q&A, 버전별 변경 로그
임베더블 위젯: <script src="fim-one.js"> 호스트 페이지에 주입
페이지 컨텍스트 주입: 위젯이 호스트 페이지 컨텍스트 읽음 (현재 ID, URL, DOM 선택기)
고급 트리거: 웹훅 인바운드 이벤트; 예약된 작업 개선 (다중 시간대, 달력 인식)
배치 실행: DAG를 통해 1000개 이상 항목 처리
엔터프라이즈 보안: IP 화이트리스팅, 저장 데이터 암호화, SSO
KB 고급 편집기: 대규모 지식 기반을 관리하는 파워 사용자용 빌더 모드 에이전트 — 대량 URL 수집, 중복 감지, 갭 분석, 문서 라이프사이클 관리; 기존 KB AI 채팅을 ReAct 도구 루프로 확장
영향: 엔터프라이즈는 FIM One을 0에서 며칠 내에 다중 시스템 오케스트레이션으로 배포. 패키지 시스템은 크리에이터 생태계 생성 — 솔루션 작성자가 복합 번들 (스킬 + 에이전트 + 커넥터 + KB + 워크플로우) 게시, 엔터프라이즈가 한 번의 클릭으로 설치, 크리에이터가 채택으로부터 수익 창출. 설치/포크 이원성은 “있는 그대로 사용” 및 “템플릿에서 커스터마이즈” 사용 사례를 단일 메커니즘으로 커버.
직교성 전략에 따라 이러한 기능들은 출시되어 작동하지만 새로운 기능을 추가하지 않습니다 (버그 수정만 수행):
기능
버전
동결 이유
ReAct 에이전트
v0.1, v0.9
모델이 이제 기본 도구 호출 기능을 보유. 루프 중간 자체 반성(v0.9)이 긴 체인에서 목표 이탈 방지. 도구 관찰 합성 품질 개선(8K 문자, REACT_TOOL_OBS_TRUNCATION을 통해 구성 가능)
DAG 계획 / 재계획
v0.1, v0.5, v0.7.5
모델 추론 능력 향상; 분해가 단일 샷으로 변경. v0.7.5에서 단계별 검증 출시(DAG_STEP_VERIFICATION). 강화됨: 계단식 실패 전파, 검증자 상태 수정, 계획자 도구 설명, 전체 재계획 기록, 화이트리스트 기반 도구 캐시. 14개 엔진 상수가 ENV 변수로 노출됨 — 추가 계획 기본 요소 계획 없음
메모리(윈도우, 요약, 컴팩트)
v0.2, v0.5
컨텍스트 윈도우 증가(200K+); 외부 메모리 관리 필요성 감소
RAG 파이프라인
v0.5
제공자가 기본적으로 검색 구축(OpenAI file_search, Gemini Search Grounding)
제공업체가 기본적으로 구축 중 (OpenAI Swarm, Google A2A 및 유사한 다중 에이전트 제공). FIM One의 CallAgentTool은 1단계 위임 사례를 다루고, 이벤트 트리거 백그라운드 에이전트는 v0.9의 Scheduled Jobs로 다룸
에이전트 자체 수정 스킬 (절차적 메모리)
실행 중 에이전트가 자신의 skill.md를 업데이트 — 높은 복잡성, 보안/감사 표면적. 에이전트 스킬 시스템 (v0.8) 출시에 따라 달라짐. 엔터프라이즈 고객이 자체 개선 에이전트를 명시적으로 요청하면 재평가
에이전트 워크스페이스 (도구 출력 파일 오프로딩)
v0.9로 승격. 가치는 선택적 읽기이지 컨텍스트 용량이 아님 — 크로스 프레임워크 검증 확인. 원래 연기 사유 (“200K+ 윈도우는 긴급성 감소”)는 잘못됨
크로스 세션 장기 메모리
컨텍스트 윈도우가 빠르게 증가 중 (200K–2M); 제공업체가 기본 메모리 추가 중 (OpenAI 메모리, Gemini 컨텍스트 캐싱); 높은 구현 비용 vs 감소하는 차별화 가치. 엔터프라이즈 고객이 명시적으로 요청할 때 재평가
메모리 라이프사이클 (TTL, 할당량)
크로스 세션 메모리에 따라 달라짐; 함께 연기
활성 컨텍스트 압축 도구 (에이전트 트리거)
ContextGuard (v0.5)로 명시적 동결. 200K+ 컨텍스트 윈도우는 가치 감소. 컨텍스트 비용이 주요 엔터프라이즈 불만이 되지 않는 한 재검토하지 않음
브라우저 자동화 / 컴퓨터 사용
높은 유지보수 비용 (DOM 변경, 봇 방지, 샌드박싱). 업계가 컴퓨터 사용 모드 (Anthropic, OpenAI Operator, Google Mariner) 및 MCP 브라우저 도구 (Puppeteer/Playwright MCP)로 수렴 중. MCP 통합을 통해 소비, 자체 구축 금지. 안정적인 컴퓨터 사용 MCP 표준이 나타날 때 재평가
웹 푸시 알림
Service Worker + VAPID를 통한 브라우저 기본 푸시. IM 채널 통합 (v0.8)과 겹침 (엔터프라이즈 선호 채널 Lark/Slack/WeCom/Email 다룸). IM 푸시는 더 높은 엔터프라이즈 가치; 웹 푸시는 포털 전용 사용자를 위한 부가 기능. IM 채널 출시 후 재평가 — 사용자가 IM 커버리지 이상의 브라우저 알림을 요청하면
다중 사용자 워크플로우 협업 편집
동일한 워크플로우 블루프린트의 실시간 공동 편집 (Figma/Notion 스타일), 커서 인식, 충돌 해결, 노드별 잠금 포함. 높은 구현 비용 (CRDT / OT, 프레젠스 인프라), 오늘날의 “한 번에 한 편집자 + 버전 diff” 모델에 대한 엔터프라이즈 수요 불명확. 여러 엔터프라이즈가 공유 라이브 편집을 명시적으로 요청하면 재평가
노드별 워크플로우 실행 권한 (실행 시 RBAC)
단일 워크플로우 실행 내 세분화된 권한 부여 — 예: “노드 X는 실행을 위해 finance_approver 역할 필요”. 현재 권한은 워크플로우 수준 (누가 트리거할 수 있는지)과 커넥터 수준 (누구의 자격증명이 실행하는지)에서 발생; 노드별 RBAC는 활성 고객 요청 없이 실질적인 복잡성을 가진 세 번째 축 추가
라이브 업데이트를 포함한 크로스 조직 워크플로우 공유
다른 조직의 워크플로우를 구독하고 재포킹 없이 업스트림 업데이트 수신. 현재 구독 = 포크 (스냅샷), 따라서 업스트림 변경이 전파되지 않음. 라이브 업데이트는 업스트림 호환 스키마 진화 + 충돌 해결 필요; 높은 유지보수 비용. 엔터프라이즈가 “자회사 간 공유 워크플로우”를 요청하면 재평가
마켓플레이스 모더레이션: 커뮤니티 패키지 및 개별 리소스를 어떻게 검증할 것인가? 패키지 설정에서 자격증명 유출에 대한 자동 스캔? (v1.0)
토큰 경제학: 다중 사용자, 다중 에이전트 시나리오의 가격을 어떻게 책정할 것인가? (v1.0)
패키지 버전 관리: 설치된 패키지의 주요 변경사항 — 마이그레이션 스크립트를 통한 자동 업그레이드 또는 업데이트별 수동 승인? 의존성 다이아몬드 문제 해결? (v1.0)
패키지 가격 책정: 무료 vs 유료 티어, Creator Program 수수료율, 결제 제공자 통합? (v1.0)
패키지 자격증명 UX: 설치 시간 자격증명 수집 — 마법사 스타일 단계별 또는 지연된 설정? 동일한 커넥터 유형을 사용하는 패키지 간 자격증명 공유? (v1.0)
텔레메트리 옵트아웃: 개인정보 보호 기본 설정을 어떻게 준수할 것인가? (v0.8)
커넥터 버전 관리: 커넥터 API의 주요 변경사항을 어떻게 관리할 것인가? (v0.8)
속도 제한: 사용자당 워크플로우 속도 제한 배포됨 (슬라이딩 윈도우 10 runs/min, 3 concurrent). 커넥터별 및 에이전트별 속도 제한 TBD (v0.9)
커넥터 인증 티어 선택: 관리자가 주어진 업스트림 시스템에 어떤 티어가 적용되는지 어떻게 발견할 것인가? 자동 프로브 (사용자별 API 키 시도 → 로그인 티켓으로 폴백 → 공유 DB로 폴백) vs. 커넥터 사양에서의 명시적 선언? “이 커넥터는 Tier 2를 지원하지만 관리자가 Tier 1로 운영하도록 선택했습니다”를 기술적이지 않은 관리자를 혼동시키지 않으면서 UI에 어떻게 표현할 것인가? (v0.9)
Integration vs Connector 이중성: Feishu 바인딩이 동시에 SSO 제공자이면서 API 호출 표면인 경우, 설정에서 어떻게 표현할 것인가? 자격증명을 공유하는 세 개의 토글이 있는 하나의 객체, 또는 세 개의 별도 바인딩? 제거 의미론에 대한 영향 (SSO를 취소하면 커넥터가 종료되는가?) (v0.9)
