콘텐츠로 이동

Grok 프로바이더

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

Grok은 그 여섯 중 하나입니다. 이 라이브러리가 지원을 계획하는 프로바이더 목록은 그 집합에서 나왔습니다. 어느 CLI가 중요한지에 대한 추측이 아니라, 사람들이 플러그인에서 실제로 구동하기를 원한 CLI가 무엇인지에 대한 근거이기 때문입니다.

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

조사는 두 채널의 send 파라미터를 상세히 기록했지만 — Claude의 sessionId·disableThinking·agentPrompt에 대해 Codex의 threadId·baseUrl·apiKey·serviceTier — Grok은 그중에 없었습니다.

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

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

여기서 조사를 대신하는 추론은 제시하지 않습니다. 이 CLI를 붙일 때, 사실은 그것을 실행하는 데서 나올 것입니다.

AbstractAdapter는 멤버 다섯 개이며, 두 번째 어댑터가 질문을 던지기 전까지 그대로입니다. 두 번째로 도착하는 CLI가 형태를 결정하고, 그 이후의 것들이 그 형태가 단일한 한 쌍에 맞춰진 것이 아님을 확인해 줍니다.

이식 순서는 프로바이더마다 달라지지 않습니다.

  1. CLI의 실제 동작에 맞춰 어댑터를 정확히 이식한다.
  2. 기존 계약을 우회해야 했던 모든 지점을 기록한다.
  3. 공통 형태를 추출한다.
  4. 그 뒤에야 AbstractAdapter를 넓힌다.