企业官网建设流程全解析

• 人工智能
• AI Agent
• 多智能体
• Agent 编排
• 代码智能体
• CLI

本文围绕 OpenRig 仓库中product-teamrig 规格随附的编排操作手册（Orchestration Craft）展开。它是面向「两个编排者 + 开发/QA/设计 + 两名独立评审」的多席位 Agent 团队的操作纪律：当你在另一个席位上行动时——读取它的窗格、观察它的进展、对它发起干预——需要遵守怎样的判读规则与最小代价原则。读完本文，你将掌握幽灵文本与已提交文本的可靠判别法、不烧掉共享算力配额的观察节奏、三种干预手段（唤醒 / 重聚焦 / 检查点）的适用边界，以及把实践中发现的纪律沉淀回仓库默认值（chain-file）的完整路径。

一、先理解这套文件的定位：CRAFT 文件是「行动当下」的提醒

ORCHESTRATION-CRAFT.md位于packages/daemon/specs/rigs/preview/product-team/topology/rig/，是随product-teamrig 规格「出厂」的默认文件之一。它所属的体系叫chain-file（链式文件），其唯一规则是：同一文件名，在树的每一层都相同——读者从自己所在的位置向根方向行走，逐层读取同名文件即可完成定向，不需要任何指针或分叉（见 docs/reference/chain-file-convention.md）。

在这个product-team示例 rig 中，chain-file 家族按拓扑树海拔分层：

文件头部注释说得很清楚：跨 pod 的战术提醒留在RIG 海拔；pod 目录属于某个有界子团队的自有上下文；而这份 Orchestration Craft 是「你在另一个席位上行动的那一刻」所需要的提醒。它不讨论长期战略，只讨论此时此刻的判读与操作。

二、读取另一个座位的窗格：幽灵文本与已提交文本的判别

跨席位协作的第一步是读取。Claude Code 与 Codex 都会在输入框中渲染自动补全的幽灵文本（ghost text），而rig capture抓取到的终端快照是纯文本，不携带字体颜色，因此你无法用颜色区分「这段字是自动补全的占位」还是「真的被打进去了」。ORCHESTRATION-CRAFT 给出三组可操作的判读规则：

1. 光标位置是首要判读器

• 光标在文本末尾→ 很可能是「已键入并停留」的暂存文本（staged text），即输入框里真实存在的内容；
• 光标在文本开头→ 极可能是幽灵文本，即模型/工具正在预填但尚未被接受的内容；
• 行为学判据：按一次 Enter 若没有消耗掉这段文本（它原样留下或消失），则它是幽灵文本。

文档特别强调：把幽灵误判为暂存、或把暂存误判为幽灵，都曾造成真实的误诊——在下任何关于「未提交行」的结论之前，先确认光标位置。

2. 暂存文本的修复是C-m，永远不是重发

如果文本确实坐在提示符上（staged），它尚未被消费。正确的修复是一次C-m（回车）——让该行被提交执行。绝不要重发（re-send），因为重发会交付两次，造成重复执行。这是「一次操作只产生一次效果」的纪律在终端层面的体现。

3. spinner 渲染在输入框上方，低行数抓取会失真

Claude Code / Codex 的忙碌指示器（spinner）渲染在输入框上方。如果一个席位正深度工作中，你抓取少于约 20 行的终端快照，看到的多半只是一个裸提示符——spinner 被截掉了。因此：

永远不要为了「简化活跃度读数」而降低抓取行数。

这一点与rig capture命令的实现直接对应。在 packages/cli/src/commands/capture.ts 中，capture命令默认--lines 20（源码：.option("--lines <n>", "Number of lines to capture (default: 20)", "20")），并支持--rig <name>/--pod <name>批量抓取整个编队或 pod、--json结构化输出，底层向守护进程发起POST /api/transport/capture。也就是说：默认 20 行正是文档警示的最低可用行数，用它来判断「忙碌中的席位是否存活」本身就是不可靠的，更不该把行数往下调。

三、观察而不烧掉整个舰队：单次抓取 + 被告知，而非轮询

跨席位观察最容易犯的错是把观察变成轮询循环。ORCHESTRATION-CRAFT 给出三条铁律：

