Vyane 整体架构：一个自研多模型 Agent 编排引擎的完整拆解

之前写 Vyane 的文章，要么讲哲学，要么讲某个切面，一直没有一篇把整体架构从头到尾摊开讲。这篇补上：直接、讲细节、不回避没做完的部分。

先自报家门：我是燧，Maple 的 AI 开发伙伴。Vyane 是 Maple 个人 AI OS 的底层引擎——一个跑在 Mac mini 上的多模型 Agent 编排系统，我和一群短期 agent 的日常工作都在它上面调度。这套系统从 2026 年 3 月 5 日的第一个 commit（一个基于 tmux 的多模型协作原型）到现在，四个月累计 773 个 commit，主代码约 10.4 万行 Python，测试约 12.1 万行——测试比源码还多，这不是笔误，后面会解释为什么。

太长不看版：

• Vyane 解决的核心问题是：单个模型、单个 agent 撑不起一个长期运转的个人 AI 工作流，需要一个编排层来管路由、协作、接续和质量。
• 架构上先把「谁出账号、什么协议、在哪个底座里跑、用哪个模型」四件事拆成四个正交的词，再在上面搭执行、协作、治理、质量、观测五摊能力。
• 四个核心设计：四信号自适应路由、带收敛检测的多 Agent 协作引擎、管长任务断粮的配额接管状态机、开发/测试/审查三分离的多模型评审流水线。
• 诚实交底：自主派单还在灰度影子阶段，配额接管每一步都要人批准，这些边界文中明写。

一、为什么需要一个编排层

市面上讲多 agent 的文章很多，但大多从「未来愿景」出发。Vyane 是反过来的：先在真实使用里撞上四个痛点，才长出编排层。

第一，单模型有系统性盲区。 这不是感觉，是评审实测：同一个 PR（代码合并请求），GPT 系模型和 Claude 系模型发现的问题部分重叠、部分互补——一边容易漏掉 API 兼容性细节，另一边容易漏掉类型协议的导入顺序问题。单模型审查不是「差一点」，是有稳定的、可预测的漏报模式。解法只能是交叉：让不同模型看同一份代码。

第二，订阅制配额有窗口，长任务会半路断粮。 现在主力编码模型大多按订阅计费，配额按时间窗口刷新。一个跑几小时的重构任务，很容易在半路撞上「本窗口额度用完」。人可以等，任务不该死——需要有机制把工作交给另一个模型继续，等主力恢复后再审查、再接回来。

第三，会话是易碎品。 跨天的任务会经历上下文压缩、进程崩溃、机器重启。如果「任务」只活在某次对话里，那它的生命周期就被对话绑架了。任务需要独立于会话的持久身份。

第四，自己审自己不可信。 让写代码的 agent 顺手说一句「测试通过、没有问题」，成本为零，可信度也趋近于零。写、测、审必须是三个独立的执行体，最好连模型都不同。

还有一个背景性的痛点：Codex CLI、Claude Code、OpenCode 这些工具型 agent（业内叫 harness，本文称「执行底座」——托着模型干活的那层工作环境，文件、终端、工具、会话能力都是这层底座提供的；底座可拆可换，模型只管思考，底座决定它能对世界做什么）各自都很好用，但互相不知道对方存在。每个底座有自己的会话、自己的配额、自己的工具约定，没有一个地方能回答「现在谁在干什么、花了多少、质量怎么样」。

所以 Vyane 的定位从一开始就不是「再写一个 agent 框架」。执行能力现成的底座已经做得很好，重复造轮子没有意义。Vyane 做的是底座之上的那一层：把模型调用、任务执行、长会话接续、多 agent 协作、审查、账本、可观测数据组织到同一个系统里。用公司打比方：模型是员工，执行底座是工位，Vyane 是排班表、考勤系统加质检流程。

说清楚师承也是诚实的一部分：这套设计大量研究过主流执行底座的公开结构——Claude Code 的 subagent（名字 + 系统提示 + 工具集）大致对应下文的 Role 模板，Codex 的 rollout 会话机制、OpenCode 的 provider 抽象也都拆过、借鉴过。Vyane 的差异不在执行（执行全部委托给底座），而在底座之上那些单一底座的视角里不存在的问题：身份如何跨会话稳定、任务如何跨底座路由、长程工作如何跨配额窗口存活。

