面试 · 系统串联题

本档与 1-6 类题型的关系
本方向的题库分为 6 类：1-5 类是按知识点切分的专项题（Prompt/上下文、RAG、工具与函数调用、评估、编排与记忆等），第 6 类是按岗位（Coding Agent / RAG 平台 / Infra 等）切分的岗位分支题。那些题解决的是"某个点你懂不懂"。
本档凌驾于 1-6 类之上，单独成档。 这里收录的是"综合锚点题"——一道题就能炸开成一整棵知识树的题。它同时满足三条：①高杠杆（答得好，考官对你整体分层立刻上一档；答崩，后面基本没机会）；②高频必问（几乎每场资深/高级岗都会以不同措辞问到）；③能串联（考官会顺着你的第一句话一路追问 4-5 层，从现象追到机制、边界、治理，任何一层露怯都会被抓住）。外加一条硬性要求：每题都带只有真做过 Agent 系统才知道的踩坑细节。
用法：1-5 类是"砖"，本档是"承重墙"。先用本档的追问链把自己的知识树压实，再回头用 1-5 类补细节。面试临场遇到锚点题，先给主干骨架 + 一句能自然引出下一层的钩子，把追问节奏握在自己手里，而不是被考官牵着走。
时效锚点（2026）：MCP 于 2025-11 由 Anthropic 捐给 Linux Foundation 旗下新成立的 Agentic AI Foundation（AAIF），同批还有 goose、AGENTS.md；A2A（Agent2Agent）是 Google 2025-04 发起、2025-06 捐给 Linux Foundation 的独立项目，不属于 AAIF。MCP 解决 Agent↔工具/数据（纵向集成），A2A 解决 Agent↔Agent（横向互操作），两者互补而非竞争。本档默认读者已理解 Harness Engineering（外壳工程）、trajectory eval（轨迹评估）、Confused Deputy（混淆代理人）、context engineering（上下文工程）等 2025-2026 术语。

锚点题 1：一个 Agent 陷入死循环 / 烧光了 token 预算，你怎么定位和治理？#

为什么是锚点题：这是资深 Agent 岗的第一杀手锏。它同时暴露三件事——你有没有真跑过生产 Agent（只做过 demo 的人答不出 step 级 trace）、你对"可观测性 + 失败归因 + 治理闭环"是否成体系、你是否理解 Agent 与普通 LLM 应用的本质差异（Agent 会自主循环，错误会复利累积而不是一次性发生）。区分度极高：初级只会说"加个 max_steps"，资深会讲清"为什么会循环"和"哪几层同时兜底"。

会串出的知识点地图：

观测层：step 级 trace / span、OpenTelemetry GenAI semantic conventions、Langfuse/LangSmith/Braintrust、每步记录 (思考→选工具→参数→工具返回→下一步)。
归因层（循环的根因分类）：① 目标不清/子目标漂移；② 工具选错（有更合适的工具没用）；③ 参数错（同一工具反复用错参数、修不对）；④ 工具返回被误读（把报错当成功、把空结果当有效）；⑤ 无终止条件/终止判据错（不知道任务何时算完）；⑥ 状态无进展（reasoning 在原地打转）。
治理层：step budget / token budget / cost budget（三级预算）、循环检测（重复 action、状态哈希、n-gram 重复、连续同类失败计数）、verification / critic loop（reflexion 式自检）、超时与熔断、human escalation（升级人工）。
Harness 层：这些不该散落在 prompt 里，而应固化进 harness（外壳）——预算、检测、恢复都是 runtime 职责，不是模型职责。

考官追问链：

（现象）"线上告警说某个任务跑了 200 步还没停、花了 15 美元，你第一步看什么？" → 答：先拉这条任务的 step 级 trace，看它是"卡在同一个 action 反复重试"，还是"步步不同但不收敛"——这两种循环根因完全不同。
（机制）"trace 显示它反复调用同一个搜索工具、参数几乎一样，为什么模型不自己跳出来？" → 答：因为上下文里堆满了失败的 observation，模型看到的是"我一直在努力但没成功"，倾向继续同类动作；且没有显式的"这条路走不通就换"的终止判据。这是目标/终止条件缺失 + 上下文噪声共同作用。
（边界）"那我把 max_steps 设成 20 不就行了？" → 答：max_steps 只是兜底止损，不解决问题——会误杀正常的长任务，且不告诉你"为什么循环"。真正要做的是循环检测（连续 N 步 action+参数指纹重复就中断并触发 reflection/换策略）+ 预算分级（step / token / cost 三个维度都要有，因为一步调一个贵模型也能烧光预算）。
（治理）"检测到循环之后，除了停，还能怎么自救？" → 答：先注入一条 verification/critic 反思（"你已重复 X 三次未成功，请重新评估目标是否可达、是否该换工具或拆解子任务"），给它一次跳出的机会；仍不行则降级（换更强模型 / 换路径 / 缩小任务）；再不行升级人工并把 trace 附上。关键是要有闭环，而不是单纯 kill。
（体系）"这套东西你放在哪一层实现？" → 答：放 harness，不放 prompt。预算、循环检测、恢复策略是运行时不变量，必须代码保证；prompt 里可以放软性引导，但绝不能把安全边界托付给模型自觉。

参考答题骨架：

