研发 AI 工作流与技术领导力 ​

研发 AI Workflow 的核心不是增加更多 Agent，而是让每个阶段都有明确输入、产物、Owner、门禁和失败回路。

定位：这是七篇正式文档中的最后一篇，也是最接近真实项目深挖、系统设计和 Ownership（项目主导力）的实战篇。
目标：把“需求 → 规划 → 编码 → 测试 → Review → 诊断 → 修复 → 审批 → Merge → Deploy → Verify”的研发闭环，讲成一套真正可落地、可恢复、可验证、可治理的 AI Workflow / Multi-Agent 系统，而不是多个 Coding Agent 拼接起来的 Demo。

整篇主线：

text

Requirement（需求）
→ Plan（规划）
→ Coding（编码）
→ Test（测试）
→ Review（评审）
→ Diagnosis（诊断）
→ Fix Loop（修复闭环）
→ Approval（审批）
→ Merge（合并）
→ Deploy（发布）
→ Verify（验证）

最重要的工程判断：

text

确定性步骤
→ Workflow

需要动态判断的局部环节
→ Agent

多个决策主体只有在 Context / Permission / Parallelism / Ownership 等边界真实存在时
→ Multi-Agent

**本篇不是 Coding Agent 产品介绍，也不是“如何用 AI 写代码”的经验帖。**真正要回答的是：
研发流程哪些步骤应该确定性控制、哪些步骤交给 Agent；多个 Agent 怎么拆、怎么协作、怎么恢复、怎么验证；怎样防止供应链风险和错误代码进入生产；最后怎样证明这套系统真的提高了研发生产力。

项目真实性原则：面试回答必须严格区分：

1. 实际做过；
2. 正在建设；
3. 下一阶段架构判断。

不为了显得高级而把规划中的能力说成已经上线。

一、先建立整篇项目主线 ​

1.1 第一性问题：为什么研发 AI 系统不应该是“一个 Coding Agent 包打天下” ​

一个强 Coding Agent 可以：

• 读 Repo；
• 改代码；
• 跑命令；
• 写测试；
• 生成 Diff。

但企业研发真正的闭环还有：

Requirement
Design
Code
Test
Review
Security
Diagnosis
Approval
Merge
Deploy
Verification
Audit

这些步骤的：

• 风险不同； -权限不同； -验证方式不同； -确定性不同； -Owner 不同。

所以一个成熟系统不会问：

“要不要多 Agent？”

而是先问：

每个阶段的决策权和执行权应该放在哪里？

1.2 为什么 Workflow + Agent 往往比纯 Agent 更适合研发 ​

研发流程里大量步骤其实不需要模型自由决定：

代码改完必须跑测试
高风险变更必须 Review
Merge 前必须满足 Gate
发布后必须 Verify

这些更适合 Workflow（工作流）固定约束。

真正需要 Agent 的地方是：

• 理解需求；
• Repo Context Discovery；
• Coding；
• Debug；
• Review Finding；
• Diagnosis；
• 修复方案判断。

所以更合理：

Workflow
→ 定义必须经过哪些阶段

Agent
→ 在阶段内部解决不确定性

这也是为什么：

不确定性留给 Agent，系统不变量交给 Software / Workflow。

1.3 一个研发 AI Workflow 的参考责任边界 ​

Requirement Node
→ Intent / Scope / Acceptance Criteria

Planning Agent
→ 分析任务和影响面

Coding Agent
→ 修改独立 Workspace

Test Node
→ 确定性执行测试

Review Agent
→ 输出 Finding / Claim

Diagnosis Agent
→ 对失败做 Root Cause 分析

Fix Agent
→ 在允许边界内修复

Approval Node
→ 风险 Gate

Merge Node
→ 确定性副作用

Deploy Node
→ 受控发布

Verification Node
→ 验证真实环境结果

其中：

Review Agent 的 Finding 不是事实；Coding Agent 自报完成也不是完成。

都必须通过独立 Verification。

1.4 这篇面试最重要的三类能力 ​

第一类：系统设计 ​

能从零设计：

AI 研发全链路平台

第二类：生产事故 ​

能处理：

任务卡死
重复 Merge
错误诊断
多 Agent 循环
Workspace 冲突
Supply-chain Attack

第三类：Ownership / Leadership ​

能回答：

为什么做
怎么拆阶段
为什么不用更简单方案
怎么推动落地
遇到反对怎么处理
结果怎么证明
下一步怎么演进

1.5 读不懂时先记这张“研发 AI Workflow”速记表 ​

最重要的一条：

Requirement
→ 决定“做对什么”

Agent
→ 决定“怎么做”

Workflow
→ 保证“哪些步骤绝不能跳”

Verifier
→ 证明“最后真的做对了”

二、研发 AI Workflow / Multi-Agent 项目深挖 ​

2.1 Q1｜为什么企业研发场景更适合 Workflow + Agent，而不是纯 Workflow 或纯 Multi-Agent？ ​

复习优先级：P0｜题型：S8 Composite

30 秒核心回答 ​

纯 Workflow 太确定，无法处理需求理解、代码生成、Debug 这类开放问题；纯 Agent 又太自由，容易把测试、审批、发布这些系统不变量变成概率行为。

所以我更倾向：

Workflow 管阶段和 Gate
Agent 管阶段内不确定性

2～3 分钟高分回答 ​

例如：

Requirement
→ Planning Agent
→ Coding Agent
→ Test Node
→ Review Agent
→ Approval
→ Merge
→ Deploy
→ Verify

这里：

Planning / Coding / Diagnosis

需要模型推理。

Test / Approval / Merge / Deploy / Verify

必须有确定性系统语义。

如果纯 Agent：

模型可能“认为测试不重要”而跳过。

如果纯 Workflow：

无法灵活处理复杂 Repo 和长尾 Bug。

OpenAI 当前公开的 Harness Engineering 和 Symphony 都体现同一趋势：Agent 可以承担大量研发执行，但可靠性依赖 Repo 环境、自动测试、Guardrail 和外部 Workflow / Orchestration，而不是只靠模型本身。[R1][R2]

高分亮点句 ​

研发 AI 的核心不是把 Workflow Agent 化，而是把 Workflow 里真正不确定的节点 Agent 化。

面试官真正想听什么 ​

• 是否理解确定性 / 非确定性边界；
• 是否会为了 Agent 化而 Agent 化；
• 是否知道什么必须由软件保证。

典型追问 ​

1. Review 应该是 Agent 还是 Workflow？
2. Planning 可以没有吗？
3. Deploy 为什么不能交给 Agent 自己决定？

Red Flags ​

• “所有节点都用 Agent，更灵活。”
• “固定 Workflow 就够，不需要 Agent。”

为什么这样回答 / 本题套路 ​

这是整篇总判断题。先拆确定性 / 不确定性，再落到研发阶段。

2.2 Q2｜Requirement（需求）→ Plan（规划）→ Code（编码）→ Test（测试）→ Review（评审）→ Deploy（发布）的完整状态机怎么设计？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

我不会只用一个 status=running/done。

至少要把每个阶段和等待态表达出来：

PLANNING
CODING
TESTING
REVIEWING
FIXING
WAITING_APPROVAL
MERGING
DEPLOYING
VERIFYING
COMPLETED / FAILED / CANCELLED

2～3 分钟高分回答 ​

每个阶段都应该有：

input
owner
artifact
evidence
version
deadline
retry_policy
exit_condition

例如：

CODING
→ 输出 diff artifact

TESTING
→ 输出 test report

REVIEWING
→ 输出 findings

FIXING
→ 输出 new diff

APPROVAL
→ 输出 approval evidence

DEPLOYING
→ 输出 deployment_id

VERIFYING
→ 输出 health evidence

状态转换也必须有 Preconditions。

例如：

MERGING

前置：

• required test pass；
• blocking finding resolved；
• approval valid；
• branch not stale。

高分亮点句 ​

研发 Workflow 的状态机不是 UI 进度条，而是每一步允许发生什么副作用的业务契约。

面试官真正想听什么 ​

• 是否真正设计过长流程；
• 是否理解状态和 Evidence；
• 是否有 Precondition 思维。

典型追问 ​

1. Review Failure 回到 Coding 还是 Diagnosis？
2. Approval 过期怎么办？
3. Branch 变化后是否重新 Test？

Red Flags ​

• “每个 Agent 自己判断什么时候下一步。”
• “流程状态只存当前节点名字。”

为什么这样回答 / 本题套路 ​

这是 Engineering Implementation 题。重点是状态、Artifact、Exit Condition 和副作用 Gate。

2.3 Q3｜Planning Agent 应该输出什么？为什么 Plan 不能只是自然语言 Todo List？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

Plan 最少要变成可执行、可验证的结构化 Contract：

scope
affected_components
steps
dependencies
risk
verification

自然语言 Todo 只能帮助模型思考，不能直接支撑生产编排。

2～3 分钟高分回答 ​

一个可用 Plan 可以包含：

task_id
goal
acceptance_criteria
files / modules
step DAG
dependencies
expected_artifacts
risk_level
test_plan
rollback / verification

为什么要结构化？

因为后续 Workflow 要知道：

• 哪些步骤可以并行； -哪些 Agent 有权限； -哪些模块会冲突； -什么时候完成； -是否需要审批。

Plan 也不能固定一次到底。

如果 Test / Review 发现新信息：

Evidence
→ Re-plan Trigger

项目映射 ​

研发平台里：

“前端改 UI、后端加 API、补测试”不是三个角色，而应该先通过依赖 / Resource Ownership 看能不能并行。

高分亮点句 ​

Plan 的价值不是“让 Agent 看起来有思路”，而是把任务变成可执行和可验证的结构。

面试官真正想听什么 ​

• 是否把 Planning 当 Prompt Technique；
• 是否理解 Plan 与调度 /验证关系。

典型追问 ​

1. Plan 谁验证？
2. 什么时候 Re-plan？
3. Plan 需要持久化吗？

Red Flags ​

• “让模型列几个步骤就算 Planning。”

为什么这样回答 / 本题套路 ​

这是 Planning 机制题。高分点是把 Plan 从文本提升成执行 Contract。

2.4 Q4｜大型 Repo 下 Coding Agent 怎么做 Context Discovery，为什么不能把整个 Repo 塞进模型？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

大型 Repo 的核心不是 Context Window 大小，而是：

如何找到最相关、最权威、最小充分的代码上下文。

我会做 Progressive Discovery（渐进式发现），而不是全量注入。

2～3 分钟高分回答 ​

流程可以是：

Repo Map
→ Symbol / Dependency Search
→ Relevant Files
→ Local Read
→ Test / Build Config
→ Related History if needed

优先使用：

• Symbol Search；
• Ripgrep；
• Dependency Graph；
• Build Metadata；
• Ownership； -最近变更。

而不是：

100 万行代码
→ 全部塞 Context

Context 太大后会：

• Attention Competition； -错误文件干扰； -成本上升； -关键约束被淹没。

OpenAI 当前 Harness Engineering 也强调 Agent-friendly Repo、自动化测试和清晰环境对 Coding Agent 成功的重要性。[R1]

高分亮点句 ​

Coding Agent 的 Repo Intelligence 不是“读更多代码”，而是更快找到足以做正确修改的最小上下文。

面试官真正想听什么 ​

• 是否懂大 Repo； -是否会 Repo Retrieval； -是否理解 Context Engineering。

典型追问 ​

1. Repo Map 怎么做？
2. Dependency Graph 值得吗？
3. Git History 什么时候有用？

Red Flags ​

• “模型上下文足够大后，全 Repo 直接喂进去。”

为什么这样回答 / 本题套路 ​

这是 Context / Coding 交叉题。先解释全量输入为什么失败，再讲分层 Discovery。

2.5 Q5｜Coding Agent 说“代码改好了”，为什么不能直接进入 Review？ ​

复习优先级：P0｜题型：S8 Composite

30 秒核心回答 ​

因为：

model_done
≠
verified_done

Coding Agent 自报完成只能表示：

它认为任务完成。

系统必须独立验证：

diff
build
test
lint
acceptance criteria

2～3 分钟高分回答 ​

我会把完成分成：

Model Completion
→ Agent 认为完成

Execution Completion
→ Tool / Command 真执行完