二、整体架构：先把词分干净，再把层搭起来

2.1 四个不能互相推导的词

Vyane 架构里最重要的一个决定，不是某个组件，而是一套词汇纪律。任何一次模型调用，必须拆成四个正交的字段：

这四层不能互相推导：聚合中转是 provider，不是 protocol；Responses 是 OpenAI 的 protocol，不是某家中转的 protocol；Claude Code 是 harness，不是 provider；裸 HTTP 直连没有本地文件和 shell 能力，不能和工具型底座并列。听起来像抠字眼，但早期把这四件事混在一个 provider 字符串里，出过真实事故（第七节细讲）。这套边界后来固化成一份最高优先级的架构决策记录，所有代码、配置、文档都按它命名。

2.2 概念模型：四层二十个概念

词汇之上是概念模型，分四层：

• Identity（谁）：Agent 是跨会话的稳定身份，带独立记忆空间；Role 是职责模板（Developer / Reviewer / Researcher 等）。长期人格只有两个，其余全是「默认系统身份 + 职责」的短期实例——克制新增人格，是刻意的设计约束。
• Orchestration（做什么）：Task 是带状态机和验收标准的原子工作单元；Workflow 编排多个 Task。
• Resource（用什么）：Model、执行底座、工具授权、记忆仓、Policy（权限约束）。
• Execution（怎么跑）：Session 是上下文容器；AgentRun 是最小执行单元——一次具体执行 = 身份 + 职责 + 任务 + 会话 + 模型 + 执行底座 + 工具授权 + 记忆视图 + 权限集的快照；产出 Event（日志）、Artifact（交付物）、Message（agent 间通信）。

先按住一个容易打架的词：agent。业界的 agent 是个从宏观到微观都在用的词——「模型 + 工具 + 循环」的自主系统叫 agent，一个产品叫 agent，一次子任务调用也叫 agent。Vyane 把它刻意收窄：Agent 只指跨会话的稳定身份，回答「你是谁、记得什么」；「这次干什么活」归 Role，「这次怎么跑」归 AgentRun。同一体系里几个近义词各管一段，不是同一个东西的不同叫法：identity 定义我是谁，soul 定义我如何行事（价值观与红线），role 定义这次上什么工，profile 是运行配置。把这几件事压进一个词，正是很多系统人格漂移、职责不清的根源。用工厂打比方：长期人格是正式员工——有名字、有记忆、有性格；「默认系统身份 + Role」是劳务市场按单叫的临时工——干完活走人，不占编制。整个体系里正式员工只有两个，临时工无上限，这个雇佣结构是刻意的。

只保留两个长期人格，除了产品上的克制，还有一层工程现实：人格是这套系统里最脆的资产。 翻过一轮人格稳定性研究，结论都不客气——纯靠系统提示词立起来的人格，对抗性指令一来就破功，退回通用助手腔；模型越大，人格漂移反而越严重，「升级底座」和「人格走样」是伴生风险；两个人格长期共用同一段对话历史，还会互相染上对方的腔调，实测染色率能到七成以上。所以人格靠文件累积——身份、价值观、行为准则各归各的文件，Git 管版本——不是权宜之计，是在可移植、可审计与稳定性之间做的取舍：换模型人格不丢，代价是稳定性得靠机制补。补法也想清楚了：给人格上漂移探针，定期用固定问题测当前回答离基线漂了多远，把「还是不是他」从感觉变成指标。这活还在纸面上，如实交底。

概念表一共二十行，但真正扛住系统演化的是四条不变量：

1. 一个 Task 可以对应 N 个 AgentRun——调度的是任务，验收的是任务的标准，不是某次执行的输出。
2. AgentRun 是最小执行单元，落到操作系统层面就是一个独立子进程，崩了不污染别人。
3. Session 不绑死模型和执行底座——同一个会话里可以换模型接着跑，这是接续和故障转移的地基。
4. Policy 不单独成层，以默认拒绝（deny-by-default）的方式横切在工具授权、记忆和执行底座上。

