CoRA：从文本管道到状态驱动的多智能体协作系统

CoRA 是一个面向多 Agent 协作的轻量级运行时原型，用于比较 Text、Protocol、StateRef 与 Memory 四种模式在任务成功率、通信负载、非文本状态交换和跨任务记忆复用方面的表现。

本项目当前聚焦于 OS 开源大赛赛题中的多 Agent 通信、状态传递与共享记忆优化问题。

项目亮点

1. 长文档切块与按需状态读取

面对长文档，CoRA 不把全文反复传给多个 Agent，而是先切成 SourceChunk，检索后生成 SourceRef 和 StateRef。下游 Agent 只读取当前任务真正需要的证据片段，减少重复文本、Token 消耗和上下文干扰。

2. 关键词与语义向量混合检索

关键词检索负责查找路径、命令、错误码等精确信息；本地 Embedding 负责发现“表述不同但含义相近”的内容。两者结合后，只将少量高相关证据送入后续 Agent，而不是把整篇资料直接放进 Prompt。

3. 结构化通信、握手与能力发现

系统在 Agent 执行前完成最小握手与能力检查：确认协议版本、可执行动作和对应 Agent。运行时通过结构化动作、参数、结果和引用进行协作，而不是只依赖自然语言长文本透传。

4. 非文本状态传递与 StateRef

较长中间结果和语义向量写入 StateStore，Agent 之间主要传递轻量引用，而不是复制完整正文。接收方需要细节时再按引用读取，实现“控制面传引用、数据面存状态”的协作方式。

5. 共享记忆的两级检索与双通道核验

M4 将跨任务经验保存为“记忆存储单元（MemoryRecord）”和更细的“记忆块（MemoryChunk）”。后续任务先查找相关记忆，再按需读取必要块；如果记忆不足，系统再补充当前 Corpus 中确实有新增价值的证据，避免重复读取，也避免盲目信任旧记忆。

6. 面向通信、状态与记忆机制的分层任务设计

项目使用三类任务集分别验证不同能力：Mini 验证基础通信优化，Heavy 验证长文档与大状态处理，Memory 验证跨任务写入、复用、组合和 no-hit 安全回退。不同模式在相同任务与固定语料条件下比较，保证实验结论可解释、可复现。

7. 从 Mock、Live 到 Replay 的完整验证闭环

Mock 用于检查工程链路，Live 用于获得真实模型结果，Replay 用于离线复现和回归测试。系统同时输出 JSON、HTML、Agent 消息数、文本负载、Token、状态传递、耗时和记忆命中等指标。openEuler 已完成 M1～M4 的编译、测试、Mock 与 Replay 验证；当前一键演示版本仍需在目标机补跑最终 Live。

系统整体流程

M1～M4 均使用四 Agent 串行链路；M4 在运行时外增加可跨任务持久化的 Memory Store：

PlannerAgent → RetrieverAgent → ExecutorAgent → SummarizerAgent

Agent	Action	职责
PlannerAgent	plan	生成任务计划和执行方向
RetrieverAgent	retrieve	从固定文档或 CorpusStore 中提取相关证据
ExecutorAgent	execute	基于计划和证据完成分析或结构化执行
SummarizerAgent	summarize	生成最终答案或总结结果

赛题指标统计与展示

每轮 Benchmark 都保存 benchmark_result.json、逐任务 trace 和 benchmark_report.html。正式对比使用相同任务、相同模型与同一语料包（Heavy）或同一任务顺序（Memory），避免把不同输入条件混在一起比较。

赛题关注指标	CoRA 统计口径	报告展示
Agent 间消息次数	total_message_count；四 Agent 串行任务通常为每任务 4 条运行时消息	HTML 主概览与 JSON 汇总
文本通信开销	avg_payload_chars、Runtime 输入 / 输出 / 总 Token；真实 Token 只取 API 返回 usage	HTML 主概览、逐任务表与跨阶段对比文档
非文本状态传递	StateRef 个数、状态数据字节、读取次数；语义向量分别统计 Runtime、StateRef 与语料预处理的次数 / 字节 / 复用	HTML 主概览与 StateRef / Heavy trace
单任务总耗时	Runtime 耗时；同时保留包含可选 Judge 的端到端耗时，避免混淆	HTML 主概览与 JSON 汇总
共享记忆命中率	查询任务数、命中任务数、memory_query_hit_rate、Record 复用数与成功写入数	Memory HTML 主概览、逐任务 trace 与 M3-off / M4-on 对比
整体性能提升	在成功率不下降前提下比较 Payload、真实 API Token、耗时、Corpus 解析量及 Memory 复用	Mini、Heavy、Memory 三组对比文档

