Loadout 上下文装备器
按项目、机器或任务为编程智能体自动装配合适的上下文与工作流。
按维度查看评分与理由
README 明确说明仅写入本地、gitignored 的覆盖文件，不修改共享指令文件，并描述 localhost UI、暂存差异、原子写入、环境变量白名单、敏感名称拒绝、令牌脱敏、脚本信任存储、dry-run、doctor 和 clean；npm 流程还检查非交互环境不会静默安装。这些证据支持较好的最小权限、确认、外部影响披露和恢复能力。扣分在于未提供 security.md、安装器、同步及自更新实现，无法核实网络端点、命令执行沙箱、秘密检测覆盖面或所有写入路径；curl-to-shell、动态 shell 片段、自动拉取配置和自更新均扩大供应链与执行面。Cargo 依赖使用宽泛版本要求，GitHub Actions 以可变主版本标签引用，所给材料没有依赖审计、校验和或发布签名证据。作者、仓库、MIT 版权和借鉴的工作流有基本归属，但 vendored 内容的逐项来源与许可未在材料中展示。
README、Cargo 清单和 CI 对 Rust CLI、命令名、平台及测试入口总体一致；CI 覆盖格式、Clippy、Linux/macOS 测试、浏览器冒烟和 MSRV。命令表、doctor、explain 以及 npm 的礼貌拒绝测试表明重视可诊断失败。扣分是未提供实现、锁文件和测试正文，无法静态确认依赖可取得性或错误信息质量；Cargo 注释称部分 studio 能力将在后续切片接线，而 README 将其描述为当前功能，形成轻微一致性疑问。Windows 仅通过 WSL，git、浏览器和外部代理程序也属于明确但未自动解决的运行依赖。
材料对 Rust、Node、Next.js、Go、Python 等栈、无仓库机器场景、五类代理、CLI/VS Code、全局与项目配置以及自定义工作流给出了清晰场景，因此受众和场景覆盖充分。确定性目标匹配、恰好一个 loadout、多重匹配时询问并记忆、无匹配时默认或为空，使触发规则很精确。扣分在于动态 shell provider、工作流只是指导而非强制策略、generic 需要用户自行接线等边界虽有说明但未完整展开；仅支持 macOS/Linux，Windows 依赖 WSL，部分代理接线需要全局 hook、环境变量或本地文件。
README 信息架构完整，包含快速开始、模型、工作流、支持矩阵、目录、命令、安全、安装和文档索引；安装渠道、源码构建、更新方式和平台要求写得具体，示例丰富。MIT 文本与 Cargo 元数据一致，许可项可给满分。扣分在于 load/loadout、冒号与短横线命令、不同代理文件名等命名存在必要但增加认知负担的差异；限制散布在各节而非集中清单。Cargo 提供 0.28.0 且 README 链接 Releases，但材料中没有 CHANGELOG、版本策略或迁移政策。维护责任仅能从 Ellery Familia 的版权、包命名和仓库地址推断，未见维护者名单、支持渠道或安全报告路径；发布者未验证本身不作负面推断。
输出是各代理可直接读取的覆盖文件，并提供 explain、preview、plan HTML、结构化反馈和跨代理工作流，具有较高可用性；将个人上下文与仓库指令分离、按栈自动选择并统一多代理工作流，显示出相对普通静态指令文件的实际增量价值。扣分在于价值和成本主要由 README 陈述，缺少实现或对比证据；用户需要维护全局 TOML、信任动态脚本、处理代理特定接线，并承担 git 同步、自更新及多个生成文件带来的复杂度。
主要功能声明对应具体命令、路径、配置示例、选择规则和 CI 作业，Cargo 元数据与 README 的产品定位和许可互相印证，npm 发布流程也佐证交互式安装意图。扣分在于未提供核心源码、Cargo.lock、security/concepts 文档、测试内容、发布配置或安装脚本，所以安全、确定性、字节一致渲染、自动接线及同步行为无法追溯到实现。文档通常区分了指导与强制机制，但诸如“never touched”“byte-identical”和“only official sources”等强断言没有在所给材料中获得独立佐证。
- 安装方式包含从 latest GitHub Release 执行远程 shell 脚本；在采用前应固定版本并核验安装脚本、产物校验和或签名。
- 动态 fragment 可以运行 shell 命令，且同步与自更新会访问外部来源；应审查 security.md 和实现，并限制获信任脚本及同步仓库。
- 未提供 Cargo.lock、核心源码或测试正文，不能从本次静态材料确认依赖解析、安全控制、覆盖文件接线或回滚行为。
- 不同代理会修改不同的本地或全局接线位置；首次使用前应通过 dry-run 和 load explain 核对准确写入范围，并保留原配置备份。
- 发布者身份未知；这不是恶意信号，但组织采用时应独立确认维护、安全报告和发布密钥责任。
这个 Agent 能做什么，适合哪些场景？
Loadout 是一个用 Rust 构建的本地 CLI 和上下文引擎，负责为不同开发场景选择并生成编程智能体指令。用户在全局 TOML 配置中维护可复用的 fragments、由多个 fragments 组成的 loadouts，以及可选的六阶段 workflow。运行 `load claude`、`load codex` 等命令时，它检测当前项目或机器类型，确定唯一 loadout，并把渲染结果写入各智能体支持的本地、已忽略文件。它原生适配 Claude、Codex、Cursor、opencode 和 Copilot，并为其他工具提供仅输出的 generic 模式；整个选择过程是确定性的，不由模型决定。项目还包含本地主机 Web 编辑器 `load studio`、配置同步、诊断与信任管理，以及把结构化开发计划渲染成自包含 HTML 的审阅工具。它不会修改仓库中已提交的 `AGENTS.md`、`CLAUDE.md` 或 Copilot 共享指令文件，部署边界主要是用户机器上的全局配置和每个仓库的 gitignored 文件。
Loadout 读取 ~/.config/loadout/config.toml 中的 fragments、loadouts、targets 和 workflows，并可读取不参与同步的 local.toml 机器信息。load <agent> 检测 Rust、Node、Bun、Next.js、Go、Python、Java、Ruby、PHP、Swift、.NET 或无仓库的 machine 环境；若多个 loadout 匹配，它询问一次并为该项目记住选择。随后它执行静态、内置 provider 或经批准的 shell 动态 fragment，渲染 overlay，并通过各产品的本地机制接入：Codex 使用 .loadout/generated/agents.md 和 AGENTS.override.md，Claude 使用 .loadout/generated/claude.md 和 CLAUDE.local.md，Cursor 使用 .cursor/rules/loadout.mdc，Copilot 使用 gitignored instructions 或 CLI 环境变量，opencode 使用全局 instructions。load studio 提供 localhost 可视化编辑、预览和应用差异；load explain、refresh、clean、detect、doctor 与 trust 分别用于解释选择、重建或清理输出、检测环境、诊断问题及管理脚本信任。load plan check 校验智能体生成的 plan.json，load plan render 则生成字节确定、自包含且可逐项评论的 plan.html。
- 同时维护 Rust、Next.js 和 Python 项目的开发者，希望进入不同仓库时自动切换编码约定、工具命令和沟通风格。
- 在 Claude Code、Codex、Cursor、opencode 与 Copilot 之间切换的团队成员，希望复用同一套个人上下文，而不分别维护多份指令。
- 经常登录裸服务器或运维主机的工程师，需要在仓库之外通过 machine loadout 装配系统管理或 DevOps 指引。
- 已有全局
CLAUDE.md或AGENTS.md的用户，希望借助loadout-migrate将其拆成可复用 fragments，同时保留原文件。 - 采用 Superpowers、Spec Kit、Kiro 或 Every compound engineering 流程的开发者，希望把过程映射到统一的 explore、brainstorm、plan、implement、verify、ship 命令。
- 需要在实施前审阅复杂开发计划的负责人，可将
plan.json渲染成离线 HTML，对任务、阶段、风险和开放问题逐项反馈。
这个 Agent 有哪些优点和局限？
- 同一套 fragments 和 loadouts 可投递到五种明确支持的编程智能体，并提供 generic 输出模式，减少跨工具重复维护。
- 选择算法是确定且可通过
load explain检查的；多重匹配只询问一次并为项目保存选择，不依赖模型自行判断。 - 只写入本地 gitignored overlays、bindings 和托管块，不改动团队已提交的
AGENTS.md、CLAUDE.md或 Copilot 指令。 - 既支持静态指导，也支持内置 provider 和受信任 shell 输出，并配有环境变量白名单、敏感名称拒绝、令牌脱敏及原子写入。
- 包含可视化配置工作室、跨机器 Git 同步、迁移技能和确定性计划预览，覆盖配置、迁移与审阅流程。
- 每个上下文只会启用一个 loadout；loadouts 不能叠加，用户必须在选中的 loadout 内手工组合所有 fragments。
- 生成的 overlay 只是智能体会读取的指导，不是运行时强制策略，无法保证模型严格遵循。
- 官方预编译安装仅覆盖 macOS 和 Linux；Windows 用户需要 WSL，且没有官方 Homebrew tap。
- 不同产品的接入方式并不统一，例如 Cursor 和 VS Code 的 workflow 命令使用短横线，而其他场景使用冒号，团队需要理解这些差异。
- 全局配置同步依赖 Git；动态 shell fragments 还引入脚本审批、重新信任和本机安全管理成本。
如何安装或部署这个 Agent？
官方预编译安装适用于 macOS 和 Linux；Windows 需使用 WSL：
curl -LsSf https://github.com/elleryfamilia/loadout/releases/latest/download/loadout-installer.sh | sh如果已有 Node.js，也可运行会先征求同意的 npm 引导程序：
npx @ellery/loadout studio源码安装命令为：
cargo install --git https://github.com/elleryfamilia/loadout安装不需要 API 密钥。预编译与 npm 方式需要网络；源码方式需要 Rust/Cargo。配置同步另需 Git，且精简系统可能要先执行 apt install git。
如何使用这个 Agent？
首次使用可运行 load studio，在本地主机界面中选择推荐的 starter pack，检查暂存差异后应用。也可以直接编辑 ~/.config/loadout/config.toml，例如创建含 guidance 的 fragment，再创建带 targets = ["rust"] 和 fragment 列表的 loadout。用 load explain 检查检测结果、选中的 loadout、活动 fragments 和预期写入位置；确认后执行 load claude、load codex、load cursor、load opencode 或 load run copilot 启动对应工具。使用 load use <loadout> 可固定当前项目的选择，load refresh --agent all 可只重建 overlays，load doctor 可检查配置、忽略规则和安全问题。需要跨机器共享时，在有 Git 的系统上运行 load sync init，或用 load sync init <git-url> 关联仓库，再在其他机器执行 load sync clone <git-url>。
这个 Agent 与同类方案有什么区别？
与把所有个人偏好写进每个项目的 AGENTS.md、CLAUDE.md 或 Copilot 共享指令相比，Loadout 将个人上下文保存在全局配置中，并按技术栈、机器或项目选择后写入本地 gitignored overlay。项目指令描述仓库本身，Loadout 则承载用户跨仓库带来的约定、工具和表达方式。其 workflow 还可采用 Superpowers、Spec Kit/Kiro 或 Every compound engineering 的流程内容，但统一暴露为六个 Loadout 阶段命令；这些是被建模和装配的流程，不是独立执行引擎。
常见问题
使用 Loadout 是否需要模型 API 密钥或付费服务？
它会覆盖团队仓库里的指令文件吗？
AGENTS.md、CLAUDE.md 或 .github/copilot-instructions.md，而是使用 AGENTS.override.md、CLAUDE.local.md、.loadout/ 或其他 gitignored 路径。如果多个 loadout 同时匹配怎么办？
动态 shell fragment 有哪些安全边界？
--dry-run。不过生成内容仍只是智能体指导，不构成强制安全策略。能否在多台机器共享配置而不泄露主机私有信息？
load sync init 和 load sync clone 通过 Git 同步全局配置；主机名、主机类别和机器专用值放在不会同步的私有 local.toml 中。