最基础版「AI 行动系统」Demo 落地方案

目的：让“数据在哪”变成平台看得见、连得通的一等公民。Foundry 在 V5 已自持数据源管理（与 AIP 侧数据源并列：AIP 数据源供 NLQ 取数，Foundry 数据源供数据集/同步/管道/本体写路径使用）。

操作（推荐在 Foundry 前端做，两处二选一即可）

1. 进入 Foundry 侧边栏 数据源页（前端路由 /foundry/datasources，调 Foundry 后端 /api/v1/datasources）。
2. 点“新建数据源”：名称/类型（表单下拉已与连接器 allow-list 对齐：PostgreSQL / MySQL / SQLite / SQL Server 可建，Oracle / ClickHouse 置灰需授权启用）、主机/端口/库名/账号/密码/描述。
3. 点 测试连接：返回成功即连通（后端 POST /datasources/:id/test，按请求体完整连接配置真实建连，而非仅用库内记录）。
4. 点 导入元数据：拉取表结构进平台（POST /datasources/:id/import-metadata，V5 已任务化：15s 内完成直接返回结果，超时返回 202 受理 {task_id}，前端进度条按 1.5s 轮询 GET /system/tasks/:id；导入即对账清理：按 table_schema_id 清理旧列后重建，且 prune_stale 默认 true 会一并删除实库已消失的陈旧表/列（O-026），避免残留表名误导 RAG；显式传 false 才保留纯 upsert 行为）。

怎么验

• 数据源列表出现新行且“测试连接”通过；导入后能看到 inventory / purchase_request / orders 等表名。
• AIP 侧演示库数据源（aip_demo_warehouse）在 AIP 的 数据源管理页（/datasources）也可查看/重导。

目的：演示“数据进平台”的三种姿势，并解释“自动导入”到底怎么配。平台按用途给了三种受控手段，不是“任意文件即传即用”：

操作 A：管道（主推，能跑真实 SQL）

1. 进 管道构建页 → 新建管道：名称（api_name 唯一，编辑不可改）、源连接器 ID（数据源数字 id）、目标对象类型 ID（可选，用于 write_mode 同步）、描述、保持「启用」勾选。
2. 选写入模式（append / append_only_new / snapshot_replace / snapshot_replace_and_remove / changelog——changelog 未实现，创建/更新即被 400 显式拒绝，不会进入可运行态）；选触发类型 manual（默认）或 cron（选 cron 必填表达式，如 0 2 * * *）。
3. 「+ 步骤」加 SQL 步骤（名称 + 类型 select/insert/update/create_table_as + SQL），如 CREATE TABLE IF NOT EXISTS stock_daily AS SELECT product_id, warehouse, stock_level, reorder_point FROM inventory（类型 create_table_as）。
4. 保存后点 运行：confirm 后 POST /api/v1/pipelines/:id/run（同步执行），返回 run 记录；展开「运行历史」看 status=success 与 rows_in/rows_out（前端 30s 超时后 run 仍在后端执行，勿重复点运行，用运行历史确认终态）。
5. 若想“自动跑”：触发类型选 cron + 启用 → 保存即注册到平台统一调度器（syncSchedule 幂等注册 pipeline:<id>）→ 到点自动执行，triggered_by=cron，调度记录可查（GET /api/v1/scheduler/jobs）；停用/删除/改 manual 即反注册。
6. 质量联动：管道 run 会执行挂在它名下的质量规则（scope=pipeline 且 enabled），error 级违规使 run 标 failed 并阻断目标对象同步。

操作 B：同步作业（“拉取外部表”语义，B1-3 同步引擎）

1. 进 数据同步页 → 新建同步目标（两步向导）：目标名称 + 目标数据集（先在数据集页建好，或选登记型）。
2. 第一步选来源类型：platform_ds（填数据源 ID + 来源查询 SQL，如 SELECT order_id, amount, updated_at FROM orders）或 object（本体对象快照，仅 full 模式）。
3. 第二步选同步模式：full（单事务清空目标行表全量重写）/ incremental（必填水位列 watermark_col，如 updated_at，运行时自动包装 SELECT * FROM (查询) WHERE 水位列 > 上次值；可选 field_map 幂等键映射 {"order_id":"order_id"}，冲突跳过）。
4. 可填 cron 调度（空=仅手动；如 0 */2 * * * 每 2 小时）+ 勾选「创建后立即启用」→ 创建即注册调度条目 sync:<targetID>（注册失败如非法 cron 会回滚创建）。
5. 保存后点「立即运行」（任务化：POST /api/v1/sync/targets/:id/run，15s 快路径或返回 task_id 走进度条轮询）→ 运行历史 GET /sync/targets/:id/runs 出现 success 与 rows_synced；同步成功链自动触发数据集质量画像 + 血缘打点 source→dataset。

