Herdr + Pi：我现在的个人开发工作流
从 Cursor 迁到 Herdr 之后的主力工作流：Pi 负责调度，Herdr 负责终端，worktree 负责隔离，review 负责验收。
Cursor 还在，但主力已经不是它了。
现在的工作流是：在 Herdr 里开 Pi，Pi 里挂一组插件，任务按 worker 分出去，改动落在独立的 git worktree，最后自己 review 一遍再合并。
为什么从 Cursor 迁走
Cursor 最擅长的是“在编辑器里改一段代码”。但我现在的工作越来越多是“让 agent 跑完一个任务”：读仓库、改多处、跑测试、写报告。
这两件事的瓶颈不一样。
- 单会话、单上下文：任务一长，agent 就开始漂；多个任务只能排队。
- 编辑器不是主战场：脚本、测试、部署、数据校验都在 shell 里。
- 并行靠人肉：开几个窗口，就得自己记谁在改哪个文件。
Cursor 解决的是“写代码”，我现在更需要“调度和验收”。
现在这套栈
| 工具 | 作用 |
|---|---|
| Herdr | 终端、工作区、窗格；worker 的可见运行环境 |
| Pi | agent harness，主 agent 在这里 |
pi-herdr |
提供 herd / herdr，把任务分给命名 worker |
pi-plan-mode |
/plan 只读规划，先审计划再改 |
pi-worktree |
/worktree 为任务开独立工作区 |
pi-code-indexer |
本地代码索引和符号图，减少大范围 grep |
pi-lsp |
定向 diagnostics 和 source fix |
pi-stop |
随时停：/stop、快捷键、外部脚本 |
pi-goal |
长任务目标模式，带自动轮次和预算上限 |
pi-auto-fallback |
429 / 5xx 时自动切换模型 |
pi-web-access |
查资料、读文档、抓网页 |
| ripgrep / fd | 搜索文件和内容 |
安装
Ubuntu 上先补两个搜索工具。fd 的包名是 fd-find，命令也叫 fdfind，需要做一个软链接：
apt install -y ripgrep fd-find
sudo ln -s "$(which fdfind)" /usr/local/bin/fd然后把 Pi 的插件一次装齐：
for pkg in \
'npm:@itc-steve/pi-herdr' \
'npm:pi-web-access' \
'npm:@narumitw/pi-plan-mode' \
'npm:pi-stop' \
'npm:pi-code-indexer' \
'npm:@narumitw/pi-lsp' \
'npm:@narumitw/pi-worktree' \
'npm:@narumitw/pi-goal' \
'npm:pi-auto-fallback'
do
echo "===== Installing $pkg ====="
pi install "$pkg" || echo "FAILED: $pkg"
done装完 /reload，再用 pi --list-models 确认模型连接。
Pi 侧配置
settings.json 里只留最关键的四项：默认 provider、默认模型、thinking 级别，以及允许 agent 使用的工具。
{
"allowedTools": ["herdr", "herd"],
"defaultProvider": "deepseek",
"defaultModel": "deepseek-flash",
"defaultThinkingLevel": "medium"
}models.json 负责注册 provider 和模型 ID。worker 配置里写的 deepseek/deepseek-flash、glm/...，都是从这里的 provider/model 来的。
模型和 worker
我现在主要用两家模型：DeepSeek 和 GLM。
- DeepSeek Flash：日常规划、检索、审查，快而且便宜
- DeepSeek Pro：更难的推理和长任务
- GLM：主力 coder，thinking 开到 high
每个任务按需要选 worker。herd.json 里我留了五个角色：
| worker | 模型 | 适合什么 |
|---|---|---|
| planner | DeepSeek Flash / high | 复杂任务拆解、方案比较 |
| research | DeepSeek Flash / medium | 代码库探索、日志排查、资料汇总 |
| quick | DeepSeek Flash / low | 简单检索、小任务 |
| coder | GLM / high | 功能实现、重构、修 bug |
| reviewer | DeepSeek Flash / high | 独立审查 diff 和回归风险 |
herd.json 里给每个 worker 写 model、thinking 和 maxConcurrent。模型 ID 用 provider/model，具体以 pi --list-models 为准。
maxConcurrent 限制的是同时运行的数量，不是能排队的数量。小任务可以一次排很多，但真正跑起来的只有配置允许的那几个。
一个任务怎么走
1. 先 /plan
复杂改动先开 Plan 模式。它只读，不允许改文件，先把仓库读一遍、把问题问清楚，产出一份可执行的计划。
这一步主要是把仓库读一遍、把问题问清楚，产出一份可执行的计划，再决定改哪些文件。
2. /worktree 开一个独立工作区
每个任务一个 branch、一个 worktree，主分支保持干净。agent 改坏了就删掉工作区，不影响正在跑的其它任务。
3. 把任务分给 worker
主 agent 用 herd spawn 创建任务。写任务时至少要说清楚：
- 目标是什么
- 输入在哪
- 允许改哪些文件（
owns=） - 验收标准和验证命令
- 什么情况下停
owns= 很重要。两个 worker 改同一批文件会排队；没有写 owns= 的任务默认只读，只出报告。
4. 读报告，再验收
任务完成不等于可以合并。主 agent 要读 output= 指定的报告，检查改了哪些文件、跑了什么命令、哪些没验证，然后才 accept。
5. 独立 review，再合并
coder 写完，reviewer 单独看 diff。可以让 reviewer 用另一家模型，避免同一个模型自己审自己。
最后自己再读一遍 diff，确认没问题才合并回主分支。agent 的输出要停在一个可以 review 的边界上，而不是直接进主分支。
最后自己读 diff
这套工作流里，review 是必须的一步。
- 一个任务一个 worktree / branch
- 一次提交只做一件事
- diff 必须自己读一遍
- 至少一次独立 review
- 不自动合并
Agent 跑得越快，diff 越要自己读。否则最后只是把“写代码”变成了“读一堆不知道对不对的 diff”。
这套工作流的成本
Cursor 是订阅制，长期用下来是一笔固定支出；这套没有订阅费，成本主要在模型调用。模型按 token 计费，检索和审查可以用便宜的，写代码再用强一点的。不过它也不是无条件更便宜：任务拆得多、上下文给得长，token 一样会上去。时间主要花在配置和验收上。
- 要配模型、配 worker、配 worktree
- 要写清楚任务边界，不能只说“帮我改一下”
- 要读报告、读 diff、跑验证
- 多 agent 会制造更多需要清理的中间状态
所以小改动我还是直接改。只有任务足够大、边界足够清楚、验证足够明确时，才值得分出去。
最后
工具换了几轮，瓶颈其实没变：上下文、边界、验证。
Cursor 让写代码变便宜了；Herdr + Pi 做的是另一件事：让“谁在做什么、改到哪里、什么时候停”变得可见、可停、可审。
这套流程还在变。但至少现在，我知道每个 agent 在哪、在改什么，以及什么时候该让它停下来。