说明：payload_chars 只统计进入 Agent prompt 的文本，不把二进制语义向量字节混入文本负载；共享语料预处理向量与四 Agent Runtime 向量也分开统计。旧兼容字段 avg_memory_hit_rate 不作为 M4 正式命中率，正式口径为 memory_query_hit_rate。

CoRA-Bench-mini

CoRA-Bench-mini 是项目内置的小型 benchmark，位置为 benchmarks/cora_bench_mini/。

• 任务数：12
• 任务组：4 类，每类 3 个任务
• 文档来源：项目内固定 Markdown 文档
• 目标：比较不同 runtime 模式下的成功率、payload、token、冗余率和耗时
• 特点：不依赖外部网络检索；支持 mock / live / replay 三种运行方式

任务组	任务数	关注点
code_analysis	3	runtime 流程、上下文累积、通信统计
technical_research	3	openEuler / CoRA 技术说明检索与总结
tool_call	3	结构化 action、target_agent、params、refs
memory_reuse	3	为后续共享记忆复用准备的关联任务场景

Mini 中的 memory_reuse 是早期关联场景；正式 M4 跨任务写入、检索、组合与 no-hit 回退由独立的 CoRA-Bench-Memory 六任务集验证。

CoRA-Bench-Heavy

CoRA-Bench-Heavy 位于 benchmarks/cora_bench_heavy/，用于补足 Mini 文档短、状态轻、难以体现 StateRef 优势的问题。

• 任务数：3 个服务诊断任务，覆盖状态库权限、配置 Schema 迁移与同步服务启动超时；
• 资料规模：9 篇人工构造文档、118,264 字符、120 个 Chunk；
• 检索链路：CorpusStore → SourceChunk / SourceRef → StateRef；
• 检索方式：关键词召回与本地 BAAI/bge-small-zh-v1.5（512 维）语义向量混合检索；
• 对比口径：shared_corpus_packet 冻结三种 Runtime 的共同语料和证据包，用于严格通信 A/B；
• 边界：本地 Embedding 权重不进入 Git；Heavy 主实验仍比较 M1～M3，M4 的长期复用收益使用连续 MemoryTask 单独评测。

CoRA-Bench-Memory

CoRA-Bench-Memory 位于 benchmarks/cora_bench_memory/，用于验证 M4 Shared Memory 能否在一组有关联的任务中写入经验、正确复用经验，并在没有合适记忆时回退到当前资料。

• 任务数：6 个连续任务；
• 资料来源：复用 Heavy 的固定服务诊断文档，不复制一套新的长语料；
• 对比口径：同一任务顺序下比较 M3 StateRef（Memory off）与 M4 Memory（Memory on）；
• 检索方式：先在本地 SQLite Memory Store 中按关键词与语义相似度寻找候选记录，再按需读取其 MemoryChunk；
• 安全边界：记忆只作为候选经验，不能直接替代当前证据；命中后仍可通过 SourceRef 核验，信息不足或 no-hit 时回退到当前 Corpus。

任务类型	对应任务	验证目标
写入与检索	memory_store_001、memory_retrieve_001	建立 worker 故障经验，并在相似任务中复用
写入与应用	memory_apply_001、memory_apply_002	建立 API Schema 迁移经验，并用于后续安全迁移
组合复用	memory_compose_001	联合引用 worker 与 API 两条记忆处理一次发布故障
no-hit 回退	memory_nohit_001	没有匹配记忆时不误用已有结论，回退到 sync 当前 Corpus

M1 Text Mode

M1 使用 TextRuntime 作为基线模式：

• 四 Agent 串行执行；
• 使用完整自然语言 context 传递；
• 每个 Agent 输出追加到 context；
• 后续 Agent 接收累积历史文本；
• 作为后续 Protocol / StateRef / Memory 的对照基线。

Text Mode 的主要问题是上下文滚雪球：随着流程推进，payload_chars 和真实 LLM input tokens 会持续增长，重复上下文也会被反复传递。

M2 Protocol Mode

M2 使用 ProtocolRuntime 引入结构化通信：