操作 C：数据集（CSV/上传 + 画像）

1. 进 数据集页 → 上传 CSV（仅 CSV/JSON，XLSX 显式拒绝；表头列名必须过白名单 ^[a-z][a-z0-9_]*$——小写字母开头、仅小写/数字/下划线，含大写/中文/空格直接拒绝，上限 32MB）→ 自动生成 schema → 预览 50 行 → 发布版本（POST /api/v1/datasets/upload、/datasets/:id/versions/publish；发布=指针推进不拷数据）。
2. 打开画像（GET /datasets/:id/profile）看质量分（每列 null 率/distinct/avg/top5 高频值）。
3. 也可用「新建数据集（数据源查询）」：填数据源 ID + 查询 SQL（建议带 LIMIT）→ 创建即拉数落平台行表并推断 schema，自动打血缘 datasource→dataset。

怎么验

• 管道/同步/数据集各有 ≥1 条 success 记录；血缘页能看到“源 → 管道 → 对象/数据集”的边（若打了目标对象）。
• 调度器页能看到注册的管道/作业与其最近一次运行结果。

目的：本体是“AI 能懂业务”的语义层：对象=表，属性=列，动作=授权写入口。seed 已把 inventory / purchase_request 等建好，本幕一是看懂结构，二是演示编辑流程（版本 draft→review→merge + 需要时 approve）。

操作 ①：看懂 seed 本体

1. 进 Foundry 对象工作台（/foundry，FoundryPage）→ 切到“对象”Tab，列表含 customer / order / product / inventory / purchase_request。
2. 打开 inventory：看属性（inventory_id / product_id / warehouse / stock_level 库存量 / reorder_point 补货点 / updated_at）与动作 update_inventory（modify，参数 inventory_id+stock_level+expected_updated_at，乐观锁+幂等键字段=inventory_id）。
3. 打开 purchase_request：看动作 create_purchase_request（create，新增采购申请）。这两个对象 + 动作是主剧情“补货”的语义基础。

操作 ②：改一版本体并走审批（演示“本体信息不是随便改的”）

1. 在对象工作台对某对象点“建草稿”（POST /ontology/objects/:id/drafts）→ 改一个属性显示名/加说明（PUT /ontology/drafts/:vid）。
2. 提交评审（POST /ontology/drafts/:vid/review）。
3. 若该对象动作/策略要求多人审批（requires_approval 且 min_approvals>1），合入会先返回 409 APPROVAL_REQUIRED：审批人调用 POST /ontology/objects/:id/versions/:vid/approve，票数够了再 POST /ontology/drafts/:vid/merge 才放行；自批会被 409 APPROVAL_DENIED 拦下。
4. 看版本历史（时间线 draft→review→merged + change_diff），点“影响分析”看受影响的指标/对象。

怎么验

• 版本号 +1、状态回到 merged；版本时间线、影响分析有内容。
• “被引用对象禁止删除”“merge 需审批”这些治理规则能触发一次让你讲解。

目的：把“库里有什么”变成“一句话问出来”。给你 4 个查询入口，按演示需求选：

怎么验（推荐组合拳，演示“AI 看得懂库存语义”）

1. AIP /chat 问一次订单销售额——展示“一句话出数”，并强调 OAG 已把 Foundry 对象/口径注入 Prompt。
2. 语义检索搜 inventory、purchase_request——展示“AI 能找到动作与字段”。
3. 对象查询真实过滤 inventory，找出 stock_level < reorder_point 的行——这是后续自动化的事实输入（若嫌手写 filters 麻烦，也可让 5.5 的事件触发把状态带出来）。

目的：把“查数/分析/动作/通知”编排成一条可反复跑的自动化流水线。工作流引擎 9 类节点：trigger / query_data / nlq_query / ai_analysis / ai_generate / condition / send_notification / call_api / execute_foundry_action；触发器 4 种：manual / cron / webhook / event。操作入口：AIP 管理后台 → 工作流编排（/admin/workflows）。

推荐演示：做一个“库存异动 → AI 研判 → 通知/动作”的 event 工作流

事件工作流的妙处：不用先有数据源连接，事件 payload 自带业务上下文（prior_state / new_state），最不容易“卡壳”。

