目录
- benchmarksv1.6 final integration and release audit21天前
- comembusv1.6 final integration and release audit21天前
- docsOrganize submission materials2天前
- evidenceADD file via upload22天前
- examplesv1.6 final integration and release audit21天前
- resultsv1.421天前
- scriptskeep release validation worktree clean21天前
- testsv1.6 final integration and release audit21天前
- .gitignorefeat: add CoMemBus UDS and shared memory MVP25天前
- CoMemBus_Project_Description.pdfPlace submission materials at repository root23小时前
- CoMemBus_Project_Presentation.pptxPlace submission materials at repository root23小时前
- Dockerfile.openeulerfix: support openEuler 24.03-LTS-SP3 docker build25天前
- Original_Commitment.pdfPlace submission materials at repository root23小时前
- README.mdPlace submission materials at repository root23小时前
- requirements-core.txtfeat: add CoMemBus UDS and shared memory MVP25天前
- 操作系统开源创新大赛 作品原创承诺书.pdfADD file via upload23小时前
邀请码
版权所有：中国计算机学会技术支持：开源发展技术委员会
京ICP备13000930号-9
京公网安备 11010802047560号
CoMemBus
CoMemBus 是一个面向比赛题目“多智能体低开销通信、状态传递与共享记忆机制”的可复现 MVP。v1.6 将 v1.3-v1.5 的 benchmark、可靠性、持久状态和二进制交换能力接入最终 release audit：
multiprocessing.shared_memory共享。ObjectRef，不复制 8MB 数据内容。MVP 已实现内容
当前仓库实现了这些基础能力：
comembus.protocol：ObjectRef、Message、JSON 编解码、4 字节大端长度前缀 frame。comembus.transport.uds：AF_UNIX 客户端/服务端基础收发，多客户端线程处理，socket 文件清理。comembus.object_store.shm_store：基于SharedMemory的对象写入、读取、校验和删除。comembus.object_store.lease_manager：共享对象 lease、refcount、崩溃回收和 GC 统计。comembus.reliability：ACK/NACK、可见性超时、重复消息去重、队列背压和故障注入。comembus.memory：基于 SQLite 的 SharedBlackboard，共享记忆持久化、检索和复用。comembus.capability：CapabilityRegistry和简单握手，用于 Agent 能力发现与选择。comembus.collab：text_mode 与 structured_mode 协作模式对比实验。comembus.collab.embedding_state：embedding 直接交换的EmbeddingState/EmbeddingRef。comembus.collab.embedding_codec、embedding_store：float32 二进制 codec 和 Shared Memory EmbeddingRef。comembus.codeact：最小 CodeAct 沙箱，支持受限 Python 片段校验与隔离执行。comembus.llm：可选 LLM adapter 层，默认使用离线mockprovider。comembus.state：版本化TaskState、StatePatch、SQLite/WAL 状态恢复和 patch rebase。comembus.server：支持register、publish、poll、ack、nack、renew_visibility、ping、shutdown的消息总线。comembus.client：面向 agent 的 UDS 客户端 API。comembus.transport.adaptive：按消息大小和接收者数量选择direct_uds或shm_ref。comembus.transport.calibrator：用实测 direct UDS / SHM 延迟生成按 receiver 数区分的自适应阈值。comembus.metrics：线程安全的真实字节 recorder、统计函数和进程 CPU/RSS/context-switch 指标。comembus.memory.ranking、quality、provenance：检索排序、标注质量评估和记忆来源/版本/TTL。examples/smoke_pubsub_shm.py：8MB 共享内存发布/订阅 smoke demo。examples/incident_diagnosis_mock/：不依赖 LLM 的 mock 多 Agent 故障诊断 demo。benchmarks/bench_transport.py：比较direct_uds、shm_ref和adaptive三种传输模式。benchmarks/bench_state_patch.py：比较完整状态传递和StatePatch增量传递的字节开销。benchmarks/bench_memory_reuse.py：比较连续关联任务中的共享记忆复用收益。benchmarks/bench_collaboration_modes.py：比较纯文本协作和结构化协议协作的 token / 字节 / 步骤开销。benchmarks/bench_ablation.py：9 种公平基线与完整组件消融，默认 warmup 3 次、正式 30 轮。benchmarks/bench_rigorous_transport.py：比较 direct、SHM、固定 adaptive 和校准 adaptive。benchmarks/bench_failure_recovery.py：系统化执行 8 类 crash、重复、锁冲突、fallback 和 timeout 恢复场景。benchmarks/bench_embedding_codec.py：比较摘要、JSON 数组、float32 和 Shared Memory ref。benchmarks/bench_memory_quality.py：比较四种检索方法的 Precision/Recall/MRR/wrong reuse。examples/incident_diagnosis_mock/scenarios.jsonl：覆盖database_timeout、permission_denied、storage_full的丰富任务集。examples/incident_diagnosis_mock/run_llm_agent_demo.py：可选 LLM ReviewAgent demo，默认离线 mock。examples/incident_diagnosis_mock/run_llm_multiagent_smoke.py：可选 multi-agent LLM smoke，支持 planner/review 或 all。examples/incident_diagnosis_mock/run_codeact_demo.py：可选 CodeAct demo，返回受限沙箱执行结果。examples/incident_diagnosis_mock/run_reliable_agent_demo.py：可靠投递、对象租约、WAL 状态与 patch rebase 的端到端 Agent demo。scripts/summarize_all_results.py：汇总全部 benchmark CSV，生成 Markdown 和 JSON 报告。scripts/run_all.sh：顺序执行测试、demo、bench 和结果汇总。scripts/run_ablation_bench.sh、scripts/run_rigorous_bench.sh：运行 v1.3 严谨实验套件；不改变旧run_all.sh。scripts/run_failure_bench.sh：运行 v1.4 failure injection 验收并生成 CSV。scripts/run_embedding_bench.sh、run_memory_quality_bench.sh：运行 v1.5 二进制交换和检索质量实验。scripts/run_llm_demo.sh：运行默认离线的 optional LLM demo。scripts/run_remote_llm_smoke.sh：在远程 OpenAI-compatible 环境变量已配置时运行 optional remote smoke。scripts/run_llm_compare.sh：运行 mock vs remote LLM 对比，并保存结构化 JSON 产物。scripts/run_codeact_demo.sh：运行 optional CodeAct sandbox demo。scripts/run_reliable_agent_demo.sh：运行可靠端到端 Agent demo 并检查共享内存残留。scripts/run_release_validation.sh：按固定顺序执行 openEuler 最终 release audit。scripts/create_release_manifest.py：归档结果文件 SHA-256、Git/Python/OS、测试数与 SHM 状态。tests/：基于unittest的协议、对象存储、端到端测试。当前明确不包含
当前 MVP 不包含以下内容：
说明：
openai_compatible只作为 optional smoke provider 存在，失败时会自动 fallback 到mock。codeact只作为 optional sandbox demo 存在，不进入run_all.sh默认流程。run_release_validation.sh只执行离线 mock LLM，并在启动时移除 API credential 环境变量。本地运行
先检查环境：
运行测试：
运行 8MB shared-memory demo：
运行 mock multi-agent incident diagnosis demo：
运行可靠 multi-agent 集成 demo：
执行最终 release audit：
成功后会生成
results/release_manifest.json。运行 transport benchmark：
运行 state patch benchmark：
运行 memory reuse demo：
运行 memory reuse benchmark：
运行 collaboration modes demo：
运行 collaboration benchmark：
生成结果图表：
运行大规模 stress benchmark：
运行 v1.3 完整组件消融：
运行 v1.3 transport 校准与严谨对比：
运行 v1.4 failure injection benchmark：
运行 v1.5 embedding codec 和 memory quality benchmark：
两个脚本默认固定
random_seed=20260710。消融对每个 mode/task 先 warmup 3 次，再记录 30 个正式轮次；transport profile 按规定使用 warmup 3 次和 20 个校准轮次，正式 transport 对比使用 30 轮。核心 benchmark 全部使用 Python 标准库和确定性 mock/replay 逻辑，不调用远程 LLM。一键跑完整实验并生成汇总报告：
运行 optional LLM demo：
运行 optional multi-agent LLM smoke：
运行 optional remote LLM smoke：
运行 optional LLM compare：
运行 optional CodeAct demo：
默认会生成：
CSV 字段包括：
modeselected_modesize_bytesreceiversroundlatency_msuds_payload_bytesshm_bytes_writtenchecksum_ok其中：
direct_uds会把完整 payload 通过现有 UDS JSON frame 发布给每个 receiver。shm_ref会把 bytes 写入共享内存一次，再把ObjectRef发布给每个 receiver。adaptive会用AdaptiveTransportPolicy自动选择direct_uds或shm_ref。logs_r0、logs_r1、logs_r2这类 topic 模拟广播。sha256校验，并在异常时清理共享内存。v1.3 Rigorous Benchmark and Ablation Suite
v1.3 是新增的独立严谨实验层，保留旧 benchmark、
run_all.sh和已有 CSV 格式。新增字段只出现在新结果中；send_frame、recv_frame、SharedMemoryObjectStore的 recorder 参数均为可选参数，不启用时保持原行为。消融的 9 个模式为：
text_full_contexttext_summaryjson_full_statestructured_no_shmstructured_no_patchstructured_no_memorystructured_no_embeddingstructured_no_capabilitystructured_full所有模式读取同一份
examples/incident_diagnosis_mock/scenarios.jsonl，使用同一份日志和配置事实、相同的 5 个 Agent，以及固定的 Planner → Log → Config → Memory → Review → Planner 交接路径。text_summary使用固定的字符串解析摘要函数，不调用模型；json_full_state和structured_no_patch都传完整TaskState；其余structured_no_*每次只移除一个命名组件。v1.3 的字节口径是：
wire_bytes等于 recorder 观察到的发送端 frame 字节，包含每个 frame 的 4 字节长度头；不是根据 payload 大小推算。received_bytes是接收端观察值，用于交叉校验，不会再叠加到wire_bytes。shm_bytes_written/shm_bytes_read单独记录共享内存读写，绝不混入 UDS wire bytes。message_count是成功发送的真实 frame 数。统计结果包括每轮 latency、CPU time、
ru_maxrss、系统支持时的 voluntary/involuntary context switch，以及分组后的 mean、p50、p95、p99、样本标准差、95% 置信区间和 min/max。吞吐量按实际交付 payload bytes 与实测 wall-clock latency 计算。特别说明：
estimated_tokens采用确定性的ceil(text_chars / 4)字符估算，token_metric_type=character_estimate_4_chars_per_token。它不是 tokenizer 或模型 API 返回的真实 token 数，不能作为真实模型计费 token 使用。transport 校准覆盖
1KB,4KB,16KB,64KB,256KB,1MB,8MB和receivers=1,2,4,8。AdaptiveTransportCalibrator会实跑direct_uds与shm_ref并写出results/transport_profile.json；AdaptiveTransportPolicy.from_profile(...)读取每个 receiver 数的 crossover threshold。profile 不存在或无效时，仍回退到原来的固定 64KB 策略。新增产物为：
完整实验口径见 docs/benchmark_methodology.md。
v1.4 Reliable Delivery, Object Lifecycle and State Recovery
v1.4 在既有协议和 client/server API 上增量扩展可靠性。旧
publish(topic, payload)和poll(topic)仍可直接使用：旧poll在返回 payload 时自动 ACK，保持原来的消费即移除行为。需要显式可靠投递时使用：也可以调用
nack(message_id)立即重新入队。显式 poll 后消息进入 invisible 集合；deadline 前未 ACK 会自动重新可见，下一次投递的delivery_attempt增加。ACK 后DedupStore保存业务结果，相同message_id再次 publish 时直接返回duplicate_suppressed=true和原结果，不会再次入队。AgentBusServer(max_queue_size=N)启用背压，容量耗尽时客户端收到明确的QueueFullError。协议
Message兼容性新增：message_iddelivery_attemptcreated_atvisibility_deadline旧 frame 中没有这些字段时，解码器会补默认值；现有
type/topic/payload语义不变。共享内存生命周期由
ObjectLeaseManager管理。注册记录包含 owner、consumer 集合、refcount、deadline、state 和访问时间。重复 acquire/release 是幂等的；正常释放到 refcount 0 后仍会等待 lease 到期；消费者崩溃未 release 时，GC 在 lease 到期后把遗留 holder 归零并 unlink。get_stats()报告leaked_object_count和reclaimed_object_count。持久状态使用
SQLiteStateManager：PRAGMA journal_mode=WAL。states保存最新 snapshot，patches保存每个成功 patch。BEGIN IMMEDIATE事务中。SQLiteBusyError。recover(task_id)支持进程重启恢复；compact(task_id)固化最新 snapshot 并删除已合并 patch。PatchRebaser允许 list append 和不同 facts key 合并；同一标量字段或同一 facts key 的并发修改抛出PatchConflictError。failure benchmark 覆盖：consumer crash 重投、重复消息、ObjectRef holder crash、并发 patch、coordinator commit 后 crash、SQLite lock、LLM endpoint fallback、CodeAct timeout。结果写入：
所有预期故障都必须被明确观察并完成恢复；意外异常会写入
error、将success设为 false，并使脚本返回非零状态。完整设计见 docs/reliability_design.md。v1.5 Binary Embedding Exchange and Memory Retrieval Quality
原有
HashEmbeddingEncoder、JSONEmbeddingState和 JSONEmbeddingRef保留。v1.5 另外提供EmbeddingBinaryCodec，使用 little-endian IEEE-754 float32：SharedEmbeddingStore.put_vector()把这些二进制 bytes 写入共享内存，并返回新的 sharedEmbeddingRef，其中包含完整ObjectRef、dim、dtype=float32和 SHA-256 checksum。接收端使用open_memoryview()直接验证和解码 shared buffer，不先复制为整段 Pythonbytes。旧 JSON 通路仍可作为兼容回退。Embedding benchmark 比较：
summary_textembedding_jsonembedding_float32embedding_ref维度为 32/64/128/384/768，每组默认 warmup 3 次并记录 30 轮。当前实测平均 UDS wire bytes 为：短摘要 181.6、JSON 5893.0、float32 1620.4、shared ref 389.8。这个结果说明 binary 对完整向量显著小于 JSON，但短摘要仍可能比固定大小的 ref 元数据更小；benchmark 不预设 binary 对短文本一定占优。
MemoryUnit向后兼容新增：content_hash和同内容去重version、valid_from、expires_atparent_memory_ids、superseded_byprovenance旧 SQLite memory 表会自动增加新列并回填 content hash。搜索默认排除尚未生效、已过期或已被 supersede 的记录；直接按 ID 获取仍可用于审计历史。
Memory quality benchmark 使用 5 个 family、40 条 corpus memory 和 30 条 query。每个 family 至少有 2 个关键词相似但根因不同的 hard negative，同时包含过期策略和相互矛盾/被修正的记忆。query 只传可观察线索标签，不传标准答案 family tag。输出 Precision@1/3、Recall@1/3、MRR、
wrong_reuse_rate、stale rejection、query latency 和 task success，而不是把任意命中都当作成功。当前扩展数据集中 keyword 的 MRR 为 0.8335、wrong reuse 为 0.2333；hash embedding 的 MRR 为 0.5543、wrong reuse 为 0.5667；tag/hybrid 的 MRR 为 1.0、wrong reuse 为 0；所有方法 stale rejection 都为 1.0。详细语料和指标口径见 docs/memory_quality.md。
v1.6 Final Integration and Release Audit
可靠 Agent demo 使用真实 UDS
AgentBusClient/AgentBusServer，而不是直接调用队列内部实现。LogAgent 第一次poll_reliable后取得 ObjectRef 并模拟崩溃，不发送 ACK；visibility timeout 后同一 message 以 attempt 2 重投。retry agent 执行业务一次并 ACK，随后相同 message ID 的 publish 由DedupStore返回已处理结果。同一初始 TaskState 同时交给 LogAgent 和 ConfigAgent。Config patch 先通过
SQLiteStateManager的 WAL 事务提交；Log patch 因旧版本被拒绝，再由通用PatchRebaser验证无字段冲突后重放。Coordinator 关闭并重新打开 SQLite manager，通过recover(task_id)恢复版本 3。崩溃 LogAgent 遗留的共享内存 holder 在 lease 到期后由ObjectLeaseManager.collect_expired()回收。CodeAct worker 保留 AST 白名单和 wall-clock timeout，并在子进程执行前设置
RLIMIT_CPU、RLIMIT_AS、RLIMIT_FSIZE、RLIMIT_NOFILE、RLIMIT_NPROC。stdout 最多保留 4096 字符并显式报告截断；worker 使用单向 Pipe 回传，不需要在RLIMIT_NPROC=0后创建 Queue feeder thread。最终验证入口按顺序运行环境检查、所有测试、旧主流程、可靠 demo、v1.3-v1.5 benchmark、failure injection、离线 LLM demo、CodeAct demo和
/dev/shm检查：任一核心命令失败会立即停止。脚本保留本轮新生成且被 Git 忽略的 CSV/JSON 证据，但会恢复既有 tracked SQLite/SVG/Markdown 结果基线，因此从干净 commit 启动时结束后仍保持工作树干净。最后生成的
results/release_manifest.json包含当前 Git commit、Python/OS 版本、动态发现的测试总数、全部结果文件 SHA-256、生成时间和共享内存残留数；manifest 不读取或保存 API Key。Result Figures
v0.10 新增了一个纯标准库 SVG 出图脚本：
默认读取：
results/transport_bench.csvresults/state_patch_bench.csvresults/memory_reuse_bench.csvresults/collaboration_bench.csvresults/summary_metrics.json并输出到：
当前至少会生成：
transport_latency.svgstate_patch_bytes.svgcollaboration_tokens.svgcollaboration_latency.svgmemory_reuse.svgcapability_embedding_counts.svg这样可以直接把 benchmark 结果放进技术报告、PPT 或比赛材料里，而且不需要
matplotlib、numpy、pandas。Stress Benchmark
v0.10 还新增了：
它会在
results/stress/下运行三组更大规模对比：--tasks 30 --text-context-bytes 16384--tasks 30 --text-context-bytes 65536--tasks 60 --text-context-bytes 65536并输出每组的：
text_mode total_tokensstructured_mode total_tokenstoken_saving_ratiolatency_saving_ratiostructured_mode memory_hit_rateroot_cause_correct是否全部为true这里的 richer task set 不再局限于 12 条原始样例；当轮数超过默认场景数时，benchmark 会基于当前 family 结构做循环扩展，继续验证连续任务稳定性。
默认 adaptive 策略是：
size_bytes < 65536且receivers <= 1时，选择direct_udsshm_refselected_mode用来记录该轮实际落到哪条传输路径：mode=direct_uds时，selected_mode=direct_udsmode=shm_ref时，selected_mode=shm_refmode=adaptive时，selected_mode可能是direct_uds或shm_ref说明：
direct_uds、shm_ref和adaptive在 8MB 数据上的差异，会只在 benchmark 进程内临时放宽这个上限，不修改核心运行时代码。StatePatch
comembus.state新增了一个轻量级版本化状态层，目标是在多 Agent 交接任务上下文时，只发送变化部分，而不是每次都重发完整状态。核心对象包括：
TaskState：完整任务状态快照，带version。StatePatch：基于expected_version的增量更新。InMemoryStateManager：用于 demo 和 benchmark 的内存态状态管理器。默认思路是：
TaskStateStatePatch+1这样做的意义是：
bash scripts/run_state_bench.sh会生成：用于比较
full_state与patch在small、medium、large三种状态规模下的字节开销。SharedBlackboard
comembus.memory提供一个可持久化、可检索、可复用的 SharedBlackboard，用于保存多 Agent 执行过程中的中间结果、摘要、证据链、错误原因和经验片段。核心对象包括：
MemoryUnit：一条黑板记忆，包含来源 agent、任务主题、类型、摘要、内容、标签、置信度和元数据SQLiteMemoryStore：把记忆和 embedding 持久化到 SQLiteHashEmbeddingEncoder：基于分词和哈希的固定维度轻量语义向量SharedBlackboard：统一封装写入、关键词检索、标签检索、语义检索和综合检索当前语义向量不是外部模型 embedding，而是纯标准库实现的 hash embedding。这让模块可以：
这部分能力对赛题里的“共享记忆存储、检索、复用”很关键，因为它让不同 agent 不仅能共享对象和状态，也能复用历史经验片段。
python3 examples/incident_diagnosis_mock/run_memory_reuse_demo.py会演示跨任务记忆复用：bash scripts/run_memory_bench.sh会生成：并输出
memory_hit_count和memory_hit_rate。Text Mode vs Structured Mode
v0.7 新增了一个可复现实验，用来比较：
text_mode：纯文本协作基线structured_mode：结构化协议协作模式text_mode模拟传统多 agent 系统里反复传递完整自然语言上下文的方式。它会在每次交接里重复发送：因此它的
text_chars、approx_tokens和protocol_bytes会明显偏高。structured_mode则复用当前已有能力：action_typeparamsresultAgentCapabilityObjectRefStatePatchMemoryRef（直接用memory_id）其中：
ObjectRef传递StatePatch交接SharedBlackboard搜索后传memory_refpython3 examples/incident_diagnosis_mock/run_collaboration_modes_demo.py会输出：text_mode approx_tokensstructured_mode approx_tokenstext_mode text_charsstructured_mode text_charstoken_saving_ratioroot_cause_correctbash scripts/run_collaboration_bench.sh会生成：并统计输出：
text_mode total_tokensstructured_mode total_tokenstoken_saving_ratiotext_mode total_latency_msstructured_mode total_latency_mslatency_saving_ratiostructured_mode memory_hit_ratestructured_mode total_saved_steps这组实验对应赛题里“纯文本协作模式”和“结构化协议协作模式”的直接对照，也有助于解释为什么结构化协议能更好地压缩重复上下文和 token 开销。
v0.8 在这组实验上继续做了三项增量扩展：
structured_mode会先注册 Planner / Log / Config / Review / Memory 五类能力，再通过select_agent(action_type)选择目标 agent，而不是写死分发对象。EmbeddingState和EmbeddingRef，以非文本状态形式在结构化消息里传递，并统计embedding_state_count、embedding_state_bytes。examples/incident_diagnosis_mock/scenarios.jsonl，覆盖database_timeout、permission_denied、storage_full三个任务族。results/collaboration_bench.csv现有字段保持不变，并兼容性新增：scenario_familycapability_countcapability_discovery_countembedding_state_countembedding_state_bytes这意味着 benchmark 不再只围绕单一“wrong database port”样例，而是可以比较多任务族场景下：
Optional LLM Agent
v0.9 新增了一个完全可选的
comembus.llm接入层。它的目标不是让 CoMemBus 依赖外部模型，而是在不破坏当前 openEuler 离线复现实验的前提下，提供一个“如果你本地已经有模型服务，就可以接上去”的薄适配层。当前支持三个 provider：
mocklocal_httpopenai_compatible默认一定是
mock，这意味着：run_all.sh不需要改mockprovider 会根据结构化 facts 中的关键词，稳定返回确定性 root cause 和 report，例如：database timeout+wrong database portpermission deniedstorage full如果你本地已经启动了一个 OpenAI-compatible chat completions 接口，可以额外使用：
或设置环境变量：
当前
local_httpprovider 支持：--modelCOMEMBUS_LLM_MODELlocal-model运行 demo 时会额外输出：
provider=...model=...used_fallback=true|false其中：
provider=local_http且used_fallback=false表示真实本地模型调用成功provider=mock且used_fallback=true表示本地 HTTP 调用失败后已经回退到 mock但这里有两个设计原则：
mock原因很简单：CoMemBus 当前强调的是“低开销通信、状态传递、共享记忆、可复现实验”，不是把外部网络和线上服务当作默认前提。
LLMReviewAgent也不会把 8MB 原始日志直接塞进 prompt，而是只复用：TaskState.factsSharedBlackboard返回的 memory summaries这样可以保持 structured_mode 的上下文压缩优势。
更完整的 local HTTP 验证步骤见：
OpenAI-Compatible Remote LLM
v0.11 新增了
openai_compatibleprovider，用于接入远程兼容chat/completions的服务，例如：推荐通过环境变量配置：
这里有两个概念：
BASE_URL：基础地址，例如https://api.deepseek.comendpoint：完整请求地址，例如https://api.deepseek.com/chat/completionsCoMemBus 现在两种都支持。如果
COMEMBUS_LLM_ENDPOINT里只给了 base URL，客户端会自动补成 chat completions endpoint。然后运行：
也可以直接跑：
如果希望把 mock 和 remote 的输出都保存成可复现实验产物，并直接对比它们的报告内容，可以运行：
这个脚本至少会生成：
results/llm_mock_smoke.json如果远程环境变量已配置，还会额外生成：
results/llm_remote_smoke.json这些 JSON 可以直接查看：
root_causereportused_fallbacktotal_tokensroot_cause_correctDeepSeek 示例：
Qwen / DashScope 示例：
像
https://dashscope.aliyuncs.com/compatible-mode/v1/chat/completions这种已经是完整 endpoint 的地址，CoMemBus 不会重复拼接。判断真实接入成功的关键信号是：
provider=openai_compatibleused_fallback=false如果输出里出现：
provider=mockused_fallback=true就说明请求失败后已经自动回退到 mock。
注意：
默认 benchmark 不使用远程 LLM 的原因是：
因此真实 LLM 目前主要用于验证：
LLMReviewAgent是否能生成自然语言报告usage.total_tokens和 report 差异是否已经被保留下来bash scripts/run_remote_llm_smoke.sh的行为是：COMEMBUS_LLM_ENDPOINT、COMEMBUS_LLM_MODEL、COMEMBUS_LLM_API_KEY任意一个未配置，则输出SKIP: remote LLM env not configured并退出0Minimal CodeAct Sandbox
v0.12 新增了一个可选的最小 CodeAct sandbox，用来证明 CoMemBus 也能承载“结构化 facts -> 受限代码动作 -> 结构化结果返回”这一类工具调用。
当前设计原则是：
run_all.shimport os、open、eval、exec、compile、__import__multiprocessing.Process做轻量隔离stdout_truncated运行方式：
成功时会输出：
更完整的限制说明见：
Mock Multi-Agent Demo
examples/incident_diagnosis_mock/展示了 CoMemBus 在没有任何 LLM 框架的前提下，如何支撑多个独立 agent 进程协作：PlannerAgent负责创建并发布初始TaskState。LogAgent通过ObjectRef读取至少 8MB 的共享内存日志，并生成StatePatch。ConfigAgent处理小配置文本，并生成StatePatch。ReviewAgent读取最终TaskState并生成 root cause 报告。这个示例的重点不是“智能推理”，而是证明 CoMemBus 已经可以承载一个小型多 agent 工作流：
multiprocessing.ProcessAgentBusClient/AgentBusServerTaskState+StatePatchInMemoryStateManager会做版本校验并应用 patch运行这个 demo 时，日志里会展示：
expected_versionfactsCapability Discovery 与 Embedding Direct Exchange
当前 structured collaboration runner 会在每轮启动时构建一个
CapabilityRegistry，默认注册：PlannerAgentLogAgentConfigAgentReviewAgentMemoryAgentPlanner 不再通过硬编码字符串选择下游，而是按动作发现：
analyze_logcheck_configsummarize_result随后，
LogAgent在输出结构化日志摘要时还会生成轻量 hash embedding：EmbeddingState：包含摘要、向量、维度、metadataEmbeddingRef：包含 checksum、dim、vector_bytes、summary这样可以证明 CoMemBus 不只是在传文本、对象引用和状态补丁，也可以传递“轻量语义状态”。
Result Summary
运行：
或直接：
会读取存在的 benchmark CSV，并生成：
其中：
summary_report.md适合直接贴到实验记录或比赛材料里summary_metrics.json适合后续脚本复用、做自动报告或表格抽取如果某个 CSV 还不存在，脚本会跳过并在报告里写 warning，不会直接崩溃。
在 openEuler Docker 中运行
构建镜像：
运行测试：
如果想进容器手动执行 demo，可以这样运行：
进入容器后再执行：
设计说明
设计思路和后续扩展方向见 docs/mvp_design.md。
原生 openEuler 虚拟机验证步骤见：
交付材料
项目交付材料统一放置在
master分支根目录：演示视频
演示视频文件为
演示视频.mp4，可通过百度网盘下载：z680