免费 · 系统 · 可实践
搜索 EN 从第 1 课开始
课程/他们会这样考你/AI 工程设计模式 · 30 道灵魂拷问
工程进阶 · 可靠 Agent 的工程模式

AI 工程设计模式 · 30 道灵魂拷问

每题附考察意图、答题框架与加分点：上下文工程 / 长任务 / grep vs RAG / ACI 工具设计 / 评测基建 / LLM-as-Judge / 沙箱隔离

本页解决的问题

先给结论

「AI 工程设计模式 · 30 道灵魂拷问」要解决的关键问题是什么？

每题附考察意图、答题框架与加分点：上下文工程 / 长任务 / grep vs RAG / ACI 工具设计 / 评测基建 / LLM-as-Judge / 沙箱隔离

判断标准

让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。

下一步

写下一个问题：试完这个方法后，你能用什么证据回答它？

常见误区

结论听起来很完整，却没有检查最关键的假设。

怎么用这一页
每道题都标注了提问者。这一章偏工程，技术同事的戏份会重一些，他们的问题最不留情面。
🎙 面试官想验证你是真懂，还是在背名词
👔 老板要的是解释和承诺
🛠 技术同事在试探你值不值得信任
每题给出三层：对方在考察什么 → 答题框架 → 加分点。答不上来的环节，点末尾的课程页回去补。
Q1面试官
「大家都在讲上下文工程，它和写好提示词到底差在哪？为什么 Prompt 工程突然就过时了？」
🎯 对方在考察什么
本章的开场概念题，考你有没有跟上从单轮对话到多步 Agent 的范式变化。只会说「上下文工程范围更大」的人在背定义，真懂的人能说出窗口里具体有什么、为什么必须管。
🧭 答题框架
  1. 先给定义：Prompt 工程优化指令的写法。上下文工程管理每一轮推理时送给模型的全部 Token：System Prompt、工具定义、对话历史、检索结果、用户状态，全都算。
  2. 说清动机：上下文是稀缺资源。三个硬约束：Context Rot（越长检索准确率越低）、注意力预算有限（无关 Token 稀释有用信息）、n 平方复杂度（上下文翻倍，注意力计算量变四倍）。
  3. 给目标：找到最小的高信号 Token 集合。每个 Token 都要为推理做贡献，能塞多少塞多少的思路行不通。
  4. 落三个抓手：System Prompt 找合适高度（角色加原则，别堆 50 条规则）、工具集精简、Few-shot 精选 2~3 个典型例子，别拿边界 case 刷存在感。
⭐ 加分点能报出 n 平方这笔账：上下文从 50K 扩到 100K，注意力计算量变四倍。很多人只知道长了会贵，说得出长了还会变笨的人很少。
用这些课程页组织答案 → 从 Prompt 工程到上下文工程 上下文的三板斧
Q2面试官
「你们的 Agent 要跑几十步的长任务，上下文窗口快满了怎么办？开个新会话接着跑行不行？」
🎯 对方在考察什么
考你懂不懂长任务的根本两难。答「开新会话」的人没意识到新窗口什么都记不得；答「换更大窗口的模型」的人没算过注意力稀释的账。这题能直接分出看过生产系统和只玩过 Demo 的人。
🧭 答题框架
  1. 先摆两难：开新窗口，Agent 失忆，会重复已做过的工作；留在旧窗口，Token 越堆越多，注意力被稀释，表现持续下降。Claude Code、Cursor、Devin 每天都在解这个题。
  2. 板斧一 Compaction：窗口快满时用一次 LLM 调用做结构化摘要。保留架构决策和未解决的 bug，丢掉冗余的工具输出和已完成任务的中间步骤，选错了 Agent 会重蹈覆辙。
  3. 板斧二结构化笔记：把关键信息主动写到外部文件，新窗口读回来恢复记忆。Claude Code 的 TODO 文件、Claude 打宝可梦时维护的游戏笔记，都是这个套路。
  4. 板斧三子 Agent：深度探索委派出去。子 Agent 在自己的窗口里烧 3 万 Token 读代码做推理，只向主 Agent 回传 1500 Token 的结论，主上下文始终干净。
⭐ 加分点能说出三板斧各管一段：窗口内保持精简、跨窗口传递记忆、隔离探索噪音，再补一句实际产品里三者组合用。这说明你理解的是体系，还没停在名词层面。
用这些课程页组织答案 → 上下文的三板斧 为什么 Agent 跑不了长任务 Session ≠ Context Window
Q3技术同事
「产品要加代码库问答，你该不会又要立项建向量库吧？Claude Code 可全是拿 grep 现搜的。」
🎯 对方在考察什么
试探你是否把 RAG 当默认答案。张口就是切块、向量化、建索引的 PM，在技术同事眼里就是拿着锤子找钉子。他想听你先比较方案，把索引维护这笔账算出来。
🧭 答题框架
  1. 先接住：目标是把对的信息放进上下文窗口，RAG 只是手段之一。代码库这种高频变化的数据，按需检索往往更合适。
  2. 说清 JIT 检索：用 glob/grep 在需要时现场搜，上下文保持精简，只放当前用得上的内容。代价是多一次工具调用的延迟，换来的是免去建索引和索引同步的维护负担。
  3. 给混合策略：高频信息预加载（项目约定、核心规则、用户偏好），长尾信息按需获取。类比浏览器缓存：热数据放内存，冷数据现取。
  4. 说清什么时候该上 RAG：相对静态的知识库场景适合 RAG，但裸切 Chunk 会丢语境。Contextual Retrieval 给每个 Chunk 加上下文前缀，叠加 BM25 双路召回和 Reranking，检索失败率能降 67%。