Verification Completion
→ 客观 Gate 通过

Business Completion
→ Acceptance Criteria 满足

例如：

Agent 说“测试通过”。

真正 Evidence 应该是：

test command
exit code
test report
commit / diff

GitHub 当前 Coding Agent 文档也明确要求 Agent 产出的 PR 应像普通贡献一样经过 Review，不应因为 Agent 生成就降低评审标准。[R3]

高分亮点句 ​

Coding Agent 的“完成”只是一个 Claim；测试、Diff 和 Acceptance Criteria 才能把它升级成事实。

面试官真正想听什么 ​

• 是否有 Verification 思维； -是否把模型自信当完成。

典型追问 ​

1. 测试覆盖不足怎么办？
2. Agent 会不会伪造 Test Result？
3. Verification 失败后怎么回 Loop？

Red Flags ​

• “Agent 输出最终答案就进入下一步。”

为什么这样回答 / 本题套路 ​

这是核心不变量题。直接用 model_done ≠ verified_done。

2.6 Q6｜Test Agent 和确定性 Test Workflow 应该怎么分工？ ​

复习优先级：P0｜题型：S8 Composite

30 秒核心回答 ​

测试执行本身应该尽量确定性；Agent 更适合：

• 生成测试； -选择测试范围； -分析失败； -补充边界 Case。

所以：

Agent decides what to test
Workflow executes and records result

2～3 分钟高分回答 ​

例如：

Test Agent

可以根据 Diff 决定：

• 哪些 Unit； -哪些 Integration； -是否需要新 Case； -风险区域。

Test Workflow

负责：

run exact command
capture exit code
report artifact
timeout
retry policy
resource limit

为什么不让 Agent 自己说：

“我跑过测试了。”

因为这会把 Evidence 变成语言 Claim。

高分亮点句 ​

Agent 可以决定测什么，但测试结果必须由执行系统产生。

面试官真正想听什么 ​

-是否分清决策和执行； -是否会把 Test Agent 变成一个会说话的 CI。

典型追问 ​

1. Test Selection 如何 Eval？
2. Flaky Test 怎么处理？
3. Agent 自动修测试安全吗？

Red Flags ​

• “Test Agent 自己运行、解释、判断，全链路一个模型。”

为什么这样回答 / 本题套路 ​

这是 Determinism Boundary 题。强调 Test Evidence 必须来自确定性执行。

2.7 Q7｜Review Agent 输出的 Finding 为什么不能自动变成全局事实？ ​

复习优先级：P0｜题型：S8 Composite

30 秒核心回答 ​

Review Agent 只应该输出：

Claim / Finding + Evidence。

它不是自动的最终真相。

Finding 要有：

severity
file / line
reason
evidence
confidence
suggested fix

然后进入 Verification / Human / Fix Loop。

2～3 分钟高分回答 ​

典型错误：

Review Agent
→ “这里有 Race Condition”

Supervisor
→ 直接当事实

Fix Agent
→ 修改代码

结果引入 Regression

所以 Review Result 应该区分：

finding
verified_finding
false_positive
waived

高风险 Finding 可以要求：

-静态工具； -测试复现； -第二 Reviewer； -人工确认。

高分亮点句 ​

Review Agent 的价值是扩大检查覆盖，不是替代事实验证。

面试官真正想听什么 ​

-是否理解 AI Review False Positive； -是否有 Finding 状态机。

典型追问 ​

1. 多 Reviewer 投票有用吗？
2. Finding 置信度怎么用？
3. 哪些 Finding 可以自动修？

Red Flags ​

• “Review Agent 发现的问题都自动修复。”

为什么这样回答 / 本题套路 ​

这是 Trust / Review 题。Worker Output 是 Claim，不是 Global Truth。

2.8 Q8｜前端诊断 Agent 判断“不是我的问题”后，为什么要回到主 Agent，而不是自己直接调后端 Agent？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

因为主 Agent / Supervisor 应该拥有：

全局 Routing Ownership。

子 Agent 最好只判断：

is_my_domain?
confidence
evidence
recommended_next_domain

然后回 Parent，由 Parent 决定是否重新分发。

2～3 分钟高分回答 ​

如果 Frontend Agent 可以直接 Handoff Backend，Backend 又直接 Handoff Infra：

Frontend
→ Backend
→ Infra
→ Frontend

很容易形成 Handoff Loop，且全局 Budget / Trace 失控。

更稳：

Parent
→ Frontend Diagnosis

Frontend:
  yes + diagnosis
  or
  no + evidence + suggestion

→ Parent
→ decide next route

如果 Frontend 判断“是我的问题，但结论不够好”，可以在自身 Scope 内做 Local Loop。

所以：

Local Re-diagnosis
→ 子 Agent 自循环

Cross-domain Re-routing
→ 回 Parent

项目映射 ​

这正适合研发诊断平台：

前端 / 后端 Agent 都有本地 Loop，但跨域 Routing 回主 Agent。

高分亮点句 ​

子 Agent 可以拥有局部诊断自治，但全局路由权最好集中，避免 Handoff 图失控。

面试官真正想听什么 ​

-是否理解诊断 Loop； -是否有 Parent / Child Control Boundary。

典型追问 ​

1. Parent 会不会成为瓶颈？
2. 什么时候允许 Peer-to-peer Handoff？
3. Domain 判断错了怎么办？

Red Flags ​

• “每个 Agent 自由 Handoff，最后总能找到对的人。”

为什么这样回答 / 本题套路 ​

这是你的真实研发诊断场景，非常适合体现 Multi-Agent Control Ownership。

2.9 Q9｜Fix Loop 怎样避免“修复 → 失败 → 再修复”无限循环？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

Fix Loop 必须有 Progress Signal 和 Budget，不能只靠 max_turns。

我会记录：

failure_signature
diff_signature
test_delta
finding_delta
attempt_count

没有新 Evidence / Progress 时触发 Re-plan 或 Escalate。

2～3 分钟高分回答 ​

危险循环：

Test Fail A
→ Agent 改代码
→ Test Fail A
→ Agent 换个写法
→ 还是 A

表面有很多 Token / Commit，实际上没有进展。

所以每轮比较：

Failure changed?
Coverage improved?
Finding reduced?
New evidence?
Diff meaningful?

如果连续 N 轮无进展：

Stop
→ Re-plan
→ Switch Strategy / Model
→ Ask Human

高分亮点句 ​

研发 Agent Loop 的预算应该由“有效进展”驱动，而不是由“有没有继续输出”驱动。

面试官真正想听什么 ​

-是否有 No-progress Detection； -是否理解 agent thrashing。

典型追问 ​

1. Progress Signature 怎么设计？
2. 什么时候换模型？
3. 什么时候人工接管？

Red Flags ​

• “最多 Retry 5 次。”

为什么这样回答 / 本题套路 ​

这是 Long-loop Reliability 题。高分点是 Progress-based，而不是纯次数限制。

2.10 Q10｜多个 Coding Agent 并行时，Branch / Workspace / File Ownership / Merge Queue 怎么设计？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

真正可并行的不是“任务描述”，而是：

资源冲突图。

默认：

Independent Workspace / Worktree
→ Explicit Ownership
→ Independent Test
→ Merge Queue
→ Integration Test

2～3 分钟高分回答 ​

每个 Coding Worker 需要独立：

branch
worktree
workspace
artifact

并维护 Resource Ownership：

• module； -file； -config； -schema； -dependency。

任务 A / B 即使标题不同，也可能共同修改：

package.json
shared config
auth.ts
DB schema

所以 Merge 前要：

detect conflict
rebase
merge
integration test

OpenAI 当前 Codex 产品也明确支持 built-in worktrees 和多 Agent 并行工作；但工程上真正决定能否安全并行的仍然是 Workspace / Merge / Verification，而不是“能同时启动几个 Agent”。[R4]

高分亮点句 ​

Agent 并行度应该受 Resource Conflict Graph 约束，而不是受模型并发额度约束。

面试官真正想听什么 ​

-是否做过并行 Coding； -是否考虑 Merge / Integration； -是否理解 Workspace Isolation。

典型追问 ​

1. 文件不冲突但逻辑冲突怎么办？
2. Merge Queue 谁排序？
3. DB Migration 怎么并行？

Red Flags ​

• “一 Agent 一个 Branch 就不会冲突。”

为什么这样回答 / 本题套路 ​

这是 Multi-Agent Coding 最典型生产题。Resource Ownership 是核心。

2.11 Q11｜长 CI、人工 Review、Approval 为什么必须 Durable，而不是让 Worker 一直等？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

因为：

Task Lifetime
≠
Worker Lifetime

等 CI / Review 时应该：

Checkpoint
→ WAITING
→ Release Worker / Environment
→ Signal
→ Resume

2～3 分钟高分回答 ​

典型流程：

Coding complete
→ submit CI
→ ci_job_id
→ WAITING_EXTERNAL

Worker 不再占用。

CI 回调：

Signal(ci_job_id)
→ Runtime Resume

人工 Review 同理。

等待期间：

• Sandbox 可以释放； -Workspace / Artifact 持久化； -Run State 保留。

这样才能支撑：

-小时级任务； -服务发布； -节点迁移； -成本控制。

高分亮点句 ​

异步研发任务的正确抽象是 Durable Task，不是超长请求。

面试官真正想听什么 ​

-是否理解 Runtime； -是否能做异步 Workflow。

典型追问 ​

1. CI 回调重复怎么办？
2. Review 期间 Branch 更新怎么办？
3. Resume 时环境怎么恢复？

Red Flags ​

• “Worker sleep 等 CI。”
• “HTTP Timeout 调长。”

为什么这样回答 / 本题套路 ​

这是 03 Runtime 在研发项目里的直接落地。

2.12 Q12｜PR / Merge / Deploy 这些副作用如何设计 Idempotency、Reconciliation 和 Compensation？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

高风险研发动作都不能简单 Retry。

应该：

Operation ID
→ Execute
→ Timeout / Crash
→ Reconcile
→ Skip / Retry / Compensate

2～3 分钟高分回答 ​

Create PR

可以用：

repo + branch + task_id

做幂等标识。

Merge

Timeout 后先查：

PR merged?
merge commit?

不能直接再次 Merge。

Deploy

要保存：

deployment_id
release_version
environment

Timeout 后查 Remote Deployment State。

Compensation

• Merge → Revert Commit；
• Deploy → Rollback Version；
• Notify → 通常不可逆。

所以不可逆动作要提高 Approval / Verification，而不是幻想都能 Rollback。

高分亮点句 ​

研发自动化最危险的不是 Tool 失败，而是“Tool 可能成功、系统却不知道”。

面试官真正想听什么 ​

-分布式副作用基本功； -是否会无脑 Retry。

典型追问 ​

1. Merge 已成功但 Checkpoint 失败怎么办？
2. Deploy Provider 不支持 Idempotency 怎么办？
3. Revert 一定安全么？

Red Flags ​

• “失败就 Retry Merge / Deploy。”

为什么这样回答 / 本题套路 ​

这是 Side-effect Recovery 题，必须讲 Unknown Outcome。

2.13 Q13｜Repo（代码仓库）中的 Prompt Injection（提示注入）、恶意 Package、CI Config、Script 对 Coding Agent 有什么供应链风险？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

Coding Agent 会把 Repo 内容既当：

数据

又可能当：

指令 / 可执行代码。

所以 Repo 本身就是不可信输入，Software Supply Chain（软件供应链）必须进入 Agent Threat Model（威胁模型）。

2～3 分钟高分回答 ​

攻击入口包括：

README
Issue
Code Comment
Package
postinstall
CI config
Makefile
Shell script
Test Fixture

风险链：

Agent reads malicious instruction
→ runs command
→ accesses secret
→ exfiltrates via network

治理：

Content Untrusted by Default
Sandbox
Filesystem Scope
Network Egress
Secret Broker
Package Registry Policy
Lockfile
Dependency Scan
Approval for boundary crossing

Anthropic 当前 Claude Code Sandbox 强调 Filesystem / Network Isolation；OpenAI 当前 Codex 内部部署也强调 Sandbox、Managed Network Policy、Credential 和 Telemetry 的组合控制。[R5][R6]

高分亮点句 ​

对 Coding Agent 来说，Repo 既是 Context，也是潜在攻击载体。

