自动化与多 Agent 协作¶

先稳定掌握日常开发工作流和项目规则。非交互 CLI/API 是否受支持，逐款看工具篇；不要套一个伪通用命令。

什么时候值得自动化¶

适合重复、输入边界明确、结果可检查的任务，如整理只读报告或固定格式校验。涉及删除、发布、凭据或不可逆操作时保留人工确认。

选择受支持的入口¶

检查所用工具官方 CLI/API 是否有非交互模式，记录输入参数、输出、退出状态、认证和审批默认值。没有官方接口时就保留交互操作，不模拟按键或绕过确认。

设计输入和结果¶

固定工作目录，引用路径，区分 stdout/stderr，保存版本、日志、退出码和改动摘要。进程返回 0 不代表业务验收通过；仍需检查产物和 diff。

脚本化一个只读任务¶

以普通 shell 脚本为结构示意；把 <工具官方非交互参数> 替换为对应 Harness 文档明确支持的参数，不要原样运行占位符：

set -o pipefail
tool "<工具官方非交互参数>" > "agent-output.log" 2> "agent-error.log"
status=$?
printf 'exit=%s\n' "$status"

真实脚本还需固定工作目录、检查退出码并防止密钥进入日志。先在测试仓库运行。

进入 CI 前的准备¶

单独配置最小权限凭据，避免把私人订阅登录态复制进 CI。明确哪些命令可以无人值守，产物由谁批准；首次只运行只读检查。不修改本站部署流程。

多 Agent 的分工与隔离¶

先拆成独立、只读子任务，再安排一位主 Agent 汇总。一写一审时审阅者不同时修改同一工作树。若并行写入，使用不同分支或 Git worktree，之后人工解决冲突并检查完整 diff。内置协作能力因 Harness 而异，不等同于多个终端。

Herdr 在协作中的位置¶

Herdr 可组织终端与 Agent 会话；它不替你定义任务授权或确保结果正确。按Herdr 教程在明确 pane 和工作目录下操作。Agent 完成状态仍需人工验收。

失败与恢复¶

保存失败日志和当前 diff；重试前确认上一轮是否已产生部分修改，避免重复投递。超时、审批等待和任务失败需要分别处理。限定重试次数，不做无限自治。