当你的 AI Agent 又出错了，你的第一反应是什么？换模型？调 prompt？加 few-shot？
这是行业过去两年的标准操作流程。Agent 出问题，99% 的团队第一刀砍向模型。不够聪明就换更强的，prompt 写不清楚就写更长的，推理不够好就加 Chain-of-Thought。
但一篇刚刚发表在 arXiv 上的论文，直接掀翻了这整套逻辑。
论文标题只有一句话：AI Agents Do Not Fail Alone: The Context Fails First。AI Agent 不会独自失败，是上下文先崩了。论文来自 ProofAgent 开源团队，实验对象是 GPT-5.5 和 Claude Opus 4.8。团队做了一个之前几乎没人做过的事：模型固定不变，只改 Agent 运行时的上下文环境，然后观察行为变化。
结果令人震惊。同样的模型，放在模糊的上下文里频频翻车，塞进结构化的上下文后表现判若两人。
论文提出了一个 7 维度的上下文质量评分体系，并证明：上下文质量是 Agent 可靠性的“起飞前检查信号”（preflight signal）。这个发现的冲击力，不亚于当年 Scaling Law 撞墙的讨论。因为它意味着，整个行业过去一年在 Agent 可靠性上的投入方向，可能从一开始就偏了。
一场精心设计的“翻案”实验
论文的实验设计堪称教科书级别的控制变量法。
团队选取了 GPT-5.5 和 Claude Opus 4.8 作为推理引擎，然后构建了三个层次的上下文环境。Poor（模糊）——角色定义含糊，工具描述缺失，缺乏知识支撑，对不可信输入几乎没有防护。Structured（结构化）——角色边界清晰，工具类型和用法明确，有知识支撑，信息组织更高效。Hardened（强化）——在结构化基础上增加更强的安全护栏、升级行为、输入隔离和“确认-再执行”模式。
实验覆盖了 300 组评估任务，累计 7500 轮 Agent 交互。结论直白得令人不安：当上下文从模糊变成结构化，同样的模型表现大幅提升。不是 10% 20% 的提升，而是质的飞跃，从“频繁翻车”到“稳定可靠”。
更关键的是，论文设计了一个精巧的隔离机制。上下文评分与行为评分完全独立计算，互不干扰。这意味着上下文质量对行为结果的预测不是“自己预测自己”的循环论证，而是真正的独立信号。
为什么这个发现如此重要？
2026 年，Agent 从概念验证走向生产部署的速度远超预期。但与此同时，Agent 失败率居高不下。行业默认的排查路径永远是：先怀疑模型，再怀疑 prompt，最后才看上下文。论文的发现直接翻转了这个优先级。
用 Rohan Paul 在 X 上的一句话总结：“The model may appear guilty, but the true failure frequently begins in the context surrounding it.”（模型看起来有罪，但真正的失败往往始于围绕它的上下文。）
从 Prompt Engineering 到 Context Engineering
论文首先提出了一个概念层面的区分，值得每一个 Agent 开发者认真理解。
Prompt Engineering 关注的是如何写好一条指令。调整措辞、加例子、设计格式，所有操作都围绕“输入信息”本身。Context Engineering 关注的则是 Agent 运行时接收到的全部信息环境：哪些指令存在、工具如何描述、知识如何支撑、记忆如何表示、可信和不可信内容如何分离、上下文如何随轮次演化。
这个区别绝非文字游戏。一个 Agent 的 prompt 可能只有几百 token，但它的上下文可能包含数千乃至数万 token，包括历史对话、工具 Schema、RAG 检索结果、安全规则、系统指令、用户输入。Prompt 工程只优化了其中一个小切口，而上下文工程要管理的是整个信息生态。
论文在引言中写得非常清楚：当上下文工程薄弱时，Agent 会表现出角色偏离、幻觉、工具误用、指令冲突、注入攻击脆弱以及 token 浪费。而这些症状，在传统排查中无一例外都被归类为“模型能力不足”。
七个维度的“上下文体检”
论文提出的核心实操工具，是一套 7 维度的上下文质量评分体系，实现在 ProofAgent-Harness 这个开源工具中。
评分采用多陪审员共识机制（multi-juror, consensus-based scoring），由多个评估者分别打分，然后通过讨论或德尔菲法达成一致。七个维度分别是：
Role Clarity（角色清晰度）——Agent 是否清楚自己是谁、能做什么、不能做什么？Guardrail Coverage（护栏覆盖度）——安全边界在哪里，越界行为如何拦截？Instruction Consistency（指令一致性）——同一上下文中是否存在互相矛盾的指令？Tool Schema Quality（工具描述质量）——工具的类型、参数、使用方式是否明确？Grounding Sufficiency（知识支撑充分性）——Agent 的回答是否有可靠的事实基础？Injection Hardening（注入防护强度）——是否区分可信指令和不可信用户输入？Token Efficiency（Token 效率）——上下文是否精炼，有没有浪费 token 的冗余信息？
每个维度独立评分，然后汇总成一个上下文质量总分。这个总分与行为评分完全隔离，评估者不会因为知道上下文得分高就给行为打高分。
每个维度都能预测一个行为结果
实验最有力的部分，是验证了上下文质量维度与 Agent 行为结果之间的一一对应关系。论文称之为“预测匹配”（predictive matching）。
Grounding Sufficiency（知识支撑）预测 Hallucination Resistance（抗幻觉能力）。上下文中有足够的事实支撑，Agent 就很少编造信息。Guardrail Coverage（护栏覆盖）预测 Manipulation Resistance（抗操纵能力）。安全护栏完善，Agent 更难被诱导越界。Instruction Consistency（指令一致性）预测 Instruction Following（指令遵循度）。指令不矛盾，Agent 就不会“精神分裂”。Tool Schema Quality（工具描述质量）预测 Tool Use（工具使用准确率）。工具描述清晰，Agent 就不会乱调用或错误使用。
这些对应关系看起来像是常识。但论文的贡献在于两点。第一，它用实验数据证明了这些关系确实成立，且独立于模型能力。第二，它提供了一个可量化的测量工具，让团队在部署前就能诊断上下文的健康度，而不是等到上线后从失败日志中回溯。
安全规则不是越多越好
论文的另一个反直觉发现，藏在 Hardened 上下文的实验结果中。
逻辑上，更强的安全护栏应该带来更好的整体表现。但实验发现并非如此。当团队给 Agent 增加更多安全规则后，Agent 在某些任务上确实更安全了，但在另一些任务上反而表现更差。
原因很简单：过度防护的 Agent 变得过于谨慎（too cautious）。面对一个需要快速判断的场景，Hardened 级别的 Agent 可能会反复确认、拒绝执行模糊指令，或者在应该行动的时候选择“上报”。在安全敏感场景中，这种谨慎是必要的；但在效率优先的场景中，过度安全规则反而拖垮了 Agent 的实用价值。
论文坦率地记录了这个 tradeoff，并将其作为“安全与效率不可兼得”的实证证据留给行业讨论。这是一个负责任的团队迟早要面对的选择题，而不是技术问题。
对行业的三个启示
第一，Agent 可靠性工程的重心，需要从模型层转移到上下文层。这不是说模型不重要。但当前行业对 Agent 失败的归因逻辑存在系统性偏差。当 Agent 出错时，大多数团队的第一反应是“换更强的模型”或“调更好的 prompt”。论文的发现表明，在大多数情况下，问题可能出在上下文的设计上：角色定义不清、工具描述不准确、知识支撑不足、安全边界模糊。在责怪模型之前，先给 Agent 的上下文做一次体检。
第二，Context Engineering 将成为 Agent 时代的核心工程能力。就像 2023-2024 年 Prompt Engineering 成为热门技能一样，2026-2027 年 Context Engineering 将取代它的位置。不是简单的“写 prompt”，而是系统性管理 Agent 运行时接收到的全部信息环境，包括工具 Schema、RAG 策略、记忆管理、安全规则、输入隔离、Token 预算。
第三，开源工具正在定义 Agent 评估的新标准。ProofAgent-Harness 的发布，意味着团队不再需要从零构建自己的 Agent 评估体系。7 维度评分框架、多陪审员共识机制、上下文与行为分离的评估设计，这些方法论可以作为行业标准被广泛采用。
所有正在将 Agent 推向生产环境的团队，都值得停下来想一想。如果你们还在用“换模型”作为 Agent 出错的唯一解决方案，很可能已经陷入了归因误区。在责怪模型之前，先给 Agent 的上下文做一次体检。
模型可能是无辜的。有罪的是上下文。
快报