Skip to main content
Glama
songzhifei512

multi-agent-bridge

workflow_evolve

Evolve a workflow by forking, appending, inserting, degrading, rolling back, or branching its DAG, with automatic guardrails, audit, and independent review enforcement.

Instructions

【自适应重规划引擎】总入口:封装六个 DAG 演进动作(fork 备选 agent / append 后置追加 / insert 前置插入 / degrade 降级验收 / rollback 阶段回退 / branch 条件分支),并【服务端强制】演进护栏——演进计数 ≤3(超限拒)、演进 ≥2 次强制独立审闸(未过审 gate_required 拒执行)、不破坏已完成段(rollback 是显式豁免:授权推翻已完成段)、留痕统一记进 workflow 元数据。调用方只要给 action+目标任务+理由,护栏/计数/留痕/面板标记引擎代管,不必手动拼 task_fork/task_depend/task_create。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scoreNodegrade 实际质量分(<threshold 但在带宽内)
actionYes演进动作:fork=连续失败换备选 agent;append=评审产出新需求追加实现段;insert=发现遗漏前置决策反向插入前置;degrade=质量分<th 但接近时降级验收放行;rollback=已完成段打回重做并失效其后所有下游段(显式推翻已完成段);branch=决策点产出后分支出条件子路径(不删已有已完成段,锚点 superseded 到分支路径)
reasonYes演进理由(必填,进留痕/审计)
fork_toNofork 备选 agent 名(如 opencode/dsh/qwen)
task_idNo锚点任务 id(fork/insert/rollback/branch 的目标;append 的完成后承接段;degrade 的评审任务)
branch_toNobranch 分支任务 id(可选,决策方已建好分支段则连它;缺省引擎自建 pending 分支承接锚点
thresholdNodegrade 验收阈值
auto_reviewNo演进独立权审·引擎自动落:true 时审闸命中(演进≥2 且无 manual 背书/无 gate_bypass)由引擎自动派 qwen 独立视角背书(复用 run_verify qwen judge)——通过自动执行、驳回停止当前演进路线交人工、qwen 未决退回手动。默认 false=保持手动派审(SKILL 派 qwen)路径,不隐含 token 成本
gate_bypassNo跳过独立审闸直接执行(仅队长人工放行时置 true)
workflow_idYes目标工作流 id(task.workflow.id,多段共享同一演进计数/留痕)
append_titleNoappend 新段标题
branch_conditionNobranch 条件:决策点判据描述(如 '验收未达标 → 转人工复审路径'),进留痕;true 时由决策方据产出判定走哪条
prepend_task_descNoinsert 前置段描述(插在锚点任务依赖链最前)
independent_reviewNo独立审背书凭据:当演进累计≥2 时必传(如 'qwen:已独立审通过' 或人工放行标记),否则返回 gate_required

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.3/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden and does so well. It discloses the evolution-count cap of 3, mandatory independent review after 2 evolutions, gate_required rejection, the completed-segment preservation rule with rollback as an explicit exemption, and unified metadata tracing. This is unusually transparent for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is information-dense and front-loaded with the tool's identity and scope, but it is a single long compressed paragraph that mixes action enumeration, guardrail policy, and usage guidance. It earns its content, but scannability suffers from the lack of structural separation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with six actions, 14 parameters, no annotations, and no output schema, the description covers the core invocation contract, safety guardrails, audit side-effects, and gate behavior. Minor missing details like exact return shape are acceptable given no output schema, and the overall picture is complete enough for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3 even without additional parameter detail in the description. The description adds the high-level insight that only action+workflow_id+reason are required and the engine manages the rest, but it does not individually explain parameters beyond what the schema already provides. This is adequate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as the '总入口' adaptive re-planning engine and enumerates six concrete DAG evolution actions (fork/append/insert/degrade/rollback/branch). It frames the tool as a managed aggregate, explicitly distinguishing it from lower-level siblings like task_fork/task_depend/task_create.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states the usage contract: callers only need to provide action + target task + reason, and guardrails/counting/tracing are engine-managed. It also says users need not manually compose task_fork/task_depend/task_create, giving a clear when-to-use directive. It does not enumerate exclusion conditions for all alternatives, but the guidance is sufficiently clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.