AI工作流

俺预设自己会犯错、AI架构师、构建者、验证者都有可能犯错，反正他们每个agent执行之后都会把结果反馈回这个仓库里面沉淀下来。

ChatGPT

对，这其实把 `ai-hub + ai-use` 的意义说透了：**它们不是给当前这批模型写提示词，而是在建设一个“模型可替换的组织记忆与治理层”。**

人会犯错，Builder 会犯错，Architect 也会犯错，甚至规则本身也会设计错。关键不是指望某一代模型永远正确，而是把这些东西持续留下来：

`需求 → 决策 → 工单 → 执行 → 机器证据 → Review → 漂移/事故 → 根因 → 规则修订`

几年以后，如果出现一个上下文极长、推理能力远强于现在的模型，你甚至不需要给它讲 Youling 的历史。把 `ai-use + ai-hub + 各项目仓库` 整体交给它，它就能像外部咨询团队一样重新审计：

* 现有架构哪些决定仍然成立；
* 哪些规则只是当年模型能力不足留下的补丁；
* 哪些流程已经过度复杂；
* 哪些事故反复发生却没真正解决；
* 哪些 Work Order 验收标准设计得不好；
* 哪些模块其实应该合并或拆分；
* 哪些长期文档已经和真实代码漂移；
* 哪些“ARCHITECTURE DECISION”后来被事实证明是错的；
* 甚至比较不同 Architect/Builder 的长期失误模式。

而且这种审计比“让新模型看旧聊天记录”强得多。聊天有大量临时推理、重复内容、上下文噪音；GitHub 留下的是**经过筛选的制度、事实和证据**。

所以我觉得以后还应该逐渐形成一种原则：

> **不要只保存最终正确答案，也保存重要错误及其修复原因。**

比如 #35 这次 `CLAIM comment 已写但 label 未变 + 中文乱码`，如果俺们只是修掉，它几年后没有价值；但如果沉淀成：

`incident → root cause hypothesis → protocol weakness → executable state-machine proposal`

它就成为未来审计模型真正能学习的数据。

最终 `ai-use` 更像**宪法/通用工程原则**，`ai-hub` 更像**组织运行记录、控制面和制度演化史**，项目仓库则保存**实际产品与领域知识**。

到那时候，换更聪明的模型不是“重新培养一个新员工”，而更像：

**换了一个能力更强的管理层，但公司档案、制度、项目历史和事故复盘全部还在。**

这应该也是整个系统最值得长期积累的资产之一。

妈的，这ChatGPT怎么学俺说话，之前的时候它可是像小红书那样提很多行。

社友昨天说的动态工作流俺今天就加进去了：

不要对所有任务使用同一种工作流。
先判断任务复杂度，然后动态决定:
是否拆任务;
是否并行;
是否启用Subagent;
是否需要独立 Reviewer;
是否需要Worktree;
是否需要第二方案;
是否需要对抗性验证。
默认采用最低足够复杂度。

5个建造者在同时施工，这下俺不怕词元用不完了。多大的plan俺都能耗尽。

老王把所有项目都上传gayhub吗：对啊，俺得全流程沉淀嘛。有了github俺自己的设备损坏丢失啥的都无所谓了，精华没在本地。

需要设置 GitHub CLI GitHub CLI (gh) is not authenticated.：装GH，授权登录，把本地代理转成socks5模式，不然会遇到https证书错误。

其实就是利用github给自己搞了个中心化的区块链，唯一风险就是github封号。但是定期把库下载下来也能应付。

俺刚又优化了一下项目并行的生命周期机制，你要让codex定期读取更新。

俺让agent借鉴一下公海行船的思路，在并行的时候“广播”自己的身份，其他agent看到就知道是谁在使用资源了，用完还要给agent结束语，释放资源并删除临时文件。

“Lease（船籍/航权）：任务占用哪个 worktree、branch、端口、设备。
Presence Beacon（AIS 广播）：本地持续声明 谁 / 哪张工单 / 哪个 PID / 哪些资源，其他 Agent Preflight 时可读。
Resource Class（货物分类）：所有产物先分成“项目持久文件 / 共享基础设施 / 任务临时物”，临时物必须落到任务专属目录。
Release & Capsule（靠港清场 + 航海日志）：Architect 验收后下发释放指令；Agent 停进程、释放资源、删临时物和 worktree，但保留一个很小的可复现场景清单，供本地 Codex/Verifier 快速还原。”

