context_inertia_task_assignment_20260429_deep_research

Z3 全文↑ Z2 条目

方法论库 · 引用级 · none

本页是 <code>contexts/methodology/context_inertia_task_assignment_20260429_deep_research.md</code> 的逐字投影（仅隐私清洗，零改写）。

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

报告元数据（frontmatter）

name: context_inertia_task_assignment_20260429_deep_research
description: 上下文惯性与任务分配
domain: infra
consumption:
  surface: none
  trigger: ""
  consumer: orchestrator
status: library
promoted_to: null

Context 惯性、隐性知识与任务分配调研

date: 2026-04-29
skill: deep-research
reader_mode: internal
primary_question: LLM 在同一 context 下是否存在惯性，这种惯性是否应影响任务分配

结论

你的直觉是对的，但需要把词收紧。

LLM 在一个 context 下确实会形成惯性。最准确的名字不是人类式隐性知识，而是 latent task state。它由 prompt、examples、历史对话、工具输出、文件路径、当前任务措辞共同写入模型的 activations、attention pattern 和 KV cache。它不会写回模型参数，也不会跨 context 自然保存，但在当前上下文内足以稳定影响后续输出。

这对任务分配有直接影响：context 惯性既是资源，也是污染源。

作为资源，它让讲解类、写作类、框架统一类任务受益。同一 context 会维持读者模型、术语体系、比喻空间、语气密度和输出结构，所以多个同类知识点可以得到风格统一的讲述。

作为污染源，它会让调研、审查、反证、跨领域判断受害。早先形成的 task mode 会锚定后续解释，旧材料会竞争 attention，多个相邻框架会同时激活，模型可能把后来的材料吸收到先前框架里，而不是重新判断。

因此任务分配的核心原则是：

保留需要统一的惯性，隔离需要独立判断的惯性。

工程上对应一个 hybrid pattern：研究、提取、反证、验证放到 clean context 的 sub-agent；最终写作、风格统一、架构取舍留在主 context。主 context 不应吞下所有材料，而应吞下 distilled artifacts。

一、定义：context 惯性是什么

这里的惯性指：在当前上下文中，模型已经形成了某种临时任务表征，导致后续输出倾向于沿着同一解释框架、同一风格、同一操作策略继续。

它至少有四层。

风格惯性：句式、语气、抽象层级、是否用类比、是否偏解释性语言。
任务惯性：模型认为自己现在是在讲解、审查、编码、调研、写作还是辩论。
语义框架惯性：模型已经采用的 ontology 会继续组织后续材料，例如把 Skill 理解成路由机制、把 context 理解成工作记忆。
认识论惯性：模型已经接受的假设会影响新证据的解释路径，类似锚定效应。

它不是三件事。

它不是参数更新。inference 时模型权重不变。

它不是人类完整 tacit knowledge。人类 tacit knowledge 包含身体经验、社会实践和责任主体，LLM 没有这些。

它也不是单纯记忆。记忆强调保存信息，context 惯性强调当前状态如何改变后续条件分布。

更合适的定义是：

context 惯性是当前输入在模型内部诱导出的临时任务状态，它把可用知识、输出风格、操作策略和判断准则推向某个局部吸引子。

二、机制证据：为什么它不是玄学

1. ICL 会形成 task vector

Hendel, Geva, Globerson 的 In-Context Learning Creates Task Vectors 显示，in-context examples 可以被压缩为 query-agnostic 的 task vector，再 patch 到只含 query 的 forward pass 中，仍保留相当一部分 ICL 能力。这个实验说明 examples 的作用不只是给模型看几条样例，而是在当前计算中形成一个可迁移的任务表征。

来源：In-Context Learning Creates Task Vectors

2. Function vector 是更强的 causal evidence

Todd et al. 的 Function Vectors in Large Language Models 用 causal mediation 找到少数 attention heads 搬运 compact task representation。把 function vector 加到中层 activations，可以在 zero-shot 或自然文本上下文里触发特定 function。这个结果直接支持一个判断：task mode 有可定位的 activation carrier。

来源：Function Vectors in Large Language Models

3. Induction heads 提供 ICL 的 circuit 原型

Olsson et al. 的 In-context Learning and Induction Heads 发现 induction heads 能实现 match-and-copy 类算法，并且它们出现的阶段与 ICL 能力跃升同步。小模型里有 causal evidence，大模型里更多是相关证据。它支持一个较弱但重要的说法：context 内模式学习至少部分由 attention circuit 执行。

