Kimi 프로바이더

왜 목록에 있는가

가장 큰 경쟁 JetBrains 플러그인 zhukunpenglinyutong/jetbrains-cc-gui(star 5,315)는 ai-bridge/channels/ 아래에 여섯 개의 CLI 채널 — claude, codex, grok, kimi, opencode, pi — 을 붙였지만 그 사이에 공통 계약이 없습니다.

Kimi는 그 여섯 중 하나입니다. 이 라이브러리의 계획된 프로바이더 집합은 그 목록에서 나왔습니다. 누군가가 이미 수고를 들여 연결해 둔 CLI가 무엇인지에 대한 기록이며, 이는 추측보다 나은 근거입니다.

알려진 것

여섯 채널 중 하나라는 사실, 그 이상은 없습니다.

조사는 Claude와 Codex의 send 파라미터만 상세히 다루었습니다. Kimi의 것은 기록되지 않았으므로, 대화를 어떻게 식별하는지, 무엇을 받는지, 어떻게 되보고하는지에 대해 여기서 확립된 것은 없습니다.

알려지지 않은 것

그 밖의 전부입니다. 아직 조사되지 않았습니다.

커맨드 이름과 대화를 식별하는 방식.
어느 플래그가 이것을 터미널 UI가 아니라 제어 가능한 양방향 스트림으로 만드는지.
출력이 type 판별자를 가진 NDJSON인지. 그렇다면 EventParser가 그대로 동작합니다.
권한 어휘, 그리고 닫힌 PermissionMode 집합이 그것을 표기할 수 있는지.
auth와 mcp 서브커맨드가 있는지, 그리고 어떤 형태로인지.

이 CLI에 대해 실행해 보기에 앞서 단언되는 것은 없습니다.

붙였을 때 기여할 것

모든 프로바이더 아래의 계약은 멤버 다섯 개이며, 의도적으로 작게 유지됩니다. 단일 구현에서 뽑아낸 계약은 추측이고, 커밋할 가치가 있는 형태는 두 번째를 견뎌 낸 것입니다.

세 번째와 네 번째 어댑터는 일반화되는 형태와 우연히 두 CLI에 맞은 형태를 구별해 줍니다. 각 이식은 같은 순서를 따릅니다.

CLI의 실제 동작에 맞춰 어댑터를 정확히 이식한다.
기존 계약을 우회해야 했던 모든 지점을 기록한다 — 특히 Auth/와 Mcp/, 그리고 PermissionMode가 맞지 않았던 모든 곳.
공통 형태를 추출한다.
그 뒤에야 AbstractAdapter를 넓힌다.

다음으로 볼 것

프로바이더 작성하기 — CLI를 붙인다는 것이 무슨 일인지.
AbstractProvider — 현재 상태의 계약.
로드맵 — 작업 순서상 이것의 위치.