工作台 vs 驾驶舱：2026 年 agent runtime 选型笔记

Claude Agent SDK 默认给你工作台，OpenAI Agents SDK 默认给你驾驶舱。

模型决定智力上限，runtime 决定行动边界。

工作台和驾驶舱不分高下，是任务形态决定的。

凡是同时听说过 Claude Agent SDK 和 OpenAI Agents SDK 的人，多半都有一种模糊印象：Claude Agent SDK 好像更强一点。但要追问一句”强在哪”，多数人答不上来。是因为 Claude Code 先发优势？是因为它代码能力更好？

这种模糊是有原因的。两家都托管 agent loop，都自动处理模型调用、工具调用、handoff，开发者都不需要手写底层循环。在”会不会跑 agent”这一层，它们没有差别。

真正的差别在 loop 外面那一层：runtime 默认替你搭好了什么样的 harness。Claude Agent SDK 默认给的是一个完整的自主工作台，含文件、命令、搜索、权限、session、自动压缩；OpenAI Agents SDK 默认给的是一个一体化控制面板，trace、guardrail、human review、evals、sandbox 全部接进 OpenAI 平台。

所以 Claude 不是”更强”，是它和 OpenAI 默认给你的根本是两种东西：一个工作台，一个驾驶舱。这篇文章想把这个讲清楚。

1. Agent loop 的两种层级

讨论框架之前先确立一个分类，因为后面所有比较都建立在它之上。

完整工作台 loop：模型不仅会调函数，还能在工作区里读文件、改文件、跑命令、搜索、压缩上下文、恢复 session、请求审批。Claude Agent SDK、OpenCode、DeepSeek-TUI 属于这一类。强项是”给一个目标，让 agent 自己推进”。

应用级 Runner loop：SDK 自动处理多轮工具调用和 handoff，但工具语义、业务状态、审批流、持久化、UI 主要由开发者设计。OpenAI Agents SDK、Pydantic AI、Google ADK 属于这一类。强项是”嵌进产品后端，控制流程和质量”。

智能性主要来自模型，runtime 的价值主要落在这两类 loop 的 harness 设计上。

至于多 agent 团队，几个 agent 围一桌开会到收敛这种模式，在 2026 年生产里已经基本退潮。活下来的多 agent 形态都是上面两类 loop 之上的拼装模式（orchestrator + 并行 subagent）或外部流程引擎（durable workflow），不构成独立的第三类 loop。这部分放到第 6 节专门讲。

2. 一个成熟 agent runtime 应该包含什么

判断 runtime 成熟度的八层清单：

Agent loop：模型规划、调工具、读结果、继续推理、停止或恢复。成熟框架不再让开发者手写 while-loop。
Tool use + harness：函数工具、文件/命令/浏览器/搜索/API 工具、MCP 工具、结构化 schema、并行调用、失败重试。关键不是把工具暴露给模型，而是 runtime 可靠执行工具。
上下文管理：会话状态、短期历史、长上下文压缩、自动 compact、长期记忆、artifact、token/cost 预算。决定长任务是否稳定。
权限与安全：allow/ask/deny、人审、guardrails、sandbox、rollback、危险动作拦截。越能行动的 agent，越需要这层。
编排：subagent、handoff、agent-as-tool、team、graph、parallel jobs。原则是先做好单 agent + 好工具，多 agent 是增量，不是默认解。
Observability + eval：trace 必须覆盖模型调用、工具调用、handoff、guardrail、成本和延迟；eval 既评最终答案，也评 trajectory。
Runtime 与部署：SDK、CLI/TUI、API server、streaming、结构化输出、durable execution、resume/cancel、云端或自托管。
可配置能力：hooks/callbacks、plugins、skills、AGENTS.md/CLAUDE.md/rules、项目记忆。好的 runtime 把工程经验沉淀成可复用配置。

和 LangChain/LlamaIndex 那个时代相比，主矛盾换了。过去是把 prompt、RAG、tool schema 胶水接起来；现在是把 agent loop、工具执行、上下文压缩、权限、人审、trace/eval、部署托管交给 runtime。开发者从”接模型”转向”设计行动边界和反馈闭环”。

3. Claude Agent SDK vs OpenAI Agents SDK：默认值的差别

这两家最容易混淆，单独讲。

Claude Agent SDK 不是只能做 coding agent 的框架。更准确的说法是：它是从 Claude Code 演化出来的通用自主工作台 runtime。因为默认内置 Read/Edit/Write/Bash/Grep/Glob/WebSearch/WebFetch/AskUserQuestion/Agent/Skill 等工具，它天然适合代码库、文档库、数据文件、终端任务。但研究 agent、邮件 agent、内部运营 agent 一样能做，只要任务形态是”agent 在一个工作区里持续行动”。