• ProtocolMessage：Agent 间结构化消息；
• 中央 task_state：保存任务状态与阶段输出；
• INPUT_POLICY：控制下游 Agent 能看到哪些字段；
• summary / detail / raw_output：三层输出状态；
• raw_output 本地保存，不默认下传；
• detail 通过 details_from 受控传递；
• Agent prompt 中已移除 Required outputs，避免评测关键词泄漏；
• SummarizerAgent 使用 final-answer 输出约束，不再被中间 Agent 的 3 条短摘要限制。
• 运行前执行本地 HELLO → CAPABILITIES → ACCEPT / REJECT 握手，验证协议版本、必需 action 与 Agent 能力映射；握手失败时不调用 LLM。

层	字段	用途	是否下传
传输摘要	summary	给下游快速接力	默认传
必要细节	detail	保留关键证据和推理	按 INPUT_POLICY 传
原始输出	raw_output	trace / report / debug	本地保存，不默认下传

传递方向	默认传递内容
Planner → Retriever	plan.summary
Retriever → Executor	retrieval.summary + retrieval.detail
Executor → Summarizer	execution.summary + execution.detail
raw_output	只写入 task_state / trace / report，不进入下游 prompt

M3 StateRef Lite

M3 在 M2 的结构化通信基础上引入任务内 StateStore 和 StateRef：较长 DETAIL 不再默认内联传递，而是写入状态仓库；下游 Agent 接收稳定 SUMMARY、引用和 Resolver 选出的必要 chunks。raw_output 继续只用于本地 trace、报告和调试。

通俗地说，M1 是反复传整叠历史材料，M2 是传摘要加必要细节，M3 则把较长细节放进任务内“资料柜”，下游只在需要时取用相关片段。该状态仓库只服务当前任务或 benchmark session，不等同于 M4 的跨会话长期记忆。

图中的 ProtocolRuntime / 控制面 表示 M3 继承自 M2 的握手、能力映射和结构化任务状态；M3 实际运行时为 StateRefRuntime，负责 StateStore、StateRef、SourceRef 与按需读取的数据面。

• Retriever 与 Executor 的 DETAIL 写入 StateStore，形成 2 个 StateRef / 任务；
• Executor 受控读取 Retrieval 状态，Summarizer 仅在 Summary Gate 未满足时读取 Execution 状态；
• StateRef validator 校验写入、引用、读取、预算与非法读边，任务质量和机制正确性分别统计；
• Resolver 依据任务查询、Agent 角色、去重与字符预算选择 chunks，避免把完整历史 detail 重新搬回 prompt；
• summary + selected chunks 是稳定交接合同，避免局部证据替代全局结论。

M3 Lite 已在 Mini 完成 12/12 答案成功与 12/12 StateRef 机制成功。M3 Heavy 扩展进一步增加 CorpusStore、SourceChunk、SourceRef、本地 Embedding 与混合检索，使长文档先切块并保留来源，再由下游 Agent 按需读取必要状态。2026-07-28 的 Heavy 严格同证据 Live 中，M3 以 3/3 成功保持完整检索证据，平均输入 Token 较 M2 下降 36.67%、总 Token 下降 25.72%。设计细节见 docs/m3_state_ref_design.md。

M4 Shared Memory

M4 将 M3 的“任务内状态柜”扩展为可跨任务使用的“经验卡片库”：成功任务可以把可追溯的结论、证据、策略、验证与回滚信息写入 SQLite；后续任务先检索短摘要，再按 MemoryRef 读取必要 Detail Chunk。

CoRA-Bench-Memory：6 个连续记忆任务

M4 不使用 Mini 中早期的 memory_reuse 小场景作为正式证明，而是通过独立的 CoRA-Bench-Memory 连续任务集验证跨任务写入、检索、组合复用和安全回退。该任务集复用 Heavy 的固定服务诊断资料，使 M3-off 与 M4-on 在相同任务顺序和同一资料条件下比较。

任务类型	对应任务	要验证的能力
写入与检索	memory_store_001、memory_retrieve_001	写入 worker 故障经验，并在相似任务中正确复用
写入与应用	memory_apply_001、memory_apply_002	写入 API Schema 迁移经验，并用于后续安全迁移
组合复用	memory_compose_001	同时复用 worker 与 API 两条记忆处理发布故障
no-hit 回退	memory_nohit_001	没有匹配记忆时不误用历史结论，转而读取当前 sync 资料

图中左侧是跨任务 Memory 的检索与受控写入，中部是继承 M3 的四 Agent 与 StateStore，底部是当前任务 Corpus 通道。运行时先核验并按需读取相关 MemoryChunk，再通过 Coverage Gain 判断是否需要补充新的 Corpus Chunk，从而减少重复读取，同时保留当前证据核验能力。

