LobeHub Agent Goals 产品与 UX 审计指南：产品模型、首屏信息架构与端到端体验验证

本文基于 LobeHub 仓库中的官方产品与 UX 审计文档 agent-goals-product-ux-audit.md 展开成文，系统拆解 Agent Goals（Agent 目标）功能的完整用户旅程审计结论。文中不仅完整还原审计的范围界定、产品概念模型、首屏"五问"视图模型、已落地修正清单与端到端审计矩阵，还结合 Agent Goals 设计方案、Goal 列表/详情页源码与 Goal 状态 store 实现给出可验证的仓库证据。读完本文，你可以掌握 LobeHub 是如何区分 Goal / Acceptance / Task / Task execution / Agent run 五个领域概念的，理解目标列表与详情页应呈现哪些信息、以什么顺序呈现，以及一个诚实的审计应当承认哪些尚未建模的产品边界。

审计范围：一次完整的已实现旅程核查

审计文档首先界定了 Scope，即对"Topic Goal lab gate → Agent 导航 → Goal 列表 → Goal 详情 → Acceptance 检查与最新结果 → 任务执行计划 → Agent runs/operations"这条完整已实现链路逐段核查。这条链路在 docs/development/agent-goals-product-ux-audit.md 中以伪代码形式给出：

Topic Goal lab gate
  → Agent navigation
  → Goal list
  → Goal detail
  → Acceptance checks and latest result
  → Task execution plan
  → Agent runs / operations

审计的证据来源也被明确记录：task 与 acceptance 领域类型、Task 生命周期/store 行为、Goal 列表/详情路由、Agent 导航、Acceptance bundle hooks，以及针对代表性本地数据的浏览器实测。也就是说，这份审计不是纸面评审，而是"领域类型 → store 行为 → 路由组件 → 真实数据渲染"四层证据链的交叉验证——这正是我们在下面各节中会反复引用仓库路径的原因。

对应到当前仓库，这条旅程的实现入口包括：

• Goal 列表页入口：src/routes/(main)/agent/goals/index.tsx/agent/goals/index.tsx) 与项目级入口 src/routes/(main)/project/[projectId]/goals/index.tsx；
• Goal 详情页入口：src/routes/(main)/agent/goal/[goalId]/index.tsx（Agent 名下）与 src/routes/(main)/goal/[goalId]/index.tsx（无负责 Agent 的目标）；
• 核心页面组件集中在 src/features/AgentGoals/；
• Goal 客户端状态集中在 src/store/goal/（action.ts、initialState.ts、selectors.ts）。

产品模型：Goal 是被查找对象，Acceptance 是证据，Task 与 Agent Run 是下钻细节

审计文档用一张"业务角色 vs 终端事实"对照表定义了五个核心概念，这是整个 UI 设计的第一性依据，必须完整理解：

概念	业务角色	终端事实
Goal	Agent 持续追求的一个稳定结果	用户可见的目标保持稳定，而它的计划与运行会不断变化
Acceptance	"结果是否足够好"的决策契约与证据	人的验收关闭交付生命周期；verifier 输出只是支撑证据
Task	当前用于追求 Goal 的可执行计划	Task 状态描述的是执行情况，而非 Goal 是否成功
Task execution	一次由任务 topic 表示的计划性/手动/heartbeat 尝试	产生一个执行结果，可能触发验证或下一轮
Agent run	由一个 Agent 实际执行的 Gateway 操作	提供执行 provenance；它本身不意味着 Goal 已成功

基于这一模型，UI 的职责被严格分层：Goal 是查找对象（lookup object），Acceptance 是被挂接的证据（attached proof），Task / Agent Run 是可下钻的执行证据（drill-down execution evidence）。这条分层原则直接决定了后文的全部信息架构决策。

补充说明：这份审计所依据的产品模型与 Agent Goals 设计方案中提出的"durable goal loop on top of Tasks"架构一脉相承——设计文档中 Goal 是长期存在的 outcome contract，Tasks 是可变执行计划，Topics 是有限次执行尝试，Agent 是 owner 与 executor；两者都强调"不要因为目标长期存在，就把每个 task 变成永久 Agent goal"。

用户视图模型：用户打开 Goals 时，首屏必须回答五个问题

审计把用户打开 Goals 的"第一眼扫描"抽象为五个必须立即得到答案的问题：

1. 这个 Agent 正在追求哪些结果？
2. 哪些 Goal 需要关注？它们距离验收有多近？
3. 在某个 Goal 上，目标到底是什么？
4. 已经发生了多少执行（Task executions 与 Agent runs）？
5. 最新一次验收结果是什么，背后有什么证据支撑？

而时间线、任务配置、单个 topic 与操作（operations）被归为次级审计维度——它们仍可通过执行计划下钻访问，但不应抢占首屏。这是一种典型的"概览优先、细节殿后"信息层级设计，避免用户在扫描阶段就被执行流水细节淹没。

