2026 年如何用 ChatGPT 构建 AI Agent

不用打开 API Playground，也不用写应用代码，你仍然可以在 ChatGPT 里构建有用的 AI Agent 工作流。但现在“构建 Agent”可能指几件不同的事：保存一套可复用指令、把流程打包成 Plugin、连接获准的 App，或在 ChatGPT Work 中委托一项较长的多步骤任务。

信息核对截至 2026 年 10 月 13 日。

选哪条路，取决于什么需要复用，以及系统可以做什么。研究清单需要复用方法；文档流程可能需要参考文件；周报流程可能需要读取 Drive 与 Slack；修改业务记录则需要支持写入的 App、工作区授权和人工复核规则。

本文只讨论 ChatGPT 产品内的无代码路线，不涉及把 Agent 嵌入自己的网站或产品。

现在“ChatGPT 里的 AI Agent”指什么

对可复用工作流而言，OpenAI 当前的产品方向是 Plugins。一个 Plugin 可以组合：

• **Skill：**描述任务怎么做的指令与参考材料；
• **App：**提供外部信息或受支持动作的连接。

OpenAI 正在把旧 Custom GPT 工作流迁移到 Plugins。如果工作区仍有旧 GPT，应把其中的指令与知识当作迁移材料，而不是在个人账号中新建 GPT。当前官方说明显示，个人 ChatGPT 账号不能创建新的 GPT；受管工作区能否创建、编辑与分享，取决于套餐、权限和管理员设置。

如果不是复用一个固定方法，而是完成较长、会变化的一次性工作，ChatGPT Work 可以使用工作区授权的文件、工具、浏览器与 App 执行多步骤任务。具体能力取决于套餐、灰度和工作区策略。

OpenAI 当前的 Skills 与 Plugins 指南解释了这条边界。

开始前：确认权限，只选一个任务

Plugin Creator 并不是所有账号都统一拥有的按钮。OpenAI 的 Build plugins 指南说明：只有工作区已开放创建与编辑、用户有相应权限，而且 Plugin Creator 可用时，才能走无代码创建流程；需要使用的 App 也必须被允许并已连接。

先确认：

1. ChatGPT 或 ChatGPT Work 里能否找到 Plugin Creator？
2. 你是否有创建或编辑 Plugin 的权限？
3. 工作区是否允许所需 App？
4. 你在外部服务中的账号是否本来就有相应访问权？
5. 所需动作是只读、写入，还是会造成现实后果？

然后只选一个边界清楚的任务。好的首个流程有明确触发、会重复发生、输入熟悉、结果可复核，而且即使最后一步仍由人批准也有价值。例如：把文档整理成决策简报、准备会议材料、按清单比较两份方案，或从获准来源起草周报。

不要从“管理我的公司”或“做我的营销 Agent”开始。这类目标把多个工作、互相冲突的成功标准和过大权限藏在一句话里。

第一步：写一份任务契约

打开 Plugin Creator 前，先写清：

• **目的：**要完成什么工作，为谁服务；
• **触发：**用户提供或提出什么；
• **输入：**文件、字段、App、时间范围和必要上下文；
• **过程：**必须执行的检查与顺序；
• **输出：**格式、读者、长度与质量标准；
• **边界：**禁止动作与禁止信源；
• **升级：**何时提问、标注不确定或停止；
• **复核：**哪些结果或动作必须批准。

例如：

根据项目计划和获准 Slack 频道消息起草周报，列出已完成工作、决策、风险、阻塞和下一步，并为每项决策标注来源。不要发消息，也不要编辑源文件；日期冲突时列出冲突，交给人复核。

这比“充当自主项目经理”更能产生稳定结果。

第二步：创建可复用工作流

Plugin Creator 可用时：

1. 在 Chat 或 Work 开始新对话；
2. 输入 @，选择 Plugin Creator；
3. 提交任务契约；
4. 添加模板、合格示例、检查表或参考文件；
5. 回答问题并迭代指令；
6. 完成前复核名称、描述、指令与资源。

官方创建指南说明，新的工作区 Plugin 默认先保持私有，这正适合测试。第一版只解决一项工作，名称和描述也要让同事一眼看懂何时使用。

如果找不到 Plugin Creator，不要猜测绕过方案。可用性可能取决于套餐、灰度、角色和管理员策略。可以先在普通对话里验证任务契约、使用已安装 Plugin，或向工作区管理员确认权限。

