Cumora — Agent Team Chat Runtime
Cumora — Agent Team Chat Runtime
一句话结论
yetone/cumora 是一个把 AI agent 放进团队协作空间的 chat/work board runtime：人和 agent 共享 roster、DM、群聊、看板、日历与邮件入口；agent 可以运行在 Cumora Cloud 的 per-agent pod，也可以用 BYOA daemon 接入本地 Claude Code / Codex。它值得进入 llm-wiki 的原因不是“又一个聊天应用”，而是提供了 多 agent 协作时的协调边界、freshness gate、claim arbitration 和 BYOA/云端双运行路径，这些都直接关联 Loop-Engineering、Harness-Engineering 与 Context-Engineering。
为什么对用户重要
用户的 Hermes / llm-wiki 目前主要是单 agent cron：每日雷达发现、评分、入库、更新索引并报告。但当任务扩展到“多个子代理分别做搜索、阅读、写页、校验、发布”时，核心问题不再只是工具调用，而是 多个 agent 如何共享上下文、避免互相覆盖、申领任务、处理 stale reply、记录成本和保留人类可审计协作面。Cumora 的 README 把这些问题放到了产品/runtime 层：同一房间里的 agent 回答前要通过 seen-cursor freshness gate，真实工作单元需要 atomic claim，模型调用进入统一 cost ledger。
这给 llm-wiki 的启发是：未来如果把每日雷达拆成多 agent，不应只让子代理并发写 markdown；需要一个 work-item/claim/receipt 层，至少记录“谁认领了哪个候选、基于哪个上下文版本、产出了哪些文件、是否被 verifier 接受”。
机制 / 一阶原理
1. Agent 作为团队成员，而不是隐藏后台函数
Cumora 的关键设计是让 agent 使用与人相同的协作对象：DM、group conversation、Kanban、calendar、email。这意味着 agent 的状态和行动暴露在团队协作界面里，而不是只作为某个后端 pipeline 的不可见函数运行。对长期 agent loop 来说，可见协作面本身就是 harness：它让任务申领、等待、人类介入和错误复盘有一个公共事实表。
2. 多 agent 协调需要 freshness 与 claim
多 agent 最容易出现的问题是：A 读取旧上下文准备回复时，B 或人类已经推进了对话；如果 A 继续执行，就会产生 stale action。Cumora 用 seen-cursor freshness gate 将陈旧回复 HOLD，并把较新的消息展示给 agent 重新决定；同时用 atomic claims 避免多个 agent 争抢同一个真实工作单元。这是 Harness-Engineering 中“流程约束必须落到 runtime”的一个具体样本。
3. BYOA 把能力边界从平台下沉到用户机器
Cumora 的 BYOA 让本地 Mac/VPS 运行 daemon，并把本地 Claude Code / Codex 作为 brain；服务端不接触 provider keys。这个模式对个人 Hermes 很重要：很多高能力工具链、安全凭证和本地文件只能在用户机器上运行，平台应只承载协调与 UI，而不是拥有所有执行权限。代价是 BYOA daemon 成为新的供应链/权限边界，需要明确安装、更新、日志和最小权限策略。
与已有 wiki 概念的关系
- 对 Loop-Engineering：Cumora 是“协作空间即 loop runtime”的样本，强调长期 agent loop 需要 conversation/work-item/cost/memory 的共享状态。
- 对 Harness-Engineering：freshness gate、atomic claim、triage gate、per-agent pod/BYOA 隔离都是 harness 控制点。
- 对 Context-Engineering：agent 看到的上下文不只是 prompt，还包括房间历史、任务看板、邮件、日历、记忆和本地 workspace；这些 context provider 需要版本和可见边界。
- 对 External-Agent-Skills-Design-Patterns：BYOA + local CLI 说明 skill/runtime 可以远程协调、本地执行，但必须把权限、密钥和审计分开。
对 Hermes / llm-wiki 的可执行启发
- 为未来多 agent ingest 增加 work-item 语义：候选源应先变成任务卡，带 claim owner、状态、上下文快照、产物路径和 verifier verdict，避免多个子代理重复写页或覆盖概念页。
- 给 cron 报告增加 stale-context 防护：如果
_index.md或目标页面在本轮执行中被其他进程更新，写入前应重新读取或 HOLD，而不是基于旧 offset patch。 - 区分协调平面与执行平面：Feishu/Obsidian/网页 UI 可以是协调平面；真正写文件、跑测试、访问凭证的执行仍在本机 Hermes，减少平台持钥风险。
- 把 cost ledger 当成 loop 质量信号：多 agent radar 不能只统计“新增页面数”，也应统计搜索/API/模型/工具成本与被拒候选数，防止日更制造低价值噪音。
失败模式 / 边界条件
- 协作 UI 不等于可靠 harness：如果 claim/freshness/triage 只在应用层弱实现，仍可能出现 race condition 或重复执行；关键任务需要文件锁、事务或外部 verifier。
- BYOA 权限扩大：本地 daemon 能访问用户机器与 CLI subscription，安装和自动更新风险高于纯 SaaS；不应在无人 cron 中自动安装运行。
- 聊天空间可能放大噪音：多 agent 同室容易产生讨论泡沫；需要明确任务卡、done criteria 和自动静默规则。
- README 级验证有限：本次只读取 README，没有本地部署 Cumora；架构和机制判断为 medium confidence。
深度判断
本次将 Cumora 晋升为正式 source page，因为它满足三个价值触发：提供可复用的 multi-agent coordination workflow；能改进用户未来 Hermes/llm-wiki 多 agent radar 的 claim/freshness/receipt 设计；并澄清“agent 协作产品”与“agent runtime harness”之间的边界。它不是今天的工具推荐，原因是尚未本机运行验证，且 BYOA/云端 pod 都涉及较大的权限与运维面。
写入记录
- 2026-08-19 09:00 CST：新增 Cumora 来源页，沉淀 agent team chat、freshness gate、atomic claim、BYOA、本地/云端执行平面分离及对 llm-wiki 多 agent radar 的启发。