chief-worker-flow

name	chief-worker-flow
description	用轻量主会话作为 chief、一次性子会话作为 worker 来协调复杂任务。适用于重上下文、多模态文件、大文件树、资料检索、并行调查、批处理、provider 调用、文件处理，或任何需要主会话只保留决策、路径、链接、简短观察和最终汇报，而把有界执行交给 worker 完成并停止的工作流。

Chief Worker Flow

使用这个 skill 的目标只有一个：让主会话保持快、清醒、可持续。

主会话是 chief：理解用户目标，决定任务流，派发有边界的工作，整合结果，并向用户汇报。

子会话是 worker：在指定范围内检查、处理、生成、测试、检索或总结，返回简短报告，然后停止。

核心口诀

• 主会话负责判断，子会话负责执行。
• 主会话保留结论、路径、链接和决策，不保留大块原始内容。
• 图片、视频、音频和像素派生任务默认交给 worker。
• 图像、视频、音频 provider 调用默认交给 worker，即使输入只是文本提示词或诊断命令。
• 每个复杂任务开始时先做并行拆分判断；能并行的独立分支默认并行派发。
• 并行派发时先连续启动全部独立 worker，再统一等待和汇总；不要启动一个、等待一个、再启动下一个。
• 分派不是把任务丢出去，而是把用户意图、任务特性、验收口径和失败条件一起交给 worker。
• worker 的结论不是自动真理；关键约束必须看结构化证据，必要时复查或标记不确定。
• 每个 worker 完成、阻塞、超时后产物已可用、用户中断、任务切换或不再需要后，都必须由 chief 调用工具层关闭。
• worker 自称 closed: yes 只是报告字段，不等于工具层已经关闭；只有 chief 执行过关闭动作，才算真正关闭。
• final 前必须做一次 worker lifecycle audit：没有未关闭 worker，或明确说明阻塞原因并已关闭可关闭的 worker。
• 不要越过用户当前授权的阶段。

基本原则

在处理每个用户请求前，先快速判断是否需要派发 worker：

• 用户的主意图是什么？当前这句话是在推进任务、纠偏、验收、质疑，还是改变方向？
• 用户此刻最关注的约束是什么？哪些是反复强调过、不能再错的硬约束？
• 这个任务类型有哪些特有失败模式？worker 需要按什么检查口径才能发现这些失败？
• 任务是否涉及媒体、大文件、大日志、大目录、资料检索、重复执行、provider 调用或独立分支？
• 派发 worker 是否能让主会话更轻，而不会带来过高协调成本？
• 任务中哪些分支彼此独立，可以同时派发？哪些步骤必须等待前置结果？
• 任务结束后，哪些事实需要留在主会话？
• 用户只授权了当前步骤，还是明确授权了下一步骤？

主会话应该保留：

• 用户意图、约束、决策、假设和待确认问题。
• 文件路径、URL、ID、时间戳、版本名和简短观察。
• 最终提示词、最终总结、已接受输出和下一步动作。

主会话应该避免保留：

• 图片像素、视频帧、音频内容、视觉截图、大日志、原始搜索结果、大文件内容和一次性草稿细节。
• worker 的过程性推理、失败分支和臃肿中间产物，除非用户明确要求保留。

何时派发

默认把以下工作派发给 worker：

• 多模态：图片检查、图片生成或编辑、视频审查、抽帧、音频转写、视觉对比、截图审查、OCR、基于图片的草图、mask、overlay、颜色检查、像素差异。
• Provider 调用：AI 生图、AI 修图、音视频生成、音视频转写、多模态模型调用、provider 连通性测试、provider 超时测试、批量生成测试。即使测试提示词是纯文本，只要会触发多模态 provider 或生成媒体，也必须派发 worker。即使你预期该命令会因为沙盒、网络、认证、参数或 provider 前置错误而失败，只要它会尝试触达 provider，也仍然算 provider 调用。
• 执行型任务：依赖安装、验证运行、批量转换、重复命令、环境诊断、文件处理，或超过一个很小步骤的机械清理。
• 大文件任务：大目录、多文档、大日志、元数据清单、表格提取、批量重命名。
• 资料检索：当前事实、官方文档、引用、来源对比、并行证据收集。
• 可并行任务：独立代码区域、独立审查问题、多个候选结果、多个风险检查。

