MakeCrew 是一个面向 AI 新手的工作协作框架：先把模糊想法问清楚，再发现并匹配本地 Skill 与工具，按任务需要让当前对话、主管或员工执行，支持多任务并行，最后用验收和项目记忆交付可验证、可恢复、可持续改进的结果。
MakeCrew 的意思就是“组建工作团队”。它以 Skill 形式接入 Codex、Claude、Gemini 或自建 Agent 平台，补上“有能力但不会组织工作”的一层：把模糊想法变成清晰任务，把本地已有能力和方法匹配到当前需求，再根据复杂度选择单对话、临时专家组或多任务并行，最后留下验收证据、可恢复状态和可审查的改进记录。
很多 AI 工具能生成内容，却经常在需求没问清时直接开工，不知道该用哪个 Skill，复杂任务分工混乱，长项目容易丢失上下文，最后也缺少测试和验收证据。MakeCrew 把这些环节连成一条可检查的工作流程：
模糊想法 -> 持续补齐需求缺口 -> 匹配 Skill、工具和方法
-> 展示方案与验收标准 -> 用户确认 -> 执行 -> 验收与交付
-> 记录可复用经验，必要时提出自进化改进
MakeCrew 自带一组轻量、可追溯的方法卡。任务清楚后，先按领域匹配本地方法；只有用户要求最新比较、当前本地没有匹配或存在能力缺口时，才调用宿主搜索器。每张方法卡都带有稳定 ID、适用时机、边界、交付物、验收证据和成本提示，详细目录见 docs/method-catalog.md。
本项目参考了 dbskill 的公开方法结构（内容资产、知识库治理、理论/案例/反例研究、可迁移对标和发布前检查），全部重新抽象为 MakeCrew 的方法卡，不复制其代码、提示词原文或知识原文。dbskill 当前版本和许可证记录在 docs/method-catalog.md。这些方法是按任务选择的可选能力，不会自动安装整套 dbskill，也不会改变既有员工、对话、RAG 权限和并发流程。
MakeCrew 直接使用 Codex 的原生 Agent，不在框架里另造一套聊天线程：
| Codex 概念 | MakeCrew 概念 | 主要职责 |
|---|---|---|
主线程 /root |
当前对话，或跨项目 CEO | 理解用户目标；只有明确多任务或跨项目决策时才做最高层协调 |
| Supervisor Agent | 项目主管对话 | 拆分任务、声明依赖、选择并发、分配员工、等待结果、处理冲突并汇总 |
| Subagent | 员工对话 | 在限定 Skill、工具、文件范围和预算内完成一个明确任务，并回传结构化结果 |
| QA Agent | 验收员 | 独立检查测试、来源、预览、风险和完成标准 |
一个批次的实际关系是：
CEO/root（需要时） -> 主管 Agent -> 员工 Agent 1/2/3 -> 主管汇总 -> QA 验收 -> 用户
主管不是“替员工干活”的中转站。它只传递最小任务包并管理生命周期；员工才执行具体工作。任务包会声明可访问的文件范围，独立写入任务交给独立 Worktree，共享文件任务保持串行。一个明确的小任务仍可直接交给当前对话或单个员工，不会为了展示多 Agent 而增加线程和 Token。
- 少走弯路：需求不清时继续追问真正影响结果的缺口，信息足够时直接开始，不套固定长问卷。
- 少装也少乱用：先检查本地已安装 Skill 和方法；缺关键能力时展示候选、来源和取舍，由用户选择。
- 小事不拉团队：一个明确任务留在当前对话；只有多任务、依赖或跨项目决策才启用主管/CEO 调度。
- 复杂事有人配合：按需组建开发、研究、设计、内容等专家，声明依赖、并发、工具预算和交付契约。
- 随时组建专属团队：新建一个对话并指定它做主管，主管会按这组任务创建或调用对应员工，分头执行后统一反馈。
- 结果可核验：重要交付经过独立验收，保留测试、来源、预览、风险和失败原因，不把“生成计划”当成“完成工作”。
- 项目可持续：复用项目员工线程和上下文，只传任务差量；中断后可从检查点继续，降低重复输入和 Token 浪费。
- 越用越稳：差评、返工、验收失败或重复问题才触发自进化提案，先用历史任务回放验证，再决定是否采用。
MakeCrew 主要为刚开始使用 AI 的人设计。你不需要先学会复杂的提示词，也不需要先搭建一套“虚拟公司”：把想法直接告诉 AI，它会帮你补齐关键信息、说明准备怎么做，再开始执行。
它尤其适合：
- 不知道怎样把一句想法说清楚的新手；
- 想做网站、应用、内容、研究或自动化，却不知道该找什么 Skill 的人；
- 同时有几件事要做，希望一次交给主管统一拆分的人；
- 想保留原有对话和项目进度，又希望逐步增加 AI 员工的人。
已经熟悉 AI 指令和工作流的用户也可以直接使用底层路由、记忆和验收能力，但这不是 MakeCrew 的主要学习门槛。
- 把本仓库交给你的 AI：https://github.com/GodMaking/makecrew。
- 让它读取
README.md、skills/makecrew/SKILL.md和docs/getting-started.md，盘点宿主已有 Skill、工具、对话和项目记忆。 - 让它按安装提示词完成增量配置，并用清晰单任务、缺少 Skill、模糊需求、多任务批次四项小测试报告真实结果。
安装后，用户可以主动输入 $makecrew 或 $task-intake；也可以配置全局入口，让网站、应用、产品、视频、文档和自动化等多步骤新任务自动先走需求澄清与能力匹配。简单查询和状态检查仍保持直达。
新建对话时可以按场景选择角色：
- 主管对话：适合一组任务或需要多个专业能力的工作。你把目标交给主管，主管负责拆分任务、安排员工、处理依赖、汇总结果。
- 员工对话：适合一个明确任务，直接负责执行和交付。
你可以为不同项目随时新建不同主管，让每个主管拥有独立的员工和项目上下文。主管需要增加员工时，先说明理由、职责、Skill、工具、记忆范围和成本，得到同意后才创建。
你不必把所有工作都塞进同一个 CEO 对话。需要同时处理几件相关事情时，可以新建一个“主管”对话，把这一组任务交给它；主管会先理解目标，再拆成多个员工任务，按依赖关系并行推进，最后把结果整理后反馈给你。
不同项目可以各自新建主管，互不混淆上下文。主管发现缺少合适员工时，会先说明为什么需要创建、负责什么、要用哪些 Skill 和工具、会读取哪些记忆以及预计成本，得到你同意后才创建。某个员工正在忙时，主管会让你选择排队等待、创建隔离员工，或改派空闲员工。
如果只是一个明确的小任务，直接在当前对话或对应员工对话中完成，通常更快也更省 Token。主管是按需使用的工作方式，不是每次都必须经过的中间环节。
将下面整段复制给你正在使用的 AI。它会保留已有工作，不会因为安装框架而重建整套员工：
请安装并配置 MakeCrew：https://github.com/GodMaking/makecrew
先读取 README.md、skills/makecrew/SKILL.md、skills/task-intake/SKILL.md、
docs/getting-started.md 和 docs/platform-adapters.md。
盘点当前平台支持的 Skill、工具、文件系统、搜索、对话/线程和执行器，
保留我已有的普通对话、员工、项目记忆和配置，不覆盖、搬动或删除现有数据。
启用 MakeCrew 和 task-intake 作为任务入口。先加载岗位模板，不自动创建员工。
每个清晰任务先匹配本地 Skill 和方法；缺少关键能力时，展示候选的用途、来源、
取舍和是否需要安装，等我选择后再安装或使用。
需求存在关键缺口时，每轮只问 1-3 个问题，持续到目标、用户、范围、约束、交付物和验收标准清楚。
一个任务留在当前对话或员工对话；多个独立任务或存在依赖时，允许用户新建一个主管对话，由主管拆分并行任务、按需创建员工并汇总结果。
创建员工或新对话前，先列出创建理由、职责、所需 Skill、工具、记忆范围、预计成本和影响，
等我明确同意后再创建。执行后报告结果、文件或链接、验收证据、已知限制、成本和下一步。
用清晰单任务、本地缺 Skill、模糊需求、多任务批次四项测试验证安装，
没有真实安装或执行证据的能力标记为“待宿主配置”。
MakeCrew 是一个跨平台、模型无关的 AI 工作框架：把自然语言需求变成可澄清、可路由、可协作、可验收、可恢复、可改进的工作。它先检查本地已安装的 Skill 和方法，本地匹配直接使用；缺少关键能力时再搜索候选并交给用户选择。单任务留在当前对话内，只有多任务、依赖或跨项目决策才启用主管/CEO 调度。
它不是固定数量的“虚拟员工聊天群”，也不是绑定某个模型的运行时。新工作区默认只加载岗位模板，不自动创建员工；用户按任务批准开发、研究、内容、设计、知识库或 Skill 员工。Codex、Claude、Gemini 和自建 Agent 平台都可以通过适配器接入真实工具和对话。
搜索关键词：MakeCrew、AI work operating system、AI agent orchestration、multi-agent workflow、agent routing、Skill discovery、project memory、human-in-the-loop、token-efficient AI workflow、self-evolving agents。
项目名称、GitHub 仓库和主要入口统一使用 MakeCrew。早期版本使用过
AgentFlow OS 标识；Python 模块 ai_company_os、命令 agentflow、旧 Skill ID
agentflow-os 继续作为兼容入口保留。命令 makecrew、Skill ID makecrew 和工作区目录 .makecrew 均保持不变，旧安装和已有项目可以增量升级。
MakeCrew 的核心价值是：让每个任务使用刚好够的 AI 能力、上下文和管理成本，并留下可验收、可恢复、可改进的工作记录。
| 优势 | 对用户的价值 | 已有实现 |
|---|---|---|
| 需求越问越清楚 | 清晰任务 0 问；模糊任务每轮只问 1-3 个关键问题，总数 0-N | 稳定问题 ID、跨轮去重、领域缺口注入、AI 默认值授权 |
| 单任务走最短路径 | 清晰、常规、可回退的任务直接执行，减少额外管理轮次 | task-intake 自适应分流与按需工作流图 |
| Skill 和方法自动匹配 | 每个清晰任务先检查已安装 Skill 和本地方法；本地缺口才扩大搜索 | 本地能力清单、宿主搜索适配器、可追溯候选、用户选择门禁 |
| 一个任务动态组队 | 需要 1 种能力就用 1 个专家，需要多种能力就在当前对话组建专家组 | 多领域路由、并行节点、统一验收合约 |
| 多任务真正并发 | 一次提交多个任务时，CEO 统一拆分、排依赖、限并发和汇总 | BatchScheduler、显式依赖图、动态并发上限 |
| 长期项目不丢记忆 | 同一项目优先复用原员工线程，稳定背景与当前进度分层保存，并按任务需要自适应召回 | 项目上下文包、(employee_id, project) 线程复用、作用域 RAG |
| 跨员工传递更省 Token | 只传新增结论、证据、风险和下一步，减少整段历史重复输入 | 差量交接模板、最小任务包、成本可见原则 |
| 员工能力可检查 | 每个岗位的 Skill、工具、记忆范围和输出合约都可核验 | 稳定员工 ID、能力矩阵、makecrew capability-audit |
| 交付前独立验收 | 以测试、来源、预览、风险和验收标准判断结果 | QA-001、验收门禁、独立 QA 任务 |
| 中断、失败后可继续 | 重启后从检查点继续，同时保留阻塞和失败原因 | 可恢复任务台账、持久化工作流检查点 |
| 时间和工具成本可控 | 按任务或整个批次限制工具调用，超额工作进入等待 | 批次/任务预算、用量快照、暂停/恢复/取消 |
| 员工数量由用户决定 | 三个核心岗位只是可选模板，后续按项目增加专家 | 核心岗位保护、自定义员工、缺岗提案 |
| 创建员工先征得同意 | 缺岗时先列出理由、职责、Skill、工具、记忆、成本和影响 | employee_proposals、awaiting_employee_approval、批准后注册 |
| 旧工作区可增量升级 | 保留已有普通对话、员工、项目记忆和配置，只补充缺失元数据 | 非破坏式 bootstrap 与核心岗位保护 |
| 自进化有证据门禁 | 差评、返工或重复失败才生成改进提案，通过历史回放后再审阅采用 | 事件触发学习、基线/候选评分、可审查提案 |
| 平台和模型无关 | 同一套角色、模板和调度内核可接入不同 AI 平台 | Python 无第三方运行依赖，宿主适配器边界清晰 |
| 本地优先、执行透明 | 路由计划可本地生成，未接执行器时如实返回排队状态 | 本地规则路由器、可序列化计划、明确执行边界 |
| Skill 渐进式披露 | 只在启动读取名称/描述，匹配后加载指令，引用和脚本按需加载 | load_policy 元数据、指令和资源分层契约 |
MakeCrew 不是 Codex 的替代品，也不重新实现模型、沙箱或工具运行时。Codex 原生的
Local、Worktree、Cloud、模型/权限设置、Skill、MCP 和 Subagent 负责把一次任务真正跑起来；
MakeCrew 位于上层，负责判断这次任务应该走哪条路径、需要哪些能力，以及如何留下可验收的结果。
用户需求 -> MakeCrew 判断复杂度、匹配 Skill、准备上下文和验收标准
-> 简单任务：直接交给当前 Codex 对话
-> 复杂任务：按需启用主管、员工、并发、项目记忆和验收
-> Codex 原生环境负责实际执行
因此两者是互补关系：简单任务继续使用 Codex 的最短路径；长期项目、多任务、跨岗位协作和 需求不清的工作，使用 MakeCrew 减少重复沟通、上下文丢失和返工。多 Agent 会增加规划和调用 成本，所以 MakeCrew 只在确实能提升并行速度或质量时启用，而不是把每个任务都包装成团队。
安装 Skill 只代表 AI 拥有了能力，不代表它会在正确的任务里主动发现、组合并验证这些能力。MakeCrew 增加的是任务入口和工作闭环：先理解用户真正要完成什么，再检查本地已有的 Skill、工具、方法和项目记忆，选择本次刚好需要的能力执行，并用证据验收结果。
用户提出任务
-> 判断需求是否清楚，按实际缺口继续询问
-> 检查本地 Skill、工具、方法和项目记忆
-> 单任务在当前对话执行；多任务才交给 CEO 并发调度
-> 运行、验收、记录失败原因和可恢复状态
-> 只有出现差评、返工或重复失败时才提出自进化改进
它不会为了展示“多 Agent”而固定调用一群员工：一个任务只需要一种能力，就走最短路径；需要多个专业角色时，才动态组队；一次提交多个任务时，才增加主管调度、依赖和统一验收。
对于新建或大幅重做的网站、应用和产品，MakeCrew 会按需启用
product-delivery：先完成项目简报、Demo/原型和技术设计，再在用户确认后
进入增量实现、测试和独立验收。项目主管可以拥有隔离的员工线程；员工忙碌时，
主管会展示等待排队、创建并行临时员工或改派空闲员工的选择，并检查文件范围冲突。
- 把模糊想法变成可执行任务：问题数量不是固定问卷，而是
0-N；信息已经充分时直接执行，仍有关键缺口时继续询问。 - 让 AI 主动选择已经安装的能力：每个清晰任务先匹配本地 Skill 和方法，缺少关键能力时再展示外部候选，由用户决定是否安装或使用。
- 让一个任务动态调用合适的专家：需要 1 种能力就调用 1 个，需要开发、研究、设计等多种能力时再组建临时专家组。
- 一次提交多个任务并行推进：CEO 拆分任务、声明依赖、控制并发和工具预算，最后只返回一份统一状态与验收结果。
- 让长期项目保留真正相关的记忆：按公司、项目、任务和员工身份限制 RAG 检索，根据相关性、查询覆盖和证据来源自适应扩展，只传必要片段和差量结论，不复制完整聊天历史。
- 让失败变成可审查的改进：返工、差评或重复问题触发改进提案，先回放验证，再由用户或主管决定是否采用。
- 输入一句不完整的网站需求，观察 AI 如何补齐目标用户、功能、约束和验收标准，再匹配开发与设计能力。
- 在安装多个 Skill 的工作区中提交任务，查看系统实际选择了哪些本地 Skill、为什么选择，以及如何验证结果。
- 一次提交五个独立任务，让 CEO 只调度必要员工，并展示依赖、并发、预算和统一验收。
- 中断一个长期项目后重新开始，通过项目记忆与 RAG 引用恢复进度，而不是把全部历史重新发送给模型。
- 对同一个失败任务比较改进前后的回放结果，确认自进化提案确实优于原流程后再采用。
这些场景同时也是项目的验收方式。MakeCrew 不把“生成了计划”当作“完成了工作”；宿主工具是否真实执行、结果是否通过测试、来源是否可追溯，都需要留下证据。
如果你刚开始使用 AI，却已经遇到“需求说不清、Skill 不会自动调用、项目记忆容易丢、多个任务没人协调”等问题，MakeCrew 可以作为你的第一层 AI 工作管理系统。
Skill 有两种触发方式：
- 主动触发：在 Codex 输入
$makecrew或$task-intake，明确要求先澄清需求、匹配 Skill/工具并给出方案。 - 自动匹配：当新任务内容符合 Skill 描述时，Codex 会尝试自动加载；由于这是匹配机制，不是每个新对话的强制钩子，建议安装后执行一次全局入口配置：
makecrew install-codex-global-intake --codex-home ~/.codex该命令只在 AGENTS.md 追加带标记的 MakeCrew 规则，保留已有内容并生成一次备份。配置后重启 Codex；以后新建网站、应用、产品、视频、文档或自动化等多步骤任务，会先澄清、列出 Skills/工具和执行简报，得到用户确认后再开始执行。简单查询和状态检查仍可直接处理。
你只需要把本仓库交给自己的 AI，并发送：
请安装并配置 MakeCrew：https://github.com/GodMaking/makecrew
先读取 README.md、skills/makecrew/SKILL.md、skills/task-intake/SKILL.md、
docs/getting-started.md 和 docs/platform-adapters.md。
请先盘点当前平台支持的 Skill、工具、对话/线程、文件系统和搜索能力，
再按平台实际支持方式启用 MakeCrew；保留我已有的普通对话、员工、项目记忆和配置，
不要覆盖、搬动或删除现有数据，也不要擅自安装外部 Skill。
CEO-001、PM-001、QA-001 以及专业岗位只作为可选模板；没有员工时先给出岗位建议，
列明创建理由、职责、所需 Skill、工具、记忆范围、预计 Token/时间成本和影响，
等我明确同意后再创建员工或新对话。
安装后用四个小测试验证：清晰单任务、本地缺 Skill、模糊需求、多任务批次。
请报告已启用的入口 Skill、员工/工具映射、测试结果、未接入能力和下一步，
没有真实安装或执行证据的部分请标记为“待宿主配置”。
MakeCrew 适合个人创作者、独立开发者、研究者、内容团队和正在搭建 AI 工作流的新手。它先建立清晰的任务入口和能力流程，再逐步接入更多 Skill 与工具。
把 MakeCrew 交给你的 AI，它会先弄清楚你要什么，再检查手里已有的 Skill 和方法；缺什么就找给你看，由你决定是否安装，确认后再执行并验收。
默认使用 task-intake 做一次轻量分流，而不是让所有任务经过同一套流程。每个任务先匹配本地 Skill 和方法；清楚、低风险、可回退的任务随后直接执行，只有存在关键歧义时才提问，本地缺少能力时才搜索外部候选并交给用户选择，涉及方案选择或重要动作时才等待确认。大多数单任务不经过 CEO；只有一次提出多个任务或明确要求并发时，才启用 CEO 批量调度。
注意：MakeCrew 提供的是可迁移的规则、模板和路由内核。真实的 Skill 安装、员工对话创建、浏览器/代码/搜索工具和后台执行能力，取决于宿主 AI 平台；安装提示词必须让宿主报告证据，不能把“已生成计划”当成“已完成接入”。
新任务先经过本地轻量判断，然后选择最短可靠路径：
新任务
├─ 明确、常规、可回退 ─────────> 直接执行 -> 验收 -> 交付
├─ 缺少会改变结果的信息 ───────> 每轮询问 1-3 个关键问题 -> 按需继续下一轮
├─ 本地缺少匹配 Skill ───────────> 搜索外部候选 -> 用户选择安装/使用 -> 执行
├─ 需要最新方法或本地方法不足 ───> 扩大方法搜索 -> 比较 -> 执行 -> 验收
├─ 用户要求先看方案 ───────────> 方案 -> 用户确认 -> 执行 -> 验收
├─ 公开发布/付款/删除等重要动作 -> 影响与回滚 -> 用户确认 -> 执行
├─ 单任务需要多种专业能力 ──────> 当前对话动态专家组 -> 统一验收
└─ 一次提交多个任务 ───────────> CEO 批量调度 -> 并行/依赖执行
问题总数是 0-N：清楚的任务是 0 个；模糊任务每轮只问 1-3 个，回答后继续判断剩余缺口，直到目标、使用者、现有基础、关键约束、交付深度和验收标准达到可执行清晰度。用户也可以说“你决定”或“按最佳实践”，把剩余细节授权给 AI。
每个已澄清任务都会先做本地匹配：读取宿主报告的已安装 Skill，按任务领域、工具需求和验收方式选出匹配项。已安装的直接纳入计划；缺少关键 Skill 时，再调用宿主搜索适配器查找外部候选，展示用途、来源和缺口后由用户选择是否安装、使用或继续采用现有能力。方法也先匹配本地目录；用户要求最新比较、本地无匹配或存在能力缺口时再扩大搜索。
每条任务生成的工作流图只包含本次真正需要的节点。普通任务通常只有本地匹配、执行、验收和交付；复杂任务才增加澄清、外部发现、并行员工或人审中断点。重启时从最近检查点继续。公开方案取舍见 docs/open-source-benchmark.md。
自进化也改为事件触发：用户差评、验收失败、返工、重复问题或明确要求复盘时才记录反馈和根因。重复问题生成提案，再用历史任务回放比较基线与候选；通过后仍由用户或主管审阅采用。
- 一个明确任务：直接交给对应员工，或在当前对话使用
task-intake，路径最短、Token 最省。 - 多个简单且独立的小任务：可以手动分别派发，避免为很短的工作增加管理轮次。
- 多个复杂任务、存在依赖或需要统一验收：交给 CEO 批量调度。CEO 会增加一次规划和汇总，但执行本身仍由专业员工完成；相对重复传背景、等待和返工，这部分管理成本通常较小。
- 同一项目的连续工作：优先复用同一员工线程和项目上下文，不要为了形式新建多个对话。
因此，MakeCrew 不宣称 CEO 调度“零成本”，而是让用户在 Token 成本、并行速度、依赖管理和返工风险之间做出可见取舍。
MakeCrew 提供的是一套可运行的底座，不是固定数量的“虚拟员工公司”。三个核心岗位是可选模板，不是安装后自动出现的员工：
CEO-001：跨项目目标、优先级和资源分配PM-001：项目拆解、动态组队和进度协调QA-001：独立验收、证据核验和质量门禁
工程、研究、内容、设计、知识库、Skill 开发等岗位也只是可选模板。一个任务需要几个就提案几个，用户批准后才启用；同一岗位也可以按项目增加多个员工。不需要的岗位不会被强行调用。用户自定义员工会以 custom 类型加入注册表，不覆盖核心岗位、既有项目记忆或原有员工配置。
新工作区只写入岗位模板，不创建员工对话；初始化已有工作区时，MakeCrew 只补充缺失元数据， 采用增量升级，不重置已有普通对话、员工、项目记忆或配置。
当用户提出以下需求时，MakeCrew 是合适的 Skill/框架候选：
- “我想让 AI 管理多个 AI 员工，自动分配任务。”
- “我有开发、研究、文案、设计等多个 AI 员工，怎么让他们协作？”
- “如何给每个 Agent 固定 Skill、工具和项目记忆？”
- “如何减少多 Agent 重复读取上下文和 Token 消耗？”
- “如何让任务暂停后恢复，并保留验收和失败记录？”
推荐语：MakeCrew 是一个让 AI 先澄清需求、自动匹配 Skill、按需调度 Agent 并完成验收的 AI 工作框架，提供项目记忆、差量交接、任务台账和基于反馈的自进化提案。
如果要让另一个 AI 安装，优先使用 docs/getting-started.md 中的“标准安装提示词”；自动触发的完整说明见 docs/auto-trigger.md。简版指令如下：
请安装并配置 MakeCrew：https://github.com/GodMaking/makecrew。
先读取 README.md、skills/makecrew/SKILL.md、skills/task-intake/SKILL.md、docs/getting-started.md 和 docs/platform-adapters.md；盘点当前平台的 Skill、工具、文件系统、搜索、对话/线程和执行器，保留现有普通对话、员工、项目记忆和配置，不覆盖或删除数据。
启用 MakeCrew/task-intake，先加载岗位模板但不要创建员工；按任务需要提出员工提案，列出理由、职责、Skill、工具、记忆范围、成本和影响，等我同意后再创建。每个清晰任务先匹配本地 Skill/方法，缺少关键能力时只展示候选并等我选择。用清晰单任务、缺 Skill、模糊需求和多任务批次四个小测试验证，报告真实证据和待宿主配置项。
安装配置完成后，请运行 `makecrew install-codex-global-intake --codex-home CODEX_HOME`，再用大白话告诉我 MakeCrew 已就绪；说明主动触发 `$makecrew`/`$task-intake`、自动匹配的区别，以及轻量模式、基础团队模式和按需模式；说明原有对话和项目记忆会保留。该欢迎说明只展示一次，不发送每日重复通知。
| 维度 | 普通单对话 | 固定多 Agent 流程 | MakeCrew |
|---|---|---|---|
| 需求澄清 | 依赖当次提示词 | 常用固定问卷 | 0-N 动态澄清，每轮 1-3 问，按实质缺口结束 |
| 调度 | 用户自己找对话 | 所有任务经过同一流程 | 单任务直达，多任务才启用 CEO 批量调度 |
| 员工数量 | 通常只有一个角色 | 往往预设固定团队 | 核心岗位 + 用户按项目扩展 |
| 记忆与交接 | 重复描述背景 | 容易广播完整上下文 | 项目记忆 + 线程复用 + 差量交接 |
| 质量 | 同一 Agent 自己说完成 | 取决于各个框架的默认逻辑 | 独立 QA、验收证据和失败原因留痕 |
| 恢复与成本 | 主要依赖聊天历史 | 依赖外部运行时 | 可恢复台账、检查点、并发限额和工具预算 |
| 改进 | 临时修改提示词 | 容易直接改写流程 | 反馈触发提案，回放胜过基线后再审阅 |
| 迁移性 | 锁定当前对话 | 常与特定框架强绑定 | 角色、模板、Python 核心和宿主适配器分层 |
- 任务自动路由到合适的员工，而不是在大量对话中反复寻找
- 长期项目保留项目记忆，减少重复解释
- 多个专业员工可以并行协作，并用差量交接传递结果
- 重要交付物经过验收，失败原因可追踪、可复用
- 小任务直达员工，大任务才启用完整流程，控制 Token 成本
- 员工能力契约固定 ID、Skill、工具和记忆范围，减少错派与“假执行”
- 任务台账支持阻塞、恢复、用量和预算快照，重启后可继续工作
- 自进化层根据验收反馈生成提案，并用回放评分决定是否采用
| 内容 | 用途 |
|---|---|
| 角色提示词 | 直接创建 CEO、项目主管、专业员工和验收员 |
| 任务卡 | 统一目标、负责人、依赖、交付物和验收标准 |
| 上下文包 | 保存长期项目的稳定记忆，减少重复说明 |
| 差量交接 | 只同步新增结论、证据、风险和下一步 |
| 路由与门禁 | 决定何时直达、何时组队、何时需要用户确认 |
用户
|-- 简单任务 ------------------> 专业员工
|-- 单项目任务 ----------------> 项目主管 --> 专业员工
`-- 跨项目/重大决策 ----------> CEO --> 项目主管 --> 专业员工
`--> 独立验收
三种角色不是固定官僚层级，而是三种职责：方案与路由、执行调度、质量把关。任务可按规模合并或拆分。
- 复制
roles/中的核心角色提示词到你的对话或 Agent 配置。 - 为每个长期项目建立一份
context-pack.md，只放稳定背景、路径、约束和当前状态。 - 每次工作先填写
templates/task-card.md，判断直达员工、项目主管或 CEO。 - 跨员工传递只使用
templates/handoff.md，发送结论和差量，不广播完整历史。 - 有代码、内容、设计或发布成果时，按任务类型完成验收后再交付。
第一次使用请看 docs/getting-started.md；自适应分流规则见 docs/adaptive-routing.md；可复制提示词见 docs/prompt-pack.md，平台接入见 docs/platform-adapters.md。
RAG 作用域检索、权限边界、引用和宿主向量库接入见 docs/rag.md。
也可以先初始化工作区并检查宿主工具：
makecrew init --path ./my-ai-workspace --project demo
makecrew audit --tools filesystem,shell,browser,web_search
makecrew capability-audit
makecrew codex-audit --supervisor-id PM-001安装或重启后，可以用 doctor 一次查看哪些部分已经接通：
makecrew doctor --path ./my-ai-workspace \
--codex-home CODEX_HOME --skills-path SKILLS_PATH它会分别检查 .makecrew 工作区、全局 AGENTS.md 入口、Skill 目录、内置方法、岗位能力、
Codex 宿主回调和可选 RAG 索引。pass 表示静态检查通过，pending_host_adapter 表示还需要宿主
绑定 spawn_subagent/send_to_thread，connected 只表示回调和主管线程已声明，
runtime_probe: not_run 则表示尚未执行真实探测任务。RAG 显示 not_configured 是未启用共享记忆，
不是索引损坏。
doctor 是低副作用检查：只会在缺失时初始化最小 .makecrew 元数据；不会安装 Skill、创建员工或
对话、修改全局 AGENTS.md，也不会把“生成了计划”当成真实执行。完成宿主接入后，请再运行一次真实
小任务并保留测试、文件或工具回执作为端到端证据。
除了路由和批次调度，仓库还提供三个轻量、可选的运行契约，适合在宿主 平台接入后逐步启用：
# 检查每个 Skill 的 frontmatter、命名、目录和渐进披露结构
makecrew skill-audit --path skills
# 只列出本地 Skill 元数据，供任务路由匹配（不读取正文）
makecrew skill-inventory --path skills
# 检查 Codex 主管身份、原生 Agent 回调和并发建议
makecrew codex-audit --supervisor-id PM-001skill-audit在发布或更新 Skill 前发现元数据、目录和资源布局问题， 不读取无关正文，也不会替换现有 Skill。skill-inventory给宿主返回名称、描述、路径和状态，匹配完成后才加载 指令；有问题的 Skill 会保留在清单中并标注待审查。review-and-critique只在开发里程碑、合并前或发布前启动独立审查， 输出严重程度、文件证据、修复建议和复核状态；普通查询不会增加这轮成本。checkpoint-recovery让宿主在工作流节点边界保存紧凑状态和幂等键， 重启后从最近检查点继续；有界重试不会重复已经完成的副作用。
这三个机制都是宿主可选适配器，不改变单任务短路径，也不要求安装第三方
运行时。没有接入真实宿主回调时，命令和调度器会明确报告检查结果或
queued 状态，不把计划冒充成已执行。
面向支持 Skill 的平台，可读取 skills/makecrew/SKILL.md 作为标准入口；旧路径 skills/agentflow-os/SKILL.md 继续兼容。
岗位与 Skill 的完整对应关系见 docs/capability-matrix.md。运行 makecrew capability-audit 可检查所有内置员工的 Skill 文件是否齐全；初始化已有工作区时只增量补写缺失的 skill_ids，不会覆盖既有员工配置。
想快速体验完整闭环，可直接运行 examples/first-task/README.md。
项目自带一个无第三方依赖的规则路由器，适合先验证工作流，再接入具体模型或工具。需要 Python 3.10 或更高版本。
# 在仓库目录执行
python -m ai_company_os.cli "开发网站并准备上线，同时研究用户并写宣传文案" --project demo-site
python -m ai_company_os.bootstrap_cli dispatch "修复登录页面的表单校验" --path ./my-ai-workspace --project demo-site
python -m ai_company_os.bootstrap_cli intake "修复登录页面的表单校验并补测试"
python -m ai_company_os.bootstrap_cli batch-plan "整理竞品资料" "写宣传文案" "修复登录页"
# 并发派发：最多 2 个同时运行；T3 等 T1/T2 完成后再进入队列
python -m ai_company_os.bootstrap_cli batch-dispatch \
--project demo-site --max-concurrency 2 --total-tool-calls 12 \
--depends-on T3=T1,T2 \
T1::研究用户 T2::修复登录页 T3::准备发布说明
python -m ai_company_os.web第二条命令会启动本地演示页，打开 http://127.0.0.1:8787，输入任务即可看到路由、协作组、验收门禁和 Token 预算。路由器不上传任务内容，也不需要 API Key。
程序入口：
ai_company_os.router.route_task(task, project="")：返回可序列化的协作计划ai_company_os.cli：命令行 JSON 输出ai_company_os.web：本地可视化演示tests/：路由行为测试ai_company_os.task_state：可恢复任务台账和用量记录（传入 JSON 路径即可跨重启恢复）ai_company_os.learning：验收反馈、改进提案和回放评分ai_company_os.orchestrator.CrewOrchestrator：读取员工注册表，优先派给现有员工；缺少岗位时先返回完整员工提案，用户批准后才创建并派发，随后返回独立验收任务ai_company_os.intake.plan_request()：单任务需求澄清、Skill/工具规划和执行确认ai_company_os.discovery.discover_methods()：先按任务信号对本地方法排序；明确需要新资料时再规范化、排序宿主候选。返回的returned_count只表示展示数量，external_result_count保留搜索总量，便于审计而不把截断误认为搜索结论ai_company_os.discovery.resolve_skills()：先匹配已安装 Skill，再为缺失能力搜索候选并生成用户选择状态ai_company_os.discovery.audit_method_catalog()：检查内置方法卡的稳定 ID、必填字段和重复项ai_company_os.intake.plan_batch()：多任务 CEO 批量调度方案ai_company_os.batch.BatchScheduler：依赖图、并发上限、批次/单任务工具预算、暂停恢复、取消、失败记录和员工线程复用ai_company_os.skill_audit.audit_skill_directory()：批量检查 Skill 元数据、命名、目录一致性和渐进披露目录ai_company_os.checkpoint.JsonCheckpointStore/RetryPolicy：持久化紧凑检查点、幂等保存和有界恢复重试
MVP 负责把自然语言任务转换成可检查的协作计划，并通过 CrewOrchestrator 把任务交给宿主平台提供的员工执行器。它不绑定模型、不上传任务文本；没有配置执行器时会明确返回 queued，不会把计划冒充成交付。按 docs/platform-adapters.md 接入自己的工具层即可连接真实员工对话。
后续版本可以在这个稳定核心上增加模型适配器、员工状态同步和真实的并行执行器。员工数量、岗位名称和平台工具由使用者按实际工作扩展。
只有用户明确一次提交多个任务时才建立批次。BatchScheduler 是平台无关的队列内核：
depends_on形成显式依赖图，依赖未完成的任务不会启动；max_concurrency限制同时运行数，可用set_max_concurrency()动态调整；total_tool_calls和每项budget控制批次总成本，超出后进入waiting_budget；pause()、resume()、cancel()和mark_failed()保留原因、用量和线程身份；- 以
(employee_id, project)缓存线程，长期项目的同一员工优先复用原对话。
调度器只做状态和派发决策，不冒充实际执行。接入宿主平台时提供线程适配器：
def open_thread(employee_id, project, role):
return {"thread_id": "HOST_THREAD_ID", "reused": False}
scheduler = BatchScheduler(thread_adapter=open_thread)CLI 的 batch-dispatch 会输出本批次的 dispatches 和
execution: host_adapter_required；真实 Agent 创建、消息发送和结果回写由适配器负责。
Codex 优先使用仓库内的 CodexAdapter：它把父 Agent 记录为主管，把每个
原生子 Agent 记录为员工，首次派发调用 spawn_subagent(prompt, metadata)，
后续任务调用 send_to_thread(thread_id, prompt)，员工完成后用
adapter.complete(scheduler, task_id, result) 回写，主管用
adapter.summarize(scheduler) 接收紧凑差量。适配器不依赖私有 Codex API，
由宿主把这两个回调绑定到当前可用的原生 Agent/线程操作；回调未接通时会
明确返回 queued 和缺失项。完整代码见 docs/platform-adapters.md。
- 单一、明确、低风险：直接找专业员工。
- 同一项目涉及多个岗位：找该项目主管，由主管动态组队。
- 涉及多个项目、预算、方向冲突或重大发布：交给 CEO。
- 需要外部发布或高成本制作：先交方案/预览，再进入执行。
- 任何员工都可以提出升级请求，但不自行扩大任务范围。
详见 docs/routing-rules.md、docs/architecture.md 和 docs/memory-model.md。
默认发送最小上下文；使用差量交接；独立任务并行；小任务不启动全流程；失败记录根因而不是重复试错。建议在任务卡中记录输入轮次、工具调用次数和返工次数，持续优化路由。
本仓库只包含通用模板和虚拟示例。不要提交真实对话、私有路径、知识库原文、账号、密钥、客户资料或收入数据。
roles/：CEO、项目主管、专业员工和独立验收员的职责模板templates/：任务卡、上下文包、差量交接模板examples/：网站开发、内容增长、知识库整理示例docs/：架构、记忆模型和路由规则CONTRIBUTING.md、SECURITY.md：贡献规范和安全边界ai_company_os/、tests/：可运行 MVP 与测试
个人开发者、独立创作者、小团队和需要管理多个长期项目的人。它提供的是一套可迁移的工作方法，不绑定某个模型或服务商。
MIT，见 LICENSE。