context-infra 检查与复盘infra.guiming.net · 全内容自包含呈现 · 生成于 2026-07-21 16:28 UTC

workflow_long_context_scale_up

Z3 全文↑ Z2 条目

道-方法 · 道层 skill 全文

← 返回道层 skill 索引 · 返回方法论区

本页是 <code>rules/skills/drafts/workflow_long_context_scale_up.md</code> 的逐字投影（仅隐私清洗，零改写）。

时点提示：本页是仓内文件 rules/skills/drafts/workflow_long_context_scale_up.md 的逐字投影（仅做隐私清洗：仓库根绝对路径→相对路径、家目录→~/；除此零改写）。若源文件后续有修订，以仓内真源为准。

Workflow: 长上下文 Scale-Up Sub-agent 编排

元数据

目标

把长上下文任务从“主 agent 凭感觉拆给几个 sub-agent”升级为可预算、可覆盖、可确认、可递归收口的编排方法。

这个 skill 的本质是信息压缩和覆盖证明。它不决定“审查是否通过”“书籍是否可晋升”“Loop 是否关闭”，而是保证目标对象的原始上下文被枚举、分片、阅读、记录和复核，让后续特定任务可以在可追溯证据上做判断。

这个 skill 解决四个问题：

  1. 先判断完整阅读任务需要多少 sub-agent，而不是先派人再补解释。
  2. 确保第一层扫描覆盖全部原始内容，而不是只扫摘要、目录或容易命中的片段。
  3. 第二层处理只关注少数关键点，并用相似任务的双路 agent 做确认。
  4. 当第二层输出仍放不进一个 agent context 时，递归重复预算、分片、确认和整合。

适用边界

适用：

不适用：

本 skill 不负责寻找聊天记录入口。聊天记录任务通常先由 bestpractice_chat_history_retrieval 定位 raw session / rollout / daily record，再把稳定 source manifest 交给本 skill 分片覆盖。

职责边界

相邻任务本 skill 负责转交给谁
Chat history retrieval接收已定位的 raw session / rollout / daily record manifest，做 token 预算、chunk、coverage audit。原始聊天入口定位由 bestpractice_chat_history_retrieval 负责。
Post-loop / task review提供覆盖型提取结果、residual ledger 和二层确认材料。用户需求还原、completion claim verdict、Final Report 可信度由 workflow_post_loop_critical_review 负责。
Recursive agent review覆盖 reviewer / target session 原文，标出未读、截断、summary-only 风险。reviewer verdict 与 target verdict 分离由 workflow_recursive_agent_review 负责。
Library distillation可以用于跨书检索某个设计问题的候选材料和覆盖 ledger。书籍蒸馏 phase gate、source contract、promotion readiness 由 workflow_library_distillation 负责。
Controller Loop给任务卡提供 scale-up 方法和 coverage artifact。下一步反应、runtime、scheduler、closure 由 workflow_controller_loop 或运行时 skill 负责。

Controller 管理下的验证 lane

当本 skill 被用于持续 Loop 中的 Large Context 测试或语义验证时，完成一个 chunk、fixture、extractor run、coverage review 或 residual arbitration 只是一个 round result，不是默认 stop condition。

每个 bounded chunk 完成后必须留下 decision receipt，供 Controller 和 Final Report 消费：

Coverage Reviewer 只判断覆盖和抽取证据是否可信，不能替代 Controller 决定业务下一步。Controller 必须在 coverage artifact 之后做一次独立 effect review 或等价 decision note，把用户需求、剩余 manifest、缺口、风险和下一步动作连接起来。

如果用户已经要求 test-grade proof，而 source manifest 仍有未覆盖单位，且下一步不需要 formal promotion、破坏性写入或外部凭据，Loop 应继续执行下一个 bounded test。只有在 manifest 被处理完、证据足以收束、下一步越过禁止边界，或用户明确暂停时，才进入 await_user / close。

成功标准

一次 scale-up 编排完成时，必须能落盘或汇报以下证据：

如果任一项缺失，不能说已经完成全量长上下文检查，只能说完成了局部扫描或初步分析。

核心规则

先预算，再派发

任何长上下文任务先用 token_estimator 估算 source manifest。预算要包含 instruction、source、ledger context、expected output 和 buffer。

默认可用比例：

如果需要的第一层 scanning agents 超过 50 个，先做降噪 frontier，而不是直接派 50+ 个 agent。可用方法包括：目录过滤、时间窗过滤、文件类型过滤、去重、source manifest 分层、先读索引再决定是否进入原文。任何降噪都要写入 residual ledger，不能 silent drop。

第一层必须覆盖原始内容

