Parallelism | Francis Du

wcode v0.6.1：`parallel_tools` 不再按层等

Sat, 12 Sep 2026 05:31:00 +0800

v0.6 开始在 agent_context 里标出可以并行的工作。接着我去看 Runtime 本身，发现 parallel_tools 虽然已经有依赖图，执行时还保留着按层推进的做法。

例如：

A ─→ C

B ─────────→ D

假设 A 100ms 完成，B 要 5s，C 只依赖 A。

按“层”执行时，很容易变成：

第一层：A + B
        ↓ 等两者都结束
第二层：C + D

C 明明在 100ms 时已经 Ready，却因为一个和自己无关的 B，被迫多等几秒。

所以 v0.6.1 我把调度器改成了 completion-driven。

Ready 的任务不应该等同层慢分支#

现在 Scheduler 只看一个问题：

这个任务自己的前置依赖是不是已经完成？

满足就进入 Ready Queue。

实际任务图通常不整齐。一个慢测试、一个大文件读取、一个外部命令，不该顺手把无关分支也拖住。

失败也只应该污染依赖它的分支#

同样的原则也用在失败上。

如果：

A → C
B → D

A 失败，那么 C 应该被 Skip，因为它的前置不成立；但 B 和 D 不应该跟着一起失败。

所以运行时会区分依赖失败导致的 Skip、当前任务自己的运行失败，以及完全独立、仍然可以继续的分支。

这对批量读取、搜索、验证尤其重要。Agent 不应该因为一个不存在的可选文件，就失去其他已经能确定的结果。

Partial 不能假装 Complete#

这轮我把批处理结果的语义也重新收紧了。

批量读、创建、编辑、移动会明确报告：

complete
partial
failed

并保留逐项结果。

如果一个批次只完成了一部分，MCP Result 会保守地带错误标记，依赖整个批次的后续任务不能把它当作完整输入。独立分支仍然继续。

重试也不应该重放整个批次。先核对状态，只重试失败项。这对写操作尤其重要，因为“请求失败”不等于“所有副作用都没发生”。

并行写入最怕错误合并#

为了减少 Tool Call，wcode 会在安全条件满足时合并部分文件编辑。

这里我宁愿少合并一点。

同一个文件、同一个 SHA 的 Edit，如果中间隔着一个依赖 Read、Move 或其他会改变语义的操作，就不能跨过去合并。否则 Scheduler 会把原本有先后关系的工作偷偷变成一个事务。

合并前也会检查既有的 128 项编辑上限，不能因为优化路径就绕过原来的安全边界。

如果一次优化改掉了原本的先后关系，那就已经不是调度优化了。

Cancel 也必须真的往下传#

异步系统里还有一个很烦的问题：外层任务取消了，不代表里面已经排队的工作自动消失。

如果父请求断开，而子任务还在队列里，最糟的情况是用户以为“已经取消”，几秒后某个写操作才突然开始。

v0.6.1 把取消传播继续往下压：父任务取消会取消仍在排队的子任务；持久 MCP Task 被取消或 TTL 过期，也会取消它拥有的执行任务。

已经开始的阻塞文件操作不会假装回滚。这条边界也要说清楚。

并发许可要跟真实工作走#

以前还有一种容易让面板数据看起来比实际更漂亮的情况：外层 Future 被取消以后，如果并发许可提前释放，但底层阻塞工作其实还在跑，就会出现“系统看起来有空位，实际上旧工作没结束”。

现在已经启动的阻塞工作会继续持有对应许可，直到结束或异常退出。排队工作取消则会释放预留。

我更愿意让数字难看一点，也不想让 Scheduler 对自己的真实资源状态撒谎。

Context 也继续往目标优先收紧#

顺手还改了一轮 agent_context 的候选排序：精确定义优先于相似辅助函数；直接目标文件优先于按字母排在前面的 Design 映射；并行建议开始结合当前 Scope、活动 Worklist Lane 和运行时并发上限，而不是固定最多四路。

Lane 数只用来给 Agent 提示，并不能证明两件事真的独立。最后仍然由真实资源和依赖决定能不能一起跑。

Observatory 不再把“有映射”当“已验证”#

Project Observatory 这轮还修了一个我很在意的表达问题。

以前“某个 Requirement 有 Verification 映射”和“这个 Revision 上真的执行并通过了验证”在视觉上太容易靠近。

现在会明确区分：

verification mapped
executed
passed
fresh proof

因为有测试文件，不等于测试跑过；测试跑过，也不等于它属于现在这份代码。

这版主要把无意义等待拿掉#

v0.6.1 基本都在修执行语义：Ready 就进队列，失败只截断依赖分支，Partial 明确报告 Partial，Cancel 继续往子任务传，许可跟着真实工作释放。

它不会把本来串行的任务凭空变快，但长任务里少掉几次无关等待，体感很明显。

再往后到 v0.6.2，我又继续拆了一个误区：外层 SLOTS 很高，不代表真实吞吐就高。

wcode v0.6：哪些工具调用可以一起跑

Sat, 12 Sep 2026 05:30:00 +0800

v0.5 做完 Warm LSP Runtime 以后，我原本打算继续补 Semantic。

实际拿 wcode 连续写了几轮代码，先暴露出来的却是执行节奏：模型已经知道几件事互不依赖，还是经常按顺序一个个调用工具。

