第 8 章：上下文工程与长任务

“上下文工程”把问题从“写好 prompt”扩展到“当前这一轮推理里应该放什么”。工程文章强调上下文是有限资源，越长并不等于越好，因为模型在长上下文里会出现注意力分散与检索困难。工程目标不是填满窗口，而是把最关键的信号留下来。[61]

这意味着系统指令必须在“过于细碎”和“过于抽象”之间找到恰当层级。过度细化会让提示词变成硬编码逻辑，过度抽象又会让模型理解不足。官方建议把指令分块组织、用明确段落区分背景、工具指引和输出结构，但更重要的是保持“最小充分信息”。[61]

工具也属于上下文工程的一部分。工具描述越清晰，模型越少误判；工具返回越精简，模型越容易抓住重点。工程文章明确指出，工具集合过大、语义重叠会导致模型在调用时犹豫或选错，这是上下文工程的一个常见失败模式。[61][65]

上下文工程的另一半在运行时。文章提出“按需检索”的策略：模型保留文件路径、查询语句、索引标记等轻量线索，需要时再用工具加载内容。这种做法与人类的外部记忆相似，不要求模型把所有信息塞进当前窗口，而是通过工具去取。[61]

当任务跨度很长时，单一上下文无法承载全部信息。工程文章给出三类常见方案：对话压缩（把重要决策浓缩成新的上下文），结构化笔记（把长期状态写进外部文件），以及子代理并行探索（把大任务拆分为多个独立窗口，再把结果汇总）。[61][25]

Memory 工具可以视作“结构化笔记”的官方实现，它允许 agent 把重要状态写到外部存储，再在需要时回读。与会话机制结合后，它可以让长期任务持续运行，而不必依赖单次上下文承载全部信息。[11][34]

长任务不仅需要上下文策略，还需要一个稳定的执行框架。关于长任务 harness 的工程文章提出双角色结构：初始化代理负责搭建工程环境与进度记录，后续执行代理只做增量推进，并把结果写回进度文件与版本控制记录。这样每次新会话都有明确起点，不会在“我做过什么”上消耗上下文。[62]

在这套结构里，功能清单是一个关键部件。它把大目标拆成可验证的小项，执行代理只改动一项再写入进度，避免一次性尝试整个项目导致中途断裂。配合基本测试步骤，agent 可以在每次会话开始时先确认系统状态，再继续推进。[62]

上下文工程的最终目标不是“减少信息”，而是“把信息放在最合适的位置”。当系统把指令、工具、检索与长期记忆组织起来，agent 才能在多个上下文窗口之间保持一致性与方向感。[61][62]