Oz平台实战：AI代理自动赚钱和修Bug的完整配置指南

文章正文

当我们谈论AI代理（Agent）时，大多数人想到的可能是帮你整理邮件、管理日历的私人助手。但如果告诉你，一个AI代理每月能自动为你赚取上千美元，另一个能在用户提交Bug后自动定位问题并提交代码修复——你会怎么想？

AI代理是基于大语言模型（LLM）构建的自主执行系统，能够感知环境、制定计划并采取行动以完成目标。与传统的聊天机器人不同，AI代理具备工具调用（Tool Use）能力，可以操作文件系统、调用API、执行代码、浏览网页等。现代AI代理通常采用ReAct（Reasoning + Acting）框架，即先推理再行动，并根据执行结果动态调整策略——这使得它们能够处理多步骤、需要上下文判断的复杂任务，而不仅仅是回答单一问题。

开发者Travis近期分享了他使用Warp团队推出的Oz平台管理多个AI代理的实战经验，展示了AI代理从"个人玩具"走向"规模化生产力工具"的真实路径。

两个真实的AI代理赚钱与修Bug用例

用例一：AI代理自动更新Udemy优惠页面，月入千刀

Travis运营着一个Udemy课程优惠汇总页面，每月为他带来超过1000美元的被动收入。过去，他需要手动从数百个Udemy优惠变体中筛选相关信息、更新数据、清理过期优惠——这项工作既繁琐又耗时。

现在，他创建了一个专门的AI代理来完成这一切：

• 抓取数据：自动爬取最新的Udemy优惠信息
• 智能筛选：按月份过滤、按活动分组、生成优惠ID
• 更新内容：修改YAML数据文件和网页展示
• 清理维护：移除过期优惠、转换时间戳
• 提交审核：将所有变更打包成Pull Request供人工审核

这个AI代理每天自动运行，Travis只需要在手机上瞥一眼PR内容，决定是否合并即可。这种"代理执行、人类决策"的协作模式，正是AI代理在生产环境中最理想的工作形态——它将人类从重复性劳动中解放出来，同时保留了关键决策的人工把关。

用例二：AI代理自动修复GitHub Bug

第二个用例更具技术含量。当用户在Travis的开源项目中发现Bug并提交Issue时，AI代理会自动介入：

1. 读取Issue的标题和描述
2. 分析整个代码库，定位问题根因
3. 必要时启动容器进行测试验证
4. 找到解决方案后，自动创建分支、提交修复代码
5. 开启PR并附上详细的问题描述和修复说明
6. 在原Issue下评论PR链接

整个流程的触发条件非常简单——只需在Issue上添加一个"Oz agent"标签。开发者看到一个Issue，判断大模型能处理，加个标签就行。AI代理完成所有繁琐工作，开发者只需审核PR并决定是否合并。

这一用例的底层技术支撑是GitHub Actions的事件驱动架构。GitHub Actions是GitHub提供的CI/CD自动化平台，可响应仓库中的各类事件（Issue标签添加、PR创建、代码推送等）自动触发预定义的工作流。将AI代理与GitHub Actions结合，本质上是将LLM的推理和代码理解能力嵌入软件开发的事件循环中——每一个Issue标签的添加，都成为启动一次智能代码分析与修复流程的信号。

为什么需要AI代理编排平台？

管理一个AI代理并不难，但当你需要同时运行多个代理、面向不同环境和代码库时，挑战就来了：

• 如何追踪每个代理的运行进度和事件？
• 如何为不同代码库提供正确的环境依赖？
• 如何在云端按计划调度运行？
• 如何响应系统事件自动触发代理？

正如Travis所说："任何人都能打开10个Cloud Code终端来执行任务，但这不是规模化管理。"这正是Oz这类AI代理编排平台要解决的核心问题。

