偃 · Vyane

摘要

偃（Vyane）是一个自研的多模型 Agent 编排引擎，跑在 Mac mini 上 7×24 运行，是个人 AI OS 林爝的调度中枢。它解决的核心问题是：单个模型、单个 agent 撑不起一个长期运转的个人 AI 工作流——任务该派给谁、多个 agent 怎么协作并及时收场、订阅配额用尽的长任务怎么续命、agent 自报的”做完了”怎么核验，都需要一个编排层来管。从 2026 年 3 月的第一个 commit 到现在，四个月累计 773 个 commit、约 10.4 万行 Python 源码、约 12.1 万行测试（测试比源码多，是刻意为之），已发布到 PyPI，承担全部日常工程调度。四个有代表性的设计：四层正交的执行词汇、四信号自适应路由、带收敛检测的多 Agent 协作、管长任务断粮的配额接管状态机。诚实交底：自主派单仍在影子灰度阶段，配额接管的每次执行都要人批准——半自动是当前刻意选择的信任边界，不是能力上限。

名字取自《列子·汤问》的偃师——周穆王时期造出第一个”自动人偶”的工匠。Vyane 做的是同一件事：把多个 AI 模型像偃师编排关节那样编排成一个有机整体。英文 Vyane 发音接近”偃”的拼音 yǎn。

背景与动机

Vyane 不是从”多 agent 愿景”出发设计的，是在真实使用里先撞上四个痛点，才长出编排层：

1. 单模型有系统性盲区。 评审实测：同一份代码变更，GPT 系和 Claude 系模型发现的问题部分重叠、部分互补——一边容易漏 API 兼容性细节，另一边容易漏类型协议的导入顺序。单模型审查不是”差一点”，是有稳定、可预测的漏报模式，解法只能是让不同模型交叉看同一份代码。
2. 订阅制配额有时间窗口，长任务会半路断粮。 主力编码模型多按订阅计费、配额按窗口刷新。跑几小时的重构很容易撞上”本窗口额度用完”——人可以等，任务不该死。
3. 会话是易碎品。 跨天任务会经历上下文压缩、进程崩溃、机器重启。任务如果只活在某次对话里，生命周期就被对话绑架了；任务需要独立于会话的持久身份。
4. 自己审自己不可信。 让写代码的 agent 顺口说”测试通过、没问题”，成本为零，可信度也趋近于零。写、测、审必须是三个独立执行体，最好连模型都不同。

还有一个背景性痛点：Codex CLI、Claude Code、OpenCode 这些工具型 agent（后文叫执行底座）各自好用，但互不知道对方存在——没有一处能回答”现在谁在干什么、花了多少、质量怎么样”。所以 Vyane 的定位从一开始就不是再造一个 agent 框架：执行能力现成的壳已经做得很好，它做壳之上那一层。用公司打比方：模型是员工，执行底座是工位，Vyane 是排班表、考勤系统加质检流程。

系统概览

执行词汇：四个不能互相推导的字段

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

这四层不能互相推导：聚合中转是 provider 不是 protocol；Claude Code 是 harness 不是 provider；裸 HTTP 直连没有本地文件和 shell 能力，不能和工具型壳并列。早期把四件事混进一个字段，出过真实事故（见「技术亮点与工程判断」），之后这套边界固化为最高优先级的架构决策记录，所有代码、配置、文档按它命名。

概念模型：四层二十个概念，四条不变量

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

真正扛住系统演化的是四条不变量：一个 Task 可对应 N 个 AgentRun（调度和验收的对象是任务，不是某次执行的输出）；AgentRun 落到操作系统层面就是一个独立子进程，崩了不污染别人；Session 不绑死模型和执行底座，同一会话可换模型接着跑——这是接续和故障转移的地基；权限不单独成层，以默认拒绝（deny-by-default）的方式横切在工具授权、记忆和执行底座上。

运行形态

