AgentMesh

面向多智能体协作的低开销通信、语义状态传递与演化共享记忆 Runtime

AgentMesh 面向“中国研究生创新实践系列大赛——第三届中国研究生操作系统开源创新大赛暨开放原子大赛操作系统专项赛”赛题 10。项目不依赖第三方 Multi-Agent 编排框架，而是自行实现进程 Runtime、结构协议、成本感知路由、mmap 非文本状态、演化共享记忆以及贯穿 B0–B4 的统一观测与消融系统。

当前仓库已实现 Phase 0、B0（Full-Text）、Phase 2 Runtime Core 的 B0–B4 纵切、B1（Structured）、B2（Adaptive Sparse）、B3（Semantic State）、B4（Evolving Shared Memory）和 Phase 7 deterministic benchmark foundation。B0 保持为冻结基线；可选 Runtime transport 将 B0–B4 的实际 Agent 调用放入独立 UDS worker process；B1 改用结构协议；B2 选择安全稀疏链路；B3 让 mmap 非文本向量参与 routing 和 fixture ranking，并由 worker 依据 opaque ref 实际映射读取；B4 将成功诊断沉淀为可检索、有关联且可演化的共享记忆。当前不包含 B5 KV cache。

AgentMesh Runtime Architecture

为什么是 AgentMesh

传统多智能体系统常见三个问题：所有角色无差别通信、长自然语言上下文反复传递、成功任务的中间知识无法跨任务复用。AgentMesh 对应提供三个可独立消融的机制：

研究问题	AgentMesh 机制	当前实现
谁应该通信？	Cost-aware Adaptive Communication Graph	B2 可解释 utility、mandatory dependency、低置信 fallback
应该传什么？	Multi-Plane Semantic Communication Fabric	B1 MsgPack Control Plane；B3 opaque ref + float32 mmap State Plane
过去的计算如何复用？	Evolving Shared Memory	B4 Working/Episodic/Long-Term、link、consolidation、evidence ledger

项目的核心原则是：正确性与可测量性优先于“看起来更高级”。B0 故意保持固定拓扑全文通信；B1–B4 每次只增加主要机制，并复用同一任务、模型、Evaluator 和 Metrics 口径。

已验证状态

检查项	当前结果
WSL Ubuntu / Python 3.11	115 tests passed；`pip check` 通过
离线 B0 smoke	5/5；20 calls；8,254 Mock estimated tokens
真实 Qwen Phase 7 × 2	B0/B1 13/14；B2/B3/B4 14/14
真实 Qwen B4 UDS	4/4；11 IPC exchanges；0 retry/restart
openEuler 24.03-LTS-SP3 container	strict userspace PASS；115 tests；三轮 UDS B0–B4 全部 100%

真实 qwen3_vl_8b 两轮消融均值：

Variant	Success	LLM calls	Tokens	Messages	Task movement
B0 Full-Text	92.86%	56	44,404	56	117,870 B
B1 Structured	92.86%	66	38,096	56	56,940 B
B2 Adaptive	100.00%	55	33,149	44	45,160 B
B3 Semantic	100.00%	56	34,910	44	67,285 B
B4 Memory	100.00%	49	32,042.5 ± 1.5	38	60,482 B

B4 相对 B3：calls -12.50%、tokens -8.21%、messages -13.64%、task movement -10.11%；每轮 5 次有效复用、规避 6 次正常调用。完整实验边界见真实 Qwen B0–B4 报告，脱敏证据见 results/official。

Real Qwen B0-B4 Results

三分钟复现

conda activate agentmesh
python -m pip install -e ".[dev]"

# 完全离线的固定全文基线
python -m benchmarks.run_benchmark \
  --mode text --suite smoke --backend mock

# 四 worker UDS + mmap state + evolving memory
python -m benchmarks.run_benchmark \
  --mode memory --suite memory_smoke --backend mock \
  --transport uds_process

python -m pytest -q

Mock 模式不读取 API Key、不加载模型、不访问网络。真实模型通过统一 OpenAI-compatible Backend 接入；endpoint、model 和 key 只由环境变量提供。

文档导航

实现细节

Task
  -> Planner
  -> Retriever (offline fixtures only)
  -> Executor
  -> Reviewer
  -> Final answer

