Agent SDK 与框架前沿

• 三种抽象：handoff / subagent / graph 的语义
• 各 SDK 的抽象设计取向
• 选型依据：任务结构、生态、控制粒度

三种抽象的差异：Handoff（OpenAI Agents SDK 核心）——Agent 之间通过"移交"转交任务：当前 Agent 判断任务应由谁处理时，调用 handoff 把控制权（连同对话上下文）交给目标 Agent，类似"客服转接"，实现轻量、代码量小，适合"多专业 Agent 接力处理、边界清晰"的场景；Subagent（Claude Agent SDK 等）——主 Agent 派生子 Agent 执行独立子任务，子任务完成后结果回传主 Agent，类似"委派"，子 Agent 有独立上下文（隔离性好），适合"任务可拆解、子任务独立"的场景；Graph（LangGraph）——显式状态图定义节点、边与条件路由，执行路径完全确定，适合"流程结构固定、需要精确控制与持久化"的场景。

选型依据：控制粒度——需要精确控制每一步（分支、恢复、并行）→ graph；需要灵活委派但不想管图结构 → subagent；需要多专业角色接力对话 → handoff。状态与持久化——长任务、断点恢复 → LangGraph（checkpoint 原生）；轻量会话 → SDK 的内置会话管理。生态与语言——Python 团队三者皆可，OpenAI Agents SDK 轻量易上手、Claude Agent SDK 与 Claude 生态（Skills、MCP）整合深、LangGraph 功能全但学习曲线陡。实践结论：没有绝对优劣——同一系统可混合（graph 编排主流程，节点内用 handoff/subagent 完成灵活子任务）；选择看"任务的执行结构"（固定流程→graph、接力对话→handoff、独立子任务→subagent）与团队维护能力。

本题考察主流 SDK 的抽象差异。回答要讲清 handoff/subagent/graph 三种抽象的语义与适用场景，再从控制粒度、持久化、生态给选型依据。核心是"抽象决定执行结构，按任务结构选抽象"。

• Skill 的结构与元数据（名称、描述、参数）
• 版本管理：语义化版本、依赖、兼容
• 权限边界：能力范围、数据访问、执行许可

Skill 的封装结构：每个 Skill 是自包含的能力单元——元数据（名称、描述、适用场景）、输入参数定义、执行逻辑（prompt/代码/工具调用）、依赖声明与文档；元数据质量决定模型能否正确调用（描述要说明"什么场景用什么、参数怎么填"）。版本管理：语义化版本（major.minor.patch）——破坏性变更升 major（参数变化、行为变化）、新增兼容特性升 minor、修复升 patch；Skill 依赖其他 Skill/库时声明依赖与兼容范围（依赖升级不破坏本 Skill）；版本发布走 CI（描述与实现一致性校验、示例回归测试）；运行时按需加载指定版本（支持多个版本并存，灰度切换）；变更记录与废弃策略（deprecated 提示期后移除）。

权限边界设计：Skill 声明"能力范围"（能做什么、不能做什么），执行时按授权校验——每个 Skill 挂权限配置（可访问的数据域、可调用的工具、可执行的写操作），模型调用 Skill 前检查授权（Skill 无法越权调用未授权资源）；敏感 Skill（写操作、外发、付费）要求审批（与 HITL 集成）；数据边界——Skill 的输入输出经过脱敏与最小化（Skill 只拿到任务需要的字段）；审计——Skill 调用记录（谁、何时、参数、结果）留痕，用于安全审查与问题定位；沙箱——不可信 Skill（第三方）在受限环境执行（限制网络、文件系统、资源）。核心原则：Skill 是"可复用、可治理、可审计"的能力资产，版本与权限是其工程化的两条腿。

本题考察 Skill 的工程化治理。回答要覆盖封装结构、语义化版本管理（含依赖与 CI）与权限边界（能力声明、授权校验、审计沙箱）。核心是"Skill 既要好用（描述清晰、版本可控）又要安全（权限最小、全程审计）"。

• StateGraph 三要素：节点、边、条件路由
• 状态定义与 reducer 语义
• Checkpointing 与断点恢复

