OpenAI Agent Builder和Evals将在11月30日下线：开发者迁移Agents SDK完整清单

文章摘要

OpenAI已经明确，Agent Builder和平台内Evals产品将在2026年11月30日后停止提供。对于仍依赖可视化工作流、平台数据集、Trace评分和自动化评测的团队，这不是简单替换一个API，而是需要重新梳理工作流定义、工具调用、状态管理、评测数据和上线治理。本文给出一套从资产盘点、代码化迁移、评测重建、双轨验证到最终切换的完整执行方案。

一、哪些产品会受到影响

OpenAI在AgentKit页面的更新说明中明确表示：

Agent Builder
Evals

将在2026年11月30日后停止提供。

官方给出的迁移方向是：

需要以代码持续运行的工作流
→ Agents SDK

更适合自然语言配置的业务场景
→ ChatGPT中的Workspace Agents

需要注意，这并不等于以下能力全部消失：

  • Responses API；
  • Agents SDK；
  • Tool Calling；
  • File Search；
  • Web Search；
  • Computer Use；
  • ChatKit；
  • 模型API；
  • 自己维护的评测系统。

真正需要迁移的是：

建立在Agent Builder可视化编排和平台Evals产品之上的工作流与质量流程。

二、为什么不能等到11月再迁移

Agent Builder通常不只是画了几个节点，它可能隐含了：

  • Prompt；
  • 分支条件；
  • 工具配置；
  • MCP连接；
  • Guardrail；
  • 人工审批；
  • 模型参数；
  • 错误重试；
  • 版本历史；
  • 发布环境。

Evals则可能保存：

  • 测试数据集；
  • 评分规则；
  • Trace；
  • 模型对比；
  • Prompt版本；
  • 人工标注；
  • 自动评分结果。

如果临近下线才开始迁移，最容易发生：

  1. 找不到完整Prompt版本；
  2. 不知道某个节点为什么存在；
  3. 无法复现平台中的默认行为；
  4. 历史评测结果无法与新系统对齐；
  5. 新旧系统没有足够时间并行验证；
  6. 工具权限和密钥配置遗漏；
  7. 上线后才发现成本明显上升。

建议把迁移拆成三个阶段：

7—8月：资产盘点与目标架构
9—10月：代码迁移与双轨运行
11月：冻结旧系统并完成切换

三、第一步：导出工作流资产清单

不要先写代码，先形成完整资产表。

建议每个Agent Builder工作流记录：

workflow_id
workflow_name
业务负责人
技术负责人
当前模型
入口方式
节点数量
工具列表
MCP Server
数据源
Prompt版本
人工审批点
重试规则
超时
日调用量
单次成本
失败率
是否生产使用

可以使用表格：

资产 必须记录的内容
Prompt System、User模板、变量、默认值
节点 类型、输入、输出、分支条件
工具 名称、Schema、鉴权、风险等级
数据 File Search、向量库、连接器
状态 Thread、Session、Memory
安全 Guardrail、审批、敏感字段
评测 数据集、评分器、基线结果
发布 环境、版本、流量、回滚方案

还应给工作流分级：

P0：核心生产业务
P1：内部高频使用
P2：试点或低频
P3：实验和废弃候选

优先迁移P0和P1，不要把时间浪费在已经没人使用的实验流程上。

四、第二步：把可视化节点转成代码组件

迁移不是把整个画布写成一个超长函数。

建议拆成：

Agent定义
Tool定义
Workflow编排
State模型
Guardrail
Persistence
Observability
Evaluation

一个最小的代码化结构：

agent-project
├── agents
│   ├── classifier.py
│   ├── researcher.py
│   └── responder.py
├── tools
│   ├── search_customer.py
│   ├── query_order.py
│   └── create_ticket.py
├── workflows
│   └── support_workflow.py
├── guardrails
│   ├── input_guard.py
│   └── output_guard.py
├── evals
│   ├── datasets
│   ├── graders
│   └── regression.py
└── app.py

每个可视化节点都应该回答：

输入类型是什么
输出类型是什么
是否可重试
是否有副作用
是否需要状态
失败后怎么办
是否需要人工确认

五、分支条件不要继续依赖自然语言猜测

Agent Builder中的分支可能由模型分类：

退款问题
技术问题
账户问题
其他问题

迁移时应把输出改成结构化对象：

{
  "category": "REFUND",
  "confidence": 0.93,
  "reason": "用户明确要求退回已支付订单"
}

然后使用确定性代码路由：

def route_category(result: dict) -> str:
    category = result["category"]
    confidence = result["confidence"]

    if confidence < 0.75:
        return "human_review"

    routes = {
        "REFUND": "refund_agent",
        "TECHNICAL": "technical_agent",
        "ACCOUNT": "account_agent"
    }

    return routes.get(category, "general_agent")

不要把高风险流程建立在不可追踪的自由文本判断上。

六、工具迁移时重点检查权限

可视化平台可能替你完成了一部分连接配置，但代码化后必须明确：

谁可以调用
可以操作哪些数据
参数范围是什么
是否有副作用
是否需要审批
如何幂等
如何审计

工具定义建议增加元数据：

from dataclasses import dataclass
from enum import StrEnum


class RiskLevel(StrEnum):
    LOW = "low"
    MEDIUM = "medium"
    HIGH = "high"