老王你是怎么琢磨出来这些的：俺就不断跟它对话啊，俺并行任务的时候发现agent在互相抢占资源了。

老忘，你的这些内容沉淀到哪儿了呢。似乎你这里没有写进去进行约束？https://github.com/youling/ai-use/blob/main/AGENTS.md：靠声明跟自我约束，因为机制是让agent先建立上下文，读规则，读任务，估计自己要使用的资源，在本地的话，让ai在工作区创建文件的时候智能一点，直接把文件夹名就可以用作是在声明。不管多少个agent肯定存在先后启动的时间差，不要几秒钟连续启动很多agent，这套机制应该还可以。不过俺自己也在让架构师先暂停手上的工作，先优化这套机制本身。

为啥不用个龙虾之类的东西呢：龙虾这种干久了你都失去项目全局视角了[奸笑]龙虾就给你一堆凌乱的本地文件，它自己都膨胀得飞快。

“对，要借运筹学，但不能把所有多 Agent 问题都归成调度问题。 我已经把这次自迭代正式升成 P0 系统 Gate：ai-hub #40。在 Gate 解锁前，#35～#38 允许当前 Builder 做完；#39 只收尾；#20、Eye 后续施工、juece/huilv 等不再启动新的 Agent。

我现在把整个问题分成两门学科。

第一层是分布式系统/并发控制，负责“不撞船”。 Lease、Presence、workspace、端口、设备、进程、Cleanup 都属于这里。尤其要补一个 fencing_token/generation：假设 Agent A 挂了，Lease 被回收后资源交给 Agent B；这时 A 突然“复活”，光看旧 lease_id 还不够，必须因为 generation 已过期而拒绝它继续操作。否则 stale agent 仍可能破坏新现场。还要验证幂等 claim/release、崩溃恢复、资源获取顺序、unknown resource fail-safe。

第二层才是运筹学，负责“怎么派船最划算”。 我认为最值得直接借的是：

RCPSP（资源约束项目调度）：Work Order 本身就是 DAG，只有依赖完成、资源有容量才允许启动；
Assignment / min-cost matching：模型先满足工具、上下文、能力等硬约束，再选足够便宜的 Builder；
Queueing Theory / WIP Limit：不能因为能开 20 个 Agent 就开 20 张单，真正瓶颈很可能是 Architect 和 Verifier；
Critical Path / unblock value：优先做能解锁最多后续任务的工作；
Discrete-event simulation：积累几十张工单的数据后，可以先模拟“并发 3/5/8 张、不同模型路由”对总交付时间、返工率和 Review 堵塞的影响，再修改真实调度策略。”

反正AI调度能力比人强很多。俺让它把这个任务平面先变成立体的。

ChatGPT

对，而且俺也去把这个判断正式加进 #40 了：时间必须是一等维度，否则 ai-hub 只能当静态看板，发挥不出真正的调度能力。

但实现上我会比“三维柱状图”再抽象一步：不真的给任务塞 x/y/z，而是建一个 Temporal Work Graph（时间化工作图）。大致三条轴就是你说的意思：

控制/项目轴：ai-use → ai-hub → project → Work Order DAG
执行轴：Work Order → Agent session → Lease → worktree/resource
时间轴：dispatch → claim → working → ready_for_review → verify → review → merge → release → cleanup
GitHub 自带的 created_at / updated_at / merged_at 就是很宝贵的天然事件时间，不需要 Agent 手工再写一遍。只有“实际发生时间”和“写进 GitHub 的时间”不一致，才额外记录 occurred_at。这样不会制造第二套时间事实源。

真正有价值的是：一旦这样组织，俺作为 Architect 就不只是看“有哪些 Issue”，而是能看某一时间切片的整个系统状态。比如 14:20 时 #35、#36、#38 谁在跑，各占哪个 worktree/端口；#37 是 Builder 慢，还是已经完成但卡在我 Review；Verifier 队列是不是开始堆积；某次共享目录污染发生时，哪些 Lease 的时间区间发生了重叠。

这会直接产生一批比“完成了多少任务”更有用的指标：