StateGraph 的建模：节点（Node）——工作流的处理单元（普通函数：解析、校验、工具调用、LLM 调用），接收状态输入、返回状态更新；边（Edge）——节点间的连接，分普通边（顺序执行：A→B）与条件边（Conditional Edge）：按"路由函数"（读状态字段或外部信号）动态决定下一节点（如"按校验结果走重试节点还是完成节点"），条件路由把"流程中的决策"显式化——决策由代码（路由函数）做而非模型随意做；状态（State）——TypedDict 或 Pydantic 定义的工作流数据（字段 + 类型），节点通过"reducer"定义字段如何更新（覆盖、追加、合并），Reducer 机制解决"多节点并行写同一字段"的合并语义。复杂工作流的建模套路：条件分支（条件边）、循环（条件边回到前序节点）、并行（多条边 fan-out + 汇合节点）、子图（把子流程封装为 SubGraph，主图引用）、HITL（interrupt 节点暂停等人工）。

Checkpointing 与断点恢复：LangGraph 在每次节点执行后自动保存完整状态（通过 Checkpointer：内存/Redis/Postgres/SQLite），形成状态历史；断点恢复——进程重启后从 Checkpointer 加载最近状态继续执行（同一 thread_id 的任务续跑）；中断（interrupt）——节点内调用 interrupt() 暂停执行并持久化，恢复时从暂停点继续（HITL 场景：等待审批后 resume）；恢复时的重放控制——已完成节点不重复执行，配合"状态版本"避免并发写冲突；LangGraph 还提供"时间旅行"（从历史 checkpoint 分支回放）用于调试。核心价值：状态显式化 + 持久化，让复杂流程可控制、可恢复、可调试。

本题考察 LangGraph 的核心机制。回答要讲清节点/边/条件路由/状态的建模方法（含 reducer 与子图）与 checkpoint 断点恢复（interrupt/resume、时间旅行）。核心是"把决策与流程显式化，把状态持久化"。

• Agent 角色三要素：role、goal、backstory
• 任务的分配与依赖（context）
• 顺序/并行执行与流程控制

CrewAI 的角色定义三要素：role（角色）——Agent 的身份定位（"资深数据分析师"），决定其立场与视角；goal（目标）——该 Agent 要达成的核心目标（"从数据中产出可执行的洞察"），模型据此聚焦行为；backstory（背景故事）——角色背景与专长描述（"十年零售行业数据分析经验"），增强角色一致性与输出风格；三要素共同构成本质上是"系统提示的角色化工程"——让每个 Agent 有清晰的职责与视角，协作时不串角色。工具的绑定（Agent 的工具集）与权限（角色能调用什么）也是角色定义的一部分。

Crew 的任务编排：任务（Task）定义"做什么"（描述、预期输出）与"分配给谁"（agent）；任务依赖（context）——任务声明依赖的前置任务，其输出作为上下文传入（信息流显式化）；执行模式：顺序执行（process=sequential）——任务按依赖顺序逐个执行；层级执行（hierarchical）——由 Manager Agent 动态规划任务分配（适用于任务分配不确定的场景）；并行——CrewAI 支持无依赖任务并行执行（async 任务并发，配合 Flows 更细粒度控制）；CrewAI Flows 提供事件驱动的流程控制（条件、循环、动态任务），弥补"任务级编排"在精确控制上的不足。工程要点：任务输出用 Pydantic/JSON 定义（结构化传给下游）、任务级错误处理与重试、人工输入任务（HumanInput）嵌入审批。核心价值：CrewAI 把"角色分工 + 任务流水"的协作模式模板化，适合团队化协作任务，精确流程控制交给 Flows 或与图框架组合。

本题考察 CrewAI 的协作模型。回答要讲清角色三要素的工程意义、任务依赖的上下文传递与顺序/并行/层级执行模式。核心是"CrewAI 把角色协作模板化，信息流靠任务依赖显式传递"。

• Handoff 的机制与设计模式
• 上下文传递与 Guardrails 集成
• 与 LangGraph subgraph 的对比

Handoff 机制：OpenAI Agents SDK 中，Agent 通过"handoff"把对话控制权移交给另一个 Agent——每个 Agent 声明可移交的目标（handoff 列表），当前 Agent 判断任务应转交时调用 handoff（如同客服转接：原 Agent 保留在对话历史中，控制权转给目标 Agent，目标 Agent 继承对话上下文继续处理）；设计模式：专业接力（不同领域 Agent 依次处理用户请求的不同部分）、升级转交（低权限/通用 Agent 把高风险或专业问题转交高级 Agent）、动态路由（主 Agent 根据意图把请求转给对应专业 Agent）；handoff 也是"终止对话"的一种方式（转到结束/人工）。上下文传递：对话历史随 handoff 完整传递（新 Agent 能看到之前全部对话），可显式携带"移交说明"（原 Agent 总结"用户要什么、已做了什么"），减少新 Agent 的重新理解成本。

