尧图网页设计 
起因多个 AI agent 共用一个 GitHub 账号很多开发者已经让对话式 AI 代跑开源贡献流程建分支、写 commit、开 PR、回 issue。随着 AI 工具增多豆包、atomcode、codex……一个现实问题出现了多个 AI agent 要共用你一个人的 GitHub 账号去操作。token 散落在各处、一个 token 干所有事出了权限问题分不清是谁的责任泄露了也不知道影响范围。我们的做法把 GitHub token 统一收进一个本地约定目录~/.config/github/按职责分文件跨会话、跨工具共享同一份约定。核心设计按职责分文件互不混用一张 Mac 上目前维护三个 token各管一摊只读 API tokenfine-grained跨项目查公共数据、提升 API 限流配额不能写任何东西玄铁上游一条龙 tokenclassicpublic_repo推 fork 分支 开上游 PR issue / 追评全部 API 自动化某个上游仓库的专用 PR tokenfine-grained只授权一个 fork 仓库仅用于给那个项目交翻译 PR原则三条最小权限、单一职责、互不混用。用文件而不是环境变量是因为多个会话、多个 agent 都要读同一份约定文件路径可复用、可审计环境变量只活在一个 shell 里撑不起跨会话协作。为什么玄铁仓的 token 用 Classic 而不是 Fine-grained玄铁XuanTie是一门开源中文编程语言我们作为贡献者要给它上游仓开 PR。踩过的坑fine-grained token 的「Only select repositories」只能选自己拥有的仓库选不到别人的上游仓库—— 开上游 PR 直接 403。classicpublic_repo覆盖所有公开仓库推分支、开 PR、回 issue 一条龙都够。还有一个隐蔽的坑重 fork 之后fine-grained 的授权列表会失效。授权列表挂的是旧仓库 ID删库重 fork 后推新 fork 分支照样 403。所以我们后来把「推分支 开 PR issue」合并进一个 classic token单一职责不再维护多个半残的 fine-grained。workflow scope推含 ci.yml 的分支被 GitHub 拒绝上游仓库一旦引入 GitHub Actions 工作流文件.github/workflows/ci.yml基于最新 master 建分支再推送就可能被 GitHub 拦下refusing to allow a Personal Access Token to create or update workflow .github/workflows/ci.yml without workflow scopeclassic token 的workflowscope 只能在新建时勾选已建 token 补不了fine-grained 需要加Workflows: Read and write网页交互还有个坑Settings 里的Generate new token 是下拉按钮要再点一下(classic)才进 classic 配置页提交约定诚实标注人类参与程度token 是基础设施标注规范是行为准则—— 两者配套才构成完整的协作约定。核心一条诚实。批准 ≠ 审阅声明只写「人类已在 Agent 对话中批准提交」不冒充「逐字审阅」提交 vs 追评两套标注创建 issue/PR、提交 commit 用「人类已批准」AI 自行追加的评论补验证、补测试结果用「AI 代理自行追加、未经人类逐字审阅」红线任何「人类已批准」的表述必须以人类真实批准为前提我们也犯过错给 closed issue 追评验证结论时尾巴误套了「人类已批准提交」—— 那条评论人类根本没批准。被指出后补上了「适用范围边界」追评是 AI 自作主张信息可以给措辞必须诚实。AI 自己查 CI不依赖人类截图协作里还有一个高频动作挂完 PR 后确认 CI 结果。以前靠人截图 PR 列表的对号、展开 checks、copy Actions 链接喂给 AI现在 agent 自己调 GitHub REST APIGET /repos/{owner}/{repo}/pulls/{n}/commits?per_page1 # 取最新 commit sha GET /repos/{owner}/{repo}/commits/{sha}/check-runs # 读 check runs解读规则check_runs为空 CI 未触发纯文档 PRpaths-ignore 生效 —— 没有对号是「跳过」不是失败每条 run 的conclusionsuccess 绿勾failure 红叉html_url就是该 job 的 Actions 页面链接省去手动 copy安全红线token 文件权限600仅本用户可读写严禁提交进任何 git 仓库、发到外部服务、贴公开渠道过期后重新生成并覆盖对应文件文件名保持不变使用方无需改动落地效果这套约定已经跨会话持续生效多个豆包会话、其他 AI agent 都读同一份文档。玄铁语言的 macOS/arm64 自举 PR、历史 issue 的验证追评、CI paths-ignore 配置的实测确认 —— 都是这套「按职责分文件 诚实标注」支撑下来的。可复用的一句话token 按职责分文件是基础设施标注规范是行为准则基础设施管「能不能」行为准则管「怎么诚实地用」。 GitHub Token 与 AI agent：跨会话协作 —— 按职责分文件与诚实标注
起因多个 AI agent 共用一个 GitHub 账号很多开发者已经让对话式 AI 代跑开源贡献流程建分支、写 commit、开 PR、回 issue。随着 AI 工具增多豆包、atomcode、codex……一个现实问题出现了多个 AI agent 要共用你一个人的 GitHub 账号去操作。token 散落在各处、一个 token 干所有事出了权限问题分不清是谁的责任泄露了也不知道影响范围。我们的做法把 GitHub token 统一收进一个本地约定目录~/.config/github/按职责分文件跨会话、跨工具共享同一份约定。核心设计按职责分文件互不混用一张 Mac 上目前维护三个 token各管一摊只读 API tokenfine-grained跨项目查公共数据、提升 API 限流配额不能写任何东西玄铁上游一条龙 tokenclassicpublic_repo推 fork 分支 开上游 PR issue / 追评全部 API 自动化某个上游仓库的专用 PR tokenfine-grained只授权一个 fork 仓库仅用于给那个项目交翻译 PR原则三条最小权限、单一职责、互不混用。用文件而不是环境变量是因为多个会话、多个 agent 都要读同一份约定文件路径可复用、可审计环境变量只活在一个 shell 里撑不起跨会话协作。为什么玄铁仓的 token 用 Classic 而不是 Fine-grained玄铁XuanTie是一门开源中文编程语言我们作为贡献者要给它上游仓开 PR。踩过的坑fine-grained token 的「Only select repositories」只能选自己拥有的仓库选不到别人的上游仓库—— 开上游 PR 直接 403。classicpublic_repo覆盖所有公开仓库推分支、开 PR、回 issue 一条龙都够。还有一个隐蔽的坑重 fork 之后fine-grained 的授权列表会失效。授权列表挂的是旧仓库 ID删库重 fork 后推新 fork 分支照样 403。所以我们后来把「推分支 开 PR issue」合并进一个 classic token单一职责不再维护多个半残的 fine-grained。workflow scope推含 ci.yml 的分支被 GitHub 拒绝上游仓库一旦引入 GitHub Actions 工作流文件.github/workflows/ci.yml基于最新 master 建分支再推送就可能被 GitHub 拦下refusing to allow a Personal Access Token to create or update workflow .github/workflows/ci.yml without workflow scopeclassic token 的workflowscope 只能在新建时勾选已建 token 补不了fine-grained 需要加Workflows: Read and write网页交互还有个坑Settings 里的Generate new token 是下拉按钮要再点一下(classic)才进 classic 配置页提交约定诚实标注人类参与程度token 是基础设施标注规范是行为准则—— 两者配套才构成完整的协作约定。核心一条诚实。批准 ≠ 审阅声明只写「人类已在 Agent 对话中批准提交」不冒充「逐字审阅」提交 vs 追评两套标注创建 issue/PR、提交 commit 用「人类已批准」AI 自行追加的评论补验证、补测试结果用「AI 代理自行追加、未经人类逐字审阅」红线任何「人类已批准」的表述必须以人类真实批准为前提我们也犯过错给 closed issue 追评验证结论时尾巴误套了「人类已批准提交」—— 那条评论人类根本没批准。被指出后补上了「适用范围边界」追评是 AI 自作主张信息可以给措辞必须诚实。AI 自己查 CI不依赖人类截图协作里还有一个高频动作挂完 PR 后确认 CI 结果。以前靠人截图 PR 列表的对号、展开 checks、copy Actions 链接喂给 AI现在 agent 自己调 GitHub REST APIGET /repos/{owner}/{repo}/pulls/{n}/commits?per_page1 # 取最新 commit sha GET /repos/{owner}/{repo}/commits/{sha}/check-runs # 读 check runs解读规则check_runs为空 CI 未触发纯文档 PRpaths-ignore 生效 —— 没有对号是「跳过」不是失败每条 run 的conclusionsuccess 绿勾failure 红叉html_url就是该 job 的 Actions 页面链接省去手动 copy安全红线token 文件权限600仅本用户可读写严禁提交进任何 git 仓库、发到外部服务、贴公开渠道过期后重新生成并覆盖对应文件文件名保持不变使用方无需改动落地效果这套约定已经跨会话持续生效多个豆包会话、其他 AI agent 都读同一份文档。玄铁语言的 macOS/arm64 自举 PR、历史 issue 的验证追评、CI paths-ignore 配置的实测确认 —— 都是这套「按职责分文件 诚实标注」支撑下来的。可复用的一句话token 按职责分文件是基础设施标注规范是行为准则基础设施管「能不能」行为准则管「怎么诚实地用」。