alibaba/anolisa

Component sight What problem are you trying to solve? 是否能增加指定 agent 单 session 的内存占用曲线、cpu占用曲线监测，可标注区分 llm 调用段和toolcall段和空闲段 此处 tool call 时间段定义为，harness识别到需要toolcall发起调用为起点，toolcall返回调用结果到harness为终点的时间段，可直观将session时间段划分为：llm调用段、toolcall段、agent未触发时间段（例如人类在打字思考的时间） 期待定时采集进程mem/cpu占用，并新增toolcall段的起点/终点时间戳 What would a useful outcome look like? dashboard 显示 agent 单 session 的内存占用曲线、cpu占用曲线监测，可标注区分 llm 调用段和toolcall段和空闲段。原始数据可拉取。 资源采样点最小字段 字段 类型 约束 timestamp_ns int64 纳秒精度，必须与 genai_events.start_timestamp_ns / end_timestamp_ns 同一时钟源（CLOCK_REALTIME 或等价），否则曲线与时段条

背景 当前 Agent 看板（/health，AgentHealthPage）的数据来源是 扫描 /proc 目录发现当前运行中的进程（HealthChecker → AgentScanner::scan()）。这导致： 只能看到此刻正在运行的 Agent 进程，大量 Agent 类型缺失 实际使用中经常只显示 Claude 一个卡片，Qoder、Codex、Cursor 等间歇性运行的 Agent 根本看不到 看板的信息价值大打折扣——用户期望看到"这台机器上有哪些 Agent"，而非"此刻哪些进程在跑" 期望行为 Agent 看板的 Agent 列表从 SQLite 数据库查询，展示所有曾被采集到的 Agent： 数据源从 /proc 进程扫描 → SQLite 查询（genai_events.db + trajectories.db） 展示所有出现过的 agent_name，无论当前是否在运行 每个 Agent 显示最后活跃时间、累计调用量等统计信息 当前实现 现有数据流（需要改变） /proc 扫描 → AgentScanner::scan() → HealthChecker → HealthStore（内存）→ GET /api/agent-health

背景 当前 Dashboard 的默认落地页（/）渲染的是 Agent 可观测（ConversationList），即 LLM 调用会话列表。但对于日常运维场景，用户打开 Dashboard 第一眼更想看的是 Agent 看板（/health）——它展示所有 Agent 的在线/离线/挂起状态概览，信息密度更高、更适合作为首页。 期望行为 访问 Dashboard 根路径 / 时，默认展示 Agent 看板（/health 对应的 AgentHealthPage） 如果 agent_health capability 不可用，回退到当前行为（agent_observability → /，否则 /sessions） 当前实现 dashboard/src/App.tsx 中的路由逻辑： const LOCAL_DEFAULT_PATH = "/sessions"; function defaultPath(capabilities: string[]): string { return capabilities.includes("agent_observability") ? "/" : LOCAL_DEFAULT_PATH; } // Route "/" <Route path="/" element={ capabilities.includes("agent_observability") ? <ConversationList /> : <Navigate to={fallbackPath} replace /> } /> 修改建

背景 当前 Agent 看板（/health 页面）以进程（PID）为粒度展示卡片：每个被发现的 Agent 进程独占一张卡片。当用户同时运行多个同类型 Agent 实例时（如开了 3 个终端各跑一个 claude-code），看板会出现 3 张几乎相同的卡片，信息密度低且不易快速掌握全局状态。 期望行为 按 agent_name（Agent 类型）聚合展示： 同一 agent_name 的所有进程合并为一张聚合卡片 卡片标题显示 agent 类型名（如 "Claude Code"），附带进程计数徽章（如 "×3"） 聚合卡片的状态取所有子进程中最严重的状态（优先级：hung > unhealthy > offline > healthy > no_port > unknown） 展开卡片可查看各子进程详情（PID、端口、延迟、状态） 单进程 Agent 保持现有卡片样式不变（无需展开） 示意 ┌─────────────────────────────────────────────┐ │ 🟢

Component anolisa What problem are you trying to solve? Issue #2086 and PR #2171 improved the error for a missing local raw-repository index: local raw repository index not found at /tmp/.../repo/v1/index.toml; check the raw repository URL in repo.toml or, if supplied, the one-off --repo <URL> override That diagnostic identifies the missing index, but users still cannot tell which repo.toml supplied the stale URL. ANOLISA discovers repository configuration from multiple locations (user/site, packaged data, and the development tree), so "check repo.toml" is not enough to recover without inspecting the source code or asking for support. A real user-mode failure was caused by ~/.config/anolisa/repo.toml retaining a file:// URL for an already removed temporary repository. Moving that config aside and retrying allowed ANOLISA to provision its default repository config and complete the install. Reproduction In a temporary user-mode filesystem layout, write repo.toml with [backends.raw].bas