Cambium

cambium

xylem 技术栈的一部分。

知识生命周期 MCP，可将 Agent 已完成的工作转化为复合型、组织级知识。cambium 将两个现有基础连接起来：agentsync（发生了什么：声明、完成事项、备注、变更文件）和 context-keeper（为什么：决策、约束），并补上它们都不具备的三项能力：

1. distill() — 自动将事件转化为记忆（被动捕获）
2. recall() — 为所有 Agent 类型提供统一的联合读取端点 （编码 Agent、Slack 知识库机器人、SRE 机器人——使用同一存储、同一调用）
3. promote() — 随着知识获得信任，将其从本地 → 团队 → 组织逐级提升

名称取自树木的形成层：所有生长都发生于此的薄薄活组织。

为什么需要第三个 MCP（而不是数据库）

知识层会失败，因为它们是没人调用的旁支系统。cambium 的主张是：捕获和召回应当是Agent 工作循环中的原生工具，而状态应存储在工作本身所在的基础设施中——也就是 git——而不是独立服务中。存储只是 recall() 背后的实现细节：

范围	存储位置	信任门槛
local	<repo>/.cambium/knowledge.json	无——它属于你
team	共享仓库专用 cambium 分支中的 knowledge.json	召回次数 ≥ N 或获得认可
org	组织知识专用仓库中的 knowledge.json	必须获得认可；也可通过拉取请求提交——审查是门槛，git revert 用于撤销

团队写入采用 agentsync 模式：在 .git/ 下创建私有工作树，并使用 git push 进行比较并交换，因此并发运行的 Agent 不会相互覆盖。

安装

pip install -r requirements.txt      # just `mcp`

仅在以拉取请求模式提升组织级知识时才需要 gh（GitHub CLI）。

配置

将 MCP 客户端指向服务端——无需设置环境变量即可启动：

{
  "mcpServers": {
    "cambium": {
      "command": "python3",
      "args": ["/abs/path/to/cambium_server.py"]
    }
  }
}

初次接触时会提供帮助，而非冷冰冰地拒绝。 MCP 服务无法主动发起对话，因此 cambium 会通过自身的响应为你提供指引。在完成配置前调用 status()（或任何工具），你不会只得到一条环境变量错误，而是会收到结构化的指引——哪些项已设置、哪些项缺失、每个缺失项会带来什么影响（用通俗的语言说明），以及用于修复问题的准确 setup() 调用：

{
  "configured": false,
  "gaps": [
    {"setting": "CAMBIUM_REPO",
     "cost": "no project repo → cambium has no substrate; every tool is unavailable",
     "fix": "setup(project_repo=\"/abs/path/to/your/clone\", agent_id=\"your-id\")"},
    {"setting": "CAMBIUM_ORG_REPO",
     "cost": "org scope off → promotions stop at team; org-wide recall unavailable",
     "fix": "setup(project_repo=…, agent_id=…, org_repo=\"owner/knowledge or /abs/path/to/clone\")"}
  ],
  "next_step": "setup(project_repo=\"/abs/path/to/your/clone\", agent_id=\"your-id\")"
}

setup(project_repo, agent_id, org_repo?, org_pr?, team_branch?) 会完成剩余工作：验证路径、创建 .cambium/（并将其添加到仓库的 .gitignore），以及在 ~/.cambium/config.json 写入备用配置；当环境变量缺失时，服务端会读取该配置。配置会立即生效，无需重启。不会写入任何密钥：文件只包含路径、ID 和标志，且位于任何仓库之外。如果 org_repo 是你尚未在本地克隆的 GitHub owner/name，setup 会提供准确的 gh/git 命令来创建它，并保持组织作用域关闭——绝不会替你创建或推送仓库。

环境变量优先。 在 MCP 客户端配置中设置的以下任一变量，都会按键覆盖配置文件——下表是完整的参考说明：