来源：In-context Learning and Induction Heads

4. KV cache 是 context state 的物理载体之一

自回归 Transformer 生成下一 token 时，会读取前面 token 的 key/value 表征。工程实现里的 prefix caching 直接利用这一点：同一 prefix 的 KV cache 可以被复用到不同 continuation。也就是说，同一 conversation 的后续生成不是 stateless。

来源：Attention Is All You Need，Hugging Face KV cache documentation

5. Attention sinks 和位置偏置会加强开头惯性

Efficient Streaming Language Models with Attention Sinks 发现，初始 token 即使语义不重要，也会吸收强 attention。Lost in the Middle 发现长 context 中相关信息放在开头或结尾时更容易被利用，放在中间时显著退化。

这解释了你说的“context 真正放在前面”为什么重要。开头不仅是文本顺序上的前面，也可能成为 attention 的锚点。结尾则负责当前动作的 recency。中间适合放材料，不适合放最高优先级的约束。

来源：Efficient Streaming Language Models with Attention Sinks，Lost in the Middle

三、经验现象：为什么刷新 context 后表现不同

1. Prompt 顺序会改变表现

Lu et al. 在 ACL 2022 的 prompt order sensitivity 研究中发现，few-shot examples 的排列顺序可以让模型表现从接近随机到接近 SOTA。Zhao et al. 的 Calibrate Before Use 也指出，prompt format、examples 和 examples 顺序会导致 few-shot learning 不稳定，并且模型会偏向 prompt 中某些答案。

来源：Fantastically Ordered Prompts and Where to Find Them，Calibrate Before Use

2. 无关 context 不是中性的

Shi et al. 的 GSM-IC 实验证明，数学题中加入无关信息会干扰 LLM 推理。模型不是先完美识别哪些 token 相关再推理，而是在 noisy context 中做条件生成。旧对话、过时材料、相邻主题都可能成为 distractor。

来源：Large Language Models Can Be Easily Distracted by Irrelevant Context

3. context 越长，边际收益越低

Anthropic 的 context engineering 文章把 context 定义为有限资源，并明确说随着 context 变长，模型会失焦或困惑。其工程建议是寻找最小的 high-signal token set，而不是把所有信息塞进去。

来源：Effective context engineering for AI agents

4. 本地案例显示漂移由 context 多样性触发

本仓库的 attention drift case study 里，context 使用率只有 21%，但仍出现四次偏离。关键变量不是 token 快满了，而是同一上下文里出现了多个竞争任务框架：原计划、agent 结果、注意力漂移讨论、新方案、元反馈。这个本地案例和外部 context rot 研究方向一致。

来源：contexts/thought_review/think_attention_drift_case_study_20260410.md

四、Skill 蒸馏：为什么它部分有效，部分失效

微信文章的核心框架很有用：Skill 的效果不是把一个人完整蒸馏进文件，而是把某些可语言化、可触发、可执行、可验证的知识变成 agent 可调用结构。

外部论文支持这个边界。

SkillsBench 显示，curated Skills 平均提升 16.2 个百分点，但领域差异极大，Software Engineering 只提升 4.5 个百分点，Healthcare 提升 51.9 个百分点。更重要的是，focused Skills with 2 to 3 modules outperform comprehensive documentation。也就是说，Skill 的有效性不是越完整越好，而是要激活正确区域、提供可执行步骤、避免 context 污染。

来源：SkillsBench

SWE-Skills-Bench 更直接：49 个真实软件工程 Skill 中，39 个没有 pass-rate 改善，平均只有 +1.2%。只有少数高度专门的 Skill 有明显收益，负增益案例来自版本不匹配的指导和项目 context 冲突。

来源：SWE-Skills-Bench

SkillFoundry 则说明另一面：当资源能被抽取为 task scope、inputs/outputs、execution steps、environment assumptions、provenance 和 tests 时，自动挖掘 Skill 是可行的，尤其适合科学 workflow。

来源：SKILLFOUNDRY

综合看，Skill 能蒸馏三层东西。

L1 确定性规则：事实、路径、schema、IF-THEN、公式、验证器。最有效。
扩散激活：风格、读者模型、术语偏好、判断方向。有效但有分辨率上限。
Utility 冲突裁决：什么时候规则应该让步、什么时候换框架。最难蒸馏，必须靠 examples、反例、validator、历史结果和人类审查补足。

