织信informat

概述

织信(Informat)平台系统方法

第一步：检查环境变量（必须最先执行）

加载本技能后，在解析路径、读取参考文档或调用任何织信接口之前，第一步必须检查 INFORMAT_HOST 和 INFORMAT_AGENT_TOKEN 是否已设置：

test -n "${INFORMAT_HOST:-}" && test -n "${INFORMAT_AGENT_TOKEN:-}"

• 检查通过：继续执行后续步骤。
• 检查失败：立即停止，明确告知用户缺少哪个环境变量，不得调用任何织信接口，不得转而从 scripts/.env 或其他文件读取凭据。
• 检查时只判断是否为非空值，不得输出 INFORMAT_AGENT_TOKEN 的内容。

当前会话路径规则（优先级最高）

当前会话的用户消息前缀会提供：

• informatclawThreadId
• call_informat.js 的绝对路径
• informat skill 的绝对目录

必须使用这些绝对路径：

• 调用接口：node "<运行时提示给出的 call_informat.js 绝对路径>" <方法名> --threadId <informatclawThreadId> ...
• 读取参考文档：cat "<运行时提示给出的 informat skill 目录>/references/..."

不要使用 Read 读取 /root/.informatclaw/config/skills/informat；不要使用 $INFORMAT_CONFIG_DIR、{baseDir}、/data/workspace/informat 或自行猜测路径；不要写或依赖 scripts/.env。

共 216 个方法。每个方法的参数定义文件在 {baseDir}/references/ 下。

📦 SkillHub 压缩包说明：为满足发布页“最多 200 个文件”的限制，本目录可能将原 references/system_*.json 参数定义合并到 references/system_catalog/system_schemas.json。

• 原文件内容可在 system_schemas.json.byPath["system_create_table_module.json"] 中找到
• 方法名到原文件名的映射在 system_schemas.json.byMethod["_create_table_module"]
• scripts/call_informat.js 已兼容该合并格式，会优先读取独立 schema 文件；不存在时自动从 catalog 读取

📚 参考文档目录：{baseDir}/references/doc/ 下包含平台完整开发文档：

• references/doc/markdown/ 目录：平台核心功能官方文档（AI助手、API、自动化、仪表盘、表达式、定时任务、脚本、数据表、任务、网站等）
• references/doc/markdown/script/ 目录：脚本API参考文档，按模块分类（bpmn.md、table.md、http.md等），开发脚本时优先查阅

调用规则

根据方法名前缀，系统自动选择对应的智能体接口：

调用协议（合并闸门：doc + schema 一次过）

⚠️ 脚本内置闸门：首次进行某类操作前，先读领域设计文档 + 参数 schema，否则脚本拒绝执行并返回提示。两道证明（_doc_ack 读文档、_ack 读 schema）合并成一次——提示里要哪个就一起带哪个，一次重调即过：

# 步骤1：读参数 schema（理解必填/枚举/类型/嵌套结构）
cat {baseDir}/references/system_create_table_module.json
# 步骤2：读该领域设计文档（references/doc/markdown/ 下对应 .md，取头部 DOCKEY: <令牌>）
cat {baseDir}/references/doc/markdown/informat.table.md

# 步骤3：写参数文件，按提示带上 _doc_ack(=DOCKEY 令牌) 和/或 _ack(=该方法【必填】参数名，逗号分隔)
#        两者都是“已读”的凭证，调用前自动剥离不发后端。_ack 只需必填参数名（不是全部）。
echo '{"id":"t1","name":"表","fields":[],"_doc_ack":"tbl-2e7a9","_ack":"id,name,fields"}' > params.json

# 步骤4：执行（脚本仍会按 schema 本地校验必填/枚举/类型——这是防造参的真正安全网）
node {baseDir}/scripts/call_informat.js _create_table_module --appId <appId> --threadId <threadId> --file params.json

# 公共/团队/工作台方法（无需 --appId）；只读(查询/列表/读取)与零参方法免闸门、无需 _ack
node {baseDir}/scripts/call_informat.js _get_current_time --threadId <threadId>

闸门按领域只拦一次：_doc_ack/_ack 凭证按领域记（表/自动化/工作流/仪表盘…）——某领域首个建造方法过闸后，同领域其余方法不再逐个拦（如建完第 1 张表，后面 11 张表直接放行），靠步骤 4 的本地校验兜底。

闸门反馈处理：

