openai agents ai-economics llm observability

OpenAI的智能体API如何改变人工智能工作的经济模式

智能体会依次执行捆绑模型、工具调用、沙箱测试、重试以及人工审核等操作，因此令牌数量已无法反映成本，应改为衡量已完成的任务数量。

发布者：REACTAPP.TOP加入本站 2026年10月23日阅读约 9 分钟2004 词

来源: OpenAI’s Agents API Changes the Economics of AI Work

OpenAI的Agents API旨在让云端智能体在长时间会话中持续运行，它配备了工具、沙箱、文件处理功能、上下文管理能力以及可并行工作的子智能体。一个智能体可以分析问题、运行代码、将任务分配给其他智能体、保存中间结果，并持续工作直至任务完成。

这不仅改变了开发者构建智能体的方式，也改变了企业计算成本的方式。

现在，一个请求就能触发一系列模型处理、工具调用、沙箱操作、重试、结果存储以及人工审批流程。虽然账单上仍会显示代币数，但它已无法反映实际工作成本。真正值得追踪的单元是已完成的任务：它必须是正确的、可恢复的、可审计的，并且其价值应等同于完成它所付出的成本。

请求不再是工作单元

普通的模型调用流程十分清晰：应用程序发送输入，模型返回输出，之后应用程序便继续正常运行。

Agents API则是为另一种运行方式设计的。智能体接收任务目标后自行决定执行方案。比如，你可以要求它调查5xx错误率上升的问题：

查明为何在过去的30分钟内service-api的错误率出现异常上升，并提出安全的解决方案。

传统的助手只会描述工程师可能会如何调查，而接入相应系统的智能体则可以直接开始行动。它会检查最近的部署记录、查询应用程序日志、对比依赖项版本、查看基础设施指标、分配不同的分析任务、运行诊断代码、保存相关证据，且在做出任何更改之前等待批准。

用户只能看到一个请求，但实际上系统已经执行了完整的流程。

OpenAI关于构建智能体的实用指南将这一过程称为“运行”：即一个循环，会持续到智能体完成任务、生成最终输出、遇到错误或达到预设限制为止。成本就在这个循环中不断累积。

运行过程存在隐藏费用

代币是费用的一部分，只不过是最容易看到的那一部分而已。

再回到生产故障的问题。首先智能体会从监控工具中获取最近的错误率，接着读取部署历史记录，最后搜索日志。每一次这样的操作都有相应的成本、延迟、权限要求以及可能出错的方式。

随后，日志工具会返回500条记录。这听起来似乎很有用，但接下来发生的情况就未必如此了。这些记录需要被移动、处理并放入模型的上下文中。其中大部分都是无关信息，模型不得不花费时间去处理这些冗余数据，才能找到能够解释该事件的5个关键事件。

因此，工具的设计实际上就是成本的设计。一个能够返回简洁结构化摘要的搜索工具，往往比那些展示所有匹配记录的工具更便宜且更可靠。API的解决方案是结合工具搜索与程序化调用方式，这样只有在需要时才会显示工具定义，并在结果传送到模型之前对其进行过滤或整合。

沙箱执行也遵循同样的逻辑。诊断脚本会消耗CPU、内存、存储空间、软件包安装时间，甚至还可能占用网络资源。如果它生成了报告或证据集，这些输出内容就必须被存储、索引、审查或保留。

长时间运行的代理程序产生的不仅仅是文本。在调查事件时，用于诊断的证据往往比书面总结更为重要。在编程工作中，补丁只是输出内容的一部分，而测试结果和依赖关系分析同样具有很高的价值。

一个简短的Agents SDK示例展示了执行边界的位置：

from agents import Agent, Runner, function_tool
@function_tool
def get_error_rate(service: str, minutes: int = 30) -> str:
    """Return the recent error rate for a service."""
    return f"{service}: 8.4% errors over {minutes} minutes"
investigator = Agent(
    name="Incident investigator",
    instructions=(
        "Investigate the incident, use evidence, and recommend "
        "the safest next action. Do not change production state."
    ),
    tools=[get_error_rate],
)
result = Runner.run_sync(
    investigator,
    "Investigate the elevated 5xx rate in service-api."
)

这个函数本身很简单，但其背后的经济成本却不容忽视。这一切都由代理决定：它是否会被调用、是否会被再次调用、其结果如何被读取，以及是否需要其他工具或人工审批。

可靠性、可控性与可接受度决定成败

SDK提供了该流程背后的运行时组件：代理、执行器、工具、数据传递机制、会话管理、约束规则以及追踪功能。这些组件非常重要，因为实际的工作流程很少能一次就顺利完成。

日志查询可能会超时，因此代理会重新尝试。第二次查询虽然成功，但返回的数据并不完整。它会重新编写查询语句，获取更大的数据集，并请专门的代理来检查部署历史。最终，调查会取得成功。

对用户而言，代理似乎已经完成了任务。但从经济成本的角度来看，这项任务实际上还包含了失败的尝试、额外的模型处理步骤、更多的工具调用以及更长的耗时。

重试并不一定是浪费。那些能够从短暂故障中恢复的重试，恰恰可能是让智能体具备可靠性的关键。问题在于将这些重试合并到同一个总体成功指标中。

并行智能体以时间为代价换取效率

API可以将复杂任务分配给并行运行的子智能体处理。在事故调查中，一名专家负责获取部署历史，另一名专家负责分析应用程序错误，还有一名专家负责查看依赖关系变化，随后由协调者整合这些信息。

由于所有任务同时进行，实际耗时可能会减少。但总成本却可能上升，因为现在需要为多个独立的模型上下文、多条工具调用链、协调工作、综合处理步骤，甚至可能重复处理的相同内容付费。

