diff --git a/pipeline_core/__init__.py b/pipeline_core/__init__.py index 3e5607a..8da67b8 100644 --- a/pipeline_core/__init__.py +++ b/pipeline_core/__init__.py @@ -21,6 +21,7 @@ from .agent_config import ( from .ability import ( PipelineAbility, RoleSpec, + FlowStage, register_ability, get_ability, list_abilities, @@ -30,6 +31,8 @@ from .ability import ( normalize_role, get_next_role, list_roles, + get_flow_stages, + flow_stage_to_dict, ) from .slash import ( SlashCommand, diff --git a/pipeline_core/ability.py b/pipeline_core/ability.py index 173d3ff..1a74204 100644 --- a/pipeline_core/ability.py +++ b/pipeline_core/ability.py @@ -36,6 +36,28 @@ class RoleSpec: tools: List[str] = field(default_factory=list) # 工具白名单（空 = 产线全部工具） +@dataclass +class FlowStage: + """产线预制流程的一个阶段（可裁剪声明）。 + + trim 三级（裁剪合法性由 flow_plan_capability 代码硬校验，不靠 LLM 自觉）： + - "no" 不可裁：裁掉流程不成立（如投标的章节编写/合成），propose 直接拒绝； + - "warn" 可裁但需警告：质量门禁类（如 QC 审核/章节评审），裁剪时把 warn_note + 写进确认待办，用户确认才生效（双确认语义）； + - "yes" 自由裁剪。 + roles：执行该阶段的产线角色（规范名 agent.xxx），用于计划确认后收敛清理 + 被裁阶段的在办任务，以及 next_role 线性链的跳段判定。 + deps：上游阶段 key 列表（静态依赖不变量）：保留的阶段依赖被裁阶段 → propose 拒绝。 + """ + key: str # "analysis_scoring" + label: str = "" # 展示名「评分项解析」 + description: str = "" # 阶段作用（展示给用户） + trim: str = "no" # no / warn / yes + warn_note: str = "" # trim=warn 时的风险提示文案 + roles: List[str] = field(default_factory=list) + deps: List[str] = field(default_factory=list) + + @dataclass class PipelineAbility: """产线能力包：一个产线 = 一组工具 + 一段 prompt + 一组 handler + 一组角色。 @@ -52,6 +74,7 @@ class PipelineAbility: handlers: Dict[str, Callable] = field(default_factory=dict) # {tool_name: handler} roles: List[RoleSpec] = field(default_factory=list) # 产线角色集 menus: List[Dict] = field(default_factory=list) # 产线功能菜单（AgentIO 上方）[{"label","icon","url","type"}] + flow_stages: List[FlowStage] = field(default_factory=list) # 预制流程阶段（空 = 该产线未声明可裁剪流程） # ── 全局注册表 ── @@ -130,3 +153,24 @@ def get_ability_menus(pipeline_id: str) -> List[Dict]: """取某产线的功能菜单（AgentIO 上方，菜单/卡片/按钮）。""" a = get_ability(pipeline_id) return a.menus if a else [] + + +# ── 预制流程阶段查询（流程裁剪机制，flow_plan_capability 消费） ── + +def get_flow_stages(pipeline_id: str) -> List[FlowStage]: + """取某产线声明的预制流程阶段（空列表 = 未声明可裁剪流程）。""" + a = get_ability(pipeline_id) + return a.flow_stages if a else [] + + +def flow_stage_to_dict(st: FlowStage) -> Dict: + """FlowStage → dict（展示/落库用）。""" + return { + "key": st.key, + "label": st.label or st.key, + "description": st.description or "", + "trim": st.trim or "no", + "warn_note": st.warn_note or "", + "roles": list(st.roles or []), + "deps": list(st.deps or []), + } diff --git a/skills_library/all/flow-plan/SKILL.md b/skills_library/all/flow-plan/SKILL.md new file mode 100644 index 0000000..858e3a6 --- /dev/null +++ b/skills_library/all/flow-plan/SKILL.md @@ -0,0 +1,70 @@ +--- +name: flow-plan +description: 产线流程裁剪与 PM 任务拆解的通用概念规范——预制流程阶段、裁剪合法性、确认门禁、复杂度判断与子任务编排。任何产线的会话 agent 裁剪流程、PM 拆解复杂任务时先读它。触发：流程裁剪/简化流程/跳过阶段/任务拆解/子任务编排。 +capability: flow_plan_capability +tools: [create_sub_tasks] +--- + +# 流程裁剪与任务拆解（通用概念规范） + +## 一、概念 + +- **预制流程** = 产线声明的阶段链（能力包 flow_stages：key/label/描述/可裁性/角色/依赖）。 +- **流程裁剪计划** = 项目级的一次性决定：哪些阶段保留、哪些裁掉。存 pipeline_flow_plans， + 状态机 draft → pending_confirm → confirmed / rejected（驳回可修订重提，version+1）。 +- **裁剪只在项目启动阶段有效**：已有角色任务产出结果（approved/completed）后拒绝裁剪； + 确认后不可改（要改流程 = 新建项目）。 + +## 二、可裁性三级（代码硬校验，不是 LLM 自觉） + +| trim | 语义 | propose 行为 | +|---|---|---| +| no | 流程必需（裁了流程不成立） | 直接拒绝并说明原因 | +| warn | 质量门禁类（可裁但有风险） | 允许，风险提示写进确认待办（用户双确认） | +| yes | 自由裁剪 | 允许 | + +依赖不变量：保留阶段的 deps 不得落在被裁阶段（如裁「章节骨架解析」则「章节编写」不成立）， +propose 时代码校验拒绝。**任何校验失败都要把原因如实转告用户，不得绕过或伪造成功。** + +## 三、确认门禁（人拍板点） + +- 提案后系统发「流程裁剪确认」待办（flow_plan_confirm），**只有用户能确认/驳回**—— + agent 没有确认工具，禁止声称「已确认」「已生效」。 +- 待确认（pending_confirm）期间流转机制全局阻塞（不派发）； +- **驳回（rejected）期间同样阻塞**：会话 agent 应主动 get_flow_plan 读驳回意见， + 按意见修订 trim_keys 重新 propose（不要等用户催）； +- 确认后机制收敛：不再派发被裁阶段；「仅属于被裁阶段」角色的在办任务被取消 + （跨阶段共用角色不受影响）。 + +## 四、会话 agent 工具 + +- show_flow_template：列预制流程阶段与可裁性（裁剪前必用，别凭记忆猜 key）。 +- propose_flow_plan(trim_keys, user_requirements, propose_note)：生成草案+发确认待办。 + user_requirements 必须写用户要求原文（进确认待办给用户看）。 +- get_flow_plan：查计划状态与驳回意见。 + +## 五、PM 复杂度拆解（create_sub_tasks） + +PM 推进流程时对派发的任务做**复杂度判断**，复杂任务拆为子任务组挂进主流程： + +判断标准（满足其一即算复杂，倾向拆解）： +1. 任务描述含 ≥3 个可独立交付的工作面（如「解析六类评估项」「编写含多子系统的方案章」）； +2. 输入文档规模大（招标文件/需求书 > 50 页或 > 10 万字），单次执行易超时/漏项； +3. 产出需要多种角色协作（如同一章需要技术+商务素材）； +4. 历史同类任务 retry/revise 次数 ≥2（说明颗粒度过大）。 + +拆解规则： +- 每个子任务 {title, role, description, key?, depends_on?, dep_policy?}： + title 具体到工作面；role 必须是本产线角色（list_roles 查）；description 写到操作层； +- 依赖编排：无依赖并行（不填 depends_on）；有先后用 key 互引 + depends_on； + dep_policy 可选 {mode: all|any|at_least, n}； +- 子任务 parent_id 自动挂当前任务 → 任务树分层展示，编排子流程自动进项目主流程视图； +- 机制门禁：依赖解析失败的任务置 waiting 冒泡（不会静默降级为并行）；同标题活跃任务 + 自动取消（重做保护）；产线门禁风格（skip_generic_qc）自动继承； +- **拆完即交付本任务**：派发子任务本身就是编排交付物，不要长等子任务完成； + 子任务全部终结后由流转机制/验收环节闭环。 + +反模式（禁止）： +- 不判断复杂度就把所有任务一律拆碎（管理开销大于收益）； +- 拆解绕过流程裁剪计划（被裁阶段的子任务同样不得派发）； +- 用 create_sub_tasks 派其他产线的角色名（守卫会拒绝）。 diff --git a/skills_library/pipelines/bidding_general/common/bid-orchestration/SKILL.md b/skills_library/pipelines/bidding_general/common/bid-orchestration/SKILL.md index 8b774a1..b5e4ad6 100644 --- a/skills_library/pipelines/bidding_general/common/bid-orchestration/SKILL.md +++ b/skills_library/pipelines/bidding_general/common/bid-orchestration/SKILL.md @@ -22,10 +22,16 @@ tools: [analysis_progress, dispatch_analysis_dim] ## 编排动作（每次编排任务） 1. `analysis_progress` 看各维度进度与门禁状态（就绪/阻塞缺什么）。 + **2026-09-11 流程裁剪**：被用户裁剪的维度会标注「已被用户裁剪（不得派发）」—— + 跳过它们，不计掉链、不重试；只编排保留维度。 2. 对每个「就绪且待派发」的维度调 `dispatch_analysis_dim`： - 上游 QC 未全过的维度会被工具拒绝，不重试、不绕过，等上游； + - 被裁维度会被工具拒绝（裁剪计划是用户确认过的决定，不得绕过）； - 已过的上游自动注入任务参数，分析员会先读上游产出再抽取。 3. 派发完当前就绪的维度后完成任务——**不长等**，对账器下轮会再派新编排任务。 +4. **复杂度拆解（2026-09-11）**：某维度工作面过大（如异常招标文档多包件、 + 需分段交叉核对）时，可用 `create_sub_tasks` 把该维度拆成子任务组 + （parent_id 挂编排任务，depends_on 编排先后），拆解标准见技能 `flow-plan` 第五节。 ## 编排意图（归你，代码不管的部分） - **指令补充**（dispatch 的 instructions 参数）：异常招标文档的特殊交代 diff --git a/skills_library/pipelines/bidding_general/common/bid-workflow/SKILL.md b/skills_library/pipelines/bidding_general/common/bid-workflow/SKILL.md index 62a2127..f0b2c08 100644 --- a/skills_library/pipelines/bidding_general/common/bid-workflow/SKILL.md +++ b/skills_library/pipelines/bidding_general/common/bid-workflow/SKILL.md @@ -38,6 +38,31 @@ PM 编排掉链保护：编排任务重派超 3 次仍有维度缺失 → 冒泡 - 角色 agent 只做自己那一件事：写完章节就提交、评审完就打分落库，不管下一步。 - 对账器是角色任务的唯一自动创建者，也是阻塞门禁的守门人。 +## 流程裁剪（2026-09-11 起，通用机制 pipeline_flow_plans） +投标预制流程 11 个阶段（bid_ability.BID_FLOW_STAGES 声明）可由会话 agent 按用户要求裁剪： +- **裁剪时机**：项目启动阶段（已有角色任务 approved/completed 后拒绝）；确认后不可改。 +- **可裁性**：不可裁 = analysis_scoring/analysis_reqs_outline/chapter_write/compose； + 可裁需警告（质量门禁）= qc_analysis/chapter_review/analysis_quals； + 自由裁 = analysis_cost_benefit/prep/whole_score/delivery_confirm。 +- **确认门禁**：propose 后发 flow_plan_confirm 待办（全局阻塞门禁），只有用户能确认/驳回； + agent 无确认工具。驳回 → 对账器继续暂停，会话 agent 读驳回意见修订重提（version+1）。 +- **确认后语义**（对账器按 plan_stage_enabled 逐段门禁）： + - 被裁分析维度不派发、不计缺失；PM 编排 dispatch_analysis_dim 对被裁维度直接拒绝； + - qc_analysis 被裁 → 章节依赖矩阵（CH_SECTION_DEPS）的 QC 通过判定全部视为通过； + - 被裁维度对应的 QC 类型同样视为通过（不会再有产出与审核）； + - prep 被裁 → 商务章不等资料准备； + - chapter_review 被裁 → written 章节直接置 approved（不派评审）； + - whole_score 被裁 → 合成后标书直接置 passed（不派评分）； + - delivery_confirm 被裁 → passed 标书直接置 delivered + 项目 completed； + - 「仅属于被裁阶段」角色的在办任务在确认时收敛取消（tender_analyst 跨 4 个解析阶段共用， + 只裁其中一段不受影响）。 +- 无计划（存量项目/用户没裁）= 标准全流程，行为与裁剪机制上线前完全一致。 + +## PM 复杂度拆解（2026-09-11 起） +PM 推进时按技能 `flow-plan` 第五节判断任务复杂度，复杂任务用 create_sub_tasks +拆子任务组（parent_id 挂主流程任务、depends_on 编排串并行、waiting 计入在办防重复派发）。 +拆解不得绕过裁剪计划。 + ## 红线：分析问题 ≠ 执行指令（2026-09-03 用户纠正，实测违反过） 用户问「还差什么没完成」「如果允许重做会重做哪些工作」这类**分析/假设性问题**时： - 只输出分析结论（缺什么、重做范围、影响面），**禁止创建任何任务、禁止改任何数据**； diff --git a/skills_library/pipelines/bidding_general/roles/agent.pm/role/SKILL.md b/skills_library/pipelines/bidding_general/roles/agent.pm/role/SKILL.md index 31584d6..3d108ec 100644 --- a/skills_library/pipelines/bidding_general/roles/agent.pm/role/SKILL.md +++ b/skills_library/pipelines/bidding_general/roles/agent.pm/role/SKILL.md @@ -1,8 +1,8 @@ --- name: role -description: 投标项目经理：解析编排（按任务链派发分析维度）；验收各角色任务交付件；编写阶段前从样板标书抽取编写规范（章节结构/篇幅口径/商务要素）供写者与评审参照。 -capability: task_capability, bid_spec_capability, bid_orchestration_capability -tools: [extract_writing_spec, add_kb_doc, list_kb_docs, kb_doc_detail, search_bid_kb, analysis_progress, dispatch_analysis_dim] +description: 投标项目经理：解析编排（按任务链派发分析维度）；任务复杂度判断与拆解（create_sub_tasks）；验收各角色任务交付件；编写阶段前从样板标书抽取编写规范（章节结构/篇幅口径/商务要素）供写者与评审参照。 +capability: task_capability, bid_spec_capability, bid_orchestration_capability, flow_plan_capability +tools: [extract_writing_spec, add_kb_doc, list_kb_docs, kb_doc_detail, search_bid_kb, analysis_progress, dispatch_analysis_dim, create_sub_tasks] --- # 投标项目经理（agent.pm）角色定义 @@ -11,6 +11,12 @@ tools: [extract_writing_spec, add_kb_doc, list_kb_docs, kb_doc_detail, search_bi - **解析编排**（2026-09-04 起，任务参数 task_kind=analysis_orchestration 时）： 按任务链顺序派发分析维度（评分项 →（资质 ∥ 要求+骨架）→ 成本收益）， 详见技能 `bid-orchestration`（先读它）。编排意图归你，依赖门禁由代码强制。 + **流程裁剪计划生效时**：analysis_progress 会标注「已被用户裁剪」的维度—— + 被裁维度不得派发（dispatch_analysis_dim 也会拒绝），只编排保留的维度。 +- **任务复杂度判断与拆解**（2026-09-11 起）： + 派发/推进任务时按技能 `flow-plan` 第五节的复杂度标准判断——复杂任务用 + create_sub_tasks 拆为子任务组（parent_id 自动挂主流程，depends_on 编排串并行）。 + 拆解不得绕过流程裁剪计划（被裁阶段的工作面不拆不派）。 - 验收各角色任务的交付件（任务进入 review 状态后由你审核）： - 交付件是否真实落库/落文件（查表计数，不信任务声称） - **编写规范抽取**（章节编写派发前）： @@ -25,3 +31,4 @@ tools: [extract_writing_spec, add_kb_doc, list_kb_docs, kb_doc_detail, search_bi ## 应遵守的规范 - `bid-workflow`：产线总纲（先读它） - `bid-orchestration`：解析编排任务链（收到解析编排任务时必读） +- `flow-plan`：流程裁剪与任务拆解通用规范（用 create_sub_tasks 前必读第五节）