1. 一次抓取，然后安排被告知。你无法「持续观看」——只能「瞥一眼」，而每一次瞥视都消耗一个回合（turn）。
2. 如果必须轮询：最小间隔两分钟；并且相同输出连续出现两次 = 停止轮询，而不是「更努力地轮询」。
3. 在共享 provider 上打紧循环会耗尽用量上限，停掉上面所有的席位。这是「一个人轮询，全队陪葬」的典型事故。

其背后是对「活跃度 ≠ 健康」的清醒认识：一个窗格可以持续渲染，但工作毫无进展（比如卡在某个死循环、反复输出同样的错误）。所以在把某个席位判为「卡住」之前，必须跨屏交叉验证：

• 用rig capture看窗格内容；
• 用rig queue transitions <qitemId>看该队列项的状态迁移日志（append-only transition log，见 packages/cli/src/commands/queue.ts 中transitions子命令，其实现为GET /api/queue/:qitemId/transitions）；
• 对照该席位最近一次认领（claim）的时间戳claimedAt。

三者的合取才能支撑「卡住」的结论：渲染中但队列迁移停滞、认领后长时间无产出，这才值得干预。单看窗格里有没有动静，是典型的误判来源。

四、在另一个席位上行动：三种干预，绝不可混用

当确认需要干预时，ORCHESTRATION-CRAFT 首先划定干预的类型学——wake（唤醒）、refocus（重聚焦）、checkpoint（检查点）是三种不同的干预：

文档点出的最常见「自我造成的停滞」是：该发轻量干预时发了重型干预——把一次唤醒升级成了重聚焦，或把重聚焦升级成了检查点，结果把正在正常工作的席位搅停。

绝对禁忌：永远不要为了「解锁某事」而压缩（compact）同级席位

这是本手册中最重的一条红线：

Never compact a peer to unblock something.压缩之后回来的那个席位「自以为知道一切，但实际上已经不知道了」——而且只有你知道发生过压缩。

压缩会丢失该席位的上下文连续性；被压缩者回来后基于残缺上下文继续行动，会产生下游误判，而事故源头只有操作者自己清楚。因此若确实需要解除阻塞，正确路径是：

1. 先沉淀（Deposit first）——把关键上下文落盘（如写入该席位的 chain-file 或队列项）；
2. 宣告（Announce）——明确告知发生了什么；
3. 声明该席位不再持有哪些信息（state what the seat no longer holds）——把「你知道它不知道」这件事显式移交。

这与product-team编队级 CRAFT（topology/rig/CRAFT.md）中「传输负面信号会撒谎」的规范同源：超时是「不确定」而非「失败」，任何重试前都必须按 ID 对账，否则会把队列行分叉（fork the row）。干预一个人，本质上是管理信息与义务的流动，不是管理进程。

五、把实践沉淀回这些文件：发现 → 策展 → 发布

ORCHESTRATION-CRAFT.md的最后一部分回答了「这些文件里的纪律从哪来、如何生长」的问题，给出一个三级流水线：

1. 发现（Discovery）：实践出现在它被挣得的地方——一个席位的LEARNED.md、一条现场笔记、一次评审观察。它先作为「本地经验」存在。
2. 策展（Curation）：判断它是否普遍适用（换一台陌生机器、换一个不同项目是否仍然成立）。若只是项目特有，就留在挣得它的那个海拔，不要上提。
3. 发布（Ship）：把普遍适用的实践写进规格源码中的topology/默认文件，每行附一个动机事件（one motivating incident per line）。编辑本机已安装的副本只对当前 rig有效；发布到源码默认值则惠及每一次未来的安装。

这套「发现 → 策展 → 发布」机制在 docs/reference/chain-file-convention.md 中有完整定义，关键约束包括：

• 副本优先：随 rig 发布的默认文件是「起点」，占据该层的团队可以自由追加；后续 rig-up永不覆盖已存在的文件（existing files win）。
• 项目树不发货：拓扑树（instance → rig → pod → seat）承载「工作怎么做」，可以出厂默认；项目树（mission → slice）承载「在构建什么」，依赖具体项目，无法预售。
• 编辑不是投递：修改源文件只影响新安装；对正在运行的席位，默认文件的变更必须通过显式投递渠道（refocus channel）送达——editing a file is not delivery to a running seat。

