outcomeops/context-engineering

来源：https://github.com/outcomeops/context-engineering

上下文工程

上下文工程的一个实际参考实现——该学科涉及设计、检索和注入 AI 系统生成准确的、特定于组织的输出所需的信息。

本仓库是 What Is Context Engineering? (https://www.outcomeops.ai/context-engineering) 的代码配套，文章在 outcomeops.ai 上。词汇表定义了概念，本仓库展示了它们针对 Amazon Bedrock 上真实语料库的端到端运行。

上下文工程将上下文视为一流的工程制品——版本控制、可检索、可强制执行——而不是输入到聊天窗口的提示。

五个组件

上下文工程系统有五个组件。每个文件夹针对相同的运行示例（一个带有 ADR 的 Spring PetClinic 代码库）实现一个：

加上 comparisons/ — 同一任务使用和不使用上下文工程的对比，以及 CE 与 RAG、Copilot 和代理框架的区别。

仅包含组件 1–3 的系统是 RAG 系统。输出和强制执行层是 CE 的不同之处——它们使生成的内容可审查且可治理。

运行示例

所有示例使用 Amazon Bedrock 和 Claude。每个文件夹都有自己的 requirements.txt 和 README.md，包含可运行命令。

前置条件：

• Python 3.11+
• 配置了凭证的 AWS 账户（aws configure 或环境变量）
• 支持 Claude 和 Titan 的 AWS 区域（如 us-east-1、us-west-2）

本仓库使用 Anthropic Claude 进行生成，使用 Amazon Titan 进行嵌入。Titan 和大多数 Bedrock 基础模型在首次调用时自动启用 — 无需任何操作。

Anthropic Claude 需要每个 AWS 账户填写一次首次使用 (FTU) 表单。 如果你的账户从未在 Bedrock 上使用过 Anthropic 模型，第一次脚本运行将失败并显示 AccessDeniedException。要修复：

1. 在 Bedrock 模型目录中打开任何 Anthropic Claude 模型 (https://console.aws.amazon.com/bedrock/home#/model-catalog)
2. 填写首次使用表单（公司、用例——约一分钟）
3. 提交 — 访问权限立即获得，无需审核队列

如果你在 AWS 组织子账户中，必须从管理账户提交表单才能继承访问权限。

快速开始：

git clone https://github.com/outcomeops/context-engineering.git
cd context-engineering/01-corpus
pip install -r requirements.txt
python ingest_adrs.py ./sample-adrs

如果要覆盖默认值，可通过环境变量设置模型：

export BEDROCK_MODEL_ID="us.anthropic.claude-sonnet-4-5-20250929-v1:0"
export AWS_REGION="us-east-1"

为什么有这个仓库

大多数 AI 编码助手生成通用输出。使用通用助手的工程师仍然必须将输出调整为本地模式——助手不知道你的团队上季度做了什么决策、你的合规框架要求什么，或者你为什么选择了某个库而不是另一个。

上下文工程系统生成的输出已经符合本地模式，因为检索层在决策时已经向模型提供了相关的 ADR、代码和标准。强制执行层确保输出确实引用了它所依赖的内容。

这个仓库的存在是为了在代码中展示这种模式的端到端运行，所以团队可以自己构建它或评估声称可以做到这一点的商业工具。

上下文工程改变组织，而不仅仅是代码

五组件模型是技术框架。真正一致部署它的团队发现更难的转变是组织方面的。传统软件组织中的角色、KPI 和决策权是在 AI 无法读取语料库的世界中形成的。一旦它能做到，该结构的中间层开始看起来不同——而上面的仓库首先有用是因为那些变化。

• 结果工程师的崛起 (https://www.outcomeops.ai/blogs/the-rise-of-the-outcome-engineer) — 新兴角色
• 拥有成果的工程师 (https://www.outcomeops.ai/blogs/engineers-who-own-the-outcome) — 运营模式
• OutcomeOps 和上下文工程：DevOps 之后的下一个企业演进 (https://www.outcomeops.ai/blogs/outcomeops-and-context-engineering-the-next-corporate-evolution-beyond-devops) — DevOps 之后的发展
• 传统产品负责人的死亡 (https://www.outcomeops.ai/blogs/death-of-the-traditional-product-owner) — 产品侧角色转变
• 衡量真正重要的东西 (https://www.outcomeops.ai/blogs/measurng-what-actually-matters) — KPI 转变

进一步阅读

关于上下文工程作为一门学科的基础文章、参考指南和实践者撰写的文章：

• AI 代理的有效上下文工程 (https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents) (Anthropic, 2025 年 9 月) — 策划和限制代理看到的内容
• 上下文工程的崛起 (https://blog.langchain.com/the-rise-of-context-engineering/) (LangChain, 2025 年 6 月) — 使该术语广泛使用的文章
• 代理的上下文工程 (https://blog.langchain.com/context-engineering-for-agents/) (LangChain, 2025 年 7 月) — 写/选择/压缩/隔离框架
• 上下文工程：为提示带来工程纪律 (https://addyo.substack.com/p/context-engineering-bringing-engineering) (Addy Osmani, 2025 年 7 月) — 工程纪律框架
• 上下文工程指南 (https://www.promptingguide.ai/guides/context-engineering-guide) (PromptingGuide.ai) — 参考条目
• 记录架构决策 (https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions) (Michael Nygard, 2011) — 原始 ADR 文章；本仓库全程使用的格式
• OutcomeOps 和上下文工程：DevOps 之后的下一个企业演进 (https://www.outcomeops.ai/blogs/outcomeops-and-context-engineering-the-next-corporate-evolution-beyond-devops) (OutcomeOps) — 本仓库背后的组织论文
• OutcomeOps：自文档化架构 — 当代码变成可查询的 (https://www.outcomeops.ai/blogs/outcomeops-self-documenting-architecture-when-code-becomes-queryable) (OutcomeOps) — ADR 语料库如何随代码演进而复合
• 知识的真实成本：为什么大多数 AI 工程平台过度设计 RAG (https://www.outcomeops.ai/blogs/the-real-cost-of-knowledge-why-most-ai-engineering-platforms-over-engineer-rag) (OutcomeOps) — 反对过早的检索基础设施
• AI 辅助开发在两年内实际看起来的样子 (https://www.outcomeops.ai/blogs/what-ai-assisted-development-actually-looks-like-in-two-years) (OutcomeOps) — 工作开发者的视角

配套仓库

• bonigarcia/context-engineering (https://github.com/bonigarcia/context-engineering) — 来自 Boni García 的书籍配套；按章节组织，包含多语言示例
• davidkimai/Context-Engineering (https://github.com/davidkimai/Context-Engineering) — 概念、模式和技术
• Meirtz/Awesome-Context-Engineering (https://github.com/Meirtz/Awesome-Context-Engineering) — 精选的论文、工具和文章列表
• joelparkerhenderson/architecture-decision-record (https://github.com/joelparkerhenderson/architecture-decision-record) — 决定性的 ADR 资源列表

按组件深入探讨

每个文件夹的 README 都有自己的策划阅读列表；快速索引：

• 语料库 — 见 01-corpus/ — ADR 格式、语料库引导、自文档化架构
• 检索 — 见 02-retrieval/ — FAISS、“Lost in the Middle”、检索经济学
• 注入 — 见 03-injection/ — 提示结构、令牌预算、推理成本
• 输出 — 见 04-output/ — JSON Schema、Bedrock 工具使用、结果工程师
• 强制执行 — 见 05-enforcement/ — LLM 作为判断者研究、PR 作为护栏
• 比较 — 见 comparisons/ — CE 与 RAG 与代理与企业搜索

关于

由 OutcomeOps (https://www.outcomeops.ai) 的 Brian Carpio 构建。欢迎通过 issue 和 PR 提出问题、更正或贡献。

许可

MIT — 见 LICENSE。