@dataclass(frozen=True)
class ToolPolicy:
    name: str
    risk_level: RiskLevel
    requires_confirmation: bool
    required_permissions: tuple[str, ...]
    timeout_seconds: int
    max_retries: int

高风险工具包括：

  • 支付；
  • 退款；
  • 删除数据；
  • 修改权限；
  • 创建外部订单；
  • 发送正式邮件；
  • 更新客户信息。

模型只能提出调用建议，最终授权必须由业务代码完成。

七、状态与Memory需要单独设计

迁移后不要把全部状态塞进Prompt。

至少区分：

对话状态

当前用户问题
最近几轮消息
当前语言
当前任务

业务状态

订单号
审批状态
任务进度
已完成步骤
工具执行结果

长期记忆

用户偏好
历史摘要
长期项目资料

建议使用显式State：

from dataclasses import dataclass, field


@dataclass
class WorkflowState:
    trace_id: str
    user_id: str
    task_status: str = "PENDING"
    current_step: str | None = None
    completed_steps: list[str] = field(default_factory=list)
    tool_results: dict = field(default_factory=dict)

需要跨请求恢复的状态应进入数据库或持久化Checkpoint，而不是只保存在进程内存。

八、如何重建Evals能力

平台Evals下线后，评测不能退回到“人工看几条回答”。

建议建立四层评测：

1. 确定性校验

适合：

  • JSON是否合法；
  • 必填字段；
  • 工具名称；
  • 参数范围；
  • 是否泄露敏感字段；
  • 是否引用不存在的订单。

2. 规则评分

例如客服回答：

是否说明处理结果
是否给出下一步
是否包含禁止承诺
是否要求不必要的个人信息

3. 模型评分

适合评估：

  • 相关性；
  • 完整性；
  • 忠实度；
  • 语气；
  • 推理质量。

4. 人工抽检

高风险业务必须保留人工评审。

评测数据结构：

{
  "case_id": "CS-001",
  "input": {
    "message": "我要取消订单A1001"
  },
  "expected": {
    "intent": "CANCEL_ORDER",
    "requires_confirmation": true
  },
  "forbidden": [
    "未确认直接取消",
    "修改其他订单"
  ]
}

九、Trace评测应该如何保留

Agent质量不能只看最终回答。

需要保存完整轨迹：

用户输入
→ 模型决策
→ 工具选择
→ 工具参数
→ 工具结果
→ 下一步决策
→ 最终回答

建议记录：

trace_id
workflow_version
prompt_version
model
step_no
tool_name
arguments_hash
tool_status
latency_ms
input_tokens
output_tokens
total_cost
final_status

可以分别计算：

  • 任务完成率；
  • 工具选择准确率；
  • 参数准确率；
  • 重复调用率；
  • 人工接管率；
  • 平均步骤数；
  • 单任务成本；
  • P95耗时。

十、新旧系统如何双轨验证

不要直接关闭旧工作流。

推荐影子运行：

真实请求
→ 旧系统正常处理
→ 同时复制给新系统
→ 新系统结果不返回用户
→ 比较两套轨迹和结果

对比维度：

指标 旧系统 新系统
任务成功率
平均步骤数
工具错误率
平均成本
P95耗时
人工接管率

当新系统连续达到目标后，再逐步导流：

1%
→ 10%
→ 30%
→ 50%
→ 100%

十一、迁移过程中最容易漏掉什么

1. 默认Prompt

可视化节点可能存在平台默认指令，迁移后行为发生变化。

2. 工具超时

旧平台可能自动处理，代码中却没有设置。

3. 重试叠加

HTTP层、工具层和Agent层同时重试，成本迅速放大。

4. 密钥权限

迁移时直接复用高权限账户，增加安全风险。

5. 评测基线

只保存平均分，没有保存逐条结果，无法定位退化。

6. 版本映射

不知道旧工作流版本对应哪个Prompt和工具版本。

十二、建议迁移时间表

7月下旬

  • 导出全部工作流；
  • 标记P0—P3；
  • 冻结无价值流程；
  • 建立迁移负责人。

8月

  • 完成目标架构；
  • 迁移工具与权限；
  • 重建State和Trace；
  • 迁移首批P0工作流。

9月

  • 建立评测数据集；
  • 影子运行；
  • 修复行为差异；
  • 完成P1流程迁移。

10月

  • 灰度切流；
  • 完成成本和性能优化；
  • 演练回滚；
  • 停止新增旧平台流程。

11月

  • 全量切换；
  • 导出最终历史数据；
  • 关闭旧凭证和连接；
  • 完成审计归档。

总结

Agent Builder和Evals下线，对生产团队而言不是一次简单的产品替换，而是一次Agent工程治理重构。

最稳妥的迁移方式是：

资产盘点
→ 工作流代码化
→ 权限重新设计
→ 状态持久化
→ 评测重建
→ 影子运行
→ 灰度切换

越早开始双轨验证，越能避免11月集中迁移带来的业务风险。

延伸阅读

想持续跟踪大模型、AI Agent、RAG、MCP 与开发者生态的最新变化，欢迎访问 智元界：

https://www.zyentor.com/

智元界将持续分享 AI 热点解读、技术实战、工具推荐与企业落地案例。