"我按观测 → 归因 → 治理 → 固化四步走。① 先拉 step 级 trace，把每步的 thought/tool/args/observation 摊开，判断是'原地重复型'还是'发散不收敛型'循环。② 归因到具体根因——我常见的是工具返回被误读（把报错当没错继续）、终止条件缺失、参数修不对反复试三类。③ 治理上，我会同时上三层兜底：预算（step/token/cost 三维）、循环检测（action 指纹 + 状态哈希重复计数）、verification loop（触发后先给一次反思自救，再降级，再升级人工）。④ 最后把这些全部固化进 harness，而不是靠 prompt——因为这是 runtime 不变量。"

踩坑 / 加分点：

只设 max_steps 会误杀长任务：真实的 coding / research 任务几十上百步很正常，一刀切步数是新手做法。应按"无进展"而非"步数多"来判定循环——状态哈希 / 目标完成度是否推进，比绝对步数靠谱。
token 预算要算"读"不只算"写"：循环最烧钱的往往不是输出，而是每步都把膨胀的历史重新塞进上下文（context 越滚越长，单步 input token 线性上涨）。加分点：结合 compaction / 上下文压缩 一起讲，循环治理和上下文工程是同一个问题的两面。
"把报错当成功"是最隐蔽的循环源：工具返回了 500 或空结果，但模型解析成"拿到了数据"，于是基于幻觉继续。防御是结构化工具返回（显式 success 字段 + 错误码），别让模型靠自然语言猜工具到底成没成功。
prompt cache 会掩盖循环成本：开了 prompt caching 后单步便宜了，容易让人忽视循环步数暴涨，监控要看绝对步数和累计 cost，别只看单步价。
加分：提一句 OpenTelemetry GenAI semantic conventions——2025-2026 这已是 Agent 可观测性的事实标准，能让你的 trace 跨 Langfuse/LangSmith/自建栈统一，而不是每家一套私有 schema。

锚点题 2：从 0 设计一个能改代码、跑测试、提 PR 的 Coding Agent Runtime#

为什么是锚点题：Coding Agent 是 2025-2026 最热的 Agent 落地场景（Claude Code / Codex / Devin / OpenHands），也是最能考"系统设计能力"的题。它把 repo 理解、编辑、执行、隔离、验证、门禁、权限、恢复全串起来——你必须一层层说清"每一步怎么保证不把用户仓库搞坏、怎么保证改动真的对"。答得好，考官会认定你能独当一面搭 runtime；答成"调个 LLM 让它写代码"就出局。

会串出的知识点地图：

Repo 上下文获取：代码检索（ripgrep/grep + AST + embedding 混合）、依赖图/调用图、AGENTS.md / CLAUDE.md 约定文件、按需读取 vs 全量塞入。
编辑能力：diff/patch 式编辑（str-replace、apply-patch）vs 全文件重写——为什么前者更安全（可审计、冲突可检测、token 省）。
执行能力：受限 shell、命令白名单、超时、输出截断。
隔离：git worktree / 容器 / VM 沙箱，为什么必须隔离（避免污染主分支、避免破坏宿主环境）。
测试闭环（test loop）：跑测试 → 读失败 → 定位 → 改 → 再跑的红绿循环，这是 Coding Agent 的核心引擎。
评审门禁（review gate）：生成 diff → LLM 自审 / 人工审 → 通过才提 PR。
Hooks：pre/post-tool hook 自动跑 lint/format/typecheck，把确定性检查从模型手里拿走。
权限 / sandbox：文件系统边界（可写目录白名单）、网络隔离、密钥不进上下文。
长任务恢复：checkpoint、状态持久化、可 resume、任务分解与 subagent。
基准：SWE-bench / SWE-bench Verified（真实 GitHub issue 改到测试通过）、Terminal-Bench。

考官追问链：

（现象/入口）"Agent 拿到一个 issue，第一步该干嘛？" → 答：建立 repo 上下文，但不是把整个仓库塞进去——用检索（grep/AST 定位符号 + embedding 找语义相关）+ 读 AGENTS.md/CLAUDE.md 了解项目约定，只把相关文件和结构拉进来。上下文预算是稀缺资源。
（机制）"它要改文件，你让它整文件重写还是给 diff？为什么？" → 答：diff/patch 式编辑。原因：可审计（review gate 直接看 diff）、可检测冲突、省 token、失败可精确回滚。全文件重写容易把无关代码改坏、diff 噪声大、review 不了。
（隔离/边界）"它跑 rm -rf 或 pip install 怎么办？会不会把用户机器搞坏？" → 答：必须沙箱隔离——git worktree 隔离分支（改动不碰主工作区）+ 容器/VM 隔离文件系统和网络 + 命令白名单/审批。破坏性命令要么禁、要么走人工审批。这里正好引到安全（见锚点题 3 的 Confused Deputy）。
（验证）"它说'我改完了'，你凭什么信？" → 答：不信自述，信 test loop。改完必须跑测试，红了就把失败信息喂回去继续修，绿了才算一步完成；再叠加 hooks 跑 lint/typecheck（确定性检查，不靠模型判断）。最后生成 diff 过 review gate（LLM 自审 + 人工），通过才 git commit / 开 PR。
（规模/恢复）"任务跑到一半 runtime 挂了，或者要跑 40 分钟，怎么办？" → 答：checkpoint + 状态持久化，把已完成的编辑、当前计划、测试状态落盘，支持 resume；长任务用 subagent 隔离子任务（比如"探索 codebase"丢给 subagent，只回主 agent 一份摘要，避免主上下文被探索噪声撑爆）。

