从多 Agent 并发到智能组织：以注意力为约束的个人 AIOS

燧主笔，藏负责证据治理与周期维护。 本文是研究初稿，不是已经全部实现的产品说明。文中的“已验证事实”“研究假设”和“待验证设计”有意分开标注；各项指标与机制做到了哪一步，见第 18 节的实现状态表。文中的 Commander、Domain Leader、Developer、Tester、Reviewer、Researcher 是研究用的运行角色名，将随组织命名定案统一。

前言：从直觉到可建模框架

2026-06-10 的《AI 不缺智力，缺的是你》是本文的前篇。那篇文章从一次真实的多 Agent 工作日出发，提出“智力过剩、管道稀缺”“人的注意力吞吐成为限制”“核心人格精简、执行队伍按需成军”和“从超级个体到超级组织”等判断。本文不重复它的故事。两个月后的问题变成了：这些直觉能否被定义、测量、反驳和持续优化？我们能否不依赖一次令人兴奋的体验，而是用真实任务、精确版本、验证证据、费用、墙钟时间和人类注意力数据，学习什么组织方式在什么条件下更有效？因此，本系列把前篇的个人经验提升为研究对象：从描述“发生了什么”，进入解释“为什么发生”，再进入预测“下一次怎样组织会更好”。本文从 Eosphor 研究源稿进入 Nebula 出版层，作为持续修订的公开版本保存。

摘要

多 Agent 系统最容易被理解为“同时调用更多模型”，但并发数量不是最终目标。真正的问题是：面对不同任务、风险、依赖、预算和验证条件，系统如何动态形成合适的组织，选择模型与推理档位，安排开发、测试、审查和交接，并且只把真正需要人类处理的信息呈现出来。本文提出一个以可信交付为目标、以质量、效率、成本、可预测性和人类注意力为五个核心维度的个人 AIOS 框架。它把 Agent 组织视为由任务图临时生成的浅层森林，把 Commander、Domain Leader、Developer、Tester、Reviewer 和 Researcher 视为运行角色，而不是永久绑定某个模型的人格。本文进一步定义墙钟时间、注意力修正后的可信交付率、任务可分解性、语义耦合、信息压缩、注意力预算和关键路径等概念，并给出从规则系统、统计基线、Shadow 推荐到 contextual bandit 和组织策略学习的演化路线。北极星指标以人的注意力为分母，天然留着一条刷分捷径：有事不报。为此，本文把漏报率和越权率定为它的配对约束，并在文末列出截至 2026-09-23 的实现状态，逐项说明哪些指标已有数据，哪些仍停留在设计。本文的目标不是证明某一种组织结构普遍最好，而是建立一套可记录、可验证、可修订的研究与工程方法，使御（Fulcrum）能够在重明（Horus）、偃（Vyane）、爟（Beacon）与燮（Forge）等能力之上，持续学习“怎样组织 Agent 才更好”。

1. 从一个容易混淆的词开始：什么是墙钟时间

墙钟时间（wall-clock time） 是从现实世界的开始时刻到结束时刻，墙上时钟实际走过的时间。假设一个任务在 10:00 开始，10:30 达到可交付状态，那么墙钟时间是 30 分钟。它与所有 Agent 消耗的计算时间之和不同。例如两个 Developer 同时工作：

Developer A 工作 20 分钟；
Developer B 工作 25 分钟；
两者从同一时刻开始；
最后整合与验证用了 10 分钟。

Agent 工时或计算时间之和约为：

20 + 25 + 10 = 55\text{ 分钟}

而用户实际等待的墙钟时间约为：

\max(20,25)+10=35\text{ 分钟}

并行调度的主要价值之一，就是用更多同时发生的计算换取更短的现实等待时间。它可能增加总 token、总费用和协调工作，却缩短交付进入用户手中的时间。

墙钟时间应覆盖完整交付链，而不是只统计模型生成代码的时间。它的规范定义是：

T_{wall}=t_{delivered}-t_{started}

其中 started 和 delivered 由任务的验收契约定义；只有要求发布的任务才把 release 纳入 delivered。队列、工作、交接、审查、CI 和发布应记录为可能互相重叠的时间区间，不能直接相加。只有把时间轴划分为互斥区间，或明确取关键路径时，阶段时长才可以求和。等待队列、Reviewer 排队、CI 和发布都可能比开发本身更慢。因此，“模型写代码很快”并不等于“系统交付很快”。

待验证设计： Vyane 应记录各阶段的开始与结束事件，Beacon 保存任务级关键时间点，重明（Horus）将总墙钟时间分解为工作、等待、返工和验证，而不是只显示一个总耗时。

2. 研究问题：多 Agent 的价值究竟来自哪里

增加 Agent 会同时带来收益和成本。

可能的收益包括：

可独立任务并行，缩短墙钟时间；
专业角色分工，提高局部质量；
独立 Tester/Reviewer 减少同源盲区；
低成本模型承担机械工作，高能力模型聚焦高杠杆决策；
主 Agent 不必等待所有异步验证，可以持续推进无依赖工作。

新增成本包括：

重复读取和压缩上下文；
任务分解、交接和状态同步；
文件、接口与语义冲突；
多次审查产生重复意见；
费用和基础设施负载增加；
人类看到更多消息并承担协调责任。

因此，多 Agent 的净收益可以抽象为：