当前实现中，任务主题和标签来自任务元数据，主题缺省时可回退到 Planner 目标；正式 Memory Benchmark 的写入还要求任务允许写入且最终成功。Coverage Gain 是 Retriever 调用前的 Corpus 选块步骤，图中为便于展示进行了简化。

成功任务输出
  → 生成 MemoryRecord + MemoryChunk
  → SQLite 持久化并保存本地 BGE 向量
  → 后续任务按关键词、标签和语义召回 Record
  → SourceRef 核验来源
  → Retriever 只读取必要 Memory Chunk
  → 覆盖不足时再补当前 Corpus

M4 的主要边界：

• 一个主题对应一张 MemoryRecord，写入前检查同主题和内容 hash；
• Memory ID、Chunk ID、核验状态和完整 SourceRef 留在本地 trace，不塞入 LLM Prompt；
• Memory 与当前 Corpus 分为两条通道，命中记忆不等于无条件跳过原始资料；
• Corpus 候选只有在能提升 Planner 检索方向覆盖时才加入，8 个 Chunk 只是安全上限；
• Seed、复用、双记忆组合和 no-hit 回退由 CoRA-Bench-Memory 六任务连续验证。

M4：M3-off / M4-on 全链路 Live 对比与记忆复用结果

以下是同一模型、同一组 6 个连续 MemoryTask 的本机最终 Live 对比。M3-off 不使用长期记忆，M4-on 开启 Shared Memory；两者均成功完成 6/6 任务。

指标（每任务平均）	M3 StateRef	M4 Memory	M4 变化
最终成功	6/6	6/6	保持
Payload Chars	17,510.50	13,133.00	下降 25.00%
Runtime 输入 Token	6,508.17	4,575.00	下降 29.70%
Runtime 总 Token	9,159.00	6,939.83	下降 24.23%
Runtime 耗时	46,984.45 ms	45,850.83 ms	下降 2.41%
记忆写入 / 复用	0 / 0	2 / 4	M4 跨任务能力

M4 记忆复用统计（六任务合计）：

指标	结果	含义
查询任务 / 命中任务	4 / 3	有 4 个任务实际查询长期记忆：其中 3 个是预期复用任务，均安全采用了历史经验；另 1 个是刻意设计的 no-hit 回退任务，正确结果应是不命中并读取当前 Corpus，因此命中率为 75% 而非 100%。
正式查询命中率	75%	3 / 4；剩余任务是刻意验证安全回退的 no-hit，不应强行命中。
Record 复用 / 成功写入	4 / 2	实际使用 4 次历史主题经验，并沉淀 2 条新经验。
选中 MemoryChunk / 注入正文	8 / 4,227 字符	只读取并注入必要细节，不把整条历史记忆搬进 Prompt。
跳过重复 Corpus Chunk	15	已由可核验记忆覆盖的重复候选不再重复读取。

本轮所有预期命中任务均复用了正确来源，no-hit 任务没有误用 worker 或 api 记忆。对应 Live 的缓存 Replay 为 6/6；随后十轮离线 Replay 为 10/10。详细口径见 docs/m4_shared_memory_live_comparison.md 与 docs/final_local_live_replay_verification_20260727.md。

M1 / M2 / M3 本机最终全链路 Live 对比

以下为同一 qwen-plus 模型、当前代码版本下的全链路 Live 结果。Runtime 指标只统计 Planner、Retriever、Executor、Summarizer 四个 Agent 的真实 API usage；端到端指标会额外包含实际触发的 Judge 调用。各模式只在同一任务集内比较。

CoRA-Bench-mini：12 个常规任务

指标（每任务平均）	M1 Text	M2 Protocol	M3 StateRef
最终成功	12/12	12/12	12/12
avg_payload_chars	20,891.58	10,776.50	8,081.17
Runtime 输入 Token	8,194.75	3,576.25	2,467.50
Runtime 总 Token	11,546.00	5,155.83	3,954.25
Runtime 耗时	58,478.85 ms	28,867.59 ms	29,974.33 ms

Mini 是系统级端到端对比：M3 相比 M1 保持成功率，同时使文本 Payload 下降 61.32%、Runtime 输入 Token 下降 69.89%、Runtime 总 Token 下降 65.75%、耗时下降 48.74%。相对 M2，M3 的 Payload、Runtime 输入 Token、Runtime 总 Token 分别下降 25.01%、31.00%、23.31%；M3 的局部状态读取使耗时上升 3.83%，因此不把时延宣传为全面下降。

