[P1] 配置模板页新增 Profile 会走完整安装向导，已装过的 Agent 也一样

[yujiezhang-ops]

在「配置模板」页点「新增 Profile」，会被送进从「选择 Agent」开始的五步安装向导，即使这个 Agent 早就装好了。用户想做的只是加一份配置，却要重新走一遍安装流程。

现状

ProfilesPage.tsx:67-70 直接把新增动作接到 onboarding 上：

// Creating a Profile goes through onboarding: it collects the Agent, Provider,
// model and name in order, tests the saved Provider connection, and the
// install writes the Profile itself.
const startSetup = () => {
  dispatch({ type: "START_SETUP" });
  navigate("/setup/agents");
};

注释把设计意图写清楚了——Profile 是由 install 顺带写出来的，没有独立的创建路径。于是新增 Profile 只能借道安装流程。

落地页 AgentSelectionPage 是无条件的安装语义，标题和描述都写死：

• AgentSelectionPage.tsx:55 — 「选择这次要安装并配置的开发工具，每次安装一个。」
• AgentSelectionPage.tsx:86 — 还会渲染 RuntimePrompt，提示安装 Node/uv 运行时

整页没有一处读 state.status.agents[id].installed。已安装与未安装的 Agent 在这一步长得完全一样。

到最后一步，ActivationPage.tsx:58 把安装标志硬编码为真：

configure: true,
install_agent: true,

对比同一个文件里的桌面 Agent 路径（ActivationPage.tsx:144），那边是判断过的：

const installRequest = desktop.installed ? undefined : api.installDesktopAgent(desktop.id);

CLI 路径没有这个判断。

有一件事需要说清楚：不会真的重装

我核到了 internal/install/install.go:173-180 的幂等短路：

current := ""
if executable != "" {
    current = InstalledVersion(ctx, runtime, agent)
    if version == "" || current == version {
        result.Version = current
        return result, nil
    }
}

ActivationPage 不传 agent_version，所以走 version == "" 分支直接返回，不会执行 npm install -g。所以这不是"重复安装"的数据风险，是用户链路与界面表达的问题。

但代价不是零。install_agent: true 仍然会：

1. 进 ensureAgentRuntime（internal/app/install.go:341），检查并可能引导安装 Node/uv
2. 跑 InstalledVersion 探测版本，即启动一次子进程
3. 让用户读完「正在安装」的全套文案和运行时提示

也就是说用户被迫穿过一条为安装设计的流程，看着与自己意图无关的提示，来完成一件纯配置的事。

建议

三个层次，从小到大：

1. 最小改动：AgentSelectionPage 读 installed 状态，已安装的 Agent 不显示安装语义的文案，RuntimePrompt 也不必出现；requestFor 里 install_agent 改为按状态推导而不是常量 true。
2. 中等：从 ProfilesPage 进入时给流程一个"仅配置"的模式标记，跳过第一步的运行时准备，标题改成配置语义。
3. 彻底：给 Profile 一条独立的创建路径，不再依赖 install 顺带写出。SaveProfile 用例（internal/binding/services.go:395）本身已经能独立保存 Profile，编辑现有 Profile 走的就是它（ProfilesPage.tsx:78）——所以后端能力是有的，缺的是新增时的前端路径。

值得注意的是，ProfilesPage.tsx:72-95 的 save 已经在用 api.saveProfile 直接写了。也就是编辑走独立路径、新增走安装向导，同一个页面上两种行为不一致。第 3 条其实是把新增对齐到编辑已有的做法。

相关

EnvironmentOverviewPage.tsx:21 也 dispatch 同一个 START_SETUP，但那里的入口本来就是"安装新 Agent"，语义匹配，不是问题。

[yujiezhang-ops]

补充：同一个产品里已经有两套「创建 Profile」，行为完全不同

继续排查用户链路时发现，AgentProfilePage（/agents/:id，也就是管理页上「配置」按钮进入的那页）已经有一条独立的 Profile 创建路径，根本不碰安装向导。

AgentProfilePage.tsx:180：

<button className="button button-secondary" type="button" onClick={openCreate} disabled={Boolean(draft)}>
  <Plus size={15} />{t("创建 Profile")}
</button>

openCreate（:87-104）就地生成一个草稿：从现有 Provider 推默认值、按 owner-provider 生成不重复的 ID、带上当前模型，然后 save 直接调 api.saveProfile（:118）。全程没有 START_SETUP，没有跳 /setup/agents，也不需要 Agent 已安装。

对比一下两个入口：

入口	动作	是否走安装向导
/agents/:id 的「创建 Profile」	openCreate → api.saveProfile	❌ 不走
「配置模板」页的「新增 Profile」	dispatch(START_SETUP) → /setup/agents	✅ 走五步

所以这不是"能力缺失"，是两个入口的实现不一致。 原 issue 里第 3 条建议（给 Profile 一条独立创建路径）其实不用从零做——AgentProfilePage.openCreate 就是现成的参考实现，ProfilesPage 只要对齐它即可。

这也让修复范围小了很多：ProfilesPage 本身已经在用 api.saveProfile 处理编辑（ProfilesPage.tsx:78），缺的只是把新增接到同一个 saveProfile 上，并复用 openCreate 那套默认值推导（ID 去重那段逻辑值得抽出来共用，两处都需要）。

顺带记一个相关事实：AgentProfilePage 没有测试文件（frontend/src/pages/AgentProfilePage.test.tsx 不存在），而它是这两条路径里"正确"的那条。如果要把 ProfilesPage 对齐到它，先给它补测试会更安全，否则等于把未覆盖的行为复制到第二处。