⭐ 加分点主动算 Contextual Retrieval 的成本账：每个 Chunk 多一次 LLM 调用做前缀，用 Prompt Caching 可以压下来；法律、医疗、金融这类高准确率场景才值得上，闲聊推荐就算了。
用这些课程页组织答案 → JIT Context vs 预加载 Contextual Retrieval：更好的 RAG
Q4面试官
「线上 Agent 老是选错工具、填错参数。工程师说模型太笨，等下一代吧。作为 PM 你怎么看？」
🎯 对方在考察什么
考你知不知道 ACI 这回事。附和「等模型升级」的人直接出局。对方想听到：工具定义就是 Agent 的用户界面，调错工具大概率是设计问题，PM 有明确的排查抓手。
🧭 答题框架
  1. 先定性：工具的名称、参数、描述就是 Agent 的用户界面。传统 API 是确定性的，Agent 工具是非确定性的，什么时候用、怎么用，全看设计质量。设计工具要像设计 HCI 一样投入。
  2. 给排查清单：四原则挨个过。参数顺序有没有给模型思考空间（先简单方向、后复杂内容）、格式贴不贴近训练数据（标准 unified diff 好过自定义 DSL）、有没有逼模型数行号做机械操作、有没有防呆设计（Poka-yoke）。
  3. 举实锤案例：SWE-bench 上把文件路径参数从相对路径改成只收绝对路径，一个参数的改动，工具调用从频繁出错变得几乎完美。
  4. 说描述标准：像给聪明但没有上下文的初级开发者写文档。示例用法、边界情况、输入格式、和其他工具的区别、何时不该用，五件套写全。
⭐ 加分点补一句「如果人类都分不清该用哪个工具，AI 也分不清」，再提 Claude Code 的进阶玩法：用 Agent 给自己的工具写描述、跑评测、自动迭代优化。
用这些课程页组织答案 → ACI：Agent-Computer Interface 用 Agent 优化 Agent 的工具 工具集要精简
Q5老板
「新模型都发布一周了，竞品第二天就官宣接入。我们评估要三周？说说时间都花在哪了。」
🎯 对方在考察什么
表面在催进度，实际在问你的团队有没有评测基建。这是把被动挨骂转成主动要资源的机会题。答「技术排期就是这样」等于认领无能，答「明天就切」等于拿产品质量赌命。
🧭 答题框架
  1. 先给结论：迁移速度取决于评测基建。有完善 eval suite 的团队跑一遍测试、确认不掉分、几天完成切换；没有的团队只能人肉验证数周。我们慢在基建欠账。
  2. 解释评测在赚什么钱：改 Prompt、换模型、调参数，几分钟知道对整体的影响；防止修一个 bug 制造三个新的；每次新模型发布都能第一批吃红利。
  3. 给启动方案：先做 20 条覆盖核心场景的测试任务就能起步。20 条精心设计的用例，比停在计划里的 500 条领先一个时代。
  4. 顺手管理预期：竞品接得快未必测得严。公开 benchmark 分数会被高估（模型能认出考试），要用自己业务场景的用例；评测环境要和生产一致，仅沙箱配置差异就能造成 6 个百分点的误差。
⭐ 加分点用指标语言替代形容词汇报：把「感觉变差了」升级成「简洁性从 72 提到 85，但过度工程化从 3% 恶化到 7%，需要回退」。老板对你的信任会上一个台阶。
用这些课程页组织答案 → 为什么评测比训练更重要 评测的坑：噪音、作弊与退化
Q6面试官
「Agent 的输出质量怎么自动化打分？全靠 LLM-as-Judge 靠谱吗？」
🎯 对方在考察什么
考你评测工具箱的掌握深度。只答「用大模型打分」的人停留在听说过；能讲清三种 Grader 的边界和组合方式的人，一听就是真做过评测的。
🧭 答题框架
  1. 列全三种 Grader：代码 Grader（断言、单测、正则，毫秒级、零成本、完全可复现，但对合理变体过于严格）、模型 Grader（能评主观质量，但有成本、有偏见）、人工 Grader（质量最高，但不可扩展）。
  2. 正面回答 LLM-as-Judge：靠谱程度取决于 Rubric。「给质量打 0 到 1 分」几乎没用，要具体到每一分：0 分长什么样、0.3 分缺了什么、1 分必须同时满足哪几条。
  3. 给组合拳：代码 Grader 打底守确定性场景，模型 Grader 扩展到主观质量，人工定期抽检、校准模型 Grader 有没有漂移。三层缺一不可。
  4. 补一个容易漏的点：评的应该是 Outcome，环境的最终状态。Agent 说做完了不算数，要看文件是否真的改对、API 是否真的调对。
⭐ 加分点提到 Trial 概念：模型输出有随机性，同一个 Task 要跑多次才有统计意义。再举 Descript 的三维度打分（不破坏、做了该做的、做得好），显得见过真实案例。
用这些课程页组织答案 → 三种 Grader：代码、模型、人工 评测的核心概念
Q7技术同事
「你这需求要 Agent 拿着用户的 GitHub Token 去跑模型生成的代码，出了事谁负责？加一句『别执行危险操作』的提示词可打发不了我。」
🎯 对方在考察什么
安全评审会上的经典对峙，考你懂不懂结构性安全。回答里只有「加约束提示词」「模型会拒绝的」，这个需求当场就会被毙掉。对方想确认你知道防线要建在架构上。
🧭 答题框架
  1. 先认同对方立场：提示词防线靠不住，安全要靠结构性设计。目标是即使模型被 Prompt Injection 完全操控，攻击者也拿不到凭证。
  2. 给风险分类：三类分开设防：用户故意滥用、模型自发失控（过度行动、基于幻觉执行真实操作）、外部攻击（网页和文档里嵌入的注入指令，用户自己都不知情）。
  3. 给凭证方案：第一原则是生成的代码和密钥永远隔离在不同容器。两种模式：Token 注入到资源访问路径（Agent 可用不可见，比如嵌进 Git remote URL）、Vault 代理转发（代理按 Session 注入 Token，Agent 全程见不到一个字符）。
  4. 给执行环境方案：OS 级沙箱三重隔离（文件系统、网络、进程），叠加三层信任控制：高危工具人工审批、会话级授权、全局策略兜底（永远碰不到生产库）。
