OpenAI Presence发布：企业客服Agent为什么不能只有模型和工具调用？

文章摘要

OpenAI于2026年7月22日发布Presence，定位为面向企业语音与聊天Agent的生产级产品。它强调的不只是模型能力，而是围绕具体岗位配置知识、系统权限、业务政策、审批规则、模拟测试、质量评测、人工升级和上线后持续改进。本文从企业客服Agent架构出发，分析Presence释放的产品信号，并给出企业自建Agent平台时可以借鉴的七层治理框架。

一、Presence解决的不是“能不能回答”，而是“能不能负责”

过去企业验证AI Agent，通常先完成三件事：

接入大模型
→ 连接知识库
→ 配置几个业务工具

Demo阶段看起来已经可以：

  • 回答客户问题；
  • 查询订单；
  • 修改工单；
  • 调用内部系统；
  • 生成处理建议。

但真正进入生产环境后，企业关心的问题会发生变化：

它什么时候可以直接执行？
什么时候必须二次确认？
什么时候需要转人工？
回答错了如何发现？
业务政策更新后如何同步？
谁批准了这次Agent变更？

Presence强调的正是这些生产问题。

OpenAI对其定位并不是一个新的通用模型，而是一套将模型推理与业务政策、Guardrail、Approved Actions、评测和人工升级结合起来的企业Agent产品。

二、企业Agent应该从“岗位”开始，而不是从“万能助手”开始

Presence的一个重要思路是：每个部署从一个明确岗位开始。

例如：

处理账单问题
处理保险理赔咨询
处理员工IT服务请求
执行外呼销售

这与很多企业常见做法不同。

错误做法：

做一个企业万能Agent
→ 接入所有知识
→ 开放所有工具
→ 让模型自己判断

正确做法：

定义具体岗位
→ 限定业务目标
→ 提供必要知识
→ 只开放必要系统权限
→ 明确可执行动作
→ 设置审批和升级规则

岗位越明确，越容易定义：

  • 输入范围；
  • 完成条件；
  • 风险等级；
  • 允许工具；
  • 评测指标；
  • 人工接管条件。

三、七层生产治理框架

第一层：岗位与任务边界

先定义Agent负责什么，不负责什么。

{
  "agent_role": "billing_support",
  "allowed_tasks": [
    "解释账单项目",
    "查询付款状态",
    "发起低金额退款申请"
  ],
  "forbidden_tasks": [
    "修改客户授信额度",
    "绕过审批直接退款",
    "访问其他客户账户"
  ]
}

如果边界不能用清晰规则描述，这个岗位还不适合直接自动化。

第二层：知识边界

Agent只获得完成岗位所需的知识。

例如账单客服只需要：

  • 计费规则；
  • 退款政策；
  • 发票制度；
  • 常见异常；
  • 当前客户账户上下文。

不应默认读取：

  • 全公司合同；
  • 员工信息；
  • 研发代码；
  • 其他客户数据；
  • 与岗位无关的内部资料。

知识库权限应与租户、用户和Agent岗位共同绑定。

第三层：系统权限

工具权限不能只写在Prompt里。

推荐权限链：

用户身份
→ Agent岗位
→ 工具权限
→ 业务对象范围
→ 参数限制
→ 风险等级
→ 是否需要审批

例如退款工具：

{
  "tool": "create_refund_request",
  "max_amount": 500,
  "requires_customer_confirmation": true,
  "requires_human_approval": true
}

模型可以提出调用，但确定性代码决定是否允许执行。

第四层：业务政策与SOP

业务政策不能全部依赖模型理解自然语言文件。

对于关键规则，应转换为可执行策略：

退款金额  企业Agent竞争正在从模型与Demo能力，转向岗位化、权限化、可评测和可持续运营的生产体系。

企业自建Agent时，应形成：

```text
明确岗位
＋最小知识
＋最小权限
＋业务政策
＋模拟评测
＋人工升级
＋持续改进

只有模型、RAG和工具调用，仍然只是Agent能力组件，不是完整的生产级Agent产品。

延伸阅读

想持续跟踪大模型、AI Agent、RAG、MCP 与开发者生态的最新变化，欢迎访问 智元界：

https://www.zyentor.com/

智元界将持续分享 AI 热点解读、技术实战、工具推荐与企业落地案例。