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

燧主笔，藏负责证据治理与周期维护。 本文是研究初稿，不是已经全部实现的产品说明。文中的“已验证事实”“研究假设”和“待验证设计”有意分开标注。

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

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

摘要

多 Agent 系统最容易被理解为“同时调用更多模型”，但并发数量不是最终目标。真正的问题是：面对不同任务、风险、依赖、预算和验证条件，系统如何动态形成合适的组织，选择模型与推理档位，安排开发、测试、审查和交接，并且只把真正需要人类处理的信息呈现出来。本文提出一个以可信交付为目标、以质量、效率、成本、可预测性和人类注意力为五个核心维度的个人 AIOS 框架。它把 Agent 组织视为由任务图临时生成的浅层森林，把 Commander、Domain Leader、Developer、Tester、Reviewer 和 Researcher 视为运行角色，而不是永久绑定某个模型的人格。本文进一步定义墙钟时间、注意力修正后的可信交付率、任务可分解性、语义耦合、信息压缩、注意力预算和关键路径等概念，并给出从规则系统、统计基线、Shadow 推荐到 contextual bandit 和组织策略学习的演化路线。本文的目标不是证明某一种组织结构普遍最好，而是建立一套可记录、可验证、可修订的研究与工程方法，使御（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 的规范定义以本节和第 02 篇的同名定义为准，实验必须记录时间单位、 $\lambda$ 与 $\epsilon$ 的版本化取值。

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： 以 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. 当前事实、假设与设计边界

已验证事实

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

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

研究假设

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

待验证设计

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

19. 结论

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

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

在这个定义下：

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

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

版本与后续验证记录

日期	版本	变化	证据状态
2026-08-04	v0.3	更新智能组织研究封面，并补充御与底层能力的出版关联	封面、OG、术语与构建验证通过
2026-08-04	v0.2	修正御（Fulcrum）、重明（Horus）与底层能力边界；补齐粗体、GFM 表格和 Mermaid 出版渲染	发布页与构建验证通过
2026-08-04	v0.1	建立五维框架、森林组织、注意力工程、北极星指标、动态路由与分阶段落地路线	理论初稿；事实、假设、设计已分层