READ · UNDERSTAND · TRANSFER
阅读理解，按需巩固
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · 编排抽象与业务责任的匹配
先理解核心原理
先备概念：有限状态机、持久任务、团队运维能力
框架应覆盖任务真正需要的控制与恢复复杂度，而不是替业务承担不存在的保证。选型比较同一任务的故障行为、调试成本和状态迁移边界。
先画任务，不先画框架
三个确定工具调用可能只需要有限循环与异常处理；分支、共享状态与人工中断需要更明确的图；跨天等待和严格恢复可能需要工作流引擎。模型自主决定下一步和固定业务编排是不同维度，使用多个 Agent 不能消除恢复责任。
每引入一层都有边界
既有 Java 平台可能已经覆盖身份、任务持久化和审计，引入 Python 服务增加网络协议、版本、部署与故障协调。收益应来自可验证的状态编排需求，不是生态流行。工具外部幂等和权限最终仍在业务服务处理。
选型试验包含升级
让同一任务经历 worker 宕机、等待批准、工具成功但回执丢失，再试状态格式变化。能恢复旧任务与能启动新 Demo 是不同能力；保留运行版本或显式迁移都要预算维护成本。这里提供比较方法，没有给出未执行的框架性能排名。
回到问题：怎样回答？
先看任务形态。短流程、少量工具和明确终止条件可以用原生 SDK 自己写有限循环；需要分支、共享状态、暂停恢复时考虑 LangGraph；跨天任务、定时等待和服务故障恢复严格时评估工作流引擎。各框架提供的抽象不同，不会自动解决权限、内容质量或外部幂等。用相同任务和故障样例比较可恢复性、排障成本、延迟和迁移边界，再决定。
实现与取舍
先写约束而不是选名字
列出工具数量、任务最长时长、分支数量、是否需要人工等待、故障后从哪里恢复，以及团队熟悉的语言和部署环境。两次读取后总结的流程，用一个有步骤上限和超时的循环即可；把它拆成十个 agent 往往增加上下文复制、追踪与一致性成本。只有存在独立职责、可并行任务或可测量的路由收益时，再引入多 agent。
按抽象选择实现
原生模型 SDK 适合掌控请求与响应契约，需要自行实现工具分发、状态和错误分类。OpenAI Agents SDK提供工具、handoff、guardrail 与 tracing 等构件，可缩短标准 agent 循环的搭建时间；仍需确认所用模型、部署和数据处理选项符合需求。LangGraph overview强调持久化执行、流式输出和人工参与，适合把确定步骤与模型决策放入明确图结构。它不是答案质量保证，也不会替开发者完成租户授权。
长期等待需要额外评估
若任务跨天、等待外部回调、涉及定时重试和多个业务系统，评估专门工作流引擎的事件记录、活动调度和故障恢复。Temporal 的 Activity Execution区分活动执行与重试；调用外部服务的活动仍需考虑重复执行。引入引擎会增加部署、版本管理和排障成本。也可以保留现有任务队列并补齐检查点，但要明确恢复语义，不能将队列投递成功等同业务完成。
用同一实验决定取舍
准备一个读取工具、一个故意超时工具、一处人工暂停和一个写入动作，在候选实现中使用相同模型及输入。记录代码复杂度、状态可查询性、失败恢复行为、延迟和费用，不把不同提示词造成的结果差异归功于框架。比较进程在工具完成后退出、重复回调、恢复期间更换代码版本三种场景。模型适配、工具 schema、业务状态和权限判断封装为独立模块，框架只负责调度。结果记录为 ADR：为何选择、可接受限制、何时重新评估，并固定依赖版本和升级回归样例。选型的目标是让任务可理解、可恢复、可维护。
工程推演
- 场景
- 假设工程场景：一个内部知识助手从单次问答扩展为审核后生成并发布研究报告。
- 设计决策
- 先实现明确状态和工具契约，再分别验证有限 SDK 循环与图编排是否满足恢复需求。
- 验证目标
- 预期形成可复核的选型记录；本文没有实际跑分，也不宣称某框架一定更快或更准。
- 适用边界
- 框架能力与生态会变化，升级必须重新检查 API、持久化兼容性及回归结果。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层既有 Java 任务平台，何时值得引入 Python 图编排服务？
选型不仅比较抽象，还要结合现有 Java 平台与团队成本。
参考解答
当分支与中断需求明显超出现有平台能力，且团队能维护跨语言契约、部署和排障时再考虑。先做隔离小服务，用稳定业务 ID 和有限 API 接入；如果 Java 平台已覆盖需求，保留单栈通常更简单，不能仅因示例用 Python 就重写核心。
第 1 层业务流程固定时，为什么可能不需要多 agent？
工作流需求与多 Agent 需求应分别证明。
参考解答
固定步骤可由普通工作流保证顺序和重试，模型只处理需要语言判断的局部。多 Agent 增加消息、交接与不一致状态，未必提高效果；只有职责或上下文隔离产生真实收益才拆分，并验证交接和终态，而不是把角色名字当架构理由。
第 1 层框架升级改变状态格式，正在等待审批的任务怎么迁移？
框架状态持久化之后，还需面对升级与旧任务兼容。
参考解答
对已暂停任务保留可执行旧版本，或读取旧快照并做显式、可回退迁移。检查节点名称、字段类型、工具语义与批准对象兼容；LangGraph 对暂停线程的删改节点和不兼容状态类型有边界，不能把 schema 能解析当业务兼容。
沿着这个回答继续深入
第 2 层旧字段改名，新字段意义相同，直接读取默认值可行吗？
父问描述状态迁移，子问选常见字段改名与默认值陷阱。
参考解答
不可静默这样做。旧快照需要明确映射，否则缺失字段可能被当初始状态导致重做。迁移记录旧值、新值和状态版本，检查必要业务键与已执行事实；不能恢复的信息保持待处理，而不是用默认值伪造。
沿着这个回答继续深入
第 3 层迁移后的状态能通过类型检查，为何仍要故障验收？
父问有显式映射，继续区分结构兼容与行为兼容。
参考解答
类型只说明字段形状，不说明恢复点、动作语义和外部效果一致。用旧任务快照推演恢复，检查不重复提交、批准仍对应同一对象、终态正确；若没有实际运行则仅报告设计审查，不能称为迁移验证通过。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
从分钟任务变成跨天审批
改变的条件：等待时长与 worker 重启概率大幅增加。
延伸问题：原内存循环如何演进？
推导与参考解答
把状态、批准对象与动作账本持久化，选择能够等待恢复的编排；比较现有任务系统增强与引擎接入成本。流程恢复后仍重验权限和资源版本。需求的时间变化促成持久机制，不自动要求多 Agent。
保持不变的原理：选型按控制和恢复需求补缺口。
流程固定、仅分类需要模型
改变的条件：无需自主探索，输出空间受限。
延伸问题：需要完整图服务吗？
推导与参考解答
可以用现有工作流加一次受约束模型分类，程序路由到确定步骤，并对分类失败设回退。只有分支共享状态或恢复复杂度增大时再引入图；仍保存配置和验收，不以框架多少判断能力。
保持不变的原理：最小实现应满足真实任务契约并可检查。
易错点
- 将某框架宣称为所有 Agent 场景的唯一方案。
- 只比较最短 demo，忽略恢复、部署和排障工作量。
- 将业务权限与工具实现写进框架专用回调，导致难以迁移和测试。
参考资料
依据公开技术资料设计；参考资料支持技术机制，场景与评分标准为本站设计，不代表某公司面试原题。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 知道框架、SDK 与工作流引擎解决不同层次问题。
- 中高级信号
- 按状态复杂度、恢复、人机协作与团队能力比较。
- 资深信号
- 通过最小原型验证并说明迁移成本、锁定与退出策略。
巩固练习 按需完成 · 建议 15 分钟
比较一次问答、小时级研究、跨天审批三种任务的技术选择。
展开验收要求与检查点
- 选择对应任务约束
- 恢复保证有验证
- 不以框架流行度代替依据
重点检查
- 能从需求推导框架，而非从框架名称反推需求。
- 明确 agent orchestration 与 durable workflow 的不同职责。
- 能说明状态与工具接口如何隔离，避免业务完全绑定框架。