mio-agent-runtime 0.5.23 → 0.6.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +485 -85
- package/bin/mio.js +1882 -78
- package/observe/observer.js +73 -15
- package/package.json +45 -45
- package/scripts/check-syntax.cjs +72 -0
- package/server/agent-store.js +140 -0
- package/server/evolution-report.js +311 -0
- package/server/experience-store.js +214 -0
- package/server/insight-store.js +118 -0
- package/server/llm-client.js +69 -0
- package/server/memory-store.js +505 -3
- package/server/mio-intelligence-mcp/index.js +126 -1521
- package/server/observer-store.js +219 -0
- package/server/policy-store.js +263 -0
- package/server/query-log.js +66 -0
- package/server/subscription-store.js +213 -0
- package/server/task-store.js +385 -0
package/README.md
CHANGED
|
@@ -4,25 +4,30 @@ Mio Agent Runtime 的可发布 CLI 包。
|
|
|
4
4
|
|
|
5
5
|
安装一次,所有 Agent 自动接入 Mio。
|
|
6
6
|
|
|
7
|
-
##
|
|
7
|
+
## 安装
|
|
8
8
|
|
|
9
9
|
```bash
|
|
10
10
|
npm install -g mio-agent-runtime
|
|
11
11
|
```
|
|
12
12
|
|
|
13
|
-
> 新机器 / 升级:请安装 `>=0.5.
|
|
13
|
+
> 新机器 / 升级:请安装 `>=0.5.23`(5 host 被动观察 + trace 查询 + digest 价值管线;
|
|
14
|
+
> 0.5.23 修复了 digest 写回污染其它项目 workspace 的问题)。
|
|
14
15
|
> 旧版本只有主动 MCP 规则注入,没有「无感存/取」。安装后执行一次
|
|
15
16
|
> `mio init && mio install <host>`。
|
|
16
17
|
|
|
17
|
-
##
|
|
18
|
+
## 命令
|
|
18
19
|
|
|
19
20
|
```text
|
|
20
21
|
mio init Initialize MIO_HOME
|
|
21
22
|
mio mcp Start Mio MCP server (stdio)
|
|
22
23
|
mio install <host> Install Mio into a host (codex|opencode|workbuddy|hermes|claude)
|
|
23
24
|
mio status Show runtime and adapter status
|
|
24
|
-
mio agents List installed
|
|
25
|
+
mio agents List installed host adapters
|
|
26
|
+
mio agents list List observed agents (from agents.jsonl, --project X)
|
|
27
|
+
mio agents report Report per-agent task/memory/reuse telemetry (--agent X, --project Y)
|
|
28
|
+
mio agents register --agent-id X Register an observed agent (--yes to apply; previews by default)
|
|
25
29
|
mio evolution status Show composed evolution module health
|
|
30
|
+
mio evolution report Cross-agent evolution report: ecosystem, agents, memory health, suggestions (--period 24h|7d|30d|all)
|
|
26
31
|
mio evolution shadow record Record a shadow comparison sample
|
|
27
32
|
mio evolution dual-write record Record a dual-write comparison sample
|
|
28
33
|
mio evolution cutover readiness Assess shadow/dual-write cutover readiness
|
|
@@ -36,89 +41,93 @@ mio traces Show recent observer traces (--type/--outcome/--agen
|
|
|
36
41
|
mio prune --days 30 Trim old traces/queries/reuse records and observe.log (--dry-run to preview; --memory needs --yes)
|
|
37
42
|
mio digest --days 7 Aggregate traces/memory/reuse into an actionable report (--write-back feeds agent context files; --json)
|
|
38
43
|
mio remember "<content>" Write a memory record from the terminal (--kind/--tags/--scope/--project)
|
|
44
|
+
mio memory analyze Report duplicates, low-quality records and the kind histogram (--project/--limit)
|
|
45
|
+
mio memory archive --ids a,b Archive records, hiding them from recall/analyze (--yes required; reversible)
|
|
46
|
+
mio memory restore --ids a,b Un-archive previously archived records
|
|
47
|
+
mio memory forget --ids a,b PERMANENTLY delete records (--yes required; writes an audit entry; not undoable)
|
|
48
|
+
mio memory merge --ids a,b Merge duplicate records into one survivor (--keep/--allow-divergent; --yes required)
|
|
49
|
+
mio memory migrate --ids a,b --scope global|project Move records between the project and global layers
|
|
50
|
+
mio policy check "<action>" Check the historical risk of an action before running it (--project; reads global MIO_HOME)
|
|
51
|
+
mio creativity status Show creativity hypothesis counts and recent top ideas (reads global MIO_HOME)
|
|
52
|
+
mio creativity list List creativity hypotheses (--status active|validated|rejected|draft, --limit N)
|
|
53
|
+
mio creativity generate Generate hypotheses from 2+ --source "name|content" (calls an LLM)
|
|
54
|
+
mio creativity ferment Review and refine active hypotheses (calls an LLM)
|
|
55
|
+
mio insight status Insight counts: total, reported, unreported, high-value (needs @akemi-mio/insight)
|
|
56
|
+
mio insight list List insights (--unreported, --min-score N, --detector X, --limit N)
|
|
57
|
+
mio insight mark-reported Mark insights as reported (--ids a,b)
|
|
58
|
+
mio observer <view> Observer research pipeline views (research pipeline, not the observe daemon):
|
|
59
|
+
status|world-model|trends|research|insights|essays|dag (--base-dir DIR)
|
|
60
|
+
mio observer ingest --trace-id T --event-type E Record a trace event (--payload JSON/--outcome)
|
|
61
|
+
mio observer subscribe --event-types a,b Subscribe to events (--yes to apply; previews by default)
|
|
62
|
+
mio observer digest New events since the last digest (advances the cursor)
|
|
63
|
+
mio phase0 report Show the Phase 0 validation report (--project X, --format markdown)
|
|
64
|
+
mio host capabilities Show what each host supports and whether it is installed (--json)
|
|
65
|
+
mio task route "<task>" Which verified experiences apply to this task (--project/--scope/--limit)
|
|
66
|
+
mio task record-outcome --outcome success Record a task outcome (--yes to apply; previews by default)
|
|
39
67
|
mio --json status Machine-readable status
|
|
40
68
|
mio --json agents Machine-readable agents
|
|
41
69
|
mio --json evolution status Machine-readable evolution module health
|
|
42
70
|
```
|
|
43
71
|
|
|
44
|
-
## MCP
|
|
72
|
+
## MCP 工具
|
|
45
73
|
|
|
46
|
-
MCP
|
|
74
|
+
MCP 服务端在 5 大域共暴露 48 个工具:
|
|
47
75
|
|
|
48
|
-
###
|
|
49
|
-
`mio.memory.query` · `mio.memory.record` · `mio.memory.archive` · `mio.memory.migrate` · `mio.memory.analyze` · `mio.experience.list` · `mio.experience.confirm` · `mio.experience.reuse` · `mio.policy.check`
|
|
76
|
+
### 记忆(11)
|
|
77
|
+
`mio.memory.query` · `mio.memory.record` · `mio.memory.archive` · `mio.memory.merge` · `mio.memory.migrate` · `mio.memory.analyze` · `mio.memory.forget` · `mio.experience.list` · `mio.experience.confirm` · `mio.experience.reuse` · `mio.policy.check`
|
|
50
78
|
|
|
51
|
-
###
|
|
79
|
+
### 观察管线(14)
|
|
52
80
|
`mio.observer.world_model` · `mio.observer.trends` · `mio.observer.research` · `mio.observer.insights` · `mio.observer.status` · `mio.observer.collect` · `mio.observer.ferment` · `mio.observer.essays` · `mio.observer.dag` · `mio.observer.ingest` · `mio.observer.subscribe` · `mio.observer.digest`
|
|
53
|
-
`mio.trace.query` —
|
|
54
|
-
`mio.digest.generate` —
|
|
81
|
+
`mio.trace.query` — 按类型/结果/agent/项目/时间窗口查询 trace 日志(任务结果、工具错误);CLI 上也可通过 `mio traces` 调用
|
|
82
|
+
`mio.digest.generate` — 把近期数据聚合成可执行的 digest(agent 成功率、项目活跃度、错误热点、复用证据、建议);CLI 上也可通过 `mio digest` 调用
|
|
55
83
|
|
|
56
|
-
###
|
|
84
|
+
### 洞察自省(4)
|
|
57
85
|
`mio.insight.status` · `mio.insight.list` · `mio.insight.mark_reported` · `mio.insight.generate`
|
|
58
86
|
|
|
59
|
-
###
|
|
87
|
+
### 创意引擎(4)
|
|
60
88
|
`mio.creativity.generate` · `mio.creativity.ferment` · `mio.creativity.list` · `mio.creativity.status`
|
|
61
89
|
|
|
62
|
-
###
|
|
90
|
+
### 任务、Agent 与演化(15)
|
|
63
91
|
`mio.task.route` · `mio.task.record_outcome` · `mio.agent.register` · `mio.agent.list` · `mio.agent.report` · `mio.host.capabilities` · `mio.evolution.status` · `mio.evolution.report` · `mio.evolution.shadow.record` · `mio.evolution.dual_write.record` · `mio.evolution.cutover.readiness` · `mio.evolution.cutover.apply` · `mio.evolution.migration.plan` · `mio.evolution.authority.plan` · `mio.phase0.report`
|
|
64
92
|
|
|
65
|
-
##
|
|
93
|
+
## 包
|
|
66
94
|
|
|
67
|
-
|
|
95
|
+
`mio-agent-runtime` 依赖发布在 `@akemi-mio` scope 下的 **9** 个包(声明于 `package.json`,均为 `0.1.0`)。它们仅在源码变更时才发布,所以普通的 CLI 发布不会重新发布这些包。
|
|
68
96
|
|
|
69
|
-
|
|
|
97
|
+
| 依赖 | 说明 |
|
|
70
98
|
|---|---|
|
|
71
|
-
| `@akemi-mio/
|
|
72
|
-
| `@akemi-mio/
|
|
73
|
-
| `@akemi-mio/
|
|
74
|
-
| `@akemi-mio/
|
|
75
|
-
| `@akemi-mio/
|
|
76
|
-
| `@akemi-mio/evolution-
|
|
77
|
-
| `@akemi-mio/evolution-
|
|
78
|
-
| `@akemi-mio/
|
|
79
|
-
| `@akemi-mio/
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
scope in `~/.claude.json` (`mcpServers`) — no interactive approval needed,
|
|
104
|
-
unlike project-scope `.mcp.json` — and injects Mio usage rules into
|
|
105
|
-
`~/.claude/CLAUDE.md` (auto-loaded user memory) plus `<workspace>/CLAUDE.md`
|
|
106
|
-
(project memory). Restart running Claude Code sessions to reload both.
|
|
107
|
-
`mio observe` passively tails `<config-dir>/projects/<munged-cwd>/*.jsonl`
|
|
108
|
-
session transcripts: sidechain (subagent) lines are skipped, each user
|
|
109
|
-
prompt closes the previous turn, `tool_result.is_error` lines are recorded
|
|
110
|
-
as error traces, and successful turn summaries are written back into the
|
|
111
|
-
workspace `CLAUDE.md` MIO_CONTEXT block so the next session retrieves them
|
|
112
|
-
passively. Set `CLAUDE_CONFIG_DIR` to override the config dir.
|
|
113
|
-
- WorkBuddy uses `~/.workbuddy/mcp.json` and requires each custom MCP server to
|
|
114
|
-
be approved in `~/.workbuddy/mcp-approvals.json`. `mio install workbuddy`
|
|
115
|
-
writes both files and injects Mio usage rules into
|
|
116
|
-
`~/.workbuddy/CODEBUDDY.md` (user-level memory rules, auto-loaded by
|
|
117
|
-
WorkBuddy into every session; the CLI hardcodes the CodeBuddy product name, so the file is CODEBUDDY.md not WORKBUDDY.md) plus `<workspace>/AGENTS.md` (project-level).
|
|
118
|
-
If WorkBuddy is already running, restart it once so it reloads the approval
|
|
119
|
-
and memory rule files.
|
|
120
|
-
|
|
121
|
-
## Passive observer (`mio observe`)
|
|
99
|
+
| `@akemi-mio/runtime-contracts` | 共享类型定义 |
|
|
100
|
+
| `@akemi-mio/runtime-foundation` | 日志、EventBus、记忆 schema |
|
|
101
|
+
| `@akemi-mio/experience-memory` | 经验记录与检索 |
|
|
102
|
+
| `@akemi-mio/evolution-learning` | 演化学习引擎 |
|
|
103
|
+
| `@akemi-mio/evolution-strategy` | 演化策略引擎 |
|
|
104
|
+
| `@akemi-mio/evolution-safety` | 安全护栏 |
|
|
105
|
+
| `@akemi-mio/evolution-scheduler` | 演化调度器 |
|
|
106
|
+
| `@akemi-mio/observer` | ObserverService —— 多源数据采集、趋势分析、深度研究、世界模型、发酵、DAG 状态机、自演化引擎(零 npm 依赖) |
|
|
107
|
+
| `@akemi-mio/insight` | InsightService —— 基于 LLM 的洞察生成、冲突/漂移/重复/停滞目标/摩擦检测器、在场服务、洞察打分(零 npm 依赖) |
|
|
108
|
+
|
|
109
|
+
以下 `@akemi-mio` 包同样位于本 monorepo 中并独立发布,但**不是**本 CLI 的依赖——其源码从不 import 它们,因此未声明在 `package.json` 里:
|
|
110
|
+
|
|
111
|
+
- `@akemi-mio/analysis` — ModuleScanner,对包源码树做静态分析(零依赖)
|
|
112
|
+
- `@akemi-mio/messaging` — ExternalMessageGateway,入站消息路由 + 通知分发(零依赖)
|
|
113
|
+
- `@akemi-mio/reasoning` — 纯函数打分规划器,用于推理指令
|
|
114
|
+
- `@akemi-mio/resource-control` — 资源预算、后台任务运行器
|
|
115
|
+
- `@akemi-mio/agent-persona` — 人格漂移控制、内容分类
|
|
116
|
+
|
|
117
|
+
它们可直接被其它 Node 项目消费。`mio-agent-runtime` 自身是 CLI + MCP server 包。
|
|
118
|
+
|
|
119
|
+
### 与宿主耦合的包(不发布)
|
|
120
|
+
|
|
121
|
+
`@akemi-mio/core` 与 `@akemi-mio/creativity` 通过 `workspace:*` 链接在本 monorepo 内部消费,因此从源码构建,**不**发布到 npm。`packages/cli/` 已不存在。不要把这两个包加进下游 `package.json`——安装会失败。
|
|
122
|
+
|
|
123
|
+
## 宿主说明
|
|
124
|
+
|
|
125
|
+
- OpenCode 通过 `~/.config/opencode/opencode.json` 做 MCP 注册,通过 `~/.config/opencode/AGENTS.md` 做全局指令。`mio install opencode` 会写入这两个文件,并向 `AGENTS.md` 注入 Mio 使用规则,使 OpenCode 自动调用 Mio 的记忆/观察/策略。若 OpenCode 已在运行,重启一次以重新加载这两个文件。`mio observe` 还会被动跟踪 OpenCode 会话数据库(`opencode db`),无需模型主动调用 Mio 工具。
|
|
126
|
+
- Hermes 使用 `hermes mcp add mio-intelligence --command node --args <server>` 来注册 Mio MCP server。Hermes 有原生记忆并读取 AGENTS.md Context Files,因此无需注入 Mio 规则也能检索。
|
|
127
|
+
- Claude Code:`mio install claude` 在用户级 `~/.claude.json`(`mcpServers`)注册 Mio MCP server——不像项目级 `.mcp.json` 需要交互式审批——并向 `~/.claude/CLAUDE.md`(自动加载的用户记忆)与 `<workspace>/CLAUDE.md`(项目记忆)注入 Mio 使用规则。重启运行中的 Claude Code 会话以重新加载两者。`mio observe` 被动跟踪 `<config-dir>/projects/<munged-cwd>/*.jsonl` 会话记录:跳过 sidechain(子 agent)行,每个用户 prompt 结束上一轮,`tool_result.is_error` 行记为错误 trace,成功轮次的摘要写回 workspace 的 `CLAUDE.md` 的 `MIO_CONTEXT` 块,供下一会话被动取用。可用 `CLAUDE_CONFIG_DIR` 覆盖配置目录。
|
|
128
|
+
- WorkBuddy 使用 `~/.workbuddy/mcp.json`,并要求每个自定义 MCP server 在 `~/.workbuddy/mcp-approvals.json` 中审批通过。`mio install workbuddy` 会写入这两个文件,并向 `~/.workbuddy/CODEBUDDY.md`(用户级记忆规则,由 WorkBuddy 自动加载进每次会话;CLI 硬编码了 CodeBuddy 产品名,所以文件名是 CODEBUDDY.md 而非 WORKBUDDY.md)以及 `<workspace>/AGENTS.md`(项目级)注入 Mio 使用规则。若 WorkBuddy 已在运行,重启一次以重新加载审批与记忆规则文件。
|
|
129
|
+
|
|
130
|
+
## 被动观察器(`mio observe`)
|
|
122
131
|
|
|
123
132
|
WorkBuddy 的默认模型不一定会主动调用 Mio MCP 工具,即使规则已注入
|
|
124
133
|
(`CODEBUDDY.md` / `AGENTS.md`)。`mio observe` 是一个不依赖模型自觉的
|
|
@@ -140,16 +149,25 @@ schema,`source=workbuddy-observer`)。
|
|
|
140
149
|
### Context 块的写入范围(`MIO_CONTEXT`)
|
|
141
150
|
|
|
142
151
|
`<workspace>/AGENTS.md`(或 `CLAUDE.md`)里的 `MIO_CONTEXT` 块最多保留
|
|
143
|
-
6 条(`CONTEXT_MAX
|
|
152
|
+
6 条(`CONTEXT_MAX`),按时间倒序。三条规则保证真实历史不被挤掉:
|
|
144
153
|
|
|
145
154
|
- **同一条内容只占一个位置**。重复写入只把它移到最前。旧版本会把同一行
|
|
146
155
|
反复插入,占满全部 6 个位置,把真实任务摘要整体挤出(存量
|
|
147
156
|
`observe-state.json` 里的重复条目会在下次写入时自动清理)。
|
|
157
|
+
- **同一项目只对应一个桶**。Context 键取自各 host 转录里的 `cwd` 字段,
|
|
158
|
+
而不同 Agent 的拼写不一致(`D:\work\code\x`、`d:\work\code\x`、
|
|
159
|
+
`D:/work/code/x`)。这些写法现在会被归一到统一形式(盘符大写 + 反斜杠),
|
|
160
|
+
等价桶在读取和写入时自动合并——否则同一个项目会被拆成多个桶,各自
|
|
161
|
+
只保留 6 条,互相看不到对方的历史。存量分裂键无需迁移脚本,
|
|
162
|
+
`loadState` 会在下次加载时合并。
|
|
148
163
|
- **`mio digest --write-back` 只写回有数据的项目**。写回的是一行项目维度
|
|
149
164
|
摘要(`digest(7d): <项目> N 任务 M% 成功`),不是全局统计;`observe-state`
|
|
150
165
|
里没有对应 digest 数据的 workspace 会被直接跳过,不会被写入。旧版本把
|
|
151
166
|
同一条全局 headline 广播给所有历史项目,导致无关仓库(如 ComfyUI)被污染。
|
|
152
167
|
|
|
168
|
+
桶合并后若超过 `CONTEXT_MAX`,按条目内嵌的时间戳(`YYYY/M/D HH:MM:SS`)
|
|
169
|
+
截断,保留最新的,而不是按存储位置丢弃。
|
|
170
|
+
|
|
153
171
|
需要强制指定目标时用 `--cwd <path>` 或 `--project <name>`;`--cwd` 优先。
|
|
154
172
|
|
|
155
173
|
OpenCode 会话不依赖模型自觉:`mio observe` 通过 `opencode db` 增量读取
|
|
@@ -170,7 +188,7 @@ Hermes 本身有原生记忆,Mio 只负责让 Hermes 经验进入跨 Agent 生
|
|
|
170
188
|
|
|
171
189
|
默认 `~/.mio-intelligence`,可通过环境变量 `MIO_HOME` 覆盖。
|
|
172
190
|
|
|
173
|
-
##
|
|
191
|
+
## 包结构
|
|
174
192
|
|
|
175
193
|
```text
|
|
176
194
|
packages/mio-cli
|
|
@@ -189,32 +207,414 @@ packages/mio-cli
|
|
|
189
207
|
│ ├── runtime-modules.js
|
|
190
208
|
│ ├── creativity-engine.js
|
|
191
209
|
│ ├── memory-store.js
|
|
210
|
+
│ ├── experience-store.js
|
|
211
|
+
│ ├── policy-store.js
|
|
192
212
|
│ ├── retention.js
|
|
193
213
|
│ ├── digest.js
|
|
194
214
|
│ └── mio-intelligence-mcp/index.js
|
|
195
215
|
└── package.json
|
|
196
216
|
```
|
|
197
217
|
|
|
198
|
-
`server/memory-store.js`
|
|
199
|
-
|
|
200
|
-
|
|
201
|
-
|
|
202
|
-
|
|
203
|
-
|
|
204
|
-
|
|
205
|
-
|
|
206
|
-
|
|
218
|
+
`server/memory-store.js` 是记忆查询/记录排序(Latin token + CJK bigram 打分、project/global 作用域分层、复用证据加权)的唯一实现。MCP 服务端(`mio.memory.query` / `mio.memory.record`)与 CLI(`mio recall` / `mio remember`)都经过它,因此各入口的排序结果完全一致。同一个模块还实现了卫生操作——`analyze` / `archive` / `merge` / `migrate`——所以 `mio.memory.analyze` 与 `mio memory analyze` 不可能各自漂移。`server/experience-store.js` 与 `server/policy-store.js` 对 `mio.experience.*` 与 `mio.policy.check` 遵循同样的模式;策略存储复用了记忆存储的分词器,因此策略风险证据与相关记忆排序在构造上就与 `mio.memory.query` 一致。`server/creativity-engine.js` 是 `mio.creativity.*` 背后的共享实现——CLI 的 `mio creativity status`/`list` 与 MCP 工具调用的是同一个 `CreativityEngine`,因此假设计数在入口间不会漂移。`server/agent-store.js` 是 `mio.agent.list` / `register` / `report` 背后的共享实现;CLI 的 `mio agents list`/`report` 与 MCP 工具读取的是同一个存储,因此被观察 agent 的遥测数据在任何地方都相同。`server/llm-client.js` 是 `chatJson` 的唯一实现,MCP 服务端(创意引擎 + insight)与 CLI(`mio creativity generate`/`ferment`)共用,因此两边调用的是同一个模型与同一份配置(`LLM_API_URL`/`LLM_KEY`/`LLM_CHAT_MODEL`)。`server/query-log.js` 是 `queries.jsonl` 的唯一读写实现——记忆存储在 `queryMemory` 时记录查询,任务存储在 auto-claim 时消费它把 `task_outcome` 归因到先前的查询;两者**不能互相引用**(会成环),所以日志自成一模块、由调用方把同一个实例交给两个 store。`server/digest.js` 把 traces/memory/reuse 聚合成可执行报告(同样以 `mio.digest.generate` 暴露),`server/retention.js` 驱动 `mio prune`(按年龄/过期裁剪并备份;没有显式的 `--memory --yes` 绝不触碰 `memory.jsonl`)。
|
|
219
|
+
|
|
220
|
+
## 记忆卫生
|
|
221
|
+
|
|
222
|
+
`mio.memory.analyze` 能诊断重复项与低质量记录,但此前唯一的处置途径是通过 MCP 服务端。`mio memory` 子命令补上了这个缺口:
|
|
223
|
+
|
|
224
|
+
```bash
|
|
225
|
+
mio memory analyze # 需要关注什么?
|
|
226
|
+
mio memory archive --ids mem_a,mem_b # 预览(不加 --yes = 不写入)
|
|
227
|
+
mio memory archive --ids mem_a,mem_b --yes # 执行
|
|
228
|
+
mio memory restore --ids mem_a # 撤销
|
|
229
|
+
mio memory merge --ids mem_a,mem_b --yes # 把重复项合并为一个幸存者
|
|
230
|
+
mio memory migrate --ids mem_a --scope global # 提升到 global 层
|
|
231
|
+
```
|
|
232
|
+
|
|
233
|
+
说明:
|
|
234
|
+
|
|
235
|
+
- **归档可逆,不是删除**。被归档的记录仍以 `archived: true` 留在 `memory.jsonl` 中,并从 `recall` 与 `analyze` 中消失。`mio prune --memory` 仍是唯一会永久删除记录的操作,且仍需要 `--yes`。
|
|
236
|
+
- **`archive` 默认先预览**。不加 `--yes` 时打印将要发生的变更并以退出码 `1` 结束;`--json` 模式同样如此,脚本无法意外归档。预览中会展示 id,拼写错误在此被捕获。
|
|
237
|
+
- **id 既可写作 `--ids a,b`,也可作裸位置参数**(`mio memory archive mem_a mem_b`)。id 中绝不含逗号。
|
|
238
|
+
- **无变更时以非零退出**。若每个 id 都未知、已归档或属于其它项目,命令会报告 `not found` / `already archived` 并以退出码 `1` 结束,而非假装成功。
|
|
239
|
+
- **重复项使用 Latin token 与 CJK bigram 的 Jaccard 相似度**,阈值 `0.75`,用并查集聚类,使 `A~B, B~C` 坍缩为一组。活跃记录超过 1500 条时跳过扫描,改为报告 `duplicatesSkipped`,避免在 O(n²) 工作上卡死。
|
|
240
|
+
|
|
241
|
+
### 彻底遗忘(`mio memory forget`)
|
|
242
|
+
|
|
243
|
+
上面所有操作都是**可逆**的:archive 只是打上 `archived: true`,merge 基于 archive,
|
|
244
|
+
migrate 只改作用域。`forget` 是**唯一不可逆**的操作——它把记录真正删除。
|
|
245
|
+
|
|
246
|
+
```bash
|
|
247
|
+
mio memory forget --ids mem_secret --project demo # 预览
|
|
248
|
+
mio memory forget --ids mem_secret --project demo --yes # 真正删除
|
|
249
|
+
```
|
|
250
|
+
|
|
251
|
+
```text
|
|
252
|
+
Forget preview: 1 id(s) (project=demo)
|
|
253
|
+
mem_secret secret token abc123
|
|
254
|
+
|
|
255
|
+
WARNING: this permanently deletes the record(s) and cannot be undone.
|
|
256
|
+
An audit entry (excerpt only) is written to memory-forget-audit.jsonl.
|
|
257
|
+
Reversible alternative: mio memory archive --ids mem_secret --yes
|
|
258
|
+
Re-run with --yes to delete permanently.
|
|
259
|
+
```
|
|
260
|
+
|
|
261
|
+
几条硬性保证(均有测试覆盖):
|
|
262
|
+
|
|
263
|
+
- **预览显示"将要消失的是什么"**,而不只是 id——这是唯一删了就没了的操作。
|
|
264
|
+
- **审计先行**:先把条目写进 `<MIO_HOME>/memory-forget-audit.jsonl` 再删除,
|
|
265
|
+
所以任何一次删除事后都能回答"删掉了什么"。
|
|
266
|
+
- **审计只存摘要,不存全文**(`excerpt` 取前 120 字符 + `contentLength` + `kind`),
|
|
267
|
+
不会在你要求删除之后又悄悄把全文留下来。
|
|
268
|
+
- **跨项目绝不误删**:id 属于其它项目时按 `not found` 处理,原记录保留。
|
|
269
|
+
- **全部未命中以退出码 `1` 结束**,避免一次 typo 被当成成功。
|
|
270
|
+
- 预览与 `--json` 里都会给出**可逆替代方案**(`mio memory archive`)。
|
|
271
|
+
|
|
272
|
+
> 除非记录必须真的消失(例如误存了凭据),否则请优先用 `archive`。
|
|
273
|
+
|
|
274
|
+
### 合并重复项
|
|
275
|
+
|
|
276
|
+
`analyze` 会报告重复组但无法消解——逐个手动归档会让幸存者丢失它吸收的那些内容。`mio memory merge` 解决了这个问题:
|
|
277
|
+
|
|
278
|
+
```bash
|
|
279
|
+
mio memory merge --ids mem_a,mem_b --yes # 最新者胜出
|
|
280
|
+
mio memory merge --ids mem_a,mem_b --keep mem_a --yes # 指定幸存者
|
|
281
|
+
```
|
|
282
|
+
|
|
283
|
+
**默认只合并字节完全一致的内容。** 这是刻意为之的安全立场,而非疏漏:在真实 860 条记录的存储上实测,22 个重复组中有 19 个字节完全一致,3 个不一致。拼接分歧内容会破坏它们——一个真实案例产生了一条同时携带 `Token 来源` 和 `凭证来源` 同一字段、还多了重复表头的记录。因此当组内成员不一致时,merge **会拒绝并打印候选**,而不是猜测:
|
|
284
|
+
|
|
285
|
+
```bash
|
|
286
|
+
mio memory merge --ids mem_a,mem_b --yes
|
|
287
|
+
# No merge applied: content differs across records; refusing to concatenate
|
|
288
|
+
# - mem_a (1167 chars, 2026-09-09T14:25:56.735Z)
|
|
289
|
+
# - mem_b (1174 chars, 2026-09-09T14:31:00.898Z)
|
|
290
|
+
```
|
|
291
|
+
|
|
292
|
+
要消解这样的组,必须指定保留哪份内容,这正是 `--keep` 的用途;`--allow-divergent` 表示承认其它成员是被丢弃而非合并:
|
|
293
|
+
|
|
294
|
+
```bash
|
|
295
|
+
mio memory merge --ids mem_a,mem_b --keep mem_b --allow-divergent --yes
|
|
296
|
+
```
|
|
297
|
+
|
|
298
|
+
合并会写入的内容:
|
|
299
|
+
|
|
300
|
+
- **幸存者**原样保留自己的正文,并获得 `supersedes: [<archived ids>]`、`mergedAt`、`mergedCount`,以及合并后的标签列表,不丢失任何检索关键词。
|
|
301
|
+
- **其它成员**以 `archiveReason: "merged-into:<survivor>"` 归档,并带上 `mergedInto` 指针。
|
|
302
|
+
- 它**可逆**:`mio memory restore --ids <archived ids>` 能把整组恢复。审计字段保留在记录上,因此合并历史在撤销后依然存在。
|
|
303
|
+
- 没有可合并内容时的重跑会以退出码 `1` 报告 `nothing left to merge`——不会为它没归档的记录打印撤销命令。
|
|
304
|
+
|
|
305
|
+
## 策略检查
|
|
306
|
+
|
|
307
|
+
`mio.policy.check` 一直能从 trace 日志回答「这个动作历史上是否有风险?」,但此前只通过 MCP 提供。`mio policy check` 把它带到了终端:
|
|
308
|
+
|
|
309
|
+
```bash
|
|
310
|
+
mio policy check "npm publish"
|
|
311
|
+
mio policy check "git reset --hard" --project akemi-mio
|
|
312
|
+
mio policy check "npm publish" --json
|
|
313
|
+
```
|
|
314
|
+
|
|
315
|
+
```text
|
|
316
|
+
Policy check: "npm publish" (project=akemi-mio)
|
|
317
|
+
risk: HIGH (0.5)
|
|
318
|
+
evidence: 2 matching trace(s), 1 failure(s)
|
|
319
|
+
outcomes: failure=1 success=1
|
|
320
|
+
|
|
321
|
+
Recent failures:
|
|
322
|
+
- E403 token lacks bypass_2fa
|
|
323
|
+
|
|
324
|
+
Related memory:
|
|
325
|
+
- mem_pub npm publish requires a granular token with bypass_2fa enabled
|
|
326
|
+
|
|
327
|
+
Historically risky: ...
|
|
328
|
+
```
|
|
329
|
+
|
|
330
|
+
说明:
|
|
331
|
+
|
|
332
|
+
- **它读取全局 `MIO_HOME`,而非每项目目录。** MCP 服务端把数据目录解析为 `MIO_DATA_DIR || cwd/.mio-intelligence`,因此从任意目录发起的 MCP 调用看到的是空存储;CLI 刻意指向累积的全局日志。用 `--project` 把 trace 集合限定到某个项目。
|
|
333
|
+
- **风险即失败占比**,`>= 0.4` 为高,`>= 0.2` 为中。`retry` 与 `aborted` 与 `failure`、`error` 一并计为失败。无匹配历史报告 `UNKNOWN`,与 `LOW`(干净记录)不同。
|
|
334
|
+
- **匹配可能被通用 token 带偏。** 匹配是对动作 token 的宽松 OR,所以像 `task` 这样的动作几乎匹配每条 trace,因为关键词 `task` 几乎出现在所有 payload 中。当动作中*每个* token 都至少出现在半数候选 trace 里时,CLI 会打印警告,而不是让等级自说自话:
|
|
335
|
+
|
|
336
|
+
```text
|
|
337
|
+
WARNING: low-signal match. Every token in this action (task) appears in
|
|
338
|
+
most traces regardless of subject, so the level above is not meaningful.
|
|
339
|
+
Try a more specific action, e.g. mio policy check "npm publish".
|
|
340
|
+
```
|
|
341
|
+
|
|
342
|
+
这把弱点暴露在了 CLI 层;MCP 的匹配行为不变,且 `diagnostics` 是新增字段,既有消费者继续可用。
|
|
343
|
+
- **小样本会标注。** 匹配 trace 少于 5 条时打印 `NOTE: only N matching trace(s); treat the level above as a weak signal.`
|
|
344
|
+
- **属于动作的 flag 会被保留。** 只有 `--project` 与 `--json` 作为选项被消费,因此 `git reset --hard` 会原样透传,而非被截断成 `git reset`。
|
|
345
|
+
|
|
346
|
+
## 创意引擎
|
|
347
|
+
|
|
348
|
+
`mio.creativity.status` 与 `mio.creativity.list` 自引擎落地起就在 MCP 面上,但此前没有终端入口。`mio creativity` 把只读一侧带到了 CLI:
|
|
349
|
+
|
|
350
|
+
```bash
|
|
351
|
+
mio creativity status
|
|
352
|
+
mio creativity list --status rejected --limit 10
|
|
353
|
+
mio creativity list --json
|
|
354
|
+
```
|
|
355
|
+
|
|
356
|
+
```text
|
|
357
|
+
Creativity engine:
|
|
358
|
+
hypotheses: 5 combos: 3 experiments: 1
|
|
359
|
+
active: 2 validated: 1 rejected: 1
|
|
360
|
+
|
|
361
|
+
Recent top ideas:
|
|
362
|
+
- Plugin architecture (novelty=80 feasibility=70 impact=90 score=240)
|
|
363
|
+
idea_1787936687555_0
|
|
364
|
+
```
|
|
365
|
+
|
|
366
|
+
说明:
|
|
367
|
+
|
|
368
|
+
- **它委托给与 MCP 服务端相同的 `CreativityEngine`**,因此终端的 `mio creativity list` 看到的是与 `mio.creativity.list` 工具完全一致的假设。存储位于 `<MIO_HOME>/creativity/creativity-hypotheses.jsonl`;CLI 指向全局 `MIO_HOME`,与 `mio policy check` 一致。
|
|
369
|
+
- **空存储是正常状态。** 引擎运行之前,`status` 报告全零计数,`list` 显示 "No hypotheses match." 两者都是有效输出,不是错误。
|
|
370
|
+
|
|
371
|
+
### 生成与发酵(`generate` / `ferment`)
|
|
372
|
+
|
|
373
|
+
这两个子命令会调用 LLM,`mio creativity` 同样支持它们——用的是**共享的 LLM 客户端**
|
|
374
|
+
(`server/llm-client.js`),与 MCP 服务端完全同一实现:
|
|
375
|
+
|
|
376
|
+
```bash
|
|
377
|
+
mio creativity generate --source "auth|token rotation" --source "cache|write-through"
|
|
378
|
+
mio creativity ferment --limit 3
|
|
379
|
+
```
|
|
380
|
+
|
|
381
|
+
- `--source "名称|内容"` **至少两个**:引擎是把概念两两配对来产生新假设的,
|
|
382
|
+
一个来源在构造上就不可能产出组合(此时**不会**调用 LLM,直接返回
|
|
383
|
+
`need at least 2 sources`)。
|
|
384
|
+
- `ferment` 会复核 `active` 假设并更新分数;`verdict=promote` 且总分 > 200 时
|
|
385
|
+
升为 `validated`,`verdict=reject` 则标记为 `rejected`。
|
|
386
|
+
|
|
387
|
+
#### LLM 配置
|
|
388
|
+
|
|
389
|
+
三个环境变量,与 MCP 服务端读取的完全相同:
|
|
390
|
+
|
|
391
|
+
| 变量 | 说明 |
|
|
392
|
+
|---|---|
|
|
393
|
+
| `LLM_API_URL` | OpenAI 兼容端点(默认 opencode zen) |
|
|
394
|
+
| `LLM_KEY` | Bearer token;留空表示无需鉴权(本地 Ollama 常见) |
|
|
395
|
+
| `LLM_CHAT_MODEL` | 模型 id,回退到 `LLM_MODEL` |
|
|
396
|
+
|
|
397
|
+
本机跑 Ollama 时可以这样指过去:
|
|
398
|
+
|
|
399
|
+
```bash
|
|
400
|
+
LLM_API_URL=http://localhost:11434/v1/chat/completions mio creativity ferment
|
|
401
|
+
```
|
|
402
|
+
|
|
403
|
+
未设置 `LLM_API_URL` / `LLM_KEY` 时,命令会**先提示**它将要调用默认端点,
|
|
404
|
+
再继续——不会静默地把请求发到你没配的地方。
|
|
405
|
+
|
|
406
|
+
## 洞察自省与观察管线
|
|
407
|
+
|
|
408
|
+
`mio.insight.*` 与 `mio.observer.*` 此前都只有 MCP 入口:agent 会话里能读到,终端里看不到。`mio insight` 与 `mio observer` 补上了这两块的终端入口。
|
|
409
|
+
|
|
410
|
+
```bash
|
|
411
|
+
# 洞察自省(需要可选包 @akemi-mio/insight)
|
|
412
|
+
mio insight status
|
|
413
|
+
mio insight list --unreported --min-score 0.7
|
|
414
|
+
mio insight mark-reported --ids ins_1,ins_2
|
|
415
|
+
|
|
416
|
+
# 观察研究管线(纯文件读取,不依赖可选包)
|
|
417
|
+
mio observer status
|
|
418
|
+
mio observer trends --limit 5
|
|
419
|
+
mio observer trends --date 2026-09-12
|
|
420
|
+
mio observer dag --days 14
|
|
421
|
+
mio observer essays --type published
|
|
422
|
+
mio observer world-model
|
|
423
|
+
mio observer research --json
|
|
424
|
+
mio observer trends --base-dir /path/to/.local/observer
|
|
425
|
+
```
|
|
426
|
+
|
|
427
|
+
说明:
|
|
428
|
+
|
|
429
|
+
- **两者都委托给与 MCP 服务端完全相同的共享实现** —— `server/insight-store.js` 与 `server/observer-store.js`。这是 `memory-store.js` / `experience-store.js` / `policy-store.js` / `creativity-engine.js` / `agent-store.js` 一路沿用的同一个模式:一份实现、两个入口,因此不可能各自漂移。
|
|
430
|
+
- **只暴露不需要 LLM、不发起网络请求的子命令。** `insight generate`、`observer collect`、`observer ferment` 仍是 MCP 专有(`mio.insight.generate` / `mio.observer.collect` / `mio.observer.ferment`),CLI 把三者当作未知子命令拒绝。前两者需要 LLM,`collect`/`ferment` 依赖的 `@akemi-mio/observer` 包未安装时更无从谈起。
|
|
431
|
+
- **`mio observer ingest` 记录任意 trace 事件**(`tool_call` / `error` / `retry` / `task_outcome`):
|
|
432
|
+
|
|
433
|
+
```bash
|
|
434
|
+
mio observer ingest --trace-id t1 --event-type tool_call --payload '{"tool":"Bash"}' --project demo
|
|
435
|
+
```
|
|
436
|
+
|
|
437
|
+
它是**追加**而非修改,所以像 `mio remember` 一样直接写入、**不做预览**;但缺 `--trace-id` / `--event-type`,或 `--payload` 不是合法 JSON 对象时,会在写入任何东西之前拒绝。
|
|
438
|
+
只想记录任务结果时用 `mio task record-outcome` 更合适——它更专用,还会一并更新该 agent 的 `taskCount` / `successCount` / `failureCount`。
|
|
439
|
+
|
|
440
|
+
### 订阅与摘要(`subscribe` / `digest`)
|
|
441
|
+
|
|
442
|
+
```bash
|
|
443
|
+
mio observer subscribe --event-types tool_call,error --project demo # 预览
|
|
444
|
+
mio observer subscribe --event-types tool_call,error --project demo --yes # 订阅
|
|
445
|
+
mio observer ingest --trace-id t1 --event-type tool_call --project demo
|
|
446
|
+
mio observer digest --project demo
|
|
447
|
+
```
|
|
448
|
+
|
|
449
|
+
```text
|
|
450
|
+
Observer digest: 1 event(s) (project=demo, agent=cli)
|
|
451
|
+
subscriptions: 1 active, 1 matched
|
|
452
|
+
- tool_call trace=t1
|
|
453
|
+
Note: this advances the cursor; the next digest returns only newer events.
|
|
454
|
+
```
|
|
455
|
+
|
|
456
|
+
- `subscribe` 是写操作,**默认只预览**(exit 1、不落盘),`--yes` 才写。相同的
|
|
457
|
+
agent+project+事件类型+主题视为**同一条订阅**,重复执行是**续期**而非新增一行。
|
|
458
|
+
- **`digest` 是基于游标的**:只返回上次投递之后的**新事件**,并推进游标。
|
|
459
|
+
所以「第二次跑返回 0 条」是**正确行为**,不是坏了——输出里也明确写了这一点,
|
|
460
|
+
免得让人误以为订阅失效了。
|
|
461
|
+
- 因此 digest **无法预览**(不跑就不知道有什么),但它会写游标这件事在输出与
|
|
462
|
+
`mio observer help` 里都写明了。
|
|
463
|
+
- 订阅、traces、游标都在 `<MIO_HOME>` 下(与研究管线的 `.local/observer` 不同),
|
|
464
|
+
所以这组能力放在 `server/subscription-store.js`,与 `observer-store.js` 分开。
|
|
465
|
+
|
|
466
|
+
- **数据位置不同,这是有意的。** 洞察存储在 `<MIO_HOME>/insights/insights.json`,与 `mio recall` / `mio policy check` 同处全局 `MIO_HOME`;观察研究管线则是按项目的,默认 `<cwd>/.local/observer`(与 MCP 服务端的默认值一致),可用 `--base-dir` 覆盖。
|
|
467
|
+
- **`@akemi-mio/insight` 是可选依赖。** 未安装时 `mio insight status` 会失败并提示 `@akemi-mio/insight not installed`,而不是报告一个「看起来没有洞察」的全零结果——全零会掩盖「引擎根本没装」这件事。
|
|
468
|
+
- **观察管线的空目录是正常状态。** 管线没跑过时,`observer status` 各阶段计数为 0 并提示 "No pipeline data yet.",其余视图显示 "No ... found.",都是有效输出而非错误。
|
|
469
|
+
|
|
470
|
+
## Agent
|
|
471
|
+
|
|
472
|
+
本仓库里有两种不同的「agent」概念,CLI 把它们分开以免混淆:
|
|
473
|
+
|
|
474
|
+
- **已安装的宿主适配器**(`mio agents`,无子命令)来自 `config.json`——哪些宿主(codex/opencode/workbuddy/hermes/claude)已通过 `mio install` 接好。这是配置状态。
|
|
475
|
+
- **被观察的 agent**(`mio agents list` / `mio agents report`)来自 `agents.jsonl`,并交叉引用 `traces.jsonl`、`memory.jsonl` 与 `experience_reuse.jsonl`。这是运行时遥测:每个 agent 跑了多少任务、成功多少、产生了多少记忆与已验证复用。
|
|
476
|
+
|
|
477
|
+
```bash
|
|
478
|
+
mio agents # 已安装的宿主适配器
|
|
479
|
+
mio agents list # 被观察的 agent(--project 限定范围)
|
|
480
|
+
mio agents report # 每 agent 的任务/记忆/复用遥测
|
|
481
|
+
mio agents report --agent codex
|
|
482
|
+
```
|
|
483
|
+
|
|
484
|
+
```text
|
|
485
|
+
Agent report (project=akemi-mio): 2 agent(s)
|
|
486
|
+
codex (mcp) idle
|
|
487
|
+
tasks: 5 total, 5 success, 0 failure (100% success)
|
|
488
|
+
memories: 88 experience reuses: 54 (verified 6)
|
|
489
|
+
last seen: 2026-09-06 00:57:03 | sessions=2
|
|
490
|
+
```
|
|
491
|
+
|
|
492
|
+
两个子命令都委托给 `server/agent-store.js`——与 `mio.agent.list` / `mio.agent.report` / `mio.agent.register` MCP 工具相同的存储,因此终端与 MCP 服务端报告一致的遥测,不可能漂移。`list` 读取 `agents.jsonl`;`report` 叠加 trace/memory/reuse 的交叉引用。
|
|
493
|
+
|
|
494
|
+
### 注册(`mio agents register`)
|
|
495
|
+
|
|
496
|
+
`register` 是这一组里唯一的**写操作**,因此沿用与 `mio memory archive` 相同的约定:
|
|
497
|
+
**默认只预览,加 `--yes` 才落盘**,`--json` 模式同样受限。
|
|
498
|
+
|
|
499
|
+
```bash
|
|
500
|
+
mio agents register --agent-id my-agent --project demo --capabilities code,test
|
|
501
|
+
mio agents register --agent-id my-agent --project demo --yes # 真正写入
|
|
502
|
+
```
|
|
503
|
+
|
|
504
|
+
```text
|
|
505
|
+
Register preview: my-agent (project=demo, host=mcp)
|
|
506
|
+
will create a new agent record
|
|
507
|
+
capabilities: code, test
|
|
508
|
+
Re-run with --yes to apply.
|
|
509
|
+
```
|
|
510
|
+
|
|
511
|
+
- **预览时不会创建 `agents.jsonl`**——这点有测试钉住(预览跑完文件不存在)。
|
|
512
|
+
- 已存在时预览会显示 `will update existing agent (sessionCount 4 -> 5)`,
|
|
513
|
+
而不是含糊地说"将注册"。
|
|
514
|
+
- `--yes` 首次创建(`sessionCount: 1`),再次执行则更新
|
|
515
|
+
`lastSeenAt` + `sessionCount`,**不会产生重复行**。
|
|
516
|
+
- 更新时若省略 `--capabilities`,原有能力**保留**(只有显式传入非空列表才覆盖)。
|
|
517
|
+
|
|
518
|
+
### 与 `mio host capabilities` 的区别
|
|
519
|
+
|
|
520
|
+
第三个与 host 相关的命令是 `mio host capabilities`,它回答的是**另两个问题**:
|
|
521
|
+
每个宿主支持什么能力(静态表),以及**此刻是否真的装上了**(实时探测各 adapter)。
|
|
522
|
+
|
|
523
|
+
```text
|
|
524
|
+
Host capabilities: 5 host(s)
|
|
525
|
+
codex not installed
|
|
526
|
+
mcp-tools, memory, observer-ingest, policy-check, experience-reuse, runtime-status
|
|
527
|
+
opencode installed
|
|
528
|
+
mcp-tools, memory, observer-ingest, policy-check, experience-reuse, runtime-status
|
|
529
|
+
```
|
|
530
|
+
|
|
531
|
+
它与 `mio agents` **不是一回事**,两者不一致时本身就是有用的诊断信号:
|
|
532
|
+
|
|
533
|
+
| 命令 | 数据来源 | 含义 |
|
|
534
|
+
|---|---|---|
|
|
535
|
+
| `mio agents` | `config.json` | 记录"曾经安装过"(含安装时间) |
|
|
536
|
+
| `mio host capabilities` | 实时探测 adapter | 本机**现在**是否真的装上了 |
|
|
537
|
+
|
|
538
|
+
例如配置文件还在、但宿主目录已被删掉时,`mio agents` 仍会列出它,而
|
|
539
|
+
`host capabilities` 显示 `not installed`。
|
|
540
|
+
|
|
541
|
+
## 任务路由(`mio task route`)
|
|
542
|
+
|
|
543
|
+
回答的是"这类任务历史上谁做成过、按哪条已验证经验走":把**已验证的复用经验**
|
|
544
|
+
(`confirmed` + `reuse` + `behaviorChanged` + `outcomeImproved` 四项全真)与任务描述
|
|
545
|
+
做相关性匹配,再叠加 digest 快照里的 agent 健康信号。
|
|
546
|
+
|
|
547
|
+
```bash
|
|
548
|
+
mio task route "publish npm package"
|
|
549
|
+
mio task route "mio.experience.confirm 复用证据" --project akemi-mio --limit 3
|
|
550
|
+
mio task route "deploy service" --json
|
|
551
|
+
```
|
|
552
|
+
|
|
553
|
+
```text
|
|
554
|
+
Task route: "mio.experience.confirm 复用证据" (project=akemi-mio, scope=project)
|
|
555
|
+
verified routes: 5
|
|
556
|
+
|
|
557
|
+
Routes (apply the top match first):
|
|
558
|
+
1. [score 23.5] mem_1786932717070_22577ed0f57a — reused 2x (confirmed)
|
|
559
|
+
新增 mio.experience.confirm(worktree ...):把 source=auto_claim 的复用证据升级为已确认...
|
|
560
|
+
codex -> opencode
|
|
561
|
+
```
|
|
562
|
+
|
|
563
|
+
### 与 MCP 唯一的行为差异:不写查询日志
|
|
564
|
+
|
|
565
|
+
`mio.task.route` 会把这次查询写进 `queries.jsonl`——这是 Phase 0 **自动认领**
|
|
566
|
+
(auto-claim)机制的输入:之后的 `task_outcome` 才能把"路由命中→任务成功"
|
|
567
|
+
关联成复用证据。这个写入是**承重的**,不能去掉。
|
|
568
|
+
|
|
569
|
+
但终端里的 `mio task route` 是一次**查看**,每跑一次就往查询日志塞一条是不对的。
|
|
570
|
+
所以 store 提供了 `persistQuery` 开关:
|
|
571
|
+
|
|
572
|
+
| 调用方 | `persistQuery` | 是否写 `queries.jsonl` |
|
|
573
|
+
|---|---|---|
|
|
574
|
+
| MCP `mio.task.route` | 默认 `true` | ✅ 写(保持原行为) |
|
|
575
|
+
| CLI `mio task route` | `false` | ❌ 不写 |
|
|
576
|
+
|
|
577
|
+
测试里两条都钉住了:CLI 跑完 `queries.jsonl` **不存在**;同一 store 传
|
|
578
|
+
`persistQuery: true` 则**确实写入**——证明差异来自开关,而不是代码路径坏了。
|
|
579
|
+
|
|
580
|
+
### 记录结果(`mio task record-outcome`)
|
|
581
|
+
|
|
582
|
+
把任务结果写回证据库,与上面的路由形成**闭环**:
|
|
583
|
+
路由 → 执行 → 记录结果 → 变成新的复用证据。
|
|
584
|
+
|
|
585
|
+
```bash
|
|
586
|
+
mio task record-outcome --outcome success --task "deploy service" --summary "all green"
|
|
587
|
+
mio task record-outcome --outcome failure --task "deploy service" --yes # 真正写入
|
|
588
|
+
```
|
|
589
|
+
|
|
590
|
+
它做三件事:写一条 `task_outcome` trace → 触发 auto-claim(把此前匹配的查询
|
|
591
|
+
关联成复用证据)→ 更新该 agent 的 `taskCount` / `successCount` / `failureCount`。
|
|
592
|
+
|
|
593
|
+
```text
|
|
594
|
+
Record outcome preview: success (project=demo, agent=cli)
|
|
595
|
+
task: deploy it
|
|
596
|
+
agent not registered: trace only, agent registry untouched
|
|
597
|
+
register it with: mio agents register --agent-id cli --yes
|
|
598
|
+
Re-run with --yes to apply.
|
|
599
|
+
```
|
|
600
|
+
|
|
601
|
+
同样是**写操作**,因此同样默认只预览:
|
|
602
|
+
|
|
603
|
+
- 预览**不会创建 `traces.jsonl`**(有测试钉住)。
|
|
604
|
+
- `--outcome` 非法时**在写入任何东西之前**就拒绝——不会出现"写了一半"。
|
|
605
|
+
- 预览会告诉你 agent **是否已注册**:未注册时明确说"只写 trace、不更新注册表"
|
|
606
|
+
并给出注册命令,而不是默默少做一件事。
|
|
607
|
+
- 已注册时预览显示 `will update agent (taskCount 4 -> 5, successCount 3 -> 4)`。
|
|
207
608
|
|
|
208
|
-
##
|
|
609
|
+
## 发布验证
|
|
209
610
|
|
|
210
|
-
|
|
611
|
+
发布运行时包之前,先运行:
|
|
211
612
|
|
|
212
613
|
```bash
|
|
213
614
|
npm run verify:pack-install --workspace mio-agent-runtime
|
|
214
615
|
```
|
|
215
616
|
|
|
216
|
-
|
|
217
|
-
directories through environment variables:
|
|
617
|
+
对于 CI 或可通过 `npm run` 复现的发布证据,用环境变量设定确定性目录:
|
|
218
618
|
|
|
219
619
|
```bash
|
|
220
620
|
MIO_PACK_ARTIFACT_DIR=./dist/mio-pack-artifacts \
|
|
@@ -223,7 +623,7 @@ MIO_PACK_REPORT_PATH=./dist/mio-pack-report.json \
|
|
|
223
623
|
npm run verify:pack-install --workspace mio-agent-runtime
|
|
224
624
|
```
|
|
225
625
|
|
|
226
|
-
PowerShell
|
|
626
|
+
PowerShell:
|
|
227
627
|
|
|
228
628
|
```powershell
|
|
229
629
|
$env:MIO_PACK_ARTIFACT_DIR = './dist/mio-pack-artifacts'
|
|
@@ -232,7 +632,7 @@ $env:MIO_PACK_REPORT_PATH = './dist/mio-pack-report.json'
|
|
|
232
632
|
npm run verify:pack-install --workspace mio-agent-runtime
|
|
233
633
|
```
|
|
234
634
|
|
|
235
|
-
|
|
635
|
+
直接调用脚本时也支持命令行 flag:
|
|
236
636
|
|
|
237
637
|
```bash
|
|
238
638
|
node packages/mio-cli/scripts/verify-packed-runtime.js \
|