企业官网建设流程全解析

• 人工智能
• AI 应用
• AI 评测
• RAG
• 微调
• 提示工程
• 开发工具
• 桌面应用

导读

本文以 Kiln 仓库中specs/projects/model_sweep/smoke_log.md为骨架，完整复盘 "Model Sweep"（模型扫描）这一自动化例行任务从首次云端冒烟、环境排障、规则迭代到稳定定时的全过程：它每天清晨自动读取 Slack#models频道的模型线索，在ml_model_list.py中增删模型、跑付费测试、开 PR、播报 Slack、维护模型过时报告。读完本文，你将理解一个"AI 自主运维 GitHub 仓库"的例行任务在设计上会遇到的真实问题（网络策略、密钥、身份、PR 规范、反馈回路），以及 Kiln 团队是如何用一条条可验证的规则把这些坑逐一填平的。

smoke_log.md 属于specs/projects/model_sweep/系列文档（另含 project_overview.md、architecture.md、functional_spec.md、implementation_plan.md、routine_prompt.md），是一个真实的运行日志：记录了 2026-10-01 至 10-05 期间共 6 次运行、多次规则裁定与若干次环境修复。文中所有事实均出自该日志及相关设计文档，仓库源码用于印证底层机制。

背景：Model Sweep 是什么

Model Sweep 是 Kiln 的一个"生产率黑客松"项目（2026 年 10 月）。目标一句话概括：让每天早上的模型维护工作不再需要人肉驱动。此前的手动流程是：有人在#models发模型链接并 @ 操作者，操作者再 @ 云端 Claude 说"读取.agents/skills/claude-maintain-models/SKILL.md并照做"，而且云端会话跑不了付费测试，PR 只能本地收尾。

例行任务成型后，每个工作日早上它自动完成：读取#models的线索 → 发现新模型 → 把"简单"的加进 ml_model_list.py → 用付费测试验证 → 找出已确认死亡的模型并标记废弃 → 以 PR 形式提交 → 在 Slack 播报草稿 PR → 处理 PR 上的反馈 → 刷新跨仓库的模型过时（staleness）报告。安静日的成功态就是沉默：没有 PR、没有 Slack 消息（staleness 报告仍然刷新）。

架构上，例行任务遵循"确定性脚本 + 模型判断"的分工：凡是"有正确答案"的步骤（环境准备、发现、付费测试、分类、废弃审计、开 PR、Slack 发布）都由.agents/skills/kiln-model-sweep/下的小型确定性脚本执行；模型只做需要判断的事（读 Slack 线索、写 PR 正文、写需要讨论的评论、决定如何回应 PR 评论）。具体组件与数据流可参考 architecture.md。

而 smoke_log.md 的价值在于：它把这个例行任务从构想推向 v1 定型的全部证据——哪些决策是冒烟测试驱动的（而非拍脑袋），哪些环境问题被现场修复，哪些规则是在真实运行中因为翻车才加上去的。

Run 1：首次云端冒烟（2026-10-01）

第一次运行是人工启动的冒烟测试：例行任务当时被创建为 disabled 状态，cron 计划为0 11 * * 1-5（UTC，即美东工作日早上），运行环境是操作者的 Claude Code 云端环境，模型 Opus 5.5，工具为 Bash、Read、Write、Edit、Glob、Grep、WebFetch、WebSearch，提示词为当日的routine_prompt.md。

创建时的一个意外发现：云 API自动附加了账号在 claude.ai 上已连接的 connectors（Slack、Linear、Claude Docs、Claude Code Remote），因此 hints 步骤里多了一个 Slack 工具。Linear 与 Claude Docs 用不上，本轮之后被裁剪到只剩 Slack。

本轮要回答五个问题，构成了整个冒烟的核心：

过程中的关键发现（9 分钟、17 分钟、27 分钟时间点）