AI代理编排平台的技术定位，类似于容器编排领域的Kubernetes——它将多代理运行中的基础设施复杂性（环境隔离、状态持久化、调度策略、权限管理）抽象为统一的配置层，让开发者无需关心"代理在哪台机器上跑、依赖有没有装好、密钥怎么安全传递"等底层问题，而是专注于定义代理的业务逻辑。这种关注点分离（Separation of Concerns）的设计思想，是从单个代理实验走向多代理生产部署的关键跨越。

Oz平台核心架构：触发器→代理→环境→产出物

Oz的工作流程可以用一条清晰的链路来概括：触发器 → 代理（技能） → 环境 → 产出物。

触发器（Trigger）：定义何时启动代理

触发器决定了"什么时候启动AI代理"，支持多种方式：

• Slack中的标签提及
• API调用
• Cron定时任务
• GitHub事件（如Issue创建、PR评论）
• 手动触发

环境（Environment）：定义代理如何运行

环境是Oz的核心概念之一，它定义了代理如何运行，而不是做什么。包括：

• Docker镜像：提供运行时基础（Oz提供预构建镜像，也支持自定义）
• GitHub仓库：代理需要克隆的代码库
• Setup命令：安装依赖或准备环境的前置命令

Docker容器技术在AI代理场景中的价值尤为突出。容器提供了操作系统级别的隔离，确保每次代理运行都在一个干净、一致的环境中启动，避免了"在我机器上能跑"的经典问题。对于AI代理而言，这种可重复性至关重要——同一个技能定义，无论在开发者的MacBook上还是云端服务器上，都应产生相同的行为。此外，容器化还天然支持并发运行多个代理实例，每个实例拥有独立的文件系统和进程空间，互不干扰。

关键优势在于环境的可复用性——一旦为你的网站项目创建了环境，后续所有针对该项目的代理都可以复用同一环境配置。

技能（Skill）：代理的核心逻辑

技能是AI代理的"大脑"，定义了代理具体要做什么。Travis推荐将技能定义在代码库中，Oz会自动识别并加载。这种方式的好处是：

• 行为一致、可重复执行
• 可版本控制，方便回溯
• 团队间可共享复用

将技能定义存储在代码库中，本质上是将AI代理的行为纳入GitOps工作流。这意味着技能的每一次修改都有完整的变更历史，可以通过PR进行代码审查，也可以在出现问题时快速回滚到上一个稳定版本——这是AI代理从个人实验走向团队协作的重要工程实践。

产出物（Artifacts）：代理的输出结果

AI代理运行完成后产生的结果，比如Pull Request、执行计划、会话分享链接等，都可以在Oz平台中统一查看和管理。

Oz平台实战配置详解

GitHub Action触发Bug修复代理

在GitHub Action中配置AI代理自动修Bug的流程如下：

1. Checkout仓库代码
2. 从Issue的标题和描述动态构建Prompt
3. 将Prompt和Warp API Key传递给Oz代理
4. 代理分析代码、定位问题、提交修复
5. 自动创建分支、开PR、回复Issue

Udemy优惠代理的完整配置步骤

在Oz Web界面中的配置过程：

第一步：添加GitHub集成 —— 将GitHub作为集成添加，并限制只访问目标项目仓库，确保权限最小化。

第二步：创建运行环境 —— 由于项目是Next.js应用，选择对应的Docker镜像，关联GitHub仓库。

第三步：配置密钥管理 —— 通过oz secret create命令添加必要的密钥（如优惠平台凭证、GitHub Token）。密钥存储安全，创建后不可读取，运行时作为环境变量注入。这种设计遵循了最小权限原则（Principle of Least Privilege）——代理只能访问完成任务所必需的凭证，且密钥以加密形式存储，即使平台遭到入侵也无法直接读取明文。

第四步：创建代理技能 —— 在代码库中定义Skill文件，详细描述代理的每个执行步骤。

第五步：设置定时调度 —— 配置为每日自动运行，确保不遗漏任何优惠信息更新。

云端运行与可观测性

Oz平台的一个重要特性是云端可观测性。与本地Warp终端运行不同，通过Oz云端触发的AI代理，所有活动都会显示在Web界面中。你可以：

• 实时查看代理运行状态和日志
• 通过"View Session