• [First operation of this kind: please read the documentation and parameter definitions before calling]（exit 3）→ 该领域首次建造。按提示用 Read 读出的那份 .md 取 DOCKEY 作 _doc_ack，读 schema 取【必填】参数名作 _ack，连同业务参数一并重调（提示要几样就带几样，一次过）。严禁不读凭空猜令牌/参数名。
• [Parameter validation failed: xxx]（exit 4）→ 必填缺失 / 枚举非法 / 类型错。对照 schema 修正后重试。这是放宽闸门后防造参的主防线，认真改。
• [Before saving this script: read the SDK reference for each informat.* module it uses]（exit 5）→ 仅 _save_informat_script：脚本里用到的 informat.<模块>.*（如 informat.table.*）对应的 script/<模块>.md 本会话未读过。先逐个 Read 提示中的 script/<模块>.md 核对准确签名（参数个数/顺序/位置，常见错：tableId 塞进 query、update 写成 3 参），再带 _sdk_read=<模块名逗号拼接> 重调。同一模块一会话只拦一次。
• [Before this operation: read the expression reference, as the payload contains a platform expression ${...}]（exit 6）→ 任何写类方法的参数里出现平台表达式 ${...}（自动化步骤值、公式字段、流程条件等），但本会话未读 informat.expression.md。织信表达式是平台 DSL（UEL），不是 JavaScript，语法与可用函数以该文档为准。先 Read informat.expression.md，再带 _expr_ack=<该文档头部 DOCKEY 令牌> 重调。一会话只拦一次（脚本 _save_informat_script 与前端 _codestudio_* 的 ${} 是 JS 原生模板串，不触发本闸）。
• [Blueprint not yet complete: finishing is not permitted]（exit 7）→ 仅完整应用编排：调用 _app_check_setting 收尾但某类组件实建数未达标。补齐提示中的缺口组件（须与蓝图联动，不应为充数而堆砌）再收尾。实建数由脚本按 name 自动计数（含 table/automatic/script/api/workflow/dashboard/listener/schedule——监听器、定时任务一旦在 §2 对齐时经用户确认就须写进 plan.targets 并真正建出，不得当"可选扩展"在建造阶段静默丢弃），无法通过口头"已完成"规避；确需删减某项用 _plan_set 重新登记目标数并说明原因。
• [Build artifact rejected: it violates the <domain> design rules]（exit 10）→ 建造产物校验（抗上下文衰减）：在建造那一刻按领域跑确定性硬规则，与"是否还记得文档"无关。覆盖 dashboard（enableCardStyle 须 true / Number 卡 xPosition·yPosition 须 center / subTitle≠name / 排序 orderByList 须为 {field,type:asc|desc} 对象而非 "count#desc" 字符串 / 卡片 width 须适配当前行剩余列：24 列栅格按"流式 order+width"排布，width 超出本行剩余会换行留空导致错位，须按行凑满 24 且按视觉顺序建卡 / ProChart 须有数据源：proChartSetting.dataset 非空且每条绑真实 tableId 或 expression、series 非空，否则图表空白）、automatic（按 schema 逐步校验每个步骤必填引用：OutputBpmnProcess 须 bpmnModuleId+bpmnProcessDefineId+bpmnProcessStartFormTableId+bpmnProcessStartFormFieldList、OutputRecordCreate 须 recordCreateTableId、CallScript 须 scriptId+func、SetReturnValue 须 valueVar、If 须 expression+If.true/If.false 分支；交互输出步骤须有展示内容：OutputToast 须 toastValueVar、OutputConfirm 须 confirmTitleVar 或 confirmDialogTitleVar、OutputNotification 须 messageVar 或 message，否则前端弹空白框；funcSettingList 不能为空）、bpmn（UserTask 须配 assignee+formSetting.tableId+至少一个按钮 / 退回边不可用"全无条件流转线构成的环"，须带 conditionExpression 或改用 TaskMoveToActivity 按钮）、listeners（eventList 元素须事件 ID 字符串非对象 / 顶层不应有 tableId / invokeType 须配执行体）、table（业务字段不得叫 id·seq / 关联字段须有真实目标 tableId）、schedule（invokeType 须配执行体 / cron 型须有 cron）。提示附紧凑要点，按提示修正参数后重调，无需重读全文。仅在真违规时触发、不误伤合法变体。
• 关联建模收尾闸（exit 7 的一部分）：完整应用且计划表数 ≥2，但全应用未建任何 Relation（M:N）或 LookupList（1:N）字段时，收尾自检判定建模过于扁平（关联全是 N:1）并拦回，提示按语义补主子表的查找列表/多对多关联，不要把所有关联都做成单条关联记录。
• 瞬时网络错误自动重试：5xx（含偶发 HTTP 550）/ 超时 / 连接重置等瞬时错误，脚本会自动退避重试至多 4 次；4xx 与 JSON-RPC 业务错误不重试。遇到偶发网络报错先重发当前调用，不要据此改动已正确的参数。
• 领域软提醒（每会话每领域首次建造注一次）：建造某领域首个对象成功后，响应尾部追加 ≤8 行该领域核对清单（主题一致 / 图表选型 / 工作流须多节点带分支 等无法机检的规则），marker 节流，后续零开销。看到后据此自检，不要无视。
• 蓝图契约用 _plan_set 命令登记（call_informat.js _plan_set --appId <id> --threadId <threadId> '{"targets":{...}}'），不要自行写盘——进程常进入只读目录，自行写出的文件脚本无法定位，将导致闸门失效。

