从零开始搭一个企业级 Agent Harness10/10：2026年有哪些 Framework 和产品 API 可以直接实现这套架构？

前九章已经把企业Agent Harness需要的部件一块块装齐了。现在我把2026年能用的Framework、SDK、模型API和托管Agent产品摊在桌面上，看它们分别能接走哪一段工作。读这一章时，可以一直带着那笔42美元退款：现在缺的是让模型调用工具的循环，还是等审批、恢复任务和查结果的能力？带着这个问题看产品，名字就容易对上用途。

先看清楚：现成工具到底有哪些？

写Agent的Framework、SDK和开源Harness

这一组是装进自己服务里的开发工具。Framework是替我们组织程序流程的框架；SDK是一套可以直接调用的开发组件。它们帮我运行“模型判断下一步—调用工具—把结果交回模型”这段循环；Harness则把上下文、工具、状态和审批一起包在循环周围。服务怎么部署、用户是谁、退款能不能执行，仍由企业应用决定。读表时先看“它具体替我做什么”，找到要省掉的那段工作；再看运行方式和模型绑定，判断它能否放进已有系统。

直接调用模型与Agent能力的API

框架把Agent循环搭起来以后，每一轮仍要有一个模型调用入口。API就是程序向另一项服务发请求的接口。这些API负责接收输入、返回模型结果和工具请求；团队既可以直接调用，也可以把它们交给上一组SDK。

托管Agent运行的平台

模型与Agent循环接好以后，团队还要保存会话、维护运行环境、隔离不同用户的任务，并在请求变多时扩容。托管平台把其中一部分连同Harness一起接走，比较时直接看它实际承担了哪些运行工作。“托管”表示这部分程序由平台负责运行；把自己的Agent代码交给平台运行，与直接使用平台写好的Agent循环，是两种不同的交接范围。

给Agent补上持久执行与观测

无论Agent循环由团队运行还是交给托管平台，程序重启后从哪里继续、出错时怎样查清过程，都要落到具体系统。持久执行负责把进度保存下来，让任务跨重启继续；观测负责留下可追查的调用记录。下面这些配套产品分别接手其中的工作，表中不是每个产品都同时承担两项职责。

换一家模型，需要换掉多少东西？

表里最后一列先回答模型适配。LangChain、OpenAI Agents SDK、ADK、Microsoft Agent Framework、Strands和Pydantic AI都能接多家模型供应商，原来的任务状态与大部分循环可以留下。比如“先等批准，再退款”这项业务规则仍然成立；需要适配的是程序怎样把请求发给新模型，又怎样读回它的结果。不过，工具参数格式、结构化输出、流式事件、模型为什么停止以及平台自带工具都会变化。换模型时我保留同一份业务工具契约，再为新模型接入重做适配与回归测试。

再看运行平台。AgentCore Harness可以在同一个AWS Harness里切换Bedrock、OpenAI、Gemini或LiteLLM兼容模型，这解决了模型选择；会话、隔离环境、身份、工具入口与执行记录仍由AWS承接。Claude Managed Agents、OpenAI Agents API、Gemini Enterprise Agent Platform和Foundry Agent Service同样会保存各自的平台状态。迁移方案要覆盖历史记录、状态重建、运行环境、凭证、审计记录和部署入口。所以“能换模型”与“能搬走整套运行系统”要分别判断。前者看模型接口能否适配，后者还要看历史记录和未完成任务能否一起迁走。

迁移成本看清以后，我把同一笔退款交给不同方案，看看它们各自接走哪些步骤。

把第一章那笔重复扣款放进去，差别马上出来

如果我用Responses API或Messages API调用基础模型与自定义业务工具，模型可以读取描述并提出退款工具调用；循环怎样继续、审批信息放在哪里、接口超时后怎样恢复，都由我的应用负责。Gemini Interactions API还能在服务端保存会话状态、后台运行，并调用Google提供的专用Agent；订单政策、支付工具和业务结果仍要接回我的系统。

如果我先要一个标准Agent循环，选择就跟着团队已有系统走。任务需要读写文件和执行命令，可以用Claude Agent SDK；已经使用OpenAI API，可以让OpenAI Agents SDK接管多轮执行、把任务转给另一个Agent，并在运行前后检查输入和输出；Python团队可以用Pydantic AI先验证退款意图。ADK、Microsoft Agent Framework和Strands则更容易接入各自熟悉的云与编程语言。

这笔退款一旦要求固定顺序，我把它写成“收集证据→提出具体退款金额→等待批准→执行→核验退款编号”。这时直接使用LangGraph最清楚：持久状态存储器按同一个thread_id保存进度。这里的thread_id是用来找回同一条工作流记录的标识，审批节点就是流程中负责等待与处理批准的一步。经理批准后，程序会重新进入这个节点处理批准结果，再走到单独的支付节点；支付调用始终携带同一个动作编号与幂等键。LangGraph保存程序做到哪里，支付系统确认退款是否真的发生。

LangChain技术栈从底到上分成三个层级：LangGraph控制复杂状态与确定步骤，LangChain提供标准循环，Deep Agents再补上任务规划、文件上下文、长任务和子Agent。要明确指定每一步和跳转条件，就从LangGraph进入；只需要标准循环，可以从LangChain进入；需要已经配好的规划、文件和子Agent能力，再看Deep Agents。LangSmith可以在旁边记录模型和工具每一次调用，再用旧的失败案例检查新版本有没有退步。

