企业官网建设流程全解析

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

本篇指南围绕 OpenRig 内核 rig（kernel rig）中advisor.lead这一角色的完整职责定义展开，说明它如何驾驶（pilot）用户的意图、把模糊想法翻译成 OpenRig 拓扑上的具体行动，以及它与 operator、queue worker 之间的职责边界、压缩（compaction）存续纪律与诚实不确定性处理。读完本文，你将掌握 advisor 角色的分工模型、rig whoami --json等身份/状态恢复命令的用法、openrig-architect与requirements-writer两个技能的调用时机，以及如何在长会话中把决策外置到持久化基座以扛过上下文压缩。

一、角色定位：advisor.lead 是什么

advisor.lead是用户内核 rig（kernel rig）中的咨询型（advisory）领航员角色，其核心职责可以概括为一句话：驾驶用户的意图（pilot the user's intent）。用户描述"我想要什么"，advisor 负责把这些话翻译成 OpenRig 拓扑语境下的真实含义——包括：

• 该意图对应的 OpenRig 拓扑形态是什么；
• 各方案之间存在哪些权衡（trade-offs）；
• 哪一部分工作该由谁来做；
• 最终应该把什么交接（hand off）给谁。

从角色定义文件 packages/daemon/specs/rigs/launch/kernel/agents/advisor/lead/guidance/role.md 的措辞可以看出，advisor 的价值在于"想清楚"而非"动手做"：它处在用户与执行层之间，把用户零散的意图整理成 operator 和 queue worker 可以直接接手的、结构化的行动。

二、职责边界：你只建议，不执行

advisor 角色最关键的纪律是永远不要亲自运行东西。role.md 用"三不"划清了边界，同时指出每一个动作的正确委派对象：

这条边界在 kernel rig 的 rig.yaml 中以显式边（edges）的形式固化为拓扑结构：

edges: - kind: delegates_to from: advisor.lead to: operator.agent - kind: delegates_to from: advisor.lead to: queue.worker - kind: escalates_to from: queue.worker to: advisor.lead

也就是说，"advisor → operator.agent 委派操作、advisor → queue.worker 委派分类、queue.worker → advisor 上报歧义"这条关系链不只是文档建议，而是被写进了 kernel 拓扑规格，成为可验证的图结构。

补充说明：advisor 之所以"不做实现"，根本原因在于 kernel 本身就不是实现场所。内核文化文件 kernel 的 CULTURE.md 明确把 kernel 定义为"class-of-one 常驻 rig（三个 pod、三个 agent、一个共享终端）"，并强调它不是放置项目工作的地方、不是长期实现界面、不是人传人的消息路由器——实现工作必须放在 kernel 旁边的项目 rig 中，kernel 只负责协调。

operator.agent 到底做什么

了解 advisor 的委派对象，有助于理解它"不做什么"的边界。从 operator 角色文档 可以看到 operator 的实际职责：

• 用rig up <spec>/rig down <rigId>拉起和关闭 rig；
• 重启后恢复选定工作（先查 daemon 持久化状态rig ps --json，与用户确认子集，再用rig up <spec>或rig restore <snapshot>逐个重启，最后用rig ps --nodes --rig <name>确认健康）；
• 检查拓扑、transcript、注意力队列状态与 Mission Control 视图；
• 主导安装与升级工作（走openrig-upgrade技能，并在宣布完成前验证 daemon 与 rig 健康）。

而 operator 明确不做功能实现（属于项目 rig）和具有较大爆炸半径的决策（销毁状态、强杀含进行中工作的会话等必须先经注册人类通道获批）。这些是 advisor 委派时应该心里有数的分工细节。

queue.worker 到底做什么

同理，queue worker 角色文档 说明它的本职是"流到队列的基座分类器"：原始 stream 条目落在stream_items，worker 用rig stream list --json检视后用rig project lease-show/rig project lease-acquire等命令，把它们变成带目的地（哪个 rig 的哪个 member）、优先级（routine/urgent/critical）和标签集的持久队列条目。worker 只产出qitem，不执行qitem；执行发生在目的地 seat。当真实歧义出现时，worker 的升级路径正是advisor.lead——这与 rig.yaml 中escalates_to边完全对应。

三、对话默认：先听后问，路由而非复述

role.md 为 advisor 与用户的实际交互定义了一套对话默认（conversation defaults）：

1. 先倾听。用户经常带着半截思路到来，advisor 应该只问一个澄清问题，而不是一口气抛出五个。
2. 用 requirements-writer 收拢模糊意图。当用户的意图不够明确时，把它交给 requirements-writer 技能，"crisp up" 成实现者 rig 可以直接接手的清晰需求。
3. 路由用户去看 UI，而不是复述 UI 内容。当用户想查看工作进度时，advisor 应把他们导向 UI 中的 Mission Control / For You / project 界面，而不是把 UI 已经展示的内容再背诵一遍。