B0 后继 Agent 接收完整自然语言历史；B1 只传 action、parameters、result 和 capability 等结构字段。
Phase 2 B0–B4 Runtime 使用四个独立 spawn process、Unix Domain Socket、能力注册、有界并发、同角色串行保护、排队超时/背压、有限重试和 worker crash recovery；B2–B4 的 routing/memory control 保持在父进程，只调度选中角色；默认 in-process 模式保持不变。
B1 使用 MsgPack wire codec、JSON debug view、严格角色输出 schema 和四角色 capability handshake；OpenAI-compatible 结构化调用显式请求 JSON object。schema 或 evidence-anchor validation 失败时最多按配置进行一次反馈修复，原始与修复调用都记录真实 usage；最终失败仍保留有限长度响应诊断和跨进程 trace。
B2 根据 relevance、novelty、confidence、dependency、历史 token/latency cost 和 queue pressure 给候选角色打分。
B2 保留 mandatory dependency 和低置信完整链 fallback；不会为了降低成本剪掉 Executor/Reviewer。
B3 使用离线 deterministic hashing vector、float32 mmap store、opaque state ref 和 checksum；它不是神经 embedding 模型。
B3 process worker 注册 semantic_state_mmap capability，在限定 state root 内校验 task/shape/dtype/nbytes/SHA-256 后 mmap 读取；本机路径不进入消息或 trace。
B3 分别统计 Agent state transfer 与 Runtime 内部 state access，不把控制消息和向量数据混为一项。
B4 提供任务内 Working Memory、SQLite Episodic/Long-Term Memory，以及 similar_to/supports 关系。
B4 只写入 deterministic evaluator 判定成功的 episode；达到阈值的同类 episode 会创建或演化 long-term memory。
B4 命中时仍强制执行 Executor/Reviewer，只替换可由历史知识覆盖的 Planner/Retriever，并按 B3 counterfactual route 统计实际避免的调用。
B4 process 模式由父控制器持有临时 SQLite、检索与 consolidation；选中的 Agent 在 worker 内读取 B3 mmap state。数据库路径和 state 路径不进入 task message/trace。
MockBackend 完全离线、确定性运行；另有可配置的 OpenAI-compatible HTTP backend。
每任务自动记录成功状态、端到端/各 Agent 延迟、LLM 调用、输入/输出 token、消息数、序列化通信字节和 trace event；结构化模式额外记录 repair attempts/successes 和 unrepaired failures。
真实模型质量层额外记录 Planner/Retriever/Executor/Reviewer 的证据组覆盖率，以及 Retriever→Executor、Executor→Reviewer 的证据丢失；这些诊断指标不放宽 strict success。
baseline_v1 保留历史 Mock 消融提示；evidence_fidelity_v2 是首轮真实模型证据保真试验；当前推荐的 evidence_fidelity_v3 进一步约束紧凑 evidence ledger，并要求 Reviewer 审计 ledger 而非复制可能丢信息的 Conclusion。summary 显式记录 profile、model、temperature、max tokens 与 seed。
UDS 模式额外记录实际 IPC bytes/roundtrip、scheduler queue wait、backpressure rejection、retry 和 worker restart；这些 transport 指标不与逻辑通信字节混算。
Phase 7 统一 suite 包含 8 个 Linux operations 和 6 个 SWE diagnostic tasks、5 组连续序列，并支持 in-process/UDS 重复实验、均值/总体标准差、IPC 指标、CSV/JSON/SVG 与环境 manifest。
benchmark runner 每完成一个 task 就原子 checkpoint 任务、trace 和进度；被中断的无状态 B0/B1 实验可在严格校验 suite/backend/model/profile/task 顺序后通过 --resume 继续。

详细设计见 B0、Runtime Core、Evidence fidelity、B1、B2、B3、B4、Benchmark runner、Phase 7 benchmark 和 openEuler validation，代码真实状态见 decision log。

环境与安装

当前开发基线是 Python 3.11。Runtime 依赖只有 PyYAML 和 MsgPack；测试额外依赖 pytest。请使用已有的 agentmesh Conda 环境，不需要创建新环境：

conda activate agentmesh
python --version
python -m pip install -e ".[dev]"

代码不依赖 WSL 或 Windows 路径，目标是在普通 Linux 和 openEuler 24.03-LTS-SP3 上以同样命令安装和测试。

Linux/openEuler portability preflight

安装后可以无网络、无特权地验证 AgentMesh 所需的 Linux 原语：