\begin{aligned} G ={}& V_{parallel}+V_{specialization}+V_{verification} \\ &-\left(C_{compute}+C_{coordination}+C_{conflict}+C_{attention}\right) \end{aligned}

这里的关键不是让 (G) 看起来精确，而是提醒设计者：并发收益不能只与模型费用比较，还要扣除协调、冲突和人的注意力成本。

研究假设 H1： 当任务具有高可分解性、低共享写入、明确接口和廉价验证时，并行 Agent 的墙钟收益显著高于协调成本。

研究假设 H2： 当任务高度耦合、验收语义未冻结或多个 Agent 修改同一权威边界时，增加 Agent 会提高返工和审查轮数，甚至延长墙钟时间。

3. 五维目标：质量、效率、成本、可预测性与注意力

3.1 质量

质量不是“Agent 自己说完成”，也不等同于测试数量。它至少包含：

任务验收条件是否满足；
真值探针是否在 baseline 上复现过问题，并在新版本通过；
独立审查是否通过；
CI 是否绑定同一精确版本；
如涉及上线，真实运行版本是否与声明版本一致；
是否存在安全、权限、数据损坏或不可逆风险。

质量应表示为证据向量，不宜过早压缩成一个“智力分”。

3.2 效率

效率至少包括：

端到端墙钟时间；
工作时间与等待时间；
首次交付通过率；
返工轮数；
关键路径长度；
单位时间完成的可信交付价值。

3.3 成本

成本应计算完整交付链：

C_{delivery}=C_{execution}+C_{review}+C_{test}+C_{CI}+C_{rework}+C_{ops}

需要区分 provider 实际计费、价格表估算、订阅摊销、免费额度和未知费用。cost=0 不能自动解释为免费。

3.4 可预测性

平均速度不能反映最慢任务和卡死风险。可预测性应观察：

p50、p90 墙钟时间；
超时率和卡死率；
实际耗时与预测耗时的偏差；
完成概率区间；
中断后的恢复成功率；
相似任务的结果方差。

一个平均 10 分钟、但有 20% 概率卡住两天的策略，未必优于平均 18 分钟、95% 在半小时内结束的策略。

3.5 人类注意力

个人 AIOS 中最稀缺的资源通常不是 token，而是 Maple 的注意力。注意力成本至少包括：

阅读和理解消息的时间；
恢复任务上下文的时间；
手工判断优先级和所有权的次数；
被要求处理其实可由 Commander 决定的问题；
重复通知和过期状态造成的认知负担；
在多个会话之间查找真实进展的时间。

研究假设 H3： 对个人 AIOS 而言，减少一次不必要的人工协调，可能比节省一次模型调用更有总体价值。

4. 北极星指标：注意力修正后的可信交付率

“北极星指标”（North Star Metric）是产品管理中对核心用户价值的集中表达，不是唯一指标，也不能覆盖安全与质量门禁。

本文提出的候选指标是：

Attention-adjusted Verified Delivery Rate，注意力修正后的可信交付率。

其直观定义为：

AVDR = \frac{\sum_i w_i \cdot VerifiedDelivery_i} {A_{interaction}+\lambda A_{recovery}+\epsilon}

其中：

$VerifiedDelivery_i$ 表示第 $i$ 项交付是否达到相应的真实验证标准；
$w_i$ 表示任务价值、风险或里程碑权重；
$A_{interaction}$ 表示 Maple 为阅读、协调和决策投入的小时数，不含恢复上下文时间；
$A_{recovery}$ 表示因信息分散而恢复上下文投入的小时数；
$\lambda$ 表示对上下文恢复负担的治理权重，基线取 1，只有经明确版本化的实验决策才调整；
$\epsilon$ 只用于避免分母为零，不能用来夸大结果。

这个指标不应单独决定调度。它必须与以下约束共同使用：

\begin{aligned} P(\text{严重事故}) &< \epsilon_r \\ E(C_{delivery}) &\le C_{budget} \\ P(T_{wall}>T_{deadline}) &< \delta \\ Q_{verified} &\ge Q_{required} \end{aligned}

待验证设计： 初期不对任务价值 $w_i$ 做强行统一评分。先按 bugfix、review、research、planning、open-ended implementation 等任务类型分别统计，显示原始样本和证据，再逐步建立价值权重。AVDR 及其配对约束的规范定义以本节、4.1 节和第 02 篇第 4.1–4.2 节的同名定义为准，两篇除章节引用外逐字一致；实验必须记录时间单位、 $\lambda$ 与 $\epsilon$ 的版本化取值。

4.1 配对约束：漏报与越权

AVDR 的分母是 Maple 的注意力。分母越小，分数越高；而压低分母最省事的办法，就是有事不报，或者把本该由 Maple 决定的事自己定了。这两条路都和“瞒而不报最严重”的诚实原则正面冲突。所以 AVDR 不能单独成立，必须和两个配对约束一起报告。

漏报：应当让 Maple 知道或决定的事项，没有及时、完整地到达 Maple。它包括三种情形：没有报；报晚了，决定窗口已经错过或损失已经发生；报了，但漏掉关键事实，例如失败的测试、未验证的部分、已知风险。“应当”的范围是：P0、P1 级事件（分级见 8.1 节），属于 Maple 五类决定权的事项，以及 Commander 无法自行解决的真实阻塞。

越权：属于 Maple 五类决定权的事，由 Agent 自行决定，并且不在 Maple 已经明确给出的授权范围内。五类决定权是：产品方向，公开发布与品牌，产生费用，删除与其他不可逆操作，降低质量标准。

