全真模拟考试 #1

agentic loop 的标准模式：当 stop_reason 为 tool_use 时，意味着模型在等待工具执行结果以继续推理。你需要执行该工具调用，将返回结果以 tool_result 角色消息传入对话，然后继续 loop。模型收到结果后会继续推理（可能返回更多 tool_use 或最终 end_turn）。

B：延迟重试与 stop_reason 无关 — tool_use 是明确的结构化信号，不需要等待或重试。

C：退款操作是正常的工具调用场景，tool_use 恰说明 loop 在正确运转，不应终止。

D：不传结果会导致模型缺乏执行反馈，无法判断下一步该做什么。

单一终止条件不可靠。max_turns 作为硬上限防止无限循环（成本控制），重复检测作为软终止避免无效消耗。当模型陷入循环（反复调用同一工具但无进展，或输出高度重复的文本），提前终止比等到 max_turns 更高效。

A：模型有时会持续调用工具（即使没必要），完全依赖 end_turn 可能导致无限循环和巨额费用。

C：降低上限会惩罚需要多轮迭代的合理任务。

D：注入系统消息会破坏对话结构 — 模型在第 29 轮收到的消息与第 28 轮完全不同，可能产生不可预期的行为。

子智能体的核心价值在于专业化。每个子智能体应有聚焦的系统提示词，只包含该领域的审核规则、术语和标准。这样每个智能体的上下文干净、专业，不会被其他领域的信息干扰。总控智能体拿到三个独立意见后进行溯源合成，可以明确每条审核意见的来源和依据。

A：共享上下文会破坏独立性 — 法务的意见可能不恰当地影响财务判断。且全量历史消耗大量 token。

C：总控智能体统一分析失去了多智能体分工的意义，应采用分层处理。

D：加权平均对定性审核无意义 — "合同有重大法律风险"和"金额无误"不能平均。

子智能体的系统提示词应遵循最小化原则：只描述当前子任务的目标、涉及的文件路径、相关规则和输出格式。不应包含全局项目信息、无关的编码规范或其他子智能体的职责。更窄、更精准的提示词既减少 token 消耗，又提升专注度。

A：合并智能体会使单点上下文压力更大，且失去了专业化和并行处理的好处。

C：简略回答的指令对上下文窗口占用几乎无影响，真正占用上下文的是输入（系统提示词 + 工具结果 + 对话历史）。

D：流式输出只影响响应传输方式，不影响上下文窗口内的 token 计数。

最小权限原则要求每个子智能体只获得完成其任务所必需的工具。lint 检查器只需 Read；重构执行器需要 Read + Write（可能还需要 Bash 执行构建验证）；报告生成器需要 Read 源代码 + Write 报告文件，但应限定到 report/ 目录防止意外修改源码。

A：授予相同权限违反了最小权限 — lint 检查器不需要写权限。

C：父智能体手动执行会变成瓶颈，也失去了智能体自动化的意义。

D：检查器和报告生成器需要 Read 才能工作，不给任何工具会使它们完全无用。

健壮的错误处理需要区分错误类型：5xx（服务端临时故障）适合重试，指数退避（1s → 2s → 4s）减少服务器压力；4xx（客户端错误如参数非法）重试无意义，应立即报告以便修复；网络超时短暂重试后若仍失败，应有降级方案（如返回缓存数据或部分结果）。

A：统一重试对 4xx 是浪费且误导 — 参数错误重试 3 次也不会有不同结果。

C：跳过关键步骤（如支付）会导致后续步骤在不一致的状态下执行。

D：模型不应负责重试决策 — 这是基础设施层的职责，且模型的判断不一致。

持久化状态管理的最佳实践：在 loop 外维护一个状态对象（case facts），包含用户偏好、已收集的关键信息、待办事项等。每轮组装请求时，将这些事实以结构化格式注入到消息中（通常作为系统消息或最近一条 user message 的前缀）。这样即使对话历史很长，关键上下文始终在模型的注意力焦点内。

A：重复插入会产生冗余，且人工设置间隔容易出错。

C：更大的上下文窗口不是解决方案 — 模型对窗口中部信息的注意力天然衰减（"lost in the middle" 问题）。

