方法论 常见叫法
Context Engineering
围绕模型或 agent 能获得哪些上下文、如何组织上下文、怎样减少错误引用和遗漏而进行的设计工作。
One-line Definition
Context Engineering 关注的是给模型或 agent 什么上下文、如何组织和裁剪这些上下文。
官方名称
Context Engineering
常见别名
上下文工程
这个词条适合做什么
适合先快速判断定义和边界，再继续进入相关文章或官方来源。
这是什么
- + 它更偏输入侧和知识可见性设计。
- + 它常和 Prompt Engineering、Harness Engineering 一起出现，但关注点不同。
不是什么
- - 不是简单把所有背景都塞进上下文窗口。
- - 不是完整的长期工程约束体系。
为什么最近常被提到
- • 它有助于解释为什么 repo 入口、知识源组织和上下文可见性会直接影响 agent 表现。
如果 Prompt Engineering 更像“怎么说”，Context Engineering 更像“让它看到什么”。
可信来源
下一步阅读
什么是 Harness Engineering：当 AI 开始写代码后，工程重点为什么从写代码转向设计约束与反馈回路
Harness Engineering 不是又一个花哨名词，而是当 AI coding agent 真正进入生产开发后，团队如何通过仓库结构、文档、校验、观测和回路，让代理稳定交付的软件工程方法。
Harness Engineering vs Prompt Engineering：团队开始让 agent 连续改仓库后，重点为什么会变
Prompt Engineering 解决的是单次交互质量，Harness Engineering 解决的是 agent-first 团队的长期稳定性。把这两层分开，很多工程判断会一下子清楚。
怎么把 Agent 工作流从 demo 变成稳定系统：真正难的不是搭出来，而是跑得住
很多 Agent 工作流 demo 看起来很顺，一上线就开始卡、飘、返工。真正的问题通常不在模型本身，而在目标、步骤、反馈、人工确认和回退机制。