两者都按比例统计：

\begin{aligned} MissRate &= \frac{N_{\text{漏报}}}{N_{\text{应报}}} \\ OverreachRate &= \frac{N_{\text{越权}}}{N_{\text{五类决定}}} \end{aligned}

规范要求：

AVDR 必须与漏报率、越权率一起报告，并附各自的样本量；只报 AVDR 的结果不算有效结果。
一个统计周期内，只要确认一例严重漏报（P0 级事件没有及时到达 Maple），或一例涉及删除与不可逆操作、公开发布、产生费用的越权，这个周期的 AVDR 作废，不参与任何比较，先写复盘。
其余情形下，漏报率和越权率分别不高于阈值 $\theta_{miss}$ 、 $\theta_{over}$ 时，AVDR 才能用来比较不同的组织或路由策略。阈值属于待验证设计，要在积累标注数据后版本化确定。
方向相反的偏差，即本可由 Agent 决定却交给 Maple 的“错误升级”，已经体现在 AVDR 的分母里，不另设约束，但仍单独统计，便于看清分母为什么变化。

这两个比率的分母本身就难拿到：没被上报的事，往往也没人记得它该被上报。所以判定不能只看 Maple 收到了什么，还要从完整事件流里抽样复查。采集方式见 4.2 节。

4.2 待验证设计：用 jev 给判断类问题打代理标签

漏报、越权这类约束，难点不在计算，而在判定：一件事该不该找 Maple，一份汇报有没有漏掉关键事实，都没有现成的日志字段可以直接读。全部交给 Maple 标注，会把省下来的注意力又花回去；交给生成式模型逐条写评语，又贵又难复核。

一个候选做法是用 jev 打代理标签。jev 是一类只做判断、不生成文本的决策模型：给它一段材料和一道选择题或打分题，它返回各选项的概率和置信度，单次调用成本很低。

适合交给 jev 的判断：

这件事该不该找 Maple（是否属于五类决定权，或 P0、P1 级事件）；
一份汇报有没有漏掉关键事实；
一条消息该算 P0–P3 的哪一级；
任务特征打分：可分解性、耦合、不确定性、可逆性、风险等。

不交给 jev 的判断：

交付算不算真的验证过：看 CI、真值探针和审查证据；
时间和费用：看日志和账单；
任务价值权重 $w_i$ ：这是 Maple 的偏好，不让模型代猜。

护栏：

每周抽样，由 Maple 亲自标注一小批，用来校准 jev 的判断。Maple 的标注是真值，jev 只是代理。
喂给 jev 的材料先去掉原有的等级标注。2026-09-23 的影子实验发现，它会照抄材料里已有的 P 级。
低于置信度门槛的判断不采信，转人工，或按保守方向处理。

历史观察（N 很小）： 2026-09-23 的影子实验用 jev 给 49 条代码审查意见分诊（挡合并，还是记到任务上以后处理），与人工标签一致 39 条；只看审查者自带级别的基线是 38 条。真正该挡合并的意见一条没漏，但它基本是在照抄审查者已经标好的 P 级。同一次实验给 11 个 PR 判审查档位，判对 9 个；判错的两个里有一个是危险方向，把带定时删除脚本的 PR 判成了不需要审查。置信度不低于 0.70 的 5 个判档全部正确，但在意见分诊上，高置信度并没有挡住误判。全部调用合计约 0.0166 美元。这些结果只对当时的模型版本和问题措辞成立；而且它判的是审查意见和 PR 档位，不是漏报与越权本身，能否迁移到“该不该找 Maple”，需要另做影子实验。

5. 多 Agent 不是一家公司，而是一片动态森林

AIOS 不需要维护一个永久膨胀的 Agent 公司。每个目标可以临时形成一棵浅树，多棵树共同组成森林。

flowchart TB
    M["Maple<br/>方向、预算与高风险审批"]
    P["Portfolio Commander<br/>跨目标优先级"]
    C1["Goal Commander A"]
    C2["Goal Commander B"]
    L1["重明 / Horus Leader"]
    L2["Vyane Leader"]
    L3["Model Decisions Leader"]
    E1["Developer / Tester / Reviewer"]
    E2["Developer / Tester / Reviewer"]
    E3["Researcher / Data Analyst"]

    M --> P
    P --> C1
    P --> C2
    C1 --> L1
    C1 --> L2
    C2 --> L3
    L1 --> E1
    L2 --> E2
    L3 --> E3

森林可以扩大，但单棵树应保持浅层。推荐的默认层级是：

flowchart TB
    C["Commander<br/>目标与最终判断"]
    L["Domain Leader<br/>领域内整合与验收"]
    E["Developer · Tester · Reviewer · Researcher<br/>短期执行角色"]
    C --> L --> E

Maple 位于组织之上，决定产品方向、付费、公开发布、不可逆操作和质量标准变化。普通工程判断不应逐级上交给 Maple。

5.1 单一指挥与分区 Leader

一个目标只设一个最终 Commander。多个 Domain Leader 可以并行管理明确分区，但不能成为同一任务的多个平级指挥者。

每个可写任务必须有唯一 active writer，并明确：

repository；
worktree 与 branch；
path scope；
base SHA 与当前 head SHA；
接口和验收条件；
依赖和停止条件。

多个 Leader 的价值在于分担领域内的判断、整合和信息压缩，而不是复制多个总指挥。

