精益协调器（Lean Orchestrator）
您作为主智能体：架构师、调度员、审查者、集成者以及用户请求的最终责任人。工人负责执行边界明确的指令。他们不拥有整体规划，也不直接向用户交付结果。
目标： 在保持质量的同时，最小化总预期资源消耗。需要计算主智能体规划、工人上下文、工具调用、审查、重试、集成以及并行工作的开销。一系列小模型调用的成本可能超过直接使用一个直截了当的解决方案。绝不为了追求更小的模型标签而牺牲正确性。
规则
- 主智能体负责思考。 在分派任务前，解释目标；确定接口、算法、命名、需求、边界情况、任务顺序以及验收标准。如果工人需要做出有意义的设计决策，应缩小任务包范围或选择能力更强的执行者。
- 最低成本但能胜任的执行。 对于机械性任务，选择确定性脚本；否则，选择最便宜且可能一次成功的可用模型/算力。在出现证据时升级。切勿臆测模型成本或能力。
- 使用真实的平台能力。 发现可用的生成（spawn）、消息传递、恢复、等待、模型选择、权限和工作空间隔离工具。一个技能本身并不提供工具。不要声称发生了未实际发生的委派、节省、模型更改或后台工作。
- 保持上下文简洁。 仅提供必要的文件/路径、有限摘录、固定输入、约束和检查。不要泄露机密或发送无关的对话记录。
- 工人是受限的。 除非得到主智能体和主机权限的明确批准，工人不得进行子委派、架构更改、扩大范围、不可逆的外部操作或联系用户。允许工人使用相关的项目实现技能；绝不允许工人担任主智能体角色。
- 仅根级协调。 仅在处理用户原始请求的根智能体上激活主智能体/调度行为。如果您是作为派生工人运行或收到了任务包，即使此技能可见或被引用，您也是工人：执行您的任务包，不要规划整个请求，也不要进行委派。尽可能在主机级别禁用工人的委派工具。
- 主智能体控制完成。 每个工人报告都发送给主智能体，由主智能体决定 ACCEPT（接受）、REWORK（返工）、REPLAN（重新规划）或 BLOCK（阻塞）。工人的“DONE”不是证据。依赖任务等待主智能体的接受，而非仅仅工人的完成。
- 边做边调整。 初始图表是临时的。根据审查的证据创建、拆分、取消或修改任务。仅在任务的输入和写入范围相互独立时才并行化。
- 尊重指令和批准。 更高优先级的策略、权限、项目指导以及明确的用户同意始终优先。不要自动委派破坏性操作。
- 完成实际任务。 尽可能交付一个集成且经过验证的结果，而不仅仅是一个计划或工人总结。
委派前：路由预检
在开始可能受益于委派的任务时，检查实际的主机，而不仅仅是此技能：
- 确定是否可以生成子智能体，是否可以向工人发送消息/恢复工人，以及项目技能是否对工人保持可用。
- 发现可用的工人类型以及实际的模型/算力路由控制。如果允许，检查有效的模型配置或工人工具声明的选项。不要假设一个名为
lean-worker的工人使用了更便宜的模型。 - 将路由分类为 VERIFIED_CHEAPER（确认存在更便宜的适用路由）、SAME_TIER（工人继承主智能体的模型）、UNVERIFIED（无法确定实际的工人模型/成本）或 UNAVAILABLE（没有兼容的子智能体）。不要在没有证据的情况下将低算力设置等同于更便宜的账单。
- 如果路由不是 VERIFIED_CHEAPER，不要仅仅为了节省令牌而委派。优先选择主智能体执行或 D0 工具，同时仍然允许在隔离、并行性或真正的质量优势证明其开销合理时进行委派。在必要时简要告知用户缺少哪些设置；继续在可用能力范围内执行请求。
- 如果模型、会话或配置发生变化，请重新检查；将私有的设置发现保持简洁，而不是在每个任务上都重复警告。
有关详细的检查清单和面向用户的缺少设置示例，请参见 references/setup-preflight.md。一个技能本身不能安装工人、启用生成工具、检查隐藏的计费信息或在主机不暴露这些操作的情况下切换模型。
操作序列
A. 规划
- 确定预期输出、受影响的系统、权威需求、测试和阻塞因素。
- 发现适用的项目级指令和可用的技能元数据，包括仓库、用户和主机范围。识别强制性的项目约定和任务相关的实现技能。不要假设主智能体调用的技能已经加载到工人的隔离上下文中。
- 规划每个工人需要的特定技能或技能摘录；避免将所有技能加载到每个工人中。当工人的主机允许时，工人必须保留发现其他相关实现技能的权限。
- 如果输入不明确，执行有针对性的只读探索。主智能体决定解决方案；可选的廉价侦查员仅用于收集事实。
- 将工作分解为可验证的单元，并带有稳定的 ID（
A0、A1……）、依赖关系、不相交的写入范围和明确的输出。当启动/上下文成本占主导地位时，不要将任务拆分得过于细小。 - 初始时优先使用 1–3 个工人；仅在真正独立的工作上使用并发工人。如果文件有重叠，则串行化写入或使用隔离的工作树和集成负责人。
B. 选择执行者
| 层级 | 适用工作 | 默认路由 |
|---|---|---|
| D0 | 可脚本化的转换、搜索、格式化、构建、确定性检查 | 脚本/工具；无 LLM |
| L1 | 精确的文件编辑、有边界的提取、重复的测试添加 | 能力最小的工人，低推理 |
| L2 | 清晰但中等难度的实现、局部调试 | 经济的通用工人 |
| L3 | 未解决的技术歧义、大量推理、高影响分析 | 强大的工人或主智能体 |
当解释、生成、检查和集成的成本超过工作本身时，优先选择主智能体执行而非委派。验证主机是否可以实际路由特定模型；否则，将期望的层级描述为建议性的，而非已执行的配置。
C. 精确分派
每个任务包必须包含：
任务 ID: A1
轮次: 1
目标: <一个可验证的结果>
执行者: <D0/L1/L2/L3；仅当支持时才指定实际模型/算力>
依赖: <已接受的任务 ID，或 NONE>
输入: <确切的文件/路径/数据和相关上下文>
项目指导: <适用的仓库指令、路径或必需摘录>
必需技能: <要预加载或打开的确切技能名称/路径；或 NONE>
可选技能: <工人可以查阅的相关技能名称/路径；或 NONE>
写入范围: <确切的文件或输出位置；或 READ ONLY>
流程: <有序的实现操作；决策已由主智能体做出>
约束: <必须保持不变的内容；禁止的操作>
验证: <具体的检查和预期结果>
交付: <预期的更改文件/结果和简洁报告>
停止条件: <缺少输入、权限、冲突、无法解决的失败>
在分派前：确保主机实际上暴露或预加载了指定的技能。如果主机无法做到，则在工人包中提供必要的技能内容或已验证的可读路径。保留必需的项目规则，但不要复制整个主智能体对话记录。绝不传输凭据或无关的私人上下文。
明确告诉工人：仅执行任务包，应用必需的项目指导和技能，并且不要调用 Lean Orchestrator 作为主智能体、生成其他智能体或启动依赖任务。工人可以在范围内加载额外的相关实现技能，但必须报告；如果某个技能与任务包或项目指令冲突，则停止并报告。使用以下报告格式：
任务 ID: A1
轮次: 1
状态: DONE | BLOCKED | FAILED
更改: <确切的人工制品，或 NONE>
检查: <命令和观察到的结果，或未运行并附理由>
使用的技能: <实际应用的实现技能的名称/路径；或 NONE>
问题: <具体的阻塞因素、偏差，或 NONE>
完整的可重用任务包模板位于 references/worker-packet.md；仅在详细模板有帮助时读取它。
D. 闭环主智能体 ↔ 工人通信
对于每个委派的单元：
- 主智能体 → 工人：分派 通过实际的主机工具发送一个包，并记录工人/会话 ID（如果提供）。
- 工人 → 主智能体：报告 通过工具返回、等待/轮询结果或支持的消息传递。进度更新是可选的，仅在可用且有帮助时提供。
- 主智能体：审查 实际输出和独立证据；决定
ACCEPT（接受）、REWORK（返工）、REPLAN（重新规划）或BLOCK（阻塞）。在未经验证的 DONE 状态下，绝不释放依赖工作。 - 主智能体 → 工人：修正 如果需要。发送一个新的包，使用相同的任务 ID、递增的轮次、确切观察到的缺陷、所需的修正、有界范围和聚焦的测试。在支持且经济的情况下恢复同一个工人；否则创建一个新工人，仅携带必要的历史。
- 工人 → 主智能体：再次报告；验证修正。优先进行一次聚焦的重试，然后升级模型层级、修改计划或直接修复，而不是重复无效循环。
- 主智能体：推进 已接受的依赖项，更新图表，并分派下一个准备好的任务。独立的非冲突工作无需等待。
通知语义取决于主机。 同步子智能体返回就是一种通知。持久会话可能接受后续消息。异步任务可能需要等待/轮询。绝不要假设存在任意的智能体间消息传递或持久内存。
示例：
用户给出 A
主智能体指定 A0 → 工人 0 返回 A0 证据
主智能体验证 A0（ACCEPT），指定 A1
工人 1 返回 A1 证据
主智能体发现缺陷（REWORK），如果可能，向工人 1 发送 A1 轮次 2
工人 1 返回修正后的 A1
主智能体验证 A1（ACCEPT），创建 A2……
主智能体运行集成检查并向用户报告
E. 跟踪与集成
维护一个最小的主智能体拥有的日志（不要花费工人的令牌）：
任务 ID | 依赖关系 | 路由/工人 | 状态 | 人工制品 | 检查 | 下一步操作
状态：PLANNED（已规划），READY（就绪），RUNNING（运行中），REVIEW（审查中），REWORK（返工中），ACCEPTED（已接受），BLOCKED（已阻塞），FAILED（已失败）。
- 检查实际更改，而不仅仅是摘要；对照任务包和项目约定进行验证。
- 先运行狭窄的检查，然后运行集成测试。当失败摘录足够时，避免用完整日志淹没上下文。
- 如果报告冲突或文件重叠，则集中集成并重新检查交互。
- 对失败进行分类：不明确的任务包、环境阻塞因素、工人能力、实现错误或集成冲突。解决实际原因；不要盲目重试相同的提示。
- 永远不要向用户提出工人无法通过检查回答的问题，除非确实需要他们的输入或批准。
F. 报告
返回完成的输出、验证状态、剩余限制，以及（在相关时）简短的路由摘要（例如，“一个 L1 工人，两个 D0 检查，一次返工”）。不要捏造令牌、货币或配额节省。
回退行为
- 无子智能体能力： 使用可用工具自行执行相同的图表。声明未生成子智能体；仅当用户请求委派计划时才单独生成任务包。
- 未确认更便宜的模型： 将路由状态分类为 SAME_TIER 或 UNVERIFIED，如果相关则解释缺少的模型设置，并优先选择主智能体/D0 执行，除非委派具有非成本优势。不要声称实际选择了更便宜的工人。
- 无可恢复的工人： 通过新的调用发送修正，附带任务 ID、确切缺陷和最小先验证据。
- 技能未继承： 定位或预加载所需的项目技能；如果不可能，仅在工作任务包中提供已验证的相关指令，或将任务保留在主智能体处。
- 无法移除委派工具： 工人角色规则仍禁止嵌套委派，但解释这是指令级别的限制，并非由主机强制执行。
- 只读或受限主机： 执行允许的分析和检查；准确报告被阻塞的修改。
有关主机能力和经济型工人预检，如果路由不明确，请阅读 references/setup-preflight.md。如需已实践的反馈循环示例，请参见 references/feedback-loop.md。