现代agent开发2026

vbnet
用户输入
  ↓
Agent Runtime
  ├─ 强模型：理解任务、规划、选择工具
  ├─ Tool Registry / MCP：动态暴露工具
  ├─ Async Executor：并发执行工具
  ├─ Memory / RAG：拉上下文
  ├─ Workflow Engine：长任务、重试、状态恢复
  ├─ Guardrails：权限、审批、安全校验
  └─ Observability / Evals：追踪、评估、回放
  ↓
流式返回 + 工具结果聚合

OpenAI 现在的工具调用流程已经是模型直接返回结构化 tool call，然后由应用执行工具，再把结果回传模型；OpenAI 还提供内置工具，例如 web search、code execution、MCP server 等。 Anthropic 的 Claude 也是类似模式：Claude 根据用户请求和工具描述决定是否调用 client tools 或 server tools，应用侧或 Anthropic 侧执行工具。

所以，低级模型 router 不再是必须品。它现在更多用于节省成本、降低延迟、做安全分流，或者把明显简单的问题送给便宜模型。真正复杂的 Agent，通常让强模型直接面对清晰定义好的工具。

ChatGPT、Claude 为什么能“响应快 + 调很多工作流”

它们的内部实现没有完全公开，所以不能精确断言。但从公开 API 和文档看，主要靠下面几类机制。

第一是 streaming。不是等整个任务完成才返回，而是先把模型输出、工具调用状态、阶段性结果流式推给前端。OpenAI 文档说明，流式响应可以在模型继续生成完整输出时先处理或打印开头内容。

第二是 工具 schema 预注册 + 模型原生 tool calling。模型不是输出自然语言“我应该查数据库”，而是直接输出结构化工具调用。OpenAI 文档把 tool calling 描述为：给模型工具定义，模型返回 tool call，应用执行工具，再把工具结果回传模型。 Claude 文档也说明 Claude 会根据请求和工具描述决定何时调用工具，并返回结构化调用。

第三是 并发工具调用。OpenAI 支持模型在一个 turn 里选择多个 function calls，但需要注意：OpenAI 文档明确写到，使用内置工具时不支持 parallel function calling；自定义 function tools 可以让模型一次选择多个调用。 Claude 的最佳实践也建议：如果多个工具调用之间没有依赖关系，应尽量并行调用，例如同时读取多个文件，而不是顺序读取。

第四是 MCP / Apps / Connectors 这种标准化工具层。MCP 是连接 AI 应用和外部系统的开放标准，可连接本地文件、数据库、搜索引擎、计算器、工作流等。 OpenAI 的 Apps SDK 也建立在 MCP 之上，让 ChatGPT 可以连接外部工具和数据，并扩展出交互式界面。

第五是 Tool Search / Deferred Tools。以前你可能把 100 个工具 schema 全塞进 prompt，模型慢、贵、还容易选错。现在 OpenAI 有 tool search，可以让模型动态搜索和加载需要的工具，避免一次性把所有工具定义放进上下文；OpenAI 文档也说这可以减少 token 和成本，并且设计上保留模型缓存。 Claude 也有 Tool Search Tool，用于让 Claude 面对数百或数千个工具时按需发现和加载。

第六是 prompt caching。固定系统提示词、工具说明、长上下文会被缓存。OpenAI 文档说 prompt caching 可减少最高 80% 延迟和最高 90% 输入 token 成本。 Anthropic 也支持自动缓存和显式 cache breakpoint，适合多轮会话和长上下文。

第七是 运行时层的状态管理、审批和观测。OpenAI Agents SDK 提供 handoffs、agents-as-tools、guardrails、tracing 等能力。 这类能力不是“模型能力”，而是平台和工程系统能力。

现在推荐的 Agent 技术栈

快速上线型：TypeScript / Web 产品

我会选：

Next.js / Node.js

  • Vercel AI SDK
  • OpenAI Responses API 或 Anthropic Messages API
  • MCP Gateway
  • Postgres / Redis
  • pgvector / Qdrant / Weaviate
  • Langfuse 或 Phoenix 做 tracing/evals

Vercel AI SDK 适合前端和全栈应用，支持 streamText、tool calling、审批、动态工具、MCP 工具等场景。 AI SDK 5 还强调了 type-safe chat、agentic loop control、tool improvements 和跨 React/Svelte/Vue/Angular 的集成。

适合你这种想快速做产品原型的人。缺点是复杂长任务、强状态恢复、复杂多 Agent 图编排，需要自己补一层 workflow engine。

Python 后端型：更适合 Agent 服务

我会选：

FastAPI

  • OpenAI Agents SDK / Claude Agent SDK / PydanticAI
  • LangGraph 或 LlamaIndex Workflows
  • MCP servers
  • asyncio / Celery / Dramatiq
  • Postgres + pgvector
  • Temporal / DBOS
  • Langfuse / Phoenix / Braintrust