OpenAI Agents SDK 默认不是工作台，是驾驶舱。它自带一组 hosted tools：WebSearchTool、FileSearchTool、CodeInterpreterTool、ImageGenerationTool、HostedMCPTool、ToolSearchTool，分别解决网页搜索、向量库检索、Python 沙箱执行、文生图、远端 MCP 接入、工具懒加载。但 hosted 不是免费午餐：FileSearch 必须先把文件上传到 OpenAI Vector Stores，CodeInterpreter 数据进 OpenAI 沙箱，WebSearch/ImageGen 也走 OpenAI 后端。需要数据驻留、企业内合规或私有部署时，hosted tools 这一层基本用不了，要换成自己的 RAG/搜索/沙箱实现。

它真正的特点是另一种取舍：trace、guardrails、human review、evals、sandbox 直接跟 OpenAI 平台闭环走，开箱即用。代价是这套驾驶舱默认绑在 OpenAI 平台上。要换 trace 后端、自托管或换 LLM 提供商，要么自己拆，要么放弃 hosted 那一截。

具体场景判断：

让 agent 自己探索 repo、读文件、改代码、跑测试、危险动作再问人：Claude Agent SDK 的 loop 更强，因为 action harness 已经内置。
做客服、风控、投研、内部审批、数据处理这类产品功能：Claude 也有优势。开发快、行动强、工作台完整，trajectory/log、hooks、OpenTelemetry、成本统计也够做严肃迭代。如果产品本质上是”agent 在一批材料/工具/工作区里自主推进任务”，Claude 更省事。OpenAI Agents SDK 走另一条路：trace/eval/guardrail/human review 默认接入 OpenAI 自家控制面，开箱就有 dashboard 和审批状态恢复，胶水代码少。Claude 用 hooks/permissions/OpenTelemetry，Pydantic 用 hooks/capabilities/Logfire/OTel/Pydantic Evals，也能搭出一样的能力，且更容易接自建/第三方观测后端。
让 agent 处理一个目录里的私有材料并产出文件：两者都能做。Claude 更像”直接开工”；OpenAI 更像”先定义 sandbox/manifest/capability/审批和 artifact 出口”。

Claude 默认给你工作台，OpenAI 默认给你驾驶舱。 真正的问题不是谁更聪明，而是要默认给我多少，又愿意默认绑谁。

Trace 这一条要说精确

三家 (Claude/OpenAI/Pydantic) 技术上都能导 OTel，差别在四点：

打包：Claude 是 env-var 原生开关 (OTEL_METRICS_EXPORTER 系列)；OpenAI 要装社区 contrib opentelemetry-instrumentation-openai-agents-v2；Pydantic 默认就开，最 OTel-native。
语义标准：OpenAI 和 Pydantic 走 OTel GenAI semconv，跨观测系统便携；Claude 用自家 claude_code.* 命名空间，可移植性差一点。
Trace 上下文嵌入：Claude 自动传播 W3C traceparent 到子进程 (Bash/PowerShell)，agent run 能直接嵌入到调用方现有 service trace 里，不孤立成新 silo；OpenAI/Pydantic 主要在 LLM 这一层发 spans。
成熟度：Claude trace 还在 beta (metrics/logs 已 GA)，OpenAI/Pydantic 已稳。

OpenAI”默认进 OpenAI dashboard”更多是默认设置和生态权重，技术上能导 OTel，只是不开箱即用。差异在”默认给你多少”和”默认绑谁”：OpenAI 默认给最多 + 默认绑 OpenAI 平台；Claude/Pydantic 默认中立后端。再叠加 hosted tools 的数据要进 OpenAI 基础设施，企业自托管和数据驻留场景下，Claude/Pydantic 胶水更少。

4. 主流框架对比总表

