别再给智能体当保姆了：一场关于“上下文引擎”的反直觉演讲

如果你还在手动喂 prompt、调参数、盯着智能体别跑偏，Brandon Walsenuk 会告诉你：问题不在模型，而在“上下文”。这场演讲抛出了一个刺痛从业者的观点——真正的瓶颈，是你还没有一个像样的 context engine。

最残酷的真相：我们正在给 AI 当“人肉上下文引擎”

Brandon 一上来就点破一个很多团队不愿承认的事实：不久之前，真正的“上下文引擎”不是系统，而是人。你负责找文档、翻代码、筛选哪些信息有用、哪些该丢掉，再一股脑塞进 prompt。模型只是执行者，而你是那个默默做信息蒸馏的人。

问题是，这种模式在 demo 阶段还能凑合，一旦进到真实组织，复杂度会指数级爆炸。文件散落在各个系统里，看起来像个文件系统，但实际上毫无“理解能力”。你越是 babysit agent，它就越像一个离不开你的实习生。

静态内容 + 全量塞给模型，是最偷懒也最昂贵的解法

当前很多团队的做法，本质上是把“所有可能相关的静态内容”一股脑喂给模型，希望它自己搞定。这听起来很 AI，但实际效果往往是：慢、贵、还不稳定。

Brandon 指出，这类系统通常只是披着智能外衣的文件系统。它们不理解任务，也不理解时序，只是存储和检索。你花了更多 token，却没有换来更快的决策，反而让 agent 在噪音里迷路。

真正有效的系统，目标不是“给模型更多”，而是“在对的时间给对的内容”，让它更快把事做完。

Andrej Karpathy 提醒过的坑：一次错误上下文，足以毁掉整个系统

演讲中提到的一个关键警示，来自 Andrej Karpathy 提出的经典问题：如果上下文构建出错，会发生什么？答案很直接——足以让你整个系统翻车。

Brandon 坦言，如果他们当时把某些方案直接上线，错误的上下文组合会直接“broken our entire system”。这不是模型能力问题，而是架构问题。

这也引出了他总结的“构建上下文的三个迷思”：不是上下文越多越好；不是一次构建就能反复复用；更不是靠堆 token 就能解决。这些迷思，都会在规模化时反噬你。

为什么你需要一个真正的 Context Engine，而不是更聪明的 Agent

Brandon 给出的核心答案是：把“理解任务、筛选信息、组合上下文”这件事，从人和 agent 身上剥离出来，交给一个专门的 context engine。

这个引擎的职责只有一个：围绕当前任务，动态构建最小但足够的上下文，只把真正有用的内容送进模型，再只把必要的结果送回来。这样，agent 才能停止被 babysit，开始规模化工作。

在 AI forward 的团队里，这种架构变化带来的不是 10% 的优化，而是数量级的杠杆。这也是为什么他把整场演讲的落点，放在一个可运行的 demo 上，而不是更多概念。

总结

这场演讲真正想传达的，不是某个工具，而是一种分工观念的转变：模型负责推理，agent 负责行动，而上下文，本身是一等公民，需要独立的系统来管理。对从业者来说，最直接的行动建议是：回头看看你现在的 agent，有多少“聪明”其实是人肉补丁？如果把上下文构建自动化、结构化，你的系统是否能立刻上一个台阶？下一个竞争优势，很可能不在更大的模型，而在你是否停止当那个最累的保姆。

关键词： Context Engine， AI Agent， 上下文管理， Andrej Karpathy， 智能体架构

事实核查备注： 需要核查：1）演讲者姓名 Brandon Walsenuk 的拼写；2）其所在公司 Unblocked 的准确名称；3）Andrej Karpathy 被引用的具体问题表述；4）视频发布时间 2026-05-26 是否准确。