编排框架选型

• 五个选型维度的具体含义
• 各维度与业务需求的映射
• 多维度加权决策

五个维度的考量：状态持久化——框架对 checkpoint、断点恢复、时间旅行的支持程度（长任务、需要中断续跑的系统必须要求原生持久化，如 LangGraph 的 Checkpointer 与 Durable Execution；短任务可以放宽）；类型系统——框架是否提供结构化状态与类型校验（Python 的 Pydantic 集成、TS 的 zod 类型），类型系统决定状态与工具定义的可靠性，复杂业务数据强烈需要；HITL——框架对人工审批/暂停/恢复的原生支持（interrupt/resume、审批节点），有强人工介入需求的系统（金融、审批流）必须重点评估；可观测性——trace 的自动采集（LangSmith、OpenTelemetry 集成、自带的追踪视图），生产系统要求"开箱即用的 trace + 跨节点关联 ID"；团队语言——框架的技术栈是否与团队技能匹配（Python 团队选 Python 框架、Java 团队选 Spring AI/LangChain4j、.NET 团队选 Semantic Kernel），团队语言是最现实的门槛。

选型流程：先按"硬性需求"过滤（必须支持持久化/HITL/语言的框架入候选），再按"软性维度"评分（类型系统、可观测性、社区活跃度），最后做原型验证（跑一个代表性任务，比较真实体验而非文档）。维度权重按业务定：长任务系统重持久化，B2C 对话重可观测性与延迟，金融系统重 HITL 与类型安全。注意：框架选型是"业务约束下的匹配"，不是"排行榜第一"——同一业务可能选多个框架（不同子任务用不同框架），关键是与需求对齐。

本题考察框架选型的系统方法。回答要给出五维度的含义与各自对应的业务需求，以及"硬性过滤 + 软性评分 + 原型验证"的流程。核心是"选型是需求匹配，不是功能比拼"。

• 框架锁定的表现：业务代码依赖框架类型
• 隔离架构：适配层与端口
• 迁移成本控制

框架锁定的根源是"业务代码直接使用框架的状态对象与 API"——业务逻辑散落在框架节点函数里、业务数据用框架的状态类型承载，导致换框架等于重写业务。隔离的架构原则是"端口-适配器"（六边形架构）：定义独立的领域模型与业务接口（业务实体、业务操作、业务流程接口），编排框架只作为"适配层"——框架的节点/工具通过适配器调用领域服务，框架的状态对象只做"传输"（从框架状态映射到领域对象，再映射回来），业务层完全不感知框架类型。

具体做法：状态映射层——框架状态（如 LangGraph 的 State）与领域模型分离，节点内先反序列化为领域对象再处理，产出再序列化回框架状态，业务规则只写领域对象；依赖方向——领域层不 import 框架包，框架层 import 领域层；编排描述独立——流程定义（节点、边、依赖）用业务可读的配置/DSL 描述，框架只是执行器；副作用与工具调用封装在适配层，换框架时只重写适配层（节点包装、状态映射、工具注册），领域逻辑与流程定义原样保留。收益：框架升级、更换甚至"从框架回到自研运行时"，业务层不受影响；可同时验证多个框架（同一业务逻辑跑不同框架对比）。代价是增加映射层代码，但相比"被锁定"的迁移成本，这个投资是必要的。

本题考察防框架锁定的架构设计。回答要给出端口-适配器架构、状态映射层与依赖方向控制。核心是"业务层不依赖框架类型，框架只是可替换的执行器"。

• 升级影响面：序列化格式、checkpoint 结构、工具语义
• 迁移方案：数据迁移 + 兼容层
• 回归验证：历史任务回放与灰度

框架升级的迁移分三步：影响评估——对照 changelog 确认三类破坏性变更：序列化格式（状态/消息的存储格式变化，影响已存数据读取）、checkpoint 结构（断点恢复的存储 schema 变化，影响长任务续跑）、工具语义（工具调用约定、参数校验变化，影响工具层）。评估要"数据先行"——盘点存量 checkpoint 与状态数据，用新版本代码尝试读取旧数据，实测兼容性而非看文档推断。

迁移实施：数据迁移——写迁移脚本把旧格式数据转换为新格式（字段映射、版本转换），迁移要在隔离环境验证（迁移后数据能被新版本完整恢复并正确续跑）；兼容层——短期内保留旧格式读取路径（新版本支持读旧 checkpoint），双写过渡（新旧格式并存一段时间）降低一次性切换风险；工具语义变更——检查工具注册与调用的适配，参数与返回结构按新语义调整。回归验证：历史任务回放——用线上真实任务（含正常、失败、中断恢复的样本）在新版本上重放，对比结果一致性与恢复正确性；功能回归——HITL 中断恢复、时间旅行、并行汇合等重点能力逐项测试；灰度发布——按流量百分比灰度，监控成功率、恢复率与延迟，异常立即回滚。核心原则：升级要"数据可迁移、旧版可回退、回归可量化"。

本题考察框架升级的迁移工程。回答要覆盖影响评估（序列化/checkpoint/工具三类）、数据迁移与兼容层、历史回放与灰度验证。核心是"升级以数据兼容与可回退为底线"。

• trace 的层级结构：任务、节点、子图、子 Agent、工具
• 关联 ID 的传播机制
• 统一采集的技术方案

统一采集的核心是"上下文传播（context propagation）"：定义全局唯一的业务关联 ID（trace_id / business_id），从任务发起时生成，贯穿所有层级——主流程、子图、子 Agent、工具调用都携带同一 trace_id，嵌套调用再生成子 span ID（parent-child 关系），从而把分散的日志串成完整调用树。技术方案：基于 OpenTelemetry——框架层（LangGraph 等）已有自动埋点或通过 hooks 接入 OTel，每个节点/工具调用生成 span（名称、时间、输入输出摘要、状态），span 通过 context 注入传递到子 Agent 与工具调用（HTTP 头、消息字段携带 traceparent）；自研埋点——框架 hooks/callbacks 里手动创建 span 并传递 trace_id，工具层用中间件自动附加。

实践要点：关联 ID 的传播要"无遗漏"——所有出口（外部 HTTP 调用、消息队列、子进程）都要注入 trace_id（W3C traceparent 标准），否则断链；数据汇聚——span 上报到统一后端（Jaeger、LangSmith、云 APM），按 trace_id 聚合查询，支持"一次搜索看到整条任务链"；关联业务上下文——trace 与业务数据关联（任务表里存 trace_id，业务查询与链路查询互通）；跨组织（A2A）场景 trace_id 作为标准头传递，但注意不泄露业务正文。统一采集的价值：故障定位从"翻日志"变成"看调用树"，成本归集与性能分析（哪类节点慢、哪类工具贵）都建立在同一 trace 之上。

本题考察跨层级 trace 的统一采集。回答要讲清 trace_id 的生成与上下文传播（OTel、W3C traceparent）、span 层级结构、统一汇聚与业务关联。核心是"关联 ID 贯穿所有层级，断链即失联"。

• 框架重试的定位：技术层重试
• 业务补偿的定位：业务层撤销
• 事务边界的控制权：业务方而非框架

框架重试是"技术层重试"：针对瞬时失败（网络、超时、限流），重复执行同一个技术操作，语义是"同样的调用再来一次"；业务补偿是"业务层撤销"：针对已产生的副作用，执行反向业务操作（退款、撤销、恢复），语义是"把已发生的事逆向处理"。两者不能混同：重试适合"未生效或可安全重复"的操作（幂等），补偿适合"已生效且不可重复"的操作；框架不知道业务的副作用语义（扣款后重试还是退款？只有业务知道），所以框架能做的是"重试与失败通知"，补偿逻辑必须由业务实现。

事务边界的控制权在业务方：框架提供执行编排（顺序、重试、状态），但"哪些操作组成一个事务单元、失败时如何补偿"是业务领域知识——由业务代码定义事务边界与补偿动作（Saga 模式：每个业务步骤配正向操作与逆向补偿，编排器按业务配置执行补偿序列）。实践建议：框架配置技术重试（次数、退避、幂等键），业务层实现补偿（每步注册 undo 动作、记录副作用清单、定义补偿顺序与幂等）；框架触发的失败事件（重试耗尽）交给业务决策（补偿 / 重规划 / 人工），不要让框架自动"补偿"（框架不知道业务语义，自动补偿会做错）。核心原则：技术可靠性（重试）框架管，业务一致性（补偿与事务边界）业务管。

本题考察重试与补偿的职责划分。回答要讲清技术重试与业务补偿的本质差异，以及事务边界的业务归属（Saga 模式）。核心是"框架管重试，业务管补偿，事务边界是业务知识"。

• 灰度发布策略：流量灰度与实例灰度
• 回滚预案与新旧兼容
• 在执行任务的三类保护：兼容、迁移、续跑

灰度与回滚：灰度——先在小流量（如 5%-10%）或影子模式（复制流量到新版本但不影响用户）验证，逐步放大到全量；实例级灰度（部分实例升级，新旧实例并存）配合路由控制（新实例接测试流量）；指标门禁——每个灰度阶段检查成功率、延迟、恢复率、异常率，达标才放量，不达标立即暂停。回滚——保持旧版本可用（新旧版本并行部署，避免"升级即删旧"），新版本异常时路由切回旧版本；回滚不仅是代码回退，还有数据回退问题（新版本写过的状态与 checkpoint，旧版本能否读取——通过数据兼容设计保证）。

对正在执行任务的保护三类：兼容读取——旧 checkpoint 新版本可读、新 checkpoint 旧版本可读（双格式兼容），保证任意时刻切换版本任务都能恢复；存量任务迁移——升级时正在运行的长任务，在版本切换点（节点边界）迁移到新版本继续执行（迁移其 checkpoint 格式），或允许其在旧版本实例上跑完；执行保护——灰度期间不强制中断运行中的任务（等待其自然完成或人工确认后迁移），框架升级不丢状态。实践上配合"升级窗口"：选择低峰期，提前探测存量任务，制定"继续跑完/迁移/重跑"的分类策略；升级后观察期验证恢复功能（中断恢复是框架升级最易损坏的能力）。核心原则：升级期间"任何时刻任何版本都能恢复任意任务"，这是无痛升级的底线。

本题考察框架升级的灰度与任务保护。回答要覆盖流量/实例灰度、回滚预案与存量任务的三类保护（兼容读取、迁移、续跑）。核心是"升级无痛的前提是数据双向兼容与版本可回退"。

• 内置工具与 MCP Server 的特性差异
• 选型维度：耦合、复用、生态、治理
• 内置工具成为限制的场景

内置工具（框架/库自带：LangChain 的工具、SDK 内置检索等）与外部 MCP Server（独立进程/服务暴露工具）的差异：内置工具集成简单（代码级调用）、延迟低、调试方便，但绑定框架生态（换框架工具重写）、复用性差（跨框架/跨 Agent 难共享）、难以独立治理（版本、权限、监控随框架走）。MCP Server 是标准协议的外部服务：工具能力与框架解耦（任何支持 MCP 的客户端可复用）、可独立部署与治理（权限、鉴权、版本、监控在服务侧）、生态互操作（同一工具服务给多个 Agent/框架用），代价是额外网络层（延迟）、服务治理成本（部署、运维）。

内置工具成为限制的场景：工具需要被多个框架/Agent/团队复用（一个支付工具服务要接 LangGraph、CrewAI、Claude 等多个客户端）；工具权限与审计要求独立管控（安全团队要求工具独立鉴权与审计，不能藏在应用代码里）；工具需要独立演进与发布（工具团队独立迭代，应用侧不感知）；异构技术栈（工具是 Java 服务，Agent 是 Python——MCP 协议消除语言耦合）。选型结论：单框架、轻量、内部专用工具用内置；跨框架复用、强治理、异构系统用 MCP Server；大系统常混合——内部简单工具内置，核心业务与外部能力走 MCP。判据核心是"工具的复用半径与治理边界"。

本题考察工具集成方式选型。回答要对比内置与 MCP 的差异（耦合、复用、治理），给出"复用半径与治理边界"判据与混合实践。核心是"工具是资产，跨系统复用与独立治理时 MCP 更有价值"。

• 场景异质性：任务类型、约束、团队差异
• "最佳选择"论断的认知错误
• 选型的场景化与组合化

没有"所有场景最佳"的框架，原因在于 Agent 场景是异质的：任务结构不同（确定性流程 vs 开放探索 vs 实时对话——分别适合状态图、ReAct 循环、流式 SDK）；约束不同（延迟敏感、成本敏感、合规敏感——框架在这些维度上有不同的权衡位置）；团队与生态不同（语言、技能、已有基础设施）；规模不同（原型、单任务、高并发生产——框架的复杂度与开销适配不同阶段）。"某个框架全场景最佳"的论断忽视了这些维度，本质是把"适合我的场景"错误外推为"适合所有场景"。

正确认知：框架各有设计取舍——LangGraph 强在状态图与持久化、CrewAI 强在角色化快速搭建、AutoGen 强在并发消息、Pydantic AI 强在类型安全、Semantic Kernel 强在 .NET 集成；每个框架的"最佳实践"都隐含其适用前提。选型应场景化：按任务结构、约束、团队三个维度匹配，甚至同一系统内多个框架组合（不同子任务用不同框架，通过标准接口衔接）；同时保持"框架可替换"的架构（适配层隔离），让"当前选型"不变成"永久绑定"。宣传"全场景最佳"的框架往往低估了场景约束的差异，工程上要警惕这类话语。

本题考察框架选型的认知方法论。回答要论证场景异质性（任务结构、约束、团队）决定框架适配，以及"最佳选择"论断的外推错误。核心是"框架是权衡的产物，选型必须场景化"。

• 迁移判据：复杂度信号（分支、状态、重试逻辑膨胀）
• 可靠性信号（恢复、一致性、并行需求）
• 迁移的时机与成本评估

复杂度信号：代码中手写流程控制的规模——if-else 分支数量膨胀、状态字段散落（用临时变量传递状态）、重试逻辑在各处重复实现、人工介入靠"暂停线程/轮询"硬编码、并行需要手写线程管理；当这些"手写编排"开始重复出现（同样的状态检查代码复制多份、改一个分支要改多个地方）时，说明编排复杂度超过了手写可维护的边界。可靠性信号：出现进程重启丢状态、重试造成副作用重复、任务中断无法恢复、并发分支难以汇合等问题，且修起来越来越费劲——这些正是编排框架设计要解决的（checkpoint、幂等、状态机、并行汇合）。

迁移依据综合判断：任务数量与种类增长（从 1-2 个流程到几十个）、状态持久化与恢复成为硬需求（长任务）、多人协作维护（手写编排难交接）、以及"失败成本"上升（手写编排出错影响生产）。迁移的成本评估：框架学习成本、现有代码改造量（把散落的流程逻辑收拢到框架结构）、测试回归范围——只有当"继续手写的维护成本"超过"迁移成本"时才迁移；且迁移要渐进（先迁移一个高频流程做试点，验证框架收益再铺开）。核心信号一句话：当"流程本身"成为你的业务复杂度瓶颈时，就到了引入编排框架的时候。

本题考察迁移时机的判断。回答要给出复杂度与可靠性两类信号的具体表现，以及综合判据与渐进迁移策略。核心是"手写编排的维护成本超过框架迁移成本时迁移"。

• 最佳实践的前提假设与适用边界
• 业务场景差异：数据、风险、约束
• 适配清单：状态、工具、错误处理、安全

框架"最佳实践"文档通常是框架作者在其假设场景下的优化方案，隐含多个前提：数据规模与形态（小状态 vs 大对象）、失败容忍度（可重试 vs 必须人工）、安全要求（内部工具 vs 严格鉴权）、团队与运维形态。直接套用会出问题：文档推荐的默认 checkpoint 存内存/文件，你的生产要分布式存储；文档示例的错误处理是"重试"，你的业务需要补偿与审批；文档的示例工具是演示用的，你的工具需要权限校验与审计。最佳实践是"起点"不是"终点"。

适配清单：状态设计——按业务数据重新建模状态（类型、粒度、敏感字段），不直接用示例字段；持久化——按可靠性要求选 checkpoint 后端与频率（数据库/对象存储、事件+快照）；工具与权限——工具按最小权限挂载、加鉴权与审计，不按示例全量暴露；错误处理——按业务错误分类配置重试/补偿/人工策略（替换示例的默认重试）；安全与合规——数据脱敏、租户隔离、审批点按业务风险插入；可观测性——接入自己的 trace 与告警体系，替换示例的简单日志；性能——按流量与延迟目标调参数（并发、超时、批大小）。适配后要回归验证（自己的评测集跑通），不能只跑通示例就算完成。核心原则：最佳实践解决"通用问题"，业务适配解决"你的问题"。

本题考察最佳实践的批判性应用。回答要论证文档最佳实践的前提假设（数据、风险、安全、运维），再给适配清单。核心是"把最佳实践当起点，按业务场景逐项适配并验证"。

• 迁移规划：评估、适配、验证、切换
• 数据可移植：状态与 checkpoint 的导出导入
• 轨迹可移植：trace 与日志的迁移

迁移规划分四阶段：评估——盘点现有实现（节点、工具、状态、错误处理、HITL 逻辑）与新框架的映射关系（LangGraph 节点 ↔ CrewAI 任务 ↔ AutoGen 消息），识别"直接映射"与"需要重写"的部分（通常业务逻辑直接映射、框架 API 重写）；适配——写适配层（领域模型隔离的价值在此体现：业务层不变，只重写框架适配层）；并行验证——新旧框架同时运行同一业务（影子模式）对比结果；切换——按流程灰度迁移，保留回滚通道。

数据可移植：状态数据——通过框架提供的导出能力（序列化为标准格式：JSON/事件日志）导出，导入时按新框架的 schema 映射（字段映射表 + 迁移脚本）；checkpoint——旧 checkpoint 迁移为"业务状态快照 + 事件流"，新框架从业务状态重建（迁移时允许"已完成步骤登记导入、未完成步骤重跑"的分层策略，不追求 checkpoint 逐字节兼容）；幂等与副作用登记表是框架无关的（业务侧持久化），可直接复用。轨迹可移植：trace 数据通过标准格式（OpenTelemetry）导出，迁移到新框架后统一采集到同一 trace 后端（trace_id 沿用），历史轨迹与新轨迹可在同一视图查询对比；业务日志保持格式统一（结构化 JSON），框架差异只体现在调用层次上。核心原则：业务状态与 trace 用"框架无关的格式"持久化，迁移时数据是资产而非负担。

本题考察跨框架迁移的方法论。回答要覆盖四阶段规划与数据/轨迹的可移植设计（标准格式、映射、适配层）。核心是"数据与轨迹脱离框架格式存储，迁移即可复用"。

• 低代码的适用人群与场景
• 生产环境的调试痛点
• 低代码与代码的共存策略

低代码可视化编排的价值分人群：业务人员与运营（快速搭简单流程、看流程全貌）与"原型探索"阶段（快速验证想法）确实有用；但生产环境中，复杂 Agent 系统的核心矛盾是"可视化配置表达力有限"——条件逻辑、异常分支、数据转换、幂等与补偿等生产级细节难以用拖拽表达，最终仍要落代码；且可视化编排与代码"双轨"会引入不一致（画布上的流程与代码实际执行的不一致）。生产级系统的调试（断点、状态检查、重放、单元测试）在纯可视化环境中受限，工程师更习惯"代码即真相"。

工程师是否会放弃低代码：当调试困难（无法单测、无法版本化 diff、无法定位线上问题）时，工程师会绕过可视化层直接改代码，最终可视化画布与实际逻辑脱节，弃用。合理形态是"代码优先 + 可视化辅助"：以代码定义流程（可版本控制、可测试、可 review），可视化作为"只读视图"展示流程结构与运行状态（调试与讲解用）；或低代码平台必须提供"代码导出"能力（画布导出为标准代码，后续在代码中演进）。选型建议：纯业务搭建（无复杂逻辑）可低代码；生产级复杂 Agent 用代码优先，可视化做观测辅助。核心判断：低代码的价值在于"看得见"，生产的价值在于"可调试"，两者结合而非二选一。

本题考察低代码编排的适用边界。回答要论证低代码的表达力限制与调试痛点，以及工程师弃用的机理，给出"代码优先 + 可视化只读辅助"的结论。核心是"生产要代码即真相，可视化做观测不做真相"。

• 混部成本归集的难点：口径不一、埋点分散、归属不明
• 基于 trace 的费用桥：span 级费用标注与汇总
• 归集口径与分摊规则

混部难归集的根源：各框架的成本数据口径不一（Token 统计方式不同、有的按请求、有的按步骤）、埋点位置分散（框架自带埋点、应用层埋点、模型网关埋点各自独立）、归属不明（一次业务请求跨多个框架/子 Agent 执行，成本分散在各段，难以按业务维度汇总）；且框架间没有统一的"调用链"，成本无法沿着真实执行路径归集。费用桥的方案：以统一 trace 为骨架——所有框架的调用都纳入同一 trace，在 span 上标注费用维度（模型调用的 token 数与单价、工具调用的外部费用、计算资源费用），各框架通过适配层把各自成本写入对应 span 的 attribute；汇总时沿 trace 树自底向上聚合（父 span 成本 = 自身成本 + 子 span 成本），实现"一次业务请求的总成本可沿调用链精确归集"。

归集口径设计：按维度聚合——业务类型（trace 的业务标签）、Agent/节点（span 名称）、模型（model attribute）、租户/用户（trace 携带的业务 ID）；分摊规则——公共成本（共享模型服务、基础设施）按用量分摊或独立记账；费用桥的工程要点：统一费用 schema（span 上定义 cost 属性标准：token 输入/输出、单价、总价、币种）、成本口径校验（各框架上报口径一致化，定期对账模型网关账单与 span 统计的差异）、成本爆炸预警（按 trace 聚合后设置任务级成本上限，超限告警）。核心价值：成本归集从"各框架各算各的"变成"沿真实执行路径统一结算"。

本题考察混部成本归集的工程方案。回答要讲清归集难的三类原因，再给出"trace 为骨架、span 挂费用、沿树聚合"的费用桥设计。核心是"成本必须挂在真实执行路径上才能归集准确"。

• 内置评估的定位：通用框架级指标
• 业务指标的必要性：业务语义、验收标准
• 必要的接入点：回调、hook、trace、事件

框架内置评估（如 LangSmith 的通用评分、框架自带的 trace 统计）衡量的是"框架层事实"——执行是否成功、耗时、token 消耗、重试次数；这些指标对监控框架运行健康度有用，但回答不了业务问题——"这次客服回答是否解决了用户问题""退款流程是否符合合规标准""推荐是否提升了转化"。业务指标的判据来自业务领域（验收规则、业务结果、用户反馈），必须由业务自定义，内置评估无法替代；把内置指标当全部评估，会导致"系统运行正常但业务目标未达成"的盲区。

应保留的接入点：回调与 hooks——节点级回调（每步完成/失败/重试时执行业务逻辑，如业务指标统计、规则校验）；自定义评估器——在框架的评测流程中挂业务评估函数（跑完任务后执行业务验收：结果 schema 校验、业务规则检查、用户反馈回收）；事件流——框架执行事件（任务开始/节点完成/终止）发布到业务事件总线，业务系统消费做指标与联动；trace 扩展——span 上附加业务标签（任务类型、结果代码、业务 ID），让业务指标与框架指标在同一 trace 上关联分析；指标导出——业务指标接入统一监控体系（而非只看框架面板）。设计原则：框架提供"钩子"与"数据通道"，业务填充"语义"，两者互补——内置评估看框架健康，自定义指标看业务成效。

本题考察评估体系的职责划分。回答要讲清内置评估只覆盖框架层事实、业务指标承载业务语义，以及应保留的回调、自定义评估器、事件流与 trace 扩展等接入点。核心是"框架给通道，业务给语义"。

• 三类存储的特性：内存级 / 事务性 / 大对象
• checkpoint 的访问模式：高频小写 vs 低频大快照
• 选型与组合策略

三类存储的定位：Redis——内存级 KV，读写极快，适合"高频、小体积、短生命周期"的 checkpoint（会话级状态、短任务的断点），代价是数据易失（需持久化配置 RDB/AOF）与容量受限，适合热状态层；PostgreSQL——关系型 + 事务，适合"结构化状态、需要强一致与查询能力"的 checkpoint（任务状态表、步骤记录、幂等登记），支持事务性写入（checkpoint 与业务状态原子更新）与按字段查询，是生产环境最常用的 checkpoint 后端；S3/对象存储——大体积快照，适合"大对象状态"（完整上下文、检索内容、中间产物），容量大成本低，但读写延迟高（不适合高频小写），且无事务语义，适合冷态/大块数据层。

工程组合：高频小状态（最新几轮状态）放 Redis 加速读写，结构化任务状态与审计放 PostgreSQL 保证一致性与查询，大体积快照（历史 checkpoint 全量、上下文备份）放 S3；恢复时按"最新 Redis → PostgreSQL 对账 → S3 大快照"分层加载。选型细节：checkpoint 频率决定存储——秒级高频写用 Redis（注意持久化配置防丢）、分钟级写用 PostgreSQL 即可；体积决定存储——单 checkpoint 超过 MB 级考虑对象存储引用；一致性要求决定存储——需要与业务数据事务一致用 PostgreSQL，纯缓存性质用 Redis；还要考虑恢复性能（S3 恢复慢，适合低频恢复）与成本（Redis 内存贵，长任务状态常驻要算账）。核心原则：按"频率、体积、一致性"三维选型，生产常用组合而非单存储。

本题考察 checkpoint 存储选型。回答要给出三类存储的特性与适用场景，以及"Redis 热层 + PostgreSQL 事实层 + S3 大对象层"的组合模式。核心是"按访问频率、体积与一致性要求分层存储"。

• 主流开源 License 的权利义务差异
• 开源与商业双许可的陷阱
• License 评估的工程流程

主流 License 的权利义务：Apache 2.0——宽松许可，可商用、可修改、可闭源分发，需保留版权声明与 NOTICE 文件，附带专利授权，是最安全的企业友好许可；MIT——更简单的宽松许可，可商用，仅要求保留版权声明；两者适合大多数企业场景，Apache 2.0 的专利条款在专利诉讼场景更有保护。Elastic License（ELv2）——"源码可用"而非开源：允许使用与修改（内部使用），但禁止提供托管服务（SaaS 托管该软件收费场景受限）、禁止移除许可限制，企业自用通常可行，但"把框架做成对外托管服务"受限；商业许可——闭源或双许可（开源版 + 商业版），商业版提供额外功能（企业级特性、支持服务），企业需付费购买，注意"开源版功能裁剪"对业务的影响。

企业评估流程：确认使用方式（内部使用/修改/对外提供 SaaS）与每个 License 的兼容性（ELv2 的托管限制是常见坑）；检查依赖链——框架的传递依赖 License（框架用 GPL 依赖会使整体传染，要扫描依赖树）；区分"框架 License"与"模型/数据 License"（模型权重与训练数据的许可单独评估）；记录义务（版权声明、NOTICE 保留）；建立清单管理——引入新框架/依赖时做 License 评审入库。核心原则：License 影响"你能否这样用、要不要付费、有什么义务"，必须在使用方式确定后评估，不能只看"是不是开源"。

本题考察框架 License 的工程评估。回答要对比四类 License 的权利义务（重点 ELv2 的托管限制与 GPL 传染性），给出按使用方式的评估流程。核心是"License 评估绑定使用方式，依赖链要整体扫描"。

• Agent Card 的构成：能力、技能、输入输出契约
• 能力夸大的危害与验证方法
• 契约测试自动化

Agent Card（A2A 协议中的能力声明，JSON 描述 Agent 的技能、输入输出模式与安全信息）编写原则：能力声明"可验证"——每项技能声明对应的输入 schema、输出 schema 与调用约束（参数必填、限制、权限），不写"能完成所有任务"这类不可验证的描述；技能粒度适中——技能按"可独立调用、契约清晰"拆分（"查航班"是技能，"帮用户出行"是多个技能的组合），避免大而全导致契约模糊；声明与实现一致——Card 内容必须与 Agent 实际行为对齐，任何不一致都导致调用方按错误假设调用而失败。

验证与契约测试自动化：契约测试——为每项技能生成测试用例（合法输入、边界输入、非法输入、超时），自动化验证"Card 声明的 schema 与真实接口行为一致"（请求按 schema 构造、响应按 schema 校验）；能力抽测——定期随机抽取声明技能做真实调用验证（用测试环境），发现能力退步（声明能做但实际做不好）即告警；漂移监控——Card 版本化，发布与更新走 CI（Card 变更触发契约测试全量回归），防止"改实现忘了改 Card"；互操作测试——用标准客户端按 Card 调用，验证跨厂商兼容（状态机一致、错误码映射）。核心原则：Agent Card 是"对外承诺"，承诺必须被自动化验证，未验证的承诺就是夸大。

本题考察 A2A 能力声明的可信度工程。回答要讲清 Card 的编写原则（可验证、粒度适中、实现一致）与契约测试自动化（schema 校验、能力抽测、版本化 CI）。核心是"能力声明要被持续验证，防止承诺与实现脱节"。

• 技术层约定：认证、计费、审计的协议实现
• 合同层约定：责任边界、SLA、数据
• 两层约定的对齐

跨组织 Agent 调用的三层问题都要"技术 + 合同"双重约定：认证——协议层用标准认证（OAuth2/OIDC、mTLS、API 密钥），明确"谁认证谁"（调用方认证、Agent 的授权范围）；合同层约定凭据的保管责任、泄露责任与权限变更通知义务，避免"技术能通但出事无人担责"。计费——协议层传递计费上下文（调用方 ID、配额、用量计数，A2A 支持费用信息的传递与返回），合同约定计费口径（按调用次数/按 token/按结果）、价格变更通知期、争议处理（计费对账流程，双方对账数据一致）。

审计责任——协议层传递 trace/调用 ID 与审计信息（谁调用了什么、结果如何，双方都记录），合同约定：日志保存期限、审计信息的使用边界（不能用于其他用途）、安全事件的通知义务与责任分配（哪方的数据泄露由谁担责）、以及取证协助义务。对齐原则：技术约定实现"能做什么"（协议支持认证、计费、审计信息传递），合同约定"责任与边界"（做不到或做错了怎么办）；合同条款要映射到技术能力（合同约定"调用方请求须带有效凭据"，技术上落实为强制认证与拒绝无凭据请求）；变更管理——协议版本升级、能力变化要同时反映在合同（SLA 调整）与技术（版本协商）中。核心原则：技术层保证"过程可执行"，合同层保证"结果可追责"，两层缺一不可。

本题考察跨组织 Agent 调用的治理。回答要按认证、计费、审计三个维度分别给出协议层与合同层的约定内容，强调两层对齐。核心是"技术管过程、合同管责任，两层同步升级"。

• 互操作测试的三个层面：状态机、事件、错误码
• 测试套件的组成与用例设计
• 跨厂商验证的组织方式

互操作测试套件按三个层面构建：状态机一致性测试——验证双方对任务状态的理解一致：定义标准状态集（submitted/working/completed/failed 等）与合法转移表，测试用例覆盖每条合法转移（提交→执行→完成）与异常转移（非法状态跳转应被拒绝），验证"我方发起的状态序列对端正确解析、对端返回的状态我方正确映射"；事件顺序测试——验证事件（任务更新、进度通知、完成事件）的到达顺序与语义：乱序事件的处理（迟到的完成事件 vs 进度事件）、重复事件（幂等）、事件与状态的一致性（收到 completed 后不应再有 working 事件）；错误码映射测试——验证双方错误码的对应关系：定义标准错误类别（认证失败、配额不足、无效请求、内部错误），测试"对端返回的错误码我方是否正确映射到本地错误类型并给出正确提示/重试策略"。

套件组织：用例库分层——协议基础（消息格式、认证）、任务生命周期（状态机）、事件流（顺序与幂等）、错误处理（错误码映射）、边界与极端（超时、大响应、并发）；执行方式——接入 CI 定期跑全量回归 + 与新厂商 Agent 接入时跑互操作认证；用标准参考实现（官方测试工具）验证协议合规，再与实际厂商实现做双向测试；发现的不一致（语义分歧、错误码缺失）记录到互操作问题清单，推动协议版本或实现修正。核心原则：互操作不是"能连通"，而是"状态、事件、错误三方语义完全一致"，靠自动化套件持续验证。

本题考察 A2A/ACP 互操作测试。回答要讲清状态机、事件顺序、错误码映射三类测试的设计要点与套件组织（分层用例、CI、参考实现）。核心是"语义一致性验证是互操作测试的灵魂"。

• 超时预算：总超时、分段超时、降级
• 轮询与推送的取舍
• 部分结果的接受与使用策略

超时预算设计：先定总预算（业务可接受的端到端时间上限），再细分到各环节（认证、启动、执行、每段轮询等待）；每个环节独立超时，任一环节超时按策略处理（重试该环节 / 降级 / 放弃）；关键是要有"对端不配合时的逃生通道"——对端无响应超时后，调用方不能无限等待，而是按"放弃并回退"或"用部分结果继续"处理；超时参数要与对端 SLA 对齐（对端声称 P95 10 分钟，调用方总预算至少要覆盖并有冗余）。

轮询与推送取舍：推送（webhook/事件流）实时、省资源，但对端必须支持且要处理推送丢失（推送断链时补轮询）；轮询实现简单、兼容性好，但有空轮询开销与延迟；实践用"混合"——优先订阅推送，推送中断或对端不支持时退化为轮询（带自适应间隔：按剩余预算与进度动态调整频率）；轮询要考虑对端限流（避免频繁轮询触发限流）。部分结果接受策略：任务支持分段产出时（研究任务先出结论再出细节），调用方定义"最小可用结果"标准（达到即算可用，不等待全量）——超时或对端失败时，用已收到的部分结果交付或降级（附"部分完成"说明）；接受部分结果的前提是结果"可切割可用"（独立结论可单独使用），不可切割的任务（转账必须全流程成功）不能接受部分结果，只能失败重试或人工。

本题考察远程 Agent 调用的超时与结果策略。回答要给出总预算分解与逃生通道、轮询推送混合模式、部分结果的接受判据。核心是"调用方永远要有兜底路径，不被对端拖死"。

• 输出 schema 校验：入参出参契约校验
• 漂移监控：字段变化、行为变化检测
• 防 SLA 破坏：版本锁定、兼容策略、告警

输出 Schema 校验：对第三方 Agent 的每个调用定义契约（入参 schema、出参 schema），响应先过 schema 校验（字段存在性、类型、枚举、必填），校验失败按策略处理（重试、降级、告警），防止"对端返回了新结构"直接进入业务逻辑导致崩溃；校验要区分"破坏性变更"（缺必填字段、类型变化→立即拦截）与"非破坏性扩展"（新增可选字段→放行但记录）。漂移监控：定期比对"实际响应结构"与"声明的 schema"——结构漂移（字段增删改、类型变化）、行为漂移（返回语义变化、错误模式变化、延迟变化、成功率变化），用统计与告警发现"悄悄变坏"；对端版本信息（Agent Card 版本、API 版本头）记录在调用日志中，版本变化触发重点验证。

防 SLA 破坏机制：版本锁定与协商——优先调用对端指定版本（版本参数/头），对端升级先做兼容性评估（跑回归契约测试）再切换；缓冲层——己方加适配层，把对端输出映射为内部标准结构，对端变化只影响适配层；双跑验证——对端升级灰度期新旧版本并行调用对比结果；监控与告警——己方 SLA 指标（成功率、延迟、正确性）与对端行为联动，异常自动告警并回退到备选供应商或降级路径。核心原则：第三方输出是"不可信输入"，校验、监控、缓冲三件套缺一不可。

本题考察外部 Agent 依赖的稳健性。回答要覆盖输出 schema 校验、结构/行为漂移监控与版本锁定加适配层的防破坏机制。核心是"把第三方当作不可信服务，校验与缓冲是标准动作"。

• 注册表与客户端缓存：发现与本地缓存
• 健康检查：探测机制与状态分级
• 熔断策略：阈值、半开、降级

注册表与客户端缓存：Agent 注册表（服务发现）维护可用 Agent 列表（能力、地址、健康状态），客户端缓存注册信息减少对注册表的依赖（避免注册表本身成为单点），但缓存要带 TTL 与失效刷新（注册信息变更后客户端及时感知，防止"缓存里已下线的 Agent 还在被调用"）；缓存刷新用推送（注册表变更通知）+ 轮询兜底（定期全量拉取）。健康检查：注册表主动探测（心跳/HTTP 健康端点），状态分级（健康/亚健康/不可用），分级结果写入注册信息供客户端路由（只路由到健康实例）；探测要考虑对端负载（探测频率与对端限流平衡）。

熔断设计：客户端侧熔断——统计调用失败率/超时率，超过阈值（如连续失败 5 次或错误率 50%）打开熔断（直接拒绝调用快速失败），避免对端故障时大量请求堆积；半开状态——熔断后定时放少量探测流量，成功恢复则关闭熔断，失败继续熔断；降级——熔断后按业务降级（返回缓存结果、走备选 Agent、人工处理），不让故障向上传导；级联防护——限制对远程 Agent 的并发调用上限（信号量），防止对端变慢时客户端线程耗尽；超时优先于重试（对端不可用时重试会放大故障）。监控：熔断器状态、对端健康度、降级比例纳入告警。核心原则：远程 Agent 是"可故障的外部依赖"，缓存、探测、熔断、降级构成标准防护链，防止单点故障变成级联事故。

本题考察外部 Agent 的弹性设计。回答要覆盖注册缓存（TTL 与刷新）、健康检查分级与熔断（阈值、半开、降级）三层。核心是"远程依赖要按分布式系统标准做防护，故障隔离在源头"。

• 信任分级的依据：来源、审计状态、能力风险
• 未审计 Agent 的默认处置
• 必须审批开放的能力清单

信任分级：对发现的 Agent（如注册表中新出现的第三方 Agent）按"来源可信度 × 审计状态 × 能力风险"分级——来源可信度（官方发布、厂商认证、社区、未知来源）、审计状态（已安全审计/审计中/未审计）、能力风险（只读查询、可写操作、可执行外部动作）。分级结果决定可用范围：高信任（官方 + 已审计）可直接调用；中信任（审计中）仅限只读与测试环境使用；低信任（未审计/未知来源）默认拒绝调用或仅白名单场景试用。未审计 Agent 的默认处置是"不信任、不开放生产权限"，而不是"默认可用、出问题再封"。

必须人工审批后开放的能力：写操作类（写数据、改配置、发消息、付款、删除）；高影响读（读取敏感数据、批量导出）；执行类（运行脚本、调用外部系统、发布内容）；授权类（申请凭据、获取权限升级）；以及"未知能力的组合"（未审计 Agent 的任意能力首开都要审批）。审批流程：能力申请（Agent 的开发者提交能力声明与用途）→ 安全审查（代码/行为审计、权限最小化建议）→ 授权配置（授予最小权限 + 配额 + 审计）→ 试用观察（测试环境验证）→ 生产开放；审批记录与授权范围留痕，定期复审（能力变化重新审批）。核心原则：信任是"挣来的"不是"默认给的"，未审计即不信任，高风险能力门禁式审批。

本题考察 Agent 的信任治理。回答要给出分级依据与未审计默认拒绝的原则，以及必须审批的能力清单与审批流程。核心是"默认不信任、按级开放、高风险能力审批放行"。

• 跨组织 trace 的传递需求与泄露风险
• 传递内容的最小化：ID 与上下文，不传正文
• 关联查询与权限控制

跨组织排障需要"关联能力"而非"数据可见"：传递的内容应只包含关联 ID 与上下文元数据——taskId（任务 ID）、trace ID（调用链 ID）、parent ID（调用关系）、时间戳、调用方标识与分段结果摘要，不包含业务正文（用户消息内容、业务数据、内部 prompt）。传递方式：A2A 协议的标准头/字段传递（taskId、traceparent 等标准 trace 上下文），随请求与回调传递；双方各自的完整日志保存在自己边界内，用 ID 关联。这样排障时能对齐"同一任务的双方记录"（我方记录显示已发送、对端记录显示已接收，用 taskId 对上），但不暴露任何一方的业务内容。

实现要点：trace 上下文传递遵循标准（W3C traceparent 等），对端可解析即用；跨组织查询的权限控制——联合排障时按"最小授权"开放（排障期间临时授权、限定查询字段、审计查询行为），不能开放对方日志全量；分段结果摘要——传递"已完成/失败/进度"级的状态与摘要（不含详细内容），需要细节时走正式的工单/协作流程（带授权）；日志保留与合规——跨组织日志交互遵循数据协议（哪些字段可共享、保留多久）；安全上防止"trace 上下文被利用做探测"（ID 不携带敏感信息、加签名或随机性）。核心原则：跨组织传递"关联标识"而非"业务数据"，排障靠 ID 对齐，细节靠授权获取。

本题考察跨组织 trace 的安全传递。回答要讲清传递内容最小化（ID 与元数据、不传正文）、标准上下文传递与联合排障的权限控制。核心是"可关联、不可见——排障能力与数据保密不冲突"。

• 协议兼容设计：前向兼容与后向兼容
• 版本协商机制
• 新旧字段与状态的优雅处理

协议升级的兼容原则："加不加删，宽进严出"——新版本只允许新增字段/状态/消息，不允许删除或改语义（删除导致旧客户端解析崩溃，改语义导致旧客户端静默误解）；新字段带默认语义（旧客户端忽略时行为合理）；新增状态要定义旧客户端的处理（未知状态按"最接近的已知状态"映射或按失败处理，不能崩溃）。版本协商机制：双方在连接/请求时交换协议版本（握手），按"最低公共版本"通信（双方都支持的能力内交互）；调用带"能力声明"（我方支持的字段与状态集），对端按此适配返回；版本变化时通过注册表/Agent Card 更新通知。

新旧兼容的工程实践：解析层宽容——解析未知字段（保留并传递，不报错）、未知枚举值（映射到 unknown 并提示）、未知状态（映射到默认分支并记录）；行为层显式——遇到未知状态/字段时"显式降级"（记录日志、返回明确的 not supported 提示）而非"静默降级"（悄悄丢掉导致行为不一致）；客户端侧——响应校验区分"破坏性"与"扩展性"变化，破坏性变化触发告警与升级流程；灰度与观察——协议升级先灰度（新旧版本并存，观察旧客户端兼容情况），旧客户端升级完成后再移除兼容逻辑；兼容测试——用"旧客户端 vs 新服务端""新客户端 vs 旧服务端"两个方向做互操作测试。核心原则：未知内容"不崩溃、不静默、可协商"。

本题考察协议升级的兼容性。回答要给出"只加不删"原则、版本协商机制与未知字段/状态的显式处理。核心是"旧客户端遇到新内容要么优雅适配、要么明确报错，绝不崩溃或静默错乱"。

• 两种抽象的本质：状态图 vs 角色任务
• 表达力的差异：控制流 vs 协作语义
• 各自的擅长边界

两种抽象解决不同层次的问题：LangGraph 的 StateGraph 以"状态与转移"为核心——节点（处理单元）、边（顺序/条件路由）、共享状态（显式数据流），表达的是"控制流"：分支、循环、并行、恢复都显式建模，适合"流程结构复杂、需要精确控制执行路径与状态"的任务（多步工作流、需要 checkpoint 与重试的系统），表达力强在"执行语义"——每一步怎么走、状态怎么变、失败怎么处理，都是确定的。CrewAI 的角色 + 任务抽象以"分工与协作"为核心——Agent 定义角色（目标、背景、工具），任务定义"谁做什么"（分配、依赖、输出），表达的是"协作语义"：多角色如何分工、任务如何派发与汇总，适合"任务可角色化分解、强调人设与协作"的场景（内容团队、研究小组），表达力强在"组织语义"——角色间的职责与协作关系。

差异的本质：StateGraph 是"程序员的图"（精确控制流程），CrewAI 是"组织者的图"（描述分工协作）；StateGraph 能表达 CrewAI 的大部分行为（把角色建模为节点、协作建模为边），但要多写状态与路由代码；CrewAI 搭角色协作快，但精确控制执行路径（条件、循环、恢复）需要 Flows 或代码补充。选型：流程精确控制、恢复要求高→LangGraph；角色化协作、快速构建→CrewAI；复杂系统常组合（CrewAI 角色 + LangGraph 编排）。表达力结论：两者不是谁强谁弱，而是"控制流表达力"与"协作表达力"的侧重不同。

本题考察框架抽象层的差异。回答要讲清 StateGraph 的控制流表达力与 CrewAI 的协作表达力，以及"程序员的图 vs 组织者的图"的本质。核心是"按你要表达的是流程还是分工来选择抽象"。

• ConversableAgent：可对话 Agent 的组成（LLM、工具、记忆、行为）
• GroupChat：群聊协作的发言与终止机制
• Actor 模型的并发与消息语义

AutoGen 的 Actor 模型以"独立对话主体"为单元：ConversableAgent 是核心类——每个 Agent 封装自己的 LLM 配置、工具（tools）、记忆与行为策略，Agent 之间通过"消息"交互（而非共享状态），每个 Agent 对收到的消息自行决定如何回应（调用工具、继续对话、产出最终回答），形成"多主体对话"的执行模型；Agent 的回复可以是文本或工具调用结果（ToolCallMessage），消息带 sender/recipient 与类型，支持终止条件（termination condition，如关键词、函数判定）控制对话结束。GroupChat 是群聊协作——多个 ConversableAgent 加入 GroupChat，由 GroupChatManager 管理"下一轮谁发言"（speaker selection：round_robin 轮流、auto 让模型选择、manual 人工指定）与对话轮次、终止判定。

Actor 模型的特点与机制：并发——Agent 是独立执行单元，消息异步传递，可并行推进不同 Agent 的处理（在异步运行时中）；但也注意：GroupChat 本质是"串行的多轮对话"（一轮一人发言），真正的并行需要多个独立对话流或任务委派（UserProxyAgent 与 AssistantAgent 的分工是经典模式——前者执行工具，后者推理）；消息语义——消息即"对话"，适合需要多轮讨论的任务（辩论、评审、协作产出），不适合强流程控制（条件分支、并行汇合需要额外编排）；状态管理——会话状态在对话历史中演进，长对话需要清理/摘要，断点恢复依赖对话历史的持久化（AutoGen 支持消息历史保存与恢复）。选型要点：任务本质是"多角色对话协作"→AutoGen；任务是"多步骤流程"→状态图框架。

本题考察 AutoGen 的编程模型。回答要讲清 ConversableAgent 的组成、GroupChat 的发言选择与终止机制，以及 Actor 消息模型的并发与适用边界。核心是"AutoGen 适合对话式协作，不适合强控制流"。

• 类型驱动的含义：schema 即契约
• 类型系统的收益：校验、补全、重构
• 工程化的具体体现

类型驱动框架的核心是"用类型系统定义 Agent 的全部契约"：工具输入输出用类型定义（Python 的 Pydantic 模型、TS 的 zod schema）、Agent 的返回结果用类型定义（结构化输出）、依赖注入用类型（Pydantic AI 的 dependency injection 用类型声明依赖）、消息与状态也用类型约束。模型输出先按类型校验再进入业务逻辑（格式错误在边界拦截），工具参数按类型校验后执行——把"模型输出的不确定性"挡在类型墙外。收益：开发期——编辑器补全与类型检查（工具参数写错编译期报错，而不是运行期才炸）、重构安全（改字段类型全局校验）；运行期——输出校验自动化（schema 校验替代手写 if-else 检查）、错误信息精确（校验失败给出缺哪个字段）；维护期——契约即文档（类型定义就是接口文档，团队认知一致）。

工程化体现：结构化输出——声明返回模型（如 Result[T]），模型输出自动解析校验为类型化对象；工具注册——工具函数签名即契约，参数校验与错误处理模板化；依赖注入——测试时注入 mock 依赖（类型保证替换安全），生产注入真实服务；测试——基于类型生成测试数据（或校验测试数据合法性）；与 IDE/CI 集成——类型检查进 CI，错误在合并前暴露。代价与注意：类型定义要覆盖"模型输出的合法变体"（过严会频繁校验失败、过松失去保护），类型驱动不等于自动正确——校验逻辑与提示词仍需配合（模型输出要在类型约束内）。核心价值：类型把"运行时才知道的错误"提前到"开发时或边界处"。

本题考察类型驱动框架的工程价值。回答要讲清"类型即契约"的含义、开发/运行/维护三期的收益与工程实践（结构化输出、依赖注入、CI 检查）。核心是"用类型系统把模型输出的不确定性挡在边界外"。

• Java 生态 Agent 编排的整合点：安全、事务、连接池
• 与 Spring Security 整合：身份传递、授权校验
• 与事务和连接池整合：边界与资源管理

与 Spring Security 整合：Agent 调用链要继承请求的身份上下文——用户身份（SecurityContext）随 Agent 执行传递（工具调用、模型请求、子任务都携带当前用户），权限校验在"工具执行层"落地（每个工具按当前用户权限判定能否执行，而不是只校验一次入口）；Spring Security 的方法级注解（@PreAuthorize）可以应用于工具方法，模型只能"提议"工具调用，执行权在 Spring Security 保护的方法边界；身份传递到模型供应商时注意不泄露（模型请求只带业务上下文，不带安全令牌）。与事务整合：Agent 的"事务边界"要显式设计——每个工具调用是独立事务单元（工具方法 @Transactional 自管事务），Agent 层不跨工具维持长事务（模型调用期间持锁是反模式）；业务补偿仍按业务层设计（事务回滚只覆盖数据库动作，外部副作用靠补偿）；与 Spring 事务传播配合，避免"Agent 外层事务吞掉工具内部异常"导致的隐式回滚。与连接池整合：Agent 的并发工具调用会放大数据库连接压力（多子 Agent 并行调用），连接池参数（最大连接数、等待超时）要按 Agent 并发度调整；长任务不要长连接持有（每步短连接、及时释放）；异步 Agent 线程要传递事务上下文与连接池租用规则（避免线程间连接泄漏）。

工程要点：统一入口——Agent 执行上下文（用户、租户、trace ID）通过 ThreadLocal/上下文传递到工具层；资源治理——连接、线程、模型调用的配额在 Agent 会话维度管理；测试——工具层事务与安全的单测用 Spring 测试框架，Agent 层用注入 mock 工具。核心原则：Agent 是"新的编排层"，安全、事务与资源治理的权威仍在 Spring 生态，Agent 只能"适配"不能"绕过"。

本题考察 Java 生态 Agent 与既有设施整合。回答要覆盖身份传递与工具级鉴权、工具级事务边界与连接池并发适配。核心是"Agent 编排层适配 Spring 的安全、事务与资源治理，而不是绕过它们"。

• OTel GenAI 语义约定：gen_ai span 属性
• hooks/callbacks 到 span 的映射
• 埋点脱节的成因与对齐方法

OpenTelemetry GenAI 语义约定定义了 AI 调用的标准 span 与属性：gen_ai.operation.name（操作类型：generate/embeddings）、gen_ai.system（供应商）、gen_ai.request.model、gen_ai.usage.input_tokens/output_tokens、gen_ai.response.finish_reason 等；框架的 hooks/callbacks（如 LangChain 的 callbacks、LangGraph 的节点钩子、各 SDK 的事件）是埋点入口——把它们映射到 OTel 语义约定，才能生成"标准化的 GenAI span"：模型调用（LLM 调用）→ gen_ai span（带模型名、token 用量、供应商）；工具调用→普通 span + 工具属性（或按约定的 tool 语义）；Agent 节点/步骤→ span 带节点名与状态。映射不是"有日志就行"，而是"统一到同一套 span 结构与属性名"，这样下游（可观测平台、成本分析、评测）才能按标准消费。

埋点脱节的成因与对策：各框架埋点字段名不统一（token 用量有的叫 token_count、有的叫 usage）、层级不对齐（模型调用嵌在节点内还是平级）、属性类型不一致（数字 vs 字符串）；对策——写"适配层"：框架 hooks → 标准化转换（字段映射、单位统一、类型归一）→ OTel span 写入；在适配层维护一张映射表（框架事件 ↔ OTel 属性），框架升级只改映射表；建立验证——埋点正确性测试（调用一次真实任务，断言 span 结构与属性符合约定，token 数与模型账单对账）；监控"无埋点调用"（产生了模型调用但没生成 span 的缺口检测）。核心原则：hooks 是"事件源"，OTel 语义约定是"标准输出"，中间必须有对齐层，否则各框架埋点互相脱节。

本题考察埋点标准化。回答要讲清 GenAI 语义约定的 span/属性与 hooks 的映射方式、脱节成因（字段名、层级、类型）与适配层对策。核心是"统一到标准语义约定，适配层消化框架差异"。

• 两种并发模型：消息并发 vs 图执行并发
• 协作方式：对话驱动 vs 数据流驱动
• 取舍维度与典型选型

两种模型对"并发"的语义不同：AutoGen 的 Actor 模型并发是"消息并发"——Agent 是独立主体，通过异步消息交互，多 Agent 各自独立处理消息，适合"多角色并行对话/独立处理"（多个专家 Agent 各自评估、多个数据源 Agent 并行检索后汇总）；但其 GroupChat 协作默认是"一轮一发言人"的串行对话，真正并行要靠多个独立 Agent 任务（消息异步）。LangGraph 的并发是"图执行并发"——StateGraph 中显式定义并行分支（fan-out 多个节点同时执行），框架调度并发并同步汇合，并发是"结构化"的（每个分支是图中明确的节点）；LangGraph 适合"已知可并行的任务分解"（固定并行结构）。

取舍维度：协作模式——任务需要"对话式协商"（讨论、辩论、逐步达成一致）→ AutoGen；任务需要"数据流处理"（检索→处理→校验的管线、固定并行）→ LangGraph；并发结构——并发是动态的（根据内容决定派给谁）→ Actor 消息；并发是静态的（预先知道哪几步可并行）→ 状态图；状态与恢复——需要精确 checkpoint 与流程恢复 → LangGraph；需要松散自治主体 → AutoGen。实践上混合：LangGraph 编排主流程（并行分支、汇合、恢复），节点内用 AutoGen 式多角色对话完成复杂子任务。核心结论：按"对话协作 vs 流程数据流"与"动态 vs 结构化并发"取舍，两者互补而非互斥。

本题考察两种并发模型的取舍。回答要对比消息并发与图执行并发、对话驱动与数据流驱动，给出取舍维度与混合实践。核心是"对话式协作用 Actor，结构化流程用状态图"。

• 团队技能评估：语言、经验、学习成本
• 生态评估：文档、社区、集成
• 场景契合度：任务结构、约束匹配

团队技能评估：语言栈匹配（Python 团队优先 LangGraph/CrewAI/Pydantic AI，Java 团队优先 Spring AI/LangChain4j，.NET 团队优先 Semantic Kernel）——选团队能直接写生产的语言，避免"框架好但团队要重新学语言"；框架经验存量（团队已用过的框架复用成本最低）；学习曲线与内部知识沉淀（选框架后要能形成团队内部实践，冷门框架的踩坑成本高）。生态评估：文档质量与示例完整性（决定上手速度与排障效率）、社区活跃度（issue 响应、版本更新频率、第三方扩展）、与企业已有基础设施的集成（监控、部署、模型供应商 SDK 的兼容）。

场景契合度：任务结构（确定性流程→状态图框架、角色协作→CrewAI、类型安全→Pydantic AI、消息并发→AutoGen）；约束（延迟、成本、合规）；规模（原型到生产的扩展路径）。评估方法：给每个候选框架打分卡（团队、生态、场景三维 × 子项），加权汇总；再用"代表性任务原型"实测（真实业务样本跑通，对比开发效率与运行质量），避免纯文档对比；最后做"选型评审"记录决策理由与备选（便于后续评估变更）。核心原则：契合度 = 团队能维护 × 生态能支撑 × 场景能匹配，三者相乘而非相加（任一为零则整体为零）。

本题考察框架选型的综合评估方法。回答要给出团队、生态、场景三个维度的评估要点与打分卡加原型实测的流程。核心是"三维契合缺一不可，原型验证胜过文档对比"。

• 状态映射：共享 State 到角色/任务上下文
• 工具映射：节点内工具到 Agent 工具绑定
• 流程映射：图结构到任务依赖