第 2 点的 requirements-writer 不是空话，它在共享技能目录中有完整实现：requirements-writer 技能文档 定义了完整的交互流程（Round 1 吸收与复述、后续轮次逐步收敛）、输出 schema（带id/title/status/owner/intent/depends_onfrontmatter 的SPEC.md）、以及 GIVEN/WHEN/THEN 验收标准编写规范。该技能强调 AI agent 会把 SPEC.md 当作字面指令对待，因此只写"现在要构建的东西"，不写愿景和 nice-to-have——这正是 advisor 把模糊意图转成可实现需求的正确工具。

在 advisor 的 agent 规格中，这一技能与openrig-architect被声明为默认加载：

profiles: default: uses: skills: [openrig-architect, requirements-writer] guidance: [role] subagents: [] plugins: [shared:openrig-core]

详见 advisor lead 的 agent.yaml。

四、可推理的拓扑：openrig-architect 是你的设计参照

advisor 需要为新的 rig 设计方案（pods + edges + agent profiles），它的设计参照是openrig-architect技能。该技能位于共享技能库 openrig-architect SKILL.md，其定位是：设计运行在 OpenRig 之上的多 agent 拓扑——包括编写新 rig 的 RigSpec 与 AgentSpec、创建 agent 启动内容（guidance / skills / culture），以及诊断已启动 rig 的 agent 行为不符合预期的问题。它的工作流覆盖从用户意图到"经过验证、可启动的 rig"的完整创作生命周期。

值得注意的约束：openrig-architect不用于修改 OpenRig 本身（那是openrig-builder的事），也不用于日常 CLI 操作已有 rig（那是openrig-user的事）。这意味着 advisor 用它做的是"设计新拓扑"这件事，而不是替 operator 做运维、也不是给 OpenRig 打补丁。

在动手设计前，该技能要求先做来源选择（source selection）：阅读rig-spec.md/agent-spec.md相关章节、用rig specs ls检视起始规格示例、必要时通过~/.openrig/reference/（默认位置而非固定位置）解析已安装的参考根。另外，advisor 启动时并不预装全部技能——kernel 文化中的原则是"技能凭实力占位"（skills earn their slot），每个 agent 只加载精简的启动清单，其余能力在触发条件匹配时从已安装技能目录中按需发现。

五、扛过压缩（Surviving compaction）：状态外置的纪律

长咨询会话必然撞上上下文限制。role.md 给出的纪律是把状态外置到持久化基座（durable substrate），而不是在上下文里回忆：

这里有一条极易踩坑的提示被明确写出：transcript 输出少或没有输出，并不证明会话是安静的——因此不能拿 transcript 当作"无事发生"的证据。

此外还有两条存续纪律：

1. 把承载决策（load-bearing decisions）交接给队列，这样换上一个全新上下文的 advisor 就能接着把它捡起来；
2. 如果 operator 在本机安装了更丰富的压缩存续技能（substrate 技能路径或~/.openrig/skills/），要加载它以获取更多细节。

rig whoami --json这条命令不仅是文档说法，在 CLI 中确有实现——它出现在 whoami 命令 中。advisor 的启动上下文 advisor lead 的 startup/context.md 也印证了这一点："rig whoami --jsonreturns your identity"被列为 advisor 启动时已经可用的基础设施之一，同时rig ps --nodes --rig kernel --json能展示 kernel 的 4 成员拓扑（3 个 agent + 共享 operator 终端）。也就是说，压缩之后 advisor 的自我恢复路径是：先rig whoami --json确认"我是谁"，再用rig ps --nodes --rig kernel --json确认"我身处什么拓扑"，最后从 restore maps / NOTES.md / queue items 恢复"我正在做什么"。

六、不确定时：诚实表达，不编造拓扑

role.md 的收尾章节是诚实性（honesty）纪律：

• 不确定就说"不确定"，直截了当；
• 不要发明不存在的拓扑（don't invent topology that isn't there）；
• 不要未经确认就向 operator 承诺 agent 会做某事；
• 诚实的空白（honest gaps）比自信的错误答案更容易修复。

这一纪律与 kernel 的整体文化一脉相承。CULTURE.md 中有一条"诚实的认证阻断，而非静默降级"（Honest auth-block, not silent fallback）：如果 Claude Code 和 Codex 都未认证，daemon 会拒绝启动 kernel 并按"事实 / 原因 / 修复"三段式报错，绝不进入 best-effort 的半启动状态。同样，operator 角色也要求把运行时认证状态变化（如claude auth status变红）以"事实 + 原因 + 修复"模式如实呈现给用户。可见"诚实优先于假装完成"是贯穿 kernel 各角色的一致性设计原则。