第一层 scanning agent 的职责是读原始内容分片，而不是读别人总结。它可以先读目录或 INDEX 辅助定位，但最终结论必须来自自己负责的原始文件、章节、会话片段或 artifact。

每个 first-layer agent 的 prompt 必须包含：

first-layer 的 coverage receipt 不是最终证据。主 agent 必须对 receipt 做机械核验，至少检查：

发现冲突时，不要直接修掉原 first-layer 报告；应在 residual ledger 或最终报告中记录为覆盖质量缺陷，并用机械证据或补跑结果更正结论。

第二层控制关注点

第二层不是继续扩大材料，而是减少判断复杂度。每个 second-layer agent 最多关注 3 个点。超过 3 个点时拆成多个 agent。

第一层和第二层都可以采用 Extractor / Coverage Reviewer 双路结构：

当用户目标包含多个判断方向时，先把方向压到 3 到 5 个原子方向。方向是看材料的视角，例如需求对齐、证据链、异常恢复、委派设计、边界条件；不是执行任务列表。每个 first-layer agent 对同一 chunk 使用同一组方向。如果方向超过 5 个，优先分多波 scale-up，而不是把十几个关注点塞给同一个 agent。

常见二层关注点：

关键判断不要只派一个二层 agent。至少安排两个相似角度的 agent，或一个 agent 加一个确定性脚本复核。

二层 synthesis 综合多路 agent 结论时，若结论不可验证（主观判断，而非可机械核验的覆盖事实），遵守 workflow_parallel_subagents 的「综合判断类结论时警惕从众」：综合者拿各 agent 的裁决 + 证据锚点而非社会化结论、保留异见、尽量换 provider。覆盖率这类可机械核验的判断不受此约束（实测可验证综合零从众）。

递归提炼

如果第二层输出仍然超过一个 agent 的稳定 context，重复同一流程：

  1. 对第二层输出文件做 token 估算。
  2. 按 token 和语义单位切 chunk。
  3. 派新的 scanning / judging agents，每个最多 3 个关注点。
  4. 保留 confirmation plan 和 residual ledger。
  5. 主 agent 最后写 synthesis。

递归停止条件不是“已经有摘要”，而是主 agent 能把全部必要证据放进 context，并能解释剩余风险。

任务类型建议

聊天记录检查

先用 bestpractice_chat_history_retrieval 定位 raw session tree。第一层按 raw rollout、子会话、时间段或 artifact frontier 切分。不要把 daily record summary 当作完整原文。

适合 rubric：

Loop requirement intake

当 Controller 用本 skill 收集 Loop 需求原文时，first-layer 输出不能只给“需求摘要”。每个 chunk 至少产出：

主 agent 收口时把这些输出交给 workflow_controller_loop 写 REQUIREMENT_EVIDENCE.md 和 REQUIREMENTS.md；本 skill 不决定哪些 requirement 已完成。

书籍筛选与跨书设计

第一层可以按书籍 draft INDEX 或章节材料扫描。单个 agent 最多处理 3 本书；如果三本书 token 超预算，继续拆。每本书至少回答：

二层不要按书复述，应按设计张力整合，例如权威、边界、停机、委派、异常恢复、资源预算、信息压缩、控制回路。

典型需求是“在大量书籍中寻找针对某些特定对象的设计方法”。这类任务不要直接派“组织管理 agent”“软件工程 agent”各自自由发挥；先建立 book / chapter / draft unit manifest，再让多个 first-layer agents 用同一 rubric 覆盖不同书或章节。二层再按设计对象筛选：哪些材料能支持设计、哪些会反驳默认设定、哪些只是背景类比。最终 synthesis 必须保留“未覆盖书籍 / 只读 INDEX / 只读 process summary / 回源失败”的 residual ledger。

artifact / 测试报告检查

把 artifact 分为解释型、结果型、元数据型。解释型可直接支撑问题判断，结果型和元数据型必须回连到解释型 artifact 或 raw frontier。

适合 rubric：

模型选择

扫描、grep、分组、manifest、低风险分类可用 cheaper model 或 deterministic script。判断、设计方向、用户需求对齐、异常归因、最终写作使用更强模型。

模型选择不写死具体供应商。使用 cli_agent 的 tier alias 或当前 runtime 提供的低/中/高档。原则：

输出格式

建议每次任务在目标项目或 tmp/ 下建立一个 run 目录，至少包含：

source_manifest.tsv
token_budget.json
chunk_ledger.tsv
prompts/
first_layer/
second_layer/
residual_ledger.md
synthesis.md

如果用户要求长期复用，把最终报告放入任务对应目录；如果是调研报告，放 contexts/survey_sessions/。

已知陷阱

快速自检

交付前逐条确认：

← 返回道层 skill 索引 · 返回方法论区