agentmesh-portability --output results/portability/preflight.json

该命令检查 Python/依赖/配置、临时文件系统、AF_UNIX 0600 ping-pong、mmap、SQLite CRUD 和 multiprocessing spawn。在 openEuler 24.03-LTS-SP3 实机验收时使用严格发行版 gate：

agentmesh-portability \
  --require-openeuler \
  --output results/openeuler_validation/preflight.json

./scripts/validate_openeuler.sh

一键脚本在 preflight 后继续执行 pip check、全量 pytest、B4 UDS smoke 和三轮 Phase 7 UDS。它不安装依赖、不联网、不提权。WSL/Ubuntu 可以通过通用 Linux prerequisites，但 openEuler userspace/host validation 均为 false；这不等于 openEuler 实机验收。

若宿主已安装 Docker 并显式拉取官方 openeuler/openeuler:24.03-lts-sp3 镜像，可运行验证专用入口：

./scripts/validate_openeuler_container.sh

该脚本使用一次性、非 privileged 容器，源码只读挂载，结果保存在被 Git 忽略的 results/openeuler_container/。容器 bootstrap 会联网安装 python3-pip、git 和项目测试依赖；实际 preflight/test/benchmark 不调用网络。容器结果验证 openEuler 用户态、RPM Python 和 AgentMesh Linux 原语，但共享宿主内核，不能替代 openEuler 主机/VM 的 kernel、SELinux、systemd 或 cgroup 验收。

当前 clean revision 4a741f3 已通过该容器入口：strict userspace gate PASS、115 tests、B4 UDS 4/4、三轮 Phase 7 B0–B4 全部 100% 且 Mock stability PASS。容器入口只克隆当前提交，ignored results 和未跟踪的比赛材料不会进入验证副本。证据与边界见 openEuler container checkpoint 和 curated bundle。

运行离线 benchmark 与消融

从仓库根目录执行：

python -m benchmarks.run_benchmark --mode text --suite smoke
python -m benchmarks.run_benchmark --mode structured --suite smoke
python -m benchmarks.run_benchmark --mode adaptive --suite smoke
python -m benchmarks.run_benchmark --mode semantic --suite smoke
python -m benchmarks.run_benchmark --mode semantic --suite routing_smoke
python -m benchmarks.run_benchmark --mode memory --suite memory_smoke
python -m benchmarks.run_benchmark --mode text --transport uds_process --suite smoke
python -m benchmarks.run_benchmark --mode structured --transport uds_process --suite smoke
python -m benchmarks.run_benchmark --mode adaptive --transport uds_process --suite smoke
python -m benchmarks.run_benchmark --mode semantic --transport uds_process --suite smoke
python -m benchmarks.run_benchmark --mode memory --transport uds_process --suite memory_smoke
python -m benchmarks.run_benchmark --mode text --suite smoke --task-id linux-memory-pressure-001
python -m benchmarks.run_ablation --suite smoke
python -m benchmarks.run_b2_ablation --suite smoke
python -m benchmarks.run_b3_ablation --suite smoke
python -m benchmarks.run_b4_ablation --suite memory_smoke
python -m benchmarks.run_phase7 --suite phase7 --repetitions 3 --backend mock
python -m benchmarks.run_phase7 --suite phase7 --repetitions 3 --backend mock --transport uds_process
python -m benchmarks.run_runtime_ablation --suite smoke --backend mock
python -m benchmarks.run_runtime_ablation --mode structured --suite smoke --backend mock --results-root results/runtime_ablation_b1
python -m benchmarks.run_runtime_ablation --mode adaptive --suite smoke --backend mock --results-root results/runtime_ablation_b2
python -m benchmarks.run_runtime_ablation --mode semantic --suite smoke --backend mock --results-root results/runtime_ablation_b3
python -m benchmarks.run_runtime_ablation --mode memory --suite memory_smoke --backend mock --results-root results/runtime_ablation_b4
python -m benchmarks.run_runtime_load --suite smoke --concurrency 4 --max-inflight-requests 4
python -m benchmarks.run_runtime_load_sweep --suite smoke --concurrencies 1,2,4,8 --repetitions 3 --task-repetitions 20 --max-inflight-requests 4
python -m benchmarks.run_runtime_overload --suite smoke --concurrency 8 --task-repetitions 4 --max-inflight-requests 2 --queue-timeout-seconds 0.01 --mock-service-time-ms 50
python -m benchmarks.compare_real_runs --run v1=results/real_llm/run-v1 --run v3=results/real_llm/run-v3 --output-dir results/real_llm/comparison