Guardrails 集成：SDK 提供 Guardrail（输入/输出护栏）——Agent 或 Tool 调用前后执行校验（内容安全、格式校验、业务规则），不通过则中止或重试；Guardrails 可绑定到特定 Agent（每个 Agent 有自己的护栏）或全局（所有调用都过），与 handoff 结合：转交前校验当前输出、转交后校验目标 Agent 的输入，防止"转交点成为安全检查的盲区"。与 LangGraph subgraph 对比：语义上 Handoff 是"动态转交"（目标由模型在执行中决定），subgraph 是"静态嵌套"（子图是图中预定义的节点集合）；Handoff 灵活但执行路径难以预测（适合开放对话），subgraph 结构固定、可控可恢复（适合确定性流程）；状态——LangGraph 子图共享父图状态与 checkpoint（断点恢复强），Handoff 的状态是对话历史（恢复依赖会话持久化）；选型：对话式多角色 → Handoff，流程式多步骤 → subgraph，复杂系统两者可混用（graph 内节点用 handoff 完成灵活转交）。

本题考察 Handoff 机制与对比。回答要讲清 handoff 的转交语义与设计模式、上下文与 Guardrails 集成，再对比 subgraph（动态 vs 静态、对话 vs 流程）。核心是"handoff 是运行期动态转交，subgraph 是设计期静态嵌套"。

• Skills 的目录结构与格式（SKILL.md + 资源）
• 三类 Skill 的封装方法
• 团队最佳实践的沉淀路径

Claude Code Skills 的体系：项目级目录 .claude/skills//，每个 Skill 含 SKILL.md（YAML frontmatter 声明 name、description，正文写使用说明与步骤）+ 可选资源（参考文件、模板、脚本）；模型按 description 判断何时调用 Skill，调用时把 SKILL.md 与资源加载进上下文执行；Skills 是"把可复用的指令与知识打包为可调用单元"，团队最佳实践通过它固化到 AI 编程工作流。封装方法：spec-driven skill——把"需求规格驱动开发"的流程封装为 Skill（如何解析 PRD/规格、生成设计、落地代码、对照验收），团队新成员也能按 Skill 的标准流程产出；review skill——封装代码评审标准（架构、安全、性能、可读性检查清单与流程），让 AI 评审与团队评审口径一致；debug skill——封装问题定位方法（复现→二分→日志分析→根因→修复→回归），把资深工程师的排查思路沉淀为可执行步骤。

封装要点：description 写得可触发（说明"什么时候该用本 Skill"）；步骤要具体可执行（不是原则而是操作序列）；示例与模板随 Skill 携带（review 清单、spec 模板）；版本与演进——Skill 由团队维护，随最佳实践迭代（评审新问题后更新 Skill）；权限与安全——Skill 内容受控（避免注入恶意指令）、执行的操作有边界。价值：Skill 把"人脑中的经验"变成"仓库里的资产"，AI 编程的产出质量向团队标准收敛；多 Skill 组合（spec → review → debug）形成完整工作流。

本题考察 Claude Code Skills 的封装实践。回答要讲清 Skills 的目录结构与 SKILL.md 格式，并以 spec/review/debug 三类为例说明封装方法。核心是"Skill 是团队最佳实践的可执行化沉淀"。

• 两者的本质差异：知识/流程 vs 工具/数据
• 选型维度：静态知识 vs 动态执行
• 组合使用与边界案例

本质差异：Skill 是"知识与流程的封装"——告诉模型"遇到这类任务该怎么做"（标准步骤、评审清单、最佳实践、模板），内容主要是文本指令与静态知识，加载进上下文即可生效，不产生外部副作用；MCP Server 是"能力与数据的接入"——暴露可执行的工具（查数据库、调 API、操作文件、访问业务系统）与数据源，通过协议在运行时执行，产生真实副作用。判断标准：要解决的是"怎么做好"（方法论、标准、知识）→ Skill；要解决的是"能做什么"（访问什么数据、执行什么操作）→ MCP Server。

