面试 · 岗位分支面试题

考察目标：按目标岗位深入，考察岗位特定能力 约 7 题，覆盖 7 类岗位分支 说明：每题分「题干」（标题）与「参考答案」两段。Confused Deputy 防护、基准谱系、LLM-judge 偏差等通用模块引用规范条目（3-原理 Q11 / 1-概念 Q10 / 3-原理 Q14）。

Q1（应用工程师）：业务场景如何选 Agent vs Workflow？如何接业务系统？如何做效果评估？#

参考答案

Agent vs Workflow 选择#

实战策略：先 workflow 把可控场景做扎实，再逐步引入 Agent 自主决策到"受控区"。若已上 Agent，编排范式（ReAct / Plan-and-Execute / Reflexion / ToT）的选型见 2-对比 Q10。

如何接业务系统#

• REST API：通用业务系统，标准、易调试
• Webhook：事件驱动（订单创建/状态变更），异步被动
• 消息队列：异步任务、解耦（Kafka/RabbitMQ/RocketMQ）
• OAuth：第三方 SaaS 接入，不存密码
• IM 渠道：飞书/企微/钉钉，用 Channel Adapter 解耦

如何做效果评估#

• 业务指标：任务完成率、用户满意度、人工接管率
• A/B 测试：不同 prompt/模型/工具组合对比
• 用户反馈：点赞/点踩、自由文本反馈
• 成本控制：单任务成本不超标，路由降级（成本杠杆见 3-原理 Q13）

Q2（RAG 工程师）：如何做权限感知检索？引用忠实度怎么评？知识库更新流水线怎么设计？#

参考答案

权限感知检索#

反模式：先检索后过滤（召回 100 条 → 按权限过滤剩 10 条，丢了 90 条相关结果）。

正确做法：

• 检索时就过滤（Vector DB 的 filter 能力）
• metadata 加 ACL 字段（department/level/project）
• 查询时注入用户权限上下文

results = vector_db.search(
    query=embedding,
    filter={"department": {"$in": user.departments}},
    top_k=10
)

引用忠实度评估#

• faithfulness：回答是否基于检索内容（防幻觉）——低忠实度多是"没强制引用/证据没进上下文"，不是 temperature 问题（见 4-场景 Q2）
• 工具：Ragas 的 faithfulness 评分
• LLM-as-a-Judge：让强模型判断"回答里每个事实是否能在检索内容里找到出处"——注意 judge 的 verbosity/self-preference 偏差（见 3-原理 Q14）
• 校准：人工标注一小部分，校准 judge 准确性

知识库更新流水线#

[新文档入库] → [自动解析+Chunking] → [Embedding]
       ↓
[增量索引] → [版本管理] → [灰度发布]
       ↓
[失效检测] → [旧 chunk 标记/删除]

• 增量更新：新文档自动入库
• 版本管理：文档改了，旧 chunk 标记 deprecated
• 失效检测：chunk 引用的文档被删/改了，自动失效
• 灰度发布：新知识库先小流量验证再全量

Q3（Coding Agent）：如何设计 test loop + diff review + worktree 隔离？如何刷 SWE-bench？#

参考答案

Test Loop + Diff Review + Worktree 隔离协同#

1. 每个任务在独立 worktree (git worktree add)
   ↓ 不影响主仓库, 多 Agent 并行不冲突
2. Agent 改代码 → 跑测试
   ↓
3. 测试失败 → 分析失败原因 → 改代码 → 再跑 (Test Loop)
   ↓
4. 测试通过 → 生成 diff
   ↓
5. 自动 review (lint/security scan/dependency check)
   ↓
6. 人工 review (PR review)
   ↓
7. 通过 → merge 到主分支
   不通过 → Agent 修改后重提

如何刷 SWE-bench#

• 理解 benchmark：SWE-bench 是让 Agent 修复真实 GitHub issue，跑测试验证（它只测代码库这一个维度，测什么/局限见 1-概念 Q10）
• 能力建设：Repo Context 管理、Test Loop、File Edit、Patch Apply
• 微调策略：针对 SWE-bench 的常见模式优化 prompt
• 避免过拟合：用 SWE-bench Verified 子集、报 pass@1，不为刷榜 overfit，要在真实场景验证

过拟合代价：刷榜分数高但真实场景效果差——benchmark 不能完全代表业务能力，且训练数据可能已污染（issue/PR 被爬过）。

Q4（Workflow/Platform）：如何做 durable execution + 版本化工作流 + 灰度？trace 如何转 dataset？#

参考答案

Durable Execution#

• 状态持久化：每步 checkpoint 到 DB
• 进程崩溃恢复：从最近 checkpoint 续跑
• 长任务支持：几小时/几天任务，心跳保活
• 超时/重试：每步设超时，失败重试有上限

版本化工作流#

• 语义化版本：v1.2.3（major.minor.patch）
• 旧版本兼容：旧版本任务还在跑时，新版本不能 breaking change
• 同时多版本：不同 tenant 用不同版本（迁移期）

灰度发布#

10% 流量 → 新版工作流
  ↓ 监控指标 (成功率/成本/延迟)
90% 旧版
  ↓
指标 OK → 切到 50% → 100%
指标差 → 回滚到旧版

Trace 转 Dataset#

[线上 Run] → [Trace 记录] → [抽取 input/output]
       ↓
[人工标注 golden] → [加入回归集]
       ↓
[发版前必跑] → [保证同样 bug 不再发生]