任务要跨多个服务等待几天，我再把Temporal、Restate或DBOS接进来。它们保存审批、定时等待和恢复位置；同一个退款有没有被执行两次，则由稳定动作编号、副作用账本和支付服务共同核对。

如果团队连会话、运行循环、隔离环境和扩缩容也不想运营，就选托管平台。Claude Managed Agents和OpenAI Agents API直接托管整个Harness；AgentCore Harness提供配置式Harness，AgentCore Runtime只托管团队带来的Agent代码；Foundry和Gemini Enterprise Agent Platform进一步把云身份、工具入口和运行记录接进调用路径。

为什么2026年可以少写不少接线

今年的变化集中在三件事。第一，托管产品开始明确接管Harness而不只提供模型：Claude Managed Agents与OpenAI Agents API进入公开阶段，AgentCore Harness正式可用，Foundry与Gemini Enterprise Agent Platform也把Agent运行、身份和工具入口放到同一产品面上。

第二，自己写的Agent更容易获得持久执行。Pydantic AI与Restate在5月提供直接集成；Temporal在2026年10月的Product Edition中把ADK、OpenAI Agents SDK、Strands和LangGraph等Agent集成列为正式可用。这里少写的“接线”，是把Agent每个步骤接到进度保存、等待通知和故障恢复上的代码。接线代码变少以后，团队更容易把注意力放回审批、幂等和权威结果核验。

Agent一旦要调用外部工具，或者把任务交给另一个Agent，连接方式就成为第三件事。A2A 1.0于2026年3月12日发布，用于独立Agent系统交换任务和产物；MCP 2026-07-28核心规范让工具请求携带明确的版本、身份和能力。MCP Tasks扩展截至2026年11月8日仍是Draft草案，可以表达单个长工具调用的查询、取消与等待输入。工具、运行和连接这三层都有了现成选择，我就可以把它们组合成几条清楚的起步路线。

四个可以直接开始的组合

组合一：最小自建Agent

我先用LangChain接上一个模型API和公司的工具入口。用户提交重复扣款后，LangChain让模型整理退款意图，也就是明确要处理的订单、金额与理由，再调用“查询订单”和“申请退款”两个工具；工具入口检查当前用户能不能退这张订单，支付服务用同一个动作编号避免重复退款。需要排查时，LangSmith把模型和工具的调用记录串起来。这一组保留自建空间，适合已经有后端、权限和日志系统，只想尽快把Agent循环跑起来的团队。

组合二：把退款步骤写清楚

退款顺序不能由模型临场决定时，我直接用LangGraph画出五个节点：查订单、提出退款金额、等经理批准、执行退款、核验结果。持久状态存储器把当前节点和任务数据写入可靠存储，因此服务进程退出后，仍能找回原来的位置。经理第二天批准后，程序会重新运行暂停所在的审批节点，所以我把实际支付放在批准后的独立节点，并一直使用同一个幂等键。公司的工具入口负责权限，副作用账本记录退款动作，支付服务给出最终结果。这一组适合步骤固定、需要暂停恢复和完整审计的财务、采购与合规任务。

组合三：先检查数据，再让长任务可靠运行

我用Pydantic AI把退款意图固定成订单、金额、原因三个字段，字段缺失或类型错误时先停下来，不让错误参数进入支付系统。比如金额应当是可计算的数值，模型却给了一段解释，程序就要求它修正；金额填写正确以后，是否允许退款仍由公司的权限与业务规则判断。Restate或Temporal再保存模型已经作出的决定、等待中的审批和完成过的步骤；程序重启后，它从最后一个可靠位置继续，而不是重新猜一次退款金额。批准到来后，调用仍经过公司的工具入口，再由支付服务返回最后的退款结果。这一组适合Python团队，也适合要跨天等待、跨多个服务完成的任务。

组合四：托管Harness加企业控制系统

团队不想维护Agent进程、会话保存、隔离环境和扩缩容时，我从Claude Managed Agents、OpenAI Agents API、AgentCore Harness、Gemini Enterprise Agent Platform或Foundry Agent Service中选一个托管平台。平台运行Agent，公司现有系统仍负责四件事：确认用户身份、判断这笔退款是否允许、执行支付调用、到支付系统核验最终退款编号。这一组适合已经确定云平台、希望把运行基础设施交出去的团队；选型时要同时计算模型绑定和平台迁移成本。

无论选哪一组，我都让第一章那笔重复扣款完整走一次：批准是否只对这一次具体退款金额有效；服务重启后是否读取同一份退款意图；支付超时后是否复用同一动作编号；公司的工具入口和支付服务是否分别检查权限；核验程序能否拿到唯一退款编号；调用记录能否把整个过程串起来。

选了支持多家模型的框架，我还让至少两家模型读取同一份任务契约和工具输入格式，比较生成合法退款意图的比例、人工介入次数、延迟和总成本。这样验收的是整套Agent换模型后的行为，而不只看某一次回答。

十篇走到这里，我们从一个最小Agent循环出发，逐个补上完成条件、上下文、工具边界、恢复、权限、评测与多Agent协作。现在再看这张产品目录，每个名字都有了位置：它接管哪一段、留下哪一段、出了问题该去哪里查。