【Harness Engineering（1）】如何判断一个系统是否真的进入上下文工程

很多人理解上下文工程第一反应是这不就是把提示词写长一点吗这个理解看起来没错。很多上下文工程的结果确实是一段更长、更完整的输入。但如果只看到“长”就会错过真正的变化。上下文工程的关键不是输入变长了而是任务语境开始由系统负责维护。提示词工程解决的是“我怎么把话说清楚”。上下文工程解决的是“模型在每一步工作时应该知道什么、忽略什么、更新什么”。这两个问题听起来接近工程含义完全不同。一、问题不在提示词太短而在语境缺失书里用了一个购车例子用户问“理想 L6 怎么样”这个问题太短。模型可以回答很多参数比如空间、续航、智驾、价格、品牌定位。但这些回答大多是通用信息。因为模型不知道提问者是谁也不知道他在什么约束下做决策。他是第一次买车还是老车主换车预算是多少通勤还是长途家里几口人更看重操控、安全还是智能化能不能接受增程准备开几年这些信息没有进入上下文模型只能输出“看起来全面但对决策帮助有限”的回答。于是很多人会得出一个结论提示词要写长一点。这个结论只对了一半。如果用户自己补充通勤距离、家庭成员、预算、试驾反馈、电池供应商再问一次模型当然会答得更好。但这里真正发生的变化不是提示词从一句话变成了一段话而是决策所需的语境被补齐了。购车决策需要个人约束、评价维度、外部知识和现实反馈。预算、家庭成员、用车周期是约束安全、操控、续航是评价维度电池供应商、竞品差异是外部知识试驾感受和车主反馈是现实反馈。这些信息不是修辞而是判断材料。所以提示词工程和上下文工程的分界不在于字数而在于责任归属。如果语境完全靠用户一次性组织好那仍然主要是提示词工程。如果系统能主动识别缺什么、去哪里取、如何筛选、怎么更新再把它组织成模型下一步需要的输入这才进入上下文工程。二、上下文工程的分界是语境由系统维护换一个工程场景你让 Agent 分析一个陌生代码仓库并输出架构说明。最朴素的提示词可能是帮我分析这个项目的架构。这句话和“理想 L6 怎么样”一样太空。模型如果只能看到这一句话就只能给一套泛泛的方法论先看目录再看 README再看入口文件再看模块关系。你可以把提示词写长一点请分析项目架构包括目录结构、核心模块、数据流、启动方式、测试方式、潜在风险并用 Markdown 输出。这比第一版好但它仍然没有真正看到项目。它只是把输出格式讲清楚了。真正的上下文工程会让系统开始行动先列出仓库文件判断 README、配置文件、入口文件在哪里读取关键文件而不是读取所有文件根据发现继续追踪模块依赖把无关日志、重复文件、生成产物排除把中间发现压缩成结构化摘要最后再让模型写架构说明。这时模型的输入不是一条更长的提示词而是一份被系统逐步构建出来的任务语境。这个差异很关键。提示词工程仍然假设人已经知道该放什么信息并且能一次性组织好。上下文工程则承认复杂任务一开始往往不知道缺什么信息必须在任务推进中不断发现、筛选和修正。换句话说提示词工程是一次表达上下文工程是一个维护过程。三、判断一个系统是否进入上下文工程判断一个系统是否真正进入上下文工程可以先看三件事。第一信息是不是动态获得的。如果所有信息都由用户在开始时一次性提供它更接近提示词工程。如果系统会随着任务推进去读文件、查资料、调用 API、执行命令并把结果带回模型它开始具备上下文工程特征。但关键不在于有没有工具而在于工具结果是否改变了下一步判断。第二信息是不是经过选择和结构化。上下文不是资料越多越好。代码仓库里可能有源码、测试、缓存、构建产物、锁文件、日志。全部塞给模型只会让模型分心。上下文工程必须回答哪些信息进入当前窗口哪些只保留引用哪些应该丢弃。同样一批信息散乱堆放和结构化组织效果完全不同。好的上下文会区分目标、约束、事实、假设、观察、待验证问题。没有结构的上下文只是更大的文本块。第三信息是不是会随任务推进更新。复杂任务里早期判断经常会被后续观察修正。一开始以为项目是普通 Web 服务后来发现它是一个脚手架一开始以为性能问题在数据库后来发现慢在权限服务。上下文工程要允许旧判断被覆盖、压缩或标记为已失效。这也是很多长提示词失败的原因它们增加了信息量但没有提高决策质量。真正有用的上下文不是让模型知道更多而是让模型下一步更好判断。如果一段信息不能帮助下一步计划、执行、校验或收束它就可能只是噪声。四、上下文工程也有代价不是所有任务都需要上下文工程。如果任务是单轮、低风险、信息完整的提示词工程就够了。比如改写一段文案、总结一段已给出的文本、生成一个固定格式模板。这些任务没有复杂外部状态也不需要持续探索。这时引入 Agent、记忆、Skills、上下文压缩反而会让系统变重。上下文工程适合的是另一类任务目标开放信息不完整需要多步探索且中间观察会影响后续判断。比如代码仓库分析、深度研究、复杂运维诊断、企业知识问答、ChatBI 查询。这些任务的问题不在于“提示词还不够好”而在于“任务语境无法靠人一次性准备完整”。当然上下文工程不是免费午餐。它会引入系统复杂度。你需要工具、状态、记忆、压缩、选择策略还要处理失败路径。它也会引入错误传播。工具拿到的信息可能错摘要可能丢关键信息早期错误判断可能影响后续探索。它还会带来噪声治理问题。系统越主动收集信息越容易把无关内容带进上下文。所以上下文工程的目标不是“让系统尽可能多地收集信息”而是让系统在约束下持续维护一份足够好的工作记忆。足够好比看起来全面更重要。提示词工程的核心动作是把一句输入写清楚。上下文工程的核心动作是让系统持续维护任务语境。二者的分界不在长度而在过程信息是否由系统动态获得、筛选、结构化、更新并服务于下一步行动。如果只是把更多背景一次性塞进模型那只是长提示词。如果系统能在任务过程中持续改善模型的工作记忆那才是上下文工程。