环境变量	必需	默认值	含义
CAMBIUM_REPO	是	—	你的项目克隆（本地作用域，agentsync + context-keeper 基础层）
CAMBIUM_AGENT_ID	是	—	你的唯一 Agent ID
CAMBIUM_REMOTE	否	origin	git 远程仓库
CAMBIUM_GIT_TIMEOUT	否	25	每次调用的 git/gh 超时时间（秒），让卡住的调用快速失败，而不是让服务端一直挂起
CAMBIUM_TEAM_BRANCH	否	cambium	团队作用域分支
CAMBIUM_AGENTSYNC_BRANCH	否	agentsync	distill 读取的协调分支名称
AGENTSYNC_BOARD_REPO	否*	—	哪个仓库保存看板——与 agentsync 读取的设置相同，因此两个服务端不会产生分歧（见下文）
CAMBIUM_ORG_REPO	否	—	组织知识库克隆的路径（未设置时关闭组织作用域）
CAMBIUM_ORG_PR	否	直接推送	1 = 组织晋升时创建拉取请求
CAMBIUM_PROMOTE_RECALLS	否	3	本地→团队所需的回想次数
CAMBIUM_RELEASE_CAPTURE	否	关闭	1 = 也在 agentsync 声明转为 done/released 状态时捕获这些声明（见下文）
CAMBIUM_CONFIG_FILE	否	~/.cambium/config.json	覆盖备用配置文件路径（主要用于测试）

agentsync 看板的位置（看板寻址）

* distill() 会从协调看板读取已完成的 agentsync 声明。该看板是共享且长期存在的团队产物——并非取决于当前会话所在项目的属性——因此 cambium 会独立于会话解析其地址，并严格按照 agentsync 自身使用的顺序：

1. AGENTSYNC_BOARD_REPO——显式的看板地址（环境变量，或 ~/.cambium/config.json 中的同名键）。一个设置即可配置两个服务端。
2. AGENTSYNC_REPO——agentsync 的旧版显式固定值。
3. CAMBIUM_REPO——但仅当该仓库确实包含协调分支时（实际引用查找：本地 head → 远程跟踪引用 → ls-remote）。
4. 否则：没有看板，并会明确报告（见下一节）——绝不静默处理。

原因。 在此之前，cambium 会在 CAMBIUM_REPO 中查找协调分支，而 agentsync（未固定仓库时）会跟随 ~/.xylem/active_project.json。两者可能指向不同的仓库；而且只要当前项目从未配置过，两者就都找不到任何内容。distill() 会将此情况报告为平淡的字符串 "no coordination branch found"，调用方将其视为正常情况，结果便是 distill 在其整个生命周期内都没有导入任何 agentsync 声明——一个原本需要三条腿的设计，就这样在静默中只靠两条腿运行。

被跳过的来源不会显示为已完成

现在，distill() 的返回结果会让未命中不再被误读为成功：

• 顶层 status 变为 "distilled_with_warnings"（而不是 "distilled"）；
• 顶层 warnings 会为每个被跳过的基底提供一条通俗易懂的说明；
• sources.agentsync 是一个对象 — {status, board_repo, board_source, branch, claims_seen, done_claims, imported, reason, fix} — 因此，“没有看板”、“看板在这里，但没人完成任何事”和“已导入 3 项”会清楚地显示为三种不同结果，而不是一个空数字。

status() 会在 substrates.agentsync_board 下报告相同信息。

组织设置：创建一个（私有）仓库，例如 github.com/you/knowledge，并在 knowledge.json 中放入空的 {"items": []}；所有需要读取组织知识的人都克隆该仓库，并将 CAMBIUM_ORG_REPO（或 setup(org_repo=…)）指向自己的克隆。cambium 会管理这个克隆（会强制同步）——请专门用于此目的，不要在其中工作。

工具

capture(content, type, kind, why, tags, valid_while) — 将知识条目保存到本地范围（类型：memory | need | skill）。手动路径。 valid_while 可选地指明该条目所依赖的前提，以便之后发现已失效的假设（参见 机器维护的文档熵）。

record_need(content, why, tags) — 一等需求（“我们缺少 X”），与其他内容一样可提升，从而让反复出现的需求在团队／组织层面显现。

distill() — 自动路径。读取 agentsync 的协调分支（每个当前已完成的声明：任务 + 备注 + 变更文件 → 一条 outcome 记忆）以及 context-keeper 的 .context/（保留有效决策与约束、理由和 dec-NNN 来源信息）。具有幂等性 — 将其接入会话结束或提交后钩子，即可被动完成捕获。