D：禁止追加工具结果会让模型失去执行反馈，无法继续工作。

智能体任务编排应遵循 DAG（有向无环图）模式：分析任务间的依赖关系。提取表格、识别论点、检查一致性之间没有相互依赖，可以并行执行。摘要任务天然依赖前三者的输出，必须串行等它们完成。这种混合并行/串行策略在保证正确性的前提下最大化吞吐量，预计总耗时可降至约 5 分钟。

A：摘要任务在不知道前三者结果的情况下只能做泛泛总结，质量会大幅下降。

C：换模型不能弥补架构问题 — 串行仍是串行，且低质量模型可能导致重做。

D：拆分 PDF 破坏文档的整体语义 — 跨章节的论点关联和数据一致性检查无法进行。

Hook 系统是实现合规横切关注点的理想机制。PreToolUse 在工具执行前触发：可检查参数合法性、记录审计日志、拦截未授权查询。PostToolUse 在工具执行后触发：在结果返回模型前自动扫描并脱敏敏感字段（如 SSN 替换为 ***-**-1234）。这样合规逻辑与业务逻辑分离，且模型永远看不到未脱敏数据。

A：依赖模型自觉是不可靠的 — 模型可能遗漏、格式不一致，且在 prompt injection 攻击下可能被绕过。

C：不做审计违反合规要求。

D：每次弹窗打断了智能体的自动化流程，且人工审批成为瓶颈。

可观测性三支柱（日志/指标/追踪）在智能体系统中的核心是 trace。每个工单一个唯一 trace ID，记录：每轮的用户消息、模型 response（含思考 + tool_use + 文本）、工具实际执行结果、模型下一轮输入。这样当工单结果不理想时，可以按 trace ID 回放整个过程，精确定位是工具返回了错误数据、模型推理偏差还是 loop 提前终止。

B：只存原始对话缺少结构化元数据（turn 序号、trace ID、时间戳），排查效率低。

C：只有最终回复无法定位中间步骤的问题。

D：模型自评不可靠且不客观，不能代替结构化日志。

复杂任务的分解应遵循「理解 → 规划 → 增量执行 → 验证」模式。先分析现有代码避免破坏已有功能；设计方案确保三种模式可共存；逐个实现降低单次变更的 blast radius，每次实现后测试；最后做兼容性回归测试确保旧版 API 仍可正常使用。

A：一次性完成大型重构的失败率极高，且难以定位问题。

C：随机开始意味着缺少全局视角，容易在中途发现架构冲突不得不返工。

D：过度设计 — 用户需要的是执行而非文档，且 50 页文档消耗大量 token 和时间。

凭据安全的黄金法则：凭据永远不应进入模型的上下文窗口。系统提示词和对话历史可能被记录、缓存或意外输出。在工具定义中使用环境变量占位符（如 ${GITHUB_TOKEN}），实际凭据由运行时注入，模型只知道"有一个 GITHUB_TOKEN 可用"但从未见过 token 值。这最小化了凭据泄露的攻击面。

A：API key 在系统提示词中可被模型输出、被日志记录、或在 prompt injection 攻击中被提取。

C：手动输入破坏自动化流程，且用户在对话中输入凭据同样有泄露风险。

D：单一超级 key 违反最小权限原则 — 一个 key 泄露影响所有 API。

工具 schema 设计需要在完整性和简洁性之间取得平衡。12 个参数全显式定义会让 schema 过于冗长，模型选择参数时容易出错。更好的做法是：将高频使用的核心参数显式定义为顶级字段（类型安全、自动校验），低频参数收敛到一个 filters 对象中，并在 description 中提供常用组合的示例。这样既保持了灵活性，又降低了模型的决策复杂度。

A：全部显式定义虽然技术上可行，但参数过多会增加模型选错参数组合的概率。

C：单一 text 参数放弃了结构化 schema 的好处 — 后端解析不可靠，模型表达也不统一。

D：只在 description 中说明的参数，模型无法以结构化方式传入。