获取应用ID

# 1. 查询所有应用列表
node {baseDir}/scripts/call_informat.js _company_app_list --threadId <threadId>

# 2. 从返回结果中找到目标应用的ID，用于后续调用
node {baseDir}/scripts/call_informat.js _query_app_define_designer --appId <appId> --threadId <threadId>

配置

运行时应由服务端注入 INFORMAT_HOST、INFORMAT_AGENT_TOKEN 和 INFORMAT_AGENT_THREAD_ID；必须先通过文档开头的环境变量检查。调用时只需要按上方规则显式传 --threadId。严禁写入或依赖 scripts/.env。

INFORMAT_AGENT_TOKEN 获取方式：登录后访问 <informat host>/workbench/account/aiAgentApiKey

生成文件必须上传 — 重要规则

当你生成了任何文件（Excel、PPT、PDF、Word、CSV、图片等）需要让用户下载时：

1. 必须调用 _wb_upload_file 将文件上传到平台存储
2. 必须将返回的 downloadUrl 提供给用户作为下载链接
3. 严禁直接返回服务器上的本地文件路径给用户（用户无法访问服务器文件系统）

# 示例：生成Excel后上传（使用base64编码，推荐方式，兼容Docker容器环境）
# 1. 将文件base64编码并写入参数文件
node -e "const fs=require('fs');const b64=fs.readFileSync('/path/to/report.xlsx').toString('base64');fs.writeFileSync('params.json',JSON.stringify({fileName:'report.xlsx',fileContent:b64}))"
# 2. 调用上传
node {baseDir}/scripts/call_informat.js _wb_upload_file --threadId <threadId> --file params.json
# 返回 { "downloadUrl": "https://...", "fileName": "report.xlsx" }
# 3. 将 downloadUrl 提供给用户

完整应用编排 — 意图识别 + 需求对齐 + 蓝图

收到请求先做意图分析，区分两类，不要把所有需求都当完整应用：

• 单点操作（加一张表 / 查数据 / 改字段 / 建一个自动化等明确单一动作）→ 直接走下方「操作前必须先查询」对应小节，不触发本流程。
• 网站 / 前端应用（用户说「做一个网站 / 官网 / 门户 / 前端页面 / Vue 应用 / H5」等，以页面体验为主）→ 优先用 _codestudio_*（AICodeStudio，完整 Vue3 项目），先按「网站资源-Website(设计器)」里的 AICodeStudio 指引查询/创建模块、读 informat.codestudio.md、写 Vue、编译、预览；仅纯静态展示页才考虑 _website_*。这类需求不默认套用“数据表+仪表盘+工作流”三件套，除非用户明确要同时建设后台业务应用。
• 完整应用 / 系统（用户说「做一个 XX 系统 / 管理平台 / 应用」，无论是否列出部分模块）→ 进入完整应用流程；用户已列出的模块只作为初始需求输入，仍须先对齐蓝图，不直接开建：

铁律：

