GPU_GUARD_MONOREPO/docs/code-wiki/concepts/tool-runtime-policy.md
2026-05-20 21:39:12 +08:00

143 lines
6.0 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
title: Tool Runtime Policy
created: 2026-04-21
updated: 2026-05-02
type: concept
tags: [tool, runtime, agent, backend, config]
sources: [packages/backend/src/modules/netaclaw/tools/manifest.ts, packages/backend/src/modules/netaclaw/tools/runtime_policy.ts, packages/backend/src/modules/netaclaw/tools/presentation.ts, packages/backend/src/modules/netaclaw/service/tool_resolver.ts, packages/backend/src/modules/netaclaw/subagent/process_protocol.ts, packages/frontend/src/modules/agent/tools/runtime-policy.ts]
---
# Tool Runtime Policy
Tool Runtime Policy 是工具重构后新增的运行时策略层。它解决的问题是:工具不仅要知道“是否启用”,还要知道“在当前 Agent、当前子进程、当前 workspace/policy 下到底能不能执行,以及应该在哪里执行”。
它连接 [[tool-system]]、[[tool-governance]]、[[subagent-session]] 和 [[agent-runtime]]。
2026-05-02 后还要区分 [[tool-operations]]Runtime Policy 决定工具在 worker 视角是本地、主进程代理还是禁用Operations 决定某个已构建工具的文件系统、进程和搜索调用如何落地。当前实现仍保持工具粒度 route不把每个 file/process 方法拆成独立权限。
## 三层模型
```text
Tool Catalog / DB Governance
-> Tool Manifest
-> Runtime Policy Projection
```
### 1. Catalog / DB Governance
这一层负责工具是否存在、全局是否启用、Agent 是否覆盖、Prompt Hint 如何写入。详见 [[tool-governance]]。
### 2. Tool Manifest
`tools/manifest.ts` 将工具转成稳定画像:
- `kind`: `builtin``memory``skill``delegation``admin``custom`
- `executionMode`: `parallel``sequential`
- `supportedInWorker`
- `workerRoutingHint`: `local``main-process-proxy``disabled`
- `requiresShell`
- `requiresWrite`
- `requiresSkillScope`
这些字段是子 Agent worker 和前端诊断展示的共同语言。
### 3. Runtime Policy Projection
`tools/runtime_policy.ts` 根据 manifest、enabled tool names、disabled reasons、worker policy 推导最终状态:
| 状态 | 含义 |
| --- | --- |
| `worker-local` | 子进程可以本地执行 |
| `main-process-proxied` | 子进程请求父进程代理执行 |
| `disabled-in-worker` | 当前 worker 策略下不能执行 |
| `not-selected` | 没有被选入当前子 Agent 工具集 |
前端再映射为路由:
- `worker-local`
- `main-process-proxy`
- `disabled`
## Worker Policy 自动推导
`buildSubprocessWorkerPolicy` 会从当前 session 和工具 manifest 推导 worker 策略:
- `workspaceRoots`: 来自 `sessionCwd` 和额外 workspace roots去重后传给 worker。
- `allowShell`: 只有工具确实需要 shell且策略允许时才为 true。
- `readonly`: 如果没有写工具需求,默认只读;写工具需要显式允许。
这使子 Agent 不需要默认拥有完整宿主进程权限。
## 阻断原因
常见 `blockedReason` 包括:
| 原因 | 含义 |
| --- | --- |
| `workspace_root_required` | 工具需要 workspace root但当前 session 没有 cwd/root |
| `shell_disabled_by_policy` | `bash` 等 shell 工具被策略禁用 |
| `write_blocked_by_readonly_policy` | 写入类工具被 readonly 策略阻止 |
| `requires_main_process_proxy` | 工具需要主进程代理 |
| `unsupported_in_worker` | 工具没有 worker 支持 |
| `not_selected_for_subagent` | 未被选入子 Agent 工具集 |
这些原因应该在工具管理页、Agent 编辑页、子 Agent 批次详情里使用同一套中文展示。
## 当前内置路由
| 工具类别 | 工具 | 默认路由 |
| --- | --- | --- |
| Worker 本地 | `bash``read_file``list_dir``find_files``grep` | `worker-local` |
| 主进程代理 | `write_file``edit``patch``read_skill``read_skill_file``skill_manage``execute_skill``memory_save``memory_recall` | `main-process-proxy` |
| 强顺序工具 | `edit``patch``write_file``delegate_task``delegate_parallel``clarify``escalate` | `sequential` |
治理层可以通过 `workerRoutingStrategy` 强制覆盖:
- `auto`
- `force-local`
- `force-main-process-proxy`
- `force-disabled`
## 前端一致性要求
这次重构的目标之一是让三处页面一致:
- 工具管理页显示全局治理、核心工具、是否可关闭、运行时画像。
- Agent 编辑页显示当前 Agent 的局部启停、子 Agent 允许工具、有效 runtime profile。
- 对话页显示实际运行时的子 Agent 工具路由和 blocked reason。
这些页面不应各自重新推导规则,而应消费后端 `runtimeDiagnostic` / projection。
## 2026-04-23 动态路由与静态画像的区别
近期实现里Tool Runtime Policy 需要同时解释两种结果:
- `manifest` / `effectiveRuntimeProfile`:偏静态画像,描述工具理论上支持什么、通常需要什么权限。
- `toolRuntimeRoutes`:偏动态结果,描述在当前 session cwd、workspace roots、allowShell、readonly、selected tools 条件下,这次运行究竟走哪条路。
因此:
- 工具管理页更适合看“画像”和“全局风险”。
- Agent 编辑页更适合看“该 Agent 保存后会生效什么画像”。
- 对话页和子 Agent 批次更适合看“本次任务真正请求到的路由结果”。
如果出现“Agent 编辑页显示允许,但运行时还是 blocked”优先检查动态 `toolRuntimeRoutes`,不要只盯着静态 manifest。
## Operations 不是 Runtime Policy
[[tool-operations]] 新增后,容易混淆两条线:
- `toolRuntimeRoutes` 是“这个工具在本次策略下能不能进 worker / 是否代理”的决策结果。
- `ToolOperations` 是“工具实例内部调用文件、搜索、进程时走哪个后端”的执行依赖。
例如 `bash` 可以被 Runtime Policy 判定为 `worker-local`,但其具体执行仍由注入的 `ProcessOperations.exec()` 完成;测试环境可以替换为 mock process operations而不需要改 policy。
## 相关页面
- [[tool-governance]]
- [[tool-system]]
- [[tool-operations]]
- [[subagent-session]]
- [[agent-runtime]]
- [[frontend-architecture]]