这也解释了你的问题：在讲解类任务里，context 惯性主要利用第二层扩散激活。它让风格和解释框架保持一致。但当任务进入第三层 utility 裁决，例如架构取舍、方法论更新、跨领域判断，同一 context 的惯性可能会让模型过度沿用旧框架。

五、回答你的两个具体问题

1. 激活权重和任务分配有没有关联

有，但这里的激活权重不要理解成模型参数里某些权重被永久点亮。更准确是：context 改变了当前 forward pass 的 activation trajectory，诱导模型进入某个 latent task state。

任务分配应该按 latent task state 分，而不是只按主题名分。

同一个 latent task state 包括：

任务类型：讲解、调研、审查、编码、综合。
证据标准：论文优先、官方文档优先、本地文件优先、行为证据优先。
输出形态：报告、代码 patch、decision memo、教学讲稿。
读者模型：专家、初学者、未来 agent、自己。
冲突裁决：速度优先、正确性优先、可审计性优先、风格统一优先。

如果两个子任务共享这些维度，放在同一 context 里通常有收益。如果它们在这些维度上冲突，应拆开。

2. 同样是讲述任务，不同领域知识该如何分配

讲述任务本身可以拆成两层。

第一层是内容获取：每个领域的事实、来源、边界、反例。

第二层是表达编译：用同一读者模型、同一风格、同一论证节奏把材料讲出来。

所以最佳结构通常不是“一个 agent 从头讲完所有领域”，也不是“每个领域各自写一段然后拼起来”。更稳的是：

不同领域的内容调研分开，用 clean context 保持独立判断。
每个研究 agent 只返回 distilled notes：核心概念、关键证据、反例、术语表、不能误讲的点。
主 writer context 读取所有 notes，用同一个讲解框架统一表达。

这样既保留了写作惯性，又避免了研究阶段的跨领域污染。

如果多个领域确实共享同一技术 ontology，例如都是网络安全协议、Transformer 内部机制、agent 编排方法，则可以让同一个 context 连续处理更多内容。此时惯性是有益的，因为它会复用术语体系和解释框架。

如果领域差异很大，例如医学指南、软件架构、金融风控、组织管理，则研究阶段必须拆开。否则一个领域的 utility 准则会污染另一个领域。

六、任务分配决策表

任务形态	推荐分配	context 策略	原因
单一小任务，目标明确	主 agent 直接做	保留惯性	沟通成本高于拆分收益
同一风格的长文写作	主 writer context	保留惯性	风格、读者模型、论证节奏需要统一
多领域材料收集	多 sub-agent	clean context	避免领域先验互相污染
多源调研和交叉验证	多 sub-agent，30% 到 50% overlap	clean context + 重叠	分歧本身是信号
代码实现，模块边界清楚	按模块分 worker	clean context + 接口契约	降低 context 污染和工具输出噪声
代码审查、安全审查、反证	独立 judge	clean context	需要抵消主线程锚定
最终取舍和版本判断	主 agent	保留惯性	需要对齐用户长期偏好和本仓库规则
方法论更新	主 agent + 人类审查 + validator	保留历史，但写入前显式校验	utility 层最难自动化
长上下文快满	compaction 或 fresh subagent	summary handoff	重建 task state，清除噪声

七、一个可执行的分配算法

面对一个复杂任务，先做五个判断。

这个任务是否需要同一写作风格或同一读者模型。需要则保留主 writer context。
这个任务是否需要独立证据路径。需要则拆 clean research context。
子任务之间是否共享大量 intermediate state。共享则少拆或串行拆。
子任务是否有可验证 artifact。可验证越强，越适合拆。
是否存在相邻框架误触发风险。存在则在 sub-agent prompt 中明确 should-not-trigger。

然后用三段式 contract 派任务。

declarative payload：这个 agent 必须知道哪些事实、路径、source、已有结论。

procedural contract：它要执行什么 workflow，输出什么 artifact，哪些边界不能越过。

utility criterion：结果如何被选择、比较或拒绝，例如证据强度、覆盖率、反例质量、是否能通过 validator。

这比“你负责 X 主题”更稳。主题名只定义了内容域，没有定义 task mode。

