ruflo-iot-cognitum 運(yùn)維參考指南Cognitum Seed 設(shè)備 5 級信任模型、工具目錄與后臺 Worker 調(diào)度【免費(fèi)下載鏈接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated項(xiàng)目地址: https://gitcode.com/GitHub_Trending/cl/ruflo導(dǎo)讀REFERENCE.md是 ruflo-iot-cognitum 插件面向運(yùn)維的按需加載參考手冊O(shè)perations Reference集中存放設(shè)備協(xié)調(diào)器 Agent 在 spawn 時按需讀取的信任等級表、工具目錄與后臺 Worker 調(diào)度表。本篇指南以該參考文檔為主體結(jié)合插件源碼v3/claude-flow/plugin-iot-cognitum/src下的生命周期服務(wù)、異常檢測服務(wù)、6 個 Worker 與固件編排狀態(tài)機(jī)深入展開幫助你理解Cognitum Seed 設(shè)備的 5 級信任模型與 6 分量信任評分公式、完整的cognitum-iotCLI 工具目錄、后臺 Worker 的周期與事件語義以及這套Agent 提示詞瘦身 參考文檔外置的 token 優(yōu)化設(shè)計對應(yīng) ADR-098。一、這份 Reference 是什么Agent 提示詞的按需加載搭檔1.1 設(shè)計動機(jī)把表格從 Agent 提示詞里搬出來ruflo-iot-cognitum 插件的 Agent 提示詞被刻意保持精簡≤ 60 行依據(jù)是 ADR-098 Part 2Plugin Capability Sync Token Optimization。該 ADR 的審計結(jié)論指出ruflo-iot-cognitum的device-coordinator提示詞曾因內(nèi)聯(lián)信任等級表達(dá)到約 80 行——每行約 12 token每次 spawn 僅 Agent 定義就要消耗約 1000 token乘以 spawn 頻率就是可觀的運(yùn)行時開銷。解決方案正是本文件將信任等級表、工具目錄、后臺 Worker 調(diào)度表等冷數(shù)據(jù)外置到REFERENCE.mdAgent 只在真正需要執(zhí)行某項(xiàng)操作時才讀取該文件。device-coordinatorAgent 提示詞中明確寫道完整的工具目錄與后臺 Worker 調(diào)度表位于 REFERENCE.md——當(dāng)你需要職責(zé)之外的操作時讀取它并標(biāo)注該做法每次 spawn 節(jié)省約 40% token見 device-coordinator.md。1.2 使用方式人類運(yùn)維直接閱讀本參考掌握全部運(yùn)維命令與調(diào)度語義Agent 運(yùn)行時由device-coordinator、fleet-manager、telemetry-analyzer、witness-auditor四個 Agent 按需引用契約保障冒煙腳本 的第 12 項(xiàng)檢查要求REFERENCE.md存在且非空確保參考文檔不會因重構(gòu)而丟失。二、5 級信任模型Trust Tiers2.1 等級表設(shè)備從注冊到獲得完整艦隊(duì)操作權(quán)限共經(jīng)歷 5 個信任等級LevelNameScore rangeCapabilities0UNKNOWN0.0–0.19Discovery only僅發(fā)現(xiàn)1REGISTERED0.2–0.39Status, identity queries狀態(tài)與身份查詢2PROVISIONED0.4–0.59Telemetry ingest, vector store遙測攝取、向量庫3CERTIFIED0.6–0.79Mesh participation, firmware deploy網(wǎng)格參與、固件部署4FLEET_TRUSTED0.8–1.0Full fleet operations, witness signing完整艦隊(duì)操作、見證簽名2.2 升降級規(guī)則升級要求設(shè)備在全部 6 個信任分量上同時達(dá)到下一等級的下界降級則是單分量懸崖機(jī)制——任意一個分量不達(dá)標(biāo)例如固件版本落后即整體下降一個等級直到缺陷修復(fù)為止。2.3 源碼級實(shí)現(xiàn)證據(jù)等級枚舉定義在 device-trust-level.tsexport enum DeviceTrustLevel { UNKNOWN 0, // Seen on the network but not paired REGISTERED 1, // Paired, identity verified via Ed25519 PROVISIONED 2, // Firmware verified, policies applied, security zone assigned CERTIFIED 3, // Extended uptime, clean witness chain, anomaly-free history FLEET_TRUSTED 4, // Fleet-level attestation across multiple devices }注意源碼中的枚舉注釋與參考文檔的語義完全對應(yīng)REGISTERED意味著已配對且 Ed25519 身份驗(yàn)證通過PROVISIONED意味著固件已驗(yàn)證、策略已應(yīng)用、安全分區(qū)已分配——這與 CLI 命令中pair提升信任等級、unpair回退等級的行為一致。分值到等級的映射實(shí)現(xiàn)在 device-lifecycle-service.ts 的evaluateTrustLevel()evaluateTrustLevel(score: DeviceTrustScore): DeviceTrustLevel { if (score.overall 0.3) return DeviceTrustLevel.UNKNOWN; if (score.overall 0.5) return DeviceTrustLevel.REGISTERED; if (score.overall 0.7) return DeviceTrustLevel.PROVISIONED; if (score.overall 0.85) return DeviceTrustLevel.CERTIFIED; return DeviceTrustLevel.FLEET_TRUSTED; }一個值得注意的細(xì)節(jié)CERTIFIED的臨界值在參考文檔中標(biāo)注為 0.6–0.79而源碼中FLEET_TRUSTED的下界為0.85而非 0.8。也就是說即使綜合評分達(dá)到 0.8若未超過 0.85設(shè)備仍停留在CERTIFIED——這一閾值差異正是文檔 2.2 節(jié)必須達(dá)到下一等級下界規(guī)則的量化體現(xiàn)。三、信任評分公式逐分量拆解3.1 完整公式trustScore 0.30 · pairingIntegrity # mTLS chain valid, expected fingerprint 0.15 · firmwareCurrency # current firmware vs latest available 0.20 · uptimeStability # rolling 24h uptime ratio 0.15 · witnessIntegrity # Ed25519 chain has no gaps 0.10 · anomalyHistory # 1.0 minus normalized anomaly count 0.10 · meshParticipation # active edges in the mesh topology3.2 各分量含義分量權(quán)重評估對象滿分條件pairingIntegrity0.30mTLS 證書鏈有效、指紋符合預(yù)期配對完成即滿分 1.0firmwareCurrency0.15當(dāng)前固件 vs 最新可用版本固件最新uptimeStability0.20滾動 24h 在線率持續(xù)在線witnessIntegrity0.15Ed25519 見證鏈無缺口見證鏈連續(xù)無 gapanomalyHistory0.10歸一化異常計數(shù)取反無異常記錄meshParticipation0.10網(wǎng)格拓?fù)渲械幕钴S邊網(wǎng)格參與充分3.3 關(guān)鍵失效場景witness verify 失敗參考文檔明確了一條硬規(guī)則設(shè)備一旦witness verify失敗witnessIntegrity立即歸零——該單點(diǎn)失敗將設(shè)備綜合評分上限封死在 0.85必然從FLEET_TRUSTED強(qiáng)制降級。這與 2.2 節(jié)的單分量懸崖機(jī)制互為印證witnessIntegrity權(quán)重 0.15歸零后理論最高分 1 ? 0.15 0.85恰好低于FLEET_TRUSTED的源碼閾值 0.85嚴(yán)格小于因此必然被擋在最高等級之外。3.4 源碼中的評分實(shí)現(xiàn)device-lifecycle-service.ts 的computeTrustScore()是公式的落地實(shí)現(xiàn)const pairingIntegrity paired ! undefined ? (paired ? 1.0 : 0.0) : (device.trustScore?.components?.pairingIntegrity ?? 0.0); const firmwareCurrency 1.0; // version comparison TBD const uptimeStability Math.min(1.0, uptimeSecs / SEVEN_DAYS_SECS); // 604_800s const witnessIntegrity Math.min(1.0, witnessDepth / EXPECTED_WITNESS_DEPTH); // 10_000 const anomalyHistory 1.0; const meshParticipation 0.5; const overall 0.3 * pairingIntegrity 0.15 * firmwareCurrency 0.2 * uptimeStability 0.15 * witnessIntegrity 0.1 * anomalyHistory 0.1 * meshParticipation;實(shí)現(xiàn)細(xì)節(jié)可以印證文檔公式uptimeStability以 7 天604,800 秒為滿額窗口計算uptime_secs / 604800并鉗制到 1.0對應(yīng)文檔rolling 24h uptime ratio的語義擴(kuò)展實(shí)現(xiàn)取 7 天窗口witnessIntegrity以見證鏈深度 10,000 為期望滿額min(1.0, witnessDepth / 10000)pair成功后pairingIntegrity置 1.0unpair后置 0.0——對應(yīng)等級表中配對狀態(tài)對能力門的直接控制從源碼結(jié)構(gòu)看firmwareCurrency、anomalyHistory目前在服務(wù)中為占位常量注釋標(biāo)明version comparison TBD、No anomaly detection yet實(shí)際完整評估由固件編排與異常檢測服務(wù)在 Worker 鏈路中承擔(dān)讀者可據(jù)此判斷當(dāng)前版本的評分邊界。四、設(shè)備協(xié)調(diào)器工具目錄cognitum-iot CLI4.1 默認(rèn)端點(diǎn)未指定端點(diǎn)時默認(rèn)端點(diǎn)為http://169.254.42.1/——Cognitum Seed 的 link-local USB Ethernet 地址USB-C 直連、免認(rèn)證。LAN 場景下則為https://169.254.42.1:8443需要 bearer token 進(jìn)行狀態(tài)變更類操作。4.2 完整命令目錄# Lifecycle生命周期 npx -y -p claude-flow/plugin-iot-cognitumlatest cognitum-iot register [endpoint] npx -y -p claude-flow/plugin-iot-cognitumlatest cognitum-iot pair device-id npx -y -p claude-flow/plugin-iot-cognitumlatest cognitum-iot unpair device-id npx -y -p claude-flow/plugin-iot-cognitumlatest cognitum-iot remove device-id # Inspection巡檢 npx -y -p claude-flow/plugin-iot-cognitumlatest cognitum-iot status device-id npx -y -p claude-flow/plugin-iot-cognitumlatest cognitum-iot list npx -y -p claude-flow/plugin-iot-cognitumlatest cognitum-iot mesh device-id # Witness audit見證審計 npx -y -p claude-flow/plugin-iot-cognitumlatest cognitum-iot witness device-id npx -y -p claude-flow/plugin-iot-cognitumlatest cognitum-iot witness verify device-id4.3 完整的 25 個子命令面在插件命令文件 commands/iot.md 中/iot命令覆蓋 25 個子命令主題除上述生命周期/巡檢/見證外還包括分組子命令遙測ingest device-id、baseline device-id [--compute]、anomalies device-id、query device-id --vector [...] --k N艦隊(duì)fleet create --name NAME、fleet list、fleet add fleet-id device-id、fleet remove fleet-id device-id、fleet delete fleet-id固件firmware deploy fleet-id --version VER、firmware advance rollout-id、firmware rollback rollout-id、firmware status rollout-id、firmware list運(yùn)維擴(kuò)展health device-id、trust device-idquery的--vector參數(shù)要求 JSON 數(shù)字?jǐn)?shù)組源碼 cli-commands.ts 中parseVector()會嚴(yán)格校驗(yàn)非數(shù)組或含非數(shù)字元素即拋錯--vector must be a JSON array of numbers確保向量維度合法性后再執(zhí)行 k-NN 搜索。4.4 與 Agent/Skill 的協(xié)同工具目錄與 Agent 職責(zé)一一對應(yīng)device-coordinator負(fù)責(zé)生命周期與信任評分對應(yīng) Skill iot-registerfleet-manager負(fù)責(zé)艦隊(duì)與固件對應(yīng) iot-fleet、iot-firmwaretelemetry-analyzer負(fù)責(zé)異常分析對應(yīng) iot-anomalieswitness-auditor負(fù)責(zé)見證鏈驗(yàn)證對應(yīng) iot-witness-verify。四個 Agent 的模型分層為前三者為sonnetwitness-auditor為haiku純校驗(yàn)型任務(wù)低成本模型即可勝任。五、后臺 Worker 調(diào)度表5.1 調(diào)度總覽插件被宿主守護(hù)進(jìn)程加載后即派發(fā) 6 個后臺 Worker可通過ruflo hooks worker list與ruflo hooks worker status驗(yàn)證運(yùn)行狀態(tài)WorkerIntervalEvent emittedDescriptionHealthProbeWorker30siot:device-offlineProbes device status, detects offlineTelemetryIngestWorker60s—Ingests telemetry vectorsAnomalyScanWorker120siot:anomaly-detectedRuns Z-score anomaly detectionMeshSyncWorker120siot:mesh-partitionDetects mesh topology partitionsFirmwareWatchWorker300siot:firmware-mismatchDetects firmware version changesWitnessAuditWorker600siot:witness-gapAudits witness chain epoch continuity5.2 源碼實(shí)現(xiàn)佐證HealthProbeWorkerhealth-probe-worker.ts默認(rèn)intervalMs30,000遍歷coordinator.listDevices()逐臺探測維護(hù)lastKnownStatus狀態(tài)表僅在狀態(tài)翻轉(zhuǎn)時觸發(fā)onDeviceOffline/onDeviceOnline回調(diào)避免重復(fù)告警探測異常統(tǒng)一走onProbeError。這就是iot:device-offline事件的產(chǎn)生源頭。WitnessAuditWorkerwitness-audit-worker.ts默認(rèn)intervalMs600,00010 分鐘按 epoch 升序排序后逐對檢查entry[i].epoch entry[i-1].epoch 1發(fā)現(xiàn)actual expected即回調(diào)onGapDetected(deviceId, fromEpoch, toEpoch)——即iot:witness-gap事件載荷為{ deviceId, fromEpoch, toEpoch }。事件載荷匯總來自 fleet-manager.mdEventSource WorkerPayloadiot:mesh-partitionMeshSyncWorker (120s){ deviceId, peerCount: 0 }iot:firmware-mismatchFirmwareWatchWorker (300s){ deviceId, oldVersion, newVersion }iot:witness-gapWitnessAuditWorker (600s){ deviceId, fromEpoch, toEpoch }iot:anomaly-detectedAnomalyScanWorker (120s){ deviceId, anomalies[] }5.3 見證鏈驗(yàn)證算法witness-verification-service.ts 實(shí)現(xiàn)了見證鏈完整性評分integrityScore max(0, 1 ? gapRatio) × (hashValid ? 1 : 0.5)其中g(shù)apRatio為缺口 epoch 數(shù)占鏈長的比例哈希鏈校驗(yàn)通過則乘 1、失敗乘 0.5。整體流程為拉取鏈 → 按 epoch 升序排序 → 檢查 epoch 連續(xù)性 → 校驗(yàn)previous_hash鏈接 → 輸出完整性評分與缺口報告。六、與信任/異常/網(wǎng)格/固件相關(guān)的深度機(jī)制6.1 異常檢測Z-score 復(fù)合評分telemetry-analyzer采用min(1, meanZ/3)的復(fù)合評分分類規(guī)則TypeDetection RuleTypical CausespikemaxZ 5Sudden sensor failureflatlineall zero low ZSensor disconnecteddrift1-2 dimensions high ZGradual calibration lossoscillationalternating high/lowFeedback looppattern-breakmoderate Z, multiple dimsEnvironmental changecluster-outlier50% dimensions high ZMulti-sensor failure源碼 anomaly-detection-service.ts 定義了三個關(guān)鍵閾值anomalyThreshold默認(rèn) 0.7高于此值判定為異常、quarantineThreshold默認(rèn) 0.9觸發(fā)隔離動作、baselineWindowSize默認(rèn) 100基線計算窗口。對應(yīng)動作分級score 0.7 記錄日志、0.7–0.9 告警、 0.9 隔離?；€通過窗口內(nèi)逐維度求均值與標(biāo)準(zhǔn)差meanVector/stdVector計算。6.2 SONA 神經(jīng)學(xué)習(xí)集成sona-integration-service.ts 將異常模式以anomaly:{type}:{deviceId}鍵寫入 SONA 模式庫供跨設(shè)備關(guān)聯(lián)漂移向量記錄為baseline-shift:{deviceId}用于預(yù)測性維護(hù)遙測軌跡以獎勵式學(xué)習(xí)異常為負(fù)、正常為正。minConfidence默認(rèn) 0.6predictAnomalyRisk()在置信度超閾值時返回風(fēng)險類型。6.3 固件發(fā)布狀態(tài)機(jī)pending → canary → rolling → complete ↘ rolled-back ↙canary部署到ceil(deviceCount × canaryPercentage/100)臺設(shè)備rolling若 canary 階段異常評分低于回滾閾值則向其余設(shè)備鋪開rolled-back異常閾值被突破或人工命令觸發(fā)強(qiáng)制回滾。源碼 firmware-orchestration-service.ts 將狀態(tài)機(jī)擴(kuò)展為pending | canary | rolling | complete | rolled-back | failed六態(tài)canary 數(shù)量取max(1, ceil(N × percentage))回滾閾值與異常評分通過getDeviceAnomalyScore()動態(tài)評估。配套的艦隊(duì)默認(rèn)策略來自 fleet-manager.mdPolicyDefaultFirmware channelstableCanary percentage10%Canary duration30 minutesRollback threshold0.8 anomaly scoreTelemetry interval60 secondsTelemetry retention30 daysOffline threshold10 minutesMin uptime95%Max anomalies36.4 網(wǎng)格與數(shù)據(jù)平面MeshService 聚合 AP 狀態(tài)、自動組網(wǎng)、集群健康與對端列表為拓?fù)淇煺者b測向量經(jīng) agentdb-telemetry-repository.ts 持久化到 AgentDBiot-telemetry命名空間HNSW 索引參數(shù) M16、efConstruction200支持 k-NN 相似度檢索。七、命名空間與生態(tài)關(guān)聯(lián)7.1 AgentDB 命名空間協(xié)調(diào)插件持有 5 個 AgentDB 命名空間全部符合 ruflo-agentdb ADR-0001 命名約定plugin-stem-intentkebab-caseNamespacePurposeiot-devicesDevice trust history per Cognitum Seediot-telemetryTelemetry vectors (HNSW: M16, efConstruction200)iot-telemetry-anomaliesDetected anomalies tagged by type remedial actioniot-anomaliesSkill-level anomaly index上述命名空間的別名iot-auditWitness-chain gap records保留命名空間pattern、claude-memories、default不得被遮蔽。7.2 與聯(lián)邦信任模型的平行結(jié)構(gòu)本插件的 5 級設(shè)備信任模型UNKNOWN → REGISTERED → PROVISIONED → CERTIFIED → FLEET_TRUSTED與 ruflo-federation 5 級信任模型UNTRUSTED → VERIFIED → ATTESTED → TRUSTED → PRIVILEGED形態(tài)一致評分驅(qū)動晉升、能力門控的原則相同只是作用面不同IoT 設(shè)備 vs 聯(lián)邦對等節(jié)點(diǎn)、命名不同。7.3 安裝與驗(yàn)證# 安裝插件 claude --plugin-dir plugins/ruflo-iot-cognitum # 契約驗(yàn)證ADR-0001 定義的 smoke-as-contract 門禁12 項(xiàng)結(jié)構(gòu)檢查 bash plugins/ruflo-iot-cognitum/scripts/smoke.sh # 預(yù)期輸出: 12 passed, 0 failed冒煙腳本 的 12 項(xiàng)檢查覆蓋插件版本與關(guān)鍵詞、5 技能 4 Agent 1 命令存在性、/iot子命令主題、6 個 Worker 文檔化、5 級信任模型、6 類異常類型、固件狀態(tài)機(jī)、v3.6 CLI 版本鎖定、命名空間協(xié)調(diào)、聯(lián)邦信任模型交叉引用、ADR-0001 狀態(tài)、REFERENCE.md非空——其中最后一項(xiàng)正是本文檔的契約保障。八、小結(jié)REFERENCE.md通過冷數(shù)據(jù)外置策略把運(yùn)維表格從 Agent 提示詞中剝離配合 6 個后臺 Worker 的事件驅(qū)動模型形成了一套完整的 Cognitum Seed 設(shè)備治理閉環(huán)注冊發(fā)現(xiàn)HealthProbe/注冊→ 信任評分6 分量公式→ 等級門控5 級升降級→ 遙測分析Z-score SONA→ 固件演進(jìn)canary/rolling/rollback→ 溯源審計Ed25519 見證鏈。運(yùn)維人員可直接沿用本文檔的工具目錄與調(diào)度表進(jìn)行設(shè)備艦隊(duì)管理開發(fā)者則可在v3/claude-flow/plugin-iot-cognitum/src中找到每個表項(xiàng)對應(yīng)的服務(wù)與 Worker 實(shí)現(xiàn)作為深入定制與二次開發(fā)的起點(diǎn)?！久赓M(fèi)下載鏈接】ruflo The original agent meta-harness. Deploy intelligent multi-player swarms, coordinate autonomous workflows, and build conversational AI systems. Features adaptive memory, self-learning intelligence, RAG integration, and native Claude Code / Codex / Hermes and many more Integrated項(xiàng)目地址: https://gitcode.com/GitHub_Trending/cl/ruflo創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考