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 公开仓库提交
e83d6226，2026-08-08。
Bot 接入解决什么问题
形式 ：Bot 主动注册身份、能力（name/summary/domains/skills/scopes）、可见性和投递地址，BCS 落库到 bcs_bots，维护 bot_id → 实际 runtime 的映射 。两条接入路径：WebSocket /ws/bot 直连，或 HTTP Provider 模式（bcs_providers + bcs_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 agents | Registry 让 Bot 成为可寻址对象：discover(topic) 匹配 name/summary/domains/skills/scopes，find_by_skills/find_by_domains/find_by_scopes 按标签过滤；候选查询区分发现与协作用途并传入好友关系，见 bcs-app-bot/src/lib.rs:L213-L249 |
部分。寻址是真的，但能力是自述而非凭证 |
| Cannot align 表面共识掩盖分歧 | structured coordination | 把验收标准写成明文 criteria，LLM 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/priority，registry.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 均标 Planned；Provider 模式下会话上下文由对方平台按 (provider_bot_ref, session_id) 自行维护，BCS 不下发完整历史；本地配置 store_messages = false，聊天消息默认不落库。真正可复利的资产其实是模板------一次评审的结论价值有限，"这类事该按什么判据、哪里并行、哪里要人审"被固化成可复用流程，才是组织能力。
治理层尚未生效。 权限只在协作图层面起作用：把 Bot 加进 Session 时检查公开性、所有者或创建者关系、好友关系，Hidden Bot 不能参与协作，见 bcs-app-session/src/lib.rs:L370-L424。但这层不做能力隔离；公开本地配置 require_authentication = false，Security、Governance 标 Planned，Audit 仍在进行中，见 bcs-config-local.toml:L145-L147。README 承诺的 governed execution，目前只有"流程受控"，没有"权限受控"。
与 Emdash、Orca 的差别由此确定：后两者的核心对象是一次开发任务及其目录、分支和进程，随任务结束消失；Avernet 的核心对象是长期存在的 Bot，一次协作只是把它临时绑定到某个角色。
两种接入方式连接异构 Bot
Avernet 不要求所有 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 四个逻辑角色，再描述下面的步骤：
text
项目负责人整理评审范围
↓
技术可行性 / 风险 / 业务价值并行评审
↓
项目负责人汇总结果开始这次评审时，调用方提交模板、本次输入和角色绑定，例如：
bash
bcs collaborate run review.yaml \
--session "review-group:abcdef12" \
--binding "project_lead=bot-lead" \
--binding "solution_architect=bot-architect" \
--binding "risk_analyst=bot-risk" \
--binding "value_analyst=bot-value" \
--input '{"proposal":"登录系统改造方案"}'participant_bindings 的作用是把逻辑角色解析成节点的实际执行者。绑定 solution_architect=bot-architect 后，BCS 会检查这个 Bot 是否属于当前 Group，并把技术评审节点的 assignee_bot_id 设置为它；绑定不会永久改变 Bot 的身份或人格。当前运行时还要求每个被节点引用的角色恰好绑定一个 Bot，见 runtime.rs:L3730-L3819。
Run 启动后，BCS 先向 bot-lead 发送整理任务。协议会加入当前 Group、Session、参与者和"需要回复"等投递信息；状态机再加入本次输入、直接上游产物和节点指令。入口节点收到的核心 Prompt 接近：
text
[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_text，judge 判定连同逐条判据与证据落在 bcs_collaboration_events.payload_json（可按 run / node / attempt 回溯"第一次为什么被拒、第二次为什么通过"），本次所用流程定义另有快照表。Bot 的专业知识仍归各自 Runtime；Session 对话上下文由 Provider 按 (provider_bot_ref, session_id) 维护，BCS 不会自动把完整历史发给每个 Bot。完整的跨任务 Context 与 Memory 仍是规划能力。需要人工决策时，流程也可以插入 human_input 节点，等待审核后再继续，见 bot-human-bot-review.yaml:L17-L62。
Orca 的 Coordinator 需要临场拆 Task、选择 Worktree 和 Worker；Avernet 的 Run 按预先写好的角色和状态图推进。前者适合目标仍需 Agent 动态拆解的编码任务，后者适合团队已经知道"谁先做、谁并行、谁审核、谁汇总"的重复流程。
三者按同一口径比较
| 维度 | Emdash | Orca | Avernet |
|---|---|---|---|
| 首要场景 | 多 Coding Agent 并行开发 | 多 Coding Agent 开发与 Coordinator-Worker 协调 | 异构 Bot 的长期组织协作 |
| 核心对象 | Task、Workspace、Worktree、Conversation | Worktree、Terminal、Run、Task、Dispatch | Bot、Relation、Group、Session、Run、Template |
| 隔离方式 | Git Worktree / 独立 Workspace | Git Worktree / 独立终端 | 可见性、关系和 Session 边界（无能力隔离） |
| 谁分配工作 | 人 | 人，或调用 Orca CLI 的 Coordinator Agent | YAML 状态机按角色绑定和节点流转 |
| Agent 间关系 | 默认互不通信，由人汇总 | Coordinator 监督 Worker | Bot 可发现、建立关系、组群和交换上下文 |
| 人机协作 | 人创建任务、Review Diff/PR | 人监督，Decision Gate 可等待决策 | human_input 是工作流节点 |
| 代码开发闭环 | Worktree、编辑器、Diff、PR、CI | Worktree、编辑器、浏览器、Diff、PR、CI | 公开主线没有等价的 Worktree 与 PR 闭环 |
| 接入范围 | 本地或 SSH 上的 CLI Coding Agent | 本地或远程 CLI Coding Agent | WebSocket 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_transitions，judge 驱动的 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_session + require_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 的升级版。它更像两者上方可能出现的一层组织控制面，而这层控制面能否进入生产，取决于公开版接下来怎样补齐恢复、审计、记忆和评测。