发布时捕获（可选启用，CAMBIUM_RELEASE_CAPTURE=1）。 agentsync 根据 Agent ID 标识声明，并在声明被释放或重新认领时立即从实时状态中删除 — 它不提供任何钩子或事件，只会重写分支上的 claims.json。因此，一项已完成的声明如果在完整运行一次 distill 之前就发生变动，便会悄无声息地丢失。启用该标志后，每次 distill 还会记住每个 Agent 上次看到的声明，并捕获自上次运行以来任何已经变动消失的声明 — 从该快照中重建声明，并通过同一去重水位线处理，因此在释放时捕获的声明之后再次经过完整 distill 时绝不会重复导入。在完成事件上触发 distill()（提交后／会话结束钩子），即可在工作完成时捕获，而不只是碰巧在其仍处于实时状态时运行 distill 才能捕获。

这并不意味着：它是在 distill 运行时进行被动捕获，并非穷尽式重建。保证范围明确 — 如果一次 distill 扫描观察到某项声明处于已完成状态（或带有备注），就会捕获其中的知识，即使该声明之后发生变动。 剩余的缺口是：如果一项已完成状态在两次扫描之间产生并且完全变动消失（例如 cambium 未在运行），就永远不会被观察到，只有 agentsync 的 git 日志还会保留它。遍历该日志以穷尽式重建此类声明，是未来可能跟进的工作（历史记录仍然存在 — agentsync 的 history() 可以读取），本次变更特意不包含这项工作。

import_memory(source, path) — 将外部记忆导出内容导入 cambium，作为带有来源信息的本地范围知识条目（参见下文的导入）。对来源只读；导入的条目不会自动提升。

recall(query, scope, limit) — 对本地 + 团队 + 组织范围进行联合搜索。每个命中都会增加条目的回忆计数器（提升机制依赖此信任信号），并记录跨项目使用情况。若相关性低于阈值，则会如实放弃：返回 no_confident_match: true，而不是看起来很确定的噪声。每个结果都带有 endorsed_as — 将条目的背书备注作为一等上下文呈现，因为对于已提升的条目，其跨项目含义正是在这些备注中写明的。 endorse(item_id, note) — 为条目背书。加快 local→team 的晋升； team→org 时必需。

promote(item_id, to_scope, force, org_content) — 不带参数：扫描并晋升所有符合条件的 local 条目至 team。使用 to_scope="org"：推送至 org 仓库，或在 CAMBIUM_ORG_PR=1 时创建 PR（PR 合并前，team 副本会保留并附上注释）。晋升会写入 last_verified——晋升本身就是一次验证。 **通用化门槛：**所有项目都会读取 org 范围的内容，因此，若正文看起来是项目特定的（提及某个文件、test_* ID、dec-/con-NNN 引用或其来源项目本身），就会在 org 边界被拒绝——通过 org_content= 将其改写为跨项目规则（具体正文会保留为 example），或使用 force=True 覆盖。拒绝时会将背书备注作为可直接使用的草稿一并返回。这与背书门槛相呼应；安全路径也最简单。

generalize(item_id, org_content, note) — 门槛的补救方式：将已晋升条目的正文原位改写为跨项目规则，并将具体版本保留为 example。适用于在门槛启用前已进入 org 的条目（或通过强制方式越过门槛的条目）——即 review_promotions() 在 org_needs_generalization 下列出的条目。省略 org_content 时，会回退使用条目最新的背书备注。通过 org CAS 路径写入（直接写入，或在 CAMBIUM_ORG_PR=1 时使用一个共享的 cambium/generalize PR 分支，因此重复调用会合并到一个可供审查的 PR 中）；此操作幂等。

verify_entry(item_id, note) — 确认条目仍然有效；将其 last_verified 设为当前时间（备注可选）。这是防止已晋升知识悄然过时的事件（参见 机器维护的文档熵）。

stale_report(project, older_than_days) — 按最近验证时间从早到晚列出已晋升（team + org）条目，标记从未重新验证的条目，并显示每个条目的 valid_while 前提。报告过时情况；绝不自动降级。

review_promotions() — 查看哪些条目符合晋升至 team 的条件、哪些条目已获准晋升至 org、哪些 org PR 尚待处理，以及 org_needs_generalization——正文看起来仍是项目特定内容的 org 条目（在门槛启用前越过门槛或通过强制方式晋升），并列出每个条目发现的问题和建议改写内容的背书备注。