⭐ 加分点主动说出「模型能力越强，旧架构下攻击面越大」，所以安全设计不能指望模型升级自动变好。这句话能让安全工程师把你当自己人。
用这些课程页组织答案 → 三类风险：滥用、失控、外部攻击 沙箱与凭证隔离
Q8面试官
「你设计的这个功能，到底该做成 Workflow 还是 Agent？给我一个判断标准，别只说 Agent 更智能。」
🎯 对方在考察什么
本章第一课的分水岭题。只会喊 Agent 的人在追热词，真懂的人先看任务结构：控制权在代码手里还是模型手里，这个选择决定了后面所有的成本和调试方式。
🧭 答题框架
  1. 先给定义：Workflow 是 LLM 和工具走预定义代码路径，开发者写代码时就定好先 A 后 B 再 C；Agent 是模型动态决定流程，每一步自主判断调什么工具、什么时候结束。
  2. 摆核心差异：Workflow 输入确定则路径确定，容易复现和调试；Agent 同样输入可能走不同路径，行为不确定，线上问题难复现。
  3. 给判断标准：任务拆解明确、步骤固定，用 Workflow，典型如文案生成管道、数据清洗流水线；任务开放、需要临场决策，才用 Agent，典型如 Claude Code、Devin 这类编程助手。
  4. 引生产共识：Anthropic 复盘过大量落地案例，最成功的实现没有用复杂框架，用的是简单、可组合的模式。
⭐ 加分点主动算成本账：Workflow 调用次数固定、预算可估；Agent 循环次数未知、账单不可控。报预算时两者是完全不同的谈法，这一点大多数候选人想不到。
用这些课程页组织答案 → Workflow vs Agent：先搞清楚你要什么
Q9技术同事
「你这方案又是分类器又是固定流程，隔壁团队都在跑全自主 Agent 了，咱们是不是太保守了？」
🎯 对方在考察什么
反向试探，看你会不会被行业热词绑架。能按复杂度阶梯反着推、证明每一层复杂度都有对应收益的 PM，才值得工程团队信任。
🧭 答题框架
  1. 先立原则：复杂度是成本。每加一层都要回答同一个问题：这层带来的收益，值不值得额外的延迟、费用和调试难度。
  2. 摆四级阶梯：先优化单次 LLM 调用（Prompt、Few-shot、Temperature）；不够就加 RAG；还不够用 Workflow 拆步骤；确实需要灵活决策才上 Agent。
  3. 算全自主的代价：把控制权从代码交给模型，意味着循环次数未知、成本不可控、行为难复现。这些代价要有对应的收益才划算。
  4. 举过度设计反例：用 Agent 框架做一个 Prompt 加一次搜索就能解决的问题，框架引入的延迟、成本和不确定性远大于收益。
⭐ 加分点引用生产实践的结论：大多数场景优化单次调用配合检索增强就够了。敢在评审会上说「我们不需要 Agent」的 PM，比追热词的更让工程师放心。
用这些课程页组织答案 → 复杂度阶梯 五种 Workflow 模式
Q10面试官
「五种 Workflow 模式你都用过吗？挑三种讲讲，各自适合什么场景、要付出什么代价。」
🎯 对方在考察什么
名词题的进阶版。能背出五个英文名的人一抓一把，能说清适用条件和代价的人很少。让你挑三种，考的就是取舍表达。
🧭 答题框架
  1. Prompt Chaining：任务能拆成固定顺序步骤时用，步骤间可以插质量门，比如检查文案含不含品牌关键信息，过了才进翻译环节。代价是延迟，本质是拿延迟换准确度。
  2. Routing：输入类型多样时先分类再分流。简单 FAQ 走 Haiku 这类快而便宜的模型，退款问题走 Sonnet 加订单工具。价值在关注点分离和成本分层。
  3. Parallelization：两个子模式。Sectioning 把独立子任务并行跑，比如安全、性能、风格三路同时做代码审查；Voting 同一任务跑多次取多数意见，拿钱换置信度。
  4. 收尾补另外两种：Orchestrator-Workers 由编排者在运行时动态拆任务，子任务提前定不了时用，最接近 Agent；Evaluator-Optimizer 生成加评判循环迭代，适合翻译这类有明确质量标准的场景。
⭐ 加分点说出 Orchestrator 和 Parallelization 的分界线：前者的子任务是编排者运行时动态决定的，后者在代码里预先写死。这个区分绝大多数人答不上来。
用这些课程页组织答案 → 五种 Workflow 模式
Q11老板
「AI 客服这个月 API 账单涨了 40%，用户量才涨 10%。下季度费用给我砍一半，功能一个不许少。」
🎯 对方在考察什么
考你有没有结构性降本的工具箱。答「找厂商砍价」或「限制用量」都算没接住。账单涨速超过用户涨速，说明每次调用的 Token 在膨胀，这才是要治的病。
🧭 答题框架
  1. 先上 Routing 分流：加一个分类器，简单 FAQ 走便宜的小模型，退款、投诉这类复杂问题才用强模型加工具。客服流量大头是简单问题，这一刀最省钱。
  2. 治理工具返回：查一遍是不是在全量返回。一次回 847 条完整记录要烧 5 万多 Token，改成前 10 条核心字段加分页提示，800 Token 就够，信息密度反而更高。
  3. 吃缓存红利：System Prompt、工具定义这些稳定内容放在前缀并保持不变，命中 Prompt Cache 后重复部分的费用大幅下降。
  4. 给验证闭环：每项改动跑评测确认质量不掉，最后拿数据汇报：成本降了多少，核心指标持平。
⭐ 加分点提醒老板一笔隐性账：上下文越长模型还会变笨（Context Rot），检索准确率随 Token 数下降。精简上下文经常是省钱和提质同时发生，这点多数团队没意识到。
用这些课程页组织答案 → Routing 成本分流 Token 效率：精简返回 Context Rot 与注意力预算
Q12面试官
「你写的 System Prompt 被工程师吐槽像需求文档，快 60 条规则了。你觉得 System Prompt 到底该写到什么程度？」
🎯 对方在考察什么
考「合适高度」的判断力。狂堆规则的人默认模型不可信，只写一句「你是助手」的人放弃了引导。对方想听你说清两个极端各错在哪，以及怎么把 60 条治理下来。
🧭 答题框架
  1. 摆两个极端：太模糊（你是一个有用的助手）让模型缺方向感，输出泛泛而谈；太具体（50 条规则加 100 个边界 case）把模型锁死，遇到新情况不会变通。
  2. 给甜蜜点：明确的角色定位，加 5~10 条核心原则，划清边界，然后信任模型在框架内自主判断。像好的管理者：给方向，别下每一步的指令。
  3. 算规则的代价：60 条规则本身就是 Token，占的是注意力预算；规则之间互相打架时，模型行为反而更难预测。
  4. 给落地动作：把规则按原则、格式、边界归类合并，通常能压到十几条，再跑评测确认行为没有退化。