高质量的 tool description 应包含四要素：(1) 做什么（what），(2) 什么时候用（when — 适用条件），(3) 什么时候不能用（when-not — 限制和边界），(4) 行为细节（成功/失败时的返回行为）。这样模型在选择工具时能做出更准确的判断，避免在不适用场景中错误调用。

A：过于简略，模型无法判断工具的限制条件，可能在订单已发货后仍调用此工具。

C：只有参数说明缺少限制条件，模型不会自动知道 30 分钟和 pending 状态的限制。

D：礼貌用语占用 token 但未提供任何有用的决策信息。

MCP 中 Resource 与 Tool 的核心区分：Resource 是「暴露数据」，适合相对静态、可被 URI 标识的内容（如政策文档、代码文件、数据库 schema）；Tool 是「执行操作」，适合需要参数化、实时计算或产生副作用的行为（如查询工单状态、创建记录、调用外部 API）。工单状态是实时变化的，需要传入参数（如工单 ID）查询，适合 Tool；政策文档可以直接用 URI 读取，适合 Resource。

A：Resource 不支持参数化查询 — 每次查询不同工单需要不同 URI，不灵活。

C：政策文档不需要参数和实时计算，用 Resource 暴露更简单直接。

D：Prompts 是预定义的提示词模板，不适合用来暴露数据。

MCP 支持两种传输机制，选择取决于通信距离。stdio 传输：client 作为父进程启动 MCP server 子进程，通过标准输入/输出（stdin/stdout）通信 — 适合本地工具，零网络配置，天然安全。HTTP + SSE 传输：client 通过 HTTP 请求与远程 server 通信，SSE 用于服务器向客户端推送 — 适合远程场景，支持多客户端连接、负载均衡和标准 HTTP 安全机制（TLS、OAuth）。

A：本地场景不需要 HTTP 的开销和复杂度。

C：stdio 无法用于远程通信 — 它依赖父子进程间管道。

D：SSH 隧道增加了不必要的复杂度，HTTP + SSE 本身就是为远程设计的。

批量操作中的部分失败是常见场景。工具应返回结构化响应，包含三部分：(1) 成功列表（让模型知道哪些文件已处理完成），(2) 失败列表（每个失败项附带文件名和具体错误原因，模型可利用这些信息决定后续策略 — 如建议手动修复格式），(3) 整体状态标记（partial_success 让模型和 loop 逻辑知道发生了什么）。这样模型可以做知情决策，而不是面对一个笼统的 "error"。

A：静默忽略失败会让模型在不知情的情况下遗漏数据。

C：遇到第一个失败就终止会浪费剩余文件的处理机会。

D：格式不兼容的问题重试不会自动修复，反而是浪费。

MCP server 的安全应在多个层面实施，但最重要的是数据和操作层面的鉴权。每个 Tool 和 Resource 在返回数据前应验证调用方身份（通过 MCP 的认证机制或自定义 token），根据角色权限过滤数据字段和范围。例如：经理可以查看本团队薪资但不能看其他团队；HR 可以查看但不能修改；普通员工级别的 Resource 根本不暴露薪资字段。

A：日志只是记录，不是访问控制。

C：网络隔离是必要的防御层，但不能替代应用层鉴权 — 内网用户也应有不同权限。

D：在提示词中说明限制对模型没有约束力 — prompt injection 或模型错误可能导致数据泄露。

工具版本管理的最佳实践与 API 版本管理一致。创建 search_v2 作为新工具定义（新 schema + 新返回格式），保留 search_v1 标记为 deprecated。给消费方智能体团队设定明确的 sunset date，在迁移窗口内他们可以逐步切换。旧版本不再新增功能但保持可用，确保生产稳定性。

A：硬切换风险大 — 一个智能体未及时更新就会在生产环境出错。

C：不更新 schema 意味着模型看到的工具描述与实际返回不一致，会导致解析错误。

D：Fork server 会带来维护负担，且消费方需要重新配置 server 连接信息，成本更高。

防御性工具设计：永远不要信任模型的参数格式。应在工具实现的入口处做严格校验，如果格式不符合预期，返回一个包含以下信息的错误：(1) 哪个参数有问题，(2) 期望什么格式，(3) 给出一个正确示例。这样的错误消息传回模型后，模型通常能在下一轮自动修正。这是 agentic loop 的自我纠错机制的体现。

