webhook.github.issues · opened
故事从一个人遇到问题开始。
贡献者打开熟悉的 GitHub Issue 页面,写下现象、影响与复现方式,然后点击 “Submit new issue”。提交完成后,画中画亮起:agent-compose 第一次介入。
NO SPECIAL COMMAND OR BOT MENTION REQUIRED
它运行在 agent-compose 上,也为 agent-compose 自己处理 Issue、修改代码和修复 CI。
贡献者打开熟悉的 GitHub Issue 页面,写下现象、影响与复现方式,然后点击 “Submit new issue”。提交完成后,画中画亮起:agent-compose 第一次介入。
使用者看到 labels 和一条分诊评论陆续出现。画中画同步点亮 Webhook、Scheduler、Agent 与受管写入,让幕后执行变得可见。
问题清楚、范围合适时,维护者在 GitHub 标签菜单中选择
agent:ready。这不是普通状态标记,而是允许 Agent
修改仓库的明确授权;在此之前,画中画会一直显示 WAITING。
Issue 进入 agent:running。agent-compose 在全新
sandbox 中挂载隔离 checkout;Agent 可以编辑和测试,但拿不到 GitHub
凭据,也不能 commit 或 push。
可信外层验证 diff、测试、secret 与风险后,才替 Agent commit、non-force push 并创建 Draft PR。使用者直接看到摘要、测试和完整改动。
失败的 check suite 或可信 Reviewer 的 changes requested 会触发一次新的隔离运行。Agent 验证问题并修复;每批最多一个 commit,绝不 force-push。
完整 diff、测试和修复记录都在熟悉的 GitHub PR 页面里。Workflow 在这里停下:是否标记 ready、是否 merge、是否关闭 Issue,始终由维护者决定。
配置声明 Agent、Skill 和 Scheduler;运行时再把事件、隔离环境与可信写入依次点亮。
agents: issue-triage: skills: [issue-triage] scheduler: sandbox_policy: new concurrency_policy: parallel draft-pr: skills: [draft-pr] scheduler: sandbox_policy: new
打开 Agent Compose UI,查看一次真实 Issue,或直接阅读 Workflow 源码。