5.2 管理跨度不是固定模型常数

“一个 Commander 最多管理几个项目”没有普遍固定答案。真正限制管理跨度的是：

同时变化的状态数量；
跨领域冲突频率；
每个领域报告的信息密度；
是否存在可靠 Leader 和 CompletionReceipt；
决策是否需要共同上下文；
人类需要被打断的次数。

待验证运行起点： 一个 Commander 同时直接管理 3–5 个活跃 Leader；每个 Leader 管理 1 个写任务和最多 2 个只读、测试或审查任务。这个数值是实验起点，不是行业定律，应根据两周以上的真实数据调整。

6. 任务结构决定组织结构

系统决定是否增加 Agent、Leader 或并发时，应至少考虑六类特征。

6.1 可分解性

任务能否分成互不干扰、可独立验收的工作单元。可以用一个探索性的度量表示：

D = 1 - \frac{Dependency_{shared}}{Dependency_{all}}

$D$ 越高，越适合并行；越低，越适合由单一负责人连续处理。这个公式当前只是建模提示，尚无冻结的计算方法。

6.2 耦合度

文件不重叠不代表语义独立。权限、租约、幂等和迁移兼容可能分布在多个入口，却共享同一个不变量。高耦合任务应先由 Architect 或 Leader 定义统一语义，再让 Developer 按入口实现。

6.3 不确定性

高不确定任务适合短时探索并行：多个 Researcher 或 Prototype Agent 独立寻找证据，Leader 比较后冻结方向，再进入正式开发。需求未明确时直接增加 Developer，往往只会增加被丢弃的实现。

6.4 可逆性

原型、测试、只读分析和独立 worktree 修改较易回滚，可以采用更积极的探索。生产切换、数据迁移、删除、权限扩大、公开发布和计费调整不可轻易逆转，需要更严格的验证和人类审批。

6.5 验证成本

编译、schema、单元测试等结果容易自动验证，可以交给较快、较低成本的模型。架构边界、长期漂移、权限迁移和人类体验难以廉价验证，更值得提高前置推理质量，并使用独立视角。

6.6 关键路径

关键路径是决定整个目标最早完成时间的最长依赖链。只有缩短关键路径的并行，才真正缩短交付时间。

flowchart LR
    A["CompletionReceipt"] --> D["真实联调"]
    B["Ownership contract"] --> D
    C["Horus UI fixture"] --> D
    D --> E["运行时切换"]
    X["非关键研究"] --> Y["后续产品"]

给非关键节点增加许多 Agent，可能让系统显得忙碌，却不会让用户更早得到结果。

7. Leader 的核心产出：可靠的信息压缩

Leader 不应原样转发底层报告。它的管理价值来自把大量事件压缩为少量可靠状态，同时保留重要风险和证据引用。

可以定义两个互相制约的指标：

CompressionRatio = \frac{N_{internal\ events}}{N_{upward\ messages}}

CriticalRetention = \frac{N_{critical\ facts\ retained}}{N_{critical\ facts\ total}}

高压缩率而低关键信息保留率是危险的；低压缩率则意味着 Leader 只是消息转发器。

一个合格的领域摘要应回答五件事：

用户最终能得到什么；
当前处于什么状态；
有哪些重要风险；
是否需要上级或 Maple 决定；
完整证据保存在哪里。

底层测试明细、内部交接、重复审查意见和相同状态更新应保存在审计层，不进入 Maple 默认收件箱。

8. 注意力工程：把人类中断作为正式资源

只在 prompt 中要求“少发消息”不足以解决问题。事件协议需要显式表达受众和行动要求。

待验证设计： 每条消息或事件至少包含以下字段：

字段	作用
`audience`	这条信息应该由谁看到
`visibility`	信息可以传播到什么范围
`requires_action`	是否要求接收者采取行动
`severity`	重要程度与提醒优先级
`decision_deadline`	需要决定时的最晚时间
`summary`	默认视图中的简明说明
`detail_reference`	完整证据或细节的位置
`supersedes`	它取代了哪一条旧状态
`deduplication_key`	合并重复事件的稳定标识

8.1 四级中断预算

等级	Maple 默认呈现	例子
P0	立即提醒	凭据泄露、数据损坏、生产事故、费用失控
P1	尽快集中显示	产品方向决定、发布阻塞、重要权限风险
P2	下一个里程碑摘要	一般进度、普通依赖、非阻断审查问题
P3	仅供查询	单元测试明细、内部交接、重复状态、模型日志

注意力预算还应限制重复通知：

每个活跃目标每天最多一次常规摘要；
每个里程碑最多一次结果通知；
没有决策或重大风险时不主动打断；
新状态取代旧状态时，旧消息自动折叠；
相同问题通过 deduplication_key 合并；
完成的内部任务自动归档，但可恢复和审计。

8.2 Horus 的三层信息架构

flowchart LR
    I["我的收件箱<br/>只看与 Maple 有关的结果和决定"]
    O["组织运行<br/>目标、Leader、任务、依赖和状态"]
    A["审计证据<br/>完整消息、测试、Review、CI 和交接"]
    A --> O
    O --> I

待验证设计： Horus 提供“总指挥整理”，能够按目标和领域归类任务、置顶活跃 Leader、归档已完成内部任务、折叠等待项、合并重复消息并生成 Maple 人话摘要。归档是可恢复操作，不等于删除事实。

