与 Adi Polak 探讨上下文工程

📌 一句话摘要

本文探讨了从无状态的提示工程 (Prompt Engineering) 到有状态的上下文工程 (Context Engineering) 的转变，强调了智能体工作流、可复用技能以及用于扩展软件工程中 AI 应用的事件驱动架构。

📝 详细摘要

在这次技术讨论中，Adi Polak 概述了 AI 交互从简单的提示工程向复杂的上下文工程的演进。提示工程侧重于无状态指令，而上下文工程则赋能有状态的 AI 系统，使其能够管理短期会话记忆和长期领域知识。对话强调了“智能体体验”(Agent Experience， AgentEx) 的重要性，即开发者需要专门为 AI 智能体设计系统，以辅助其在软件开发生命周期 (SDLC) 中进行导航。讨论的关键架构模式包括：将成功的 AI 工作流保存为可复用的“技能”，并利用 Apache Kafka 和 Flink 等事件驱动基础设施，为智能体的“思维链”过程提供实时数据增强。

💡 主要观点

- 从无状态提示到有状态上下文工程的转变。 传统的提示工程通常是无状态且短暂的。上下文工程专注于管理状态，允许 AI 系统在会话之间保持连续性，并区分短期任务记忆和长期持久知识。

通过可复用的 AI “技能”扩展工程团队。 团队不应重复推导提示词，而应将成功的 AI 辅助工作流捕获为可复用的技能。这创建了一个可搜索的存储库，允许智能体仅在需要时加载特定的领域专业知识，从而优化准确性和 Token 成本。

从开发者体验 (DevEx) 到智能体体验 (AgentEx) 的转变。 随着 AI 智能体成为 CI/CD 和 SDLC 流程中不可或缺的一部分，架构师必须专门为智能体设计系统接口和数据访问模式，确保它们拥有正确的上下文和工具来自主运行。

作为智能体系统骨干的事件驱动架构。 OpenAI 等公司的高规模 AI 实现利用 Kafka 和 Flink 来处理实时事件流。这种基础设施通过提供低延迟的数据增强并触发对系统事件的智能体响应，从而支持“思维链”。

💬 文章金句

- 提示工程技术采用无状态方法，而上下文工程允许 AI 系统是有状态的。

• 当我们拥有领域专业知识时，提示工程确实非常出色……我们需要知道想要实现什么，并对实现步骤有一个大致的了解。
• 我们正在从开发者体验 (DevEx) 的世界走向智能体体验的世界。
• 我们需要明智地选择引入的上下文……如果我们用过大的上下文让它不堪重负，它反而会犯更多错误，成本也会更高。

📊 文章信息

AI 评分：91

来源：InfoQ

作者：Thomas Betts

分类：人工智能

语言：英文

阅读时间：24 分钟

字数：5917

标签： 上下文工程, 提示工程, 智能体工作流, LLM, 事件驱动架构

阅读完整文章