框架	它替你托管的核心	你还要自己做	强场景	弱点 / 风险
Claude Agent SDK	内置 autonomous loop；文件、命令、搜索、MCP、subagent、skills、session、自动 compaction、权限、hooks、cost/usage、OpenTelemetry	业务系统集成、长期数据模型、产品 UI、批量 eval/治理流程	”给一个目标在工作区持续行动”：改代码、审 repo、整理文档、生成报告、跨文件排查；也适合材料密集型客服/投研/运营	框架强绑定 Claude（可换不同模型，但是框架基于Claude模型优化）；默认工具偏工作区；要严格业务状态机时可能太自主
OpenAI Agents SDK	Runner 自动跑 loop；Agent/Tool/Handoff/Session/Guardrail/Human review/Tracing/Evals/SandboxAgent 一体化控制面；hosted tools 全套，但数据走 OpenAI 基础设施	工具语义、业务状态、审批策略、数据权限、前端、持久化；如果要做工作台型 agent，整套行动 harness（文件、命令、压缩、session）也得自建	愿意吃 OpenAI 平台耦合、想用最少胶水拿到 trace/eval/guardrail/human review 一体化闭环的产品后端 agent	没有默认完整本地工作台；控制面默认绑 OpenAI 平台；换观测后端、跨云、跨模型或企业自托管要自己做适配
Pydantic AI	Pythonic `Agent.run/run_stream/iter` loop；强类型 deps、结构化输出、Pydantic 校验、toolsets、MCP、capabilities、hooks、Logfire/OTel、Pydantic Evals、durable execution	文件系统、代码执行、记忆、权限、guardrails 通过 capabilities/harness 组合；部署和产品壳	Python 后端：需要类型安全、可测试、可替换模型、结构化输出稳定落库	不是开箱即用的 autonomous workbench；行动能力取决于装配的工具和能力包
Google ADK	Runner + event loop；Session/State/Memory/Artifacts；callbacks；sequential/loop/parallel workflow agents；A2A/MCP；Web/CLI/API Server；Cloud Run/GKE/Vertex Agent Engine；评测仿真	非 GCP 场景下的集成成本、模型选择、权限沙箱、业务工具治理；预算/熔断、tool retry 等 harness 细节	已经在 GCP/Vertex/Gemini 生态闭环里、需要 Cloud Run/GKE/Agent Engine 一站式部署的企业	深度耦合 Vertex/GCP；独立基准里执行速度排末位；没有 max_budget_usd 类预算熔断；工具调用失败率被多份评测吐槽；CLI 和文件夹结构死板
OpenCode	开源终端/IDE/Web/Server 形态 autonomous workbench；read/edit/bash/grep/glob/apply_patch/lsp/webfetch/websearch/question；primary/subagents；permissions；sessions；summary/compaction；skills；多模型	生产级 eval、企业 SLA 和商业支持（开源项目）、平台部署、跨系统业务状态	想要可自托管、多模型、接近 Claude Code/Codex 体验的工程工作台	生态和平台闭环弱于厂商；更像开发者工具 runtime，不是通用业务后端框架
DeepSeek-TUI	面向 DeepSeek V4 的终端 agent；1M context、prefix-cache-aware、RLM 并行子推理、file/shell/git/web/apply-patch/subagents/MCP、Plan/Agent/YOLO、session save/resume、side-git rollback、durable queue、HTTP/SSE	生态、稳定性、长期维护、生产治理、模型选择空间	成本敏感、大上下文、中文/终端/DeepSeek 生态、愿意押模型专用 harness 的团队	很新，成熟度和主流验证不足；不是 DeepSeek 官方通用生产框架

5. 五个具体场景

A. 做”AI 工程师”，接 Jira、改 repo、跑测试、提 PR 优先 Claude Agent SDK、OpenCode；如果必须 DeepSeek 成本和 1M context，再 A/B DeepSeek-TUI。OpenAI Agents SDK 也能做，SandboxAgent 给了沙箱底（目前 Python），但 repo mount、审批、artifact、PR 流程仍要自己设计。

B. 客服/运营/销售 agent，能查 CRM、改订单、升级工单、需要人审 如果产品形态是”agent 像员工一样在工作台里处理材料、查系统、写结论、必要时问人”，Claude Agent SDK 优势明显：开发路径短，行动工具齐，hooks/permissions/log/OTel 支撑审计和迭代。如果产品形态是”每个动作都要进入业务状态机，审批可持久化，跨团队统一 eval/trace/guardrail”，优先 OpenAI Agents SDK 或 Pydantic AI。只有已经在 GCP/Vertex 重度建设、Gemini 是主模型的团队，才把 Google ADK 作候选。

C. 研究/文档 agent，读材料、搜网页、产出报告 Claude Agent SDK 上手最快，工作台工具和 compaction 已经齐。OpenAI Agents SDK 更适合做成产品：trace 和 datasets/evals 默认在 OpenAI dashboard 串好，批量研究的评测和复现胶水最少。Pydantic AI 适合 Python 团队把输出强制成结构化 schema 后落库。

D. 多 agent 编排或长流程跨段恢复 不要按”哪个框架支持多 agent”挑。orchestrator + 并行 subagent 各家都做：Claude 用 Agent 工具，OpenCode 用 subagents，OpenAI 用 handoff/agent-as-tool，Pydantic 用 Graph，用你已经选的主框架就行。需要跨天、可恢复、跨业务系统的长流程，把 agent 嵌进 Temporal/Inngest/Restate/DBOS 这类流程引擎，agent 框架谁都能配合。具体见第 6 节。

