返回 ResolveAI 项目总览 · 交互图：OPERATOR · TASK · MAP
做 Agent 平台时，很容易出现一种“合理但危险”的增长方式：每完成一个能力，就为它增加一个页面。
有了 Prompt 管理，就加 Prompt 页面；有了 Policy，就加 Policy 页面；接入 Knowledge，再加知识库页面；支持评测、失败聚类、校准、回归和发布以后，侧边栏很快变成一份技术对象目录。对开发者来说，这很清楚；对质量运营人员来说，它却把真正的问题藏起来了：我今天先处理什么？判断依据在哪里？处理完以后，怎样让同类问题不再回来？
ResolveAI 的前端收敛不是删掉能力，而是改变首层组织原则：一级页面按运营任务命名，复杂的 Prompt、Policy、Workflow、Tool、Knowledge 和评测证据继续保留在下钻路径中。
本文统一使用 ResolveAI 这一博客项目名称；当前仓库内的产品界面仍显示演示品牌 AgentOne，二者指向同一个实践项目，不代表两个独立系统。
任务地图：首层从“工作总览”进入异常处理，经过运行排查、Case 复盘和复测用例，最后到变更验证；场景、配置和知识是这条任务链的支撑证据。
先分清两个都正确、却不能混在一起的模型
平台内部需要一个技术对象模型。ResolveAI 确实要分别管理场景、配置修订、Context Manifest、Provider Attempt、Policy、Guard、Tool 回执、Workflow 状态、评测资产和 Release Candidate。没有这种拆分，运行失败时就无法定位责任，也无法稳定回放。
但操作界面还需要一个用户任务模型。运营人员面对的不是“我想管理一个 Context Manifest”，而是：
- 指标异常了，我要找到受影响的 Case；
- 客户投诉了，我要判断是真问题还是误报；
- 确认问题以后，我要把它沉淀成可复测资产；
- 有了修复候选，我要确认它修复了原问题，同时没有破坏别的场景；
- 证据就绪以后，我要知道还缺谁的批准，而不是看到一个含糊的“可上线”。
这两套模型都需要存在。错误不在于技术对象多，而在于把技术对象的边界直接复制成用户导航。
GOV.UK 关于内部服务的指导提出，设计管理系统要理解用户试图完成的任务及其工作情境；这类用户可能需要频繁重复、快速切换任务，或在一个位置查看足够信息才能做决定。因此，“一页只做一件事”不能机械套用，关键是用户能否快速完成任务。Services for government users
这给我的启发不是照抄一种页面布局，而是把信息架构的单位从“系统有什么”换成“用户要完成什么”。
当前导航怎样表达真实工作顺序
当前侧边栏只有三组一级语义：
- 发现与处理：工作总览、运行排查、客户案例；
- 沉淀与复测：复测用例、知识内容；
- 配置与发布：业务场景、业务配置、变更发布。
它不是严格的向导，因为运营人员需要在多个任务之间来回切换；它也不是任意菜单，因为分组顺序表达了默认心智路径：先发现和确认问题，再形成可重复验证的资产，最后处理配置与发布。
技术能力没有消失。运行排查仍然可以下钻 Context、Provider、Decision、Policy、Guard、Tool、Workflow 和 Outcome；客户案例仍能看到业务真值、首次偏离和人工复盘；发布中心仍能承载校准、候选、门禁和版本关系。变化只发生在第一层：用户先看到任务语言，进入任务后再看必要技术证据。
工作总览不是仪表盘集合，而是决策队列
很多运营首页会继续犯同一个错误：把所有能统计的东西做成卡片和图表，却没有回答下一步动作。
ResolveAI 的当前总览把“需要你关注”放在质量摘要之前，并提供“处理下一条异常”的主动作。待办区分别显示：
- 等待人工复盘的运行；
- 未达到服务目标的场景；
- 可以沉淀为复测用例的问题。
其下再展示业务问题解决率、模型服务完成率、发布前复测和已形成的保护数量。也就是说，指标用于解释为什么要行动，而不是代替行动。
当前工作树截图：界面仍显示仓库内演示品牌 AgentOne；首屏把待处理异常、质量概览和从问题到复测保护的路径放在一起。这里能证明页面实现，不能证明真实坐席的处理效率已经提升。
这一区分很重要。一个“成功率 50%”的卡片本身不是工作；知道是哪一条 Case 失败、是否需要人工判断、判断后进入哪里，才是可执行任务。
渐进披露不是隐藏复杂度
为了让首屏可读，服务目标与全部运行记录默认折叠。但折叠不是删除，更不能把关键风险藏起来。
当前规则是：
- 首层显示需要行动的数量和状态；
- 展开后显示场景目标、样本量、解决率、Provider 可用率、P95 和关联调查；
- 每条运行保留场景、版本、业务结果、生命周期状态和后续 Case；
- 数据读取失败时显示“数据服务不可用”，不会把空列表冒充“暂无异常”。
渐进披露解决的是认知顺序，而不是信息完整性。用户先判断“是否需要处理”，再进入“凭什么这样判断”。
为什么没有为每项高级能力增加新入口
在项目迭代中，候选生成、独立质询、校准、模式漂移和故障演练都曾有充分理由成为一个独立页面。但如果每项能力都拥有一级入口，平台就会重新退化成能力展厅。
我采用了一个更严格的入口判断：这项能力是否构成用户独立发起、独立结束、并能描述完成条件的主任务？
如果答案是否定的，它就应该进入已有任务上下文。例如：
- AI Case Diagnosis 位于 Case 复盘内，因为它服务于根因判断；
- 候选质询和校准位于发布任务内，因为它们服务于能否进入验证；
- 评测草案进入复测资产工作区，因为它最终需要人工确认真值并版本化；
- 故障演练位于相应能力的验证入口，而不是成为运营首页的中心。
这条规则不会减少后端复杂性，却能阻止复杂性直接扩散到用户心智模型。
这次收敛还没有证明什么
当前证据能证明：导航分组、任务路径、错误状态和详细下钻已经在页面中实现；相关组件测试也验证了入口、链接、折叠和不可用状态。
但它还不能证明：
- 一线运营人员能更快完成复盘；
- 新用户培训成本下降；
- 信息分组适用于不同企业角色；
- 320、375、414 和 768 像素下的所有真实数据状态都完成了本轮重新验收；
- 角色权限已经根据任务自动裁剪。
要把“设计合理”提升为“设计有效”，下一步应使用真实或具备真实经验的运营人员，建立任务基准：完成时间、回退次数、误操作率、需要帮助的次数和证据定位成功率。GOV.UK 也建议把性能指标与用户研究结合，而不是仅依赖数字分析。How to set performance metrics for your service
当前验证证据
2026-09-02，我运行了 App Shell、Overview、Case 证据包和两类 Case 页面共五个聚焦测试文件，28 项测试全部通过。与本文直接相关的反例包括：
- 导航必须显示业务任务名称，不得回退为 Playground、Production Lab 等实现语言；
- 没有真实 Run 时显示空状态与运行入口；
- 数据服务失败时显示不可用，不能显示健康或空列表；
- 运行明细保持折叠，首层不出现 Provider、SLO 适配器等实现术语；
- “沉淀用例”必须进入专门的复测资产工作区。
这些测试验证当前代码合同，不是用户研究。
读者可能关心的边界问题
功能被藏深以后，会不会降低专家效率？
任务型入口不等于删除专家信息。专家仍可从 Case、运行和发布任务下钻完整证据；真正要验证的是高频路径是否少跳转、证据是否在决策上下文内，而不是所有对象是否永远可见。
为什么知识内容还保留一级入口？
知识有独立的生命周期：范围、版本、引用、检索评测和发布都需要被持续治理。它既服务故障调查，也可能由知识运营人员单独维护，因此仍是可独立完成的任务。
怎样判断一个新能力该不该新建页面？
先描述用户、触发条件、完成动作和结束状态。如果它只是在既有任务中提供判断或证据，就进入现有页面；只有当它具有独立责任人、独立开始与完成条件时，才考虑新入口。
这算产品设计还是前端重构？
两者都有，但核心是产品信息架构。代码层改了路由名称、导航层次、首页优先级和详情披露；更重要的是重新定义了用户进入系统时首先看到的对象。
结语
Agent 平台的技术能力会持续增长，用户的注意力却不会同步增长。
因此，一个成熟的工作区不应该把每项能力都变成新的入口。它应当让用户先看见任务、风险和下一步，再在需要时展开完整技术证据。ResolveAI 当前已经把这一原则做成了可运行页面；它下一步需要的不是更多菜单，而是真实角色的任务验证。