• Slack connector 可用：成功读取#models最近 7 天消息。
• GitHub MCP 工具可用：云端会话里有mcp__github__*系列工具。
• 密钥以环境变量形式存在：OpenAI、Anthropic（以KILN_ANTHROPIC_API_KEY桥接）、Gemini、OpenRouter、Fireworks（含 account id）、TogetherAI、SiliconFlow、Cerebras、Groq、Featherless、Vertex project id；未设置HUGGINGFACE_API_KEY与TOGETHER_API_KEY。
• 发现结果：经 models.dev、OpenRouter、各 provider 的/models端点与网络搜索，发现 10 个新模型 + 3 个滞后 provider 回填；GPT-6.1 Sol 因add-model/gpt-6-1-sol已有打开中的 PR 而被跳过；Gemini 4 Argon 当时尚未出现在 API 中。
• 编辑动作：修改 ml_model_list.py（+228 行），单元测试通过。
• 付费冒烟的真实翻车：Muse Glimmer on Fireworks 在目录里有条目，但实际调用返回NOT_FOUND "not deployed"；按规则被拆分到 needs-discussion 项。其余 8 个模型的全量付费套件继续运行。
• 环境瑕疵一：沙箱uv（0.8.17）无法解析 pyproject 中的exclude-newer = "7 days"（每次 uv 命令都告警），且环境未配置 setup script（日志提示 "No setup script configured"）；团队的 VM 配置包装脚本可同时解决这两个问题。
• Q2 答案（17 分钟时确认）：mcp__github__get_me返回的是操作者的 GitHub 登录名。也就是说，云例行任务产出的 PR 与评论会以操作者身份署名，直到出现 bot 身份。
• Q3 答案（17 分钟时确认）：8 个新模型的付费全量套件结果——141 passed，1 flake（MiMo V2.6 Flash，结构化输出 CoT），用-n 0串行重试后通过，65 skipped，8 个 collection errors（环境无tkinter，桌面测试无法收集）。Qwen 3.8 Omni Flash 的音频/视频抽取测试通过。
• 废弃审计：check_provider给出 12 个候选；11 个在 Kiln 的 adapter 测试中 not-found 失败，glm_5on SiliconFlow 返回 403 "Model disabled"，deepseek_4_proon Together 是 "non-serverless, create a dedicated endpoint"。其中 10 条在独立 worktree 分支model-sweep/deprecations-2026-10-01上被标记deprecated=True。
• Q4 网络策略缺口：remote-config.getkiln.ai与api.together.ai被沙箱代理拒绝（connect_rejected）。前者通过直接读取 checkout 中的built_in_models绕过（这也正是 spec 想要的）；Together 目录读取失败，但 Together 付费测试仍可通过api.together.xyz工作。
• 环境自修复：uv版本不符（仓库要求required-version >= 0.10）→ 运行改写uv.lock后安装 uv 0.12.21 并恢复 lock；无node_modules→ 执行npm ci；无tkinter→ 桌面测试在此环境无法运行。
• 27 分钟时：付费套件完成，废弃与讨论分支已在独立 worktree 中备好，npm ci与checks.sh运行超 10 分钟转入后台，PR 正文正在按每个测试的证据撰写（例如 Grok 4.7：17 passed, 10 skipped；Qwen 3.8 Omni Flash：22 passed, 5 skipped）。

本轮沉淀的云端环境修复清单

冒烟日志明确记录了操作者云环境的三个待办，属于环境即一等公民的经典案例：

1. Setup script：把.config/utils/claude_code_vm_setup.sh粘贴进环境的 setup-script 字段，消除每次运行都要做的uv sync、npm ci，以及 uv 版本不匹配（沙箱 0.8.17 对仓库要求的 >= 0.10 会反复改写uv.lock）。
2. 网络白名单：加入remote-config.getkiln.ai与api.together.ai（废弃脚本两个都要用；api.together.xyz已放行）。
3. tkinter 缺失：app/desktop/test_desktop.py无法收集，checks.sh在这里永远显示这些 collection errors——要么在 routine prompt 里接受，要么在 setup script 里补装。

checks.sh 超时引发的"定向检查"改造