参考答题骨架：

"我把 runtime 拆成六个部件：上下文层、编辑层、执行层、隔离层、验证层、恢复层。上下文层用检索按需喂而非全塞；编辑层强制 diff/patch 保证可审计可回滚；执行层是受限 shell + 白名单；隔离层用 git worktree + 容器双重隔离；验证层是 test loop（红绿循环）+ hooks（确定性检查）+ review gate（diff 门禁）三道关，通过才提 PR；恢复层做 checkpoint 和 subagent 隔离支撑长任务。贯穿其中的原则是：确定性的事交给工具/hook，不交给模型；破坏性的事必须隔离或审批。评估我会拿 SWE-bench Verified 打底。"

踩坑 / 加分点：

worktree 隔离是新手最容易漏的一步：直接在主工作区让 Agent 改，一旦它跑偏，用户未提交的改动就没了。用 git worktree 给每个任务开独立工作树，跑砸了整棵删掉即可，零污染。（本项目 harness 里的 worktree 隔离模式就是这个道理。）
diff 编辑的"字符串不唯一/缩进不匹配"是高频失败：str-replace 式编辑要求 old_string 精确唯一，模型经常给出不唯一或缩进错的片段导致 patch 失败。加分：讲清楚要给模型足够上下文行 + 失败后把精确报错喂回，而不是让它盲改。
测试通过 ≠ 改对了：Agent 会"作弊"——改测试而不是改实现、加 skip、写恒真断言。review gate 必须显式检查 diff 里有没有动测试文件、有没有削弱断言。这是真踩过才知道的。
别把密钥/环境变量喂进上下文：Coding Agent 读 .env、CI 配置时极易把密钥带进 LLM 请求并落进 trace。沙箱要做 secret 脱敏，可写目录白名单要排除凭据文件。
hooks > prompt 约束：想让它每次改完都 format？别写进 prompt（模型会忘/会跳），用 post-edit hook 强制执行。确定性需求一律用 harness/hook 兜，这条能体现你懂"外壳工程"。
加分：提一句 A2A——如果这个 Coding Agent 要和其它 Agent（比如 CI Agent、Review Agent）协作，跨 Agent 通信走 A2A；它自己连 GitHub/文件系统等工具走 MCP。能分清这两个协议各管一层，是 2026 的加分项。

锚点题 3：一个 Agent 系统的安全，比普通 LLM 应用难在哪？怎么分层防护？#

为什么是锚点题：这是安全维度的天花板题，也是 2025-2026 最被反复问的题（因为 Agent 出事就是真出事——删库、越权转账、数据外泄）。它的核心区分点：普通 LLM 应用风险停在"输出"（顶多说错话），Agent 风险升级到"执行"（会调工具、会写数据、会花钱）。能不能一句话点破这个"从输出到执行"的质变，基本决定了这题的档位。

会串出的知识点地图：

风险质变：输出层风险 → 执行层风险（工具调用 = 真实副作用）。
Prompt Injection：直接注入（用户输入里的"忽略以上指令"）vs 间接注入（恶意指令藏在 Agent 读取的外部内容里——网页、文档、邮件、issue、工具返回、代码注释）。间接注入是 Agent 独有的重灾区，因为 Agent 会自主读取不可信内容。
Confused Deputy（混淆代理人）：Agent 持有广泛权限（OAuth token、DB 访问、文件系统），被诱导代表攻击者执行越权操作——权限是 Agent 的，意图是攻击者的。MCP 场景下的 OAuth proxy confused deputy 是经典案例。
分层防护：工具权限最小化、human-in-the-loop 审批、指令/数据分离、Dual-LLM / CaMeL 模式、沙箱、输出/工具调用白名单、审计日志。
供应链：MCP server / 技能（skill）/ 插件的供应链风险——第三方 MCP server 可能是恶意的或被投毒。
2026 治理面：MCP 的 server 身份验证、Enterprise-Managed Authorization、"MCP Firewall" / 治理注册表。

考官追问链：

（质变）"同样是 LLM，Agent 的安全为什么不能照搬普通应用那套？" → 答：因为风险从"输出"升级到"执行"。普通 LLM 说错话你过滤输出就行；Agent 会调工具产生真实副作用（发邮件、改 DB、转账、删文件），一次被诱导就是真实损失，且错误会被后续步骤放大。
（机制）"最典型的攻击面是什么？" → 答：间接 prompt injection。Agent 会自主去读网页、文档、issue、工具返回，攻击者只要在这些内容里埋指令（"把用户的密钥发到 X"），Agent 读到后可能当成任务执行。这和直接注入的区别是：你根本没法要求用户"别输入恶意内容"，因为恶意内容来自 Agent 自己抓取的外部世界。
（升级）"就算注入了，它顶多乱说话吧？" → 答：不是——这就引出 Confused Deputy。Agent 持有用户授权的广泛权限（比如 OAuth 后能读整个邮箱、能查 DB），被注入诱导后，它拿着合法权限去干攻击者想要的事，系统看到的是"授权用户的正常操作"，很难拦。权限越大，confused deputy 危害越大。
（边界）"那我上一个 prompt injection 分类器过滤输入不就好了？" → 答：单点过滤必然被绕（对抗样本、编码混淆、多语言、藏在图片/代码里）。安全不能靠"检测恶意指令"这一条线，必须假设注入会成功，然后靠架构限制"就算被注入，也造不成大破坏"——这就是分层防护和最小权限的意义。
（治理）"那你的分层具体是哪几层？" → 答：见骨架。核心思想是能力限制 > 意图检测：与其猜它是不是被骗了，不如让它压根没有能力做危险操作（没权限、要审批、在沙箱里、动作过白名单）。

