feat(core): 产线流程裁剪声明层——FlowStage dataclass(key/label/trim三级no-warn-yes/warn_note/roles/deps)+PipelineAbility.flow_stages字段+get_flow_stages/flow_stage_to_dict;新增all/flow-plan通用技能(裁剪概念+确认门禁+PM复杂度拆解规范,capability=flow_plan_capability);投标bid-workflow/bid-orchestration/agent.pm技能补裁剪与拆解说明

This commit is contained in:
yumoqing 2026-09-11 12:58:26 +08:00
parent f8b370b958
commit f5cf90eb17
6 changed files with 158 additions and 3 deletions

View File

@ -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,

View File

@ -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 []),
}

View File

@ -0,0 +1,70 @@
---
name: flow-plan
description: 产线流程裁剪与 PM 任务拆解的通用概念规范——预制流程阶段、裁剪合法性、确认门禁、复杂度判断与子任务编排。任何产线的会话 agent 裁剪流程、PM 拆解复杂任务时先读它。触发:流程裁剪/简化流程/跳过阶段/任务拆解/子任务编排。
capability: flow_plan_capability
tools: [create_sub_tasks]
---
# 流程裁剪与任务拆解(通用概念规范)
## 一、概念
- **预制流程** = 产线声明的阶段链(能力包 flow_stageskey/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 派其他产线的角色名(守卫会拒绝)。

View File

@ -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 参数):异常招标文档的特殊交代

View File

@ -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 用户纠正,实测违反过)
用户问「还差什么没完成」「如果允许重做会重做哪些工作」这类**分析/假设性问题**时:
- 只输出分析结论(缺什么、重做范围、影响面),**禁止创建任何任务、禁止改任何数据**

View File

@ -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 前必读第五节)