Q5（Tool/MCP）：如何设计工具事务与回滚？如何防 Confused Deputy？A2A 何时引入？#

参考答案

工具事务与回滚#

问题：多个工具组合调用，要保证原子性（要么都成功，要么都回滚）。

方案：

• Saga 模式：每个工具调用记录 compensating action（撤销操作）
• 状态校验：执行前后状态对比，发现不一致就回滚
• 失败处理：任一步失败，按反向顺序执行 compensating action

# 转账 = 扣款 + 加款
compensations = []
try:
    deduct_result = call_tool("deduct", {from: A, amount: 100})
    compensations.append(("refund", {to: A, amount: 100}))
    
    add_result = call_tool("add", {to: B, amount: 100})
    compensations.append(("deduct", {from: B, amount: 100}))
    
except ToolError:
    # 反向执行补偿
    for comp in reversed(compensations):
        call_tool(*comp)

防 Confused Deputy#

Tool/MCP 岗位落地要点：每任务 scoped token（任务结束失效）+ 按请求者身份而非 server 身份鉴权 + 严禁把客户端 token 透传给上游（校验 token audience + PKCE）+ 审计每条调用 + 敏感操作二次确认。完整定义、为何在 Agent 里危害放大（持权方常是 Agent 本身、prompt injection 为头号触发手段）见 3-原理 Q11。

A2A 何时引入#

• 何时引入：多 Agent 跨系统协作（我的 Agent 调用你的 Agent）——A2A 已是 Linux Foundation 下 v1.0 稳定标准（见 1-概念 Q6）
• 何时不引入：单 Agent 内部的工具调用（用 MCP 就够）
• 判断：调用方有自主决策能力 → A2A；调用方是无决策的工具 → MCP

Q6（Personal Agent）：如何设计技能供应链安全？OAuth 与设备权限如何最小化？如何保护长期记忆？#

参考答案（本题为「技能供应链 + 长期记忆保护」的规范条目，5-方案 Q5 引用此处）

技能供应链安全（四件套）#

1. 来源审核：白名单机制，只装可信来源
2. 安装审计：静态扫描（subprocess/curl/eval）+ 依赖检查（typo-squatting）+ 权限审查
3. 隐藏脚本/外部依赖/越权声明检测：扫所有 .py 文件、查 requirements.txt、审 skill.yaml
4. 技能扫描与回滚隔离：VirusTotal 查、ClawScan 静态分析、首次沙箱试运行、出错能回滚

OAuth 与设备权限最小化#

OAuth：

• 不存用户密码，存 token
• 最小化 scope（邮件技能只申请 mail.send，不要 mail.read.all）
• token 定期刷新、过期管理
• 多账户隔离（每个 OAuth 凭证独立存储）

设备权限：

• 每任务 scoped 权限（任务结束撤销）
• 最小必需（review 技能不该要网络权限）
• 用户安装时显式确认权限声明

保护长期记忆#

风险：恶意技能悄悄写记忆（如"user_preference: always_cc_attacker@example.com "），且会跨会话累积放大（见 3-原理 Q11）

防护：

• 写入审核：敏感字段（email/cc/账号/路径）必须人工确认
• 记忆审计：记录每次写入（who/when/what/which_skill）
• 记忆回滚：恶意技能污染后能恢复（卸载时自动撤销该技能的记忆写入）
• 隔离：技能记忆与用户核心记忆隔离，技能记忆可清空不影响核心
• 读回再校验：从记忆读出的内容进入敏感操作前重新校验，别默认可信

Q7（Safety/Eval）：如何做轨迹级回归评测？如何做红队/prompt injection 测试？如何建工具调用风险模型？#

参考答案

轨迹级回归评测#

目标：不只看最终结果，看完整轨迹是否合理。

步骤：

1. 标注 golden trajectory：每个测试用例标注期望的步骤序列
2. 多维评测：
   • 任务成功率（最终是否完成）
   • 工具选择准确率（每步选对工具吗）
   • 参数填写准确率（每步填对参数吗）
   • 轨迹合理性（步骤顺序/数量合理吗，LLM-as-a-Judge，需处理位置/啰嗦/自我偏好偏差，见 3-原理 Q14）
3. 回归集：线上失败 → 转 eval case → 发版前必跑
4. 基准对比：跑 τ-bench/SWE-bench/Terminal-Bench/GAIA/WebArena 横向对比（各测什么见 1-概念 Q10）

红队 / Prompt Injection 测试#

红队流程：

1. 攻击库建设：收集 prompt injection 攻击样本（直接/间接/越狱）
2. 自动化测试：用攻击库批量测 Agent，跑攻击成功率（ASR）
3. 人工红队：模拟攻击者视角，构造新攻击
4. 失败分析：哪些攻击成功？为什么？怎么修？
5. 回归：修复后加入回归集，保证不再犯

测试维度（直接/间接注入拆解、dual-LLM 防御见 1-概念 Q11）：

• 直接注入（用户输入藏恶意指令）
• 间接注入（检索内容/工具返回/邮件/网页藏恶意指令）——Agentic 头号威胁
• 越狱（绕过 system prompt 约束）
• 越权（哄骗 Agent 调不该调的工具，即 Confused Deputy，见 3-原理 Q11）
• 供应链（恶意技能注入）

工具调用风险建模#

每个工具的风险维度：

风险评分：综合各维度算分，按分定权限级别（自动 vs 人工审批 vs 多人审批）。

审计：所有调用记 who/when/what/where/why/permission_check/approval，可追溯。