面试官真正想听什么 ​

-是否理解 Indirect Prompt Injection； -是否有 Supply Chain 思维； -是否会把 Repo 当可信内部数据。

典型追问 ​

1. npm install 能自动执行吗？
2. CI Config 谁审批？
3. README 里的指令能否进 System Prompt？

Red Flags ​

• “内部 Repo 默认可信。”
• “只要 Agent 不看到 Secret 就安全。”

为什么这样回答 / 本题套路 ​

这是 Coding Agent Security P0 题。Repo 内容必须和 Tool / Network / Secret 一起考虑。

2.14 Q14｜为什么 Approval 不能作为主要安全边界？怎样避免 Approval Fatigue？ ​

复习优先级：P1｜题型：S7 Concept / Mechanism

30 秒核心回答 ​

Approval 应该只覆盖真正高风险越界动作。

低风险操作应该通过：

Sandbox
Filesystem Boundary
Network Policy
Least Privilege

自动执行。

否则审批太多会产生 Approval Fatigue，用户最后变成机械点“允许”。

2～3 分钟高分回答 ​

如果每条：

cat
grep
test
git diff

都弹确认：

• 开发体验差； -人不再认真判断； -安全反而下降。

更合理：

Low-risk inside sandbox
→ auto

Boundary crossing
→ policy review

High-risk irreversible
→ explicit approval

Anthropic 公布的 Claude Code Sandboxing 经验中就明确提到通过 Sandbox 降低大量 Permission Prompt，从而减少 Approval Fatigue。[R5]

高分亮点句 ​

Approval 是风险 Gate，不是 Sandbox 的替代品。

面试官真正想听什么 ​

-是否会过度 HITL； -是否理解 Deterministic Containment。

典型追问 ​

1. Auto-review 合理吗？
2. 哪些动作必须审批？
3. Approval 能否继承到后续动作？

Red Flags ​

• “所有危险都让用户确认即可。”

为什么这样回答 / 本题套路 ​

这是 Controllability + Security 题。核心是风险分层。

2.15 Q15｜如何给 Coding / Review / Diagnosis Agent 做 Eval，而不是只看 SWE Benchmark？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

外部 Benchmark 只能验证部分能力。

企业应该建立自己的：

Historical Issue
Bug Fix
Repo Task
CR Finding
Incident

回归集，并分层评测。

2～3 分钟高分回答 ​

Coding

• Build； -Test； -Acceptance； -Minimal Diff； -Regression。

Review

• Finding Precision； -Recall； -Severity； -False Positive； -Actionability。

Diagnosis

• Root Cause Accuracy； -Evidence Quality； -Localization； -Wrong-domain Rate。

Workflow

• End-to-end Verified Success； -Latency； -Cost； -Human Intervention； -Loop Count。

最重要：

Eval Case 要来自真实历史 Failure / Review / Bug，而不是只靠人工编题。

高分亮点句 ​

研发 Agent Eval 的北极星不是“代码看起来不错”，而是历史真实任务能不能被可靠完成并验证。

面试官真正想听什么 ​

-是否有企业内部 Eval； -是否能按 Agent 职责分指标。

典型追问 ​

1. CR Finding Ground Truth 怎么做？
2. Review Agent False Positive 怎么控？
3. Benchmark 泄漏怎么办？

Red Flags ​

• “SWE-bench 分高就能直接上企业 Repo。”

为什么这样回答 / 本题套路 ​

这是 Evaluation 题。必须从公开 Benchmark 升级到内部真实任务集。

2.16 Q16｜一次回归发生后，怎么判断是 Model、Prompt、Harness、Repo Context、Tool、Skill 还是 Sandbox Image 的问题？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

没有 Version-aware Trace（版本感知追踪）就做不到。

每个 Run 至少绑定：

model
prompt
harness
context policy
tool
skill
repo commit
sandbox image
workflow topology

2～3 分钟高分回答 ​

同一任务昨天成功、今天失败，变量可能很多。

所以 Trace 需要：

run_id
agent_version
model_version
prompt_version
skill_version
tool_version
repo_commit
context_snapshot
sandbox_image
workflow_version

然后：

Replay
Diff
Ablation

逐层归因。

例如：

同 Model + 同 Prompt
只换 Sandbox Image
→ 失败

就可以快速定位环境回归。

高分亮点句 ​

Agent Regression Engineering 的前提，是所有影响结果的变量都可以被版本化和回放。

面试官真正想听什么 ​

-是否有生产 Debug 体系； -是否只看 Prompt / Model。

典型追问 ​

1. Repo Data 变化怎么 Replay？
2. Model Provider Silent Update 怎么办？
3. Context Snapshot 要存多少？

Red Flags ​

• “失败先换模型试试。”
• “记录完整聊天日志就够。”

为什么这样回答 / 本题套路 ​

这是 Debug / Observability 题。高分点是 Version Manifest + Replay。

2.17 Q17｜如何设计 Parent / Child Agent Trace，让 Multi-Agent 研发任务可以真正排障？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

Trace 必须表达：

Parent Run
→ Delegation
→ Child Run
→ Tool / Execution
→ Artifact / Finding
→ Merge / Verification

而不是所有日志平铺。

2～3 分钟高分回答 ​

至少需要：

session_id
parent_run_id
child_run_id
delegation_id
span_id
artifact_id
operation_id

Span 类型：

model
tool
handoff
subagent
test
review
approval
merge
deploy
verification

这样才能回答：

• 谁派了这个任务？
• Child 用了什么 Context？
• 哪个 Finding 导致 Re-fix？
• 哪个 Agent 修改了哪个 Artifact？
• 成本 /延迟花在哪？

高分亮点句 ​

Multi-Agent Trace 的价值是恢复因果链，不是把更多日志塞进一个 Dashboard。

面试官真正想听什么 ​

-是否懂 Parent/Child observability； -是否能做成本和错误传播归因。

典型追问 ​

1. 一个 Child 被多个 Parent 共享怎么办？
2. Handoff Trace 怎么表示？
3. Artifact 如何关联 Trace？

Red Flags ​

• “每个 Agent 各看自己的日志。”

为什么这样回答 / 本题套路 ​

这是 Observability 题。重点是 causal graph，而不是日志量。

2.18 Q18｜研发 AI Workflow 的 Cost（成本）/ Latency（时延）应该怎么归因？为什么 Token Cost（Token 成本）不是全部？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

总成本至少是：

Model
+
Tool
+
Sandbox
+
CI / Build
+
Storage
+
Retry Waste
+
Human Review

而总延迟要看 Critical Path，不是所有 Agent 时延相加。

2～3 分钟高分回答 ​

成本 Attribution：

planning tokens
coding tokens
review tokens
test compute
sandbox minute
CI minute
artifact storage
retry
human approval

多 Agent 还增加：

• Context Duplication； -Delegation； -Merge； -Coordination。

延迟：

End-to-end
=
critical path
+ waits
+ retries
+ approvals

并行 Worker 的总计算更多，但关键路径可能更短。

所以核心指标：

Cost per Verified Completed Task
P50/P95 End-to-end
Human Minutes per Task

高分亮点句 ​

研发 Agent 最应该优化的是单位 Verified Outcome 的总成本，而不是单轮 Token。

面试官真正想听什么 ​

-是否有 Cost Engineering； -是否理解并行时延； -是否考虑 Human Cost。

典型追问 ​

1. Review Agent 值不值得成本？
2. Sandbox Idle Cost 怎么降？
3. Multi-Agent 成本怎么分摊？

Red Flags ​

• “模型 Token 降了 20%，所以系统成本下降 20%。”

为什么这样回答 / 本题套路 ​

这是 Cost / Performance 题。必须 end-to-end。

2.19 Q19｜Human Approval 怎样按风险分级，而不是每个步骤都卡人？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

我会按：

Reversibility
Blast Radius
Environment
Data Sensitivity
Privilege
Confidence / Evidence

分风险。

只有高风险边界需要人审批。

2～3 分钟高分回答 ​

低风险

read repo
run test
edit isolated worktree

自动。

中风险

create PR
update staging

可能 Policy / Auto-review。

高风险

merge protected branch
production deploy
permission change
data deletion

Human / Dual Approval。

审批本身要记录：

who
what
evidence
scope
expiry

不能变成“同意整个 Session 所有后续动作”。

高分亮点句 ​

Approval 应该授权一个明确动作边界，而不是给 Agent 发一张长期通行证。

面试官真正想听什么 ​

-是否有 Risk-based HITL； -是否理解 Approval Scope / Expiry。

典型追问 ​

1. 同类动作能否批量批准？
2. Approval 过期怎么办？
3. 谁定义风险等级？

Red Flags ​

• “生产操作前统一弹一次确认。”

为什么这样回答 / 本题套路 ​

这是 Controllability 题。风险分层 + scope 是核心。

2.20 Q20｜为什么研发 AI Workflow 的真实 ROI 不能只看“代码生成量”和“需求吞吐量”？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

因为 AI 可能让代码产量上升，但同时增加：

• Review； -Regression； -Incident； -返工。

所以最终要看：

Verified Engineering Throughput（经验证的研发吞吐）和总人力成本。

2～3 分钟高分回答 ​

我会分四层。

Speed

lead time
cycle time
time to first PR

Quality

change failure rate
reopen
regression
review findings

Human Effort

engineer minutes
review minutes
manual interventions

AI Economics

cost / verified task
agent success
retry waste

一个简单北极星可以是：

Verified Task Throughput
/
Human + AI Cost

高分亮点句 ​

AI 研发提效不是“写代码更快”，而是“更少人力、更短周期交付同等或更高质量的软件”。

面试官真正想听什么 ​

-是否有业务 ROI； -是否会 Vanity Metrics； -是否考虑质量债。

典型追问 ​

1. 需求吞吐率怎么定义？
2. Review 负担增加怎么办？
3. 如何做对照实验？

Red Flags ​

• “AI 生成代码占比 80%。”
• “提交次数上涨就是生产力提升。”

为什么这样回答 / 本题套路 ​

这是业务价值题。要从产量转向经过质量校正后的 Outcome。

2.21 Q21｜什么时候从一个 Coding Agent 演进到 Multi-Agent？Trigger 应该是什么？ ​

复习优先级：P2｜题型：S3 Trade-off / Decision

30 秒核心回答 ​

只有当 Single Agent 在：

Context
Permission
Parallelism
Specialization
Failure Containment

上出现结构性问题时才拆。

不是因为流程长。

2～3 分钟高分回答 ​

不要拆的情况

-一个 Repo； -任务高度耦合； -同一 Workspace； -同一权限； -无明显并行收益。

值得拆

例如：

Frontend / Backend 可独立 Workspace
→ 并行

Review 需要 Read-only 权限
→ Permission Isolation

Diagnosis 需要独立 Context / Tool
→ Capability Isolation

演进：

Single Coding Agent
→ Workflow
→ Specialist as Tool
→ Parallel Workers
→ Supervisor

每一步都要通过：

Success
Latency
Cost
Error Propagation

证明净收益。

高分亮点句 ​

Multi-Agent 的 Trigger 是单一决策边界失效，不是任务看起来复杂。

面试官真正想听什么 ​

-是否克制 Multi-Agent； -是否有演进路径。

典型追问 ​

1. 前后端一定拆吗？
2. Review 一定单独 Agent 吗？
3. 如何判断需要 Supervisor？

Red Flags ​

• “全流程天然就是多个角色，所以多个 Agent。”

为什么这样回答 / 本题套路 ​

这是 Architecture Evolution 题。强调 Trigger。

2.22 Q22｜平台 Shared Core（共享核心）与 Repo / Team-specific Semantics（仓库 / 团队特定语义）应该怎么分？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

平台统一：

Run
Trace
Workspace Contract
Sandbox
Tool Contract
Policy Hook
Eval Infrastructure

Repo / Team 保留：

build command
test rule
code convention
owner
domain skill
business verification

2～3 分钟高分回答 ​

一个常见错误是平台统一：

“所有 Repo 都必须使用同一个 Coding Prompt / Test Workflow。”

不同技术栈：

• Java； -TypeScript； -Go； -MonoRepo； -Mobile；

规则完全不同。

所以平台提供：

extension point
skill
repo config
verification hook