PydanticAI 适合 Python 里做强类型工具、结构化输出和可控 agent run；它底层用 pydantic-graph 管理执行流。 LangGraph 适合长时间、状态化、多步骤 Agent，它强调 durable execution、streaming、human-in-the-loop 和 persistence。 LlamaIndex Workflows 适合 RAG、文档处理、异步事件流和多步编排。

如果你偏 Python，这套最稳。

企业级复杂工作流：Graph + Durable Execution

如果你的 Agent 会做这些事情：

查多个系统
写数据库
发邮件
审批
等待用户确认
跑几十分钟
失败后继续
多 Agent 协作

那不要只靠一个 while loop。推荐：

LangGraph / Microsoft Agent Framework / Google ADK

  • Temporal / DBOS / Restate / Prefect
  • MCP
  • Tracing / Evals

Microsoft Agent Framework 提供 Agents 和 Workflows 两类能力，支持 LLM、tools、MCP servers、graph-based workflows、type-safe routing、checkpointing 和 human-in-the-loop。 它还内置 sequential、concurrent、handoff、group chat、magentic 等多 Agent 编排模式。 Google ADK 是开源 Agent 开发框架，支持构建、调试、部署企业级 Agent，并支持多 Agent、工具生态、评估和在 Cloud Run / GKE 等环境扩展。

长任务的关键是 durable execution。PydanticAI 官方文档也把 Temporal、DBOS、Prefect、Restate 作为 durable execution 方案，用于让 Agent 在 API 失败、应用重启、长时间任务、人类审批场景下保留进度。 Temporal 也强调它适合 AI 应用中的状态管理、失败处理、调试和 durable execution

现在最值得关注的 Agent 架构方法

1）Augmented LLM

也就是：

LLM + Tools + Retrieval + Memory

这是最基本、最实用的 Agent 形态。Anthropic 把它称作 agentic systems 的基本构建块：模型带有 retrieval、tools、memory 等增强能力，并能主动生成查询、选择工具和决定保留什么信息。

适合：客服、知识库问答、简单业务助手、内部工具助手。

2）Router / Routing Workflow

这个和你一年前做的“意图识别”类似，但现在建议更克制地用。Anthropic 认为 routing 适合输入类别明显不同、后续流程不同、分类准确性可控的任务，例如客服里把退款、技术支持、普通咨询分到不同流程。

适合：客服、工单、业务流程入口。

不适合：用户任务很开放，或者每次都要临时组合多个工具。

3）Parallelization / Fan-out Fan-in

把任务拆成多个独立子任务并发执行，然后聚合结果。Anthropic 把 parallelization 分成 sectioning 和 voting：一种是拆不同子任务，一种是多次独立判断后投票。

适合：

同时查多个数据源
同时读多个文件
同时跑多个搜索
同时让多个 reviewer 检查代码

这是实现“快速响应 + 多工具调用”的关键模式。

4）Orchestrator-Workers

一个主 Agent 动态拆任务，多个 worker/subagent 执行，最后主 Agent 汇总。Anthropic 认为这适合无法预先知道子任务数量和形态的复杂任务，例如代码修改、多源搜索。 OpenAI Agents SDK 也支持 agents-as-tools，即主 Agent 保持最终回答控制权，把专家 Agent 当工具调用。

适合：

研究报告
代码库分析
竞品分析
复杂表格/文档处理
多数据源决策
5）Handoff

Handoff 是把对话控制权交给某个专家 Agent，而不是让主 Agent 只是调用它。OpenAI 文档区分了 handoffs 和 agents-as-tools：handoff 适合专家接管某个分支，agents-as-tools 适合主 Agent 保持控制、调用专家作为辅助能力。

适合：

客服分部门
销售转售后
法务 Agent 接管合同问题
财务 Agent 接管报销问题
6）Evaluator-Optimizer

一个模型生成，另一个模型评估，然后循环优化。Anthropic 认为它适合有明确评价标准、迭代改进能带来可衡量收益的任务。

适合：

代码修复
测试生成
文案打磨
法律条款审查
SQL 生成后校验
7）MCP 工具生态

MCP 现在非常重要。它解决的是：

Agent 怎么标准化连接外部工具、数据库、文件、SaaS、工作流

MCP 允许 server 暴露工具，每个工具有名字、schema 和 metadata，模型可以根据上下文自动发现和调用。 你现在做 Agent，不建议每接一个工具就写一套私有协议，最好把内部系统包装成 MCP server。

8）A2A / Agent-to-Agent

MCP 解决“Agent 调工具”，A2A 更偏“Agent 和 Agent 通信”。Google 发布的 Agent2Agent Protocol 目标是让 AI agents 能安全交换信息、协调动作，并跨企业应用平台协作。 A2A 官方文档也说明，它是用于不同框架、不同供应商构建的 Agent 之间通信协作的开放标准。

短期内你不一定需要 A2A，但如果你做的是企业多 Agent 平台，值得关注。

9）Skills / Procedural Knowledge