1. 先对齐再行动：先问清业务领域/核心对象/角色/关键流程/统计诉求 → 完整应用默认只规划三类必备组件：数据表、仪表盘、1 个核心工作流；自动化/脚本/API/监听器/定时任务等只在用户明确确认有必要时作为可选扩展纳入 → 产出蓝图前先把本次涉及的模块设计文档读了（必备：表→informat.table.md、仪表盘→informat.dashboard.uipreset.md、工作流→informat.bpmn.md；可选组件按确认结果再读对应文档），蓝图里的表结构/卡片类型/流程节点/字段选型必须基于这些文档的真实预设，严禁凭训练印象自创（典型反面：仪表盘写「数字卡片+进度条」「饼图+数字」这种文档里没有的自造描述——真实卡片类型只有 Number/ProChart/Record/Pivot/Table 五种）→ 产出结构化蓝图（每张卡片注明 类型+尺寸+所在行+主题）→ 等用户显式确认，未确认前不建任何东西。
2. 联动铁律 + 绑定规划：仪表盘/工作流以及被确认的可选自动化/脚本/API/监听器/定时任务，每个都须写明「服务于哪张表或流程、为何存在、如何串联」，说不清者剔除。蓝图须包含一张「绑定规划表」：逐条写明工作流或可选自动化绑定到哪张表的哪个按钮（工具栏/表单/查找列表·关联列表行内按钮 _subtable_create_tool_bar_btn）或哪个监听器/定时任务——已创建但未绑定触发入口的动作组件，用户无法触达，等同无效配置。监听器/定时任务为可选扩展，需求对齐时可主动询问一次，确有意义且用户确认后才创建。
3. 固化三步（顺序固定）：用户确认蓝图后，依次——①先用 _plan_set 登记蓝图契约（默认只登记必备三类：call_informat.js _plan_set --appId <id> --threadId <threadId> '{"targets":{"table":N,"dashboard":N,"workflow":1}}'；若用户确认了可选组件，再追加 automatic/script/api/listener/schedule 对应数量；dashboard 按卡片张数计；不要自行写盘，脚本会写入会话稳定位置）；②读齐 targets 涉及的模块设计文档（table→informat.table.md、dashboard→informat.dashboard.uipreset.md、workflow→informat.bpmn.md；可选组件：automatic→informat.automatic.md、script→informat.script.md、api→informat.api.md、listener→informat.listeners.md、schedule→informat.schedule.md），使建模基于已读文档；③按下方执行顺序逐项建造并通过 _app_check_setting 自检。
4. 执行顺序：应用→主数据表（人员/部门/客户等真实实体，非字典）→复杂表（引真实 fieldId）→工作流（多节点+分支，完整应用必建 1 个核心流程，按钮在此才被真正创建）→仪表盘→已确认的可选扩展→_app_check_setting 自检→提示用户发布应用。
5. 收尾闸门：_app_check_setting 会按 plan.json 核对各类实建数（脚本自动计数），未达标将 exit 7 拦回，须补齐缺口方可收尾——不得完成主要部分后即提前收尾。
6. 维护进度文件：开工先 cat informat_progress/<appId>.md 续接，每完成一步重写它（仅存 已完成摘要/下一步/关键ID，有界不无限追加）。跨对话靠它快速恢复。
7. 收尾须通过发布健康检查：调用 _app_check_setting 若返回任何问题项（如「应用模块 Ref 中不存在…」），脚本将 exit 9 拦回。这些问题意味着表/模块未真正挂入应用、发布必然失败，须逐项修复（缺失模块重新创建、冲突改名）后重新自检至返回空清单，方可向用户报告完成。严禁在存在未修复问题时收尾或虚报「建设完成」。

建造类调用必须串行 —— 禁止并行（极重要）

创建/保存/编辑/删除 这类「写应用结构」的调用（建表 _create_table_module、建字段、建仪表盘卡片 _save_dashboard_*、建工作流节点/连线 _bpmn_*、_automatic_save_define、_api_create_define、_save_informat_script 等）必须逐个串行执行，严禁使用 & / 后台 / 并行方式同时发起多个。

原因：每个这类调用在后端均为「读取整个应用模块树 → 加入自身 → 整树存回」。并行执行多个会相互覆盖，导致表/模块已创建却未挂入应用模块树（左栏不可见、发布报 refNotFound）。实际事故：一次 for f in …; do node … & done; wait 并发创建 8 张表，结果仅 2 张成功留存。

铁律：一次只发起一个写调用，待其返回后再发起下一个。需创建大量表/卡片时应顺序循环执行，不使用 &。（脚本侧已加串行锁作为兜底，但仍不应主动并行——并行只会排队等待、徒增耗时。）

操作前必须先查询 — 最重要的规则

执行任何创建或修改操作前，必须先查询系统现有结构，获取真实ID。严禁凭空构造任何ID或字段名。

