用SignalBox串联多款编程智能体

Codex 写实现、Claude 拆方案、Copilot 参与检查，工具可以轮换，流程却常常只存在于人的脑子里。SignalBox 想把这套操作写进 YAML：谁先做、谁接手、哪里等人审核、失败后从哪继续，都交给本地程序调度。

它的吸引力不在于让几个模型一起聊天，而在于把反复复制提示词的劳动变成可复用流程。不过，原文展示的是功能和设计，没有证明多模型协作一定更快、更省钱。对程序员来说，恢复机制和权限边界，比接入多少模型更值得看。

把工作交给多个模型，先把交接规则写清楚

SignalBox 是一个内嵌 Web UI 的 Go 单文件程序，可以调用 Codex、Claude、Copilot，以及兼容 OpenAI API 的运行时。各家 agent CLI 和脚本解释器仍需单独安装，它负责把这些工具串起来。

运行时在 signalbox.yaml 中命名，流水线里的 agent 按名称引用。原文最简单的例子是：Claude 生成计划，人工批准，再由 Codex 实现。handoff 指定下一站；没有 handoff 的节点结束当前链路，其输出成为执行结果。

人工审批通过时，输入内容原样向下传。拒绝时，规划节点会带着审核意见重跑，避免反馈散落在另一个聊天窗口里。

下面这组命令解决的是先体验流程的问题，默认 mock runtime 不需要 AI 凭据，但需要 Go 1.25 或更新版本：

go install github.com/kaladinstorm84/SignalBox/cmd/signalbox@latest

signalbox init my-project     # creates signalbox.yaml + pipelines/default.yaml
cd my-project
signalbox validate            # checks config and every pipeline
signalbox serve               # web UI on http://127.0.0.1:8484
signalbox run default --input "Hello SignalBox"   # or run in the terminal

注意 signalbox validate 这一行：它会检查配置和所有流水线，但通过校验不代表生成代码正确。终端执行会询问审批；传入 --yes 则自动批准所有关卡，适合已经确认可以无人值守的脚本或 CI。

初始化项目还会生成 AGENTS.md，帮助编程 agent 起草流水线。校验器能发现未知交接目标、普通交接环路、不可达节点、缺失运行时或脚本，以及无效的代码退出映射。这个设计比较实用：模型写配置，确定性的程序检查结构。

节点也不必都是模型。code 节点从 stdin 接收输入，将 stdout 交给下游，因此 Python、PowerShell 等本地检查可以插在两个 agent 之间。

审核能退回，才算真正描述了工作流程

只有顺序执行还不够。实际开发里，计划会被驳回，实现会漏要求，审核意见必须能影响下一轮。

SignalBox 的 approval 和 gate 节点支持按决定路由，并用模板组装下一站输入。模板只支持 {{ input }}、{{ output }}、{{ comment }}，做纯文本替换，不提供表达式语言。能力有限，但交接内容更容易看懂。

模型也可以充当审核者。下面的配置让 Codex 检查事实准确性和完整性，拒绝后退回 writer：

- id: quality_review
  type: llm_gate
  runtime: codex
  prompt: Check factual accuracy and completeness.
  max_reworks: 2
  reject-to: writer
  handoff: [publish]

要看的是 max_reworks: 2：返工超过上限就报错结束，避免无限循环。格式不合法的审核结论也会失败，不会被当成批准。界面会区分模型裁决和人工审批。

模型审核通过，只能说明通过了这一轮模型检查。

原文建议把 llm_gate 放在人工关卡之前，先过滤一轮再占用人的注意力。这个安排有道理，但作者没有提供漏检率或人工节省时间的对照数据。

复杂流程还有几种组合方式：orchestrator 按阶段执行，各阶段内部并行派发任务、收集结果，也可用提示词汇总；多个节点交给同一节点时，后者等待全部输入后执行一次。pipeline 节点可以启动关联的子流水线，子流程中的待审批项会出现在父执行页面。