B：提示词指令不能保证模型每次遵守，尤其在复杂对话中注意力可能分散。

C：只靠 description 不做校验，是"信任但不验证"，不可靠。

D：后端自动纠正虽然方便但隐藏了问题 — 应该让模型学会正确调用。

MCP 的 Prompt 原语专为此场景设计。它允许 server 定义可参数化的提示词模板（如 review_pr 模板接收 pr_url 参数），返回结构化的消息列表（可包含 role、content 和 resource 引用）。client 可以将返回的消息直接注入到对话上下文中。这样常用的专业提示词不需要每次由用户手写，保证了质量和一致性。

A：用 Tool 模拟 Prompt 是可能的但不符合语义 — Prompt 的意图是提供模板而非执行操作。

C：Resource 是数据暴露，不适合存放需要参数替换的模板。

D：description 字段不适合放长文本模板，且不支持参数化。

MCP server 的边界应遵循领域驱动设计的限界上下文原则。按业务能力拆分 server 的好处：(1) 每个 server 的 Tool 列表精简，模型更容易选择正确工具；(2) 独立部署和权限控制 — 处理订单的智能体不需要访问用户管理的 Tool；(3) 故障隔离 — 一个 server 出问题不影响其他业务；(4) 团队可以独立维护各自的 server。

A：50 个 Tool 在一个 server 中会让模型选择困难，且单一 server 成为单点故障。

B："万能工具" 失去了 MCP tool schema 提供的结构化参数校验优势。

D：按频率而非领域拆分，会导致跨领域耦合 — "用户管理" 和 "订单处理" 混在一个 server 中。

CLAUDE.md 采用层级继承模型：Claude Code 会从当前工作目录向上遍历到仓库根目录，收集所有 CLAUDE.md 文件，将它们合并为一个指令集。子目录的指令可以覆盖父目录的指令（就近原则）。这允许全局配置（根目录）设定通用规范，项目级配置（子目录）添加或覆盖特定规则。

A：子目录不会完全覆盖父目录 — 两者合并。

C：子目录的 CLAUDE.md 是有实际效力的，不只是参考。

D：Claude Code 自动合并，不需要用户手动选择。

Claude Code 的自定义斜杠命令通过在 .claude/commands/ 目录下放置 Markdown 文件来定义。文件名即命令名（如 deploy.md → /deploy）。文件内容包含该命令的提示词指令。项目级命令覆盖全局命令，允许不同项目有不同的部署实现。可以在全局级别定义通用模板，在项目级做具体化。

A：全局定义无法适应不同项目的部署差异。

C：CLAUDE.md 的注释不会自动变成可调用的斜杠命令 — 需要使用 .claude/commands/ 机制。

D：这不是插件市场的标准功能，且同样缺乏项目级定制能力。

Hook 系统可以在工具执行前插入强制检查。PreToolUse hook 拦截所有 Edit/Write 调用，检查是否存在对应的 plan 文件（通常位于 .claude/plans/ 目录）。如果 plan 文件不存在，hook 返回一个拒绝响应并提示用户先运行 /plan。这是程序化保障，比约定更可靠 — 因为约定可能被遗忘或在压力下跳过。

A：提示词指令是约定而非强制 — 模型可能在复杂指令中忽略此要求。

C：移除写权限过于极端，计划确认后仍需正常执行修改。

D：人工提醒不可靠且不能规模化 — 每次对话都要记得提醒。

不同 Hook 类型对应生命周期中的不同阶段，选择正确的类型才能实现预期行为。PostToolUse：在工具执行完成后触发，适合记录审计日志（知道工具实际做了什么、返回了什么）。PreToolUse：在工具执行前触发，可以阻止执行，适合二次确认。Stop hook：在会话结束时触发，适合生成摘要或清理资源。

A：PreToolUse 在工具执行前触发 — 此时还不知道执行结果，无法做有意义的审计日志。

C：提示词不能拦截工具调用或感知生命周期事件。

D：包装脚本无法感知 Claude Code 内部的 Hook 生命周期。