而运行中的席位若要读取这些链式文件，标准姿势是rig context trace --rig <rig> [--pod <pod>] --seat <seat> --name <NAME>.md：它从你站立的位置向根行走、逐层打印同名文件，标记内容来源（topology.root/ 遗留树 / 缺失），且不需要守护进程在运行——定向恰恰是守护进程可能宕机的时刻（该命令定义同样见 docs/reference/chain-file-convention.md）。

六、与同级 CRAFT 的协同：编排纪律是整套规范的一环

ORCHESTRATION-CRAFT.md不是孤立的。把它放回product-teamrig 的 chain-file 家族，可以看清编排纪律在整套规范中的位置：

• 实例海拔（topology/instance/CRAFT.md）给出所有席位共用的元纪律：检查而非回忆（rig whoami/rig ps/rig queue list --mine优先于记忆）、路径从配置推导（rig config get topology.root等）、两棵树（拓扑树 vs 项目树）不可混淆、按效果验证而非按成功消息（重新读盘、跑消费者、数行数，零不是一个可信的成功）。这些是编排者做任何判断前的地基。
• 编队海拔（topology/rig/CRAFT.md）给出队列义务的本质：若另一个席位必须行动，它就需要一个队列行——send 只是通知，只有行（qitem）才产生可审计的义务；交接必须用rig queue handoff使「关闭旧行 + 创建新行」成为一个事务。这直接解释了为什么「跨屏交叉验证」要查rig queue transitions：队列才是义务的真相源。
• 席位海拔（如 topology/seats/orch1-lead/CRAFT.md）进一步约束编排席位本身：验证要查源头（handler body 而非 summary）；不要亲自做工作，锁定「好」的标准然后委派；你是减震器而非导线，只中继已定论的决策；只有本席位可以 park（且必须rig watchdog register武装看门狗）；不要为了显得忙碌而发明工作。

三者的关系可以概括为：实例 CRAFT 保证「你的读取可信」，编队 CRAFT 保证「义务可审计」，编排 CRAFT 保证「你的跨席位操作不造成伤害」。而product-team的整体拓扑（packages/daemon/specs/rigs/preview/product-team/rig.yaml）——orch1（lead/peer 双编排）、dev1（impl/qa/design）、rev1（r1/r2 双评审），配以delegates_to与can_observe边——决定了这套纪律实际发生的场景：编排者向开发/评审委派、评审者观察实现与设计，跨席位读取与干预是日常而非例外，因此操作纪律必须先于事故沉淀为默认。

七、实践清单：把本文浓缩为行动时的四条判读

最后，将全文压缩为可以直接贴在行动时刻的检查清单：

1. 读窗格之前：先看光标位置——末尾是暂存、开头是幽灵；暂存用一次C-m消费，绝不重发；忙碌席位的抓取行数不低于 20 行（rig capture的默认--lines 20正是底线）。
2. 观察的节奏：一次rig capture之后安排被告知；必须轮询则至少间隔两分钟，相同输出两次即停；判「卡住」必须交叉claimedAt与rig queue transitions，渲染 ≠ 健康。
3. 干预的选择：唤醒不重构、重聚焦以「先完成当前动作」开场、检查点是刻意的阶段边界；永远不用压缩（compact）来解锁同级席位，确需解锁则先沉淀、再宣告、并声明该席位不再持有的信息。
4. 沉淀的路径：本地挣得的经验先留在挣得处（LEARNED.md/ 现场笔记），经策展确认普遍适用后，以「一行一个动机事件」的方式发布进 packages/daemon/specs/rigs/preview/product-team/topology/ 的默认文件——编辑副本只救当前 rig，发布源码救未来所有安装。

这套纪律的全部价值在于：在一个由多个长期运行的 Agent 席位构成的系统里，操作者本人的判断习惯就是系统可靠性的第一道防线。它无法被代码完全替代，但可以被沉淀成文件、随 rig 出厂、并在每一次行动中被提醒。

• 人工智能
• AI Agent
• 多智能体
• Agent 编排
• 代码智能体
• CLI