E. 构建 agent 平台，而不只做一个 agent OpenAI Agents SDK、Pydantic AI 更适合做底座；Google ADK 也能，前提是已经在 GCP/Vertex 生态，否则 Sessions/Memory/部署默认走 Vertex 会把整个平台拖进 GCP 耦合。Claude/OpenCode/DeepSeek-TUI 更像”已有工作台 runtime 可嵌入/可驱动”，能快，但平台抽象会受它们原本形态影响。

6. 多 agent 在 2026 年 5 月的实际格局

自由协作多 agent，那种”几个 agent 围一桌开会到收敛”的模式，在 2026 年生产里已经退潮。Claude Agent SDK 的 Agent 工具、OpenCode 的 subagents、OpenAI 的 handoff/agent-as-tool，都把多 agent 退化成 orchestrator + worker 或专家路由。

活下来的是两类：

Orchestrator + 并行 subagent：主 agent 拆任务、派几个 subagent 并行查、汇总结果。Anthropic 自己的研究 agent 就是这模式，适合”任务可拆 + 子任务独立 + 结果可合并”。
单 agent + durable workflow (Temporal/Inngest/Restate/DBOS)：长流程、跨天、必须可恢复、跨业务系统时，agent 被工作流分段调用，每段是可重试 activity。OpenAI Agents SDK 已经接 Temporal。

自由协作多 agent 输的原因很直接：通信成本高、token 浪费、错误传染、不可重现、几乎没法 eval。工作流刚好相反，每步有边界、可重试、可观测。

多 agent 不是聪不聪明的问题，是任务能不能拆、需不需要跨段恢复的问题。

7. 选型建议

只追求自主行动能力：Claude Agent SDK 第一梯队。理由不是它叫 Claude Code，而是它已经把 agent loop、文件/命令工具、权限、hooks、session、compaction、subagent、skills 这套长任务 harness 打包好。

做生产产品里的 agent：不要简单排除 Claude。工作台型产品、材料处理型产品、内部 agent 工具，Claude Agent SDK 可能更快更强。严格业务流程型产品有两条路：要默认给最多、胶水最少、能接受 OpenAI 平台默认绑定的，用 OpenAI Agents SDK；要默认中立后端、自选观测/评测系统、跨云跨模型或企业自托管的，用 Claude Agent SDK 或 Pydantic AI 更顺。三家技术上都能导 OTel，差别是默认设置和打包方式。

Python 后端 + 在意可靠性、类型、结构化输出、测试：Pydantic AI 很强。它不像 Claude 那样开箱就是自主工作台，但更像 FastAPI 时代的 agent 框架：清晰、类型安全、可组合。

已经在 Google Cloud / Vertex / Gemini / GKE / Cloud Run：Google ADK 值得看。强项是 session/state/artifacts/memory/runtime/deployment/eval 的企业闭环。

要开源、自托管、多模型的终端工作台：OpenCode 是最值得认真试的，更接近 Claude Code/Codex 类产品。

押 DeepSeek V4 未来进步和成本：DeepSeek-TUI 是高风险高弹性的候选。适合试点，不建议一上来就当公司级标准 runtime。

8. 结语

2026 年 agent runtime 的核心分水岭是：它到底只帮你”调用工具”，还是帮你”管理行动”。

模型决定智力上限，runtime 决定行动边界。所以选型问题不是哪个框架更聪明，而是四个具体的取舍：

你要的是自主完成任务，还是产品流程里的可控步骤？
你的核心风险是做不完，还是做错了没人知道？
你的状态在工作区文件里，还是在业务数据库里？
你更需要开箱即用，还是更需要可审计、可评测、可嵌入？

Claude Agent SDK 最擅长工作区型自主任务；OpenAI Agents SDK 最擅长平台化生产 agent；Pydantic AI/Google ADK 适合工程化应用 agent；OpenCode/DeepSeek-TUI 适合终端工作台和自托管实验。

工作台和驾驶舱不分高下，是任务形态决定的。问清楚上面这四个问题，你也就知道自己要走进的是哪一边。

主要来源： Claude Agent SDK Claude Agent Loop Claude Sessions Claude Hooks Claude Code Features in SDK OpenAI Agents SDK OpenAI Running Agents OpenAI Guardrails and Human Review OpenAI Sandbox Agents OpenAI Integrations and Observability OpenAI Agent Evals Pydantic AI Agents Pydantic AI Hooks Pydantic AI Capabilities Pydantic AI Harness Pydantic AI Durable Execution Pydantic Evals Google ADK Runtime Google ADK Event Loop Google ADK State Google ADK Artifacts Google ADK Callbacks Google ADK Evaluation OpenCode Agents OpenCode Tools OpenCode Permissions OpenCode SDK OpenCode Skills OpenCode Server DeepSeek-TUI