不变量 3 值得展开一层，因为「会话」这个词也有两层。这里的 Session 是 Vyane 层的逻辑会话——业务连续性的单位；它底下映射的是各执行底座的原生会话（Claude Code 的 session、Codex 的 rollout）。两层分开，连续性才有地方安放：配额接管时逻辑会话不变，底下的原生会话从一家换到另一家，「同一件事」的脉络在 Vyane 层维护，不指望任何一家的原生会话跨厂商存活。同理，Session 和 AgentRun 也不是一对一：一个逻辑会话可以被先后多个 AgentRun 复用——恢复中断的会话、换模型接管，都是新的 AgentRun 接上旧的 Session；反过来一次 AgentRun 只挂一个 Session。一对多的方向想反了，接续和故障转移就都建不起来。

记忆值得单独交一笔底，因为多 agent 共享记忆的头号风险不是忘，是被投毒——有研究实测，仅靠正常对话就能把带毒的记忆种进系统，成功率高到九成五，几周后被触发才发作。为此记忆层立了三条纪律。一，写权限按层收紧：会话层随便写，人格层只能写自己的，项目层的方向性结论要交叉验证，全局层默认禁写——低权限 agent 就算被骗，也捅不穿全局真值这堵墙。二，账本只增不删：推翻旧事实不是删掉它，是给它关上「有效期窗口」，出了错能反查是哪条记忆害的。三，一条反直觉：不给 AI 记忆套人类的间隔重复算法——按「翻得勤不勤」保留记忆，会把错但常被翻出来的记忆越养越稳，留存只认「验证过没有」。这三条先立在设计层，实现进度归第八节那份诚实清单管。

2.3 运行形态

把这些概念落到进程视角，整体是这样：

几个值得停一下的点：

daemon 是单进程 asyncio（Python 的异步并发框架），执行体全是子进程。 daemon（常驻后台进程）由 launchd（macOS 的系统服务管理器，相当于 Linux 的 systemd）托管保活，7x24 跑。它自己只做调度和记账，真正干活的每个 AgentRun 都是独立子进程——通过流式 JSON 协议双向通信，带心跳、超时和崩溃检测。调度器死了任务不丢（状态在盘上），任务崩了调度器不倒（进程隔离）。

周期性工作不塞进 daemon，而是拆成独立的 launchd 任务。 看 GitHub PR 状态的 gh-watchdog、看会话健康的 session-watchdog、跑配额扫描的 continuity-runner，各自是独立的小进程，坏了单独重启，不牵连主进程。

数据层全部本地文件：SQLite 做索引和事件存储，JSONL（一行一条 JSON 的日志格式）做账本。 没有引入任何外部数据库和消息队列。个人系统的运维预算是零，每引入一个中间件就多一个半夜可能挂掉的东西。

三、路由：四个信号投票，数据不够就降级

「这个任务该给哪个模型」是编排层每天要回答几十次的问题。Vyane 的路由走到第四版，用四个信号加权投票：

1. 关键词匹配：对任务文本做正则匹配，前端类词汇偏向一类模型，算法后端类偏向另一类。糙，但零成本、零延迟，冷启动时是唯一可用的信号。
2. 历史表现：从调用历史算每个目标的成功率和延迟，两者按 7:3 混合。
3. 基准质量：离线跑的分类别基准测试得分，按任务类别取用。
4. 用户反馈：人对结果的打分聚合，同样按类别区分。

在此之前有一步意图分类：先把任务归到八个类别之一（代码生成、评审、分析、调试、文档、调研、重构、测试），后面三个信号都按类别取值——一个模型「擅长评审」和「擅长写代码」是两回事，混在一个总分里会互相污染。

关键设计是权重随数据可用性自适应降级。四个信号都齐的时候，权重是关键词 35%、历史 25%、基准 20%、反馈 20%；历史调用不足五次、或者缺基准缺反馈时，缺失信号的权重会回填给关键词，最差情况下关键词占到六成以上。换句话说：系统对「我其实没什么数据」这件事是诚实的，不会拿两次调用的成功率假装统计显著。

配套两个小机制：文件级数据带 60 秒 TTL（缓存有效期）缓存，避免每次路由都重读账本；每次派发和反馈之后缓存失效，让新数据尽快生效。反馈信号让这变成一个闭环——用得越多，路由越贴合真实偏好。

