让 WAVE Agent 从 Skill 路由器变成视觉工程助手

WAVE Agent 做到 8 月初时，功能列表已经不短了：有 Skills，有 MCP，有项目工具，有 Workflow Assistant，也有训练和部署的 Proposal / 审批链。

但实际聊天时有一个非常尴尬的问题。

用户输入一句“你好”，或者只是说“我想做一个视觉项目”，Agent 的第一反应经常不是正常回答，而是努力判断“我应该调用哪个 Skill”。如果没有正好匹配的 Skill，整个交互就会显得很僵。

这说明问题不在于工具数量，而在于最上层的判断逻辑错了。一个视觉工程助手首先应该知道什么时候不用工具。

8 月 9 日这轮重构，核心就是把 WAVE Agent 从“Skill 路由器”重新拆成几种不同的工作模式。

普通问题先当成对话，而不是任务

第一条规则很简单：普通聊天和一般视觉问题直接交给 LLM。

“你好”应该得到自然回复；“目标检测和分割有什么区别”也不需要先搜索 Skill。只有当用户的意图真的落到某个 WAVE 项目能力上时，才继续进入项目上下文或工具系统。

同时，对话上下文不会原样无限送给模型。最近消息先做长度限制和脱敏，再作为必要上下文提供给 LLM。Provider 的凭据也按各自配置隔离，不允许一个服务的凭据被拿去给另一个 Provider 兜底。

这两点看起来不像 Agent 功能，却决定了它是不是一个可以长期放在系统里的组件。

第二类输入是“我想做一个视觉项目”“我需要分析视频”这种方向明确、细节不足的需求。

旧逻辑很容易急着生成一个 Workflow。可如果用户连输入源、目标、实时性要求都没有说清楚，画得再漂亮也只是猜测。

现在这类请求会先进入澄清。Agent 只询问那些会改变流程结构的信息，例如输入是图片还是视频、任务目标是检测还是计数、结果需要实时显示还是离线统计。

7 月底参考 Roboflow Workflows AI Assistant 的公开交互时，我最想借鉴的也不是某个界面，而是这种节奏：先理解场景，再决定流程；生成修改后允许用户保存或回退；在不确定时把选择权明确交还给人。

WAVE 没有也不应该声称复刻 Roboflow 未公开的内部编排。真正能参考的是公开可验证的产品逻辑。

Skill 仍然很重要，只是它不再负责接住所有输入。

例如“分析当前项目状态”是一个边界清楚的任务，它应该调用项目概览 Skill，读取数据集、训练、模型和部署状态，再给出结构化结论。

类似地，数据集审计、训练监控、ONNX 发布这类工作，本身就有固定步骤、输入和验收条件，Skill 很适合把这些经验固化下来。

这样一来，Skill 的价值从“让 Agent 看起来什么都会”变成了“让重复的工程流程有稳定的做法”。

第三类输入是训练、部署、发布等会真实改变项目状态的操作。

这部分我不希望因为聊天变自然，就顺手放宽安全边界。

Agent 可以理解需求、准备参数、调用只读工具，也可以形成 Proposal；但真正开始训练、部署模型或修改重要资源时，仍然需要明确的工具路径和人工审批。

MCP 在这里更像统一的工具入口：Codex、Claude Code 或其他客户端可以看到 WAVE 暴露的能力，但“能看到工具”不代表可以绕过平台自己的权限和审批规则。

我越来越觉得，一个工程 Agent 最重要的能力之一就是知道自己什么时候只有建议权，什么时候才有执行权。

在这次重构之前，Workflow Assistant 已经做过一轮调整：能够针对场景给建议，在缺少关键信息时询问，并根据步骤依赖生成 DAG，而不是把节点随便铺在画布上。

这对视觉任务特别重要。一个“车辆停留检测”流程可能有视频输入、检测、跟踪、区域判断、停留计时和告警；有些步骤串行，有些步骤可以并行。流程图应该来自依赖关系，而不是来自 Agent 对“好看”的想象。

8 月 9 日的改动把这套能力重新接回自然对话入口：用户可以先描述问题，Agent 再决定是继续聊天、澄清、调用 Skill，还是准备 Workflow Proposal。

重构完成后，我专门验证了几个非常普通的输入：

这些测试从技术上并不华丽，但它们终于让 Agent 的行为和人的预期一致了。

以前我总在给 Agent 增加能力。现在开始意识到，真正成熟的 Agent 还需要一套拒绝过度行动的路由逻辑：能回答就回答，需要问就问，适合 Skill 才调 Skill，要改变系统状态才进入工具和审批。

从 Skill 路由器变成视觉工程助手，关键并不是多接了一个模型，而是终于让“理解用户”排在“寻找工具”之前。