Skip to content

Qoder Agent SDK:DeepSeek BYOK 是否能免除强制 Qoder 用户认证? / BYOK-only authentication support #231

Description

@Gracker

中文说明

问题概要

SmartPerfetto 希望确认:使用用户自己的 DeepSeek API Key 驱动 Qoder Agent Harness 时,是否可以不再要求第二套 Qoder 账号凭据;如果目前不支持,希望 Qoder SDK 提供相应的正式集成方式。

SmartPerfetto 是一个 AGPL 开源、自托管的 Android Perfetto 智能分析平台。它通过统一的 MCP/工具合同,为不同 Agent Runtime 提供 Trace Processor、Skills、知识库、证据验证和报告生成能力。

当前接入的 Runtime 包括:

前四种 Runtime 都可以复用用户在 SmartPerfetto Provider Manager 中配置的同一个 DeepSeek Key:分别通过 Anthropic-compatible 接口、OpenAI-compatible 接口或 Runtime Model JSON 连接 DeepSeek。Qoder 当前则需要两套独立凭据。

当前 Qoder 行为

测试基于 @qoder-ai/qoder-agent-sdk 1.0.x,包括 1.0.15。

SmartPerfetto 已经可以通过 resolveModel 向 Qoder SDK 提供 DeepSeek 自定义模型:

resolveModel: () => ({
  model: {
    provider: 'deepseek',
    model: 'deepseek-v4-pro',
    api_key: deepseekApiKey,
    url: 'https://api.deepseek.com/v1',
    style: 'openai',
  },
})

但是,query() 仍然要求独立提供 options.auth

  • 不提供 auth 会产生 auth_not_configured
  • 使用 qodercliAuth() 要求本机预先登录 Qoder CLI。
  • 使用 accessTokenFromEnv() 要求额外配置 QODER_PERSONAL_ACCESS_TOKEN
  • DeepSeek BYOK Key 不能代替 Qoder 认证;没有有效的 Qoder 认证时,CLI 会以认证失败退出。

因此,实际凭据链是:

Qoder PAT / 本地 Qoder 登录 -> 授权启动 Qoder Agent SDK
DeepSeek API Key            -> 执行具体模型推理

为什么这会影响 SmartPerfetto

我们期望的 Provider 体验是:

SmartPerfetto Provider Manager
        -> 用户自己的一个 DeepSeek Key
        -> 可切换的 Agent Runtime
        -> DeepSeek API

额外要求 Qoder 身份会产生以下问题:

  • 已经配置 DeepSeek 的用户还必须注册并登录 Qoder。
  • 浏览器登录不适合 Docker、CI、无界面服务器和 Portable 部署。
  • 为每位用户分发 Qoder PAT 不符合现有自托管 Provider Manager 的设计。
  • Qoder 与另外四个 BYOK Runtime 并列显示,但凭据语义并不等价。
  • Trace 上下文、代码上下文、Prompt 和 MCP 工具结果可能包含敏感信息,因此数据传输边界必须明确。

在 SmartPerfetto 中,我们已禁用 Qoder 内置的文件、Shell、编辑和 Web 工具。Qoder 只会获得请求范围内的 SmartPerfetto MCP 工具。我们的目标是评估 Qoder Agent Harness 的编排和会话能力,而不是使用 Qoder 托管的模型资源。

希望 Qoder 团队确认的问题

  1. Qoder Agent SDK 当前是否支持,或是否计划支持 BYOK-only 认证模式?即 resolveModel 已返回完整的第三方模型凭据后,不再要求 Qoder 账号、PAT 或本地登录。
  2. 如果 Qoder 认证不能取消,它具体负责哪项能力:产品授权、会话管理、模型目录、Telemetry,还是 Qoder Backend 的强制依赖?
  3. 对第三方平台集成,是否存在应用级凭据、Service Account、Job Token 或其他平台集成模式,避免要求每位 SmartPerfetto 用户分别登录?
  4. Docker、CI、无界面服务器和 Portable 应用的官方推荐认证方式是什么?
  5. 使用 DeepSeek BYOK 时:
    • 推理费用是否完全由用户的 DeepSeek 账号承担?
    • 是否仍会消耗 Qoder Credits?
    • Prompt、代码/Trace 上下文或 MCP 工具结果是否会经过或持久化到 Qoder 服务?
    • Runtime 是否可能静默回退到 Qoder 托管模型?
  6. provider + model + api_key + url + style 这套自定义模型结构是否属于稳定的公共 SDK 合同?是否正式支持自定义 DeepSeek-compatible Base URL?

期望的 SDK 合同

理想流程是:

SmartPerfetto
  -> Qoder Agent Harness
  -> resolveModel(DeepSeek BYOK)
  -> DeepSeek API

其中不再需要额外的 Qoder 最终用户凭据。