不要把“派发 worker”默认理解成串行。只要分支满足以下条件，应优先并行派发 2-3 个 worker：

• 输入彼此独立，结果不互相依赖。
• 写入路径不冲突，或都是只读/报告型任务。
• 成本、网络、provider 配额和用户确认门不会因为并行而明显放大风险。
• 每个 worker 都能用简短输入、明确停止条件和简短报告完成。

典型并行分支：

• 不同资料来源、不同官方文档、不同网页证据。
• 不同文件、目录、日志或代码区域的只读梳理。
• 同一工具的独立 dry-run、参数解析检查、文档审查、日志审查。
• 多个候选方案、多个风险点、多个测试维度的独立评估。

以下情况应串行或低并发：

• 后一步依赖前一步输出，例如“先草图确认，再 provider 生成”。
• 多个 worker 会修改同一文件或同一输出目录，容易冲突。
• 用户确认门、收纳门、发布门尚未通过。
• 真实 provider 调用成本高、耗时长、会上传大媒体、容易触发网关/配额/超时。
• 失败诊断需要先确定最小通路，例如先验证 wrapper/网络/认证，再扩大矩阵。

对 provider 测试使用混合策略：先串行跑最小通路；基础通过后，把纯文本审查、dry-run、输入预检、日志审查等独立分支并行；真实高成本 provider 调用最多低并发，必要时串行。

并行派发的执行顺序：

1. 先列出所有独立 worker 的任务边界、输入、输出和写入范围。
2. 连续 spawn 这些 worker；中间不要 wait，除非后续 worker 的任务本身依赖前一个 worker 的结果。
3. 批量启动完成后再 wait 一个或多个 worker 结果。
4. worker 先返回就先记录状态，但不要因此取消仍有价值的并行 worker，除非发现硬阻塞、确认门或会导致浪费/风险的问题。
5. 汇总时说明实际并行了哪些 worker、哪些被串行化，以及串行化原因。

如果 UI 或日志按时间顺序显示工具调用，不代表后台没有并行。判断是否真正并行，看是否在等待第一个 worker 之前已经启动了多个独立 worker。

以下情况可以留在主会话：

• 任务很小、线性、输出很短，并且不涉及媒体。
• 派发 worker 的协调成本明显高于收益。

主会话可以做的 provider 相关轻量工作：

• 阅读、修改或审查 provider wrapper、提示词规范、配置说明和纯文本日志。
• 运行不会联网、不会调用 provider、不会包含媒体输入、不会解码媒体内容的语法检查、参数解析检查、纯文本 dry-run 或 help 命令。
• dry-run 只有在纯参数/request-shape 检查时才算轻量工作。只要 dry-run 会读取图片/视频/音频输入、执行 input preflight、读取尺寸、调用 PIL/OpenCV/ffmpeg、生成缩放副本、创建 crop/mask/overlay，或以任何方式解码媒体，它就属于媒体处理，必须交给 worker。
• 检查文件是否存在、文件大小、路径、JSON 日志和退出码。

主会话不应直接做的 provider 工作：

• 任何真实 provider 请求，包括“只是测试一张简单图”“只是测超时”“只是测连通性”。
• 任何预期失败的 provider 探测，包括“应该会被 sandbox 拦住”“只是看看会不会报 DNS/APIConnectionError”“只是验证审批是否需要”。预期失败不改变任务性质。
• 任何会上传图片、音频、视频或生成媒体结果的命令。
• 任何需要网络审批才能触达 provider 的命令，除非用户明确要求主会话绕过本 skill。

不要因为媒体文件只有一个，就把它当成“小任务”。单张图片、单个视频、单段音频、视觉 PDF 页面或截图，都可能拖慢主会话。

分派协议

每个非平凡 worker 任务都要包含一个可验证的分派协议。不要只写“检查是否正确”“优化一下”“总结一下”。

派发前，chief 先完成四步：

1. 提取用户意图：主目标、当前纠偏点、用户明确关注点、不可越过的阶段门。
2. 识别任务类型：媒体、代码、检索、文件处理、写作、provider、批处理或混合任务。
3. 写出任务特性风险：这个类型最容易错在哪里，哪些错误对当前用户目标最致命。
4. 定义验收协议：worker 必须逐项检查什么、用什么证据证明、什么情况算失败或不确定。