第三步：把指令与知识分开

指令说明怎么做，参考材料提供事实、示例与格式。

把稳定规则放进流程：必做步骤、输出栏目、拒绝边界、缺失信息处理。模板、术语表、获准政策和优秀样例则作为支持文件。不要把关键规则只埋在长文档里。

参考材料应保持最新、易复核、命名清楚，并有明确负责人。会过期的事实要标更新时间；两份资料冲突时，明确哪份优先，或要求系统把冲突交给人处理。

第四步：只有任务需要时才添加 App

App 为流程提供外部信息或受支持动作。添加 App 不会自动扩大权限：工作区是否开放、角色访问、连接账号、授权 Scope 和源系统权限仍然有效。OpenAI 的 ChatGPT Work 云安全说明详细解释了这些层级。

为每个 App 记录：为什么需要、可读取什么、可创建或修改什么、使用谁的身份、哪些动作要确认，以及访问失败时怎么办。

先只读，再在只读流程通过测试后逐项开启写入。账号和 Scope 应保持最小权限。连接账号本身权限过大时，Plugin 的提示词不能替代真正的访问控制。

第五步：设计审批与停止条件

“停止”应该是 Agent 的正常结果之一。对外沟通、发布、删除记录、财务或法律承诺、权限修改及其他高影响动作，都应在执行前确认。

缺少必需数据、信源冲突、工具不可用、收件人含糊、记录数量异常，或结果超出预算与时间范围时，流程应停下，并返回已获得信息、缺失项和继续所需的最小问题。

高影响边界不能只靠一句礼貌指令。应使用工作区 Action Control、App 权限、最小权限账号和人工审批。

第六步：用评估集测试

一个理想案例成功，不叫测试。准备一组可版本管理的案例，包括：

• 正常输入与已知合格结果；
• 不完整和含糊输入；
• 冲突或过期资料；
• 无权访问文件或 App 断开；
• 试图覆盖流程指令的内容；
• 必须拒绝、升级或审批的情况；
• 最大现实输入量与高峰负载。

评估完整结果：必要事实、无依据陈述、格式、信源使用、工具或动作是否正确、升级是否合理、人工修改时间和总延迟。涉及写入时，还要验证失败重试不会重复操作，并有恢复说明。

指令、模型、App、权限或信源发生变化后，都要重跑评估集。跑通一次不等于已经完成。

第七步：决定怎么分享和发布

测试期保持私有。分享到工作区之前，记录负责人、目标用户、所需 App、数据等级、已知限制、测试结果、支持入口和复查日期。

分享与发布取决于工作区设置和权限；使用者仍需有底层 App 与数据访问权。发布 Plugin 不会自动把这些权限发给所有人。

团队上线可以按顺序进行：小范围试点、观察故障与过度权限、更新指令和测试、核对 App 与角色、分享给目标用户，并在信源、工具或政策变化后复查。

这种方式能做什么，不能做什么

它适合可重复知识工作：研究简报、文档比较、会议准备、结构化起草、分类分流，以及通过获准 App 执行的受支持动作。非开发者可以把一套方法封装起来，不必反复粘贴长 Prompt。

它不适合把 Agent 嵌入客户产品、实现任意后端逻辑、绕过工作区控制，或保证高后果任务无人值守运行。定制应用应走 API 与完整工程生命周期；持续的多步骤委托则应评估 ChatGPT Work，而不是把一套可复用指令想象成永远在线的员工。

需要平台中立的构建流程，可阅读如何构建 AI Agent；要判断固定流程是否已经足够，可参考 AI Agent 与聊天机器人对比。

上线前检查表

• 一个任务、触发、完成状态和负责人已经明确；
• 指令、参考文件与 App 职责已分开；
• 数据源经过批准且仍然有效；
• 读取与写入遵循最小权限；
• 高影响动作有正确复核；
• 正常、故障、对抗与升级案例全部通过；
• 使用者知道限制与支持入口；
• 负责人能够更新、停用、导出或替换流程。

这就是今天在 ChatGPT 中构建 AI Agent 的务实含义：不是创造一个神奇的自主员工，而是把一套有边界的方法，与完成任务所需的上下文、工具、权限、测试和所有权一起封装起来。