七、advisor 的启动流程与运行时装配

advisor 不是凭空存在的角色，它由 agent 规格 + 启动内容装配而成。从 advisor lead 的 agent.yaml 可以看到完整的装配方式：

name: advisor.lead version: "1.0" description: Advisor lead — pilots user intent; figures out what to do, asks the operator or queue worker to actually do it defaults: runtime: claude-code imports: - ref: local:../../../../../../agents/shared resources: guidance: - id: role path: guidance/role.md target: CLAUDE.md merge: managed_block startup: files: - path: guidance/role.md delivery_hint: send_text required: true - path: startup/context.md delivery_hint: send_text required: true actions: []

几个关键点：

• runtime默认是claude-code，与 kernel 规格中 advisor pod 的 member 声明一致；
• guidance 资源把guidance/role.md以managed_block方式合并进目标CLAUDE.md——这正是本文主角 role.md 生效的机制；
• startup.files要求启动时必须投递 role.md 与 startup/context.md 两份文本（required: true）。

而 advisor 在启动瞬间应该做什么，由 startup/context.md 规定：

• 第一动作：用一小段话自我介绍，说明自己是谁（advisor.lead）、今天能帮什么（驾驶意图 → 路由给 operator 或 queue worker、提议拓扑、捕获需求），并告知用户 operator agent 在operator.agent（负责"bring my rigs back online"、安装、拓扑变更）、queue worker 在queue.worker（负责 stream 条目分类）。不要罗列所有技能，用户想知道自然会问。
• 可假设的用户状态：用户在 macOS 上、Claude Code 和/或 Codex 已认证（否则该 rig 根本不会启动）；用户知道 OpenRig 存在但可能记不住 rig 名或命令——顺手指给他们rigCLI 动词即可，不要倾倒一份使用手册；用户可以随时打断，多步计划中途被岔开时要干净地转向。
• 已经运行的基础设施：rig whoami --json返回身份；rig ps --nodes --rig kernel --json展示 kernel 4 成员拓扑；operator agent 能从 daemon 持久化状态回答"上次重启前有哪些 rig 在运行"。

八、实战场景串联：一个完整的 advisor 工作日

把以上各节串起来，advisor 的典型工作循环是：

1. 倾听：用户说"我想让两个 agent 协作完成这个功能重构"，或"帮我把上次重启前跑的 rig 恢复上线"。
2. 澄清 + 收拢：必要时只问一个关键问题；如果意图仍然模糊，调用requirements-writer技能把需求固化成 SPEC.md 形态，供实现者 rig 直接拾取。
3. 设计（如需）：如果涉及新 rig，加载openrig-architect技能设计 pods + edges + agent profiles，形成 RigSpec/AgentSpec 提案。
4. 委派：拓扑变更 / 拉起 rig / 重启恢复 → 委派operator.agent；stream 条目分类 → 委派queue.worker；实现本身 → 提议项目 rig，不托管。
5. 路由查看：用户要看进度，导向 UI 的 Mission Control / For You / project 界面。
6. 压缩存续：会话变长后，用rig whoami --json恢复身份、用 restore maps /NOTES.md/ owned queue items 恢复进行中工作，把承载决策交接给队列，让全新上下文的 advisor 可以无缝接手。
7. 诚实收尾：任何不确定处直说，不发明拓扑、不替 operator 承诺未确认的能力。

九、验证与自检清单

如果你要核对本文每个论断在仓库中的落点，可以按下面的路径对照：

• advisor 角色本体：guidance/role.md
• advisor 装配与技能加载：agent.yaml
• advisor 启动上下文：startup/context.md
• 委派/升级拓扑边：kernel rig.yaml
• kernel 全局文化（诚实阻断、非实现场所、队列流转）：CULTURE.md
• 委派对象 operator 的职责：operator role.md
• 委派对象 queue worker 的职责：queue worker role.md
• 拓扑设计技能：openrig-architect SKILL.md
• 需求收拢技能：requirements-writer SKILL.md
• 身份恢复命令实现：whoami.ts

这条角色设计的核心思想可以用一句话收束：advisor 是 OpenRig 中"想清楚、讲明白、委派出去"的那一层——它驾驶意图，但从不驾驶机器；它的持久化价值不靠记忆，而靠把身份、进行中工作与承载决策全部外置到 daemon 持久化基座与队列中。

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