1. 新建工作流，名称如 stock_drop_alert；触发器选 event 并填 filters：object_types=[inventory], action_names=[update_inventory]（防止自动动作写库再自触发，这是防环关键）。
2. 编排节点（JSON / 或前端节点表单；节点输出在节点间用 {{.节点id.output.字段}} 引用）：

   节点 t0  trigger        // 触发数据注入 {{.trigger.event.*}}
   节点 a   ai_analysis    // prompt: 库存 {{.trigger.event.new_state.stock_level}}
                           // 低于补货点 {{.trigger.event.new_state.reorder_point}} 吗？给一句话研判
   节点 c   condition      // condition_template: true → 放行；false → 兜底分支
   节点 n   send_notification // channel=internal(默认)|feishu|email，主题/正文可引 {{.a.output.text}}
   节点 x   execute_foundry_action // action_name=create_purchase_request, params 引用事件字段,
                           // idempotency_key=stock-event-{{.trigger.event.id}}

3. 保存并 发布（POST /workflows/:id/publish，发布后 event 调度器每 ~30s 轮询 Foundry change-events）。
4. 点 立即运行（manual，POST /workflows/:id/run）可先验证一次不报错；再进入 5.8 用一次真实动作触发 event 路径。

补充演示：cron 定时（“自动”的字面意思）与 webhook

• 把同一工作流触发器改为 cron: 0 9 * * *（每天 9 点）→ 发布即注册到调度器；/admin/monitoring 或 GET /scheduler/jobs 可见下次触发时间。若内部有 query_data 节点要“定期盘点”，请确保其数据源里确有对应表。
• webhook 触发：配置 trigger_config.type=webhook, path=price-alert → 任意调用方 POST /api/v1/webhooks/price-alert（公开）即触发。仅适合轻量场景，网关建议限来源。

怎么验

• 工作流列表状态 published；手动 run 返回一次 execution，GET /workflows/executions/:eid 能看到逐节点状态/输入/输出（执行回放）；通知节点落 WORKFLOW_NOTIFICATION 审计。
• 事件触发后，executions 的 trigger_type=event、trigger_data 含 event 对象（可核对 id 与动作名）。

目的：上面手搭 DAG 门槛高——Copilot 把“配置自动化”变成对话。它通过 function calling 调用工具：create_automation / list_automations / enable / disable / delete / run_automation_now / query_objects / execute_action / list_change_events / get_doc，并把配置写成完整可执行、已发布的工作流。入口：AIP 管理后台 → AI 自动化经营（/admin/automation，AutomationConsole）。

三段对话演示（照着念，跑偏就补一句纠正）

1. 建定时简报：“每天 9 点检查一遍低于补货点的库存，帮我生成一段中文分析，发到站内通知，并把发现的低库存商品自动创建采购申请。”——Copilot 会先 list_automations 避免重复，再 create_automation（trigger_type=cron）并发布；右侧自动化列表应出现新行。
2. 建事件规则：“以后每次库存被调低，如果低于补货点就自动建采购申请并通知我。”——生成 event 模板：t0→ai_analysis→condition→execute_foundry_action+send_notification，幂等键 automation-event-{{.trigger.event.id}}。
3. 直接问/做：“现在有哪些库存低于补货点？”（query_objects，展示 AI 懂库存语义）；如想演示写库再补一句“把 SKU-0001 的库存量改成 80”（execute_action 前它会先说明影响，演示人点头再放行）。

怎么验

• 对话落 automation_sessions/automation_messages；每次工具调用审计 AUTOMATION_TOOL_CALL；生成的自动化在“工作流编排”里可见且 status=published。
• 把 5.5 的 event filters 加进对话：“只监听库存更新事件，避免自触发”——Copilot 会把它写进 filters。

目的：演示“AI/自动化做决定之前，人可以设一道闸”。Foundry 有一套业务流程工作流引擎，节点含 start / human_task / auto_task / script_task / gateway / wait / end：human_task 把流程停在人工待办上，approve / reject 后流程继续；auto_task 可调用本体 Action（走写路径执行）。入口：Foundry 侧边栏 → 工作流（/foundry/workflows）。

演示一个“补货审批”工作流

