qwai-tech2k downloadsAI chat, agents, and MCP tooling for your notes.
Your notes. Your models. Your AI workspace.
Chat with your notes, explore your vault, and let Agents work through multi-step tasks.
简体中文 · Install · User guide · Documentation
Desktop only · Models, tools and vault context in one workspace.

From a request to saved notes: tool use, verification and a visible task record.
Continue. in the same conversation, including after reloading Obsidian. Saved task context and tool evidence support continuation; this is not automatic crash replay or an exactly-once guarantee for external actions.| Choose the tools your Agent can use | Configure retrieval for your vault |
|---|---|
![]() |
![]() |
Actual Obsidian captures. Screenshot provenance and validation scope.
The plugin is listed in the official community registry. Community installation uses published release assets; it may install a different version from this checkout. See Releases for published assets, the 0.1.1 notes for cumulative changes including 0.1.0, and the 0.1.0 record for its original validation scope.
To build this checkout, use Node.js 22 and the committed lockfile:
git clone https://github.com/qwai-tech/obsidian-plugin-intelligence-assistant.git
cd obsidian-plugin-intelligence-assistant
npm ci
npm run build:production
Copy main.js, styles.css and manifest.json into <vault-config>/plugins/intelligence-assistant/ (<vault-config> is usually .obsidian inside your vault). Reload Obsidian and enable the plugin. For an upgrade, back up your vault and replace those three application files; retain data.json and the plugin's data/ folder.
SAP AI Core uses a Keychain entry containing the complete Service Key JSON and a resource group (usually default). The AI API URL comes from serviceurls.AI_API_URL unless overridden. Connection testing discovers running deployments. SAP code is included, but this preparation did not perform a live SAP tenant test.
Built-in Agent proposals govern supported vault edits. Configured CLI commands, MCP servers and HTTP operations can have their own filesystem, process and network effects; they are not sandboxed by the proposal UI. Grant an Agent only the tools it needs. Prompt text such as “without confirmation” does not by itself enable automatic vault writes.
| Feature | Data handling |
|---|---|
| Chat / Agent | Prompts and included notes, images, retrieved context and enabled memory are sent to the selected model service. A local endpoint keeps model processing local only if that service and its configuration do so. |
| RAG | The index is local. Indexed text is sent to the configured embedding provider; optional model grading also makes model requests. Enabled incremental indexing can process later vault changes. |
| Web search | Queries derived from the original user input go to the configured search service. |
| External tools | Tool arguments go to the configured process or endpoint, whose implementation determines its access and effects. |
| Storage / secrets | Conversations, settings, caches and memory are stored under the vault's plugin configuration directory. Provider keys, SAP Service Keys, web-search credential fields and OpenAPI authentication values use Obsidian SecretStorage references. Arbitrary CLI/MCP environment values are not automatically converted into Keychain secrets. |
Other enabled plugins share Obsidian's host environment. Tool permissions and secret references do not provide process isolation. See data and execution details.
Agent completion text is not independent proof that every requested artifact exists. Check the actual files and execution trace. Step/output budgets and provider timeouts still apply; interrupted external operations may need inspection before retrying.
Use exact tool names for a task restriction, such as Use only read_file; or No tools.. These narrow configured permissions and survive a bare continuation. They do not grant new tools. The accepted directive grammar is intentionally limited; see the guide.
The recorded 0.0.23 real gate completed a 40.525-minute task with 100 articles and a real file-measurement tool. The 0.1.0 version revision received build and actual installation/reload checks. These are separate scopes, documented in 0.1.0 validation.
npm ci
npm run dev # development build and watch
npm run lint
npm run typecheck
npm run build # development bundle
npm run build:production # production bundle and provenance
npm run verify, Jest, missions and the CI E2E suite include mocks. For a no-mock release check, configure real services and use npm run verify:release:real; see testing. A normal push to main/master triggers Build and Publish: check the version tag, lint/type-check/build, verify artifact hashes, then create the Release automatically. The CI real-verification job is temporarily removed by explicit approval; the local real-test runner remains available. See the release process.
| Document | Contents |
|---|---|
| User guide / 中文指南 | Setup, tools, permissions, continuation and data |
| Documentation index | Current guides and historical records |
| Architecture | Runtime ownership and contracts |
| Developer guide | Builds, persistence and extension points |
| Source map | Source ownership and entry points |
| Testing | Real versus mock suites and artifact-bound release evidence |
Issues and feature requests are welcome. Include the plugin/Obsidian version, provider/model, steps to reproduce and redacted logs.