Claude Skills 这种模式也很值得学。它不是普通工具，而是把“如何完成某类任务”的说明、脚本、模板、资源打包成一个能力包，按需加载。Anthropic 的 Skills repo 描述 Skills 是包含 instructions、scripts、resources 的文件夹，用来让 Claude 在特定任务上表现更稳定。

适合：

生成固定格式 Excel
按公司品牌规范做 PPT
按内部流程写报告
复杂但重复的操作规范

这对工程实践很重要：不要把所有知识都塞进系统 prompt，把可复用流程做成 Skill / Playbook / Tool instruction。

实战里我会怎么设计一个“快且能调很多工具”的 Agent

推荐架构
前端
├─ SSE / WebSocket 流式展示
├─ 展示 tool progress
└─ 支持用户中途确认/取消

API 层
├─ Request Normalizer
├─ Safety / Permission Check
├─ Agent Runner
├─ Tool Router / Tool Search
├─ Async Tool Executor
├─ Result Aggregator
└─ Trace Logger

工具层
├─ MCP servers
├─ 内部业务 API
├─ 数据库工具
├─ 搜索工具
├─ 文件工具
├─ 代码执行工具
└─ 第三方 SaaS 工具

状态层
├─ Postgres
├─ Redis
├─ Vector DB
└─ Temporal / DBOS
关键优化点

第一，不要一次塞太多工具。
把工具按 namespace、业务域、权限分组，例如：

crm.*
calendar.*
email.*
database.*
file.*
browser.*
payment.*

然后用 tool search 或你自己的工具检索层，先找出候选工具，再给模型调用。

第二，工具 schema 要非常清楚。
Anthropic 明确建议像设计 HCI 一样设计 Agent-Computer Interface，工具定义要有清晰参数、边界、示例、错误约束；他们还提到，在工具优化上花的时间可能比总体 prompt 还多。

第三，独立工具必须并发。
例如用户问：“帮我总结这 5 个客户最近的邮件、CRM 记录和工单”。不要这样：

查客户1邮件 → 查客户1 CRM → 查客户1工单 → 查客户2邮件 → ...

而是：

并发查所有邮件
并发查所有 CRM
并发查所有工单
聚合
让模型总结

第四，长任务交给 workflow engine。
短任务可以一个 HTTP request 内完成；长任务必须有 checkpoint、retry、resume、approval。LangGraph、Microsoft Agent Framework、Google ADK、Temporal、DBOS 这类东西就是为这个准备的。

第五，把安全动作做成人类审批。
比如发邮件、付款、删文件、改数据库、执行 shell，都应该先返回 approval request。Vercel AI SDK 的 tool approval 机制就是这类模式：敏感工具可以设置为需要审批，模型先返回审批请求，批准后再执行。

第六，必须做 tracing 和 evals。
OpenAI Agents SDK 的 tracing 会记录整体 workflow、模型调用、工具调用、handoffs、guardrails 和自定义 spans。 Phoenix 也支持 tracing model calls、retrieval、tool use 和 custom logic，用于调试行为和定位耗时。

你现在应该怎么选

如果你是一个人或小团队，想最快做出可用 Agent，我建议：

前端：Next.js
LLM：OpenAI Responses API 或 Anthropic Claude API
流式：Vercel AI SDK
工具：MCP + 自定义 function tools
数据库：Postgres
向量检索：pgvector 或 Qdrant
缓存：Redis
观测：Langfuse 或 Phoenix
长任务：先不用；复杂后再接 Temporal / DBOS

如果你主要用 Python，我建议：

后端：FastAPI
Agent：PydanticAI 或 OpenAI Agents SDK
复杂编排：LangGraph
RAG：LlamaIndex
工具协议：MCP
长任务：Temporal / DBOS
观测：Phoenix / Langfuse

如果你要做企业级多 Agent 平台：

Agent Runtime：LangGraph / Microsoft Agent Framework / Google ADK
Tool Layer：MCP
Agent Communication：A2A
Durability：Temporal / DBOS
权限：RBAC + human approval
观测：OpenTelemetry + Langfuse/Phoenix/Braintrust
评估：offline evals + production traces replay

我的结论

今天做 Agent，最实用的路线是：

强模型原生 tool calling

  • MCP 工具生态
  • tool search / 动态工具加载
  • 并发 fan-out/fan-in
  • graph workflow
  • durable execution
  • tracing/evals
  • human approval

你一年前的“低级模型做 intent，再调用高级模型”不是过时，而是从主架构降级成优化手段了。现在更重要的是：让强模型直接面对一组设计良好的工具，同时用工程系统控制并发、状态、权限、失败恢复和可观测性。

js技术栈

主流稳妥路线：
Next.js + Vercel AI SDK + shadcn/ui + Postgres + Drizzle/Prisma

更偏工程洁癖 / 类型安全 / AI-agent-friendly 路线：
TanStack Start + TanStack Router + TanStack Query + TanStack AI

折中路线，也是我最推荐给你现在用的：
Next.js + Vercel AI SDK + TanStack Query/Table/Form

行动是实现梦想的钥匙 -- 卡拉·威尔金斯