工程决策维度：内容形态——静态文本知识（评审标准、编码规范、流程说明）→ Skill；动态执行能力（每次调用都要连系统、查实时数据）→ MCP。更新频率——知识类内容低频更新（随实践演进）→ Skill 版本管理即可；工具能力随系统变化（API 变更）→ MCP 服务独立演进。副作用——纯指导无副作用 → Skill；有写操作/外部调用 → MCP（配合权限与审计）。边界案例：封装"调工具的最佳方式"（如"调某 API 前必须校验的参数"）属于 Skill（方法论），而"调某 API 的工具本身"属于 MCP；两者常组合——Skill 描述流程，流程中的具体动作由 MCP 工具执行。选型结论：先问"这是知识还是能力"——知识进 Skill，能力进 MCP，复杂场景两者协作。

本题考察 Skill 与 MCP 的边界决策。回答要讲清"知识流程 vs 工具数据"的本质差异与判断标准，再从内容形态、更新频率、副作用给选型维度。核心是"Skill 教方法，MCP 给能力，两者组合使用"。

• Skill 生命周期的工程化：版本、分发、API 化
• Marketplace 的生态与风险
• 企业落地的真实价值评估

Skill 生命周期的工程化：版本管理——Skill 按语义化版本演进（破坏性变更升 major），内容变更走 review 与测试（变更后验证在示例任务上的效果），团队仓库统一管理（Skill 进 git，随代码库评审与回滚）；共享分发——Skill 按"团队级共享"（公司内部仓库/注册表，统一口径）、"项目级"（随项目代码）、"个人级"分层分发，内部共享解决"同一最佳实践多处复制"的问题（评审标准、编码规范在多个项目复用同一份）；API 化——把 Skill 的"加载与调用"暴露为服务/接口（内部 Skill 服务按名称与版本提供），让不同工具（Claude Code、内部 Agent 平台）统一消费，避免各工具各存一份。Marketplace——官方与第三方 Skill 市场提供现成 Skill（降低起步成本），但企业落地要评估：来源可信（第三方 Skill 可能含恶意指令或低质内容）、维护可持续（社区 Skill 无人维护时是负债）、合规（内容许可与数据安全）；企业策略：Marketplace 作为"灵感与起点"，生产 Skill 自建并内部治理（受控的分发与审计）。

真实工程价值：把"隐性经验"变成"显性资产"（评审、调试、规范类 Skill 让 AI 产出向团队标准收敛，新人借助 Skill 复制资深流程）；减少重复（同类实践一处维护多处复用）；可治理（Skill 有版本、有 owner、有审计，比"散落的提示词"可管）；风险：Skill 过度依赖（流程教条化）、内容腐化（实践变了 Skill 没更新）——需要持续维护机制（owner 定期 review、效果监控）。结论：价值真实但前提是治理到位，Marketplace 宜作参考不宜作生产依赖。

本题考察 Skill 生态的企业落地。回答要覆盖版本/分发/API 化的工程化路径与 Marketplace 的风险评估，再给真实价值与治理前提。核心是"Skill 的资产价值靠治理兑现，Marketplace 只作参考"。

• 三种载体的定位：编辑器级 / 仓库级 / 技能级
• 各载体的内容边界与适用场景
• 跨工具同步与维护策略

三种载体的定位差异：.cursorrules——Cursror（编辑器）的提示规则文件，控制编辑器内 AI 助手的全局行为（编码风格、回复偏好、项目约束），是"编辑器级"配置，Curor 专属格式，其他工具不识别；AGENTS.md——仓库根目录的规范文件（Claude Code、Cursor 等多家工具支持），描述项目的技术栈、架构约定、构建测试命令、代码规范，是"仓库级"规范，正成为跨工具的事实标准；.claude/skills/——Claude Code 的 Skill 目录，封装"可执行的最佳实践流程"（如何做评审、如何调试），是"技能级"资产，粒度比规范细、可被模型按需调用。取舍原则：仓库级约定（架构、命令、规范）→ AGENTS.md（跨工具通用）；编辑器行为偏好（工具特有）→ .cursorrules（或对应工具的配置）；可复用的流程方法 → Skills（.claude/skills/ 或跨工具 Skill 格式）。