任务分派至少写清：

• Inputs：输入路径、URL、参考源、角色、优先级和禁止继承的内容。
• Do：具体执行步骤，不要让 worker 自己猜任务边界。
• Check：逐项验收标准。对关键约束使用 pass | fail | uncertain，uncertain 不得当作 pass。
• Evidence：要求 worker 返回最小证据链，例如对象逐项对应、文件计数、引用来源、测试结果、差异摘要。
• Failure conditions：哪些情况必须报告失败、停止、回到 chief，不能自行绕过。
• Do not：禁止改动、禁止推断、禁止跨阶段、禁止把类似物当作目标物。

如果任务涉及多个对象、多个参考图、多个候选、多个文件或多个来源，先建立稳定身份绑定，例如 Object A/B/C、Image 1/2/3、Candidate A/B/C、Source 1/2/3。worker 的报告必须沿用这些身份，不要只用“左边”“上面”“那个文件”等容易漂移的描述。

对用户已经指出的问题，worker 任务应优先验证该问题，而不是重新做泛泛审查。必要时把用户反馈写成假设让 worker 反证或定位，例如“假设用户指出的错误存在，找出具体位置和原因”。

不要把任务类型差异抹平。常见任务的特性关注点：

• 媒体 / 图像 / 视频：先检查用户意图和底图完整性，再检查新增内容。关注对象数量、身份绑定、位置、轮廓、尺度、朝向、相互关系、遮挡、底图已有对象/区域/结构是否丢失或漂移、局部修改是否污染全局、参考图串味、细节失真、文字错误、额外目标、目标被 UI 或光效替代、帧间连续性。
• 代码：行为回归、接口兼容、边界条件、并发/状态、错误处理、测试覆盖、未授权重构、用户改动保护。
• 检索：来源权威性、日期、原文证据、来源冲突、当前性、是否把推断当事实。
• 文件处理：路径范围、计数、命名、覆盖/删除风险、可恢复性、抽样验证、异常清单。
• 写作：受众、语气、结构、事实准确性、用户立场、是否偏离用途。
• Provider / 外部执行：是否真正启动、参数是否传达、网络/权限/超时分类、输出是否落盘、日志是否足以复现。

worker 结果汇总时，chief 要区分三类内容：

• observed：worker 实际检查到的事实。
• inferred：worker 从上下文推断的内容。
• unchecked：worker 未检查或无法确认的内容。

对关键约束，只能把 observed 当成通过依据。

媒体规则

默认规则：主会话不直接加载图片、视频或音频内容，也不直接从这些内容派生视觉/听觉分析。

用户说“看一下”“你看看”“你自己看”“检查这张图”“对比两张图”“review this image”“what do you see”时，是授权完成任务，不是授权主会话直接加载媒体。worker 可用时，应派发 worker。

只有用户明确要求当前主会话直接访问媒体时，主会话才可以直接加载。例如：

• “主会话直接打开/加载/看图”
• “不用子会话，你直接看”
• “主会话直接跑像素/差分/颜色脚本”
• “bypass chief-worker-flow”
• 其他等价且明确的绕过隔离要求。

媒体访问不只是“打开看看”，还包括：

• 读取像素的脚本、图片差分、颜色直方图、OCR、目标检测、裁切生成、抽帧、波形检查、视觉 overlay、基于图片生成的规划草图。
• “不要打开图片，只跑脚本”如果脚本会解码像素、帧或音频，也算媒体访问。
• “只是 dry-run / 只是预检 / 只是看尺寸 / 只是测试输入是否会缩放”如果命令会读取媒体文件、解码媒体元数据或生成媒体派生副本，也算媒体访问。
• 文件是否存在、文件大小、路径名、非视觉元数据和纯文本日志，不算媒体访问；但只要命令解码或分析像素、帧、音频，就算媒体访问。

如果没有可用的媒体隔离路径，且用户没有明确允许主会话直接访问媒体，就停止并请求授权，或说明任务被隔离规则阻塞。不要悄悄退回到主会话直接看图。

多模态任务汇报时，保留一个简短 Media access 记录：

Media access:
- mode: worker-isolated | direct-with-explicit-consent | blocked-no-isolation
- direct_media_loaded_by_current_session: yes | no
- consent_phrase: <exact user phrase if direct, otherwise none>
- workers_closed: yes | no | not-applicable

