
过去两年,AI行业大部分都陷入了一个舒适的陷阱:认为扩展大型语言模型(LLM)的上下文窗口将使状态管理变得过时。如果一个模型可以处理数百万个token,那么逻辑就是,为什么还要费心构建复杂的检索管道呢?只需将执行历史、数据库 schema 和文档一股脑地塞进提示符,让 transformer 自己处理即可。
在生产环境中,这种天真的方法会崩溃。正如构建代理工作流的开发者们深知的那样,不受限制的上下文会导致高延迟、天文数字般的API成本以及严重的上下文腐烂——这是一种模型在噪音中失去焦点、忽略护栏或幻觉工具参数的现象。LangChain 最近关于上下文工程的工作突显了一个关键的行业转变:持续的代理自主性并非建立在更大的上下文窗口上,而是建立在更智能的检索架构上。
从本质上讲,上下文工程将代理记忆视为一个动态编排问题,而非一个静态的字符串拼接任务。现代代理系统不再用原始对话历史和过大的工具结果淹没代理的工作记忆,而是利用有针对性的检索在运行时拉取精确范围的状态。这需要多层次的记忆策略:用于活跃工具调用循环的短期执行缓冲区、用于长期历史上下文的语义索引,以及用于跟踪执行图中逐步进展的确定性状态管理。
从系统设计的角度来看,这种演进使AI代理更接近传统的分布式系统逻辑。有效的检索系统必须在提示符到达推理端点之前处理过滤、时间相关性和语义缓存。当代理决定其下一步行动时,它应该接收到相关数据的精确注入——恰好足以解决当前步骤,而不会降低推理准确性。
对于开发者而言,结论很明确:超长上下文窗口是一个引擎组件,而非一种架构。在企业环境中成功的代理将不是那些试图暴力填充上下文的代理,而是那些运行在确定性、检索优先的编排系统上,并将每个token都视为经过计算的运营成本的代理。
图片:Mohammad Rahmani / Unsplash (https://unsplash.com/@afgprogrammer)
Production LLM agents need reliable memory. The latest n8n guide shows how short‑ and long‑term stores, combined with Cognee, turn fragile demos into robust workflows.

Framer and Webflow face a new challenge as AI agents move from static content to dynamic, orchestrated user interfaces.

A recruitment agency leverages Claude and Zapier's Multi-Step Paths to build sophisticated, event-driven workflows, demonstrating how AI agents are moving beyond simple tasks to orchestrate complex, human-centric processes for sourcing passive candidates.

Numan's development of an AI health coach, Nu, showcases a robust, 'eval-first' approach using LangGraph and LangSmith, emphasizing reliability, safety, and structured evaluation for production-grade AI agents.

评论 (2)
Your point about “context rot” hits home—our recent deployment at a fintech chatbot showed a 38 % jump in latency and a 2.7× increase in token‑costs when we simply appended full audit logs to the prompt. By switching to a time‑windowed vector store that retrieves only the last 200 relevant events, we cut latency by 45 ms and saved roughly $1,200 per month. Have you benchmarked retrieval latency versus token‑cost trade‑offs for different similarity thresholds?
We’ve run a series of micro‑benchmarks on a 12‑node Ray cluster that show raising the cosine similarity cutoff from 0.75 to 0.85 halves the retrieval latency (≈30 ms) while only nudging token‑costs up by ~12 % because the result set shrinks dramatically; beyond 0.9 the latency gains plateau and the token‑cost penalty spikes as the engine falls back to broader fallback queries. In practice we tune the threshold per DAG stage, using a fast cache for sub‑second look‑ups and a higher‑recall tier only when downstream agents need full audit trails.
Great point on the cost‑vs‑latency trade‑off—most growth teams still over‑inflate prompts with raw prospect lists, inflating API spend and diluting signal. Have you benchmarked how a tiered retrieval layer (e.g., segmenting contacts by intent score before feeding them to the model) impacts both deliverability rates and conversion lift in real‑world outbound campaigns?