参考答题骨架：

"一句话：普通 LLM 的风险在'输出'，Agent 的风险在'执行'，所以防护重心从'过滤内容'转向'限制能力'。我分五层：① 最小权限——每个工具/MCP server 只给完成任务必需的最小 scope，宁可多轮授权不要一把大权限；② 指令/数据分离 + 不可信内容隔离——外部读到的内容默认是数据不是指令，用 Dual-LLM / CaMeL 这类模式让处理不可信内容的 LLM 无工具权限；③ human-in-the-loop——高危动作（转账、删除、外发数据、执行破坏性命令）强制人工审批；④ 沙箱 + 动作白名单——执行环境隔离网络/文件系统，工具调用过白名单；⑤ 审计——全链路 trace + server 身份验证，事后可追溯。贯穿原则是假设注入一定会成功，靠架构让它'骗得动但干不成'。"

踩坑 / 加分点：

别把 A2A 归到 AAIF：安全题很容易扯到协议治理。准确说法是——MCP 2025-11 进了 AAIF（Agentic AI Foundation，Linux Foundation 旗下）；A2A 是 Linux Foundation 的独立项目，不在 AAIF 下。说反了会被懂行的考官抓住。
Confused Deputy 的经典 MCP 案例：MCP server 作为 OAuth proxy、用静态 client_id 时，若用户之前已对该 client consent 过，攻击者可构造授权链接跳过 consent 界面直接拿到 auth code。加分：能点出"OAuth proxy + 静态 client + 已存在的 consent cookie"这个具体机制，说明你真读过 MCP 安全规范。
间接注入最毒的载体是"工具返回"：大家防网页/文档，却忘了另一个 Agent 或工具的返回值本身也可能被投毒（尤其多 Agent 经 A2A 协作时）。工具返回也要当不可信数据处理。
技能/MCP 供应链投毒：装一个第三方 MCP server 或 skill，等于把执行权交给了别人的代码。要审来源、锁版本、最小权限运行、监控其行为。2026 企业已经在上 "MCP Firewall / 治理注册表"来管"哪个 Agent 能连哪个 server"。
"人工审批"会被审批疲劳废掉：如果每步都弹审批，用户会闭眼点"同意"。加分：讲清楚要按风险分级——只读/可逆操作放行，不可逆/高危才拦，并把上下文（要干什么、影响范围）清楚呈现给审批人。
反面加分：明确说"输入过滤分类器只是纵深防御的一层，不能作为主要防线"——这是区分"读过安全 paper"和"背了几个名词"的关键。

锚点题 4：企业知识库问答不准，怎么系统性排查和优化？#

为什么是锚点题：RAG 是 Agent 落地最广的场景，"问答不准"是每个做过 RAG 的人都被投诉过的问题。这题考的是系统性排查能力——能不能先做"检索 vs 生成"的二分定位，而不是一上来就瞎调 chunk size。区分度在于：初级会罗列一堆优化手段（rerank、换 embedding……）像撒网；资深会先定位问题在哪一环，再对症下药，还能判断"要不要升级到 Agentic RAG"。

会串出的知识点地图：

第一刀二分：检索问题（相关文档没召回/排序靠后）vs 生成问题（召回了但没用好/答跑偏/编造）。
检索侧：chunking（大小/重叠/语义分块/结构感知）、embedding 模型选型与领域适配、hybrid 检索（BM25 + dense）、rerank（cross-encoder）、query rewrite / expansion / HyDE / 多查询、metadata 过滤。
上下文侧：召回的到底进没进上下文、有没有被截断、lost-in-the-middle（放中间被忽略）、排序与去重。
生成侧：引用忠实度（faithfulness/groundedness）、答非所问（answer relevancy）、幻觉、有没有真的基于检索内容作答。
RAG Eval：RAGAS（faithfulness、answer relevancy、context precision/recall）、检索指标（recall@k、MRR、nDCG）、端到端 + 分环节评估。
升级判断：单轮 RAG 何时不够 → Agentic RAG（多轮检索、query 分解、self-RAG、CRAG、让 Agent 自主决定检索什么/够不够）。

考官追问链：

