4月28日消息，OpenAI Developers 今日发布交互式语音应用 Chappy 演示视频，展示开发者基于 gpt-realtime-1.5 构建低延迟语音原生体验、用户通过自然语音直接控制应用状态的完整链路。同期，OpenAI 上月开源的编码 Agent 编排框架 Symphony 持续发酵，截至 4 月 23 日 GitHub 星标已突破 1.57 万。一头是语音 API 的应用层落地，一头是 Coding Agent 的工程化范式，OpenAI 在两条开发者工具线上同时加速。
Chappy：用语音状态机替代 UI 层
Chappy 演示的核心是把 gpt-realtime-1.5 当作"语音状态机"，让 App 状态变更绕过传统 UI 控件，直接由用户自然语音驱动。模型支持 WebRTC（浏览器低延迟）、WebSocket（服务器侧）、SIP（电话系统接入）三种接入方式，对应了消费端 Web/移动应用、后端 Agent 服务、企业客服电话三类典型场景。
gpt-realtime-1.5 于 2026 年 2 月 23 日通过 Realtime API 上线，相对 2025 年 8 月发布的首版 gpt-realtime，关键提升集中在三处：Big Bench Audio 推理 +5%、字母数字转录准确率 +10.23%、指令遵循 +7%；工具调用与多语种处理可靠性也有同步改进。价格保持不变——音频输入 $32、输出 $64 每百万 token，文本输入 $4、输出 $16 每百万 token，缓存输入统一 $0.40。这意味着开发者无需为新版本支付溢价，是 OpenAI 在 Realtime API 商业化节奏上一个明确信号。
横向对比，ElevenLabs 的 Conversational AI、Anthropic 的 Claude 语音模式（已支持 iOS/Android 端语音对话）目前都在抢同一个市场，OpenAI 的差异点是 SIP 接入与函数调用的成熟度——gpt-realtime 在 ComplexFuncBench 音频评测上从 49.7% 提升到 66.5%，这是企业语音 Agent 投产的关键指标。Chappy 的演示视频本质是给开发者一份"非客服场景"的参考实现，避免外界把 Realtime API 局限理解为"AI 客服专用"。 Symphony：把 Linear 工单当作 Agent 控制面
Symphony 由 OpenAI 在 GitHub 开源，定位是"管理工作而非监督 Coding Agent"。运行机制是：以 5 秒间隔轮询 Linear 等任务面板，为每个处于 open 状态的 issue 启动独立 workspace，调用 Codex（默认 gpt-5.3-codex 模型）持续工作，跑至 CI 通过、PR 复盘、复杂度分析、demo 视频齐备后交付给人工 review，人类 reviewer 接受后 Agent 安全合入 PR。
工程实现上，Symphony 用 Elixir 写就，核心理由是 BEAM/OTP 提供了原生的并发监督树与热代码加载能力，能稳定托管长时间运行的子 Agent 进程——这与目前 AI Agent 框架普遍以 Python 为主的生态形成明显反差。配置上极简：单文件 WORKFLOW.md，使用 YAML front matter + Markdown 提示词正文。关键参数包括 max_concurrent_agents（默认 10）、max_turns（默认 20，单次 Agent 调用的最大连续 turn 数）、approval_policy（沙箱审批策略）等。OpenAI 在博客中明确，参考实现选用 Elixir，但核心思路本身可由任意 Agent 用任意语言重新实现，他们也用 Codex 让模型自己用 TypeScript、Go、Rust、Java、Python 各实现了一遍以验证规范的清晰度。
效果数据上，OpenAI 内部部分团队的 PR 落地量提升 500%，开发者 Dan McAteer 在一周内关闭 30 个 issue。Symphony 上月初低调上线 GitHub，截至 4 月 23 日已收获 1.57 万 star（当前 14.7k，含 1.2k fork），4 月 23 日 OpenAI 官方博客正式发文介绍。
把 Symphony 放进当前 Coding Agent 工具图谱，定位会更清楚。Anthropic Claude Code、Cursor 走的是"开发者主导、Agent 协助"的交互式路线，单 Agent 单开发者，强调实时协作；Devin 这类自主开发 Agent 走"端到端代办"路线，但公开数据显示其在真实工程任务上的成功率仍不稳定。Symphony 的差异在于——它不是新的 Agent，而是 Agent 的编排器，核心调度对象是 Codex，并明确假设代码库已经做过"Harness Engineering"改造（自动化测试齐备、Agent 友好的仓库结构、明确的护栏规范）。
换句话说，Symphony 的"500% PR 落地量提升"是有前置条件的：团队需要先把仓库改造成 Agent 能可靠工作的形态。OpenAI 在博客中也直言，Symphony "best in codebases that have adopted harness engineering"——这是低调表达的高门槛。对没有完整 CI/test 体系、issue 描述质量不稳定的中小团队，直接复制 Symphony 模式收益会打折。
局限与未明朗的几点
需要客观看待的有几点。
其一，社区主要槽点集中在 token 成本——Symphony 默认配置 max_turns=20、并发 10 个 Agent，且 Codex 使用 gpt-5.3-codex 配合 model_reasoning_effort=xhigh，单次 issue 处理成本可观，OpenAI 官方未公开人均/issue 的平均开销数据，需要团队自己跑试点压测。
其二，Symphony 当前定性为"low-key engineering preview for testing in trusted environments"，OpenAI 自己也强调适合可信环境，生产环境的安全沙箱、密钥管理、对外部依赖的访问控制仍需团队自行加固。
其三，Chappy 是演示性质的应用案例，并非 OpenAI 推出的新产品 SKU，gpt-realtime-1.5 的工具调用准确率、interrupt 处理、多语种切换在真实生产负载下的表现仍要看开发者落地反馈。
其四，Symphony 与 Linear 之外的任务系统（Jira、GitHub Issues、Asana）的适配层目前需开发者自行实现 tracker 接口，原生支持仅限 Linear。
更值得关注的是 OpenAI 这两条线背后的共同信号：从单 Agent 工具调用，向"Agent 集群 + 状态控制平面"演进。Chappy 演示的语音 → 应用状态映射，Symphony 演示的工单 → PR 映射，本质都是把 LLM 当作业务系统的控制面而非聊天界面。Codex 与 Realtime API 这两个现有产品基础上，OpenAI 接下来在控制面工具链（任务编排、状态机抽象、跨 Agent 通信协议）上的动作，会是观察其开发者平台战略的核心维度。
AI 速览