已落地修正：从审计结论反推 UI 决策

基于上述产品模型与视图模型，审计文档记录了六条"Implemented corrections"（已落地修正）。它们逐条对应当前列表页/详情页的组件实现：

1. Goal 列表默认使用紧凑列表以便扫描，并支持显式的 List/Card 切换。 在 src/store/goal/initialState.ts 中，goalViewMode 的默认值即 'list'；AgentGoalsPage.tsx 通过 GoalItem = viewMode === 'list' ? GoalListItem : GoalCardItem 实现两种渲染，工具栏提供 ListIcon 与 LayoutGridIcon 两个显式切换按钮。同时默认过滤 goalListFilter: 'active'，终态目标（代码中以 TERMINAL_GOAL_STATUSES = new Set(['achieved', 'failed', 'canceled']) 表示）被默认隐藏，保证"需要关注"的目标不被已闭环目标稀释。

2. Goal 详情以完整的目标定义开头。 详情页先呈现目标标题，再呈现可滚动展开的 requirement 文档区（GoalRequirement），之后才是过程控制区，确保用户先理解"在追什么目标"。

3. 第一屏接着显示 Acceptance 进度、Task 执行数、Agent run 数、轮次预算与最新验收结果。 审计当时建议把这些指标做成详情页的指标带。从当前仓库的 GoalDetailPage.tsx 看，这一"指标带 + 可下钻"的结构得到了延续与演化：头部渲染 Status / Tasks / Findings / Budget（rounds 或 spend）/ Duration / Liveness 六个 Metric，每个 Metric 都是一个可点击的下钻入口（openGoalMetric(goalId, metric)），点击后在右侧 Portal 中打开对应详情——这正是审计所强调的"指标承载信息、而非装饰"。

4. Acceptance 检查被展示为挂接在 Goal 上的证据，而非一份无关的报告。 这是产品模型直接推演的落地：验收界面属于"证明"而非"报表"。仓库中验收相关能力独立沉淀在 src/features/Acceptance/（如 Viewer/useAcceptanceBundle.ts、Report/ReportViewer.tsx、Viewer/AcceptanceStatusControl.tsx 等），由专门的 acceptance bundle hooks 驱动，服务于"证据挂接"这一角色。

5. 当前执行计划是次级信息，并链接到已有 Task Detail。 执行计划作为下钻目标存在，而非首屏主角，避免用户在"目标是什么、验收了吗"尚未得到答案前就被推进执行流水。

6. 加载中、瞬时错误、未找到、lab 门控深链等状态彼此区分。 这一点在详情页实现中可以直接验证：GoalDetailPage.tsx 用 error && !snapshot 判断并渲染 AsyncError（带 onRetry={mutate} 重试），用 !snapshot && isLoading 渲染 GoalDetailSkeleton，否则渲染 NotFound——因此"目标不存在"绝不会被误报成网络错误。

端到端审计矩阵：七个阶段的期望行为与结论

审计以七个阶段串起整条旅程，并用"Expected behavior → Result"两列给出结论。原表应整体保留：

阶段	期望行为	结果
Gate	关闭 lab 时隐藏导航并重定向 Goal 深链	Covered
Entry	Goal 是 Agent 级别目的地	Covered
Browse	默认列表支持快速对比；Card 视图仍然可用	Covered
Inspect	Goal 定义与进度优先；执行内部细节靠后	Covered
Judge	Acceptance 检查与最新结果可见	Covered
Investigate	用户可以打开底层任务执行计划	Covered
Recover	拉取错误提供重试；缺失 Goal 不报为网络错误	Covered

其中 Gate、Entry、Recover 三行分别对应导航与门控、Agent 级归属、错误恢复这三点"最容易做错"的工程细节。对照当前代码：Browse 行对应上文的默认 'list' 视图与 TERMINAL_GOAL_STATUSES 过滤；Inspect 行对应详情页"标题/需求 → 指标带 → 过程控制"的阅读顺序；Recover 行对应 AsyncError（重试）与 NotFound（区分语义）的双分支渲染。

诚实的未决边界：审计认为还不该做的事

这份审计最有价值的部分，是它明确划出了当前产品模型尚未建模、因此 UI 也不该假装支持的边界。审计文档用三个小节分别论述，任何 UI 迭代都应先回到这些问题：

直接创建 Goal —— 尚未建模为管理页事件

当前 Goal 通过 /goal 对话流创建，该流程会同时创建 goal-marked root Task 与 Acceptance 契约。Goal 页面没有独立的创建事件或表单契约，因此添加一个装饰性的 Create 按钮会承诺一个尚不存在的业务事件。审计指出：未来的切片必须先定义清楚——创建是启动一段对话草稿、立即创建一个持久 Goal，还是打开一个结构化契约编辑器？需要说明的是，后续仓库实现已经在此方向上前进：AgentGoalsPage.tsx 已挂载真正的创建入口（createGoalModal，创建后自动跳转详情页并刷新列表），这印证了审计"先定义业务事件、再补 UI"的顺序判断。