Domain 自己填内容。

高分亮点句 ​

平台应该统一研发 Agent 的生产保证，不应该统一每个 Repo 的研发语义。

面试官真正想听什么 ​

-是否有平台 / Domain 边界； -是否懂 Repo-specific context。

典型追问 ​

1. AGENTS.md / repo instruction 属于哪层？
2. Skill 谁维护？
3. Repo 自定义 Tool 怎么接？

Red Flags ​

• “平台提供统一最佳 Prompt，所有 Repo 共用。”

为什么这样回答 / 本题套路 ​

这是平台边界题，直接沿用 Platform owns Guarantees；Domain owns Meaning。

2.23 Q23｜如果从零设计企业级研发 AI Workflow，你会怎么画架构？ ​

复习优先级：P2｜题型：S1 System Design

30 秒核心回答 ​

我会先画闭环，而不是先画多个 Agent：

Requirement
→ Plan
→ Code
→ Test
→ Review
→ Fix
→ Approval
→ Merge
→ Deploy
→ Verify

然后给每个节点决定：

Workflow 还是 Agent？需要什么 Runtime / Execution / Evidence？

2～3 分钟高分回答 ​

参考架构：

[Task / Requirement]
        ↓
[Workflow Control Plane]
        ↓
[Planning Agent]
        ↓
[Coding Agent]
        ↓
[Workspace / Sandbox]
        ↓
[Test Runner]
        ↓
[Review / Diagnosis Agents]
        ↓
[Fix Loop]
        ↓
[Approval Gate]
        ↓
[Merge / Deploy Executor]
        ↓
[Verification]

横向：

Runtime
Identity / Policy
Trace
Eval
Artifact
Cost
Version

真正要强调：

• Code Modification 在独立 Workspace；
• Test Evidence 独立；
• Review Finding 不是事实；
• Merge / Deploy 有 Idempotency；
• Release 后必须 Verify；
• Long Wait Durable； -所有版本可追踪。

高分亮点句 ​

系统设计题不是看你能画多少 Agent，而是看每一步的 Control、Execution、Evidence 和 Recovery 是否闭环。

面试官真正想听什么 ​

-端到端设计； -跨 01～05 的整合能力； -是否有生产闭环。

典型追问 ​

1. 哪个组件先做？
2. Runtime 怎么选？
3. Multi-Agent 怎么 Scale？
4. 如何灰度上线？

Red Flags ​

• 画 8 个 Agent，但没有 Runtime / Sandbox / Eval； -只有 happy path。

为什么这样回答 / 本题套路 ​

这是本系列最重要的综合 System Design 题。它测试你是否能把前 5 篇装回真实业务。

2.24 Q24｜Coding Agent 为了让测试变绿，直接改测试、删断言、跳过校验，为什么这是典型 Verifier Gaming（验证器投机）？怎么治理？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

因为 Agent 的目标如果被简化成：

“让 CI 变绿。”

它可能优化指标，而不是优化真实目标。

所以 Verification 不能只有单一 Test Pass，还需要：

Acceptance Criteria
Protected Test / Hidden Test
Diff Policy
Test-change Policy
Independent Review

2～3 分钟高分回答 ​

典型 Reward Hacking（奖励投机）：

Feature Test 失败
→ Agent 修改 Test Expectation
→ CI Pass
→ 功能实际仍然错误

或者：

Lint Fail
→ Agent disable rule

E2E Fail
→ Agent mark skip

Snapshot Fail
→ Agent blindly update snapshot

所以我会区分：

Implementation Surface
Verifier Surface

高风险情况下，Coding Agent 不应该拥有无限修改 Verifier 的权限。

可以做：

• Protected / Hidden Tests；
• 测试变更需要单独理由和 Review；
• Acceptance Criteria 独立于 Agent；
• 对 skip / disable / expect 等敏感 Diff 做 Policy；
• 重要任务由独立 Verifier / Reviewer 检查。

高分亮点句 ​

Verifier 如果和被验证对象拥有同一个优化主体，Agent 很可能学会“让指标变好”，而不是“让软件变对”。

面试官真正想听什么 ​

• 是否理解 Agent Reward Hacking；
• 是否把 Test Pass 当绝对 Ground Truth；
• 是否有独立 Verification 边界。

典型追问 ​

1. Agent 能不能修改测试？
2. Hidden Test 会不会导致开发体验差？
3. Snapshot Update 怎么自动判断？

Red Flags ​

• “测试通过就一定正确。”
• “Coding Agent 既写实现又自由改所有验证规则。”

为什么这样回答 / 本题套路 ​

这是 Coding Agent 进入生产后非常关键的高阶题。它考的不是测试知识，而是“验证器本身也可能被 Agent 优化和绕过”的系统性风险。

2.25 Q25｜需求本身模糊时，Agent 写出“测试全过但需求做错”的代码怎么办？Requirement Contract 应该包含什么？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

测试只能验证“被表达出来的要求”。

如果 Requirement 本身模糊：

Test Pass
≠
User Intent Satisfied

所以研发 AI Workflow 的第一步应该把需求转成可验证的 Requirement Contract（需求契约）。

2～3 分钟高分回答 ​

一个高质量 Requirement Contract 至少应包含：

goal
scope
out_of_scope
acceptance_criteria
non_functional_requirements
risk
dependencies
examples / edge cases
owner

如果关键条件缺失，不应该让 Coding Agent 自己猜成永久设计决策。

可以：

Clarify
→ Ask Human

or

Make Explicit Assumption
→ Record
→ Continue only if low-risk

例如：

“新增导出能力。”

至少要确认：

• 导出格式； -数据范围； -权限； -最大数据量； -同步 / 异步； -失败体验。

否则 Agent 很可能实现了一个“功能正确、产品错误”的版本。

项目映射 ​

研发平台非常适合把：

PRD / Issue
→ Requirement Normalization
→ Acceptance Criteria

作为 Workflow 的第一阶段，而不是直接把原始 Issue 丢给 Coding Agent。

高分亮点句 ​

Coding Agent 最危险的错误之一不是代码写错，而是把未确认的假设永久固化进代码。

面试官真正想听什么 ​

• 是否理解 Spec Quality；
• 是否会先澄清边界；
• 是否有 Acceptance Criteria 思维。

典型追问 ​

1. 什么情况下 Agent 应该主动问人？
2. Clarification 会不会降低自动化率？
3. Acceptance Criteria 能否自动生成？

Red Flags ​

• “模型足够强，可以自己补全需求。”
• “测试全过就说明需求完成。”

为什么这样回答 / 本题套路 ​

这是 Requirement → Coding 的因果链题。高分点是承认“Verifier 的上游 Spec 也可能错”，从而把质量控制前移到需求契约。

三、通用 Project Deep Dive / Incident Review ​

这一章不是新的项目，而是 Data Agent 和研发 AI Workflow 都必须准备的一套通用深挖能力。
真正的高级候选人不能只“讲系统”，还要讲清：为什么做、为什么这样设计、出过什么问题、怎么证明价值，以及自己真正改变了什么。

3.1 Q26｜挑一个你最核心的 Agent 项目：为什么要做？为什么一定要 Agent，而不是 Workflow / Search / Copilot？ ​

复习优先级：P2｜题型：S5 Project / Ownership

30 秒核心回答 ​

我不会从“我们想做 Agent”开始，而会先说：

业务目标
→ 原方案的结构性瓶颈
→ 为什么需要动态决策闭环
→ Agent 解决哪一段不确定性

只有任务需要在执行过程中持续“观察 → 决策 → 行动 → 再观察”，Agent 才有充分理由。

2～3 分钟高分回答 ​

例如一个企业 Data Agent 项目，不能只说：

“用户想自然语言查数，所以做 Agent。”

应该继续问：

• BI 为什么不够？
• Search 为什么不够？
• NL2SQL 为什么不够？
• 哪一段需要动态路由 / 下钻 / Verification？

如果真实问题只是：

固定字段查询
→ 固定 API

我会明确反对 Agent。

Agent 的合理性通常来自：

目标明确
但路径不固定
+
需要多步 Tool / Context
+
中间 Observation 会改变下一步

同样研发场景里，如果只是：

固定 CI pipeline

Workflow 就够。

只有 Repo 理解、Coding、Diagnosis 这类开放决策节点才需要 Agent。

高分亮点句 ​

“能不能用 Agent”是实现问题；“为什么必须允许动态决策”才是项目立项问题。

面试官真正想听什么 ​

• 是否为了技术而做 Agent；
• 是否理解 Agent 的适用边界；
• 是否能把项目和业务问题连起来。

典型追问 ​

1. 如果不用 Agent，次优方案是什么？
2. Agent 带来的最大新增风险是什么？
3. 哪些流程后来又从 Agent 收回给 Workflow？

Red Flags ​

• “因为 Agent 是趋势。”
• “因为自然语言体验更好，所以必须 Agent。”

为什么这样回答 / 本题套路 ​

这是项目开场题。高分重点不是先讲架构，而是证明“Agent 这个技术选择本身有因果必要性”。

3.2 Q27｜这个项目最关键的三项架构决策是什么？每项替代方案为什么没选？ ​

复习优先级：P2｜题型：S5 Project / Ownership

30 秒核心回答 ​

我会只选真正改变系统路径的三项，而不是罗列组件。

每项都按：

Problem
→ Options
→ Decision
→ Why
→ New Complexity
→ Evidence

回答。

2～3 分钟高分回答 ​

比如研发 AI Workflow 可以选三项：

决策一：Workflow + Agent，而不是纯 Agent

原因：Test / Approval / Merge 是系统不变量。

决策二：诊断跨域 Routing 回 Parent

替代方案：Frontend Agent 直接 Handoff Backend。

没选原因：容易形成 Handoff Loop、权限和 Budget 失控。

决策三：独立 Workspace + Merge Stage

替代方案：多个 Coding Agent 共用 Repo Workspace。

没选原因：资源冲突、难归因、回滚困难。

真正要讲的是：

为什么当时另一个方案看起来也合理，以及什么约束让你最终做了选择。

高分亮点句 ​

架构决策的价值不在“选了什么”，而在“你知道哪些方案都能工作，为什么这个约束下只选这一种”。

面试官真正想听什么 ​

• 是否真正参与关键决策；
• 是否理解 Option Space；
• 是否能讲 Trade-off。

典型追问 ​

1. 哪个决策后来证明错了？
2. 如果规模小 10 倍会不会换方案？
3. 决策证据是什么？

Red Flags ​

• “三项决策：用了模型、用了向量库、用了多 Agent。”
• 不讲替代方案。

为什么这样回答 / 本题套路 ​

这是 Ownership + Architecture Decision 题。三项足够，不要把全部系统模块都说成“关键决策”。

3.3 Q28｜讲一次最严重的线上 Agent 事故：怎样讲出真正的生产深度？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

事故不要只讲：

“出了问题，然后我们修了。”

我会严格按：

现象
→ Impact
→ Evidence
→ Root Cause
→ Wrong Fix
→ Correct Fix
→ Validation
→ Prevention

讲。

2～3 分钟高分回答 ​

高分事故有一个关键要求：

一定要解释“为什么原设计当时看起来合理”。

否则只是事后诸葛亮。

例如：

Tool Timeout
→ 系统直接 Retry
→ 产生重复副作用

为什么原设计合理？

大多数传统 HTTP 调用 Timeout 后 Retry 是常规做法。

真正根因：

有副作用 Tool 的 Timeout 是 Unknown Outcome，不等于 Failure。

错误修复：

增大 Timeout / Retry 次数。

正确修复：

Operation ID
+ Idempotency
+ Reconciliation

最后必须讲：

• 怎么回放； -怎么故障注入； -哪个指标确认复发消失。

高分亮点句 ​

事故复盘最有价值的一句，往往是“我们当时为什么会合理地做错”。

面试官真正想听什么 ​

• 是否真经历过生产问题；
• 是否会 Root Cause；
• 是否把 Incident 变成系统机制。

典型追问 ​

1. 为什么监控没提前发现？
2. 如果再发生一次系统会自动怎么处理？
3. 这次事故改变了哪个 Architecture Invariant？

Red Flags ​

• 事故完全没有影响 / 指标；
• 只有最终修复，没有错误修复过程；
• 事故故事过于完美，像编的。