Claude Code 的权限系统支持三级粒度：allow（自动批准）、ask（每次询问）、deny（完全禁止）。安全最佳实践：将已知的危险操作加入 deny 列表（rm -rf、git push --force、chmod 777 等），将文件修改操作限制在项目目录内以防止越界访问，其余操作使用默认的 ask 模式让用户有机会审查每次调用。

A：auto-approve 所有工具对新成员来说风险太高。

C：禁用所有工具会使 Claude Code 失去大部分能力。

D：提示词中的警告没有强制力，模型可能忽略或在复杂场景中忘记。

Claude Code 的配置设计是 IDE-agnostic 的。所有配置（CLAUDE.md、commands/、hooks/、settings.json）都存放在项目仓库的 .claude/ 目录中，无论 VS Code 还是 JetBrains 扩展都从同一目录读取。将 .claude/ 提交到 Git 意味着配置与代码一起版本管理、一起 Code Review、一起部署，确保所有团队成员和 CI 环境使用相同的配置。

A：两份副本会不可避免地产生差异，且维护成本翻倍。

C：网络驱动器引入单点故障和权限问题。

D：要求 JetBrains 用户手动转换会引入人为错误，也违背 "配置即代码" 原则。

多仓库配置管理采用"模板继承"模式：一个中心模板仓库定义通用规范（编码标准、安全策略、常用命令），各微服务仓库通过参考模板创建自己的 .claude/ 配置，只在需要差异化的地方做覆盖。CI pipeline 定期检查各仓库是否与模板有非预期的差异，确保核心策略不被意外修改。这是"DRY + 允许覆盖"的平衡。

A：复制粘贴导致配置漂移 — 修改通用规范需要同步 5 个仓库，容易遗漏。

C：缺少配置的项目丧失了 Claude Code 的定制能力。

D：全局配置对所有项目生效，无法处理项目间的合理差异。

Claude Code 的 settings.json 支持全局和项目两级。个人偏好（主题、telemetry、自动更新）应在全局级别配置，因为它们与用户身份相关而非项目。默认模型可以在全局设置个人偏好，也可以在特定项目中覆盖（例如某个项目预算有限使用 Sonnet 而非 Opus）。这体现了：个人设置 → 全局，项目设置 → 项目级，项目级覆盖全局级。

A：CLAUDE.md 是给模型的指令，不是给 Claude Code 运行时的配置项。

C：虽然部分设置支持环境变量，但不是所有设置都适用，且环境变量不便于版本管理。

D：命令行参数不适合持久化配置。

Claude Code 提供了 EnterWorktree 机制来支持任务级隔离。在 CLAUDE.md 中配置 worktree 策略（何时创建、分支命名规则、清理策略），Claude Code 在开始任务时自动创建隔离的 git worktree。这样每次任务在独立的文件系统空间中运行，互不干扰，完成后可以选择保留或删除 worktree。分支管理、代码提交等 git 操作仍在正常流程中进行。

A：手动流程增加操作负担且容易出错（忘记清理、命名不一致等）。

C：单 worktree 无法并行处理多个任务，且不同任务的上下文可能相互干扰。

D：完整克隆浪费磁盘空间和时间 — worktree 共享 .git 目录，秒级创建。

Agent Skill 的复用应遵循"通用逻辑 + 参数化"原则。SKILL.md 定义生成测试的通用方法论（如何分析函数签名、边界条件、mock 策略等），项目在 CLAUDE.md 中配置具体参数（使用的测试框架、命名约定、覆盖率目标百分比、是否需要测试 fixtures）。Skill 被调用时读取当前项目的 CLAUDE.md 获取参数。这使得 Skill 本身保持通用，而差异化由项目配置驱动。

A：硬编码所有项目的配置会让 Skill 文件臃肿且难以维护。

C：创建多份副本失去了复用的意义 — 通用逻辑的改进需要同步到所有副本。

D：不使用 Skill 意味着每次都需要重述需求，失去了标准化和效率。