标准 runner 会在开始、每个 task 完成后以及最终结束时原子更新结果。summary.json 的 run_status、进度、resume count、源码 revision/tracked-diff 哈希和 run contract 可区分完整结果与中断 checkpoint。对于 B0/B1，可使用同一命令追加 --resume 继续；runner 会校验源码、case 内容、endpoint 哈希、生成参数、Agent prompt 哈希与 transport 配置，不一致时拒绝恢复。B2 Router cost profile、B3 state 和 B4 memory 会跨任务演化，因此当前不允许 --resume 拼接这些模式，正式实验应整轮重跑。

Phase 7 repeated runner 进一步拒绝覆盖非空结果目录，并在长实验开始/结束时写入 running/complete manifest。真实 OpenAI-compatible 模式会先验证配置 model 是否由 endpoint 提供，生成脱敏 service_manifest.json；连接地址、API key 和服务端模型路径不会写入结果。

run_runtime_load 使用两套隔离的 B0 UDS Runtime 对同一 suite 分别做顺序与并发执行，输出 wall time、throughput、task latency P50/P95、逐 IPC queue wait、背压/retry/restart，并逐任务校验答案、Agent 输出、tokens、logical messages/bytes 和 IPC exchange count 完全等价。它不会注入 Mock 延迟，属于调度机制检查而非正式性能结论。实验定义见 Runtime load benchmark。

run_runtime_load_sweep 将该检查扩展为默认 1/2/4/8 clients × 3 repetitions，并把 5-case workload 确定性复制为每轮 100 个唯一请求。它输出 raw CSV、mean/pstdev/min/max、speedup/efficiency 和 95%-of-peak saturation reference；所有档位仍必须通过逐任务语义等价与确定性计量稳定性 gate。

run_runtime_overload 是单独的 synthetic failure experiment：显式让 Mock service time 大于 queue timeout，检查可归因背压、零错误 retry/restart、过载前后探针和 worker PID 连续性。正常 benchmark/load/sweep 强制 service time 为 0，不能把 overload rejection/wall time 当作性能结果。

compare_real_runs 对两个以上结果目录重新计算统一 evidence-fidelity 指标，并强制 suite/mode/transport/backend/model/task IDs 完全一致；输出 JSON 与 Markdown。它适合比较版本化 prompt profile，不允许把不同任务集或模型拼成“改进率”。

默认配置为 configs/default.yaml，默认 backend 是 mock。Mock 模式不读取 API key、不加载模型，也不发起网络请求。运行结果写入：

results/
├── b0_text/
│   ├── summary.json
│   ├── tasks.jsonl
│   └── traces/<task_id>.jsonl
├── b1_structured/
│   ├── summary.json
│   ├── tasks.jsonl
│   └── traces/{setup,<task_id>}.jsonl
├── b2_adaptive/
│   ├── summary.json
│   ├── tasks.jsonl
│   └── traces/{setup,<task_id>}.jsonl
├── b3_semantic/
│   ├── summary.json
│   ├── tasks.jsonl
│   └── traces/{setup,<task_id>}.jsonl
├── b4_memory/
│   ├── summary.json
│   ├── tasks.jsonl
│   ├── memory_snapshot.json
│   └── traces/{setup,<task_id>}.jsonl
├── ablation_b0_b1/comparison.json
├── ablation_b0_b1_b2/comparison.json
├── ablation_b0_b1_b2_b3/comparison.json
├── ablation_b0_b1_b2_b3_b4/comparison.json
├── runtime_ablation/{in_process,uds_process,comparison.json}
├── runtime_ablation_b1/{in_process,uds_process,comparison.json}
├── runtime_ablation_b2/{in_process,uds_process,comparison.json}
├── runtime_ablation_b3/{in_process,uds_process,comparison.json}
├── runtime_ablation_b4/{in_process,uds_process,comparison.json}
├── runtime_load/{sequential,concurrent,comparison.json}
├── runtime_load_sweep/{manifest.json,aggregate.json,runs.csv,runs/...}
├── runtime_overload/{report.json,probes.json,summary.json,tasks.jsonl,traces/...}
├── phase7/
    ├── manifest.json
    ├── aggregate.json
    ├── runs.csv
    ├── comparison.svg
    └── runs/run-NNN/{b0_text,...,b4_memory}/
