mirror of
https://github.com/slhaf/Partner.git
synced 2026-05-12 08:43:02 +08:00
docs(action): add document for action
This commit is contained in:
77
doc/action/infra/command-execution-service.md
Normal file
77
doc/action/infra/command-execution-service.md
Normal file
@@ -0,0 +1,77 @@
|
||||
# CommandExecutionService
|
||||
|
||||
`CommandExecutionService` 是命令执行的最低层服务。它接收 `WrappedLaunchSpec` 或原始命令数组，负责启动进程、传入环境变量与工作目录、收集输出，并把进程执行结果转换为结构化 `Result`。
|
||||
|
||||
它有两类执行路径：
|
||||
|
||||
- 一次性命令：调用 `exec(...)`，等待进程结束后返回完整结果。
|
||||
- 持久命令：调用 `createSessionTask(...)`，返回 `CommandSession`，由调用方持有进程与输出缓冲区。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["CommandExecutionService"] --> B{"调用入口"}
|
||||
B -- " exec(List/String...) " --> C["defaultLaunchSpec<br/>command + args + System.getenv"]
|
||||
B -- " exec(WrappedLaunchSpec) " --> D["WrappedLaunchSpec"]
|
||||
C --> D
|
||||
D --> E["startProcess"]
|
||||
E --> F["ProcessBuilder"]
|
||||
F --> G["command + args"]
|
||||
F --> H["workingDirectory"]
|
||||
F --> I["environment<br/>clear + putAll"]
|
||||
G --> J["process.start"]
|
||||
H --> J
|
||||
I --> J
|
||||
J --> K["stdout virtual thread<br/>collect lines"]
|
||||
J --> L["stderr virtual thread<br/>collect lines"]
|
||||
J --> M["process.waitFor"]
|
||||
K --> N["join"]
|
||||
L --> N
|
||||
M --> N
|
||||
N --> O["Result"]
|
||||
O --> P["ok = exitCode == 0"]
|
||||
O --> Q["stdoutLines / stderrLines"]
|
||||
O --> R["resultList<br/>stdout 优先，否则 stderr"]
|
||||
O --> S["total<br/>stdout + stderr 展示文本"]
|
||||
```
|
||||
|
||||
一次性命令会同步等待进程结束，并用两个虚拟线程分别读取 stdout 和 stderr。进程退出后，执行服务等待输出读取线程结束，再构造 `Result`。
|
||||
|
||||
`Result` 中几个字段的语义如下：
|
||||
|
||||
| 字段 | 语义 |
|
||||
|---|---|
|
||||
| `ok` | 进程退出码是否为 0，或异常路径下为 false |
|
||||
| `stdoutLines` | 标准输出逐行结果 |
|
||||
| `stderrLines` | 标准错误逐行结果 |
|
||||
| `resultList` | 优先使用 stdout；如果 stdout 为空，则使用 stderr |
|
||||
| `total` | 合并后的展示文本，stdout 和 stderr 都存在时按顺序拼接 |
|
||||
|
||||
异常会被转换为失败结果：`ok=false`，`stderrLines` 与 `resultList` 保存异常信息，`total` 保存异常 message。
|
||||
|
||||
持久命令路径用于需要保留进程句柄和持续读取输出的场景：
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["createSessionTask(List/String...)"] --> B["defaultLaunchSpec"]
|
||||
A2["createSessionTask(WrappedLaunchSpec)"] --> C["startProcess"]
|
||||
B --> C
|
||||
C --> D["Process"]
|
||||
D --> E["CommandSession"]
|
||||
E --> F["process"]
|
||||
E --> G["stdoutBuffer"]
|
||||
E --> H["stderrBuffer"]
|
||||
D --> I["stdout virtual thread<br/>readToBuffer"]
|
||||
D --> J["stderr virtual thread<br/>readToBuffer"]
|
||||
I --> G
|
||||
J --> H
|
||||
```
|
||||
|
||||
`CommandSession` 不等待进程结束，也不生成 `Result`。它保留 `Process`、`stdoutBuffer` 和 `stderrBuffer`，让上层可以在长生命周期命令运行期间自行读取输出、判断状态或终止进程。
|
||||
|
||||
`buildFileExecutionCommands` 是 `ORIGIN` 路由使用的命令构造辅助方法。它把 action 文件执行转换为：
|
||||
|
||||
```text
|
||||
launcher absolutePath --param=value ...
|
||||
```
|
||||
|
||||
随后这组 commands 会先进入 `ExecutionPolicyRegistry.prepare`，再由 `CommandExecutionService.exec(WrappedLaunchSpec)` 真正启动进程。
|
||||
49
doc/action/infra/execution-policy.md
Normal file
49
doc/action/infra/execution-policy.md
Normal file
@@ -0,0 +1,49 @@
|
||||
# 执行策略
|
||||
|
||||
执行策略用于把原始命令包装成具体可启动的 `WrappedLaunchSpec`。它位于 `OriginExecutionService`、动态 action MCP 执行和底层 `CommandExecutionService` 之间，负责在命令真正交给进程执行前应用运行策略。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph ConfigPlane["配置平面"]
|
||||
A1["action/runner_policy.json"] --> A2["ExecutionPolicy"]
|
||||
A2 --> A3["ExecutionPolicyRegistry.currentPolicy"]
|
||||
A4["LocalRunnerClient"] --> A5["registerPolicyProviders"]
|
||||
A5 --> A6["direct provider<br/>默认已注册"]
|
||||
A5 --> A70["Linux"] --> A80["bwrap"]
|
||||
A5 --> A71["Windows/MacOS"] --> A81["暂无"]
|
||||
end
|
||||
|
||||
subgraph PreparePlane["命令包装"]
|
||||
B1["commands: List<String>"] --> B2["ExecutionPolicyRegistry.prepare"]
|
||||
A3 --> B2
|
||||
B2 --> B3{"policy.provider"}
|
||||
B3 -- " 已注册 " --> B4["selected PolicyProvider"]
|
||||
B3 -- " 未注册 " --> B5["fallback: direct"]
|
||||
B4 --> B6["provider.prepare(policy, commands)"]
|
||||
B5 --> B6
|
||||
B6 --> B7["WrappedLaunchSpec<br/>command + args + workingDirectory + environment"]
|
||||
end
|
||||
|
||||
subgraph ExecutePlane["命令执行"]
|
||||
B7 --> C1["CommandExecutionService.exec"]
|
||||
end
|
||||
|
||||
subgraph ListenerPlane["策略变更监听"]
|
||||
A2 --> D1["updatePolicy"]
|
||||
D1 --> D2["RunnerExecutionPolicyListener"]
|
||||
D2 --> D3["McpConfigWatcher<br/>reload MCP clients"]
|
||||
end
|
||||
```
|
||||
|
||||
`ExecutionPolicyRegistry` 本身不执行命令，只选择 provider 并返回包装后的启动规格。当前默认 provider 是 `direct`；在 Linux 环境下，`LocalRunnerClient` 会额外注册 `bwrap` provider。
|
||||
|
||||
`ExecutionPolicy` 描述运行策略，包括 provider、运行模式、网络开关、是否继承环境变量、额外环境变量、工作目录，以及只读 / 可写路径集合。provider 会根据这些信息生成最终的 `WrappedLaunchSpec`：
|
||||
|
||||
| provider | 生效方式 |
|
||||
|---|---|
|
||||
| `direct` | 直接使用原始命令和参数，附加工作目录与环境变量 |
|
||||
| `bwrap` | 使用 `bwrap` 包装原始命令，按策略加入网络隔离、路径绑定和工作目录设置 |
|
||||
|
||||
`ExecutionPolicyRegistry` 也维护策略变更 listener。`McpConfigWatcher` 会注册为 listener；当 policy 被更新时，它可以重新加载 MCP client，使 MCP server 的启动规格与最新执行策略保持一致。
|
||||
|
||||
> 当前沙箱仅支持 Linux，其他平台暂未提供沙箱支持，后续会进行补充。
|
||||
56
doc/action/infra/meta-action-info.md
Normal file
56
doc/action/infra/meta-action-info.md
Normal file
@@ -0,0 +1,56 @@
|
||||
# MetaActionInfo 行动描述覆写
|
||||
|
||||
`MetaActionInfo` 是行动能力进入 planner / evaluator / executor 前的描述层。它不负责执行行动，而是描述一个 action 可以被如何理解、选择、组装和调用。
|
||||
|
||||
不同来源的行动能力都会汇入 `ActionCore.existedMetaActions`，但它们生成描述信息的方式不同：
|
||||
|
||||
- 外部 MCP tool 会先生成基础 `MetaActionInfo`，再允许通过 `mcp/desc/*.desc.json` 进行覆盖。
|
||||
- BUILTIN action 在注册时直接提供 `MetaActionInfo`。
|
||||
- dynamic action 使用 `dynamic/<name>/desc.json` 作为描述来源。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph Sources["MetaActionInfo 来源"]
|
||||
A["外部 MCP tool"]
|
||||
B["mcp/desc/*.desc.json<br/>描述覆盖"]
|
||||
C["BuiltinActionDefinition"]
|
||||
D["dynamic/name/desc.json"]
|
||||
end
|
||||
|
||||
subgraph Build["描述构建 / 合并"]
|
||||
A --> E["McpMetaRegistry<br/>基础描述"]
|
||||
B --> E
|
||||
C --> F["BuiltinActionRegistry"]
|
||||
D --> G["DynamicActionMcpManager"]
|
||||
end
|
||||
|
||||
subgraph ActionCore["行动核心: ActionCore"]
|
||||
E --> H["existedMetaActions"]
|
||||
F --> H
|
||||
G --> H
|
||||
end
|
||||
|
||||
subgraph Usage["使用位置"]
|
||||
H --> I["listAvailableMetaActions"]
|
||||
H --> J["loadMetaActionInfo"]
|
||||
H --> K["loadMetaAction(actionKey)"]
|
||||
K --> L["MetaAction"]
|
||||
L --> M["ExecutableAction.actionChain"]
|
||||
end
|
||||
```
|
||||
|
||||
描述覆写主要服务于外部 MCP tool。外部 tool 自带的信息通常只够完成调用，但不一定足够支撑 Partner 的行动规划。`mcp/desc/*.desc.json` 可以补充或覆盖这些信息，让外部 tool 进入行动系统后具备更完整的行动语义。
|
||||
|
||||
当前描述信息会影响：
|
||||
|
||||
| 信息 | 作用 |
|
||||
|---|---|
|
||||
| `description` | 让评估器和规划器理解 action 的用途 |
|
||||
| `params` | 描述行动参数，用于参数提取和调用装配 |
|
||||
| `launcher` | 为 ORIGIN / dynamic action 提供启动器信息 |
|
||||
| `io` | 描述输入输出形态，辅助行动组合 |
|
||||
| `preActions` / `postActions` | 描述行动前后依赖关系 |
|
||||
| `strictDependencies` | 表达必须满足的行动依赖 |
|
||||
| `tags` | 为 action 分类和筛选提供辅助信息 |
|
||||
|
||||
`ActionCore.loadMetaAction(actionKey)` 会根据 action key 前缀构造 `MetaAction`，但 `MetaActionInfo` 本身不会直接执行。它的价值在于让系统在执行前能够知道：有哪些 action 可用、它们需要什么参数、适合什么场景，以及是否存在依赖或补充约束。
|
||||
277
doc/action/infra/runner-client.md
Normal file
277
doc/action/infra/runner-client.md
Normal file
@@ -0,0 +1,277 @@
|
||||
# RunnerClient 与本地路由
|
||||
|
||||
本文说明 `RunnerClient`、`LocalRunnerClient` 以及 `MCP` / `BUILTIN` / `ORIGIN` 三类执行路由。
|
||||
|
||||
## MetaAction 执行通道
|
||||
|
||||
`MetaAction` 当前有三类执行通道：
|
||||
|
||||
| 类型 | 说明 |
|
||||
|---|---|
|
||||
| `MCP` | 通过 MCP client 调用外部工具能力 |
|
||||
| `BUILTIN` | 调用 JVM 内部注册的内置行动 |
|
||||
| `ORIGIN` | 执行本地或持久化的 action 文件 |
|
||||
|
||||
行动链只保存 `MetaAction`，不直接关心底层通道。执行时，`RunnerClient` 根据 `MetaAction` 的类型和位置信息把调用交给对应实现。
|
||||
|
||||
这种设计把“行动链结构”和“行动运行方式”分开：上层只需要知道 action key，底层负责解释这个 key 如何运行。
|
||||
|
||||
## RunnerClient
|
||||
|
||||
`RunnerClient` 是执行器与底层行动运行环境之间的边界。`ActionExecutor` 完成参数提取后，只需要把 `MetaAction` 提交给 runner；runner 负责确认该行动是否仍处于可执行状态、调用具体执行通道，并把结果统一写回 `MetaAction.Result`。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["ActionExecutor<br/>已完成参数提取"] --> B["MetaAction"]
|
||||
B --> C["RunnerClient.submit"]
|
||||
C --> D{"Result 是否仍为 WAITING？"}
|
||||
D -- " 否 " --> E["跳过重复执行"]
|
||||
D -- " 是 " --> F["doRun(metaAction)"]
|
||||
F --> G["RunnerResponse"]
|
||||
G --> H["写回 MetaAction.Result"]
|
||||
H --> I{"ok?"}
|
||||
I -- " true " --> J["SUCCESS"]
|
||||
I -- " false " --> K["FAILED"]
|
||||
```
|
||||
|
||||
这个边界让 `ActionExecutor` 不需要感知 MCP、ORIGIN、BUILTIN 的差异。对执行器来说，单个 `MetaAction` 只有“提交、等待结果、记录历史”这一种语义。
|
||||
|
||||
`RunnerClient` 还抽象了 action 文件序列化能力。临时 action 和持久化 action 的落盘位置、命名和文件结构由 runner 管理，上层只通过 runner 暴露的接口生成临时路径或持久化 action。
|
||||
|
||||
## LocalRunnerClient
|
||||
|
||||
`LocalRunnerClient` 是当前主要的 runner 实现。它不只是本地执行器，还负责初始化本地 action 基础设施。
|
||||
|
||||
启动时，它会建立本地 action 目录结构：
|
||||
|
||||
```text
|
||||
action/
|
||||
tmp/
|
||||
dynamic/
|
||||
mcp/
|
||||
desc/
|
||||
```
|
||||
|
||||
这些目录分别承担不同角色：
|
||||
|
||||
| 目录 | 作用 |
|
||||
|---|---|
|
||||
| `tmp/` | 临时 action 文件目录，不进入长期能力注册 |
|
||||
| `dynamic/` | 持久化动态 action 目录，由 watcher 转换为本地 MCP tool |
|
||||
| `mcp/` | 外部 MCP 配置目录 |
|
||||
| `mcp/desc/` | MCP tool 描述覆盖目录 |
|
||||
|
||||
`LocalRunnerClient` 初始化时还会启动三组基础设施：
|
||||
|
||||
- `McpMetaRegistry` + `McpDescWatcher`：维护 MCP tool 的描述资源和描述覆盖。
|
||||
- `DynamicActionMcpManager`：把 `dynamic/` 下的本地 action 包装成本进程 MCP tool。
|
||||
- `McpConfigWatcher`：监听外部 MCP 配置，动态注册或移除 MCP client。
|
||||
|
||||
因此，`LocalRunnerClient` 同时承担两个角色：一方面是 `MetaAction` 的本地执行入口，另一方面是本地行动能力集合的维护入口。
|
||||
|
||||
三类路由共享同一组平面：能力注册 / 描述平面负责让能力进入系统，`ActionCore` 维护可用能力表，行动链装配平面把 action key 加载成 `MetaAction`，执行平面再按 `MetaAction.type` 分流到具体 route。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph CapabilityPlane["能力注册 / 描述平面"]
|
||||
A1["MCP config"] --> A2["McpClientRegistry"]
|
||||
B1["BuiltinActionRegistry"]
|
||||
C1["dynamic action"] --> A2
|
||||
C1
|
||||
end
|
||||
|
||||
subgraph ActionCore["行动核心: ActionCore"]
|
||||
A1 --> A3["existedMetaActions"]
|
||||
B1 --> A3
|
||||
C1 --> A3
|
||||
end
|
||||
|
||||
subgraph PlanningPlane["行动链装配平面"]
|
||||
A3 -- " loadMetaActions " --> D2["MetaAction"]
|
||||
D2 --> D3["ExecutableAction.actionChain"]
|
||||
end
|
||||
|
||||
subgraph ExecutionPlane["执行平面"]
|
||||
D3 --> E1["ActionExecutor stage"]
|
||||
E1 --> E2["RunnerClient.submit"]
|
||||
E2 --> E3{"MetaAction.type"}
|
||||
E3 --> F1["MCP route"]
|
||||
E3 --> F2["BUILTIN route"]
|
||||
E3 --> F3["ORIGIN route"]
|
||||
end
|
||||
|
||||
F1 -. " uses location " .-> A2
|
||||
```
|
||||
|
||||
## 执行路由：MCP
|
||||
|
||||
`MCP` 路由用于调用外部 MCP server 暴露的工具能力。外部 MCP 配置被加载为 MCP client，tool 元信息被写入 `ActionCore.existedMetaActions`，随后 planner / evaluator 可以把这些 tool 作为 `MetaAction(type=MCP)` 放入行动链。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph CapabilityPlane["能力注册 / 描述平面"]
|
||||
A1["mcp/*.json<br/>外部 MCP 配置"] --> A2["McpConfigWatcher"]
|
||||
A2 --> A3["McpTransportFactory"]
|
||||
A3 --> A4["McpSyncClient"]
|
||||
A4 --> A5["McpClientRegistry<br/>clientId -> client"]
|
||||
A4 --> A6["listTools"]
|
||||
A6 --> A7["McpMetaRegistry<br/>buildMetaActionInfo"]
|
||||
A8["mcp/desc/*.desc.json<br/>描述覆盖"] --> A7
|
||||
end
|
||||
|
||||
subgraph ActionCore["行动核心: ActionCore"]
|
||||
A7 --> B1["existedMetaActions<br/>clientId::toolName"]
|
||||
end
|
||||
|
||||
subgraph PlanningPlane["行动链装配平面"]
|
||||
B1 -- " loadMetaAction " --> C1["MetaAction<br/>type=MCP<br/>location=clientId<br/>name=toolName"]
|
||||
C1 --> C2["ExecutableAction.actionChain"]
|
||||
end
|
||||
|
||||
subgraph ExecutionPlane["执行平面"]
|
||||
C2 --> D1["ActionExecutor stage"]
|
||||
D1 --> D2["RunnerClient.submit"]
|
||||
D2 --> D3["LocalRunnerClient.doRun"]
|
||||
D3 --> D4["McpActionExecutor.run"]
|
||||
D4 --> D5["McpClientRegistry.get(location)"]
|
||||
D5 --> D6["CallToolRequest<br/>name + params"]
|
||||
D6 --> D7["McpSyncClient.callTool"]
|
||||
D7 --> D8["RunnerResponse"]
|
||||
D8 --> D9["MetaAction.Result"]
|
||||
end
|
||||
|
||||
D5 -. " uses clientId " .-> A5
|
||||
```
|
||||
|
||||
在这个通道中，`MetaAction.location` 表示 MCP client id，`MetaAction.name` 表示 tool name。执行阶段通过 `location` 回到 `McpClientRegistry` 找到已注册 client，再用 `name` 和参数调用 tool。
|
||||
|
||||
## 执行路由：BUILTIN
|
||||
|
||||
`BUILTIN` 路由用于承载智能体内部向行动系统暴露的能力集合。系统内部能力可以通过 `BuiltinActionProvider` 或 `BuiltinActionRegistry` 注册为 `MetaActionInfo`，从而进入 planner / evaluator / executor 共享的行动链模型。
|
||||
|
||||
这些内部能力覆盖的范围可以很宽，包括命令执行、capability layer 操作、临时 meta action 创建与持久化、主动 turn等。`BUILTIN` 的意义是把这些内部能力也组织成 `MetaAction`，让它们与外部 MCP tool、临时 action 一样接受行动提取、评估、编排和执行。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph CapabilityPlane["能力注册 / 描述平面"]
|
||||
A1["BuiltinActionProvider"] --> A3["BuiltinActionDefinition<br/>actionKey + MetaActionInfo + invoker"]
|
||||
A2["BuiltinActionRegistry.defineBuiltinAction"] --> A3
|
||||
A3 --> A4["BuiltinActionRegistry.definitions"]
|
||||
end
|
||||
|
||||
subgraph ActionCore["行动核心: ActionCore"]
|
||||
A3 --> B1["ActionCapability.registerMetaActions"]
|
||||
B1 --> B2["existedMetaActions<br/>builtin::name"]
|
||||
end
|
||||
|
||||
subgraph PlanningPlane["行动链装配平面"]
|
||||
B2 -- " loadMetaAction " --> C1["MetaAction<br/>type=BUILTIN<br/>location=builtin<br/>name=name"]
|
||||
C1 --> C2["ExecutableAction.actionChain"]
|
||||
end
|
||||
|
||||
subgraph ExecutionPlane["执行平面"]
|
||||
C2 --> D1["ActionExecutor stage"]
|
||||
D1 --> D2["RunnerClient.submit"]
|
||||
D2 --> D3["LocalRunnerClient.doRun"]
|
||||
D3 --> D4["doRunWithBuiltin"]
|
||||
D4 --> D5["BuiltinActionRegistry.call"]
|
||||
D5 --> D6["BuiltinActionDefinition.invoker"]
|
||||
D6 --> D7["RunnerResponse"]
|
||||
D7 --> D8["MetaAction.Result"]
|
||||
end
|
||||
|
||||
D5 -. " uses actionKey " .-> A4
|
||||
```
|
||||
|
||||
`BuiltinActionRegistry` 是当前的承载实现。它负责保存 builtin action 定义，把对应 `MetaActionInfo` 注册到 action capability，并在执行时根据 action key 和参数调用具体能力。
|
||||
|
||||
## 执行路由：ORIGIN
|
||||
|
||||
`ORIGIN` 路由用于执行临时 meta action 的本地文件形态。临时 meta action 通常由某个 builtin meta-action 创建：系统内部能力先生成 action 文件和对应 `MetaAction`，随后通过 `ORIGIN` 路由运行该文件。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph CreationPlane["临时行动生成平面"]
|
||||
A1["BUILTIN meta-action"] --> A2["生成临时 action code"]
|
||||
A1 --> A3["RunnerClient.buildTmpPath"]
|
||||
A2 --> A4["RunnerClient.tmpSerialize"]
|
||||
A3 --> A4
|
||||
A4 --> A5["tmp action file"]
|
||||
end
|
||||
|
||||
subgraph ActionCore["行动核心: ActionCore"]
|
||||
A5 --> B1["origin::tmpActionPath"]
|
||||
B1 --> B2["existedMetaActions"]
|
||||
end
|
||||
|
||||
subgraph PlanningPlane["行动链装配平面"]
|
||||
B2 -- " loadMetaAction " --> C1["MetaAction<br/>type=ORIGIN<br/>location=origin<br/>name=tmpActionPath"]
|
||||
C1 --> C2["ExecutableAction.actionChain"]
|
||||
end
|
||||
|
||||
subgraph ExecutionPlane["执行平面"]
|
||||
C2 --> D1["ActionExecutor stage"]
|
||||
D1 --> D2["RunnerClient.submit"]
|
||||
D2 --> D3["LocalRunnerClient.doRun"]
|
||||
D3 --> D4["OriginExecutionService.run"]
|
||||
D4 --> D5["resolveOriginPath"]
|
||||
D5 --> D6["CommandExecutionService<br/>buildFileExecutionCommands"]
|
||||
D6 --> D7["ExecutionPolicyRegistry.prepare"]
|
||||
D7 --> D8["WrappedLaunchSpec"]
|
||||
D8 --> D9["CommandExecutionService.exec"]
|
||||
D9 --> D10["RunnerResponse"]
|
||||
D10 --> D11["MetaAction.Result"]
|
||||
end
|
||||
|
||||
D5 -. " resolves to " .-> A5
|
||||
```
|
||||
|
||||
`ORIGIN` 表示临时能力的执行阶段：action 文件有本地路径，执行时由 `OriginExecutionService` 解析文件位置、组合 launcher 与参数，并交给执行策略和命令执行服务处理。
|
||||
|
||||
临时 meta action 可以过期，也可以被主动持久化。持久化后，它会进入 dynamic action 流程，成为可长期复用的动态行动能力。
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
subgraph OriginPlane["临时 ORIGIN 阶段"]
|
||||
A1["tmp action file"]
|
||||
A2["临时 MetaAction<br/>type=ORIGIN"]
|
||||
A1 --> A2
|
||||
end
|
||||
|
||||
subgraph PersistencePlane["持久化阶段"]
|
||||
A2 --> B1["BUILTIN persist meta-action"]
|
||||
B1 --> B2["RunnerClient.persistSerialize"]
|
||||
B2 --> B3["ActionSerializer.persistSerialize"]
|
||||
B3 --> B4["dynamic/name/run.ext.tmp"]
|
||||
B3 --> B5["dynamic/name/desc.json.tmp"]
|
||||
B4 --> B6["ATOMIC_MOVE<br/>run.ext"]
|
||||
B5 --> B7["ATOMIC_MOVE<br/>desc.json"]
|
||||
end
|
||||
|
||||
subgraph CapabilityPlane["能力注册 / 描述平面"]
|
||||
B6 --> C1["DynamicActionMcpManager"]
|
||||
B7 --> C1
|
||||
C1 --> C2["normalPath"]
|
||||
C2 --> C3["system MCP server<br/>addTool"]
|
||||
C2 --> C4["dynamic action MetaActionInfo"]
|
||||
end
|
||||
|
||||
subgraph ActionCore["行动核心: ActionCore"]
|
||||
C4 --> D1["existedMetaActions<br/>local::name"]
|
||||
end
|
||||
|
||||
subgraph PlanningPlane["行动链装配平面"]
|
||||
D1 -- " loadMetaAction " --> E1["MetaAction<br/>type=MCP<br/>location=local<br/>name=name"]
|
||||
E1 --> E2["ExecutableAction.actionChain"]
|
||||
end
|
||||
|
||||
subgraph ExecutionPlane["执行平面"]
|
||||
E2 --> F1["ActionExecutor stage"]
|
||||
F1 --> F2["RunnerClient.submit"]
|
||||
F2 --> F3["MCP route"]
|
||||
end
|
||||
|
||||
F3 -. " uses location=local " .-> C3
|
||||
```
|
||||
|
||||
因此，`ORIGIN`、dynamic action 和 `MCP` 可以组成一条能力生命周期：内部能力创建临时 meta action，临时阶段通过 `ORIGIN` 执行，持久化后转为 dynamic action，并由系统创建的 MCP server 统一管理。
|
||||
Reference in New Issue
Block a user