什么是 Agent as a Service？把 AI Agent 变成可调用的服务
一张 Bug 工单刚提交，系统就启动了一次排查。几分钟后，工单页面上出现了复现结果、失败测试的输出和一份可供审查的代码补丁。开发者可以在页面上补充条件，让 Agent 继续验证，也可以直接接手。
从工单系统的角度看，这和开发者打开 AI 聊天窗口有一个关键区别：排查可以由应用发起，进度可以被跟踪，产物也能回到原来的业务流程。
这就是本文所说的 Agent as a Service，也就是把 Agent 的执行能力封装成服务，让其他应用通过 API 提交任务、获取进度和接收结果。这是一种架构思路。团队可以自己运营服务，也可以使用托管平台提供的 Agent 运行能力。 OpenAI Agents API 架构文档
调用模型和调用 Agent，有什么区别？
假设团队想自动排查一张标题为“订单取消后重复发送通知”的工单。
直接调用模型时，应用可以把工单描述和相关代码发给模型，请它提出原因和修复建议。如果需要搜索仓库、运行测试，再根据测试结果决定下一步，应用也可以围绕模型 API 自己实现这一轮工具调用和状态管理。
调用一个已经封装好的排查 Agent 时，工单系统可以提交工单编号、仓库版本和任务范围。Agent 服务负责运行排查过程。应用跟踪执行状态，等到任务完成后读取报告和补丁。如果排查缺少复现条件，应用还可以把待确认项展示给用户，再把用户的回答送回同一个会话。OpenAI Agents API 的会话和事件机制就是这种接口的一个例子。 OpenAI Agents API 文档
区别在于谁负责把任务跑完。模型 API 可以作为 Agent 服务的底层组件。Agent 服务进一步封装了工具调用、执行状态和结果交付，让接入方能够围绕任务设计产品。
一次任务怎么走完整个流程？
以工单排查为例，可以把流程拆成四步。
- 应用提交任务。 工单系统传入问题描述、目标仓库和提交版本，并指定本次只交付排查报告与补丁。服务返回任务标识，页面可以继续使用。
- Agent 执行排查。 它搜索相关代码、尝试复现问题、运行测试。需要执行命令时，服务可以为这次任务准备一个隔离的工作区。
- 应用跟踪状态。 页面可以显示“正在复现”“等待补充信息”或“执行失败”。具体实现可以使用事件流，也可以用 Webhook 通知应用处理新的结果。 OpenAI 会话事件文档
- 业务流程接收结果。 工单页面展示复现步骤、测试输出和补丁，由开发者决定是否采纳。排查失败时，也可以保留已经验证过的线索，供接手的人继续使用。
把这套流程接入代码审查系统时，入口可以换成合并请求，交付物可以换成审查发现。同一套会话、权限和运行记录机制仍然可以复用，具体任务的工具和交付要求则可以分别配置。
它和 Agent in the Sandbox 是什么关系？
Agent as a Service 关心应用如何发起任务、跟踪进度和接收结果。Agent in the Sandbox 关心命令在哪里运行、文件在哪里修改，以及执行环境能访问什么。
两者可以组合。代码排查服务可以把每次执行放进独立沙箱，让 Agent 安装依赖、修改仓库副本和运行测试。一个只通过只读工具查询知识库的 Agent，也可以对外提供服务，而无需专门准备能运行命令的工作区。 OpenAI Agents API 架构文档
服务接口需要说清楚什么？
做成服务以后，调用方会遇到一些聊天窗口里容易被忽略的问题。比如工单系统提交任务后网络超时，重新提交会启动两次排查吗？如果 Agent 有权写回工单，重试会不会生成两条一样的评论？用户补充了信息，系统该继续原来的排查，还是启动一轮新的执行？
这些问题决定了服务接口是否好用。任务标识让应用知道正在跟踪哪一次执行。状态和事件让应用知道何时该等待、补充信息或展示结果。对于会写入外部系统的操作，还需要明确调用者的权限，并在重试时防止重复写入。
回到那张重复通知的工单，理想的交付并不止于一句“已修复”。第二天接手的开发者打开工单，就能看到 Agent 针对哪个版本做了排查、用什么步骤复现、哪些测试已经通过，以及并发请求是否还需要验证。他可以沿着已有证据继续工作，无需重开一轮聊天、重新交代项目背景。