├── phase7_uds_process/
    ├── manifest.json
    ├── aggregate.json
    ├── runs.csv
    └── runs/run-NNN/{b0_text,...,b4_memory}/
└── portability/preflight.json

临时运行结果默认由 Git 忽略；未来经过复核的正式实验结果可放入 results/official/ 单独提交。

Mock token 数是无 tokenizer 条件下的确定性估算，trace 中标记为 deterministic_estimate；OpenAI-compatible backend 使用服务端返回的 usage。Mock benchmark 的成功率验证 pipeline、证据传播和评估规则，不代表真实模型诊断准确率。--task-id 只筛选既有 suite，适合真实端点探针；正式准确率仍应运行完整 suite。

当前 Runtime Core checkpoint

uds_process transport 为 Planner、Retriever、Executor、Reviewer 启动四个独立 worker。每个 worker 同时注册 B0 full-text 与 B1 structured capability。父进程通过 versioned length-prefixed MsgPack/UDS 请求进行 capability handshake 和调用，只对 transport failure 做有限重试并重建 worker。

在最初的 B0-only Runtime checkpoint（源码 4d3594d）中，in-process 与 UDS process 都是 5/5、20 calls、8,254 tokens、20 logical messages 和 27,289 logical bytes。UDS 路径实际产生 20 次 task exchanges / 52,437 B，另有 8 条 setup messages / 1,024 B；本机单轮平均 task latency 为 0.374 ms vs 1.358 ms。详见 Runtime ablation。当前双能力 descriptor 使 worker setup 增为 1,094 B，但不改变 B0 task semantics 或 task IPC bytes。

B1 的进程内/UDS 路径同样保持 5/5、20 calls、10,602 tokens、20 logical messages、19,609 logical bytes，以及 8 条/2,626 B 的 B1 协议握手。UDS 任务流量为 20 次交换/57,289 B；Runtime worker 握手另计 8 条/1,094 B。详见 B1 Runtime ablation。两份报告均为单轮 Mock 机制检查，不能作为正式性能结论。

B2 smoke 的进程内/UDS 路径均为 5/5、15 calls、9,176 tokens、15 logical messages 和 16,085 logical bytes；5 次 Planner 剪枝及 15/25 active edges 逐任务一致。UDS 只产生 15 次 task exchanges / 48,807 B，证明剪枝发生在 worker dispatch 之前。详见 B2 Runtime ablation。

B3 smoke 的进程内/UDS 路径均为 5/5、15 calls、9,176 tokens、15 logical messages、19,553 logical bytes，以及 15 次 Agent state read / 3,840 B。每个选中 worker 在调用 Agent 前实际 mmap 并验证同一个 opaque state ref；UDS 任务流量为 15 次交换/54,165 B。详见 B3 Runtime ablation。

B4 memory_smoke 的当前证据保真路径在进程内/UDS 均为 4/4、11 calls、15,011 Mock tokens、11 logical messages、26,007 logical bytes、2 次 effective reuse 和 3 次 avoided calls；两侧规范化 memory snapshot 完全一致。UDS 当前执行 11 次 task exchange / 108,141 B。fb3bd47 上的早期 transport checkpoint 保留在 B4 Runtime ablation，其 11,511-token 数字属于尚未在 memory summary 中保留 evidence ledger 的历史实现，不能作为当前冻结值。

当前 B0–B4 Agent 执行均已进入 process Runtime；B4 memory control 仍位于父进程，不是独立服务。受限 sandbox 可能禁止 AF_UNIX bind，此时相关集成测试会 skip；当前普通 WSL/Linux 权限下完整测试为 90 passed。所有 Runtime checkpoint 都是 Mock 机制检查，不能作为正式性能结论。

B0 UDS controlled load runner 在 clean revision 50f3cbf 上使用 5-case smoke 对比单 client 与 4 clients：两侧均 5/5，答案、Agent 输出和确定性 calls/tokens/messages/bytes/exchanges 逐任务完全一致。该次 wall time 为 8.422→6.975 ms、throughput ratio 1.208×，但 task P95 从 1.883 增至 4.515 ms，且它只是未预热的单轮 Mock 微基准。详见 Runtime concurrency load checkpoint。