（定位）"用户说答得不准，你怎么开始？" → 答：先做二分——把"检索到的 chunk"和"最终答案"分开看。如果相关内容根本没被召回（或排在很后被截断），是检索问题；如果召回了但答案没用上/编造，是生成问题。方向错了后面全白调。
（检索机制）"确认是检索没召回，怎么修？" → 答：分层查——① chunking 是不是把答案切碎了（语义被拦腰截断）；② embedding 模型在这个领域行不行（通用 embedding 对专业术语/缩写常常拉胯，考虑领域微调或换模型）；③ 是不是缺 hybrid——纯向量对精确关键词/型号/编号召回差，加 BM25；④ 加 rerank（cross-encoder）把相关的顶上来；⑤ query 本身太口语/太短，上 query rewrite / HyDE / 多查询。
（上下文边界）"我召回 top-20 全塞进去了，为什么还是漏答？" → 答：两个坑——截断（超 context 被砍掉）和 lost-in-the-middle（关键内容放在中间被模型忽视）。不是塞越多越好；要 rerank 后精选 top-k，把最相关的放头尾，去重去噪。context 是稀缺注意力预算。
（生成/忠实度）"召回明明有正确答案，模型却编了个别的，怎么治？" → 答：这是 faithfulness/groundedness 问题。手段：强制带引用作答（每个论断标注来源 chunk）、prompt 约束"只依据提供的资料，无依据就说不知道"、用 RAGAS 的 faithfulness 指标量化幻觉率、必要时加一个 grounding 校验步骤。
（升级判断）"这些都做了还是不行，接下来呢？" → 答：判断任务是不是单轮检索本就搞不定——比如需要多跳推理、需要先查 A 再据 A 查 B、或问题模糊要先澄清。这类要升级 Agentic RAG：让 Agent 自主决定检索什么、判断"证据够不够"、不够就再检索、query 自动分解（self-RAG / CRAG 思路）。但要权衡成本和延迟，别为了炫技把简单 FAQ 也套 Agent。

参考答题骨架：

"我先分环节归因，绝不上来瞎调参。第一刀切'检索 vs 生成'：拉出召回的 chunk 和最终答案对比。检索侧我按 chunking → embedding 选型 → hybrid（BM25+dense）→ rerank → query rewrite 逐层查；中间还要确认召回内容真进了上下文没被截断、没落进 lost-in-the-middle。生成侧查忠实度——强制带引用、约束'无依据不作答'、用 RAGAS 量化幻觉。每一层都用指标兜底：检索用 recall@k/MRR/nDCG，端到端用 RAGAS 的 context precision/recall + faithfulness + answer relevancy。最后判断要不要升级 Agentic RAG——多跳/需澄清/需迭代检索的场景才上，简单 FAQ 不折腾。"

踩坑 / 加分点：

80% 的"生成不准"其实是检索没召回：新手一投诉就去调 prompt、换大模型，其实答案压根没进上下文。先验证召回，这是最省时间的一步。加分：讲"先把召回的 chunk 打印出来人肉看一眼"这种朴素但极有效的动作。
改了 chunking/embedding 一定要重建索引并清缓存：换了 embedding 模型或分块策略，旧向量和新 query 不在同一语义空间，结果全乱；且检索层常有缓存（如 Valkey/Redis 缓存 query→结果），改格式后必须清脏数据。这是真踩过的运维坑。
纯向量检索对"编号/型号/精确词"是灾难：问"XX-2024 型号参数"，dense 检索可能召回一堆语义相近但型号不对的。必须 hybrid 补 BM25。能主动点出这个反例是加分。
rerank 的性价比常被低估：很多时候不用换 embedding、不用重建库，只在召回后加一个 cross-encoder rerank，top-k 质量立竿见影，成本极低。先试这个再谈大改。
引用忠实度要校验"引的对不对"而不只是"有没有引"：模型会一边编造一边随便挂个引用。加分：提"引用能对齐到具体 span、且答案论断能被引用内容支撑"才算真忠实，RAGAS faithfulness 就是量化这个。
Agentic RAG 不是银弹：多轮检索会成倍放大延迟和 token 成本，还引入锚点题 1 的循环风险（反复检索停不下来）。要能说清"什么场景值得、什么场景是过度工程"。

锚点题 5：怎么评估一个 Agent 好不好？为什么比评估普通 LLM 难？#

为什么是锚点题：评估是 Agent 工程的"照妖镜"——不会评估的团队，优化全靠感觉、上线全靠运气。这题的高杠杆点在于能否讲清 Agent 评估的独有难点：普通 LLM 看单轮输出对不对就行，Agent 是多步轨迹 + 多条可达路径 + 成本/延迟多维 + 非确定性，只看最终结果会漏掉一半问题。能把 trajectory eval 和 outcome eval 的关系讲透、能报出基准谱系，档位立刻拉开。

会串出的知识点地图：

为什么更难：非确定性（同输入不同轨迹）、多路径可达同一结果、部分正确、long-horizon（错误累积）、多了成本/延迟/可靠性维度、LLM-as-Judge 自身有偏差。
评估层次：outcome eval（最终结果对不对）+ trajectory eval（轨迹评估）——工具选择是否正确、参数是否正确、步数是否高效、有无冗余/回退、路径是否合理。
LLM-as-a-Judge 的坑：position bias（位置偏好）、verbosity bias（偏爱长答案）、self-preference（偏爱同源模型输出），要用 pairwise、rubric、打乱顺序、多 judge 来缓解。
可靠性维度：pass@k（k 次里至少一次成功）vs pass^k / pass*k（k 次全部成功，衡量稳定性）——Agent 尤其看后者。
基准谱系（会被点名要求列举）：τ-bench / τ²-bench（工具使用 + 遵守 policy + 多轮）、SWE-bench / SWE-bench Verified（真实代码修复）、GAIA（通用助理多步工具）、WebArena / VisualWebArena（真实网站 web agent）、OSWorld（computer use）、Terminal-Bench 等。

