Emdash、Orca 和 Avernet 都能让多个 Agent 同时工作但它们管理的不是同一种东西Emdash管理隔离的 Coding Task由人选择仓库、Worktree 和 CLI Agent。Orca在相似的开发工作台上增加 CLI 控制面让 Coordinator Agent 显式创建并监督 Coding Worker。Avernet管理长期存在的 Bot以及 Bot 之间的身份、关系、群组、会话和协作流程。因此前两者主要解决“怎样并行改代码”Avernet 解决“不同来源的 Bot 怎样被发现、组队并按固定流程协作”。如果需求是让三个 Coding Agent 分别修改同一仓库Avernet 不能替代 Worktree 工作台如果需求是让产品、研发、验证 Bot 长期在线并在一个组织网络中反复协作Emdash 和 Orca 又没有提供 Avernet 这层模型。核实基准Avernet 公开仓库提交e83d62262026-08-08。Bot 接入解决什么问题形式Bot 主动注册身份、能力name/summary/domains/skills/scopes、可见性和投递地址BCS 落库到bcs_bots维护bot_id → 实际 runtime 的映射。两条接入路径WebSocket/ws/bot直连或 HTTP Provider 模式bcs_providersbcs_provider_bot_bindings记录绑定。注册只让 BCS 知道“这个 Bot 是谁、能干什么、往哪投”不改写它的 System Prompt不接管它的 Skill、RAG 和记忆。公开代码已包含 Bot Registry、Discovery、Group Chat、Context Fusion、Message Routing、Friend 与 Visibility Control见 BCS README:L1-L16。README 把规模化后的四个瓶颈与四项基础设施成对给出瓶颈README 的对策机制是否解决Cannot find能力难以发现persistent agentsRegistry 让 Bot 成为可寻址对象discover(topic)匹配 name/summary/domains/skills/scopesfind_by_skills/find_by_domains/find_by_scopes按标签过滤候选查询区分发现与协作用途并传入好友关系见 bcs-app-bot/src/lib.rs:L213-L249部分。寻址是真的但能力是自述而非凭证Cannot align表面共识掩盖分歧structured coordination把验收标准写成明文criteriaLLM Judge 强制 JSON Schema 输出逐条返回checked_criteria{criterion, satisfied, evidence}outcome限定 enum、越界拒绝结果驱动approved/rejected分支未通过带retry_instruction重做是已实装Cannot run fast执行依赖人工传递governed execution上游artifact_text自动进入下游[Upstream Outputs]并投递取代人工复制粘贴人只在human_input节点按需介入是但编排能力受限Cannot retain知识未沉淀为组织能力compounding organizational memory单次 Run 落库节点产物全文node_runs.artifact_text、判定审计链collaboration_events.payload_json可按 run/node/attempt 回溯、流程定义快照以及可复用模板bcs_collaboration_templates带 visibility/owner/priorityregistry.yaml按 judge/branching/parallel/serial 打 tag部分。单次 Run 内成立跨任务记忆缺失四项里第二、三项是当前公开版最实的部分第一、四项都停在“形似”这一步。三处边界值得单独点出。能力描述不是凭证。scopes在全仓库只出现于find_by_*过滤器从不参与授权判断见 memory.rs:L818-L850。scopes: [production_db]等同于简历上写“精通 MySQL”BCS 不校验、不授予、不拦截。所以“找不到”只被改善为**“找得到但不保证找得对”**——既无能力验证也无效果评价Evaluation 标 Planned风险从“不知道有谁”转移为“不知道谁靠谱”。同理角色绑定只是把节点assignee_bot_id解析到具体 Bot节点 Prompt 仅含节点名、Run 输入、直接上游产物和instruction角色的description从不进入 Prompt见 runtime.rs:L922-L964。能力必须 Bot 自带Avernet 不赋能。记忆止于单次 Run。Context 与 Memory 均标 PlannedProvider 模式下会话上下文由对方平台按(provider_bot_ref, session_id)自行维护BCS 不下发完整历史本地配置store_messages false聊天消息默认不落库。真正可复利的资产其实是模板——一次评审的结论价值有限“这类事该按什么判据、哪里并行、哪里要人审”被固化成可复用流程才是组织能力。治理层尚未生效。权限只在协作图层面起作用把 Bot 加进 Session 时检查公开性、所有者或创建者关系、好友关系Hidden Bot 不能参与协作见 bcs-app-session/src/lib.rs:L370-L424。但这层不做能力隔离公开本地配置require_authentication falseSecurity、Governance 标 PlannedAudit 仍在进行中见 bcs-config-local.toml:L145-L147。README 承诺的 governed execution目前只有“流程受控”没有“权限受控”。与 Emdash、Orca 的差别由此确定后两者的核心对象是一次开发任务及其目录、分支和进程随任务结束消失Avernet 的核心对象是长期存在的 Bot一次协作只是把它临时绑定到某个角色。两种接入方式连接异构 BotAvernet 不要求所有 Bot 使用同一种 Agent Runtime。单个 Bot 进程可以通过 WebSocket/ws/bot接入完成握手、接收chat.send再用chat.event回传最终结果。协议同时支持群聊、mention、broadcast 和上下文注入最小交互可在 Bot 接入指南:L35-L97 核对。已经拥有 Bot 平台的团队可以使用 HTTP Provider 模式。BCS 保存 Provider 与 Bot 的注册关系并投递任务Provider 自己选择 Runtime、维护 Session 并异步回调结果BCS 不接管 Provider 实例也不会自动下发完整历史见 Bot Provider 接入:L8-L31。这两条路径说明 Avernet 更接近协作控制面而不是另一个 Agent 引擎。它连接 OpenClaw、本地 Bot 和已有平台但推理、工具调用以及平台内部调度仍由各自 Runtime 负责。从一次方案评审理解协作假设团队要评审“登录系统改造方案”已有项目负责人、架构、风险和业务价值四个 Bot 接入 BCS。接入只让 BCS 知道 Bot 的身份、能力和投递地址不会改写它们的 System Prompt也不会接管各自的 Skill、RAG 或长期记忆。Avernet 在这些 Bot 之上创建三个对象Group 保存长期团队和默认流程Session 隔离“登录系统改造”这一次评审Run 则是在该 Session 中执行一次 YAML 状态机。“多专家并行协同”模板先声明project_lead、solution_architect、risk_analyst和value_analyst四个逻辑角色再描述下面的步骤项目负责人整理评审范围 ↓ 技术可行性 / 风险 / 业务价值并行评审 ↓ 项目负责人汇总结果开始这次评审时调用方提交模板、本次输入和角色绑定例如bcs collaborate run review.yaml\--sessionreview-group:abcdef12\--bindingproject_leadbot-lead\--bindingsolution_architectbot-architect\--bindingrisk_analystbot-risk\--bindingvalue_analystbot-value\--input{proposal:登录系统改造方案}participant_bindings的作用是把逻辑角色解析成节点的实际执行者。绑定solution_architectbot-architect后BCS 会检查这个 Bot 是否属于当前 Group并把技术评审节点的assignee_bot_id设置为它绑定不会永久改变 Bot 的身份或人格。当前运行时还要求每个被节点引用的角色恰好绑定一个 Bot见 runtime.rs:L3730-L3819。Run 启动后BCS 先向bot-lead发送整理任务。协议会加入当前 Group、Session、参与者和“需要回复”等投递信息状态机再加入本次输入、直接上游产物和节点指令。入口节点收到的核心 Prompt 接近[State Machine Task] node_id: frame_review_scope display_name: 明确评审范围 [Input] {proposal:登录系统改造方案} [Upstream Outputs] (none) [Instruction] 请把用户请求整理成一份简短评审简报……这里有一个容易误解的边界角色的display_name和description目前不会自动变成完整的角色 Prompt。真正约束 Bot 行为的是节点instruction以及 Bot 自己原有的 System Prompt 和知识源码构造的节点 Prompt 只包含节点名称、Run 输入、直接上游产物和指令见 runtime.rs:L922-L964。bot-lead返回评审简报后BCS 将结果保存为该节点的artifact_text再把这份简报放进三个专家节点的[Upstream Outputs]并并行投递。三个专家各自使用自己的知识完成评审等三个节点都结束后汇总节点会收到三份产物并生成最终结果。模板中的并行分支、超时、尝试次数和汇聚节点可在 parallel-expert-review.yaml:L39-L136 核对。因此Avernet 当前沉淀的“知识”限于单次 Run 范围内但不止于产物本身节点产物全文落在bcs_state_machine_node_runs.artifact_textjudge 判定连同逐条判据与证据落在bcs_collaboration_events.payload_json可按 run / node / attempt 回溯“第一次为什么被拒、第二次为什么通过”本次所用流程定义另有快照表。Bot 的专业知识仍归各自 RuntimeSession 对话上下文由 Provider 按(provider_bot_ref, session_id)维护BCS 不会自动把完整历史发给每个 Bot。完整的跨任务 Context 与 Memory 仍是规划能力。需要人工决策时流程也可以插入human_input节点等待审核后再继续见 bot-human-bot-review.yaml:L17-L62。Orca 的 Coordinator 需要临场拆 Task、选择 Worktree 和 WorkerAvernet 的 Run 按预先写好的角色和状态图推进。前者适合目标仍需 Agent 动态拆解的编码任务后者适合团队已经知道“谁先做、谁并行、谁审核、谁汇总”的重复流程。三者按同一口径比较维度EmdashOrcaAvernet首要场景多 Coding Agent 并行开发多 Coding Agent 开发与 Coordinator-Worker 协调异构 Bot 的长期组织协作核心对象Task、Workspace、Worktree、ConversationWorktree、Terminal、Run、Task、DispatchBot、Relation、Group、Session、Run、Template隔离方式Git Worktree / 独立 WorkspaceGit Worktree / 独立终端可见性、关系和 Session 边界无能力隔离谁分配工作人人或调用 Orca CLI 的 Coordinator AgentYAML 状态机按角色绑定和节点流转Agent 间关系默认互不通信由人汇总Coordinator 监督 WorkerBot 可发现、建立关系、组群和交换上下文人机协作人创建任务、Review Diff/PR人监督Decision Gate 可等待决策human_input是工作流节点代码开发闭环Worktree、编辑器、Diff、PR、CIWorktree、编辑器、浏览器、Diff、PR、CI公开主线没有等价的 Worktree 与 PR 闭环接入范围本地或 SSH 上的 CLI Coding Agent本地或远程 CLI Coding AgentWebSocket Bot 与外部 HTTP Bot Provider当前成熟边界主流程以人管理任务为中心Orchestration 仍是实验能力公开协作运行时仍是 MVP这个表也给出直接的选型规则目标是隔离并行改代码、比较 Diff选 Emdash 或 Orca。需要 Coordinator Agent 调用工具创建并监督 Coding Worker优先看 Orca。需要长期 Bot 身份、发现、关系、群组和可复用协作模板再看 Avernet。把三者串起来也比三选一更合理Avernet 负责选角色和推进组织流程某个研发 Bot 再调用 Orca 或 Emdash 完成具体仓库里的编码任务。公开仓库目前没有提供这条现成集成但它符合三者各自的对象边界。公开版离“组织级平台”还有多远Avernet 已有可运行代码但 README 中的完整愿景也不能全部算作公开能力。首先README 将 Identity、Discovery、Relationships、Team Formation、Routing 和 Collaboration 标为 Available同时把 Context、Memory、广义 Orchestration、Evaluation、Evolution 标为 Planned见 README.zh-CN:L37-L82。这与源码中的状态机并不矛盾固定模板的协作运行时已经公开跨任务记忆、通用自主编排和持续评测仍未完整公开。其次当前状态机明确是 MVP。它只接受bot_task和human_input节点不支持action、output_contract、变量和事件图必须无环且只能有一个入口和一个终止节点guarded transition 也会被拒绝见 definition.rs:L112-L132、L157-L199、L298-L374。但这些限制不等于状态机只能线性或并行推进validate_requires的白名单已放行state_machine.node.judge和state_machine.outcome_transitionsjudge 驱动的 outcome 分支与带反馈重试已经实装配合max_attempts和 judge 超时公开版已具备质量门禁与条件分支而不只是“并行后汇总”。可靠性边界更值得注意。Provider 收到重复下行请求时必须自行按业务 ID 保证幂等并按(provider_bot_ref, session_id)保存上下文状态机的后续处理运行在当前 BCS 进程中进程退出后不会恢复尚未完成的处理见 Bot Provider 接入:L123-L130、L162-L173。本地配置虽然使用 SQLite但store_messages false不能据此声称聊天消息默认全部持久化见 bcs-config-local.toml:L1-L12。最后官方称内部部署已覆盖 12 个业务板块统计工作流完成率超过 90%但公开 README 同时说明 Demo 不展示完整的连接规模、权限隔离、审计、故障恢复和长期组织协作。这组数字应视为项目方自述不是公开仓库已经独立证明的能力见 README.zh-CN:L24-L41、L118-L127。需要单独区分的是权限它不是“仍是 MVP”而是公开部分尚未生效。公开本地配置的鉴权链为chain [local, session]且require_authentication false生产模板才是oauth_sessionrequire_authentication true见 bcs-config-local.toml:L145-L147。因此本地形态下真正被强制的只有协作图层面的一致性检查组织成员、好友、可见性、配额不含能力隔离。最终判断Avernet 与 Emdash、Orca 只有表层相似它们都把多个 Agent 放进一个可观察、可控制的系统。向下一层看前两者围绕一次 Coding Task 组织目录、进程和代码结果Avernet 围绕长期 Bot 组织身份、关系和协作方式。当前公开版最可信的能力是 BCS连接异构 Bot控制谁能发现和邀请谁再用群组、Session 与 YAML 状态机完成并行、汇聚、人工审核以及 judge 质量门禁与条件分支。它已经比“多 Bot 群聊”多了一层可执行结构但距离具备崩溃恢复、长期记忆、完整治理和自主编排的组织级 Agent 平台仍有明确缺口。所以Avernet 不是 Emdash 或 Orca 的升级版。它更像两者上方可能出现的一层组织控制面而这层控制面能否进入生产取决于公开版接下来怎样补齐恢复、审计、记忆和评测。