Context Engineering MOC
Agent 上下文工程知识地图，按上下文来源、预算、组装、压缩、结构化状态、RAG/Memory 注入、协议边界和反模式组织学习路径。
#moc
#growing
#ai
#architecture
[!info] related notes
Context Engineering MOC
知识总览
filters:
and:
- 'file.ext == "md"'
- 'file.inFolder("z")'
- 'this.file.links.contains(file)'
- 'file.path != this.file.path'
formulas:
knowledge: 'file.asLink(title)'
properties:
formula.knowledge:
displayName: 知识
note.description:
displayName: Description
note.mastery:
displayName: Mastery
views:
- type: table
name: 知识总览
order:
- formula.knowledge
- note.description
- note.mastery
columnSize:
formula.knowledge: 280
note.description: 760
note.mastery: 56[!abstract] 核心认识 Context Engineering 是系统化决定模型这一轮能看到什么、以什么结构看到、哪些信息必须被排除。Prompt 只是上下文的一部分；State、RAG、Memory、Tool Schema、工具结果和运行环境同样属于上下文来源。
一张图看 Context Builder
Instructions
+ User Input
+ Runtime State
+ Recent History / Summary
+ Retrieved Evidence
+ Selected Memory
+ Tool Definitions / Results
+ Environment Observation
↓ select / validate / compress / order
Context Builder
↓
Context Contract
↓
Model Call推荐学习顺序
- Context Engineering：定义和职责边界。
- 信息层边界：分清规则、现场、外部知识和长期状态。
- 上下文窗口预算：把 token 当有限资源。
- Context Builder 模式：将组装逻辑从 prompt 字符串中抽离。
- 结构化 State：业务状态不能只藏在聊天历史里。
- RAG Engineering MOC：检索证据如何进入上下文。
- Agent Memory Types & Policies：记忆如何选择性注入。
- Tool Calling Engineering MOC：Tool Schema 与 Tool Result 的上下文边界。
- Context Contract：跨服务传递时保持 schema、来源和版本稳定。
- 结构化信息采集、Context Anti-patterns。
Context 质量模型
每段信息进入模型前都应回答：
| 维度 | 核心问题 |
|---|---|
| Relevance | 当前决策真的需要吗 |
| Authority | 来源是否有资格支持该结论 |
| Freshness | 是否过时，时效窗口是什么 |
| Consistency | 是否与其他事实冲突 |
| Completeness | 关键字段或证据是否缺失 |
| Isolation | 是否混入其他用户、任务或租户内容 |
| Budget | 价值是否值得占用 token |
| Provenance | 能否追溯从哪里来、怎样处理过 |
State 不等于 History
Chat History
→ 用户和模型说过什么
Structured State
→ 当前任务真正处于什么状态年龄、审批状态、已执行动作、证据缺口等关键业务状态应有显式 schema；不能要求模型每轮从自然语言重新猜。
RAG 与 Memory 如何进入 Context
RAG
→ query current external knowledge
→ retrieve evidence
→ rank / filter / cite
Memory
→ retrieve prior user/project experience
→ validate scope / freshness / permission
→ inject selected facts“检索到了”不等于“应该放进上下文”，还要经过来源、冲突、权限和预算判断。
Context Engineering 与 Prompt Engineering
- Prompt Engineering：怎样表达任务、角色、格式和约束。
- Context Engineering：整轮调用的信息选择、状态组装、证据治理、压缩、隔离与生命周期。
Prompt 是局部表达层，Context 是完整输入系统。
常见反模式
- 全量聊天历史直接拼接；
- 把业务状态只存在自然语言里；
- 检索结果不带来源、版本或权限；
- 把工具完整原始输出永久塞入后续每一轮；
- 多 Agent 共用未隔离的上下文；
- 为了“信息越多越好”占满窗口，反而稀释关键约束。
项目映射
BodySense
用户事实、当前症状、红旗证据、姿态证据、已完成问诊阶段和工具结果应分别建模，再由 Context Builder 按当前决策组装。
Coding Agent
任务规格、代码片段、构建结果、历史决策、仓库规则和当前 diff 的来源与时效不同，不应无差别地塞进同一个 prompt。
掌握标准
- 能区分 Context、Memory、RAG、State 和 Instruction。
- 能为一次模型调用列出每类输入的来源和预算。
- 能解释哪些信息必须结构化，哪些可以保留为文本。
- 能识别污染、冲突、过时、越权和注意力稀释。
- 能让输出或决策回溯到具体上下文来源。
Digital Biome