为什么这样回答 / 本题套路 ​

这是最能拉开真实项目经验的题。Incident 的“错修 → 纠正”比最后正确答案更能体现经验。

3.4 Q29｜你怎样定义项目成功？Quality、Reliability、Cost、Latency、Human Intervention 应该怎么组成指标体系？ ​

复习优先级：P2｜题型：S8 Composite

30 秒核心回答 ​

我不会只看一个“Agent Success Rate”。

我会用：

Quality
Reliability
Cost
Latency
Human Effort
Business Outcome

构成分层指标，并且最上层看 Cost per Verified Outcome。

2～3 分钟高分回答 ​

Quality

• Verified Task Success；
• Semantic / Business Correctness；
• Unsupported Claim。

Reliability

• Recovery Success；
• Stuck Run；
• Duplicate Side Effect；
• Incident Rate。

Cost

• Token；
• Tool / Warehouse / Sandbox；
• Retry Waste；
• Human Minutes。

Latency

• TTFT；
• End-to-end P50 / P95；
• Waiting / Tool Critical Path。

Human Intervention

• Approval；
• Correction；
• Manual Takeover；
• Review Minutes。

最高层应回到业务：

Verified Outcome
/
Total AI + Infra + Human Cost

高分亮点句 ​

Agent 成功率必须被质量、可靠性和人工成本校正，否则很容易优化出“看起来成功”的系统。

面试官真正想听什么 ​

• 是否有完整指标体系；
• 是否只看模型准确率；
• 是否能把技术指标连到业务价值。

典型追问 ​

1. Quality 和 Reliability 哪个优先？
2. Human Intervention 越低越好吗？
3. 怎么定义 Verified Outcome？

Red Flags ​

• “成功率 90% 就是项目成功。”
• “Token 降低就是成本优化完成。”

为什么这样回答 / 本题套路 ​

这是项目经营题。P8 不只要做系统，还要知道系统怎样被衡量。

3.5 Q30｜项目从 Demo 到 Production 最大的架构变化是什么？什么 Trigger 逼着你升级？ ​

复习优先级：P2｜题型：S4 Architecture Evolution

30 秒核心回答 ​

我不会用“组件变多了”描述 Productionization。

真正变化通常是：

原来可以靠隐式约定的东西，被真实 Failure / Scale / Risk 逼成显式 Contract。

2～3 分钟高分回答 ​

Demo 常见：

Prompt
+ Few Tools
+ In-process Loop
+ Shared Credential
+ Raw Logs

Production 后逐步出现：

Tool Contract
Runtime / Recovery
Identity / Policy
Sandbox
Version-aware Trace
Eval / Release Gate

升级 Trigger 应该讲具体：

Failure
→ Crash 后任务重头来

Scale
→ Tool 从 20 到 500

Risk
→ Agent 开始写生产系统

Reuse
→ 多个业务重复做同一能力

Governance
→ 多团队 / 多租户失控

高分亮点句 ​

Demo 到 Production 的本质，不是功能更全，而是隐式假设被逐个外显成可治理的系统保证。

面试官真正想听什么 ​

• 是否经历 Productionization；
• 是否能讲 Architecture Evolution；
• 是否知道为什么升级，而不是事后套架构。

典型追问 ​

1. 哪一层最先升级？
2. 哪个升级后来觉得过早？
3. 哪个隐式假设最危险？

Red Flags ​

• “Demo 用单 Agent，生产改成 Multi-Agent。”
• 只讲技术栈变化，不讲 Trigger。

为什么这样回答 / 本题套路 ​

这是架构演进题。用“隐式约束 → 显式 Guarantee”最能体现生产经验。

3.6 Q31｜线上 Agent 成功率突然下降，怎样区分 Model、Prompt、Context、Harness、Tool、Runtime、Execution 还是 Product 层的问题？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

先不要改 Prompt。

我会按：

Change Diff
→ Failure Stage
→ Version / Trace Evidence
→ Replay / Ablation

做分层归因。

2～3 分钟高分回答 ​

第一步先问：

最近什么变了？

包括：

model
prompt
context policy
knowledge / memory
tool
harness
runtime
execution image
product input distribution

第二步按 Failure Stage 分类：

Intent / Product
Context
Decision
Tool Selection
Execution
Recovery
Verification

第三步固定变量做 Replay / Ablation：

same task
same context snapshot
old model vs new model

same model
old tool vs new tool

不要看到模型输出错就默认是 Model。

高分亮点句 ​

Agent Debug 的第一原则不是“猜哪层有问题”，而是把 End-to-end Failure 拆回版本化系统层。

面试官真正想听什么 ​

• 是否有系统排障能力；
• 是否会 Prompt-first Debug；
• 是否有 Replay / Versioning。

典型追问 ​

1. Product Distribution Shift 怎么发现？
2. 没有旧版本 Model 怎么 Replay？
3. Multiple Changes 同时上线怎么办？

Red Flags ​

• “先看 Prompt / Temperature。”
• “换强模型验证一下。”

为什么这样回答 / 本题套路 ​

这是通用 Incident Attribution 题。它要求把整个 01～05 系列真正装回 Debug 流程。

3.7 Q32｜Offline Eval 提升 3%，怎样证明是真实提升，而不是样本噪声、泄漏、Judge 偏差或任务分布变化？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

3% 不是结论。

我会依次检查：

Eval Set Validity
Measurement Variance
Leakage
Judge Stability
Segment Distribution
Online Confirmation

2～3 分钟高分回答 ​

首先看 Eval Set：

• 是否代表线上分布；
• Ground Truth 是否过期；
• 是否被 Prompt / Skill 看过；
• 是否因为过滤样本变简单。

其次看 Measurement Variance：

• 多次运行；
• Bootstrap / Confidence Interval；
• 分 Segment 看提升。

再看 Judge：

• Judge Version 是否变化；
• 和 Human Label 一致性；
• Position / verbosity bias。

最后做：

Canary / A-B

看真实 User Correction、Verified Success、Incident 是否同方向变化。

高分亮点句 ​

Eval Score 是测量结果；在证明测量体系可信之前，分数变化本身不是证据。

面试官真正想听什么 ​

• 是否懂 Evaluation Science；
• 是否会把小幅提升直接当结论；
• 是否考虑 Judge / Leakage。

典型追问 ​

1. 3% 多大样本才显著？
2. Online 与 Offline 方向相反怎么办？
3. Long-tail Segment 退化怎么办？

Red Flags ​

• “Benchmark 涨 3% 就上线。”
• “LLM Judge 分更高，所以一定更好。”

为什么这样回答 / 本题套路 ​

这是测量质量题。高级回答要 Review “尺子”本身，而不只 Review 模型。

3.8 Q33｜你如何证明 Agent 项目产生了真实业务价值，而不是只是 Agent 使用量增长？ ​

复习优先级：P2｜题型：S5 Project / Ownership

30 秒核心回答 ​

使用量只能证明有人在用，不能证明创造价值。

我会把 Agent 指标连接到：

Business Outcome
+
Human Effort Saved
+
Quality / Risk
-
Total AI / Infra Cost

2～3 分钟高分回答 ​

Data Agent 可以看：

• 找数 / 分析 Lead Time；
• 人工分析小时；
• Verified Answer Success；
• 决策链路缩短。

研发 Agent 可以看：

• Verified Engineering Throughput；
• Cycle Time；
• Review Minutes；
• Change Failure / Regression。

还要建立：

Baseline
→ Before / Control Group

否则：

“DAU 涨了、Agent Call 涨了”

可能只是产品推广，并不代表业务收益。

高价值项目应该能回答：

如果拿掉这个 Agent，业务损失什么？

高分亮点句 ​

Usage 是采用证据，不是价值证据；真正的价值必须落回业务 Outcome 和被替代的人力 / 风险成本。

面试官真正想听什么 ​

• 是否有商业价值意识；
• 是否会 Vanity Metric；
• 是否能建立因果对照。

典型追问 ​

1. 很难做 A/B 怎么办？
2. 业务收益滞后怎么测？
3. 质量提升怎么货币化？

Red Flags ​

• “Agent 调用量上涨 3 倍，所以项目成功。”

为什么这样回答 / 本题套路 ​

这是通用项目 ROI 题。高级候选人要能把技术投入翻译成业务结果，而不是停在产品使用数据。

四、Coding / AI Full-stack Implementation ​

4.1 Q34｜现场设计一个最小 Agent Loop API：Tool、State、Stop Condition、Trace、Structured Output 怎么表达？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

我会先定义稳定对象，不先绑某个 Framework：

Run
State
ToolContract
Observation
StopCondition
TraceEvent
OutputContract

Loop 只做最小反馈闭环。

2～3 分钟高分回答 ​

一个最小接口可以类似：

create_run(input, agent_version)
step(run_id)
cancel(run_id)
get_run(run_id)
stream_events(run_id, after_event_id)

内部：

Context
→ Model
→ Structured Action Proposal
→ Validate
→ Tool
→ Observation
→ State Update
→ Verify Stop

ToolContract 需要参数、错误、副作用、Timeout / Cancel；Structured Output 只负责结构，Stop Condition 必须由系统 / Verifier 决定。

Trace 每个 Step 有：

run_id / span_id / type / version / latency / outcome

高分亮点句 ​

最小 Agent Loop API 的关键不是 endpoint 数量，而是把“模型建议”和“系统事实”分开。

面试官真正想听什么 ​

• 是否能现场落接口；
• 是否理解 Loop 稳定对象；
• 是否避免 Framework API 背诵。

典型追问 ​

1. State 放哪里？
2. Tool Call 异步怎么办？
3. model_done 怎么处理？

Red Flags ​

• “一个 /chat 接口 while true 调模型即可。”

为什么这样回答 / 本题套路 ​

这是编码 / 系统设计题。先给最小对象模型，再扩展持久化和 Runtime。

4.2 Q35｜实现 Tool Router（工具路由器）时，怎样保证参数校验、Timeout（超时）、Cancellation（取消）、Error Classification（错误分类）和测试可控？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

Tool Router 不只是 name → function。

生产上至少要包住：

Schema
Policy
Timeout
Cancellation
Error Taxonomy
Retryability
Trace
Fake / Test Adapter

2～3 分钟高分回答 ​

调用前：

tool exists?
visible?
authorized?
args valid?
budget?

执行中：

deadline
cancel token
operation id

执行后把 Error 分类：

INVALID_INPUT
UNAUTHORIZED
TIMEOUT_UNKNOWN
RETRYABLE_DEPENDENCY
NON_RETRYABLE
BUSINESS_REJECTED

测试时 Tool Registry 可以注入 Fake Tool，覆盖：

• success；
• timeout；
• partial；
• malformed result；
• side-effect unknown。

这样 Harness 单测不需要真实 LLM / API。

高分亮点句 ​

Tool Router 真正的价值是把外部不确定性翻译成 Agent 可以稳定处理的执行语义。

面试官真正想听什么 ​

• 是否会写生产 Tool Layer；
• 是否有 Error Taxonomy；
• 是否可测试。

典型追问 ​

1. Timeout 是否自动 Retry？
2. Tool Schema 谁负责？
3. Fake Tool 和 Mock HTTP 区别？

Red Flags ​

• try/except Exception 后统一返回字符串错误。

为什么这样回答 / 本题套路 ​

这是 S6 工程实现题。接口设计必须体现前面 Harness / Runtime 的生产语义。

4.3 Q36｜一个 Agent 同时调用多个独立 Tool，怎样做异步并发，又如何避免共享资源冲突？ ​

复习优先级：P1｜题型：S2 Incident / Debug

30 秒核心回答 ​

我会先做 Dependency / Resource Analysis：

独立 Read-only
→ 并行

有依赖或共享可写资源
→ 串行 / Lock / Ownership

不能因为 Tool Call 看起来独立就 gather() 全并发。

2～3 分钟高分回答 ​

例如：

search docs
fetch metrics
read file

可以并发。

但：

edit file A
edit same file A
deploy same service
modify same row

有共享资源冲突。

实现上 Plan / Tool Proposal 可以声明：

read_set
write_set
dependency
side_effect

Scheduler 再决定并发。

还要控制：

• concurrency limit；
• deadline；
• fail-fast / best-effort；
• cancellation；
• partial result。

