OpenRig Pod内边与跨Pod边：两种作用域的Agent关系拓扑实战对比

OpenRig Pod内边与跨Pod边两种作用域的Agent关系拓扑实战对比【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址: https://gitcode.com/GitHub_Trending/op/openrigOpenRig是一个开源的多智能体协作工具Multi-agent harness能把 Claude Code 和 Codex 组成同一支可管理的 Agent 团队。本文将带你实战对比 OpenRig 拓扑中的两种Agent 关系边Pod 内边pod-local edges与跨 Pod 边cross-pod edges——搞懂它们你就掌握了定义 Agent 团队关系的完整方法。为什么 Agent 团队需要边来描述关系在 OpenRig 里一支团队用 YAML 声明叫做RigSpec。它的层级是Rig机架→ Pod小组→ Seat席位如dev-ownerfirst-project→ 边Edge边就是连接两个席位的关系声明谁委托谁干活、谁盯着谁的产出、谁是平级搭档。边不会替你发消息但它是团队的组织架构图——决定了启动顺序、可视化拓扑也告诉每个 Agent 自己在团队里跟谁有关系。下面这张动图展示了 OpenRig 中多个 Agent 协同工作的真实画面从拓扑图到席位表格再到单个 Agent 详情。两种作用域一句话分清 Pod 内边和跨 Pod 边这是本文的核心对比官方参考文档在 edge-types.md维度Pod 内边pod-local跨 Pod 边cross-pod连接对象同一 Pod 内的成员不同 Pod 的成员写法直接写成员 ID如from: qa必须带 Pod 前缀如from: orch.lead声明位置写在 Pod 自己的edges:字段里写在 Rig 顶层的edges:字段里典型用途组内分工开发↔QA、评审搭档组间协作编排组派活给开发组校验规则两端成员必须属于同一个 Pod两端必须分属不同的 Pod同 Pod 请用内边语法一句话记忆组内连线写在组里跨组连线写在顶层且跨组连线必须带组名.前缀。用 demo 机架看懂两种边的完整写法OpenRig 自带的演示机架 demo/rig.yaml 是一个绝佳样本——4 个 Pod编排、开发、评审、基础设施里同时存在两种边# Pod 内边写在 dev 这个 Pod 内部 pods: - id: dev members: [ { id: impl }, { id: qa } ] edges: - kind: can_observe from: qa # 组内成员直接写 ID to: impl - id: rev members: [ { id: r1 }, { id: r2 } ] edges: - kind: collaborates_with from: r1 # 两个评审席互为搭档 to: r2 # 跨 Pod 边写在 Rig 顶层带 pod.member 前缀 edges: - kind: delegates_to from: orch.lead # 编排组的 lead to: dev.impl # 开发组的 impl对照这个例子三类典型组内关系都出现了QA 观察开发者can_observe、两位评审平级搭档collaborates_with、以及编排 lead 跨组委托开发delegates_to。再看一个流水线型机架 conveyor它的 4 个 Pod 各自edges: []组内无边所有关系全靠跨 Pod 边串成一条接力链intake.lead → plan.planner → build.builder → review.reviewer delegates_to 链 review.reviewer ⇢ build.builder / intake.lead can_observe 回看设计启示Pod 是共享上下文和指引的边界。如果两个 Agent 需要频繁共享 SOP、文化文件就把它们放进同一个 Pod 用内边如果只是跨职能派活就用顶层跨 Pod 边。边的实战效果启动顺序、拓扑图、身份投影很多人以为边会强制执行通信其实当前运行时里边的作用非常克制详见 edge-types.md只有delegates_to和spawned_by影响启动顺序。delegates_to要求委托方先启动spawned_by要求父席先启动。系统对依赖图做拓扑排序——出现环就会启动失败这是边最硬的运行时行为。所有边都会渲染进 TUI 拓扑图。Pod 内边画在虚线 Pod 框内部跨 Pod 边横跨各组连接如下图product / development / QA 三个 Pod 分组清晰可见边会投影到 Agent 身份。rig whoami --json输出中能看到自己的edges.outgoing/edges.incoming让 Agent 知道自己在拓扑里与谁相连——但由 Agent 自行理解运行时不强制。边不路由消息、不做权限控制。rig send可以发给任何席位与边无关。边的语义是设计意图不是访问控制。5 种边类型速查如何为每种关系选对类型边类型何时使用影响启动顺序delegates_toA 把活派给 B最常见✅ 先启动spawned_byB 由 A 生成层级启动关系✅ 先启动can_observeA 审查/观察 B 的产出❌collaborates_withA、B 平级协作❌escalates_toA 遇到搞不定的问题上报 B❌拿不准时按顺序问自己来自官方文档的建议一个给另一个派活→delegates_to一个盯着另一个的产出→can_observe两者是平等的→collaborates_with一个向上级汇报问题→escalates_to一个生成了另一个→spawned_by不确定就用can_observe——它只记录关系、不暗示流程方向也不影响启动顺序是最安全的默认值。上手建议从 starter rig 开始观察两种边推荐两条起步路径小团队起步rig up first-project两个席位或四席混合运行时Claude Code Codex的conveyor先观察跨 Pod 接力链如何工作。研究现成样例用rig specs ls浏览内置机架库重点看 adversarial-review纯跨 Pod 委托与 pm-team组内delegates_toescalates_to双向搭配 跨 Pod 观察边。完整的字段语法与校验规则可查 rig-spec.mdPod 的上下文注入机制见 agent-startup-guide.md。小结Pod 内边写在 Pod 的edges:里、用裸成员 ID描述组内分工跨 Pod 边写在 Rig 顶层、用pod.member全限定名描述组间协作只有delegates_to/spawned_by有真实运行时行为启动顺序 成环即失败其余边是设计意图的显式记录边不是权限也不是消息路由——团队真正的通信靠rig send而边让团队结构对人和 Agent 都可见、可恢复、可演进。【免费下载链接】openrigMulti-agent harness that runs Claude Code and Codex together as one system项目地址: https://gitcode.com/GitHub_Trending/op/openrig创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考