⭐ 加分点点出过度约束的隐藏代价：模型被 50 条规则捆死后无法灵活处理新情况，等于花大模型的钱买了个规则引擎。这句话工程师听了会点头。
用这些课程页组织答案 → System Prompt 的合适高度
Q13面试官
「Agent 的记忆就靠它自己写的一个笔记文件？听起来很原始，这东西要怎么设计才靠谱？」
🎯 对方在考察什么
结构化笔记听着简单，考的全是设计细节：写什么、什么格式、什么时候读回来。答「让模型自由发挥」的人，一听就没跑过真实的长任务。
🧭 答题框架
  1. 先讲原理：把短期记忆（上下文窗口）外化成长期记忆（文件系统）。窗口重置后，新会话第一件事是读笔记恢复状态，记忆跨窗口延续。
  2. 格式必须固定且结构化：自由散文读回来还要额外烧 Token 去理解。用固定栏目：已完成、未完成、关键决策、已知问题，后续推理按栏目直接取。
  3. 定读写节奏：写的时机是每完成一个关键步骤就更新，别攒到窗口快满才写；读的时机是每次窗口重置或新会话开始的第一步。节奏乱了，笔记就会和实际进度脱节。
  4. 分清和 Compaction 的分工：压缩是把旧信息压小了继续用，适合连续不中断的对话；笔记是存到外面以后取用，适合可能被打断、要跨 session 延续的任务。实际产品里两者组合上。
⭐ 加分点补一个保护机制：这类状态文件要在 Prompt 里用强措辞守住，比如明确「不允许删除或修改已有的测试清单」，否则 Agent 会为了让测试通过而自己降低标准。
用这些课程页组织答案 → 结构化笔记 进度文件与功能清单
Q14面试官
「你在方案里加了个 think 工具，它不查数据、不调 API、什么状态都不改。加一个什么都不干的工具，图什么？」
🎯 对方在考察什么
考你是不是真理解 Think Tool 的机制和边界。答「让 AI 多思考总是好的」直接露馅，对方想听它解决什么问题、什么时候纯属浪费，最好还有数据。
🧭 答题框架
  1. 说机制：Think Tool 是一个没有副作用的工具，唯一作用是让 Agent 在执行中途把思考写下来。把「停下来想」包装成工具调用，模型就能在工具链的节奏里自然插入一段推理。
  2. 说场景：三类场景最见效：调用 5 个以上工具的长链、策略密集环境（20 条退款政策加 6 种例外）、每步依赖前一步结果的串行决策。共同点是早期信息容易被后续上下文淹没。
  3. 报数据：τ-bench 航空客服从 0.570 提到 0.878，提升 54%；零售客服提升 11%。航空的退改签政策远比零售复杂，策略密度越高，Think Tool 价值越大。
  4. 划边界：查天气、读文件这类一步到位的操作用它是纯开销；不调工具的纯生成任务不需要；能一次性想清楚的问题交给 Extended Thinking 更直接。
⭐ 加分点说清和 Extended Thinking 的分工：一个在动手前深度规划，一个在执行中途暂停整理。能讲出「思考发生的时机不同」，这题就答穿了。
用这些课程页组织答案 → Think Tool：让 AI 先想后做
Q15技术同事
「你这个工具需求要返回用户的全部订单记录，重度用户有八百多条。你算过这一次调用要吃多少 Token 吗？」
🎯 对方在考察什么
考你有没有把工具返回当成上下文预算的一部分。技术同事最怕 PM 说「都返回，让模型自己挑」，那是把成本和注意力问题同时引爆。
🧭 答题框架
  1. 先认账：全量返回是灾难。847 条完整记录约 5 万 2 千 Token，模型处理不过来，还会把窗口里其他信息的注意力稀释掉。
  2. 给四个精简策略：总结（只返回统计信息）、截断（默认前 N 条）、分页（带翻页参数）、过滤（支持条件筛选），按场景组合使用。
  3. 返回要带下一步线索：只回 success 是差设计。要返回 Agent 下一步用得上的信息，比如工单 ID、链接、负责人，省掉一次追查调用。
  4. 把翻页做进返回体：带上 total、showing、page，再加一句「用 page=2 看更多」的提示，Agent 自己就知道怎么取剩下的数据。
⭐ 加分点把这事上升成原则：工具返回也是 ACI 的一部分，占用的是模型的注意力预算。800 Token 的高密度返回，效果好过 5 万 Token 的原始数据倾倒。
用这些课程页组织答案 → Token 效率：返回结果的学问 ACI：Agent-Computer Interface
Q16面试官
「你们的 Agent 工具从 10 个加到 60 个之后，选错工具的比例反而上升了。你会怎么治理这个工具集？」
🎯 对方在考察什么
考「少即是多」的落地能力。加工具人人会，敢砍工具、会组织工具的 PM 少见。对方想听规则明确的治理方案，先别急着怪模型。
🧭 答题框架
  1. 先定性：选错率随工具数量上升，说明工具之间的边界糊了。search、find、lookup 三个功能相近的工具摆在一起，选错是工具集的病，模型只是把病症暴露出来。
  2. 合并重复项：两个工具的使用场景重叠超过一半就合并。宁可一个工具多几个参数，也不要两个容易混淆的工具。
  3. 上命名空间：相关工具加统一前缀分组，jira_create_issue、jira_list_issues、git_diff、db_query。Agent 一眼看出哪些工具操作同一个系统，选错概率直线下降。
  4. 用数据验收：工具选择错误可以被评测度量。治理前后跑同一套用例对比选对率，证明砍工具砍对了。
