Redis团队实战：生产级AI智能体的上下文工程

在构建生产级AI智能体时，上下文工程（Context Engineering）往往比模型选择更关键。Redis应用AI工程团队负责人Tyler Hutcherson与AI工程师Andrew Perukin在近期分享中，基于其SRE智能体等实战经验，深入探讨了如何设计、管理和优化智能体的上下文窗口。

什么是智能体的上下文？

Andrew将上下文类比为人类的“工作记忆”：当你同时处理多项任务时，工作记忆提供当前任务所需的所有信息。对于LLM而言，上下文就是每次API调用时随输入一起发送的数据——包括系统提示、工具描述、动态日志、指标数据以及集群状态快照等。

关键在于，上下文并非静态信息，而是不断变化的动态数据流。一个SRE智能体在排查Redis集群问题时，需要同时关注日志、指标、用户行为以及集群的实时状态。但设计系统时，开发者往往无法预知哪些信息真正相关，这就引出了核心矛盾：如何从海量数据中筛选出对当前任务最有价值的片段？

为什么“塞满上下文”会失败？

面对上下文窗口，一个常见的误区是把所有可能相关的数据都塞进去。Tyler和Andrew明确反对这种做法，原因有二。

注意力稀释与“大海捞针”。如果上下文中包含一个关键错误日志，但同时混入了上千条无关日志，注意力机制很难精准定位到那根“针”。更糟的是，模型可能被无关信息误导，去解决一个错误的问题。Andrew强调，我们希望模型回答的是“给定这个错误和当前集群状态，最可能的解决方案是什么”，而不是在噪声中挣扎。

成本失控。每次请求都填满上下文窗口意味着Token消耗急剧上升。Tyler坦言，如果不加控制，团队预算可能迅速耗尽，甚至出现“花在Token上的钱比工资还多”的窘境。现实世界的成本约束会直接倒逼上下文工程优化。

注意力机制与上下文窗口的技术背景：现代LLM依赖Transformer架构中的自注意力（self-attention）机制，模型在处理每个token时，会计算其与上下文中所有其他token的相关性权重。当上下文窗口被无关信息填满时，注意力权重会被分散到大量低相关性的token上，导致关键信息的信号被稀释——这就是“注意力稀释”的技术根源。此外，主流模型的上下文窗口虽然已扩展到数十万token级别，但有效利用长度（即模型能稳定关注到的信息范围）往往远小于标称上限，存在“中间遗忘”现象：位于长上下文中间位置的信息比开头和结尾的信息更容易被忽略。这解释了为何简单堆砌数据不仅浪费成本，还会降低推理质量。

工具抽象与安全边界

在SRE智能体的设计中，团队没有给LLM直接访问数据库的权限。相反，他们构建了一层抽象：智能体只能通过预定义的工具与系统交互。这带来两个好处：一是可以强制执行安全检查，二是能记录详细的审计日志。

Tyler指出，模型提供商正在将工具使用能力内化到训练中。如果你给模型一个包含大量工具列表的提示，每个工具只有简短描述，模型很容易产生大量错误的工具调用，这些错误调用又会累积到上下文中，进一步污染后续决策。因此，渐进式暴露工具（progressive disclosure）成为更优解：根据任务阶段动态提供相关工具，而非一次性展示全部。

工具调用（Tool Use/Function Calling）与渐进式暴露：工具调用是指LLM在生成回复时，输出结构化的函数调用请求（如JSON格式的工具名与参数），由外部运行时执行后将结果返回给模型，形成“推理-行动”循环。模型提供商通过在训练中注入工具使用数据，使模型具备了一定的调用能力，但工具列表过长时，模型需要在众多选项中做选择，容易产生幻觉式调用（如调用不存在的工具或参数错误）。渐进式暴露（progressive disclosure）借鉴了人机交互中的渐进披露原则：先提供高层级、少而精的工具集，待任务进入特定阶段再动态加载相关工具。这能显著降低单次决策的候选空间，减少错误调用及其对上下文的污染，同时便于按阶段实施差异化的权限与审计策略。

评估与可观测性：如何知道它有效？

当团队尝试优化上下文策略时，一个根本问题浮现：如何判断改动是否有效？Andrew和Tyler都强调评估（Evals）的必要性。Tyler形容评估“无聊但必不可少”，就像写单元测试——没人喜欢，但缺乏它就无法安全迭代。

除了评估，可追溯性（traceability）同样关键。智能体在运行过程中看到了什么、调用了哪些工具、基于哪些信息做出决策，这些都需要被记录和追踪。Andrew提到，审计事件和血缘追踪（lineage）能帮助团队理解“为什么智能体会做出这个选择”，尤其在多轮会话和动态事件冲突时，溯源能力直接影响调试效率。

评估（Evals）与可追溯性（Traceability）的工程实践：评估（Evals）是指针对智能体行为建立可重复的测试集与评分标准，通常包括离线评估（用标注数据或模拟环境批量运行）和在线评估（用真实流量做A/B或影子测试）。对上下文工程而言，评估需要覆盖“检索到的上下文是否相关”“工具调用是否正确”“最终答案是否准确”等多层指标。可追溯性则依赖结构化日志与分布式追踪：记录每次LLM调用的完整输入（系统提示、工具列表、检索片段）、输出、工具调用链及耗时，形成可回放的执行轨迹。血缘追踪（lineage）进一步记录每条上下文数据的来源与流转路径，使得当智能体做出错误决策时，能快速定位是数据源问题、检索策略问题还是提示设计问题，从而支撑安全迭代。

智能体技能的自动优化：现实与边界

分享最后，Tyler抛出一个前沿话题：能否让智能体从历史会话中自动学习，优化自身的技能（skills）？他的判断是：技能本身是真实且有用的，但“自动优化闭环”目前仍处于早期。

一个可行的流程是：记录智能体的完整执行轨迹，基于这些日志生成技能改进建议，但最终由人类审核并应用。Tyler明确表示，他不会让LLM完全自主地构建和使用技能而不经审查。至于何时能实现全自动闭环，目前尚无定论。

结语

Redis团队的实践揭示了一个核心趋势：生产级智能体的竞争力，正从模型能力转向上下文工程能力。如何精准检索、高效表示、安全暴露、持续评估和追溯上下文，将决定智能体在真实业务场景中的成败。对于正在构建AI Agent的团队而言，这些来自一线的经验比任何理论框架都更具参考价值。