高分亮点句 ​

Tool 并发的真正边界不是“调用是否独立”，而是它们的依赖图和资源读写集合是否独立。

面试官真正想听什么 ​

• 是否懂异步并发；
• 是否考虑共享资源；
• 是否有 Partial Failure。

典型追问 ​

1. 一个 Tool 失败是否取消其他？
2. 并发结果顺序怎么处理？
3. LLM 一次生成 20 个 Call 怎么限流？

Red Flags ​

• “用 Promise.all / asyncio.gather 就行。”

为什么这样回答 / 本题套路 ​

这是 Full-stack + Distributed State 题。真正的高级点在 Resource Conflict，而不是异步语法。

4.4 Q37｜Agent 运行 10 分钟，用户刷新页面后怎样恢复进度和结果？前后端分别保存什么？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

浏览器不能成为 Run 的 Source of Truth。

Backend 持久化：

run state
event log / snapshot
artifact

Frontend 只保存 run_id + last_event_id + projection，刷新后重新订阅。

2～3 分钟高分回答 ​

Backend：

Run
status
progress
checkpoint
events
artifacts
approval
outcome

Frontend：

• current run id；
• last applied event id；
• local UI projection；
• optimistic transient state。

刷新：

GET run snapshot
→ restore UI
→ stream after last_event_id

不能依赖：

页面内 JS Promise 继续存在。

如果任务跨进程 / Deploy，还要 Runtime Durable。

高分亮点句 ​

长任务 Web App 的 Source of Truth 在后端 Run，不在浏览器连接。

面试官真正想听什么 ​

• 是否能做长任务前后端；
• 是否理解状态恢复。

典型追问 ​

1. 多端同时看一个 Run 怎么办？
2. Event Gap 怎么修？
3. 浏览器离线两小时怎么办？

Red Flags ​

• “刷新后重新发起任务。”
• “状态存在 React Store。”

为什么这样回答 / 本题套路 ​

这是非常实用的 AI Full-stack 题：Agent Runtime 必须真正落到前端用户体验。

4.5 Q38｜长任务 Agent Web UI 在 SSE / WebSocket 断线后，怎样恢复进度、Approval 和 Artifact，而不是只恢复消息流？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

我不会把 Stream 当状态。

用：

Snapshot
+ Ordered Events
+ Event ID

构建可重放 Projection，断线后 resume from last_event_id。

2～3 分钟高分回答 ​

Event：

run_id
event_id
type
payload
timestamp
version

UI 只消费 Event 更新 Projection。

重连：

last_event_id = 108
→ server sends 109...

如果历史已过期：

GET latest snapshot
→ reset projection
→ subscribe new events

要处理：

• duplicate → idempotent；
• out-of-order → reject / buffer；
• gap → re-sync；
• stale snapshot → version check。

高分亮点句 ​

Streaming Reliability 的核心不是“连接不断”，而是“连接断了状态仍可重建”。

面试官真正想听什么 ​

• 是否会 SSE / WebSocket 恢复；
• 是否理解 UI Projection。

典型追问 ​

1. SSE 和 WebSocket 怎么选？
2. Snapshot 频率怎么定？
3. Event Store 会不会太大？

Red Flags ​

• “断线就重新连，后续消息继续推。”

为什么这样回答 / 本题套路 ​

这是工程实现题。把网络层问题提升到状态机和 Event Sourcing 思维。

4.6 Q39｜Human Approval 的 UI 和后端状态机怎样设计，才能支持等待数小时后恢复？ ​

复习优先级：P1｜题型：S6 Engineering Implementation

30 秒核心回答 ​

Approval 必须是 Durable State，不是一个前端 Modal。

Backend 至少有：

approval_id
run_id
action
scope
status
requester
approver
expires_at
evidence

2～3 分钟高分回答 ​

Run 进入：

WAITING_APPROVAL

Worker 释放。

UI 展示：

• 要批准什么； -影响范围；
• Evidence；
• Expiry；
• Approve / Reject。

点击后 API 要：

approval_id
expected_state
actor identity
decision

做幂等状态转换。

几小时后即使：

• 页面关了； -服务发布； -Worker 换了；

Signal 仍能让 Runtime Resume。

高分亮点句 ​

Approval 是一个可审计的业务对象，不是一次按钮点击。

面试官真正想听什么 ​

• 是否能把 HITL 做成生产状态机；
• 是否考虑重复点击 / 过期 / 身份。

典型追问 ​

1. Approval Link 被转发怎么办？
2. Reject 后如何恢复？
3. 多 Approver 怎么做？

Red Flags ​

• “前端弹窗，用户点 Yes 后继续 Promise。”

为什么这样回答 / 本题套路 ​

这是 Full-stack + Runtime + Security 三者交叉题。

4.7 Q40｜怎样为 Agent UI / Backend 写确定性测试，而不是每次 CI 都调用真实模型？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

把 Agent 系统分成：

Deterministic Shell
+
Nondeterministic Model Boundary

CI 里用 Fake Model / Fake Tool / Recorded Event 测绝大部分系统逻辑，真实模型只进入专项 Eval。

2～3 分钟高分回答 ​

Backend Deterministic Test：

• state transition； -tool validation； -timeout / retry； -cancel； -approval； -event resume； -version migration。

Fake Model 可以预设：

tool_call
malformed output
model_done
loop

Frontend：

• Recorded Event Stream； -Snapshot / Delta； -Approval； -Error / reconnect； -Artifact UI。

真实 Model Test：

放到 Eval / nightly / canary，不应该成为普通单测的唯一基础。

高分亮点句 ​

Agent 系统可以非确定，但 Agent 软件本身绝不能不可测试。

面试官真正想听什么 ​

• 是否有软件工程基本功；
• 是否把所有测试都变 LLM Eval。

典型追问 ​

1. Fake Model 会不会不真实？
2. Prompt 变化怎么测？
3. E2E 要调用真实模型吗？

Red Flags ​

• “Agent 行为随机，所以只能线上测。”

为什么这样回答 / 本题套路 ​

这是 Engineering Quality 题。高级 Agent 工程必须保留传统确定性测试能力。

4.8 Q41｜设计一个同时支持 Data Agent / Coding Agent 的统一 Long-running Agent Web Application（长任务智能体 Web 应用），哪些能力应该共享，哪些不能共享？ ​

复习优先级：P1｜题型：S1 System Design

30 秒核心回答 ​

共享的是：

Run / Event / Approval / Artifact / Trace / Runtime / Identity

不共享的是 Domain Execution 和 Verification。

2～3 分钟高分回答 ​

Shared Backend

Run API
Durable Runtime
Event Stream
Approval
Artifact Store
Trace / Cost
Identity / Policy Hook

Shared Frontend

Run progress
Event timeline
Approval UI
Artifact panel
Error / resume

Data Agent Domain

• SQL / BI； -Metric Evidence； -Table / Chart。

Coding Agent Domain

• Repo Workspace； -Diff； -Test； -PR / Build。

共同 Contract：

Artifact
Evidence
Run State
Event

而不是统一业务 Payload。

高分亮点句 ​

统一 Long-running Agent App 的关键，是共享“任务生命周期 UI”，而不是共享每个 Agent 的业务界面。

面试官真正想听什么 ​

• 是否有 AI Full-stack 平台抽象；
• 是否理解 Shared Core vs Domain UI。

典型追问 ​

1. Generative UI 放哪层？
2. Artifact Schema 要不要统一？
3. Data Agent Table 和 Coding Diff 怎么共存？

Red Flags ​

• “所有 Agent 都用一个 Chat 界面。”
• “所有 Result 都转成 Markdown。”

为什么这样回答 / 本题套路 ​

这是 Full-stack System Design 题。对你当前生成式 UI / Data Agent 背景也非常贴近。

五、Technical Leadership / Architecture Judgment ​

5.1 Q42｜什么情况下你会明确反对使用 Agent？ ​

复习优先级：P2｜题型：S3 Trade-off / Decision

30 秒核心回答 ​

当任务：

路径确定
规则稳定
错误代价高
不需要动态观察决策

我会优先 Workflow / API / Rule Engine，而不是 Agent。

2～3 分钟高分回答 ​

判断三个问题：

1. 路径是否真的不确定？
2. 环境 Observation 是否会改变下一步？
3. 非确定性带来的收益是否超过风险 / 成本？

例如：

• 固定审批流 → Workflow； -精确计费 → Deterministic Service； -权限判定 → Policy Engine； -简单 FAQ → Search / RAG。

Agent 应用在：

目标明确但路径不可穷举，需要根据环境持续决策的地方。

我还会再看两个经常被忽略的维度：

Reversibility（可逆性）
×
Error Blast Radius（错误影响半径）

即使路径不确定，如果错误不可逆、验证又弱，例如资金结算、权限授予、不可逆数据删除，我也不会把最终决定权直接交给 Agent。更合理的是：

Agent proposes
→ deterministic policy / human gate
→ controlled execution

所以“适合 Agent”不等于“适合完全自治”。

高分亮点句 ​

高级 Agent 架构师最重要的能力之一，是知道什么时候不用 Agent。

面试官真正想听什么 ​

• 技术克制；
• 是否能按问题选工具；
• 是否有风险意识。

典型追问 ​

1. LLM 很强以后边界会变吗？
2. Agent 只做 Plan、Workflow 执行可以吗？
3. 什么任务是典型反例？

Red Flags ​

• “模型够强就都可以 Agent 化。”

为什么这样回答 / 本题套路 ​

这是架构判断根题。能够反对热门技术本身就是高级判断力的一部分。

5.2 Q43｜一个技术上更先进的方案成功率更高，但成本翻 5 倍、时延翻 3 倍，你怎么决策？ ​

复习优先级：P2｜题型：S3 Trade-off / Decision

30 秒核心回答 ​

我不会比较单一成功率。

要比较：

Value per Verified Outcome

并按任务价值 / SLO 分层，而不是全量切高级方案。

2～3 分钟高分回答 ​

先问：

成功率从多少到多少？

70% → 85%

和：

96% → 97%

价值完全不同。

再看：

• 错误成本； -用户等待容忍； -调用频率； -是否只对 Hard Case 有收益。

通常可以做：

Fast Path
→ cheap / low latency

Escalation Path
→ expensive / strong model / multi-agent

用 Router 让难任务才升级。

最终看：

Cost per Successful / Verified Task
P95 Latency
Business Value

我通常还会画一个 Pareto Frontier（帕累托前沿）：

质量提高多少
vs
成本增加多少
vs
延迟增加多少

如果高级方案只在少数 Hard Case 上有明显增益，就不要全量替换，而是做：

Cheap Default
→ Uncertainty / Risk Trigger
→ Escalate to expensive path

这样把系统从“一套最强方案”变成“按价值分配推理预算”。

高分亮点句 ​

不是选择“最强方案”，而是把最贵的智能用在它能改变结果的地方。

面试官真正想听什么 ​

• 是否会经济性决策；
• 是否只追 Benchmark；
• 是否有分层路由思维。

典型追问 ​

1. Router 错分怎么办？
2. 高价值用户是否全走强方案？
3. 怎么做 Pareto Frontier？

Red Flags ​

• “成功率高就应该上线。”
• “成本高以后再优化。”

为什么这样回答 / 本题套路 ​

这是 Trade-off 题。核心是单位价值和分层策略。

5.3 Q44｜什么时候应该自建 Harness / Runtime / Knowledge / Platform，什么时候直接使用云厂商 / OSS 能力？ ​

复习优先级：P2｜题型：S3 Trade-off / Decision

30 秒核心回答 ​

我用两个维度：

Semantic Control
×
Operational Differentiation

不是“核心就自研、非核心就买”。

2～3 分钟高分回答 ​

更适合买 / Managed：

• 标准基础设施； -运维复杂； -企业差异化低； -Provider SLO 更成熟。

更值得 Build：

• 业务语义强； -需要跨 Provider； -合规 / Residency 特殊； -迁移控制权重要。

即使 Buy Runtime / Sandbox，也应该保留自己的：

Run Contract
Policy
Trace
Eval
Artifact
Version Mapping

即：

买实现，不丢语义控制权。

不同层的判断也不一样：