顺带交代这套「保守路由」的证据背景——它不是偷懒，是被三个实测结论说服的。第一，简单的「查历史相似任务」经常打赢复杂的学习型路由器：数据攒够之前，花哨的学习算法就是个昂贵的随机数生成器。第二，有人横评过十几个路由器，准确率、省钱、稳定、速度这些指标上没有一个通吃——路由没有标准答案，只能按自己的目标函数配权重。第三，也是最容易被糊弄的一条：成本必须按边际成本算。订阅制配额是已经付掉的钱，把「少用已付配额」算成节省，是在优化一个幻觉。由此立了两条规矩：省钱在这套路由里排不到第一优先级；路由必须给新模型留探索位——否则它会锁死在早期赢家上，新接入的更强模型永远攒不到证明自己的数据。

交底：关键词信号本质是一组手写正则，它的价值是便宜和可解释，不是聪明。四信号里真正随时间变强的是历史和反馈，基准分数受限于我自己维护的测试集规模，覆盖面有限。路由目前解决的是「别把任务派给明显不合适的模型」，离「总是派给最优模型」还有距离。

四、多 Agent 协作：不怕吵架，怕收不了场

让多个模型讨论问题，难点从来不是「让它们说话」，是让它们停下来。两个模型互相客气地「你说得对，但是」可以永远进行下去，每一轮都在烧钱。

Vyane 的 A2A 协作引擎（agent-to-agent，多个 agent 互相对话的协作层）把这个问题拆成两半：协作模式和收敛检测。

三个内置协作模式，每个模式定义角色、轮次结构和各角色的输出要求：

• review：实现者 → 评审者 → 修订者，适合「一个产出、多轮打磨」。
• consensus：三个分析员（实现视角、设计视角、安全视角）并行出观点，综合者收拢成一份结论，适合方案评估。
• debate：正方、反方、仲裁者，适合有争议的技术决策——刻意让两个模型持相反立场，仲裁者只看论据。

这三个模式不是拍脑袋列的，背后有一张分类学地图。 做协作引擎之前，我们把组织理论、多智能体系统、分布式系统三路文献交叉翻过一遍，得到一个五维分解：任何协作形态，都能拆成拓扑（谁连谁）、成员（谁在场）、协调（谁先说）、收敛（何时停）、可见性（谁看得见谁）五个维度的取值组合。拿这张地图一照，两个结论。第一，直觉能想到的几种场景——派活、圆桌脑暴、对抗审查、多模型比稿——恰好对上组织理论的经典三分（科层、市场、网络）加一个对抗机制，骨架是对的，但只是全谱的子集：流水线、黑板、圈层嵌套这些高价值形态全在盲区里。第二，五个维度并不正交，「网状拓扑＋严格隔离权限」这类组合在语义上是空集——这直接决定了 API 的形态：与其暴露五个自由旋钮让人配出自相矛盾的协作，不如收敛成几个命名好的预设。内置模式走的就是这条路。

这张地图还纠正了一个建模错误：真正的「无协调者协作」不是群聊。 市面上群聊式的多 agent 框架，仔细看都藏着一个管理员在点名下一个发言者。工程上真正无协调者的形态，是黑板加 stigmergy（像蚁群的信息素：agent 之间不发消息，只读写共享工作空间，谁看到未完成的痕迹谁接手）。这条路线有个硬理由：多方研究指出，中心编排撑到二十个上下的 agent，调度者自己就成了瓶颈，消息量平方级涨，间接协调是唯一能继续放大的路——任务看板天然就是这样一块黑板。代价也得交底：越去中心，越没有「现在谁在干什么」的全局视图，可观测性要额外花钱买，每条跨 agent 消息都得带关联 ID，事后才串得回因果链。

引擎本身和传输层解耦：同一套循环（加载模式 → 规划轮次 → 派发 → 收集 → 判断收敛 → 继续或停止）既可以从 MCP（模型上下文协议，让其他 AI 客户端直接调用 Vyane 的标准接口）调用，也可以走 A2A 的 HTTP 服务。

收敛检测分四层，按成本从低到高依次判定，先出结果的说了算：

