Project Knowledge Graph

Problem

When agents work with knowledge bases, the hard part is often not whether an API exists, but which API should be called, how to locate the target base, how to write files, web pages, notes, or URLs safely, and how to present internal identifiers as user-facing names. This skill targets knowledge base workflows built on openapi/wiki/v1 and maps user intent to concrete APIs and parameter constraints.

How it works

• Write workflows: For file uploads, run prechecks and check_repeated_names before create_media, COS upload, validation, and add_knowledge. Batch uploads can check up to 2000 file names at once.
• Content sources: Add web or WeChat articles via import_urls, add notes with add_knowledge and media_type=11, or ingest URLs. If a URL points to a file-type resource such as PDF/Word/PPT, handle it through the file upload flow.
• Discovery and browsing: If the user knows a name but not an ID, use search_knowledge_base; if no target base is specified, use get_addable_knowledge_base_list and let the user choose. Browse with get_knowledge_list and search with search_knowledge.
• Source documents: Use get_media_info to retrieve original-content metadata. For export or download, append response-content-type and response-content-disposition so the browser downloads the file with the intended name.

Boundaries and notes

This skill is useful when natural-language tasks need to be grounded in specific knowledge base APIs, especially for uploading, searching, browsing, locating folders, and exporting source documents. Read operations are not subject to the upload safety gate, but write operations must follow repeated-name checks, COS upload, and validation. User-facing output should hide knowledge_base_id, media_id, and folder_id, and batch results should summarize successes and failures instead of exposing every internal step.