如果 Qoder 认证在产品架构上就是强制要求,也请明确确认。SmartPerfetto 将据此把 Qoder 展示为需要两套凭据的账号型 Runtime,而不再把它表现成与另外四个单 Key BYOK Runtime 完全等价的选项。

验收与下一步决策

满足以下任意一项即可推进:

  • Qoder 上游提供正式支持的 BYOK-only 或应用级认证模式;或
  • Qoder 官方明确确认每位用户都必须进行 Qoder 认证,并提供无界面部署、计费、模型回退和数据流边界的正式说明。

相关接入:#222


English version

Summary

SmartPerfetto needs upstream clarification or SDK support for using the Qoder Agent harness with a user-provided DeepSeek API key without requiring a second Qoder account credential.

SmartPerfetto is an AGPL, self-hosted Android Perfetto analysis platform. It exposes Trace Processor, Skills, knowledge, evidence verification, and report generation through a shared MCP/tool contract, then lets users select an Agent runtime.

The current runtime set is:

The first four can all use the same DeepSeek credential through an Anthropic-compatible endpoint, an OpenAI-compatible endpoint, or runtime model JSON. Qoder currently has a different two-credential requirement.

Current Qoder behavior

Tested against @qoder-ai/qoder-agent-sdk 1.0.x, including 1.0.15.

SmartPerfetto can provide a DeepSeek custom model through resolveModel:

resolveModel: () => ({
  model: {
    provider: 'deepseek',
    model: 'deepseek-v4-pro',
    api_key: deepseekApiKey,
    url: 'https://api.deepseek.com/v1',
    style: 'openai',
  },
})

However, query() still requires options.auth independently of the custom-model credential:

  • Omitting auth produces auth_not_configured.
  • qodercliAuth() requires a prior local Qoder CLI login.
  • accessTokenFromEnv() requires a separate QODER_PERSONAL_ACCESS_TOKEN.
  • A DeepSeek BYOK key does not replace Qoder authentication; without valid Qoder authentication, the CLI exits with an authentication failure.

The effective credential flow is therefore:

Qoder PAT / local Qoder login -> authorize Qoder Agent SDK
DeepSeek API key             -> perform model inference

Why this matters for SmartPerfetto

Our intended provider experience is:

SmartPerfetto Provider Manager
        -> one user-owned DeepSeek key
        -> selectable Agent runtime
        -> DeepSeek API

Requiring an additional Qoder identity creates several product and deployment problems:

  • Users who already configured DeepSeek must also register and authenticate with Qoder.
  • Browser login is unsuitable for Docker, CI, headless servers, and portable deployments.
  • Per-user Qoder PAT distribution does not fit the existing self-hosted Provider Manager model.
  • Qoder appears beside four BYOK runtimes but does not have equivalent credential semantics.
  • Trace context, code context, prompts, and MCP tool results may contain sensitive information, so the data path must be explicit.

Within SmartPerfetto, Qoder's built-in file, shell, edit, and web tools are disabled. It receives only request-scoped SmartPerfetto MCP tools. We want to evaluate the Qoder Agent harness and session/orchestration behavior, not Qoder-hosted model access.

Questions for the Qoder team

  1. Does the Qoder Agent SDK support, or plan to support, a BYOK-only authentication mode where a complete resolveModel custom-model result is sufficient and no Qoder account/PAT/login is required?
  2. If Qoder authentication cannot be removed, what capability requires it: licensing, session management, model catalog, telemetry, or a mandatory Qoder backend dependency?
  3. Is there an application-level credential, service account, job-token flow, or platform-integration mode that avoids requiring every SmartPerfetto user to log in separately?
  4. What is the recommended supported authentication flow for Docker, CI, headless server, and portable application deployments?
  5. When using DeepSeek BYOK:
    • Is inference billed only to the user's DeepSeek account?
    • Are any Qoder Credits consumed?
    • Do prompts, code/trace context, or MCP tool results pass through or persist on Qoder services?
    • Can the runtime silently fall back to a Qoder-hosted model?
  6. Is the provider + model + api_key + url + style custom-model shape a stable public SDK contract, including custom DeepSeek-compatible base URLs?

Desired SDK contract

Ideally, SmartPerfetto could use this flow:

SmartPerfetto
  -> Qoder Agent harness
  -> resolveModel(DeepSeek BYOK)
  -> DeepSeek API

with no additional Qoder end-user credential.

If Qoder authentication is intentionally mandatory, that is also important to confirm. SmartPerfetto should then present Qoder as an account-backed runtime with two separate credential sections rather than as an equivalent one-key BYOK runtime.

Acceptance / next decision

This issue can be resolved by either:

  • an upstream-supported BYOK-only or application-auth SDK mode; or
  • authoritative confirmation that per-user Qoder authentication is mandatory, together with documented headless deployment, billing, fallback, and data-flow semantics.

Related integration: #222

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestquestionFurther information is requested

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions