# 1. 如何按状态持久化、类型系统、HITL、可观测性和团队语言选择 Agent 编排框架 A 选框架只要看社区热度最高的即可 B 按状态持久化、类型系统、HITL、可观测性与团队语言五维匹配业务需求，硬性需求过滤后再原型验证 ✓ 正确答案 C 所有 Agent 系统都必须用同一个框架 D 团队语言与框架选型无关
# 2. 怎样将框架状态对象与领域模型隔离，避免业务被某个编排运行时锁定 A 业务代码直接写进框架节点里效率最高 B 框架锁定无法避免，换框架只能重写业务 C 领域层可以直接 import 框架包，方便开发 D 用领域模型加适配层隔离框架状态与业务，依赖方向由框架指向领域，换框架只重写适配层 ✓ 正确答案
# 3. 框架升级改变序列化、Checkpoint 或工具语义时，如何做迁移和兼容回归 A 升级前评估序列化、checkpoint 与工具语义变更，做数据迁移与兼容层，用历史任务回放和灰度验证 ✓ 正确答案 B 框架升级改依赖版本即可，序列化不兼容就重建数据 C 旧 checkpoint 新版本读不了就直接丢弃，任务重跑 D 工具语义变更不影响业务代码
# 4. 如何统一采集跨节点、子图、子 Agent 和工具的 trace，并保持同一业务关联 ID A 每个子 Agent 生成独立的 trace ID 更方便定位 B 用全局业务关联 ID 配合 OTel 上下文传播贯穿任务、子图、子 Agent 与工具调用，形成统一可聚合的调用树 ✓ 正确答案 C 外部 HTTP 调用不需要携带 trace 上下文 D trace 只要覆盖主流程即可，子 Agent 不用管
# 5. 框架提供的重试与业务补偿为何不能混为一谈，事务边界应由谁控制 A 框架的重试机制已经包含业务补偿 B 框架应该自动决定何时做业务补偿 C 重试针对瞬时失败重复执行，补偿针对已生效副作用做反向业务操作，事务边界与补偿由业务方定义 ✓ 正确答案 D 重试与补偿都可以由框架默认配置完成
# 6. 框架升级（破坏性变更）应如何灰度与回滚，对正在执行的任务有何保护 A 框架升级可以直接全量发布，有问题再回滚 B 按流量与实例灰度验证，新旧版本并行且数据双向兼容，对存量任务做分类保护（跑完、迁移、重跑） ✓ 正确答案 C 新版本写入的状态旧版本无需兼容 D 升级时运行中的任务必须全部中断重跑
# 7. Agent 框架的“内置工具” vs “外部 MCP Server”应如何选型，何时框架自带工具反而是限制 A 工具只要框架内置就永远够用 B 内置工具功能更强，应该一律使用内置 C MCP Server 比内置工具延迟更低 D 内置工具简单低延迟但绑定框架，MCP Server 解耦可复用可独立治理，按复用半径与治理需求选型 ✓ 正确答案
# 8. 为什么不能把某一框架宣传为所有 Agent 场景的“最佳选择” A Agent 场景在任务结构、约束与团队上高度异质，框架各有取舍，选型必须场景化甚至组合化 ✓ 正确答案 B 社区评分最高的框架就是所有场景的最佳选择 C 所有框架的功能都相同，只是包装不同 D 选定一个框架后就应永久绑定，减少迁移成本
# 9. 从无框架原型迁移到编排框架前，应以哪些复杂度和可靠性信号作为依据 A 只要用了 Agent 就一定要上编排框架 B 原型代码可以无限增长，不需要框架 C 当手写流程控制重复膨胀、状态与重试散落、恢复与一致性出问题时，以维护成本超过迁移成本为信号渐进迁移 ✓ 正确答案 D 可靠性问题可以通过加更多 try-catch 解决
# 10. 为什么不能假设某框架的“最佳实践”文档适用于你的业务场景，需要做哪些适配 A 框架文档的最佳实践可以直接照搬到生产 B 最佳实践不适用于任何场景 C 最佳实践隐含框架作者场景的前提，需按业务在状态、持久化、权限、错误处理、安全等维度适配并回归验证 ✓ 正确答案 D 示例工具可以直接上线使用
# 11. Agent 框架的迁移（从一个框架到另一个）应如何规划，数据与执行轨迹如何可移植 A 换框架必须重写所有业务代码 B 旧 checkpoint 在新框架下必须逐字节兼容 C trace 数据换框架后无法保留 D 迁移按评估、适配、并行验证、灰度切换规划，状态与轨迹用框架无关格式持久化实现可移植 ✓ 正确答案
# 12. 框架的“低代码”特性（拖拽 Agent、可视化编排）在生产中是否仍然必要，工程师是否会因调试困难而放弃 A 低代码可视化编排是生产 Agent 系统的必选 B 低代码适合原型与业务人员，生产复杂系统以代码为准（可测试可版本化），可视化作为只读辅助视图 ✓ 正确答案 C 工程师不会因为调试困难放弃低代码 D 可视化画布与代码不一致没有影响
# 13. 多 Agent 框架混部时为何难以做统一成本归集，应如何基于 trace 建立跨框架费用桥 A 各框架自己统计的成本直接相加就是总成本 B 成本归集不需要统一 schema C 混部成本口径与埋点分散难以归集，应基于统一 trace 在 span 上标注费用并沿调用树聚合，按业务维度归集 ✓ 正确答案 D 跨框架成本无法追踪，只能估算
# 14. 编排框架的内置评估为何不应替代业务自定义指标，应保留哪些必要的接入点 A 业务指标与框架指标不需要关联 B 框架内置评估指标已经覆盖业务效果 C 内置评估只衡量框架层执行事实，业务指标需自定义，应保留回调、评估器、事件流与 trace 扩展接入点 ✓ 正确答案 D 有了内置评估就不需要业务验收
# 15. 框架 checkpoint 存储（Redis、PostgreSQL、S3） A checkpoint 全部存 Redis，读写最快 B Redis 适合高频小状态、PostgreSQL 适合结构化事务状态、S3 适合大体积快照，按频率体积一致性组合分层 ✓ 正确答案 C S3 适合高频小体积的 checkpoint 写入 D PostgreSQL 不能存储 checkpoint
# 16. Agent 框架 License（Apache 2.0、MIT、Elastic、商业） A Elastic License 是标准开源许可 B 只要框架是"开源"的就可以随意商用 C Apache/MIT 宽松可商用，ELv2 禁止对外托管服务，商业许可需付费，要按使用方式与依赖链评估 License 义务 ✓ 正确答案 D 依赖的 License 不影响整体合规
# 17. A2A 的 Agent Card 能力声明与技能清单应如何编写与验证，才能避免能力夸大导致调用失败，契约测试如何自动化 A Agent Card 声明应可验证且与实现一致，通过契约测试、能力抽测与版本化 CI 自动化验证 ✓ 正确答案 B 技能粒度越粗越好，覆盖更多场景 C Agent Card 描述能力范围即可，无需验证 D 改实现后不需要更新 Agent Card
# 18. 跨组织调用第三方 Agent 时，认证、计费与审计责任的边界应如何在 A2A 协议层与合同中同时约定 A 跨组织调用只要有 API 密钥认证就足够了 B 认证、计费与审计需在协议层实现传递与执行，同时在合同中约定责任边界、SLA 与对账流程，两层对齐 ✓ 正确答案 C 计费争议由调用方单方面决定 D 审计日志只需一方记录
# 19. A2A 与 ACP 等协议的互操作测试套件应如何构建（状态机一致性、事件顺序、错误码映射），以验证与不同厂商 Agent 的互通 A 互操作测试需覆盖状态机转移一致、事件顺序与幂等、错误码映射三层语义，构建分层用例库并接入 CI 持续回归 ✓ 正确答案 B 互操作测试只要验证消息能收发即可 C 错误码只需对端返回，无需映射 D 事件乱序不影响互操作
# 20. 调用长时运行的远程 Agent 时，调用方应如何设计超时预算、进度轮询与推送的取舍以及部分结果接受策略，避免被对端拖死 A 远程 Agent 调用不需要超时，等它完成即可 B 设计总预算与分段超时并有逃生通道，推送为主轮询兜底，可切割任务超时时接受部分结果降级 ✓ 正确答案 C 轮询频率固定不变最好 D 部分结果任何任务都可以接受
# 21. 引入外部 Agent 后，如何做输出 Schema 校验与漂移监控，防止对端版本升级悄悄破坏己方 SLA A 第三方 Agent 的输出可信，直接使用即可 B 对端新增可选字段属于破坏性变更 C 对第三方输出做 schema 校验、结构行为漂移监控，版本升级走兼容评估与适配层缓冲，防止悄悄破坏 SLA ✓ 正确答案 D 版本变化不需要重点验证
# 22. Agent 注册表的客户端缓存、健康检查与熔断策略应如何设计，防止远程 Agent 不可用引发级联故障 A 远程 Agent 不可用时重试几次就能恢复 B 熔断后就不需要降级策略 C 注册缓存带 TTL 刷新、健康检查分级路由、客户端熔断加半开与降级，防止远程 Agent 故障级联扩散 ✓ 正确答案 D 注册表是唯一事实源，客户端无需缓存
# 23. 发现但未审计的 Agent 应如何分级信任，哪些能力必须经人工审批后才允许开放 A 注册表中发现的 Agent 都可以直接在生产调用 B 只读查询能力也必须逐一审批 C 按来源、审计状态与能力风险分级信任，未审计默认不开放，写操作与高影响能力必须人工审批后放行 ✓ 正确答案 D 信任级别一经确定永久不变
# 24. A2A 边界之外的 taskId 与 trace 上下文应如何传递，既支持跨组织联合排障又不泄露业务正文 A 跨组织排障需要把双方全部日志互相对方可见 B 只传递 taskId 与 trace 上下文等关联标识，业务正文留存在各自边界内，联合排障按 ID 对齐并控制查询权限 ✓ 正确答案 C trace ID 可以携带业务敏感信息 D 跨组织排障不需要权限控制
# 25. Agent 间协议升级时，如何做版本兼容，避免旧客户端遇到新字段与新状态时崩溃或静默降级 A 协议升级时可以随意修改字段语义 B 未知枚举值可以随意映射 C 旧客户端遇到新字段应该直接崩溃，促使升级 D 协议升级只增不删并带默认语义，通过版本协商与宽容解析，未知内容显式处理避免崩溃与静默降级 ✓ 正确答案
# 26. LangGraph 的有向图（StateGraph）抽象与 CrewAI 的角色 + 任务抽象在表达力上有何差异 A 两种框架的抽象完全相同 B CrewAI 能精确控制循环与条件分支 C StateGraph 侧重控制流（状态、路由、恢复）的表达，CrewAI 侧重角色分工与协作的表达，按任务需要选择或组合 ✓ 正确答案 D LangGraph 无法表达角色化协作
# 27. AutoGen 的 Actor 模型（ConversableAgent、GroupChat） A GroupChat 中所有 Agent 同时发言，天然并行 B GroupChat 可以表达条件分支与并行汇合 C AutoGen 的 Agent 之间共享同一份状态 D ConversableAgent 是独立对话主体，GroupChat 由 Manager 管理发言选择与终止，消息驱动适合多角色对话协作 ✓ 正确答案
# 28. Pydantic AI、Mastra 等类型驱动框架如何用 Python/TS 类型系统提升 Agent 工程化 A 类型驱动框架只是多写一些类型注解，没有实际价值 B 类型定义越严格越好，模型输出通不过就重试 C 类型检查只能在运行时做 D 类型驱动框架用类型定义工具、输出与依赖契约，边界自动校验，换来开发期补全检查、运行期精确拦截与维护期文档化 ✓ 正确答案
# 29. Spring AI 2.0 / LangChain4j 在 Java 生态中编排 Agent 时，如何与现有 Spring Security、事务、连接池整合 A Agent 的工具调用不受 Spring Security 保护 B Agent 层应该跨工具持有长事务 C 模型请求可以携带安全令牌 D 用户身份随 Agent 调用链传递并在工具层鉴权，工具为独立事务单元，连接池按 Agent 并发度调整，适配而非绕过 Spring 设施 ✓ 正确答案
# 30. 框架的 hooks 与 callbacks 应如何映射到 OpenTelemetry GenAI 语义约定以避免埋点脱节 A hooks 事件经适配层映射为 OTel GenAI 语义约定的 span 与属性，统一字段与层级并做埋点验证 ✓ 正确答案 B 框架 hooks 自动就是 OTel 标准埋点 C token 用量的字段名不影响可观测性 D 埋点只需要记录模型名称
# 31. AutoGen 的 Actor 模型与 LangGraph 状态图在并发 Agent 协作上如何取舍 A AutoGen 与 LangGraph 的并发机制完全相同 B LangGraph 的并发是动态的，由模型决定 C AutoGen 是消息并发适合对话式协作，LangGraph 是图执行并发适合结构化并行，按协作模式与并发结构取舍或组合 ✓ 正确答案 D AutoGen 的 GroupChat 天然支持并行分支
# 32. Agent 框架选型时，应如何评估团队技能、框架生态与业务场景的契合度 A 框架选型只看框架功能清单 B 按团队语言与经验、生态文档与社区、业务任务结构与约束三维评估契合度，并用代表性原型实测验证 ✓ 正确答案 C 团队可以为了框架重新学习任何语言 D 冷门但先进的框架优先选
# 33. 从 LangGraph 迁移到 CrewAI 时，状态对象和工具语义如何映射 A CrewAI 也有全局共享 State，与 LangGraph 完全等价 B 工具 schema 迁移后必须完全重写 C 并行分支无法在 CrewAI 中表达 D LangGraph 的 State 映射为 CrewAI 的任务输出与依赖上下文，节点工具映射为 Agent 绑定工具，图流程映射为任务依赖 DAG ✓ 正确答案
# 34. 如何用 Ragas、LangSmith 评估指标对编排框架本身做选择（成功率、Token 效率、可解释性） A 框架选型用文档对比即可，评测太麻烦 B 比较框架时用不同提示词更公平 C Token 效率只统计输出 token D 用同一任务集控制变量跑各框架，比较成功率、Token 效率与可解释性，用评测数据驱动选型 ✓ 正确答案
# 35. LangGraph 1.0、CrewAI、AutoGen、Mastra、Pydantic AI 在 State、Tool、HITL、可观测性上应如何做选型矩阵 A 选型矩阵可以给出唯一正确答案 B 五个框架在 HITL 支持上完全相同 C 框架版本更新不影响矩阵结论 D 矩阵按 State、Tool、HITL、可观测性对比各框架定位，结合业务权重筛选并经原型验证后决策 ✓ 正确答案
# 36. Semantic Kernel 的 Planner 与 Connector 生态在 .NET 企业集成中的独特价值 A SK 与 .NET DI 体系互不兼容 B Semantic Kernel 只能在微软云上运行 C Planner 的规划结果可以直接执行企业函数，无需校验 D SK 的 Planner 编排声明为插件的既有 .NET 函数，Connector 生态对接企业基础设施，让企业代码低成本成为 Agent 能力 ✓ 正确答案