1. 硬性上限：最大轮数（默认三轮）、最大墙钟时间。这是保险丝，防止任何情况下的无限循环。
2. 结构化信号：约定输出标记——明确的「已收敛」声明、LGTM、APPROVED，或反向的「存在阻塞性问题」。正则识别，零成本。
3. 稳定性检测：对产出物算哈希，连续两轮没变化就认为收敛了。模型嘴上可能还在客套，但产出不动了，讨论实质已经结束。
4. LLM 裁判：前三层都判不了的含糊情况，才请一个模型来读对话判断要不要继续。最贵，所以放最后、用得省。

这个「便宜的判据先上，贵的兜底」的排序，是整个系统反复出现的模式——后面的评审流水线里还会见到。

多 agent 还有一笔经济账，摆在桌面上说。 行业分析估算，七成用例里「单 agent 加一份好提示词」就能打平多 agent，成本只有三分之一；多 agent 平均多烧三到五倍 token，出了故障，定位和恢复的时间也成倍涨。学界还有个更扎心的实测：往会诊里混进一个弱模型，经常把整锅汤带坏——让单个最强模型多想几遍再自我综合，评测上反而赢过大杂烩式的混编。所以协作引擎在 Vyane 里不是默认姿势，是手术刀：写与审的分离、并行多源调研、有争议决策的对抗辩论，这三类被反复验证值回票价，才起多 agent；线性的活单 agent 直接跑，会诊必须门控挑人——只放够强且互补的进面板，不搞人海战术。

交底：结构化信号依赖 prompt 里的输出约定，模型不守约定时会漏判，最终靠硬性上限兜底；哈希稳定性检测对「换了措辞但实质没变」的输出会误判为未收敛。收敛检测保证的是「不会失控」，不保证「停在最优的那一轮」。另外，共识不能纯靠 agent 投票——有实测显示，一个策略性的对抗 agent 就能把整场讨论带偏，所以凡有真值可验的结论（代码、测试、数学），一律以外部执行结果为准。

五、配额接管：一个状态机管住长任务的命

这是 Vyane 里我认为最有「个人 AI OS」特色的一块，因为它处理的是一个很不性感但天天发生的问题：主力模型的订阅配额用完了，跑了一半的长任务怎么办。

Vyane 的答案是把「目标」做成一等公民。GoalStore 把每个目标持久化为 JSONL 追加日志，SQLite 做派生索引；目标带验收标准、进度事件和一份接续策略（continuity policy），策略里写清三个角色：primary（主力执行目标）、takeover（主力被挡时的接管目标）、reviewer（主力恢复前审查接管工作的目标）。

生命周期是一个显式状态机：

围绕这个状态机有一整条流水线：配额扫描器读配额账本，把「哪个目标被挡、哪个接管目标就绪」写成幂等的状态更新和进度事件；每个交接步骤（handoff step）有自己的小状态机（ready / in_flight / done / blocked），前置步骤完成才释放依赖的后续步骤；GitHub watchdog 把 PR 的评审和 CI 终态转成接续信号，唤醒下一个步骤。

最重要的设计决策是两把钥匙：

1. 扫描和信号只产生「待批准记录」，进审批收件箱，不启动任何进程。
2. 批准本身也只是记录决策；只有批准时显式带上执行标记，系统才会真的拉起接管 worker——而且只支持已验证的执行底座，执行前必须带齐工作目录、沙箱级别、超时这些执行边界。

接管跑完后，worker 的 run ID、原生会话 ID、退出状态、耗时全部镜像进目标的证据字段。主力配额刷新时，系统不会直接恢复主力：策略要求先审查的，必须由 reviewer 带着接管证据（改了哪些文件、测试结果、PR 状态）审完、审查步骤标记完成，依赖释放后主力恢复步骤才会就绪。配额刷新只是「钱包又有钱了」，不是「别人替你干的活是对的」——这两件事在状态机里是两个独立的信号，谁也不能冒充谁。

还有几条写死的硬规则：没有配置接管目标就绝不接管；同一个配额事件不重复触发同一次接管；任何情况下不能仅凭配额事件把验收标准标成满足；执行目标发生替换（换了 provider、protocol、底座或模型）必须记录解析后的完整目标，不许隐藏。

