Context engineering: 构建卓越 Agent 的关键 Neil Rahilly 2026-05-06 7.1 KB 34.9K 320 ☆ 收藏 𝕏 文章列表 文章探讨了“Context engineering（上下文工程）”作为构建优秀 AI Agent 的核心挑战与解决方案。相比于传统的 IVR 和预设流程，Context engineering 通过“渐进式披露”和条件逻辑，确保 Agent 在对话的每一个时刻都能获得最相关且最少量的信息。这不仅解决了模型处理大量 Token 时的性能下降和幻觉问题，还能让 Agent 充分利用大模型的推理能力，适应复杂的现实场景，并随着模型升级而自然进化。 AgentContext EngineeringLLMSierraAI架构Prompt设计渐进式披露自然语言处理RAG系统设计 79 值得读 ▶ 文章敏锐捕捉了Agent架构从固定流程向“上下文工程”演变的趋势，深刻论述了渐进式披露的作用，时效性极强且极具阅读价值，虽略带Sierra产品宣传色彩，但整体专业洞察力极高。 # Context engineering: the key to great agents **作者**: Neil Rahilly **日期**: 2026-05-05T17:59:22.000Z **来源**: [https://x.com/neilrahilly/status/2051723442928664620](https://x.com/neilrahilly/status/2051723442928664620) ---  In media, it’s often said that content is king. For agents, it's context. The large language models (LLMs) powering today’s agents are remarkably capable — not just at answering questions, but doing things. They can handle everything from returning an order to originating a mortgage or preventing subscriber churn. But like people, they can’t act on information they don't have. And when overloaded, they lose sight of what’s important. Getting these models the right context, at the right time, is the central challenge in building sophisticated, real-world agents. The solution: Context engineering — deciding what information an agent has access to at each moment, and when it should be used. ## Three eras of customer interaction To understand why, it helps to look at how customer interactions have evolved. Era 1: Interactive voice response (IVR). IVRs cannot think or reason. There’s only the menu. Press 1 for billing. Press 2 for returns. Press 0 to talk to a person. And if a customer’s issue doesn’t match precisely, they’re stuck. Era 2: Flow. Many AI agents today still follow a predefined path — a flowchart, decision tree, or digitized standard operating procedures (SOPs). Customers can speak naturally, but the system still operates on “if this, then that.” When a problem falls outside the flow, it gets escalated. And as more SOPs are added, the system becomes harder to manage, increasing the risk of errors. Era 3: Context engineering. The most sophisticated agents today are not driven by these more rigid flows. They’re guided by goals and constrained by guardrails. The models on which they are built drive the conversation, and the agent’s behavior adapts in the moment based on what it learns. Sierra’s role is to deliver the right context, at the right time — so they reason effectively and act correctly.  ## Progressive disclosure As the number of tokens (pieces of text) in a model's context window grows, its ability to recall and act on that information accurately declines. Every irrelevant token competes for the model's attention with the tokens that actually matter. Context engineering solves this problem through progressive disclosure: providing only the minimum, most relevant information at each moment in the conversation. For example, if a customer calls about an international shipment to Europe, the agent doesn't need custom rules for every country upfront. That information becomes relevant only after it learns the destination. If the shipment is going to Germany, the agent needs Germany-specific guidance. Until then, that information is noise. ## Conditions: the connective tissue Conditions are what make progressive disclosure work. They answer the question: under what circumstances does this piece of information become relevant? Conditions can be based on state (a tool returns specific data, the customer is authenticated, a subscription is loaded) or on observation (the customer mentioned a topic, expressed a desire to cancel, asked about a specific product). Once a condition is met, the information is given to the agent. This layering ensures the conversation starts minimal — basic tools, general policies, brand voice — but can still handle long, complex customer interactions. As the conversation progresses and the agent learns more, additional information is provided. Once the customer is authenticated, account-specific tools and policies become available. Questions about a charge reveal the dispute workflow, policies, and tools needed to investigate the transaction. Each step unlocks exactly what's needed for the next. ## Types of context Sierra’s platform structures context into manageable components. These include:  A note on workflows: while we just discussed why rigid flows are limiting, some situations (like a highly regulated intake process) genuinely require them. The difference is that a workflow becomes just another piece of context made available when conditions are met, rather than the organizing paradigm for the entire system. ## Sierra handles the context engineering for you The question, then, is how you actually build a system like this. Sierra represents an agent as a set of composable context blocks, each with an associated condition. We built an integrated stack to make this architecture usable — without sacrificing control: - Ghostwriter: An agent that does the context engineering for you. You can give it natural language instructions or have it ingest your existing SOPs, call transcripts and documentation to produce context blocks and conditions automatically. - Journeys: Our no-code editor lets you inspect and refine what Ghostwriter produced, or build directly in the UI. - Agent SDK: Offers full programmatic control for teams that want to manage agents as code. Developers can define custom blocks or write arbitrary code. No matter how you build it, it works the same way under the hood. ## Why this matters With one task and a couple of tools, any modern agent will perform naturally and reliably. But at production scale — with dozens of supported use cases, multiple systems, and segment-specific policies — the realities of performance and complexity set in. An agent that handles five journeys can get by with loose context management. One that handles fifty needs every piece of context to arrive at exactly the right moment. Without that discipline, the model gets overwhelmed, and the experience degrades. Context engineering solves this at an architectural level. By sending fewer highly relevant tokens to the model, you reduce hallucination, improve naturalness, and increase performance. And you aren’t paying to process a thousand tokens of baggage policy during a simple flight rebooking. More importantly, it future-proofs the agent. When you hardcode logic, you constrain the model — it can only be as capable as the paths you've predefined. With context engineering, the agent can reason more freely. As new, more capable models are released, your agent inherits that improvement. A smarter model doesn't replace the need for context engineering. Even the smartest people can't know what they don't know. But it does amplify the payoff for doing it right. Context engineering is the work of building great agents. ## 相关链接 - [Neil Rahilly](https://x.com/neilrahilly) - [@neilrahilly](https://x.com/neilrahilly) - [8.6K](https://x.com/neilrahilly/status/2051723442928664620/analytics) - [Upgrade to Premium](https://x.com/i/premium_sign_up) - [1:59 AM · May 6, 2026](https://x.com/neilrahilly/status/2051723442928664620) - [8,616 Views](https://x.com/neilrahilly/status/2051723442928664620/analytics) - [View quotes](https://x.com/neilrahilly/status/2051723442928664620/quotes) --- *导出时间: 2026/5/6 20:49:52* --- ## 中文翻译 # 上下文工程：打造卓越智能体的关键 **作者**: Neil Rahilly **日期**: 2026-05-05T17:59:22.000Z **来源**: [https://x.com/neilrahilly/status/2051723442928664620](https://x.com/neilrahilly/status/2051723442928664620) ---  在媒体行业，人们常说内容为王。而对于智能体而言，则是上下文为王。 驱动当今智能体的大语言模型（LLM）能力非凡——它们不仅能回答问题，还能执行任务。从处理退货订单、发起贷款申请到预防用户流失，它们几乎无所不能。 但与人一样，如果缺乏信息，它们就无法行动。而当信息过载时，它们又会迷失重点。如何在正确的时间为这些模型提供正确的上下文，是构建复杂且实用的智能体所面临的核心挑战。 解决方案就是：上下文工程——即决定智能体在每一刻可以访问哪些信息，以及何时使用这些信息。 ## 客户交互的三个时代 要理解其中的原因，我们需要回顾一下客户交互方式的演变历程。 时代 1：交互式语音应答（IVR）。IVR 无法思考或推理。只有菜单。按 1 选择账单，按 2 选择退货，按 0 转人工。如果客户的问题不完全匹配，他们就会陷入困境。 时代 2：流程。今天的许多 AI 智能体仍然遵循预定义的路径——流程图、决策树或数字化的标准操作程序（SOP）。客户虽然可以自然对话，但系统依然基于“如果这样，就那样”的逻辑运行。一旦问题超出预设流程，就会转交人工处理。而且，随着 SOP 的不断增加，系统变得越来越难以管理，出错的风险也随之增加。 时代 3：上下文工程。当今最先进的智能体不再受限于这些僵化的流程。它们由目标引导，并受限于护栏。构建它们的模型主导着对话的走向，智能体的行为会根据其在对话中的所学进行实时调整。Sierra 的作用就是在正确的时间提供正确的上下文——从而确保它们能够有效推理并正确行动。  ## 渐进式披露 随着模型上下文窗口中令牌（文本片段）数量的增加，其准确回忆并运用这些信息的能力反而会下降。每一个不相关的令牌都会与真正重要的令牌争夺模型的注意力。 上下文工程通过渐进式披露来解决这一问题：即在对话的每一刻，仅提供最少、最相关的信息。 例如，如果客户致电咨询发往欧洲的国际订单，智能体起初并不需要知道每个国家的具体规则。只有当确定了目的地后，这些信息才变得相关。如果货物发往德国，智能体才需要针对德国的指导原则。在此之前，那些信息只是噪音。 ## 条件：连接纽带 条件是让渐进式披露得以运作的关键。它们回答了这样一个问题：在什么情况下，这条信息才会变得相关？ 条件可以基于状态（某个工具返回了特定数据、客户通过了身份验证、加载了订阅信息）或基于观察（客户提到了某个话题、表达了取消意愿、询问了特定产品）。一旦满足条件，相关信息就会提供给智能体。 这种分层机制确保了对话可以从最精简的状态开始——只包含基础工具、通用政策和品牌语调——但依然能够处理漫长而复杂的客户交互。随着对话的深入和智能体了解的增多，额外的信息会被逐步提供。一旦客户身份得到验证，针对账户的工具和政策就会启用。关于某笔费用的提问会激活处理争议所需的工作流、政策和调查工具。每一步都会精准解锁下一步所需的资源。 ## 上下文的类型 Sierra 的平台将上下文结构化为易于管理的组件。这些组件包括：  关于工作流的说明：尽管我们刚才讨论了僵化流程的局限性，但在某些情况下（如高度监管的受理流程），确实需要它们。不同之处在于，在 Sierra 中，工作流只是满足条件时提供的另一种上下文片段，而不是整个系统的组织范式。 ## Sierra 为您代劳上下文工程 那么，问题就变成了如何实际构建这样一个系统。Sierra 将一个智能体表现为一组可组合的上下文块，每个块都关联着特定条件。我们构建了一个集成的技术栈来实现这一架构——且没有牺牲控制力： - Ghostwriter：一个为您代劳上下文工程的智能体。您可以向它下达自然语言指令，或让它摄入您现有的 SOP、通话记录和文档，从而自动生成上下文块和条件。 - Journeys：我们的无代码编辑器让您可以检查和优化 Ghostwriter 的产出，或者直接在 UI 中进行构建。 - Agent SDK：为希望将智能体作为代码进行管理的团队提供完全的编程控制能力。开发者可以定义自定义块或编写任意代码。 无论您采用哪种方式构建，底层的运行逻辑都是一样的。 ## 为什么这很重要 如果只有一项任务和几个工具，任何现代智能体都能表现出色且可靠。但在生产规模上——涉及几十个用例、多个系统以及针对特定细分市场的策略——性能和复杂性的现实问题就会显现。 处理 5 种交互路径的智能体或许可以通过宽松的上下文管理应付过去。但处理 50 种路径的智能体，则需要每一条上下文信息都在精准的时刻出现。缺乏这种纪律性，模型就会不堪重负，体验也会随之下降。 上下文工程从架构层面解决了这个问题。通过向模型发送更少但高度相关的令牌，你可以减少幻觉，提升自然度，并提高性能。而且，在简单的航班改签过程中，你无需为了处理那一千个关于行李政策的令牌而付费。 更重要的是，这赋予了智能体面向未来的能力。当你将逻辑硬编码时，你就限制了模型——它的能力上限只能达到你预先定义的路径。而通过上下文工程，智能体可以更自由地进行推理。随着新一代、更强大的模型发布，你的智能体也能自动继承这些进步。 更聪明的模型并不能替代上下文工程的需求。即使是最聪明的人，也无法知晓他们不知道的事情。但这确实会放大做好这件事的回报。 上下文工程，正是打造卓越智能体的关键所在。 ## 相关链接 - [Neil Rahilly](https://x.com/neilrahilly) - [@neilrahilly](https://x.com/neilrahilly) - [8.6K](https://x.com/neilrahilly/status/2051723442928664620/analytics) - [升级到 Premium](https://x.com/i/premium_sign_up) - [2026年5月6日 上午1:59](https://x.com/neilrahilly/status/2051723442928664620) - [8,616 次观看](https://x.com/neilrahilly/status/2051723442928664620/analytics) - [查看引用](https://x.com/neilrahilly/status/2051723442928664620/quotes) --- *导出时间: 2026/5/6 20:49:52*
M Memory Is a Compiler：记忆是一个编译器 作者通过一次融资会议记忆被重新解读的经历，指出记忆的本质不是固定表示，而是一个持久系统：保留过去的证据，并随新证据不断重新编译其意义。文章批评将向量数据库、知识图谱、上下文窗口等当作记忆的常见误解，认为它们只是从记忆编译出的临时表示。作者提出记忆编译产生三类产物：状态（按序折叠事件得到）、检索（查找相关证据的工具）和上下文（为单次调用组装的有界视图），并类比编译器的中间表示（IR），指出每种表示只适合特定操作，记忆本身应是唯一不可丢弃的持久层。 技术 › LLM Ashwin Gopinath 2026-09-01 AI记忆RAG向量数据库知识图谱上下文窗口AgentLLM系统设计
2 2026年你必须掌握的25个AI核心概念 文章详细列出了2026年理解和构建现代AI系统所必需的25个核心概念。内容涵盖从基础原理（如Tokens、Embeddings）到高级应用（如Agents、RAG），旨在帮助开发者掌握关键技术，忽略无用的营销术语，构建更可靠的AI系统。 技术 › LLM Kanika 2026-08-17 AILLMAgentRAGEmbeddings基础概念系统设计技术教程
H Harness Engineering：构建决定AI Agent可靠性的七层架构 文章指出，AI Agent的可靠性不取决于模型权重，而取决于周围的脚手架（Harness）。Harness分为七层：执行环境、工具接口、上下文管理、编排与生命周期、可观测性、验证和权限边界。这七层都是需要编写和版本控制的代码，而非模型属性。此外，Harness还分为由模型构建者提供的内部Harness和开发者自行组装的外部Harness。 技术 › Agent zostaff 2026-08-09 Harness EngineeringAgentAI架构LLM系统设计脚手架上下文管理可观测性
如 如何构建自动纠错 AI 循环 文章介绍如何构建一个 AI 自我纠错系统，通过分离生成、判断和管理三个角色，避免人工介入验证。关键在于利用独立的标准（如测试套件）进行结构化验证，而非简单的重复提问，从而实现自动化错误捕捉与修复。 技术 › Agent CyrilXBT 2026-07-17 AI架构自我纠错Agent提示词工程自动化系统设计LLM流程优化
A Agent 的数据面概念扫盲-建立技术侧认知体系 本文深入解析了 Agent 数据面的核心概念，将其比作操作系统的内存管理单元。文章详细阐述了 Context Engineering 的演变、Session/Thread/Profile 的架构差异，以及 Session Memory 与 Long-term Memory 的区别。作者还重点介绍了 Hermes 中的 Memory 设计方案、SQLite FTS5 与 BM25 算法原理，以及向量检索与关键词检索在 RAG 中的混合应用，旨在为开发者建立一套完整的 Agent 数据面技术认知体系。 技术 › Agent MateMatt 2026-07-12 AgentContext EngineeringRAGMemoryBM25SQLite FTS5向量检索HermesLong-term MemoryLLM
从 从零构建 LLM 架构：10 个实用经验教训 本文指出构建 AI 产品的核心不在于选择模型，而在于架构设计。作者分享了 10 个实用经验，强调从工作流而非模型入手、重视检索优于微调、将提示工程视为系统工程、关注延迟优化、为智能体设置护栏、妥善处理记忆、建立评估管道以及优化成本。最终，多智能体系统将是未来趋势。 技术 › LLM Tabassum Parveen 2026-05-20 LLM架构设计RAGAgent工程化最佳实践系统设计Prompt工程成本优化Multi-Agent
A Agentic Memory: 详解 Agent 记忆系统的架构与实现 文章通过生动的类比，指出缺乏记忆是当前 LLM Agent 的主要短板。作者详细拆解了 Agent 记忆系统的三个核心功能：连续性、上下文和学习。文章重点介绍了四种记忆类型：上下文记忆、外部记忆、情景记忆和参数记忆，并深入探讨了如何通过检索增强（RAG）和反思循环来构建持久的智能。 技术 › Agent Ramakrishna (techwith_ram) 2026-05-17 AgentLLMMemoryArchitectureRAGVectorStoreContextEpisodic向量数据库系统设计
模 模型是引擎，系统是车身：AI 架构工程随笔 文章反驳了 Kyle Kingsbury 关于 LLM 不可靠的结论。作者认为，裸模型仅是“引擎”，其不可预测性需通过“车身”工程（如 Harness、Resolver、确定性工具）来解决。不应测试模型本身，而应测试由模型、路由和工具组成的完整系统。 技术 › Hermes nash_su 2026-04-20 AI架构LLMAgentHarness工程化系统设计OpenClaw方法论
A Agent 高频题 01. 讲讲你的 RAG 链路 本文是 Agent 高频面试题详解系列第一篇，聚焦 RAG（检索增强生成）链路。文章基于近两个月牛客网 82 场面试的统计，指出 RAG 是最常被追问的题目。内容先给出 RAG 整体架构图，解释为什么需要 RAG 及其与长上下文、grep、微调、工具调用、记忆等方案的边界；再沿离线、在线两条线逐环讲解：离线部分涵盖文档解析、切分策略、embedding 向量化、HNSW/IVF 索引原理；在线部分讲解问题改写、BM25 与向量多路召回、RRF 融合、交叉编码器重排等环节。每个环节均附上面试常见追问，并提供复习优先级参考。 技术 › Agent 码良 2026-10-20 RAG面试检索增强生成向量检索embeddingBM25HNSW重排LLMAgent
深 深度体验 EverOS Cloud：让 Agent 记忆与经验沉淀为技能的测评 文章针对 AI Agent 开发中记忆缺失、RAG 低信噪比切片、状态冲突与多主体污染三大痛点，测评了 EverOS Cloud（API v2）这一 Agent 记忆操作系统。核心机制包括语义事件切割、记忆整合消解冲突、多主体严格隔离，在 LoCoMo 基准上达 93.05% SOTA，减少 90% 以上 Token 消耗。其自进化技能引擎可将任务执行链路沉淀为 Case 并蒸馏为可复用 Skill，任务成功率最高提升 234.8%。接入仅需两行核心调用，支持记忆治理 API、多模态资料挂载、MCP 协议兼容 Claude Code 等工具，以及云/本地双模部署。作者认为其适合需要跨会话跟踪意图与沉淀业务 SOP 的场景。 技术 › Agent 浅水虾 2026-10-20 Agent记忆系统EverOSRAGLLM测评MCPSkillToken优化
T The 2026 LLM Engineering Roadmap 本文提出了2026年LLM工程路线图，指出与LLM工作不只是提示词，生产级系统需要对LLM的工程化、部署和优化有深入理解。文章总结八大支柱：提示工程（将prompt当作代码管理）、RAG系统（嵌入、检索、重排）、上下文工程（管理上下文窗口中各类信息的取舍）、微调（LoRA/QLoRA等技术）、Agent（工具调用循环与编排、状态管理、重试逻辑），并为每个领域提供了大量免费开源学习资源，如Anthropic、OpenAI官方指南及多个GitHub教程仓库。 技术 › LLM Avi Chawla 2026-10-09 LLM提示工程RAG上下文工程微调Agent开源资源学习路线图
斯 斯坦福 CS224V「Agentic AI」课程：把会幻觉的 LLM 改造成可信赖的智能体 文章介绍斯坦福 Monica Lam 教授团队主讲的 CS224V「Agentic AI」研究型课程。课程围绕一个核心问题：如何将本质上不可靠、会幻觉的 LLM 变成可信赖、可追责的智能体。技术主线是一条自底向上的“反幻觉”知识栈，涵盖 LLM 基础、知识策展（STORM）、RAG（WikiChat）、结构化数据查询（SUQL、SPINACH）、形式化方法与可追责 AI（SMT、SatIR、VERDICT）、任务型对话 Agent 及元 Agent 优化。课程以研究项目为核心（占 65%），依托开源平台 AOS，选题集中于医疗遗传学等领域。其哲学是系统工程+形式化约束，与业界依赖规模的路线形成鲜明对比，适合有 NLP 基础、想做真实 Agent 研究的人。 技术 › Agent meng shao 2026-10-01 AgentLLM斯坦福CS224VMonica LamRAG知识策展形式化方法可追责AI神经符号医疗AI