进一步在 clean revision 6e03f55 上完成 1/2/4/8 clients × 3 repetitions、每轮 100 请求的 sweep。三项 gate 全部 PASS；mean throughput 为 779.201/873.451/720.237/629.750 tasks/s，观测峰值和 95%-of-peak saturation reference 均为 2 clients。4/8 clients 的吞吐下降而 queue/task P95 上升，说明已进入单角色 worker 的争用区；该 WSL/Mock 结果不是生产配置建议。详见 Repeated concurrency sweep checkpoint。

最终 clean revision 7f749d9 的 controlled overload 使用 50 ms synthetic service time、10 ms queue timeout 和 2 个在途槽位：20 个请求中 19 个按预期背压拒绝，零未知失败/retry/restart，过载前后探针均通过且四 worker PID 不变。正常 B0–B4 transport bytes 保持冻结值。该 checkpoint 后 Runtime 进入功能冻结候选，详见 overload report 和 project status。

运行测试

python -m pytest
python -m pip check

测试不访问网络，覆盖 backend、五类 pipeline、UDS framing、worker/registry/scheduler/recovery、MsgPack、Router/fallback、hashing encoder、mmap lifecycle/checksum、分层记忆、关联与 consolidation、统一 Metrics、evaluator 和 B0–B4 对照。

OpenAI-compatible 模式（可选）

不要把 key 写进 YAML 或代码。通过环境变量配置 endpoint、model 和 key：

export AGENTMESH_LLM_API_KEY="..."
export AGENTMESH_LLM_BASE_URL="https://example.invalid/v1"
export AGENTMESH_LLM_MODEL="your-model"
export AGENTMESH_PROMPT_PROFILE="evidence_fidelity_v3"

# 先用一个既有 case 验证 backend、prompt、usage 和 trace。
python -m benchmarks.run_benchmark \
  --mode text \
  --suite smoke \
  --task-id linux-memory-pressure-001 \
  --backend openai-compatible

# 探针通过后运行完整 suite；UDS 默认 75 s request timeout 包住 60 s HTTP timeout。
python -m benchmarks.run_benchmark \
  --mode text \
  --suite smoke \
  --backend openai-compatible \
  --transport uds_process

.env.example 只列变量名；.env 已被 Git 忽略。AgentMesh 本身不会隐式加载 .env，需要由 shell 或用户自己的环境管理工具导出变量。OpenAI-compatible UDS 配置要求 runtime.request_timeout_seconds > llm.timeout_seconds，不满足时启动阶段会给出明确错误，而不会把慢推理误判为 worker crash。

当前真实模型 checkpoint 使用 vLLM 0.22.0 / qwen3_vl_8b。早期受控 smoke 中 V1→V3 success 由 3/5 提升到 4/5；随后在 clean source d49107a 上完成 14-case Phase 7 B0–B4 两次重复。B0/B1 均为 13/14，B2/B3/B4 均为 14/14；B4 相对 B3 的 calls/tokens/messages/task movement 分别减少 12.50%/8.21%/13.64%/10.11%，每轮 5 次 effective reuse、6 次 avoided normal calls，且 11/11 bounded repairs 成功、未修复结构错误为 0。详细方法、完整表格和限制见 real Qwen B0 checkpoint 与 B0–B4 repeated ablation。

同一服务上的首个 B1 JSON-constrained probe 为 1/1；随后 source a30bbb8 的完整 B1 smoke 仅 3/5，暴露 Executor schema 字段别名和 Reviewer evidence loss。加入可计量的有界 repair 与 evidence-anchor validation 后，source a7295a7 clean run 为 5/5、100% final coverage、22 calls、12,081 tokens、17,534 task bytes；service/内存各触发 1 次 repair，2/2 成功。相对初次 run，calls、tokens 和延迟均上升，因此该结果只说明这次实际故障被透明恢复，不能外推为多轮或跨模型结论。

当前 B1 smoke 结论

同一 Mock smoke suite 中，B0/B1 都是 5/5、20 次 LLM 调用和 20 条任务消息。B1 任务内通信字节减少 28.14%，计入一次 8-message capability handshake 后减少 18.52%；但 Mock 估算 token 增加 28.45%。这说明小 payload 上结构 schema 有固定 token 成本，当前不能宣称 B1 同时降低 token。详见 B0 vs B1 smoke report。

