企业官网建设流程全解析

• 人工智能
• AI Agent
• 自主智能体
• 桌面应用
• MCP Clients

导读

kun-tool-router是 Kun 内置捆绑技能（bundled skill）中负责工具路由的元技能：它不执行具体任务，而是把每一次用户请求"路由"到最窄、最贴合的真实 Kun 工具族，并同时定义"任务完成所需的验证边界"。本文以 resources/bundled-skills/kun-tool-router/SKILL.md 为骨架，结合仓库中fast_context、browser_use、design_update_shapes、ppt_agent、office_inspect、mcp_search等真实工具的源码实现与测试用例，完整讲解工具路由表、五步工作流、完成门禁（completion gates）与边界约束，让你掌握在 Kun 中"选对工具、最小化动作、用可观察输出验证"的实战方法论。

技能是什么：路由而非授权

kun-tool-router的核心定位记录在技能本身的 frontmatter 与 skill.json 中：

• 名称：kun-tool-router，版本1.0.0；
• 描述：Route requests to the narrowest real Kun tool family and define the required verification boundary（把请求路由到最窄的真实 Kun 工具族，并定义所需的验证边界）；
• 入口：entry: "SKILL.md"，即技能正文由本文档构成；
• 触发方式：支持命令/kun-tool-router以及一系列提示词模式，包括Kun Tool Router、Kun tools、kun-tool-router、tool router、which tool、工具选择；
• 授权边界：allowedTools: []—— 该技能不授予任何额外工具权限。

这一"不授予额外授权"的设计在技能的 Boundaries 一节中被明确重申："This skill routes work; it does not grant additional authorization." 也就是说，router 只负责选择与编排，真正的执行权限由 Kun 的运行时能力注册表（capability registry）与各工具的 sideEffect 策略决定。从源码结构看，Kun 的技能运行时在激活技能时会把allowedTools作为独立维度注入工具策略（见 kun/src/skills/skill-runtime-engine.ts 中allowedTools: [...skill.allowedTools]的组装逻辑），router 技能的allowedTools为空，恰好印证了它只做路由、不扩权的定位。

工具路由表：六类请求的"最窄工具"

技能给出了核心的工具路由表，这是整个技能的灵魂，必须原样继承并逐条解读：

fast_context：预算受限的仓库检索器

fast_context是路由表第一行，被定位为"仓库探索的第一步检索"。源码层面，它由 kun/src/adapters/tool/fast-context-tool-provider.ts 实现，属于kind: 'delegation'的委托型工具，副作用声明为read-only、network: false、processExecution: false。

从源码可以提炼出它的关键约束：

• 受限工具集：FAST_CONTEXT_ALLOWED_TOOLS = ['grep', 'glob', 'read']，子代理只能使用这三种只读源码工具，且明确禁止 shell、web、repo maps、skills、mutation 与 delegation；
• 预算与轮次：每一模型轮最多发出 4 次源码工具调用，第 4 轮只做最终综合、不再调用工具（见FAST_CONTEXT_SYSTEM_PROMPT与fastContextPrompt中的 "Round 4 is final synthesis only"）；
• 批量任务：tasks为 1–4 个任务的数组，每个任务必须有title（≤240 字符）与query（≤4000 字符），复杂问题应在一个批次中提交 2–4 个互不重叠的任务；
• 证据包输出：返回evidencePack（Fast Context Evidence Pack），以紧凑的"文件+行号"证据代替原始搜索输出，而不是倾倒 grep 原文；
• 排队超时：FAST_CONTEXT_QUEUE_TIMEOUT_MS = 30_000，并可通过fast: true走serviceTier: 'priority'优先通道；
• 安全边界：子代理从父级工具上下文捕获的不可变 workspace 中检索，模型永远不能自行选择沙箱根目录（securitySnapshot中sandboxRoot: workspace）。

测试用例 kun/src/adapters/tool/fast-context-tool.test.ts 验证了任务批量提交、证据包构造与状态机（queued → running → completed/failed/aborted）的完整行为，可以作为理解该工具契约的入口。