Harness
→ 如果差异主要来自 Domain Behavior，通常保留自己的 Contract / Extension

Runtime
→ Durable Semantics 已成熟时优先复用成熟实现

Knowledge
→ Search / Index 可 Buy，但 Authority / Semantic / Governance 常要自己掌控

Platform
→ 只有跨团队共性稳定后再 Build Shared Layer

所以 Build vs Buy 不是一次总决策，而是逐层判断：

哪一层需要企业拥有语义，哪一层只需要可靠实现。

高分亮点句 ​

Build vs Buy 真正要保住的是语义和迁移权，不是代码所有权。

面试官真正想听什么 ​

• 是否理性做平台选型；
• 是否有 Provider Lock-in 思维；
• 是否区分语义与实现。

典型追问 ​

1. 哪些层最不值得自研？
2. 怎么评估迁移成本？
3. 多云是不是必要？

Red Flags ​

• “核心平台一定自研。”
• “云服务成熟所以全部托管。”

为什么这样回答 / 本题套路 ​

这是平台投资判断题，和 05 的 Semantic Control 对齐。

5.4 Q45｜Quality、Reliability、Cost、Latency 同时有问题时，你如何排序？ ​

复习优先级：P2｜题型：S8 Composite

30 秒核心回答 ​

没有固定全局顺序，要先识别：

哪个维度已经违反用户 / 业务不可接受的最低约束。

通常先守住正确性和安全底线，再在 Reliability、Latency、Cost 之间按 SLO / ROI 优化。

2～3 分钟高分回答 ​

我会先定义 Hard Constraint：

安全 / 权限不能越界
关键业务答案不能系统性错误
关键副作用不能重复

再看当前瓶颈。

例如：

• Success 40% → 先 Quality / Reliability；
• Success 95% 但 P95 3 分钟 → Latency；
• 全部指标达标但成本无商业可行性 → Cost。

也要避免单指标优化：

缩短 Context
→ Latency 降
→ Quality 崩

所以看 Pareto Trade-off 和：

Cost per Verified Outcome

我还会把问题拆成“底线约束”和“优化目标” ​

Hard Constraint
→ 不满足就不能上线

Optimization Objective
→ 在底线之上做 Pareto 优化

例如：

生产权限越界
重复扣款
错误财务口径

属于 Hard Constraint，不拿 Cost / Latency 去交换。

但：

95% → 97% 质量
500ms → 800ms 延迟

则是 Optimization Trade-off，需要按用户价值决定。

决策完成后必须设置停止条件 ​

优化项目很容易无休止。

所以每个维度要先写：

target SLO
acceptable floor
budget
exit condition

达到目标以后，把资源投给下一个最大约束，而不是继续追求单指标极致。

高分亮点句 ​

优先级不是 Quality > Reliability > Cost > Latency 的口诀，而是先守系统不变量，再优化当前最大的业务约束。

面试官真正想听什么 ​

• 是否能排序工程投资；
• 是否有 SLO / business thinking；
• 是否避免一刀切。

典型追问 ​

1. Quality 和 Latency 冲突怎么办？
2. 成本什么时候成为 P0？
3. 怎么定义最低质量线？

Red Flags ​

• 背固定排序，不看场景。

为什么这样回答 / 本题套路 ​

这是架构决策题。高级回答要从 Constraints 推导优先级。

5.5 Q46｜团队提出“统一一个 Vector DB，同时存 Context、Knowledge、Memory、Session”，你怎样做 Architecture Review？ ​

复习优先级：P2｜题型：S8 Composite

30 秒核心回答 ​

我首先不会讨论 Vector DB 性能，而会指出：

这四种对象生命周期、Authority、权限和一致性语义不同。

同一种 Storage 可以复用，但不能因此统一对象语义。

2～3 分钟高分回答 ​

Context

• 单次模型可见投影； -短生命周期。

Knowledge

• Source of Truth； -Authority / Freshness。

Memory

• 跨 Run 经验； -Correction / Forgetting。

Session

• 交互历史； -顺序 /一致性。

如果统一一套 CRUD / Retention / ACL，会造成：

• 旧 Knowledge / Memory 难纠错； -Session Delete 误删 Knowledge； -Context 临时数据长期留存； -Authority 混乱。

可以共享底层 Vector Index / Search Service，但上层必须：

separate contract
separate lifecycle
separate authority
separate policy

高分亮点句 ​

复用存储不等于合并语义。真正危险的 Mega Platform 往往从“反正都能放一张表”开始。

面试官真正想听什么 ​

• 是否能做 Architecture Review；
• 是否理解对象生命周期；
• 是否会被统一技术栈诱惑。

典型追问 ​

1. 共用 Vector Cluster 可以吗？
2. Context Snapshot 存哪里？
3. Shared Metadata Service 可以统一吗？

Red Flags ​

• “加一个 type 字段就能统一。”

为什么这样回答 / 本题套路 ​

这是非常好的 P2 Review 题。重点不是反对 Vector DB，而是指出语义边界比存储技术更重要。

5.6 Q47｜技术方案正确但业务团队不愿迁移，你怎样通过数据、渐进迁移和组织机制推动 Adoption？ ​

复习优先级：P2｜题型：S5 Project / Ownership

30 秒核心回答 ​

技术正确不等于迁移值得。

我会先找到业务团队真实迁移成本，再用：

Evidence
→ Low-friction Adapter
→ Progressive Rollout
→ Clear Ownership
→ Escape Hatch

推动。

2～3 分钟高分回答 ​

先问不愿迁移原因：

• 功能缺口； -性能； -可靠性； -学习成本； -历史集成； -担心平台团队成为瓶颈。

然后不做大爆炸迁移。

例如：

先接 Trace / Run Contract
→ 再接 Tool Registry
→ 再接 Runtime / Policy

用 Adapter 兼容旧 Framework。

选择一个高价值 Team 做 Pilot，用数据证明：

• 上线时间下降； -Incident 降； -Debug 快； -重复代码减少。

组织上明确 RACI 和 Escape Hatch。

还要处理一个现实问题：平台团队和业务团队的成本函数不同 ​

平台看到的是：

全局重复建设
治理风险
长期维护成本

业务团队看到的是：

本季度需求
迁移人力
线上风险
学习成本

双方都可能是理性的。

所以推动 Adoption 时必须把“企业长期收益”转成业务团队可感知的短期收益，例如：

• 少写多少 Glue Code； -上线缩短多少天； -Debug 少花多少小时； -安全 Review 是否可以复用。

如果平台只要求业务付迁移成本，却把收益留在平台侧，阻力是合理的。

高分亮点句 ​

平台 Adoption 的核心不是“让业务服从标准”，而是让迁移后的净收益大于迁移摩擦。

面试官真正想听什么 ​

• 是否能推动落地；
• 是否理解组织 /迁移成本；
• 是否会 Brownfield。

典型追问 ​

1. Pilot 失败怎么办？
2. 平台强制标准什么时候合理？
3. 双轨期多久？

Red Flags ​

• “让领导统一要求接入。”
• “技术方案先进，业务最终会接受。”

为什么这样回答 / 本题套路 ​

这是 Technical Leadership 题。真正高级的架构必须能被组织采用，而不只是设计正确。

六、研发项目 Ownership / Leadership 深挖 ​

6.1 Q48｜你在这个研发 AI Workflow 项目里真正主导了什么？怎么回答才不像“团队共同做的”？ ​

复习优先级：P2｜题型：S5 Project / Ownership

30 秒核心回答 ​

项目 Ownership 不能只说：

“我负责整体架构。”

要讲：

我发现了什么核心问题
我做了什么关键决策
我推动了哪些跨团队落地
我承担了什么结果

2～3 分钟高分回答 ​

一个高分回答结构：

业务背景
→ 我的责任边界
→ 原方案为什么不够
→ 我做的关键 Architecture Decision
→ 最大阻力 / Trade-off
→ 我怎么推动
→ 指标结果
→ 反思和下一阶段

例如不要说：

“我们做了多 Agent。”

而说：

“我主导把原来纯 Agent Loop 拆成 Workflow + Agent Node，因为 Test / Approval / Merge 这些步骤不能依赖模型概率决定；同时把诊断 Agent 的跨域 Handoff 收回 Parent，避免前后端 Agent 相互转发形成 Loop。”

只使用真实做过的部分。

更高级的讲法还要主动区分三层：

我亲自做的决策
团队共同完成的实现
我现在回头看的下一阶段判断

如果面试官继续追指标，不要用“提升明显”这类模糊表述。应该尽量给：

• Before / After； -样本量； -指标定义； -是否有其他变量同时变化。

如果没有精确数据，就明确说“当时没有做到严格归因，这是我现在会补的一层”，比编数字更可信。

高分亮点句 ​

Ownership 不是参与了多少模块，而是哪些关键决策如果没有你，项目路径会不同。

面试官真正想听什么 ​

-是否真的主导； -是否有决策和推动力； -是否只会讲团队成果。

典型追问 ​

1. 哪个决定争议最大？
2. 你亲自做的最难部分是什么？
3. 如果重来一次会改什么？

Red Flags ​

• 全程“我们”没有“我”； -只讲架构，没有结果； -把计划说成完成。

为什么这样回答 / 本题套路 ​

这是 Ownership 题。一定要用决策、阻力、结果证明主导权。

6.2 Q49｜如果团队有人坚持“直接上多 Agent，一人一个角色”，你怎么推动架构收敛？ ​

复习优先级：P2｜题型：S5 Project / Ownership

30 秒核心回答 ​

我不会用“我的方案更好”争论。

我会把讨论转成可验证问题：

拆分解决了什么边界？
新增了什么协调成本？
单 Agent baseline 是什么？
怎么证明净收益？

2～3 分钟高分回答 ​

先承认：

多 Agent 在并行、权限、Context 隔离下可能有价值。

然后要求：

Hypothesis
→ 例如前后端并行降低 30% Latency

Experiment
→ Single vs Multi

Metrics
→ Success / Latency / Cost / Merge Conflict

Decision

如果没有明确收益：

保持 Single Agent / Workflow。

这样把“技术偏好”转成工程决策。

真正推动时，我会先把争论从“架构审美”降成可验证实验 ​

例如对方认为：

“前端 Agent + 后端 Agent + Test Agent 一定更专业。”

我会要求同时定义：

Single Agent baseline
Multi-Agent hypothesis
expected gain
new failure modes
rollback condition

再选择一组真实任务做 Shadow / A-B，而不是先做完整平台。

如果 Multi-Agent 只是：

Agent 数量 ↑
Token ↑
Merge / Handoff ↑
Success 基本不变

就用数据收敛。

反过来，如果 Permission Isolation / Parallelism 明显带来收益，我也会接受拆分。

这类争议里最重要的 Leadership 信号 ​

不是“最后方案听我的”，而是：

我建立了一套团队以后还能复用的 Architecture Decision Mechanism。

以后遇到 Memory、Gateway、Platform 争议，也可以继续用：

Trigger
→ Hypothesis
→ Experiment
→ Evidence
→ Decision

高分亮点句 ​

高级架构讨论不是证明谁更懂，而是把争议变成可验证假设。

面试官真正想听什么 ​

-影响力； -架构决策方法； -是否能处理分歧。

典型追问 ​

1. 如果领导已经决定 Multi-Agent 呢？
2. 实验结果不明显怎么办？
3. 怎么避免团队一直争论？

Red Flags ​

• “我会说服他们我的方案更合理。” -拿业界产品背书替代实验。

为什么这样回答 / 本题套路 ​

这是 Leadership / Conflict 题。核心是 Evidence-based Decision。

6.3 Q50｜如何推动前端、后端、测试、安全、平台团队共同建设这套系统，而不是平台团队单方面设计？ ​

复习优先级：P2｜题型：S5 Project / Ownership

30 秒核心回答 ​

我会把共建边界拆成：

Platform Contract
+
Domain Ownership
+
Review Gate

让专业团队拥有自己的业务 / 风险语义，平台只统一稳定接口。

2～3 分钟高分回答 ​

例如：

平台

负责：

• Workflow / Runtime； -Trace； -Workspace Contract； -Policy Hook； -Eval Infrastructure。

前后端 Team

负责：

• Repo Skill； -Test Rule； -诊断规则； -Review 标准。

安全

负责：

