* feat(agent-core-v2): add built-in capabilities (kimi-cu, kimi-webbridge) with REST routes
Add a capability domain holding a closed registry of built-in product
capabilities. Each entry owns layered readiness detection and idempotent
install orchestration: binary runtimes from fixed official CDN URLs
(KimiCU.app + launchd service + TCC permission state; the WebBridge
daemon with start-if-down semantics for Kimi Work coexistence) plus
agent wiring through the plugin service. The WebBridge wiring un-shadows
stale user-source skill copies (user priority beats plugin priority).
kap-server exposes the domain as GET /api/v1/capabilities,
GET /api/v1/capabilities/{id}, and POST /api/v1/capabilities/{id}:install
with client-polled progress and new wire codes 40418 / 40922 / 40923.
The plugin marketplace gains an official kimi-webbridge entry
(browser-control skills) packaged by the existing CDN build.
* fix(agent-core-v2): rename the webbridge wiring plugin to kimi-webbridge-skill
An official kimi-webbridge guide plugin (install/remove setup skills,
v3.0.4) already exists at the marketplace path the capability installer
pointed at — a different artifact owned by another release line. Give
the browser-control usage-skill plugin its own id/path instead of
colliding with (or overwriting) the guide plugin. The capability entry's
detect/install now tracks kimi-webbridge-skill; a machine with only the
guide plugin correctly reports the skill layer as missing.
* feat(agent-core-v2): shelf installs auto-complete capability binary layers
Two changes to make the plugin marketplace a first-class install path:
- Marketplace gains kimi-cu (sourced from the CU team's CDN zip — no
repackaging) and the kimi-webbridge usage-skill plugin now claims the
kimi-webbridge id at v4.0.0, deliberately superseding the WebBridge
guide plugin (v3.0.4, install/remove guide skills): guide users get a
version upgrade onto the real usage skill.
- The capability service subscribes to IPluginService.onDidReload: when
a capability's wiring step flips to ok through ANY install path
(shelf, TUI, CLI), it auto-completes the missing binary layers
(KimiCU.app + service, or the WebBridge daemon). Triggers only on the
false→true edge so completed installs with still-missing manual steps
(TCC permissions) never retrigger heavy downloads on later reloads.
* fix(plugins): keep kimi-webbridge plugin version aligned with the upstream skill
The plugin version tracks the bundled official usage skill (1.11.3) so
version drift against the WebBridge release line stays visible, instead
of minting an independent 4.0.0.
* fix(agent-core-v2): never report the webbridge installer-script version as the product version
The on-disk ~/.kimi-webbridge/bin/kimi-webbridge.version file tracks the
installer's own lineage (3.1.x, bumps on every install/upgrade run),
not the product version (v1.11.3 — daemon, extension, and skills all
share it). A downed daemon would have shown the misleading installer
number; report no version instead (live /status remains the source of
truth).
* chore(plugins): list kimi-cu on the marketplace without a pinned version
Marketplace versions are optional by schema: rows display the version
detected from the installed plugin's manifest, and update prompts only
fire on a valid semver latest > local comparison. A hand-maintained
number would drift just like the guide plugin's did. The locally built
kimi-webbridge entry keeps its manifest-stamped version (1.11.3).
* fix(agent-core-v2): fire onDidReload on plugin mutations, not just explicit reload
installPlugin / setPluginEnabled / removePlugin changed the catalog
silently — consumers listening to onDidReload (session skill-catalog
convergence, the capability shelf-install hook) only converged on an
explicit reloadPlugins(). Fire the same summary-shaped event on every
mutation (added:[id] / [] / removed:[id]) so every install path
converges. This also unbreaks the shelf-install hook on real hosts:
its unit tests passed against a fake emitter that fired on installs,
which the real service never did.
* feat(kap-server): add plugin management and marketplace REST routes
Expose the App-scope plugin service over the wire so non-CLI hosts
(desktop, web) can manage plugins end to end:
- GET /api/v1/plugins/marketplace — catalog (pluginMarketplaceUrl
server option / KIMI_CODE_PLUGIN_MARKETPLACE_URL env / production
default) merged on demand with live install state; updateAvailable
only on strict semver catalog > installed (no semver dependency)
- GET /api/v1/plugins, POST /api/v1/plugins {source}
- POST /api/v1/plugins/{id}:{enable,disable,remove}
- New wire code 40419 plugin.not_found
Mutations flow through IPluginService, so they serialize with other
install paths and fire onDidReload (session skill catalogs and the
capability shelf-install hook converge).
* feat(agent-core-v2): surface a machine-key note from capability installs
CapabilityEntry.install now resolves an optional note exposed through
CapabilityInstallProgress.note (wire-visible). The webbridge entry
returns 'user-skill-migrated' when it replaces a pre-existing
user-source skill (from the official installer) with the plugin-managed
copy — clients can localize the migration instead of the skill silently
disappearing from the user's directory.
* feat(tui): let the real WebBridge marketplace entry win over the pinned promo
The hardcoded Web Bridge row was built when WebBridge had no plugin
package — it pinned above the Official tab and shadowed any catalog
entry with the same id (open-in-browser only). Now that the marketplace
carries the real kimi-webbridge plugin, flip the precedence: the catalog
entry renders and installs normally, and the pinned promo becomes a
loading/error/legacy-catalog fallback only. Footer counts keep their old
semantics (catalog-only; the promo row is never counted).
* fix(tui): dim the installed state so it stops reading as the install action
Both badges shared a near-identical green-ish treatment in the same
column, making a quiet fact look like a clickable action. States now
recede (installed → textDim) while actions stay loud (install →
primary, update → warning).
* feat(agent-core-v2): converge plugin state across processes sharing a home
Multiple hosts share one KIMI_CODE_HOME (CLI, desktop, other agents), but
each PluginService kept a private in-memory snapshot: a plugin installed
or removed in one process stayed invisible to every other live process
until its next restart — new sessions there kept offering stale plugin
skills/MCP, and the capability shelf hook never saw peer installs.
Watch <home>/plugins for installed.json changes and reloadPlugins
(debounced, echo-suppressed around our own mutations) so all consumers
converge in well under a second: session skill catalogs, plugin MCP
mounts, and the capability shelf-install hook alike.
* fix(agent-core-v2): un-shadow webbridge user skills in BOTH user dirs
kimi-code resolves user-scope skills from two roots (~/.kimi-code/skills
and ~/.agents/skills), both at priority 20 — a stale copy in either
shadows the plugin-managed wiring (priority 5), and also keeps the
capability working after the plugin is removed, which reads as
'uninstall did nothing'. Migrate copies in both dirs during install;
other runtimes' dirs (~/.claude, ~/.codex) remain untouched.
* feat(tui): show live runtime-setup progress for capability installs
Installing a capability plugin (kimi-cu, kimi-webbridge) from the
/plugins shelf kicked off a silent background binary install — the row
flipped to installed while megabytes of runtime downloaded invisibly.
Route capability entries through the capability surface instead: the
panel's inline installing line now mirrors live progress (step +
percent) until the install settles, and the transcript reports
ready / failure-with-retry / still-running accordingly. Capability
removal prints an explicit note that runtime binaries are deliberately
left untouched (the capability keeps working), since that read as
'uninstall did nothing'.
Plumbs the capability service through klient's global facade
('capabilityService' decorator resolves in-process) and the node-sdk
v2 client; Session exposes it with a structural feature-detect so v1
engines fail clearly.
* docs(plugins): keep the kimi-cu marketplace blurb accurate for every client
Only the capability-aware clients auto-install the KimiCU.app runtime;
older builds still get wiring-only (the wrapper's error message then
points at the official setup script). Don't overpromise in the catalog
text every version reads.
* feat(agent-core-v2): install capability wiring from client-bundled plugin copies
The kimi-cu / kimi-webbridge wiring plugins ship inside the client release
instead of the marketplace catalog, binding their visibility to the client
version. Capability installs now resolve the bundled copy (env override,
then npm-layout and source-checkout probes from the module) and install it
as a local path, replacing the two CDN zip URLs. A missing bundle fails the
wiring step with a clear reinstall-or-upgrade message.
* build(cli): bundle the capability wiring plugins into client releases
Vendor the official kimi-cu plugin (v0.5.4, from the CU team's plugin zip)
next to kimi-webbridge under plugins/official, copy both into
apps/kimi-code/bundled-plugins at build time, and ship them in the npm
package (files) and the native SEA blob (a new bundled-plugins asset set
extracted into the native cache at startup, published to the engine via
KIMI_CODE_BUNDLED_PLUGINS_DIR). Desktop points the same variable at its
extraResources copy. The .gitignore build-output entries are anchored so
sources under src/native and test/native stop being silently ignored.
* revert(plugins): remove the kimi-cu and kimi-webbridge marketplace entries
Both capabilities now distribute with the client (bundled wiring), so the
catalog drops back to kimi-datasource / superpowers / vercel-plugin. Older
clients never see the entries; current clients install from the Built-in
section. This also reverts the marketplace blurb commit 0635e99c5.
* feat(tui): add a Built-in capabilities section to the plugins panel
The Official tab now opens with a Built-in section fed by the engine's
capability registry (kimi-cu / kimi-webbridge): per-row install state
(install / finish setup / ready), Enter runs the full capability install
with live progress, and unsupported rows hide (kimi-cu off macOS). The
WebBridge promo fallback only remains for v1 engines — on v2 the real
built-in entry wins. Rows double as the reinstall path: a client upgrade
ships newer wiring, and installing again upserts from the new bundle.
* docs(plugins): document the Built-in section and refresh the capability changeset
* build(nix): stage bundled capability plugins into the SEA build
The native SEA blob now embeds the bundled-plugins asset set, so the nix
derivation needs the plugins tree in its src fileset and the staging step
alongside copy-web-assets before build:native:sea.
* revert: drop the client-bundled wiring distribution
Built-in visibility is simpler to get by injecting the two capability
entries into the marketplace catalog at load time; the wiring plugins
themselves keep installing from their fixed official CDN zips. Removes
the vendored kimi-cu plugin, the bundled-plugins npm/SEA packaging and
flake staging, the engine bundle resolver, and the plugins panel's
Built-in section. Keeps the /agents/ and /native/ gitignore anchors so
sources under src/native and test/native are not silently ignored.
* feat(cli): inject the built-in capability entries into the marketplace catalog
The kimi-cu / kimi-webbridge entries are appended by the client at catalog
load time instead of being served by the remote marketplace.json, binding
their visibility to the client version (older clients never see them). No
version is pinned — reinstalling upserts the wiring — and ids the catalog
already carries always win. In a source checkout the webbridge entry
installs the repo's own plugin copy; packaged builds use the official CDN
zip. This reverts the docs paragraph about the Built-in section, which the
simpler approach makes unnecessary.
* test(tui): select the catalog's own first row in marketplace install tests
The client-injected capability entries suppress the WebBridge promo and
append after the catalog rows, so Kimi Datasource now leads the Official
tab — the extra down-key landed on kimi-cu instead.
* feat(cli): surface the built-in capabilities as client-injected marketplace entries
The kimi-cu / kimi-webbridge entries are injected into the marketplace
catalog by the client (v2 engine, default catalog only) instead of being
served remotely, binding their visibility to the client version; injected
rows mask same-id catalog rows, so what these ids mean stays decided by
the client release — a future official listing only reaches older clients,
whose fix is to upgrade.
The /plugins panel shows capability readiness on the rows (setup
incomplete / installing…), platform-gates kimi-cu to macOS, and Enter
finishes the runtime setup with live progress; v1 keeps the plain plugin
install path and the WebBridge promo fallback.
Capability and plugin calls move from the ad-hoc REST routes onto the
typed klient contract (capabilityService next to pluginService), so the
public REST surface returns to its pre-feature shape. Detection is
presence-only — version pins removed: the current version is always read
live (Info.plist, daemon status, install records), installs are
detect-first and idempotent so an interrupted setup can be retried, and
reinstalling pulls the latest managed artifacts (the passive upgrade
path).
* ci: retrigger checks
* fix(cli): recognize Computer Use CDN plugins as official
* fix(cli): keep built-in entries on catalog outage and isolate detector failures
Two review follow-ups: the client-injected entries no longer disappear when
the marketplace catalog is unreachable (they are not served by it), and a
single capability's failing detect probe degrades to a failed step on that
entry instead of rejecting the whole listCapabilities call.
* refactor(cli): simplify built-in capability integration
* refactor(cli): source built-in catalog rows from the engine and tighten detect probes
The injected marketplace entries are now derived from the engine's
capability registry (listCapabilities) instead of hardcoded client-side
copies — the util only owns the mask/append mechanics, and capability ids
are no longer pinned in the CLI (the remove note resolves them through the
registry too). kimi-cu's detect-path probes (service-status, xpc-ping) get
a 3s timeout — they answer in milliseconds when healthy but run on every
status listing, so a wedged binary must degrade quickly instead of
stalling the panel. Document the Official tab's built-in capability rows
in the plugins guide.
* fix(cli): answer capability id membership without running detectors
listCapabilities() runs every entry's detect probes (seconds on a wedged
binary), so using it to decide whether to print the post-remove hint made
every plugin removal pay a full detection round. The id set is part of the
client/engine contract (mirrored in the klient schema), not product data
that drifts — restore the closed-set check. The injected catalog rows keep
flowing from the registry.
* fix(agent-core-v2): make capability setup recover from disabled, partial, and wedged states
Three review follow-ups on the install path: setup now re-enables the
wiring plugin when a previous disable survived installPlugin's upsert
(detection requires enabled, so it would otherwise strand the capability
at partial); the webbridge daemon-binary step verifies the executable bit
on POSIX, so an install interrupted between rename and chmod re-downloads
instead of failing start with EACCES; and kimi-cu's detect degrades
wedged CLI probes (service-status, xpc-ping) to failed steps instead of
throwing, keeping the detect-first install able to repair the remaining
layers — with the probe timeout injectable for tests.
* fix(agent-core-v2): abort capability downloads whose byte stream stalls
downloadToFile had no inactivity deadline: a CDN connection that stops
producing bytes hung the background install forever, wedging the
capability in a permanent installing state (retries rejected as
in-progress) until the process restarted. An idle watchdog now fails the
download after 30s without a chunk; slow but flowing downloads are
unaffected.
* fix(tui): stop offering capability setup on unsupported platforms
An installed wiring plugin whose capability is unsupported on this
OS/arch (kimi-cu off macOS, webbridge on an unknown arch) was treated
like a partial setup: the Installed tab showed setup incomplete and
Enter routed to installCapability, which the service always rejects.
Setup actions are now gated to actionable states (not_installed /
partial); unsupported renders as a dim fact and Enter opens details.
* fix(agent-core-v2): cover the two remaining install wedge modes
Review follow-ups: the KimiCU app step now requires an executable binary,
so a ditto interrupted mid-copy reads as missing and the next setup
re-copies instead of failing EACCES forever; and downloadToFile's idle
budget now also covers the response-header phase via an AbortSignal on
the fetch itself, so a connection that never completes headers fails the
install (clearing the running state) instead of hanging it.
* fix(tui): render capability rows independently of the catalog fetch
While the marketplace catalog was loading or unreachable, the Official
tab showed only the pinned WebBridge promo — built-in runtime setup was
blocked by an unrelated remote fetch, and Enter opened the browser
instead of installing. Locally-known capability rows (from the engine
registry) now render and install in every catalog state; the promo
remains only as the v1 fallback.
* fix(agent-core-v2): keep KimiCU cleanup timeouts best-effort
stopOldProcesses is documented as || true, but runCommand propagates
timeouts: a wedged old binary made kimi-cu uninstall exceed the command
timeout and the reinstall died before ditto could replace the app.
Cleanup commands now swallow failures (the timeout already attempts a
kill) so the replacement always proceeds; the command timeout is
injectable for tests alongside the probe timeout.
* fix(cli): inject built-in entries only for the default marketplace catalog
Injection is part of the default catalog experience: any explicit
replacement (slash-command source or KIMI_CODE_PLUGIN_MARKETPLACE_URL)
now opts out wholesale — its same-id rows are never masked by the
built-ins, and an unreachable custom catalog surfaces its own failure
instead of being silently replaced by a built-in-only tab.
* refactor: align capability row rendering on the source marker and drop conditional spreads
Marketplace-row capability enrichment (status, badges, issue details,
platform filtering) now keys on the capability:<id> source marker — the
same condition Enter uses to route installs — so a custom catalog row
that merely reuses a built-in id renders and installs as a plain plugin.
Also replaces the conditional-spread optional fields with direct
undefined-valued assignments per the repo coding rules.
* refactor(agent-core-v2): move capability comments to the file headers
The domain's comment convention allows only the top-of-file block:
responsibility and scope context for the recent hardening (detect-first
idempotent install, executability gates, probe-failure degradation,
best-effort cleanup, download watchdog, per-entry detection isolation)
now lives in the module headers, and inline narration beside statements
and members is removed.
* fix(tui): follow an in-progress capability install instead of restarting it
Opening /plugins while a capability setup is already running showed the
installing… row, but Enter called installCapability again and the
service's duplicate-start rejection (40922) surfaced as a fake failure.
The panel now checks the live status first and, when an install is
already running, skips the start call and just polls for the existing
progress.
* fix: align two more replacement paths with their contracts
The EXDEV daemon-binary fallback now stages on the target filesystem and
atomically renames over the destination instead of opening a
possibly-running binary for write (ETXTBSY on Linux). And the panel's
fallback capability rows (catalog loading/error) now follow the same
default-catalog condition as the loader injection, so an explicitly
overridden marketplace fully replaces the Official tab.
* fix(tui): make the built-in row marker unforgeable
The capability:<id> source string was the trust signal for routing rows
into capability installs, but any catalog can write that string — a
custom marketplace could smuggle a row past the third-party trust path
into an official runtime install. Injected rows now carry an internal
builtIn flag that the field-by-field catalog parser never produces;
rendering and install routing key on the flag, and the source string is
purely diagnostic.
* fix(agent-core-v2): include MCP server enablement in capability readiness
A user who disabled the kimi-cu stdio MCP server (/plugins mcp disable)
got a ready capability with no Computer Use tools in new sessions: the
plugin step only checked the plugin toggle, and installPlugin's upsert
preserves per-server state. Readiness now requires every declared MCP
server enabled (reporting e.g. mcp 0/1 enabled), and setup re-enables
disabled servers alongside the plugin toggle.
* fix(agent-core-v2): shell-quote ditto paths in the elevated KimiCU copy
The elevated fallback escaped paths only for the AppleScript string
delimiters, not for the /bin/sh command line inside do shell script: a
TMPDIR with spaces broke the install, and shell metacharacters in the
temp path could inject commands into an administrator-privileged script.
Paths are now POSIX single-quoted first, then the assembled command is
AppleScript-escaped.
* fix(agent-core-v2): never break a working KimiCU on a failed update
The reinstall stopped and uninstalled the old service before the
downloaded archive was unpacked: a corrupt or captive-portal zip then
tore down a previously ready setup. The archive is now staged and
unpacked first, and the app step additionally requires the bundle's
Info.plist, so a partially copied bundle reads as missing and gets
re-copied instead of failing registration against a corrupt bundle.
* fix(agent-core-v2): limit the fetch deadline to the header phase
The 30s AbortSignal stayed attached for the whole request, so a
slow-but-healthy download of a large archive was aborted at 30s total
even while chunks kept arriving — exactly what the per-chunk idle
watchdog was meant to allow. The header phase now uses an
AbortController cleared once headers arrive; the body remains governed
by the inactivity watchdog alone.
* test(tui): provide the harness plugin facade in the capability command fakes
The lazy-session refactor routes session-less plugin calls through
host.harness; the fake host now mirrors that shape.
20 KiB
Plugins
Plugins 把可复用的 Kimi Code CLI 能力打包成可安装单元——可以添加 Agent Skills、自定义 Agent、在会话启动时自动加载指定 Skill、提供系统提示词指令,也可以声明 MCP servers 来提供真实工具能力。适合把工作流共享给团队、连接外部服务,或从官方 marketplace 安装扩展。
安装与管理
在 TUI 中运行 /plugins 打开 plugin 管理器。它是一个面板,有四个 tab:Installed(管理已装的)、Official(Kimi 官方 marketplace plugin)、Third-party(第三方 marketplace plugin)、Custom(从 URL 安装),用 Tab / Shift-Tab 切换。常用按键:
| 按键 | 操作 |
|---|---|
Tab / Shift-Tab |
在 Installed / Official / Third-party / Custom 四个 tab 间切换 |
Space |
启用或禁用选中的已安装 plugin(Installed tab) |
D |
移除选中的已安装 plugin(Installed tab) |
M |
管理选中 plugin 的 MCP servers(Installed tab) |
R |
重新加载 installed.json 和所有 manifest(Installed tab) |
Enter |
Installed tab:有更新时安装更新,否则查看 plugin 详情 · Official/Third-party tab:安装或更新 · Custom tab:安装 |
I |
查看 plugin 详情(Installed tab) |
Esc |
返回或取消 |
也可以直接使用斜杠命令:
| 命令 | 说明 |
|---|---|
/plugins |
打开交互式 plugin 管理器 |
/plugins list |
列出已安装 plugins |
/plugins install <path-or-url> |
从本地目录、zip URL 或 GitHub 仓库 URL 安装 |
/plugins marketplace [source] |
浏览官方 marketplace,或传入自定义 marketplace JSON 的路径或 URL |
/plugins info <id> |
查看 plugin 详情和 diagnostics |
/plugins enable <id> |
启用 plugin |
/plugins disable <id> |
禁用 plugin |
/plugins remove <id> |
移除 plugin(需二次确认) |
/plugins reload |
重载 installed.json 和各 plugin manifest |
/plugins mcp enable <id> <server> |
启用 plugin 声明的 MCP server |
/plugins mcp disable <id> <server> |
禁用 plugin 声明的 MCP server |
Installed tab 列出已安装的 plugin,并在 marketplace 有更新版本时显示更新徽章。当一个使用了过时 plugin(其 MCP 工具或 /<plugin>:<command> 斜杠命令)的 turn 结束后,也会出现一次性提示,引导你到 /plugins 更新;每个新的 marketplace 版本只提醒一次。Official 和 Third-party tab 按 tier 列出 marketplace plugin;Custom tab 从 URL 安装。在 v2 引擎下,Official tab 还会列出内置产品能力(Kimi Computer Use——仅限 macOS——和 Kimi WebBridge):这些条目由客户端注入(不来自远端目录),每行显示部署状态(install / finish setup / ready,安装中显示实时进度)。回车执行完整的运行时部署(二进制运行时与接线插件一起装好);之后再装一遍即为升级。marketplace 目录会在需要时自动加载。每个安装会显示信任徽章:kimi-official(来自官方地址)、curated(来自精选地址)、third-party(其他所有情况)。安装第三方 plugin(任何非官方地址的 plugin,包括 Custom 安装)会先显示一个默认「取消」的确认提示,只有在你选择信任该来源后才会继续安装。
从 GitHub 安装
通过 /plugins install <url> 可以直接从 GitHub 仓库安装,支持四种 URL 形式:
https://github.com/<owner>/<repo>:安装最新 release;无 release 时回落到默认分支https://github.com/<owner>/<repo>/tree/<ref>:安装指定分支、tag 或短 commit SHAhttps://github.com/<owner>/<repo>/releases/tag/<tag>:钉死具体 taghttps://github.com/<owner>/<repo>/commit/<sha>:钉死具体 commit
网络请求只走 github.com 重定向和 codeload.github.com 下载,不调用 api.github.com。
注意事项
- Plugin 变更需要通过
/reload或新会话生效。安装、启用/禁用、移除后,运行/reload或/new;当前会话不会更新。 - 本地安装会被拷贝到
$KIMI_CODE_HOME/plugins/managed/<id>/,CLI 始终从这份托管副本运行。安装后编辑原始源目录不会生效,需重新安装。 - 移除 plugin 只会删除安装记录,托管副本和原始源文件仍保留在磁盘上。
- Plugin 目前按用户安装,对所有项目生效,暂不支持项目级安装范围。
自定义 marketplace JSON
浏览自定义目录时,把 JSON 路径或 URL 传给 /plugins marketplace <source>;或通过 KIMI_CODE_PLUGIN_MARKETPLACE_URL 覆盖默认 marketplace。plugins 数组中每个条目需要 id 和 source(本地路径、zip URL 或 GitHub URL):
{
"version": "2",
"plugins": [
{
"id": "my-plugin",
"displayName": "My Plugin",
"source": "./my-plugin"
}
]
}
Kimi Datasource
Kimi Datasource 是 Kimi Code 官方数据插件,让你通过自然语言直接查询金融行情、宏观经济、企业工商、学术文献和中国法律法规,并接入 Wind、IMF、恒生聚源、SEC EDGAR、S&P Capital IQ 等专业金融数据源,无需手动调用接口或申请任何数据账号。
安装
需先通过 /login 完成 Kimi Code 账号 OAuth 登录,插件依赖本地凭据访问数据服务。
- 运行
/plugins,选择 Official - 找到 Kimi Datasource,按
Enter安装 - 安装完成后运行
/reload或/new激活 plugin
使用 Kimi Datasource 会消耗你的 Kimi Code 套餐额度,安装结果中会提示这一点。当前最新版本为 v3.3.0。插件安装后不会自动更新,如需升级到新版本,重新执行上述安装步骤即可。
使用方式
安装完成后,直接用自然语言描述你的需求,Kimi Code 会自动调用数据能力;也可以通过 /skill:kimi-datasource 明确触发数据查询 Skill。
能做什么
实时量化研究:盯着茅台想做个量化分析?一句话拉取近三年的每日收盘价、MACD 和 KDJ 信号,直接出结论,不用找第三方数据平台。
跨国宏观对比:研究中印越产业转移?基于世界银行 50 年历史数据,一次查询拿到三国 GDP 增速、贸易额、人口结构的完整时间序列对比。
合同前风险排查:签合同前五分钟才想起来要查对方背景?输入公司名,立刻拿到工商注册信息、股权穿透、司法纠纷和失信记录,当场决策。
文献综述加速:写论文要梳理 RLHF 领域的研究脉络?直接列出高引论文、主要作者和核心结论,综述提纲半小时内成型。
法律条文速查:碰上居住权的合同纠纷,拿不准法条?一句话定位《民法典》相关条文原文、效力级别和时效性,再顺手拉几个相近判例佐证,不用翻法规库。
机构级美股研究:写美股深度报告?一句话拉出 10-K 年报原文、XBRL 标准化指标、前 50 大股东和分析师一致预期,SEC 披露文件和 S&P 数据一次配齐,不用在多个数据终端之间来回切。
数据覆盖
| 类别 | 覆盖范围 |
|---|---|
| 股票行情 | A 股、港股、美股及全球主要市场实时/历史行情、技术指标、财务报表、股票筛选 |
| 宏观经济 | 世界银行 189 个成员国、50 年以上历史时间序列(GDP、贸易、人口、气候等) |
| 企业数据 | 中国大陆境内企业工商信息、股权穿透、司法风险、关联图谱 |
| 学术文献 | 物理、数学、计算机、金融、经济等领域百万量级论文,支持预印本查询 |
| 法律法规 | 中国法律法规与司法案例:宪法、法律、司法解释、部门规章等各效力层次的法规语义/关键词检索与详情,普通及权威判例检索 |
| 综合金融终端(Wind) | A 股、基金、债券、指数行情与财务指标,上市公司公告研报,宏观经济数据 |
| 国际宏观(IMF) | IFS、BOP、DOTS、WEO 等官方数据集:汇率、CPI、国际收支、贸易、GDP 预测 |
| 智能筛选(恒生聚源) | 自然语言选股 / 选基金 / 基金经理筛选,宏观行业数据、研报、公告与新闻 |
| 美股披露(SEC EDGAR) | 8,000+ 美股上市公司 10-K/10-Q 财报、XBRL 指标、Form 4 内部人交易、13F 机构持仓、8-K 重大事项(2009 年至今) |
| 美股基本面(S&P Capital IQ) | 标准化财务报表、估值比率、分析师一致预期、股东与高管、竞争对手关系、公司事件与电话会纪要 |
计费与限制
- 数据查询按次计费,消耗 Kimi Code 账号额度
- 插件为只读查询,不提供任何写入或交易功能
- 技术指标(MACD、KDJ 等)及实时行情仅在交易时段内可用
- AI 输出内容仅供参考,不构成任何投资或商业决策建议
Plugin manifest
Plugin 是一个带 manifest 的目录或 zip 文件。Manifest 可以放在以下任一位置:
<plugin_root>/kimi.plugin.json
<plugin_root>/.kimi-plugin/plugin.json
两个文件同时存在时,以 kimi.plugin.json 为准。
示例:
{
"name": "kimi-finance",
"version": "1.0.0",
"description": "Finance data and analysis workflows for Kimi Code CLI",
"skills": "./skills/",
"systemPromptPath": "./SYSTEM.md",
"sessionStart": {
"skill": "using-finance"
},
"interface": {
"displayName": "Kimi Finance",
"shortDescription": "Market data and financial analysis workflows"
}
}
支持的字段:
| 字段 | 说明 |
|---|---|
name |
必填,作为 plugin id。必须匹配 [a-z0-9][a-z0-9_-]{0,63} |
version、description、keywords、author、homepage、license |
展示元数据 |
interface |
在 /plugins 中展示的字段:displayName、shortDescription、longDescription、developerName、websiteURL |
skills |
一个或多个 ./ 路径,必须位于 plugin 根目录内。省略时根目录的 SKILL.md 被当作单个 Skill root |
agents |
一个或多个 ./ 路径,必须位于 plugin 根目录内,指向含有 Agent 文件的目录。省略时根下的 agents/ 目录(若存在)被自动采用 |
sessionStart.skill |
在新会话或恢复会话开始时,把指定 plugin Skill 加载到主 Agent |
skillInstructions |
每次加载此 plugin 的 Skill 时一并附带的额外说明 |
systemPrompt |
plugin 启用期间提供给 Agent 系统提示词的内联指令 |
systemPromptPath |
指向 UTF-8 文本文件的 ./ 路径;同时设置 systemPrompt 时,文件内容拼接在内联指令之后 |
mcpServers |
MCP server 声明,默认启用,可从 /plugins 中禁用 |
hooks |
在 plugin 启用期间于生命周期事件上运行的 hook 规则;见插件中的 Hooks |
commands |
一个或多个 ./ 路径,指向目录或 .md 文件,把其中的 Markdown 文件注册为斜杠命令;见插件斜杠命令 |
tools、apps、inject、configFile 等不支持的运行时字段会显示为 diagnostics 并被忽略。
系统提示词指令
短指令可以直接写在 systemPrompt,较长内容则用 systemPromptPath 指向 plugin 根目录内的文件。两个字段同时存在时,内联文本在前,文件内容在后。文件内容在安装或重载 plugin 时读取,因此修改文件后需要 /plugins reload 才会生效。例如:
{
"name": "code-review",
"systemPromptPath": "./SYSTEM.md"
}
系统提示词贡献在两个 Agent 引擎上都生效:交互式 TUI 与 kimi -p(v1 引擎)、kimi web,以及 KIMI_CODE_EXPERIMENTAL_FLAG=1 时的所有 CLI 界面(v2 引擎)。
systemPrompt 字段与 systemPromptPath 文件各限制为 32 KB(UTF-8 字节):超限内容会被忽略,并显示在 plugin 的 diagnostics 中。一次提示词构建最多注入所有已启用 plugin 合计 64 KB 的指令;超出预算的贡献会被跳过并给出警告——单个 plugin 的内联文本与文件合计超过该预算时同样整体跳过。
新会话和新建 Agent 会读取当前已启用 plugin 的指令。正在进行的请求会继续使用已有的系统提示词。/plugins reload 会刷新 plugin Skill 列表,并请求重建活跃 Agent 的提示词;如果需要让变更在下一轮前明确收敛,请使用这个命令。在 v2 引擎中,安装、启用、禁用或移除 plugin 会立即更新 catalog,后续的提示词重建(例如压缩上下文或修改工具策略后)可能会读取新的指令。legacy 引擎会让每个活跃 session 保留自己的 plugin 快照,直到 /plugins reload 或创建新 session。从磁盘恢复的 session 会先使用持久化的提示词,后续重建再遵循对应引擎的行为。切换 plugin 的 MCP server 不会改变系统提示词指令。
内置 Agent 提示词会自动包含已启用 plugin 的指令。自定义 SYSTEM.md 或 Agent 文件完全拥有自己的模板,因此应在希望出现 plugin 指令的位置加入 ${plugin_sections}。如果自定义模板包含 ${base_prompt},且该有效默认提示词已经包含 plugin 块,就不要再重复加入 ${plugin_sections}。完整变量表见 自定义 Agent 与 SYSTEM.md。
插件斜杠命令
斜杠命令把一段常用提示词存成 /命令,输入它就能触发,省得每次重打。
下面是一个最小完整例子,插件目录结构:
kimi-finance/
kimi.plugin.json
commands/
report.md
manifest(kimi.plugin.json)用 commands 字段指出命令文件的位置:
{
"name": "kimi-finance",
"version": "1.0.0",
"commands": "./commands/"
}
命令文件 commands/report.md。顶部两行 --- 之间是 frontmatter(描述命令的元数据),下面的正文是触发时发给 Agent 的提示词:
---
description: 拉取指定股票的财报并总结
---
拉取 $ARGUMENTS 的最新财报数据,总结营收、利润和关键风险。
装好并启用后,在对话里输入:
/kimi-finance:report TSLA
Kimi 会把正文里的 $ARGUMENTS 替换成 TSLA,再执行这段提示词。三处细节分述如下。
声明命令(commands 字段)
commands 填一个 ./ 路径或路径数组,指向 plugin 根目录内的目录或 .md 文件:
- 指向目录:递归收集其中所有
.md文件,每个各成为一个命令。 - 指向单个
.md文件:只注册这一个。 - 指向非
.md或不存在的路径:显示为 diagnostics(/plugins面板里的诊断提示)并被忽略。
编写命令文件
命令文件分两部分:可选的 frontmatter(顶部两行 --- 之间的元数据,可写 name、description)和正文(--- 之后的提示词)。两个字段省略时的回退规则:
name(命令名):省略时用文件相对commands路径的路径命名(去.md、/分隔),如commands/frontend/component.md→frontend/component;frontmatter 里显式写的优先。description(命令列表里的说明):省略时取正文首行非空文字(超 240 字符截断);正文也为空则显示No description provided.。
调用命令与传参
命令自动以插件 id 作前缀(即命名空间),注册成 <插件名>:<命令名>,所以上面的命令实际叫 /kimi-finance:report,不同插件的同名命令因此不会冲突。
命令后输入的文字会替换正文里的 $ARGUMENTS(上例中 TSLA 替换掉 $ARGUMENTS)。若正文没写 $ARGUMENTS 却传了参数,参数不会丢弃,而是以 ARGUMENTS: <你输入的内容> 追加到正文末尾。
Skills 与会话启动
Plugin Skills 使用与普通 Agent Skills 相同的 SKILL.md 格式,典型目录结构如下:
my-plugin/
kimi.plugin.json
skills/
using-my-plugin/
SKILL.md
another-workflow/
SKILL.md
sessionStart.skill 在会话启动时把一个 plugin Skill 加载到主 Agent,适合放置初始化说明、工作流规则,或把其他工具中的术语映射到 Kimi Code CLI。它只注入文本,不执行代码。
无论 Skill 通过哪种方式加载(sessionStart.skill、/skill:<name> 或模型自动调用),skillInstructions 都会随该 plugin 的 Skill 一起出现。
插件 Agent
Plugin 可以携带自定义 Agent:在 manifest 的 agents 字段里声明一个或多个 ./ 目录(或直接在 plugin 根下放置 agents/ 目录),其中的 Agent 文件与自定义 Agent 格式相同,会在 plugin 启用期间作为子 Agent 被主 Agent 自动发现和委派。
my-plugin/
kimi.plugin.json
agents/
reviewer.md
Plugin Agent 的优先级低于其他文件来源:同名时用户级、额外目录、项目级和 --agent-file 的 Agent 都会覆盖 plugin 提供的版本;替换内置 Agent 同样需要在 frontmatter 里显式写 override: true。安装、启用、禁用或移除 plugin 后,Agent 列表在新会话(或 /reload)时刷新;v2 引擎的当前会话还会在 /plugins reload 后刷新。
Plugin 中的 MCP servers
当 plugin 需要真实工具能力时,可以在 manifest 中声明 mcpServers,复用 MCP 的 schema。
Stdio server(本地命令):
{
"mcpServers": {
"finance": {
"command": "uvx",
"args": ["kimi-finance-mcp"]
}
}
}
HTTP server(远程服务):
{
"mcpServers": {
"docs": {
"url": "https://example.com/mcp"
}
}
}
对于 stdio servers,command 可以是 PATH 上的命令,也可以是 plugin 根目录内以 ./ 开头的路径。cwd 同理,必须以 ./ 开头并位于 plugin 根目录内,否则该 server 会被忽略。
Plugin MCP servers 会在 /reload 后或新会话中启动。启用或禁用某个 server:
/plugins mcp disable kimi-finance finance
/reload
/plugins mcp enable kimi-finance finance
/reload
插件中的 Hooks
plugin 可以在其 manifest 中声明 hook 规则,在 plugin 启用期间于生命周期事件上运行。每一项使用与 config.toml 中的 [[hooks]] 规则相同的字段(event、matcher、command、timeout):
{
"hooks": [
{
"event": "PreToolUse",
"matcher": "Bash",
"command": "node ./hooks/check-bash.mjs",
"timeout": 5
}
]
}
plugin hooks 复用与全局 hooks 相同的机制——事件列表、stdin JSON 载荷以及退出码和返回值如何影响主流程,详见 Hooks。区别如下:
- plugin 的 hooks 仅在 plugin 启用期间生效;禁用 plugin 后其 hooks 停止运行。
- 每条 hook 的工作目录为 plugin 根目录,因此
command可以使用 plugin 内的./路径。 - hook 进程会额外收到两个环境变量:
KIMI_CODE_HOME和KIMI_PLUGIN_ROOT(plugin 根目录)。
仅安装 plugin 本身不会运行其 hooks——它们只在 plugin 启用期间、匹配的事件触发时运行。
安全模型
Plugin 的加载范围有限,以下操作不会在安装或会话启动时发生:
- 不会执行命令型 plugin tools 或旧式工具运行时
- 所有路径在解析符号链接后仍必须位于 plugin 根目录内
- 已启用 plugin 的 MCP servers 会在
/reload后或新会话中启动,且可随时从/plugins禁用 - 损坏的 manifest 或不安全路径会显示在
/plugins info <id>的 diagnostics 中,不影响其他会话