例如一个普通修改，前面经常同时存在几条工作：

读目标文件
查相关测试
看项目约束
确认调用方
检查工作树

这些动作很多没有依赖关系。如果 Prompt 只写一句“可以并行”，模型仍然很容易串着做。

v0.6 就从这里开始改。我想让 Harness 少给模型一层猜测：当前任务有哪些入口，哪些可以一起做，哪些必须等前一步完成。

`agent_context` 不再只是一包上下文#

最早的 agent_context 主要解决 Context 成本。

它把 Design State、Repo Map、目标源码、SHA、验证入口和项目约束压进一个有界包里，让模型不用每次从根目录重新理解一遍。

到了 v0.6，我给这份 Context 又加了一层执行信息：

你现在应该做什么？
哪些动作可以一起做？
哪些动作有真实依赖？
哪些文件已经是可编辑目标？
哪些 Semantic Provider 已经可用？
这次修改应该控制在多大范围？

所以 Context 里开始明确带 Minimal-change Strategy、Complexity Budget、Active Worklist、Hot Source、Semantic Provider Readiness、绑定当前 Revision 的文件 SHA、候选 Dependency Lane，以及推荐并发数和立即并行的执行指引。

现在这份 Context 除了描述仓库，也会把这次任务已经确定的执行入口一起带出来。

Parallel-first 不等于“把槽位占满”#

并行最容易做成一个漂亮但没什么用的数字。多发几个 Tool Call 很简单，麻烦的是先确认它们之间到底有没有依赖：

独立 Discovery     ─┐
独立 Read          ─┼─→ 同时开始
独立 Review        ─┤
独立 Check         ─┘

需要前置结果的 Edit ───→ 等依赖满足再开始
同一文件冲突写入     ───→ 串行
授权后才能执行的命令 ───→ 等批准

v0.6 的规则很直接：先看依赖，再决定哪些调用一起发。

v0.6 的 Skill 和 Agent 工作流也开始明确要求：Host 支持并行调用时，应该尽早把独立的 Discovery、Read、Review、Check，以及不重叠 Edit 发出去。

我不想让模型自己猜仓库结构#

以前 Agent 虽然拿到了很多能力，但仍然可能自己脑补：

这个项目大概是 Rust + Web？
这个目录看起来可能是 UI？
这里应该跑 cargo test？
那个 Language Server 应该已经能用了？

这种猜测单次看没什么，长任务里会不断累积。

所以 Task-ready Context 会更主动地把已经确定的东西摆出来。目标文件是谁，就把目标文件和 SHA 放前面；当前 Scope 是什么，就把相关源码和 Worklist Lane 放前面；Semantic Provider 还没准备好，就明确说没准备好。

我在 Software Graph 那篇里写过一次：Tree-sitter、LSP、Runtime 是不同精度的事实。

执行层也照这个规则。Provider 没准备好就明确标出来，不用一个模糊状态让模型自己猜。

LSP 也开始按真实安全边界工作#

v0.5 把 LSP 做成了 Warm Semantic Runtime。

v0.6 又补了一层：Server Discovery、Binary Identity、Bounded Warm Session、Source Revision Sync 和 Safety Profile。

Language Server 不是纯文本查询器。它可能读取项目配置、调用构建系统、加载插件，甚至间接触发仓库里的代码。

所以“机器上装了 rust-analyzer”不等于“Agent 可以无条件启动 rust-analyzer”。如果某个 Server 没有明确的 Automatic Safety Profile，wcode 会 Fail Closed，然后进入精确授权流程。

命令授权从“允许/禁止”变成精确指纹#

v0.6 还有一块变化，我自己用起来很明显：本地探查命令少打断了，但真正可能执行仓库代码或者产生副作用的命令，也不再只有“永久拒绝”这一条路。

只要没有撞上硬安全边界，就可以生成一次精确的 RiskyExecution 请求。

批准绑定的是：

Workspace
Program
Arguments
Working Directory

我批准一次 cargo test --locked，不代表顺便批准 cargo publish，更不代表给 Agent 无限 Full Access。

Shell、Workspace Escape、Protected Path、凭据或配置重定向、Host-wide Tool Mutation、Package Publication / Ownership，以及明显破坏性的基础设施操作，仍然是硬边界。

我最后留下了一段很实用的中间地带：动作本身允许，但这一次要执行的 Workspace、Program、Arguments 和 Working Directory 必须让我看清楚再批。

这版主要在收执行摩擦#

parallel、context、LSP、authorization 这些改动看起来分散，实际都来自我自己使用时反复碰到的几类浪费：模型重复确认已经知道的事实、明明可以并行却串着查、语义服务状态不清楚、命令到了最后一步才发现权限不够。

v0.6 做的就是把这些信息提前放进 Runtime 能确定的位置，尽量少让模型靠 Prompt 猜。

我也不会给 v0.6 编一个“通用提速百分比”。真实收益取决于任务图、仓库、Host 是否支持并行调用，以及 Semantic Session 是否已经热起来。

后面的 v0.6.1，我又继续把 parallel_tools 调度器改了一轮。那次处理的是另一个更底层的问题：并行任务不应该因为同一层里有一个慢分支，就集体等它。