实际问题
同时使用多个 AI CLI，需要解决的不只是选哪个模型，还包括谁能读取仓库、超时后怎样收尾，以及谁来验收结果。
我的贡献
- 主导路由、权限和验收边界相关的编排需求与取舍。
- 借助 AI 完成实现，再审查失败路径、回归证据与安装行为。
工作方式：产品主导，AI 辅助实现，逐步检查与迭代。
关键选择与取舍
01
明确声明路由，不猜测任务意图
- 选择
- 显式选择 worker、有序 profile 或 route，并按所需能力筛选候选者。
- 代价与取舍
- 配置需要多做一些判断，但选择某个 worker 的原因可以被检查。
- 如何检查
- 配置校验与确定性路由测试覆盖选择和拒绝路径。
02
登录继续由各 CLI 管理
- 选择
- 使用经过审查的适配器与原生登录，不在策略文件中保存凭据或可执行命令。
- 代价与取舍
- 接入新服务需要修改并审查适配器；配置本身不承担任意命令执行。
- 如何检查
- 安全契约与配置检查明确允许的配置范围。
03
把执行完成当作待审查的证据
- 选择
- 限制执行时长与输出，记录清理结果，并在写入 worker 启动后停止自动跨 worker 重试。
- 代价与取舍
- 发生部分写入时，需要先检查再交给下一位 worker；进程成功不代表工作已验收。
- 如何检查
- Windows 回归与安装生命周期测试在 PowerShell 5.1 和 7 中检查进程处理行为。
查看成果样例
动手了解项目
沿着任务边界，查看三个执行分支
根据公开 v0.3 约定和确定性测试制作的合成流程演示。这些是说明性状态，不是生产日志或实时 CLI 调用。
显式选择
workspace.read
明确的 repo-review 路由要求 workspace.read。先按能力筛选，保留 profile 中声明的顺序，再选出合格 worker。
传递与执行
子进程退出 · 0
有边界的任务经审查过的适配器传递。合成 worker 返回输出和退出码 0；这只表示传递与执行完成。
进程收尾与清理
本场景设为已确认
即使主进程成功结束，执行器仍会关闭其管理的进程树并清理自有临时文件。清理状态需要独立核查。
任务验收
仍需审阅
人或主代理仍须检查输出、文件、差异及任务验收项。worker 不能自行宣布最终验收通过。
真实清理失败会单独报告，不能触发回退。超时回退仅适用于显式启用的只读任务，且要求已确认终止并有剩余预算。写入 worker 一旦启动，就不会自动换另一个执行。 查看测试 ↗
这项工作说明了什么
v0.3.0 提供适配器文档、配置示例、安装与卸载路径，以及结构化结果契约。公开 CI 记录显示Windows PowerShell 5.1 与 PowerShell 7 测试任务均成功完成。
查看原始依据
当前边界
- 支持的执行环境是 Windows；它不是跨平台服务，也不是恶意本地程序的沙箱。
- 服务商二进制和原生配置仍属于可信依赖。v0.3 的 MiniMax 适配器没有经过审查的仓库读写能力。