CCA-F 反复惩罚的 10 个 CCA 考试反模式

CCA-F 的题目是用一个个场景搭起来的，场景里总有一个或几个选项是一眼能认出来的架构反模式：只靠提示词文本约束一条硬规则、每种失败都返回同一个错误、给一个 agent 所有工具、跑一个没有停止条件的 agent 循环、派生子代理却不把它需要的上下文传过去。学会认出下面这十个，大多数题目就会从四个都说得通的选项塌缩成两个。

下面每个反模式都链接到详细讲解修法的学习指南文章。领域编号沿用本站学习指南（D1 Agentic Architecture、D2 Tool Design & MCP、D3 Claude Code、D4 Prompt Engineering、D5 Context Management）。

为什么考试总在考反模式？

因为考试是情景题，要你在既定约束下选出最不坏的设计，出题人就需要看起来合理的错误选项。写一个看起来合理的错误选项，最省事的办法就是描述团队真的会做的事：往系统提示里加一句话、多重试几次、给 agent 更多工具、把上下文窗口换大。这些做法在某些情况下没问题，在题目描述的那个情况下就是错的。考的能力是：把机制和所需的保证对上号。

约束类反模式

1. 用提示词而不是 hook 来约束硬规则。 场景说某个动作绝对不能发生（删生产库表、未经批准给客户发邮件、重复执行一笔支付）。错误选项是往系统提示里加“绝不要做 X”。模型仍然会在某个比例的情况下做 X；hook 和权限检查则不会。学习：模型会在 4-15% 的情况下无视你的指令 和 按后果和可验证性选择，不是按合规率。领域：D1。

2. 用提示词而不是 schema 来约束输出结构。 “只输出符合这个形状的合法 JSON”给你的是大部分时候合法的 JSON。带 input_schema 的 tool_use 每次都给你结构合法的输出；语义校验仍然要跟上。学习：tool_use 消灭了结构错误。语义错误还在。。领域：D4。

工具与错误处理类反模式

3. 千篇一律的错误信息。 每种失败都返回 “operation failed”，agent 分不清权限错误和超时，于是在一件永远不会成功的事上烧掉五次重试。修法是 isError 加上分类过的错误类型。学习：“Operation Failed” × 5 次重试 × 30 秒 = 客户白等 和 没有分类，Agent 在权限错误上浪费 5 次重试。领域：D2。

4. 给一个 agent 所有工具。 工具列表越长，选择准确率越低；一个协调者拿着它永远用不到的数据库写入工具，既更不准也更不安全。每个 agent 只拿它角色需要的工具。学习：3 个工具 = 97% 准确率，18 个 = 51%：工具数量曲线 和 最小权限：每个 Agent 只拿角色所需的工具。领域：D2。

5. 编排里的通用错误上下文。 子代理或工具往上只报一句“数据库错误”，别的什么都没有，编排器就去重试一个早已下线的资源。结构化的错误上下文（什么失败了、能不能重试、已经试过什么）才能让调用方做决定。学习：“数据库错误”——编排器重试了 5 次。数据库早就永久下线了。 和 通用的”失败”→ 18% 恢复率。结构化错误 → 71%。。领域：D5。

6. 把访问失败报成有效的空结果。 搜索超时了，报告却说“不存在相关研究”；数据库挂了，工具却说“订单不存在”。失败和不存在必须在结果里区分开。学习：“不存在同行评审研究”——实际上，停机结束后找到了 47 篇论文，以及它在 D2 的对应篇 “您的订单不存在”——但它存在，只是数据库挂了。领域：D2 和 D5。

编排类反模式

7. 没有边界的 agent 循环。 循环一直调用模型直到它“完成”，没有迭代上限、没有成本上限、也不检查 stop_reason。正确的循环由 stop_reason 驱动，并带有显式的终止条件和预算条件。学习：stop_reason 才是唯一靠谱的循环控制 和 三个破坏 Agentic 循环的反模式。领域：D1。

8. 在适合模型驱动路由的地方硬编码决策树。 场景里是开放式的用户请求，错误选项却在模型前面搭一个 if/else 分类器。当路由依赖对语言的理解时，让模型来路由（配上描述清楚的工具）；固定逻辑留给真正固定的流水线。学习：模型驱动 vs 硬编码决策树 和 动态分解在固定任务上多 30% 开销：按任务类型匹配策略。领域：D1。

9. 不做子代理上下文隔离，或者反过来：假设子代理会继承上下文。 同一个错误的两个版本。要么协调者把整段对话一股脑倒进每个子代理（成本、噪音、锚定），要么假设子代理已经知道客户 ID，什么都不传。子代理从空白开始；传结构化的事实，不要传对话记录。学习：子代理什么也看不到：上下文必须显式传递 和 结构化数据保留归因，纯文本摧毁归因。领域：D1。

上下文类反模式

10. 往上下文里硬塞，而不是管理它。 长会话会退化，错误选项于是“换一个窗口更大的模型”，或者把每次工具结果原样追加。修法是结构性的：把工具输出过滤到需要的字段、维护一个持久的案件事实块、把发现写进 scratchpad、把大批量阅读委派给子代理。学习：来源 1-2：96%。来源 5-6：52%。来源 9-10：94%。U 形注意力曲线。、返回 40 个字段，需要 5 个——4 次调用就把上下文撑满了，本该能撑 11 次 和 Scratchpad：在上下文遗忘之前把发现写下来。领域：D5。

还有一个近亲，虽然算上它就是十一个，也值得点名：按模型置信度或用户情绪来路由升级。 两者都是不可靠的信号；应该在用户明确要求转人工、政策空白、多条匹配无法消歧时升级。学习：高置信度（0.9+）：12% 出错。低置信度（<0.5）：68% 正确。这个信号坏了。。领域：D5。

通过这些反模式，考试真正在考什么？

上面每一个反模式，都是在场景需要别处提供保证的时候，把模型当成了保证：这个“别处”可以是 hook、schema、结构化错误、限定范围的工具列表、显式的循环条件，或者上下文结构。读题时先问一句“什么必须每次都成立”，再检查哪个选项能用机制把它变成必然。这一个问题就能排掉大多数反模式选项。

下一步

用免费的 60 题模拟考 测测你的识别速度；每答错一题，说出你选的选项属于这十个模式里的哪一个。然后系统学一遍 领域 1——十个里有五个住在那里——再学 领域 5，把上下文和错误上下文的模式补齐。