正因如此，多智能体系统看起来就像是在循环中使用语言模型的分布式系统。协调器充当调度器，各专业智能体则是工作者，外部工具则相当于服务，而文件和数据库则成为共享状态。随之而来的问题是：部分故障、重试、状态不一致、重复工作、并发限制以及难以明确的成本归属问题。智能体数量增多并不必然意味着更好的推理能力。并行处理的价值应取决于任务的架构以及时间成本的高低。

验收才是终点线

生成过程可能在实际工作完成之前就结束了。对于支持案例而言，这意味着客户的問題已得到解决，且无需进一步升级处理。对于编码任务，这意味着测试通过、符合审查标准且更改已被合并。在事件响应中，这意味着诊断结果有证据支撑，并由此采取了安全的缓解措施。由此得出的指标为：

cost per accepted task =
    total execution cost / tasks accepted without rework

如果客服在十秒内回复，但随后需要人工花费十分钟来解决问题，那么这十秒的回复并非真正的低成本解决方案，只不过是一次低成本的尝试而已。

让人工对结果进行审核并不意味着自动化失败。对于高风险工作，只有经过人工确认，自动化处理才有可能被接受。理想的情况是尽可能减少人工干预，同时仍保持真正的人工控制。

该 SDK 提供了输入、输出及工具层面的约束机制，其文档将智能体层面的检查与工具层面的检查分开说明：涉及委托专业人员的配置可能需要对单个功能工具及 MCP 操作进行额外检查。这些约束机制虽然需要投入精力，有时还会增加模型调用次数，但能够避免因错误操作、数据泄露、政策违反或监管问题而带来的更大损失。只有经过质量检查并经过适当程度的人工干预后，输出内容才能被视为已完成的任务。

从追踪数据到业务价值

每一种新工具都会扩展智能体的功能范围，同时也会增加系统的权限要求、延迟、故障模式以及治理需求。

该 API 支持自定义函数、内置工具以及 MCP 服务器。MCP 规范了人工智能应用与外部工具、资源及提示语的连接方式，从而降低了集成难度，但并不会默认使远程工具具备可信性。MCP 规范警告称，不应自动信任来自不可信服务器的工具描述与注释，并建议对工具调用进行可视化处理，同时由人工对操作进行审批。远程授权还会带来诸多额外问题，比如验证令牌的权限范围、安全存储令牌、使用 PKCE 机制以及防范混淆代理攻击等。每增加一项功能，都会带来新的授权、审计和治理需求。

追踪数据属于会计数据

最终结果几乎未透露其得出过程。你无法知道考虑了哪些工具、运行了多少次、是否有子任务出错，或是何种因素促使某人介入。

SDK提供了涵盖多代处理、工具调用、任务交接、约束规则及自定义事件的追踪功能。追踪功能通常被用作调试辅助工具，但实际上也是一种统计系统。通过追踪可以发现是某个工具导致了大部分延迟，某个工作流一直在重复相同的搜索，或者某种模型选择能在更少的重试次数下获得更高的接受度。没有追踪功能时，团队只能优化整体平均值；有了追踪功能后，他们就能针对每个工作流阶段进行优化。

绩效看板应将执行数据与结果数据结合展示：每项已完成任务的成本，以及所使用的模型迭代次数和工具调用次数、在沙箱中的运行时间、重试频率与恢复频率，还有返工量、审核所需时间、升级处理情况以及最终创造的价值。具体的仪表板设计取决于工作流程。支持团队可能关注无需升级即可解决的案例，平台团队可能关注已缓解的故障，产品团队则可能关注保障的收入或节省的员工时间。变化之处在于用于分母的指标。

战略决策

组织不应一开始就考虑如何降低每次通话的代理成本。更重要的问题应优先考虑：

该代理能否足够可靠地处理这类工作，使其总成本低于现有流程的成本？

为此，你需要为当前流程建立一个真实的基准，涵盖员工工作时间、排队等待时间、反复交接的次数、基础设施成本、错误及其返工成本、错失的机会以及合规成本。当现有流程的成本为20美元时，每完成一项任务仅需2美元的代理显然是一笔极佳的投资；而如果每次尝试的成本仅为0.10美元，但只有半数输出结果能被接受，且每次失败都需要人工修复，那这种代理则属于糟糕的选择。

一个合理的优化计划应从最简单的能够完成任务的系统开始。对于路由、过滤或简单验证等任务，可使用较小的模型；当需要更复杂的推理时，再逐步升级到更强大的模型。要让工具返回简洁、结构化的结果，仅对独立的工作进行并行处理，同时要对后续操作进行验证，并保留足够的证据以便后续审查和问题修复。

当运行时本身需要处理轮次、工具、会话、交接、约束规则或智能体之间的协调时，SDK才能发挥价值。而当团队希望自行掌控循环处理和状态管理时，Responses API更为合适。这一选择既关乎架构设计，也涉及成本问题。

衡量工作量，而非文字数量

Agents API使得构建能够在不同工具、环境、会话及子智能体之间运行的智能体变得更加容易，而SDK则提供了应用层的基本功能，用于协调这些智能体、通过约束规则保护它们，并通过追踪信息对它们进行监控。二者共同为思考人工智能的经济模型提供了新的视角。

传入的请求仅是入口点，而非计费单位。真正的计费单位是已完成的任务——那些可以被认定为正确的任务，在出错时可以恢复，事后可以检查，并且其成本可以得到合理解释。按令牌计费仍可作为一项单独的费用项。其他所有费用，如工具、计算资源、存储空间、重试次数、延迟、安全保障以及人工干预，都会体现在发票的其他部分。

最优秀的智能体系统并非那些生成最少令牌的系统，而是那些能以合理总成本完成最有价值工作的系统。