1. 新建工作流（JSON 编辑节点与边，表单预填 start→human_task→end 示例）。推荐两个版本：
   • 线性版（最稳，推荐先演）：start → human_task(经理审批) → auto_task(创建采购申请) → end。审批通过则自动建采购申请；拒绝即实例 failed（MVP 语义：reject 置实例 failed，无退回/分支）。

     nodes:
     - {"key":"s","type":"start","label":"开始"}
     - {"key":"h","type":"human_task","label":"采购经理审批",
        "config":{"assignee_role":"admin"}}          // 或 {"assignee_user":"用户ID"}；可加 "due_in_hours":24
     - {"key":"a","type":"auto_task","label":"创建采购申请",
        "config":{"action":"create_purchase_request","object_type_id":<采购申请对象ID>,
                  "params":{"product_id":1,"quantity":20}}}
     - {"key":"e","type":"end","label":"结束"}
     edges:
     - {"source_node_id":"s","target_node_id":"h"}
     - {"source_node_id":"h","target_node_id":"a"}
     - {"source_node_id":"a","target_node_id":"e"}

   • 分支版（讲条件路由时用）：条件分支要用 gateway 节点——引擎只对 gateway 的出边逐条求值（EvalCondition，如 {{amount}} > 1000），取首个 true 的边；human_task 出边挂 condition 不生效。审批通过后 human_task 把 {decision:"approved",comment,handler} 写入上下文，后续 gateway 用 {{approval.decision}} 点路径引用。
2. 校验（POST /workflows/:id/validate，DAG 校验：唯一 start/end、类型合法、环检测、可达 end）→ 发布（版本自增置 active，未发布不能启动）→ 启动（POST /workflows/:id/start，prompt 填 JSON 输入）→ 实例停在 human_task（任务 assigned + 发站内通知）。
3. 换审批人账号登录，进 我的待办（GET /tasks/my）→ 看到该任务 → 填意见后 通过/拒绝（POST /tasks/:id/approve|reject；后端强制「仅限被分配人处理」，否则 403）。
4. 同意后引擎恢复快照继续推进 → auto_task 调用本体动作 create_purchase_request 走写路径落库（幂等键 wf-<instanceID>-<nodeID> 防重复写）；驳回则实例置 failed。

怎么验

• 任务中心出现 human 待办，approve 前业务表无新采购申请，approve 后出现新行——审批闸门是真的。
• 实例详情能看到节点执行轨迹；审批动作留痕（任务状态 completed/rejected + 审计）。
• 关联的评论（/comments）与站内通知（/notifications）也一并可用，可补一句“审批还能 @ 同事、留言”。

目的：演示“AI 不是只会说，而是能执行受控动作”，并验证安全机制（校验/幂等/乐观锁/审计/事件）。平台提供四种“动作执行入口”，同一套写路径安全流水线：

操作：①（动作测试）+ ②（Agent）组合拳

1. 校验动作本身：动作测试页固定 VALIDATE_AND_EXECUTE 模式（页面不提供模式切换）；纯校验用 API POST /ontology/actions/:name/validate（mode 强制 VALIDATE，不落盘不耗幂等键）。
2. 拿乐观锁：对象查询看某行 updated_at（update_inventory 的 SQL 模板带 AND updated_at=:expected_updated_at，参数 schema 的 required 含 inventory_id/stock_level/expected_updated_at）。
3. 真实执行：选动作 → 按 param_schema 生成参数表单（number/enum 自动渲染）→ 点「生成」自动产生幂等键（crypto.randomUUID）→ 执行，把 stock_level 调低（低于 reorder_point，为 5.5/5.6 的事件流“递补货理由”）→ 返回 success + rows_affected=1 + operation_id（run_<id>）。
4. 幂等重放：点页面「重放上次执行」按钮（复用 lastKey 再提交）→ 返回 replayed + replayed_from_run_id，rows_affected 回放首次值，不重复写库。
5. 乐观锁冲突：故意用旧 expected_updated_at 再跑 → 返回 conflict（409 ACTION_CONFLICT）。注意契约：HTTP 200 ≠ 成功——validation_failed(422)/forbidden(403)/conflict(409) 业务失败时响应体仍携带完整 mode/status/validation/edits；仅 replayed 降为 200。
6. Agent 查证：AIP /agent 新建任务 goal=“统计各客户消费总额”（或“查询当前低于补货点的库存”），模式 plan_execute（当前唯一模式）→ 同步执行（前端 timeout 120s），返回 steps 时间线（工具名+状态+结果摘要）+ result_summary——体现“Agent 规划并调用工具完成目标”，随后把步骤结论作为“要不要补货”的依据。

怎么验

• 动作执行后：业务表行被改、审计 ACTION_EXECUTE success、GET /ontology/change-events 出现对应事件（prior_state/new_state/operation_id/user_id）——为 5.5 event 工作流供料。
• Agent 任务返回 completed + steps 明细；工具执行有审计。

