实战：用 /goal 模式重写 UP 主监控器HERMES & AGENT ENGINEERING · 课时 09

9.1 回顾：6.8 的逐步指令写法

6.8 写好的提示词是这样的：

完成以下任务，只做一次：

1. CDP 连接我的Chrome浏览器，打开我的 B 站"特别关注"分组页面
   （https://space.bilibili.com/xxxxx/fans/follow?tagid=分组ID），
   获取这个分组里的所有 UP 主。
   注意：关注列表可能会分页，需要翻页获取完整列表。

2. 依次访问每个 UP 主的个人主页
   检查他们在过去 24 小时内是否发布了新视频。

3. 对于每个新视频，按以下流程提取内容：
   a. 先用 CDP 调 B 站 /x/web-interface/view 接口，
      检查这个视频是否有字幕（看 subtitle 字段是否为空）。
   b. 如果有字幕，用 CDP 调 /x/player/wbi/v2 接口获取字幕下载 URL，
      然后立即 curl 下载字幕 JSON（URL 有时效性，约 5-10 分钟过期，必须马上下载）。
      拿到字幕后，用字幕内容生成摘要。
   c. 如果没有字幕，直接读取视频的标题和简介，用这些信息生成摘要。

4. 把所有新视频的结果整理成一份日报，格式如下：
   - UP 主名称
   - 视频标题
   - 视频链接
   - 内容摘要（约 100 字，来源标注：字幕/视频简介）
   - 来源：字幕/视频简介

5. 把这份日报通过微信发送给我。

这段提示词很详细，把每一步该做什么、用什么 API、遇到字幕缺失怎么降级，都写得很清楚。Agent 按部就班执行，不容易出错。

但它也暴露了逐步指令写法的一个问题：你替 Agent 做了太多决策。用什么 API、先查哪个接口、URL 过期了怎么办，这些都是执行层面的细节。你写得越细，Agent 的自主性就越低。一旦某个 API 返回格式变了，或者 B 站新增了其他获取字幕的途径，这段提示词就得跟着改。

9.2 /goal 模式的写法

换成 /goal 风格，核心变化是：不再告诉 Agent 每一步怎么做，而是告诉它要什么结果、怎么判断完成。

但在改写之前，我们要先想清楚一件事：6.8 里那些技术细节，哪些该保留，哪些该去掉？

答案是分成两类来看。硬约束要保留，就是那些"不告诉 Agent 它就会踩坑"的事实；具体路径可以去掉，就是那些"Agent 自己能探索出来"的执行步骤。

改完之后：