八、context 怎么放：前面、中间、后面

推荐结构：

前面放任务身份、硬约束、成功标准、冲突裁决规则。
中间放 bulk context：长文档、日志、参考材料、代码片段。
后面放当前请求、短版检查清单、验收标准。

前面负责 anchor，后面负责 current action，中间负责 evidence reservoir。

不要把唯一关键约束埋在中间。如果必须放长材料中间，前面要有索引，后面要有 checklist。

对 Skill 和 AGENTS.md 来说，这意味着：

必读规则和身份约束适合前置。
大量参考资料适合按需加载。
每轮具体任务的验收标准适合放在当前 user prompt 尾部。
长任务每 5 到 8 个复杂 action 应写一次 note 或 recap，防止 latent task state 漂移。

九、对 NightCode/context-infra 的设计含义

第一，sub-agent 的价值不只是并行，而是 state isolation。独立 context 可以让研究、验证、审查不被主线程的框架污染。

第二，handoff artifact 应该像 task vector，不像聊天摘要。最小字段是：任务、输入、输出格式、硬约束、已验证事实、未确认点、下一步。

第三，workflow 应区分编译层和执行层。研究 agent 产出 evidence，writer agent 产出 narrative，judge agent 产出 verdict。不要让一个 agent 同时承担三种 mode。

第四，Skill 写作要把 should-trigger 和 should-not-trigger 都写清楚。很多失败不是没触发正确 Skill，而是正确 Skill 和相邻 Skill 同时激活后没有 utility 裁决。

第五，重要发现必须落盘。context 惯性是短期状态，文件才是跨 session 的稳定接口。本次调研本身也是这个原则的例子。

十、可验证实验建议

如果要把这套判断变成你自己的经验数据，可以做三个小实验。

实验 A：讲解风格惯性

同一组 6 个知识点，比较三种条件：

单 context 连续讲。
每个知识点 fresh context，但给同一 style guide。
各 research agent 写 notes，主 writer 统一成稿。

评价：风格一致性、事实准确性、跨段术语一致性、是否出现领域污染。

预期：第三种最稳。第一种风格最统一，但事实污染风险高。第二种事实相对干净，但风格一致性依赖 style guide 质量。

实验 B：调研锚定污染

同一问题，让一个 agent 先读强观点文章再调研，另一个 clean agent 直接调研。比较 sources、反例数量、结论强度。

评价：是否过度引用先读材料，是否遗漏相反证据，是否把不确定结论写成确定。

实验 C：context 位置

把同一关键约束分别放开头、中间、尾部、开头加尾部。比较遵循率。

评价：约束漏遵守率、输出格式稳定性、事实引用准确性。

预期：开头加尾部最稳，中间最差。

十一、结论压缩

LLM 的 context 惯性是真实的。它的机制基础包括 ICL task vector、function vector、induction heads、KV cache、attention sinks、position bias 和 prompt order sensitivity。

但它不是人类式隐性知识。更准确地说，它是 current context induced latent task state。

任务分配上，应把它当成调度变量：

需要统一风格、统一读者模型、统一解释框架时，保留同一 context。
需要独立事实、独立反证、跨领域比较、审查验收时，拆 clean context。
需要两者兼得时，用 research agents 分离证据，用 writer context 保留风格。

一句话：

让 context 惯性服务于表达统一，不要让它接管证据判断。

Sources

本地材料

contexts/library/articles/2026-04-29_严肃聊聊_Skill到底能蒸馏我们的几分之几_Hao好聊趋势.md
methodology/llm_context_multi_topic_20260416_deep_research.md
methodology/llm_capability_boundary_20260417_deep_research.md
contexts/survey_sessions/coding_agent_skill_discovery_attention_decay_20260408_deep_research.md
methodology/llm_task_decomposition_20260414_deep_research.md
contexts/thought_review/think_attention_drift_case_study_20260410.md
contexts/thought_review/think_skill_philosophy_reflection_20260405_030727.md

外部来源

Version Decision

按 rules/skills/workflow_version_evolution.md，本文件是新建调研产物，属于兼容新增的研究文档。语义上应判为 research Y 级。由于当前 session 不主动 commit，本文件尚未形成可正确打 tag 的 commit 对象，tag 应在自动提交或人工提交完成后再落到包含本文件的 commit 上。

← 返回方法论库索引 · 返回方法论区