跨工具同步策略：以 AGENTS.md 为"单一事实源"（仓库规范只维护一份），各工具的专属文件生成或引用它——避免"规范多处复制、改一处忘一处"；同步方式：维护一个"规范源"仓库（AGENTS.md + 公共规范 + Skills），通过脚本/CI 生成各工具所需的派生文件（.cursorrules 引用或复制 AGENTS.md 内容、Skills 从源仓库同步）；内容分层——跨工具通用内容（仓库规范）放 AGENTS.md，工具特有内容（编辑器偏好）留在专属文件；变更流程——规范变更走统一 review（改源文件 + 同步派生文件 + 验证工具加载效果）。实践结论：AGENTS.md 为主、专属文件为辅，Skill 作为流程资产单列，同步靠"源文件 + 生成"避免分叉。

本题考察 AI 编程规范载体的管理。回答要讲清三种载体的定位差异（编辑器级/仓库级/技能级）与以 AGENTS.md 为单一事实源的同步策略。核心是"规范只维护一份，派生文件生成而非复制"。

• Hooks 的事件模型：PreToolUse/PostToolUse/Stop 等
• 质量闸门：lint、格式化、安全扫描的自动执行
• 工程价值与治理意义

Claude Code Hooks 的事件模型：在 Agent 操作的关键点触发外部命令——PreToolUse（工具调用前触发，可校验/拦截/修改参数）、PostToolUse（工具执行后触发，可检查结果/记录）、Stop（Agent 完成一轮响应后触发）、Notification 等；Hook 是"外部脚本/命令"，Claude Code 把执行权交给工程化工具，使 AI 编程行为可被质量体系约束。工程价值：把"人靠自觉"变成"系统强制"——AI 写代码的质量控制从提示词建议升级为可执行闸门。自动质量闸门的落地：PreToolUse 闸门——在写文件/编辑前拦截：检查文件路径白名单（防止改到不该改的文件）、参数校验、对敏感操作（删除、执行命令）追加确认或拒绝；PostToolUse 闸门——文件写入后自动执行格式检查（prettier/eslint --fix、格式校验），失败则通知模型修复或回滚；Stop 闸门——每轮完成后跑一次完整检查链：lint + 格式化 + 单元测试 + security scan（依赖漏洞扫描、密钥检测、危险函数检查），不通过则把结果回传给模型继续修复，形成"写码-检查-修复"闭环。

落地要点：Hook 命令要快（质量检查进关键路径不能拖慢太多，重检查放 Stop 异步）、失败处理分级（格式问题自动修，安全扫描高危直接阻断，测试失败回传修复）；Hook 与 CI 的关系——Hook 是"开发期即时闸门"，CI 是"合入期最终闸门"，两者用同一套检查脚本（脚本复用，避免双轨不一致）；审计——Hook 执行记录（触发了什么检查、结果如何）留痕。核心价值：Hooks 把"AI 编程的质量、安全、合规要求"从口头约定变成自动化执行的工程约束。

本题考察 Hooks 系统的工程应用。回答要讲清事件模型（Pre/Post/Stop）与三类质量闸门的落地方式，以及 Hook 与 CI 的一致性。核心是"用自动化闸门把 AI 编程纳入质量与安全体系"。

• 研究任务的规划-执行-验证循环设计
• 长任务的断点续跑工程化
• 研究质量的验证与迭代

Deep Research 类任务的循环设计：规划——先生成研究计划（研究问题分解、检索策略、预期证据来源、产出结构），计划随研究推进修订；执行——按计划多路检索（搜索、文档读取、数据查询），把证据收集到"证据池"（带来源与引用）；验证——中间验证（收集的证据是否支撑结论、是否存在关键缺口）与最终验证（结论与证据链的一致性、来源可靠性、覆盖度）；循环——验证发现缺口则回到"补充检索/调整计划"，形成"规划-执行-验证-再规划"的迭代，而不是一次检索一把梭。工程化要点：证据管理——每条证据记录来源 URL、时间、可信度（权威性评分），结论必须可回溯到证据（防止编造来源）；中间检查点——每完成一个子问题即验证（证据不足及时补，避免最后发现整个方向错了）。

