耄耋专属AI Loop全自动编码器技术笔记
写给想了解「多AI Agent 在大LOOP时代怎么真上线」的同学
一句话
Loop Engineering 时代，别只在聊天里写代码——用多 AI Agent，跑一条自己干活的交付 Loop。
先给这套 Loop 代码编排器定一条简单主线：
需求 Issue → 多角色 AI 协作 → 脚本验证与独立审阅 → 合并 → 固定脚本部署 → 看板盯进度。
人定目标和验收；AI 负责中间大部分实现与自检；模型不直接登录生产。
为什么不只「开个 Cursor 窗口」
聊天式助手擅长帮你改文件，但上线仍要人拉分支、补测、发版、盯结果。Loop 把这些环节收成固定流水线：
| 聊天式 AI 编程 | Loop | |
|---|---|---|
| 起点 | 粘贴上下文 | Issue / 看板目标 |
| 过程 | 人来回追问 | 多角色自动推进 |
| 质量 | 靠自觉 | 脚本验证 + 独立审阅 |
| 上线 | 手工发版 | 确定性发布脚本 |
| 可见性 | 对话记录 | 看板阶段与应用入口 |
一句话：助手帮你写；Loop 帮你把需求送到可点开的版本。
技术骨架：三层分工
▼text复制代码触发层 Forgejo Issue（ai-ready） / 看板「新建项目」 编排层 Worker + loopctl + Hermes 五角色 Profile 落地层 verify.sh → PR 合并 → SSH/Compose 发布 → sslip 域名跳转
- 触发层：习惯还是 Git Issue；新产品也可在看板填「仓库名 + 目标」一键建仓。
- 编排层：分析 → 架构 → 编码 → 测试 → 审阅；审阅打回最多返工 3 轮；单阶段约 30 分钟超时。
- 落地层：过门后由脚本部署，看板只监控和跳转，不托管业务前端。
密钥只在服务器 secrets/，不进仓库。
多 Agent：故意「拆开」，不让一个模型既当运动员又当裁判
| 角色 | 做什么 | 典型产出 |
|---|---|---|
| 分析 | 收成可验收目标 | spec.md |
| 架构 | 拆任务、定边界 | plan.md |
| 编码 | 改业务代码与测试 | 仓库 diff |
| 测试 | 独立补测、跑验证 | 测试报告 |
| 审阅 | 只评不改，给通过/打回 | review.json |
执行侧用 Hermes 多 Profile，工具集刻意收窄（文件 / 终端 / 必要时代码执行），并设轮次上限，避免一轮对话无限烧 Token。
模型也可分层：编码侧重代码模型，测试用更快模型，审阅用更稳的模型——质量门与写代码的人不是同一个「脑」。
配置落在哪
编排层（仓库）
config/loop.json 只规定：
- 五角色各自用哪个 Profile 名
- 工具集（分析 / 架构 / 审阅：
file,terminal；编码 / 测试再加code_execution） - 单阶段轮次上限、YOLO、返工次数、超时
其中
hermes.models可以按角色覆盖模型名；留空则用 Profile 默认值。
执行层（服务器 Hermes）
真正的模型 ID、base_url、API Key 写在各 Profile 的 config.yaml（例如 /root/.hermes/profiles/loop-coder/config.yaml）。
线上现行大致是：
| 角色 | 模型 |
|---|---|
| 分析 / 架构 / 编码 | ark-code-latest（火山方舟选GLM5.2） |
| 测试 | deepseek-v4-flash |
| 审阅 | deepseek-v4-pro |
小技巧
如果想真正的分饰多角，完全可以多买几个便宜的Agent Plan分别挂不同对应角色能力的LLM，但这里由于成本控制的原因，最少两个LLM对应不同能力就可以完成基本工作了。
人格层（SOUL）
仓库 roles/*.md 同步进各 Profile 的 SOUL.md，约束「只做什么、不做什么」：
- 模型负责能力
- SOUL负责边界
调用链
▼text复制代码Issue Worker → loopctl → 对应 Profile 的 Hermes（--oneshot，瘦工具集）→ 该 Profile 配置的模型
有边界的自治（比「全自动」更重要）
会自动做： 读仓、改码、跑校验、开/合 PR、按脚本部署。
不会自动做： 没目标乱开需求、跳过质量门上生产、把密钥写进 Git。
人能介入： 看板看卡点、一键重跑；紧急可停 Worker。
发布永远走 release.sh / SSH 一类确定性路径，而不是让 Agent 临时拼命令登生产。
看板：把黑盒变成进度条
看板回答三件事：
- 现在跑到哪（分析 / 架构 / 编码 / 测试 / 审阅 / 发布）
- 有没有被打回、卡在哪
- 应用在哪打开（当前交付 + 历史项目各自地址）
多项目时：一仓一应用、独立端口、独立 *.sslip.io 域名。改哪个程序，Issue 就开在哪个仓库。
一次真实路径长什么样
- 看板新建，或在目标仓开 Issue 并打
ai-ready - Worker 领取 → 工作区拉出
ai/issue-N分支 - 五角色流水线跑完，产物落在
.loop/current/ - 质量门通过 → PR 合并
deploy_once部署 Staging/Production，写好跳转域名- 打开
{项目名}.xxx.sslip.io验收
试点里我们用这条链路交付过多智能体对话应用、内容创作平台等——从「一句话目标」到「浏览器能点开」，中间大部分由流水线完成。
适合什么，不适合什么
适合： 中小功能、脚手架增量、内部试点、需求边界写得清的迭代。
暂不适合： 无人值守改核心账务、无评审的大重构、强合规唯一发布通道。
产出质量仍然取决于：需求是否写清、模板是否匹配、模型额度与提示词。
目前Loop编排器自动完成的项目展示
结语
Loop 的技术选择可以概括成三句：
- 角色分离，降低「自写自审」幻觉；
- 脚本守门，模型负责想和改，脚本负责过不过、能不能上；
- 看板可见，自动跑也不变成黑盒。
它不是取代工程师，而是把重复的「领任务 → 改代码 → 验证 → 发版」收成一条可观测流水线，让人把时间花在目标与验收上。