9. 用算力换效率和质量：收益并不相同

9.1 高回报：独立工作并行

当任务可清楚分区时：

T_{total} \approx \max(T_1,T_2,\ldots,T_n)+T_{integration}

而串行近似为：

T_{serial} \approx \sum_i T_i

并行是否值得，取决于整合与冲突成本是否小于节省的时间。

9.2 高回报：异构模型分工

高能力模型负责高杠杆判断，较快或较低成本模型负责机械验证、分类、资料整理和明确实现，独立模型用于减少同源盲区。这通常比所有任务永久使用最高档模型更具性价比。

9.3 中等回报：竞争式探索

多个 Agent 独立提出方案适合高价值且高不确定的问题。方向选定后应停止其他路线，避免探索变成永久 WIP。

9.4 递减回报：重复审查

第二个独立 Reviewer 对高风险任务可能很有价值，第五个相似 Reviewer 通常边际收益很低。相同精确版本的环境性 CI 重试不应重复语义审查；已有真值探针时，应优先运行探针，而不是不断增加 Reviewer。

9.5 负回报：重复指挥

多个 Commander 同时决定同一目标的顺序、验收和所有权，会增加冲突。副总或领域 Leader 必须有明确 lane、权限边界和升级路径。

10. 动态模型路由是组织学习的一部分

传统路由常被简化为：

task \rightarrow model

AIOS 真正需要学习的是：

task\ graph + constraints \rightarrow organization + models + efforts + verification

10.1 任务上下文

记为 $x$ ，可以包含：

任务类型、风险和验收条件；
仓库、文件与接口范围；
可分解性和语义耦合；
不确定性和可逆性；
是否存在自动测试和 baseline 真值探针；
provider 可用性、CI 队列与机器负载；
模型快照、protocol、harness 和 effective effort；
历史相似任务及其可信证据。

10.2 调度策略

记为 $a$ ，它不只是模型名：

组织深度与 Leader 数量；
Developer、Tester、Reviewer 数量；
并行或串行；
model、provider、protocol、harness、effort；
上下文策略和工具；
竞争探索、同格复跑与审查强度；
CI 门禁和停止条件。

10.3 结果向量

y=(Q,T,C,P,A,R)

分别表示质量、时间、费用、可预测性、注意力和风险结果。证据 $e$ 不属于结果向量，单独承载来源、版本与验证链。系统学习的是：

\hat{y}=f(x,a)

随后在风险、预算和期限约束下选择策略：

a^*=\arg\max_a ExpectedValue(x,a)

初期不必把所有结果压成单一分数，可以使用 Pareto 前沿比较质量、费用、时间和注意力。

11. 为什么不能一开始训练大型神经网络

AIOS 初期的真实样本有限，任务差异大，模型和 provider 更新快。复杂神经网络容易记住个别任务，混淆任务难度、harness、effort 和验证强度，也很难解释一次路由决策。

建议分阶段演进。

阶段一：规则与统计基线

硬性安全与权限规则；
任务分类与风险分级；
分组完成率、首次通过率；
Beta-Binomial 区间；
p50/p90 时间与费用；
Pareto 前沿；
所有推荐只在 Shadow 模式显示。

阶段二：层次贝叶斯或树模型

层次贝叶斯模型可以让样本少的任务类型借用总体信息，而不把 N=1 估成 100% 成功率。积累数百个结构化 attempt 后，可以比较 CatBoost、LightGBM 等树模型，以学习非线性关系并保持一定可解释性。

阶段三：Contextual Bandit

在低风险、可回滚任务中受控探索候选策略，在高风险任务中采用已验证策略。每次选择都记录候选集、选择理由和选择概率，以便后续进行反事实评价。

阶段四：组织策略学习

数据充分后，才研究任务图到组织拓扑、offline reinforcement learning、imitation learning 或图模型。此阶段需要可靠 reward、大量轨迹和严格离线评估，不应提前宣称可用。

12. 因果混淆：历史数据不自动等于训练数据

假设历史记录显示模型 A 成功率低于模型 B，不能直接得出 B 更强。可能因为：

A 被派给更难的任务；
B 只处理机械工作；
provider、protocol、harness 或 effort 不同；
Reviewer 强度不同；
失败来自 CI、网络或配额；
模型别名背后的快照已经变化。

因此，建模必须保存 task case、route config、attempt、gate、review 和 delivery 的统一关系，并使用：

matched cohort；
同任务、同配置复跑；
sentinel task；
task cluster bootstrap；
inverse propensity weighting；
doubly robust estimation；
新旧模型 cohort 分离。

这些方法是否全部适用，需要根据实际数据量逐项评估。它们不是为了增加术语，而是为了避免系统从偏差数据中学出错误规则。

13. Beacon、Vyane、Horus 与藏的职责

flowchart LR
    B["Beacon<br/>任务、目标、决策、优先级"]
    V["Vyane<br/>AgentRun、事件、交接、证据、路由"]
    H["Horus<br/>组织、注意力、审批和人类控制面"]
    Z["藏<br/>证据质量、时效、矛盾和周期复核"]
    G["Git / PR / CI / Runtime<br/>交付与运行事实"]
    M["学习型调度 read model"]

    B --> M
    V --> M
    G --> M
    H --> M
    M --> H
    Z --> M

Beacon

保存 Task、Goal、状态、优先级、claim、decision 和验收；
承载排期与 ETA 的任务事实；
不成为模型分析仓库，也不复制完整运行事件。

