self-use-haiku-subagent git:20261025.742afa9A

Immutable. This exact content never changes and is served at /api/v1/blob/ad0c295bcb03ab77.

---
name: self-use-haiku-subagent
description: 把任务委托给 Haiku 5.5 子代理（claude-haiku-5-5，默认 high）时读本技能。单个子代理的上下文按 100k 规划；子代理不会压缩上下文，用到窗口上限就被终止，不留收尾消息，没写进文件的结果全部丢失。准备用 Haiku 5.5 派发任务、估算一个子代理能做多少、写子代理提示词，或者它报告 ran out of room 时使用。
metadata:
  author: Alice39s
  template: self-use-haiku-subagent/scripts/templates/SKILL.md.j2
---

# 用 Haiku 5.5 当子代理

## 调用方式

`subagent({ provider: "aigw", model: "claude-haiku-5-5", reasoning_effort: "high", ... })`

`provider` 是 DeepSeek Harness（DSH）provider 配置里的名字，换了环境就改成自己配的那一项。派发之前用 `list_subagent_models` 确认 model id 和档位都还能用。

`reasoning_effort` 用 `high`，DSH 里这个模型最高只到这一档。

## 上下文预算

单个子代理的总用量控制在 100k 以内，provider 配置里的 contextWindow 也建议设成 100000。这样设是因为 Haiku 5.5 的上下文超过 100k 以后按五倍计费。

子代理不会自动压缩上下文。用量碰到 contextWindow 时，DSH 直接终止它，返回 `ran out of room`。这时没有收尾消息，还没写进文件的结论全部丢失。

派发任务之前先估算一遍：

| 内容                                                  | 大致占用   |
| ----------------------------------------------------- | ---------- |
| 系统提示词、工具声明和任务提示词                      | 15k 到 25k |
| 用 `web_fetch` 读一整页网页或文档                     | 10k 到 40k |
| 一个源码文件，例如 raw.githubusercontent.com 上的文件 | 5k 到 20k  |
| 一次没有截断的部署或构建输出                          | 5k 到 15k  |
| 一次 `docker ps`、`ss -ltnp` 这类列表                 | 2k 到 5k   |

扣掉固定开销和 5k 左右的余量，留给任务本身的大约是 70k。估出来比这个多，就先把任务分成更小的几份再派发。

## 一个子代理做多少事

一个子代理只交付一样东西，并且同时满足下面几条：

- 只有一个产出物：一个文件、一个脚本，或者一份调研报告。
- 最多读 2 个外部网页或 4 个源码文件。资料比这多的时候，主代理先把要点查好写进共享文件，再派发子代理。
- 最多对一个远端系统做写操作。
- 预计 15 次工具调用以内能做完。

拿不准时这样判断：一个没有其他背景、只读过这份提示词的人，能不能在半小时内做完。做不完就把任务再分小一些。

下面三个任务都要先分开再派发。前两个各有好几个产出物，第三个要读的文件远远超过上限：

- 从头到尾包办一次部署：读文档、查指标、创建 API 令牌、写配置、写部署脚本、验证。
- 写数据采集脚本、做监控看板、把看板设成公开链接、写部署脚本、补 README。
- 一次调研十几个服务，每个都要读好几个源码文件。

一个子代理就能做完的任务：

- 写几条监控查询，逐条实际运行验证。
- 照着提示词里给的配置示例写一份配置并部署。
- 调研四个服务：一个要读文档写详细对比，另外三个搜索一次就能写出几行结论。

## 提示词怎么写

- 公共背景写进一个共享文件，例如项目结构、必须遵守的规则、会用到的地址列表。每个提示词只写「先读 <共享文件>」和这一次的任务，背景不在每个提示词里重复贴。
- 已经知道的直接写给它：版本号、文件路径、配置项名称、验证过的命令。子代理每多查一样，就多花一份预算。
- 尽量不让子代理读整页文档。主代理先把要点查好写进共享文件，或者点名具体文件的原始内容地址（例如 raw.githubusercontent.com 上的链接），要求只摘录需要的部分。
- 要求输出尽量短。只读的查询命令接上 `head`、`tail`、`jq` 或 `cut`。部署这类会改动远端状态的命令，管道接 `head` 会让命令中途退出，所以先把完整输出写进日志文件，再从里面只取变更、报错和汇总几行，例如 ansible 的日志用 `grep -E "changed|fatal|RECAP"` 过滤。复杂的命令先写成脚本文件再执行。
- 写明允许哪些副作用。提示词里没写到的写操作都不许做，例如重置管理员密码、新建账号、重启服务。
- 写明怎么收尾：报告写进哪个文件，用 `send_message` 发回的摘要不超过多少行（例如 10 行）。

## 每做完一项就写进文件

子代理中途被终止时，已经写进文件的结果还在，主代理可以直接接着用。所以提示词要把任务列成编号的几项，再加上这句：

> 每完成一项，就把这一项的结果追加到 <输出文件> 末尾，写完再做下一项。

## 派出之后

- 子代理启动以后，不管它还在运行还是已经结束，主代理用 `send_message` 发给它都会报 `active teammate not found`。中途没法补充说明，结束后也没法追问，所以提示词要一次把信息给全。
- 子代理不能再派发子代理。
- 子代理的报告是它自己的说法。主代理要亲自核对文件在不在、远端状态有没有真的变化、有没有做提示词以外的写操作。

## 子代理被终止以后

收到 `ran out of room` 时：

1. 先看它留下了什么：输出文件、仓库里新出现的文件（`git status`）、远端的当前状态。不要把同一个任务原样再派发一次。
2. 已经做完的部分由主代理接手并核对。
3. 剩下的如果几次工具调用就能做完，主代理自己做完更快。
4. 否则把剩下的部分分成几份，每份不超过原任务的一半，重新派出去。提示词里写明「<输出文件> 里已经有前 N 项的结果，从第 N+1 项继续」。