OpenAI Agents API：构建智能体新范式

▲ 175aquir104 HN 评论区
OpenAI Agents API：构建智能体新范式

OpenAI 正式推出 Agents API，标志着开发者构建自主智能体的方式迎来重大变革。该 API 提供了从会话管理、沙箱环境到工具集成的完整架构，支持多智能体协作与实时交互。开发者可以利用 OpenAI-hosted sandboxes 或 self-hosted sandboxes 安全地运行代码，并通过 MCP connections 和 Plugins 扩展能力。无论是构建语音助手还是自动化工作流，Agents API 都提供了从 Quickstart 到 Production 全生命周期的支持，让复杂任务的处理变得更加灵活和可控。

Agents API 为开发者提供了构建自主智能体所需的全部工具，从会话管理到沙箱环境，再到多智能体协作，让复杂任务的自动化处理变得前所未有的简单。
阅读原文 →HN 评论区RSS

HN 评论区

104
  1. bluesnowmonkey

    我觉得我们还在摸索将智能体作为产品提供的正确抽象层。

    - LLM 是很好的基础，但自己搭建运行框架（harness）是一项巨大的工程，是个深不见底的兔子洞。

    - 虽然有开源库提供现成的框架，但这仍然与环境强耦合。状态存在哪里？比如，如果我是一个 Cloudflare worker，甚至根本没有文件系统。

    像这样的智能体即服务（Agent as a service）让你可以按需接入所需的工具，将其打造为任何你想要的智能体。但他们依然能够封装并持续迭代所有智能体都需要的核心框架部分，比如记忆和上下文管理。

    话虽如此，我目前并不看好 OpenAI 和 Anthropic 的产品，因为他们被自己的专有前沿模型困住了，而这些模型目前并不是大多数智能体的最佳选择。一个非 LLM 实验室的竞争对手可以随时在市场上挑选最合适的模型。比如，现在大多数智能体任务你可能更想用 GLM 5.3 Flash。

  2. andrewchambers

    我最近成功地在普通的 qemu 虚拟机中运行 codex，并通过 codex remote control 从手机与它交互。

    老实说，作为个人助手效果极好。

    我完全理解将其做成 API 的合理性，但要注意，如果你能自己搭建虚拟机，就不必把自己锁死在某个方案里。

  3. brap

    我觉得普通 LLM“端点”与智能体/框架之间的界限会越来越模糊，直到这个区分变得毫无意义。

    当你使用 ChatGPT/Claude/Gemini 等时，你基本上已经在与带有工具等功能的后端框架交互，而不是原始的 LLM。直接给它一台电脑就完事了。

    我甚至发现自己在处理与编程无关的任务时，也更倾向于使用 Claude Code / Antigravity（通过网页版），而不是 Claude / Gemini。为什么要用功能受限的版本呢？

  4. monneyboi

    别搞这种增加供应商锁定的把戏了，把我们付费购买的推理 token 还给我们。谢谢。

  5. 6thbit

    藏在里面的一个细节：你可以选择自托管沙盒环境

    https://developers.openai.com/api/docs/guides/agents-api/env...

    这让这个方案更有吸引力，也可能让在不同服务商之间迁移变得更加容易。

  6. varenc

    他们的展示案例 [0] 链接到了 GitHub，但链接显示 404。比如这个 Slack 智能体的链接：https://github.com/OpenAI-Early-Access/agents-api-python-pre...

    猜测这只是一个尚未完全准备好的早期发布？有趣的是有个 'OpenAI-Early-Access' 的 GitHub 用户，当然没有任何公开仓库。推测等到正式发布时，他们会把示例智能体仓库移到另一个 GitHub 用户下。

    [0] https://developers.openai.com/showcase/agents-api-slack-bot

    编辑：也许 OpenAI 有人看到了我的评论，因为链接现在修复了！而且指向了 openai 组织下的一个公开仓库：https://github.com/openai/openai-cookbook/tree/main/examples...

  7. chairhairair

    当你想要数据被程序化地窃取时，这简直完美。

  8. jumploops

    我觉得有趣的是，智能体对比页面 [0] 并没有列出 codex 的 app-server 作为一个选项。

    我发现 app-server 比原始的 Responses API 或 Agents SDK 灵活得多。

    显然大家还在摸索正确的接口形式。

    另外值得注意的是，自从 GPT-5.5 左右开始，Codex 甚至不再按预期方式使用 Responses API，而是使用一个“轻量版”，他们更手动地管理上下文（比如发送完整的对话记录，或者使用自定义的 web.run 工具，而不是提供的 `web_search` 工具）。

    如果你照着文档做，会带你走向很多功能完善的道路，但在他们最成功的框架中，大部分功能其实都被弃用了。

    [0]https://developers.openai.com/api/docs/guides/agents#compare...

同日更多故事

2026-09-10