Use the DeepKnow REST API to import and browse knowledge, search internal knowledge, comprehensive sources, FoodPartner, or approved websites, and query actual table data.

knowledge-bases.md

import.md

search.md

food-knowledge.md

external-search.md

external-search.md

tabular.md

Based on the user's intent, first read the corresponding instruction file in full, then call the API. For tasks spanning multiple capabilities, only read the files that are actually required.

Before retrieval, select one business entry point based on the user's intent:

Select only one business entry point per operation. Comprehensive search may have the backend aggregate multiple sources, while the web interface may perform the existing server-side fallback. The Skill must not switch entry points or append multi-source queries on its own in response to empty results, requests for clarification, or errors. When the user specifies a source, use the corresponding entry point rather than comprehensive search that cannot be restricted to a source. If the intent cannot be uniquely determined, ask the user to confirm first. All data sources are accessed exclusively through this Skill's REST API and ; do not connect directly to , call MCP tools, or ask users for FoodPartner, Firecrawl, or MCP credentials.

https://wiki.sbtbiotech.cn/api/v1

All paths are relative to this URL. Do not ask the user to configure or replace .

: "${DEEPKNOW_SKILL_VERSION:?请从 SKILL.md frontmatter 注入版本}"

dk_api() { local method="$1" endpoint="$2" body="${3:-}" local args=( -sS -X "$method" "$DEEPKNOW_API_BASE/$endpoint" -H "X-API-Key: $DEEPKNOW_API_KEY" -H "X-DeepKnow-Channel: skill" -H "X-DeepKnow-Skill-Version: $DEEPKNOW_SKILL_VERSION" -H "Content-Type: application/json" ) if [ -n "$body" ]; then args+=(-d "$body") fi curl "${args[@]}" }

For file uploads, use `multipart/form-data` and do not manually add the JSON Content-Type, but the authentication, channel, and version headers are still required. See `import.md` for specific examples.

Successful responses usually use the following format: . Business errors generally use the following format:

{
  "success": false,
  "error": {
    "code": "ERROR_CODE",
    "message": "面向用户的错误描述",
    "details": "可选的额外信息"
  }
}

Authentication-stage or responses may also return . Prefer ; next, prefer when it is a string. Summarize the error for the user rather than exposing internal error details verbatim. Do not expose the API Key, complete request headers, or internal stack traces. For , check the credentials; for , check the permissions; for , check the resource ID; for , ask the user to reduce or split the file; and for , one safe retry is permitted. If the request still fails, stop and explain the error.

Every request reports the local version through . When the backend determines that an upgrade is required, it must short-circuit the request before executing the business logic and return HTTP with a top-level :

{
  "success": false,
  "error": {
    "code": "SKILL_UPGRADE_REQUIRED",
    "message": "DeepKnow skill 需要升级"
  },
  "upgrade_info": {
    "minimum_version": "<minimum-compatible-version>",
    "request_executed": false
  }
}

After receiving , proceed in the following order:

Automatic upgrades are part of API protocol handling and do not require further version negotiation or business confirmation from the user. If the host environment requires system authorization for network access or executing , follow the host's authorization procedure.

The backend must ensure that an upgrade response never executes business logic. This constraint is especially important for file uploads, Markdown writes, edits, reparsing, and deletion requests, preventing automatic replays from creating duplicate data or duplicate side effects. If the response does not contain , process the business result normally.