7.8
深览指数
科技人人都是产品经理·Timothy··AI 生成
上下文工程观止：为什么 Prompt 工程救不了你的 Agent？
本文提出一套产品经理可用的诊断框架，用于解决Agent在Prompt写清楚后仍不稳定的问题。核心观点是：问题常出在“上下文工程”而非“Prompt工程”。作者将上下文管理拆解为“检索、压缩、记忆、隔离”四格，并提供了预算表、门禁和上线清单等具体工具。适合正在从事Agent产品设计、面临稳定性挑战的从业者阅读，帮助团队跳出“出错就补Prompt”的循环。原文 ↗
核心观点
- ▍当Prompt写得足够清楚，Agent依然不稳定时，问题通常出在“上下文工程”上，而非Prompt本身。需要从信息供给、压缩、记忆和隔离四个维度进行诊断和管理。
- ▍上下文工程的核心是“克制”，即要用尽量少的高信号信息提高模型做出目标行为的概率，而不是把知道的信息都塞进窗口。
- 01作者以一个合同审核Agent在第18轮出错为例：Agent在错误地发送邮件，原因是工具列表中有相似动作、检索到过期流程、摘要漏掉了“对外发送前再次确认”的临时约束，而非指令被遗忘。
- 02作者引用了Anthropic的区分：Prompt是上下文的一部分；上下文还包括工具说明、外部数据、消息历史、记忆、示例和工具返回结果。
- 03作者指出，模型窗口大小不能解决“干扰项相似”问题。Chroma的Context Rot报告显示，随着输入增长，模型在受控任务上的表现会非均匀下降，干扰项越相似问题越明显。
- 04文章提出了“四格”框架：检索（解决供给）、压缩（解决长任务连续性）、记忆（解决跨会话复用）、隔离（解决边界）。每个格子都对应了具体的产品错误。
- 05文章给出了一个代理出错时的排查顺序：先还原模型当时看到的完整输入，根据异常信号对症下药，最后做单变量回归。
- 06作者建议产品经理拍板五件事：上下文预算的owner、供给触发条件、压缩/重启时机、长期记忆写入门槛、边界如何被系统执行。
反方 / 局限
- — 作者承认，对于单轮、低风险、信息稳定的任务，清楚的Prompt加少量必要材料通常已经足够，不需要复杂的上下文工程。上下文工程的投入应与任务长度、信息冲突概率和错误代价相匹配。
- — 作者暗示，四格模型并非行业标准，而是他提出的一个产品分析框架，其价值在于让团队分工，而非争论术语。
- — 文章指出，简单的“从长文本里找到一个明确句子”和Agent在多份相似规则、工具返回、历史状态之间做决策，不是同一道题，因此长窗口的效用不应被高估。
15 分钟 · 3 卡片 · 8 资料
读原文 →