📚 首页 / 14-certification-prep / common-traps.md

易错点合集（Common Traps）——从模块 01–13 提炼

每条：❌ 错误认知 → ✅ 正确认知 + 出处模块。这些是架构判断层面的坑，也是官方考试（考 tradeoff 判断）最爱设的干扰项。 复习法：先遮住 ✅ 那行，看 ❌ 能否自己说出正确认知；说不出 → 回链模块重读。

一、安全与权限（错一项就可能全失守）

🎯 学习重点：看到 prompt 禁令、宽权限、全量审批或可信域名时，先找模型外的确定性边界。
  1. ❌ 「prompt 里写了不许读 secrets，模型就不会读」

    2. ✅ LLM instruction ≠ application enforcement——授权必须在应用层/工具层用确定性代码强制（deny 规则、PreToolUse hook、工具根本不给）。安全评审先问：「这条期望由哪段代码强制？」 · 出处：M04/M08/M09/M11

  1. ❌ 「RAG 里加一句『请只引用本租户文档』就是权限控制」

    2. ✅ 提示词不是授权机制——权限必须在检索的 pre-filter 层由应用按元数据强制，否则就是数据泄露 · 出处：M07/M11

  1. ❌ 「给 agent 一个万能 shell/SQL 工具，方便」

    2. ✅ 万能工具 = 注入成功即全失守。最小权限工具面（least-privilege tool surface）：不能做 X 的正确实现是不给做 X 的工具 · 出处：M11/M13

  1. ❌ 「egress 白名单按域名过滤就行」

    2. ✅ 白名单是能力授予不是域名过滤——api.anthropic.com 也能当数据外传信道；要按 API 能力粒度评估 · 出处：M11

  1. ❌ 「审批弹窗越多越安全」

    2. ✅ 审批疲劳：弹得越多批得越快，93% 批准率 = 没有审批。低频高危才用审批门，高频操作靠沙箱/权限分级 · 出处：M11/M13

  1. ❌ 「防住了用户输入就防住了注入」

    2. ✅ 间接注入：工具输出、RAG 检索块、网页正文（含隐藏标签）都是载荷入口；网页要取渲染文本而非原始 HTML · 出处：M11

  1. ❌ 「把 API key 塞进沙箱/上下文，反正模型要用」

    2. ✅ 凭据不进沙箱——用短时 scoped token 代理换票；任何材料都不该出现明文密钥 · 出处：M11

  1. ❌ 「只测晴天路径，安全上线后再说」

    2. ✅ 上线前做注入红队测试，否则会被 best-of-N 攻击打穿 · 出处：M11

二、Agent 与编排（考试最大权重域的坑）

🎯 学习重点：路径可预测用 workflow，动态决策才用 agent，多智能体必须有可并行或专业化收益。
  1. ❌ 「agent 比 workflow 高级，能上就上」（为 agentic 而 agentic）

    2. ✅ 步数/路径可预测的任务用 workflow——可预测、可测试、可预算。控制权转移给模型是最后手段 · 出处：M08（官方 Building Effective Agents）

  1. ❌ 「agent loop 跑起来就行了，不用管停止条件」

    2. ✅ 无 max iterations / 预算上限的 loop 是烧钱事故。停止条件是 agent 上生产的准入门槛 · 出处：M08

  1. ❌ 「开放研究任务，我硬编一条查 A→查 B 的流水线」

    2. ✅ 步数不可预测的开放任务才需要 agent；硬编 pipeline 覆盖不全且是维护地狱——与上一条正好互为镜像 · 出处：M08

  1. ❌ 「multi-agent 系统更强大，默认拆多个 agent」

    2. ✅ multi-agent 四前提：开放式+可并行+超窗口+高价值，代价 ≈15× token。强依赖/共享上下文的任务（多数编码）不适合 · 出处：M08/M09

  1. ❌ 「agent 说『订好了』就是订好了」

    2. ✅ transcript 不是 outcome——任务成功的唯一可靠判据是环境终态（state_check 查数据库） · 出处：M12

  1. ❌ 「工具写好了就用，文档无所谓，重点调 prompt」

    2. ✅ ACI 投入：官方做 SWE-bench agent 时优化工具花的时间超过优化 prompt（例：强制绝对路径后模型零失误） · 出处：M04/M08

三、上下文与 RAG