browser_use：结构化公开网页浏览

browser_use是"结构化交互式公开浏览"的工具。在 kun/src/adapters/tool/browser-use-tool-provider.ts 中可以看到它的严格性设计：

• 动作枚举：action字段必须取BROWSER_USE_ACTIONS枚举中的值，且明确 "Do not use navigate or goto aliases"（禁止导航别名）；
• 元素引用：ref是来自最新结构化快照的不透明元素引用，不接受选择器或坐标；
• 期望目标校验：expectedTarget对 click/type/select/press 是必填项，需从快照中拷贝sessionId、tabId、documentGeneration、origin、sanitizedUrl与节点的role/name，主进程会对实时不匹配直接拒绝；
• URL 策略：open的url必须是绝对 HTTP/HTTPS 地址，主机在加载前强制实施 public/local origin 策略；
• 标签页管理：newTab: true在配置的标签页上限内创建并激活独立标签页。

这些约束与 router 技能"结构化、可验证、拒绝临时绕过"的精神完全一致：浏览动作必须基于快照引用，而不是自由坐标猜测。

design_update_shapes：可编辑画布的定点变更

design_update_shapes对应"可编辑画布变更"。在 kun/src/adapters/tool/design-canvas-tool.ts 中，DESIGN_UPDATE_SHAPES_TOOL_NAME = 'design_update_shapes'被列入DESIGN_CANVAS_MUTATION_TOOL_NAMES，是画布变更工具族的一员，同族还包括design_canvas、design_create_screen、design_create_diagram、design_arrange、design_export_canvas、design_system、design_validate、design_svg_create等。

值得注意的细节：该工具是否对模型"广告"（advertise）取决于SHOULD_ADVERTISE_DESIGN_TOOL条件 —— 只有context.guiDesignCanvas === true（即当前处于 GUI 设计画布会话）时才会被展示。这体现了 router 技能的 Completion gates 第一条："Do not assume a surface or tool that is not advertised in the current turn"（不得假设当前轮次未广告的表面或工具存在）。同时，工具描述要求：在设置 x/y 前必须先检查当前轮次提示中的画布快照，避免与已有形状、图片、帧、选中边界、内容边界重叠；无需精确定位时省略 x/y，由渲染器自动选择不重叠的位置（见CANVAS_SNAPSHOT_PLACEMENT_DESCRIPTION）。

ppt_agent：原生演示文稿工作流

ppt_agent是演示文稿任务的一等公民入口，实现于 kun/src/adapters/tool/ppt-agent-tool-provider.ts。它的设计要点：

• 工作流动作：action取值start、select_direction、revise_directions、revise_previews、retry_failed、approve_and_build，后续评审/续作动作通过childId+workflowId恢复原 PPT 子代理；
• 内容来源：工具读取当前激活的用户轮次及其附件作为唯一内容来源，工具参数中"不得转述、总结、扩写或编造演示内容"（"never restate, summarize, expand, or invent presentation content in tool arguments"）；
• 显示标题：start动作要求 2–6 个词、最多 160 字符的短title，仅作为 UI 显示元数据，永不进入子请求；
• 交付验证：子代理在 workspace 下写 deck 文件，父代理负责交付物验证（deck 结构、.pptx 导出、逐页 fade）；只有approve_and_build才允许ppt_export，其他动作阶段会被blocksPptExport屏蔽；
• 托管本地工具：部分 provider 无法执行 Kun 受治理的本地 PPT 工具，此时工具会返回phase: 'unavailable'并提示在 Lab 设置中配置具备工具能力的 PPT Agent 模型。

这与 router 技能的 Workflow 第 4 步"执行最小的连贯动作"和第 5 步"用最接近的可观察输出验证"形成闭环：PPT 工作流被拆成 start → direction → review → build 的最小动作序列，每步都有结构化 bundle（directionBundle / reviewBundle / deckArtifact）作为可观察的验证产物。