CoRA-Bench-Heavy：3 个长语料诊断任务（本机最终全链路 Live）

Heavy 使用 9 篇人工构造的日志、配置参考和运维手册，共 118,264 字符、120 个 Chunk。三种模式共用冻结的 Corpus Packet、任务顺序、文档哈希、Chunk 集合和 Embedding 身份，比较器已验证 strict_ab_verified=true。

下表为 2026-07-28 的严格同证据 Live：三种模式共用同一冻结证据包后才渲染各自 Prompt。M3 的通信与 Token 均低于 M2；局部解析与状态读取仍使其墙钟耗时高于 M2，不能宣传为所有指标都领先。

指标（每任务平均）	M1 Text	M2 Protocol	M3 StateRef
最终成功	3/3	3/3	3/3
avg_payload_chars	51,726.00	28,445.00	20,019.00
Runtime 输入 Token	22,766.00	12,038.33	7,624.33
Runtime 总 Token	26,822.33	15,052.00	11,180.00
Runtime 耗时	78,821.11 ms	52,133.27 ms	65,007.67 ms

在本轮严格 Heavy 对比中，M3 相比 M1 的 Payload 下降 **61.30%**、Runtime 输入 Token 下降 **66.51%**、Runtime 总 Token 下降 **58.32%**，并保持 3/3 成功；相对 M2，Payload 下降 **29.62%**、输入 Token 下降 **36.67%**、总 Token 下降 **25.72%**。M3 比 M2 耗时上升 **24.70%**，主要来自本地解析与状态读取，属于当前可见边界。

完整实验口径、限制、指标解释和结果路径见 docs/m1_m2_m3_live_comparison.md。

当前 M2 / M3 严格成对验证（2026-07-28）

指标（每任务平均）	M2 Protocol	M3 StateRef	M3 相对 M2
最终成功	3/3	3/3	保持
Payload Chars	28,445.00	20,019.00	下降 29.62%
Runtime 输入 Token	12,038.33	7,624.33	下降 36.67%
Runtime 总 Token	15,052.00	11,180.00	下降 25.72%
Runtime 耗时	52,133.27 ms	65,007.67 ms	上升 24.70%

M3 的通信与 Token 均更低，检索证据覆盖率保持 100%，但局部解析与状态读取使耗时没有同步下降；本轮 Live 与其新缓存 Replay 的成功数、Payload 和 Token 均逐项一致。详细结果见 docs/final_local_live_replay_verification_20260727.md。

运行模式与关键配置

模式	用途
mock	工程链路验证，不调用真实 LLM
live	调用真实 LLM，获得正式实验结果
replay	使用缓存复现实验，避免重复消耗 API

主要示例入口：

• examples/run_benchmark_text_mode.py
• examples/run_benchmark_protocol_mode.py
• examples/run_benchmark_state_ref_mode.py
• examples/run_benchmark_heavy.py
• examples/run_benchmark_memory_mode.py
• examples/run_m3_m4_memory_live_comparison.py
• examples/run_benchmark_unified.py（统一配置入口，默认 Mock）
• examples/run_competition_demo.py（固定运行 Mini、Heavy、Memory 的 M1～M4 全量对比）
• scripts/run_final_demo.sh（openEuler 上的最终演示入口）

常用配置字段：

• llm_backend
• model
• base_url
• max_tasks
• benchmark_dir
• output_root
• enable_llm_judge
• cache_write_path
• replay_path

API Key 可通过环境变量或被 Git 忽略的 configs/final_demo.local.json 提供；不要将真实 Key 写入源码、示例配置、文档或 Git 提交。

快速验证

推荐 Python 3.10+。项目当前最小依赖见 requirements.txt。

pip install -r requirements.txt
python -m pytest -q
python examples\run_benchmark_text_mode.py --llm-backend mock --max-tasks 1
python examples\run_benchmark_protocol_mode.py --llm-backend mock --max-tasks 1
python examples\run_benchmark_state_ref_mode.py --llm-backend mock --max-tasks 1
python examples\run_benchmark_memory_mode.py --llm-backend mock --max-tasks 1
python examples\run_benchmark_unified.py --dry-run

requirements.txt 已包含 Heavy/M4 本地 Embedding 检索的运行依赖；模型权重放在 Git 忽略的 models/embedding/。Live 凭证必须保存在环境变量或 Git 忽略的本地配置中，不能写入源码、示例配置、文档或提交记录。