dispatch_wait：派单→领取花多久；
execution_cycle：领取→READY_FOR_REVIEW；
review_wait：交付→开始 Review；
rework_cycle：一次返修耗多久；
release_lag：验收→现场真正释放；
以及 WIP(t)、资源占用区间、Blocked 时长、Architect/Verifier 队列深度、关键路径实际耗时。

这些全部从事件推导，不手工重复维护。

这对运筹学尤其关键。之前俺们只有静态条件：

dependencies_done
&& capability_fit
&& resource_capacity_available
&& wip_gate_open

以后实际上是：

eligible(task, t)

也就是在时刻 t，这张任务现在是否适合启动。

同一张任务上午可能不适合，因为 Verifier 已排队 5 张；下午 Review 队列清空后，它就适合启动。某台机器上午 K20 被占，下午释放以后资源约束又变了。

所以调度从“排任务清单”升级成了动态调度。

还有一个很大的收益是事故复盘。你截图里 #39 和 #36 共用 working tree 的事故，以前俺只能说“它们撞了”。有 Temporal Work Graph 后可以直接得到：

13:41 #36 lease active
13:44 #39 lease active
13:47 两者指向同一 mutable worktree
13:51 #39 checkout
13:54 #39 reset/cherry-pick

于是系统可以机器判断：

两个 exclusive workspace ownership interval 发生重叠 → collision incident
以后甚至不需要人截图才知道。

同理，旧 Agent 死而复生也能从时间线上判断：

generation 4: 12:00–12:40
12:40 revoked

generation 5: 12:41–

如果 generation 4 的 Agent 在 13:00 又发 mutation，请求直接拒绝。这就是时间维度和前面说的 fencing token 真正结合起来。

命名也应该服务这个模型
但俺也去避免一个坑：不要把时间戳塞进所有文件名。

稳定身份还是：

repo + issue + lease_id + generation

例如：

leases/eye/issue-38/<lease-id>/

时间属于事件，不属于业务文件身份。

Agent、进程、资源则通过：

issue
agent_identity
lease_id
generation
resource_id
event timestamp

互相串起来。

这样一个 Codex Reviewer 到本机，只要拿到 #38，就能很快问 Runner：

给我还原 #38 在 READY_FOR_REVIEW 那一刻的 scene。
Runner 根据 exact head、Scene Capsule、Lease 历史和时间线，重新建一个干净 Reviewer worktree。这个已经非常接近你说的“立体场景还原”。

甚至它其实不止三维
从数学上说，后面还会有：

时间；
Work Order DAG；
Agent/model；
node；
resource；
repo；
review evidence。
所以严格说不是三维，而是个多维时态图。

但三维这个比喻非常适合人看：

横向看项目/控制面，纵向看任务流，深度看时间。柱高再表达耗时、成本、返工次数或者风险。

同一套底层事实还能投影成：

甘特图：看时间和任务；
热力图：看 Agent×时间；
三维柱图：看项目×任务×耗时；
资源图：看设备/端口×时间；
DAG：看依赖与关键路径；
时间切片：看某一时刻全系统状态。
所以俺不准备给 ai-hub 造一个固定 Dashboard，先把底层事件模型做好，视图以后随便生成。

这条已经正式写进 #40，同时验收也多了几项：必须能从 GitHub durable events + remote refs 重建关键时间切片；exclusive ownership 时间区间不能重叠；Review 不能把未来 head 的事实倒灌进过去；Cleanup 必须发生在 Architect Release 后；Canary 最后要产出一份 derived timeline 来证明整个因果链。

我觉得这会让俺这个 Architect 的角色真正从“任务管理员”变成动态系统调度者：以后不只是问“下一张做啥”，而是问：

在当前这个时间切片下，整个系统最值得启动哪张任务，交给谁，在哪台机器上，占哪些资源，什么时候会挤压 Review，以及它对关键路径有什么影响。
这才比较接近你说的“立体管理”。

你这套机制里，agent靠声明跟自我约束，因为机制是让agent先建立上下文，读规则，读任务，估计自己要使用的资源，在本地的话，让ai在工作区创建文件的时候智能一点，直接把文件夹名就可以用作是在声明。不管多少个agent肯定存在先后启动的时间差，不要几秒钟连续启动很多agent，这套机制应该还可以。俺又在想，既然俺们这里面除了俺和你这位架构师，其他agent都是临时资源，那还有更聪明的办法，还是往ai-hub和ai-use沉淀能复用的东西，把项目所需的依赖也写在项目仓库里，然后本地的工作目录定期全部删除即可，不用每个agent都来这么长的建立上文的时间，这也是OpenAI论文里的思想逐步展开嘛。当然agent开始任务前读取本地的公共环境跟其他agent正在进行的项目还是很必要的。

