第二站：Context Engineering

第二站：Context Engineering#

Agent 火起来之后，模型不再只是"回答问题"，而是真要进到环境里"干活"了。

系统面对的问题变了：

每一次发给模型的全部信息加在一起，就叫上下文（Context）。提示词只是其中很小的一块。

上下文的组成：

Context = 提示词
        + 系统消息
        + 历史对话
        + 工具描述
        + 工具返回结果
        + 检索到的外部知识
        + 任务状态/进度
        + 环境感知信息

这里有个要命的现实：模型一次能装的上下文是有上限的（上下文窗口，Context Window）。

约束链：

任务复杂度 ↑ → 所需上下文量 ↑ → 逼近窗口上限 → 必须取舍

取舍维度：

更麻烦的是：塞太满，注意力反而涣散。

Anthropic 给这个现象起了个名字：context rot（上下文腐化）。

上下文塞得越满
    ↓
模型注意力被稀释
    ↓
关键信息被淹没在噪声中
    ↓
输出质量反而下降

这意味着"给得多"不等于"给得好"。超过某个阈值后，信息量增加反而带来负收益。

Anthropic 那套 Agent Skills 的"渐进式披露"（Progressive Disclosure）就是这个理念的极致实践：

核心理念：平时只给模型看一份能力目录，等它判断真要用某个能力了，才把详细说明动态加载进来。

Context Engineering 的核心，不是"给得多"，而是"给得准"。

工程实践要点：

Context Engineering 解决的核心瓶颈是"给什么"。

它承接 Prompt Engineering 的局限：

但它也很快遇到新瓶颈：当任务链路变长、模型需要连续工作数小时时，单纯把上下文管理好已经不够——模型在长链路中会跑偏，需要外部监督。这催生了 Harness Engineering。