📋 Agent-Runner 契约速查表

工作流(Orchestrator)和 AI 代理(Agent Runner)之间的"合同"。适用于所有 AI 驱动的工作流。

核心原则

工作流拥有所有 GitHub 写操作。AI 代理只输出文件。这条"接缝"让系统可测试、AI 可替换。

输入规范(工作流 → AI)

通道规范示例
环境变量 通过 env: 传入,命名用 UPPER_SNAKE_CASE ISSUE_NUMBERISSUE_TITLEBRANCHPR_NUMBER
上下文文件 工作流用 gh CLI 预获取,存在 $RUNNER_TEMP issue-context.jsonPR_COMMENTS_JSON
Git 工作树 工作流负责 checkout 到正确的分支/commit actions/checkout@v4 with ref: and fetch-depth:
输出目录 通过 OUTPUT_DIR 环境变量告知 AI 写入位置 通常设为 $RUNNER_TEMP

输出规范(AI → 工作流)

文件由哪个工作流写入工作流怎么读取
analysis.md Analyze Issue cat analysis.md | gh issue comment --body-file -
failure_reason.txt 所有(失败时) gh issue comment --body-file failure_reason.txt
pr_title.txt Implement gh pr create --title-file pr_title.txt
pr_description.txt Implement gh pr create --body-file pr_description.txt
has_commits.txt Implement PR 读 "true"/"false" 决定是否 push
should_push.txt Update Branch 读 "true"/"false" 决定是否 push
comment.md Update Branch gh pr comment --body-file comment.md
summary.md Review 诊断/记录用
verdict.txt Review 决定 PR 是"ready"还是"needs changes"
review_payload.json Review 结构化评审数据(评论、行级建议等)
replies.json Implement PR 针对每条评审评论的回复
architecture_review_output.json Architecture Review PRD 提案的结构化数据

可靠性模式

单次通过(side-effect-free 任务用)

适用:只是生成内容,不修改仓库(比如写 PR 标题/描述、拆解 PRD 为子 Issue)。prompt 带输出 schema,验证失败则重试(同一 session,最多 N 次)。

生产-提取分离(有副作用的任务用)

适用:会提交代码或评论的步骤。

  1. 生产阶段:运行工作 prompt,不带输出 schema。即使输出格式错误,代码/评论也已经产生了。
  2. 提取阶段:恢复同一 session,用"只输出结构化数据,不要改任何东西"的 prompt + schema,重试提取。

为什么?如果一次 LLM 调用既做工作又输出严格 JSON,格式错一个字段整个运行就失败了——包括副作用。分离之后,工作不会丢,提取可以重试。

凭证

Secret用途
GITHUB_TOKEN内置。工作流用于大部分 tracker 操作(标签、评论、PR 管理)。
AGENT_PAT强烈推荐。用于需要触发下游工作流的操作(绕过 GITHUB_TOKEN 的递归抑制)。
Agent-runner credential必须。认证 AI 服务。sandcastle 用 CLAUDE_CODE_OAUTH_TOKEN

AI 权限控制

工具风险何时允许
Read始终
Grep始终
Glob始终
Write会修改文件Implement 工作流
Edit会修改文件Implement 工作流
Bash会执行命令需要编译/测试的工作流
原则:只给 AI 完成当前任务所需的最小权限。Analyze Issue 只需读权限;Implement 需要写权限;Review 需要读取 PR diff 的权限。

参考文档 相关课程:第 4 课 →