export_markdown(scope) — 将知识渲染为便于阅读的 KNOWLEDGE.md，按范围再按项目分组（每个条目包括：摘要、类型、来源信息 dec-NNN/声明来源、召回次数、晋升日期；规范化 cp1252 乱码）。scope="org"（默认）会重新渲染并将 org 仓库的 KNOWLEDGE.md 推送到 knowledge.json 旁边；local/team/all 会返回 Markdown，但不发布。此操作还会在每次晋升至 org 后自动运行——直接推送模式会同时提交两个文件，PR 模式则会将两个文件放在同一个 PR 分支上——确保 org 仓库的文档始终保持最新。

setup(project_repo, agent_id, org_repo?, org_pr?, team_branch?) — 从全新状态完成配置（参见 配置）。验证路径、搭建 .cambium/，并写入回退配置；对于 org 仓库，会提供 gh 命令，而不是创建仓库。不写入任何密钥。

status() — 首先显示配置状态：已设置和缺失的项目、每个缺项的影响，以及可修复它的 setup()（未配置时绝不抛出异常）。配置完成后，还会统计各范围/类型的条目数、导入水位线和已连接的底层存储。

复合增长循环

stobie's agent finishes work ──agentsync──▶ done claim + note + files
                                                 │
jonny's cambium: distill()  ◀────────────────────┘
        │ outcome memory (local)
jonny + teammates: recall() ×N  ──▶ trust grows ──▶ promote() → team
        │ visible to every collaborator's agent
someone: endorse()  ──▶ promote(to_scope="org")  ──▶ org repo / PR
        │
ANY agent, ANY project, ANY type (SRE bot, KB bot): recall(scope="org")

被动捕获：添加一个在会话结束时运行 distill 的 Claude Code 钩子——此后捕获无需为每条记录付出任何额外工作。也在完成事件中运行它（通过 post-commit 钩子），并设置 CAMBIUM_RELEASE_CAPTURE=1，即可在 agentsync 工作完成的瞬间捕获内容，赶在发布或重新认领将其清除之前。

导入

import_memory(source, path) 将外部记忆系统中的知识导入 cambium。这仅用于导入/摄取——它读取外部存储并写入 cambium 条目；绝不会写回源系统（导出是另一项风险更高的功能，特意不在此范围内）。导入采用源适配器的形式，与 distill 的基底读取器结构相同：适配器从源位置读取记录，并生成规范化的 cambium 知识条目，这些条目通过 distill 使用的同一套规范化、写入和去重流程写入，不会另设机制。

导入保证：

• 始终为本地范围。 导入的条目会进入 local 范围。它们尚未在 cambium 内获得晋升资格，且不会自动晋升——团队/组织范围仍需通过正常方式获得，即使用 recall() 并进行 endorse()。
• 始终保留来源信息。 每个导入条目都会标记 source: {system, ref, imported: true, source_ts}，并添加 imported 标签，以便将导入的知识与原生提炼的内容区分开来，并追溯审计其来源（系统 + 原始 ID + 原始时间戳）。
• 幂等。 重新导入相同记录不会添加任何内容——如果源记录存在稳定 ID，则按该 ID 去重；否则按内容哈希去重，并经由共享水印流程处理。
• 对源系统只读，且无依赖（仅使用标准库和本地文件——不联网，也不需要外部身份验证）。

json 适配器（参考实现）

随附的唯一适配器可从本地文件读取通用 JSON / JSONL 记忆导出文件，不与特定服务耦合。它接受顶层数组、在 memories/items/records/data/entries 下包含列表的对象，或 JSONL（每行一个 JSON 对象）。每条记录映射如下：

cambium 字段	源键（采用首个存在的键）	若缺失
content（正文）	content、text、body、memory、note	跳过记录（无正文）
— 合并到正文中	title、name、summary	省略
why	why、reason、rationale、context	空
kind	kind、type、category	"note"
tags	tags（列表或逗号/空格分隔的字符串）	仅 imported、json
source.ref	id、uuid、_id、key	改用内容哈希去重
source.source_ts	timestamp、created_at、ts、time、date	省略

type 始终为 memory；格式错误的行以及没有可用正文的记录都会计为跳过，绝不会导致导入崩溃。返回值会汇总 imported / skipped / duplicates。

# import_memory(source="json", path="/abs/path/to/export.jsonl")

适配器是扩展点。 随附的格式只有 json——这并不表示支持任何特定记忆产品。若要摄取另一个系统的数据，只需向 IMPORT_ADAPTERS 添加一个适配器（生成规范化条目的生成器），无需更改核心逻辑。此处有意不包含需要网络访问或凭据的适配器。

机器维护的文档熵

