上下文决定上限

大语言模型在标准测试中成绩亮眼，但到了实际业务场景中却常常让人失望。原因并不神秘：模型的能力是通用的，但要执行具体任务就需要背景信息——你们的产品架构、业务规则、内部约定——而这些信息模型根本不知道。

想象一位天才工程师加入你的团队，他具备深厚的理论功底和卓越的编程能力，但对你们的产品架构、业务逻辑、技术债务、团队规范一无所知。更糟的是，关键的架构决策散落在不同团队成员的记忆中，代码库也缺乏文档。这位天才即便智力超群，也难以发挥真正的价值——这恰恰是当前 AI Agent 面临的困境。

上下文的质量才是能力的真正上限

以一个 Coding Agent 为例。同样是“帮我修复这个 bug”的指令，agent 拿到的上下文质量直接决定了它能否完成任务：

• 实时代码上下文：当前代码库的目录结构、各模块的职责划分、核心数据结构的定义、团队的代码规范。没有这些，agent 写出的代码可能语法正确但风格与项目格格不入，甚至引入架构层面的冲突。
• 流程规范：Git 分支策略、代码提交规范、代码审查流程、CI/CD 管线的要求。缺少这些，agent 可能直接往主分支提交未经测试的代码。
• 环境信息：开发环境的配置、测试数据库的连接地址、staging 环境的部署方式、API 密钥的管理方式。没有这些，agent 在本地能跑通的修复，到了测试环境可能立刻崩溃。

这三类信息——代码、流程、环境——构成了 agent 有效工作的最低信息需求。模型本身的智力只是基础，上下文的质量才是 agent 能力的真正上限。一个中等能力的模型配上精心组织的上下文，往往能胜过一个顶级模型在信息匮乏下的盲目摸索。

上下文工程首先是一个组织问题

上下文工程因此成为利用现有模型开发高效 agent 的关键所在。它不仅仅是往 prompt（提示词）里塞更多信息的技术问题，而是要系统性地设计、组织和提供 AI 完成任务所需的全部背景知识。上下文工程首先是一个技术问题，但更根本的是一个组织问题。大多数团队的关键知识都是隐性的：架构决策只有老员工记得，业务规则靠口口相传，重要的背景信息锁在私聊记录里。如果团队本身就是一个信息黑洞，再好的 AI Agent 也无计可施。

对远程工作友好的团队往往也对 AI Agent 友好。像 Linux 内核这样的开源项目就是一个很好的范例：分布在全球的开发者协作维护了三十多年，成功的秘诀是高度透明、文档驱动的沟通文化——所有讨论公开进行，每个决策都有详细的记录，任何新加入者都能通过阅读历史来理解代码的演化逻辑。这种工作方式天然创造了对 AI 友好的环境：信息是公开的、可检索的、结构化的。

AI Agent 就像一个永远的新员工：给足背景信息，它能干得很好；什么都不告诉它，再聪明也是白搭。所以构建 AI 原生团队，首先是一场文档化运动，而不只是部署新工具。

OpenAI 研究员翁家翌曾精辟地总结这个观点：“人和模型一样，最重要的是 Context。” 决定 agent 能力上限的不是模型参数量，而是它在每个决策点能获得多少、多精准的上下文。这恰恰是上下文工程要解决的核心问题：如何把 agent 需要的背景信息系统性地、结构化地送到模型面前。

那么，这些上下文信息在技术上到底是以什么形式送给大模型的？上下文工程的其余各页依次展开：

• API 的上下文结构——上下文在技术上就是一个消息列表
• KV Cache 友好的上下文设计——缓存如何反过来约束上下文的设计
• 提示工程、Agent Skills、Agent 状态栏、上下文压缩