为什么 Context Engineering 将取代传统架构思维
Source: Dev.to
请提供您希望翻译的具体文本内容，我才能为您进行简体中文翻译。
邀请
现在，我已经正式在 X（Twitter）上活跃。对于新的 DevOps 想法，你也可以在 X（Twitter）上与我一起交流。点击这里
文章摘要
在软件工程的大部分历史中，架构关注的是结构。
工程师们设计了：
- 服务边界
- API
- 数据模型
- 基础设施层
- 通信协议
架构回答了一个核心问题：
组件应如何交互以产生期望的系统行为？
在 AI 时代，这一问题正在演变。当系统依赖智能模型时，行为不再仅由代码结构决定——它由上下文决定。这就是为什么一种新学科——上下文工程——正在兴起。
传统架构模型
在传统软件系统中，行为是确定性的。如果开发者定义了：
- 输入
- 逻辑
- 输出
系统的行为就是可预测的。因此，架构的重点在于高效地组织代码和服务。关键的设计关注点包括：
- 可伸缩性
- 模块化
- 可维护性
- 容错性
一旦架构确定，系统的行为就由其中编写的逻辑决定。
AI 引入依赖上下文的行为
AI 系统的运行方式不同。它们不是执行预定义的逻辑，而是解释信息并动态生成响应。它们的输出在很大程度上取决于：
- 提示或指令
- 检索到的数据
- 周围的上下文
- 所施加的约束
- 交互历史
两个相同的模型可以根据上下文的结构产生完全不同的结果。换句话说，上下文成为 AI 行为的架构。
什么是上下文工程
上下文工程是设计信息环境以塑造 AI 系统行为的实践。它涉及控制以下要素：
- 提示和指令
- 检索到的文档或知识来源
- 用户状态和对话历史
- 系统约束和策略
- 任务特定的数据和工具
工程师不再仅关注服务和 API，而是设计引导智能决策的信息输入。
为什么上下文往往比模型更重要
许多团队最初会认为提升 AI 性能需要更换模型。实际上，最大的性能提升往往来自更好的 context design。例如：
- 检索到正确的文档可以提升准确性
- 结构化提示可以减少 hallucinations
- 添加 constraints 可以提升可靠性
- 提供 examples 可以提升一致性
模型的智能固然重要，但 context 的质量决定了这些智能能够被多有效地应用。
架构转向信息流设计
传统的架构图展示系统通过 API 进行通信。在 AI 驱动的系统中，第二层同样重要：在模型生成输出之前信息如何流入模型。这包括：
- retrieval pipelines
- context filtering
- memory management
- prompt construction
- knowledge integration
设计这些管道成为核心的工程挑战。系统必须在恰当的时机向模型提供正确的信息。
开发者必须管理上下文大小和相关性
AI 系统在有限的上下文窗口内运行。开发者必须决定：
- 包含哪些信息
- 排除哪些信息
- 如何优先处理相关数据
- 如何对大型数据集进行摘要
上下文管理不当可能导致：
- 回答错误
- 信息不相关
- 成本增加
- 性能下降
因此，上下文工程需要对信息进行仔细的选择和压缩。
评估成为上下文工程的一部分
因为上下文塑造行为，工程师必须持续评估：
- 上下文是否提升了输出质量
- 某些提示是否引入偏见
- 检索到的数据是否仍然相关
- 系统在不同任务中的表现是否一致
这会形成一个反馈循环，使上下文随时间不断优化。不同于静态架构，上下文工程是一个 迭代过程。
上下文工程需要跨学科思维
传统架构在很大程度上依赖计算机科学原理。上下文工程则加入了额外的学科：
- 信息检索
- 知识表示
- 人机交互
- 行为设计
- 数据策展
工程师必须不仅考虑系统和代码，还要思考信息如何塑造机器推理。
新开发者角色
从事 AI 系统的开发者正日益承担以下角色：
- 上下文设计师
- 工作流架构师
- 评估工程师
- 系统行为分析师
他们不再仅仅编写确定性逻辑，而是通过精心构建的信息环境引导概率系统。其职责是确保 AI 系统拥有正确的上下文，从而可靠地运行。
传统架构仍然重要
上下文工程并 不 完全取代架构。基础设施设计、系统可扩展性和服务可靠性仍然是必不可少的。然而，在 AI 驱动的系统中，仅靠架构已不足以决定行为。系统架构 和 上下文设计的组合决定了最终结果。
真正的要点
AI 时代引入了一个新的工程责任层面。
- 传统架构 决定软件组件如何交互。
- 上下文工程 决定智能系统的行为方式。
开发者现在必须不仅设计系统的结构，还要设计引导机器推理的信息环境。随着 AI 融入各类应用，这项技能将成为基础。
因为在智能系统中，代码定义结构，而上下文定义行为。