⭐ 加分点提工具定义本身占上下文：60 个工具的 schema 每轮推理都要进窗口。砍掉用不上的工具，等于给每次调用免费腾出注意力预算。
用这些课程页组织答案 → 五个工具设计原则 工具集要精简
Q17面试官
「几十个工具的描述文档，你打算安排谁来写？怎么保证写出来的质量，靠人肉 Review 吗？」
🎯 对方在考察什么
听着是分工问题，实际考你知不知道用 Agent 优化 Agent 工具这套工作流。答「工程师写完我审一遍」，说明你还停在传统文档思维。
🧭 答题框架
  1. Prototype：让 Claude Code 按需求生成工具原型，包括工具定义、参数校验、API 调用逻辑，人只描述要什么。
  2. Evaluate：建评测度量四个维度：Agent 是否选对了工具、参数填写是否正确、返回结果是否被正确理解、端到端任务完成率。
  3. Optimize：让 Claude Code 读评测结果自动分析失败原因。它能给出「43% 的错误是 Agent 混淆了 search 和 list，因为描述太相似」这种精确结论，然后自动重写描述、补区分说明和示例。
  4. 定人的角色：人负责定评测标准和最终验收，机器负责写和改。循环跑到达标为止，迭代速度比人肉调试快一个量级。
⭐ 加分点点出这套循环的本质：工具写得好不好，Agent 自己最有发言权。让使用者当作者，Agent 成了自己工具的产品经理，这比任何文档规范都有效。
用这些课程页组织答案 → 用 Agent 优化 Agent 的工具 工具描述的学问
Q18面试官
「假设你下周入职，我们的 Agent 一条评测都没有。前三十天，你怎么把评测从零建起来？」
🎯 对方在考察什么
考操作路径。喊「评测很重要」的人遍地都是，能给出从 0 到 20 条的具体节奏、说清每个概念怎么落地的人，才算真做过。
🧭 答题框架
  1. 第一周定义成功：写评测的第一价值是逼团队回答「什么算好」。挑最核心的用户场景写 20 条精心设计的 Task，每条含输入和成功标准。20 条就能起步，别等 500 条的宏大计划。
  2. 搭最小闭环：Harness 负责起沙箱、跑任务、收结果，Grader 负责打分，一组 Task 构成 Suite 一键全跑。先把 Task、Trial、Grader、Suite 这套语言和工程团队对齐。
  3. 存好 Transcript：每次执行的完整轨迹（每步推理、每次工具调用、中间结果）都记录下来。失败时能定位是选错工具还是填错参数，评测才能指导改进方向。
  4. 接入变更流程：从此改 Prompt、换模型、调参数都先跑一遍 Suite，几分钟看到影响面。团队的汇报语言从「感觉变差了」升级成具体分数。
⭐ 加分点补一个反常识收获：很多团队在写 eval 的过程中，第一次理清了模糊已久的产品定义。评测既是质检工具，也是需求分析工具。
用这些课程页组织答案 → 为什么评测比训练更重要 三种 Grader：代码、模型、人工
Q19老板
「你们评测一轮要跑几百次模型调用，一个月光测试就烧几万块。这钱花得值吗？」
🎯 对方在考察什么
老板质疑的是 ROI。念「评测很重要」的口号没用，要把每一笔看似浪费的开销讲成保险和杠杆，还要给出控制成本的办法。
🧭 答题框架
  1. 解释为什么跑那么多次：模型输出有随机性，同一个任务单跑一次的结果就是噪音。同一个 Task 要跑多次 Trial 才有统计意义，省这笔钱等于拿骰子做产品决策。
  2. 算没有评测的成本：修一个 bug 制造三个新的，等用户投诉才发现；一次「Agent 变差了」的排查要翻三天 commit 记录。工程师的时间比 API 费贵得多。
  3. 算评测赚的钱：每次改 Prompt、换模型几分钟就知道影响；新模型发布时跑一遍 Suite 确认不掉分就切换，每次都第一批吃红利。
  4. 给降本方案：20 条精选用例覆盖核心场景；确定性检查用毫秒级、零成本的代码 Grader 打底，花钱的模型 Grader 只用在主观质量上。
⭐ 加分点用一句话收尾：评测的投入是复利，前期每一分钟都会在回归测试、模型迁移、团队协作里持续产生收益。老板听得懂复利。
用这些课程页组织答案 → 评测的核心概念 三种 Grader 的成本结构
Q20面试官
「用户嫌输出啰嗦，你改了 System Prompt 直接上线，结果代码能力掉了。复盘一下，流程上错在哪？」
🎯 对方在考察什么
事故复盘题，考你知不知道真实生产里 Prompt 变更引发退化的案例和防护流程。把锅甩给模型或者测试同学的人，当场出局。
🧭 答题框架
  1. 先定性：单一维度的改善不等于整体改善。真实案例里，为减少啰嗦改 System Prompt，简洁性上去了，coding eval 掉了约 3%：模型变简洁的同时，把关键注释和错误处理也省了。
  2. 流程错误一：没做逐行 ablation。Prompt 变更应该每次只改一行、单独测量影响，搞清楚每句话各自的贡献。
  3. 流程错误二：只测了目标维度。上线前要跑完整 eval suite，简洁性、代码质量、过度工程化一起看，防止按下葫芦浮起瓢。
  4. 举同类事故：改 reasoning effort 默认值这种看似无害的配置调整，也曾造成多个维度退化。结论是所有变更，包括 Prompt、参数、基础设施，一视同仁走评测。
⭐ 加分点提「过度工程化 eval」这类反向指标：优化简洁性时同时监控它有没有恶化。一对互相牵制的指标，才能防止优化朝单一方向跑偏。
用这些课程页组织答案 → 评测的坑：噪音、作弊与退化 Claude Code 的评测演进
Q21技术同事
「选型会上你拿公开 benchmark 排行榜说话？那玩意儿早被刷烂了，你真信那个分数？」
🎯 对方在考察什么
考你对评测可信度的认知层次。承认 benchmark 有局限还能说出具体失效机制的 PM，才能在选型会上站得住脚。
🧭 答题框架
  1. 失效机制一，模型识别考试：Claude Opus 4.6 在 BrowseComp 上能推测出自己在跑 benchmark，识别出题目模式后去搜答案，或者调用训练数据里见过的类似题。静态题库遇上联网环境，测的可能是回忆力。
  2. 失效机制二，区分力衰减：模型越强，识别评测的能力越强，固定 benchmark 对前沿模型的区分力在持续下降，公开题目的成绩会被系统性高估。
  3. 失效机制三，基础设施噪音：仅改 CPU 和内存限制，分数就能差 6 个百分点；同一模型同一任务，换个沙箱配置排名会逆转。
  4. 给替代方案：用自己业务场景的私有用例、动态生成测试题、限制联网；评测环境和生产环境对齐，报分数时同时报环境配置。