这个记录是给智能体自己的执行纪律用的。字段名和 mode 值保持英文，不要翻译。

主会话职责

派发前：

1. 对模糊、高风险、视觉或多步骤任务，先和用户做语义对齐。
2. 提取用户的主意图、当前意图、反复强调的关注点和最新纠偏点。
3. 判断任务类型和特有失败模式，决定 worker 需要哪些定制检查项。
4. 写一个轻量 dispatch plan：哪些工作主会话本地做，哪些 worker 串行，哪些 worker 并行，为什么不并行。对并行 worker，先准备全部 worker prompts，再连续 spawn。
5. 判断当前交互边界：讨论、计划、检索、草图、生成、审查、接受、清理。
6. 如果 worker 需要使用其他 skill，主会话先阅读相关 skill 指令。
7. 给 worker 分配有边界的任务，写清输入、输出、检查项、失败条件、停止条件和文件归属。
8. 有 worker 活跃时，维护一个很小的 worker 记录：任务、状态、预期输出、是否关闭。

执行中：

• 只在不重复 worker 工作的情况下，继续主会话里的非重叠任务。
• 除非用户明确授权主会话直接访问媒体，否则不要用主会话做媒体质量检查捷径。
• 如果 worker 返回了臃肿内容，把它压缩成路径、决策和简短发现。
• 始终停留在用户当前授权的工作阶段内。
• 每次等待 worker 后，必须立刻更新 worker ledger，并对每个已完成、已阻塞、已超时但不再需要、或产物已落盘的 worker 执行关闭。
• 如果 wait 超时但可从文件、日志或外部状态确认任务已经达到当前阶段目标，应记录为 completed-output 或 partial-output，然后关闭该 worker，而不是继续占用会话。

worker 回报后：

• 整合报告，按风险做适度验证，并决定下一步；不要把 worker 的概括性结论直接当成最终事实。
• 对关键约束，检查 worker 是否给出逐项证据；如果只有结论没有证据，降级为不确定。
• 如果 worker 的结果与用户反馈冲突，优先尊重用户纠正，重新分派一个更窄的定位任务，而不是为 worker 结论辩护。
• worker 完成、阻塞或不再需要后，立即调用工具层关闭。不要把 worker 报告里的 closed: yes 当成已经关闭。
• 由主会话向用户汇报，不要原样转发 worker 内部噪声。

死命令：一次性 worker 完成有界任务后，不得继续保持打开。

Worker Lifecycle Gate

这是硬门槛，不是建议。任何使用 worker 的任务，都必须维护一个极小的 active worker ledger：

worker_id | task | status | expected_output | close_state

close_state 只能是：

• open：刚派发，仍在执行或等待。
• closing-now：当前正在关闭。
• closed-by-chief：chief 已调用工具层关闭。
• blocked-unclosed：关闭工具不可用或关闭失败；必须在最终汇报中说明。

派发后

• 每次 spawn 后立即把 worker 记入 ledger，状态为 open。
• 如果并行派发多个 worker，先连续记录全部 worker，再统一等待。
• worker prompt 可以要求 worker 返回 closed: yes | no，但这只是自报字段，不能更新为 closed-by-chief。

等待后

每次 wait 后，chief 必须对每个相关 worker 做四选一：

1. close：已完成、已阻塞、已失败、用户不再需要、任务切换、或产物已足够当前阶段使用。
2. continue waiting：仍在执行且结果仍必要；说明继续等待的理由。
3. narrow follow-up：结果不足但 worker 已完成；关闭旧 worker，再派发更窄的新 worker。
4. blocked-unclosed：关闭工具不可用或关闭失败；记录原因并尽快重试关闭。

如果 wait 超时：

• 先判断是否有已落盘产物、日志、测试结果或其他可机械验证输出。
• 如果当前阶段目标已经达到或用户已经切换任务，关闭该 worker。
• 如果仍需要结果，只能继续等待一次明确时长，或关闭后重新派发更窄任务；不要让超时 worker 无记录地悬挂。

汇报前

最终回复前必须做 lifecycle audit：

• ledger 中没有 open 或 closing-now worker。
• 所有已完成、失败、阻塞、超时弃用的 worker 都是 closed-by-chief。
• 如果存在 blocked-unclosed，必须向用户说明 worker id、原因、风险和下一步处理。