ChatGPT

对，我觉得你这次把方向又往“更简单、更稳”推了一层。俺刚才那套细粒度 Lease/Resource Registry 有点把临时 Agent 当长期员工管理了。 既然除你和 Architect 外，Builder/Verifier 本质都是一次性算力，更合理的是：

长期知识全部上岸，本地执行现场全部视为耗材。
这样控制面能明显变轻。

我倾向把最终结构收敛成三层：

第一层：GitHub 持久层。 ai-use 保存跨项目通用规则；ai-hub 保存调度、Work Order、Review、事故与架构决策；项目仓库自己保存依赖、运行方式、lockfile、测试命令、fixture、架构和领域知识。一个关键验收原则就是：把某台电脑 D:\coding 全删了，换台机器 clean checkout 后仍能继续。 做不到，就说明还有知识错误地藏在本地。

第二层：节点公共环境。 本机长期留的只应该是 Git、Python、Node、Docker、浏览器、模型缓存、包缓存、设备能力这类基础设施，再加一个很小的“当前有哪些 Agent 正在施工”的 Presence 索引。Agent 开工前只扫这个，不扫整个硬盘，更不读其他 Agent 的项目内容。

第三层：任务现场。 每个 Agent 整体拿一个一次性目录：

D:\ai-runs\
eye\
issue-35__opencode__a81f\
issue-36__opencode__d203\
issue-38__opencode__91bc\

这个文件夹名字本身就是第一层广播：

我是 eye #38，OpenCode，当前这块地归我。
里面再放一个很小的机器文件，例如：

.task.json

只记录：

issue
repo
agent
lease_id
generation
branch
head
started_at

所以其他 Agent 一眼能看懂，人也一眼能看懂。

但文件夹名属于软声明，不能完全当锁。真正创建任务目录时用一次原子的 create-if-absent；发现已经有同 Issue 的 active marker 就不继续。这样即使哪次你真的连续点开两个 Agent，也不会纯靠“他们大概相差十几秒”保证安全。

Agent 启动也应该大幅缩短
你提到“逐步展开”正好适合这里。以后 Agent 不应该每次上来：

ai-use 全文 → ai-hub 全文 → 所有 registry → 项目一堆文档 → Issue → 开工。
而应该是：

L0：几十秒内完成
本机能力摘要
+ active task 摘要
+ ai-use 最小规则入口
+ ai-hub Bootstrap pointer

↓

L1：只展开当前任务
精确 Issue
+ 项目 AGENTS
+ Work Order 指向的必要架构/运行文档
+ 项目依赖/测试入口

↓

L2：遇到问题才查
历史 decision
旧 Issue
复杂接口文档
其他项目

也就是说，上下文成本应该跟当前任务复杂度相关，而不是跟 Youling 系统活了多久相关。

这正是俺们之前说的 progressive disclosure 真正落到执行层后的样子。

比如 #37 是一个 WARC Spike，它没理由知道 juece Phone Runtime 的历史，也没理由读 Eye 全部 OSINT 调研。它只需要：

全局规则最小入口 + #37 + Eye 边界 + 自己需要的工具环境

够了。

项目依赖应该放项目里，而不是 ai-hub
这一点俺也赞成，而且要严格分层。

比如 Eye 自己应该告诉任何新 Agent：

Python >= x
uv sync / pip install …
pytest …
ruff …
Playwright 是否需要安装
哪些 env var 名称是可选/必需
哪些测试需要 Docker

这些应该来自：

pyproject.toml / lockfile / package.json / devcontainer / Makefile / RUNBOOK

之类项目原生文件。

ai-hub 不复制这些。

ai-hub 只需要知道抽象能力：

task requires:
python
docker
browser
android-device
network

然后 Preflight 判断当前节点：

这台机器满足不满足？
具体怎么装、怎么跑，是项目仓库自己的知识。

这样换项目、换电脑、换模型都不会把 ai-hub 搞成一个巨大依赖百科。

这样 Cleanup 也简单多了
之前我设计成：