系统提示词应遵循"行为指令在提示词，事实数据在工具"的原则。产品列表和退换货政策是事实性数据，会随时间变化，放在系统提示词中有三个问题：(1) 占用大量 token，(2) 更新需要修改提示词而非数据源，(3) 模型对提示词中部信息的注意力衰减。将这些数据移到工具中，模型在需要时查询，既节省 token 又保证数据实时准确。

A：臃肿的提示词不仅浪费 token，还会稀释关键指令的有效性。

C：角色和语气是客服智能体的核心行为约束，不应删除。

D：盲目压缩会丢失关键的行为指令。

静态 few-shot（固定示例）有两个问题：示例可能与当前场景不匹配（审查 Go 代码时 Python 示例无关），且占用上下文空间。动态 few-shot 策略：(1) 先让模型或用规则识别代码语言和问题类型，(2) 从 curated 示例库中检索最相关的 2-3 个示例（基于语言和问题类型相似度），(3) 将这些示例注入到当前消息中。这样模型每次都看到高度相关的示例，提升审查准确度。

A：固定的 10 个示例浪费 token — 审查 Go 代码时 5 个 Python 示例无关且占用空间。

C：没有示例的话，模型对审查风格和粒度没有直观参考。

D：要求用户提供示例违背自动化原则，且用户示例质量参差不齐。

两种方式都能实现结构化输出，但适用场景不同。通过 tool_use 的 input_schema（方案 C）是最可靠的方式 — 模型被训练为在 tool_use 中生成符合 schema 的 JSON，在实际中也更稳定。但如果场景是模型需要在文本回复中输出 JSON（非工具调用场景），则方案 B（Schema + 示例 + 校验 + 重试）是有效的。两种方式并非互斥，可以在一个系统中同时使用。

A：文字描述不够精确 — 模型可能输出字段名拼写错误或嵌套层级不对。

Chain-of-Thought (CoT) 提示的核心是为模型提供推理的"脚手架"。通过明确定义推理步骤（提取 → 对比 → 趋势分析 → 环境分析 → 综合建议），模型被引导按结构化流程思考，而不是跳跃到结论。每一步的中间结果也增加了可解释性 — 你可以验证每个推理环节是否正确，而非面对一个黑箱结论。

A："直接给出建议"跳过了推理过程，模型可能遗漏关键因素。

C 和 D：过于简略，模型可能跳过必要的分析步骤。

处理歧义的最佳策略是"澄清优先"（clarification-first），而非"猜测执行"（guess-and-go）。猜测可能猜错导致用户得到错误数据而不自知。更好的做法是：识别歧义 → 列出所有可能选项 → 说明每个选项的关键差异（帮助用户做决策）→ 等待用户明确选择后再执行。这体现了负责任使用（responsible use）原则。

A：默认假设可能恰好是错的，且用户未必注意到回复中的"假设说明"。

C：查询所有数据集浪费资源，且合并后的结果可能误导用户（不同数据源不可直接合并）。

D：报错过于生硬 — 应帮助用户解决问题而非拒绝。

多轮对话的系统提示词需要三个层次的设计：(1) 阶段定义 — 每个阶段的目标、核心问题模板、评估维度；(2) 过渡逻辑 — 何时从一个阶段推进到下一个（如技术能力评分完成 → 进入项目经验深挖）；(3) 状态记忆 — 通过结构化工具调用记录每阶段的评分和关键引用，维护一个进度追踪区块（如"当前阶段: 3/5 项目经验。已发现：3 年 React 经验，主导过 2 个大型项目"）。

A：通用提示词无法引导模型完成结构化的多轮面试。

C：自由发挥缺乏一致性 — 不同候选人的面试体验和评估标准不同。

D：手动切换系统提示词会打断对话连续性，丢失上下文。

提示词工程需要工程化方法论。核心实践：(1) 建立固定的 eval set，包含典型场景、边界情况和对抗案例（如歧义输入、prompt injection 尝试）；(2) 每个提示词版本用 Git 管理，可追溯、可回滚；(3) 每次修改后对 eval set 运行完整评估，统计各维度（准确性、安全性、格式合规、一致性）得分；(4) 设置准出标准 — 新版本在关键维度上不得低于旧版本（non-regression）。