uv run ./checks.sh --agent-mode在 4 vCPU 沙箱中运行超过 25 分钟被杀死（exit 143），随后运行开始逐个二分各检查项（ruff、format、ty、schema、web checks）。下一版 prompt 的修复：用定向检查替换完整checks.sh——ruff check、ruff format --check、ty check、OpenAPI schema 检查、web 的 format/lint/check 三件套，外加pytest libs/core/kiln_ai/adapters/test_ml_model_list.py；完整套件留给 CI 在 PR 上跑。注意open-pr技能的 S1 步骤会要求checks.sh，因此 routine prompt 必须显式声明"以定向检查集代替之"。仓库中的 checks.sh 是一个并行运行 ruff/format/ty/pytest/构建等检查的脚本（--agent-mode只输出失败项，为 AI Agent 节省 token）。

三份 PR 与结果

16:41 UTC 运行结束：成功，55 分钟，95 轮交互，在Kiln-AI/Kiln上开出三份 PR，全部以操作者的 GitHub 账号署名：

• CI：三份 PR 上每个结束的检查全绿（Python 3.10 至 3.13、lint、schema、web UI、Socket）。CodeRabbit 因WIP:前缀而跳过。
• 自反馈回路：最终报告后，会话又因自己 PR 的 GitHub 通知醒了三次并做了分流（CI、coverage）。也就是说，评论或 CI 失败会以同样的方式唤醒它——运行开出的 PR 天然带一个无需额外接线的反馈回路，只要会话还存在。
• 推送：运行还推送了一条移动端通知，带 PR 链接。

本轮之后的 prompt 变更（routine 于 2026-10-01 更新）

1. 所有 PR 读写改用 GitHub MCP 工具——沙箱中gh的 token 无效（gh auth status报告GH_TOKEN无效），而git push与mcp__github__*正常；gh在 skills 和 routine prompt 中一律不用。
2. 用定向检查替换checks.sh，并在 PR 正文中将tkinterimport 失败标注为环境因素。
3. 废弃审计改读 checkout 中的built_in_models；使用api.together.xyz。
4. 沙箱 uv 低于仓库要求版本时先升级；永不提交uv.lock。
5. connectors 裁剪到仅 Slack；例行任务启用，cron0 11 * * 1-5。

Run 2：环境修复后的"安静日"验证（2026-10-01）

第二次运行前，操作者对云环境做了修复：粘贴团队的 VM setup script、设置UV_SYSTEM_CERTS=true、网络白名单追加raw.githubusercontent.com、cdn.playwright.dev、playwright.download.prss.microsoft.com、remote-config.getkiln.ai、api.together.ai。

本轮要回答四个问题：