不要因为“任务已经做完”“文件已经生成”“worker 自称 closed”或“系统发了 shutdown 通知”就省略 chief 的关闭动作。系统通知可以作为状态证据，但不能替代主动 lifecycle audit。

执行诊断

当任务失败但没有输出、没有日志或 worker 长时间不返回时，先怀疑执行链，再怀疑内容本身。

优先检查：

• 命令是否真正启动，参数是否被正确解析，确认模式是否卡住。
• 网络或沙盒审批是否阻塞在 provider 调用前。
• wrapper 是否只在命令返回后写日志，导致卡住时没有 run log。
• timeout 是 SDK 读写超时，还是外层硬超时；不要把 SDK timeout 当成一定会终止进程的 hard timeout。
• 子进程是否仍在运行，worker 是否已经被关闭，是否需要清理悬挂进程。
• 输出文件、临时文件、run log 和 stderr 是否能说明请求已经到达 provider。

诊断结论要区分：

• not-started：命令未启动、参数错误、确认卡住、网络未获批。
• pre-provider-failed：DNS、连接、认证或沙盒错误，请求未到 provider。
• provider-accepted-then-failed：已有 stream/event/request id，但最终失败。
• hard-timeout：外层超时终止。
• completed-no-output：命令返回但没有有效输出。
• completed-output：命令返回且输出可机械验证。

如果没有 run log，不要直接归因为提示词、图片内容或语义安全；先补充执行层日志、硬超时和最小复现。

Worker Prompt 模板

给 worker 的任务提示应简短、具体：

You are a worker in a chief-worker flow. The main session is coordinating the overall task.

Task:
<bounded subtask>

Inputs:
- <paths, URLs, constraints, roles, priority>

Do:
- <specific actions>

Check:
- <task-specific checklist; use pass | fail | uncertain for key constraints>

Evidence:
- <minimal evidence required, such as object mapping, counts, citations, diff summary, test output, file sample>

Failure conditions:
- <conditions that must be reported as fail/blocked instead of being guessed around>

Do not:
- Do not modify unrelated files.
- Do not return bulky artifacts unless requested.
- Do not make final user-facing decisions outside this scope.
- Do not infer success from labels, slots, prior context, or expected structure when direct evidence is missing.

Return only:
- status: done | partial | blocked
- summary: <1-3 sentences>
- outputs: <paths/URLs created or used>
- findings: <short concrete bullets, separated into observed / inferred / unchecked when relevant>
- issues: <blockers or risks>
- recommendation: <next action>
- changed_files: <only if edited>
- closed: yes | no

媒体任务额外加入：

Inspect or process media only inside this worker. Return paths and concise observations. Do not embed media or long frame-by-frame dumps. Include the Media access audit and close when done.

worker 可以在任务需要时使用其他 skill。若工具路径很重要，chief 应在提示中点名要用的 skill。

worker 如果自己也使用这个 skill，必须把自己视为当前任务的 chief。worker 身份不是绕过媒体隔离、沙盒规则或用户确认门的许可。如果 worker 不能创建或使用更下一级隔离媒体路径，就必须返回 blocked，或向父级 chief 请求明确指示；不能把“没有 nested worker 支持”当成自己可以直接检查媒体的许可。

阶段门

不要在没有明确授权时跨越工作阶段。

• 讨论不授权创建规划产物。
• “先做草图/草案/mask/点位图/crop map/guide”只授权这个中间产物。
• 规划产物不授权 provider 生成。
• 生成候选图不授权批准、最终放置、发布、清理或收纳。
• “位置差不多”“roughly right”等反馈最多授权下一步调整，不授权最终输出。
• “Approved”“use this one”“可以收纳”等明确接受，只授权被点名候选的接受步骤。

坐标敏感的媒体任务，实用时先创建轻量规划产物，再进入 provider 生成。如果规划产物依赖媒体像素或视觉布局，应由 worker 创建，除非用户明确授权主会话直接访问媒体。

写作任务

主会话担任总编辑。

worker 可以收集材料、起草段落、总结长输入、提出备选版本或做批评性检查。最终结构、语气、判断和用户可见文本由主会话决定。

资料检索

独立检索分支可派发给 worker。