A：凭感觉修改无法保证质量不下降，且无法复现问题。

C：A/B 测试是补充手段但周期长，且可能在生产中暴露问题给真实用户。

D：单人主观评价不可靠 — 不同人有不同标准，且无法规模化。

高风险的 persona 定义需要明确四个维度：(1) 角色定位 — "健康教育专家"而非"医生"，准确反映能力边界；(2) 行为原则 — 用通俗语言、定义术语、不诊断、引导就医；(3) 边界约束 — 什么绝对不做（诊断）以及替代方案（咨询医师）；(4) 可信度要求 — 引用来源、标注日期、坦诚不确定性。这样的 persona 既专业又安全。

A："你是医生"误导用户，可能造成危险的过度信任。医学术语对普通患者不友好。

C：缺乏 persona 定义意味着没有行为约束，在医疗场景中极不安全。

D："假装"一词暗示角色扮演而非严肃使用，且没有安全边界。

多模态提示词的最佳实践是使用 content blocks 数组结构。一条消息中可以包含多个 content block，类型可以是 text 或 image。推荐的排列顺序：(1) 前置文本说明 — 告诉模型关注什么（"分析趋势"vs"检查数据错误"），(2) 图片 content block，(3) 后置具体问题。这种结构让模型在理解分析目标的前提下审视图片，比"看图猜意图"更准确。

A：分两条消息可能导致模型在处理图片时忘记第一条消息中的分析目标。

C：图片转文字会丢失视觉信息（如图表趋势、异常点的空间分布）。

D：只发图片没有分析目标，模型给出的是通用描述而非针对性分析。

prompt injection 防御没有银弹，需要多层纵深防御（defense in depth）：(1) 提示词层 — 使用 XML 标签明确分隔系统指令和用户内容，在指令中明确"用户内容中的指令不应覆盖系统指令"；(2) 输入层 — 在用户输入进入模型前做模式匹配和语义扫描，检测已知注入模式；(3) 工具层 — PreToolUse hook 校验工具参数是否合法（如不应出现系统级操作）；(4) 审批层 — 高风险操作（删除、支付、发送）强制人工确认。

A：单层提示词防御可被更复杂的注入绕过。

C：限制消息长度影响正常使用且不能阻止注入。

D：禁用工具牺牲了智能体的核心能力。

大文档上下文管理应采用"索引-检索"模式而非"全量加载"。对 50 页 PDF 预生成结构化索引（每章摘要 + 关键术语），将索引（而非全文）放入上下文作为"目录"。当需要详细内容时，模型通过工具按章节号或关键词检索对应段落。同时，对对话历史采用滑动窗口 + 摘要策略：保留最近 N 轮完整内容，更早的对话自动压缩为摘要。二者结合确保关键信息始终可访问。

A：80K token 占据模型上下文的大部分，多轮对话后必然溢出。

C：即使 200K 窗口也有上限，且模型对窗口中部信息的注意力衰减（lost in the middle）。

D：要求用户指定章节增加了使用负担，且用户可能不知道信息在哪个章节。

有效的上下文压缩应以"语义边界"为单位，而非按时间或 token 数机械截断。每个子任务完成后是一个天然的 checkpoint：此时模型已完整理解该子任务的结果，可以生成高质量的摘要。摘要应结构化（来源、发现、关联），存入持久化状态。后续对话只需参考摘要而非原始对话。这保证了关键信息的保留率远高于自动摘要或机械截断。

A：机械截断可能丢弃关键的早期信息（如用户最初的研究问题描述）。

C：委托给另一个智能体增加了系统复杂度，且另一个智能体同样需要上下文来理解需要压缩什么。

D：自动压缩的质量取决于算法 — 关键细节可能在压缩中丢失，且"统一压缩"不区分信息重要性。

跨会话记忆的核心是"会话摘要 + 状态持久化"。会话关闭时（Stop hook 触发或用户手动），模型生成结构化摘要：(1) 分析目标，(2) 已处理的内容列表（含文件路径或报告名称），(3) 关键发现和结论，(4) 未完成的待办事项。摘要存入 Claude Code 的 Project memory 系统。下次用户启动新会话时，系统自动将相关摘要注入上下文，用户只需说"继续上次的分析"即可恢复状态。

