Apriso 开发人员 AI 工具架构总览Apriso Developer AI Tools Architecture Overview
面向 DELMIA Apriso 实施工程师的 AI 辅助开发体系 —— 涵盖 AI Dev Assistant、MCP 工具、AI Agent 与 Apriso 数据库的分层架构与调用关系。AI-assisted development system for DELMIA Apriso implementation engineers — covering the layered architecture and invocation relationships among AI Dev Assistant, MCP Tools, AI Agent, and the Apriso database.
整体架构总览Architecture Overview
本系统是围绕 DELMIA Apriso Process Builder 的 AI 辅助开发工具体系,采用四层分层 + 进程隔离架构。核心设计原则:AI 内核沉到本地后端进程(IIS 托管的 MCP 站点),PB 桌面客户端插件仅承担 UI 与上下文抓取,进程隔离避免 PB 崩溃拖垮 AI、PB 升级影响 Agent。This system is an AI-assisted development tool built around DELMIA Apriso Process Builder, adopting a four-layer architecture with process isolation. Core design principle: the AI kernel resides in a local backend process (IIS-hosted MCP site); the PB desktop client plugin handles only UI and context capture. Process isolation prevents PB crashes from taking down AI, and PB upgrades from affecting the Agent.
flowchart TB
subgraph ENTRY["User Entry Layer"]
PB["PB Desktop Plugin
AI Dev Assistant Panel"]
EXT["External MCP Client
Claude / Cline / VS Code"]
end
subgraph AGENT["AI Agent Layer"]
AIPANEL["AI Dev Assistant
Context Tracking + Function Selection"]
CHAT["ChatClient
MCP JSON-RPC / SSE"]
MEM["DevAiMemory
Keyword + Semantic Hybrid Retrieval"]
end
subgraph MCP["MCP Tool Layer (IIS / net48 / Stateless)"]
HOST["McpHttpHandler
POST/SSE · Auth · Reflection Registry"]
TOOLS["49+ MCP Tools
5 Tool Groups"]
CFG["McpConfig · ConnectionFactory
Web.config Flat Config"]
end
subgraph DB["Apriso Database Layer"]
SA["Solution Authoring DB
Oracle / SQL Server"]
TABLES["SF_SCREEN · DFC · FUNCTION_
SF_VIEW · SF_VIEW_FORM_CONTROL etc."]
end
PB --> AIPANEL
EXT -->|"POST JSON-RPC"| HOST
AIPANEL --> CHAT
CHAT -->|"localhost HTTP/SSE"| HOST
HOST --> TOOLS
TOOLS --> CFG
CFG -->|"Direct SQL Dual-Dialect"| SA
SA --> TABLES
style ENTRY fill:#eef1f5,stroke:#4f46e5,color:#1a1a2e
style AGENT fill:#fdf2f8,stroke:#db2777,color:#1a1a2e
style MCP fill:#ecfeff,stroke:#0891b2,color:#1a1a2e
style DB fill:#fffbeb,stroke:#b45309,color:#1a1a2e
AI 内核不在 PB 桌面客户端插件进程内运行。插件通过 localhost HTTP 调用 MCP 站点(IIS 托管),后端进程独立于 PB 客户端生命周期。PB 崩溃不影响 AI 会话,PB 升级不影响 Agent。未来若扩展为远程服务,插件仅改通信地址即可对接。The AI kernel does not run inside the PB desktop plugin process. The plugin calls the MCP site (IIS-hosted) via localhost HTTP; the backend process is independent of the PB client lifecycle. PB crashes do not affect AI sessions; PB upgrades do not affect the Agent. To extend to a remote service in the future, only the communication address needs updating.
用户入口层User Entry Layer
两类用户入口,覆盖从日常开发到自动化集成的全场景:Two user entry points covering all scenarios from daily development to automated integration:
PB 桌面客户端插件PB Desktop Client Plugin
DLL · net48- 编译为 ClassLibrary DLL,挂载为 PB 原生插件,随 PB 客户端启动加载Compiled as a ClassLibrary DLL, loaded as a native PB plugin on client startup
- 通过 WorkbenchPlugin 注册机制加载,不改 Apriso 程序集Loaded via WorkbenchPlugin registration mechanism; no Apriso assemblies modified
- 右键菜单 / View 菜单触发,侧边面板停靠Triggered via context menu / View menu; side panel docking
- AI Dev Assistant 作为其中一个插件入口,提供上下文抓取与对话面板AI Dev Assistant is one plugin entry, providing context capture and chat panel
- 其他工具入口:Deep Copy/Delete/Move、EntityViewer、FlexpartManager 等Other entries: Deep Copy/Delete/Move, EntityViewer, FlexpartManager, etc.
外部 MCP 客户端External MCP Client
HTTP/SSE- 经 Streamable HTTP 协议(stateless)接入 MCP 站点Connects to the MCP site via Streamable HTTP protocol (stateless)
- POST JSON-RPC 请求,SSE 流式响应POST JSON-RPC requests; SSE streaming responses
- 支持 MCP-Api-Key / Bearer Token 鉴权Supports MCP-Api-Key / Bearer Token authentication
- 可调用全部 49+ 工具,适用于自动化场景Can invoke all 49+ tools; suitable for automation scenarios
AI Agent 层AI Agent Layer
AI Dev Assistant 是 PB 桌面客户端插件内的侧边面板,负责上下文抓取、对话发起与记忆管理。当前处于 PoC 验证阶段(回显链路已贯通,待接入真实 LLM)。AI Dev Assistant is a side panel within the PB desktop client plugin, responsible for context capture, conversation initiation, and memory management. Currently in PoC validation phase (echo loop confirmed; real LLM integration pending).
架构组成Architecture Components
AI Dev Assistant 面板AI Dev Assistant Panel
- Properties 风格可折叠侧边面板,上下文栏 + 函数芯片 + 聊天区 + 输入区Properties-style collapsible side panel: context bar + function chips + chat area + input area
- ContextTracker:订阅 Workbench SelectionChanged / ActiveWindowChanged 事件 + 1.5s 定时轮询回退ContextTracker: subscribes to Workbench SelectionChanged / ActiveWindowChanged events + 1.5s polling fallback
- ContextProbe:反射探针,抓取当前 Screen / DFC / View、选中函数、打开实体列表ContextProbe: reflection probe capturing current Screen / DFC / View, selected function, open entity list
- 跨 PB 版本兼容的反射辅助(GetProperty / InvokeGenericGet / FindType)Cross-PB-version reflection helpers (GetProperty / InvokeGenericGet / FindType)
MCP 聊天客户端MCP Chat Client
- Stateless Streamable HTTP JSON-RPC 客户端Stateless Streamable HTTP JSON-RPC client
- initialize -> notifications/initialized -> tools/call 三步握手initialize -> notifications/initialized -> tools/call three-step handshake
- 载荷:{ message, contextJson, selectedFunctionJson, sessionKey }Payload: { message, contextJson, selectedFunctionJson, sessionKey }
- SSE data: 行解析 result.content[].textSSE data: line parsing of result.content[].text
- 全程 try/catch,失败返回友好错误文本Full try/catch; returns friendly error text on failure
DevAiMemory 记忆体系(规划中)DevAiMemory System (Planned)
- 权威主存储:Apriso 服务端 DevAiMemory 实体Authoritative store: Apriso server-side DevAiMemory entity
- 记忆维度:项目名 + 模块类型 + 问题类型 + 开发人员 + Apriso 版本 + PB 版本Memory dimensions: project + module type + question type + developer + Apriso version + PB version
- 混合检索:关键词层(索引精确过滤)+ 语义层(embedding 余弦排序)Hybrid retrieval: keyword layer (exact index filter) + semantic layer (embedding cosine ranking)
- 对话审计:DevAiConversationLog 全量记录,含 Token 消耗与延迟Conversation audit: DevAiConversationLog full recording incl. token cost and latency
- 离线容错:SQLite 本地缓存(对话历史 + 暂存记忆)Offline fallback: SQLite local cache (conversation history + pending memories)
PoC-1 已验证通过:PB 插件 API 可拿到活动建模项、脚本编辑器内容、公式对象模型等关键上下文,可行性已确认。ai_dev_assistant_chat 工具当前为回显实现,"PB 插件 -> MCP -> 返回"链路已贯通。下一步推进 PoC-2(存储与方言落地)。PoC-1 verified and passed: PB plugin API can access active modeling items, script editor content, formula object models and other key context. Feasibility confirmed. The ai_dev_assistant_chat tool is currently an echo implementation; the "PB Plugin -> MCP -> Return" loop is operational. Next step: PoC-2 (storage and dialect implementation).
MCP 工具层MCP Tool Layer
MCP 站点部署为 IIS 集成模式 Web 应用(/apriso-mcp 路由),采用 Stateless Streamable HTTP 协议:每个 POST 请求独立创建 transport + server,处理完即销毁。工具方法通过 [McpServerTool] 特性标注 + 反射自动注册,新增工具类无需改注册代码。The MCP site is deployed as an IIS integrated-mode web application (route /apriso-mcp) using the Stateless Streamable HTTP protocol: each POST request creates an independent transport + server, destroyed after processing. Tool methods are annotated with [McpServerTool] and auto-registered via reflection; adding new tool classes requires no registration code changes.
MCP 宿主架构MCP Host Architecture
flowchart LR
CLIENT["MCP Client"] -->|"POST JSON-RPC
Mcp-Api-Key"| HANDLER["McpHttpHandler
Auth · CORS · Protocol Version Check"]
HANDLER -->|"Stateless"| TRANSPORT["StreamableHttpServerTransport"]
TRANSPORT --> SERVER["McpServer.Create"]
SERVER --> OPTIONS["JsonRpcServerOptionsProvider
Process-level read-only options"]
OPTIONS -->|"Reflection scan"| TOOLS["ToolCollection
49+ [McpServerTool]"]
TOOLS --> RESULT["McpToolResult
Unified DTO Wrapper"]
RESULT -->|"SSE text/event-stream"| CLIENT
style CLIENT fill:#eef1f5,stroke:#4f46e5,color:#1a1a2e
style HANDLER fill:#ecfeff,stroke:#0891b2,color:#1a1a2e
style OPTIONS fill:#ecfeff,stroke:#0891b2,color:#1a1a2e
style TOOLS fill:#ecfeff,stroke:#0891b2,color:#1a1a2e
五大工具群组Five Tool Groups
Deep 复制 / 删除 / 移动Deep Copy / Delete / Move
17 toolsdeep_copy_screen/view/dfc(with _preview)deep_delete_screen/view/dfc(with _preview)deep_move_preview · deep_move(EntityManager move)get_modules · get_project_revisions · get_revision_module
DFC 函数与 Step 创作DFC Function & Step Creation
10 toolscreate_step · create_branch_stepcreate_sqlquery · create_table_bc · create_user_formulacreate_input_to_output · create_sub_dfccreate_stored_procedure · show_message · web_service
Screen / View / DFC 内容与列参数Screen / View / DFC Content & Column Parameters
15 toolsconfig / interface / create_grid_screenget/update_entity_content(DFC / View / Screen)add / modify / delete_column(with _preview)
SQL 查询与状态更新SQL Query & Status Update
6 toolsexecute_sql_query(read-only SELECT/WITH, dual-dialect)get_dfc_functions(query all DFC function contents)get_revision_statusesupdate_screen/view/dfc_status
AI Dev Assistant 会话AI Dev Assistant Session
1 toolai_dev_assistant_chat(echo validation; LLM pending)- 入参:message + contextJson + selectedFunctionJson + sessionKeyInput: message + contextJson + selectedFunctionJson + sessionKey
- 出参:echo + context + selectedFunction + noteOutput: echo + context + selectedFunction + note
所有工具方法以 McpToolResult.Run() 包裹,返回 { success, durationMs, data, error, errorDetail }。错误不抛给 SDK 而以 success:false 回传,AI 客户端可直接阅读 JSON。完整堆栈仅写服务端日志,避免向客户端泄露 SQL / 内部路径。All tool methods are wrapped with McpToolResult.Run(), returning { success, durationMs, data, error, errorDetail }. Errors are returned as success:false rather than thrown to the SDK; the AI client can directly read the JSON. Full stack traces are written only to server-side logs, preventing SQL / internal paths from leaking to the client.
基础设施Infrastructure
ConnectionFactory
- 为单次工具调用创建独立 IDbExecutor,用完即弃Creates an independent IDbExecutor per tool call; disposed after use
- 连接串来自 Web.config 扁平配置Connection string from Web.config flat configuration
- 完全脱离 Apriso DataServices 加密链路Fully decoupled from Apriso DataServices encrypted config chain
双方言适配Dual-Dialect Adaptation
ISqlDialect:抽象接口(LimitRows / 参数前缀 / 分页): abstract interface (LimitRows / param prefix / pagination)- Oracle 参数 '@param' -> ':param',ParameterName 去 '@'Oracle param '@param' -> ':param'; ParameterName trimmed of '@'
- SQL 参数重写 regex 避免匹配 dblinkSQL param rewrite regex avoids matching dblinks
- 统一用 IsOracle 标志(非 IsSqlServer)Uses IsOracle flag (not IsSqlServer)
认证与安全Authentication & Security
- 支持 Mcp-Api-Key 请求头 或 Bearer TokenSupports Mcp-Api-Key header or Bearer Token
- 固定时间 SHA256 比较,防时序攻击Constant-time SHA256 comparison; prevents timing attacks
- CORS 预检(OPTIONS)不校验密钥CORS preflight (OPTIONS) skips key validation
- GET/DELETE 返回 405(stateless 不支持)GET/DELETE returns 405 (not supported in stateless mode)
Apriso 数据库层Apriso Database Layer
系统直连 Apriso Solution Authoring 库(当前 Oracle,支持 SQL Server),操作创作期元数据表。数据库连接串由 Web.config 扁平配置提供,不走 Apriso 加密配置链路。MCP 工具经 ADO.NET 双方言直连,不依赖 Apriso 运行时 API。The system connects directly to the Apriso Solution Authoring database (currently Oracle; SQL Server supported), operating on authoring-time metadata tables. Connection strings are provided by Web.config flat configuration, bypassing the Apriso encrypted config chain. MCP tools connect via ADO.NET dual-dialect, without depending on Apriso runtime APIs.
核心表与层级关系Core Tables & Hierarchy
erDiagram
SF_SCREEN ||--o{ SF_SCREEN_REVISION : "1:N"
SF_SCREEN_REVISION ||--o{ SF_SCREEN_REVISION_LINK : "1:N"
SF_SCREEN_REVISION ||--o{ SF_VIEW : "1:N"
SF_VIEW ||--o{ SF_VIEW_REVISION : "1:N"
SF_VIEW_REVISION ||--o{ SF_VIEW_FORM : "1:1"
SF_VIEW_FORM ||--o{ SF_VIEW_FORM_CONTROL : "1:N"
SF_VIEW_REVISION ||--o{ SF_VIEW_ACTION : "1:N"
SF_SCREEN ||--o{ SF_SCREEN_PANEL : "1:N"
SF_SCREEN_PANEL ||--o{ SF_SCREEN_PANEL_ACTION : "1:N"
DFC ||--|{ DFC_REVISION : "1:N"
DFC_REVISION ||--|{ DFC_REVISION_LINK : "1:N"
DFC_REVISION ||--|{ DFC_STEP : "1:N"
DFC_STEP ||--|{ DFC_STEP_FUNCTION : "1:N"
DFC_STEP_FUNCTION ||--|| FUNCTION_ : "1:1"
FUNCTION_ ||--o{ FUNCTION_INPUT : "1:N"
FUNCTION_ ||--o{ FUNCTION_OUTPUT : "1:N"
FUNCTION_OUTPUT ||--o{ FUNCTION_OUTPUT_ROUTING : "1:N"
BUSINESS_OBJECT ||--o| SF_SCREEN : "SFScreenID"
BUSINESS_OBJECT ||--o| SF_SCREEN_REVISION : "SFScreenRevisionID"
关键表说明Key Table Description
| 表名Table | 用途Purpose | AI 工具操作AI Tool Operation |
|---|---|---|
| SF_SCREEN | 屏幕定义(Name, ID, Active)Screen definition | Deep Copy/Delete/Move 根实体Deep Copy/Delete/Move root entity |
| SF_SCREEN_REVISION | 屏幕修订(IsDefaultRevision)Screen revision | 修订状态查询/更新Revision status query/update |
| SF_VIEW / SF_VIEW_REVISION | 视图定义与修订View definition & revision | Deep Copy 子树遍历Deep Copy subtree traversal |
| SF_VIEW_FORM_CONTROL | 表单控件(Grid/Button/Input)Form controls | 列参数管理、控件克隆Column param management, control cloning |
| DFC / DFC_REVISION / DFC_STEP | DFC 流程定义与步骤DFC process definition & steps | DFC Step 创建、Deep CopyDFC Step creation, Deep Copy |
| DFC_STEP_FUNCTION / FUNCTION_ | 步骤函数(FunctionType=28 为 ScreenInterface)Step functions (FunctionType=28 = ScreenInterface) | 函数内容读写、HTML 抽取Function content read/write, HTML extraction |
| FUNCTION_INPUT / OUTPUT | 函数输入输出参数Function I/O parameters | 列参数管理Column param management |
| SF_SCREEN_PANEL_ACTION | 面板按钮动作(含 TargetScreenID)Panel button actions | 删除时需先 nullify 依赖列Must nullify dependent columns before delete |
| TEXT_TRANSLATION | 多语言翻译(LanguageID=2052 中文)Multilingual translations | 字段翻译、术语表Field translation, glossary |
| PROJECT / PROJECT_REVISION | 项目与修订(EntityManager = null)Project & revision (EntityManager = null) | Deep Move 作用域判定Deep Move scope determination |
Oracle 严格强制参照完整性。删除 SF_SCREEN 记录时,必须先将依赖列置 NULL(SF_VIEW_ACTION.TargetScreenID / TargetScreenRevisionID、SF_SCREEN_PANEL_ACTION.NextScreenID / NextScreenRevisionID),否则报 ORA-02292。SQL Server 的级联删除策略不同,需注意双方言差异。Oracle enforces referential integrity strictly. When deleting SF_SCREEN records, dependent columns must first be set to NULL (SF_VIEW_ACTION.TargetScreenID / TargetScreenRevisionID, SF_SCREEN_PANEL_ACTION.NextScreenID / NextScreenRevisionID), or ORA-02292 will occur. SQL Server cascade-delete strategy differs; beware of dual-dialect divergence.
调用关系详解Invocation Flow
主调用链:用户操作到数据库Main Call Chain: User Action to Database
sequenceDiagram
actor U as User
participant PB as PB Plugin
participant AI as AI Dev Assistant
participant MCP as MCP Server
participant DB as Apriso DB
Note over U,DB: Scenario A: AI Chat
U->>PB: Open AI Dev Assistant panel
PB->>AI: Auto-capture entity context + selected function
U->>AI: Type message (auto-attach context)
AI->>MCP: POST tools/call ai_dev_assistant_chat
MCP->>DB: Query context entities (optional)
DB-->>MCP: Entity data
MCP-->>AI: SSE streaming response
AI-->>U: Render reply + context summary
Note over U,DB: Scenario B: External MCP client - Deep Copy Preview
U->>MCP: POST tools/call deep_copy_screen_preview
MCP->>DB: SELECT SF_SCREEN + DFC + FUNCTION_
DB-->>MCP: Entity tree data
MCP-->>U: SSE JSON response (preview rows)
Note over U,DB: Scenario C: External MCP client - SQL Query
U->>MCP: POST tools/call execute_sql_query
MCP->>DB: SELECT (dual-dialect)
DB-->>MCP: DataSet
MCP-->>U: SSE JSON response
调用关系矩阵Invocation Matrix
| 调用方Caller | 被调用方Callee | 调用方式Method | 说明Notes |
|---|---|---|---|
| PB 桌面客户端插件PB Desktop Plugin | AI Dev Assistant 面板AI Dev Assistant Panel | 进程内直接引用In-process direct reference | 插件加载时初始化面板,订阅 Workbench 事件Panel initialized on plugin load; subscribes to Workbench events |
| AI Dev Assistant 面板AI Dev Assistant Panel | MCP 站点MCP Site | localhost HTTP (JSON-RPC/SSE) | ai_dev_assistant_chat 工具调用ai_dev_assistant_chat tool call |
| 外部 MCP 客户端External MCP Client | MCP 站点MCP Site | HTTP POST (Streamable HTTP) | 全部 49+ 工具可调用All 49+ tools callable |
| MCP 工具方法MCP Tool Method | ConnectionFactory | 静态方法调用Static method call | CreateExecutor() -> IDbExecutorCreateExecutor() -> IDbExecutor |
| ConnectionFactory | Apriso Authoring 库Apriso Authoring DB | ADO.NET 直连ADO.NET direct connection | Oracle.ManagedDataAccess / System.Data.SqlClient |
MCP 工具 -> 数据库 调用链MCP Tool -> Database Call Chain
上下文颗粒度设计:核心挑战Context Granularity Design: Core Challenge
把 Apriso 中的原子化操作提炼成 MCP 工具供 AI Agent 调度,最大的困难不在工具本身,而在返回给 AI Agent 关于 Flexpart / Screen / View / DFC 信息的颗粒度——太粗则 AI 无法理解上下文、无法决策;太细则 Token 爆炸、淹没在噪声中。Apriso 实体树天然深且宽(一个 Screen 可挂载数十个 View、上百个 DFC Step Function),这使颗粒度问题尤为突出。The biggest difficulty in distilling Apriso atomic operations into MCP tools for AI Agent orchestration is not the tools themselves, but the granularity of Flexpart / Screen / View / DFC information returned to the AI Agent — too coarse and the AI cannot understand the context or make decisions; too fine and tokens explode, drowning in noise. The Apriso entity tree is naturally deep and wide (a single Screen can carry dozens of Views and hundreds of DFC Step Functions), making this problem especially acute.
Apriso 实体树的深度与广度Depth & Breadth of the Apriso Entity Tree
flowchart TB
FP["Flexpart / Business Object"]
FP --> SCR["Screen"]
SCR --> SCREV["Screen Revision"]
SCREV -->|"1:N"| VW["View"]
VW --> VWREV["View Revision"]
VWREV --> VFC["View Form Control xN
Grid / Button / Input / Label"]
VWREV --> VACT["View Action xN
with TargetScreenID jump"]
SCREV --> SP["Screen Panel xN"]
SP --> SPA["Panel Action xN
with NextScreenID jump"]
FP --> DFC["DFC"]
DFC --> DFCREV["DFC Revision"]
DFCREV --> DSTEP["DFC Step xN"]
DSTEP --> DSTF["DFC Step Function xN"]
DSTF --> FN["Function_ (1:1)"]
FN --> FNIN["Function Input xN"]
FN --> FNOUT["Function Output xN"]
FNOUT --> FNROUT["Output Routing xN"]
style FP fill:#eef1f5,stroke:#4f46e5,color:#1a1a2e
style SCR fill:#ffffff,stroke:#0891b2,color:#1a1a2e
style DFC fill:#ffffff,stroke:#059669,color:#1a1a2e
style FN fill:#eef1f5,stroke:#b45309,color:#1a1a2e
以一个典型的收货 Screen(如 EIL.WMS.RMO.Receive.Order_V3)为例,其实体树可能包含:Taking a typical receiving Screen (e.g., EIL.WMS.RMO.Receive.Order_V3), its entity tree may contain:
- 1 个 Screen + 1 个 Screen Revision1 Screen + 1 Screen Revision
- 3-5 个 View(含弹窗子 View),每个 View 10-30 个 FormControl3-5 Views (incl. popup sub-Views), each with 10-30 FormControls
- 2-3 个 DFC,每个 DFC 5-15 个 Step,每个 Step 1-3 个 Function2-3 DFCs, each with 5-15 Steps, each Step with 1-3 Functions
- Function 类型多样:C# 脚本 / SQL 查询 / BC 方法调用 / 子 DFC / WebService / 存储过程 / ScreenInterface(HTML)Diverse Function types: C# script / SQL query / BC method call / sub-DFC / WebService / stored procedure / ScreenInterface(HTML)
- ScreenInterface 的 HtmlCode 可达 5000+ 行,JavaScriptCode 2000+ 行ScreenInterface HtmlCode can reach 5000+ lines; JavaScriptCode 2000+ lines
如果一次性返回完整实体树 + 全部函数内容,单次 MCP 工具响应可能超过 100,000+ Token,远超 Claude Code 的 25,000 Token 工具响应上限。If the full entity tree + all function contents are returned at once, a single MCP tool response may exceed 100,000+ tokens, far beyond Claude Code's 25,000-token tool response limit.
业界最佳实践与模式Industry Best Practices & Patterns
调研 MCP 生态中已验证的颗粒度控制模式,以下五种最适用于 Apriso 场景:Investigating granularity control patterns validated in the MCP ecosystem, the following five are most applicable to the Apriso scenario:
渐进式披露(Progressive Disclosure)Progressive Disclosure
推荐Recommended- 第一层工具返回索引/摘要:实体名、类型、ID、子项计数Layer 1 returns index/summary: entity name, type, ID, child count
- 第二层工具按需返回结构树:类型 + 名称,不含内容Layer 2 returns structure tree on demand: type + name, no content
- 第三层工具按需返回具体内容:某个函数的脚本/HTMLLayer 3 returns specific content on demand: a function's script/HTML
- 业界实测可削减 85-95% Token 开销Industry tests show 85-95% token reduction
句柄/指针返回(Handle Pattern)Handle / Pointer Return
推荐Recommended- 返回实体 ID + 名称 + 类型标签,不嵌入内容Return entity ID + name + type label, no content embedded
- AI Agent 用 ID 调后续工具取详情AI Agent uses ID to call follow-up tools for details
- Anthropic 实测一个 150K Token 工作流降至 ~2K Token(98.7% 削减)Anthropic measured a 150K-token workflow dropping to ~2K tokens (98.7% reduction)
- 天然适配 Apriso 的 ID 体系(ScreenID / RevisionID / FunctionId)Naturally fits Apriso's ID system (ScreenID / RevisionID / FunctionId)
自适应详细度(Adaptive Verbosity)Adaptive Verbosity
推荐Recommended- 添加
depth参数:summary | tree | contentAdddepthparameter:summary | tree | content - 添加
maxItems参数:限制数组成员数AddmaxItemsparameter: limit array member count - 添加
fields参数:指定需要返回的字段Addfieldsparameter: specify required fields - IETF ADOL 草案定义了此模式的标准化方案IETF ADOL draft standardizes this pattern
结构化截断(Structured Truncation)Structured Truncation
兜底Fallback- 不粗暴字符截断,而是按结构裁剪Not brute character truncation; structured pruning instead
- 数组只取前 N 项 +
truncated: true+totalCountArray takes first N items +truncated: true+totalCount - 大字段(CLOB)取前 maxChars +
...truncated后缀Large fields (CLOB) take first maxChars +...truncatedsuffix - AI Agent 可根据截断标记决定是否拉取更多AI Agent can decide whether to fetch more based on truncation markers
元工具模式(Meta-Tool Pattern)Meta-Tool Pattern
长期Long-term- Tool 1:
discover—— 返回能力索引(能做什么 + 需要什么参数)— returns capability index (what can be done + required params) - Tool 2:
execute—— 按发现结果执行具体操作— executes specific operation per discovery results - GitHub-Slim 实测 27 -> 7 语义操作,Token 削减 71.5%GitHub-Slim tested: 27 -> 7 semantic operations, 71.5% token reduction
- 适用于工具数继续增长到 100+ 时收拢工具定义开销Suitable when tool count grows to 100+ to contain definition overhead
Apriso 专属颗粒度分层方案Apriso-Specific Granularity Tiers
结合上述模式与 Apriso 实体树特性,建议采用三级颗粒度 + 句柄链接策略:Combining the above patterns with Apriso entity tree characteristics, a three-tier granularity + handle linking strategy is recommended:
| 层级Tier | 命名Name | 返回内容Returns | 适用场景Use Case | 预估 TokenEst. Tokens |
|---|---|---|---|---|
| L0 | Index | 实体名、类型、ID、修订号、子项计数(如 Screen 有 3 Views, 2 DFCs, 28 Functions)Entity name, type, ID, revision, child counts (e.g., Screen has 3 Views, 2 DFCs, 28 Functions) | "这个 Screen 大概有什么?" "项目下有哪些 Flexpart?""What does this Screen contain?" "Which Flexparts exist in this project?" | ~200-500 |
| L1 | Tree | 完整实体树(类型 + 名称 + ID),不含函数内容。Function 行只返回类型标签(C#/SQL/BC/SubDFC/WebService/SP/ScreenInterface)+ 行数统计Full entity tree (type + name + ID), no function content. Function rows return only type label + line count | Deep Copy 预览、架构理解、"这个 DFC 有哪些步骤?"Deep Copy preview, architecture understanding, "Which steps does this DFC have?" | ~2,000-5,000 |
| L2 | Content | 单个函数/控件的完整内容(脚本正文、HTML/JS/CSS、SQL 文本、参数定义)。带 maxChars 截断保护Single function/control full content (script body, HTML/JS/CSS, SQL text, param defs). With maxChars truncation guard |
脚本排错、SQL 优化、"这个 ActionScript 报错怎么修?"Script debugging, SQL optimization, "How to fix this ActionScript error?" | ~1,000-15,000 |
| L3 | Raw | 无截断的原始字段值(仅限 AI 显式请求 raw=true)Untruncated raw field values (only when AI explicitly requests raw=true) |
精确字段值校验、特殊排错Exact field value verification, special debugging | 不限(需告警)Unlimited (with warning) |
默认最省:工具默认返回 L0/L1 级别,L2/L3 必须显式请求。句柄链接:每层返回值都带实体 ID,AI 可用 ID 调下一层工具。截断必有标记:被截断的数据必须带 truncated: true + totalCount + nextOffset,AI 据此决定是否分页拉取。上下文预算:单次响应硬上限 25,000 Token(对齐 Claude Code),超限自动降级到上一层级。Default minimal: tools default to L0/L1; L2/L3 require explicit request. Handle linking: every tier's return values carry entity IDs; AI can call next-tier tools with IDs. Truncation always marked: truncated data must carry truncated: true + totalCount + nextOffset; AI decides whether to paginate. Context budget: single response hard cap 25,000 tokens (aligned with Claude Code); auto-degrade to upper tier on overflow.
示例:AI Agent 查询 Screen 上下文的典型交互Example: AI Agent Querying Screen Context — Typical Interaction
sequenceDiagram
participant AI as AI Agent
participant MCP as MCP Server
participant DB as Apriso DB
Note over AI,DB: Step 1: L0 Index
AI->>MCP: get_entity_index(name="...Order_V3")
MCP->>DB: SELECT Screen + COUNT(DFC) + COUNT(View)...
DB-->>MCP: Aggregate data
MCP-->>AI: { type:"Screen", id:123, views:3, dfcs:2, functions:28, totalFnLines:8500 }
Note over AI,DB: Step 2: L1 Tree
AI->>MCP: get_entity_tree(entityId=123, depth="tree")
MCP->>DB: SELECT entity tree (no function content)
DB-->>MCP: Tree structure
MCP-->>AI: [{ kind:"Screen", name:"..." }, { kind:"DFC", name:"...", children:[{ kind:"Step", functions:[{type:"C#Script", lines:45}, {type:"SQL", lines:12}] }] }, ...]
Note over AI,DB: Step 3: L2 Content
AI->>MCP: get_function_content(functionId=456, maxChars=10000)
MCP->>DB: SELECT FUNCTION_.PropertyValue (parse PropertyBag)
DB-->>MCP: Script body
MCP-->>AI: { type:"C#Script", content:"...", lines:45, truncated:false }
Note over AI,DB: Step 4: L2 Content - ScreenInterface HTML
AI->>MCP: get_screen_interface(names=["...Order_V3"])
MCP->>DB: SELECT FUNCTION_ (FunctionType=28) + parse HtmlScreen
DB-->>MCP: HTML/JS/CSS
MCP-->>AI: { html:"...(truncated, 5000/12000 chars)", js:"...", css:"...", truncated:true }
落地建议:对现有 MCP 工具的改造路径Implementation: Refactoring Path for Existing MCP Tools
新增 L0 索引工具Add L0 Index Tool
get_entity_index:按名称/ID 返回摘要(类型 + 子项计数): returns summary by name/ID (type + child counts)- 查询极轻(几条 COUNT + 主表行),< 5msVery light query (a few COUNTs + main table row), < 5ms
- AI 默认调用此工具"探路"AI calls this tool by default to "scout"
改造现有 _preview 为 L1Refactor _preview to L1
- 现有
deep_copy_screen_preview已返回结构树already returns structure tree - 增加
depth参数,默认treeAdddepthparameter, defaulttree - Function 行增加
fnType+lineCount,不返回脚本内容Function rows addfnType+lineCount, no script content
改造 get_screen_interface 为 L2Refactor get_screen_interface to L2
- 已有
listOnly模式(L1 级别)already haslistOnlymode (L1) - 增加
maxChars截断 +truncated标记AddmaxCharstruncation +truncatedmarker - 增加
fields参数:只返回 html/js/css 中指定段Addfieldsparameter: return only specified html/js/css segments
新增 L2 函数内容工具Add L2 Function Content Tool
get_function_content:按 FunctionId 返回脚本正文: returns script body by FunctionId- 参数:
functionId+maxChars+rawParams:functionId+maxChars+raw - 解析 FUNCTION_.PropertyValue PropertyBag XMLParses FUNCTION_.PropertyValue PropertyBag XML
本方案不需要重构现有工具——deep_copy_*_preview 已天然是 L1 级别(返回结构树),get_screen_interface 已有 listOnly 模式(L0/L1),execute_sql_query 已有 maxRows/maxCellChars 截断。改造主要是增加 depth 参数统一化 + 新增 L0 索引工具add L0 index tool + 新增 L2 函数内容工具add L2 function content tool,不影响现有调用方。This plan does not require refactoring existing tools — deep_copy_*_preview is already L1 (returns structure tree), get_screen_interface already has listOnly mode (L0/L1), execute_sql_query already has maxRows/maxCellChars truncation. The refactoring is mainly unifying the depth parameter + adding L0 index tool + adding L2 function content tool, without affecting existing callers.
AI Agent 编排能力:待解决的核心难题AI Agent Orchestration: Core Challenges to Resolve
我们已部署了 MCP 工具层(49+ 原子化工具)和 AI Dev Assistant 入口,但AI Agent 本身的智能编排层还是空白——任务如何拆解、如何编排执行、遇到变化如何动态重新规划、是否需要子 Agent 分工、失败后如何回退或重试、Agent 的长期记忆如何沉淀与复用——这些编排能力直接决定了 AI 工具体系从"能用"到"好用"的跨越。我们希望 Global 团队能在这些方面提供经验、模式和建议。We have deployed the MCP tool layer (49+ atomic tools) and the AI Dev Assistant entry point, but the intelligence orchestration layer of the AI Agent itself remains a blank — how to decompose tasks, how to orchestrate execution, how to dynamically re-plan upon changes, whether sub-agents should be dispatched, how to roll back or retry on failure, and how agent long-term memory should be distilled and reused. These orchestration capabilities determine the leap from "usable" to "effective." We hope the Global team can share experiences, patterns, and recommendations in these areas.
理想 Agent 编排流程Ideal Agent Orchestration Flow
flowchart TB
USER["User Request
e.g. 'Copy this Screen and modify the DFC'"] --> PLAN["Task Planning
Decompose into sub-tasks"]
PLAN --> ORCH["Task Orchestrator
Sequence / Parallel / Conditional"]
ORCH --> EXEC1["Sub-Task 1
deep_copy_screen_preview"]
ORCH --> EXEC2["Sub-Task 2
get_entity_tree"]
ORCH --> EXEC3["Sub-Task 3
create_step / modify_function"]
EXEC1 --> CHECK{"Success?"}
EXEC2 --> CHECK2{"Success?"}
EXEC3 --> CHECK3{"Success?"}
CHECK -->|"No"| FAIL["Failure Strategy
Retry / Rollback / Escalate"]
CHECK2 -->|"No"| FAIL
CHECK3 -->|"No"| FAIL
CHECK -->|"Yes"| AGG["Result Aggregation"]
CHECK2 -->|"Yes"| AGG
CHECK3 -->|"Yes"| AGG
AGG --> MEM["Memory Update
Store outcome + lessons"]
MEM --> USER2["Response to User
Summary + next steps"]
FAIL -->|"Retry"| ORCH
FAIL -->|"Escalate"| USER2
style USER fill:#eef1f5,stroke:#4f46e5,color:#1a1a2e
style PLAN fill:#fdf2f8,stroke:#db2777,color:#1a1a2e
style ORCH fill:#fdf2f8,stroke:#db2777,color:#1a1a2e
style FAIL fill:#fffbeb,stroke:#b45309,color:#1a1a2e
style MEM fill:#ecfeff,stroke:#0891b2,color:#1a1a2e
上图展示了一个理想的 Agent 编排流程,但目前我们在其中每一个环节都缺乏成熟方案。以下逐一拆解六大挑战领域:The diagram above shows an ideal orchestration flow, but we currently lack mature solutions for every single环节. The six challenge areas are detailed below:
1. 任务拆解1. Task Decomposition
核心Core- 用户说"把这个 Screen 复制到另一个项目并修改 DFC",Agent 需拆解为:查源 Screen -> 查目标项目 -> deep_copy -> get_entity_tree -> modify_function -> update_statusUser says "copy this Screen to another project and modify the DFC"; agent must decompose: query source Screen -> query target project -> deep_copy -> get_entity_tree -> modify_function -> update_status
- 难点:Apriso 操作有隐式依赖(先复制才能改;先查才能改),拆解需理解业务顺序Challenge: Apriso operations have implicit dependencies (copy before modify; query before update); decomposition must understand business ordering
- 问题:拆解策略由 LLM 提示词驱动还是用规则模板?复杂度阈值在哪(超过几步需拆解)?Question: should decomposition be LLM prompt-driven or rule-template-based? What is the complexity threshold (how many steps before decomposition is needed)?
2. 任务编排2. Task Orchestration
核心Core- 独立子任务可并行(如同时查 Screen + DFC),有依赖的必须串行Independent sub-tasks can be parallel (e.g., query Screen + DFC simultaneously); dependent ones must be serial
- 难点:MCP 工具是 stateless 的,每次调用独立——Agent 需自己维护中间状态(如复制后的新 ID)Challenge: MCP tools are stateless, each call independent — the Agent must maintain intermediate state (e.g., new ID after copy)
- 问题:编排引擎用什么?LangGraph / AutoGen / 自研?是否需要 DAG 表达?Question: what orchestration engine? LangGraph / AutoGen / custom? Is DAG representation needed?
3. 动态规划3. Dynamic Planning
高级Advanced- 如 deep_copy 时发现目标项目已存在同名 Screen,需决定:覆盖 / 重命名 / 跳过 / 问用户e.g., during deep_copy, a same-name Screen already exists in target project; must decide: overwrite / rename / skip / ask user
- 难点:Apriso 实体有复杂约束(外键、修订状态、Active 标志),规划需感知这些约束Challenge: Apriso entities have complex constraints (foreign keys, revision status, Active flags); planning must be constraint-aware
- 问题:重新规划的触发条件是什么?允许重新规划几次(防死循环)?需要人工确认的阈值?Question: what triggers re-planning? How many re-plans allowed (prevent infinite loops)? What threshold requires human confirmation?
4. 子 Agent 调度4. Sub-Agent Dispatch
高级Advanced- 可能的子 Agent:ScreenAgent(屏幕专家)、DfcAgent(DFC 流程专家)、SqlAgent(SQL 优化专家)、DebugAgent(排错专家)Possible sub-agents: ScreenAgent, DfcAgent, SqlAgent, DebugAgent
- 难点:子 Agent 间如何传递上下文(一个 Agent 的输出是另一个的输入)?是否共享会话记忆?Challenge: how do sub-agents share context (one's output is another's input)? Do they share session memory?
- 问题:是否真需要子 Agent,还是一个 Agent + 工具选择提示词就够?分工的 ROI 在哪?Question: are sub-agents truly needed, or does one Agent + tool-selection prompt suffice? Where is the ROI of specialization?
5. 失败策略5. Failure Strategy
关键Critical- Apriso 操作有副作用(DB 已写入),失败不能简单重试——需事务补偿Apriso operations have side effects (DB written); failure cannot simply retry — transactional compensation needed
- 难点:MCP 工具是 stateless 的,没有内置事务——deep_copy 半途失败(Screen 创建了但 DFC 没复制完),如何回滚?Challenge: MCP tools are stateless with no built-in transactions — if deep_copy fails midway (Screen created but DFC not copied), how to roll back?
- 问题:是否需要在 MCP 层引入补偿事务(Saga 模式)?还是 Agent 层负责"逆向操作"(deep_delete 清理半成品)?Question: should a compensation transaction (Saga pattern) be introduced at the MCP layer? Or should the Agent layer handle "reverse operations" (deep_delete to clean up partial results)?
- 问题:哪些操作是幂等的可安全重试,哪些不是?分类标准是什么?Question: which operations are idempotent and safe to retry, which are not? What is the classification criteria?
6. Agent 记忆6. Agent Memory
基础Foundation- 短期记忆:当前会话的上下文(已查实体、已执行操作、中间结果),随会话结束消亡Short-term: current session context (entities queried, operations executed, intermediate results); perishes on session end
- 长期记忆:DevAiMemory 实体已规划(项目 + 模块 + 问题类型 + 版本维度),但与 Agent 编排层的记忆如何衔接?Long-term: DevAiMemory entity planned (project + module + question type + version dimensions), but how does it connect with the Agent orchestration layer's memory?
- 难点:编排记忆("上次这个项目复制时遇到过重名问题,用了重命名策略")与领域记忆("这个项目的 Screen 命名规范")是不同维度Challenge: orchestration memory ("last time copying this project, hit a name conflict, used rename strategy") and domain memory ("this project's Screen naming convention") are different dimensions
- 问题:编排记忆应存哪?Agent 侧还是 DevAiMemory?格式是自然语言摘要还是结构化?Question: where should orchestration memory be stored? Agent-side or DevAiMemory? Format: natural language summary or structured?
业界主流方案对比Industry Mainstream Approaches
当前 Agent 编排生态已涌现多种框架和模式,以下是最值得参考的方案及其与 Apriso 场景的适配性:Several frameworks and patterns have emerged in the Agent orchestration ecosystem; the most noteworthy and their fit for the Apriso scenario:
| 方案Approach | 核心思路Core Idea | 优势Strengths | Apriso 适配性Apriso Fit |
|---|---|---|---|
| ReAct (Reasoning + Acting) | LLM 交替输出推理与工具调用,单步决策LLM alternates reasoning and tool calls; single-step decision | 简单直接,无额外框架Simple, no extra framework | 适合简单场景(1-3 步),复杂编排力不从心Good for simple scenarios (1-3 steps); insufficient for complex orchestration |
| LangGraph | 有向图状态机,节点 = Agent / 工具,边 = 条件路由Directed graph state machine; nodes = agents / tools, edges = conditional routing | 可视化流程图、支持并行/循环/条件、持久化 checkpointVisual flow, supports parallel/loop/conditional, persistent checkpoints | 天然适配 Apriso 的有依赖操作序列;checkpoint 可做失败恢复Naturally fits Apriso's dependency-ordered operation sequences; checkpoints enable failure recovery |
| AutoGen (Microsoft) | 多 Agent 对话框架,Agent 间消息传递协作Multi-agent conversation framework; inter-agent message passing | 子 Agent 天然分工、对话式协作Natural sub-agent specialization; conversational collaboration | 子 Agent 分工模式适合,但消息开销大、延迟高Sub-agent pattern fits, but high message overhead and latency |
| CrewAI | 角色化 Agent + 任务 + 流程,声明式编排Role-based agents + tasks + processes; declarative orchestration | 角色定义清晰、流程声明式Clear role definition, declarative process | 可定义 ScreenExpert / DfcExpert 角色,但与 MCP 工具映射需自定义Can define ScreenExpert / DfcExpert roles, but MCP tool mapping requires custom work |
| OpenAI Assistants API | 托管式 Agent,内置 function calling + 上下文管理Managed agent with built-in function calling + context management | 零基础设施、自动上下文窗口管理Zero infrastructure, automatic context window management | 最省力但锁死 OpenAI 生态;自定义编排能力弱Lowest effort but locks into OpenAI ecosystem; weak custom orchestration |
| 自研轻量编排器Custom Lightweight Orchestrator | Plan -> Execute -> Verify 循环 + 规则模板 + 状态持久化Plan -> Execute -> Verify loop + rule templates + state persistence | 完全可控、可针对 Apriso 领域深度优化Full control, deep Apriso domain optimization | 最贴合但自研成本高,需评估 ROIBest fit but high self-build cost; ROI must be evaluated |
短期 PoC 阶段用 ReAct 模式(LLM 单步推理 + 工具调用)验证简单场景;中期引入 LangGraph 构建有向图编排(可视化 + checkpoint 恢复 + 并行/条件支持);长期视复杂度增长决定是否引入子 Agent 分工(CrewAI/AutoGen 模式)。自研轻量编排器作为备选方案——如果 LangGraph 的抽象与 Apriso 领域差距太大。但这只是初步想法,非常希望 Global 团队给出建议,尤其是:在你们的产品场景中,Agent 编排层是自研还是用框架?失败回滚是怎么做的?Agent 记忆的存储格式和检索策略是什么?Short-term PoC: ReAct mode (single-step LLM reasoning + tool calls) for simple scenarios. Mid-term: introduce LangGraph for directed-graph orchestration (visualization + checkpoint recovery + parallel/conditional support). Long-term: decide on sub-agent specialization (CrewAI/AutoGen) as complexity grows. Custom lightweight orchestrator as fallback if LangGraph's abstraction is too distant from the Apriso domain. However, these are only initial thoughts — we strongly hope the Global team can provide recommendations, especially: in your product scenarios, is the Agent orchestration layer self-built or framework-based? How is failure rollback handled? What are the storage format and retrieval strategies for Agent memory?
面向 Global 团队的关键问题Key Questions for the Global Team
以下问题按两大主题分组,涵盖上下文颗粒度(第 7 章)与 Agent 编排(第 8 章)两个维度的核心待解难题,希望 Global 团队提供经验和建议。The following questions are grouped by two major themes, covering the core challenges in both context granularity (Chapter 7) and Agent orchestration (Chapter 8). We hope the Global team can share experiences and recommendations.
- 上下文模板:不同 AI 场景(脚本排错 / SQL 优化 / 建模答疑 / 架构理解)各自需要哪些 Apriso 实体字段?能否预定义"上下文模板"让 AI 按场景选择?Context templates: which Apriso entity fields does each AI scenario need (script debugging / SQL optimization / modeling Q&A / architecture understanding)? Can we predefine "context templates" for the AI to select by scenario?
- Flexpart 语义层:Flexpart / Business Object 是 Apriso 的业务语义单元,但数据库中它只是 BUSINESS_OBJECT 表的一行。如何在不依赖 Apriso 运行时 API 的情况下,把 Flexpart 的语义关系(它关联了哪些 Screen/DFC)高效返回给 AI?Flexpart semantic layer: Flexpart / Business Object is Apriso's business semantic unit, but in the DB it's just one row in BUSINESS_OBJECT. How to efficiently return Flexpart's semantic relationships (which Screens/DFCs it links) to the AI without depending on Apriso runtime APIs?
- ScreenInterface 内容压缩:HTML 可达 5000+ 行,是否应返回 AST 摘要(控件树 + 事件绑定)而非原始 HTML?JS 是否应提取函数签名而非全文?ScreenInterface content compression: HTML can reach 5000+ lines — should we return an AST summary (control tree + event bindings) instead of raw HTML? Should JS return function signatures instead of full text?
- DFC 图 vs 树:DFC 之间存在子 DFC 调用、Screen 跳转形成的有向图。AI 需要图遍历能力还是树结构就够用?跨 Screen 的跳转关系(View Action -> TargetScreen)是否应单独建索引工具?DFC graph vs tree: DFCs form a directed graph via sub-DFC calls and Screen jumps. Does the AI need graph traversal or is a tree sufficient? Should cross-Screen jump relationships (View Action -> TargetScreen) have a separate index tool?
- Token 预算分配:单次 MCP 工具响应的 Token 上限应设多少?(Claude Code 25K / Claude Desktop 30K / Cline 可配)不同 AI 客户端差异如何适配?Token budget allocation: what should the single MCP tool response token limit be? (Claude Code 25K / Claude Desktop 30K / Cline configurable) How to adapt across different AI clients?
- 缓存与增量:同一 Screen 的结构树在会话中可能被多次引用。是否应在 MCP 站点侧加 LRU 缓存,让 AI 重复请求 L0/L1 时零 DB 查询?Caching & incremental: the same Screen's structure tree may be referenced multiple times in a session. Should an LRU cache be added at the MCP site so repeated L0/L1 requests incur zero DB queries?
- Schema 演进:Apriso 不同版本的表结构有差异(如 2023 vs 2026),返回给 AI 的字段集如何版本适配?已有
AprisoVersion记忆维度,但工具返回层是否也应版本感知?Schema evolution: Apriso table structures differ across versions (e.g., 2023 vs 2026). How should the field set returned to the AI adapt? There is already anAprisoVersionmemory dimension, but should the tool return layer also be version-aware?
- 编排框架选择:你们推荐自研还是用开源框架(LangGraph / AutoGen / CrewAI)?基于什么判断标准?有无 Apriso 类似场景(有副作用的多步 DB 操作)的编排经验?Orchestration framework choice: do you recommend self-built or open-source framework (LangGraph / AutoGen / CrewAI)? Based on what criteria? Any experience with orchestration for scenarios similar to Apriso (multi-step DB operations with side effects)?
- 任务拆解模式:用 LLM 驱动拆解还是规则模板(如"复制 Screen" -> 预定义步骤序列)?两者如何配合——LLM 做意图理解 + 规则模板做步骤展开?Task decomposition pattern: LLM-driven decomposition or rule templates (e.g., "copy Screen" -> predefined step sequence)? How do they cooperate — LLM for intent understanding + rule templates for step expansion?
- 失败回滚:在 stateless MCP 工具层,你们如何处理有副作用的失败操作?Saga 补偿事务?Agent 层逆向操作?还是接受"半成品 + 人工修复"?Failure rollback: with stateless MCP tools, how do you handle failed operations with side effects? Saga compensation transactions? Agent-layer reverse operations? Or accept "partial results + manual repair"?
- 动态规划触发:什么条件触发重新规划?如何防止死循环(Agent 反复重试同一失败路径)?人工介入的阈值是几步失败或几次重规划?Dynamic planning triggers: what conditions trigger re-planning? How to prevent infinite loops (agent repeatedly retrying the same failing path)? What is the threshold for human intervention — how many failed steps or re-plans?
- 子 Agent 必要性:在你们的实践中,子 Agent 分工的 ROI 在哪?什么复杂度阈值下值得引入?单 Agent + 好的提示词能否覆盖大多数场景?Sub-agent necessity: in your practice, where is the ROI of sub-agent specialization? At what complexity threshold is it worth introducing? Can a single agent + good prompting cover most scenarios?
- Agent 记忆架构:编排记忆(执行经验、失败教训)与领域记忆(项目规范、命名约定)是分开存储还是统一?格式是自然语言、结构化 JSON、还是向量?检索时机——规划前检索还是失败后检索?Agent memory architecture: should orchestration memory (execution experience, failure lessons) and domain memory (project conventions, naming rules) be stored separately or unified? Format: natural language, structured JSON, or vectors? Retrieval timing — before planning or after failure?
- 人机协作模式:哪些决策点应该自动执行、哪些应该暂停等用户确认?如何设计"置信度阈值"——Agent 不确定时主动求助?Human-AI collaboration mode: which decision points should be automatic, which should pause for user confirmation? How to design "confidence thresholds" — agent proactively asks for help when uncertain?
- 成本控制:复杂编排(多步工具调用 + LLM 推理)的 Token 开销如何控制?是否有"预算感知规划"——Agent 在规划阶段评估 Token 成本并选择更省的路径?Cost control: how to control token overhead of complex orchestration (multi-step tool calls + LLM reasoning)? Is there "budget-aware planning" — agent evaluates token cost at planning time and chooses a cheaper path?
与现有架构的衔接点Integration Points with Existing Architecture
MCP 工具层无需改动MCP Tool Layer: No Changes Needed
- 49+ 工具已是原子化、stateless、DTO 统一包裹49+ tools already atomic, stateless, unified DTO wrapper
- Agent 编排层在 MCP 之上,通过 JSON-RPC 调用Agent orchestration layer sits above MCP, calls via JSON-RPC
- 编排逻辑与工具实现完全解耦Orchestration logic fully decoupled from tool implementation
AI Dev Assistant 面板为编排入口AI Dev Assistant Panel as Orchestration Entry
- 面板负责用户交互 + 上下文抓取 + 结果展示Panel handles user interaction + context capture + result display
- 编排引擎可后置在 MCP 站点或独立进程Orchestration engine can be in MCP site or separate process
- 面板发送的高层指令由编排引擎拆解High-level instructions from panel are decomposed by orchestration engine
DevAiMemory 为记忆载体DevAiMemory as Memory Vehicle
- 已规划的 AiMemory schema 可承载编排记忆Planned AiMemory schema can carry orchestration memory
- 需新增"记忆类型"字段区分编排 vs 领域Need a "memory type" field to distinguish orchestration vs domain
- ConversationLog 已规划,可记录编排全过程ConversationLog already planned; can record full orchestration process
MCP 工具层已就绪(原子化操作 + stateless + DTO 统一),上下文颗粒度方案已设计(L0-L3 分级 + 渐进式披露),但Agent 编排层是当前最大的未解难题——它决定了 AI 能否真正替代开发者完成多步骤、有依赖、有副作用的复杂 Apriso 操作。我们希望 Global 团队在框架选择、失败策略、记忆架构、人机协作等方面提供经验指导,帮助我们避免重复造轮子。The MCP tool layer is ready (atomic operations + stateless + unified DTO), the context granularity scheme is designed (L0-L3 tiering + progressive disclosure), but the Agent orchestration layer is the biggest unsolved challenge — it determines whether AI can truly replace developers in executing multi-step, dependency-aware, side-effecting complex Apriso operations. We hope the Global team can provide experience guidance on framework selection, failure strategy, memory architecture, and human-AI collaboration, helping us avoid reinventing the wheel.
演进路线Roadmap
AI 工具体系按三个阶段递进,当前处于 PoC 验证阶段(关键路径约 10 人日)。The AI tool system progresses in three phases; currently in PoC validation (critical path ~10 person-days).
MCP 工具层 + 业务内核MCP Tool Layer + Business Core
49+ MCP 工具(Deep 三件套 17 + DFC 创作 10 + Screen 内容 15 + 查询/状态 6 + AI PoC 1),双方言直连 Authoring 库,屏幕图统一遍历,Deep Move 作用域语义修复,异步预览加载。49+ MCP tools (Deep trio 17 + DFC creation 10 + Screen content 15 + query/status 6 + AI PoC 1), dual-dialect direct connection to Authoring DB, unified screen graph traversal, Deep Move scope semantics fix, async preview loading.
PoC-1:PB 上下文可达性探针PoC-1: PB Context Reachability Probe
PB 插件 API 可行性已验证通过:能拿到活动建模项、ActionScript 编辑器内容、UserFormula 配置、Grid 绑定 SqlQuery 等关键上下文。Gating item 已清除。PB plugin API feasibility verified and passed: can access active modeling items, ActionScript editor content, UserFormula configuration, Grid-bound SqlQuery and other key context. Gating item cleared.
AI Dev Assistant PoC 验证AI Dev Assistant PoC Validation
PoC-1 已完成 -> PoC-2 存储与方言落地 -> PoC-3 MCP AI 工具 + LLM 流式 + 密钥管理 -> PoC-4 端到端 插件 <-> MCP <-> LLM。PoC-5(SQLite 离线)后置第二阶段。PoC-1 done -> PoC-2 storage & dialect implementation -> PoC-3 MCP AI tool + LLM streaming + key management -> PoC-4 end-to-end Plugin <-> MCP <-> LLM. PoC-5 (SQLite offline) deferred to Phase 2.
核心可用:真实 AI 对话 + 记忆提炼Core Usable: Real AI Chat + Memory Distillation
AI Dev Assistant 接入真实 LLM 后端,DevAiMemory 建表 + CRUD,基础对话流 + 记忆提炼 + 关键词检索。成本控制(低价值对话前置拦截)+ 对话审计从 MVP 即内置。上下文颗粒度 L0-L2 分层工具落地。AI Dev Assistant connects to real LLM backend; DevAiMemory table creation + CRUD; basic conversation flow + memory distillation + keyword retrieval. Cost control (low-value conversation pre-filtering) + conversation audit built in from MVP. Context granularity L0-L2 tiered tools implemented.
记忆体系完善 + Agent 编排 PoCMemory System Refinement + Agent Orchestration PoC
Embedding + 语义检索(混合检索上线),记忆去重/冲突覆盖,过期清理 + 版本追溯,离线 SQLite 缓存 + 双向同步落地。Agent 编排层启动 PoC:ReAct 模式验证简单多步场景(如"复制 Screen 并修改 DFC"),评估 LangGraph 适配性。编排记忆与领域记忆分层设计落地。Embedding + semantic retrieval (hybrid retrieval online); memory dedup/conflict override; expiry cleanup + version tracing; offline SQLite cache + bidirectional sync. Agent orchestration PoC starts: ReAct mode validates simple multi-step scenarios (e.g., "copy Screen and modify DFC"); evaluate LangGraph fit. Orchestration memory vs domain memory layered design implemented.
Agent 编排成熟 + 场景深化Agent Orchestration Maturity + Scenario Deepening
Agent 编排引擎落地(LangGraph 或自研),失败回滚策略(Saga 或逆向操作)上线,动态规划 + 人机协作阈值机制。报表/集成接口/日志排查场景规则,企业建模规范沉淀工作流,成本配额可视化面板,相似问题缓存复用。后端进程可平移为远程服务,插件仅改通信地址。Agent orchestration engine implemented (LangGraph or custom); failure rollback strategy (Saga or reverse operations) online; dynamic planning + human-AI collaboration threshold mechanism. Report/integration interface/log investigation scenario rules; enterprise modeling convention sedimentation workflow; cost quota visualization dashboard; similar question cache reuse. Backend process can be migrated to remote service; plugin only changes communication address.
PB 插件 API 可行性:已验证通过,能拿到活动建模项/脚本/公式对象模型。PB Plugin API feasibility: verified and passed; can access active modeling items / scripts / formula object models. SQL Server 版本:向量原生支持需 2025+,当前以 JSON 数组兜底。SQL Server version: native vector support requires 2025+; currently using JSON array fallback. Agent 编排框架:LangGraph vs 自研待评估,需 Global 团队建议。Agent orchestration framework: LangGraph vs custom-build under evaluation; Global team input needed. 失败回滚策略:stateless MCP 工具的补偿事务方案待定(Saga / 逆向操作 / 人工修复)。Failure rollback strategy: compensation transaction approach for stateless MCP tools TBD (Saga / reverse operations / manual repair). Apriso WebAPI 鉴权:后端进程如何拿到合法 Apriso 凭证,第二阶段明确。Apriso WebAPI auth: how the backend process obtains valid Apriso credentials; to be clarified in Phase 2. 本地后端进程安装分发:随 PB 插件安装包一起分发。Local backend process distribution: bundled with PB plugin installer.