目的：把“自动化的结论/待办”主动推给真人。通知演进：internal（审计即通知）→ feishu（私聊/卡片）→ email（SMTP）。管理工作流通知节点三渠道可配。

配置与状态检查

1. 邮件：AIP 管理后台 → 邮件设置（/admin/email）填 SMTP 账号；用 POST /api/v1/email/test 发测试邮件，GET /email/status 看状态。未配置时 email 节点会直接失败（设计如此，不静默丢通知）。
2. 飞书：飞书设置页（/admin/feishu）显示机器人运行状态（config 已配 app_id/app_secret 且 feishu.enabled=true 时默认启用）；POST /feishu/push 可主动推（receive_type=open_id|chat_id）。
3. 通知中心：站内通知（列表/标已读）在 Foundry 工作流页与 AIP 均有入口，适合 offline 演示兜底。

接到工作流上

1. 在 5.5 的事件工作流里把 send_notification 节点配三渠道：channel=internal（必现）、channel=email（填收件邮箱）、channel=feishu（填收件人 open_id）。
2. 跑一次事件触发 → 对应渠道收到消息：internal 落审计 WORKFLOW_NOTIFICATION、email 收到 SMTP 邮件、飞书收到卡片。任一渠道因缺凭证失败会在节点状态里明确报错——这本身就是“配置检查”的演示。

把上面各幕的“留痕”统一收口，回答“凭什么相信 AI 干了这些”：

跨产品串讲（收尾话术）

把整个主线连起来讲一遍：① 某商品库存被调低（8 的 ActionTester）→ ② 事件触发 AIP event 工作流（5.5），Copilot 生成的规则负责 AI 研判并建采购申请、发通知（5.6/5.9）→ ③ 采购经理在 Foundry 任务中心审批（5.7）→ ④ approve 后流程继续 → ⑤ 全部动作进审计/事件/血缘（5.10）。演示时逐个页面翻证据，就是一个“AI 行动系统”的完整故事。

1. 开场 20s：翻到 Foundry 本体对象 inventory（属性+动作），说“数据在这，动作受控写库”。
2. 40s：AIP /chat 一句话“各区域订单销售额”→ 图表出来，“AI 能查”。
3. 60s：切到 Automation Copilot 对话：“每天 9 点检查低库存，低于补货点自动建采购申请并通知我”→ 右侧自动化 published，“AI 能配自动化”。
4. 80s：动作测试把某库存调低 → 打开工作流执行列表，≤90s 内（~30s 轮询相位 + 执行时长，实测 24~32s）出现一条 event 触发、自动建单+通知，“AI 能行动”。
5. 100s：换审批账号打开任务中心，approve → 采购申请落库，“关键时刻人拍板”。
6. 120s：审计 + 对象变化事件翻两屏，“全程留痕可回看”。收工。

• 产品与路线：wiki/OVERVIEW.md、wiki/ROADMAP.md、wiki/upgrade-v5/UPGRADE-PLAN.md（V5 数据域+知识域双线蓝图）
• AIP 模块开发文档：wiki/docs/aip/{workflow_automation, automation_copilot, tool_system, agent_framework, nlq_engine, oag, datasource_connector}.md
• Foundry 模块开发文档：wiki/docs/foundry/{ontology_modeling, ontology_sql, pipeline_builder, dataset, sync, data_lineage, actionctl}.md
• 业务故事站（面向听众的叙述素材）：docs/story/aip/{workflow-automation, agent-orchestration, oag-object-path, datasource-onboarding}.html、docs/story/foundry/{ontology-modeling, pipelines, semantic-query, action-writepath}.html、docs/story/cross/combined-demo.html（旧 v4 口径：无编排、靠人接力——本方案即把其中“靠人接力”的短板用 AI 自动化补上）
• 真实回归参考：冒烟脚本 temp/smoke_foundry.sh（本体/语义/动作写路径/管道全链路 23 项 PASS）；AIP v4 测试（products/aip/server/agent_http_test.go、automation_http_test.go）可作为自动化用例的“标准答法”
• 各幕前端页面：见 §2 表与各幕操作；前端源码 web/src/router/index.js、各 views/*.vue
• 前端页面操作手册（逐页详解，与本方案配套食用最佳）：action/docs/frontend-intro-v5/markdown/（foundry/ 30 篇：data-sources、datasets、sync、pipelines、yaml、object-query、action-tester、workflows、apps 等；aip/ 36 篇：chat、agent-run、admin-automation、admin-workflows、admin-email、admin-feishu 等；另有同名 html 版）。进阶版「从新手到资深」全流程使用文档见 action/docs/manuals/usage-guide/（16 章）