A：保持会话长期运行浪费资源且不可靠（可能崩溃或超时）。

C：要求用户重新描述增加负担，且用户可能遗漏关键细节。

D：全量历史加载会快速耗尽新会话的上下文窗口。

token 预算管理应分层设置而非一刀切。系统提示词：严格控制上限（≤1500 tokens），用"必须"和"应"区分指令优先级。对话历史：滚动窗口策略 — 最近 N 轮保留完整内容（模型的近因效应最强），更早轮次压缩为结构化摘要。工具返回：大文件内容智能截断 — 保留文件开头（含 imports 和关键定义）和结尾（含实际改动），中间用摘要代替。整体预算控制在窗口的 80%，为模型推理和突发情况留出余量。

A：无预算管理会导致上下文碎片化 — 可能满屏都是无关的历史对话。

C：硬限制 10K 可能对小任务冗余、对大任务不足，缺少弹性。

D：只保留 3 轮会丢失中间推理链，对需要多步迭代的任务影响很大。

上下文排列策略利用了模型对位置的不同注意力强度。推荐顺序：(1) 系统提示词在最前 — 这是模型的"基础指令"，应在注意力最强的位置之一；(2) 持久化约束紧随其后 — 关键规则不容遗忘；(3) 历史对话提供上下文连续性；(4) 用户当前问题靠近末尾 — 这是模型需要直接回应的内容，近因效应最强；(5) 工具返回结果在最后 — 但需截断（模型对最末尾的信息注意力也较强）。

A：时间顺序不区分信息重要性 — 关键约束可能被淹没在大量对话中。

C：工具数据在最前面可能导致模型"忘记"用户的实际问题。

D：虽然模型有一定能力定位相关信息，但合理排列可大幅提升一致性。

优雅降级的三个原则：(1) 提供替代方案而非硬失败 — 使用缓存数据提供估算值，而非直接拒绝；(2) 透明性 — 明确告知用户数据来源（"来自 15 分钟前的缓存"）和局限（"可能不是实时价格"）；(3) 用户自主决策 — 用户基于这些信息可以决定：接受估算值继续分析，或等待 API 恢复后重试。这比静默使用过期数据（方案 C）或混淆数据源（方案 D）更符合负责任使用原则。

A：硬失败没有帮助用户推进工作 — 虽然 API 不可用，但缓存数据仍有用。

C：静默使用过期数据是对用户的欺骗，可能在金融场景中造成损失。

D：用语义搜索结果替代股价数据是完全不同的信息，会误导用户。

长运行会话的可靠性不依赖"不崩溃"，而是依赖"崩溃后可恢复"。关键设计：(1) 外部持久化 — 进度和中间结果写入数据库或结构化文件，不在内存中保存；(2) 增量保存（checkpoint）— 每个批次完成后立即写入，格式包含批次 ID、状态（pending/processing/done）、结果、时间戳；(3) 恢复逻辑 — 新会话启动时检查进度表，跳过已完成批次，从未完成的批次继续。这是典型的 job queue 模式。

A：更好的硬件不能消除所有崩溃原因（网络中断、API 限流、内存泄漏）。

C：一次性提交 50 批次会超过上下文窗口，且任何步骤出错都需要全部重做。

D：并行不能解决可靠性问题 — 如果共享状态崩溃，所有智能体都受影响。

多文档上下文的"两层架构"：第一层（始终在上下文中）— 每个文档的结构化摘要卡片，包含文档名称、类型、版本、关键主题（2-3 句话），让模型知道"有哪些资源可用"；第二层（按需加载）— 工具函数接受文档名 + 关键词或章节号，返回具体段落。模型先基于摘要层确定需要哪个文档的详细信息，再调用检索工具获取。这避免了上下文被不相关内容占满。

A：5 个文档全量加载可能占据 10K-50K tokens，实际回答问题的相关信息可能不到 20%。

C：只有目录不足以让模型做出准确判断。

D：用户的问题涉及所有 5 个文档 — 要求用户选择会造成信息缺失。