本文目录
适合做过 Agent 工作流的人，重点练状态如何保存、失败后怎样恢复，以及什么时候需要人工确认。
教学示例：先换成自己的真实项目描述，再逐题练习。下面保留完整追问分支、检查重点与评分规则。
页面加载中…
求职指南 · 简历项目模拟面试
适合做过 Agent 工作流的人，重点练状态如何保存、失败后怎样恢复，以及什么时候需要人工确认。
适合做过 Agent 工作流的人，重点练状态如何保存、失败后怎样恢复，以及什么时候需要人工确认。
教学示例：先换成自己的真实项目描述，再逐题练习。下面保留完整追问分支、检查重点与评分规则。
学习内容与项目面试，在同一条路上。
负责【真实 Agent 工作流】的状态与编排，承担【节点、持久化或人工介入模块】。
需要准备：业务流程；个人职责；状态工件。
将【真实长任务】上线，支持【恢复、审批或回滚能力】，并满足【真实 SLO】。
需要准备：状态语义；恢复证据；SLO；失败记录。
简历原句是“【自己的真实项目描述】”。图节点、状态 Schema、Checkpoint、业务工具和审批台分别由谁实现？
考察重点：核验项目所有权，避免把团队或平台成果当作个人成果。
需要追加追问时：ownership_ambiguous → ownership-proof。
下一步：design。
配套学习：LangGraph 状态机与场景。
请用一个状态迁移、Checkpoint 记录或审批回放说明你的设计和改动。
考察重点：用可脱敏工件交叉验证职责，而不是继续听抽象表述。
下一步：design。
配套学习：Agent 中断恢复:状态持久化策略。
从任务创建到节点执行、状态持久化、暂停审批、恢复和结束，状态怎样变化？
考察重点：确认候选人理解端到端链路、关键接口和状态变化。
下一步：tradeoff。
为什么使用图式工作流而不是顺序代码、队列编排或完全自主 Agent？哪些节点必须人工介入？
考察重点：验证选型来自真实约束和对比，而不是技术名词堆砌。
下一步：metrics。
任务成功、节点重试、恢复成功、人工介入和端到端时延如何定义？基线是什么？
考察重点：核验效果数字是否有定义、基线、样本和可归因证据。
需要追加追问时：metric_undefined → metrics-proof；baseline_missing → metrics-proof；evaluation_set_missing → metrics-proof。
下一步：failure。
配套学习：异步 Agent 最终一致性。
请把任务成功、节点重试、恢复成功和人工介入分开定义，并给出同一任务集的流程版本与基线；没有回放记录就不能证明可恢复。
考察重点：二次核验缺失的指标证据；仍无法提供时，在复盘中标记为“只有知识，没有项目事实”。
下一步：failure。
配套学习：异步 Agent 最终一致性。
给出一次进程重启、重复回调或审批超时的故障，状态如何保持一致且不重复执行副作用？
考察重点：确认候选人见过方案边界，并能完成证据驱动的失败复盘。
需要追加追问时：failure_case_missing → failure-proof。
下一步：production。
请按状态版本回放一次重启、重复回调或审批超时，指出 Checkpoint、租约、幂等键和副作用状态；没有记录就按设计题回答。
考察重点：要求用可回放材料证明失败复盘；若只有假设分析，必须与真实事故或 bad case 明确区分。
下一步：production。
生产中如何设置 Checkpoint、租约、超时、死信、人工 SLA、监控、灰度和回滚？
考察重点：验证系统是否真实上线，并具备监控、灰度和回滚能力。
需要追加追问时：production_evidence_missing → production-proof；rollback_missing → production-proof；scale_unverified → production-proof。
下一步：extension。
配套学习：LangGraph 状态机与场景。
请给出一次图或状态 Schema 变更，说明旧 Checkpoint 如何兼容、灰度如何观察、失败如何回退；没有记录就明确尚未经过生产迁移。
考察重点：核验生产事实与设计知识的边界；没有线上材料时，只按设计能力记录，不视为上线经历。
下一步：extension。
配套学习：LangGraph 状态机与场景。
如果任务持续数天并跨多个租户，状态分片、版本迁移、审批权限和历史清理怎么设计？
考察重点：测试约束变化后的迁移、容量和风险判断能力。
配套学习：Agent 工具集成与工作流编排。
dimension：ownership
0：只会复述团队目标，无法说明本人职责。
1：能说出参与模块，但职责边界和决策权不清。
2：能区分本人、同事和平台职责，并给出实现证据。
3：职责、决策、协作边界和可核验工件完整一致。
dimension：chain-understanding
0：只罗列技术名词，讲不清数据如何流动。
1：能描述主流程，但关键接口和状态变化含糊。
2：能画清端到端链路，并解释关键输入输出。
3：能解释节点执行、状态持久化、暂停审批、恢复、幂等副作用和结束状态的迁移。
dimension：tradeoff
0：只说方案先进或效果好，没有备选比较。
1：知道一个备选方案，但说不清真实约束。
2：能结合质量、时延、成本或维护性解释选择。
3：有候选对比、实验或决策记录，并能说明放弃条件。
dimension：metric-credibility
0：只有提升结论，没有指标定义和基线。
1：有数字，但缺评测集、统计窗口或口径。
2：指标、基线、样本和统计口径基本完整。
3：能用固定任务集和故障演练核验任务成功、恢复成功、重试与人工介入口径。
dimension：failure-review
0：声称没有失败案例或只归因于模型能力。
1：能举失败现象，但没有复现和根因证据。
2：能给出代表性坏例、定位过程和修复验证。
3：有失败分类、复现材料、反事实验证和遗留边界。
dimension：production-engineering
0：只讲离线 Demo，不了解上线约束。
1：知道监控或降级概念，但没有具体阈值。
2：能说明时延、容量、监控、灰度和回滚。
3：能用图版本、状态迁移、死信、人工 SLA、Checkpoint 恢复和补偿记录证明上线。
dimension：consistency
0：前后职责、数字或架构明显冲突。
1：主要结论一致，但追问后口径频繁变化。
2：事实、指标和方案在多轮回答中保持一致。
3：能主动声明不确定项、版本变化和证据边界，回答可交叉核验。
dimension：chain-understanding
能说清状态迁移、Checkpoint 和恢复语义。
dimension：failure-review
能复现重启或重复消息并证明无副作用。
dimension：production-engineering
有工作流版本、死信和人工 SLA。
dimension：consistency
把内存对话历史当作可靠状态。
dimension：production-engineering
没有幂等、租约或死信处理。
dimension：tradeoff
所有节点都交给模型自由决定。