DeepSeek Harness é um loop. O agente lê seu espaço de trabalho, edita arquivos, executa comandos através de sua ferramenta bash e decide o que fazer em seguida com base na saída. Então, por que seus testes de API não estão nesse loop? Eles ficam no Apidog atrás de uma GUI e são executados quando alguém se lembra de clicar. O agente nunca os toca.
A solução é um único bloco de configuração. O CLI do Apidog é um pacote npm, apidog-cli, que executa os cenários de teste que você construiu no Apidog diretamente de um terminal. Uma vez que o CLI esteja instalado e o DeepSeek Harness saiba que ele existe, o agente executa um cenário do Apidog da mesma forma que executa seus testes de unidade: dispara o comando, lê o código de saída, corrige o código se estiver vermelho.
button
Há também um argumento de token para fazer isso. Um agente que confirma se sua API ainda funciona relendo o código do handler e raciocinando sobre as formas de resposta queima contexto a cada passagem. Um agente que executa um comando obtém a verdade em poucas linhas. O CLI comprime "a API está correta?" em um código de saída, e o agente gasta seu contexto na correção, em vez disso.
Este guia cobre a parte específica do harness que o guia de instalação genérico omite: qual arquivo de instruções o DeepSeek Harness realmente lê, como sua ferramenta bash executa apidog run e como manter o loop honesto. Se você ainda não instalou o CLI, faça isso primeiro. Como instalar o Apidog CLI com um agente de codificação de IA descreve a instalação do npm, a autenticação e a primeira execução. Este artigo assume que apidog --version imprime um número e que sua máquina está autenticada.
Sobre qual DeepSeek Harness este artigo trata
DeepSeek Harness, dsh na linha de comando, é o harness de agente de código aberto que a DeepSeek lançou em 13 de agosto de 2026, junto com o V4-Pro na API. É licenciado sob MIT, está em github.com/deepseek-ai/deepseek-harness e já havia ultrapassado 169 mil estrelas em 20 de agosto. Você o inicia com npx @deepseek-ai/dsh web, que serve uma interface web local em http://127.0.0.1:3080. Lá você escolhe um espaço de trabalho, o diretório do projeto onde você o iniciou, e o agente trabalha dentro dele: lendo e editando arquivos, executando comandos e perguntando antes de operações que exigem aprovação sob a política de permissão ativa.
Duas coisas moldam tudo abaixo. Primeiro, o harness é uma prévia para desenvolvedores. O README avisa, em letras maiúsculas, que haverá mudanças que quebrarão a compatibilidade, então considere os nomes de arquivo e as chaves de configuração aqui como precisos para o final de agosto de 2026 e verifique novamente a documentação do repositório se algo não carregar. Segundo, tudo no dsh é um plugin, construído na arquitetura Cordis, o que torna a pergunta prática abaixo respondível: qual plugin lê suas regras de projeto e o que ele procura? Para um tour mais amplo, veja o que é DeepSeek Harness; para ver como ele se compara ao concorrente, veja DeepSeek Harness vs Claude Code.
Passo 1: coloque o CLI no AGENTS.md
O DeepSeek Harness lê as instruções do espaço de trabalho através de seu plugin @deepseek-ai/dsh-agent-instructions, e as configurações padrão são amigáveis se você já usou outros agentes. De acordo com a fonte do plugin e o catálogo de configuração, o carregador percorre a partir do diretório de trabalho da sessão até a raiz do seu projeto (marcada por .git) e carrega AGENTS.md, voltando para CLAUDE.md, em cada diretório ao longo do caminho. Overlays locais chamados AGENTS.local.md ou CLAUDE.local.md carregam após os arquivos base, e um AGENTS.md global de usuário fixo em $DSH_HOME (padrão ~/.dsh) se aplica a todos os projetos. Arquivos com mais de 1 MiB são ignorados, o que seu arquivo de regras nunca atingirá.
O resultado prático: se o seu repositório já tem um AGENTS.md para Codex ou um CLAUDE.md para Claude Code, o DeepSeek Harness o reconhece sem nenhuma configuração extra. Adicione um pequeno bloco do Apidog a ele:
## API testing with the Apidog CLI
- To test the API, run the Apidog scenario. Do not click through the GUI.
- Command: apidog run -t <scenario_id> -e <env_id> -r cli
- Exit code 0 means every assertion passed. Non-zero means a failure; read the report and fix the code.
- The machine is already authenticated. Never add an --access-token flag and never put a token in this file.
É por isso que o arquivo de regras supera o chat. Um ID de cenário digitado no compositor de sessão desaparece quando a sessão termina. Um escrito em AGENTS.md é carregado em cada nova sessão, para cada colega de equipe, em cada máquina que clona o repositório. Se você trabalha em vários projetos, o ~/.dsh/AGENTS.md global do usuário carrega o hábito ("sempre verifique as mudanças da API com o comando apidog run do projeto") enquanto o arquivo de cada repositório carrega os IDs reais.
Passo 2: obtenha o comando do Apidog
Você não precisa adivinhar os IDs do cenário e do ambiente. Abra o cenário de teste no Apidog, vá para a aba CI/CD e copie o comando gerado. Ele se parece com isto:
apidog run -t 123456 -e 789012 -r cli
A flag -t é o ID do cenário de teste, -e é o ID do ambiente, e -r cli seleciona o relator que imprime os resultados inline, o que é exatamente o que um agente precisa ler. Cole os IDs reais no seu bloco AGENTS.md para que o agente execute o comando gerado pelo Apidog, e não uma suposição.
Passo 3: faça o agente executar o teste
Inicie uma sessão na interface web do dsh com seu espaço de trabalho selecionado. O carregador de instruções já alimentou seu AGENTS.md no contexto do agente, então ele sabe que o CLI existe. Faça uma mudança que afete sua API, ou apenas pergunte:
Run the Apidog test scenario and tell me the exit code.
O agente o executa através de sua ferramenta bash, e saber como essa ferramenta se comporta poupa você de uma sessão de depuração mais tarde. De acordo com o catálogo de ferramentas, a ferramenta bash padrão executa cada comando em um shell limpo: nenhum diretório de trabalho, variáveis ou funções persistem entre as chamadas, e os comandos são executados a partir do espaço de trabalho da sessão, a menos que um workdir seja passado. Ótimo para apidog run, um comando único e autocontido, mas o agente não pode cd para algum lugar primeiro e executar o teste como um segundo passo. Se o seu cenário deve ser executado a partir de um subdiretório, coloque a invocação completa em uma única linha no seu arquivo de regras.
Mais dois comportamentos que vale a pena conhecer. Saídas não-zero retornam como um marcador explícito [exit code: N], então o sinal de sucesso/falha sobrevive mesmo quando uma saída longa é truncada em sua parte final. E os comandos podem ser executados sob um sandbox de arquivo: uma operação bloqueada é relatada como uma negação de política, não uma falha de comando. Uma execução de teste somente leitura raramente aciona isso, mas o reporter HTML que escreve para ./apidog-reports poderia, dependendo da política ativa.
Se a execução precisa do seu clique primeiro, depende da mesma política de permissão. A interface web pede antes de operações que exigem aprovação sob ela, de acordo com o guia do usuário. Quando ele solicitar apidog run, aprove-o: um cenário de teste contra o ambiente de staging é exatamente o tipo de comando seguro e de leitura que o fluxo de aprovação existe para permitir.
Passo 4: leia o relatório
Quando uma execução fica vermelha, o relatório tem a resposta. Com -r cli, o agente obtém um detalhamento legível inline: cada requisição, cada asserção e qual falhou com o valor esperado versus o real. A asserção falha nomeia o campo exato ou o código de status, o que geralmente é suficiente para o agente localizar a correção sem que você precise traduzir.
Para um relatório que você pode abrir em um navegador ou entregar a um colega de equipe, adicione o reporter HTML:
apidog run -t 123456 -e 789012 -r cli,html
O reporter html escreve um arquivo autocontido para ./apidog-reports. Mantenha cli na lista para que o agente ainda obtenha a saída inline que ele lê para decidir seu próximo passo.
O loop, de ponta a ponta
Aqui está o que a configuração oferece. Digamos que o agente esteja editando um handler de checkout. Sem o CLI, seu loop termina em “o código parece correto.” Com o bloco em AGENTS.md, o loop se estende: ele edita o handler, executa apidog run -t 123456 -e 789012 -r cli e lê o resultado. Verde, ele prossegue. Vermelho, ele vê [exit code: 1], lê qual asserção falhou (um 500 onde um 200 era esperado, um campo total ausente, um código de moeda incorreto), corrige o handler e o executa novamente. A verificação do contrato da API torna-se parte do mesmo ciclo de edição-teste-correção que o agente já executa com seus testes de unidade.
Note o que o agente não fez: reler cada arquivo de rota para se convencer de que a API funciona. O cenário já codifica o comportamento esperado, construído visualmente no Apidog por quem é responsável pela API. O agente delega a verificação a uma ferramenta determinística e gasta seus tokens onde o julgamento é necessário. Essa divisão de trabalho é o padrão completo: o dsh escreve código, o CLI verifica a camada da API, e você cria cenários no Apidog sem escrever nenhum código de teste.
Verifique se o dsh realmente executou
Agentes relatam sucesso que não conquistaram, e um harness em prévia para desenvolvedores não é o lugar para aceitar a prosa com fé. Três verificações, na ordem em que pegam problemas.
Primeiro, confirme se o comando foi executado. A interface web do dsh mostra as chamadas de ferramentas do agente e suas saídas na sessão. Procure pela chamada bash literal apidog run ... e seu resultado. Se o agente diz que executou os testes, mas nenhuma chamada desse tipo aparece, ele resumiu algo que nunca fez. Peça para ele executar novamente e mostrar a saída bruta.
Segundo, confirme o código de saída. Pergunte diretamente: “qual foi o código de saída daquele comando apidog run?” O harness entrega ao agente um marcador explícito [exit code: N] em caso de falha, então não há ambiguidade para se esconder. Quando o resumo do agente diz “testes passaram” mas o marcador indicou não-zero, o marcador está correto.
Terceiro, confirme se ele usou o cenário real. Uma falha de “cenário não encontrado” geralmente significa que o agente inventou ou se esqueceu de um ID. Verifique novamente os valores de -t e -e contra seu bloco AGENTS.md e o comando na aba CI/CD do Apidog. Os IDs no arquivo de regras são a verdade; qualquer outra coisa que o agente digitou é uma suposição.
Opcional: adicione o servidor Apidog MCP para acesso à especificação
A execução de cenários cobre a verificação. Se você também quer que o agente leia sua especificação de API enquanto escreve código, isso é trabalho para o MCP, e aqui a imagem honesta importa: a partir do final de agosto de 2026, o suporte a MCP não está documentado no README principal ou no guia do usuário do DeepSeek Harness. O que existe é um plugin da comunidade, hyqhyq3/dsh-mcp-manager, descoberto através do tópico do GitHub dsh-plugin como o resto do ecossistema. Ele adiciona uma página MCP em Configurações, suporta servidores HTTP remotos e stdio locais, registra ferramentas como mcp__<name>__* e lê definições de servidor por projeto de <workspace>/.dsh/dshmm/mcp.json.
Através dele você pode conectar o servidor Apidog MCP, que expõe suas especificações de API via MCP para que o agente possa verificar o esquema real de um endpoint antes de escrever o handler, em vez de depois que o cenário falha. Plugin da comunidade mais host de prévia para desenvolvedores significa que essa combinação pode quebrar na atualização de qualquer lado, então trate-o como uma camada bônus. O caminho do CLI acima é o essencial: ele precisa apenas de um shell.
Ressalvas da prévia e para onde isso vai
O DeepSeek Harness se move rapidamente e avisa que quebrará coisas. Os detalhes mais propensos a mudar são os nomeados aqui: os arquivos candidatos do plugin de instruções, o relatório de sandbox da ferramenta bash e qualquer coisa que o plugin MCP da comunidade toque. O padrão, no entanto, é portátil. Um arquivo de regras que diz “verifique a API com este único comando” mais um CLI que retorna um código de saída limpo funciona no dsh hoje pela mesma razão que funciona no Claude Code e em todos os outros harnesses desta série: agentes são bons em ler a saída de comandos e ruins em serem confiáveis sem ela.
Então: baixe o Apidog, construa um cenário de teste visualmente, copie seu comando apidog run da aba CI/CD e adicione o bloco ao AGENTS.md que seu repositório provavelmente já possui. Da próxima vez que o DeepSeek Harness tocar no seu código de API, ele verificará seu próprio trabalho antes de dizer que terminou.
FAQ
O DeepSeek Harness lê AGENTS.md nativamente? Sim. O plugin @deepseek-ai/dsh-agent-instructions carrega AGENTS.md (ou CLAUDE.md como fallback) da raiz do seu projeto e dos diretórios acima do diretório de trabalho da sua sessão, além de overlays AGENTS.local.md/CLAUDE.local.md e um AGENTS.md global de usuário em ~/.dsh. Se você já mantém um AGENTS.md para outros agentes, o dsh o reconhece inalterado.
Preciso de um plano pago do DeepSeek para usar o Apidog CLI no dsh? Não. O harness é de código aberto e licenciado sob MIT, e você traz seu próprio modelo: provedores de catálogo cobrem Anthropic, OpenAI, Bedrock, Vertex e Azure, e gateways personalizados funcionam através de settings.yaml, conforme abordado em como executar qualquer modelo no DeepSeek Harness. O próprio Apidog CLI é um pacote npm gratuito; ele precisa de um cenário de teste do Apidog e autenticação, não de um modelo específico.
Por que o segundo comando do agente esquece o diretório para o qual o primeiro comando mudou? Por design. A ferramenta bash padrão do dsh executa cada chamada em um shell limpo, então o cd não persiste entre os comandos. Passe o parâmetro workdir da ferramenta ou, de forma mais simples, mantenha a invocação completa de apidog run em uma única linha no seu arquivo de regras para que não haja nada a esquecer.
O dsh pode executar o cenário sem me perguntar toda vez? Isso depende da política de permissão ativa. A interface web pede antes de operações que exigem aprovação sob ela; o guia do usuário não enumera os níveis da política, então verifique as Configurações na sua compilação para ver o que sua implantação permite. Quando ele solicita, aprovar um apidog run contra o ambiente de staging é um "sim" seguro.