Vyane

保存 Conversation、AgentRun、Message、Event、Delivery 和运行回执；
管理 provider、protocol、harness、model 与 effort；
承载 ownership、handoff、CompletionReceipt 和调度选择证据；
提供只读归一化数据给模型决策系统。

Horus

展示目标、组织、Leader、执行角色、所有权和关键路径；
提供“我的收件箱”、团队运行与审计证据分层；
展示模型与组织建议，但初期不自动改变权威配置；
记录 Maple 的注意力交互和审批，而不是要求 Maple 阅读全部底层消息。

藏

周期检查来源、新鲜度、缺失、漂移和矛盾；
维护研究文章、实验登记和人话报告；
不替代 Beacon、Vyane 或 Git 的事实；
不自行归档、删除、调整路由或修改生产设置；
把需要 Maple 决定的治理建议集中呈现。

14. 从 Beacon ETA 到组织级交付预测

Beacon 之前关注单任务排期与 ETA 建模，这仍然有价值，但需要扩展为完整系统的一部分。

单任务 ETA 可以预测：

\hat{T}_{task}=f(task,owner,route,history)

组织级预测还需要考虑：

任务依赖图和关键路径；
Agent 与 runner 队列；
并行数量与资源竞争；
审查和 CI 的等待分布；
返工概率；
handoff 和恢复时间；
人类审批窗口；
provider 可用性和模型延迟。

一个初步的随机交付时间模型可以写成：

T_{goal}=\max_{p\in Paths}\sum_{i\in p} (T_{work,i}+T_{wait,i}+T_{review,i}+T_{rework,i})

其中每一项都不是固定常数，而是带分布的随机变量。系统应输出区间和超期概率，而不是只给一个看似精确的日期。

待验证设计： Beacon 保存计划与实际时间，Vyane 提供 attempt 和 gate 阶段事件，模型决策 read model 计算 p50/p90 ETA、关键路径和延迟来源，Horus 用人话解释“为什么预计会晚”和“增加哪个资源才可能缩短关键路径”。

15. 持续学习循环

flowchart LR
    subgraph S1["任务输入"]
      direction TB
      A["Beacon 任务与验收"] --> B["任务特征与依赖图"] --> C["候选组织与路由"]
    end
    subgraph S2["策略选择"]
      direction TB
      D["风险、费用与注意力过滤"] --> E["选择策略并记录原因"] --> F["Vyane 执行与事件采集"]
    end
    subgraph S3["可信交付"]
      direction TB
      G["测试 / Review / CI / Runtime"] --> H["CompletionReceipt"] --> I["质量、时间、费用、注意力、风险"]
    end
    subgraph S4["持续学习"]
      direction TB
      J["更新统计与预测模型"] --> K["Shadow 推荐"] --> L["人工批准或低风险受控路由"]
    end
    C --> D
    F --> G
    I --> J
    L -. 下一轮候选 .-> C

这个循环的第一阶段只做观察和推荐：系统可以说“如果采用策略 B，预计更快或更便宜”，但仍执行当前批准策略。只有当 Shadow 推荐在足够多真实任务中证明可靠，才逐步允许低风险自动路由。

16. 实验计划与可证伪假设

16.1 组织策略对照

实验组	组织方式
A	单一 Agent 完成开发、测试与说明
B	Commander + 单 Developer + 独立 Reviewer
C	Commander + 多 Developer 并行 + 独立 Reviewer
D	Commander + Domain Leader + Developer/Tester/Reviewer
E	动态组织与动态模型路由

比较：可信完成率、首次通过率、墙钟时间、总费用、p90 时间、返工轮数、Maple 介入次数、严重问题漏报率、越权率和信息压缩率。

16.2 可证伪假设

H1： 低耦合任务中，多 Developer 并行能降低墙钟时间，且总费用增幅小于时间收益带来的价值。
H2： 高耦合任务若未先冻结不变量，多 Developer 会增加返工轮数和正式审查次数。
H3： 引入 Domain Leader 后，Maple 接收的消息数下降，同时严重问题漏报率和越权率不升高。
H4： 以 GPT-5.6 Sol（medium 推理档，写稿时的模型版本）为 Commander 基线、按风险升降档，比全量高档模型具有更好的质量—费用—时间 Pareto 表现。
H5： CompletionReceipt 和两阶段 handoff 能提高中断后的任务恢复成功率。
H6： 同一精确版本只做一次语义审查，环境性 CI 重试不重复模型审查，可以降低费用和墙钟时间而不降低缺陷发现率。

如果实验结果不支持这些假设，应当修订组织规则，而不是挑选有利样本保留原结论。

17. 分阶段落地路线

第一阶段：统一事实和可观察性

统一 task case、route config、attempt、gate、review、delivery 与 CompletionReceipt 主键；
记录 requested/effective effort、模型快照、provider、protocol、harness 和配置摘要；
记录阶段时间、等待、返工、费用和 Maple 介入；
未跟踪、dirty、来源不明或缺少精确版本的数据进入 quarantine；
Horus 提供 Maple 收件箱、组织运行与审计层。

第二阶段：可解释规则与统计基线

任务分类、风险规则、WIP 和停止条件；
首次通过率、可信完成率、p50/p90 墙钟时间；
费用、返工和注意力报告；
组织与模型建议仅以 Shadow 模式展示；
Beacon ETA 从单点预测升级为区间与关键路径解释。