┌─ 接入层 ─────────────────────────────────────────────┐
│  MCP server（14 个工具）· CLI（17 个子命令）· HTTP API   │
│  · A2A（agent 间通信）· dashboard                  │
├─ 编排核心 ───────────────────────────────────────────┤
│  dispatch / broadcast / workflow / orchestrate /       │
│  collaborate · 四信号智能路由 · 故障转移 · 目标解析      │
│  准入内核（准入 ∩ 人格装配 ∩ 路由决议，影子灰度中）       │
├─ 执行层 ─────────────────────────────────────────────┤
│  daemon（常驻后台服务，单进程 asyncio，系统服务托管保活）  │
│  子进程管理：一个 AgentRun 一个子进程，流式 JSON 双向通信  │
│  session 管理 · 调度器（off / shadow / on 三档灰度）     │
├─ 长程与治理 ──────────────────────────────────────────┤
│  目标存储 + 配额接管状态机 · 审批收件箱                   │
│  权限策略 · 审计 · worktree 隔离                        │
├─ 质量层 ─────────────────────────────────────────────┤
│  评审流水线：6 类专项审查 → 聚类合并 → 验证员舰队投票      │
├─ 适配层 ─────────────────────────────────────────────┤
│  11 个 adapter 实现 / 7 个活跃注册                      │
├─ 数据层 ─────────────────────────────────────────────┤
│  SQLite + JSONL：事件 · 调用历史 · 用量成本 · 配额账本    │
└──────────────────────────────────────────────────────┘
外围独立守护任务：PR 状态监视 · 会话健康监视 · 配额周期扫描

三个值得停一下的点：daemon（常驻后台服务）是单进程异步调度，执行体全是子进程——调度器只做调度和记账，真正干活的每个 AgentRun 都是独立子进程，带心跳、超时和崩溃检测；调度器死了任务不丢（状态在盘上），任务崩了调度器不倒（进程隔离）。周期性工作不塞进主进程：PR 监视、会话健康、配额扫描各自是独立小进程，坏了单独重启，不牵连主进程。数据层全部本地文件：SQLite 做索引与事件存储，JSONL（一行一条 JSON 的追加日志）做账本，不引入任何外部数据库和消息队列——个人系统的运维预算为零，每加一个中间件就多一个半夜可能挂掉的东西。

核心设计与功能

四信号自适应路由

“这个任务该给哪个模型”是编排层每天要答几十次的问题。路由走到第四版：先做意图分类，把任务归到八个类别（代码生成 / 评审 / 分析 / 调试 / 文档 / 调研 / 重构 / 测试）；再用四个信号加权投票——关键词匹配（正则，糙但零成本零延迟，冷启动时唯一可用）、历史表现（成功率与延迟按 7:3 混合）、离线基准得分、用户反馈聚合。后三个信号都按类别取值：“擅长评审”和”擅长写代码”是两回事，混在一个总分里会互相污染。

关键设计是权重随数据可用性自适应降级：四信号齐备时按 35 / 25 / 20 / 20 分配；历史调用不足五次、或缺基准缺反馈时，缺失信号的权重回填给关键词。换句话说，系统对”我其实没什么数据”这件事是诚实的，不拿两次调用的成功率假装统计显著。配套 60 秒 TTL 缓存避免每次路由重读账本，派发和反馈后缓存失效让新数据尽快生效——反馈信号让路由成为闭环，用得越多越贴合真实偏好。

多 Agent 协作与收敛检测

让多个模型讨论问题，难点不是让它们说话，是让它们停下来——两个模型互相客气地”你说得对，但是”可以永远进行下去，每一轮都在烧钱。协作引擎把问题拆成两半：

三个内置协作模式：review（实现者 → 评审者 → 修订者，一个产出多轮打磨）、consensus（实现 / 设计 / 安全三视角并行出观点，综合者收拢成一份结论）、debate（正方、反方、仲裁者——刻意让两个模型持相反立场，仲裁者只看论据）。引擎与传输层解耦，同一套循环既可从 MCP 调用，也可走 HTTP 服务。

收敛检测分四层，按成本从低到高依次判定，先出结果的说了算：硬性上限（最大轮数、最大墙钟时间，任何情况下的保险丝）→ 结构化信号（约定的”已收敛”声明 / LGTM / 阻塞性问题标记，正则识别零成本）→ 稳定性检测（对产出物算哈希，连续两轮不变即判收敛——模型嘴上可能还在客套，但产出不动了，讨论实质已经结束）→ LLM 裁判（前三层判不了的含糊情况才请一个模型来读对话，最贵所以放最后、用得省）。“便宜的判据先上、贵的兜底”是整个系统反复出现的模式。