状态对象映射：LangGraph 的共享 State（显式状态字典，所有节点读写）在 CrewAI 中没有"全局共享状态"的等价物——CrewAI 的信息流通过"任务上下文（context）"与 Agent 的返回结果传递：每个任务可声明依赖任务（context），把前置任务的输出作为上下文传入；映射策略——把 State 中的字段按"谁产生、谁消费"拆分：某任务产生且后续需要的字段，声明为任务输出并作为下游任务的 context；需要全局共享的字段（用户 ID、配置）放"全局上下文（crew 级输入）"或工具内部状态；映射时注意：CrewAI 默认每次任务执行是相对独立的（没有 LangGraph 的"同状态多步演进"），跨步骤状态要显式通过任务输出-依赖传递。

工具语义映射：LangGraph 中工具挂在节点上（节点内调用），CrewAI 中工具绑定在 Agent 上（Agent 的所有任务可调用其工具）；映射——把"只在某节点用的工具"绑定到执行该任务的 Agent（相当于节点级工具），跨步骤工具绑定到对应角色 Agent；工具描述与参数 schema 可直接复用（两者都支持 function calling 格式）；错误处理语义——LangGraph 的节点级重试/条件路由在 CrewAI 中要转为任务级重试与"任务依赖 + 条件输出"（CrewAI Flows 更适合表达条件分支）。流程映射：LangGraph 的图（分支、循环、并行）映射到 CrewAI 的"任务依赖 DAG + Agent 分配"，并行分支映射为无依赖的多任务并行执行（CrewAI 支持任务并行），条件分支映射为流程控制（Flows 的 condition 或外部编排）。核心原则：迁移的实质是"把状态流改成任务依赖流，把节点工具改成角色工具"，业务逻辑不变、结构表达方式变。

本题考察框架间迁移的映射方法。回答要给出状态（State→任务 context）、工具（节点→Agent 绑定）、流程（图→任务依赖）三类映射。核心是"业务逻辑等价迁移，表达结构按新框架语义重写"。

• 用评测指标比较框架：同一任务集跑不同框架
• 三类指标：成功率、Token 效率、可解释性
• 评测驱动的选型流程

用评测数据选框架的方法：准备"标准任务集"（覆盖业务的正常/边界/失败样本，标注答案或验收规则），把同一任务集分别跑在候选框架上（相同模型、相同工具、相同提示策略，控制变量），采集三类指标：成功率——任务级成功率（产出通过验收的比例）、单步正确率、恢复成功率（中断后恢复的正确性），用 Ragas 等框架级评估器辅助评分（忠实度、答案相关性等面向 RAG/QA，任务成功率用业务验收）；Token 效率——平均每任务 Token 消耗（输入+输出）、达成相同成功率下的成本（token 效率 = 成功率 / token 成本）、重试开销占比；可解释性——trace 完整度（每步可追溯到工具与上下文）、恢复与失败的可解释（失败原因可定位）、审计可还原度。Ragas 提供 RAG 类指标（忠实度、上下文相关性），LangSmith 提供 trace 与评估面板（在 LangSmith 里对同一任务集跑不同框架配置，对比面板指标）。

评测驱动选型流程：先做"可达性验证"（候选框架都能在任务集上达到成功率底线？达不到的出局）；再比"效率"（同成功率下 Token/成本最省）；再看"可解释性"（trace 与失败定位能力是否满足运维要求）；加权决策并记录数据依据。注意控制变量：框架比较要在"同模型同提示"下进行（否则比较的是提示不是框架）、样本量要够（小样本的成败差异可能是噪声）、评测集长期复用（选型后作为框架回归基线）。核心原则：框架选型用"业务任务集的实测指标"说话，而不是文档特性。

本题考察评测驱动的框架选型。回答要给出标准任务集与控制变量的方法、三类指标的采集与工具（Ragas、LangSmith）、分级筛选流程。核心是"用业务评测数据选框架，控制变量防误导"。

• 五个框架在四个维度的能力定位
• 选型矩阵的构建与读取
• 矩阵到决策的落地

选型矩阵按四个维度横向对比：State——LangGraph 1.0 状态管理最强（显式 StateGraph、checkpoint、时间旅行）；CrewAI 通过任务 context 传递、无全局共享状态；AutoGen 用对话历史承载状态、持久化需自行处理；Mastra 提供工作流状态（TS 生态）；Pydantic AI 状态轻量（用类型化模型管理，依赖注入）。Tool——LangGraph 工具注册灵活（节点内或 ToolNode）；CrewAI 工具绑定 Agent（角色化）；AutoGen 工具是 Agent 的一部分（execute_tool）；Mastra 工具注册在 Agent/工作流中（TS 原生）；Pydantic AI 工具用类型定义（函数签名即契约，校验最强）。HITL——LangGraph 原生支持（interrupt/resume、checkpoint 恢复）；CrewAI 通过人工输入任务与流程实现（HumanInputTool）；AutoGen 用 UserProxyAgent 模拟人工（对话式）；Mastra 支持工作流暂停等待（事件驱动）；Pydantic AI 通过工具返回/结果处理实现（较手工）。可观测性——LangGraph 与 LangSmith 深度集成（开箱 trace）；CrewAI 有自带追踪与 Langfuse 集成；AutoGen 有 OTel 支持（2.x 增强）；Mastra 提供内置观测（tracing/telemetry）；Pydantic AI 可接 OTel（日志简单、需自建）。

矩阵使用法：把"业务需求"投影到矩阵——要求强状态持久化与断点恢复 → 首选 LangGraph；要求快速角色化协作 → CrewAI；要求多角色对话 + 消息并发 → AutoGen；要求 TS 全栈 + 工作流 → Mastra；要求类型安全与结构化输出 → Pydantic AI；HITL 强需求与可观测性要求作为硬过滤（不达标出局）。矩阵要配合"权重"：按业务优先级给四个维度加权，矩阵评分 × 权重排序，再原型验证前两名。注意矩阵是"静态快照"，框架版本迭代快，决策要核对最新版能力；且矩阵维度要补充"团队语言"（TS 与 Python 的分野往往先于框架能力决定）。核心原则：矩阵提供"结构化的对比视角"，决策仍要结合业务权重与实测。

本题考察多框架选型矩阵的构建。回答要给出五个框架在四维度的能力定位与矩阵用法（需求投影、加权、原型验证）。核心是"矩阵结构化对比，业务权重与实测落地决策"。

• Planner 的规划能力与演进
• Connector 生态：记忆、向量、插件连接
• .NET 企业集成的场景价值

Semantic Kernel（SK）是微软的 Agent 框架，在 .NET 企业环境中的独特价值：Planner——SK 的规划器把任务拆解为可执行步骤（Function Calling 驱动的计划生成，支持 Handlebars/Stepwise 等规划策略），规划结果调用注册的插件函数（plugins）执行；Planner 的价值在于与 .NET 的"函数即能力"模型结合——企业现有的 .NET 方法可以声明为插件（KernelFunction 特性标注），Planner 自动编排这些既有代码，让 LLM 能力"长"在企业已有的业务函数之上，而不是另起炉灶；规划失败/复杂任务可降级为人工或固定流程。Connector 生态——SK 提供大量连接器：记忆连接器（内存/向量库/云存储）、模型连接器（OpenAI/Azure OpenAI/开源模型）、数据与插件连接器，以及企业集成组件（与 Azure 服务、Microsoft 365、企业认证的对接）；在企业场景，Connector 的价值是"开箱即用地接入企业已有基础设施"（Azure 认证、Entra ID、企业向量库），减少自研集成成本。

.NET 企业集成的独特场景：与现有 .NET 微服务/库无缝互操作（同一进程内调用业务函数）、依赖注入与配置体系（SK 融入 .NET DI 容器，与既有服务无缝组合）、企业级运维（与 .NET 的日志、监控、配置体系集成）、团队技能复用（.NET 工程师无需学习新语言）。注意点：Planner 的自主规划在企业场景要受控（规划结果过校验与审批，避免随意调用业务函数）、Connector 生态的质量参差（生产选型要验证连接器维护状态）。核心价值总结：SK 让"企业现有 .NET 代码"直接成为 Agent 的能力层，Planner 做编排、Connector 做接入，形成低迁移成本的企业 Agent 路径。

本题考察 Semantic Kernel 在企业集成的定位。回答要讲清 Planner（函数即能力、规划企业既有代码）与 Connector（记忆、模型、企业基础设施接入）的价值，以及 .NET 生态的整合优势。核心是"SK 的价值在把既有 .NET 资产转化为 Agent 能力，而非模型能力本身"。