一个任务怎么跑通

你敲下一条 vyane dispatch,或者某个 agent 从 MCP 里调 vyane_dispatch,任务就被派了出去。中间发生了什么?这一页把这条数据流拆开讲清楚。

一句话记住:不管从哪个入口进来,后端是同一套。 CLI、MCP、HTTP 三个门,进门之后走的是同一条流水线,不分叉。

三个入口,一套后端

任务可以从三个门进来:

入口	长什么样	谁用
MCP	`vyane_dispatch` 工具调用(stdio 传输)	agent(Claude Code / Codex 等 runtime 里的 MCP 客户端)
CLI	`vyane dispatch <任务>`	人在终端里手敲,或脚本
HTTP	daemon 的 dashboard REST API(`POST /api/dispatch`,带 Bearer token)	远程客户端、其他服务

三个入口是三种不同的接入方式:MCP 走 stdio、CLI 是本地进程、HTTP 是 daemon 上的 REST 接口(认证、异步任务包装各有不同)。但核心执行链是共用的——参数规范化、四层解析、执行、记账,底层都收敛到同一套 dispatch 代码,不各写一遍。所以你在 CLI 上验证过的执行行为,换成 agent 从 MCP 调,结果一致。

共用一条执行接缝

记账、失败重试这些关键逻辑不会因为入口不同而漏掉。执行的最小接缝叫 run_base_adapter_turn,CLI、MCP、workflow 里的每一次模型调用都从这个接缝过,没有谁另起炉灶。

七步流水线

一次 dispatch 从进门到返回,依次经过七步。

入口(MCP / CLI / HTTP 三选一)
      │
  ①  参数规范化    加载配置 / profile,auto 时做智能路由
      │
  ②  四层解析      把一个 provider 便捷选择器展开成完整四层
      │
  ③  内核决策      当前 shadow 观测(见下方说明);enforce 为规划方向
      │
  ④  选 adapter    按 adapter_provider 找到对应的执行驱动
      │
  ⑤  执行          run_turn:真正调模型 / 跑 CLI 壳
      │
  ⑥  记账 + 会话    审计、历史、会话续写、额度事件
      │
  ⑦  统一返回      一份结构一致的结果 JSON

1. 参数规范化

先把入口递进来的参数理顺:加载配置(项目级 .vyane/ + 用户级 ~/.config/vyane/profiles.toml),如果指定了 profile 就把这个命名组合读出来。provider/model 这种写法(例如 your-provider/some-model)在这一步拆开。

如果 provider 填的是 auto,这一步会做智能路由——根据任务内容和当前可用 provider,自动挑一个合适的。挑完之后,后面几步就当成一个明确的 provider 来处理。

2. 四层解析(target_resolver)

你在 dispatch 里通常只填一个 --provider,但那只是个便捷选择器。真正执行需要完整的四层组合,这一步就是把选择器展开成四层:

层	解析出什么
provider	谁给 endpoint、key、额度、计费
protocol	wire 请求形态(代码字段叫 `chat_transport`)
harness	执行壳:CLI 壳(claude-code / codex-cli)还是直连 HTTP(direct-chat)
model	具体模型 ID;没填就取 provider 的默认模型

产物是一个规范化的执行目标,里面除了四层,还带上「用哪个账号资源」「这个 adapter 能不能跑这个 protocol」「能不能跑」这些判断。四层是什么、为什么要拆,见四层架构。

3. 内核决策(kernel)

Vyane 设计了一个 DispatchKernel——一个纯函数、无状态的决策层,目标是在任务真正发出去之前统一做三件事:

算有效策略 —— 把 agent 的权限上限(ceiling)、role 的模板、调用方的请求三者取交集。调用方只能收窄,不能放宽。
定路由 —— 在允许的 provider / 沙箱范围内确定最终执行目标。
准入 + 安全扫描 —— 对真实要发出去的那段 prompt 跑安全扫描,再叠加全局策略(allowlist / blocklist / 超时上限 / 频率限制)。

🚧 当前是 shadow 观测,还不是强制守门

内核有三档 VYANE_KERNEL_MODE:off(默认,不启)/ shadow(与实际执行并行跑一遍决策,只做对比和记录,不拦截)/ enforce(由内核真正准入、可拒绝)。

截至当前实现,内核跑在 off / shadow 档——它不驱动执行、也不会真的拦下一次 dispatch。 上面三件事描述的是内核的目标能力;enforce(真正的策略守门 + 不可绕过的拒绝)是已定方向、尚未启用的部分。读到"内核拒绝就派不出去"时,请理解为设计意图,不是当前行为。

4. 选 adapter

拿到确定的执行目标后,按 adapter_provider 找到对应的 adapter 类。adapter 是「不同 harness 的驱动」:claude-code、codex-cli、opencode 各有各的 adapter,直连 HTTP 的各类云端 provider 也各有 adapter。选中哪个,取决于这个目标要走哪个执行壳。

5. 执行(run_turn)

选好 adapter,就真正跑一轮——这一步叫 run_turn,是所有执行的公共接缝:

CLI 壳类(claude-code / codex-cli):起子进程,把 prompt、workdir、沙箱、超时喂进去,跑一轮拿回结果。
直连类(direct-chat):按 protocol 直接发 HTTP 请求给模型。

因为不管重试、失败切换还是 schema 校验重发,每一轮都从同一个 run_turn 接缝过,所以 provider / 沙箱 / 超时 / 用量记账在各种路径下都是一致的,不会某条分支漏记。

执行阶段还内建了兜底:

同 provider 重试 —— 报错或超时时按指数退避(2s、4s、8s…)重试,上限 5 次(带会话续接的调用不重试,避免污染上下文)。
失败切换(failover) —— 开了 --failover 且当前 provider 彻底失败时,换一个候选 provider 再试;额度耗尽会记一条 quota 事件,但不自动降级,把选择权留给人。

6. 记账 + 会话

一轮跑完(不管成没成),都要落账:

审计 —— 记一条 audit(provider、任务摘要、状态、耗时、调用方、模型、会话 ID…)。
历史 —— 完整结果写进 history,vyane history 能查回来。
会话续写 —— 如果带了 --session,把这次 dispatch 追加进那个逻辑会话,下次接着聊有上下文(注意:CLI 上是 --session,别写成 --vyane-session)。
额度事件 / 意图分类 —— 额度耗尽记事件、给结果打上意图分类标签,供分析用。

7. 统一返回

最后把所有东西打包成一份结构一致的结果返回:任务状态、输出、耗时、实际用的 provider / 模型 / harness、会话 ID、失败切换路径(如果发生过)、额度信息等等。

三个入口拿到的是同一种结构。CLI 打印成 JSON,MCP / HTTP 把这份 JSON 递回给调用方——同一份 schema,不因入口而变形。

一个心智锚点

把这条流水线想成一条流水线,三个入口是三个上料口,料一进传送带就走同一条线:规范化 → 展开四层 → 过安检(内核)→ 上机(adapter + run_turn)→ 记台账 → 出成品。你换哪个上料口,产线不变,成品规格也不变。这就是「三入口共用一套后端、不分叉」的全部含义。