🎯 学习重点：长窗口不等于知识库；检索、结构化分块、权限过滤和来源归因各解决不同问题。
  1. ❌ 「上下文窗口 1M，把所有文档塞进去就行」（上下文塞满）

    2. ✅ context rot：token 越多召回越差，且 lost in the middle——关键信息别埋中部。策展上下文 > 塞满窗口 · 出处：M01/M07/M08

  1. ❌ 「知识库一大就必须上向量数据库」

    2. ✅ 小库「全量塞 prompt + prompt caching」常常又便宜又准——先问库多大再选架构 · 出处：M07

  1. ❌ 「向量检索是语义的，万能」

    2. ✅ 精确 token（错误码、SKU、函数名、条款编号）是向量检索的系统性盲区——BM25/混合检索才是正解 · 出处：M07

  1. ❌ 「固定 512 字符切块，简单」

    2. ✅ 结构化文档按标题/函数/表格行切并保留层级元数据；硬切把表格切两半、让「增长了 3%」丢失主语变废数据 · 出处：M07

  1. ❌ 「多租户场景，检索完再按租户过滤也一样」

    2. ✅ post-filter 可能把 Top-K 滤空或被迫回填噪音；pre-filter 更准也更安全 · 出处：M07

  1. ❌ 「检索效果不好就调 K / 调 prompt」

    2. ✅ 先做检索层评估（recall/precision/MRR）再动其他层；K 调大 recall 涨是假象——context rot 与干扰成本同涨 · 出处：M07/M12

  1. ❌ 「索引建好就一劳永逸」

    2. ✅ 文档更新、政策作废后索引是陈旧的——ingest 管线要有增量更新与失效机制 · 出处：M07/M13（支持政策「旧版作废」需求）

  1. ❌ 「有据的回答就是正确的回答」

    2. ✅ groundedness ≠ accuracy：引用可能过时/错误（有据不正确），也可能碰巧对而无引用（正确无据）——两个维度分开评 · 出处：M07/M12

四、提示工程与结构化输出

🎯 学习重点：结构化输出保证语法不保证语义，旧版 prefill 与手动 thinking 题要识别时效。
  1. ❌ 「prompt 里写了『输出 JSON』就有格式保证」

    2. ✅ 软指令永远有漏网率。下游系统对接要 structured output（constrained decoding）的硬保证 · 出处：M05

  1. ❌ 「输出不符合 schema 就重试」

    2. ✅ repair retry 只对格式类错误有效；语义错误重试无解，要评估管线兜底。结构化输出本身只保格式不保语义 · 出处：M05

  1. ❌ 「few-shot 示例给 5 个一样的成功案例最好」

    2. ✅ 示例全部同构 = 模型学到你示例的偏差；示例要覆盖任务的真实变化（含边界情形） · 出处：M05

  1. ❌ 「还在用 prefill / budget_tokens 老技巧」

    2. ✅ prefill 4.6+ 已弃用（返回 400）、手动 extended thinking 4.7+ 拒绝——2026 现行方案是 structured output + adaptive thinking（effort）。旧教程识别题 · 出处：M02/M05

  1. ❌ 「system prompt 塞 user 消息里也一样」

    2. ✅ system 是顶层参数：角色边界的规范位置 + 参与缓存前缀——塞错位置浪费缓存与稳定性 · 出处：M02/M05

五、API 与生产运维