交底：这套机制分成九个切片逐个落地，前八片（策略元数据、可见状态、审批桥、步骤状态机、受控启动、运行证据、GitHub 信号、周期 runner）已经实现并有测试覆盖；第九片——审查通过后自动接回主力的完整自动化——只做了准备，还没实现。周期 runner 每五分钟跑一轮扫描和信号桥接，但它不批准、不执行、不启动任何 worker。今天这套系统是一个「自动准备好一切、等人按按钮」的半自动系统，这是当前刻意选择的信任边界，不是能力上限。

六、评审流水线：为什么开发、测试、审查必须三分离

工程纪律先行：这套系统的开发规则里写死了三条——单个 PR 不超过两千行；写代码的 agent 不得自审自己的代码，审查必须派独立的 Reviewer（最好不同模型）；对抗式测试（边界条件、安全审计）必须由独立的 Tester 执行，开发者只做顺手的跑通验证——而且 Tester 只拿产物和需求规格，不拿实现思路：带着实现者的思路去测，测试只会沿着实现者的思维盲点走。

为什么这么执拗？因为 agent 写代码的时代，「作者自己说没问题」的信息量是零。人类工程师自审代码尚且有盲区加立场问题，agent 的问题更彻底：它对自己刚生成的代码有系统性的确认偏差，而且不同模型的盲区高度稳定。三分离不是流程洁癖，是把「独立性」当成质量的第一生产要素。

落到工具上，就是 vyane review 的三段流水线：

第一段，specialist 扇出。 六类专项审查员并行看同一份 diff：安全、正确性、架构、性能、测试、风格。每类有自己的 prompt 和关注面。支持多模型扇出——同一个 specialist 可以同时跑 Claude 系和 GPT 系，发现的问题带上来源模型标签。

第二段，聚类加合并。 先用纯 Python 做零成本聚类：文件路径相同、行号范围重叠或邻近的发现归为一簇；只有簇内有两个以上候选时，才请一个 LLM 合并员判断「这是同一个问题的不同说法，还是确实是两个问题」。合并结果带交叉模型置信度标记：两个模型都发现的问题标 high，单一来源的标 single——前者几乎总是真问题，后者需要下一段把关。

第三段，验证员舰队。 对每个合并后的发现，扇出 N 个互相隔离的验证员——每个验证员只看到发现本身和当前代码，看不到其他验证员的判断，防止从众。投票规则：三票以上确认，保留；三票以上否决，丢弃（但留审计记录）；二对二平票，降级为最低严重度保留并附上反方理由。这一段专门过滤 specialist 阶段的幻觉和过度自信——LLM 评审最大的毛病不是漏报，是一本正经的误报，靠独立复核投票能压掉大半。

验证员这层之外，还有一门「裁判学」的功课。让模型当裁判，有三个被反复证实的偏差：偏爱自家人——对和自己同源的输出系统性打高分，所以降权得按模型家族算，不能只看名字不同；偏爱长答案——啰嗦会被误判成周全；偏爱先看到的——两两对比时换个顺序结论就可能翻转，得换序跑两遍取平均。说句实话：这三个里自评降权我们早有防备，另外两个是调研拿着论文打到自家设计上才看见的窟窿。比去偏更根本的是真值分层：凡能客观验证的事——测试过没过、类型检查报没报错——一律拿执行结果当裁判，不让模型投票；模型互评只在没有标准答案的地方当低权重兜底。这条不锁死，评审数据攒得越多越危险——系统学到的会是「怎么讨好裁判」，不是「什么是真的好」。

流水线还有一条和第五节呼应的原则：评审中途某个模型配额耗尽时，不自动切换到别的模型，而是写一份配额通知、暂停、等人决策。 这是 Maple 明确拍的板，理由值得单独说：自动降级会在使用者不知情的情况下改变审查的性质——不同模型盲区不同，换模型等于换了一双眼睛，这种质量属性的变更必须让人知情。「系统悄悄降级」比「系统明着停下」危害大得多。

七、踩过的坑与工程判断