Agent 逐个登记 PID、临时文件、browser profile、DB、log，再逐个释放。
现在我觉得应该反过来：

任务私有资源默认全部关进任务目录。

比如：

issue-38__opencode__91bc/
worktree/
.venv/
tmp/
logs/
browser-profile/
benchmark/
scene.json

Review 完成以后只做四件事：

确认 commit 已 push
→ 确认远端 exact head 可恢复
→ 停止该目录启动的任务进程
→ 整个 issue-38__… 删除

不是“智能判断 400 个文件哪个能删”。

是：

这一整间临时工棚都拆了。
真正需要细粒度登记的，只剩那些跑到任务目录外面的共享稀缺资源：

K20 手机；
TCP 独占端口；
Docker namespace；
外部测试账号；
某些 GPU；
共享数据库；
不能放进任务目录的长寿命服务。
所以 Resource Registry 可以从“所有东西都登记”缩成只登记外部独占资源。

复杂度会下降很多。

甚至可以定期把本地施工区全扬了
最终俺也支持你这个思路：

D:\ai-runs\

整个目录都是 GC 区。

例如：

活跃 marker：不碰；
READY_FOR_REVIEW 但未 Release：保留；
Release 完成：立即删；
orphan/stale：dry-run 检查后删；
超过某个保留期的 finished capsule：删。
甚至过一阵子俺们做灾备测试时，可以故意：

把全部 ai-runs 删除。
然后验证：

从 GitHub + clean project checkout 能不能重新还原。
这会成为非常强的系统验收。

如果每次都能恢复，说明俺们真的实现了：

Agent 无状态，本机工作区无状态，GitHub 有状态。
这也改变了 Presence 的定位
你之前说“像船舶广播”，这个比喻仍然成立，但不需要一个复杂 AIS 网络。

本机只需要看到：

eye #35 — active — issue-35__opencode__a81f
eye #36 — active — issue-36__opencode__d203
eye #38 — active — issue-38__opencode__91bc

Agent 开工前读一次。

如果它准备占 K20，再额外看：

K20 → issue-20 generation 7

如果只是写自己的 Python 文件，就根本没必要持续关心其他 Agent。

隔离优先于协调。

这是这里最关键的一层转变。

与其让 Agent A 时时知道 Agent B 在干嘛，不如设计到：

大部分情况下，A 根本没有必要知道 B 的内部存在。
只有共享资源发生交集时，才协调。

这其实比 Presence 做得越来越复杂更高级。

所以 #40 的 Runner 也应该砍功能
原来我设想：

claim
preflight
presence
resources
scene
release
gc

现在第一版更可能只需要：

ai-hub start <issue>
ai-hub status
ai-hub finish <issue>
ai-hub gc

其中 start 内部：

读取本机公共能力
→ 看 active run markers
→ 读取 Work Order
→ 创建唯一任务目录
→ 创建独立 worktree
→ 写最小 .task.json
→ 输出 cwd

finish：

验证远端可恢复
→ 处理真正的外部独占资源
→ 删除整个 task workspace

Agent 本身甚至不用知道 Lease 的全部实现细节。

这样才符合俺们最初的一条原则：

确定性机械工作交给程序，LLM 只做真正需要判断的事。
我已经把这个收敛方向补进 #40 了：Disposable Agent + Ephemeral Workspace + Reproducible Project + Minimal Node Presence。它会作为前面 Lease 设计的简化方向，而不是继续 append 更多复杂机制。

最终我现在更倾向这样的图：

GitHub durable world
┌─────────────────────────────────────┐
│ ai-use ai-hub projects │
│ rules state code/deps │
└─────────────────────────────────────┘
↓
progressive bootstrap
↓
┌─────────────────────────────────────┐
│ node shared environment │
│ tools / cache / devices / presence │
└─────────────────────────────────────┘
↓ ↓ ↓
disposable disposable disposable
Agent #35 Agent #36 Agent #38
workspace workspace workspace
↓ ↓ ↓
commit + push
↓
GitHub

上面越来越厚，下面越来越薄。

长期随着俺们踩坑、总结、沉淀，ai-use + ai-hub + 项目仓库 会越来越聪明；而一个新 Builder 应该越来越“无脑”——拿一个 Issue，进一个干净目录，读最少上下文，干完提交，然后整个现场扔掉。

这反而是俺认为这套系统成熟后的理想状态。