Ideation · repo-grounded

Agents 列表页：可见性 / 访问范围字段

· topic: agent-list-visibility-field · mode: repo-grounded（聚焦一轮：3 视角 / 4 存活）

focus: 在 agents 列表页加一个"可见性范围"字段，是否更方便？

Grounding Context（代码库上下文）

Topic Axes

1. what-to-show — 展示哪些权限/可见性数据

2. how-to-display — 列 vs 徽标 vs tooltip；消解 view/invoke 混淆

3. find-and-organize — 按访问范围筛选/分组/排序

4. manage-and-act — 行内/批量编辑、新 agent 默认值

Ranked Ideas

1 有效访问列（三态），而非裸 visibility what-to-show + how-to-display

加一列显示有效的调用范围——"工作区 / 指定人员 / 仅所有者"，由 permission_mode+invocation_targets 合成，不读派生的 visibility。其中"仅所有者"这一态同时承担"自动化/autopilot 无法调用此 agent"的信号（#5230），通过 tooltip/副标说明。

有效访问（3 态） 工作区 · 任意成员/agent 可调用 指定人员 · public_to + member 仅所有者 · 自动化无法触发 派生折叠（丢信息） 裸 visibility（2 态） "workspace" "private" ↑ 指定人员 + 仅所有者 被合并
问题核心：public_to + member 目标的 agent 会被折叠成 visibility:"private"，与"仅所有者"无法区分。三态列保留了这个区分。
Basis
direct: packages/core/types/agent.ts:10-15——"a public_to agent WITH a workspace target maps to visibility:'workspace'; everything else (private, or public_to scoped only to member/team targets) maps to visibility:'private'"。即裸 visibility 把"仅所有者"与"指定人员"合并成同一标签。agent_access.go:48-65 的 canInvokeAgent 对 private / public_to 有截然不同的分支。
Rationale
用户字面诉求（加"可见性列"）若照搬 visibility 会主动误导——一个 public_to+member 的 agent 会显示 "private"，但特定成员其实能运行它。有效访问列一次建立正确心智，且"仅所有者"态把 #5230 的静默丢弃风险提前到最早可见的触点。
Downsides
第 8 列增加横向滚动；建议默认隐藏或同时作为排序/筛选键。标签计算是纯前端、字段已在列表 payload 里。
Confidence
92%
Complexity
Low–Medium

2 经现有批量工具栏批量改访问范围 manage-and-act

在 AgentBatchToolbar（agents-page.tsx:646，现仅归档/恢复）增加"设置访问范围…"动作，用既有 runBatch（:668）逐个套用 AccessPicker 的选择。把"筛选 → 全选 → 设为工作区"变成几秒钟的事，直接移除我们刚被逼着写的 SQL。

Basis
direct: agents-page.tsx:668 的 runBatch 是带失效处理的通用顺序执行器；:661 allManageable 已做行级权限门控；agent-access-settings.tsx 的 AccessPicker 发出 onChange(next) 补丁，逐行可复用。痛点 #2（跨 5 工作区 70 agent 的 UPDATE+INSERT）正是因 UI 无此路径才发生。
Rationale
杠杆最高。此后每次访问范围重组（团队入职、把私有 agent 开放给工作区）都从"有风险、不可重放、需管理员"的 SQL 变成 30 秒、可审计、非管理员可用的 UI 操作。基础设施 100% 复用。
Downsides
需确认对话框护栏（访问范围是安全敏感字段）；"指定人员"批量极易出错，建议批量只开放"工作区 / 仅所有者"两档。
Confidence
90%
Complexity
Medium

3 访问筛选维度 find-and-organize

给 AgentListFilters（view-store.ts:41）加一个 access 多选维度，取值与列一致（工作区/指定人员/仅所有者）。一键隔离某一类，而非扫 80 行或跑 SQL。它也是想法 2 的发现机制——筛选 → 全选 → 批量改。

Basis
direct: view-store.ts:41-54 已有四维（availability/runtimes/owners/models），agents-page.tsx 行筛选是纯前端按字段匹配，加第五维机械一致。痛点 #1（"写 SQL 盘点哪些是私有"）本质就是缺这个筛选。
Rationale
对"盘点"任务，筛选 > 列：列只能逐行扫，筛选直接隔离目标集。也是想法 2 批量流的前置发现步骤。改动极小。
Downsides
取值粒度（二态 vs 三态）需与列保持一致，需团队拍板。
Confidence
90%
Complexity
Low

4 工作区级"新 agent 默认访问范围" manage-and-act / default

工作区设置里设新建用户 agent 的默认 permission_mode（自动化重的工作区可默认 public_to+workspace），内置 agent 显式钉为私有。从源头消除"每个新工作区都要重做一次 70 agent 清理"的积压。

Scope-adjacent（范围相邻）这是一个工作区设置，不是列表页字段；可经由列表页暴露（如横幅提示），但落地在工作区设置。用户聚焦在列表页字段，故此条标记为相邻、可选。
Basis
reasoned: 批量 SQL 是症状，根因是默认值与意图不符——若每工作区 ~14 业务 agent 按意图都该是工作区可调用，则 private-by-default 迫使每个 agent 都要 opt-in。external: GitHub 仓库默认 public、Slack 频道默认工作区可见——协作工具默认共享、私有是 opt-out。
Rationale
唯一能阻止痛点复发的想法。想法 2 是"治理"，本条是"预防"。
Downsides
默认值放工作区级还是所有者级需设计；内置 agent 必须豁免；离开列表页表面。
Confidence
70%
Complexity
Medium

Rejection Summary

#想法剔除理由
—裸 visibility 列（用户字面诉求，照搬）会误导：visibility 是派生的 2 态投影（agent.ts:10-15），public_to+member 的 agent 会显示 "private"。被想法 1 取代。
—独立的"自动化不可达"告警标记并入想法 1——"仅所有者"态已承载该后果。
—行内快切（kebab / 单元格 popover）被想法 2（批量）+ 现有逐 agent inspector 覆盖；杠杆较低的便利项。
—按访问范围排序被想法 3（筛选即可分组）吸收；增量价值低。
—访问范围分布计数 chip 条与想法 3 及既有 scopeCounts 重叠；价值较低。
—axis 覆盖4 个存活已覆盖全部 4 个轴；无空轴。