查询不能只查列表就够了，必须进一步查询每张相关表的完整字段结构。因为创建关联字段时需要目标表的字段ID，仅知道表ID是不够的。

创建应用前

1. _company_app_list          -> 获取现有所有的应用 包括应用标识符唯一

创建数据表前

1. _query_table_list_designer          -> 获取现有所有数据表及其ID
2. 对每张可能被关联的表分别调用
   _query_table_define_designer        -> 获取该表的完整字段列表（字段ID、字段类型、选项值等）
   这一步不能省略，因为关联字段需要目标表的字段ID
3. cat {baseDir}/references/system_create_table_module.json  -> 阅读参数文档
4. 用查询到的真实表ID和字段ID构造参数，创建新表

为什么必须查每张表的字段结构：

• RelationRecord 字段需要 tableId（目标表ID）和 nameFieldId（目标表中用于显示的字段ID）
• RelationRecordField 字段需要 fieldId（本表外键字段ID）、targetTableId、targetFieldId
• LookupList 字段需要子表ID和子表中外键字段的ID
• LookupRollup 字段需要子表ID和子表中的聚合字段ID
• 这些ID只有通过 _query_table_define_designer 查询才能获得

默认建表选型铁律（详见 informat.table.md 顶部，建表文档闸门会要求阅读）：

• 状态/类型/优先级等固定选项用 ListSelect 单选/多选，不建字典表 + 文本字段。
• 关联按语义三选一：关联记录(N:1)/关联列表(M:N)/查找列表(1:N)，不应通篇只用关联记录。
• 关联记录/关联列表/查找列表均须设置要显示的展示字段（不限于主显示列）。
• 业务表字段须充分（编号+名称+基础信息+状态+关键日期+人员+关联+金额/数量+备注+附件），不应仅以三五个字段草草建成。

创建仪表盘卡片前

1. _query_table_list_designer          -> 获取所有表ID
2. 对目标数据源表调用
   _query_table_define_designer        -> 获取该表所有字段ID和字段类型
   不查字段结构就无法正确配置聚合字段、分组字段、筛选条件
3. _read_informat_dashboard_document   -> 获取仪表盘文档
4. _read_informat_dashboard_ui_preset  -> 获取UI预设方案（用户未明确指定样式时必须按预设填充cardStyle；
   同一仪表盘内所有卡片用同一套主题色板；创建多张卡片前先按6套布局模板选定一套再分配尺寸）
5. 按卡片类型阅读对应参数文档：
   cat {baseDir}/references/system_save_dashboard_prochart_card.json  (图表)
   或 system_save_dashboard_number_card.json  (数字)
   或 system_save_dashboard_record_card.json  (数据表)
   或 system_save_dashboard_pivot_card.json   (透视表)
   或 system_save_dashboard_table_card.json   (表格)
6. 用查询到的真实字段ID构造卡片参数
7. 仪表盘卡片一定要发布后测试一下，确认用户端真实展示不空白、不错位、不卡在暂无数据占位

创建自动化前

1. _query_app_define_designer          -> 获取模块列表、已有自动化分组
2. _query_table_list_designer          -> 获取所有表ID
3. 对自动化涉及的每张表分别调用
   _query_table_define_designer        -> 获取字段ID（自动化步骤中的字段映射、筛选条件都需要真实字段ID）
4. _automatic_doc                      -> 获取自动化文档
5. cat {baseDir}/references/system_automatic_save_define.json  -> 阅读参数文档
6. 用查询到的真实ID构造自动化步骤

创建工作流前

1. cat references/doc/markdown/informat.bpmn.md -> 工作流设计文档（必读，调 _bpmn_* 会被 doc 闸门要求）
2. _query_app_define_designer -> 获取模块列表
3. _query_table_list_designer + _query_table_define_designer -> 获取表和字段
4. _read_informat_expression_doc -> 获取表达式文档（审批人/流转条件都是表达式）
5. 阅读对应的参数文档
6. 按顺序创建：模块 -> 流程定义 -> 启动配置 -> _bpmn_query_process_define 取 StartEvent id -> 多个审批节点(配齐表单字段+同意/驳回按钮+x/y) -> 流转线(分支用同源多条带条件线+一条默认线) -> 绑主表发起按钮
   工作流必须多节点、有分支、连线齐全、绑到表，不能只建一个节点

创建脚本前

