iop/agent-roadmap/phase/knowledge-tool-optimization-extension/PHASE.md

Phase: 지식과 도구 최적화 확장

상태

[계획]

목표

Ollama serving 경로와 운영 기반이 안정화된 뒤, 단계 호출, tool/schema 강제, output validation, retry/fallback과 누적 요청 컨텍스트 구성을 IOP의 추론 최적화 계층으로 확장한다. 1차 MVP는 planner/generator/verifier 같은 단계 호출과 runtime schema 검증의 최소 실행 모드를 스케치하는 데 집중하고, caller-neutral 누적 요청 컨텍스트 최적화, RAG 장기 기억, advisor와 Context Hook은 서로 다른 2차 기능으로 분리한다. 이 Phase는 특정 Agent Shell에 종속되지 않고 OpenAI-compatible, A2A, IOP native protocol 중 맞는 표면에서 공통 최적화 책임을 제공하는 방향을 다룬다.

Milestone 흐름

완료된 Milestone은 archive 경로를 가리키고, 검토중, 진행중, 계획, 스케치 또는 보류 Milestone은 이 Phase 하위 milestones/ 경로를 가리킨다. 이 흐름은 해당 Phase 안의 상태 정리이며, Phase를 가로지르는 실행 순서는 아니다. Milestone은 완료, 검토중, 진행중, 계획, 스케치 또는 보류 상태 그룹으로 정리한다. Phase를 가로지르는 실제 다음 작업 선택은 전역 마일스톤 실행 순서를 우선한다.

• [완료] Tool Call Runtime 검증 재시도 MVP

  • 경로: tool-call-runtime-validation-retry
  • 요약: 명시적 tools[]/tool_choice 계약이 있는 OpenAI-compatible 요청에서 IOP 내부 provider 응답의 마지막 tool call을 검증하고, schema 불일치 시 같은 요청을 bounded exact replay로 재시도하는 runtime-only MVP를 구현한다.

• [완료] OpenAI-compatible Think 제어 MVP

  • 경로: openai-compatible-think-control
  • 요약: OpenAI-compatible Chat Completions 요청에서 thinking/reasoning 생성과 응답 노출을 요청별로 제어하고 provider별 option 매핑과 unsupported 정책을 구현한다.

• [완료] OpenAI-compatible Tool Call Boundary Hardening

  • 경로: openai-compatible-tool-call-boundary-hardening
  • 요약: provider-pool/OpenAI-compatible 응답에서 raw text tool-call block, unknown tool name, chat-template sentinel token이 클라이언트 화면으로 새지 않도록 Edge tool-call 경계를 검증/정규화한다.

• [계획] OpenAI-compatible 출력 검증 필터

  • 경로: openai-compatible-output-validation-filters
  • 요약: OpenAI-compatible Chat Completions provider stream의 single-stream 반복, incoming request history의 assistant-only anchor, 동일 tool/action 반복을 caller-neutral하고 progress-aware하게 감지해 승인된 정책에 따라 관찰, bounded 보정, continuation repair 또는 안전 중단으로 처리한다. Chat Completions SSE chunk 조립, bounded tail, terminal/tool event 판정과 상위 filter/policy replacement 적용은 별도 모듈로 분리하며, 다른 endpoint/provider codec은 후속 범위로 둔다. metadata.scheme JSON 출력 계약은 buffered contract_schema 경로로 검증/재시도한다.

• [계획] OpenAI-compatible Incomplete Tool Call Syntax Gate

  • 경로: openai-compatible-incomplete-tool-call-syntax-gate
  • 요약: terminal provider 응답에서 완성된 tool call 수와 raw/reasoning/content tool-call marker scanner 결과가 불일치하는 케이스를 runtime에서 deterministic하게 판정해 incomplete tool-call syntax로 분류한다.

• [스케치] OpenAI-compatible Runtime Output Integrity Filter

  • 경로: openai-compatible-runtime-output-integrity-filter
  • 요약: terminal assistant 응답이 content, valid tool call, 명시 허용 structured/error finish 중 하나를 만족해야 한다는 runtime invariant를 정의하고, empty terminal, reasoning-only, incomplete tool-call syntax 같은 deterministic violation을 공통 filter pipeline과 bounded retry 정책으로 묶는다.

• [스케치] LLM 판별 기반 Missing Tool Call 재시도 Gate

  • 경로: llm-judged-missing-tool-call-retry-gate
  • 요약: Pi/dev-corp 같은 tool-bearing 요청에서 provider가 tool 사용 의도를 reasoning했지만 tool call 없이 종료하는 케이스를 LLM judge와 buffered retry 후보로 재검토하고, 정확한 종료/재시도 정책이 정의될 때까지 구현을 잠근다.

• [스케치] 단계 호출과 검증 최적화 MVP

  • 경로: knowledge-tool-validation-optimization
  • 요약: 요청 의도 분석, 실제 작업, 검증/schema 강제, 오류 시 회귀를 단계 호출 실행 모드의 MVP 후보로 스케치한다.

• [스케치] Tool Call 판정 모델 Gate 리뷰

  • 경로: tool-call-validator-model-gate-review
  • 요약: 명시적 tool schema만으로 판정할 수 없는 자연어/텍스트/agent-specific tool call 후보를 별도 validator 모델로 분류할지, 어떤 조건에서 허용할지 사용자 리뷰가 필요한 결정 항목으로 스케치한다.

• [스케치] 누적 요청 컨텍스트 구성과 최적화

  • 경로: request-context-assembly-optimization
  • 요약: Agent, Open WebUI, 일반 API caller와 cloud 요청처럼 이전 message와 tool/search 결과가 누적되어 들어오는 요청을 target별 context package로 구성·축소하는 caller-neutral 방향을 스케치한다.

• [스케치] 장기 기억과 RAG 업데이트 사이클 (2차)

  • 경로: long-term-memory-rag-second-wave
  • 요약: 특정 repo 장기 기억, RAG 저장소, update cycle, MCP 기반 context 절약은 MVP 이후 2차 후보로 스케치한다.

• [스케치] Advisor와 Context Hook 확장 (2차)

  • 경로: advisor-context-hook-second-wave
  • 요약: advisor 역할과 여러 최적화·검증 기능을 실행 흐름에 연결할 수 있는 Context Hook의 호출·실패·노출 경계를 별도 2차 후보로 스케치한다.

Phase 경계

• 이 Phase는 Ollama 경로와 Edge model group queue가 안정적인 serving 경로로 검증된 뒤 시작한다.
• 이 Phase는 Control Plane/Client 운영 기반과 운영 관측 MVP 없이 현재 provider 확장 Phase 안으로 당겨 구현하지 않는다.
• 기본 /v1/models, /v1/chat/completions, Edge-Node relay, Ollama option/API passthrough 안정화는 Ollama 서빙 안정화 기반 Phase 책임이다.
• 추가 추론 서버 provider의 adapter/config/target/model 매핑 표준화는 추론 서버 provider 확장 Phase 책임이다.
• 단계 호출, schema 강제, validation/fallback은 1차 MVP 후보로 검토하되, 누적 요청 컨텍스트 최적화, 장기 기억/RAG, advisor, Context Hook, cloud fallback, 품질 평가 feedback은 서로 책임이 다른 2차 또는 그 이후의 확장으로 둔다.
• direct/Plan/Milestone 분류와 workflow 실행 라우팅은 Automation Runtime과 Bridge 확장 Phase 책임으로 두며, 이 Phase의 컨텍스트 최적화 계층은 선택된 target과 budget을 소비할 뿐 target을 고르지 않는다.