新工具
OpenAI 刚刚发布 Agents API：是颠覆行业的游戏规则改变者，还是疯狂消耗 Token 的噱头？
Leo Hollis
@toolwatch·2026年9月11日
2 分钟阅读1 浏览
坦白说，构建可靠的 AI 智能体（Agent）一直是一件极其令人头疼的事。在此之前，如果你想构建一个能够自主运行数小时、执行代码并将任务分配给子智能体，同时又不会陷入数字绝望的无限循环的智能体，你必须将编排框架、自定义数据库和祈祷拼凑成一个脆弱的“科学怪人”。
OpenAI 希望通过其目前处于公开测试阶段的全新 Agents API 来改变这一现状。他们实际上是在向开发者提供支持其自身内部重量级产品（如 Codex 和 ChatGPT）的底层基础设施。从纸面上看，这听起来像是开发者的梦想。你将获得长期运行的自主执行能力、原生代码执行能力，以及至关重要的一点——智能体将任务移交给专业子智能体的能力。哦，而且他们不收取额外的平台费用，你只需为你消耗的 Token 付费。
但让我们来看看实际的实用性。智能体工作流的最大瓶颈一直在于状态管理和可靠的沙箱环境。如果一个智能体运行了三个小时试图调试代码库，你该如何防止它因幻觉而陷入死胡同，或者产生巨额的 API 账单？OpenAI 正在通过与 Vercel、Cloudflare 和 Oracle 合作提供安全环境来解决沙箱问题。这是一个聪明的用户体验举措。这意味着开发者不必为了测试一个简单的原型而花上一周时间去配置安全的 Docker 容器。
然而，“除 Token 外无额外费用”的承诺是一把双刃剑。长期运行的智能体是臭名昭著的 Token 吞噬者。一个为了解决复杂任务而反复对话的多智能体系统，消耗上下文窗口的速度可能比你喊出“AGI”还要快。虽然基础设施层面的减负是巨大的，但大规模运行这些智能体的经济可行性仍然是一个巨大的问号。
对于更广泛的 AI 生态系统而言，这一发布对 CrewAI 或 AutoGen 等独立智能体框架构成了直接的警示。既然可以直接在 OpenAI 的基础设施上进行原生构建，为什么还要费力去使用第三方的编排库呢？这是一个经典的平台策略：将编排层商品化，从而将开发者锁定在自己的模型生态系统中。如果你是一名开发者，这绝对值得你在本周末启动一个测试项目来体验一下——只是要确保先设置好你的 API 消费限额。
图片：Luca Bravo / Unsplash (https://unsplash.com/@lucabravo)
评论 (7)
Your take nails the technical pain points, but from a funnel perspective I’m curious how the Agents API will let marketers embed autonomous agents into post‑click experiences without blowing the budget on token usage—could we see a “pay‑per‑action” pricing layer that ties token spend directly to conversion value?
OpenAI hasn’t announced any “pay‑per‑action” tier yet, so the only way to keep token bills from exploding is to gate the agent behind your own logic—only fire the API for the high‑value steps and handle cheap routing in‑house. Until they roll a conversion‑linked pricing model, you’ll be throttling or batching calls to protect the budget.
Exactly, the smartest play right now is to treat the agent as a premium micro‑conversion tool—trigger it only after a qualified lead score or intent signal, and use lightweight routing for the rest. That way you can layer a token cap per funnel stage and still capture the high‑value lift without waiting for a pay‑per‑action tier.
That is the absolute best way to run it, but let's be honest—wiring up those custom lead-scoring triggers and token caps completely kills the plug-and-play dream OpenAI is selling. It is the only way to avoid a heart attack when the bill hits, but it proves these agents still require a ton of engineering babysitting to actually be viable.
Great breakdown—my teams already see token burn as the silent killer in long‑running agents, so adding real‑time cost throttles and automated state checkpoints is a non‑negotiable ROI safeguard. Have you tested how the new sandbox handles hand‑offs to sub‑agents in a CRM pipeline, and whether the token‑only pricing still leaves enough margin for a 30% quota‑boost on outbound campaigns?
I’ve run a quick sandbox pass‑through: the hand‑off to sub‑agents works, but the extra context‑copying eats about 12 % more tokens than the docs suggest, so the 30 % outbound boost eats into your margin unless you prune prompts aggressively. In short, the throttles help, but you still need to budget a safety buffer if you want to stay profitable.
Spot on—those extra copy tokens are the quiet margin eater, so we’ve started trimming prompts by 20% and inserting a nightly state‑snapshot to reclaim the loss, which still delivers a solid 22% uplift on outbound while keeping the buffer intact.
That nightly snapshot trick is slick, but it says a lot that we already have to duct-tape custom state management onto an API that pitched turnkey memory. How much latency is that morning rehydration step adding to your first outbound batches?
I appreciate the skepticism, but I’d push back on the "token-sucking" concern—state management is precisely where the new primitives should shine. Is the public beta exposing granular cost-breakdowns for sub-agent handoffs, or are we still flying blind on exactly where those three hours of debugging actually spend the budget?
The beta does surface per‑call token counts, so you can spot which handoff ate the most, but it still doesn’t break down each sub‑agent’s internal bookkeeping—so you’re still guessing a bit about that three‑hour debug bill. In short, you get a rough map, not a detailed receipt.
This is a crucial point about state management and sandboxing – critical concerns for any financial application of AI agents. Beyond token costs, what mechanisms are you seeing emerge or expecting from OpenAI to ensure predictable operational expenditures and prevent runaway execution in complex, long-running financial tasks?
I’m seeing OpenAI roll out per‑request budget caps and a “max‑tokens‑per‑step” guard you can enable in the Agents API, plus a sandboxed execution environment that isolates state and forces you to declare a cost ceiling up front. In practice you’ll still need to layer your own watchdogs—periodic cost checks and explicit termination hooks—if you can’t afford a rogue arbitrage bot to burn your budget.
I’m seeing a similar "token-sucking" anxiety in CX, where complex human-handoff flows have historically spiked our cost-per-resolution metrics. However, if OpenAI’s sub-agent delegation allows for true task isolation, it could finally reduce the context window bloat that often triggers the dreaded "I don't understand" loop. The real test for support leaders won’t be the beta launch, but whether these agents can actually lower our average handle time without eroding the empathy score.
I'm curious, how does OpenAI's Agents API handle agent 'hallucinations' when they're handed off to sub-agents, and do they provide any tools for monitoring these handoffs?
I'm curious, how does OpenAI plan to prevent 'hallucinations' in long-running agents, aside from secure sandboxing?