From dd3572a0efa1c76dd7eafc9d1ef5317c68137600 Mon Sep 17 00:00:00 2001 From: toki Date: Sat, 13 Jun 2026 16:06:56 +0900 Subject: [PATCH] update agent-roadmap: automation-runtime-bridge and inference-provider-extension phase docs --- agent-roadmap/ROADMAP.md | 5 +++-- agent-roadmap/phase/automation-runtime-bridge/PHASE.md | 4 +++- .../milestones/openai-workspace-agent-execution-contract.md | 6 +++++- agent-roadmap/phase/inference-provider-extension/PHASE.md | 4 +++- .../milestones/lemonade-provider-serving-validation.md | 3 ++- .../provider-availability-capacity-queue-foundation.md | 3 ++- 6 files changed, 18 insertions(+), 7 deletions(-) diff --git a/agent-roadmap/ROADMAP.md b/agent-roadmap/ROADMAP.md index 0957fbd..02d7e5a 100644 --- a/agent-roadmap/ROADMAP.md +++ b/agent-roadmap/ROADMAP.md @@ -11,6 +11,7 @@ OpenAI-compatible API는 현재 chat completions baseline을 넘어 Responses AP IOP의 외부 실행 호출 계약은 OpenAI-compatible API 방식을 기본 표면으로 채택하고, IOP 고유의 workspace, session, agent, approval, artifact, notification 의미는 별도 `iop` wrapper field가 아니라 `metadata` 또는 IOP native endpoint의 명시 필드로 전달한다. IOP native protocol은 proto-socket을 기본으로 하며, HTTP는 OpenAI-compatible/A2A/health/bootstrap처럼 필요한 경계에서만 사용한다. A2A는 표면으로 유지하되, NomadCode가 A2A를 도입하는 시점은 현재 확정하지 않는다. +현재 제1 active delivery는 NomadCode가 IOP를 실행 백엔드로 사용할 수 있도록 OpenAI-compatible Responses 요청의 `metadata.workspace`, task/source metadata, 내부 workspace-bound agent 실행 경로를 먼저 안정화하는 것이다. 모델 선택, 로컬/클라우드 라우팅, 모델별 profile, token/속도/품질 최적화, 모델 호출 로그와 품질 평가는 IOP 책임으로 둔다. 특히 로컬 모델을 우선 활용하되, cloud fallback과 품질 평가를 결합해 엔터프라이즈 모델 서비스에 가까운 운영 품질을 목표로 한다. @@ -36,11 +37,11 @@ RAG, context 구성/압축, web search, MCP 정책, tool policy, output validati - [진행중] Automation Runtime과 Bridge 확장 - 경로: `agent-roadmap/phase/automation-runtime-bridge/PHASE.md` - - 요약: Runtime과 Automation 실행 흐름을 공통화하고, specialized domain agent의 독립 전환 이후 generic boundary 정리, bootstrap/enrollment, message boundary와 agentless remote terminal bridge를 분리해 확장하는 단계다. + - 요약: Runtime과 Automation 실행 흐름을 공통화하고, NomadCode 지원을 위한 OpenAI-compatible workspace agent 실행 계약을 최우선으로 닫은 뒤 generic boundary 정리, bootstrap/enrollment, message boundary와 agentless remote terminal bridge를 분리해 확장하는 단계다. - [진행중] 추론 서버 provider 확장 - 경로: `agent-roadmap/phase/inference-provider-extension/PHASE.md` - - 요약: Ollama 경로 안정화 결과와 Node 단일 통로 멀티 타겟 서빙 기반을 기준선으로 삼아, provider 공통 상태 확인과 capacity queue 기반을 먼저 정리한 뒤 Lemonade를 우선 provider로 올리고 이후 vLLM/SGLang 같은 추가 provider의 adapter/config/target/model 매핑 표준선을 정리하는 단계다. + - 요약: NomadCode workspace 실행 계약이 닫힌 뒤 Ollama 경로 안정화 결과와 Node 단일 통로 멀티 타겟 서빙 기반을 기준선으로 삼아, provider 공통 상태 확인과 capacity queue 기반을 먼저 정리한 뒤 Lemonade를 우선 provider로 올리고 이후 vLLM/SGLang 같은 추가 provider의 adapter/config/target/model 매핑 표준선을 정리하는 단계다. - [계획] 지식과 도구 최적화 확장 - 경로: `agent-roadmap/phase/knowledge-tool-optimization-extension/PHASE.md` diff --git a/agent-roadmap/phase/automation-runtime-bridge/PHASE.md b/agent-roadmap/phase/automation-runtime-bridge/PHASE.md index 85d2d0e..3c5dee6 100644 --- a/agent-roadmap/phase/automation-runtime-bridge/PHASE.md +++ b/agent-roadmap/phase/automation-runtime-bridge/PHASE.md @@ -8,6 +8,7 @@ Runtime과 Automation 실행 흐름을 공통화하고, agent 설치형 대상과 비설치형 대상의 제어 경로를 분리해 확장한다. CLI 실행, specialized agent 등록, bootstrap/enrollment, 원격 터미널 브리지를 서로 충돌하지 않는 운영 경로로 정리한다. +현재 제1 목표는 NomadCode가 IOP를 실행 백엔드로 사용할 수 있도록 OpenAI-compatible Responses 기반 workspace agent 실행 계약을 먼저 닫는 것이다. ## Milestone 흐름 @@ -72,7 +73,7 @@ CLI 실행, specialized agent 등록, bootstrap/enrollment, 원격 터미널 브 - [계획] OpenAI Workspace Agent Execution Contract - 경로: `agent-roadmap/phase/automation-runtime-bridge/milestones/openai-workspace-agent-execution-contract.md` - - 요약: NomadCode가 IOP CLI를 직접 실행하지 않고 IOP Edge OpenAI-compatible HTTP 호출의 `metadata.workspace`만으로 내부 workspace-bound agent target이 해당 checkout에서 산출물을 만들 수 있게 한다. + - 요약: NomadCode가 IOP CLI를 직접 실행하지 않고 IOP Edge OpenAI-compatible HTTP 호출의 `metadata.workspace`와 task/source metadata만으로 내부 workspace-bound agent target이 해당 checkout에서 산출물을 만들 수 있게 하는 최우선 contract/serving hardening 작업이다. - [계획] 원격 터미널 브리지 POC - 경로: `agent-roadmap/phase/automation-runtime-bridge/milestones/remote-terminal-bridge-poc.md` @@ -84,3 +85,4 @@ CLI 실행, specialized agent 등록, bootstrap/enrollment, 원격 터미널 브 - Edge는 실행 요청의 broker 역할을 하고, Node는 대상 transport 실행자 역할을 유지한다. - 설치 가능한 대상은 bootstrap/enrollment 경로로, 설치가 어렵거나 일회성 유지보수 대상은 remote terminal bridge 경로로 구분한다. - OpenAI-compatible Responses 표면은 외부 모델 호출 호환을 위한 입력 표면이며, IOP 고유 운영 제어는 native protocol이나 명시 운영 API로 분리한다. +- NomadCode 지원을 위한 `metadata.workspace` 실행 계약은 provider 확장, Lemonade 추가, remote terminal bridge보다 먼저 닫는다. diff --git a/agent-roadmap/phase/automation-runtime-bridge/milestones/openai-workspace-agent-execution-contract.md b/agent-roadmap/phase/automation-runtime-bridge/milestones/openai-workspace-agent-execution-contract.md index 6a8e521..d83cd98 100644 --- a/agent-roadmap/phase/automation-runtime-bridge/milestones/openai-workspace-agent-execution-contract.md +++ b/agent-roadmap/phase/automation-runtime-bridge/milestones/openai-workspace-agent-execution-contract.md @@ -10,6 +10,7 @@ 외부 소비자, 특히 NomadCode는 IOP와 CLI로 통신하지 않고 IOP Edge의 OpenAI-compatible HTTP 표면(`/v1/responses`, `/v1/chat/completions`)으로 요청한다. 이 마일스톤은 그 HTTP 요청의 `metadata.workspace`가 IOP 내부 `adapter + target` 실행 경로를 지나 실제 workspace agent process의 작업 디렉터리까지 전달되도록 만든다. 완료 지점은 NomadCode가 workspace slot path를 `metadata.workspace`로 넘겨 IOP Edge HTTP 호출 한 번으로 Codex 같은 내부 agent target이 해당 checkout 안에 roadmap Milestone 산출물을 만들 수 있는 상태다. +현재 제1 목표인 `../nomadcode` 지원을 위해 provider 확장보다 먼저 완료해야 하는 contract/serving hardening 작업으로 둔다. ## 상태 @@ -27,6 +28,7 @@ - Edge service가 workspace를 명시 실행 필드로 받아 Node `RunRequest.Workspace`로 전달하는 흐름 - Node CLI adapter 계열이 `ExecutionSpec.Workspace`를 process working directory로 적용하는 흐름 - target/session 재사용 시 workspace가 섞이지 않도록 하는 logical session 기준 +- NomadCode Core가 workspace slot path, task id, source를 OpenAI-compatible metadata로 넘기는 소비자 호출 shape - NomadCode workspace slot 기반 authoring run을 검증할 수 있는 HTTP smoke/test 기준 ## 기능 @@ -53,7 +55,8 @@ Edge service와 Node runtime 사이에서 workspace가 metadata 문자열로만 NomadCode가 Plane `Todo` projection 전 단계에서 IOP Edge HTTP 호출로 workspace agent 산출물을 만들 수 있는 최소 실행 증거를 확보한다. - [ ] [workspace-authoring-smoke] `metadata.workspace`가 가리키는 임시 checkout에서 workspace-bound agent target이 파일을 생성/수정할 수 있음을 검증한다. 검증: OpenAI-compatible `/v1/responses` smoke가 workspace 안 marker 또는 git diff를 남기고, 프로세스 cwd가 workspace 밖으로 벗어나지 않는다. -- [ ] [nomad-handoff-contract] NomadCode authoring 호출 shape를 계약 문서와 운영 문서에 연결한다. 검증: 외부 호출은 `model`, `input`, `metadata.workspace`만으로 충분하며 `metadata.cli`, root-level `iop` wrapper, IOP CLI 직접 실행을 요구하지 않는다. +- [ ] [nomad-metadata-shape] NomadCode Core가 workspace slot path를 flat `metadata.workspace`로, task/source context를 `metadata.task_id`/`metadata.source` 또는 `metadata.nomadcode.*`로 전달하는 호출 shape를 맞춘다. 검증: `../nomadcode`의 OpenAI Responses client/scheduler fixture와 IOP Edge smoke fixture가 같은 metadata contract를 사용한다. +- [ ] [nomad-handoff-contract] NomadCode authoring 호출 shape를 계약 문서와 운영 문서에 연결한다. 검증: 외부 호출은 `model`, `input`, `metadata.workspace`, task/source metadata만으로 충분하며 `metadata.cli`, root-level `iop` wrapper, IOP CLI 직접 실행을 요구하지 않는다. - [ ] [failure-surface] workspace 누락, 존재하지 않는 경로, 권한 오류, agent process exit failure가 호출자에게 구분 가능한 실패로 드러난다. 검증: 잘못된 workspace 요청이 조용히 기본 cwd에서 실행되지 않는다. ## 완료 리뷰 @@ -79,6 +82,7 @@ NomadCode가 Plane `Todo` projection 전 단계에서 IOP Edge HTTP 호출로 wo - 관련 경로: `agent-contract/provided/openai-compatible-api.md`, `apps/edge/internal/openai/`, `apps/edge/internal/service/`, `apps/node/internal/router/`, `apps/node/internal/node/`, `apps/node/internal/adapters/cli/`, `proto/iop/runtime.proto`, `configs/edge.yaml`, `agent-test/local/` - 표준선(선택): 외부 통신은 IOP Edge OpenAI-compatible HTTP 표면을 사용한다. 내부 실행은 `adapter + target`과 `RunRequest.Workspace`로 변환한다. workspace agent process의 작업 디렉터리는 prompt 본문, `metadata.cli` wrapper, IOP CLI 직접 실행이 아니라 `metadata.workspace`에서 온다. +- 우선순위: provider 상태/capacity queue, Lemonade provider, vLLM/SGLang provider 확장은 이 마일스톤으로 NomadCode workspace 실행 계약을 먼저 닫은 뒤 진행한다. - 선행 작업: `OpenAI Responses Input Surface`, `Codex App Server 스트리밍 전환` - 후속 작업: NomadCode `Milestone Work Item Creation Sync`, `원격 터미널 브리지 POC` - 확인 필요: 없음 diff --git a/agent-roadmap/phase/inference-provider-extension/PHASE.md b/agent-roadmap/phase/inference-provider-extension/PHASE.md index b3db6fe..3bce509 100644 --- a/agent-roadmap/phase/inference-provider-extension/PHASE.md +++ b/agent-roadmap/phase/inference-provider-extension/PHASE.md @@ -9,6 +9,7 @@ Ollama 경로가 안정화된 뒤, 그 결과를 기준선으로 삼아 Lemonade를 우선 provider로 올리고 이후 vLLM, SGLang 같은 추가 추론 서버 provider를 붙인다. 이 Phase는 하나의 Node transport 위에서 여러 CLI profile, terminal gateway, 추론 엔진, model target을 함께 쓰는 구조를 기준선으로 삼고, provider별 adapter/config/target/model 매핑을 단계적으로 검증한다. 추가 provider를 붙이기 전에 Node가 Ollama/Lemonade/vLLM/SGLang 같은 provider의 최소 가용 상태와 IOP-owned capacity/queue 상태를 공통 형태로 Edge에 제공하는 기반을 선행한다. +다만 현재 제품 우선순위에서는 NomadCode가 IOP Edge OpenAI-compatible Responses를 workspace agent 실행 백엔드로 사용할 수 있는 계약 하드닝이 먼저이며, 이 Phase의 provider/capacity 작업은 그 뒤의 운영 품질 확장으로 둔다. ## Milestone 흐름 @@ -21,7 +22,7 @@ Ollama 경로가 안정화된 뒤, 그 결과를 기준선으로 삼아 Lemonade - [계획] Node provider 상태와 Capacity Queue 기반 - 경로: `agent-roadmap/phase/inference-provider-extension/milestones/provider-availability-capacity-queue-foundation.md` - - 요약: provider별 health/model probe 차이를 Node adapter 내부로 숨기고, Edge가 공통으로 볼 수 있는 최소 상태와 capacity/in-flight/queued snapshot, FIFO admission queue 기준선을 만든다. + - 요약: NomadCode workspace 실행 계약이 닫힌 뒤 provider별 health/model probe 차이를 Node adapter 내부로 숨기고, Edge가 공통으로 볼 수 있는 최소 상태와 capacity/in-flight/queued snapshot, FIFO admission queue 기준선을 만든다. - [계획] Lemonade provider 서빙 경로 추가 - 경로: `agent-roadmap/phase/inference-provider-extension/milestones/lemonade-provider-serving-validation.md` @@ -42,4 +43,5 @@ Ollama 경로가 안정화된 뒤, 그 결과를 기준선으로 삼아 Lemonade - provider 작업 우선순위는 Ollama 기준선 다음 Lemonade를 우선하고, vLLM/SGLang은 그 뒤 후보로 둔다. - 여러 추론 서버 provider 표준화는 Ollama 경로가 안정화된 결과와 Node 단일 통로 멀티 타겟 기준선을 함께 기준으로 삼아 진행한다. - provider 공통 상태 확인과 Node-owned capacity/FIFO queue는 추가 provider 검증 전에 필요한 기반으로 이 Phase에서 다룬다. +- NomadCode `metadata.workspace` 기반 실행 계약과 `/v1/responses` workspace smoke가 충족되기 전에는 이 Phase를 제품 최우선 작업으로 끌어올리지 않는다. - model group alias, 여러 Node/Edge 후보 간 자동 부하 라우팅, cloud fallback, 품질 평가 feedback과 후속 최적화 계층은 이 Phase에서 다루지 않는다. diff --git a/agent-roadmap/phase/inference-provider-extension/milestones/lemonade-provider-serving-validation.md b/agent-roadmap/phase/inference-provider-extension/milestones/lemonade-provider-serving-validation.md index 2c2a9ed..e1f11e6 100644 --- a/agent-roadmap/phase/inference-provider-extension/milestones/lemonade-provider-serving-validation.md +++ b/agent-roadmap/phase/inference-provider-extension/milestones/lemonade-provider-serving-validation.md @@ -9,6 +9,7 @@ Node provider 상태와 capacity queue 기반을 전제로 Lemonade provider를 Ollama 다음 우선 provider 후보로 검증한다. Edge OpenAI-compatible 입력 표면에서 Lemonade target/model의 모델 조회, non-streaming/streaming chat, option/API passthrough, split-host smoke 기준을 검증한다. +현재 제품 정렬에서는 NomadCode workspace 실행 계약과 provider 상태/capacity queue 기반이 선행된 뒤 Lemonade를 provider 우선순위 2순위로 올린다. ## 상태 @@ -71,6 +72,6 @@ Edge OpenAI-compatible 입력 표면에서 Lemonade target/model의 모델 조 - 표준선(선택): 내부 실행 계약은 `adapter + target`을 유지하고, OpenAI-compatible API는 외부 호환 입력 표면으로 둔다. - 표준선(선택): Node provider 상태와 capacity queue 기반을 Lemonade provider에도 동일하게 적용한다. - 표준선(선택): 실제 provider가 보장하지 않는 확장 상태는 추가하지 않고, 초기 상태는 `unknown`, `available`, `unavailable`만 사용한다. -- 선행 작업: Node provider 상태와 Capacity Queue 기반 +- 선행 작업: OpenAI Workspace Agent Execution Contract, Node provider 상태와 Capacity Queue 기반 - 후속 작업: Lemonade provider 실테스트에서 확인된 serving 경로 안정화 보완 - 확인 필요: Lemonade adapter 경계, 실테스트 endpoint/served model name 또는 model, 인증/헤더 필요 여부, streaming 기대 동작 diff --git a/agent-roadmap/phase/inference-provider-extension/milestones/provider-availability-capacity-queue-foundation.md b/agent-roadmap/phase/inference-provider-extension/milestones/provider-availability-capacity-queue-foundation.md index da6849d..5756819 100644 --- a/agent-roadmap/phase/inference-provider-extension/milestones/provider-availability-capacity-queue-foundation.md +++ b/agent-roadmap/phase/inference-provider-extension/milestones/provider-availability-capacity-queue-foundation.md @@ -9,6 +9,7 @@ Ollama, Lemonade, vLLM, SGLang 같은 provider별 상태 확인 방식 차이를 Node adapter 내부로 숨기고, Edge가 동일한 형태로 provider 가용성과 부하 상태를 확인할 수 있게 만든다. 초기 상태 모델은 `unknown`, `available`, `unavailable`만 사용하고, provider별 capacity를 넘는 요청은 Node가 소유한 FIFO queue에서 대기시키는 기준선을 만든다. +현재 제품 정렬에서는 NomadCode 지원을 위한 OpenAI workspace agent 실행 계약이 먼저이며, 이 마일스톤은 그 뒤 provider 운영 품질을 높이는 후속 기반으로 둔다. ## 상태 @@ -76,6 +77,6 @@ Provider별 동시 처리 한도를 IOP가 소유하고, 한도를 넘는 요청 - 표준선(선택): provider가 직접 제공하지 않는 상태를 IOP 공통 상태로 만들지 않고, 초기 상태는 `unknown`, `available`, `unavailable`만 사용한다. - 표준선(선택): capacity와 queue는 provider 기능이 아니라 Node의 공통 provider execution wrapper 책임으로 둔다. - 표준선(선택): Edge routing은 provider별 endpoint가 아니라 Node가 제공하는 availability/load snapshot을 입력으로 삼는다. -- 선행 작업: Node 단일 통로 멀티 타겟 서빙 기반 +- 선행 작업: Node 단일 통로 멀티 타겟 서빙 기반, OpenAI Workspace Agent Execution Contract - 후속 작업: Lemonade provider 서빙 경로 추가, vLLM provider 서빙 경로 추가, SGLang provider 서빙 경로 추가, model group alias와 capacity-aware routing Milestone - 확인 필요: 없음