/goal 检查我 B 站"特别关注"分组(https://space.bilibili.com/xxxxxxx/relation/follow?tagid=-10)里所有 UP 主的最新动态。
找出过去 24 小时内的每个新视频，为每个视频生成约 100 字的内容摘要。

约束：
- 字幕提取必须通过 CDP 浏览器完成（裸 HTTP 请求拿不到字幕数据，
  因为 B 站的字幕接口要求登录态）
- 优先用字幕内容生成摘要；字幕获取失败时，最多尝试 3 种不同的获取方式，
  都失败后再降级用视频标题和简介
- 关注列表可能分页，必须翻页获取完整列表（B 站每页只显示 20 人）

整理成日报，格式包含：UP 主名称、视频标题、视频链接、内容摘要、摘要来源。

完成标准：
- 所有特别关注的 UP 主都已检查（无遗漏）
- 每个新视频都有对应的摘要条目
- 日报已通过微信发送

异常处理：
- 某 UP 主主页加载失败：记录失败，不阻塞其他 UP 主的检查
- 分组内无新视频：日报中说明"过去 24 小时无更新"

和 6.8 的原版对比，有三处明显的变化：

第一，去掉了具体的 API 调用顺序。原版写的是"先调 /x/web-interface/view 查 subtitle 字段，再调 /x/player/wbi/v2 拿下载 URL，然后 curl 下载"。这些是执行步骤，Agent 自己能探索。你告诉它"字幕要通过 CDP 浏览器拿"就够了，用什么接口、先查哪个字段，让 Agent 自己决定。

第二，保留了硬约束，但补了理由。比如"字幕提取必须通过 CDP 浏览器完成"后面跟了一句"裸 HTTP 请求拿不到字幕数据，因为 B 站的字幕接口要求登录态"。这条约束不是方法偏好，是 B 站的技术限制。Agent 不知道这个事实就会先试裸 curl，失败，再试 CDP，白白烧一轮。告诉它为什么，它就不会走弯路。

同理，"关注列表可能分页，B 站每页只显示 20 人"也是一条硬约束。不告诉 Agent，它可能拿到第一页 20 人就以为完事了。

第三，"字幕获取失败时，最多尝试 3 种不同的获取方式"这条约束很有意思。它不是告诉 Agent 具体用什么方法（那是具体路径），而是给它一个探索的边界：你可以尝试不同的方式，但不能无限尝试。超过 3 种方式还失败，就降级用标题和简介。这样既发挥了 Agent 的自主探索能力，又防止它在失败的方法上无限烧 Token。

9.3 两种写法的对比

把两段提示词放在一起看：

逐步指令的优势是可预测。你知道 Agent 会做什么，因为它就按你的步骤走。但代价是脆弱，一旦某个步骤的前提条件变了，整条链路就得改。

/goal 模式的优势是鲁棒。Agent 有全局视角，遇到异常能自主调整，你不需要预判每一种失败情况。但代价是执行过程不完全可预测，你需要信任 Agent 的规划能力。

9.4 写好 /goal 提示词的四个要点

从这次改写中，可以提炼出四个原则：

区分硬约束和具体路径。 这是最关键的一步。硬约束是"不写就会踩坑"的事实，比如"需要登录态""有分页""URL 会过期"。具体路径是"你摸索出来的最优做法"，比如"先调 A 接口再调 B 接口"。前者要写，后者可以不写。判断标准很简单：如果 Agent 不知道这条信息就会犯错，那就是硬约束；如果它犯错后能自己纠正，那就是具体路径。

硬约束要带上理由。 只写"必须通过 CDP 浏览器"，Agent 可能会尝试绕过。写上"因为 B 站的字幕接口要求登录态，裸请求拿不到数据"，Agent 理解了原因，就不会白费力气试其他路径。理由越具体，Agent 越不容易走偏。

给探索行为设定边界。 /goal 模式鼓励 Agent 自主探索，但不能无限制探索。"字幕获取失败时，最多尝试 3 种不同的获取方式"这条约束，既给了 Agent 探索空间，又防止它在失败的方法上反复尝试烧 Token。边界越清晰，Agent 的行为越可控。

完成标准必须可验证。 "把所有视频处理好"不是一个好标准，因为没法判断什么是"处理好"。"所有 UP 主都已检查（无遗漏）、每个新视频都有对应摘要条目、日报已发送"是可以验证的。Judge 模型能自己检查这些条件是否满足。

9.5 什么时候该用哪种写法

不是所有任务都适合 /goal 模式。一个简单的判断框架：

用逐步指令：任务只有一条线性的执行路径，异常很少，完成标准不需要显式验证。比如 6.2 的"收到消息自动回复"，流程很简单，逐步指令足够了。

用 /goal 模式：任务有多个分支路径，可能遇到各种异常，需要验证最终结果。比如 UP 主监控器，要遍历多个 UP 主、处理字幕提取失败、最终验证日报是否完整。

实际使用中，两种写法经常混合使用。复杂任务的顶层用 /goal 定义目标和约束，内部某个关键子流程用逐步指令保证执行精度。比如你可以把字幕提取的完整 API 调用链作为一段逐步指令嵌入到 /goal 的上下文里，让 Agent 在这个子流程上不走弯路，同时保持整体流程的自主性。

9.6 ■ 学点英语