目录
[1 引言](#1 引言)
[2 理论知识与技术基础](#2 理论知识与技术基础)
[2.1 从对话模型到Agent：最小闭环到底是什么](#2.1 从对话模型到Agent：最小闭环到底是什么)
[2.2 形式化视角：把Agent看成带工具的POMDP](#2.2 形式化视角：把Agent看成带工具的POMDP)
[2.3 检索增强与工具增强：上下文构建的两条路径](#2.3 检索增强与工具增强：上下文构建的两条路径)
[2.4 工作流与控制流：为什么2025更像"图结构"而不是"长提示词"](#2.4 工作流与控制流：为什么2025更像“图结构”而不是“长提示词”)
[3 通用ChatGPT Agent的分层架构：2025年的"参考实现"](#3 通用ChatGPT Agent的分层架构：2025年的“参考实现”)
[3.1 整体框架结构：从模型到执行环境的五层视图](#3.1 整体框架结构：从模型到执行环境的五层视图)
[3.2 Agent Loop：观察---推理---行动---反思的工程化闭环](#3.2 Agent Loop：观察—推理—行动—反思的工程化闭环)
[3.3 运行对象：任务、会话、状态、轨迹与"可解释的中间层"](#3.3 运行对象：任务、会话、状态、轨迹与“可解释的中间层”)
[4 工具调用系统：从函数到"可见世界"的操作](#4 工具调用系统：从函数到“可见世界”的操作)
[4.1 工具分类：托管工具、函数工具、Agent工具、MCP服务器](#4.1 工具分类：托管工具、函数工具、Agent工具、MCP服务器)
[4.2 托管工具清单：从搜索到终端的"可组合行动空间"](#4.2 托管工具清单：从搜索到终端的“可组合行动空间”)
[4.3 Web Search：三种模式与"深度研究"化](#4.3 Web Search：三种模式与“深度研究”化)
[4.4 File Search与向量存储：知识外部化的主通道](#4.4 File Search与向量存储：知识外部化的主通道)
[4.5 Computer Use：GUI行动空间与闭环反馈](#4.5 Computer Use：GUI行动空间与闭环反馈)
[5 规划与推理：2025 Agent的核心算法栈](#5 规划与推理：2025 Agent的核心算法栈)
[5.1 ReAct范式：推理痕迹与行动交织](#5.1 ReAct范式：推理痕迹与行动交织)
[5.2 Toolformer：让模型学会"何时用工具"的数据路径](#5.2 Toolformer：让模型学会“何时用工具”的数据路径)
[5.3 Reflexion：把失败经验写回策略的迭代机制](#5.3 Reflexion：把失败经验写回策略的迭代机制)
[5.4 Voyager：技能库、自动课程与"可迁移的工具链"](#5.4 Voyager：技能库、自动课程与“可迁移的工具链”)
[5.5 规划的工程化折中：局部最优、可解释与可恢复](#5.5 规划的工程化折中：局部最优、可解释与可恢复)
[6 记忆与知识：从短期上下文到长期外部化](#6 记忆与知识：从短期上下文到长期外部化)
[6.1 会话记忆与长期记忆：生产系统更偏好"外部化"](#6.1 会话记忆与长期记忆：生产系统更偏好“外部化”)
[6.2 外部记忆的三件套：向量库、引用与可追溯证据](#6.2 外部记忆的三件套：向量库、引用与可追溯证据)
[6.3 记忆写入的安全边界：PII、越狱与数据泄露](#6.3 记忆写入的安全边界：PII、越狱与数据泄露)
[7 多Agent与工作流编排：从"一个大脑"到"团队协作"](#7 多Agent与工作流编排：从“一个大脑”到“团队协作”)
[7.1 Handoffs：委派机制与角色分工](#7.1 Handoffs：委派机制与角色分工)
[7.2 Agents as Tools：子Agent工具化的工程意义](#7.2 Agents as Tools：子Agent工具化的工程意义)
[7.3 Agent Builder：节点化编排、版本化发布与可调试运行](#7.3 Agent Builder：节点化编排、版本化发布与可调试运行)
[7.4 ChatKit：托管后端与自托管后端的两种部署形态](#7.4 ChatKit：托管后端与自托管后端的两种部署形态)
[8 可观测性与评测：从"能跑"到"可衡量"](#8 可观测性与评测：从“能跑”到“可衡量”)
[8.1 Tracing与Trace Grading：把每一步变成可审计事件](#8.1 Tracing与Trace Grading：把每一步变成可审计事件)
[8.2 学术基准：WebArena、VisualWebArena、OSWorld、GAIA等](#8.2 学术基准：WebArena、VisualWebArena、OSWorld、GAIA等)
[8.3 用真实数据理解"可靠性"：幻觉、语言覆盖与偏差](#8.3 用真实数据理解“可靠性”：幻觉、语言覆盖与偏差)
[9 安全、权限与抗攻击：Agent能力放大后的系统工程](#9 安全、权限与抗攻击：Agent能力放大后的系统工程)
[9.1 Prompt Injection：从文本攻击到工具劫持](#9.1 Prompt Injection：从文本攻击到工具劫持)
[9.2 用户确认与watch mode：把高风险动作变成"可逆决策"](#9.2 用户确认与watch mode：把高风险动作变成“可逆决策”)
[9.3 终端网络限制、加密推理项与企业隐私](#9.3 终端网络限制、加密推理项与企业隐私)
[9.4 安全评测：从越狱到指令层级](#9.4 安全评测：从越狱到指令层级)
[10 成本、延迟与资源治理：把"智能"落在可运营的约束里](#10 成本、延迟与资源治理：把“智能”落在可运营的约束里)
[10.1 Token成本、工具成本与计费模型](#10.1 Token成本、工具成本与计费模型)
[10.2 背景模式：长任务的可靠执行方式](#10.2 背景模式：长任务的可靠执行方式)
[11 2025生态与标准化：MCP、连接器与"可组合工具链"](#11 2025生态与标准化：MCP、连接器与“可组合工具链”)
[11.1 MCP：上下文与工具接入的标准化接口](#11.1 MCP：上下文与工具接入的标准化接口)
[11.2 AgentKit：从SDK到可视化平台的闭环](#11.2 AgentKit：从SDK到可视化平台的闭环)
[12 结语：通用Agent架构的稳定内核](#12 结语：通用Agent架构的稳定内核)
1 引言
如果把传统聊天模型看作"只会说话的系统"，那么2025年兴起并快速落地的ChatGPT Agent更像"会做事的系统"：它不仅能生成文本，还能在任务的上下文中自行搜索、读取文件、调用外部工具、甚至通过可视化浏览器界面执行点击与输入，从而把"回答问题"扩展为"完成目标"。这种变化并不是简单的能力叠加，而是架构层面的范式转移：系统需要有明确的任务边界、可回溯的执行轨迹、可控的权限与确认机制，以及能把外部世界变化反馈回模型的闭环。以OpenAI在2025年7月发布的ChatGPT agent系统卡所描述的能力形态来看，一个通用Agent往往将深度研究式的多步检索与综合写作能力、可视化远程浏览器的任务执行能力、受限网络的终端/代码环境、以及通过连接器访问外部数据源等能力整合为一个统一体，并且将安全作为系统设计的固有部分而不是外挂功能。
从工程实现角度看，2025年的"通用ChatGPTAgent架构"已经逐步形成可复用的标准构件：以Responses API为核心的工具调用接口与长任务执行方式，以Agents SDK为代表的轻量编排与可观测机制，以AgentKit/Agent Builder/ChatKit为代表的可视化工作流与部署组件，以及以MCP（Model Context Protocol）为代表的工具与上下文标准化接入方式。尤其值得注意的是，OpenAI在2025年5月对Responses API的更新中强调了远程MCP服务器支持、后台模式（background mode）、推理摘要（reasoning summaries）与加密推理项（encrypted reasoning items）等特性，指向了一个更"可运营"的Agent平台：不仅能做事，还要能在真实业务中长期稳定运行、可审计、可优化。
本文将围绕"2025通用ChatGPT Agent架构"进行综述性梳理：从理论抽象与技术基础出发，逐层拆解Agent的分层架构、工具系统、规划与推理范式、记忆与知识外部化、多Agent协作与工作流编排、评测与可观测性、安全与权限控制、以及成本与运维约束。
2 理论知识与技术基础
2.1 从对话模型到Agent：最小闭环到底是什么
讨论"Agent架构"之前，先把"Agent"与"聊天"区分清楚。聊天系统的核心闭环往往是"输入→生成→输出"，即使加入了少量工具（例如单次检索），本质上仍是"为了一次回答服务"。而通用Agent的闭环更接近"观察---推理---行动---再观察"的反复迭代，它必须把外部世界当成状态机/环境来处理：网页会变化、文件会更新、工具会失败、权限会不足、用户会改变目标，系统不能只追求一次性输出的"看起来正确"，而要在执行过程中持续校正。OpenAI在Agents SDK中把这种闭环直接做成内建的"agent loop"，强调其负责工具调用、回传结果、持续循环直到模型停止。
当系统具备网页搜索、文件检索、GUI操作、代码执行、连接器访问等能力时，闭环的"行动"空间会变得非常大，这带来两个直接后果：一是模型输出不再只是自然语言，还会产生结构化的工具调用参数；二是系统必须把"行动结果"作为下一步推理的输入，保证状态一致性。Computer use工具的官方说明明确把它描述为一个连续循环：模型提出如click(x,y)、type(text)等动作，你的代码在真实浏览器/虚拟机环境执行，然后把截图回传给模型继续决策。 这意味着Agent系统的工程核心，已经从"生成一段话"转向"维护一个可交互环境中的闭环控制"。
2.2 形式化视角：把Agent看成带工具的POMDP
为了更系统地理解"通用ChatGPT Agent架构"，一个常用的理论抽象是把Agent视作部分可观测马尔可夫决策过程（POMDP）中的策略执行者：环境有真实状态s，但Agent只能通过观测o（例如网页DOM、可访问性树、截图、文件片段、工具返回值）来近似推断状态；Agent在每一步选择行动a（自然语言输出或工具调用），获得奖励/代价信号r，同时环境转移到新状态。Agent的目标并不一定是传统强化学习里严格的长期回报最大化，但把"成功完成任务"形式化为奖励函数，有助于解释许多工程设计选择，比如为什么要引入工具调用成本、为什么要限制某些权限、为什么要做用户确认与"watch mode"。
一个简化的目标函数可以写成"带成本的期望回报最大化"：
\\pi\^\*=\\arg\\max_{\\pi}\\ \\mathbb{E}\\left\[\\sum_{t=0}\^{T}\\gamma\^{t}\\left(r_t-\\lambda c_t\\right)\\right\]
其中，π表示策略（可由LLM+编排器共同实现），γ为折扣因子，r_t是每步对"任务进展"的奖励刻画，c_t是工具调用/时间/风险等成本，λ是成本权重。这个公式在工程上对应着非常具体的现象：当工具调用昂贵、或具有潜在风险（如计算机操作可能误点、终端可能泄露环境变量）时，系统会偏向先用推理压缩搜索空间，再谨慎调用工具，并在关键步骤插入用户确认与安全检查。OpenAI在计算机使用工具文档中也明确提醒其仍处于beta阶段，不建议在完全登录/高风险环境中无监督信任。
POMDP形式化还解释了"记忆"的必要性：因为观测并不等于状态，Agent需要维护信念状态b_t（belief），以便在部分信息下决策。在经典POMDP里，belief更新可写为：
b_{t+1}(s')=\\eta\\ O(o_{t+1}\\mid s')\\sum_{s}T(s'\\mid s,a_t)\\ b_t(s)
这里T是状态转移概率，O是观测概率，η是归一化常数。对LLM Agent而言，我们通常不会显式计算这些概率，但会用"上下文窗口里的历史消息、工具回执、检索片段、结构化状态对象"来近似承载b_t。Agents SDK把"Sessions"作为一等公民，强调其自动维护对话历史以支撑跨次运行的状态管理。
2.3 检索增强与工具增强：上下文构建的两条路径
在2025年的通用Agent实践中，"让模型知道更多"通常走两条路径：第一条是检索增强（RAG/向量检索/文件检索），第二条是工具增强（调用外部系统获取实时信息，或直接操作环境完成任务）。二者看似类似，实则对架构的要求不同。检索增强更强调"把外部知识压缩成可输入上下文的片段"，需要向量化、召回、重排、切片与过滤；工具增强更强调"把外部系统当成行动空间的一部分"，需要工具定义、参数校验、权限、失败重试、以及执行环境的安全隔离。
用一个简化的检索流程表达式，可以把"查询q构建上下文C(q)"写成：
这里D是文档片段集合，e(·)是向量编码器，sim是相似度函数，TopK产生排序索引π，Concat把前k个片段拼接为上下文。这个公式背后的工程问题在于：k如何选、片段如何切、过滤条件如何表达、以及召回后如何让模型"信任并引用"这些片段。OpenAI在Agents SDK与平台文档里把"file search"作为托管工具之一，并强调其可查询OpenAI托管的向量存储（vector stores），同时支持多向量库搜索与属性过滤等能力。
工具增强则更像把Agent嵌入到一个"可执行的工作流"：模型不需要把所有知识压进上下文，只需要知道"该去哪个工具问什么问题、拿到什么结果再怎么推理"。OpenAI在web search工具文档中甚至把"深度研究（deep research）"单独作为一种更长程、更迭代的检索方式，强调它可能调用大量来源并适合配合后台模式运行。 这也意味着，通用Agent架构必须同时支持"检索片段注入"和"工具循环控制"，而且两者在可观测性与安全策略上会有明显差异。
2.4 工作流与控制流：为什么2025更像"图结构"而不是"长提示词"
早期许多LLM应用用"一段超长提示词+少量函数调用"就能跑起来，但当任务变成多步、多工具、多角色协作时，控制流会迅速变得复杂：你需要条件分支、错误回退、循环、并行检查、不同角色的handoff、以及对每一步输入输出进行类型约束。这些需求推动了工作流图结构在2025年的主流化。OpenAI的Agent Builder把"workflow"定义为agents、tools与control-flow logic的组合，并强调节点连接形成"typed edge"，即每条边有明确的数据契约，便于调试与防止下游节点收到不符合预期的数据。
这种"图化"并不只是界面上的便利，而是Agent可靠性工程的核心：当你能把每一步的输入输出类型化，就能把很多原本会在模型里以隐式方式发生的问题（比如某个工具参数缺失、某个字段类型错误、某次检索没召回）前移到编排层做校验与补救。2025年Agents SDK强调"少量原语"即可表达复杂关系：agents、handoffs、guardrails、sessions，再加上内建tracing，这种设计取向与"图工作流"是一致的------把控制流显式化，把安全与校验显式化，把执行轨迹显式化。
3 通用ChatGPT Agent的分层架构：2025年的"参考实现"
3.1 整体框架结构：从模型到执行环境的五层视图
把2025年的通用ChatGPT Agent拆开看，最清晰的一种方式是分层：最底层是执行环境（浏览器、虚拟机、沙盒、外部系统API），其上是工具层（web search、file search、computer use、code interpreter、连接器、MCP服务器等），再上是编排层（agent loop、工作流图、handoffs、重试、缓存、并行guardrails），再上是模型层（具备推理与工具调用能力的LLM/推理模型），最上是产品层（交互UI、会话、权限、可观测与审计、企业治理）。OpenAI对ChatGPT agent的描述基本覆盖了这些要素：它结合深度研究与Operator，通过远程可视浏览器执行任务，提供受限网络的终端工具进行数据分析与生成幻灯片/表格，并可通过第一方连接器访问外部数据源（如Google Drive）。
图1：2025通用ChatGPT Agent分层架构框架图
在这个分层框架中，最容易被低估但最关键的是"编排层"。很多人会把Agent理解为"更强的模型+更多工具"，但真正让系统可用的是编排层如何在工具之间组织信息、在失败时恢复、在风险动作前让用户确认、在输出前做安全检查、并记录完整轨迹以便复盘。Agents SDK把"agent loop"做成内建能力，并把guardrails、sessions、tracing作为核心原语，这反映的就是一种"编排优先"的设计哲学：把模型当成决策器，把工具当成行动空间，把编排当成控制系统。
3.2 Agent Loop：观察---推理---行动---反思的工程化闭环
通用Agent的最小运行单元可以抽象为一个循环：接收目标与上下文→生成下一步行动（可能是语言、也可能是工具调用）→执行行动→把结果纳入上下文→判断是否结束。这个闭环在2025年被进一步标准化：工具调用不再是"开发者强制指定"，而是模型在推理过程中主动决定是否调用，并可在多次调用后再产出最终答案。OpenAI在Responses API更新中强调o3和o4-mini等推理模型能够在Responses API里"直接在chain-of-thought中调用工具和函数"，并且可以在跨请求与工具调用中保留推理token，从而提升智能并降低成本与延迟。
图2：Agent运行主循环
这张流程图背后其实是"Agent loop的职责边界"问题：哪些环节交给模型，哪些必须由系统强制执行。以computer use为例，模型可以提出点击坐标或输入文本，但真正执行动作的是你的代码/沙盒环境；模型可以提出"继续下一步"，但系统应在敏感动作前插入用户确认，或在检测到潜在prompt injection时强制进入watch mode。ChatGPT agent系统卡的风险缓解摘要中明确提到prompt injection场景下的多层缓解手段，包括自动监控与过滤、用户确认、敏感上下文下的watch mode、终端网络限制以及关闭记忆等。
3.3 运行对象：任务、会话、状态、轨迹与"可解释的中间层"
为了把Agent从"看起来很聪明"变成"可运营"，架构里必须有一套能被工程系统理解的运行对象。2025年OpenAI平台文档中，"会话""工作流ID与版本""工具调用对象""trace与grader"等概念都被提升为平台级能力：Agent Builder发布工作流时会生成可版本化的工作流对象；ChatKit在前端嵌入聊天体验时会创建会话并以workflow作为后端；Responses API通过工具调用对象返回web_search_call、open_page、find_in_page等动作以及引用注释；Agents SDK内建tracing用来可视化与调试agentic flows。
一个很现实的经验是：如果你不显式维护这些对象，Agent系统就会退化成"巨大且不可控的提示词工程"。例如当用户说"帮我做个报表并发邮件"，系统至少需要区分"任务状态"（已找到数据/已生成表格/已确认收件人/已发送）、"权限状态"（是否登录/是否授权连接器/是否允许发送）、"工具状态"（某次调用失败原因、重试次数）、以及"证据状态"（哪些数据源被使用、是否带引用）。这些对象如果只存在于模型的隐式上下文里，就很难做可靠性治理；而当它们存在于编排层，就能与guardrails、重试策略、缓存、审计系统对接，从而形成真正的生产级Agent。
4 工具调用系统：从函数到"可见世界"的操作
4.1 工具分类：托管工具、函数工具、Agent工具、MCP服务器
2025年的Agent工具体系已经明显分层。OpenAI Agents SDK（JS/TS文档）把工具分成四类：托管工具（Hosted tools）、函数工具（Function tools）、Agent作为工具（Agents as tools）、本地MCP服务器（Local MCP servers）。托管工具运行在OpenAI服务器侧，典型包括web search、file search、computer use、code interpreter、image generation等；函数工具则是把本地函数包装成带JSON schema的可调用接口；Agent作为工具则把一个子Agent整体暴露为工具；MCP服务器工具则允许把运行在本机或远程的MCP server接入模型调用。
表1给出Agents SDK最小原语与其在架构中的位置，这些原语决定了很多工程系统的"天然边界"，例如handoff通常是多Agent协作的显式切换点，guardrails通常是成本控制与安全门控的插入点，sessions则是跨次运行的状态载体。
表1 Agents SDK核心原语与架构含义
| 原语 | 直观定义 | 架构作用 | 常见落点 |
|---|---|---|---|
| Agent | 带指令与工具的LLM | 决策器/策略执行者 | 领域专家Agent、路由Agent、总结Agent |
| Handoffs | Agent间委派机制 | 角色切换/分工协作 | "转人工/转专科"或多角色流水线 |
| Guardrails | 输入/输出校验与拦截 | 安全门控与质量保障 | PII遮罩、越狱检测、格式验证、风险动作拦截 |
| Sessions | 自动维护历史上下文 | 状态与记忆载体 | 多轮任务、长任务续跑、断点恢复 |
| Tracing | 内建可视化追踪 | 可观测与调试基础 | trace/span、评测、后续优化与审计 |
在工具层面，托管工具与本地工具的区别尤其关键：托管工具通常带有平台侧安全策略与统一计费，而本地工具意味着你需要承担更多安全责任，比如把浏览器或虚拟机沙盒化、避免泄露环境变量、限制文件系统访问等。computer use工具文档就明确建议使用沙盒环境，并列出降低风险的设置方法，例如在本地浏览器自动化时避免暴露宿主环境变量、禁用扩展与文件系统等。
4.2 托管工具清单：从搜索到终端的"可组合行动空间"
托管工具的价值不在于"种类多"，而在于它们为模型提供了稳定的行动原语，并将很多低层细节（如检索、引用、文件切片、沙盒执行）封装为可调用接口。Agents SDK文档列出的托管工具类型非常直观：web search、file search、computer use、shell、apply patch、code interpreter、image generation等，并指出这些参数集与Responses API保持一致。
表2 OpenAI托管工具类型与用途
| 工具类型（type string） | 典型用途 | 输出形态（常见） | 关键工程关注点 |
|---|---|---|---|
| web_search | 互联网实时检索并给出引用 | 搜索结果+引用注释 | 域名过滤、引用可追溯、上下文窗口约束 |
| file_search | 查询OpenAI托管向量库 | 命中文档片段 | 切片策略、过滤条件、多向量库搜索 |
| computer | GUI自动化（点击/输入/滚动） | 动作建议+截图回传 | 沙盒化、权限确认、误操作风险 |
| code_interpreter | 沙盒中运行代码做分析 | 计算结果/文件产物 | 资源限制、依赖管理、成本计费 |
| shell / local shell | 执行命令行操作 | stdout/stderr | 环境隔离、网络限制、敏感信息泄露 |
| apply_patch | 以diff形式修改文件 | patch应用结果 | 变更可审计、回滚策略 |
| image_generation | 生成或编辑图像 | 图像 | 内容安全、成本与速率限制 |
把这些工具组合起来，Agent系统就可以覆盖从"信息获取→信息处理→行动执行→结果交付"的完整链路：web_search负责面向开放互联网的最新信息，file_search负责面向企业或个人知识库的内部文档，computer use负责在GUI上完成跨站点的操作，code interpreter负责把数据加工成可复用产物（表格、图、报告）。这与ChatGPT agent系统卡中的能力描述是对应的：远程可视浏览器环境用于执行任务，终端工具用于数据分析与生成幻灯片/表格，连接器用于访问外部数据源。
4.3 Web Search：三种模式与"深度研究"化
在Agent架构中，web search不是"把搜索结果贴给模型"这么简单。OpenAI的web search工具指南明确区分了三种模式：非推理web search（模型不做内部规划，直接传递工具返回，速度快适合快速查找）、推理模型的agentic search（模型主动管理搜索过程、可多轮搜索与分析）、以及deep research（面向长程深入调查，可能访问数百来源，适合配合后台模式运行）。 这种分层意味着：同样是"搜索"，架构上需要支持不同的控制策略与预算模型。例如快速查找更像一次性工具调用，而深度研究更像一个独立的子工作流，需要有持续的状态、允许更长的执行时间，并且要把引用结构化返回以便产品层展示。
对于通用Agent而言，web search的"引用"能力是可信输出的关键组成部分。web search文档强调：当模型使用该工具时，输出会包含web_search_call项以及包含引用注释的message项，并要求在面向终端用户展示时必须让引用清晰可见且可点击。 这对应着一个重要的架构决策：把"证据链"作为输出的一部分，使得Agent不仅输出结论，还输出可追溯证据，从而降低幻觉风险并增强审计性。后文在"幻觉评测"章节会看到，通用Agent在启用浏览能力后，其准确率与幻觉率的关系会呈现更复杂的变化，这也提示了"引用机制+评测机制"必须共同设计，而不是单纯依赖模型自觉。
4.4 File Search与向量存储：知识外部化的主通道
与web search面向开放互联网不同，file search更像企业/个人知识系统的内循环。OpenAI在Responses API更新中指出file search使开发者可以基于用户查询把文档相关片段拉入上下文，并且还引入了跨多个向量存储搜索与支持属性过滤数组等更新；同时给出了明确的计费模型：向量存储按0.10/GB/天计费，工具调用按2.50/1000次计费。 这种计费方式会直接影响架构：你会更倾向于在编排层做"召回预算管理"，比如限制每次召回片段数量、对热门文档做缓存、把低价值文件从向量库中移除或降频更新。
在通用Agent架构里，file search不仅是"补充知识"，还是"长期记忆的外部化形态"。因为把记忆写进模型上下文有窗口限制，写进模型参数又不可控且成本巨大，因此把"可检索的记忆"写入向量库成为主流方案：会话摘要、关键事实、用户偏好、项目上下文都可以以结构化文档形式进入向量库，然后通过file search按需召回。值得注意的是，ChatGPT agent系统卡在风险缓解摘要中明确提到"ChatGPT的记忆被禁用"，这提示了一个非常现实的安全考量：当Agent具备连接器与多工具访问能力时，长期记忆可能带来敏感信息滞留与被攻击利用的风险，因此在某些产品形态下宁可牺牲记忆便利，也要优先降低风险面。
4.5 Computer Use：GUI行动空间与闭环反馈
Computer use把Agent能力从"调用API"扩展到了"操作真实软件界面"。OpenAI的Computer use指南把它定义为一个连续循环：模型提出动作（点击、输入等），你的代码执行动作并回传截图，模型据此继续提出下一步动作。 这种设计在理论上对应"观测o是截图/DOM，行动a是GUI操作"，在工程上则意味着你必须提供一个可截图、可执行动作、且最好沙盒化的环境（本地浏览器自动化或本地虚拟机）。更关键的是，GUI操作空间往往是高风险空间：误点"提交订单"、误触"删除文件"、或被网页中的prompt injection诱导执行非预期动作，都可能造成真实损失。因此系统必须引入权限控制与用户确认机制。
computer use工具文档中给出了一个非常具体的可靠性信号：computer-use-preview模型在OSWorld上的表现"目前为38.1%"，并提示这表明其对OS级任务自动化仍不够可靠。 这类数据对架构设计很重要，因为它提醒我们：当成功率远未达到接近100%的水平时，系统就必须假设"失败是常态"，因此要有可回退、可纠错、可中止的机制，例如在关键步骤要求用户确认、在失败后自动重试或切换策略、在长链路任务中分段提交中间产物等。
同时，computer-use-preview模型的计费与性能特征也会反过来塑造系统形态：官方模型页给出其输入输出价格分别为3/12（每百万token），上下文窗口8192，最大输出1024，并给出可锁定的snapshot版本（如computer-use-preview-2025-03-11）。 这意味着如果你的Agent大量依赖截图与多轮交互，token成本会显著上升，并且你需要通过"减少无效循环、压缩观测表示、在编排层做动作批处理或提前规划"来控制成本与延迟。
5 规划与推理：2025 Agent的核心算法栈
5.1 ReAct范式：推理痕迹与行动交织
2025年通用Agent的规划范式中，ReAct几乎是绕不开的基石之一。ReAct提出将"推理（Reasoning）"与"行动（Acting）"在同一条轨迹中交错：模型一边以自然语言进行逐步推理，一边调用工具获取新的信息，随后在新信息基础上继续推理与行动。其价值不只在于"能调用工具"，而在于把工具调用纳入推理链条，使得模型能够显式地表达"为什么需要调用某个工具、期待得到什么信息、得到信息后如何更新计划"。这正是Agent loop在工程上能稳定运行的原因之一：模型不再把工具当作外部黑箱，而是把工具结果当作推理中的证据。
在实际架构中，ReAct式轨迹往往会被编排层结构化：例如把"想法/行动/观察"分成不同字段或不同消息类型，把"行动"限定为tool call，把"观察"限定为tool result，把"想法"在需要时以推理摘要形式返回给开发者用于调试。OpenAI在Responses API更新中引入"reasoning summaries"，正是把这种"可解释的中间层"产品化的一种方式：开发者不必直接看到完整chain-of-thought，但可以得到可读的摘要来理解Agent为什么这样走。
5.2 Toolformer：让模型学会"何时用工具"的数据路径
如果说ReAct强调的是"推理与行动如何交错"，那么Toolformer关注的是"模型如何学会在合适的地方插入工具调用"。Toolformer提出一种自监督式方法：模型在文本中插入API调用、执行API获得结果，然后用结果增强文本并评估其对语言建模损失的改善，从而筛选出高价值的工具调用样本用于训练。其核心意义在于把"工具使用"从纯提示工程推进到"可学习的能力"，让模型不仅会格式化调用，还能在语义上判断调用是否值得。
对2025通用Agent架构而言，这类思想的影响是深远的：它促使我们把"工具使用能力"分成两部分，一部分是模型内化的策略（何时调用、调用什么、如何解释结果），另一部分是编排层提供的安全与结构（schema校验、权限门控、失败处理）。Agents SDK的function tools强调自动schema生成与验证，而Toolformer式训练则为"生成更靠谱的调用意图"提供了数据基础，这两者一内一外共同构成了工具调用可靠性的支柱。
5.3 Reflexion：把失败经验写回策略的迭代机制
在多步任务中，失败往往不是"模型不懂"，而是"模型在某一步做了不合适的假设或行动"。Reflexion提出通过语言形式的反思来进行"口头强化学习"：Agent在任务失败后生成对失败原因的反思，并把反思作为记忆写入下一次尝试，从而提升后续成功率。 这类机制对通用Agent架构的启示是：记忆不应只是事实缓存，也可以是策略层的"失败模式库"，例如"某网站按钮经常被误识别，需要先放大缩小再点击""某类搜索结果容易出现SEO垃圾，需要加域名过滤"等。
不过，把Reflexion思路落地到2025的生产Agent时，必须与安全与隐私约束结合。ChatGPT agent系统卡提到"记忆被禁用"作为风险缓解手段之一，意味着在某些产品形态里，直接把反思写入长期记忆可能不被允许。 因此工程上的折中通常是"短期反思、任务级反思、或匿名化反思"：只在单次任务会话内保留反思；或把反思写成不包含敏感数据的抽象规则；或把反思交给开发者端的策略库而不是写回用户侧记忆。这样既能利用反思的迭代优势，又能控制风险面。
5.4 Voyager：技能库、自动课程与"可迁移的工具链"
Voyager展示了另一种更接近"长期成长"的Agent路线：在Minecraft环境中，Agent通过LLM驱动的规划与代码生成，不断探索、学习新技能，并把技能以可复用代码的形式写入技能库，同时自动生成新的探索目标形成课程。 虽然这类工作常被讨论为"未来应用"，但从架构角度看，它提供了一个非常实用的启示：当任务空间足够大时，Agent必须具备"把一次性轨迹压缩成可复用模块"的机制，否则每次都从零开始，成本与失败率都会难以接受。
把Voyager思想映射到2025的通用ChatGPT Agent架构里，这个"技能库"往往会以三种形态出现：第一种是工具封装层，把常用动作序列封装成高层工具（例如"登录并下载报表"作为一个函数工具）；第二种是子Agent，把某类任务交给专门Agent并通过handoff或agents-as-tools调用；第三种是工作流模板，在Agent Builder中沉淀成可复用的节点图并版本化发布。Agent Builder支持从模板开始、拖拽节点、预览与版本化发布，这为"技能沉淀"提供了平台级承载。
5.5 规划的工程化折中：局部最优、可解释与可恢复
理论上你可以追求更全局的规划（例如把整个任务当作长程规划问题），但2025的生产经验往往更偏向"局部可解释、可恢复"的策略：把任务拆成若干可验证的里程碑，每一步都能产出可检查的中间结果，并在失败时能退回上一步重试。其原因很现实：工具调用成本存在、环境不确定性存在、模型成功率远非100%、而且安全门控要求在关键步骤停下来让用户确认。于是，架构上常见的折中是"计划---执行---校验"的循环，而不是"一次性全局计划再盲目执行"。这也解释了为什么Agent Builder强调typed edge、preview与inline eval，以及为什么Agents SDK强调tracing与guardrails：它们都是为"可恢复、可调试"的局部循环服务的。
6 记忆与知识：从短期上下文到长期外部化
6.1 会话记忆与长期记忆：生产系统更偏好"外部化"
在LLM Agent系统里，"记忆"常被误解为"把更多历史塞进上下文"。但2025年通用Agent的实践显示，真正稳定的方案往往是把长期记忆外部化：事实与文档进向量库，过程与轨迹进tracing系统，偏好与权限进产品配置或数据库，模型上下文只保留任务当前必需的信息。Agents SDK把sessions作为自动维护历史的机制，解决的是"会话内状态一致性"；而长期记忆则更适合用file search、vector store与外部数据库来承载。
ChatGPT agent系统卡提到"记忆被禁用"，从另一个侧面强化了外部化趋势：当Agent能访问连接器与多工具时，把敏感信息写入持久记忆会增加被攻击或误用的风险，尤其是prompt injection可能诱导Agent从记忆中泄露敏感数据。 因此生产架构更倾向于把"能否记住"从模型能力问题转化为"数据治理问题"：哪些信息可存、存在哪里、谁能读、何时过期、如何审计。
6.2 外部记忆的三件套：向量库、引用与可追溯证据
外部化记忆要真正发挥作用，至少需要三件套：第一是向量库/检索工具，保证"存进去能找出来"；第二是引用/证据机制，保证"找出来能被正确使用并可追溯"；第三是评测与监控，保证"长期使用不会逐渐偏离或被污染"。在OpenAI平台中，file search与web search分别覆盖内部知识与外部知识，且web search天然带引用注释要求；Responses API更新也强调了这些工具的可用性与企业级特性。
很多团队在落地时会发现：检索召回"相关"并不等于"可信"。因此引用机制与评测机制必须配套：引用让开发者与用户看到证据来源，评测让系统持续校正"引用是否真的支持结论"。这与ChatGPT agent系统卡中对幻觉评测的讨论相呼应：当Agent具备浏览能力时，它可能因为更"谨慎且深入"而在某些评分体系下得分更低（例如对评分基准本身提出质疑），这提醒我们评测指标与证据体系要一起设计。
6.3 记忆写入的安全边界：PII、越狱与数据泄露
通用Agent一旦开始"写记忆"，你就必须假设攻击者会尝试诱导它读出记忆或把记忆写成恶意指令。prompt injection风险在Agent场景被放大，因为Agent会主动访问网页、文件、连接器等外部内容，这些内容可能携带攻击指令。ChatGPT agent系统卡把prompt injection列为重点风险，并在风险缓解摘要中列出多层缓解策略，包括自动监控与过滤、用户确认、敏感上下文的watch mode、终端网络限制以及关闭记忆等。 这些措施共同指向一个原则：记忆与外部上下文不是"越多越好"，而是必须在安全边界内可控增长。
7 多Agent与工作流编排：从"一个大脑"到"团队协作"
7.1 Handoffs：委派机制与角色分工
多Agent并不是为了"看起来更智能"，而是为了解决两个结构性问题：第一是上下文与能力的分割，把不同领域的指令、工具与知识隔离，降低提示词互相污染；第二是控制流的可解释性，让系统能够明确记录"是谁做了哪一步决策"。Agents SDK把handoffs作为核心原语之一，并解释其用于让一个Agent把任务委派给另一个Agent，适合不同Agent分别处理订单、退款、FAQ等不同职责。
从架构角度看，handoff是一个天然的"审计点"：你可以在handoff前后插入安全检查、权限确认、或成本预算判断；你也可以在handoff时把输入输出结构化，避免把所有上下文无差别传给下游Agent。更进一步，handoff也可以与"agents as tools"结合：当你不希望完全转移控制权，而只是希望某个子Agent提供局部能力时，把子Agent当成工具调用会更合适。Agents SDK工具指南明确支持"Agents as tools"，并解释其底层会创建一个带单一input参数的function tool，调用时运行子Agent并返回其输出。
7.2 Agents as Tools：子Agent工具化的工程意义
"把子Agent当工具"本质上是在架构上引入一种可组合的函数式接口：主Agent不必知道子Agent的全部提示词与工具细节，只需要知道"调用它能得到某种结构化产出"。这种设计在2025年很常见，因为它兼顾了模块化与控制权：主Agent仍掌握主循环，子Agent只在被调用时运行。对于复杂任务，这有助于把系统拆成可测试的小模块，并用独立eval与grader分别评估每个模块的质量。
在实践中，agents-as-tools还有一个常被忽视的优势：它天然适配"typed edge"和"schema验证"。当子Agent工具被包装成带参数与输出格式的工具时，编排层就可以像对待普通函数工具一样做参数校验与错误处理。相比之下，如果你只是把子Agent当作"另一个聊天窗口"，则容易陷入上下文漂移与格式不稳定的问题。Agent Builder的节点化编排也在推动这种模式：节点之间的数据契约越明确，工作流越稳定。
7.3 Agent Builder：节点化编排、版本化发布与可调试运行
2025年Agent Builder把"工作流"概念平台化：你在画布里拖拽节点、连接节点、为每一步配置输入输出与工具，并可用Preview进行实时运行测试，最终发布为带ID与版本的工作流对象，然后在产品里部署。官方文档强调其三步流程：设计工作流、发布工作流（获得ID与版本化对象）、部署工作流（通过ChatKit或下载SDK代码自建）。 这种"版本化"对于生产系统极其关键：它允许你锁定某次上线的工作流形态，进行回溯与对照实验，也允许你在发现问题时快速回滚到旧版本。
图3：工具调用与多Agent委派的时序图
7.4 ChatKit：托管后端与自托管后端的两种部署形态
Agent系统的强调点往往在后端，但2025年的平台化趋势让"前端部署形态"也成为架构的一部分。ChatKit文档把它定位为构建agentic chat体验的最佳方式之一，强调其提供可嵌入UI组件、工具调用可视化、文件附件、以及chain-of-thought可视化等能力，并给出两种实现方式：推荐方式是前端嵌入ChatKit并让OpenAI托管并扩展Agent Builder构建的后端；高级方式是你在自有基础设施上运行ChatKit并连接任意agentic后端。
表3 ChatKit托管后端 vs 自托管后端
| 维度 | OpenAI托管后端（Agent Builder工作流） | 自托管后端（自建Agents SDK或其他编排） |
|---|---|---|
| 适用场景 | 最快上线、减少基础设施运维 | 最大控制权、定制工作流与数据路径 |
| 聊天服务端运行者 | OpenAI | 你 |
| 消息与附件存储 | OpenAI | 你 |
| 推理流水线 | Agent Builder发布的workflow | Agents SDK或自研 |
| 认证方式 | 你先完成认证，再铸造短时client secret | 你可自定义fetch注入认证头等机制 |
| UI定制/附件/历史/小组件 | 支持 | 支持 |
| 额外能力（如Composer、响应取消等） | 文档列出差异项 | 取决于你实现与集成 |
这张表的意义在于，它把"Agent是产品"这个事实拉到台前：你不只是在调一个模型接口，而是在建设一个带会话、权限、数据存储、UI与审计能力的应用。对于企业场景，选择托管还是自托管，往往取决于数据治理与合规要求；而对于个人或中小团队，托管后端能显著降低从原型到上线的摩擦。OpenAI在AgentKit发布中也强调Agent Builder、Connector Registry与ChatKit等组件的组合，目的是减少碎片化工具带来的复杂度。
8 可观测性与评测：从"能跑"到"可衡量"
8.1 Tracing与Trace Grading：把每一步变成可审计事件
当Agent系统开始做多步执行，你很快会遇到一个现实问题：它失败时，你不知道到底是哪一步出错；它成功时，你也不知道为什么成功。这就是可观测性的价值。Agents SDK把tracing作为内建能力，强调可视化与调试agentic flows，并可用于评估与模型优化。 更进一步，Agent Builder文档提到可以在Agent Builder内部运行trace graders进行工作流评测，把评测与调试集成到同一个界面里。
这种设计在架构上意味着：Agent的"中间态"必须被结构化记录，包括每次工具调用参数、工具返回值摘要、guardrails判定结果、用户确认点、以及最终输出与引用。只有当这些事件能被串成可视化的trace，才可能做系统性优化，例如定位某类失败集中发生在"检索召回不足"还是"GUI误点"，或发现某个guardrail过于严格导致过度拒答等。ChatGPT agent系统卡中的评测讨论就提供了一个典型例子：在某些评测中出现"错误的拒答"会被计为错误，从而影响准确率，这种现象如果没有trace很难定位其触发条件。
8.2 学术基准：WebArena、VisualWebArena、OSWorld、GAIA等
通用Agent的评测越来越强调"交互环境"而不是静态问答。WebArena提供一个更真实的网页环境，用于评估自主Web代理的能力，包含812个任务。 VisualWebArena进一步面向多模态网页任务，包含910个视觉复杂的web任务。 OSWorld面向操作系统层面的真实桌面环境任务，包含369个真实计算机任务，并报告当时最强模型在完整任务上的成功率约12.24%。 GAIA（General AI Assistants）强调现实世界助手任务的综合能力，包含466个问题，并在论文中报告在不受限设置下最佳模型可达92%成功率，而"GPT-4 with plugins"约15%。 这些基准共同推动了2025年Agent架构向"可交互环境闭环"演进：不仅要会推理，还要会行动与纠错。
表4 代表性Agent评测基准的规模与特点（真实数据汇总）
| 基准 | 环境类型 | 任务/问题数量（论文披露） | 核心评估点 | 典型观测/行动 |
|---|---|---|---|---|
| WebArena | 真实Web环境 | 812 | 多步网页导航与信息获取 | DOM/文本；点击/输入/导航 |
| VisualWebArena | 多模态Web环境 | 910 | 视觉界面理解与网页操作 | 截图+结构；点击/输入/滚动 |
| OSWorld | 操作系统桌面环境 | 369 | OS级任务自动化与鲁棒性 | 截图/窗口状态；鼠标键盘操作 |
| GAIA | 现实世界助手任务 | 466 | 跨域推理、检索、工具使用 | 文本+外部工具；多步推理 |
图4：基准规模对比柱状图
这些基准的共同点是"任务链路长、环境噪声大、失败模式多"，因此也更能暴露Agent系统工程问题。例如OSWorld论文指出最强模型在完整任务上的成功率只有12.24%，这意味着"失败是常态"，必须设计重试与恢复。 而OpenAI的computer use文档给出的38.1% OSWorld表现，则体现了专门化模型与工程优化带来的提升空间，但也同样提醒我们距离"可无人值守执行OS任务"仍有明显差距。
8.3 用真实数据理解"可靠性"：幻觉、语言覆盖与偏差
学术基准主要衡量任务成功率，但生产级Agent还必须面对安全、幻觉、语言覆盖与公平性等指标。ChatGPT agent系统卡在这方面提供了大量可量化数据，例如在生产安全基准（Production Benchmarks）中，用not_unsafe作为指标，分别在非暴力仇恨、隐私、威胁骚扰、性/非法内容、未成年人性内容、极端主义、自伤等类别给出ChatGPT agent与OpenAI o3的对比。
表5 生产安全基准：not_unsafe指标对比
| 类别 | 指标 | ChatGPT agent | OpenAI o3 |
|---|---|---|---|
| 非暴力仇恨 | not_unsafe | 0.926 | 0.840 |
| 个人数据（所有隐私类别） | not_unsafe | 0.932 | 0.925 |
| 骚扰/威胁 | not_unsafe | 0.803 | 0.672 |
| 性/非法 | not_unsafe | 0.891 | 0.833 |
| 未成年人性内容 | not_unsafe | 0.854 | 0.779 |
| 极端主义 | not_unsafe | 0.989 | 0.920 |
| 仇恨/威胁 | not_unsafe | 0.891 | 0.746 |
| 非暴力非法 | not_unsafe | 0.826 | 0.739 |
| 暴力非法 | not_unsafe | 0.933 | 0.838 |
| 自伤意图 | not_unsafe | 0.908 | 0.866 |
| 自伤指令 | not_unsafe | 0.947 | 0.894 |
图5：生产安全基准雷达图
在幻觉方面，系统卡用SimpleQA与PersonQA给出准确率与幻觉率的对比，并指出由于ChatGPT agent总能浏览互联网，因此比较对象是"启用浏览的o3"。
表6 幻觉评测：准确率与幻觉率
| 评测 | 指标 | ChatGPT agent | OpenAI o3（启用浏览） |
|---|---|---|---|
| SimpleQA | 准确率（越高越好） | 0.914 | 0.954 |
| SimpleQA | 幻觉率（越低越好） | 0.079 | 0.046 |
| PersonQA | 准确率（越高越好） | 0.943 | 0.966 |
| PersonQA | 幻觉率（越低越好） | 0.043 | 0.024 |
在多语言覆盖方面，系统卡给出ChatGPT agent与deep research在多种语言上的通过率/准确率数据，这些数据非常适合用来讨论"多语言下性能退化是否显著"以及"工具增强是否影响语言差异"。
表7 多语言表现
| 语言 | ChatGPT agent | Deep research |
|---|---|---|
| English | 0.572 | 0.580 |
| Arabic | 0.568 | 0.550 |
| Bengali | 0.567 | 0.547 |
| Chinese | 0.575 | 0.545 |
| French | 0.579 | 0.566 |
| German | 0.590 | 0.585 |
| Hindi | 0.581 | 0.582 |
| Indonesian | 0.585 | 0.564 |
| Italian | 0.588 | 0.554 |
| Japanese | 0.566 | 0.556 |
| Korean | 0.560 | 0.566 |
| Portuguese | 0.588 | 0.575 |
| Russian | 0.599 | 0.542 |
| Spanish | 0.575 | 0.583 |
| Swahili | 0.578 | 0.550 |
| Turkish | 0.564 | 0.546 |
| Vietnamese | 0.584 | 0.571 |
| Yoruba | 0.473 | 0.426 |
图6：多语言表现折线图
这些真实数据对"通用Agent架构"的意义在于，它们把架构讨论从抽象概念拉回可量化指标：你不仅要设计工具系统与工作流，还要能用指标解释"为什么某次迭代更安全、更少幻觉、更公平、更能覆盖多语言"，并且能通过trace把变化定位到具体节点或具体工具调用策略上。
9 安全、权限与抗攻击：Agent能力放大后的系统工程
9.1 Prompt Injection：从文本攻击到工具劫持
Prompt injection在Agent时代的破坏力远超过传统聊天：攻击不再只是诱导模型"说错话"，而可能诱导模型"做错事"。当Agent会浏览网页、读取文件、连接企业系统时，网页内容或文件内容中嵌入的恶意指令可能试图覆盖系统目标，导致数据外泄、误操作或错误结论。ChatGPT agent系统卡明确把prompt injection作为重点风险，并指出其影响可能更高，因为Agent可同时访问更多工具。 这也是为什么通用Agent架构必须把"输入可信度"当成系统级问题，而不是只靠模型"更聪明"来解决。
在架构上，prompt injection防护通常分成三层：第一层是模型层的安全训练与对抗鲁棒性；第二层是编排层的自动监控与过滤、对敏感工具调用做门控；第三层是产品层的用户确认与可视化监督。系统卡的风险缓解摘要恰好覆盖了这三层，并且提到在敏感上下文下启用"watch mode"，以及对终端工具实施网络限制。 这为"通用Agent架构"提供了一个非常清晰的安全设计模板：你必须假设模型会被诱导，因此要在系统里预留"强制中断与人工介入"的机制。
9.2 用户确认与watch mode：把高风险动作变成"可逆决策"
在GUI操作、连接器访问、或任何可能造成不可逆后果的动作前，用户确认是最简单也最有效的风险缓解方式之一。其价值在于把"不可逆动作"变成"可逆决策"：模型可以提出行动计划，但最终执行权交给用户确认。系统卡把用户确认与watch mode列为prompt injection缓解的重要组成部分，同时也用于防止Agent犯错或在该确认时未确认。 在架构上，这意味着Agent loop必须支持"暂停---等待确认---恢复"的状态机，不能把执行当成一条不可打断的流水线。
9.3 终端网络限制、加密推理项与企业隐私
当Agent拥有终端/代码环境时，风险面进一步扩大：终端可能访问网络、读取本地文件、暴露环境变量，甚至被用来执行非预期操作。系统卡提到"终端网络限制"作为风险缓解措施之一。 同时Responses API更新引入"加密推理项"，并说明符合零数据保留（ZDR）的客户可以在不把推理项存储在OpenAI服务器的情况下复用推理项，从而提升智能并减少成本与延迟。 这类能力背后的架构意义是：企业级Agent不仅要"能做事"，还要在数据治理上提供可配置的隐私边界，并支持在隐私约束下仍能获得足够的推理连续性。
9.4 安全评测：从越狱到指令层级
安全不是口号，而需要评测。系统卡在越狱鲁棒性方面给出了StrongReject评测对比，并显示ChatGPT agent与o3在多类越狱提示上的not_unsafe都接近1.0。 同时还评估了"指令层级"相关能力，例如系统与用户消息冲突下是否能坚持系统指令、是否会泄露系统提示等。 这些评测直接对应到通用Agent架构中的"指令治理"层：你需要明确系统/开发者/用户/工具输出的优先级，并用机制防止网页内容等外部输入越权。
10 成本、延迟与资源治理：把"智能"落在可运营的约束里
10.1 Token成本、工具成本与计费模型
通用Agent的成本模型比传统聊天复杂得多：不仅有模型token成本，还有工具调用成本、向量存储成本、代码沙盒容器成本等。Responses API更新给出了多项工具成本：code interpreter 0.03/容器，file search 0.10/GB/天 + 2.50/1000次工具调用，图像生成按token与图像token计费，并指出调用远程MCP server工具本身无额外费用（主要计输出token）。 computer-use-preview模型页则给出其token价格（输入3、输出$12/百万token）。
表8 2025年OpenAI通用Agent常见成本项
| 成本项 | 计费方式（文档披露） | 典型影响 | 架构应对方向 |
|---|---|---|---|
| computer-use-preview | 3/12（每百万token输入/输出） | 多轮截图交互成本高 | 降低无效循环、压缩观测、拆分任务 |
| Code Interpreter | $0.03/容器 | 频繁开容器会累积 | 复用容器、把计算集中处理 |
| File search | 0.10/GB/天（存储） + 2.50/1000次调用 | 大规模知识库持续成本 | 分层存储、冷热分离、缓存召回 |
| Image generation（工具） | 文档给出按token/图像token计费 | 生成与编辑成本差异大 | 只在必要时调用、控制分辨率与轮次 |
| 远程MCP server工具 | 无额外工具费（主要计输出token） | 连接外部系统更便利 | 工具输出结构化、减少冗余返回 |
成本治理与架构设计高度耦合：如果你的Agent loop没有"预算意识"，系统就会在不知不觉中产生大量工具调用与token消耗。Responses API更新提到推理模型在工具调用中保留推理token可以降低成本与延迟，这实际上是在平台层面提供一种"跨步推理缓存"，使得多步工具链不必每次从零开始推理。
10.2 背景模式：长任务的可靠执行方式
通用Agent最典型的失败不是"答错"，而是"超时"或"中途断线"。OpenAI在Responses API更新中引入background mode，明确其适用于推理模型需要数分钟才能完成的复杂任务，并允许开发者异步执行、轮询或流式追踪进度。 这对架构的意义是：Agent系统需要支持"可中断、可续跑"的任务对象，并把中间状态写入可持久化的会话/工作流状态，而不是仅靠一次HTTP请求完成全部任务。
11 2025生态与标准化：MCP、连接器与"可组合工具链"
11.1 MCP：上下文与工具接入的标准化接口
当Agent要连接越来越多的外部系统时，如果每个系统都用私有协议，生态就会碎片化。Responses API更新明确宣布支持所有远程MCP服务器，并把MCP描述为"标准化应用向LLM提供上下文的开放协议"；同时表示OpenAI加入MCP的steering committee。 这意味着2025年的通用Agent架构正在走向"工具即接口、接口即生态"：开发者不必为每个SaaS写一套定制function schema，而可以通过MCP服务器统一暴露工具能力，并在Agent编排层以一致方式调用。
从架构角度看，MCP的价值在于把"工具定义、权限、上下文注入"从应用内代码迁移到一个可治理的中间层：企业可以用Connector Registry统一管理哪些数据源能被Agent访问，管理员可以集中控制连接器与第三方MCP的接入策略。AgentKit发布文档提到Connector Registry作为中央管理面板，覆盖ChatGPT与API，并包含Dropbox、Google Drive、SharePoint、Microsoft Teams以及第三方MCP等。
11.2 AgentKit：从SDK到可视化平台的闭环
2025年10月OpenAI发布AgentKit，将Agent Builder、Connector Registry与ChatKit组合成"构建---部署---优化"的完整工具链，并强调它是为了解决过去构建Agent需要编排、连接器、手工评测与前端开发等碎片化问题。 平台文档也把AgentKit定义为模块化工具包，覆盖构建、部署与优化，强调评测、trace grading、prompt optimizer等能力。 对通用Agent架构而言，这意味着最佳实践正在平台化：不只是给你一个模型，而是给你一套从工作流设计到上线运维的基础设施。
图7：Agent Builder工作流与Trace/Grader闭环示意图
12 结语：通用Agent架构的稳定内核
回看2025年的通用ChatGPT Agent架构，不难发现其"稳定内核"并不神秘：它是一套把LLM从语言生成器升级为决策器的系统工程方法。底层是可交互环境与工具集合，中间是显式编排与状态管理，上层是可观测、可评测、可治理的产品化闭环。工具调用让Agent获得行动能力，工作流图让复杂控制流显式化，可观测与评测让系统具备持续优化的可能，而安全与权限机制则为能力放大设置了必要的边界。OpenAI在2025年一系列文档与系统卡中给出的数据与机制（如生产安全基准、幻觉评测、多语言表现、prompt injection缓解、后台模式、加密推理项、MCP支持等）共同勾勒出一个清晰方向：通用Agent的竞争，不再只是"模型更强"，而是"系统更稳、更可控、更可运营"。
参考资料（精选）
-
OpenAI. ChatGPT agent System Card（2025-07-17）.
-
OpenAI. New tools and features in the Responses API（2025-05-21）.
-
OpenAI. OpenAI Agents SDK（Python）文档：核心原语与内建agent loop/tracing.
-
OpenAI. Agents SDK Tools（JS/TS）文档：工具四分类与托管工具清单.
-
OpenAI. Web search tool guide：非推理检索/agentic search/deep research三种模式与引用机制.
-
OpenAI. Computer use tool guide：循环执行机制与安全建议，OSWorld表现提示.
-
OpenAI. computer-use-preview model page：价格、上下文窗口、snapshot版本信息.
-
OpenAI. Introducing AgentKit（2025-10-06）.
-
OpenAI. Agents / Agent Builder / ChatKit 平台文档（工作流、部署与优化）.
-
Yao et al. ReAct: Synergizing Reasoning and Acting in Language Models（arXiv, 2022）.
-
Schick et al. Toolformer: Language Models Can Teach Themselves to Use Tools（arXiv, 2023）.
-
Shinn et al. Reflexion: Language Agents with Verbal Reinforcement Learning（arXiv, 2023）.
-
Park et al. Generative Agents: Interactive Simulacra of Human Behavior（arXiv, 2023）.
-
Wang et al. Voyager: An Open-Ended Embodied Agent with Large Language Models（arXiv, 2023）.
-
WebArena: A Realistic Web Environment for Building Autonomous Agents（任务812，arXiv）.
-
VisualWebArena: Evaluating Multimodal Agents on Realistic Visual Web Tasks（任务910，arXiv/项目页）.
-
OSWorld: Benchmarking Multimodal Agents for Open-Ended Tasks in Real Computer Environments（任务369，最佳模型成功率12.24%等，arXiv）.
-
GAIA: a benchmark for General AI Assistants（问题466，成功率对比等，arXiv）.
-
AgentBench: Evaluating LLMs as Agents（arXiv）.
-
StableToolBench: Towards Stable Large-Scale Benchmarking on Tool Learning（Findings of ACL 2024）.
-
Tool Learning with Large Language Models: A Survey（arXiv, 2024）.