session 则是共享讨论记录的多轮会话。原文配置由 architect、security_reviewer、delivery_lead 按 round_robin 发言，设置 max_rounds: 4，通过 vote 和 majority 判断共识，再分别走 on_consensus 或 on_no_consensus。它能组织讨论，但多数票是否代表方案可靠，仍需另外判断。

第四步失败后，能不能保住前三步

对于耗时的 agent 链路，失败恢复往往比并行更有价值。

运行时可设置 retry.count: 2、backoff: 500ms，按固定间隔重试。次数耗尽后，调用进入 waiting_retry，等待点击 Retry；其他并行分支继续运行，失败节点下游则等待重试或取消。

执行结束后，还可以用 signalbox restart --node coordinator --stage verify 从指定位置重启。它创建新执行，保留原记录，把不在重启点下游的已完成工作复制过来并标记为 reused。

复用已有输出，可以避免为了一个失败节点重跑整条链路。

每次执行会保存解析后的流水线指纹。定义发生变化时，默认拒绝重启并列出变化；--force 允许使用当前定义继续。但原文明确承认，code 步骤引用的脚本文件变化不会被检测到，因此指纹不能覆盖所有执行条件。

历史保存在 .signalbox/executions.db。程序重启后，进行中的执行会标记为 interrupted，提供「Retry from here」。

自动触发由 watcher 完成：定期运行命令，输出变化时，把输出作为输入启动指定流水线。原文每 5m 执行一次 Jira 查询，参数为 args: [issues, list, --jql, "project = OPS AND status = 'To Do'", --output, json]。这依赖本地 Jira 命令可用，不能据此理解成内置了完整 Jira 集成。

参数则通过 params 声明，用 ${{ params.topic }} 引用，让同一流水线服务不同输入。

我的判断

SignalBox 抓住了一个真实问题：模型调用可以随时换，交接、退回和恢复却需要稳定规则。对于已经反复手动串联 agent CLI 的个人开发者，这比继续积累提示词更有用。它还采用 MIT 许可，适合先用 mock 示例验证流程。

但原文没有展示作者团队的生产数据，也没有对比单个 agent、Shell 脚本或其他编排工具。多模型是否改善质量、并行是否缩短总耗时，都还是待验证的问题。简单任务用脚本串命令可能更直接；只有反复遇到审批、返工、分支和恢复，额外的 YAML 才更容易值回维护成本。

复用方面，registry 是保存版本化流水线包的目录，常见位置是文件共享。发布会打包 imports 和脚本，为每个文件记录 SHA-256；安装先验哈希，再在暂存副本中结合项目运行时校验，记录到 signalbox.lock.json。命令是 signalbox registry publish release-notes --version 1.1.0 和 signalbox registry install release-notes@latest。哈希能检查文件一致性，不能证明脚本可信。

权限边界尤其需要看清。工具授权分项目和 agent 两层，SignalBox 不启动 MCP server，只把获准配置传给 CLI；密钥通过 env_from 指定环境变量，在调用时读取。可 Codex、Copilot 仍会加载用户全局 MCP server，Claude 则被要求忽略它们，因此不能把局部授权理解为完整隔离。

它是本地单用户工具，服务没有认证，默认绑定 loopback；代码步骤和 MCP server 使用当前用户权限，没有沙箱。它也没有集成目录、多用户认证或托管服务。用来编排自己信任的本地工具很合适，直接当团队共享自动化平台，原文给出的能力还不够。

能拿来做什么

• 先用 mock runtime 跑通「规划、人工审批、实现」，检查交接内容是否完整，再接入真实 CLI，避免边付费边调流程结构。
• 给前端或 Node 项目的重复任务配置 code 检查节点，执行项目已有的测试或校验命令；模型审核负责补充检查，人工关卡负责确认关键决定。
• 对耗时流程主动演练一次失败恢复，确认哪些输出被复用，并单独检查脚本是否改动，别只依赖流水线指纹。
• 只有在手动串联已经反复发生时，再引入 session、并行阶段和 watcher，并用实际耗时、调用成本与返工次数判断是否值得保留。