在近日的一场技术分享中，开发者布道师Baruch Sadogursky与DevOps领域知名专家Patrick Debois共同探讨了编码智能体（coding agents）失败的核心原因——上下文窗口膨胀与提示词过载。他们提出，与其盲目堆砌10万个Token的上下文，不如精心设计300个高相关性的Token，这一观点正在重新定义大模型应用中的“上下文工程”实践。
两位专家指出，当前许多开发者在构建基于大模型的编码工具时，倾向于将尽可能多的代码库内容、历史对话和系统文档塞入上下文窗口，期望模型“看到更多就能做得更好”。然而实际效果往往适得其反：过长的上下文不仅增加了推理成本，还稀释了关键信息的权重，导致模型在无关细节中迷失，生成错误或低质量的代码建议。Sadogursky强调，上下文工程的核心不是“更多”，而是“更精准”——通过结构化筛选和优先级排序，让模型聚焦于真正影响输出的少数关键信息。
针对这一痛点，他们提出了一套实用的上下文工程解决方案。首先是“懒加载技能”（lazy-loaded skills），即按需加载特定任务所需的工具和知识，而非一次性全量注入；其次是“版本化上下文工件”（versioned context artifacts），将上下文作为可管理、可追溯的版本化资产，确保每次调用的上下文状态一致且可控；第三是“外部化记忆库”（externalized memory banks），将长期记忆存储在外部系统中，仅在需要时检索相关片段，避免上下文无限膨胀；最后是“LLM-as-a-judge”评估机制，利用大模型自身对输出质量进行自动化评判，从而持续优化上下文配置的有效性。
这一方法论对软件架构师和工程负责人具有直接参考价值。在实际的智能体工作流中，原始Markdown文档往往包含大量冗余信息，直接作为上下文输入会导致效果不稳定。通过上述上下文工程手段，团队可以将这些非结构化文档转化为可靠、可复用的智能体工作流，显著提升编码智能体在真实项目中的准确率和稳定性。Debois补充说，上下文工程并非一次性优化，而应作为持续迭代的工程实践，与模型版本更新和业务需求变化同步演进。
随着大模型在企业级应用中的渗透率不断提升，上下文工程正从幕后走向台前，成为决定AI应用实际效果的关键变量。对于依赖大模型构建生产力工具的企业而言，掌握这一技术意味着在同等算力成本下获得更优的业务回报。未来，如何将上下文工程标准化、工具化，并融入现有的开发运维体系，将是企业服务领域值得关注的重要方向。
该文观点仅代表作者本人，企服科学平台仅提供信息存储空间服务。