考官追问链：

（破题）"评估 Agent 和评估一个普通 chatbot，本质区别在哪？" → 答：chatbot 看单轮输出质量就够；Agent 是多步过程，最终结果对了不代表过程对（可能瞎试蒙对、可能绕了 50 步烧掉 10 美元才做完）。所以必须同时评 outcome（结果）和 trajectory（轨迹），还要加成本、延迟、可靠性维度。
（轨迹）"轨迹具体评什么？" → 答：① 工具选择——有没有选对工具（该查数据库却去搜网页）；② 参数正确性——调用参数对不对；③ 效率——步数是否冗余、有没有反复回退；④ 路径合理性——是否走了合理的解题路径。方法：和 reference trajectory 对比，或用 LLM judge 按 rubric 打分。
（非确定性/可靠性）"同一个任务跑 5 次，3 次对 2 次错，算通过吗？" → 答：这正是 Agent 评估比 LLM 难的点——要看可靠性。用 pass@k（宽松，看能力上限）还是 pass^k（严格，k 次全对，看稳定性）取决于场景：面向生产的 Agent 更该看 pass^k，因为用户不会容忍时好时坏。τ-bench 就专门引入了 pass^k 衡量一致性。
（judge 偏差）"你用 LLM 当裁判，它本身可信吗？" → 答：不能盲信。LLM-judge 有 position bias / verbosity bias / self-preference。缓解：用 pairwise 比较代替绝对打分、打乱候选顺序、给明确 rubric 而非"你觉得哪个好"、必要时多个 judge 投票、关键场景用人工 golden 校准 judge 本身。
（落地）"公开基准刷得高，上线还是拉垮，为什么？" → 答：基准是代理指标不是业务指标——SWE-bench 高不代表你司代码库好使，τ-bench 高不代表你的业务 policy 遵守好。必须自建贴合业务的评测集（真实任务 + golden 轨迹/结果），把公开基准当能力体检、把私有集当验收标准。

参考答题骨架：

"我先点破难点：Agent 是多步、多路径、非确定、多维度，只看最终结果会漏掉'瞎蒙对'和'绕远路烧钱'。所以我评三层：① outcome——任务最终有没有达成；② trajectory——工具选择/参数/步数效率/路径合理性，和 reference 轨迹对比或 LLM-judge 按 rubric 打；③ 成本/延迟/可靠性——尤其用 pass^k 看稳定性而非只看 pass@k。裁判用 LLM-as-Judge 但要防 position/verbosity/self-preference 偏差（pairwise + 打乱 + rubric + 人工校准）。基准上我用 τ-bench 看工具+policy、SWE-bench Verified 看代码、GAIA 看通用助理、WebArena 看 web agent 打底，但最终验收一定用贴业务的私有评测集。"

踩坑 / 加分点：

最终结果对 ≠ Agent 好：见过 Agent 靠反复瞎试蒙对答案，outcome 满分但轨迹一塌糊涂、成本爆炸。只报最终准确率的评估是自欺欺人——这句能立刻显出你的段位。
pass@k 和 pass^k 别搞混：pass@k 是"k 次里≥1 次成功"（看上限、偏乐观），pass^k 是"k 次全部成功"（看稳定性、偏悲观）。生产 Agent 该盯 pass^k。混淆这两个是常见硬伤。
SWE-bench 要说 Verified：原始 SWE-bench 有不少标注噪声/不可解样本，业界基本引用 SWE-bench Verified（人工筛过的子集）。直接说"SWE-bench 90 分"而不提 Verified 会显得没跟进。
LLM-judge 的 self-preference 最阴：用 GPT 系判 GPT 系的输出、用 Claude 判 Claude，会系统性偏袒同源。关键评测要么换异源 judge、要么人工兜底。
别只评离线：Agent 上线后分布漂移严重，离线基准高不代表线上稳。加分：提"离线基准 + 线上 trace 抽样评估 + 用户反馈信号"三条腿，评估是持续的不是一次性的。
加分：把评估和锚点题 1 的可观测性串起来——没有 step 级 trace 就做不了 trajectory eval。评估和观测是同一套基础设施，能点出这层关联说明你成体系。

锚点题 6：单 Agent 还是多 Agent？ReAct / Plan-Execute / Supervisor 你怎么选？#

为什么是锚点题：编排选型是架构层面的必问题，也是最容易"为了炫技上多 Agent"翻车的地方。2025-2026 业界有明确的两派论战（Anthropic 的多 Agent research 系统 vs Cognition"别轻易上多 Agent"），能讲清什么时候多 Agent 是负担而不是收益，比会背三种模式重要得多。区分度：初级罗列模式定义；资深讲 trade-off 和"默认单 Agent、被逼才拆"的决策原则。

会串出的知识点地图：

单 Agent 模式：ReAct（reason+act 交错，工具循环）、Plan-and-Execute（先规划整体再逐步执行，省 LLM 调用、可控性强）、ReWOO 等。
多 Agent 模式：Supervisor / orchestrator-worker（主 Agent 分派子 Agent）、群聊/协商式、handoff（如 OpenAI Swarm 风格的交接）。
决策维度：任务可否并行、是否需要 context 隔离、是否需要不同角色/工具集、状态一致性难度、成本、可调试性。
协议层：多 Agent 跨进程/跨组织协作走 A2A；Agent 连工具/数据走 MCP。
踩坑：多 Agent 的协调开销、状态一致性、错误传播、成本翻倍、可观测性变复杂。
上下文关联：多 Agent 的一大正当理由是 context 隔离（见锚点题 7）。

