什么是 Context Engineering？
Context Engineering（上下文工程）是为特定任务设计和运营送入语言模型的信息的过程，包括指令、任务数据、检索证据、状态、工具结果，以及它们的来源、权限、新鲜度和预算。
快速了解
| 创建时间 | 伴随长上下文 LLM 和 AI IDE 的普及而兴起 |
|---|
工作原理
上下文工程是一门工程学科，不承诺更长的 Prompt 或某个规则文件就能让模型可靠。可用的上下文契约应明确任务、Principal 和 Tenant、允许来源、来源版本、新鲜度、敏感性、Token 与延迟预算、输出契约及失败行为。它补充提示词工程：措辞仍然重要，但系统还必须选择、排序并校验围绕措辞的信息。 应区分稳定指令、检索知识、工作状态、长期记忆和运行时工具结果。检索文档、注释、摘要与工具输出可能过期、恶意、不完整或未授权。先执行访问控制，再检索和排序；保留引用；提供“无证据”路径；不要让模型、文档或规则文件为数据访问或外部副作用授权。 项目规则或 Agent 指令文件等厂商特定文件只是适配器，不是通用标准。其加载路径、优先级、作用范围和版本支持必须在目标 Host 中测试。应在代表性任务上通过任务成功率、证据覆盖率、矛盾与泄露率、延迟、成本和人工修正衡量上下文变更，而不是依赖固定 Token 比例或“消除幻觉”的承诺。
主要特点
- 任务契约：在组装请求前明确结果、约束、证据范围、预算与验证
- 信任分层：按来源和生命周期区分指令、知识、记忆和运行时结果
- 权限优先选择：在相关性排序或压缩前应用 Tenant 和对象授权
- 来源与新鲜度：记录来源、版本、权威性、有效期和引用要求
- 有预算的组装：预留输出空间，必要上下文无法放入时降级或安全失败
- 基于证据的评测：用可复现任务比较上下文版本的质量、安全、延迟、成本与恢复能力
常见用途
- 为编码任务准备包含接口、测试、风险和验收条件的有界任务包
- 构建按权限、新鲜度、权威性、多样性和结果大小过滤的 RAG 回答
- 维护具备同意、过期、纠正、删除和 Tenant 隔离的 Agent 状态
- 把已审核的项目契约适配到经过测试的 AI 编码客户端，而不假设通用规则文件
- 使用证据支持的回归集评估检索、记忆或上下文压缩变更
示例
Loading code...常见问题
上下文工程和提示词工程有什么区别？
提示词工程关注指令与表达；上下文工程还治理证据选择、状态、来源、权限、排序、预算和评测。二者有重叠，但都不能替代可信授权、输出校验或应用逻辑。
更多上下文会减少幻觉吗？
不一定。额外上下文可能过期、矛盾、无关或带有对抗性，并遮蔽必要约束。应按任务、权限、权威性、新鲜度和覆盖度选择证据，再用真实任务评估无依据断言率和引用率。
AGENTS.md、Cursor Rules 等是否是上下文工程标准？
不是。这些文件是客户端特定的集成约定。应核验目标客户端的版本、路径、优先级、作用范围和是否需要显式启用；规范性项目要求应保留在经过审核的权威来源中，厂商文件只作为窄适配器。
检索文档或工具结果能授予访问权限吗？
不能。检索内容和工具输出都是不可信数据。认证建立 Principal；可信的服务端策略必须对每次请求授权 Tenant、对象、操作、目的、配额和副作用。
团队应如何评估上下文变更？
固定模型、Tokenizer、上下文版本与代表性 Fixture。对比任务成功率、证据和引用覆盖率、矛盾率、未授权披露、延迟、Token 成本、恢复行为和人工修正，并与基线比较。