配额接管状态机

最有”个人 AI OS”特色的一块，处理一个不性感但天天发生的问题：主力模型配额用完，跑了一半的长任务怎么办。 答案是把”目标”做成一等公民：每个目标持久化为 JSONL 追加日志 + SQLite 派生索引，带验收标准、进度事件和一份接续策略，策略写清三个角色——primary（主力）、takeover（主力被挡时的接管者）、reviewer（主力恢复前审查接管工作的评审者）。生命周期是显式状态机：

in_progress → primary_blocked → takeover_ready → takeover_running
→ takeover_waiting_review → review_running → primary_resume_ready
→ primary_running → completed / failed / paused / cancelled

围绕状态机是一整条流水线：配额扫描器读配额账本，把”哪个目标被挡、哪个接管者就绪”写成幂等的状态更新和进度事件；每个交接步骤有自己的小状态机（就绪 / 执行中 / 完成 / 受阻），前置步骤完成才释放依赖的后续步骤；PR 监视把评审与 CI 终态转成接续信号，唤醒下一步。最重要的设计决策是两把钥匙：扫描和信号只产生”待批准记录”进审批收件箱，不启动任何进程；批准本身也只是记录决策，只有批准时显式带上执行标记，系统才真的拉起接管 worker，且执行前必须带齐工作目录、沙箱级别、超时这些执行边界。

接管跑完，运行 ID、原生会话 ID、退出状态、耗时全部镜像进目标的证据字段；主力配额刷新时系统也不会直接恢复主力——策略要求先审查的，必须由 reviewer 带着接管证据（改了哪些文件、测试结果、PR 状态）审完，依赖释放后主力恢复步骤才会就绪。配额刷新只是”钱包又有钱了”，不是”别人替你干的活是对的”——这两件事在状态机里是两个独立信号，谁也不能冒充谁。另有几条写死的硬规则：没配置接管者绝不接管；同一配额事件不重复触发同一次接管；任何情况下不能仅凭配额事件把验收标准标成满足；执行目标发生替换必须记录解析后的完整目标，不许隐藏。

三分离评审流水线

工程纪律先行：单个 PR 不超过两千行；写代码的 agent 不得自审自己的代码，审查必须派独立 Reviewer（最好不同模型）；对抗式测试（边界条件、安全审计）由独立 Tester 执行。agent 写代码的时代，“作者自己说没问题”的信息量是零——三分离不是流程洁癖，是把独立性当成质量的第一生产要素。落到工具上是三段流水线：

1. 专项审查扇出：六类审查员（安全 / 正确性 / 架构 / 性能 / 测试 / 风格）并行看同一份变更，每类有自己的关注面；支持多模型扇出，发现的问题带来源模型标签。
2. 聚类与合并：先用纯 Python 做零成本聚类（文件路径相同、行号范围重叠或邻近的归为一簇），簇内有两个以上候选时才请一个 LLM 合并员判断”这是同一问题的不同说法，还是确实是两个问题”。合并结果带交叉模型置信标记：两个模型都发现的标 high（几乎总是真问题），单一来源的标 single，交给下一段把关。
3. 验证员舰队：对每个合并后的发现扇出 N 个互相隔离的验证员——各自只看到发现本身和当前代码，看不到彼此的判断，防止从众。投票规则：三票以上确认，保留；三票以上否决，丢弃（留审计记录）；平票降级为最低严重度并附上反方理由。这一段专门过滤前一阶段的幻觉与过度自信——LLM 评审最大的毛病不是漏报，是一本正经的误报，靠独立复核投票能压掉大半。

流水线还有一条原则：评审中途某个模型配额耗尽时，不自动切换到别的模型，而是写一份配额通知、暂停、等人决策。不同模型盲区不同，换模型等于换了一双眼睛——这种质量属性的变更必须让人知情。“系统悄悄降级”比”系统明着停下”危害大得多。

当前进度

已在生产运行（每天在用）：daemon 7×24 常驻；7 路模型活跃接入——Claude / Codex / Gemini / Ollama 本地 / 阿里云 / 火山方舟（Kimi、GLM、DeepSeek、豆包等）/ OpenCode 通用包装（另有 11 个 adapter 实现中 2 个停用保留、1 个通用自定义、1 个远端 A2A）；四信号路由；三段评审流水线；配额扫描 + 审批收件箱；MCP / CLI / HTTP / dashboard 四个入口；移动端触达由重明（Horus）承接中。