考官追问链：

（默认选择）"一个新任务来了，你默认单 Agent 还是多 Agent？" → 答：默认单 Agent。多 Agent 引入协调、状态一致性、成本翻倍、调试变难等真实成本，只有当单 Agent 明显扛不住时才拆。这是"能简单就别复杂"的工程纪律。
（单 Agent 内部）"单 Agent 里 ReAct 和 Plan-Execute 怎么选？" → 答：ReAct 适合探索性、每步依赖上一步结果的工具循环（不知道下一步要干嘛，边做边看）；Plan-Execute 适合任务可预先规划、想减少 LLM 调用次数、想要更强可控性和可审计性的场景（先出计划，再按计划执行，计划本身可 review）。很多生产系统是二者混合——先 plan 出大纲，每个子步骤内部用 ReAct。
（何时拆多 Agent）"什么信号出现你才上多 Agent？" → 答：三个正当理由——① 可并行（多个独立子任务能同时跑，如"分别调研 5 家竞品"）；② context 隔离（某子任务会产生大量中间噪声，单 Agent 会被撑爆/污染，丢给 subagent 只回摘要）；③ 角色/工具集差异大（不同子任务需要完全不同的工具和 system prompt）。没有这些就别拆。
（代价/边界）"多 Agent 的坑是什么？" → 答：状态一致性（多个 Agent 对世界的认知会分叉）、错误传播（一个子 Agent 的幻觉被别的当事实）、协调开销（大量 token 花在互相沟通）、成本翻倍、可观测性和调试复杂度陡增。Cognition 那篇"别轻易建多 Agent"讲的就是这些——共享上下文难、决策分散易冲突。
（协议）"多个 Agent 要跨团队/跨系统协作，用什么连？" → 答：跨 Agent 通信用 A2A（Agent 互相发现、协商、交换任务，Linux Foundation 独立项目）；每个 Agent 自己连工具/数据用 MCP（AAIF 项目）。一横一纵，别混为一谈。

参考答题骨架：

"我的默认是单 Agent，因为多 Agent 的协调、一致性、成本、调试成本都是真实的。单 Agent 内部，探索型/步step依赖强的用 ReAct，可预先规划、要可控可审计的用 Plan-Execute，实践中常混用（plan 大纲 + 每步 ReAct）。只有出现三个信号才拆多 Agent：可并行、需 context 隔离、角色工具集差异大。拆的时候优先 Supervisor/orchestrator-worker 结构（主 Agent 分派、子 Agent 只回摘要），把状态收敛在主 Agent 避免认知分叉。跨系统协作走 A2A、连工具走 MCP。"

踩坑 / 加分点：

"多 Agent 更强"是最大的迷思：多 Agent 常常更慢、更贵、更难调，且因为上下文分散反而更容易做错决策。能主动泼这盆冷水、引用 Cognition"Don't build multi-agents"和 Anthropic 多 Agent research 系统的对立结论并说清各自适用边界，是这题最大的加分。
Anthropic 多 Agent 之所以成立是因为任务"可并行 + 结果可汇总"：research 场景是"分头查、最后合并",天然适合 orchestrator-worker;而写代码这种"强状态依赖、需全局一致"的任务，多 Agent 反而容易互相踩。用这组对比解释"何时行何时不行"最有说服力。
多 Agent 最隐蔽的坑是"共享状态"：让两个 Agent 同时改同一份文件/DB 会冲突，让它们靠对话同步认知会漂移。要么单写者、要么明确的 handoff 交接协议。
Plan-Execute 的计划会过期：预先规划好的步骤，执行到一半环境变了、前一步结果和预期不符，死守原计划就翻车。加分：讲清楚要有重规划（replan）触发——执行偏离预期时回到规划阶段，而不是硬着头皮走完。
加分：把编排选型和锚点题 5 的评估串起来——多 Agent 的 trajectory eval 更难（要评跨 Agent 的协作轨迹），这也是"能不拆就不拆"的一个隐性理由。

锚点题 7：长任务上下文越滚越长，模型开始变笨/漏信息，你怎么做上下文工程？#

为什么是锚点题：长任务（coding、research、多轮客服）是 Agent 的主战场，而"上下文越长质量越差（context rot）"是绕不开的物理约束。这题考的是 2025-2026 最核心的工程能力——context engineering（上下文工程），它正在取代 prompt engineering 成为 Agent 可靠性的第一决定因素。能把 compaction、subagent 隔离、结构化 memory、attention budget 讲成体系，是资深标志。

会串出的知识点地图：

