Context engineering: 构建卓越 Agent 的关键 ✍ Neil Rahilly🕐 2026-05-06📦 7.1 KB 🟢 已读 𝕏 文章列表 文章探讨了“Context engineering(上下文工程)”作为构建优秀 AI Agent 的核心挑战与解决方案。相比于传统的 IVR 和预设流程,Context engineering 通过“渐进式披露”和条件逻辑,确保 Agent 在对话的每一个时刻都能获得最相关且最少量的信息。这不仅解决了模型处理大量 Token 时的性能下降和幻觉问题,还能让 Agent 充分利用大模型的推理能力,适应复杂的现实场景,并随着模型升级而自然进化。 AgentContext EngineeringLLMSierraAI架构Prompt设计渐进式披露自然语言处理RAG系统设计 # 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*
如 如何构建自动纠错 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方法论
2 2026年如何成为AI工程师(无需CS学位) 文章指出2026年AI工程师角色已分化为机器学习工程师和应用AI工程师。对于非CS学位求职者,后者是主要机会。文章详细列出了必备技能(Python、LLM行为、RAG系统、评估观测),并提出了三个能替代学历证明的实战项目建议。 技术 › LLM ✍ Harman🕐 2026-07-24 AI工程师职业发展RAGLLMAgentPrompt无学位
A Agent Wikis 的现状与发展 文章探讨了 LLM Wiki 模式的兴起,即通过在摄取时编译知识而非查询时检索,解决传统 RAG 无法积累知识的问题。介绍了 Cognition、FactoryAI、LangChain 等团队构建的 Agent Wiki 系统,分析了其架构原理及在维护成本上的优势。 技术 › Agent ✍ mem0🕐 2026-07-22 LLMAgentWikiRAGCognitionLangChainDeepWikiAutoWiki
写 写作即编排——当方法论指向自己 本文是“AI时代的知识编排”系列收官之作。作者回顾了利用AI与结构化知识库高效产出技术博客的实践,发现写作过程本身遵循着“文档驱动”(SDD)的逻辑。文章通过信息论、认知科学及实证数据论证了结构化输入的重要性,并指出知识编排已成为AI时代内容生产的生存必需,强调了核查与人工判断不可替代。 技术 › AI ✍ SagaSu🕐 2026-07-16 AI知识编排写作方法论SDDRAG结构化输入信息核查AgentLLM
L Let's build Claude Code's harness (step-by-step) 本文深入解析了Claude Code的“harness”架构,解释了为何简单的模型调用不足以构建可靠的代码代理。作者通过CrewAI框架逐步重建了包括核心循环、工具管理、规划机制在内的关键组件,揭示了通过工程化手段弥补模型差距的方法。 技术 › Claude Code ✍ Akshay🕐 2026-07-16 Claude CodeAgentCrewAIHarness Engineering代码代理工具调用LLM工程实践架构设计Context Engineering
C Context Engineering for Outbound 文章探讨了上下文工程在外拓代理中的应用,强调通过精心设计上下文窗口(包含角色、案例、证据和规则四层),解决模型幻觉和生成内容泛化的问题。文章介绍了组装、撰写和优化三个核心技能,以提升个性化消息的质量和响应率。 技术 › Agent ✍ Nicolas Finet🕐 2026-07-14 Context EngineeringOutboundAgentLLMPrompt Engineering
如 如何在 2026 年成为AI工程师 文章指出 2026 年 AI 工程师的门槛已变,不再看重学历,而是看重作品集与交付能力。作者拆解了 AI 工程师的三个核心能力:软件工程、LLM 使用及产品思维,并规划了一份为期 12 个月的六阶段实战路线图,涵盖 Python 基础、LLM API、RAG、Agent 系统开发、评估部署及求职准备。 技术 › LLM ✍ 路飞 AI 研究员🕐 2026-07-08 AI工程师职业发展学习路线RAGAgentLLMPythonPrompt实战指南求职
阿 阿里开源 Zvec:像 SQLite 一样极简的嵌入式向量数据库 阿里开源了一款名为 Zvec 的向量数据库项目,主打“纯本地、内嵌式”极简体验,号称向量界的 SQLite。该项目基于 C++ 编写,支持零配置安装,性能强悍(毫秒级搜索数十亿向量),同时兼容稠密、稀疏向量及全文检索。它非常适合本地大模型、RAG 和个人知识库开发,彻底免去了部署繁琐的后端向量服务。 技术 › 后端 ✍ 智享🕐 2026-07-08 向量数据库阿里ZvecRAG本地大模型开源LLMAgent数据库工具