上下文工程
通过主动提供和组织上下文信息（如项目规范、领域知识、工具配置）来优化AI模型输出的工程实践，是提升AI编程助手效果的关键方法
核心事实
时间轴 (近 90 天)
上下文工程是构建高质量上下文来提升大模型效果；驾驭工程是打造能长时间稳定、可靠、安全运行的智能体；Loop工程则针对智能体的闭环迭代与持续自我优化。
多数编程助手需要用户手动维护上下文文件、规则文档或记忆库，项目复杂时维护成本较高。
三层循环的每一层都依赖可靠的上下文供给：执行层需要当前任务状态，验证层需要原始需求与产出对照，改进层需要完整trace。
长任务Agent的失败很大一部分源于上下文管理失当，例如历史消息无限累积导致关键信息被稀释，或在压缩摘要时丢失必须遵守的约束。
Anthropic技术团队成员Lamis在AI DevCon上系统回顾了上下文工程（Context Engineering）近一年的演进路径。
上下文工程实践中的典型模式包括分层上下文、动态摘要、工具输出过滤和上下文预算。
知识应放入上下文还是通过微调固化进模型，目前仍以经验判断和小规模对比实验为主，尚无通用决策框架。
上下文工程的责任归属（应用层实现 vs 下沉到模型或框架层）目前边界模糊，两种路线都有尝试。
上下文工程将模型可见的全部信息（系统提示、检索片段、工具输出、历史对话、用户画像）视为需要主动设计和动态治理的资源系统。
在多Agent工作流中，交接时给下一个Agent过多上下文会导致其淹没在无关历史中，甚至拿过时事实当依据；给得太少则使其只能瞎猜或以重新打开全部历史为代价求助。
还有 40 条时间轴事件
全部知识事实 (20)
AI开发经历四个阶段演进：单次调用大模型、Prompt Engineering、Agent与工具调用、Loop Engineering
90%已验证上下文工程（Context Engineering）是一种新范式，为 AI 提供完整的体系化上下文，包括项目文档、代码示例、编码规则、开发模式和验证机制
80%已验证大多数 AI 编程智能体无法有效完成复杂任务的主要原因是上下文缺失，而非模型能力不足
80%已验证Context Engineering关注如何精确管理传入模型的上下文窗口，Harness Engineering偏向基础设施层，与Loop Engineering同期出现
65%已验证系统提示词（system prompt）是大语言模型对话架构中优先级最高的指令层，在用户消息之前注入并影响模型对所有后续输入的处理方式
65%已验证上下文工程是系统性地设计和优化输入给LLM的上下文信息，使模型在有限的上下文窗口内获取最相关的信息来完成任务
65%已验证记忆系统必须主动筛选而非无差别存储，需回答该记住什么、如何精准检索、如何及时遗忘三个核心问题
65%已验证上下文工程是指系统性地设计、管理和优化输入给大语言模型的上下文信息的工程实践，与提示词工程侧重于单次交互的措辞优化不同
65%已验证AI开发正在从'Prompt工程'走向'Agent工程'，前者核心技能是写自然语言指令，后者核心技能是设计系统架构
65%待验证吴恩达认为过去几年行业注意力集中在提示工程和上下文工程上，但对于需要持续运行数天甚至数周的Agent来说这远远不够
90%待验证在真实上下文工程场景中，上下文散布在多个来源：本地文件系统、数据库、Web、长期记忆等，每种上下文源需要对应的搜索工具
90%待验证AGENTS.md的实践与'上下文工程'（Context Engineering）的理念密切相关，代表了从提示工程到上下文工程的演进
85%待验证上下文工程的重心已从'如何塞进更多信息'转变为'如何确保正确的信息出现在正确的位置'
80%待验证在AI编程中，提前设计好数据结构并提供JSON文档给AI（即'上下文工程'）能大幅提升代码生成的准确度，这是区分AI编程新手与熟练用户的核心能力差异之一
75%待验证行业正在经历从'模型中心'到'系统中心'的范式转移，单纯提升模型参数和训练数据的边际收益在递减
70%待验证上下文工程（Context Engineering）概念由Shopify CEO Tobi Lütke等人在2025年推广，核心理念是AI应用的质量取决于如何为模型构建和管理上下文
60%待验证上下文工程被定义为一种超越提示工程的系统化方法论，提示工程是上下文工程的一个子集
60%待验证上下文工程是在RAG之上的进一步演进，不仅关注信息的召回率，更关注注入上下文的结构质量、可信度层级和冲突标记
60%待验证上下文工程使得零编程基础的用户也能开发复杂项目
60%待验证上下文工程是构建高质量上下文来提升大模型效果；驾驭工程是打造能长时间稳定、可靠、安全运行的智能体；Loop工程则针对智能体的闭环迭代与持续自我优化。
50%