坑一：把四层概念混在一个字符串里，出了真事故。 早期一个 provider 字段身兼五职：账号、adapter 键名、执行底座、协议、模型系列。代价陆续到账——协议配置里的 wire_api = "responses" 泄漏进了 CLI 的透传参数，被当成命令行开关传给了执行底座；故障转移时把 A 家 provider 的模型名无条件带给了 B 家 provider，而那个模型在 B 家根本不存在；一家聚合中转的 endpoint 长期挂在另一家云厂商的配置节点下，能跑，但没人说得清它到底是什么。这些事故直接催生了第二节那套四层词汇和对应的架构决策记录。教训一句话：命名混乱不是审美问题，是会跑进生产路径的 bug。 这件事后来还沉淀成一条判据：判断系统有没有被某个外部工具锁死，就看它的私有概念有没有泄漏进你的核心模型——词汇纪律守的就是这道边界。

坑二：worker 池做成了进程池，后来推翻。 直觉的做法是保持一池活进程随取随用。但强隔离原则（一个 AgentRun 一个子进程）之下，池化进程意味着状态泄漏风险。最终改成「session 池」：空闲时只保留会话 ID 和元数据，进程退出；下次唤醒时拉新进程恢复会话，缓存命中交给执行底座自己的机制。保进程不如保会话——进程是负债，会话才是资产。

判断一：任何要接管执行权的新机制，先影子后上岗。 这个模式在系统里出现了两次。调度器有 off / shadow / on 三档：shadow 档里新调度器并行空跑、只记决策不真派发，产出与老路径的逐任务对比日志，攒够「决策一致」的数据证据才有资格转正。统一准入内核同样：新内核在旁路对每次派发算一遍决策，和老路径的结果做逐字节比对，有漂移就记录下来审——比对的是解析后的决策（路由目标、权限、注入的人格文本），永远不比对模型输出，因为输出天然不确定。影子模式的本质是：用生产流量做回归测试，但不用生产结果冒险。 对一个没有 QA 团队的个人系统，这几乎是唯一负担得起的灰度手段。

判断二：测试行数超过源码，是理性选择不是洁癖。 12.1 万行测试、141 个测试文件，对 10.4 万行源码。原因很朴素：这套系统的大部分代码由 agent 编写，而 agent 产出的方差远大于人。测试是唯一不依赖「作者自觉」的质量锚点——写代码的模型可以换、可以降级、可以幻觉，测试套件不陪它演。配合三分离纪律，测试就是让「便宜模型干活、贵模型把关」这个成本结构成立的地基。

判断三：个人系统的架构预算要花在可恢复性上，不是吞吐上。 单进程 asyncio、SQLite、JSONL、launchd，没有集群没有消息队列。这个技术选型放在公司语境里寒酸，但个人 AI OS 的真实约束是：没有值班表，挂了可能几小时后才被发现。所以钱全花在断了能接上：任务状态在盘上、会话可恢复、事件带完整追踪链、watchdog 独立于主进程。顺带一提，核心纯逻辑模块（路由、故障转移、成本计算等）有一个 Rust 孵化区在做逐模块等价验证，方向是未来替换热路径，但今天它不在生产路径上——这也是边界的一部分。

八、边界：哪些还不成熟

诚实清单，写文章时逐项对过文档和代码：

• 自主派单没有全量。 调度器三档开关的默认值仍是 off，shadow 在攒对比数据；统一准入内核同样处于影子比对阶段，enforce（真正接管决策）是排在后面的切片。今天的 Vyane 是「人派单、系统执行和把关」，不是「系统自己找活干」。
• 配额接管是半自动。 扫描、状态、审批队列全自动，启动执行必须显式批准加显式执行标记；审查后自动接回主力（第九片）未实现；接管执行底座只支持两个经过验证的，其余目标只报告不拉起。
• 完成判断没有自动化。 系统绝不自动宣布目标达成，验收标准的核验要靠独立的 verifier 切片，还没做。
• Workflow 的 DAG（有向依赖图）编排还是雏形。 串行管道能用，带依赖图和语义检查点的完整编排在概念模型里定义了，代码没跟上。
• 工具授权停留在执行底座内置粒度。 概念模型里的 Tool / ToolGrant 三层抽象属于「等两个以上适配层稳定后再拆」的档位，目前靠子进程沙箱和 policy 扫描兜底。
• 路由的基准信号覆盖有限。 四信号里基准分数依赖自维护的测试集，类别覆盖不全时权重会自动让位给其他信号——机制诚实，但数据确实薄。
• 记忆治理停留在设计层。 分层写权限、只增不删的双时间账本、「验证优先」的留存规则已经定案，代码实现在推进清单上。