最终一键演示

最终演示固定覆盖 Mini 的 M1/M2/M3、Heavy 的 M1/M2/M3，以及连续 MemoryTask 的 M3-off/M4-on，共 57 次任务运行；只允许选择 live 或 replay 后端，避免遗漏比较组。

# 使用当前本地配置的默认后端运行全部对比；建议日常使用 replay
bash scripts/run_final_demo.sh

# 明确运行全部阶段的 Replay 或 Live
bash scripts/run_final_demo.sh replay
bash scripts/run_final_demo.sh live

Replay 需要已有完整 Live 缓存。完整的依赖安装、Embedding 模型准备、Live/Replay 一键复现、产物验收与常见问题见 部署文档（参考本文件安装依赖复现）；最终演示使用说明保留为配置字段速查。

项目目录说明

cora/
  agents/       # Planner / Retriever / Executor / Summarizer 等 Agent
  benchmark/    # benchmark loader、runner 与报告生成
  corpus/       # CorpusStore、SourceChunk、SourceRef 与长文档资料管理
  retrieval/    # 关键词/语义混合检索、Embedding Provider 与 Replay
  runtime/      # TextRuntime、ProtocolRuntime、StateRefRuntime 与 MemoryRuntime
  state/        # StateStore、StateRef、Resolver 与动态查询词
  memory/       # MemoryRecord、MemoryChunk、MemoryRef、SQLite Store 与两级检索
  eval/         # 成功判定、StateRef 机制校验与指标汇总
  protocol/     # ProtocolMessage 等协议结构
benchmarks/
  cora_bench_mini/  # 12 任务小型评测集与固定输入文档
  cora_bench_heavy/ # 3 任务长语料服务诊断评测集
  cora_bench_memory/# 6 任务跨任务写入、复用、组合与 no-hit 评测集
docs/           # 阶段文档、实验记录与验证说明
examples/       # benchmark 与 baseline 运行入口
tests/          # 单元测试与回归测试

更多文档

• docs/dev_log.md：阶段开发记录
• docs/m2_vs_m1_protocol_comparison.md：M1 与 M2 对比分析
• docs/m3_state_ref_design.md：M3 StateRef Lite 设计说明
• docs/m3_live_comparison_report.md：历史 M3 Lite Live / Replay 记录
• docs/m1_m2_m3_live_comparison.md：最新同模型 Mini / Heavy Live 对比
• docs/m3d_heavy_comparison_report.md：HeavyTask 与严格 A/B 设计记录
• docs/m4_shared_memory_live_comparison.md：M3-off / M4-on Live 对比与 M4 验收边界
• docs/m2_m4_live_comparison_20260725.md：当前严格 M2→M3、M3→M4 Live/Replay 对比
• docs/m4_experience_memory_v2_development_plan.md：M4 经验记忆与证据核验设计
• docs/live_text_baseline_report.md：M1 Live Text Baseline 实验记录
• docs/openeuler_verification.md：openEuler 阶段验证记录
• docs/openeuler_m1_m4_verification_20260725.md：openEuler 上的 M1～M4 部署、Mock 与 Replay 验收
• docs/final_demo_usage.md：openEuler 最终一键演示的配置、命令与产物说明
• docs/final_local_live_replay_verification_20260727.md：本机 M1～M4 全量 Live 与新缓存 Replay 验证 实验 JSON、HTML、逐任务 trace、LLM cache 与 Embedding cache 均写入 results/；最新跨阶段对比见 docs/m2_m4_live_comparison_20260725.md，目标系统验收见 docs/openeuler_m1_m4_verification_20260725.md。results/、models/embedding/ 与本地缓存默认不建议提交到 Git。

下一步计划

比赛材料收口：

• 汇总 M1～M4 的设计、部署、综合实验报告和演示材料；
• 固化 Mini、Heavy、Memory 三类任务集的成功率、通信负载、真实 API Token、耗时、非文本传递与记忆复用证据；
• 在 openEuler 上使用一键演示脚本补跑当前版本的完整 Live，再以目标机新缓存执行 Replay；两次结果都使用独立输出目录保存；
• 如最终材料需要稳定性统计，可追加目标系统 Replay 多轮运行；当前不把未执行的目标系统多轮结果写成已完成；
• M3-E 网络检索与 CodeAct 沙箱属于可选扩展，当前不阻塞比赛交付。

赛题说明

官方赛题原始 README 已备份至 docs/official_problem.md。