尧图网站建设 
人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载OpenRig 中一个 agent 启动后能否立刻高效工作取决于它拿到手的启动上下文是否准确、新鲜、聚焦——本指南围绕agent-startup-and-context-ingestion技能展开讲解 AGENTS.md 覆盖层、角色文件、技能、rig spec、workflow spec、启动清单、refocus 消息与rig context检索面的正确组织方式。读完本文你将掌握 OpenRig 启动上下文的 4 种典型失败模式与规避手段、rig whoami --json驱动的任务级启动解析链路、启动文件与技能的边界划分以及 7 层叠加启动模型在实际 rig 中的落地方法。为什么启动上下文是协调成败的第一道关口在 OpenRig 的“context engineering and retrieval”体系里agent 启动是第一个具体的落点启动决定了一个 seat席位以什么初始形态进入工作而更广义的上下文工程则解决 seat 在当前工作中持续获得正确上下文的问题。核心判断是大多数协调失败不是工具失败而是上下文失败。Agent 需要知道自己的角色、当前运行模式、协调约定、边界以及当前的产品意图product intent。如果启动上下文散落各处或者已经过期agent 会以极高的效率执行错误的事情。因此启动上下文设计的优先级远高于接入更多工具。适用场景Use this when为新 agent 编写启动文件role / culture / startup-context刷新一个一直运行在过期指引上的 seat审计 agent 是否拿到了当前运行模式而不只是旧文件里写了什么设计 orchestrator → 下一个 agent 的上下文传递形态为 OpenRig 自举构建 OpenRig 的 rig绘制启动地图。不适用场景Dont use this whenagent 通过 Agent Starter 创建——此时 starter manifest 已携带启动上下文见 agent-starters/SKILL.md工作是基于 packet 的 artifact 化心智模型重建——那属于 session-compaction-and-restore目标是发布可复用的启动内容为技能——那属于writing-skills-for-openrig技能。启动失败的 4 种模式审计时的排查清单原文档明确定义了 4 种让启动上下文失效的模式也是任何启动审计首先应检查的四个方向新 agent 从旧 rig spec 启动错过了当前运行模式。Spec 会过期启动时必须让当前状态可见而不是只依赖历史配置。指引被写进文件未来的 agent 会读到但当前在跑的 agent 从未被告知。文件编辑不会传播到运行中的会话。文化类内容的推广需要配套文化广播broadcast fleet-changes-feed而不只是改文件。启动文件变成大杂烩丢掉了“指向权威源”的角色。启动文件应该指向权威来源point AT而不是试图成为权威来源TRY to be one。orchestrator 只传递实现指令没有保留产品意图。指令会衰减而意图应当随行传递。任务级启动Task-scoped startup从 whoami 到选中路径的解析链启动不应是“读一堆文件”而是解析出当前这个任务真正需要的输入。原文档给出了明确的命令链路rig whoami --json → project.yaml → mission.yaml → active slice.yaml → 选中的 component 或 wave map → addressed context被寻址的上下文完整的查找与优先级规则见 docs/reference/product-journey-sdlc.md#resolve-the-selected-path安装到本地后为$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path。该参考文档将“解析选中路径”细化为五步用rig whoami --json推导身份用rig config get workspace.root定位工作根目录可能与 seat 的代码检出目录不同读取project.yaml及其项目权威上下文沿 mission root 到被指派的mission.yaml再沿 composition ref 到活动slice.yaml不要从旧 onboarding packet 或目录新鲜度去选 mission按“项目默认 → mission 默认 → 活动 slice 显式选择/覆盖”的顺序解析 SDLC 选择更窄的显式选择替换更宽泛的组件列表而不是追加每个祖先的 gate只读被选中的组件与被额外寻址的上下文仓库引用从代码仓库根解析安装引用从$OPENRIG_HOME/reference解析context-pack 引用用rig context get获取Markdown#section地址应使用loading-addressable-markdown技能而非加载整本无关手册简要陈述用户成果、当前角色、候选方案、选中路径与下一个完成边界。任务级启动还有三条重要原则启动文件是地址地图address maps不是普适的阅读强制令不要预载无关的规划/评审教义也不要要求逐文件 ACK 和测验技能可用skill availability不等于加载其全文profile 里可用的技能是能力清单不是强制阅读清单旧的 packet 不能决定当前工作缺失被选中的上下文是一个需要解决的具名缺口named gap而不是“没有选择”的证据——不要静默地从显式选中的严谨路径回退。源码佐证rig whoami --json到底返回什么packages/cli/src/commands/whoami.ts 是这条解析链的第一环。值得注意的实现细节默认输出是compact紧凑投影通过projectCompactWhoamiwhoami.ts#L78-L104将 payload 收窄到身份恢复 ALLOWLIST——identityrigName/nodeId/logicalId/podId/memberId/sessionName/runtime、peers、edges、transcript。注释明确这是一个 allowlist 而非 denylist未来新增字段默认进--full不会悄悄让每次启动的调用膨胀。身份解析遵循固定优先级链whoami.ts#L151-L193--node-id→--session→OPENRIG_NODE_ID/OPENRIG_SESSION_NAME环境变量 → tmuxrigged_node_id元数据 →rigged_session_name元数据 → tmux 原始会话名 → 失败。--json是面向 agent 的机器可读输出--full/--verbose才展示 contextUsage 等完整负载紧凑模式下连 Context 行都省略如需用量请用rig context或rig whoami --full。这解释了为什么技能文档把rig whoami --json放在任务级启动的第一步它同时给出身份、同 rig 对等体peers含rig send所需的 sessionName、拓扑边edges与 transcript 路径是启动解析的权威锚点。证明标准Proof standard评估启动上下文是否生效原文档要求在一次性干净会话中观察真实的读取行为与由此产生的下一步动作并测试三类用例无选择no-selection场景显式严谨explicit rigor场景wave 边界wave-boundary场景。关键约束一次编辑不能证明已经在运行的 seat 采纳了它——采纳需要经过授权的刷新或下一次启动的观察。不要仅仅为了测试文案而清空或重新预热一个在线 seat。跨运行时启动路径5 条不可折叠当 seat 的启动属于 artifact 支撑的心智模型重建active-work 重入场场景区别于可复用的 Agent Starter / priming pack时遵循cross-runtime restore/reentry packet 标准 v0并使用以下源信任排序rig whoami target rigspec bounded latest transcript full transcript touched-files restore-summary.json即身份命令的当前现实优先于一切历史产物越接近“当前权威状态”的源越可信越靠后的源只作为兜底证据。这个排序也呼应了“当前命令/源码现实胜过过期 YAML 作为事实主张”的原则见 product-journey-sdlc.md#L324-L329。启动时消费的内存表面Memory surfaces启动时应盘点选中的启动输入清单AGENTS/role/CULTURE 覆盖层、replay 上下文以及任何声明的 restore packet 或 starter。对每一项记录它来自哪里、是否当前有效、为什么本任务需要它。注意可用技能或旧 packet 不能替当前工作做选择。权限边界也要清晰能读某个输入不等于能改写其源写入必须遵循活动项目/rig 的策略与指派。当需要判断持久化上下文应放在哪里时用rig context get加载skills/openrig-operating-model/SKILL.md来裁决。启动文件 vs 技能边界在哪这是最容易混淆的一处。按产品参考文档 docs/reference/agent-startup-guide.md 与团队手册的界定启动文件Startup files技能SkillsRig 专属、角色专属的身份可复用的 SOP / 方法论 / 知识告诉 agent 它是谁、在做什么、这个团队怎么运作告诉 agent 怎么做某事跨 rig 可迁移示例role.md、CULTURE.md、startup/context.md示例openrig-user、test-driven-development、vault-user按 rig 编写一次编写处处使用两条红线不要把技能内容塞进启动文件也不要把身份内容写进技能。分层问题由下面要讲的 7 层叠加启动模型处理。7 层叠加启动模型docs/reference/agent-startup-guide.md产品参考文档非技能给出了启动内容的叠加模型——各层按交付顺序累加后层不替换前层而是追加1. Agent 层 —— 来自 AgentSpec 顶层 startup block 2. Profile 层 —— 来自活动 profile 的 startup block 3. Rig 层 —— 来自 RigSpec 顶层 startup block 4. Culture 层 —— 来自 RigSpec 的 culture_file 5. Pod 层 —— 来自 pod 的 startup block 6. Member 层 —— 来自 RigSpec 中 member 的 startup block 7. Operator 层 —— 运行时注入openrig-start overlay、context collector 等每层的用途可概括为Agent 层承载随 agent 类型迁移的核心身份与能力角色指引、默认技能Profile 层做 profile 变体如 default vs minimal 的不同技能集Rig 层承载全 rig 共享的项目背景与团队规范Culture 层承载 rig 宪法CULTURE.md——沟通、质量、运作哲学Pod 层承载 pod 内协调上下文pod SOP、pod 内工作流Member 层承载成员级覆盖Operator 层由 OpenRig 系统注入openrig-start.md、context collector。实践建议多数 rig 只需要三层——agentrole.md、rigculture、operatoropenrig-start。先从简单开始只有当同 pod 内 agent 确实需要不同启动内容时才加 pod 层和 member 层。Culture 层价值高却常被跳过——没有CULTURE.md的 rig 只能靠 agent 猜测团队如何沟通协调。Member 层是例外手段而非常规如果每个 member 都有独立 startup block说明分层模型被当成了配置倾倒场应把共享内容上提到 pod 或 rig 层。交付机制与时机启动文件如何到达 agent由交付提示delivery hint决定交付提示时机方式用途autoharness 启动前系统选择默认——让 OpenRig 决定guidance_mergeharness 启动前以受管块合并进CLAUDE.md/AGENTS.md角色指引、culture、项目上下文skill_installharness 启动前复制到运行时技能目录技能send_textharness 就绪后经 tmux 以文本发送到 agent 终端启动接地、身份提示、读取技能的指令时机是关键guidance_merge与skill_install在 harness 启动前交付agent 一启动就能看到属于初始上下文的一部分send_text在 harness 就绪后送达适合身份接地、加载技能的指令以及“像 operator 简报而非预载内容”的场景。applies_on字段进一步控制生效范围fresh_start仅首次启动、restore仅从快照恢复、默认[fresh_start, restore]两者——用它可以避免向已恢复对话的 agent 重复发送它已持有的上下文。实战用 demo rig 串起启动链路仓库中的 demo/rig.yaml 是一个真实的 rig 定义可作为观察启动层叠的样例它声明了culture_file: culture.mdCulture 层并按 pod 组织成员——orchpod 的leadclaude-code、devpod 的impl/qa/designqa 为 codex、revpod 的r1/r2r2 为 codex以及infrapod 的 terminal daemon成员均引用local:agents/id的 agent spec如 demo/agents/lead/agent.yaml。每个 agent spec 通过 profile 的uses.skills声明技能可用性rig 的culture_file注入团队宪法运行时再由 Operator 层注入openrig-start接地信息——三层最小模型在这里完整可见。对应地docs/reference/agent-startup-guide.md 给出的最小有效启动是agent.yaml → guidance/role.md rig.yaml → culture_file: CULTURE.md profile → uses.skills: [openrig-user]再配上启动清单中的系统检查identity recovery 后执行rig ps --nodes确认 rig 在跑、rig env status确认服务健康、核对工作目录与所需工具agent 便能在启动后自证环境就绪。常见反模式避免重蹈把所有内容倒进一个巨型 CLAUDE.md——用分层模型拆开否则任何内容都无法复用在 guidance 文件里复制技能内容——技能会被投影guidance 应引用它们而非复制用 send_text 传本该预载的内容——agent 开始推理前就需要的内容用guidance_merge过度指定 member 级启动——共享内容应上提member 层只做小覆盖把关键 setup 押在确定性 hooks 上——若 hook 静默失败 agent 无从知晓确定性配置必须搭配启动指令或系统检查来验证结果。相关技能导航启动上下文并非孤岛它与以下技能协同工作详见各 SKILL.md 的 sibling_skills 关系mission-slice-sop——开始被指派的 mission/slice 工作时加载提供 SPEC.md、NOTES.md、PROGRESS.md 与 proof 的轻量工件与交接流程但不替任务选择 SDLCwriting-skills-for-openrig——技能内容不属于启动文件的部分的编写纪律forming-an-openrig-mental-model——新 agent 的定向引导session-compaction-and-restore——恢复期的启动摄取agent-starters——可复用的 starter manifest组合启动上下文captured → named → inspectable → used → promoted → deprecated 六态生命周期composable-priming-packs——产出已预热会话的 manifestopenrig-operating-model——持久上下文的放置与权威裁决。小结OpenRig 的启动上下文设计可以浓缩为三个动作解析用rig whoami --json沿 project/mission/slice 链路解析当前权威路径、分层按 7 层叠加模型把身份、文化与项目背景各归其位、指向启动文件是指向权威源的地址地图而非内容倾倒场。记住“启动文件 vs 技能”的边界、4 种失败模式和源信任排序你的 agent 就能在启动时拿到正确的角色、运行模式与产品意图——而不是在错误方向上高效狂奔。赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载相关推荐OpenRig Agent 启动与上下文摄取Agent Startup and Context Ingestion实战指南OpenRig Agent 启动与上下文摄取Agent Startup and Context Ingestion实战指南 Agent 启动Agent S人工智能AI Agent多智能体Agent 编排代码智能体CLIPostHog AI 上下文注入Attached Context实战指南让 Agent 知道你看到什么PostHog AI 上下文注入Attached Context实战指南让 Agent 知道你看到什么 导读 本文基于 PostHog 开源仓库中的 in数据分析后端前端数据可视化大数据大麦抢票自动化系统完整使用指南ticket-purchase 从部署到开售提交大麦抢票自动化系统完整使用指南ticket purchase 从部署到开售提交 ticket purchase大麦抢票自动化系统是开源 Python 项目GUI 自动化RPA上一篇TPU与JAX PallasMaths, CS AI Compendium非GPU加速器全景解析下一篇如何用Sunshine打造终极个人云游戏平台5步完整配置指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenRig Agent Startup and Context Ingestion：让 Agent 启动即就绪的上下文注入实践指南
人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载OpenRig 中一个 agent 启动后能否立刻高效工作取决于它拿到手的启动上下文是否准确、新鲜、聚焦——本指南围绕agent-startup-and-context-ingestion技能展开讲解 AGENTS.md 覆盖层、角色文件、技能、rig spec、workflow spec、启动清单、refocus 消息与rig context检索面的正确组织方式。读完本文你将掌握 OpenRig 启动上下文的 4 种典型失败模式与规避手段、rig whoami --json驱动的任务级启动解析链路、启动文件与技能的边界划分以及 7 层叠加启动模型在实际 rig 中的落地方法。为什么启动上下文是协调成败的第一道关口在 OpenRig 的“context engineering and retrieval”体系里agent 启动是第一个具体的落点启动决定了一个 seat席位以什么初始形态进入工作而更广义的上下文工程则解决 seat 在当前工作中持续获得正确上下文的问题。核心判断是大多数协调失败不是工具失败而是上下文失败。Agent 需要知道自己的角色、当前运行模式、协调约定、边界以及当前的产品意图product intent。如果启动上下文散落各处或者已经过期agent 会以极高的效率执行错误的事情。因此启动上下文设计的优先级远高于接入更多工具。适用场景Use this when为新 agent 编写启动文件role / culture / startup-context刷新一个一直运行在过期指引上的 seat审计 agent 是否拿到了当前运行模式而不只是旧文件里写了什么设计 orchestrator → 下一个 agent 的上下文传递形态为 OpenRig 自举构建 OpenRig 的 rig绘制启动地图。不适用场景Dont use this whenagent 通过 Agent Starter 创建——此时 starter manifest 已携带启动上下文见 agent-starters/SKILL.md工作是基于 packet 的 artifact 化心智模型重建——那属于 session-compaction-and-restore目标是发布可复用的启动内容为技能——那属于writing-skills-for-openrig技能。启动失败的 4 种模式审计时的排查清单原文档明确定义了 4 种让启动上下文失效的模式也是任何启动审计首先应检查的四个方向新 agent 从旧 rig spec 启动错过了当前运行模式。Spec 会过期启动时必须让当前状态可见而不是只依赖历史配置。指引被写进文件未来的 agent 会读到但当前在跑的 agent 从未被告知。文件编辑不会传播到运行中的会话。文化类内容的推广需要配套文化广播broadcast fleet-changes-feed而不只是改文件。启动文件变成大杂烩丢掉了“指向权威源”的角色。启动文件应该指向权威来源point AT而不是试图成为权威来源TRY to be one。orchestrator 只传递实现指令没有保留产品意图。指令会衰减而意图应当随行传递。任务级启动Task-scoped startup从 whoami 到选中路径的解析链启动不应是“读一堆文件”而是解析出当前这个任务真正需要的输入。原文档给出了明确的命令链路rig whoami --json → project.yaml → mission.yaml → active slice.yaml → 选中的 component 或 wave map → addressed context被寻址的上下文完整的查找与优先级规则见 docs/reference/product-journey-sdlc.md#resolve-the-selected-path安装到本地后为$OPENRIG_HOME/reference/product-journey-sdlc.md#resolve-the-selected-path。该参考文档将“解析选中路径”细化为五步用rig whoami --json推导身份用rig config get workspace.root定位工作根目录可能与 seat 的代码检出目录不同读取project.yaml及其项目权威上下文沿 mission root 到被指派的mission.yaml再沿 composition ref 到活动slice.yaml不要从旧 onboarding packet 或目录新鲜度去选 mission按“项目默认 → mission 默认 → 活动 slice 显式选择/覆盖”的顺序解析 SDLC 选择更窄的显式选择替换更宽泛的组件列表而不是追加每个祖先的 gate只读被选中的组件与被额外寻址的上下文仓库引用从代码仓库根解析安装引用从$OPENRIG_HOME/reference解析context-pack 引用用rig context get获取Markdown#section地址应使用loading-addressable-markdown技能而非加载整本无关手册简要陈述用户成果、当前角色、候选方案、选中路径与下一个完成边界。任务级启动还有三条重要原则启动文件是地址地图address maps不是普适的阅读强制令不要预载无关的规划/评审教义也不要要求逐文件 ACK 和测验技能可用skill availability不等于加载其全文profile 里可用的技能是能力清单不是强制阅读清单旧的 packet 不能决定当前工作缺失被选中的上下文是一个需要解决的具名缺口named gap而不是“没有选择”的证据——不要静默地从显式选中的严谨路径回退。源码佐证rig whoami --json到底返回什么packages/cli/src/commands/whoami.ts 是这条解析链的第一环。值得注意的实现细节默认输出是compact紧凑投影通过projectCompactWhoamiwhoami.ts#L78-L104将 payload 收窄到身份恢复 ALLOWLIST——identityrigName/nodeId/logicalId/podId/memberId/sessionName/runtime、peers、edges、transcript。注释明确这是一个 allowlist 而非 denylist未来新增字段默认进--full不会悄悄让每次启动的调用膨胀。身份解析遵循固定优先级链whoami.ts#L151-L193--node-id→--session→OPENRIG_NODE_ID/OPENRIG_SESSION_NAME环境变量 → tmuxrigged_node_id元数据 →rigged_session_name元数据 → tmux 原始会话名 → 失败。--json是面向 agent 的机器可读输出--full/--verbose才展示 contextUsage 等完整负载紧凑模式下连 Context 行都省略如需用量请用rig context或rig whoami --full。这解释了为什么技能文档把rig whoami --json放在任务级启动的第一步它同时给出身份、同 rig 对等体peers含rig send所需的 sessionName、拓扑边edges与 transcript 路径是启动解析的权威锚点。证明标准Proof standard评估启动上下文是否生效原文档要求在一次性干净会话中观察真实的读取行为与由此产生的下一步动作并测试三类用例无选择no-selection场景显式严谨explicit rigor场景wave 边界wave-boundary场景。关键约束一次编辑不能证明已经在运行的 seat 采纳了它——采纳需要经过授权的刷新或下一次启动的观察。不要仅仅为了测试文案而清空或重新预热一个在线 seat。跨运行时启动路径5 条不可折叠当 seat 的启动属于 artifact 支撑的心智模型重建active-work 重入场场景区别于可复用的 Agent Starter / priming pack时遵循cross-runtime restore/reentry packet 标准 v0并使用以下源信任排序rig whoami target rigspec bounded latest transcript full transcript touched-files restore-summary.json即身份命令的当前现实优先于一切历史产物越接近“当前权威状态”的源越可信越靠后的源只作为兜底证据。这个排序也呼应了“当前命令/源码现实胜过过期 YAML 作为事实主张”的原则见 product-journey-sdlc.md#L324-L329。启动时消费的内存表面Memory surfaces启动时应盘点选中的启动输入清单AGENTS/role/CULTURE 覆盖层、replay 上下文以及任何声明的 restore packet 或 starter。对每一项记录它来自哪里、是否当前有效、为什么本任务需要它。注意可用技能或旧 packet 不能替当前工作做选择。权限边界也要清晰能读某个输入不等于能改写其源写入必须遵循活动项目/rig 的策略与指派。当需要判断持久化上下文应放在哪里时用rig context get加载skills/openrig-operating-model/SKILL.md来裁决。启动文件 vs 技能边界在哪这是最容易混淆的一处。按产品参考文档 docs/reference/agent-startup-guide.md 与团队手册的界定启动文件Startup files技能SkillsRig 专属、角色专属的身份可复用的 SOP / 方法论 / 知识告诉 agent 它是谁、在做什么、这个团队怎么运作告诉 agent 怎么做某事跨 rig 可迁移示例role.md、CULTURE.md、startup/context.md示例openrig-user、test-driven-development、vault-user按 rig 编写一次编写处处使用两条红线不要把技能内容塞进启动文件也不要把身份内容写进技能。分层问题由下面要讲的 7 层叠加启动模型处理。7 层叠加启动模型docs/reference/agent-startup-guide.md产品参考文档非技能给出了启动内容的叠加模型——各层按交付顺序累加后层不替换前层而是追加1. Agent 层 —— 来自 AgentSpec 顶层 startup block 2. Profile 层 —— 来自活动 profile 的 startup block 3. Rig 层 —— 来自 RigSpec 顶层 startup block 4. Culture 层 —— 来自 RigSpec 的 culture_file 5. Pod 层 —— 来自 pod 的 startup block 6. Member 层 —— 来自 RigSpec 中 member 的 startup block 7. Operator 层 —— 运行时注入openrig-start overlay、context collector 等每层的用途可概括为Agent 层承载随 agent 类型迁移的核心身份与能力角色指引、默认技能Profile 层做 profile 变体如 default vs minimal 的不同技能集Rig 层承载全 rig 共享的项目背景与团队规范Culture 层承载 rig 宪法CULTURE.md——沟通、质量、运作哲学Pod 层承载 pod 内协调上下文pod SOP、pod 内工作流Member 层承载成员级覆盖Operator 层由 OpenRig 系统注入openrig-start.md、context collector。实践建议多数 rig 只需要三层——agentrole.md、rigculture、operatoropenrig-start。先从简单开始只有当同 pod 内 agent 确实需要不同启动内容时才加 pod 层和 member 层。Culture 层价值高却常被跳过——没有CULTURE.md的 rig 只能靠 agent 猜测团队如何沟通协调。Member 层是例外手段而非常规如果每个 member 都有独立 startup block说明分层模型被当成了配置倾倒场应把共享内容上提到 pod 或 rig 层。交付机制与时机启动文件如何到达 agent由交付提示delivery hint决定交付提示时机方式用途autoharness 启动前系统选择默认——让 OpenRig 决定guidance_mergeharness 启动前以受管块合并进CLAUDE.md/AGENTS.md角色指引、culture、项目上下文skill_installharness 启动前复制到运行时技能目录技能send_textharness 就绪后经 tmux 以文本发送到 agent 终端启动接地、身份提示、读取技能的指令时机是关键guidance_merge与skill_install在 harness 启动前交付agent 一启动就能看到属于初始上下文的一部分send_text在 harness 就绪后送达适合身份接地、加载技能的指令以及“像 operator 简报而非预载内容”的场景。applies_on字段进一步控制生效范围fresh_start仅首次启动、restore仅从快照恢复、默认[fresh_start, restore]两者——用它可以避免向已恢复对话的 agent 重复发送它已持有的上下文。实战用 demo rig 串起启动链路仓库中的 demo/rig.yaml 是一个真实的 rig 定义可作为观察启动层叠的样例它声明了culture_file: culture.mdCulture 层并按 pod 组织成员——orchpod 的leadclaude-code、devpod 的impl/qa/designqa 为 codex、revpod 的r1/r2r2 为 codex以及infrapod 的 terminal daemon成员均引用local:agents/id的 agent spec如 demo/agents/lead/agent.yaml。每个 agent spec 通过 profile 的uses.skills声明技能可用性rig 的culture_file注入团队宪法运行时再由 Operator 层注入openrig-start接地信息——三层最小模型在这里完整可见。对应地docs/reference/agent-startup-guide.md 给出的最小有效启动是agent.yaml → guidance/role.md rig.yaml → culture_file: CULTURE.md profile → uses.skills: [openrig-user]再配上启动清单中的系统检查identity recovery 后执行rig ps --nodes确认 rig 在跑、rig env status确认服务健康、核对工作目录与所需工具agent 便能在启动后自证环境就绪。常见反模式避免重蹈把所有内容倒进一个巨型 CLAUDE.md——用分层模型拆开否则任何内容都无法复用在 guidance 文件里复制技能内容——技能会被投影guidance 应引用它们而非复制用 send_text 传本该预载的内容——agent 开始推理前就需要的内容用guidance_merge过度指定 member 级启动——共享内容应上提member 层只做小覆盖把关键 setup 押在确定性 hooks 上——若 hook 静默失败 agent 无从知晓确定性配置必须搭配启动指令或系统检查来验证结果。相关技能导航启动上下文并非孤岛它与以下技能协同工作详见各 SKILL.md 的 sibling_skills 关系mission-slice-sop——开始被指派的 mission/slice 工作时加载提供 SPEC.md、NOTES.md、PROGRESS.md 与 proof 的轻量工件与交接流程但不替任务选择 SDLCwriting-skills-for-openrig——技能内容不属于启动文件的部分的编写纪律forming-an-openrig-mental-model——新 agent 的定向引导session-compaction-and-restore——恢复期的启动摄取agent-starters——可复用的 starter manifest组合启动上下文captured → named → inspectable → used → promoted → deprecated 六态生命周期composable-priming-packs——产出已预热会话的 manifestopenrig-operating-model——持久上下文的放置与权威裁决。小结OpenRig 的启动上下文设计可以浓缩为三个动作解析用rig whoami --json沿 project/mission/slice 链路解析当前权威路径、分层按 7 层叠加模型把身份、文化与项目背景各归其位、指向启动文件是指向权威源的地址地图而非内容倾倒场。记住“启动文件 vs 技能”的边界、4 种失败模式和源信任排序你的 agent 就能在启动时拿到正确的角色、运行模式与产品意图——而不是在错误方向上高效狂奔。赞分享人工智能AI Agent多智能体Agent 编排代码智能体CLI【免费下载链接】openrigBuild your own network of agents from Claude Code, Codex and Pi: persistent teams with roles, shared context and owned work.项目地址https://gitcode.com/GitHub_Trending/op/openrig点击查看免费下载相关推荐OpenRig Agent 启动与上下文摄取Agent Startup and Context Ingestion实战指南OpenRig Agent 启动与上下文摄取Agent Startup and Context Ingestion实战指南 Agent 启动Agent S人工智能AI Agent多智能体Agent 编排代码智能体CLIPostHog AI 上下文注入Attached Context实战指南让 Agent 知道你看到什么PostHog AI 上下文注入Attached Context实战指南让 Agent 知道你看到什么 导读 本文基于 PostHog 开源仓库中的 in数据分析后端前端数据可视化大数据大麦抢票自动化系统完整使用指南ticket-purchase 从部署到开售提交大麦抢票自动化系统完整使用指南ticket purchase 从部署到开售提交 ticket purchase大麦抢票自动化系统是开源 Python 项目GUI 自动化RPA上一篇TPU与JAX PallasMaths, CS AI Compendium非GPU加速器全景解析下一篇如何用Sunshine打造终极个人云游戏平台5步完整配置指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考