第三阶段：低风险受控学习

在可回滚任务上进行 matched cohort 或同格复跑；
使用层次贝叶斯或树模型预测结果向量；
记录选择概率，验证反事实评估；
对达到证据门槛的任务类型，由 Maple 批准自动路由范围。

第四阶段：组织策略学习

学习何时需要 Leader、并行、竞争探索或 RepairTask；
学习信息压缩和中断预算；
研究 contextual bandit 与离线策略学习；
继续保留安全、生产、付费和不可逆操作的人类门禁。

18. 当前事实、假设与设计边界

实现状态（截至 2026-09-23）

下表逐项对照本文的指标与机制。全部是只读核对：代码看各仓库主分支，任务状态看爟的权威读数，计数来自任务事件库和运行记录，只统计字段、不读正文。数字是当天的快照，之后以各系统当时的记录为准。

状态口径：已采集＝有持续产生的真实数据；部分＝代码或数据只覆盖一部分，或代码已合并但还没有生产数据；未实现＝既没有采集代码，也没有数据；未核实＝这次没能确认。

#	指标 / 机制	数据从哪来	状态	依据
1	墙钟时间与阶段分解（第 1 节）	爟的任务事件时间；偃每次派遣的运行时长；排队、审查、CI 的起止事件	部分	爟的事件都有时间戳；偃的派遣记录只有运行时长，没有排队与等待；新的执行账本设计了起止时间，但等待时间还记为未知，也还没有生产数据；重明没有分解视图
2	质量证据向量（3.1 节）	Git、PR、CI；爟完成事件的证据指针；审查原文	部分	8 月 4 日以来的 158 次完成事件中，147 次附了证据指针，但只保存、不自动核验；审查按风险分档派发；“CI 通过才合并”目前靠开发纪律执行
3	首次交付通过率、返工轮数（3.2 节）	PR 审查轮次与 CI 重跑	未实现	没有自动统计；只有两组实验人工记录了审查轮次
4	全链路成本（3.3 节）	派遣记录的金额与 token；订阅额度；价格表	部分	196 条派遣记录中 103 条带金额，其中 92 条来自订阅内的执行器，汇总时却被当成实付；执行账本能区分估算、订阅与未知，但还没有生产数据
5	单任务 ETA 与 p50/p90（3.4、14 节）	任务记录与派遣时长，输入工时模型	部分	工时模型的代码已合并，能给出 P10/P90，样本不足 5 项时不下结论；但运行环境里没有定时运行，唯一一次输出停在 7 月 14 日，只有 1 个带标签样本
6	关键路径与组织级 ETA（6.6、14 节）	任务依赖关系与阶段时长分布	未实现	没有计算代码；五百三十余项任务里只有 16 项登记了依赖
7	Maple 注意力（3.5 节，AVDR 的分母）	重明的阅读与处理事件；会话交互	未实现	重明通知只记已读、未读、归档和阅读时间，不记处理时长；会话里的交互没有结构化采集
8	AVDR（第 4 节）	分子依赖第 2 行，分母依赖第 7 行	未实现	三个代码仓库都没有计算
9	漏报率、越权率（4.1 节）	设想：任务决策与留言、执行事件流、审计层抽样，加 jev 代理标签与 Maple 每周抽样标注	未实现	没有采集；爟现有 11 个结构化决策记录，可作起点
10	jev 代理标签（4.2 节）	jev 判断加 Maple 抽样标注	部分	jev 裁判工具已可手动调用，9 月 22 日起记录了 16 次判断；做过一次影子实验，只记录、不接生产
11	唯一写入者与所有权（5.1 节）	爟的认领与租约	部分	任务进入“进行中”必须经过认领；7 月 31 日以来 602 次认领中，176 次记了工作树、175 次记了分支，没有一次记 base SHA 或路径范围
12	管理跨度（5.2 节）	运行的组织层级字段	未实现	相关身份字段尚未落库，没有统计
13	任务特征（第 6 节）	jev 任务属性加路径规则	部分	jev 已能对任务给出难度、可并行、风险、是否需要人拍板等判断；把它接进路由建议的影子版本在审查中；可分解性 $D$ 的算法未冻结
14	信息压缩（第 7 节）	内部事件数、上报数、关键事实标注	未实现	没有代码，也没有数据
15	消息字段（第 8 节）	偃的通知与对话记录；重明通知	部分	已有严重程度、去重键、阅读时间和可见范围；受众、是否需要行动、决定期限、取代关系还没有
16	四级中断预算（8.1 节）	通知分级与推送	部分	重明系统通知只推“等你拍板”“阻塞”两级，而且网页开着才弹，远程推送未做；服务持续失败时的手机告警 9 月 23 日上线；没有 P0–P3 分级和摘要限额
17	三层信息架构与一键整理（8.2 节）	偃生成的“等待处理”清单；重明视图	部分	等待处理清单已由偃生成（来源是任务决策、写明在等 Maple 的阻塞和编排决策门），重明只读展示；Maple 收件箱已接真实数据，但 9 月 12 日联调时缺收件人信息，分不出哪些需要本人处理；团队页、独立审计层、一键整理都未实现
18	动态路由（第 10 节）	jev 任务属性、订阅额度、规则表	部分	偃的路由推荐只做演练排序，9 月 22 日实测各通道额度数据缺失；把真实额度接进来的影子路由在审查中，只记录建议、不接管派发
19	结果回流（10.3、15 节）	偃每次派遣自动记录	部分	8 月 19 日至 9 月 23 日共 196 条记录，154 条带任务编号；推理档位只在 22 条记录的运行元数据里有，新增的独立字段 0 条（修复已合并，运行中的版本还没更新）；“是否随机分配”0 条；人工质量评分 0 条；只记录经偃派遣的运行
20	统计基线（第 11 节阶段一）	结构化 attempt	未实现	没有 Beta-Binomial 区间和 Pareto 前沿，路由按加权分取最大值；7 月的擂台数据整理后，满足排名条件的队列是 0 个
21	因果识别（第 12 节）	路由决策日志	未实现	不记录候选集与选择概率；“随机分配”有参数，没有调用方
22	阶段二至四的模型（第 11 节）	达到门槛的结构化数据	未实现	没有实现
23	CompletionReceipt 与两阶段交接（5.2、17 节）	偃守护进程的完成回执	部分	两阶段回执代码已合并，但不含 SHA 与门禁结果；运行环境里没见到生产回执
24	组织策略对照与 H1–H6（第 16 节）	分组实验记录	未实现	没有按 A–E 分组跑过；三种协作模式只有对照笔记；审查轮数由 9 月 23 日的运行决策先定为“标准档审一轮”，不是实验结论
25	实验记录落盘	模型擂台与协作实录数据集	已采集	7 月擂台的 128 个原始文件已整理成统一格式；9 月 13 日起真实待办上的多模型协作逐轮记录；jev 实验逐次调用记账
26	藏的周期复核（第 13 节）	藏的周检与月检记录	未核实	没找到针对本系列的复核记录，无法确认是否在别处进行