当前 B2 smoke 结论

B2 在 5 个简单诊断 case 中均剪掉 Planner，保持 5/5 success，并将 calls/messages 从 20 降至 15。相对 B1，Mock token 减少 13.45%，任务通信 bytes 减少 17.97%；相对 B0，任务 bytes 减少 41.06%，但 Mock token 仍高 11.17%。当前 suite 缺少必须激活 Planner 的复杂正式 case，因此这只是机制 smoke，不是 Router 泛化能力结论。详见 B0/B1/B2 smoke report。

routing_smoke 另含一个多服务依赖 case：简单 case 剪掉 Planner，复杂 case 激活完整链，两题均通过 evaluator。

当前 B3 smoke 结论

B3 保持 5/5、15 calls/messages 和 9,176 Mock token，产生 15 次 Agent state transfer（3,840 bytes）与 15 次 Runtime state access（3,840 bytes）。相对 B2，opaque ref 使 control bytes 增加 21.56%，计入 Agent 向量后 task data movement 增加 45.43%；相对 B0 总 task movement 仍减少 14.28%。因此当前只主张非文本状态“真实参与决策并可观测”，不主张 B3 在小任务上降低总数据量。详见 B0–B3 smoke report。

当前 B4 continuous-task smoke 结论

memory_smoke 按顺序运行 CPU 首次/复发和 Redis 依赖首次/复发两组任务。当前 B4 保持 4/4 success，产生 2/4 memory-hit tasks 和 2 次 effective reuse；相对同套件 B3，calls/messages 从 14 降至 11，但为防止复用时丢失路径、错误码等锚点，episode 现保留 exact evidence ledger，Mock tokens 从 12,286 增至 15,011，task data movement 从 27,022 B 增至 28,823 B。4 个成功 episode 形成 2 个 long-term unit 和 6 个关系 link。历史首次实现数据见 B0–B4 continuous-task report，当前权衡见 B4 architecture。

该结果只证明确定性连续任务中的机制和测量闭环。默认 benchmark 使用临时 SQLite 数据库，以确保每次运行从空记忆开始；运行结束前导出 memory_snapshot.json。它不代表真实 embedding 的检索质量或长期线上效果。

当前 Phase 7 repeated checkpoint

phase7 suite 包含 14 题（Linux 8 + SWE diagnostics 6）和 5 组首次→复发序列。基于干净提交 d46dcd5 的 3 次 Mock 重复实验中，B0–B4 每轮均为 14/14；B4 相对 B3 将 calls 从 44 降到 38、Mock tokens 从 30,809 降到 29,339、task data movement 从 76,153 B 降到 71,111 B。B4 每轮有 5/14 hit tasks、5 次 effective reuse 和 6 次 avoided calls。

当前 SWE case 只做基于源码、失败测试和预制 pytest 输出的故障定位，不会自动应用 patch；B4 本机 Mock latency 也显著高于 B3。详见 Phase 7 repeated report。

基于干净提交 92f8149 的配对 3 轮实验进一步验证了 UDS transport：B0–B4 的 success/calls/tokens/logical bytes 与 in-process 完全一致，所有 Mock 确定性指标总体标准差为 0，三轮共 714 次 task IPC exchange，retry/restart 均为 0。B4 相对 B3 的 calls 减少 13.64%，但实际 task IPC bytes 只减少 1.10%，说明 transport envelope/response 固定成本必须单独报告。详见 Phase 7 UDS repeated report。

加入 evidence-preserving memory 后，clean revision 4a741f3 已在 openEuler 24.03-LTS-SP3 容器中重新跑三轮 UDS Phase 7：所有 variant 每轮 14/14，Mock stability PASS。B4 仍将 calls 从 B3 的 44 降到 38，但 evidence ledger 使 tokens 由 30,809 增到 35,422、实际 task IPC bytes 由 235,769 B 增到 278,398 B；这是当前正确性优先的冻结权衡。

Planned（尚未实现）

B5：KV Fast Lane（高风险可选增强）

本阶段仍未实现独立常驻 daemon、priority/fairness/work-stealing scheduler、独立 state/memory service、cgroup、向量数据库、Web UI 或容器编排。当前 bounded concurrent scheduler 已实现。长期方案、冻结边界与剩余交付见 development plan、project status 和 docs/context/ 中的设计基线。