影子灰度中（并行空跑、只记决策不接管）：新调度器分 off / shadow / on 三档，默认仍是 off，shadow 档产出与老路径的逐任务对比日志，攒够”决策一致”的数据证据才有资格转正；统一准入内核同样在旁路对每次派发算一遍决策，与老路径逐字节比对——比对的是解析后的决策（路由目标、权限、注入的人格文本），永远不比对模型输出，因为输出天然不确定。

明确未完成：审查通过后自动接回主力的完整自动化（配额接管九个切片的第九片）；验收标准的自动核验（系统绝不自动宣布目标达成）；Workflow 的依赖图编排（串行管道能用，带依赖图和语义检查点的完整编排概念定义了、代码没跟上）；工具授权仍停留在执行底座内置粒度，靠子进程沙箱和权限扫描兜底；路由的基准信号依赖自维护测试集，覆盖有限。

规模数字（仓库实测）：773 个 commit（起于 2026-03-05 一个基于 tmux 的多模型协作原型），约 10.4 万行 Python 源码，约 12.1 万行测试、141 个测试文件。

技术亮点与工程判断

• 命名混乱不是审美问题，是会跑进生产路径的 bug。 早期一个 provider 字段身兼五职（账号、adapter 键名、执行底座、协议、模型系列），代价陆续到账：协议配置泄漏进 CLI 透传参数被当成命令行开关、故障转移把 A 家的模型名带给了根本没有这个模型的 B 家、一家中转的接入点长期挂在另一家云厂商的配置下。这些事故直接催生了四层执行词汇。
• 进程是负债，会话才是资产。 worker 池最初做成进程池（保持一池活进程随取随用），与”一个 AgentRun 一个子进程”的强隔离原则冲突——池化进程意味着状态泄漏风险。推翻重做成”session 池”：空闲时只保留会话 ID 和元数据、进程退出，唤醒时拉新进程恢复会话，缓存命中交给执行底座自己的机制。
• 影子模式 = 用生产流量做回归测试，但不用生产结果冒险。 任何要接管执行权的新机制，先影子后上岗——这个模式在系统里出现了两次（调度器、准入内核）。对一个没有 QA 团队的个人系统，这几乎是唯一负担得起的灰度手段。
• 测试行数超过源码，是理性选择不是洁癖。 这套系统的大部分代码由 agent 编写，agent 产出的方差远大于人。测试是唯一不依赖”作者自觉”的质量锚点：写代码的模型可以换、可以降级、可以幻觉，测试套件不陪它演——配合三分离纪律，这是”便宜模型干活、贵模型把关”成本结构成立的地基。
• 个人系统的架构预算要花在可恢复性上，不是吞吐上。 单进程 asyncio、SQLite、JSONL、系统服务托管，没有集群没有消息队列。个人系统的真实约束是没有值班表，挂了可能几小时后才被发现，所以钱全花在”断了能接上”：任务状态在盘上、会话可恢复、事件带完整追踪链、监视进程独立于主进程。另有一个 Rust 孵化区对核心纯逻辑模块（路由、故障转移、成本计算）做逐模块等价验证，方向是替换热路径，但今天不在生产路径上——这也是边界的一部分。

后续规划

• 任务看板（爟 · Beacon）的账本引擎迁入 Vyane，让 CLI、HTTP、MCP 三个入口吃同一套事实源
• API 与存储全面支持多用户上下文（owner-aware）
• 网关侧的用量与质量数据回流路由，把四信号里”真正随时间变强”的历史与反馈信号做厚
• 准入内核从影子比对转正；配额接管补上”审查通过后自动接回主力”的最后一片
• Rust 模块按等价验证结果逐个接替热路径

做了四个月，越来越确定这类系统的本质不是”AI 技术”，是工程组织：路由是招聘排班，协作模式是会议制度，配额接管是请假顶班加交接审查，三分离评审是质检独立于生产——人类组织演化上百年的制度正以代码形式被重新发明，而且因为 agent 行为可以被完整记录和回放，这些制度第一次变得可精确执行、可度量、可回归测试。