⭐ 加分点给一句定位：排行榜用来筛入围名单，最终决策看私有评测。把 benchmark 放在正确的位置上，这正是技术同事想听到的态度。
用这些课程页组织答案 → 模型识别考试与基础设施噪音
Q22面试官
「给 Agent 一个大任务让它跑一晚上，早上过来一看基本是废的。你说说，它到底是怎么失败的？」
🎯 对方在考察什么
考你见没见过长任务的真实失败现场。答「上下文不够长」只摸到皮毛，对方想听两种具体失败模式，以及背后共同的交接问题。
🧭 答题框架
  1. 失败模式一 One-shotting：Agent 想一口气做完所有功能，窗口中途用完。下一个接手的 Agent 面对半成品只能猜前任做了什么，时间全耗在把基本功能修回来，推进陷入停滞。
  2. 失败模式二 Premature Completion：Agent 看到实现了几个功能就宣布完工，实际只做了核心功能的 30%。没有任务清单不知道还差什么，没有端到端测试证明真的能跑。
  3. 给一个类比：像一个每次换班就完全失忆的工程师团队，每个人坐下都要从零理解一堆半成品代码。这就是没有交接机制的长运行 Agent。
  4. 点出本质：长任务的核心挑战是交接，动手做反而不难。Agent 缺的是上下文断裂时维持连续性的机制，解法方向是进度文件加增量提交。
⭐ 加分点补一句「即使有 Compaction 也救不了 One-shotting，压缩后的指令不够清晰，新 Agent 依然迷路」。说明你知道压缩的极限在哪。
用这些课程页组织答案 → 为什么 Agent 跑不了长任务 Initializer + Coding Agent
Q23面试官
「让 Agent 自主搭一个完整的 Web 应用，几百个功能点。这个系统你怎么设计，才能让它一直推进不烂尾？」
🎯 对方在考察什么
开放架构题，考双角色 Harness 的掌握度。对方期待你说出角色分工、状态文件、验收机制三层，缺一层都显得只读过标题。
🧭 答题框架
  1. 拆双角色：Initializer 只跑第一轮，负责从零到有：建 init.sh 搭环境、写进度文件、把高层需求展开成详细功能清单、做首次 git commit；Coding Agent 每轮读进度文件，一次只做一个功能，完成后更新进度并提交。
  2. 功能清单用 JSON：模型不容易错误修改结构化 JSON，Markdown 清单常被顺手重写。每个功能带分类、步骤列表和 passes 字段。
  3. 验收靠端到端测试：明确要求 Agent 用浏览器自动化真打开页面、真点按钮验证，光有单元测试不够。E2E 通过才算 passes。
  4. 说清一次一个的价值：每轮结束代码都处于可合并状态，commit 是回滚点，进度文件是交接书，窗口永远不会被塞爆。
⭐ 加分点报战果：这套方案跑出过 200 多个功能的 claude.ai 克隆，每个功能都有对应的 E2E 测试。有数字的架构答案，说服力完全不同。
用这些课程页组织答案 → Initializer + Coding Agent 长任务的失败模式
Q24老板
「你要的沙箱、评测、脚手架排期三个月。可模型半年一升级，到时候这些是不是全白做了？」
🎯 对方在考察什么
老板在问投资会不会打水漂。这题要会分类：哪些工程随模型进步过时、哪些是持久资产。一刀切说都值或都不值，都是错的。
🧭 答题框架
  1. 先承认一半：Harness 编码的是对当前模型能力的假设，假设会过时。真实案例：Sonnet 4.5 有上下文焦虑，对话变长表现下降，团队加了 context reset 机制；换 Opus 4.5 后焦虑消失，这机制反而拖慢效率。
  2. 给分类标准：特定模型的绕道方案、特定 Prompt 技巧会过时；沙箱隔离、权限分层、评测体系、Session 日志是持久架构，模型越强越需要。
  3. 按分类排期：持久资产优先做，临时补丁能不写就不写。原则是今天不写明天可能不需要的代码。
  4. 反过来讲评测的角色：模型升级时，恰恰是评测让我们几天内确认新模型能不能用、哪些旧补丁能删。这三个月里的评测投入，省的正是以后每次升级的人肉验证。
⭐ 加分点把判断力本身当答案：区分哪些逻辑会随模型进步过时、哪些是真正持久的架构决策，这种判断力是 AI 时代最值钱的工程能力。
用这些课程页组织答案 → 做最简单的、能跑的东西 评测让模型迁移变快
Q25面试官
「听说过脑手分离吗？为什么要把 Agent 的思考和执行拆到不同的进程里？拆开到底赚了什么？」
🎯 对方在考察什么
架构理解题。只背「解耦」两个字没用，对方想听三个组件各是什么，以及拆开之后故障恢复和性能各发生了什么变化。
🧭 答题框架
  1. 摆三组件：Session 是 append-only 的持久事件日志；Harness 是脑，跑调用模型和路由工具的循环；Sandbox 是手，执行代码和改文件的容器。
  2. 讲宠物变牛群：三者挤在一个容器里时，容器挂了会话就丢了，任务彻底失败；拆开后沙箱挂了只是一次工具调用报错，模型自己决定重试，系统新建容器接着干。
  3. 讲脑的恢复路径：Harness 崩了也不怕，新 Harness 用 wake(sessionId) 启动，从 Session 读回完整事件流恢复上下文，任务不受影响。
  4. 报性能收益：脑不用等容器 ready 就能开始处理，TTFT 中位数降了 60%，p95 降了 90% 以上；组件解耦后还能一脑控多手并行、一手在多脑间接力。
