一年前，使用 AI 编程 agent 的常见方式还是：一个终端、一段对话、一个任务。现在真正的杠杆已经不在这里了。大家开始同时跑好几个 agent：一个在 git worktree 里重构鉴权，一个在梳理 issue tracker，一个后台任务汇总昨天的会话日志，还有一个定时 agent 每天早上开 PR。从一段对话走向一支编队，是 2026 年这类工具用法上最大的变化。
只要你从一个 agent 迈到多个 agent，两个没人提前提醒你的故障模式就会出现：
- 它们的记忆会相互串扰。 同一个项目里的每段会话，都会读取同一份
CLAUDE.md和同一套规则。要共享标准时，这正是你想要的；但如果每个 agent 都应该是一个有自己积累的专家，这就完全不对了。 - 一次重启会让整支队伍散掉。 六个 agent 都做到一半，你重启机器，回来只看到六个空终端，完全分不清哪段对话是哪段。
这两个问题都能解决，而且不需要引入框架。所需的原语，今天的 Claude Code 已经提供了。这篇文章就是一份把它们串起来的实战指南：给每个 agent 一份自己的记忆，再让整支编队熬过重启。
第一部分：给每个 agent 一份自己的记忆
默认的记忆模型，本来就是为共享而设计的。你在一个项目里启动的每段会话，都会加载同一套记忆层级：~/.claude/CLAUDE.md（你的个人规则）、项目里的 CLAUDE.md、CLAUDE.local.md，以及任何受管策略文件。对标准来说，这样很合理：测试命令、lint 规则、那条绝不能让 agent 提交的红线，你希望每个 agent 每一轮都能读到。
但对专精来说，这个模型就错了。如果你的代码审查 agent 在五十个 PR 之后学到：这个代码库总是忘记给 webhook payload 做判空。这不是所有人都该遵守的标准，而是那个 agent积累下来的经验。把它倒进共享的 CLAUDE.md，等于让其他每个 agent 的上下文窗口，都为一条它们永远用不上的备注付费。（这笔成本为什么真实存在，可以看你的 CLAUDE.md 能多大才不拖累性能。）
Claude Code 给了你三层机制，把这些东西分开。
Subagent 在自己的上下文窗口里运行。 一个 subagent 是 .claude/agents/（项目级）或 ~/.claude/agents/（你的所有项目）下面的一个 markdown 文件。它在独立于主对话的上下文窗口中工作，有自己的系统提示词、工具允许列表和权限。它存在的意义就是隔离：subagent 做完事，只把摘要交回来；它查过的搜索结果、走过的弯路，都不会污染协调者的上下文。Subagent 不会和协调者共享记忆，也不会彼此共享记忆。这种隔离本身就是特性。
memory: 字段会给 agent 一个跨会话保留的持久目录。 这是大多数人漏掉的部分。只要在 subagent 定义里加一行 frontmatter，它就会得到一个可以持续积累知识的文件夹：代码库模式、反复出现的 bug、架构决策。这些内容会从一次会话保留到下一次会话。scope 决定这个文件夹放在哪里：
memory: scope | 目录 | 适用场景 |
|---|---|---|
user | ~/.claude/agent-memory/<agent-name>/ | 这个 agent 需要在所有项目之间保留记忆 |
project | .claude/agent-memory/<agent-name>/ | 这份知识只属于当前项目，而且可以共享（提交进 git） |
local | .claude/agent-memory-local/<agent-name>/ | 这份知识只属于当前项目，但需要私有保存（不要提交） |
启用 memory: 之后，Claude Code 会自动把该目录下 MEMORY.md 的前 200 行（或 25 KB，以先到者为准）注入到这个 agent 的系统提示词里，并开启 Read、Write、Edit，让它自己维护笔记。于是，一个审查 agent 每次启动时，都会先读到它辛苦攒下的“本代码库坑点清单”——而这些内容完全不会进入共享的 CLAUDE.md，其他九个 agent 也不用为它们付上下文成本。
真正重要的是这条边界。 多 agent 配置里最常见的错误，就是把内容放错层：
- 共享标准 →
CLAUDE.md。每个 agent、每一轮都会加载。保持精简。 - 某一个 agent 积累出来的知识 → 它自己的
memory:目录。只有这个 agent 会加载。
这条边界划对了，每个 agent 都能保持专家身份，又不会撑大其他人的 token 账单。划错了，让专精知识漏进共享文件，你就重新造出了那个让 CLAUDE.md 在五人以上团队里崩掉的膨胀问题，只不过这次受影响的不是人，而是 agent。
如果要把持续并行扩展到单段会话之外，还有两个更新的原语沿用同一套模型：background agents 可以同时运行许多独立会话，并让你在一个地方监控它们；agent teams（仍然藏在 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 后面）会给每个 worker 独立的上下文，并允许它们互相发消息。两者继承的是同一条规则：每个 worker 的上下文彼此隔离，共享标准来自 CLAUDE.md。
第二部分：让整支编队熬过重启
先说那个被慌乱盖住的好消息：重启不会删除你的会话。 Claude Code 会持续把每段对话保存成磁盘上的本地 transcript，格式是 JSONL，位置在：
~/.claude/projects/<project>/<session-id>.jsonl每一行都是一条消息、一次工具调用，或一条元数据。~/.claude/history.jsonl 里还有一个全局索引。所以重启之后，完整状态其实就在那儿。问题只是没有东西负责把它重新拉起来。解决办法是三个习惯。
1. 给会话命名。 没命名的会话，只能进 picker 里翻；命名之后，它就可以被明确寻址。启动时用 claude -n auth-refactor 给它命名，或者对正在运行的会话执行 /rename auth-refactor 改名。（在 plan 模式里接受一个计划时，会话会根据计划自动命名。这是一个不用动脑也能拿到好名字的办法。）
2. 记住几个 resume 动词。 重启之后，用下面这些命令把会话带回来：
| 命令 | 会续上的内容 |
|---|---|
claude --continue (-c) | 当前目录里最近的那段会话，不需要记任何 ID |
claude --resume <name> | 指定的命名会话，即使跨 worktree 也能找到 |
claude --resume <session-id> | 按 ID 指定的任意会话，包括 picker 里不显示的 headless claude -p 会话 |
claude --from-pr <number> | 创建某个 PR 的那段会话 |
有一个坑值得记住：在非交互模式下，--continue 可能会启动一段新会话，而不是续上旧会话。凡是脚本化的场景，都用明确的名称或会话 ID 来 resume，不要靠 -c。
3. 接一个 supervisor，让它们开机后自动重启。 这一层文档把零件给了你，但不会替你装好，因为这是操作系统的职责，不是 agent 的职责。根据 agent 是交互式还是无人值守，有两种形态：
- 你会守着看的交互式会话： 把每个
claude --resume <name>放进一个tmux（或screen）窗口，再用登录脚本在开机时重建这个 tmux 会话。重启之后执行tmux attach，每个 agent 都回到原来的位置。这是仪式感最低的方案，也最适合大多数人起步。 - 无人值守的长跑 agent： 用 headless 方式运行（
claude -p "<instruction>" --resume <session-id>），再交给进程监督器管理：macOS 上用launchd（带RunAtLoad+KeepAlive的LaunchAgentplist），Linux 上用systemd（带Restart=always的 user service）。supervisor 会在开机时重新拉起 agent，也会在它退出后重启它。
在你把任何无人值守流程自动化之前，先记住两条警告：
- 键盘前没有人的 agent，需要
--dangerously-skip-permissions才不会卡在每一个确认提示上。这个名字有多危险，它就有多危险。只把它指向沙箱化的 checkout、范围受限的凭据，以及一个即使执行了坏命令、影响范围也受控的仓库。绝不要让一个重启后还能持续运行的无人值守 agent 接触生产凭据。 - Transcript 默认会在 30 天后自动删除（
cleanupPeriodDays）。对一支长驻 agent 编队来说，把这个值调大；否则你以为“还能 resume”的会话，会在背后悄悄过期。也不要在这里用--no-session-persistence：那个标志的作用，正是关闭重启恢复所依赖的 transcript。
第三部分：看清这支编队到底记住了什么
等你真的跑起来，比如同时跑八个 agent，每个都有自己的 agent-memory/<name>/MEMORY.md，也都有自己的 JSONL transcript 流，一个和重启无关的新问题就会冒出来：你会看不清全局。 哪个 agent 学到了什么？你的审查 agent 的记忆文件，是不是已经变成 40 KB 的陈旧笔记，并且在 25 KB 注入上限处被悄悄截断？昨天那个后台 agent 到底往磁盘里写了有用的东西，还是只是烧掉了 token？看不见的编队记忆，你就管不好。
这正是我们做 AI Memory Reader 要解决的问题（利益披露：这是我们做的）。它是一个免费、开源的 macOS 应用，会自动发现你的 agent 写入的每一个记忆目录和 transcript 目录：CLAUDE.md 文件、agent-memory/ 文件夹、~/.claude/projects/ 下面的 JSONL 会话日志。然后你可以在一个地方阅读它们。它还带实时文件监听，所以 agent 工作时，你能看到它的记忆同步更新。当你运行的是一支编队时，“每个 agent 现在到底知道什么”就不再是一个需要你去 grep 半天的问题。
一张索引卡能写完的最小 agent 编队
这套东西不需要复杂。完整配置几行就能写完：
- 共享标准放在
CLAUDE.md。保持精简。每个 agent、每一轮都会加载。 - 每个专家 agent都是
.claude/agents/下一个带memory:scope 的 subagent，这样它积累的知识会留在自己的文件夹里。 - 给每段长驻会话命名（
-n//rename），这样重启之后才能寻址。 - 开机后 resume：交互式会话用
tmux+claude --resume <name>，无人值守会话用launchd/systemd+ headless--resume <id>。 - 调大
cleanupPeriodDays，别让长驻编队的 transcript 在你脚下过期。 - 盯住它们记住了什么，别让记忆在看不见的地方腐坏。
延伸阅读
- 你的 CLAUDE.md 能多大才不拖累性能——为什么把专精知识漏进共享文件，会让每个 agent 都付出成本。
- 五人以上团队的 CLAUDE.md 问题——同一个共享与私有边界问题，只是往上挪了一层。
- AI 编程 agent 到底往你磁盘里写了什么——一支 agent 编队会在身后留下哪些目录，这篇给出完整地图。
来源：Claude Code 文档 Manage sessions 和 Create custom subagents（resume 标志、JSONL transcript 路径、memory: 字段及其三个 scope 目录、MEMORY.md 注入上限、30 天清理）；background agents 和 agent teams 同样来自该文档。2026 年 6 月核对。