断点续跑工程化：长程研究（小时级）必须支持中断恢复——把"研究计划 + 证据池 + 已完成子任务 + 上下文摘要"持久化为检查点（结构化存储），恢复时加载检查点继续（已完成子问题不重跑）；上下文管理——研究过程会积累大量检索内容，用"证据池（结构化）+ 阶段性摘要"控制上下文（长对话摘要压缩，关键证据全文保留引用）；进度可见——研究状态（已完成子问题、当前阶段、剩余计划）实时反馈给用户；成本控制——检索与模型调用的预算按研究计划分配，超预算降级（减少补充轮次或转人工）。验收——最终报告与证据链可审计（每段结论附来源）。核心原则：长程研究按"证据驱动 + 检查点驱动"工程化，规划可演进、进度可恢复、结论可溯源。

本题考察长程研究 Agent 的工程化。回答要讲清规划-执行-验证循环（证据池与中间验证）与断点续跑（检查点、上下文管理、进度反馈）。核心是"研究任务要按证据与检查点驱动，防止方向漂移与中断丢失"。

• Group Chat 与发言者选择策略
• 消息过滤与上下文管理
• 终止条件设计

AutoGen Group Chat 模式：多个 ConversableAgent 加入一个群聊，GroupChatManager 调度"下一轮由谁发言"——发言者选择策略三种：round_robin（轮流发言）——确定性强、成本可控，适合"人人有份"的评审/头脑风暴（每轮各 Agent 依次发表）；auto（由模型选择）——Manager 分析对话内容决定下一位发言者（最相关的 Agent 接话），灵活但不可预测、可能偏向特定 Agent，需要引导词（"谁最适合回答就选择谁"）；manual（人工指定）——由人指定下一位，用于演示与可控场景。选择策略要与任务匹配：流程式评审用 round_robin、开放讨论用 auto、教学演示用 manual；混合——先 auto 再按需 manual 介入。

消息过滤与上下文管理：群聊所有消息进入共享对话历史，要过滤——内容过滤（低价值发言如纯附和、重复内容，减少注入）、敏感过滤（不在群内扩散的信息）、上下文截断（历史超限时摘要化，保留关键结论与分歧）；消息带 sender/recipient 明确受众（指定某 Agent 回复的消息只有它响应，减少无关 Agent 抢话）。终止条件设计：三种终止——关键词/条件终止（Manager 或任一 Agent 输出终止信号，如"TERMINATE"）、函数判定（自定义函数检查对话是否达成目标，如结论一致或轮次达标）、轮次上限（最大发言轮数兜底，防死循环）；终止要"有产出"——不能"聊到自然散场"，终止前确认最终结论/决议被产出（Manager 汇总最终结果）。核心原则：群聊是"受控的对话"——发言有序、消息有界、终止有据，防止空转与失控。

本题考察 AutoGen 群聊的调度设计。回答要讲清三种发言者选择策略的适用场景、消息过滤与上下文管理、以及多形态终止条件。核心是"群聊要发言有序、消息有界、终止有据"。

• Pydantic 模型作为工具与输出的契约
• 依赖注入的机制与用途
• 结构化输出的校验与失败处理

Pydantic AI 的类型安全开发：用 Pydantic 模型定义 Agent 的全部数据契约——工具输入（工具函数的参数模型）、工具输出（返回结构）、Agent 的结构化输出（OutputType）；模型即 schema：定义即校验（运行时自动验证）、即文档（接口清晰）、即补全（IDE 类型提示）。工具定义——工具函数签名使用类型标注（参数用 Pydantic 模型或基本类型），Pydantic AI 自动把模型输出的工具调用参数按模型校验后传入函数（参数缺字段/类型错在边界拦截），工具返回结果也按模型校验；输出验证——Agent 的 result_type 声明结构化输出，模型输出经 Pydantic 校验后返回类型化对象，校验失败（字段缺失、类型错误、枚举非法）时框架自动把错误回传给模型修正（重试机制），保证"给业务层的一定是合法结构"。

依赖注入（Dependency Injection）：Agent 的工具/执行函数通过参数声明依赖（如 db_session、user_context、service 对象），Pydantic AI 在执行时注入——生产注入真实依赖，测试注入 mock（类型保证替换安全）；依赖与模型输出解耦（工具逻辑不依赖 LLM 输出直接访问依赖），让工具可独立单测；依赖还承载"执行上下文"（当前用户、租户、配置）在工具间传递。工程收益：类型系统把"运行时才发现的问题"提前到边界（模型输出不合法在入口即知）、工具与业务逻辑可测、重构安全（改模型字段全局生效）；注意点——类型定义要与提示词配合（过严的 schema 频繁校验失败要调描述或重试次数）、结构化输出成本（复杂 schema 增加输出 token）。核心价值：Pydantic AI 把"模型输出 → 类型安全对象"的转换做成框架能力，Agent 代码获得与普通工程相同的类型保障。