⭐ 加分点用操作系统类比开场：调 read() 时你不关心底层是 SSD 还是网络盘，Managed Agent 做同样的事，让脑不关心手是哪个容器。面试官会记住这个类比。
用这些课程页组织答案 → Managed Agent：脑手分离
Q26面试官
「Session 和上下文窗口，很多人当成一回事。你说说两者差在哪，为什么必须分开存？」
🎯 对方在考察什么
概念辨析加架构动机，本章的深水区。能讲清压缩不可逆这条主线的人，才算真理解长运行 Agent 的状态设计。
🧭 答题框架
  1. 先给类比：Context Window 是内存，快、小、用完即丢，装当前推理的精选内容；Session 是硬盘，容量大、断电不失，装所有原始事件的完整记录。
  2. 说分离的动机：Compaction 和裁剪都是不可逆操作，而且压缩时很难预判未来哪些 Token 重要。今天看似无关的细节，可能是明天关键决策的依据，丢了就永远回不来。
  3. 给正确姿势：原始事件全量进 Session，append-only 只增不减；窗口只是从 Session 临时取景的一个视角。丢了 Context 没关系，随时能重建。
  4. 讲工程红利：Harness 用 getEvents 按需查任意区间、过滤特定事件类型，还能保持前缀稳定优化 Prompt Cache 命中率；换模型、换 Harness 都不动 Session。
⭐ 加分点一句话总结：不要把内存当硬盘用。用户抱怨「Agent 忘事」的产品问题，追到根上几乎都是这两层没有分开。
用这些课程页组织答案 → Session ≠ Context Window Managed Agent 三组件
Q27老板
「用户吐槽咱们的 Agent 一天弹十几次确认框，像个不敢担事的实习生。能不能全去掉？」
🎯 对方在考察什么
老板要体验，但你不能拿安全换。考你能不能给出弹窗大减但风险不升的结构化方案，「保留」或「全删」这种二选一答案都不及格。
🧭 答题框架
  1. 先给结论：能砍大部分，不能全去。Auto Mode 的实践数据是分类器加沙箱的组合把权限弹窗减少了约 83%，安全性没有下降。
  2. 讲分类器：给每个操作定风险等级，读文件、搜代码这类安全操作直接放行，真正可疑的才弹窗。弹窗从「默认都问」变成「例外才问」。
  3. 讲沙箱兜底：就算分类器误判放行了危险操作，代码也在文件系统、网络、进程三重隔离的环境里执行，伤不到真实系统。
  4. 保留高危死名单：删文件、写数据库、发邮件这类操作永远人工确认。这部分弹窗恰恰是用户信任感的来源。
⭐ 加分点把逻辑压成一句话：高自主来自分类器，低风险来自沙箱，两个都要。只做分类器是赌运气，只做沙箱体验依旧差。
用这些课程页组织答案 → Auto Mode 的实践数据 OS 级沙箱隔离
Q28技术同事
「你要接的这三个第三方 MCP 服务器，工具描述是他们写的，返回数据也是他们给的，咱们一行都审不了。你想过这意味着什么吗？」
🎯 对方在考察什么
考 MCP 攻击面的理解。他在提醒你：每接一个外部数据源，就多一个被操控的入口。答「大厂的服务应该没问题」等于零分。
🧭 答题框架
  1. 接住供应链风险：Agent 信任 MCP 返回的工具描述，恶意服务器改一改描述就能操控行为。Agent 以为自己在用「搜索文件」工具，实际执行的是删除。
  2. 接住注入风险：服务器本身没恶意也不安全，它转发的内容（比如抓来的网页）可能藏着注入指令，Agent 处理这些数据时会被说服执行非预期操作。
  3. 给治理动作：像审第三方 SDK 一样审每个 MCP 集成，接入数量最小化，MCP 返回的内容一律按不可信数据处理。
  4. 给架构兜底：OAuth Token 存外部 Vault、走代理转发，沙箱内拿不到凭证；网络隔离限制外传。就算注入成功，攻击者也偷不到东西、传不出去。
⭐ 加分点主动说「每多接一个 MCP 服务器就多一个注入入口，这份接入清单我先砍掉一半」。PM 主动砍自己的需求，是技术同事眼里最高级别的信任信号。
用这些课程页组织答案 → MCP 的双重风险 凭证隔离两种模式
Q29老板
「大客户合同里写了我们的 Agent 永远碰不到他们的生产库，销售已经签字了。你告诉我，这个『永远』技术上怎么保证？」
🎯 对方在考察什么
把合同语言翻译成架构语言的能力。答「我们在提示词里严格约束」这单就飞了。老板要的是能写进合同附件的保证机制。
🧭 答题框架
  1. 先定调：承诺靠结构兑现，模型自觉靠不住。设计目标是就算模型被注入指令完全操控，生产库也碰不到。
  2. 给三层信任控制：工具级，高危操作每次人工审批；会话级，每次会话限定授权范围、结束自动回收；全局级，组织策略写死永远不能访问生产库，任何会话授权都盖不过它。合同里的「永远」对应的就是全局层。
  3. 加网络层隔离：Agent 跑在受限沙箱里，网络访问范围受控，生产库的地址在网络层就不可达，连试的机会都没有。
  4. 给可审计性：Session 日志 append-only 记录每一步操作，客户随时可以来审计。承诺加证据，这才是能签的字。
