8.8 KiB
pipeline_core
产线核心模块 —— 管理产线定义、步骤编排、版本控制、发布流程。
功能
- 产线管理：产线 CRUD，定义产线名称与描述
- 步骤编排：产线步骤的增删改查，支持依赖关系（DAG）
- 版本控制：产线版本发布与回滚
- 编辑器：可视化产线步骤编排界面
数据表
| 表 | 说明 |
|---|---|
| pipelines | 产线定义 |
| pipeline_steps | 产线步骤（含 deps 依赖） |
| sd_projects | 软件项目定义（2026-09-10 自 pipeline-sdlc 迁入，跨产线共享） |
| sd_project_role_models | 项目角色模型配置（同上迁入；下拉 codes 指 sd_role 字典 + llm_model(status=active)） |
| pipeline_deliverables | 产线交付物（同上迁入；主要写入方 pipeline-bidding） |
| pipeline_user_memory | 跨会话持久记忆（2026-09-10 多租户：加 org_id/user_id 归属列，key 掺租户维度，迁移 m0023） |
| pipeline_tool_policies | 工具作用域策略（2026-09-10 五级作用域 org/pipeline/role/project 的 allow/deny 微调，迁移 m0028） |
已移除（2026-09-10 孤儿表清零）：pipeline_versions（页面 08-28 已删、0 行，models 定义删除+DROP 见 m0027）、llm（模型管理收敛 pipeline-llm 后停用，8 行已确认无损迁移，DROP 见 m0027）。
跨产线共享资源（wwwroot/api/）
三张迁入表配套 15 个 api dspy 与手写角色模型页（wwwroot/sd_project_role_models/，
git 跟踪、勿被 xls2ui 覆盖）。sdlc 侧页面消费 get_project_options.dspy 用绝对路径
/pipeline_core/api/** 引用；反向本模块页面消费 sdlc 子表也用绝对路径。
已知表治理清单（2026-09-10 审计）
全部办结（2026-09-10 批评会决议，用户认可）：
pipeline_conversations：孤儿表→已归籍 pipeline-service（models 定义 b8a2aea + collation 统一 m0022）。sd_conversations：死表→models 定义已删、project_capability 4 处引用已清、DROP 见 m0027（32 行备份后删）。- 其余 10 张孤儿/死表一次清零：5 张归籍补定义（bid_analysis_history、bid_cost_benefit→bidding；pipeline_agent_instances、pipeline_agent_settings、pipeline_project_agents→service），4 张死表 DROP + 权限清理见 m0027（非破坏的 collation/索引收敛在 m0026），pipeline_deploy_ledger 为 dmig 自建台账豁免（table_doctor 白名单）。
安装
cd pkgs/pipeline_core && pip install .
集成
伞仓 (pipeline-app) 通过 wwwroot symlink 加载本模块：
wwwroot/pipeline_core -> ../pkgs/pipeline_core/wwwroot
通用会话产线隔离（2026-09-05）
配合 pipeline-service 的 7 层隔离（详见其 README），本模块承担：
agent_config.load_agent_config(generic=True)：不挂产线能力包， 并剔除 GENERAL_TOOLS 中 category=project/shell 的工具（schema 层防线， LLM 根本看不见项目管理/命令执行工具）upload_tools.resolve_upload_dir(generic=True)：通用会话上传文件落_general/{uid}专属目录，与 AgentExecutor 的文件根一致 （_resolve_ws_path 越界保护只认该目录）wwwroot/api/agent_chat_generic.dspy：纯通用会话入口（generic=True）
agent 通用能力对齐 Hermes（2026-09-10）
把 Hermes Agent 的「写入侧/运行时侧」能力补齐给产线会话 agent，GENERAL_TOOLS
从 25 个扩到 29 个，新增四工具（定义在本模块 agent_config.py，handler 在
pipeline-service agent_loop_v2.py）：
| 工具 | 能力 | 隔离/门禁 |
|---|---|---|
memory |
add/list/remove 持久记忆（对齐 Hermes memory） | 多租户写入门禁在 handler：只能写 user/project/pipeline 域（global/org 种子域禁写），org_id/user_id 强制注入会话真实身份（忽略 LLM 传值），无身份拒写，remove 仅本人条目 |
manage_skill |
create/patch/write_file/remove_file/delete 技能（对齐 skill_manage） | 只落本租户 orgs/{org} 或 org 0 降级 users/{uid}；改 global 原版走 fork-on-write 继承副本；产线层拒改；子文件限 references/scripts/templates/assets |
process |
poll/log/wait/kill 后台任务（配套 run_command background） | 状态文件化在 workspace/.bg/，跨 worker 可见；只解析发起者 workspace |
subagent |
list/steer/stop/result 后台子 agent（配套 delegate_subtask background） | 同 workspace 并行上限 3、深度限制 1、子会话历史隔离 |
run_command 加 background/timeout 参数；delegate_subtask 加 background。
记忆多租户（memory_store.py）：每条记忆带 org_id/user_id 归属列；
visible_to() 是唯一可见性权威（平台种子 org_id='' 全员只读 + org 归属本机构共享 +
user 归属仅本人 + pipeline/project 域带机构匹配）；memory_key = hash(content+org+
user+scope+scope_id)，同内容跨租户 key 不同、唯一索引永不碰撞；_evict_partition
按 org+user 分区淘汰，agent 写入绝不删种子或他租户记忆；写后失效缓存保多 worker
一致。get() 是无过滤底层查询（管理用），agent 读取一律走 get_visible()。
ToolDefinition.required 字段（2026-09-10）：None=旧行为（全参数必填），含可选
参数的工具须显式声明 required 列表，否则 to_openai_schema() 把可选参数标成
required、LLM 被迫为每个参数编值。GENERAL_TOOLS 全部带可选参数的工具已补 required。
第二批能力对齐：五级工具作用域 + patch_file + 原生视觉（2026-09-10）
五级作用域工具解析（tool_sources.py，GENERAL_TOOLS 30 个）
用户要求：全局/机构/产线/角色/项目五级各注册不同工具，产线特有工具按产线区分。
| 级 | 工具来源 | 隔离机制 |
|---|---|---|
| global | GENERAL_TOOLS | generic 会话剔除 project/data 类 |
| org | 机构技能包 capability 工具 + 策略表 allow/deny | 技能 get_merged 按 orgs/{org}/ 物理目录隔离 |
| pipeline | PipelineAbility.tools + 产线技能 capability 工具 | 注册表按 pipeline_id；generic 不挂 |
| role | RoleSpec.tools 白名单（过滤器非添加器）+ 角色策略 | get_role_spec(pipeline_id, role) 按产线隔离 |
| project | 策略表 allow/deny 微调 | 策略行 scope_id=project_id |
- 策略表 pipeline_tool_policies（scope/scope_id/tool_name/effect/reason/status，
uk(scope,scope_id,tool_name)）：CRUD 管理页
/pipeline_core/pipeline_tool_policies/； 表缺失/查询失败按无策略降级（WARN 日志，不阻断会话）。 - capability 两层语义（别简化成一层）：①「capability 含哪些工具」映射从全部 可见技能收集（all/ 概念规范技能=映射手册）；②「本会话需要哪些 capability」只认 org/pipeline/role/project/user 层技能的声明——global 层声明不作为注入依据， 否则 generic 会话经 all/ 概念技能拿到 ~70 个产线工具、击穿七层隔离（单测有回归用例）。
- role 白名单收窄顺序：capability 工具必须先并入再收窄（白名单作用于全集）， 且白名单是过滤器不是添加器；ask_user/todo/memory/read_file/write_file 等基础工具始终保留。
- 执行层强制门禁（service
_execute_tool）：LLM 幻觉调用作用域外工具名直接拒绝 并回可行动提示——schema 防线挡不住幻觉。 - 测试机实测：服务端直调 17/17（真实策略表读写/产线区分 sdlc 72 个 vs bidding 17 个 capability 工具/门禁三态）+ HTTP 门禁确认（generic 会话 schema 无 create_project， LLM 如实告知未挂载拒绝伪造调用）。
patch_file 工具（文件定点替换）
old_string 唯一性校验（0 次/多次拒绝，replace_all 显式放行）+ 原子写 + 越界防护
- 二进制拒绝。HTTP 实测：agent 真实完成 write_file→patch_file→read_file 三步链并回读验证。
原生视觉（上传图片直接进对话）
- upload_tools：
is_image+build_image_parts（OpenAI 多模态 data URL；8MB/张、 4 张/条上限，超限显式告知绝不静默丢）。 - 三个 dspy 入口图片分流：不进文本上下文（避免「二进制无法读取」矛盾提示）， 仍落盘工作空间（i2t 可再处理）。
- gateway.run_message(image_paths) → executor.run(image_parts)：首条用户消息构造 多模态 content 数组；llm_bridge→llm_v1 端点→inference 全链原样透传 messages。
- 降级兜底
_degrade_images_if_needed：模型不支持视觉时剥离图片重试一次 + 注入 系统说明让 LLM 如实告知「当前模型看不了图」，绝不假装看过。token 估算/压缩摘要 兼容 list content（_content_as_text）。 - HTTP 严格实测：中性文件名（img_001/img_002，无颜色词）红蓝两图一条消息， agent 答「第一张红色、第二张蓝色」映射正确，degrade 日志 0 条（模型原生支持）。