信任门控晋升在知识进入时提供保护：只有经过足够多次召回或获得背书后，条目才会进入团队或组织层。但之后没有任何机制标记它何时会过时。某个事实通过门槛时或许确实成立——“计费使用 NetSuite”“暂存数据库最多允许 90 个连接”——但前提消失后，它仍会一直被信任。更糟的是，Agent 会召回它、据此采取行动并引用它，因此错误假设不只是持续存在，还会被制度化；使用得越多，看起来就越权威。晋升提高了出错的代价，却没有提供任何办法来察觉自己已经错了。

cambium 通过验证事件和前提关联来解决这个问题，而不是使用置信度分数或随时间衰减——两者都会制造虚假的精确感。置信度为 0.62 的记忆暗示有人做过实际上并不存在的测量，而“信任度每 90 天减半”会悄悄降低那些稳定且正确的知识的可信度。相反，每个条目都带有可选的 last_verified 时间戳（晋升计为首次验证；后续验证由 verify_entry 记录），以及可选的 valid_while 前提，用于说明它依赖的条件。过时状态由事件驱动：stale_report 会按验证时间从早到晚排列已晋升条目，并标记从未重新验证的条目；distill 的交付时路径会在工作完成时显示最早验证的相关条目，让复查顺着已有的工作流节点进行。缺失或过早的 last_verified 只是向人发出的信号，绝不会自动降级。cambium 会报告异常迹象；由人来决定。

查看：tools/dashboard.py

python tools/dashboard.py --open

构建一个独立的 HTML 视图，展示整个网状结构——每个项目的 context-keeper 日志，以及从中提炼出的 cambium 层。包含四个视图：

• 概览 — 提炼漏斗：已记录 → 活跃 → 已提炼 → 已召回 → 已晋升。每个阶段都是上一级的子集。
• 项目 — 可排序的所有存储区表格；点击即可查看某个项目的完整日志、 取代链、约束范围和健康标记。
• 知识 — 提炼产生了什么、实际召回了什么，以及内容处于本地 → 团队 → 组织层级的哪个位置。
• 健康 — 乱码、理由不足、未标记、过时和从未召回的条目；每项均按其所属群体的占比显示，因此大型存储区不会仅仅因为规模大就显得不健康。

它之所以存在，是因为统计早已可行，但理解还做不到。首次运行就回答了一个任何单一工具都无法回答的问题：

范围	条目数	已召回	召回次数
本地	229	15（7%）	117
团队	136	134（99%）	774

**晋升让知识真正得到阅读。本地是暂存区，召回率低说明系统正常运作，而非失效——只有在同一视图中同时查看两个范围，才能得出这个结论。此工具的第一个版本只读取了 .cambium/knowledge.json（仅本地范围），并报告“没有内容离开本地”；团队知识存放在 Git 分支上，当时 136 个已晋升条目被召回了 774 次。

它还发现，有 84 个条目带有 cp1252 乱码，这些条目是在 context-keeper 修复传输问题之前提炼的；它们集中在召回次数最多的团队分支上。tools/repair_mojibake.py 会修复本地存储区；团队分支属于共享的 Git 状态，因此留待有意决定后再推送。

**设计上仅限本地。**输出已加入 Git 忽略列表。网状结构横跨私有仓库和完全没有远程端的仓库，因此公开版本只能如实展示汇总信息，不能展示更多；而这个版本展示一切，因为它属于你。只读，且 test_dashboard.py 会逐字节断言这一点。

测试

python3 test_cambium.py      # server integration suite
python3 test_dashboard.py    # the mesh dashboard