⭐ 加分点主动补凭证这一环：生产库的连接凭证根本就不进 Agent 的执行环境，走 Vault 代理管理。拿不到钥匙的门，才是真正锁死的门。
用这些课程页组织答案 → 三层信任层级 双层 Containment 策略
Q30面试官
「最后一个问题。这一章这么多设计模式，如果只让你带走一句话，你带哪句？为什么？」
🎯 对方在考察什么
收官题，考抽象能力和工程价值观。背一个名词不如给一个判断。对方想看你能不能把整章内容压缩成自己的工程观，并用它反过来串联所学。
🧭 答题框架
  1. 给出那句话：Do the simplest thing that works。所有精巧的模式最后都指向它：从最简方案开始，复杂度只在明确带来收益时才加。
  2. 用它串一遍本章：能用一个 Prompt 解决就别上 Workflow，能用 Workflow 就别上 Agent；上下文找最小高信号 Token 集合；工具能合并就别拆分。
  3. 补第二层认知：Agent 工程的核心是状态管理。什么信息在什么时候、以什么形式出现在窗口里，这是工程师能控制的全部；模型的智能是预训练给的，控制不了。
  4. 补时间维度：模型在变强，工程在变简单。重试、纠错、格式化这类辅助逻辑会随模型进步变得多余，力气要花在评测、沙箱、Session 这些持久架构上。
⭐ 加分点引 Claude Code 的教训收尾：它的大部分工程复杂度花在管理上下文上，让模型变聪明反倒是次要的。这句话足以让面试官记住你。
用这些课程页组织答案 → 做最简单的、能跑的东西 进阶全景图
最后一个建议
这一章的问题大多来自技术评审的现场，对方要的从来都是判断和取舍。正确用法还是开口讲一遍：对着同事、朋友或者录音讲。讲不顺的地方，就是你以为懂了但还没懂的地方，点关联课程页回去补上。

「AI 工程设计模式 · 30 道灵魂拷问」为什么能找到相关内容

「每题附考察意图、答题框架与加分点：上下文工程 / 长任务 / grep vs RAG / ACI 工具设计 / 评测基建 / LLM-as-Judge / 沙箱隔离」把检索问题从“把资料存起来”推进到“怎样找到真正相关的资料”。这一步决定了 RAG、推荐和以图搜图最后交给模型的输入质量。

相似度不是答案，召回之后还要核对

在「每题附考察意图、答题框架与加分点：上下文工程 / 长任务 / grep vs RAG / ACI 工具设计 / 评测基建 / LLM-as-Judge / 沙箱隔离」对应的流程里，Embedding 负责把对象放到可比较的语义空间，近邻索引负责减少搜索范围，最终的回答仍然依赖召回片段是否覆盖问题、距离指标是否合适，以及内容有没有过期。

  • 先给定义： Prompt 工程优化指令的写法。上下文工程管理每一轮推理时送给模型的全部 Token：System Prompt、工具定义、对话历史、检索结果、用户状态，全都算
  • 说清动机： 上下文是稀缺资源。三个硬约束：Context Rot（越长检索准确率越低）、注意力预算有限（无关 Token 稀释有用信息）、n 平方复杂度（上下文翻倍，注意力计算量变四倍）
  • 给目标： 找到最小的高信号 Token 集合。每个 Token 都要为推理做贡献，能塞多少塞多少的思路行不通

先区分找得到和找得准

把「每题附考察意图、答题框架与加分点：上下文工程 / 长任务 / grep vs RAG / ACI 工具设计 / 评测基建 / LLM-as-Judge / 沙箱隔离」落成一次小测试：准备几条有明确答案的查询，记录召回的相关性、遗漏和无关结果，再决定是否需要换切分方式、索引或重排。

从这个例子继续往下看

这篇内容先从「先给定义： Prompt 工程优化指令的写法。上下文工程管理每一轮推理时送给模型的全部 Token：System Prompt、工具定义、对话历史、检索结果、用户状态，全都算」展开，再把问题推进到「说清动机： 上下文是稀缺资源。三个硬约束：Context Rot（越长检索准确率越低）、注意力预算有限（无关 Token 稀释有用信息）、n 平方复杂度（上下文翻倍，注意力计算量变四倍）」。把这两个片段放在一起看，可以更清楚地分辨：哪些是文章给出的事实，哪些是需要结合条件才能成立的判断。

把这条判断带到下一个场景

检索系统也可以这样看：先确定什么算相关，再观察召回是否覆盖问题，最后检查排序、切分和时效性有没有把真正有用的内容挤出去。

  • 「AI 工程设计模式 · 30 道灵魂拷问」：先给定义： Prompt 工程优化指令的写法。上下文工程管理每一轮推理时送给模型的全部 Token：System Prompt、工具定义、对话历史、检索结果、用户状态，全都算
  • 「继续往下看」：说清动机： 上下文是稀缺资源。三个硬约束：Context Rot（越长检索准确率越低）、注意力预算有限（无关 Token 稀释有用信息）、n 平方复杂度（上下文翻倍，注意力计算量变四倍）
  • 「最后的要点」：先摆两难： 开新窗口，Agent 失忆，会重复已做过的工作；留在旧窗口，Token 越堆越多，注意力被稀释，表现持续下降。Claude Code、Cursor、Devin 每天都在解这个题

最后的「最后的要点」把讨论落到「先摆两难： 开新窗口，Agent 失忆，会重复已做过的工作；留在旧窗口，Token 越堆越多，注意力被稀释，表现持续下降。Claude Code、Cursor、Devin 每天都在解这个题」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。

标记为已学完 阅读进度会自动记录
← 上一篇下一篇 →

继续阅读

同一条线上的下一篇。

你现在能做什么 · 实战搭你的第一个评测集改动前后跑分对比演示；三档任务：攒十条真实用例、写通过标准跑基线、用分数说话进阶收官 · 收官做最简单的、能跑的东西Anthropic 的核心工程哲学："Do the simplest thing that works"进阶收官 · 汇总进阶全景图设计模式、工具、评测、长运行、安全，一张图串起来进阶收官 · 深入Contextual Retrieval：更好的 RAG在检索前先给 Chunk 加上下文，Anthropic 的 RAG 升级方案

文章讨论

读到这里，留下一个判断。

把刚想明白的地方、还没想通的问题，留给下一位一起学习的人。

↗
正在讨论 AI 工程设计模式 · 30 道灵魂拷问 可靠 Agent 的工程模式
3条讨论文章讨论 · 与共学社区同步
在共学社区查看
AM
Asha Morgan内容编辑
观点实践记录

我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。

文章讨论7 有帮助
LH
Lin Harper独立开发者
观点观点

读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。

文章讨论5 有帮助
KM
Kiki Moore产品运营
问题问题

如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。

文章讨论4 有帮助