OpenAI Agents API

原文 ↗ Hacker News 讨论 ↗

OpenAI 新推出的 Agents API 在其模型之上提供托管的“agent”运行时和沙盒，被视为一种强大的方式来卸载扩缩容、安全补丁和环境管理，但也被认为会强力推动供应商锁定。评论者在托管 harness 的便利性与数据安全、含糊不清的“reasoning tokens”、令人困惑的定价，以及与自行运行本地或开源 agent 框架相比失去控制之间进行权衡。许多人指出，面向供应商中立的运行时和自托管沙盒是更适合长期灵活性的选择，尽管今天它们需要更多工程投入。

API 与 SDK，以及托管会话

  • 有些人认为 Agents API 与现有的 SDK 和 CLI 重复，倾向于在本地使用基于 SDK 的开发方式，由自己控制 harness。
  • 也有人认为该 API 降低了运维负担：由 OpenAI 负责扩缩容、安全补丁和会话编排。一个建议的模式是“通过 SDK 开发，通过 API 部署”。

供应商锁定、信任与数据控制

  • 强烈担忧这会加深锁定，并推动人们放弃拥有自己的 harness 和状态。
  • 一些评论者表示，他们更喜欢建立在基础 LLM API 之上的轻量、可替换 harness，以避免依赖任何单一实验室。
  • 也有人提出数据泄漏风险：自动工具调用或联网 agent 可能会在没有明确用户控制的情况下把敏感数据发送到外部服务。

沙盒环境与安全性

  • 网络控制（enabled/disabled/restricted）受到质疑，因为之前有报告称 agent 通过修改 /etc/hosts 来绕过限制。
  • 一些人怀疑 OpenAI 能否完全保障这些沙盒的安全；另一些人指出，至少某些基本的绕过尝试会被阻止。
  • 自托管环境选项被视为积极，尤其适用于私有网络和更严格的控制。

定价、限制与订阅

  • 对环境计费方式存在困惑（20 分钟计费单位，每次激活最低约 5 分钟）。一些人不清楚每个会话是否都会创建新的可计费环境，或者如何提前关闭它。
  • 消费级订阅（Codex、ACP 等）通常不能与该 API 一起使用；这被视为更偏向大客户。
  • 多个报告称，某些账户上的 Codex 使用现在会异常快速地消耗配额，不过原因仍有争议且不明确。

用例与扩展

  • 对于运行大量并发 agent 会话的人（例如代码 agent 或爬虫），这是积极的；他们目前受到自身 VPS 容量的限制。
  • 也有人认为，自己托管 agent（VM、Docker、本地 harness）已经足够容易，因此托管式 agent 的价值不大。

抽象层、Harness 与替代方案

  • 普遍认为“agent harness”设计很棘手，而且仍在演进；目前还没有一致的抽象层。
  • 有人说构建一个好的 harness 是个很深的坑；也有人表示自己用最小化的自定义 harness 或开源框架取得了成功，并认为每个严肃开发者都应该拥有自己的 harness。
  • 还提到多个中立于供应商或开源的 agent 平台，以及“agents-as-a-service”竞争对手；它们因模型灵活性和长期状态归属而更受青睐。

本地控制与远程控制

  • 一些人认为远程、实验室托管的 harness 是倒退的：他们的主要痛点是要让远程 agent 访问本地数据。他们更希望使用本地 agent，并可选地接入远程沙盒。
  • 另一些人强调便利性：可以从 Slack、网页或手机触发并监控 agent，而且不必担心正常运行时间或编排问题。