针对真实 git 仓库的 62 个用例：Markdown 导出（KNOWLEDGE.md 按范围和项目分组，并包含来源、回忆记录和推广日期；规范化 cp1252 乱码；在直接推送和 PR 两种模式下推广组织知识时，与 knowledge.json 一同自动写入）、写入时规范化（输入蒸馏器的基底内容中，经 cp1252 破坏的 em 短横线会在规范存储中恢复正常，因此 recall() 返回的是修复后的文本，而不只是渲染后的 .md）、入门配置（未配置时，status() 会报告缺项、成本和修复方法；未配置时每个工具都会给出有帮助的错误信息；setup() 可从冷启动状态完成配置，且配置会在进程内生效；环境变量会覆盖文件配置；组织名称会作为 gh 命令提供，而不会被创建；非 git 路径和不存在的路径会被拒绝）、捕获/回忆（以及如实弃答）、从两种基底内容蒸馏（精确遵循 agentsync 声明格式；精确遵循 context-keeper .context/ 架构）并具备幂等性、推广后的过时状态（可选的 last_verified/valid_while 字段、缺少字段时的向后兼容、verify_entry 在本地和团队间的往返、推广时添加验证时间戳、stale_report 按时间从早到晚排序并包含从未验证标记，以及年龄和项目筛选、发布蒸馏会显示验证提示）、发布时捕获 （默认关闭；已完成的声明即使在重新认领过程中发生变动，也只会被准确捕获一次；已记录但在达到 done 前释放的声明会被保留，而完整蒸馏可能会漏掉它）、导入（JSON + JSONL 导出 → 带来源标记的本地条目；重新导入会去重；没有 ID 时使用内容哈希作为后备；格式错误或缺失字段会被跳过而非导致崩溃；导入的条目会保留在本地且不会被推广；来源保持不变）、完整的推广生命周期（回忆阈值、认可快速通道、组织要求认可、使用桩模拟 gh 的 PR 模式）、组织通用化门槛（在组织边界拒绝项目特定的正文，并指出其特征、建议改写方式；org_content= 会进行通用化，并将具体正文保留为 example；force=True 可覆盖；不会过度拦截清晰的通用正文；recall 会显示 endorsed_as；review_promotions 会自我报告 org_needs_generalization；generalize() 会就地改写已推广的正文，将具体内容保留为 example，清除标记并保持幂等）、蒸馏时的旧字段回退（v0.4 之前的 context-keeper 决策即使只带有 rationale，仍会蒸馏出其 WHY）、跨项目信任跟踪、并发协作方推送下团队写入的 CAS、两个真实 agentsync 集成测试（同级仓库存在时，会驱动实际的 agentsync 认领 / 完成 / 释放工具，包括释放捕获衔接点），以及真实的 MCP stdio 传输测试。CI 会在每次推送时运行这些测试。

局限性（如实说明）

• 词汇召回，而非语义召回。 评分依据是词元／子串重叠——确定且无需依赖。之后可换成嵌入模型；工具契约不变。
• 不跟踪组织级别的使用情况（组织范围内的召回不会增加计数器）——组织级条目已经完成了晋升。
• PR 模式下的晋升不是事务性的——团队副本会保留（附有 PR URL），直到有人类合并。这正是设计目的：审核是关卡。因此，在 PR 模式下，每次只晋升一个条目到组织级别。 每次调用 promote(item_id, to_scope="org") 都会从 origin/main 创建分支，并向 knowledge.json 中同一个 items 数组追加内容，因此，两个同时打开的晋升 PR 会修改该文件的同一区域；第二个 PR 必须等第一个合并后才能顺利合并。（观察记录：2026-07-10 连续打开了两个知识 PR；第二个 PR 需要手动解决 knowledge.json 中的冲突。）先打开一个 PR，合并后，再晋升下一个——按顺序处理即可完全避免冲突。
• 每次运行 distill 恰好只读取一个看板。 distill() 会从通过看板寻址解析出的仓库中，对 <CAMBIUM_REMOTE>/<CAMBIUM_AGENTSYNC_BRANCH> 执行 git fetch，以获取 claims.json——如果设置了 AGENTSYNC_BOARD_REPO，则使用该值；否则，只有在 CAMBIUM_REPO 确实包含该分支时才使用它。现在不再固定使用项目仓库，但仍不会合并多个看板：在不同看板上协调的工作，或通过 agentsync-remote 传输与不同后端存储协作的工作，对本次运行不可见。每个看板都要单独运行一次 distill。
• Distill 只会捕获运行时的状态，不会穷尽所有情况。 默认情况下，它会导入 agentsync 中当前已完成的声明；若某个声明在任何一次 distill 实时捕获之前被释放或重新认领，就会丢失。设置 CAMBIUM_RELEASE_CAPTURE=1 可通过捕获声明进入已完成／已释放状态时的变化（借助上次观察到的快照）来弥补大部分遗漏；但如果某个已完成状态在两次扫描之间出现又消失，仍只能从 agentsync 的 git 日志中恢复——此处尚未实现历史遍历。

许可证

PolyForm Noncommercial License 1.0.0 ——可免费用于任何 非商业用途。

相关项目

属于 xylem 技术栈的一部分。