本题考察类型安全 Agent 开发。回答要讲清 Pydantic 模型作为工具与输出契约、校验失败的回传重试与依赖注入机制。核心是"用类型系统把模型输出的不确定性挡在业务边界外"。

• 自研 vs 复用的决策维度
• 社区 Skill 的评估标准
• 维护负担的控制

自研 vs 复用的决策维度：定制深度——团队实践高度定制（独特规范、内部系统、专有流程）→ 自研（社区 Skill 无法覆盖）；通用性——任务是行业通用实践（git 提交规范、通用代码评审、常规调试）→ 优先复用社区成熟 Skill（省开发成本）；差异成本——社区 Skill 需要改 30% 以上才可用 → 自研（改到"四不像"不如从零写）；依赖风险——社区 Skill 的维护状态（活跃度、issue 响应）不可靠且关键依赖 → 自研。复用社区 Skill 的评估：来源可信（官方/知名作者）、质量（文档完整、示例可用、测试覆盖）、许可（能否在团队内使用与修改）、维护（最近更新时间、issue 处理）、依赖面（Skill 依赖的其他资源是否可控）。

避免维护负担的策略：Skill 数量最小化（能合并的合并，每个 Skill 有明确的 owner 与使用频率，无人使用的 Skill 下线）；变更走治理流程（修改需 review、变更记录，防止"谁都能改、改完没人管"）；对外部 Skill 做"fork 内化"（复用后 fork 到内部仓库统一管理，避免外部变更不可控）或"薄封装"（保留核心逻辑，本地维护一层配置）；监控效果（Skill 的使用频率、成功率、是否引发问题），无效 Skill 及时移除；"少而精"——一个维护良好的 Skill 胜过十个疏于维护的 Skill。核心原则：Skill 是负债也是资产——复用省成本但承接维护责任，自研要克制（只做差异化部分）。

本题考察 Skill 的获取与维护决策。回答要给出自研/复用的决策维度与社区 Skill 的评估标准，以及控制维护负担的策略。核心是"Skill 要少而精、有 owner、有生命周期，避免成为无人维护的负债"。

• 两种架构的执行模式差异
• 成本、延迟、可观测性的对比
• 选型判据与组合策略

两种架构的执行模式：subagent 编排——主 Agent 派生子 Agent 独立执行子任务（子 Agent 有独立上下文、可并行、可复用），成本结构是"多份上下文 + 编排消息"；Skill 单 Agent——所有步骤由同一 Agent 按 Skill 指引执行，成本结构是"单份上下文 + Skill 内容注入"。成本对比：subagent 通常更高——每个子 Agent 重复携带系统提示与工具定义（上下文重复计费）、子任务结果回传与汇总有额外 token、编排本身有开销；Skill 单 Agent 复用同一上下文（Skill 内容一次加载），Token 更省；但当子任务需要"独立上下文隔离"时（各自处理大文档、互不干扰），subagent 反而省（不把大内容重复塞进主上下文）。延迟对比：subagent 可并行（多个子任务同时执行，总延迟=最慢子任务），单 Agent 串行（总延迟=步骤之和）；子任务可并行是 subagent 的核心延迟优势；但调度与汇总增加少量固定开销。

可观测性对比：subagent 边界清晰——每个子 Agent 的调用、Token、结果可独立统计与归因（成本按子任务分账、错误定位到子 Agent），trace 层级分明（主-子关系）；Skill 单 Agent 的观测是"同一 Agent 内部的步骤"——细粒度统计需要按 Skill 步骤埋点，成本归集到"单 Agent + Skill 类型"。选型判据：任务可拆分为"上下文需要隔离的独立子任务"且可并行 → subagent（换延迟优势，接受成本）；任务线性、上下文共享、步骤为"方法论指引" → Skill 单 Agent（省成本，简单）；混合——主 Agent 用 Skill 管理流程，个别重子任务派发 subagent 并行。核心结论：subagent 用成本换隔离与并行，Skill 单 Agent 用简单换成本优势，按"子任务独立性"取舍。