office_inspect：检查 Office 文档

office_inspect对应 Office 文档的只读检查场景，实现位于 kun/src/adapters/tool/office-cli-tool-provider.ts。其底层是一个受治理的 Office CLI 运行器：

• 超时与并发：单次操作超时OFFICECLI_TIMEOUT_MS = 60_000，最大并发OFFICECLI_MAX_CONCURRENCY = 2，输出上限 2 MiB、预览上限 4 MiB；
• 身份校验：通过captureFileIdentity/assertFileIdentityUnchanged校验文件在操作前后身份不变，sha256File计算哈希，防止检查或编辑过程中文件被意外替换；
• 只读检查动作：isInspectAction区分检查类动作，inspectCommand构造对应的检查命令，解析输出parseOfficeCliOutput；
• 受管进程：spawnOwnedProcess/stopOwnedProcess管理受管子进程，profile 目录以0o700权限创建。

从设计意图看，office_inspect是"检查优先于修改"的体现：先 inspect 获取文档结构证据，再决定是否需要编辑类操作（编辑则走office_edit一类动作，且有OFFICECLI_MAX_OPERATIONS操作预算）。这与 router 技能 Workflow 第 3 步"Inspect current state before mutation"完全对应。

mcp_search：发现已连接的集成

mcp_search用于"发现已连接的集成"，实现在 kun/src/adapters/tool/mcp-tool-search.ts。它是 MCP 工具族中的检索入口，同族还有mcp_describe、mcp_call、mcp_read_only_call、mcp_refresh_catalog：

• 虚拟目录：基于VirtualToolCatalog冻结目录视图（FrozenToolCatalogView），最多缓存 256 个冻结目录；
• 索引与检索：通过searchRecords+ 排序函数mcp-tool-search-ranking.ts里的describeRecord/formatSearchResult对已连接 MCP 服务器的工具进行检索，支持topKDefault、topKMax、minScore等运行时诊断参数；
• 角色定位：当用户提到某个外部集成能力时，先mcp_search发现可用工具，再mcp_describe了解契约，最后才mcp_call执行 —— 正是"先发现、再理解、后调用"的最小化路径。

五步工作流：从分类到验证

router 技能给出了可复用的五步工作流，是技能的操作核心：

1. 分类输出（Classify the output）：判断本次请求的输出形态 —— prose（文字）、file（文件）、code（代码）、browser action（浏览器动作）、design（设计）、chart（图表）、diagram（示意图）、presentation（演示文稿）、media（媒体）、schedule（日程）或 integration（集成）；
2. 选择最具体的已广告工具（Choose the most specific advertised tool）：对照路由表选择最贴合分类结果的工具；只选择当前轮次中真正被广告（advertised）的工具；
3. 变更前检查当前状态（Inspect current state before mutation）：任何修改动作前，先用fast_context/office_inspect等只读手段摸清现状；
4. 执行最小的连贯动作（Perform the smallest coherent action）：一次只做最小但自洽的动作，例如设计画布只更新目标形状，PPT 只推进一个工作流阶段；
5. 用最接近的可观察输出验证（Verify using the closest observable output）：以离动作最近的产物作为验证证据 —— 文件内容、画布快照、导出产物、结构化 bundle。

这五步可以在源码中找到印证：fast_context的证据包（evidencePack）与"文件+行号"结论、design_update_shapes的画布快照约束、ppt_agent的 direction/review/deck 三层 bundle，都是"最小动作 + 可观察验证"的具体实现。ppt_agent的emitPptLifecycleUpdate在 queued/running 阶段持续回传生命周期更新，也服务于第 5 步的可观察性。

完成门禁（Completion gates）：三条硬性验收规则

技能定义了三条完成门禁，任何任务在宣告完成前都必须通过：