1. setup script 是否在 provisioning 时生效（日志应不再有 "No setup script configured"），沙箱是否自带可用的uv、venv 与node_modules？
2. 对已打开的model-sweep/*PR 去重后，是否无事可加？
3. 安静日是否以"无 PR + 简短报告"收尾？
4. 去掉环境开销后的时长？

结果（16:55 UTC）：成功，安静日。Setup script 在 provisioning 时运行（56 秒），uv0.12.21 已在。Agent 时间 91 秒，18 轮交互。运行读取了#models、列出打开中的 PR、拉取三份model-sweep/*分支对比，发现提示的模型已在main或打开中的 PR 里，于是什么都没开，并在报告中说明原因。因无任何变化，未重跑废弃审计或付费测试。

它还把 Run 1 没加的一批 OpenRouter 条目推迟（GPT-6 Sol Pro、GPT-6 Luna Pro、GPT-6.1 Sol Pro、Command A Plus、Solar Mini 4、Aion 3.5、Perceptron Mk1.5、Ternary Bonsai 2 27B、Unbiased Pareto）——理由是"推迟给更早的扫描"；日志特意指出：正常早晨的运行没有更早的扫描可 defer，所以这些条目下次会被全新判断。两个新放行的域名本轮未实际用到（prompt 仍绕行，这本来就是更偏好的行为），付费测试与 PR 创建也未涉及。

Run 3：由操作者驱动的端到端复现（2026-10-01 ~17:45 UTC）

操作者关闭了 #1849、#1850、#1851，并在云环境上设置 webhooks 后重跑例行任务。结果：

• #1854：新增 8 个模型 + 8 个 provider 回填（ready 态）。
• #1853：10 条已死条目标记 deprecated（ready 态）。
• #1852（draft）：Together 不再提供deepseek-ai/DeepSeek-V4-Pro，但该条目携带 suggested flags，扫描提出改用-0813slug 并询问。
• 三份 PR 正文都带 TLDR；#1852 带Decisions required区块；三份 PR 下均无操作者账号的评论（遵守"不写评论"规则）。
• Slack 双通道端到端打通：#1852 的草稿帖 13:53 EDT 落在#models（含 why 与选项）；#1853、#1854 的 ready 帖落在#prs，各带一句来自 PR TLDR 的 Summary。
• 当天队友在#models提出合并main -> remote_config，这促成了 prompt 中的remote-config 发布检查步骤。

远程配置发布检查（2026-10-01 加入）

Kiln 客户端从发布的远程配置读取模型列表，发布由 publish_remote_config.yml 在推送到remote_config分支时执行：它先跑向后兼容测试test_backwards_compatibility_with_v0_19，再由uv run python -m kiln_ai.adapters.remote_config从ml_model_list.py、ml_embedding_model_list.py、reranker_list.py生成kiln_config_v2.json并部署到 Cloudflare Pages。这一点与 remote_config.py 中REMOTE_MODEL_LIST_URL = "https://remote-config.getkiln.ai/kiln_config_v2.json"、dump_builtin_config/refresh_model_list等实现相互印证。

日志从历史确认了发布流程（PR #1557、#1605、#1631、#1756 都是 headmain进 baseremote_config，由人合并；另有维护者直接 force-pushmain到remote_config的路径：2026-08-17、08-19、09-28）。每次推送都会触发 "Publish Remote Config" 成功运行。当前线上kiln_config_v2.json有 264 个模型，与remote_config分支一致（含 Opus 5.5、GPT-6 Sol、Gemini 3.8 Flash；缺 Sonnet 5.5 与 GPT-6.1 Sol——这两个在 force-push 之后才落到main）。

日志记录了两个实操坑：

• gh run list --event push会少报这些运行；actions/runs?branch=remote_config原始 API 才是可靠检查。
• 打开中的 #1810（headmain进remote_config，2026-09-23 打开，28 个检查全绿、MERGEABLE/CLEAN）被视为"人类打开的待处理 PR"：例行任务只报告、不开新的。副作用：只要有这种 PR 存在，每次推main都会触发发布工作流的 pull_request job（仅兼容性测试，不部署）。合并 #1810 即可发布 Sonnet 5.5、Sonnet 5、GPT-6.1 Sol 与三条 Fireworks 废弃。日后发布 PR 转为例行任务代开，等待期间每天收到Updates刷新。

prompt 随之更新到 v4，routine_prompt.md与线上例行任务保持一致。

Slack 播报机制（2026-10-01 定案）

• 工作区没有可用的 Workflow Builder webhook trigger，因此载体是操作者创建的一个 Slack app，带两个 incoming webhooks：一个进#models，一个进#prs。
• 路由规则：需要决策的 draft PR →#models；直截了当的 PR →#prs；draft 标记 ready 后 →#prs且摘掉needs-discussion标签。
• 备选载体是 GitHub Action.github/workflows/model_sweep_announce.yml（草案），监听model-sweep/*分支的pull_request: opened, ready_for_review，需要两个仓库 secrets：SLACK_MODELS_WEBHOOK与SLACK_PRS_WEBHOOK（操作者只有 push/triage 权限，需 admin 添加）。
• 最终决策（2026-10-01）：例行任务自己发帖。操作者在云环境设置SLACK_MODELS_WEBHOOK、SLACK_PRS_WEBHOOK环境变量，prompt 携带同路由的发布步骤。Action 保留为 v2 载体（同名 secrets），且它是唯一能在事件发生时宣布 ready-for-review 转变的通道。
• 载体验证：2026-10-01 13:19 EDT，从操作者机器向 Models webhook 发了一帖（draft #1851），成功落在#models，来自操作者的 Slack app bot（B0C61S3J4PL），mention 与 PR 链接渲染正常。

三条团队规则（2026-10-01）

冒烟期间的三条 team ruling 均被固化进 routine prompt：

• PR header rule（prompt v5）：例行任务预填模板头部（Description 已写；Small change；Mixed review；AI feedback addressed；Key decisions 填ML Model Update；No UI），Author Review 留给作者本人。当天即通过 REST body edit 应用到 #1852、#1853、#1854。
• WIP title rule：WIP:表示 draft；ready PR 用纯chore:标题；只有走向#models的 draft 保留WIP:。当天应用到 #1853、#1854；#1852 在 draft 期间保持WIP:。副作用：CodeRabbit 此前因前缀跳过了所有扫描 PR，此后 ready PR 能获得它的 review。
• Successor-slug rule（prompt v7）：源自 #1852 的#prs讨论——Together 用-0813替换deepseek-ai/DeepSeek-V4-Pro。规则：废弃旧 provider 条目 + 将继任者作为独立模型新增，这样钉在旧条目上的 evals 保留其历史。当天另开了一份人工请求的 PR 将规则应用到 DeepSeek V4 Pro，并取代 #1852。这条规则后来在源码层面也得到呼应：KilnModelProvider的deprecated字段（ml_model_list.py 第 462 行）正是"不再被特定 provider 支持"的标记。

Run 4：首次定时运行（2026-10-02 07:05 America/Toronto）

按 cron 在 11:05 UTC 触发。墙钟 42 分钟，其中约 15 分钟浪费在第一次付费测试调用上——它无输出且撞上运行自身 25 分钟超时；改为输出到文件后重跑只花 4 分钟。Setup script 在 provisioning 时运行、uv是最新的、web 检查通过。

• 自动应用 successor-slug 规则：Fireworks 用-0813替换了 DeepSeek V4 Pro 预览 slug，于是运行将DeepSeek V4 Pro 0813作为独立模型加在 OpenRouter 与 Together AI 上（27 个付费测试通过，3 个 logprobs 测试跳过），以 ready PR #1871 提交（纯chore:标题 + 预填 header）。同一 checkpoint 的 Fireworks 条目 11 个测试全部 404 "not deployed"（重试亦然），转入 draft #1872 并带Decisions required区块。两份 PR 均未发评论。
• 废弃审计：无新死亡。仅报告：OpenRouter 在旧 slug 旁列出qwen/qwen3.8-max-0902（旧 slug 仍应答）；13 个 OpenRouter 过期日期在 2026-10-08 至 2026-12-31 之间；Fireworks 的 router slugs 在 detail API 返回 403 但仍应答 chat 调用。
• 远程配置：四个文件上remote_config与main一致；发布 PR #1859 前一天已合并，#1810 已关闭。无事可做。
• Slack：ready 帖进#prs、draft 帖进#models（均为 07:47 EDT，均带 why），移动端推送已发。
• 值得注意的行为：报告后，会话自行取消订阅了两份 PR 的 GitHub 活动，理由是保持订阅会与"不评论规则"冲突。因此 CI 或 review 的跟进要等下一次运行。
• 另一个观察：团队的 Slack bot 现在会给请求了 reviewer 的 PR 在#prs发带 reviewer 状态的卡片。扫描的 PR 不请求 reviewer，所以没有卡片；从扫描侧请求 reviewer 反而会让 webhook 帖冗余。

例行任务改从分支读取技能（2026-10-02 14:35 UTC）

此前 routine 的消息里携带一份技能文本的副本，导致对 PR 分支的提交在副本被手工更新前毫无效果。修复：消息只放运行设置 + 一条指令——

git fetch origin <branch> && git show origin/<branch>:.agents/skills/kiln-model-sweep/SKILL.md > /tmp/kiln-model-sweep.md

读取并严格遵循该文件。打开的 PR 因此成为"测试床"：编辑落到分支上，第二天早上的运行就用新版本，运行发现又回流到分支；合并后消息里的分支名改为main。这正是 routine_prompt.md 目前描述的形态："你的指令在仓库里，不在这条消息里"。fetch 失败或文件缺失时，运行必须停下报告，而不是即兴发挥。

Run 5：分支馈送例行任务的验证（2026-10-02 14:38 UTC）

第一次消息里不再携带副本、而是从mike/model-sweep分支获取技能的运行。拉取与读取成功（115 行），随后遵循技能执行：6 分钟，44 轮交互。

• 发现：目录相比早上无新内容；4 个候选在实况调用中失败被跳过（Together Kimi K2.6 "no deployments"、Together Qwen 3.8 Flash "third-party data sharing"、SiliconFlow diffusiongemma、Featherless MiMo distill "at capacity"）；无回填。
• 废弃审计：OpenRouter 不再列出qwen/qwen3.8-max，Fireworks 的 detail API 对两个 router slugs 返回 403；三者都通过 Kiln 的 smoke test，故没有标记任何条目。仅报告：6 个 OpenRouter 过期（10-08、10-09）、Gemini 2.5 三兄弟（10-20）、Seed 1.6（11-11）、GLM 4.5/4.7（12-31）。
• 远程配置：维护者 14:18 UTC 合并 #1873 进remote_config，但四个源文件相对main仍有"注释清扫"差异，于是运行从两个 ref 各自生成配置 JSON 并对比，发现 JSON 相同，没有开 PR——这条检查随后被写进技能。这印证了 functional spec 的原则：注释变更不产生发布。
• 收尾状态：#1854 已合并、#1872 被人关闭、#1871 的 review 线程已解决且 Author Review 已勾。无 PR、无 Slack 帖，只有一条关于 10-08/10-09 过期的移动推送。工作分支在结束时删除。

Run 6：第二次定时运行（2026-10-05 07:10 America/Toronto）

• 开了两份带Decisions required的 draft：OpenRouter 上的 GPT-6 Pro 三兄弟（四个 thinking-level 测试返回空 reasoning 文本，与已上架的 GPT-6 条目一致）和 Qwen 3.8 Max 0902 的继任迁移（旧 slug 携带 suggested flags 与 featured 排名）。
• 操作者在运行中的会话内直接答复：GPT-6 Pro PR 按原样合并、为三个模型建议用于 evals 与 data gen、把每个 Pro 放在对应 base 之上、检查 OpenAI 直连（它们不在那）；Qwen PR 则迁移 flags 与 featured 排名。运行把每条答复作为带日期的Updates行的提交应用，两份都标记 ready、去掉WIP:、发布到 PR 频道。现在编号为 #1894 与 #1895。
• 一个与模型无关的 Linux tray 测试让 #1895 的 CI job 失败；运行读取日志、重跑一次该 job、通过，未发评论。
• 会话保持订阅其 PR 并持续被 CI 与 review 事件唤醒（这就是中午仍显示在运行的原因，不是卡死）。

播报转交团队 PR bot（2026-10-05）

团队的 Slack bot（Kiln-AI/nathan，pr_management功能）会给"任何打开了 reviewer 请求的非 draft 跟踪 PR"在 PR 频道发布、维护一张归属到作者的 review 卡片（状态、提醒、周一报告）；draft 无卡片，只有给作者的 DM 提醒。当天 #1895 因请求了 reviewer 而有卡片、#1894 没有，且扫描自己的 PR 频道帖与卡片重复。

变更：扫描在每份 ready PR 创建时从运行设置请求 reviewer，自己不再在 PR 频道发帖；draft 保留#models频道帖；ready-for-review 转变改为请求 reviewer 而非发帖。SLACK_PRS_WEBHOOK不再被读取；未提交的 GitHub Action 草案（打标签 + 播报）被删除。同日补充裁定：remote-config 发布 PR 像任何 ready PR 一样由 PR bot 出卡片（请求 reviewer），扫描对它的 Slack 播报完全取消——即使它带着冲突或失败的兼容性测试（冲突/红 CI 会显示在卡片上，并在正文Decisions required说明）。

从冒烟日志提炼的可复用工程要点

1. 环境是一等公民，冒烟的首要产出是环境修复清单

Run 1 证明：例行任务能否跑完，取决于环境而非模型。setup script（消灭每轮uv sync/npm ci）、网络白名单（remote-config.getkiln.ai、api.together.ai）、运行时版本（uv >= 0.10）、OS 依赖（tkinter）每一条都对应一个真实故障。日志把它们整理成可粘贴的清单，是"环境即代码"的最佳实践。

2. 以冒烟测试决定宿主，而非事先拍板

functional spec 明确："宿主由冒烟测试决定，不是事先决定"。Run 1 证明云端能跑付费测试（操作者调用）、Run 2 证明修复后 91 秒安静收工、Run 3 证明端到端链路（PR + Slack 双通道）成立，v1 才定在云端例行任务，本地定时任务留作 fallback，v2（云脑 + GitHub Actions 手）为长期目标。决定链条全部记录在日志里。

3. 成功态是沉默

Run 2 与 Run 5 是最有说服力的证据：没有新模型、没有新死亡条目时，运行不开 PR、不发 Slack，只刷新 staleness 与报告。这也意味着**"无输出"不等于故障**——判断一个运行是否健康要看报告与分支状态。

4. 规则必须可计算、可测试、可固化

easy/needs-discussion 的划分由 diff 路径与测试结果计算得出（见 functional_spec.md §3），不依赖模型意见；三条团队规则（PR header、WIP 标题、successor-slug）当天就从裁定变成 prompt 版本并应用到真实 PR。这解释了为什么例行任务能稳定复现人类团队的约定。

5. 身份与安全边界

• 例行任务从不写 PR 评论、review 评论或 review（PR 以操作者账号署名，评论会读作他的话）；PR 正文与 commit message 是它唯一的声音。
• 密钥永不打印，可用性只以布尔值记录（sweep_env.sh打印HAS_<NAME>=true|false）。
• 永不 merge、永不 force-push；工作树用完即删；GitHub/Slack 写失败时报告精确的重试命令。

6. 反馈回路与"下轮延迟"

评论 → 下一轮运行读取 → 范围内请求（模型清单编辑、测试重跑、正文修正）推回 PR 分支并写入带日期的Updates节；范围外请求进入Decisions required并说明边界。会话对自身 PR 的通知自唤醒形成了分钟级反馈（Run 1），而取消订阅后回到"下轮延迟"（Run 4 起）。

相关文档与源码索引

• 冒烟日志：specs/projects/model_sweep/smoke_log.md
• 例行任务提示词（含从分支拉取技能的机制）：routine_prompt.md
• 设计文档：project_overview.md、architecture.md（组件、数据文件、模式与 flags、错误处理）、functional_spec.md（easy/needs-discussion 规则、预答的 consent gates、安全）、implementation_plan.md（六阶段状态）
• 模型清单本体：ml_model_list.py（ModelFamily、ModelName、KilnModel/KilnModelProvider、deprecated字段、built_in_models）
• 模型清单单元测试：test_ml_model_list.py（如test_all_built_in_models_have_valid_providers保证每个内置模型都有可用 provider）
• 远程配置加载与序列化：remote_config.py
• 发布工作流：publish_remote_config.yml
• 全套检查入口（被定向检查集取代的checks.sh）：checks.sh

说明：smoke_log.md 中提及的技能与脚本（.agents/skills/kiln-model-sweep/等）按设计文档约定随仓库分发，当前镜像仓库中未包含.agents/目录，相关机制以其在架构文档与 routine prompt 中的描述为准；文中 PR 编号、模型名、环境变量与运行时长均直接来自该冒烟日志。

• 人工智能
• AI 应用
• AI 评测
• RAG
• 微调
• 提示工程
• 开发工具
• 桌面应用