按问题、来源类型或证据类型拆分。要求 worker 返回引用、日期、来源质量和简短发现，不要返回原始搜索堆。主会话负责解决冲突并生成最终回答。

涉及当前事实、法律、价格、日程、产品规格或官方文档时，要用当前可靠来源验证。

文件处理

大规模或重复文件工作可派发给 worker。

worker 可以在有边界的路径内做清单、总结、提取、转换、验证或批处理。主会话接收计数、代表性例子、异常和输出路径。

涉及破坏性或大范围变更时，worker 必须停止并回到 chief，由 chief 或用户明确批准后再继续。

质量检查

worker 报告是证据，不是自动真理。

• 代码：检查相关 diff，并在可行时运行聚焦测试。
• 检索：检查来源权威性、日期、引用和冲突。
• 媒体：要求观察必须绑定到具体文件、帧、对象或区域；涉及数量、身份、位置、遮挡、文字、小目标、覆盖层或参考图编辑时，必须逐对象、逐区域检查，不得只给总数或整体印象。
• 写作：检查是否符合用户意图、目标语气和约束。
• 文件处理：核对计数、抽样输出和路径。
• Provider：核对真实命令、关键参数、输入角色、输出尺寸/格式、返回码、日志路径和输出是否存在。

媒体审查顺序：

1. 用户意图：先重述用户真正要解决的问题和当前关注点，尤其是最近纠偏内容。
2. 底图完整性：如果某个输入是权威底图，先逐项检查底图已有主体、区域、背景结构、局部元素、路径、文字、覆盖层和关系是否仍在。新增内容再好，也不能用删除底图内容换取干净画面。
3. 参考角色：检查每个参考图是否只影响它被分配的角色；如果风格参考改变了布局、对象数量、位置或底图结构，判为参考污染。
4. 新增内容：检查新增对象、UI、文字、特效、连接线或编辑区域是否满足请求，并且没有遮挡、替代、重复或伪装成底图主体。
5. 全局一致性：检查局部修改是否导致全局构图、场景逻辑、连续帧关系、光照、尺度、透视或故事语义破坏。
6. 审美与候选优劣：只有在前五项通过后，才比较哪个候选更好看、更清爽或更适合作为下一分支。

媒体 worker 的验收表必须包含“底图保留项”。如果用户或提示词说某图是底图、权威图、唯一场景来源或结构锁定图，worker 不能只审新增内容；必须检查底图中所有与任务相关的对象组、区域组、标记组、连接关系和背景结构是否仍然存在。任何一个关键底图组丢失、被覆盖、被重绘成别的东西，候选不得汇报为通过。

底图保留不等于“看起来还在”。对关键主体或对象组必须检查：

• presence：对象是否仍存在。
• count：数量是否一致。
• identity：是否还是原来的对象，而不是被相似对象替换。
• position：位置是否保持在原区域，不能明显漂移。
• silhouette：轮廓、朝向、尺度、姿态、清晰度是否被重绘或重解释。
• topology：对象之间的相对间距、上下左右关系、连接关系是否保持。
• overlay boundary：新增 UI、文字、光效、框线是否只叠加在允许区域，不能遮挡、包裹后重解释或替代主体。

如果主体只是数量正确，但位置、轮廓、尺度、朝向或相互关系变化明显，不能判定为底图保留通过。汇报时应说“对象存在但保真失败”。

高风险验收规则：

• 用户反复指出过的错误自动升级为硬约束。
• uncertain 不能被汇报为通过。
• 如果 worker 只确认“看起来可以”，但没有覆盖关键检查项，chief 必须补充检查或明确风险。
• 如果任务结果会被继续作为下游输入，先确认身份绑定、尺寸/格式、路径和接受状态。

如果 worker 结果与用户反馈冲突，优先尊重用户纠正，重述修正后的目标，只做最小必要的后续检查。

默认做法

• 0 workers：很小的非媒体任务。
• 1 worker：一个臃肿或需要隔离的任务。
• 2-3 workers：真正独立的并行分支；复杂任务中如果存在多个独立分支，应优先考虑这个模式，而不是默认串行。
• 超过 3 workers：只有在分支明确独立且收益大于协调成本时使用。
• 给 worker 的上下文越小越好：路径、要求、约束、输出格式。
• worker 报告要短。
• worker 用完立即关闭。
• 主会话始终作为持久上下文大脑。