1. _query_informat_script_list -> 获取已有脚本和目录
2. _read_informat_script_sdk -> 获取脚本SDK文档
3. 【强制】调用任何 informat.<模块>.* 前，必须 Read {baseDir}/references/doc/markdown/script/<模块>.md（如 table.md、bpmn.md、http.md）核对准确签名（参数个数/顺序/位置）——禁止凭记忆；保存时 call_informat.js 会校验未读则 exit 5 拦回。常见错：informat.table.queryList 是 (tableId, query) 不是把 tableId 塞进 query；update 是 (tableId, data) 两参、id 放 data 里
4. 先用 _create_informat_script_directory 按职能建目录（api/service/utils/mapper 等），脚本按职责分文件放入对应目录——禁止将所有函数集中于一个 js 文件
5. 阅读 cat {baseDir}/references/system_save_informat_script.json
6. 创建或编辑脚本（编辑时必须传已有的脚本ID，不能重复创建）

编辑字段前

1. _query_table_list_designer -> 找到目标表
2. _query_table_define_designer -> 获取该表完整字段列表
3. _read_informat_expression_doc -> 如需配置表达式
4. 阅读 cat {baseDir}/references/system_edit_table_field.json
5. 用真实的tableId和fieldId操作

操作数据记录前

1. _query_all_table_list -> 获取已发布的表ID
2. _query_table_define -> 获取已发布的字段结构
3. 阅读对应参数文档
4. 用真实字段ID构造记录数据

工作台智能体方法列表

团队智能体方法列表

应用智能体方法列表

[应用设计端] = 草稿环境。[用户端] = 已发布环境。

API(设计器)

应用-App(设计器)

数据表-Table(设计器)

工作流-Bpmn(设计器)

自动化流程-Automatic(设计器)

仪表盘-Dashboard(设计器)

脚本-Script(设计器)

定时任务-Schedule(设计器)

国际化-I18n(设计器)

网站资源-Website(设计器)

前端/网站选择指引： 需要交互式、组件化、带路由/状态/图表的复杂前端 → 优先用 _codestudio_*（AICodeStudio，完整 Vue3 项目）；仅纯静态展示页才用 _website_*。同一需求二选一，不要混用。

★ 建模块前先查： 调 _codestudio_create_module 之前必须先调 _codestudio_list_modules 看当前应用有没有现成、用途相符的 AICodeStudio 模块——有就复用它的 moduleId，不要在同一应用里重复建模块。

★★ 用 codestudio 建应用前，必须先完整读一遍 references/doc/markdown/informat.codestudio.md（全流程手册：建模块→查表→建脚本→建API→写Vue→编译→预览，含脚本签名/错误信封/requestApi 解包/文件写入边界/npm 白名单等所有踩坑点）。不读直接调 _codestudio_* 几乎必翻车。

★ codestudio 数据对接铁律： codestudio 模块要读写平台表数据时，脚本/API 必须用 _codestudio_create_script / _codestudio_create_api（后端自动套 ai_{moduleId}_ / ai/{moduleId}/ 前缀 + 收进分组，且同名脚本/同路径 API 会更新原资源），禁止用裸的 _save_informat_script / _api_create_define，也禁止用 xxx2/list2 绕开重复——否则资源不会归属到模块或造成重复污染。前端 requestApi({ path, ... }) 使用 _codestudio_create_api 返回的完整 path。

AI助手(设计器)

监听器-AppListener(设计器)

问卷调查-Survey(设计器)

应用-App(用户端)

数据表-Table(用户端)

工作流-Bpmn(用户端)

搜索引擎-Textindex(用户端)

知识库-Knowledgebase(用户端)

通知-Notification(用户端)

公共智能体方法列表

以下方法无需 --appId，直接调用即可。

注意：_send_notification（发送通知）和 _read_informat_dashboard_document（仪表盘文档）属于应用智能体方法，必须带 --appId 调用。

本地参考文档

无需调用接口，直接查阅 {baseDir}/references/doc/ 目录：

核心功能文档（doc/markdown/ 目录）：

脚本API文档（doc/markdown/script/ 目录）：按模块分类（bpmn.md、table.md、http.md等），包含方法说明、参数定义、示例代码。

常见问题

Q: 应用模块标识符已存在？ 该模块ID已被使用，需要换一个。

Q: 如何获取应用的模块列表？ 使用_query_app_define_designer。

Q: 应用的访问地址？ {host}/app/{appId}