问题本质：context window 有限 + context rot（上下文越长、噪声越多，模型注意力被稀释、关键信息被淹没，即使没超窗也会变笨）+ lost-in-the-middle + 成本随长度线性涨。
核心手段：
- Compaction / 摘要压缩：把历史对话/中间结果压缩成结构化摘要，保留决策和结论、丢弃过程噪声。
- Subagent 隔离：把会产生大量中间 token 的子任务丢给 subagent，主 Agent 只拿回摘要——上下文隔离（和锚点题 6 的多 Agent 呼应）。
- 结构化 Memory：working memory（当前任务态）/ episodic（历史事件）/ semantic（长期知识），外置到检索而非全塞上下文。
- 外置 scratchpad / 文件系统：让 Agent 把中间产物写文件、需要时再读，而不是全揣在上下文里（本项目 harness 就用 scratchpad 目录）。
- Just-in-time 检索：按需拉信息进上下文，而非预先全塞（retrieval 而非 stuffing）。
- KV cache / prompt caching：把稳定前缀缓存，降成本降延迟。
原则：把上下文当**稀缺的注意力预算（attention budget）**来经营——right tokens, right place, right time。

考官追问链：

（现象）"任务跑长了模型开始漏信息、答非所问，我上下文明明没超窗，为什么？" → 答：这就是 context rot——即使没超 token 上限，上下文越长、无关内容越多，模型的有效注意力越被稀释，关键指令/事实被淹没（叠加 lost-in-the-middle）。上下文长度本身就是一种负担，不是"塞得下就没事"。
（手段）"那怎么办，直接截断历史？" → 答：粗暴截断会丢关键决策。更好的是 compaction——把历史压缩成结构化摘要（保留目标、已做决策、关键结论、待办；丢弃过程噪声和失败尝试的细节）。这样既省 token 又留住"记忆主干"。
（隔离）"有些子任务本身就产生海量中间内容（比如遍历整个 codebase），怎么防止它撑爆主上下文？" → 答：subagent 隔离——把这类任务丢给子 Agent 在独立上下文里跑，主 Agent 只接收一份精炼摘要。这正是多 Agent 的一个正当用途（呼应锚点题 6），本质是"上下文分区"。
（记忆）"跨会话、跨天的长期信息怎么办？" → 答：不能全塞上下文，要外置成结构化 memory + 检索：working memory 放当前任务态、episodic 存历史事件、semantic 存长期知识/偏好，用时 just-in-time 检索进来。让上下文只装"此刻需要的",其余外置。
（成本/边界）"这么压来压去，会不会压丢关键信息、或者压缩本身也很贵？" → 答：会——compaction 是有损的，压缩策略设计不好会丢掉后续需要的信息，且压缩本身要花一次 LLM 调用。所以要分层保留（决策/约束绝不压、过程细节可压）、设触发阈值（接近窗口某比例才压，不是每步压）、并保留可回溯的原始记录（写文件）以防压错。上下文工程的目标是用最少的 token 承载正确的信息，不是无脑压缩。

参考答题骨架：

"我把上下文当稀缺的注意力预算经营，核心是对抗 context rot（越长越笨，不止是超窗问题）。四板斧：① compaction——历史压成结构化摘要，保决策/结论、弃过程噪声，按窗口占用阈值触发而非每步压；② subagent 隔离——产生海量中间 token 的子任务丢给子 Agent，主 Agent 只收摘要；③ 结构化 memory + just-in-time 检索——working/episodic/semantic 分层外置，用时再拉，不预先全塞；④ 外置 scratchpad/文件系统——中间产物落盘，需要再读。原则是 right tokens, right place, right time，并配 prompt caching 降成本。压缩是有损的，所以决策类信息绝不压、且保留原始记录可回溯。"

踩坑 / 加分点：

"context 越长越好"是最贵的错觉：把能塞的全塞进去，不仅烧 token，还因 context rot 让效果变差。加分：明确说"长上下文模型能装 ≠ 装满了效果好"，attention 是被稀释的。
compaction 最容易压丢"约束和已决策事项"：把"用户明确要求不能用 X 库"这种硬约束压没了，后面 Agent 就违反。分层保留策略里，约束/决策/用户偏好属于'永不压缩'档。
subagent 摘要的"信息瓶颈"：主 Agent 只拿摘要，如果摘要漏了关键细节，主 Agent 就在残缺信息上决策。要设计好子 Agent 的返回契约（结论 + 关键证据 + 不确定项），而不是随便总结一段。
压缩会破坏 prompt cache：每次 compaction 都改写了前缀，KV/prompt cache 全失效、成本反弹。加分：讲清楚"压缩时机要和缓存策略协同"——不要高频压缩把缓存打穿。
别把 memory 做成一个大杂烩向量库：什么都往里塞、什么都检索回来，等于把 context rot 换个地方复现。memory 要有类型、有时效、有淘汰策略。
加分：把这题和锚点题 1（循环治理）打通——上下文膨胀既是长任务变笨的原因，也是死循环烧 token 的放大器，compaction 是同时治两个病的手段。能点出"上下文工程是 Agent 可靠性的公共底座"，收尾漂亮。

本档共 7 道综合锚点题，覆盖：死循环/预算治理与可观测性、Coding Agent Runtime 系统设计、Agent 安全分层防护（含 Confused Deputy / 间接注入 / 供应链）、企业 RAG 系统性排查与 Agentic RAG、Agent 评估与 trajectory eval / 基准谱系、单 vs 多 Agent 编排选型、长任务上下文工程（compaction / subagent 隔离 / 结构化 memory）。贯穿 MCP（AAIF）与 A2A（Linux Foundation 独立项目）协议边界、Harness Engineering、context rot 等 2026 术语。