大语言模型在标准测试中成绩亮眼，但到了实际业务场景中却常常让人失望。原因并不神秘：模型的能力是通用的，但要执行具体任务就需要背景信息——你们的产品架构、业务规则、内部约定——而这些信息模型根本不知道。
想象一位天才工程师加入你的团队，他具备深厚的理论功底和卓越的编程能力，但对你们的产品架构、业务逻辑、技术债务、团队规范一无所知。更糟的是，关键的架构决策散落在不同团队成员的记忆中，代码库也缺乏文档。这位天才即便智力超群，也难以发挥真正的价值——这恰恰是当前 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。”** 他以自身经历举例——“自己在 OpenAI 的工作也没有那么难，如果换一个其他人，如果有他所有的 context，也是能干的。”同样的道理适用于 Agent：决定 Agent 能力上限的不是模型参数量，而是它在每个决策点能获得多少、多精准的上下文。翁家翌还指出，“团队合作中最大的问题也是 context 的不一致”，而“AI 短时间内无法取代人的最大原因也是 context——因为 AI 跟人并不在同一个环境里面”。这恰恰是上下文工程要解决的核心问题：如何把 Agent 需要的背景信息系统性地、结构化地送到模型面前。
那么，这些上下文信息在技术上到底是以什么形式送给大模型的？
