关于 myc
myc 是面向编码 Agent 的本地任务与记忆层,包含任务队列、决策日志、混合搜索和代码索引。它使用 SQLite 保存项目状态,并可为支持的 Agent 配置 MCP 服务和钩子。
主要功能
- 01任务队列与决策日志
- 02项目记忆混合搜索
- 03内置代码索引
- 04重型命令共享队列
- 05通过 myc wire 配置 Agent
适用场景
- 01在不同 Agent 会话间保留任务
- 02检索项目事实和过往决策
- 03建立代码索引以探索项目
- 04协调多个仓库的构建和测试运行
MCP 相关
myc wire 可为 Claude Code、Codex、opencode、Kimi、mcode 和 mimo 等支持的 Agent 配置 MCP 服务。该服务向 Agent 提供工作区功能;工作区之外不提供工具或说明。
配置
本地服务的配置在各客户端中通用,复制后粘贴到客户端的 MCP 配置文件即可。
工具
本地服务需要在你的电脑上运行后才能读取工具,维护者暂未提供工具列表。
详细介绍
myc
面向编码 Agent 的本地高速任务与记忆层:包含任务队列、记录事实和决策的操作日志、对项目记忆的混合(词法 + 向量)搜索,以及内置代码索引;自身不会发起网络请求,也不强制要求提供 LLM 密钥。只有在你主动要求时才会访问网络:myc models fetch、myc code fetch、myc version --check(或设置 MYC_UPDATE_CHECK=1,此时会在 init 和 wire 中最多每天进行一次后台版本检查)。
Agent 会遗忘。myc 不会:决策会在上下文压缩后保留下来,工作会在进程终止后保留下来,而且二者都能通过普通 git 在不同机器间迁移。
设计文档位于 docs/design/(从 00-brief.md 开始);下文引用的测量结果都可以通过 bench/ 和 scripts/ 重现。
网站:https://aistastudio.github.io/myc/ — 以图表展示每项功能及其首次发布版本和对应的演示命令、路线图和测量结果,提供英文和俄文版本;每项数据旁都列出了可重现该数据的命令。这里是数据的唯一来源:bun run site/build.ts 会将网站上的每项数据与本仓库中的测量产物进行核对,将本 README 和俄文 README 中的数据与网站的 site/measurements.json 进行核对,还会将网站和两份 README 中的每条 myc 命令及标志与此版本的 --help 进行核对;任何不匹配都会导致构建失败。
原生二进制文件 — 以及作为备用方案的 Bun
myc 内部引擎仍然是 Bun(bun:sqlite,Node 端没有原生绑定)——但从 0.6.0 开始,运行它不再需要安装 Bun:npm install -g @aistastudio/myc 会为你的平台安装原生二进制文件(Windows x64、macOS arm64/x64、Linux x64/arm64),启动器只需要 Node ≥ 18。在 Windows 上,二进制文件仍处于实验阶段,尚未在实际设备上确认;WSL 仍是该平台上完全受支持的路径。
Bun 仍有何用途。 此外,该软件包还包含一个将整个 myc 打包在一起的 JS bundle:如果平台二进制文件未能安装,启动器就会改为在 Bun 下运行该 bundle。两种运行路径都包含重要的防护措施:原生二进制文件在构建时禁用了自动加载(--no-compile-autoload-dotenv/--no-compile-autoload-bunfig),bundle 则会在 argv 中加入 --no-env-file/--config——myc 绝不会加载启动项目的 .env 或 bunfig.toml(在 cherry 事件中,myc run 曾将工作树 .env 中的 20 个 EXPO_PUBLIC_* 变量传入测试)。
SQLite ≥ 3.50.4。 最低版本要求有两个原因。低于 3.44.0 时,启用 trusted_schema = OFF 后,FTS5 无法通过触发器写入,因此每次写入都会失败。此外,实测发现,在 3.43.2 和 3.46.0 上,多个 myc 进程会将同一个后台任务运行两到三次,失败的任务还会报告“database disk image is malformed”;原因尚不明确,因此 myc 会拒绝使用任何低于受支持环境所提供版本的 SQLite 库。受支持的环境不会因此损失任何功能:在 Linux 上,Bun 会链接自带的 SQLite(Bun 1.3.0 中为 3.50.4,这是 engines.bun 中的最低版本;Bun 1.3.14 中为 3.53.0);在 macOS 上,Bun 会使用系统 SQLite——macOS 14 上为 3.43.2——因此软件包会自带 SQLite:vendor/sqlite/libmyc-sqlite3.dylib,这是使用官方 amalgamation 为 arm64 和 x86_64 构建的 SQLite 3.53.4(scripts/build-sqlite.ts),优先于其他所有来源选择,除非显式设置了 MYC_SQLITE=/path/to/libsqlite3.dylib。如果正在使用的 SQLite 仍低于 3.50.4——例如安装损坏、Bun 不受支持,或 MYC_SQLITE 指向旧版库——包括 myc init 在内的每条命令都会拒绝运行,并通过 precond.sqlite_unsupported 说明应采取的措施,而不是创建一个无法写入的工作区。从 3.50.4 到 3.51.2,myc 可以运行,但会发出警告(WARN degraded.sqlite_old):此版本范围尚未证明对队列安全;在 Linux 上,可通过 bun upgrade 解决。myc doctor 会指出正在使用的 SQLite 版本及其来源。
安装 Bun:https://bun.sh
安装
安装只需一条命令:
bun install -g @aistastudio/myc # 5.11 MB compressed, 15.83 MB unpacked, 16 files; no models pulled
myc --version # myc 0.6.7 (schema 1)
Windows。 npm install -g @aistastudio/myc 会安装原生 x64
二进制文件(启动器需要 Node ≥ 18)——在实机上确认之前仍属实验性。WSL 仍是完全受支持的方式:在 WSL 中,一切
都与 Linux 上一样正常运行。
安装时不会下载嵌入模型。语义搜索需要选择启用并明确执行:myc models fetch(129 MB,约 7 s)。在此之前,搜索使用
词法方式,并会在每个回答中说明这一点(WARN degraded.embeddings)。代码索引所需的语法文件也以同样的方式获取一次:myc code fetch。
若要运行最新代码,而非已发布的版本,请从源代码构建:
git clone https://github.com/aistastudio/myc && cd myc
bun install
bun run build # produces a single binary: dist/myc
./dist/myc --version
将二进制文件放在 myc wire 能找到的位置——MYC_BIN、node_modules/.bin、
~/.myc/bin/myc 或 PATH。如果找不到,wire 会明确告知,而不会写入一个无法静默启动的配置。
快速开始
两条命令即可设置好项目;其余命令构成 Agent 日常使用的循环。(从源代码构建时,使用 ./dist/myc,而不是 myc。)
myc init # .myc/ + SQLite + migrations in this repo
myc wire # hooks + MCP for Claude Code, Codex, opencode, Kimi, mcode and mimo
myc ready --claim # take the next task
myc show <id> # all that is known about it
myc close <id>
myc remember "why X, not Y" # record a fact or decision
myc recall "how retrieval works"
myc prime # session context packet (agents call it)
myc code fetch # grammars for this repo's languages, once
myc code index # symbols, callers, code search
myc doctor # schema, counters, hooks — says "don't know" where it doesn't
完整命令列表:myc --help;各命令的详细说明:myc <command> --help。
接入 Agent
myc wire 只会完整写入自己的文件,并逐节点合并 JSON 配置,同时在旁边创建 .myc.bak;CLAUDE.md 永远不会被触碰。运行两次不会有任何变化。普通 wire 之后的所有操作均为可选:
myc wire --dry-run # show every change, write nothing
myc wire --agents claude,codex # only some of the agents
myc wire --status-line # + myc's status line under Claude Code's prompt
myc wire --queue-hook # + heavy commands take turns (below)
myc wire --agents-md # + the myc block in AGENTS.md
myc wire --scope user # the same for agents in git worktrees (Claude Code's user layer)
myc wire --scope user --agents claude,opencode # + opencode's global config
myc unwire # remove what wire put in
在 git worktree 中运行 Agent。 myc wire 会写入项目中的:
.claude/settings.json、.mcp.json。orca 在嵌套仓库的 git
worktree(~/orca/workspaces/<repo>/<branch>)中启动的 Agent 位于团队的目录树中,而这些文件并不在该目录树中,即使 myc 本身能从那里找到主副本的工作区。myc wire --scope user 会将相同内容写入 Claude Code 的用户层,供每个会话读取:
~/.claude/helpers/myc-hooks.mjs、SessionStart/PreCompact/PostToolUse hooks 以及 ~/.claude/settings.json 中的 Bash(myc <command>:*) 规则(逐节点合并;orca、herdr 和其他工具的 hooks 会逐字节保留)、~/.claude/skills/myc 中的技能,以及通过 claude mcp add --scope user 添加的 MCP 服务。首先,helper 会在不启动 myc 的情况下检查此处是否有工作区(通过主副本解析 git worktree),如果没有工作区,或项目自行配置了 myc,就保持静默:在未配置 myc 的项目中,hook 只会产生一次节点启动开销,prime 也不会重复到达。在工作区之外,MCP 服务不提供任何工具,也不提供任何说明。此处不允许使用 --hook-mode replace。日志文件为 ~/.myc/wire-user.json;myc unwire --scope user 会逐节点还原设置并移除 MCP 服务。
在这样的 worktree 中,opencode 也面临相同情况;--agents opencode
(或 claude,opencode;不指定 --agents 时,用户层仅配置 Claude Code)会配置其全局设置,即 $XDG_CONFIG_HOME/opencode 或 ~/.config/opencode:
myc 服务会作为一个节点写入 opencode 自行视为其配置文件的 opencode.json[c] 中的 mcp;该文件为 JSONC,其他条目、注释和尾随逗号都会逐字节保留;plugin/myc.ts 则会写入同一目录。opencode 会在打开它时所在的目录启动该服务,因此 myc mcp 会自行从 worktree 中找到工作区。该插件会像 helper 一样执行相同的两项检查,每个项目只检查一次且不会启动 myc:此处没有工作区,或项目自行配置了 opencode(opencode.json 中包含 mcp.myc,或存在 .opencode/plugin/myc.ts——opencode 会加载两个层级的插件,且项目的 mcp.myc 会覆盖此配置),则完全不会注册 hooks。myc unwire --scope user 会准确移除该节点和插件。
使用 --status-line 时,用户层还会添加 myc 的状态行 myc statusline --scope user:在 myc 工作区中(包括其 git worktree),它会输出完整状态行;在工作区之外则不会输出任何自身内容。原有状态行(orca 的状态行,它不输出内容而是将输入发送给 orca)会保存在日志中,而不是写入我们的命令;每次重绘时都会收到相同的标准输入,且不会等待它:orca 会将命令中包含其
agent-hooks/claude-statusline.sh 的状态行视为自己的状态行,并在卸载时移除(但会保留其他工具的状态行),因此我们的状态行绝不会包含 claude-statusline 一词。项目若有自己的 myc 状态行,则会保留该状态行,并由它将输入传递给同一条已记录的状态行。如果其他工具在 wire 之后替换了用户状态行,myc doctor --hooks 会提示;myc wire --scope user --status-line 会恢复我们的状态行,并将新的状态行设为原有状态行;myc unwire --scope user 会逐字节还原原有状态行。myc doctor --hooks 会根据日志检查整个用户层:~/.claude/settings.json 中 myc 的 hook 条目和规则、helper 是否与此版本写入的内容完全一致(过期的 helper 会标明写入它的版本)、状态行、MCP 服务;如果配置了 opencode,还会检查其插件和 mcp.myc。
重型命令依次运行
同一台机器上的多个 Agent——无论在同一个代码树中还是相邻项目里——都会运行耗费资源的任务:完整测试套件、构建、基准测试。它们同时运行时会互相影响:完整运行耗时会翻倍,延迟预算也会因为邻近任务而超标,而不是因为代码本身。myc run 会将此类命令放入机器用户所有仓库共用的队列(~/.myc/queue.db),等待空闲槽位(先到先服务),然后运行命令,并保持终端和退出代码不变:
myc run -- bun test # waits its turn (--max-wait 5m by default), then runs
myc run --max-wait 15m -- make # a longer wait for a longer tool timeout
myc queue # who is running, who is waiting, for how long
$ myc queue
heavy · slots 1 · 1 running · 1 waiting · ~/.myc/queue.db
running #1 4s bun test ~/src/api session 6468c59d · orca term_efe4850f · pid 44815 · command pid 44827
waiting #2 3s bun run build ~/src/web session 6468c59d · orca term_efe4850f · pid 44850 (#1 in line)
等待中的命令会在 stderr 中说明它在等待谁;超过 --max-wait 后,它会放弃,返回退出代码 9,并列出排在前面的命令:
myc run: waiting for a 'heavy' slot (1/1 busy, 1 waiting ahead), waited 0.0s of max 3s — held by 'bun test' in ~/src/api, session 6468c59d, orca term_efe4850f, pid 44815, running 13s
持有槽位的进程即使异常终止——包括收到 SIGKILL——也会释放槽位;在另一个 myc run 中嵌套运行的 myc run 会立即执行,占用父命令的槽位。默认每个通道有一个槽位;设置 MYC_HEAVY_SLOTS=2 可使用两个槽位。myc 不会加载项目的 .env 或 bunfig.toml:命令会原样继承调用者的环境。
Agent 不必记住这件事。 myc wire --queue-hook 会安装一个 Claude
Code PreToolUse 钩子,在重型 Bash 命令运行前将其改写为
myc run -- <the same command>。重型命令包括完整测试运行或构建:不带路径的 bun test、bun run build / typecheck、npm / pnpm /
yarn 的 test 和 build、cargo test / build、go test ./...、不带路径的 pytest、make。指定目标的 bun test <path>、已由 myc run 运行的命令、后台命令和嵌套命令都会原样通过。
MYC_QUEUE_HEAVY 可替换该列表(+… 可添加条目,off 可关闭钩子)。
此功能需主动启用:不带该标志运行 wire 不会写入此类钩子,unwire 则会将其移除。它开销很小,因为每次 Bash 调用都会运行此钩子:非重型命令由主机自身的 shell 放行,不会启动 bun 或 node——在 2026-09-11 的测试中,中位数为 3.4 ms,p99 为 4.3 ms,低于 prime 钩子的 30 ms p99 预算(bun test packages/cli/src/hooks/queue-hook.multiprocess.test.ts)。
myc run 不是绕过权限限制的方式。 它会运行收到的任何命令,因此,只有在你自己的规则允许原始命令通过时,排队的命令才会无需确认直接运行——Bash(bun test:*) 也会让排队运行的 bun test 无需确认。否则 Claude Code 会询问,并显示完整命令;针对原始命令的拒绝或询问规则仍然有效。Agent 自行输入的 myc run -- <cmd> 也一样。出于同样的原因,wire 不会写入范围过广的 Bash(myc:*):它会逐一允许 myc 的子命令,而 run、statusline --then、wire 和 unwire 都需要确认。
代码智能
内置代码智能,使用的引擎与其他替代方案相同:
tree-sitter,按需获取语法,而非随软件一同打包。符号、
调用方和代码搜索支持 TypeScript、TSX、JavaScript(js、jsx、mjs、
cjs)、Python、C# 和 Java — myc 为这些语言定义了规则。语法
包包含 36 种;添加一种语言时,需要同时添加一条规则和一个目录条目,
因此不会提供无法生成任何符号的语法。其他所有文件仍可使用
code grep、锚点和陈旧状态检测。
myc code fetch 会下载此代码库文件所需的语法,并通过 sha256
校验 — 这是唯一会访问网络的步骤;索引编制绝不会访问网络,
缺少语法的语言会被跳过并列出名称。myc code index
会增量构建索引:对未更改的目录重复运行时,不会读取任何内容,
之后索引会在后台刷新。以下命令可读取索引,CLI 和 MCP 均可使用:
myc code symbol <name> where it is defined, and what knowledge is anchored there
myc callers <name> who calls it; --direction out, --depth all
myc code search "…" by meaning, when you do not know the name
myc code grep "<lit>" exhaustive, every occurrence; --in <path> narrows it
myc code map orientation: directory clusters, their hubs, who depends on them
myc skeleton <file> the file's API, and how many times cheaper that was than reading it
文件列表由 git 自身提供(git ls-files,因此 .gitignore 会生效;没有 git 的目录则会被遍历,命令也会说明这一点)。无论文件列表如何,
带有秘密名称的文件都绝不会被编入索引,无论 .gitignore 如何设置:.env 和
.env.*(.env.example 等模板会被编入索引)、*.pem、*.key、
密钥库、SSH 私钥、.npmrc、.netrc 和其他凭据文件 —
code index 会统计这些文件,但不列出名称;code grep 则拒绝读取这些文件。
嵌套仓库和 git 工作树。 工作区可以是一个生态系统:根目录是一个 git 仓库,
其中包含独立仓库(不是子模块)。整个工作区只有一个代码索引,由根目录构建 —
每个文件对应一行,路径类似 messaging-server/server/src/x.ts。在嵌套
仓库中运行任何代码命令,都会从根索引中读取该仓库对应的部分,路径相对于当前所在的仓库;
从根目录运行时,结果不会改变。在嵌套仓库中运行
myc code index,会刷新根索引中对应的部分,而不是为相同文件构建第二份索引。索引也会自行保持最新:在任何 myc 命令运行后,如果上次索引运行时间超过 15 分钟(MYC_CODE_INDEX_PERIOD_MS),系统就会为每个工作区排入一个后台 code index,并以分离方式低优先级运行,绝不延迟当前命令;状态行和代码命令会说明索引正在刷新、已排队还是已过期。git 工作树 — 即使位于工作区目录之外 — 也会使用主检出目录的索引:每个分支不会单独建立索引。如果工作树位于不同提交,或对已跟踪文件存在未提交更改,每个结果都会附带
WARN code_index.worktree_divergent 并列出两个分支,因为行号和范围可能与文件不匹配。code grep 会读取工作树中的文件(行号来自你的文件,所属符号来自索引);如果你的副本与索引所依据的内容不同,skeleton 会显示主副本的声明,并说明这一点。如果仓库没有被任何索引覆盖,提示会给出工作区根目录的命令(myc -C <root> code index),而不是会构建重复索引的命令。从根目录和仓库内部设置的锚点会存储在不同的键下;code symbol 会同时读取两者。
锚点将知识与代码范围关联起来,并在代码移动时跟随;这一部分与语言无关,已在 Python 和 TypeScript 上验证。
当锚点指向的位置不再有对应代码时,知识不会被删除 — 只是排名降低,并说明原因。recall 会为相应行标记
[code moved ×0.64]、[code unverified ×0.5] 或 [code gone ×0.2]:乘数表示其分数被降低的幅度(漂移 × 相似度、陈旧 × 0.5、丢失 × 0.2)。所有锚点都已丢失的知识不会出现在 prime 中,页脚会统计数量:N with code gone hidden。
从 beads 迁移
cd <beads-project>
myc init
myc import-beads --dry-run # count what would come over, change nothing
myc import-beads # collects the snapshot itself: bd export --include-memories
之后再次运行时会进行同步,而不是再创建一份副本:beads 中更改的字段
(状态、优先级、标签、关闭原因、父项、阻塞项)会作为常规图变更应用,而本地
myc 编辑绝不会被悄悄覆盖——单边本地变更会保留并注明,双边变更会标记为冲突并保持
原样。快照文件可在不同机器间原样迁移:
bd export --include-memories > snapshot.json,然后运行
myc import-beads snapshot.json。
这是实实在在的功能,不是演示。 一个正在使用的项目导入空工作区仅用时
889 ms:796 个任务、972 个依赖项、265 条笔记、41 条记忆——未知
问题类型会原样保留并注明,超出范围的优先级会被限制在有效范围内并注明,因此不会因一条异常记录而中止导入。这些数字
来自首个版本(0.1.1,2026-09-07);当时该运行会悄悄丢弃导出内容中的注释,却报告所有笔记都已导入。次日,这个问题在一个真实项目中被发现并于 0.2.0 修复(git show aac5d1f)。现在导入内容包括:
- 注释会连同作者一起导入节点的讨论串;未知顶层 字段会注明,而不是丢弃(0.2.0);
- 验收标准和设计会导入任务正文,并置于受管理标记之间;同时保留源数据中的日期、作者和负责人(0.3.3);
- 对于 myc 未命名的状态,例如
deferred,会映射为blocked,并保留 原词——绝不会映射为open(0.3.3); - 共享工作区中的子仓库各自拥有独立的仓库可达范围; 空源会拒绝导入并给出提示,而不是悄悄导入零条数据(0.3.3)。
在同一张图上,现在两个就绪队列都会返回相同的 152 个任务。它们过去并不相同:myc 曾提供 195 个任务,而 beads 只有 144 个,因为 beads 会沿父级链继承阻塞项,而 myc 只检查任务自身。这 51 个任务位于一个仍被阻塞的 Epic 中,beads 隐藏它们是正确的;
memory-atcm254ry6c7 已关闭,anc_blockers 由触发器物化,现在队列会显示
281 blocked (51 through an ancestor),而不是悄悄把这些任务提供出来。
有何不同
速度是约束,不是优化目标。 每条热路径都有预算,预算测试会提出三类要求:结构性要求(查询计划、预筛选)、相对要求(将健康路径与刻意降级的对照路径交替测量,以抵消硬件差异)以及绝对要求。每次推送时,CI 都会检查前两类。绝对预算和 15% p95 回归阈值是在 darwin-arm64-14 上校准的,并且只在该平台生效;CI 和夜间运行使用 GitHub 的 4 核运行器,它们并非同一台机器,因此标记为未校准(MYC_BENCH_ABSOLUTE=0),在这些运行器上只打印并记录绝对数值,不予强制执行。以下数据是在 2026-09-11 使用 darwin-arm64-14 和 myc 0.3.6 对 100 000 个节点进行测量所得,此后未重新测量(bun run scripts/bench-latency.ts):
| 操作 | p99 | 预算 |
|---|---|---|
prime(会话上下文) | 0.608 ms | 30 ms |
| 读取 | 0.010 ms | 3 ms |
| 搜索 | 8.215 ms | 25 ms |
| 写入 | 0.327 ms | 5 ms |
| 冷启动 | 21.337 ms | 60 ms |
排序效果以测量为准,而非口头宣称。 两组带标签的语料均标注了相关性等级,每组都包含一个在功能生效时表现会变差的对照组——因此无法通过调整语料来人为制造提升(两组均于 2026-09-10 重新测量):
- 加权(优先级、新鲜度、层级):MRR@10 0.520 → 0.867(
bench/boost-eval.ts) - 图扩展至 2 跳:MRR@10 0.193 → 0.422(
bench/graph-eval.ts), 且一跳不可达的查询组从 0.000 提升至 0.333
缓存绝不会悄悄过期。 结果、嵌入和水合缓存会根据直接从数据库读取的 MAX(oplog.seq) 失效,因此其他进程写入时也会使它们失效。缓存命中比未命中开销低两个数量级——在 2026-09-07 的运行中快 252 倍,嵌入缓存约快 27 000 倍;该比值按墙上时钟时间计算,会随机器而变化。排序效果则不会变化:MRR 保持三位小数一致,排名差异为零。
记忆在上下文压缩后仍会保留。 myc wire 会安装一个压缩前钩子,因此在 Agent 的上下文被压缩的前一刻,会话片段会写入磁盘——保留原始内容,标记为 L0 和 acl private,并屏蔽机密信息——同时还会将一个救援数据包打印回能够保留的上下文中。蒸馏任务会排队处理,绝不会在写入路径上执行。片段会先写入磁盘,然后才会尝试其他操作,因此超出钩子的超时时间会导致摘要丢失,而不是记录丢失:
$ myc absorb-session --reason manual --transcript … --agent claude
# myc: context is being compacted — here is what must not be lost
episode sess-5jh8je4g050m saved (265 B)
NEXT myc show sess-5jh8je4g050m · myc ready --claim
从压缩内容中提取的决策只是候选项,不是事实。 同一个钩子会从转录中提取“我们决定/因为”这类句子,并将它们存为候选项(state pending_review);在有人确认之前,召回、搜索、prime 和 MCP 都不会返回这些内容。prime 会在页脚中列出它们——N pending review hidden — myc review——而 myc review 会列出这些候选项,并将本会话的候选项排在最前,供人员或 Agent 处理。确认后,候选项会成为知识,其处理方式与新建笔记相同(嵌入和吸收分类会排队处理);拒绝后,候选项会被撤回,拒绝原因会保留在节点中。Agent 也可以通过 MCP 执行相同操作:使用带有 review 的 myc_ready 列出候选项,再使用带有 confirm 或 reject 的 myc_update 进行处理;Web 知识库会在候选项所在行提供这两个按钮。
$ myc review
PENDING REVIEW 2 · 1 in this session's prime · 1 from other sessions · session 3f9c21aa
$ myc review confirm memory-6k2x…
$ myc review reject memory-9x1q… --reason "restates the task, not a decision"
已撤回的笔记(包括被拒绝的候选项)会从所有检索路径中排除,不只是被替换的版本:已过时、已撤回和已取消的笔记会在召回、prime 和状态行中共用同一份排除列表。
状态行展示 Agent 无法看到的信息。 myc wire --status-line 会在 Claude Code 的提示词下方显示一行信息——上下文的占用程度、任务队列、代码索引、项目记忆,以及本会话对 myc 的调用中实际返回内容的次数:
myc │ ctx 42% │ 61 ready · 34 blocked │ 612 files · 4268 symbols · 1h ago │ 101 notes │ 600/653 useful calls
“有用”与否根据主机自身的转录统计,而不是靠猜测:错误、拒绝或空答案都算一次调用,但不算有用调用。此功能需主动启用——不带该标志的 wire 绝不会触碰 statusLine——并且不会移除先前已有的状态行:先前的命令(其他工具依赖的状态行)仍会接收相同输入,既不会被等待,也不会被终止。在 2026-09-10 的测试中,渲染耗时中位数为 34 ms。
记忆按会话隔离,且隔离情况清晰可见。 每条笔记都带有作用范围:session(当前对话)或 project(所有人)。自动上下文数据包 prime 只包含当前会话的笔记;其他 Agent 会话中的内容不会泄漏到你的会话中。显式调用 myc recall 仍可找到这些内容,因为隐藏知识和限定知识范围并不是一回事;每行还会标明其范围:ses 表示自己的会话,ses* 表示其他人的会话,prj 表示整个项目。
$ MYC_SESSION_ID=s1 myc recall "retries" $ MYC_SESSION_ID=s2 myc recall "retries"
… prj project note: retries use jitter … prj project note: retries use jitter
… ses session note: retries back off… … ses* session note: retries back off…
3 of 3 · bm25 only · … 3 of 3 · bm25 only · … · 2 from other sessions
记忆有三个彼此独立的维度,并且界面会说明隐藏了什么:层级(项目或个人)、会话范围、仓库范围。prime 会显示 N from other sessions hidden 和 N notes from other repos hidden,而不是悄悄缩小结果范围。
降级情况会明确提示。 不会静默回退:向量分支不可用时,输出会说明这一点,并将答案标记为仅基于词法匹配;超出预算时,会明确指出超出的数值。基本原则是,降级答案绝不能与正常答案无法区分。使用 --strict 时,降级答案还会以退出代码 6 而非 0 退出,同时仍会打印 WARN 行。
通过普通 git 在多台机器间同步,并按字段合并。 只有操作日志会提交。两台机器编辑同一个节点时可以收敛:一台更改标题和优先级,另一台更改标题和标签;交换后,两台机器都会显示较晚的标题、第一台机器的优先级以及第二台机器的标签。不会像整条记录那样因最后写入者胜出而丢失内容。
防护条件通过变异测试来验证。 每项拒绝行为和每条不变量都有一个移除它的变异;如果移除某项防护后没有任何测试失败,就视为它不存在。完整测试套件:4312 通过 / 7 失败 / 16 跳过(
bun test,2026-10-18;针对已安装的 Orca.app 分块文件的 orca 状态行分类器、在干净的 main 上也会失败的 federation R3 系列 — memory-j4dkmcs2k7y1,以及测试套件全并行负载下的一两个 bench 和多进程偶发故障;这些测试单独运行时总能通过)。
myc 的功能
带租约、依赖关系和沿父级链继承的阻塞项的任务;可跨越压缩周期保留、按会话和仓库限定范围的记忆;排序后的混合搜索;上述代码索引;面向四种 Agent 的钩子和 MCP;用于重型命令的机器级队列;状态行;从 beads 导入;本地 Web 界面(myc viz:图、队列、看板、卡片、搜索、健康状况 — 编辑通过与 CLI 相同的写入路径进行);git 工作树和嵌套仓库;基于 Postgres、带令牌、角色和 ACL 的团队服务(myc serve,见下文);通过 git 或该服务同步;以及一项将声明与重新统计结果进行比较的 doctor 功能。
完整列表 — 每项功能都标明了首次推出的版本,并提供一条可在你的机器上运行以查看该功能的命令;网站构建时会针对本次构建的 --help 检查每条命令 — 请访问网站:
https://aistastudio.github.io/myc/#features。
路线图
各里程碑的进展情况 — 项目自身跟踪器中每个 epic 已关闭的子任务数与总数,以及其中仍未完成的每项任务,不含日期 — 请访问网站:https://aistastudio.github.io/myc/#planned。这些计数不是手动填写的:发布前,bun run site/roadmap.ts 会从 myc 读取数据;如果网站构建时发现计划中描述的任务在跟踪器中已不再处于未完成状态,就会拒绝构建。
简而言之:核心、记忆、语义和人机界面(M0–M2、M7)已完成或接近完成;所有 CLI 和 MCP 行的英文输出也已完成;代码智能(M3,包括内置的 graft 替代方案)和重型命令队列已经发布,但仍有任务未完成;团队里程碑(M4:myc serve、ACL、网络同步、Postgres)已构建并在运行 — 15 项任务中有 10 项已关闭,剩余工作包括其自身的验收(两个人和四个 Agent 在一台服务器上工作一周)、Postgres 上的混合搜索、SSE 增量、leader 和 full MCP 配置,以及批量 SQLite→Postgres 迁移;群体自学习(M5:按成本和结果进行路由,并共享 Agent 统计信息池)和蒸馏(M6)尚未开始。
实际而言,这意味着:myc 首先是本地工具,其次才是团队服务 — 两者并不相同。 所有功能都可在本地通过 git 中的文件运行。服务已经存在,已通过真实 Postgres 测试,并在下文介绍,但只有部分 CLI 能与之通信;其余部分会明确报错,而不会悄悄改写到其他位置。
团队服务
一条命令即可启动一个可直接使用的服务,无需手动操作:
docker compose -f deploy/compose.yml up -d
docker compose -f deploy/compose.yml logs server | grep 'bootstrap token'
Postgres 会在空卷上自行运行数据库架构,服务则会根据 MYC_BOOTSTRAP_* 注册第一个租户并签发第一个令牌。这个示例部署不适用于生产环境:密码是明文,没有 TLS,数据库也位于服务旁边的卷中。TLS 由部署方负责——在前面放置反向代理,并让它设置 X-Forwarded-Proto。
不使用容器时,运行方式也是同一个二进制文件:
myc serve --pg postgres://myc_app:…@host/myc --apply-schema # empty db only
myc serve --pg … --add-tenant acme
myc serve --pg … --add-token acme:anna --role owner # secret printed once
myc serve --pg … --port 8080
除存活探测 /v1/health 外,所有操作都需要令牌。令牌只存储其 sha256,因此即使拿到数据库副本,也无法获得访问权限,更没人能读回机密。角色包括 owner、maintainer、member、agent、viewer;权限包括 read、write、claim、sync、admin,而 --scopes 会缩小角色的权限范围。sync 特意不包含在 read 中:副本不会经过可见性谓词过滤,因此有权拉取副本,就意味着有权查看工作区中的所有内容。/v1/admin 管理页面会在表单中向浏览器请求令牌,并将其保存在 HttpOnly、SameSite=Strict Cookie 中。
客户端通过环境变量指向服务,绝不通过命令行参数(参数会出现在 ps、Shell 历史记录和钩子日志中):
export MYC_SERVER=https://myc.example/acme # workspace in the path
export MYC_TOKEN=myc_…
myc ready
CLI 只有部分功能支持服务端,而这点至关重要。目前可远程使用的功能有:create/task/bug/epic/msg、update、claim、list、ready、show、prime 和 sync。其他所有功能——close、remember、recall、comment、link、dep、attempt、search、code——都会以 precond.no_remote 拒绝执行,而不会悄悄使用本地数据库;毕竟,看到别人的任务并把它们据为团队所有,比遇到错误更糟。因此,服务目前是副本会合的地方,而不是整个工作闭环都能运行的地方。
所以,目前常见的使用方式是:每台机器都保留自己的本地工作区,并通过服务交换数据。
myc sync # both ways; --push-only, --pull-only, --dry-run
交换传输的是操作,而不是行:操作按 op_id 去重,并通过与 git 合并相同的 CRDT 路径重放(逐字段 LWW、添加优先的边、G 计数器);每个站点都有自己的游标,因此重复操作不会产生变化,中断后也可以恢复交换。
要了解在真实主机上配置 TLS、为每个人设置令牌、备份,以及遇到拒绝时该怎么处理,请参阅分步指南:docs/deploy.md。
在机器之间同步
只有操作日志会同步到 git(myc export → .myc/graph,克隆后运行 myc import)——不会同步派生投影或缓存。.myc/workspace.toml 和操作日志会按需提交;.myc/myc.db* 和本地状态则不会提交。
每个克隆只需注册一次合并驱动:
git config merge.myc-oplog.driver "myc merge-driver %O %A %B %L %P"
许可证
MIT——参见 LICENSE。选择它是为了让任何嵌入或分叉项目都能尽可能轻松地使用;所有运行时依赖(Bun、ONNX Runtime、sqlite-vec)也都是宽松许可。
本文档的俄语版本:docs/README.ru.md。
两种语言版本及图表见:https://aistastudio.github.io/myc/。
评论
一个开放协议,规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话,MCP 服务负责提供工具、资源和提示模板,两者通过标准消息通信,同一个服务可以被不同客户端复用。