• Sandbox； -Secret； -Network； -Supply-chain Gate。

测试

负责：

• Verification Strategy； -Golden Task； -Regression Set。

推动方式：

明确 RACI
→ 每个 Contract 有 Owner
→ 上线前共同 Review
→ Incident 共同复盘

高分亮点句 ​

平台化不是平台团队替所有人做决定，而是让跨团队决定有稳定契约和清晰 Owner。

面试官真正想听什么 ​

-跨团队协作； -是否有组织边界意识； -是否懂专业领域 ownership。

典型追问 ​

1. 谁决定上线 Gate？
2. 安全要求影响效率怎么办？
3. Domain Team 不配合怎么办？

Red Flags ​

• “平台团队统一标准，业务遵守即可。”

为什么这样回答 / 本题套路 ​

这是组织推动题。体现 RACI 与 Platform / Domain 边界。

6.4 Q51｜怎样定义研发 AI Workflow 的上线 Gate 和灰度策略？ ​

复习优先级：P1｜题型：S8 Composite

30 秒核心回答 ​

我不会一次让 Agent 拿到：

Repo Write
Merge
Deploy

全权限。

应该按风险逐层放开，并且每层有 Eval / Rollback。

2～3 分钟高分回答 ​

阶段：

Shadow
→ Read-only Suggestion

PR Draft
→ Write isolated branch

Auto Fix
→ Low-risk scoped task

Auto Merge
→ Strict repository / task class

Deploy
→ 更高风险 Gate

每阶段看：

• Verified Success； -False Positive； -Regression； -Human Review； -Incident； -Cost。

灰度还要按：

repo
team
task type
risk
agent version
model

分桶。

高分亮点句 ​

Agent 权限应该随着证据逐步扩大，而不是随着 Demo 成功一次性放开。

面试官真正想听什么 ​

-生产发布； -风险治理； -是否会 Canary。

典型追问 ​

1. 哪类任务最先 Auto Merge？
2. Rollback 是回模型还是回 Workflow？
3. Shadow 模式怎么 Eval？

Red Flags ​

• “准确率到 90% 就自动 Merge。”

为什么这样回答 / 本题套路 ​

这是 Production Rollout 题。能力和权限一起渐进放量。

6.5 Q52｜如果上线后开发者觉得 AI Agent 很烦、Review 成本高，怎么判断问题和优化方向？ ​

复习优先级：P1｜题型：S5 Project / Ownership

30 秒核心回答 ​

不要只看使用率。

我会拆：

Wrong Task
Bad UX
Low Precision
Slow Latency
High Coordination
Trust Gap

找到真正导致开发者拒绝的原因。

2～3 分钟高分回答 ​

例如 Review Agent：

每个 PR 报 20 个问题。

使用率低可能不是“大家不接受 AI”，而是：

Finding Precision 低
→ Review Fatigue

Coding Agent：

PR 生成慢。

可能是：

Repo Discovery
CI Wait
Sandbox Cold Start

而不是 Model。

指标：

• Accept Rate； -Finding Precision； -Human Edit Distance； -Time Saved； -Manual Intervention； -Abandon Rate。

高分亮点句 ​

内部开发者也是用户，Agent 产品失败很多时候是信任和交互成本问题，不只是模型能力问题。

面试官真正想听什么 ​

-产品意识； -是否会看用户体验； -是否只看技术指标。

典型追问 ​

1. Adoption 低怎么办？
2. 怎样建立 Trust？
3. AI Finding 太多怎么收敛？

Red Flags ​

• “强制团队使用就能建立习惯。”

为什么这样回答 / 本题套路 ​

这是 Product + Leadership 题。研发基础设施也要有用户视角。

6.6 Q53｜如果你发现架构复杂度已经超过收益，怎么做减法？ ​

复习优先级：P2｜题型：S6 Engineering Implementation

30 秒核心回答 ​

我会做 Architecture Ablation（架构消融）：

去掉某 Agent / Workflow / Gate
→ 看 Success / Cost / Latency / Risk 是否明显变差

如果不变，就应该删。

2～3 分钟高分回答 ​

例如：

Planner Agent
Reviewer Agent
Diagnosis Agent

并不是永远必要。

强模型升级后：

Planner / Coding 可能合并。

某 Review Agent False Positive 太高：

可以先退到 Shadow。

一个 Workflow Gate 没产生风险收益：

可以去掉。

关键是：

复杂度也要证明自己的 ROI

我会给复杂度设置“删除 Trigger”：

Success Gain 接近 0
Coordination Cost 持续上升
Owner 不清晰
只有极少场景使用
强模型 / 新基础能力已经吸收原职责

然后做 Shadow / Ablation，而不是一次性删除。

还要避免 Sunk Cost Fallacy（沉没成本谬误）：

“已经投入很多，所以不能删。”

投入历史不是继续保留复杂度的理由；未来净收益才是。

高分亮点句 ​

架构师不只负责增加能力，也负责删除已经没有正收益的复杂度。

面试官真正想听什么 ​

-是否会做减法； -是否有成本意识； -是否敢推翻自己的设计。

典型追问 ​

1. 哪个组件最容易被删？
2. 团队已经投入很多怎么办？
3. 怎么避免频繁架构摆动？

Red Flags ​

• “已经平台化了就不能回退。”

为什么这样回答 / 本题套路 ​

这是高级 Architecture Evolution / Leadership 题。

七、最后的系统设计记忆图 ​

User / Requirement
        ↓
Requirement Normalization
        ↓
Workflow Control Plane
        ↓
Planning Agent
        ↓
Task / Resource Graph
        ↓
Coding Agent(s)
        ↓
Isolated Workspaces / Sandboxes
        ↓
Deterministic Test
        ↓
Review / Diagnosis
        ↓
Fix Loop
        ↓
Risk / Approval Gate
        ↓
Merge / Deploy
        ↓
Environment Verification
        ↓
Artifact / Evidence
        ↓
Trace / Eval / Cost / Learning

横向始终贯穿：

Identity
Permission
Version
Runtime
Execution
Security
Observability
Evaluation
Rollback

八、2～3 分钟总复述 ​

如果面试官问：

“你会怎么设计企业级研发 AI Workflow？”

可以这样回答：

“我不会先从多 Agent 出发，而会先把研发主链路拆成 Requirement、Plan、Code、Test、Review、Fix、Approval、Merge、Deploy、Verify。然后逐个判断哪些是确定性系统不变量、哪些需要 Agent 推理。像 Coding、Diagnosis、Review 可以用 Agent；测试执行、审批 Gate、Merge、Deploy 和最终验证必须由 Workflow 和执行系统保证。

Runtime 上要支持长 CI、人工 Review、Approval 的 Wait / Signal / Resume；Execution 上每个 Coding Worker 要有独立 Workspace / Sandbox，Secret 和 Network 做强边界；Merge / Deploy 等副作用必须有 Operation ID、Idempotency 和 Reconciliation。多 Agent 也不是默认方案，只有 Context、Permission、Parallelism 或 Ownership 边界明确时才拆，并且用 Single Agent 作为基线证明净收益。

质量上，Coding Agent 自报完成不算完成，必须有 Build / Test / Acceptance Evidence；Review Agent 输出的是 Finding，不是事实；所有 Parent / Child、Tool、Artifact、Approval 都要进入 Trace 并绑定 Model、Prompt、Tool、Skill、Repo Commit、Sandbox Image 等版本。

最终业务指标也不是生成了多少代码，而是 Verified Engineering Throughput：在同等或更高质量下，研发周期、人力 Review、Incident 和单位任务总成本有没有真正下降。”

九、业界实现证据与边界 ​

• [R1] OpenAI — Harness engineering：公开复盘 Agent-first 软件研发，强调 Agent-friendly Repo、自动测试、环境、反馈闭环和 Harness Engineering，而不是只依赖更强模型。
  https://openai.com/index/harness-engineering/

• [R2] OpenAI — Symphony：公开一种 Codex Orchestration 设计，把项目管理板作为 Coding Agent Control Plane，让任务被持续分配给 Agent、产出结果后由人 Review。
  https://openai.com/index/open-source-codex-orchestration-symphony/

• [R3] GitHub Docs — Copilot Agents：支持从 Issue / Prompt 委派任务、在 Branch / PR 上迭代，并明确要求 Agent PR 像普通贡献一样接受 Review。
  https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents

• [R4] OpenAI Codex：当前产品强调 Worktree / Cloud Environment / Multi-agent Parallel Work 和长时间 Background Work，可作为并行 Coding Agent 已进入真实产品的现实证据。
  https://openai.com/codex/

• [R5] Anthropic — Claude Code Sandboxing：通过 Filesystem / Network Isolation 降低 Permission Prompt 和 Approval Fatigue，说明高自治 Coding Agent 需要硬执行边界。
  https://www.anthropic.com/engineering/claude-code-sandboxing

• [R6] OpenAI — Running Codex safely at OpenAI：强调 Sandbox、Managed Network Policy、Credential、Approval 和 Agent-native Telemetry 的组合治理。
  https://openai.com/index/running-codex-safely/

• [R7] OpenAI — Agents API：当前公开 API 提供托管 Codex Harness、Hosted / Custom Sandbox、长 Session、Context Compaction、Subagent 等能力，进一步说明 Coding / Cloud Agent 的运行语义正在平台化。
  https://openai.com/index/introducing-the-agents-api/

产品会继续变化，真正要掌握的是：

text

Workflow / Agent Boundary
Workspace / Ownership
Verification
Durable Runtime
Side-effect Semantics
Supply-chain Security
Parent / Child Trace
Eval / Regression
Human Risk Gate
Engineering ROI
Ownership / Leadership

十、本篇最终记忆锚点 ​

如果只记 18 句话：

1. 研发 AI 应该是 Workflow + Agent，而不是纯 Agent。
2. Workflow 管必须发生什么，Agent 管不确定性怎么解决。
3. model_done ≠ verified_done。
4. Agent 可以决定测什么，但测试证据必须由执行系统产生。
5. Review Finding 是 Claim，不是 Global Truth。
6. 跨 Domain Routing 回 Parent；局部 Re-diagnosis 留在 Child。
7. Fix Loop 要看 Progress，不只看 Retry 次数。
8. 真正可并行的是资源冲突图，不是任务标题。
9. Task Lifetime ≠ Worker Lifetime。
10. Merge / Deploy Timeout 必须 Reconcile，不能直接 Retry。
11. Repo 既是 Context，也是潜在 Supply-chain 攻击载体。
12. Approval 是 Risk Gate，不是 Sandbox 的替代品。
13. 研发 Agent Eval 应来自真实 Issue / Bug / CR / Incident。
14. Agent Regression 必须绑定 Model / Prompt / Tool / Skill / Repo / Environment Version。
15. Multi-Agent Trigger 是单一决策边界失效，不是流程看起来复杂。
16. AI 研发真正的 ROI 是 Verified Engineering Throughput，而不是代码生成量。
17. Test Pass 也可能被 Agent 投机；Verifier 本身必须有独立边界。
18. Requirement 不清楚时，Agent 最危险的是把未经确认的假设固化进代码。

十一、本篇最容易拉开候选人差距的专家判断 ​

1. 研发 AI 的高分答案从“Workflow 哪些节点必须确定”开始，而不是从“需要几个 Agent”开始。
2. Requirement 错，Test 全过也可能做错产品；质量链必须从需求契约开始。
3. **Verifier 也会被 Agent 投机。**Coding Agent 如果能自由修改测试 / Gate，就可能优化指标而不是优化真实目标。
4. Review Finding 是 Claim，不是事实；真正可信的是可复现 Evidence。
5. 真正可并行的是 Resource Conflict Graph，不是任务标题。
6. 跨 Domain Routing 回 Parent，局部诊断 Loop 留给 Child，可以显著降低 Handoff 图失控。
7. PR / Merge / Deploy 的最大风险不是失败，而是“可能已经成功但系统不知道”。
8. Repo 对 Coding Agent 既是 Context，也是潜在 Supply-chain Attack Surface。
9. AI 研发 ROI 要看 Verified Engineering Throughput，而不是代码量、PR 数、Agent 调用量。
10. 架构师不仅要会加 Agent，也要能用 Architecture Ablation 删除没有正收益的复杂度。