本题考察两种架构的工程权衡。回答要对比成本（上下文重复 vs 隔离省 token）、延迟（并行 vs 串行）、可观测性（边界清晰 vs 单层步骤）三个维度并给选型判据。核心是"以子任务的独立性与并行性为决策轴"。

• PRD/SDD 工作流的痛点与 Skill 的契合点
• spec → Skill → Agent 调用的链路
• 可复现执行的保障

PRD/SDD（产品需求文档/系统设计文档）工作流的痛点：需求到实现的转化依赖个人经验（每个人理解 PRD 的方式不同）、产出质量不稳定、过程不可复现。Skill 的契合点：把"从规格到实现"的完整方法（如何拆解 PRD、如何做设计决策、如何产出与验收）封装为 Skill，让 AI 按团队统一方法论执行，而不是自由发挥——这正是 Skill 的"知识封装"本质与文档驱动工作流的天然匹配。链路：spec（PRD/SDD 作为输入，结构化的需求/设计内容）→ Skill（加载团队封装的方法论：解析规格的步骤、设计要求、验收标准、模板）→ Agent 调用（Agent 按 Skill 指引处理规格：提炼需求→设计→实现→自检，每步产出的结构受 Skill 模板约束）→ 可复现执行（同一规格 + 同一 Skill 在任意环境重跑，产出结构一致、质量口径一致）。

可复现执行的保障：Skill 内容版本化（方法论演进可追溯，复现时用指定版本）；输入规格结构化（明确字段与格式，Agent 解析无歧义）；输出模板化（Skill 定义产出结构，验收可对比）；执行记录（Agent 处理过程的 trace 与产物保存，复现对比差异）；CI 化——把"规格 + Skill + 预期输出样例"做成回归用例（规格变更或 Skill 更新后自动验证链路仍产出合格结果）。价值：PRD/SDD 工作流从"人带 AI 自由发挥"变成"AI 按规格与方法论可复现执行"，质量与效率向团队标准收敛，新成员与老成员用同一套标准。核心结论：Skill 让文档驱动的工作流"方法论显式化、执行可复现化"。

本题考察 Skill 与文档驱动工作流的结合。回答要讲清链路（spec → Skill → Agent → 可复现）与可复现的保障（版本、模板、回归用例）。核心是"Skill 把个人经验变成团队可复现的执行标准"。

• 五个评估维度的定义
• 主流框架的定位对比
• 评估流程与权重

五个维度的定义：编排灵活性——框架表达复杂流程的能力（分支、循环、并行、子图、HITL、动态规划），决定能否适配你的任务结构；可观测性——trace、指标、评估的开箱支持（是否原生集成观测平台、span 是否结构化），决定生产排障与成本归集能力；多模型支持——框架对接模型供应商的广度与切换成本（OpenAI/Anthropic/开源/自托管），决定模型选型的自由与厂商锁定风险；社区生态——文档质量、社区活跃度、第三方扩展与集成、版本迭代节奏，决定学习与排障成本；生产就绪度——持久化与断点恢复、安全与权限机制、企业特性（治理、合规支持）、部署形态（是否支持分布式/云原生），决定能否直接上生产。

主流框架的典型定位（对比示例）：LangGraph——编排灵活性与生产就绪度强（状态图、checkpoint、LangSmith 可观测）；CrewAI——协作编排易上手、生态活跃，但深度的流程控制与恢复需要 Flows/外部补充；AutoGen——多 Agent 对话与多模型支持好，生产就绪度随 2.x 演进增强；Pydantic AI——类型安全与可观测（OpenTelemetry）优秀，编排偏轻量；Mastra——TS 全栈、内置观测，生态较新；Semantic Kernel——.NET 企业集成（连接器、DI）最强，灵活性中等。评估流程：先按"业务硬约束"过滤（语言、持久化、HITL 必须支持），再用五维度打分（各维度按业务权重加权：长任务重生产就绪度与可观测性、探索型项目重灵活性与生态、企业合规重生产就绪度），最后原型实测验证（同一任务集跑候选框架，比成功率、延迟、成本）。核心原则：五维度提供对比框架，权重由业务定，实测验证收尾——没有全维度第一的框架，只有匹配业务的组合。

本题考察框架评估的完整方法论。回答要定义五维度、给出主流框架的定位对比与"硬过滤 + 加权 + 实测"的流程。核心是"维度给视角、业务给权重、实测给结论"。