Pular para o conteúdo principal

Documentation Index

Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

Esta página é o design detalhado de referência da API para o SDK de aplicativos da OpenClaw público. Ela é intencionalmente separada do SDK de Plugin.
@openclaw/sdk é o pacote externo de aplicativo/cliente para se comunicar com o Gateway. openclaw/plugin-sdk/* é o contrato de autoria de Plugin em processo. Não importe subcaminhos do SDK de Plugin em aplicativos que só precisam executar agentes.
O SDK público de aplicativos deve ser construído em duas camadas:
  1. Um cliente Gateway gerado de baixo nível.
  2. Um wrapper ergonômico de alto nível com objetos OpenClaw, Agent, Session, Run, Task, Artifact, Approval e Environment.

Design de namespaces

Os namespaces de baixo nível devem acompanhar de perto os recursos do Gateway:
oc.agents.list();
oc.agents.get("main");
oc.agents.create(...);
oc.agents.update(...);

oc.sessions.list();
oc.sessions.create(...);
oc.sessions.resolve(...);
oc.sessions.send(...);
oc.sessions.messages(...);
oc.sessions.fork(...);
oc.sessions.compact(...);
oc.sessions.abort(...);

oc.runs.create(...);
oc.runs.get(runId);
oc.runs.events(runId, { after });
oc.runs.wait(runId);
oc.runs.cancel(runId);

oc.tasks.list({ status: "running" });
oc.tasks.get(taskId);
oc.tasks.cancel(taskId, { reason });
oc.tasks.events(taskId, { after }); // future API

oc.models.list();
oc.models.status(); // Gateway models.authStatus

oc.tools.list();
oc.tools.invoke("tool-name", { sessionKey, idempotencyKey });

oc.artifacts.list({ runId });
oc.artifacts.get(artifactId, { runId });
oc.artifacts.download(artifactId, { runId });

oc.approvals.list();
oc.approvals.respond(approvalId, ...);

oc.environments.list();
oc.environments.create(...); // future API: current SDK throws unsupported
oc.environments.status(environmentId);
oc.environments.delete(environmentId); // future API: current SDK throws unsupported
Wrappers de alto nível devem retornar objetos que tornam fluxos comuns agradáveis:
const run = await agent.run(inputOrParams);
await run.cancel();
await run.wait();

for await (const event of run.events()) {
  // normalized event stream
}

const artifacts = await run.artifacts.list();
const session = await run.session();

Contrato de eventos

O SDK público deve expor eventos versionados, reproduzíveis e normalizados.
type OpenClawEvent = {
  version: 1;
  id: string;
  ts: number;
  type: OpenClawEventType;
  runId?: string;
  sessionId?: string;
  sessionKey?: string;
  taskId?: string;
  agentId?: string;
  data: unknown;
  raw?: unknown;
};
id é um cursor de reprodução. Consumidores devem conseguir se reconectar com events({ after: id }) e receber eventos perdidos quando a retenção permitir. Famílias de eventos normalizadas recomendadas:
EventoSignificado
run.createdExecução aceita.
run.queuedA execução está aguardando uma faixa de sessão, runtime ou ambiente.
run.startedO runtime iniciou a execução.
run.completedA execução terminou com sucesso.
run.failedA execução terminou com erro.
run.cancelledA execução foi cancelada.
run.timed_outA execução excedeu seu tempo limite.
assistant.deltaDelta de texto do assistente.
assistant.messageMensagem completa ou substituição do assistente.
thinking.deltaDelta de raciocínio ou plano, quando a política permite exposição.
tool.call.startedA chamada de ferramenta começou.
tool.call.deltaA chamada de ferramenta transmitiu progresso ou saída parcial.
tool.call.completedA chamada de ferramenta retornou com sucesso.
tool.call.failedA chamada de ferramenta falhou.
approval.requestedUma execução ou ferramenta precisa de aprovação.
approval.resolvedA aprovação foi concedida, negada, expirou ou foi cancelada.
question.requestedO runtime solicita entrada do usuário ou do aplicativo host.
question.answeredO aplicativo host forneceu uma resposta.
artifact.createdNovo artefato disponível.
artifact.updatedArtefato existente alterado.
session.createdSessão criada.
session.updatedMetadados da sessão alterados.
session.compactedA compactação da sessão aconteceu.
task.updatedO estado da tarefa em segundo plano mudou.
git.branchO runtime observou ou alterou o estado do branch.
git.diffO runtime produziu ou alterou um diff.
git.prO runtime abriu, atualizou ou vinculou um pull request.
Payloads nativos do runtime devem estar disponíveis por meio de raw, mas aplicativos não devem precisar analisar raw para UI normal.

Contrato de resultado

Run.wait() deve retornar um envelope de resultado estável:
type RunResult = {
  runId: string;
  status: "accepted" | "completed" | "failed" | "cancelled" | "timed_out";
  sessionId?: string;
  sessionKey?: string;
  taskId?: string;
  startedAt?: string | number;
  endedAt?: string | number;
  output?: {
    text?: string;
    messages?: SDKMessage[];
  };
  usage?: {
    inputTokens?: number;
    outputTokens?: number;
    totalTokens?: number;
    costUsd?: number;
  };
  artifacts?: ArtifactSummary[];
  error?: SDKError;
};
O resultado deve ser simples e estável. Valores de timestamp preservam o formato do Gateway, então execuções atuais apoiadas por ciclo de vida geralmente relatam números de milissegundos desde a época, enquanto adaptadores ainda podem expor strings ISO. UI rica, rastros de ferramentas e detalhes nativos do runtime pertencem a eventos e artefatos. accepted é um resultado de espera não terminal: significa que o prazo de espera do Gateway expirou antes que a execução produzisse um fim/erro de ciclo de vida. Ele não deve ser tratado como timed_out; timed_out é reservado para uma execução que excedeu seu próprio tempo limite de runtime.

Aprovações e perguntas

Aprovações devem ser recursos de primeira classe porque agentes de codificação cruzam constantemente limites de segurança.
run.onApproval(async (request) => {
  if (request.kind === "tool" && request.toolName === "exec") {
    return request.approveOnce({ reason: "CI command allowed by policy" });
  }

  return request.askUser();
});
Eventos de aprovação devem conter:
  • id da aprovação
  • id da execução e id da sessão
  • tipo da solicitação
  • resumo da ação solicitada
  • nome da ferramenta ou ação de ambiente
  • nível de risco
  • decisões disponíveis
  • expiração
  • se a decisão pode ser reutilizada
Perguntas são separadas de aprovações. Uma pergunta solicita informações ao usuário ou ao aplicativo host. Uma aprovação solicita permissão para executar uma ação.

Modelo ToolSpace

Aplicativos precisam entender a superfície de ferramentas sem importar componentes internos de Plugin.
const tools = await run.toolSpace();

for (const tool of tools.list()) {
  console.log(tool.name, tool.source, tool.requiresApproval);
}
O SDK deve expor:
  • metadados normalizados de ferramenta
  • origem: OpenClaw, MCP, Plugin, canal, runtime ou aplicativo
  • resumo do schema
  • política de aprovação
  • compatibilidade de runtime
  • se uma ferramenta está oculta, é somente leitura, pode escrever ou pode operar no host
A invocação de ferramentas pelo SDK deve ser explícita e com escopo definido. A maioria dos aplicativos deve executar agentes, não chamar ferramentas arbitrárias diretamente.

Modelo de artefatos

Artefatos devem cobrir mais do que arquivos.
type ArtifactSummary = {
  id: string;
  runId?: string;
  sessionId?: string;
  type:
    | "file"
    | "patch"
    | "diff"
    | "log"
    | "media"
    | "screenshot"
    | "trajectory"
    | "pull_request"
    | "workspace";
  title?: string;
  mimeType?: string;
  sizeBytes?: number;
  createdAt: string;
  expiresAt?: string;
};
Exemplos comuns:
  • edições de arquivos e arquivos gerados
  • bundles de patches
  • diffs de VCS
  • capturas de tela e saídas de mídia
  • logs e bundles de rastreamento
  • links de pull request
  • trajetórias de runtime
  • snapshots de workspace de ambiente gerenciado
O acesso a artefatos deve oferecer suporte a redação, retenção e URLs de download sem presumir que todo artefato é um arquivo local normal.

Modelo de segurança

O SDK de aplicativos deve ser explícito sobre autoridade. Escopos de token recomendados:
EscopoPermite
agent.readListar e inspecionar agentes.
agent.runIniciar execuções.
session.readLer metadados e mensagens de sessão.
session.writeCriar, enviar para, bifurcar, compactar e abortar sessões.
task.readLer o estado de tarefas em segundo plano.
task.writeCancelar ou modificar a política de notificação de tarefas.
approval.respondAprovar ou negar solicitações.
tools.invokeInvocar ferramentas expostas diretamente.
artifacts.readListar e baixar artefatos.
environment.writeCriar ou destruir ambientes gerenciados.
adminOperações administrativas.
Padrões:
  • nenhum encaminhamento de segredos por padrão
  • nenhuma passagem irrestrita de variáveis de ambiente
  • referências a segredos em vez de valores de segredos
  • política explícita de sandbox e rede
  • retenção explícita de ambiente remoto
  • aprovações para execução no host, a menos que a política prove o contrário
  • eventos brutos de runtime redigidos antes de saírem do Gateway, a menos que o chamador tenha um escopo diagnóstico mais forte

Provedor de ambiente gerenciado

Agentes gerenciados devem ser implementados como provedores de ambiente.
type EnvironmentProvider = {
  id: string;
  capabilities: {
    checkout?: boolean;
    sandbox?: boolean;
    networkPolicy?: boolean;
    secrets?: boolean;
    artifacts?: boolean;
    logs?: boolean;
    pullRequests?: boolean;
    longRunning?: boolean;
  };
};
A primeira implementação não precisa ser um SaaS hospedado. Ela pode mirar hosts Node existentes, workspaces efêmeros, executores no estilo CI ou ambientes no estilo Testbox. O contrato importante é:
  1. preparar workspace
  2. vincular ambiente seguro e segredos
  3. iniciar execução
  4. transmitir eventos
  5. coletar artefatos
  6. limpar ou reter conforme a política
Quando isso estiver estável, um serviço de nuvem hospedado poderá implementar o mesmo contrato de provedor.

Estrutura de pacotes

Pacotes recomendados:
PacoteFinalidade
@openclaw/sdkSDK público de alto nível e cliente Gateway gerado de baixo nível.
@openclaw/sdk-reactHooks React opcionais para dashboards e criadores de aplicativos.
@openclaw/sdk-testingHelpers de teste e servidor Gateway falso para integrações de aplicativos.
O repositório já tem openclaw/plugin-sdk/* para Plugins. Mantenha esse namespace separado para evitar confundir autores de Plugin com desenvolvedores de aplicativos.

Estratégia de cliente gerado

O cliente de baixo nível deve ser gerado a partir de schemas versionados do protocolo Gateway, depois envolvido por classes ergonômicas escritas manualmente. Camadas:
  1. Fonte da verdade do esquema do Gateway.
  2. Cliente TypeScript de baixo nível gerado.
  3. Validadores em tempo de execução para entradas externas e payloads de eventos.
  4. Wrappers de alto nível para OpenClaw, Agent, Session, Run, Task e Artifact.
  5. Exemplos de receitas e testes de integração.
Benefícios:
  • o desvio do protocolo fica visível
  • os testes podem comparar métodos gerados com exportações do Gateway
  • o SDK de aplicativos permanece independente dos elementos internos do SDK de Plugin
  • consumidores de baixo nível ainda têm acesso completo ao protocolo
  • consumidores de alto nível recebem a pequena API de produto

Relacionados