🎯 学习重点：按错误类型决定重试，按顶层预算分配超时，按版本与灰度控制变更风险。
  1. ❌ 「429 就退避重试」

    2. ✅ 两类 429：限流 429 带 retry-after（等待重试有效）；spend-cap 429 无 retry-after（重试到天亮也无效，要查 error_code）· 出处：M03/M10

  1. ❌ 「400/401/403 也能重试成功」

    2. ✅ 4xx 是确定性错误，重试只是烧钱；只有瞬时错误（限流 429/500/529/连接错误）值得重试 · 出处：M03/M10

  1. ❌ 「每层都设 30 秒超时，很稳」

    2. ✅ 多层超时会叠加成分钟级挂起；超时预算从顶层向下分配，耗尽即降级 · 出处：M10

  1. ❌ 「时间戳/随机 ID 放消息里无所谓」

    2. ✅ 它们混进缓存前缀 → 永远 cache miss 还以为缓存坏了；断点要放「跨请求不变的末块」 · 出处：M03/M10

  1. ❌ 「529 过载，加大并发硬刚」

    2. ✅ 529 是全平台过载信号——正确响应是退避 + 平缓爬坡 + 熔断器，不是加并发 · 出处：M10

  1. ❌ 「降级了能用就行，不用告诉任何人」

    2. ✅ 降级三件套：响应显式声明 degraded、指标单独计数、可恢复切回——否则用户与运维都被蒙在鼓里 · 出处：M10/M13

  1. ❌ 「升级人工时把整段对话丢过去就行」

    2. ✅ 结构化交接：原请求/已试路径/trace_id——坐席不读 30 轮聊天记录；升级只丢一句话反而更慢 · 出处：M10/M13

  1. ❌ 「生产用别名（alias）自动跟最新版」

    2. ✅ 别名会漂移——行为随上游静默变化，评估失去意义；生产锁固定快照 ID，升级走灰度+回归评估 · 出处：M02/M10

  1. ❌ 「日志把 prompt 全记下来方便排查」

    2. ✅ PII 与凭据进通用日志 = 合规事故；内容级日志独立开关 + 脱敏 + 加密 + 期限 · 出处：M10

  1. ❌ 「Batches 里加 stream: true / fast mode 试试」

    2. ✅ 批处理不支持的参数是硬约束——直接整批验证失败；custom_id 也有格式规则 · 出处：M03/M10

六、评估

🎯 学习重点：平均分、单一 recall 或未校准 judge 都会制造假信号，必须分层并审计 grader。
  1. ❌ 「评估看平均分就够了」（平均分掩盖分层失败）

    2. ✅ 所有维度糊成一个数，回归发生时无法定位层——分层指标（task/tool/groundedness/延迟）分开设 · 出处：M12

  1. ❌ 「0% 通过率，肯定是模型太烂」

    2. ✅ 前沿模型 0% 多半是题目/评分器坏了——每题配参考解证明可解；先审 eval 再审模型 · 出处：M12

  1. ❌ 「LLM judge 直接拿来打分」

    2. ✅ 无 rubric、无 Unknown 出口、不与人工对表的 judge 不可信——四条官方技巧 + 定期校准 · 出处：M12

  1. ❌ 「幻觉率降了，效果变好了」

    2. ✅ 弃答率必须成对上报——全拒答可刷出幻觉率 0；幻觉率与任务成功率联动看 · 出处：M12

  1. ❌ 「评估集建好就完事了」

    2. ✅ 饱和不毕业、题目不换血、线上失败不回流——评估是活资产（毕业进回归套件 + 每月回流） · 出处：M12/M13

  1. ❌ 「只测『该做 X 时做了 X』」

    2. ✅ 单侧问题集训出过度触发的系统——双向平衡（该搜/不该搜都测） · 出处：M12

  1. ❌ 「严格校验工具调用顺序，保证规范」

    2. ✅ 惩罚设计者没预料的合法路径（CORE-Bench 42%→95% 的教训）——评产出不评路径，只有业务规则顺序才硬校验 · 出处：M12

七、MCP 与工具

🎯 学习重点：区分 tools/resources/prompts 的控制方，并把业务错误与协议错误分开处理。
  1. ❌ 「MCP 就是更好的 REST」

    2. ✅ MCP 解决工具的发现/描述/注入标准化（M×N→M+N），不是接口性能升级；单一稳定集成直接 API 更简单 · 出处：M06

  1. ❌ 「tools/resources/prompts 都是给模型用的」

    2. ✅ 控制方不同：tools=模型控制、resources=应用驱动、prompts=用户控制——考试最爱考 · 出处：M06

  1. ❌ 「工具执行报错就抛异常，别让模型看见」

    2. ✅ 业务错误要以 isError=true 的 structured error response 回传给模型自我修正；只有协议级错误才走 JSON-RPC error · 出处：M04/M06

  1. ❌ 「几十个工具全量注入定义」

    2. ✅ 上下文成本与选择准确率双杀——progressive discovery / tool search 按需加载 · 出处：M06/M09

  1. ❌ 「MCP server 的 token 直接转发给下游 server」

    2. ✅ token passthrough 被规范明令禁止——绕过 audience 控制与审计链；换票（scoped token）才对 · 出处：M06/M11

  1. ❌ 「工具返回全量原始数据，信息越全越好」

    2. ✅ 上下文被工具结果淹没——返回摘要/字段裁剪后的结果，全量数据留在应用层 · 出处：M04/M08

配套：术语速览见 exam-vocabulary.md；按天复习计划见 last-week-review.md。
📚 目录