• 不得假设未广告的表面或工具：Do not assume a surface or tool that is not advertised in the current turn。典型例证：design_update_shapes仅在guiDesignCanvas === true时才被广告；fast_context/ppt_agent可在 Lab 设置中禁用（enabled: false时工具在 execute 入口返回 isError）。模型只能使用当前轮次真正可见的工具，不能"脑补"不存在的工具面；
• 尊重依赖顺序，只并行独立读取：Respect dependent sequencing; parallelize only independent reads。依赖型步骤（如先 inspect 再 edit、先 direction 再 review）必须串行；只有互不依赖的读取（如fast_context批量任务中的多个独立 query）才可以并行；
• 如实上报未解决的失败：Report unresolved failures without hiding them。ppt_agent对方向/评审/交付物缺失会分别给出directionContractError、reviewContractError、deckContractError，并把子错误合并进最终 error 输出（formatPptChildError），这正是"不隐瞒失败"的实现。

边界（Boundaries）：两条不可逾越的约束

技能的 Boundaries 是安全与治理的底线：

• 路由不授权：本技能只负责路由，不授予任何额外权限（allowedTools 为空）。执行权限来自能力注册表与工具自身的 sideEffect 策略；
• 禁止用 shell 绕过来替代受治理的专用工作流：Never replace a specialized governed workflow with a shell workaround。例如：Office 文档的检查与编辑必须走office_inspect/ 受治理的 office CLI 通道（有文件身份校验、操作预算、并发控制），而不是用 shell 命令直接操作文件；演示文稿必须走ppt_agent的受治理工作流，而不是手写临时脚本导出 PPTX。

交付（Delivery）：以结果与证据为先

技能最后定义了交付范式：

• 以结果开头（Lead with the outcome）：先说结论与产出；
• 点名用于验证的证据（Name the evidence used for verification）：明确说明本次验证使用了哪一类证据 —— 是fast_context的证据包、画布快照、.pptx导出产物，还是mcp_describe返回的契约描述；
• 披露仍存在的真实局限（Disclose any real limitation that remains）：例如模型 provider 无法执行受治理的本地 PPT 工具、generate_image在当前工具策略中不可用、或某条证据链不完整导致的不确定性。

实战速查：一个请求如何被路由

综合以上内容，可以把 router 技能的运行方式浓缩为以下判定路径（仅作理解参考，非源码字面）：

1. 用户请求进入后，先分类输出形态；
2. 若涉及仓库理解，先fast_context以 1–4 个任务批次做只读检索，拿到证据包；
3. 若涉及公开网页，走browser_use结构化动作（快照引用 + expectedTarget 校验）；
4. 若涉及可编辑画布且当前处于设计画布会话，用design_update_shapes等画布工具做定点最小变更；
5. 若涉及演示文稿，交给ppt_agent并推进 start → direction → review → build 受治理流程；
6. 若涉及 Office 文档，先用office_inspect检查结构证据，再决定是否编辑；
7. 若涉及外部集成，先mcp_search发现、再mcp_describe理解、最后mcp_call调用；
8. 每一步都执行"检查当前状态 → 最小动作 → 最近可观察输出验证"，完成时如实披露局限。

延伸阅读

• 技能本体：resources/bundled-skills/kun-tool-router/SKILL.md 与 resources/bundled-skills/kun-tool-router/skill.json
• 技能运行时与激活机制：kun/src/skills/skill-runtime-engine.ts（命令、提示词模式、文件类型三类触发与打分排序）
• 各路由目标工具的实现与测试：
  • kun/src/adapters/tool/fast-context-tool-provider.ts 与 kun/src/adapters/tool/fast-context-tool.test.ts
  • kun/src/adapters/tool/browser-use-tool-provider.ts
  • kun/src/adapters/tool/design-canvas-tool.ts
  • kun/src/adapters/tool/ppt-agent-tool-provider.ts
  • kun/src/adapters/tool/office-cli-tool-provider.ts
  • kun/src/adapters/tool/mcp-tool-search.ts

• 人工智能
• AI Agent
• 自主智能体
• 桌面应用
• MCP Clients