规模化浏览 —— 需要服务端数据能力

当前 Goal 查询上限 100 条且没有游标/搜索契约。对当前"每 Agent 一小批目标"的规模足够，但若要管理一万个 Goal，就必须提供服务端分页、搜索、排序与状态 facet，否则跨全集的计数与空态将不再真实。从 initialState.ts 看，客户端目前只做了 goalListVisibleLimit: 10 的增量渲染（配合列表页 loadMoreGoals），这仍是"本地先切片、再逐页加载更多"的模式，并不能替代服务端游标——审计提出的能力缺口至今依然成立。

专门的 Goal 生命周期操作 —— 有意委托给 Task 执行模型

暂停/恢复/运行这类控制，当前归属于底层的 Task 执行模型。在控制器（controller）定义清楚其业务事件之前——暂停是只停调度、挂起所有外部唤醒，还是终止 Goal 契约——Goal 详情页应当链接到 Task Detail 而非展示语义含混的控制按钮。可以推断，这是一个"等后台领域语义稳定、再决定前台控制面"的取舍；从当前 GoalDetailPage.tsx 的 canPause 逻辑看（仅 ['paused', 'planning', 'running', 'verifying'] 状态下显示暂停/恢复），后续实现已经为 Goal 页补上了受状态约束的暂停/恢复控制，这与审计建议的"避免歧义控制"方向一致，但与 agent_goal_runs 级别的完整生命周期语义（见 agent-goals-design.md 的 agent_goals 表）仍不是一回事。

覆盖度信号：哪些高置信、哪些中置信、哪些明确未覆盖

审计在结论处以置信度对证据做了诚实的评级，这为后续研发排期提供了优先级依据：

• 高置信：导航、门控、列表/详情的信息架构、Acceptance 投影、Task 下钻、本地加载/错误行为。
• 中置信：Agent run 计数是从任务活动（task activities）中的持久化/运行中 operation provenance 推导出来的；未来专门的 Goal 模型应当暴露显式聚合值，而不是依赖投影计算。
• 明确未覆盖（需要更广架构提案解决）：控制器唤醒历史（controller wake history）、成本预算（cost budget）、截止时间（deadline）、租约所有权（lease ownership），以及 Goal 级暂停/终止语义。

换句话说，审计文本本身也在提醒：当前 UI 所展示的"Agent run 数"是投影结果而非一等公民字段，凡是依赖它的场景都应标注为中置信证据。

对照设计与原型文档继续深入

本文的主体（审计文档）是"对已实现切面的核查结论"，而仓库中还并存着两份互补文档，可以帮你把审计中反复出现的领域术语与边界问题对齐到完整架构：

• docs/development/agent-goals-design.md：完整设计提案，覆盖 agent_goals / agent_goal_runs 表结构、GoalDecision 决策联合类型、租约与幂等规则、唤醒源（Agent Signal 路由层）、预算安全、以及 Phase 0–3 的 MVP 演进路径。审计中"Goal 级 pause/terminate 语义未定义""Agent run 应显式聚合"等边界，都能在该文档的 status、leaseOwner、decision 字段设计里找到答案；
• docs/development/goal-graph-cli.md：Goal Graph 运行时 CLI 原型（lh goal create / tick / run / decide / add-node / set-budget 等），说明"目标 → Work 节点 → Task → Finding/Decision"的运行机制，可作为理解"执行计划下钻"与"waiting_human / budget 暂停"语义的最小可运行样例。

两份文档与审计文档一样位于 docs/development/ 下，三份合读可以覆盖"概念（为什么）→ 架构（怎么做）→ 已实现核查（做到没有、还剩什么）"的完整知识闭环。

小结：一次"可复用方法论"型审计

从工程方法论角度看，这份 Agent Goals 审计给出的并非新功能清单，而是一套可复用的"产品化核查模板"：

1. 先定产品模型：区分稳定结果（Goal）与可变计划（Task）、执行尝试（task execution）、执行凭证（Agent run）、验收证据（Acceptance）；
2. 再定首屏契约：明确"第一眼扫描"必须回答的问题，其余信息一律降级为下钻；
3. 用端到端矩阵复核每一段旅程：从门控、入口、浏览、查看、判定、调查到恢复，逐段标注期望行为并验证；
4. 最后诚实标注边界：凡是领域事件尚未建模的能力（直接创建、规模化查询、Goal 级生命周期控制），UI 宁可收敛也不做"假按钮"。

对任何想为长期运行的 Agent 设计管理界面的团队来说，这套"先收敛首屏问题、再设计可验证状态机、最后克制地补 UI"的思路，配合本仓库中可对照阅读的源码实现，是比单一页面截图更有价值的一手资料。