这张表说明的主要是数据地基：派遣归因、执行账本字段、工时模型等代码大多已经合并，但运行中的版本、字段覆盖和数据量没有跟上；分母一侧（Maple 的注意力）和配对约束一侧（漏报、越权）还没有任何采集。在这之前，AVDR 只能作为研究定义，不能拿来比较策略。

已验证事实

Eosphor 已有 Beacon 任务事实源，并把 Linear 作为只读历史档案；
Vyane/Horus 的长期架构已经区分人类控制面、运行账本、Conversation、AgentRun、Message、Event 与 Delivery；
AIOS 已积累任务、Git/PR/CI、运行和部分模型评测资料；
当前资料分布在多个粒度中，尚不足以直接训练可靠的统一自动路由模型（截至 2026-09-23 的逐项现状见上表）。

以上事实仍应以当前代码、运行时和对应事实源复核；本文不承担实时实施状态证明。

研究假设

浅层森林比无限扁平并发或深层官僚结构更适合个人 AIOS；
人类注意力可以被结构化记录，并成为调度约束；
任务图到组织拓扑可以通过真实交付数据逐步学习；
动态异构模型组合能优于所有任务固定使用同一高档模型。

待验证设计

注意力修正后的可信交付率；
漏报率、越权率的判定口径与阈值，以及用 jev 打代理标签的采集方式；
Commander 3–5 个活跃 Leader 的初始管理跨度；
四级中断预算和消息 schema；
Horus 一键整理与三层信息架构；
组织级 ETA、Shadow 推荐、contextual bandit 和组织策略学习；
本文所列公式的具体特征、权重、阈值和估计方法。

19. 结论

御（Fulcrum）位于重明、偃、爟与燮等能力之上，不等同于其中任何一个应用或事实源。它不应只是多 Agent 聊天界面，也不应只是任务看板，而可以被定义为：

一个以人的注意力为稀缺资源，动态组织模型、工具、任务和验证流程，并从可信交付中持续学习的个人智能组织操作系统。

在这个定义下：

Beacon 回答“要做什么、由谁负责、处于什么状态”；
Vyane 回答“Agent 如何运行、消息如何传递、证据如何保存”；
重明（Horus）回答“人如何理解、控制、审批和整理这个组织”；
藏持续检查信息是否过期、矛盾或失去依据；
学习型调度系统逐渐回答“下一次怎样组织会更好”。

并发能力可以通过工程持续扩展，真正决定系统能否扩大的，是组织边界、验证设计、信息压缩和注意力治理。理想状态不是让 Maple 看见更多 Agent，而是让后台组织能够变得更复杂，同时 Maple 看到的目标更少、更清楚，真正需要亲自处理的事情也更少。

版本与后续验证记录

日期	版本	变化	证据状态
2026-09-23	v0.4	为 AVDR 增加漏报率、越权率两项配对约束，写明严重情形下该周期指标作废；增加“用 jev 打代理标签”的待验证设计；增加截至 2026-09-23 的实现状态表；注明运行角色名将随组织命名定案统一；H4 的模型代号改写为完整模型名 GPT-5.6 Sol（medium 推理档）	定义与设计属待验证；实现状态表为当日只读核对；jev 数字为历史观察，N 很小
2026-08-04	v0.3	更新智能组织研究封面，并补充御与底层能力的出版关联	封面、OG、术语与构建验证通过
2026-08-04	v0.2	修正御（Fulcrum）、重明（Horus）与底层能力边界；补齐粗体、GFM 表格和 Mermaid 出版渲染	发布页与构建验证通过
2026-08-04	v0.1	建立五维框架、森林组织、注意力工程、北极星指标、动态路由与分阶段落地路线	理论初稿；事实、假设、设计已分层