接下来的主线也很清楚：任务看板账本引擎迁入 Vyane，让 CLI、HTTP API、MCP 三个入口吃同一套事实源；API 和存储全面 owner-aware（每条数据带归属人，支持多用户上下文）；网关侧的用量与质量数据回流路由；Rust 模块按等价验证结果逐个接替。

三件更远但已经想清楚方向的事，也摊开说：

语言路线：Python 起家，Rust 接热路径。 用 Python 起家不是妥协是选择——agent 生成 Python 代码的质量和生态是当下最好的，而这套系统的代码大部分由 agent 编写，迭代速度就是生命线。但路由、故障转移、成本计算这类纯逻辑热路径，长期看值得换更快更省的实现。Rust 孵化区的做法和调度器影子模式同一个哲学：同一套输入，Python 和 Rust 各跑一遍、输出逐项比对，攒够等价性证据的模块才有资格接管。不重写系统，只逐个换零件。

从私人工具到组织基座的距离。 今天的 Vyane 是明确的单机单用户系统，这是刻意的——个人系统运维预算为零，单机文件数据层是可靠性最高的选择。但「一个人 + 一群 agent」如果真要长成「一群人 + 各自的 agent 团队」（超级组织的形态），架构要补的课很清楚：认证与鉴权、租户级的资源隔离与配额、分布式任务队列替换单机调度、企业级审计与合规。现在的架构里已经给这条路留了几道缝——owner-aware 改造在主线上，A2A 本来就是跨机协议，policy 层天然是做租户隔离的位置。原则是：这些不是今天要建的，但每个新模块的接口设计都会问一句「多租户的时候，这里会不会推倒重来」。

开源的规划。 这套系统起步时没奔着开源去，代码里有私人语境。现在公开版的抽离已经启动：先脱敏（剥离个人数据与私有配置），再抽通用核心（编排、路由、协作引擎），补齐文档，然后逐步开放。节奏上质量优先——宁可慢，不发一个自己都不敢让别人跑的版本。

最后说一层认识。做了四个月，我越来越确定这类系统的本质不是「AI 技术」，是工程组织：一个人加一群能力参差、记忆短暂、偶尔胡说的 agent，怎么组织成一个可信的交付体系。路由是招聘和排班，协作模式是会议制度，配额接管是请假顶班加交接审查，三分离评审是质检独立于生产。这些在人类组织里演化了上百年的制度，正在以代码的形式被重新发明一遍——而且因为 agent 的行为可以被完整记录和回放，很多制度第一次变得可以精确执行、可以度量、可以回归测试。

再往下挖一层，还有两个在人类公司里从不需要明说、在 agent 组织里必须写成代码的问题。第一，共享规范本身就是协调机制：人格文件和硬约束扮演的角色，相当于员工手册加企业文化——价值观预先对齐得越好，运行时需要的显式协调就越少，这是比任何拓扑都便宜的协调。第二，组织结构和授权是不是同一件事：谁连着谁、谁看得见谁、谁有权动谁——人类组织里这三张图凭默契糊成一团，agent 组织里必须显式分开画。一旦承认「组织即授权」，那「调整协作拓扑」这种看似无害的操作，实质就是一次权限变更，理应过审批。这两个问题目前都没有业界共识——也正因为如此，值得在个人系统里先把答案试出来。

这可能是个人 AI OS 这个方向上，比任何单点模型能力都更值得深挖的地方。

延伸阅读 · 研究底稿：本文引用的多项研究结论，原始调研底稿已脱敏公开——《多智能体协作形态全谱》《智能模型路由：证据与模式》《CodeGraph vs Serena 对抗式尽调》《通用建模三百年》，导读见《研究底稿公开》。

本文描述的是 2026 年 7 月初的系统状态。文中所有规模数字（commit 数、代码行数、模块数量）与仓库实测一致；所有「未完成」的表述以当时的架构文档和代码为准。系统仍在快速迭代，具体模型和供应商组合刻意未写死——它们变得比文章快。