1683 lines
190 KiB
Markdown
1683 lines
190 KiB
Markdown
# 项目进度文档
|
||
|
||
> 每完成一个里程碑，在此追加记录。任务运行时的逐步进度写在 `data/tasks/{task_id}/progress.md`。
|
||
|
||
> 当前阶段：2026-10-30 纠偏P1基线已测量，任务task_76d551192d7e实际交付2/10位后取证停滞停止，未达标缺8位；47次调用/1140485 tokens/197.77秒。P0真实请求工具列表回执已补齐；等待监督确认后进入P2。停止D44专项；历史段落的“下一步”不作为当前执行计划。D20–D44归档及200行精简留待P5。
|
||
|
||
---
|
||
|
||
## 2026-09-16 D1：项目骨架搭建
|
||
|
||
### 已完成
|
||
|
||
| 项 | 状态 | 说明 |
|
||
|---|---|---|
|
||
| 项目目录结构 | ✅ | Electron + Python FastAPI + SQLite |
|
||
| SQLite 数据库 | ✅ | tasks / skills / knowledge / run_logs / settings |
|
||
| 业务知识配置 | ✅ | 学工系统 `https://school.miaopinai.com:29800/xuegong/` |
|
||
| Python 后端 API | ✅ | 任务创建、状态查询、设置、Browser 调试 |
|
||
| Browser Use 集成 | ✅ | 千问 qwen-vl-max，独立 Chromium 窗口 |
|
||
| Electron 桌面壳 | ✅ | 聊天 + 设置 + 进度时间线 |
|
||
| 任务进度 Doc | ✅ | 每步写入 `data/tasks/{id}/progress.md` |
|
||
|
||
### 待完成（D2+）
|
||
|
||
| 项 | 计划 |
|
||
|---|---|
|
||
| 对话收集必填字段 | D2 |
|
||
| 学工系统探索填表 | D3 |
|
||
| 人工确认提交 + 校验 | D4 |
|
||
| 暂停/恢复（登录接管） | D5 |
|
||
| Skill 复用 | D6 |
|
||
|
||
### 环境要求
|
||
|
||
- Node.js 18+
|
||
- Python 3.11+
|
||
- 千问 DashScope API Key
|
||
|
||
### 启动方式
|
||
|
||
见根目录 `README.md`
|
||
|
||
---
|
||
|
||
## 2026-09-16：切换 DeepSeek 模型
|
||
|
||
| 项 | 状态 | 说明 |
|
||
|---|---|---|
|
||
| LLM 工厂 | ✅ | 支持 `deepseek` / `qwen` 双提供商 |
|
||
| 默认模型 | ✅ | `deepseek-chat` + `https://api.deepseek.com/v1` |
|
||
| 本地 `.env` | ✅ | 已写入 Key（不提交 Git） |
|
||
| 设置页 | ✅ | 可选择提供商与模型 |
|
||
| 任务结果 | ✅ | 完成摘要写入 `artifacts.summary`，轮询可见 |
|
||
|
||
---
|
||
|
||
## 2026-09-16：API 端口改为 8788
|
||
|
||
| 项 | 说明 |
|
||
|---|---|
|
||
| 默认端口 | `8788`（可在 `.env` 修改 `API_PORT`） |
|
||
| Electron | 从 `.env` 读取，与 Python 一致 |
|
||
| npm start | `scripts/wait-backend.js` 按同一端口等待 |
|
||
| 原因 | 避免 8765 被旧进程占用 |
|
||
|
||
---
|
||
|
||
## 2026-09-16：数据层切换 MySQL（Docker）
|
||
|
||
| 项 | 状态 | 说明 |
|
||
|---|---|---|
|
||
| docker-compose.yml | ✅ | `mysql:8.4.11`，绑定 `127.0.0.1:13307`，库 `school_assistant`，utf8mb4，命名卷持久化 |
|
||
| 数据层 | ✅ | `backend/db/database.py` 改为 PyMySQL，函数签名不变，上层代码零改动 |
|
||
| Schema | ✅ | `schema.sql` 改为 MySQL DDL，JSON 列存 inputs / artifacts / content / agent_history |
|
||
| 启动重试 | ✅ | `init_db()` 等待 MySQL 就绪最长约 60 秒，失败给出明确提示 |
|
||
| 配置 | ✅ | `.env` 新增 `MYSQL_*`，`npm run db:up / db:down / db:logs` |
|
||
| 原因 | | 为后续全校共享 skill、按角色取系统账号等中心化数据做准备 |
|
||
|
||
---
|
||
|
||
## 2026-09-16 D1.5：端到端跑通 + 人工介入机制重做
|
||
|
||
### 修复的阻塞问题
|
||
|
||
| 问题 | 修法 |
|
||
|---|---|
|
||
| browser-use 每步 180 秒超时会打断 ask_user 等待 | `ask_user` 改为记录问题并以 `is_done` 结束本轮 run，浏览器 `keep_alive=True` 保活；用户回答后 `agent.add_new_task` 续跑同一个 Agent |
|
||
| 用户回答后状态停在 paused、前端停止轮询 | 编排层统一状态机 collecting/running/paused/submitted/completed/failed；回答走 `/tasks/{id}/human` 后状态回 running，前端继续轮询 |
|
||
| 「继续执行」从头重跑 | 会话仍在则续跑；会话丢失（后端重启）才带补充说明重新执行 |
|
||
| Electron 静默连上旧后端 | Electron 成为后端唯一所有者：启动前 `POST /shutdown` 关旧进程，关不掉再按端口 taskkill；退出时关自己的。`npm run dev` 不再另起一个后端 |
|
||
| Agent 执行历史没落库 | `run_logs.agent_history` 存精简历史（步数、时长、URL 序列、动作序列、错误、最终结果） |
|
||
|
||
### 新增
|
||
|
||
| 项 | 说明 |
|
||
|---|---|
|
||
| system_accounts 表 + `/api/accounts` | 按学生 + 系统存账号，密码 Fernet 加密（`ACCOUNT_ENC_KEY`），运行时经 `sensitive_data` 自动填写 |
|
||
| 每步截图 | `register_new_step_callback` 落 `data/tasks/{id}/steps/step_NNN.png`，桌面端右侧实时显示「Agent 视角」 |
|
||
| `knowledge.learned` | YAML 里人工回填的探索结论，运行时注入 prompt 为「已知信息」，skill 复用的最简形态 |
|
||
| `scripts/eval_run.py` | 同一任务连跑 N 次，统计成功率 / 步数 / 时长，写 `data/eval/*.jsonl` |
|
||
| `success_artifacts_any` | 步骤级完成判据：产物含任一 key 即完成，覆盖 Agent 自评。评测脚本第一轮就抓出了这个判定语义问题 |
|
||
| 前端 | 暂停问题直接出现在对话里，输入即回答；「新任务」按钮；状态中文标签；后端 pid 显示 |
|
||
|
||
### 实测
|
||
|
||
| 测试 | 结果 |
|
||
|---|---|
|
||
| 只读探索基线（无 learned） | 3 次：1 成功 2「失败」。失败两次产物齐全，是 Agent 因没找到留校申请自评失败；平均 31 步 / 181 秒 |
|
||
| 修判定 + 注入 learned 后 | 2 次全部成功，均为 Agent 自评成功；平均 23 步 / 99 秒。步数少 1/4，时长少近一半 |
|
||
| 暂停续跑（强制先 ask_user） | 15 秒进入 paused，会话保活；回答后 21 秒完成，续跑发生在同一浏览器会话，完成后会话释放 |
|
||
| 账号 API | 创建 / 列表（不含密码）/ 解密 / 覆盖 / 删除 全部通过 |
|
||
|
||
### 业务发现
|
||
|
||
测试环境学生端没有「留校申请」模块（模块搜索「留校」无结果）。最接近的是「节假日离返校 → 我的报备」，默认即在校。学生端可提交的申请表单是「请销假 → 发起请假」，字段与 start_date / end_date / reason 对应，建议作为填表里程碑（xgxt_fill_and_submit）的目标。
|
||
|
||
### 下一步
|
||
|
||
1. 填表里程碑：目标改为「请销假 → 发起请假」，填表 → ask_user 逐项确认 → 提交 → 记 application_no，状态进 submitted
|
||
2. 提交前重复申请检查（防重复提交）
|
||
3. 浏览器展开 / 收起（CDP 最小化 / 恢复）
|
||
4. 提交后跟踪：submitted 任务按 next_check_at 定时拉起 check_status 步骤
|
||
|
||
---
|
||
|
||
## 2026-09-17 D2：意图路由 + 业务切换为「辅导员工作日志填报（查课）」
|
||
|
||
### 背景
|
||
|
||
用户实测输入「我想请假…」，Agent 仍去找留校申请：旧 YAML 只有一个写死目标的步骤，不听用户说什么。且测试环境学生端没有留校申请模块。用户决定把演示业务换成辅导员的每月查课日志填报。
|
||
|
||
### 新增
|
||
|
||
| 项 | 说明 |
|
||
|---|---|
|
||
| `backend/nlu.py` | 一次 DeepSeek / 千问调用识别业务并抽取字段（JSON 输出），今天/明天按当天换算；接口失败退回关键词 + 正则 |
|
||
| 多业务 YAML | `businesses[]`：每个业务有 role / intent / required_inputs / workflow / learned；全局 learned 与业务 learned 合并注入 |
|
||
| 对话收集 | 缺必填项时用模型生成的追问回复用户；用户下一句直接送 `/tasks/{id}/inputs` 的 `message`，再抽取合并 |
|
||
| 按角色隔离 profile | `profiles/{user}/{role}`，学生登录态不会残留到辅导员任务 |
|
||
| 目标模板化 | 步骤 goal / instructions 支持 `{class_name}` 等占位符，通用探索用 `{goal}` 承接任意需求 |
|
||
| 提交判定 | `on_success_status: submitted` 只在有提交产物时生效；`cancelled` 产物优先判为 completed |
|
||
| `GET /businesses` | 列出业务、角色、必填项、当前启用步骤 |
|
||
|
||
### 实测
|
||
|
||
| 测试 | 结果 |
|
||
|---|---|
|
||
| 意图识别 | 「辅导员的工作日志填报…班级是计科2301班，听课是今天，听课记录还好还好」→ counselor_worklog，置信度 0.97，班级 / 日期(2026-09-17) / 记录全部抽对；「帮我填一下查课日志」→ 追问班级、听课日期、听课记录 |
|
||
| 只读探索（辅导员） | 214 秒完成。入口：辅导员管理 → 辅导员工作日志 → 日志填报 → 每月查课要求 → 新建填报；表单「查课听课记录」7 个字段，课程名称 / 授课教师 / 班级 / 听课时间必填 |
|
||
| 填报到确认 | 先追问课程名称、授课教师；补充后 372 秒填完（下拉选中计科2301班、日期 2026-09-17），暂停并逐项列出 7 个字段请确认；回复取消后未提交 |
|
||
| 发现的 bug | 取消时 Agent 也保存了 submitted_record，状态被记成 submitted。已修：取消路径保存 cancelled，编排层优先判 completed（单测 5 例通过） |
|
||
|
||
### 观察
|
||
|
||
- 填报 47 步 / 6 分钟偏慢，时间主要花在日期选择器和下拉框上；日期控件 value 正确但一直带 invalid 样式，正式提交时需确认是否影响后端校验
|
||
- 本次辅导员账号「日志填报」任务列表显示无分配任务，Agent 直接用 learned 里的新建表单地址进入，learned 起了作用
|
||
- 请假意图暂路由到通用探索，做请假业务时再加 business
|
||
|
||
### 下一步
|
||
|
||
1. 用户在桌面端真实跑一次填报并确认提交，验证提交结果与状态 submitted
|
||
2. 填报步骤提速：给日期 / 下拉控件写更明确的操作提示，或换千问 VL 对比
|
||
3. 请假业务（含「返校核验未办结」前置处理）作为第二个可提交业务
|
||
4. 提交后跟踪、浏览器展开收起
|
||
|
||
---
|
||
|
||
## 2026-09-17 D2.5：多校隔离、learned 进库自动沉淀、填报提速
|
||
|
||
### 多校隔离
|
||
|
||
不是每所学校都用我们的系统，学校之间的数据必须隔离。knowledge / tasks / system_accounts / learned_entries / skills 都加了 `school_id`，实例在 `.env` 用 `SCHOOL_ID` 声明自己属于哪所学校，所有查询按它过滤。一校一库或多校一库都能用。旧库由 `database._migrate` 自动补列、改主键，历史数据归入本实例学校。
|
||
|
||
### learned 进库 + 自动沉淀（自主学习闭环第一步）
|
||
|
||
| 项 | 说明 |
|
||
|---|---|
|
||
| `learned_entries` 表 | 按学校 / 业务包 / 业务 / 键存，状态 draft → verified / rejected，记录来源任务 |
|
||
| 自动沉淀 `backend/learning.py` | 任务成功后：产物映射（入口地址、菜单结构，探索步骤的表单字段）+ 一次模型提炼"可复用的操作知识"，写入 draft |
|
||
| 注入顺序 | YAML 出厂 learned 打底，库里 verified 的全局条目和业务条目叠加覆盖 |
|
||
| 桌面端 | 右侧「沉淀草稿」面板，采纳 / 忽略；采纳后下次同类任务立刻生效 |
|
||
| 接口 | `GET /learned`、`POST /learned/{id}/verify|reject`、`PUT /learned/{id}`、`GET /learned/export`（导出 YAML 片段用于交付） |
|
||
|
||
首批 10 条草稿的观察：约一半有价值（下拉要派发 mousedown 才展开、先填文本框再处理下拉和日期、选填字段留空、未提交时页面有「有未保存的修改」提示），其余是评测干跑指令带来的噪音或含本次业务数据。已加过滤规则（填报步骤不把 form_fields 当知识、不记录临时指令处理、不复述提示里已有流程），噪音条目已标 rejected。人工审核这一步不能省。
|
||
|
||
### 填报提速
|
||
|
||
| 改动 | 效果 |
|
||
|---|---|
|
||
| learned 里加控件技巧（下拉点文字容器、日期键入回车、任务列表为空时直接开表单地址、先填文本框） | 步数从 47 降到 20 |
|
||
| 填报步骤 `max_actions_per_step: 6`，一步连填多个文本框 | 到确认 18 步 / 158 秒，此前 47 步 / 372 秒 |
|
||
| 评测脚本干跑模式（默认到确认即取消，`--submit` 才真提交），`--supplement` 自动补充追问 | 两次干跑 2/2 成功，总时长 184 秒 |
|
||
|
||
### 下一步
|
||
|
||
1. 用户真实提交一次，验证 submitted 状态和日期控件校验
|
||
2. 第二个业务（同入口的「每周谈心谈话」或学生请假）验证"一条配置一个业务"
|
||
3. 防重复提交检查
|
||
4. 浏览器停靠 / 展开收起，任务列表 UI
|
||
5. 多步串行执行器（跨系统）、密码本管理页
|
||
|
||
---
|
||
|
||
## 2026-09-17 D3：第二个业务「每周谈心谈话」+ 防重复提交
|
||
|
||
### 目的
|
||
|
||
验证"一条 YAML 配置 = 一个业务"是否成立，以及意图识别能否区分同一入口下的相近业务。
|
||
|
||
### 过程
|
||
|
||
| 环节 | 结果 |
|
||
|---|---|
|
||
| 意图区分 | 「查课日志…」→ counselor_worklog 0.95；「记一条谈心谈话…」「每周谈心谈话的日志…」→ counselor_talk 0.95 |
|
||
| 只读探索 | 59 秒完成（入口与查课共用、登录态复用）。表单「谈心谈话记录」7 字段：谈话对象（搜索下拉）/ 谈话时间 / 谈话主题 / 谈话内容 必填，后续跟进 / 重点关注 / 附件 选填 |
|
||
| 一句话抽取 | 「今天和计科2301班的李思涵聊了学业压力，内容是…」→ 谈话对象 李思涵、日期 2026-09-17、主题 学业压力、内容原文，四个必填一次抽全，无需追问 |
|
||
| 干跑填报 | 到确认 15 步 / 81 秒，总 17 步 / 101 秒；确认清单 7 项，谈话对象解析出学号；取消后 artifacts 有 cancelled，状态 completed |
|
||
| 自动沉淀 | 5 条草稿：入口地址、谈话对象下拉选择、重复记录自查、表单地址可直达、选填项留空处理 |
|
||
|
||
新业务的边际成本：一段 YAML（角色、意图描述、必填项、步骤指令）+ 一次探索 + 一次干跑，约 40 分钟。
|
||
|
||
### 防重复提交
|
||
|
||
两个填报步骤都加了指令：提交前先看任务详情页已有记录，同一天同一对象（班级 / 学生）已有记录时 ask_user 询问是否仍要提交。谈心谈话干跑中 Agent 已主动做了这一步（沉淀出「重复记录自查」草稿）。
|
||
|
||
### 下一步
|
||
|
||
1. 用户真实提交一次（查课或谈心谈话任选），验证 submitted 状态与后端校验
|
||
2. learned 自动晋升 + 运维模式开关（用户端隐藏草稿面板）
|
||
3. 浏览器停靠 / 展开收起
|
||
4. 学生请假业务（含「返校核验未办结」前置阻断）作为跨角色样例
|
||
|
||
---
|
||
|
||
## 2026-09-17 D4：真实提交验证 + learned 自动晋升 + 运维模式
|
||
|
||
### 真实提交（用户在桌面端操作）
|
||
|
||
两条查课日志任务真实提交成功：页面提示「填报成功」，历史填报列表新增记录、审批状态「待审批」，任务状态正确落为 submitted。日期控件的 invalid 样式没有影响后端校验。用户在面板里采纳了 4 条经验（重复记录确认、提交成功判定、提交后自动送审、达标规则）。
|
||
|
||
### 自动晋升与运维模式
|
||
|
||
| 项 | 说明 |
|
||
|---|---|
|
||
| 类别与观察次数 | learned_entries 新增 category（control_tip / path / rule / note）、observations、verified_by（human / auto）；模型提炼时同时给类别 |
|
||
| 内容判重 | 模型每次给同一条知识起的 key 略有不同，改为按内容判重：内容相似度 ≥ 0.55，或 key ≥ 0.7 且内容 ≥ 0.45。阈值来自真实草稿对标定（重复对 ≥ 0.57，不相关对 ≤ 0.41） |
|
||
| 自动晋升 | 同一条知识在 ≥ 2 个不同任务里出现、类别为控件技巧或入口路径，自动 verified；系统规则类无论多少次都要人审 |
|
||
| 归并 | `POST /learned/consolidate` 把已有草稿按内容聚类、累计观察次数、触发晋升。对谈心谈话 11 条草稿：4 簇、删 6 条、自动生效 2 条 |
|
||
| 运维模式 | `.env` `OPERATOR_MODE`：开时桌面端显示「沉淀草稿」面板（带类别和观察次数），关时用户端完全无感。交付学校默认关 |
|
||
|
||
### 实测
|
||
|
||
- 谈心谈话干跑第二次：到确认 11 步 / 61 秒（首次 15 步 / 81 秒），沉淀路径带类别正常
|
||
- 自动晋升规则单测 7 例、内容归并单测 4 例通过
|
||
|
||
### 下一步
|
||
|
||
1. 浏览器停靠 / 展开收起（CDP 最小化 / 恢复）
|
||
2. 学生请假业务（跨角色 + 前置阻断样例）
|
||
3. 提交后跟踪：submitted 任务定时回查审批状态
|
||
4. 后台管理 + 服务端层（审核队列、运行监控、知识管理）
|
||
|
||
---
|
||
|
||
## 2026-09-17 D5：浏览器停靠与展开收起
|
||
|
||
### 做法
|
||
|
||
Chrome 仍是独立窗口，由后端通过 CDP 控制：
|
||
- Electron 在窗口移动 / 缩放时计算停靠区域（优先应用右侧，其次左侧，放不下就叠在应用右半边），`POST /browser/dock` 上报
|
||
- 新任务启动时 Chrome 直接按停靠区域定位（browser-use `window_size` / `window_position`）
|
||
- `POST /tasks/{id}/browser/show|hide`：show = 恢复 + 按停靠区域摆放 + 置顶（`Browser.setWindowBounds` + `Target.activateTarget`），hide = 最小化
|
||
- 桌面端「Agent 视角」面板加「展开浏览器 / 收起浏览器」按钮；任务暂停等用户确认时自动展开
|
||
|
||
### 实测
|
||
|
||
| 检查 | 结果 |
|
||
|---|---|
|
||
| 停靠启动 | 上报 (1180, 40, 900×820) 后新任务 Chrome 在该位置打开 |
|
||
| 收起 | CDP 返回 windowState=minimized |
|
||
| 展开 | windowState=normal，left/top 与停靠区域一致 |
|
||
| 无会话 | 409，提示没有活动的浏览器会话 |
|
||
| 停靠区域计算 | 三种屏幕布局（右侧有空、左侧有空、全屏无空）均落在工作区内 |
|
||
|
||
真正内嵌（Electron WebContentsView + cdp_url）留作后续验证，见 DESIGN.md 第 8 节第 5 项。
|
||
|
||
### 下一步
|
||
|
||
1. 学生请假业务（跨角色 + 前置阻断样例）
|
||
2. 提交后跟踪
|
||
3. 后台管理 + 服务端层
|
||
|
||
---
|
||
|
||
## 2026-09-17 D6：前置阻断机制 + 学生请假业务（被拦截样例）
|
||
|
||
### 探索发现
|
||
|
||
以学生身份探索：
|
||
- 「请销假 → 发起请假」点击后被拦：「请先完成未办结的返校核验，或联系辅导员处理。」表单未打开
|
||
- 「节假日离返校 → 返校登记」三个 tab：待返校 0 / 未返校 10 / 已返校 22。学生端补登窗口已结束，页面提示「如实际已到校请联系辅导员核实」
|
||
|
||
结论：这个测试学生的请假前置事项**学生自己解不开，必须辅导员核实**。这正好是跨角色阻断的真实样例。请假表单字段要等阻断解除后再探索。
|
||
|
||
### 机制
|
||
|
||
| 项 | 说明 |
|
||
|---|---|
|
||
| YAML 声明 | 步骤下 `prerequisites: [{id, title, match, resolution: self / other_role / manual, business_id, advice}]`，注入 prompt 为「可能遇到的前置阻断」 |
|
||
| 新工具 `report_blocker(prerequisite_id, message)` | Agent 遇到匹配的系统提示时调用，代替 ask_user；以 is_done 结束本轮，浏览器保活 |
|
||
| self 路径 | 标准化提问「要我现在顺带帮你办吗」；用户同意后，同一个 Agent、同一个浏览器会话用 add_new_task 切到前置业务的步骤目标，办完自动回到原目标，并明确不要为同一前置事项重复上报 |
|
||
| other_role / manual 路径 | 提问里说明要找谁怎么办（YAML advice），用户回「已处理」则重试原目标，回「取消」则任务进入新状态 `blocked`（关浏览器），处理好后可点「继续执行」重跑 |
|
||
| 状态 | 新增 `blocked`，前端标签「被前置事项拦住」，继续按钮可用 |
|
||
|
||
### 实测
|
||
|
||
| 路径 | 结果 |
|
||
|---|---|
|
||
| 真实环境 other_role（学生请假） | 25 秒识别拦截并上报；提问含辅导员处理建议；回复「取消」→ blocked，浏览器关闭，pending 清除 |
|
||
| 模拟 self（临时业务） | 上报 → 回复「是」→ 切到子目标（读出标题、用户名）→ 回到原目标保存 main_done → completed，未重复上报。首版续跑措辞会导致回来后再报一次，已修 |
|
||
|
||
### 下一步
|
||
|
||
1. 跨角色闭环：辅导员端「核实学生返校」业务，解开测试学生的拦截后再探索请假表单并做填报步骤
|
||
2. 提交后跟踪
|
||
3. 后台管理 + 服务端层
|
||
|
||
---
|
||
|
||
## 2026-09-17 D7：密码本升级（跨系统地基）+ 多步串行执行器
|
||
|
||
### 身份模型落地
|
||
|
||
| 项 | 说明 |
|
||
|---|---|
|
||
| 密码本 `system_accounts.role` | 一个人在一个系统一条账号，记录该账号在该系统的身份；`POST /accounts` 接受 role |
|
||
| 角色准入 | 业务声明 role，而当前用户在该系统的账号是别的角色 → 不开浏览器直接告知「需要以 X 身份办理」，任务 failed；没有账号不拦（走 fallback 登录） |
|
||
| 浏览器 profile | 改为 `profiles/{user}/{system}_{role}`：一人一系统一份登录态，测试环境切角色互不干扰 |
|
||
| 多系统凭据 | 任务涉及的所有系统凭据按域名分组装进 `sensitive_data`，占位符带系统后缀（`x_username_lib` / `x_password_lib`），只在对应域名页面替换；登录说明按系统分段 |
|
||
| 允许域名 | 取业务全部步骤所涉系统的并集 |
|
||
|
||
### 多步串行执行器
|
||
|
||
- 业务 workflow 的全部启用步骤按顺序执行，`inputs.step_index` 记录进度；每步可声明自己的 system
|
||
- 同一个浏览器会话：runner 新增 `keep_session`，还有下一步时成功也不关浏览器，下一步用 add_new_task 续跑；最后一步结束才关
|
||
- 前一步产物注入下一步 prompt 的「之前步骤已取得的信息」；每步产物和总结都保留（`summary_{step_id}`）
|
||
- 暂停 / 前置阻断 / 会话丢失重跑都按当前步骤处理；终态看全部步骤（有提交类步骤且真的提交才 submitted）
|
||
- 判定守卫：`success_artifacts_any` 不再把「未获取 / 无法 / 失败」这类占位文字当产物；提示词要求拿不到就不要存
|
||
|
||
### 实测
|
||
|
||
| 测试 | 结果 |
|
||
|---|---|
|
||
| 凭据分组 / profile / 角色准入 / 终态 | 单测通过；准入文案「需要以「辅导员」身份办理，而你在「学工系统」的账号是「学生」」 |
|
||
| 两步同系统业务（读门户模块 → 进请销假读记录数） | 首轮暴露两步之间会话被关、占位文字被判成功；修后 54 秒完成，一个会话，modules 与 leave_count 都拿到 |
|
||
| 谈心谈话干跑回归 | 76 秒到确认，取消后 completed，会话关闭 |
|
||
|
||
跨系统登录在只有一个系统的测试环境里无法实跑，凭据构造和提示词已单测；接入第二个系统时按 YAML 加一条 system 即可。
|
||
|
||
### 下一步
|
||
|
||
1. 辅导员业务「核实学生返校」（普通辅导员业务，由辅导员在自己的端上办；不是同一用户切角色）；之后学生端请假拦截解除，再探索请假表单并做填报步骤
|
||
2. 提交后跟踪
|
||
3. 后台管理 + 服务端层（含桌面端统一身份认证登录、按人过滤业务、按需取凭据）
|
||
|
||
---
|
||
|
||
## 2026-09-17 D8：「核实学生返校」探索——拦截无法从界面解开
|
||
|
||
### 纠正
|
||
|
||
此前把"辅导员解开学生请假拦截"叫作"跨角色闭环"，表述错误。按身份模型，是**另一个人**（辅导员）在自己的端上办「核实学生返校」这个普通业务，学生随后点「继续」；两端联动走服务端（协办请求）。已改 DESIGN.md。
|
||
|
||
### 探索结果（只读，三个角色）
|
||
|
||
| 角色 | 发现 |
|
||
|---|---|
|
||
| 学生（李思涵） | 「返校登记」页只能查看：待返校 0 / 未返校 10 / 已返校 22，补登窗口已结束；「发起请假」被「请先完成未办结的返校核验」拦截 |
|
||
| 辅导员 | 「节假日离返校」是带班工作台（本班概览 / 学生报备明细 / 未返校异常）。报备明细行内只有「查看详情」，弹窗无核实 / 补登操作；未返校异常 0 人；待办中心空；学生管理各子菜单无相关入口 |
|
||
| 系统管理员 | 门户业务模块区为空；待办空；系统设置是集成总线；权限中心只读工作区里能看到「本院 / 全校离返校态势」「请假设置中心」「请假类型字典」等路由，均为查看或配置页，无核实操作入口，也无该拦截规则的配置项 |
|
||
|
||
### 结论
|
||
|
||
「请先完成未办结的返校核验」是学工系统后端的业务规则，作用于该学生的 10 条历史「未返校」记录；**当前测试环境没有任何角色能从界面解开**。这是自家系统的测试数据 / 功能问题，不是助手能绕过的。
|
||
|
||
需要学工团队做其一：清掉测试学生李思涵的历史未返校记录，或提供一个没有阻断的测试学生账号，或在辅导员端补上「核实返校」功能。之后再探索请假表单并做填报步骤。
|
||
|
||
新增业务 `counselor_return_verify`（辅导员核实学生返校）保留，learned 记录了带班工作台的结构，等系统侧有入口后补填报步骤。
|
||
|
||
### 顺带验证
|
||
|
||
- 意图识别：「帮我核实一下李思涵的返校情况」→ counselor_return_verify，学生字段抽出
|
||
- 探索遵守「拿不到就不保存占位文字」：三次探索都没有伪造 form_fields
|
||
|
||
### 下一步
|
||
|
||
1. 等学工团队处理测试数据；期间做提交后跟踪
|
||
2. 后台管理 + 服务端层（含统一身份认证、跨人协办请求）
|
||
|
||
---
|
||
|
||
## 2026-09-17 阶段小结（换会话前）
|
||
|
||
### 已跑通的链路
|
||
|
||
一句话 → 意图识别抽字段 → 追问缺项 → 角色准入 → 按系统 / 角色登录（密码本或测试快捷登录）→ 多步串行执行（同一会话）→ ask_user 暂停续跑 → 前置阻断上报（self / other_role）→ 提交前逐项确认 → submitted / completed / blocked → 自动沉淀 learned（内容判重、自动晋升）→ 浏览器停靠 / 展开收起。
|
||
|
||
已在真实测试环境验证的业务：辅导员查课日志填报（含真实提交）、辅导员谈心谈话记录（干跑到确认）；学生请假被系统后端规则拦住，按决策不纠结。
|
||
|
||
### 决策要点（详见 DESIGN.md 第 7 节）
|
||
|
||
- 桌面端优先，后台 + 服务端层随后；桌面端登录走统一身份认证
|
||
- 学校隔离（school_id）；learned 进库自动沉淀，用户端无感，系统规则类人审
|
||
- 身份模型：人 × 系统一份账号带角色，role 是准入条件，跨系统凭据按域名分组
|
||
- 目标系统自身问题不纠结不绕过；跨人联动本阶段不做
|
||
|
||
### 下一项
|
||
|
||
提交后跟踪：submitted 任务按 `next_check_at` 定时拉起短任务回查审批状态，进 completed / rejected，桌面端通知。
|
||
|
||
---
|
||
|
||
## 2026-09-17 D9：提交后跟踪
|
||
|
||
### 机制
|
||
|
||
| 项 | 说明 |
|
||
|---|---|
|
||
| YAML `tracking` | 业务级：`interval_minutes`、`max_checks`、`step`（只读回查步骤，产物 approval_status / approval_note） |
|
||
| 排期 | 任务终态为 submitted 且业务有 tracking 时写 `next_check_at`，`artifacts.tracking` 记录次数与历史 |
|
||
| 调度循环 | 后端启动时起 `tracking_loop`，每 `TRACKING_POLL_SECONDS` 扫一次到点任务，一次只跑一个；有其他浏览器会话在用时推迟 5 分钟 |
|
||
| 判定 | approval_status 原文归类：驳回词优先 → rejected；待审批类 → pending 继续；通过 / 办结类 → completed（新增状态 rejected） |
|
||
| 接口 | `POST /tasks/{id}/track-now` 立即回查；`POST /tasks/{id}/track-stop` 停止自动回查 |
|
||
| 桌面端 | 已提交任务每分钟轮询，状态变化时提示「审批已通过 / 被驳回」；「立即回查」「停止回查」按钮；状态栏显示最近一次审批状态和下次回查时间 |
|
||
|
||
### 实测（真实提交的查课日志 task_094cc1e30fbd）
|
||
|
||
| 检查 | 结果 |
|
||
|---|---|
|
||
| 立即回查 | 73 秒，读到「未审批」及完整审批轨迹（已分派陈静、赵副书记待处理；上一轮 9/14 由赵副书记审批通过），排下次回查 |
|
||
| 调度自动回查 | 把回查时间改到过去后，77 秒内循环拉起第二次回查并重新排期，history 两条 |
|
||
| 停止回查 | next_check_at 清空，任务仍为 submitted |
|
||
|
||
### 观察
|
||
|
||
- 每次回查会弹出 Chrome 约一分多钟；后续可考虑回查时静默运行（启动后立即收起）
|
||
- 审批人是真人（陈静 / 赵副书记），测试环境里不会自动通过，completed / rejected 两个分支靠状态词归类单测覆盖，真实触发要等审批动作
|
||
|
||
### 桌面端演示版剩余
|
||
|
||
1. UI 产品化：任务列表与历史、确认卡片、接管按钮
|
||
2. 绑定账号界面
|
||
3. 临时单测整理成可重复运行的测试集
|
||
|
||
---
|
||
|
||
## 2026-09-17 D10：桌面端 UI 产品化（Codex 形态）
|
||
|
||
### 改动
|
||
|
||
| 项 | 说明 |
|
||
|---|---|
|
||
| 三栏布局 | 左：任务列表与历史（状态点、业务名、时间，30 秒刷新，点开回放）；中：对话 + 卡片；右：状态、Agent 视角、时间线、沉淀草稿（运维）、进度文档 |
|
||
| 历史回放 | 打开任务时用 progress.md 重建对话：目标、识别结果、每次提问、用户回答、完成 / 失败 / 阻断、跟踪回查 |
|
||
| 确认卡片 | 暂停时按类型渲染：提交确认（确认提交 / 取消 / 我来接管）、前置阻断 self（是先去办 / 否）、前置阻断 other_role（已处理继续 / 先结束）、普通提问（我来接管）；仍可直接在输入框回答 |
|
||
| 结果卡片 | 完成 / 已提交 / 失败（带重试）/ 被拦住 / 审批通过 / 驳回 |
|
||
| 我来接管 | 运行中：`POST /tasks/{id}/takeover` 让 Agent 在下一步前停住并展开浏览器，用户操作完点「接管完成，继续」`/takeover-done`；暂停中：直接展开浏览器 |
|
||
| 头部状态 | 业务名、用户原话、状态标签 |
|
||
| 后端 | `GET /tasks` 返回业务名与目标；`/tasks/{id}` 返回 takeover 标志 |
|
||
| 开发自测 | renderer 在没有 Electron 时回退到 fetch（127.0.0.1:8799），可用静态服务在浏览器里直接测界面 |
|
||
|
||
### 实测（浏览器里以 fetch 回退模式跑真实后端）
|
||
|
||
- 任务列表加载并高亮当前任务；点开已提交的查课任务，回放出目标、识别、两次提问与回答、总结、两次跟踪回查，右侧显示审批状态与下次回查
|
||
- 从输入框发起谈心谈话：识别回复 → 执行中 → 约 90 秒后出现「请确认后再提交」卡片（三个按钮）→ 点「取消，不提交」→ 卡片置灰、回答进对话 → 状态已完成 → 结果卡片 → 列表同步 → 运维模式提示 3 条沉淀草稿
|
||
- 修了两个回放瑕疵（总结重复、跟踪目标被当成完成消息）和一个输入问题（回车键名兼容）
|
||
|
||
### 桌面端演示版剩余
|
||
|
||
1. 绑定账号界面
|
||
2. 临时单测整理成测试集
|
||
3. 回查静默运行、嵌入式浏览器面板（可选）
|
||
|
||
---
|
||
|
||
## 2026-09-17 D11：数据库切换 PostgreSQL 17
|
||
|
||
对照同事项目后决定与其管理端一致，从 MySQL 切到 PostgreSQL。
|
||
|
||
| 项 | 说明 |
|
||
|---|---|
|
||
| docker-compose | `postgres:17.10-alpine`，127.0.0.1:15433，库 school_assistant；mysql 转入 `legacy` profile 只为迁移期保留 |
|
||
| 数据层 | `backend/db/database.py` 改为 psycopg 3（dict_row、Jsonb），SQL 改 PG 方言（ON CONFLICT、BIGSERIAL、JSONB、RETURNING id），函数签名不变 |
|
||
| schema | `schema.sql` 改 PG DDL，updated_at 由应用显式写 |
|
||
| 迁移 | `scripts/migrate_mysql_to_pg.py`：tasks 29、run_logs 30、learned_entries 62 全部迁入，序列已对齐；knowledge 由 YAML 重灌 |
|
||
| 验证 | 数据层测试（任务 / 跟踪 / 运行记录 / 密码本 / 设置 / learned 生命周期 / 归并）全过；后端接口冒烟通过；用户采纳的经验完整保留 |
|
||
|
||
### 下一步（桌面端对齐同事形态）
|
||
|
||
1. 内嵌浏览器技术验证：Electron 远程调试端口 + `WebContentsView`，browser-use 经 CDP 连入
|
||
2. 渲染层 React/TS/Vite 重做
|
||
3. uv + PyInstaller + electron-builder 打包链
|
||
|
||
---
|
||
|
||
## 2026-09-17 D12：内嵌浏览器技术验证（通过）+ 停靠坐标修复
|
||
|
||
### 验证结论
|
||
|
||
`spike/embed/`：Electron 开 `--remote-debugging-port`，主窗口里挂一个 `WebContentsView`；browser-use `Browser(cdp_url=...)` 连接后用 `get_or_create_cdp_session(target_id, focus=True)` 聚焦到该视图，Agent 的导航全部发生在面板里，没有新开窗口，截图正常。
|
||
|
||
踩到并解决的坑：
|
||
- browser-use 安全看门狗把**没有主机名的 URL 一律判为不允许**（file:// 的界面页被当作非法标签页关掉，主窗口一关应用退出）。界面页改用自定义协议 `app://ui/...`，主机名 `ui` 进白名单即可；域名限制另由 Electron 在 will-navigate 层执行。
|
||
- 内嵌模式要排除 `switch` / `close` 等标签页动作，避免 Agent 切到界面页。
|
||
|
||
### 修复
|
||
|
||
用户实际任务失败：Electron 上报的停靠 top 为负（多屏），browser-use 校验 window_position 必须 ≥ 0。runner 启动参数把坐标夹到 0 以上。
|
||
|
||
### 阻塞
|
||
|
||
DeepSeek 账户余额不足（402），Agent 无法调用模型；不影响界面和打包开发，端到端验证等充值或切千问 Key。
|
||
|
||
### 下一步
|
||
|
||
渲染层 React/TS/Vite 重做 + Electron 主进程 TS 化 + 内嵌浏览器接线（后端经 Electron 控制接口申请视图）+ 打包链。
|
||
|
||
---
|
||
|
||
## 2026-09-17 D13：桌面端对齐同事形态（渲染层重做 + 内嵌浏览器接线）
|
||
|
||
### 改动
|
||
|
||
| 项 | 说明 |
|
||
|---|---|
|
||
| 渲染层 | 弃用 vanilla `renderer/app.js`，改 React 19 + TypeScript strict + Vite；组件：Sidebar（任务列表）、TopBar（业务名 / 原话 / 状态标签 / 接管 / 浏览器开关）、Feed（对话 + PauseCard / ResultCard / TakeoverCard）、TaskCard（步骤、时间线、progress.md、运维模式沉淀草稿）、Composer（Enter 发送、Shift+Enter 换行、IME 兼容）、BrowserPanel、SettingsDialog；视觉按同事规范：白底、#f7f7f7 侧栏、黑色 accent、无渐变 / 阴影 / Emoji 图标、Lucide、8px 网格、14px |
|
||
| 主进程 | `electron/*.ts` 用 esbuild 打成 `dist/main.cjs` / `dist/preload.cjs`：`app://ui` 协议服务 `dist/renderer`；`--remote-debugging-port`（CDP_PORT，默认 9333）；`BrowserHost` 每任务一个 `WebContentsView`（独立 partition、域名白名单、Agent 模式拦截用户键盘输入并提示接管）；`control-server.ts` 在 ELECTRON_CTRL_PORT（默认 8797）给后端开 `POST/DELETE /views`、`/views/:id/reveal|hide|mode`；`BackendManager` 起停后端并注入 `CDP_URL` / `ELECTRON_CTRL_URL` |
|
||
| 后端内嵌模式 | `runner.py`：有 `CDP_URL` + `ELECTRON_CTRL_URL` 时向 Electron 申请视图，`Browser(cdp_url=…, allowed_domains=[…, "ui"])` 连入并 `get_or_create_cdp_session(target_id, focus=True)`；排除 `switch` / `close` / `search` / 文件类动作；结束 `browser.stop()` + 删视图（绝不 `kill()`，那会关掉应用）；展开 / 收起 / 接管改走控制接口；无 Electron 时仍走原独立 Chrome 停靠逻辑 |
|
||
| 渲染层与主进程通信 | preload `assistant` 桥：api get/post/put/del、openPath、meta、`browser.viewport`（BrowserPanel 用 ResizeObserver 量出占位区，主进程把视图摆到那里）、`browser.mode`、`browser:state` / `browser:reveal` / `browser:hide` / `browser:user-input` 事件 |
|
||
| 构建 | `npm run check`（tsc）、`npm run build`（esbuild + vite）、`npm start` = build + electron；`scripts/run-backend.js` 自读 .env，不再依赖 electron 目录 |
|
||
| 失败文案 | Agent 因模型 402 / 401 停下时不再说「未在 N 步内完成」，直接提示余额不足 / Key 无效并引导「继续执行」 |
|
||
|
||
### 实测（8799 测试实例，真实学工测试环境）
|
||
|
||
- 应用启动：`app://ui/index.html` 加载，后端 pid 就绪，`/api/meta` 报 `embedded: true`，CDP 列出界面页 target，控制接口 `/health` 正常
|
||
- 查课日志任务：后端向 Electron 申请视图 → 视图导航到学工登录页 → Agent 在面板里快捷登录、进门户、打开新建填报表单、选班级、填日期 / 课程 / 教师 / 记录，**29 步到「请确认后再提交」**；界面出现确认卡片（确认提交 / 取消，不提交 / 我来接管），点「取消」→ Agent 继续 → 任务结束后视图被删除（控制接口 views 为空）
|
||
- 对话回放、任务列表高亮、状态标签、浏览器面板标题 / 地址栏、composer 发送（识别 → 收集资料 → 追问课程名称和授课教师）均通过
|
||
- 修掉的问题：界面先于 uvicorn 绑定端口导致一直显示「后端未连接」→ 每 2 秒重试直到连上，之后每 30 秒复检；任务卡片被包在用户气泡里 → 独立成块；刷新后重新选中任务时地址栏为空 → 主进程在 viewport 变化时补发页面状态
|
||
|
||
### 关键发现：内嵌视图不能「隐藏」
|
||
|
||
browser-use 前 12 步每步白等 15s（截图）+ 15s（导航完成），根因是未展开面板时视图 `setVisible(false)`：Chromium 判定 occluded，页面 `visibilityState=hidden`、不再出帧，`Page.captureScreenshot` 永远不返回。对比实验（Electron 33、Win11 150% 缩放）：
|
||
|
||
| 视图位置 | visibilityState | 截图 |
|
||
|---|---|---|
|
||
| setVisible(false) | hidden | 超时 >25s |
|
||
| 整个移出窗口右侧 / 下方 | hidden | 超时 |
|
||
| 右边缘留 1px 在窗内 | visible | 0.5s |
|
||
| 已出过帧再整个移出 | visible（未重算） | 0.9s，不可靠 |
|
||
|
||
结论写进 `browser-host.ts` 的 `park()`：不展示的视图停到窗口右边缘外、留 2px 在窗内（抵消 DIP 取整），窗口 resize 时重摆。修后新建视图截图 0.08s。
|
||
|
||
### 阻塞与剩余
|
||
|
||
- DeepSeek 余额中途再次耗尽（402），本次实测在「取消」之后被打断；充值后需重跑一次完整的确认提交 + 沉淀 + 跟踪链路
|
||
- 打包链（uv 管 venv + PyInstaller onedir 后端 + electron-builder extraResources，Windows 目标）
|
||
- 登录配方支持统一认证（配置 + 提示词）、测试集、后台管理
|
||
|
||
---
|
||
|
||
## 2026-09-17 D14：打包链（uv + PyInstaller + electron-builder，Windows）
|
||
|
||
### 改动
|
||
|
||
| 项 | 说明 |
|
||
|---|---|
|
||
| 后端路径 | `backend/config.py`：`ASSISTANT_HOME`（.env / data / profiles 所在，打包后 Electron 指到 userData）、`KNOWLEDGE_DIR`（打包后指到 resources/knowledge）；冻结时默认 exe 目录。`database.py` 的 profile 路径改用 `PROFILES_DIR` |
|
||
| 后端入口 | `backend/main.py`：`--selfcheck` 只导入全部依赖与本项目模块并打印版本 JSON（不连库不监听），供打包验收；`uvicorn.run(app)` 传对象不传字符串（冻结后本文件是 `__main__`，按字符串再导入会把模块跑两遍） |
|
||
| 依赖 | `backend/requirements.txt` 固定为实测通过的版本（browser-use 0.13.10、fastapi 0.141.1、uvicorn 0.53.0、psycopg 3.3.5…）；`requirements-build.txt` 放 PyInstaller；`npm run backend:lock` 用 uv 生成带哈希的 `requirements.lock`（121 包，按当前 .venv 冻结结果约束，所以锁的就是测过的那一组） |
|
||
| 环境脚本 | `scripts/setup-backend.mjs`（`npm run backend:setup`）：找 uv（PATH / ~/.local/bin / ~/.cargo/bin，找不到就用系统 Python 的 pip 把 uv 装进 native/build/uv-bootstrap）→ `uv venv --python 3.12 .venv` → `uv pip sync --require-hashes` → 核对 browser-use / PyInstaller 版本 |
|
||
| 冻结脚本 | `scripts/package-backend.mjs`（`npm run backend:package`）：PyInstaller onedir → `native/release/school-assistant-backend/`；参数：`--python-option "X utf8"`、`--collect-submodules backend`、`--add-data schema.sql`、`--collect-all browser_use / bubus / cdp_use`、`--recursive-copy-metadata browser-use`、`--collect-submodules uvicorn / psycopg`、`--collect-all psycopg_binary`。验收两步：exe `--selfcheck`；本机 PG 可达时真起一次（等 /api/health 再 /api/shutdown）。结果写 `native/build/package-smoke.json` |
|
||
| 安装包 | package.json `build`：appId `com.qiekj.school-assistant`、productName `SchoolAssistant`、asar、`extraResources` 把冻结后端放到 `resources/backend`、`knowledge/*.yaml` 放到 `resources/knowledge`；`win.target dir`、`signAndEditExecutable false`（不下载签名工具）。`npm run package:win` = build + backend:package + electron-builder |
|
||
| 主进程打包态 | `main.ts`：`app.isPackaged` 时 HOME = userData，首次运行把 asar 里的 `env.example`（build 脚本从 .env.example 复制到 dist/）拷成 `.env`；后端改为 `packagedBackendLaunch` 起 `resources/backend/school-assistant-backend.exe`，cwd = userData，注入 `ASSISTANT_HOME` / `KNOWLEDGE_DIR`。`backend.ts` 抽出 `BackendLaunch`（command / args / cwd / env），dev 与打包两套 |
|
||
| 其他 | `.gitignore` 加 `native/`、`release/`；`.env.example` 去掉 MySQL 段；`npm run backend:setup` 会卸掉锁外的 aiosqlite / pymysql（都是废弃依赖） |
|
||
|
||
### 实测
|
||
|
||
| 项 | 结果 |
|
||
|---|---|
|
||
| `backend:package` | PyInstaller 约 2.5 分钟；产物 101.8 MiB；selfcheck 通过（frozen=true，browser-use 0.13.10）；冻结后端真实启动 3.1 秒到 /api/health（连本机 PG 15433） |
|
||
| `package:win` | `release/win-unpacked/SchoolAssistant.exe`，整目录 407 MB（Electron 33 约 250 MB + 后端 102 MB + asar） |
|
||
| 安装包形态运行 | 启动后后端进程是 `resources/backend/school-assistant-backend.exe`；`/api/meta` `embedded: true`；界面「已连接 · 运维」，任务列表 31 条；composer 发「帮我填今天的查课日志…」→ 识别 → 收集资料追问课程名称和授课教师；关窗口后后端随之退出、端口释放 |
|
||
| userData | `%APPDATA%\school-assistant\`（Electron 按 package.json `name` 取）：`.env`（首次运行从模板复制）、`data/`、`profiles/`；知识 YAML 在 `resources/knowledge` |
|
||
|
||
### 踩到的坑
|
||
|
||
- PyInstaller 的 bootloader **不读 PYTHONUTF8**：冻结后解释器在中文 Windows 上是 GBK 模式，stdout 上的路径成了乱码，带 emoji 的 progress.md 写入也会炸。用 `--python-option "X utf8"` 让解释器进 UTF-8 模式。
|
||
- 冻结后只有 browser-use 有 dist-info（`--recursive-copy-metadata`），`importlib.metadata.version('fastapi')` 抛 PackageNotFoundError；selfcheck 改为退回 `__version__`。
|
||
- electron-builder 的 `extraResources` 会漏掉点开头的文件（`.env.example` 没进 resources），模板改为随 asar 打包。
|
||
|
||
### 剩余
|
||
|
||
- 安装器：目前只出 `dir`（免安装目录），NSIS 安装包 / 图标 / 签名待做
|
||
- 打包态只支持内嵌浏览器模式（不带 Chromium，也不该带）；独立 Chrome 停靠仅供源码调试
|
||
- DeepSeek 充值后在安装包形态跑一次完整的确认提交 + 沉淀 + 跟踪
|
||
- 锁文件只在 Windows x64 / Python 3.12 验证过
|
||
|
||
---
|
||
|
||
## 2026-09-17 D15：模型 Key 兜底（主 Key 余额不足自动切换）
|
||
|
||
用户提供了第二把 DeepSeek Key 作兜底。主 Key 402 Insufficient Balance 时不再让任务失败，而是切到兜底 Key 继续。
|
||
|
||
| 项 | 说明 |
|
||
|---|---|
|
||
| 配置 | `.env` `DEEPSEEK_API_KEY_FALLBACK` / `DASHSCOPE_API_KEY_FALLBACK`（只在 .env，不入库）；`LLM_PRIMARY_RETRY_HOURS`（默认 1）切到兜底后多久重试主 Key |
|
||
| 状态 | `backend/browser/llm_keys.py`：`llm_primary_exhausted_at` 存 settings 表，重启不丢；超过重试周期下一次先试主 Key，成功即清标记（充值后自动恢复），仍 402 再记一次 |
|
||
| NLU / 沉淀 | `nlu._call_llm`：主 Key 402 当场用兜底重发；去掉 response_format 的重试不再对余额错误生效（避免多打一次） |
|
||
| Agent | `llm_factory.FallbackChatModel`：包装两份 ChatDeepSeek，对 browser-use 表现为普通 BaseChatModel；某一步 402 就切兜底重发这一步，任务不中断；构造时若标记已设直接从兜底起 |
|
||
| 可见性 | `/api/meta.llm`（fallback_configured / using_fallback / primary_exhausted_at）；侧栏状态徽标多一段「兜底 Key」；设置弹窗说明兜底状态；runner 的 402 失败文案区分「主 Key 与兜底 Key 都 402」 |
|
||
|
||
### 实测
|
||
|
||
- 切换逻辑自测：假主模型抛 402 → 第一次调用即返回兜底结果，主模型只被调 1 次；标记落库；新建包装对象直接使用兜底；`nlu._call_llm` 同样切换；清标记后恢复
|
||
- 两把真实 Key 各发一次最小请求均 200（主 Key 已充值恢复），NLU 走 llm 路径置信度 0.95
|
||
|
||
### 内嵌视图 hidden 的真正根因（D13 的 2px 停放只是部分修复）
|
||
|
||
D13 里「视图隐藏就不出帧」的结论仍成立，但今天面板收起时仍出现每步 15s+15s 的截图 / 导航超时，且把视图摆进面板也无效。逐条 CDP 命令试出：对视图发 `Emulation.clearDeviceMetricsOverride` 后立刻 visible、截图 0.06s。
|
||
|
||
原因：后端是 Electron 拉起的子进程，browser-use 探测不到屏幕就把 profile 判成 headless，`viewport` 取默认值，之后每次 AgentFocusChangedEvent / TabCreatedEvent 都对目标发 `Emulation.setDeviceMetricsOverride`；Electron 的 `WebContentsView` 被设备指标模拟后 `document.visibilityState` 变 hidden、停止出帧。它还会 `Browser.setWindowBounds` 改 Electron 主窗口尺寸（1360×860 被改成 1569×893）。
|
||
|
||
修法（`runner.py` 内嵌分支）：`Browser(cdp_url=…, headless=False, no_viewport=True, viewport=None, window_size=None, screen=None, …)`，并在 `get_or_create_cdp_session(target_id, focus=True)` 之后再发一次 `Emulation.clearDeviceMetricsOverride` 兜底。修后面板收起、窗口在后台：视图 visible 1024×720，截图 0.09s，全程无超时。
|
||
|
||
### 安装包形态完整链路实测（2026-09-17 17:40，`release/win-unpacked/SchoolAssistant.exe`）
|
||
|
||
| 环节 | 结果 |
|
||
|---|---|
|
||
| 启动 | 后端进程为 `resources/backend/school-assistant-backend.exe`，`embedded: true`，兜底 Key 已配置、当前用主 Key |
|
||
| 执行 | 查课日志（数据结构 / 李老师 / 计科2301班 / 2026-09-17）：17:40:13 视图就绪 → 17:41:38 到「请确认后再提交」，逐项列出 7 个字段 |
|
||
| 提交 | 回答「确认提交」→ 17:42:07 `submitted`；`submitted_record` 完整，`result_message` 记到「历史填报新增一条 … 未审批」「本期有效填报 3 / 3」 |
|
||
| 沉淀 | 3 条草稿：系统规则「本期达标状态显示」「草稿弹窗处理」、备注「历史填报条数变化」（运维模式待审） |
|
||
| 跟踪 | `next_check_at` 自动排到 1 小时后；「立即回查」返回「审批状态：未审批」，tracking history 记录 pending |
|
||
| 收尾 | 关窗口后端退出、端口释放；整轮 45 步（含回查）0 次截图超时、0 个 Traceback |
|
||
|
||
D14 里「充值后在安装包形态跑一次完整链路」已完成。
|
||
|
||
---
|
||
|
||
## 2026-09-17 D16：测试集（pytest）+ 两个由测试挖出的缺陷
|
||
|
||
### 测试集
|
||
|
||
`npm test`（全量，需 PostgreSQL）/ `npm run test:fast`（跳过数据库测试）。**288 个用例，3.4 秒**。
|
||
|
||
| 文件 | 覆盖 |
|
||
|---|---|
|
||
| `tests/test_nlu.py` | JSON 解析（围栏 / 夹在散文里 / 非法）、相对与绝对日期归一、关键词退路、`classify_and_extract` 在模型失败 / 无 Key / 编造业务 / 占位值下的行为、`_call_llm` 的 402 切兜底 Key |
|
||
| `tests/test_status.py` | 审批归类（驳回词优先于通过词）、回答的肯定 / 否定、产物占位文字、`_criteria_met`、`_final_status`（取消优先于已提交）、跟踪配置 |
|
||
| `tests/test_blocker.py` | `self` / `other_role` / 未声明三种前置阻断的问句，保证「顺带帮你办」不会出现在需要别人处理的路径上 |
|
||
| `tests/test_credentials.py` | Fernet 加解密与错误 Key 提示、占位符带系统后缀、凭据按域名分组（A 系统密码不进 B 系统域名）、profile 路径与 Electron 分区名 |
|
||
| `tests/test_workflow.py` | 缺项收集、多步 `step_index` 推进与夹取、步骤覆盖系统、角色准入四种情况、模板渲染缺字段不抛错、提示词分块隐藏内部键 |
|
||
| `tests/test_learned.py` | 相似度与内容判重、类别合并、填报步骤不沉淀表单值；**数据库层**：写入 / 合并 / 不重复计数 / 控件技巧自动晋升 / 规则类不自动晋升 / 已审核不再起草 / 只有 verified 进提示词 / 多校隔离；密码本 upsert 与多系统 |
|
||
| `tests/test_runner.py` | `verdict_from_history` 五种终态、402 / 401 的用户可读文案、历史精简（URL 去重、接口变动不抛错）、内嵌模式开关与动作排除、停靠坐标夹取 |
|
||
| `tests/test_llm_keys.py` | 402 识别（限流 / 401 / 超时不算）、主备选择、耗尽标记持久化与到点重试、`FallbackChatModel` 的切换 / 不重复撞主 Key / 500 不消耗兜底 Key |
|
||
|
||
分层：`@pytest.mark.db` 的 15 个用例需要本机 PostgreSQL，不可达时自动跳过（`npm run test:fast` 是 273 通过 1.9 秒）。数据库测试把 `settings.school_id` 换成一次性的 `pytest_xxx` 学校，跑完删干净，靠的正是产品自身的多校隔离；实测 demo_school 的 67 条 learned 不受影响。
|
||
|
||
为了能不起浏览器就测到核心判定，从 `_run_agent` 里抽出两个纯函数：`verdict_from_history(compact, max_steps)` 和 `window_kwargs_for(bounds)`，行为不变。
|
||
|
||
### 测试挖出的两个缺陷（已修）
|
||
|
||
**1. 关键词退路形同虚设。** `_fallback` 要求业务名 / intent 里的整段短语原样出现在用户原话里。知识里写「每月查课日志」，用户说「帮我填今天的查课日志」，整段不匹配即 0 分。实测四句真实说法全部落到 `generic_explore`：
|
||
|
||
| 用户原话 | 修前 | 修后 |
|
||
|---|---|---|
|
||
| 帮我填今天的查课日志，班级计科2301班 | generic_explore | counselor_worklog |
|
||
| 我要填每月查课要求的日志 | generic_explore | counselor_worklog |
|
||
| 帮我记一条谈心谈话…… | generic_explore | counselor_talk |
|
||
| 帮我核实一下李思涵的返校情况 | generic_explore | counselor_return_verify |
|
||
|
||
这条路径正是模型不可用（402、断网）时的保底，等于没有保底。改为按最长公共子串打分（少于 2 字不算），并把 `generic_explore` 排除出打分（它的 intent 含「查找某个入口」，会抢走具体业务）。九句真实说法全部路由正确。
|
||
|
||
**2. 单字肯定词在句中任意位置命中。** `_is_affirmative` 里「是 / 好 / 行 / 办 / 去 / 对」用的是子串包含，用户补充资料回答「课程是高等数学」会被判为「同意先办前置事项」，把任务带去办另一个业务。改为多字词任意位置、单字词只在开头。
|
||
|
||
### 剩余
|
||
|
||
NSIS 安装器 / 图标 / 签名、统一身份认证登录配方、手册导入、后台管理 + 服务端层。
|
||
|
||
### 补记：第三个缺陷（真实回归跑挖出）
|
||
|
||
改完上面两处后真实跑一次取消流程，终态是 `failed` 而不是 `completed`。查下来：`worklog_fill_and_submit` 没声明 `success_artifacts_any`，「产物达标可覆盖 Agent 自评失败」那条分支从来不生效；用户点取消后，终态取决于 Agent 那一步随手给的 `is_successful`——它不稳定，同一个取消动作 17:36 那轮记成已完成、18:29 这轮记成办理未完成。
|
||
|
||
修法：把覆盖逻辑抽成纯函数 `apply_verdict_overrides(verdict, agent_done, step, artifacts, summary)`，并新增一条——产物里有有效的 `cancelled` 就按成功处理（用户主动取消不是办砸了），排在原来的 `success_artifacts_any` 判据之前。补 7 个用例钉住，含「占位文字的 cancelled 不算」「跑满步数时不能靠产物翻案」。修后同一流程真实跑通：41 步到确认卡，回答取消 → `completed`，产物 `summary` / `cancelled` 齐全。
|
||
|
||
（这轮另有 2 次截图超时，都落在 Agent 用 `evaluate` 读写页面的步骤上，页面忙时的瞬时现象，任务照常完成、视图正常销毁，与 D13 的系统性 hidden 问题无关。）
|
||
|
||
测试集最终 **295 例 / 3.9 秒**。
|
||
|
||
---
|
||
|
||
## 2026-09-17 D17：后台管理（中心服务端 + 经验审核台）
|
||
|
||
自主学习这条线原本缺最后一段：草稿产生在各校桌面端，团队只能挨个开运维模式去看。现在补上中心。
|
||
|
||
### 形态
|
||
|
||
```
|
||
各校桌面端 中心服务端 (8801)
|
||
办完事沉淀草稿 ──上报（带学校凭证）──▶ 审核队列（按内容跨校合并）
|
||
↓ 智能预审 + 人工采纳 / 驳回 / 改写
|
||
本地 learned ◀──按版本号增量拉取── 已发布（可选只回来源校或发给所有学校）
|
||
```
|
||
|
||
| 组件 | 说明 |
|
||
|---|---|
|
||
| `server/` | FastAPI，独立库 `school_assistant_hub`（同一 PostgreSQL 实例，启动时自动建库）。`/sync/*` 给桌面端（学校 token），`/api/*` 给后台（可选 console 口令） |
|
||
| `console/` | React/TS/Vite 审核台，构建到 `dist/console`，由服务端直接伺候，不单独起前端。视觉沿用桌面端那套规范 |
|
||
| `backend/hub_sync.py` | 桌面端侧：沉淀后自动上报、启动起定时循环（默认 15 分钟）、`POST /api/hub/sync` 手动触发。没配 `HUB_URL` / `HUB_TOKEN` 就整个关掉，单机照常工作 |
|
||
| `shared/knowledge_match.py` | 判重规则抽出来两边共用，保证桌面端和中心的合并结果一致 |
|
||
|
||
### 关键设计
|
||
|
||
- **跨校合并**：同一条知识被多所学校各报一次，中心按内容合并成一条，`school_count` 是几所学校观察到过。这是最强的可信信号，预审据此直接建议采纳。
|
||
- **发布范围**：采纳时选「仅来源学校」或「所有学校」。跨校成立的经验才推给所有人，某校特有的留在本校。
|
||
- **驳回也要发布**：本地可能已经自动晋升过一条错知识，中心驳回后必须把结果送回去，桌面端据此置为 rejected，停止注入提示词。
|
||
- **增量拉取**：每次审核分配一个全局递增版本号，桌面端记住拉到哪，只拉增量。
|
||
- **凭证**：每校一串，只在生成时显示一次，库里存 SHA-256。重置即旧凭证失效。
|
||
- **同步永不影响办事**：全部后台异步，失败只记一行 `hub_last_error`，任务照跑。
|
||
|
||
### 智能预审
|
||
|
||
两层。规则层不需要模型永远可用：内容过短直接建议驳回；**跨校观察排在最前面**；整条基本只剩日期 / 班级 / 人名判为一次性数据；系统规则类一律要人工。模型层（配了 Key 才跑）判断这条是可复用的操作知识还是本次任务的具体数据，可给改写建议。建议永远只是建议，不自动改状态。
|
||
|
||
预审规则第一版有个误判：「班级是下拉框……选项形如「计科2301班（计算机科学与技术）」」这条被一次性数据的正则抢先判成需人工。它是 2 所学校都报过的控件技巧，里面的班级只是举例。改为跨校信号优先、且只在条目很短又不含操作词时才判一次性数据，7 个真实样例全部正确。
|
||
|
||
### 实测
|
||
|
||
- 冒烟：注册两校 → 错 token 被 401 拦 → A 校报 3 条 → B 校用不同 key 报同一条知识合并成功（`school_count` 2）→ 预审 → 采纳一条发给所有学校、驳回一条 → A 校拉到 2 条、B 校拉到 1 条、再拉 0 条 → `scope=origin` 的条目只有来源校拿得到
|
||
- 真实数据：把本地 47 条草稿灌进中心，自动合并掉 1 条重复；后台界面渲染正常，点「采纳」真的改了服务端状态（46 → 45 待审，版本号递增）
|
||
- 闭环：桌面端上报 47 条 → 中心改写并采纳（范围所有学校）+ 驳回一条 → 桌面端拉回 6 条 → 改写后的内容出现在会注入提示词的经验里、`verified_by=hub` → 中心驳回的那条在本地也变成 rejected
|
||
- 测试：新增 38 例（预审规则、凭证、跨校合并、发布范围与版本、桌面端落地、未配置时静默），全量 **333 例 / 9.5 秒**
|
||
|
||
### 顺带修掉
|
||
|
||
`_apply_schema` 把多行 SQL 拼成一行执行，行尾 `--` 注释会把后面的列定义一起注释掉。中心库第一次建表就踩到了。桌面端那份 schema 恰好没写行尾注释所以没暴露，同样修掉。
|
||
|
||
### 怎么跑
|
||
|
||
```powershell
|
||
npm run hub:build # 构建审核台界面
|
||
npm run hub # 启动中心服务端，后台在 http://127.0.0.1:8801/
|
||
```
|
||
|
||
在后台「学校」页给每所学校生成凭证，写进那台机器的 `.env`（`HUB_URL` / `HUB_TOKEN`），重启桌面端即接入。
|
||
|
||
### 剩余
|
||
|
||
跨校推送目前只有「所有学校」这一档，没有按学校分组；运行监控（成功率 / 步数 / 时长趋势、失败截图）还没做；后台没有多人账号，靠单个 console 口令。
|
||
|
||
---
|
||
|
||
## 2026-09-17 D18：智能采纳（自动清空审核队列里能自动定的部分）
|
||
|
||
审核台上线后队列一次就是 43 条，全靠人点不现实。加一条智能采纳，但**不是「模型说采纳就采纳」**。
|
||
|
||
### 判定规则
|
||
|
||
类别是硬门槛：**只有控件技巧和入口路径可能被自动采纳，系统规则和其他类永远留给人**，模型再有信心也不行。一条错的系统规则会让 Agent 以后一直绕开正确操作。
|
||
|
||
过了类别门槛后两条路都能走到自动采纳：
|
||
|
||
| 路径 | 条件 | 发布范围 |
|
||
|---|---|---|
|
||
| A 证据够硬 | 跨校观察 ≥ 2 所，或单校观察 ≥ 3 次；配了模型且要求一致时模型不能反对 | 跨校的发所有学校，单校的只发回本校 |
|
||
| B 模型背书 | 证据薄，但模型读过内容、比对过已采纳条目后明确说可复用 | 强制只发回来源学校 |
|
||
|
||
自动驳回要两层一致，或模型单独认定是一次性数据而规则层不反对。
|
||
|
||
### 三条安全边界
|
||
|
||
1. **自动驳回只是暂缓，人工驳回才是终局。** 之前被驳回的条目再上报会被跳过，机器误判一次就永久吃掉一条知识。现在按 `reviewed_by` 区分：auto 驳回的再被观察到会退回队列重新排队，并保留已积累的跨校证据；human 驳回的不复活。
|
||
2. **模型想改写就不自动采纳原文。** 模型给出 rewrite 时说明原文不够好，采纳原文没意义，留给人确认（理由里直接带上改写建议，粘贴即可）。
|
||
3. **干跑先行。** 后台「智能采纳」页先点「先看会动哪些」，列出每条的处置和理由，确认后再执行。单次上限 50 条。自动处理过的标记 `reviewed_by=auto`，队列里可筛出来复查，审错了点「退回待审」会分配新版本号推回各校。
|
||
|
||
上报后自动触发（`HUB_AUTO_ON_REPORT`）默认关闭，先手动跑几次看准了再打开。
|
||
|
||
### 实测（真实的 43 条队列，DeepSeek 做模型层）
|
||
|
||
第一版判定顺序有问题：规则层证据不足就先返回 hold，模型层根本没机会说话，43 条只自动处理 3 条。改成证据和模型背书并列后：
|
||
|
||
| 阶段 | 自动采纳 | 自动驳回 | 留给人工 |
|
||
|---|---|---|---|
|
||
| 只有规则层 | 3 | 0 | 40 |
|
||
| 加模型层（修判定顺序前） | 3 | 0 | 40 |
|
||
| 加模型层（修后） | 19 | 2 | 22 |
|
||
|
||
两条自动驳回都是带任务 UUID 的入口链接，规则层因为内容长又含「入口」二字漏掉了，模型抓出来了。真执行一轮后队列从 39 降到 26，剩下的 26 条里 20 条是按策略必须人审的系统规则和其他类，6 条是模型建议改写或未明确认可的。整轮 31 秒，桌面端随后拉回 17 条。
|
||
|
||
测试新增 26 例（类别硬门槛、两条采纳路径、改写守卫、自动驳回可复活、门槛可调），全量 **359 例 / 10.3 秒**。
|
||
|
||
---
|
||
|
||
## 2026-09-17 D19：试用制——不再靠人读，靠真跑当裁判
|
||
|
||
用户看了审核台后指出：那 26 条待审人工其实也审不了。「历史填报列表只显示课程、教师、创建时间」这种，不去翻页面谁都判断不了真假。人工审核在这里是个假门槛。他提的策略是**都采用但分级，优先走已确认的，走不通再试待审的，多次走通就自动升级**。
|
||
|
||
补上一个关键环节后落地：光看任务成没成功信号太糙（一个任务注入五条线索，成功了也不知道哪条有用）。但 **Agent 刚在真实页面上操作完，它知道每条线索对不对**。所以任务结束时把注入过的线索还给它，逐条要回执。
|
||
|
||
### 机制
|
||
|
||
| 级别 | 怎么进提示词 | 怎么升降 |
|
||
|---|---|---|
|
||
| 已确认 | 「已知信息（已确认）」，当事实给 | 被证伪则降级 |
|
||
| 试用中（原草稿） | 「待验证线索」，标注尚未确认、与页面冲突时一律以页面为准 | 证实 2 次升为已确认，证伪 1 次即降为驳回 |
|
||
| 已驳回 | 不注入 | 再被观察到可回到试用 |
|
||
|
||
回执格式写进提示词：`线索[编号] 相符|不符|没用上 一句话说明`。解析时只认本次注入过的编号，防止模型编号码去改别的条目。单次最多注入 8 条（防提示词膨胀和互相矛盾），按可信度排序：被证实过的优先、被证伪过的排最后。
|
||
|
||
新增 `learned_trials` 表记录每次注入与回执，可追溯某条知识是被哪次任务证实或证伪的。
|
||
|
||
### 实测（真实学工环境，连跑两次查课日志）
|
||
|
||
第一次注入 6 条，Agent 全部给出回执：4 条相符（都带页面实证，如「任务详情页顶部确实显示已达标 本期有效填报 3/3」）、2 条「没用上」（没走到相关页面，没瞎猜）。第二次注入 8 条，其中 4 条拿到第二次证实，**自动升为已确认**，`verified_by=trial`。
|
||
|
||
### 中心侧：实测证据解锁系统规则类
|
||
|
||
当初禁止自动采纳系统规则，理由是「读不出真假」。实测不是读。所以改成：系统规则和其他类只有一条路能过——**Agent 在真实页面上验证相符 ≥2 次且从未被证伪**；靠规则层启发式或模型意见一律不放行。实测证据同时排在跨校观察之前，并且能压过规则层的「拿不准」（启发式不该挡住已经验过的事实）。
|
||
|
||
桌面端上报时带上 confirmed / contradicted，且本地经试用升级的条目也上报（那是最硬的证据，中心据此可以推给别的学校）。
|
||
|
||
实测：三条被验证两次的系统规则（本期达标状态显示、历史填报列表字段、选填字段留空）现在能自动采纳，只验过一次的老实留着。
|
||
|
||
### 踩到的坑
|
||
|
||
- 服务端 `DraftEntry` 没声明 confirmed / contradicted，Pydantic 静默丢掉，中心一直收到 0。
|
||
- 第一版 A 路要求规则层也说 adopt，导致实测通过的控件技巧被启发式的「拿不准」挡住。真实数据恰好没暴露（那条观察次数够），是单测抓出来的。
|
||
|
||
测试新增 33 例（分级提示词、回执解析的格式容错与防编号、升降级、注入上限与排序、实测解锁规则类），全量 **399 例 / 11.9 秒**。
|
||
|
||
---
|
||
|
||
## 2026-10-28 D20：学校助手移入独立目录
|
||
|
||
学校智能办事助手从 `browser_use/` 根目录整体移到 `browser_use/school-assistant/`，与 AI 获客助手 `browser_use/assistant/` 并列。学校项目的 `.git`、`.gitignore`、`.env.example`、已有缓存、代码、配置和文档一并移动，Git 提交记录保持；`assistant/` 的路径、已有改动及服务保持原位。
|
||
|
||
外层新增工作区 README 和 AGENTS 导航，分别指向两个项目。学校项目 README 的启动目录和目录树、CLAUDE 的工作目录说明、DESIGN 的目录定位与决定同步更新。后续学校项目的开发、启动、测试和 Git 命令均在 `school-assistant/` 内执行。
|
||
|
||
### 验证
|
||
|
||
- 搬迁前后核对 135 项文件与目录清单、文件 SHA-256 和权限，完整一致；随后仅修改本节及上述学校项目文档。
|
||
- 学校项目 Git HEAD 保留为 `56ecc114d78f0f4e527c0b0e059b51db9c4df541`，新 Git 根为 `school-assistant/`；`assistant/` 的 Git 状态与迁移前逐字一致。
|
||
- 45 个 Python 文件 AST 语法检查、5 个 Node 脚本语法检查、3 份 JSON 配置解析、12 项入口与配置资源存在性检查通过。
|
||
- `docker compose config --quiet` 通过。Compose 已固定项目名、容器名和命名卷，目录迁移不改变数据库卷名称。
|
||
- 审查两个项目的路径解析，运行时均以各自项目根定位，无需修改业务代码。
|
||
|
||
本轮为目录整理和静态验证，未安装学校项目依赖、启动业务、调用模型或执行完整构建与测试集。
|
||
|
||
---
|
||
|
||
## 2026-10-28 D21：转为小红书 AI 拓客桌面助手并实际启动
|
||
|
||
用户明确本窗口专注本项目，将学校办事助手转为 AI 拓客助手，首个平台小红书；保留边做边学、经验沉淀思想，业务链路重新实现。同级 `assistant/` 保持独立，Git 状态摘要与本轮前一致。
|
||
|
||
### 已实现
|
||
|
||
- 新 `backend/prospecting/`：确认商品/服务、目标客户、搜索词、可选地区及有界阅读额度 → browser-use 采集 → 独立文字分析 → 带原话/来源/理由的待核线索 → 操作经验草稿与回执。补充说明随条件传递，不注入旧学校角色、查课、填报或审批提示。
|
||
- 当前 FastAPI 只挂载拓客路由；旧学校业务和账号接口不可访问，审批回查/学校中心同步不在新应用启动。新任务与经验作用域为 `prospecting_workspace`，只加载 `xiaohongshu_prospecting` 知识包。原学校设计和说明归档到 `docs/archive/`。
|
||
- 新工作台提供条件表单、历史、进度、浏览器接管与登录回答、待核结果、经验页、模型设置及连接测试。地区缺省为未知，公开检索默认关闭；修改已开始任务的条件/额度需新建任务。已停止、部分结果和额度耗尽不能借重试重开采集。
|
||
- `save_source` 核对实际笔记 URL、唯一可见来源容器及逐字原话，正文与每条评论分开；待核判断仍需人工核实。`evidence.json` 原子保留来源与经验，异常/取消/重启可恢复，未读评论不当作无评论。
|
||
- 默认 `deepseek-flash`（当前官方 V4.1-Flash-1017，支持图像），可选 `deepseek-v4-pro` 文本模式。新适配显式关闭 thinking，保留图像并验证 JSON 动作；保留原 Key 余额兜底。源码复核确认原适配器会保留图片，实际兼容缺口在新模型名的 thinking/结构化输出行为。
|
||
- `backend/research.py` 接入 DeepSeek Search/Fetch：固定官方端点、独立来源标签、参数/URL/私网边界、超时及响应大小上限。UI 本轮只有辅助 Search 开关；Fetch 已有独立 API，尚无单独界面入口。未将公开检索摘要当作小红书已读来源。
|
||
- 修复 0.13.10 的累计步数语义：续跑转换为累计上限，逐轮返回增量，`browser-budget.json` 在步骤开始与 finally 落盘；异常、取消、新建 Agent 不重置 60 步总额度。截图编号持续递增，不覆盖旧证据。
|
||
- 修复 Mac 安装：Windows 冻结锁中的无标记 pywin32 导致首次安装失败，改为 universal 哈希锁；新增跨平台 Python/锁更新脚本。Node、Python 3.12 依赖和 Electron 33.4.11 已安装，原项目独立 PostgreSQL 容器已启动。
|
||
|
||
### 实际验证
|
||
|
||
- 最终 **490 个后端测试通过 / 5.71 秒**；`npm run check`、`npm run build`、`git diff --check` 通过。新库首轮完整测试暴露缺表/历史中心库不存在，增加测试会话初始化和一次性中心测试库，测试结束自动删除该临时库后全量通过。
|
||
- 真实本地 API 验证通过：健康、默认模型、知识包、创建新任务、缺 Key 明确阻断、进度、检索参数/Key边界、停止；旧学校知识 ID 请求被拒，旧学校接口 404。联调用任务已按其唯一 ID 删除，未保存演示线索。
|
||
- 前端夹具验证条件、缺 Key、结果/经验和设置反馈；结果页截图明确是 fixture，不作为真实平台数据。
|
||
- **Electron 桌面窗口已实际打开并保持运行**，页面 `app://ui/index.html` 标题“AI 拓客助手”，API `127.0.0.1:8788` 与内嵌模式正常，CDP 9333/控制 8797 已启动。真实窗口截图：`data/ui-verification/prospecting-desktop-live.png`，已目视检查。
|
||
|
||
### 当前限制与下一步
|
||
|
||
本轮初始没有 DeepSeek Key，随后用户在应用设置中自行保存；未复制其他项目密钥。实际 `/settings/test` 成功返回 deepseek-flash，最新模型通过真实截图识别与 JSON 结构验证（读取本地应用截图标题“AI 拓客助手”，共1160 tokens）。公开 Search 返回1条官方文档，Fetch 返回同页6405字正文，两个接口均HTTP200；回执保存在 `data/ui-verification/deepseek-*-live.json`。
|
||
|
||
用户随后在应用内创建装修拓客任务，已实际到达小红书搜索和详情页，但因模型反复取完整来源URL而未成功保存来源。不能据此称完整拓客链路通过；后续问题、修复及复验另记D22。当前只读搜索、摘录与线索整理，不执行关注、评论或私信。
|
||
|
||
---
|
||
|
||
## 2026-10-28 D22：详情页后黑/空区域诊断与有界复验
|
||
|
||
用户在真实桌面运行装修拓客任务 `task_965866838f45`，反馈到详情页后界面变黑，并确认 UI 是否修改。已说明 UI 转为商品/目标客户/关键词的拓客工作台。
|
||
|
||
### 最新日志结论
|
||
|
||
- 两次运行均进入搜索与真实详情页，最后保存的 `step_036.png` 正常；反复寻找 canonical/href 获取完整签名来源链接，期间动作格式不符，始终未调用成功的 `save_source`。
|
||
- 17:20:12 第二次失败结束后，runner 关闭会话并删除 Electron WebContentsView；控制接口实际返回 `views: []`，CDP 仅剩应用页。旧 UI 仍保留原生浏览器占位，因此出现黑/空区域，没有发现应用进程崩溃证据。
|
||
- 初次入口 URL 被连接了后面的中文指令，日志明确有错误 URL。已将 URL 独立成行，禁止追加中文/标点；这不能直接当作平台封禁证据。
|
||
|
||
### 已修复
|
||
|
||
- `save_source/save_lead` 不再要求模型提供来源 URL，程序从当前实际页面取全地址并验证笔记身份；签名 URL 仅在私有证据中保存。
|
||
- 增加有界 `inspect_source_candidates`，仅返回当前笔记可见正文和首层独立评论的真实唯一定位与原文摘录，不读私有接口、不生成客户结论。单次 0–5 条评论限制写入模型可见 JSON Schema，与每篇总额度分开。
|
||
- 无活动会话时卸载原生占位，显示最近保存截图、结束原因和只读标识；无图/读取失败有明确状态，回放无接管按钮。截图时间来自真实 HTTP Last-Modified，缺失则未知，不拿任务更新时间冒充。
|
||
- 后台启动/续跑时，当前选中任务随历史 status/updated_at 变化自动同步，避免仍显示旧 blocked 状态而未挂载实时浏览器；未变化不重复读详情，在途请求去重。
|
||
|
||
### 真实有界复验
|
||
|
||
保留原目标、搜索词、原失败记录及累计 44/60 步，只用剩余额度续同一任务一次。实际新增使用15步，总计59/60；入口正常、来源 URL 卡点消失。保存 **2 篇笔记摘录 + 4 条评论 = 6 个来源**，独立模型分析均为 exclude，待核线索 **0**：主要为已完成装修分享和家具链接咨询，没有把它们当作当前装修服务需求。原5篇上限及其他关键词未全部覆盖，状态保留 blocked/results 与部分读取说明，不扩量、不替换旧失败、不做触达。本次没有新操作经验条目，不声称真实经验升降级已验证。
|
||
|
||
复验中有截图超时，当前最近保存图仍为旧轮次；已修后台状态同步，并在回放明确显示实际截图时间。该修复通过前端夹具验证，本轮不再追加真实平台采集来验证截图稳定性。
|
||
|
||
### 验证与当前状态
|
||
|
||
- 来源工具/runner 61 项相关测试通过；最终完整后端 **498 项 / 2.71 秒**通过。
|
||
- 黑屏回放10项、后台状态同步/截图时间8项前端夹具通过；类型检查、构建、差异检查通过。
|
||
- 实际桌面已验证可读取原任务截图（1270×1606）、明确结束原因，原生占位被卸载；截图 `data/ui-verification/black-screen-fixed-live.png`。
|
||
- 应用保持本地运行；DeepSeek Key 已由用户在本项目应用设置配置，真实文本连接、截图识别、Search 与 Fetch 均通过。未改同级 assistant，不再自动续本轮采集。
|
||
|
||
---
|
||
|
||
## 2026-10-28 D23：固定每轮结束的复盘与下一步
|
||
|
||
- **问题**：用户要求每轮结束明确说明问题原因、修复方法及后续路线；此前收尾对当前结果有说明，但下一步优先级和未完成验证不够固定、清楚。
|
||
- **本轮处理**：将三项固定汇报要求写入 CLAUDE，要求区分已确认/待查、实际修复/未解决、本机测试/真实平台及实际业务结果；同步 DESIGN 当前优先顺序，继续保留原任务59/60步与6源0线索的事实。
|
||
- **验证与范围**：本轮仅更新协作规范、设计与进度文档，执行差异格式检查；未修改程序、重启服务、运行平台或新增模型调用。
|
||
- **下一步**：先验证实时页面和截图同步，再在明确的小轮范围内验证需求识别，最后通过新对象/参数验证经验复用与升降级；不自动重置旧任务或扩采集。
|
||
|
||
---
|
||
|
||
## 2026-10-28 D24：最新任务日志只读分析
|
||
|
||
用户要求查看最新任务日志。本轮只读核对 API、进度、来源快照、截图和已安装框架实现，未改程序、重启、重跑任务或调用模型/平台；同步当前分析及待修顺序。
|
||
|
||
### 实际结果
|
||
|
||
最新任务为 `task_bf60e497b5db`（19:01:46–19:04:24），目标为提供装修服务、寻找最近在装修的用户，关键词“装修指南/家里装修/寻找装修团队”，5篇笔记、每篇10条评论为上限，公开检索关闭。
|
||
|
||
- 保存4篇正文与20条评论，逐篇评论数7/7/0/6；只使用第一个关键词，另外两词及第5篇未执行。
|
||
- 分析24源：22排除、1不明确、1待核。唯一待核原话“我给你8万来我家装成这样”，值得核实，但可能是认真委托，也可能是夸赞/调侃，不当作确认客户。
|
||
- 所有来源 author 字段为空。最后截图可见相应评论的昵称、页面相对时间和IP属地，但未结构化保存；截图中的IP属地不能当作装修项目所在地或客户身份验证。
|
||
- learning_candidates/outcomes均空，注入经验列表为空，任务对应 learned 为空；本轮没有实际完成经验沉淀或复用。
|
||
- 49张有效PNG，缺第8/9步恰对应动作结构解析失败；最后 `step_051.png` 已目视检查，是正常评论页。这一批未重现旧的黑/空区域，不据此宣称全局截图稳定性已经验收。
|
||
|
||
### 问题出在哪
|
||
|
||
1. **停止理由不实**：台账51/60步尚余9步，第51步Agent主动调用done且success=false；并非硬额度强停或两次格式错误直接终止。模型总结自称“预算耗尽”与账本不符。browser-use 0.13.10自75%预算开始提示保存部分结果/收尾，可能影响模型决定，但不是强制在51步停止的证据。
|
||
2. **重复低收益检查**：21次inspect、10次scroll（同一步可含多动作，不可直接折算步数占比）。第三篇仅一条“学到了”的评论未能形成可保存容器，第37–40步又连续尝试；候选工具不排除已保存项，也没有明确解释空候选原因，导致反复检查和去重。
|
||
3. **可选作者字段造成摩擦**：模型为正文传入作者名，但作者位于正文容器外，触发一次校验拒绝；留空后成功。守住来源归属是必要的，元数据需要在同一来源的外层范围单独取证。
|
||
4. **错误与终态可解释性不足**：第8/9步两次JSON动作结构失败没有字段级诊断；之后继续至51步。采集已有部分成果且文本分析成功，编排仍仅凭browser_verdict=failed统一显示blocked/results，容易被理解为整条链路没工作。
|
||
5. **获客口径和学习闭环未收口**：大多为已装修分享/单品求链接。另有窗帘报价评论可能含本人采购/预算信号，但按“非装修服务”排除，需核对“最近在装修的用户”与“明确找装修队”是否应分层，不能断言当前分类全部准确。经验生成仅靠模型自行调用，没有独立收尾动作，最终仍为0。
|
||
|
||
### 怎么修、下一步怎么走
|
||
|
||
本轮未实施程序修复。待修顺序已同步DESIGN：先修真实stop_reason/剩余额度、部分结果终态及安全字段诊断；再减少重复候选/低收益重试、单独取证作者等元数据并复核筛选口径；最后将操作复盘作为独立收尾阶段，保存有依据的经验草稿，并用后续不同对象验证复用。保留本任务51/60及原任务59/60，不自动追加采集。
|
||
|
||
---
|
||
|
||
## 2026-10-28 D25：对话与链路优化待审核方案
|
||
|
||
- **问题**：当前表单、默认篇数/评论数和固定步数不符合用户希望的自然语言委托；回复阅读、阶段组合、受限处理和真实经验复用需要统一设计。
|
||
- **本轮处理**：新增 [AI 拓客助手优化方案 v0.1](AI拓客助手优化方案-v0.1.md)，整理对话入口、真实停止原因、展开回复、主页核实及导出、关注私信授权与动作记录、平台受限后的替代路线、三层复用、独立复盘、任务评价和四阶段验收。分别审阅产品覆盖和工程恢复机制，明确已讨论方向与新增建议。DESIGN 仅增加待审核入口，保留当前实现记录。
|
||
- **验证与范围**：仅创建和核对文档及相对链接，检查差异格式；未修改程序或 UI，未重启、运行平台、调用模型或执行触达。当前方案待审核，不视为功能已交付。
|
||
- **下一步**：用户审核入口布局、阶段收尾、跟进边界和分阶段交付；获批后才同步正式设计、协作约定与实施任务，并从对话入口及准确执行状态开始。
|
||
|
||
---
|
||
|
||
## 2026-10-28 D26：按获批方案实施对话与分阶段链路
|
||
|
||
用户明确要求“那开始实现吧”。本轮在本项目实施，未修改同级 assistant，未提交或推送。
|
||
|
||
### 问题与实际修复
|
||
|
||
- **对话委托**：移除默认业务条件及数量表单，新增模型结构化意图识别、可展开计划和必要追问；同一任务可补充、修订和继续，保存目标版本、完整消息及既有来源。明确区分发现、研究、指定页面检查、导出、关注和私信意图。常用“进度怎么样”“先停一下”等控制语句直接读取进度或停止，不中断重写目标、不额外调用模型。
|
||
- **执行与停止原因**：篇数/评论数默认null；新拓客执行不再使用60步或600秒总量终止，用户明确数量仍有效。保留累计台账，旧表单策略迁移留下原值及原自然语言范围。停止原因来自程序事件，模型总结另存；成功结束不会继承旧429，实际观察过与未核对的关键词分开记录，未核对范围不报完整覆盖。
|
||
- **长任务与恢复**：适配锁定版本的无限执行范围，屏蔽预算收尾提示并保留消息压缩。新会话深拷贝恢复sources/profiles/展开记录/动作账本；无进展停止在当步触发，不虚记额外步骤。损坏台账不归零，不清除旧任务59/60、51/60历史。
|
||
- **回复及身份**：reply独立取证，保存父/根/回复对象；对应DOM单独取得作者、头像链接、页面时间和IP属地，作者可选值错误不再阻断原文。候选检查返回新增/已存/空原因，原生点击展开回复后核对新增，无变化不重复点击。主页可见小红书号须与来源作者链接匹配，内部profile_id不冒充小红书号。
|
||
- **交付和反馈**：增加CSV导出，未知账号字段留空，处理公式注入；任务👍👎关联不可变结果快照，单条纠正保留原文并映射结果卡。修复反馈/纠正API曾返回事件id、会被UI当成任务id的问题；改为返回当前任务。
|
||
- **跟进阶段**：增加只读前置核对、具体批次授权卡、账号/目标/实际输入话术校验和持久动作账本。跟进模式禁用通用click/input/send_keys，实际关注/发送只经受约束工具；已关注跳过并留据，发送前先记账，未知不重发。红色失败标记、未知结果暂停当前账号后续私信，明确页面每日限制才称当日上限。重新核对后由用户明确解除，仅解除暂停，不自动发送或重放未知动作。
|
||
- **独立复盘**：阶段结束、暂停和异常均从已核对来源形成操作合同草稿，不依赖采集Agent最后几步。草稿保留条件/成功依据/版本与任务证据，继续沿用跨任务试用回执和升降级。替代路线按已有成果提供，尚无真实效果排名。
|
||
|
||
### 验证结果与边界
|
||
|
||
- 完整后端 **561 项 / 4.62 秒**通过，类型检查、桌面构建、差异格式检查通过。涵盖API回传、快照不变性、纠正、导出、无限步数、恢复、授权边界、红色失败及未知动作不重发。
|
||
- 使用真实 pinned Agent上下文/消息压缩/step/execute/finalize方法做无网络回归：超过60步仍可继续且累计正确；消息压缩仍运行；连续无进展6次尝试仅执行5次动作，无第7个虚记步骤。
|
||
- 工具与实际DOM夹具验证父子作者归属、同文不同人、增量过滤、展开入口及可见主页号。桌面隔离Electron交互 **30 项**通过，含历史、中文输入法、只读回放时间、赞踩/纠正/导出、批次选择、账号修订失效和暂停解除。报告 `data/ui-verification/conversation-ui-fixture.json`。
|
||
- 真实DeepSeek只做一次样例意图识别：杭州装修描述返回discover、6个生成关键词、无需追问、两类数量均null，未开启浏览器或执行外部动作。报告 `data/ui-verification/conversation-intent-live.json`。
|
||
- 确认本项目无执行中任务后重启桌面，实际首页为对话输入，数量输入为0；2条历史任务保留，DeepSeek Key已配置、模型仍为deepseek-flash，活动浏览器为空。实机记录及截图 `data/ui-verification/conversation-live.{json,png}`。
|
||
|
||
本轮没有真实小红书追加采集、关注或私信。页面控件识别不匹配会停止并请用户处理；本地通过不代表真实平台整条链路、跨任务学习或获客效果已验收。
|
||
|
||
### 接下来怎么走
|
||
|
||
先用真实只读任务核对当前平台布局、回复展开、主页号和每位发言人的来源归属；再用不同对象/参数验收草稿召回及逐条验证。跟进真实测试另需明确目标批次与内容，不能把本次方案实施授权当作对真实账号发送授权。用户评价及后续回复/需求/合作数据分开积累，再调整路线推荐。细粒度JSON错误诊断等未专门验收的事项继续保留。
|
||
|
||
---
|
||
|
||
## 2026-10-29 D27：按指定小鹅内页复刻蓝灰界面与动态
|
||
|
||
- **问题**：此前绿色三栏界面与用户指定的小鹅内页差异明显。参考页外层是Penguin平台，真正助手在iframe中；只读平台HTML/CSS会误把外壳当作目标。浏览器读取初期多次超时，随后通过实际iframe结构、截图及局部计算样式确认目标。
|
||
- **实际修改**：重构为浅蓝灰玻璃面板、单段持续对话、品牌与开场消息、底部快捷入口和输入框；历史与任务设置改抽屉，执行浏览器按需展开。统一样式，移除旧绿色规则叠层；业务仍使用真实拓客API，保留对话、必要追问、导出、反馈、授权和接管。
|
||
- **动态实现**：小鹅图形与粒子采样采用实际SVG；加入idle/running/paused/completed/error状态、银蓝10列方阵4.8秒翻转与70ms对角错相，以及真实结果淡入。支持减少动态、本地偏好、隐藏暂停、DPR/帧率控制和卸载清理，不加模拟进度或假完成。
|
||
- **交互保护**：抽屉/设置期间停放原生浏览器，恢复时重新测量，保留历史请求竞态、中文IME和发送失败草稿。修复新样式的文档额外滚动条、小头像缩成点、分析动画被旧结果推到可视区域外等问题。
|
||
- **验证**：类型检查、构建及差异检查通过；隔离Electron界面42项通过，五种粒子状态非空、帧变化、方阵翻转、减少动态静止及卸载无rAF遗留均通过。已目视核对首页、结果、窄窗和执行中截图。报告 `data/ui-verification/blue-ui-fixture.json`、`particle-companion-fixture.json`。本轮只改前端及文档，没有真实平台采集、模型调用或触达。
|
||
- **实际桌面**：确认无活动任务/浏览器后重启本项目，已通过原生桌面实际截图与可访问性树核对蓝灰主界面、小鹅点云、底部输入区、历史抽屉中的2条旧任务，以及任务设置里的已连接状态和deepseek-flash。原有Key和数据保留；未关闭其他项目进程。用户随后开始查看设置，保持其当前界面选择。
|
||
- **边界与下一步**：布局、颜色、轮廓和方阵参数按实际参考对齐；参考原始粒子脚本完整运动参数未取得，粒子逐帧轨迹还不能称完全一致。下一步以同尺寸连续画面对照微调密度、漂移与状态过渡，同时在真实只读任务中继续验收业务链路。完整参考记录见 [UI_REFERENCE_PENGUIN](UI_REFERENCE_PENGUIN.md)。
|
||
|
||
---
|
||
|
||
## 2026-10-29 D28：下方业务场景与补充卡片只读核对
|
||
|
||
- **问题**：用户指出还需查看参考页下方“人事材料整理”等场景，重点是补充信息、表单及不同业务的交付UI。上一版主要完成视觉和动态，通用场景卡片尚未完整接入。
|
||
- **核对结果**：实际读取人事场景的对话确认、执行卡和材料核验交付清单，以及图书馆的实时返回/结果组装、访客及报修的必要信息追问。人事演示的2/3齐备和1项待补充只是参考页模拟数据。尚未逐项验证全部14个场景的输入、校验、修订和提交状态。
|
||
- **代码现状**：计划合同仅有missing字符串列表，计划卡主要回主输入框补充；已有跟进授权、评价、单条纠正小表单，但缺统一字段级补充卡、阶段卡与文件交付卡。替代路线后端缺message/prompt，现前端多数不显示可执行选择按钮，是另一个待接通点。
|
||
- **本轮处理与验证**：把观察事实、实现缺口和六类拓客卡片适配建议补入 [界面参考记录](UI_REFERENCE_PENGUIN.md)。仅阅读参考页和当前代码、更新文档并检查差异格式；未修改程序、重启或调用真实拓客任务。既有42项检查不代表参考全部业务场景已实现。
|
||
- **下一步**：优先补受控卡片合同和必要信息就地补充，再接阶段进展、可操作的恢复路线和名单文件交付。自然语言仍为入口；已给信息预填，只问必要缺项，目标修订时旧卡失效，保留原任务与来源。
|
||
|
||
---
|
||
|
||
## 2026-10-29 D29：默认粒子与对话场景 UI 优化方案
|
||
|
||
- **问题**：用户指出对话中的粒子与默认进入时不同。代码核对确认当前五种状态仍采样同一品牌轮廓，只调整漂移及透明度；缺少独立对话粒子与完整场景卡片。
|
||
- **本轮处理**：新增 [UI 优化方案](UI优化方案-v0.2.md)，区分默认企鹅、对话反馈和结果组装，规划补充、计划、真实进展、核验、名单文件、依据、跟进和受限恢复的场景适配。保持自然语言优先、必要才补、同一任务接续、历史静态与真实状态驱动。DESIGN 仅增加待审核链接。
|
||
- **核对与边界**：继续读取参考页实时DOM，确认基础默认状态及人事、图书馆、访客等演示内容；本轮截图调用超时，没有取得新的连续运动对照，不宣称对话粒子轨迹已精确量测。仅创建和检查方案文档，未修改程序、重启或执行平台任务。
|
||
- **下一步**：用户审核后先实现状态及卡片合同和两类粒子切换，再接真实进展、文件交付与替代路线；通过隔离交互和连续画面对照验收后，再开展真实只读平台验证。
|
||
|
||
---
|
||
|
||
## 2026-10-29 D30：先推送快照再实施场景与粒子方案
|
||
|
||
### 快照
|
||
|
||
用户明确授权先提交并推送当前代码，再实施上轮UI方案。已在本项目 `main` 提交 `c87daa8`，推送至 `origin/main` 并核对远端引用相同。提交前类型检查、构建、561项后端测试及候选凭据扫描通过；真实Key、运行数据、依赖产物和同级assistant未提交。以下优化保留为快照之后的本地改动。
|
||
|
||
### 问题与修复
|
||
|
||
- **动效分工**：原五种状态共用同一轮廓，现保留默认企鹅，新增独立流动对话粒子与执行角标，分析使用方阵。真实结果立即可读，历史首挂载与返回不重播；暂停、等回复和受限停止工作粒子。调度器统一30fps、隐藏/离屏暂停、减少动态及卸载清理。
|
||
- **必要补充**：受控字段卡使用任务ID、目标版本和卡ID，过期与重复提交被拒；卡片和文字回复沿同一解释/修订路径继续，保留只读回答历史，失败保留草稿。Cua复测发现空阶段的五个0把补充卡挤出视野，已移除空面板并把当前补充卡放在末尾。
|
||
- **任务与名单**：接入实际事件、来源与覆盖，新增表格筛选、逐人依据和纠正。小红书号只展示对应来源且有主页核对依据的记录，内部ID不冒充公开账号；IP属地不当服务地点。活动阶段不允许冲突导出和结果评价。
|
||
- **文件与替代路线**：导出文件独立清单持久保存版本、时间和可用状态，历史可重开；缺失/越界路径不可打开，账号/纠正变化会令旧文件标历史。复核路线只分析保存来源，导出不调用模型或浏览器，账号暂停和未知动作保留。
|
||
- **恢复一致性**：审阅复现界面恢复快照与路线原始DB版本不一致导致409，现统一GET、路线和导出取证投影。来源和主页按来源ID合并，新观察优先、未知/同时间保留DB。复核失败单独显示当前错误并保留原平台原因，继续时仍只复核保存资料。
|
||
- **准确提示**：普通浏览器预览无法打开本机文件时返回明确提示，避免原空字符串导致假报成功；桌面打开能力保留。
|
||
|
||
### 验证
|
||
|
||
- 最终完整后端 **579项 / 4.07秒**通过，类型、构建和差异格式通过。另有可复用纯调度器8项检查。一次子代理并发初始化测试库遇到DDL死锁，之后串行全量通过，不将其当成业务断言失败。
|
||
- 隔离本地页面经CUA实际操作：自然语言委托、缺项校验、失败保留填写、原任务补充、筛选、来源展开、纠正、导出及文件重开、👍、复核/导出路线、历史和减少动态。运行角标两帧变化1602像素，减少动态同区0像素；停止后工作粒子0、方阵未激活，历史组装不重播；600px窄窗文档无横向溢出。分析方阵50格，正常播放与减少动态静态均核对。
|
||
- 证据见 `data/ui-verification/ui-v2-*-cua.png`、`ui-v2-cua-calls.json`、`motion-loop-unit.json`。所有名单和状态均为明确标记的本地夹具，不是平台采集结果。
|
||
- 已实际构建、启动并通过原生窗口核对最新桌面；本机服务已连接，原Key仍已配置，模型deepseek-flash，已有3条历史、无运行任务或活动网页。最后前端微调构建后通过桌面原生Reload加载，用户无需再次重启。未续跑历史任务。综合记录 `ui-v2-verification.json`，实机截图 `ui-v2-desktop-live.png`。
|
||
|
||
### 边界与下一步
|
||
|
||
本轮无真实模型、小红书采集、关注或私信。粒子已分成独立造型和流动表现，参考原始轨迹仍未取得，不能称逐帧一比一。下一步先在真实只读任务验证补充、回复来源、阶段更新和文件交付，再以连续画面对照细调粒子密度与运动；真实跟进仍需具体对象与话术授权。
|
||
|
||
---
|
||
|
||
## 2026-10-29 D31：记录公开资料工具待议事项与启动说明
|
||
|
||
- 用户要求先记录DeepSeek Search/Fetch的辅助定位和当前接入缺口，后期再讨论。已加入DESIGN第5节：现有Search保存结果、Fetch有API，尚未用于优化关键词及后续规划；未来按需补业务背景与搜索方向，最后由实际平台页面核验。本轮未扩展运行逻辑。
|
||
- 核对本项目启动脚本：`npm run db:up`启动独立数据库，`npm start`构建并打开Electron，桌面自行管理后端，无需另开后端命令。目录为 `browser_use/school-assistant/`，与同级assistant分开。
|
||
- 本次检查API健康端点未连接，未发现Electron主进程，当前桌面未运行；本轮仅说明启动步骤，未启动真实任务、调用模型或执行触达。
|
||
- 文档差异检查通过。下一步先使用现有桌面主链路，Search/Fetch作为明确记录的后续讨论项保留。
|
||
|
||
---
|
||
|
||
## 2026-10-29 D32：跟妆任务审计与小火花品牌
|
||
|
||
### 最新任务实际完成范围
|
||
|
||
任务 `task_ef3c870c7e2b` 为杭州美妆工作室寻找跟妆需求。网页采集08:39:44至08:42:35，记录165.7秒、54次浏览器尝试；不是持续采集到09:27。保存7条来源（4正文、2评论、1回复），现有判断与来源逐条匹配、引用均属于各自来源。最终5条待核来源中含同作者正文/评论，不能当作5位独立客户；主页核对0，小红书号均待核。实际到过“杭州跟妆”“杭州新娘跟妆”搜索页，其他5词未执行；仅到达搜索页不等于读完。
|
||
|
||
原浏览器结果failed/is_successful=false，最后done(success=false)自报未完成。动作结构错误8次、容器/原文核对失败6次；模型总结所称“系统连续5次失败强停”不能当程序已证实的停止原因。最后截图正常，没有重现黑屏。09:26又对同一批资料独立复核3次，之后共7次CSV导出；最终review_completed/completed误掩盖原采集失败。
|
||
|
||
### 已修复与品牌修改
|
||
|
||
- 失败done不再返回agent_done。资料复核检查原browser_verdict和history，兼容旧误标，避免把未完成采集改成整体完成。
|
||
- 检索记录支持实际search_result_ai路径及有限关键词解码；旧任务只从实际history.urls恢复覆盖，完成误标只读展示为阶段结果，保留原数据库与日志，不自动续跑。
|
||
- 按用户小火花形象更换界面标识与默认品牌粒子：共享圆润火焰、独立浮滴、白脸笑容，银蓝配色；未复制用户红色JPG。独立对话流动粒子、方阵、原生浏览器和业务状态保持原逻辑。
|
||
|
||
### 模型与费用
|
||
|
||
当前配置及任务分析模型均为deepseek-flash，关闭思考模式，无兜底Key，本任务公开检索关闭。2026-10-29核对[官方价格](https://api-docs.deepseek.com/zh-cn/quick_start/pricing/)：Flash输出闲时4元/百万token、高峰8元/百万token；北京时间工作日9–12、14–18为高峰。09:26三次复核均在高峰，CSV导出不调用模型。
|
||
|
||
现有analysis_usage只记录最后一次复核：输入3861、输出620、共4481token；按高峰及记录的缓存命中计算该次约0.0054元，仅为估计且不能代表整任务。浏览器累计usage未持久化，后次复核覆盖旧分析用量，解析失败的已返回响应也未完整入账，不能据此给出精确全程费用。未更换模型、引入总配额或重跑模型补账。后续需累计供应商实际用量，并验证减少无效取证、冗长输出和无变更复核的方法。
|
||
|
||
### 验证与待完成
|
||
|
||
完整后端591项/4.40秒、类型检查、构建、8项纯粒子调度器及差异检查通过。全量首轮发现一条旧测试仍要求失败done等于agent_done，已按本次修复纠正预期，最终全量通过。实际任务只读检查新投影为blocked/stage_results、两词已观察及五词待核；原始DB和证据未改。已在实际桌面查看小火花标识及默认粒子，截图 `data/ui-verification/spark-brand-desktop-live.png`，审计汇总 `makeup-task-audit-20261029.json`。
|
||
|
||
确认无运行任务及活动网页后已重启本项目，后端PID48830、新界面及修复均已加载；原生桌面历史核对最新任务显示“阶段结果”，随后恢复首页。当前模型及Key保留，用户无需再重启。没有提交或推送本轮改动。
|
||
|
||
本轮没有真实平台取证、关注私信或模型调用。来源容器/动作JSON失败、主页号、回复父根关系、名单按人去重及完整用量记录仍需后续处理；三类操作草稿尚无跨任务复用验证，实际落库草稿出现note键与comment内容混合，需单独排查模糊合并，不能宣称学习闭环已验收。
|
||
|
||
---
|
||
|
||
## 2026-10-29 D33：明确交付人数、按人去重及重复调用优化
|
||
|
||
### 问题出在哪
|
||
|
||
取消默认篇数/评论数和60步配额后，发现候选任务缺少用户确认的交付终点。原线索按原话计数，同人正文与评论可能被当作两位；同一批资料反复复核会再次调用模型，且整任务用量缺失。新增数量字段若只依赖意图提示，还可能接受模型擅猜10位。取证失败保护最初挂在模型返回后，会多付一次调用；使用真实pinned step流程回归发现并修正。
|
||
|
||
### 怎么修复
|
||
|
||
- **明确终点**：新发现候选任务继承用户给的人数；未给人数、指定页面、明确阅读篇数或“先做一轮”范围时，仅补问“这次先整理多少位候选？”。纯数字回答直接接续同一任务，不额外调用意图模型。人数、篇数互不代填；程序核对用户原话，价格、型号、团队人数、否定/区间与代码示例不能当目标；没有恢复默认阅读/总步数/余额限制。中文数字及复杂表达保守补问。
|
||
- **交付口径**：按来源作者稳定主页身份合并需求，保留每条原话和链接，同名不合并；身份未知单列不凑人数，小红书号仍须对应主页核对。界面与CSV共享分组。业务标准修订后旧结果保留、标明待复核，不计新目标；单改人数可复用判断。
|
||
- **达标收尾**：每步保存后按剩余目标分段分析，达到人数在下一次浏览器/模型步骤前停止，保留实际未遍历关键词。未达标保持阶段结果，独立复核不能把采集失败或人数不足洗成完成。已达标任务直接继续不会重新开启采集。同一笔记在无新增来源量下三次容器/原文取证失败，当步停止，明确未完成范围。
|
||
- **复用和用量**：按来源、正文/父根、纠正、业务标准及模型生成输入签名，普通复核复用不变判断，仅新增/变化来源调用分析；明确“重新分析（新增模型用量）”才强制重做。同篇上下文按note_id/笔记路径关联，不受签名query变化影响。供应商响应在校验前入任务用量账，含意图、网页、压缩、增量分析和复核，失败解析也保留返回usage；未知/部分用量、旧历史和存储异常明确标注。存储异常不触发付费重试，日志不保存Key或原始提示/响应。模型过程输出改简短，仍使用deepseek-flash关闭思考。
|
||
|
||
### 验证结果
|
||
|
||
- 完整后端 **689项 / 5.61秒通过**，类型检查、桌面构建、8项粒子调度器及差异检查通过。覆盖原话范围约束、纯数字不调用NLU、按人去重、未达标终态、已达标继续不重跑、目标修订竞态、增量/强制复核、正文关联失效、CSV保留全部证据和用量并发/损坏/解析失败。
|
||
- 真实pinned Agent `_execute_step` 路径：同页取证失败3次只调用3次模型替身、执行3次动作即停止，没有第4次尝试；人数达标回调在1步后停止，没有额外计步。以上均为本地无网络回归。
|
||
- CUA隔离界面实际操作：自然语言委托→人数卡→空值/0拒绝→填2→同一任务展示2/2位；4条需求信号合为2位并另留1条身份未知来源，累计用量/缓存/未知及解析失败提示可展开；强制重做请求实际带force=true。所有数据明确标记夹具，不连接模型/平台。截图 `data/ui-verification/goal-{quantity,results,usage}-cua.png`，请求记录 `goal-usage-cua-calls.json`。
|
||
- 确认4条历史均无执行中任务、活动网页为空后正常退出并重新启动本项目。新后端PID86418、API已连接、deepseek-flash及已配置Key保留；实际桌面核对历史分组、强制重做入口及“历史用量不完整/未知”，没有触发复核或导出。截图 `goal-usage-desktop-live.png`。已恢复待命首页，用户无需再次重启。启动前几次连接早于后端ready返回ECONNREFUSED，随后健康和界面连接已恢复。
|
||
|
||
本轮无真实模型调用、小红书追加取证、关注或私信，没有提交推送。旧任务日志、来源、文件及动作记录保留；旧用量不能事后补造。
|
||
|
||
### 接下来怎么走
|
||
|
||
先用用户给定的少量只读候选目标验收“保存来源→增量判断→身份去重→达标停止”，核对评论/回复父根关系、主页入口与完整usage，再对比真实调用次数及质量，不能从本地测试宣称已节省多少费用。数量默认不替用户决定，已明确有限范围则不重复追问。跨任务经验草稿混合与真实获客效果仍未验收，Search/Fetch仍按D31暂缓扩展；实际关注私信另需明确对象与内容授权。
|
||
|
||
---
|
||
|
||
## 2026-10-29 D34：橘子拓客品牌、应用图标与知识沉淀核对
|
||
|
||
### 实际沉淀与问题
|
||
|
||
只读核对最新真实跟妆任务 `task_ef3c870c7e2b`：任务内有正文/评论/回复三类操作草稿，各依据4/2/1条已保存来源；共享知识库实际只有1条draft（ID385）、0条verified，试用/确认/反证均0，全工作区试用回执为空。该任务未召回旧经验，只有“检查可见来源容器→保存原话”的操作草稿，没有已验证的搜索→详情→展开回复→主页→名单完整链路。
|
||
|
||
三类模板文本相似度约0.969，旧通用阈值0.55把它们合成1条，保留note键却取更长comment值。另有采集快照的空learning_candidates覆盖复盘后数据库列表的路径：纯内存按实际快照复现3→0；导出恢复后回写artifacts会持久化这种覆盖。原任务workflow_drafts三份及共享库那一条仍存在，未谎报全部学习成功。脱敏证据 `data/ui-verification/last-learning-audit-20261029.json` 记录修复前事实。
|
||
|
||
### 修改
|
||
|
||
- 正式名称“橘子拓客”，助手昵称“小橘”，统一窗口、页面、开场/输入提示、关于面板和API产品信息；README及当前设计同步。保留机器包名、appId、原用户数据目录，既有Key、任务与文件继续沿用。
|
||
- 新应用图标沿用银蓝圆润小火花、独立浮滴、白脸笑容，加浅蓝圆角底。资源 `resources/brand/app-icon.{svg,png,icns,ico}`，PNG为1024 RGBA，ICO 7种尺寸、ICNS 11种表示；离线生成脚本 `scripts/generate-app-icons.mjs` 复用SPARK路径。正常构建复制资源并生成favicon，运行时接窗口/Dock/关于图标，macOS/Windows/Linux打包配置引用同一资源。Windows原配置关闭全部资源编辑会阻断exe图标替换，现改成仅关闭签名、保留图标与元信息编辑。
|
||
- 小红书程序合同改用 `xhs_operation_{capability}_{source_kind}_v{version}` 新命名空间，按能力/来源类型/版本区分；入库与整理去重使用相同规则，旧学校知识继续通用模糊去重。同合同在同任务多次复盘不增加观察次数；本轮真实证据支持的canonical内容不被模型同key候选覆盖。
|
||
- 恢复学习候选/回执取数据库与快照的并集，冲突以数据库主值为准并保存双方依据，恢复幂等；空旧快照不再擦掉新复盘结果。旧错配行与新合同隔离，未对真实历史草稿执行修写、重放或升级。
|
||
|
||
### 验证与运行
|
||
|
||
- 完整后端 **695项 / 5.93秒通过**；类型、构建、差异与electron-builder配置Schema检查通过。新增学习完整性回归覆盖三类/能力/版本区分、旧错配行保留、重复复盘和整理、canonical重建、空快照保护、独有及冲突依据保留。相关80项先串行通过，再运行全量，未并发初始化DB。
|
||
- SVG/PNG已目视检查，Pillow解码及macOS iconutil校验ICNS/ICO尺寸通过，二次离线生成四文件SHA256相同。使用已有bundled sharp，无新依赖、图片下载或模型调用。构建产物包含图标、favicon；本轮未生成或安装Windows/macOS发布包。
|
||
- 确认4条历史均未执行、活动网页为空后，正常退出旧实例并 `npm start` 加载新版。API新PID5332，产品橘子拓客、模型deepseek-flash、Key已配置，原4条历史仍在，活动网页0。原生桌面实际确认窗口/页面标题、小橘及关于/退出菜单品牌，首页显示本地服务已连接。截图 `data/ui-verification/juzi-desktop-live.png`；原生关于面板AX名称已核对，截图接口返回主窗口，未把它当关于图标截图。源码模式的OS进程仍为Electron；发布包产品名与图标配置已更新。
|
||
- 重启后只读再次核对共享库：仍为原ID385、draft、observations1、trials/confirmed/contradicted均0。没有自动把旧数据补成3条或改成verified。
|
||
|
||
本轮未执行真实模型、小红书采集、关注或私信，没有提交/推送。桌面已回到待命首页，无需用户再次重启。
|
||
|
||
### 接下来
|
||
|
||
下一次使用不同对象的明确只读任务验证新草稿分开入库、后续召回、逐条相符/不符/未用上回执，再决定升级；先验证小操作，再组合阶段链路，不能把预置模板或本次代码修复当实际获客经验。当前真实历史只有未验证草稿，完整链路与获客效果继续待验收。
|
||
|
||
---
|
||
|
||
## 2026-10-29 D35：结果交付与知识自动排名待审核方案
|
||
|
||
- **问题**：名单已经交付却统一标需求待核实，容易让用户以为还需逐条人工审核。知识已有基础草稿与回执，但场景匹配、动作结果验收、独立计数、持续排名及已验证经验失效处理尚未完整接通。
|
||
- **本轮处理**：按用户要求新增 [结果交付与知识复用优化方案 v0.3](橘子拓客结果交付与知识复用优化方案-v0.3.md)。明确任务达成、产物交付、名单字段和后续跟进分别表达；知识按操作、阶段、业务策略和任务资料分层，由系统自动留证、受控试用和验证，人工反馈为可选补充。提出适用条件先行、独立样本去重、样本修正排序、反证暂停、版本与业务效果归因，以及四阶段实施与具体验收。3任务3对象门槛和排序指标明确为待审核起点，不冒充已测准的概率。
|
||
- **核对**：结合现行代码和D34审计区分已实现与待补；独立审阅补齐同对象跨任务计数、程序故障与方法反证区分、仅借已授权任务验证等细节。核对文档结构、链接、示例计算和差异格式。仅新增方案并在DESIGN加待审核入口，未修改运行代码、配置或历史数据，未启动模型/平台任务或重启桌面。
|
||
- **下一步**：用户审核后先实现交付表达与必要字段口径，再补自动验收和事件去重，之后启用排名，最后验收阶段链路和业务效果；没有独立验证依据的历史草稿继续保留真实状态。
|
||
|
||
---
|
||
|
||
## 2026-10-29 D36：结果交付与独立证据知识复用首轮实现
|
||
|
||
### 问题出在哪
|
||
|
||
结果按行统一待核，混合了任务是否交付、必要条件与可选缺项。原经验召回与相符回执不足以证明动作效果，同一事件重放或重复对象可能被错误计量；模型建议、技术成功和用户满意度需要分别保留。历史实际仍只有ID385一条未验证草稿，不能迁移补成新成功链路。
|
||
|
||
### 怎么修复
|
||
|
||
- 新增 `delivery.py` 统一运行状态、必要条件与产物交付；`people.py` 共享人数口径，用户明确要求的小红书号、本人需求、地区或CSV才影响对应完成量。地区须来源本人原话支持，昵称/内部ID/IP不能代填。未知身份、补充来源与达标候选分开，UI和CSV逐项展示字段依据，缺可选字段不要求人工复核。有限范围的零匹配必须有实际读取及逐来源判断；未知不冒充没有需求。零达标但已有资料时按资料分组显示，避免“共0位”掩盖已有成果。
|
||
- 新增工作区隔离的方法、不可变验证事件和业务反馈三表。新事实只从程序取证产生：保存来源需容器/原话和持久记录相符；展开回复需同父讨论可见数量增加并出现新回复；主页需匹配来源作者入口和可见账号标签；导出需真实文件与当前结果版本一致。任务内保存前后快照，知识事件只存引用和对象摘要。新运行捕获实际run_id、当时目标版本和动作标识；历史缺失不补填，目标修改不改变原回执。
|
||
- `knowledge.py` 按平台、阶段、能力、来源类型、适配器版本、依赖和授权先匹配，再按有效独立任务/对象样本选择。首版3任务3对象且无相关反证才优先复用，样本有限可试用，没有成功依据为探索候选；旧记录统计未记录，不参与自动召回。重放幂等，修订追加事件并重算依赖；重复导出或同对象跨任务不能抬分。规则 `independent-evidence-v1` 不表示未来成功或成交概率。
|
||
- 接通同篇正文与一条独立评论/回复保存的有限阶段分支，依赖两条真实操作事件和明确终点；不把它说成完整搜索→全部评论→主页→触达链路成功。模型候选只能进入探索，模型相符/不符报告保留为未知，不能自行计技术成功或反证。👍/👎、方法纠正、回复/确认需求/合作等后续反馈独立记账，标明用户来源和归因未证实，不改任务目标或重跑浏览器。
|
||
- 知识卡增加状态、样本、适用原因、方法来源和证据入口；查看验收读取原任务快照，不新增模型或平台动作。阶段事件分别读取正文前与讨论后快照，缺半边返回缺失，不能拿正文操作的快照替代整段。反馈失败保留输入，历史/暂停状态不使用误导性成功文案。只导出分支现在实际生成文件，失败不能标为完成；知识存储故障不使已生成文件失效。
|
||
|
||
### 发现并修正的边界
|
||
|
||
首轮贯通测试发现方法记录中的datetime不能直接写回JSONB/提示，已统一公共ISO投影，提示只注入方法必需字段。重放时依赖被修订不能改变首个不可变输入，事件保存输入摘要并动态重算依赖。按能力相同不能证明被召回的方法实际被采用，只有对应方法事实计分，其余保留未使用。短时无新回复可能为加载迟延，改记未知，避免一次慢响应停用已有方法。展开后只核对按钮变化不足以证明当前父讨论增加，已补同owner指纹及数量验收。
|
||
|
||
### 验证边界与接下来
|
||
|
||
本地取证、入库、召回、提示序列化、按事件取证、文件生成与反馈已贯通，使用隔离测试工作区及本机夹具，不计入真实知识。CUA验证2/2完整交付、1/2保留原采集失败、五类字段、可选后续反馈、五种知识状态、证据展开及反馈失败保留输入；脚本禁止模型、数据库和平台出站，截图 `data/ui-verification/v03-{delivery,partial,knowledge-proof,knowledge-ranking}-cua.png`、请求记录 `v03-ui-calls.json`，全部明确夹具。
|
||
|
||
真实桌面只读核对四条历史与原ID385记录，未补成功、未修写历史、未重新分析或导出旧任务。`xhs_visible_dom_v1`目前是DOM适配器版本，并非全部动态页面变体；真实回复DOM、其他阶段组合、跨任务复用及业务效果尚需用户实际只读任务验证。下一步先用小量明确候选目标验证来源→增量判断→字段/身份归属→达标停止，再在不同对象任务观察独立计数和召回；触达仍另需明确对象及话术授权。Search/Fetch继续D31暂缓约定。
|
||
|
||
最终完整后端 **813项 / 6.81秒通过**，类型检查、桌面构建、8项粒子调度器及差异检查通过。真实隔离DB回归贯通新取证→复盘入库→下一任务召回→提示/JSONB→按事件读前后快照→反馈→真实本地导出；重复回填和导出不增加独立成功，错任务/错事件/缺半边快照不可读，纯导出无需Key，文件生成失败不标完成。回复验收单测覆盖同父讨论真新增、加载中、仅数量变化、其他讨论新增、归属变化/不可唯一及跨笔记，后者均不计成功或反证。
|
||
|
||
确认没有运行任务与活动网页后正常退出旧实例，`npm start`加载最终后端PID71026，前端最终构建已用桌面正常Reload加载；界面本地服务已连接，deepseek-flash及原Key保留，4条历史仍blocked、活动网页0。实际桌面核对新知识页仅1条历史记录、各验证统计为未记录；最新跟妆任务显示“阶段资料已交付 共5组来源”，保留0位满足当前条件、1位补充与4组身份未知，以及原采集失败和7份旧文件，不把补充资料凑成合格人数。已回到待命首页，无需用户再次重启。截图 `v03-desktop-{knowledge,home}-live.png`，脱敏验收汇总 `v03-implementation-verification.json`。启动初期连接早于后端ready有ECONNREFUSED，随后健康及界面连接正常；现有Vite配置与FastAPI弃用提醒未阻断启动。
|
||
|
||
本轮未调用真实模型、小红书或Search/Fetch，未关注私信；临时UI页及18794夹具服务已关闭。没有提交或推送代码，保留此前工作区未提交改动；当前方案状态与DESIGN已同步为用户批准后的首轮实现。
|
||
|
||
---
|
||
|
||
## 2026-10-29 D37：新版首个真实任务只读审计，先修卡点再测复用
|
||
|
||
### 实际结果
|
||
|
||
最新任务 `task_94db43a81241` 创建于11:20:46，11:23:15结束为blocked/stage_results。浏览器记录24次尝试、104.2秒，最终done(false)。只保存1篇正文、0评论/回复、0回复展开、0主页核对，作者主页关联为空，当前0位满足条件、1组身份未知来源。已生成真实1行CSV，文件可用不改变任务未完成事实。没有登录/验证码/访问限制/私信上限证据，总步数上限为null，不能说余额或业务预算耗尽。
|
||
|
||
### 问题出在哪
|
||
|
||
1. **目标提取未正确理解原话**：原请求写明“找2位本人明确表达装修或设计服务需求的候选”，`dialogue.py:39–57`只接受人数紧邻候选名词，漏掉长修饰语，导致额外追问。用户随后在补充卡明确填1，目标版本改2、人数1是实际补充，不能说程序擅自改成1。纯函数给模型提案target=2仍被程序归为null，已本地重现。
|
||
2. **必需条件误判**：“页面可见的小红书号能取得就记录，没有就说明”被按取得一词变为必填，跨逗号的可选语义没有保留；同一长句中的“本人明确表达装修或设计服务需求”反而漏记explicit_demand。纯函数复现实际required fields为csv+xiaohongshu_id，应为csv+explicit_demand。这是程序原话校验规则缺陷，不能要求用户改成特殊口令才能正常使用。
|
||
3. **页面推进失败**：step008为窄视口详情，底部评论计数101，评论列表未进入视口；没有任何scroll/expand_replies动作。step014/024为作者悬浮卡，未到完整主页，step9–14及18可确认7次作者/头像点击，始终同篇。source有作者名但主页URL/selector均空，不能按昵称凑人数。没有保存当时完整DOM，因此不能断言具体哪条选择器失效；应先补评论入口/滚动与当前真实作者链接的核对和导航。
|
||
4. **故障保护与诊断不足**：24次网页模型调用中8次schema_error，失败动作未执行；11:22:29至11:23:08的失败响应记录140113 total tokens（含缓存），不是免费重试。8次具体字段错误未保留，不能猜错的是哪一参数。步骤15–17失败、18通过、19–23连续5次失败、24done(false)，与锁定browser-use的max_failures=5及_force_done_after_failure只允许收尾机制吻合；当前仅标agent_reported_failure，丢失结构错误触发结束的直接原因。重复保护用完整DOM与动作参数作签名，临时索引/悬浮状态变化会重置计数，且解析失败不进正常动作回调；原文容器失败保护也不覆盖这类点击循环。
|
||
5. **目标版本追溯漏参**：`runner.py:524`新建内嵌浏览器提前调用_run_agent漏传prospecting_goal_version，底部已有会话/非内嵌路径才传。本次正文事实有真实run_id/action_id但缺goal_version，导出独立路径正确记录2。原测试只覆盖预装live后续跑，未覆盖新建内嵌分支；不回填历史猜值。
|
||
|
||
### 实际沉淀与复用结论
|
||
|
||
本次knowledge_methods、knowledge_selected_ids、experience_ids均空，未复用旧方法。新增正文保存与当前CSV生成两条程序操作方法，各1成功/1独立任务/1对象，全局为trial可试用；两个验收事件均可读取真实前后快照，旧legacy385继续保留缺失统计，无preferred或完整阶段链路。当前任务的搜索阅读视图把delivery阶段导出方法标场景不适用/暂停，显示本场景成功0；全局导出成功仍1，不是反证或数据丢失，文案应进一步区分不适用与故障暂停。
|
||
|
||
用量账26次请求=意图1+网页24+增量判断1，输入374538、输出10737、共385275 tokens，含缓存命中288384；账本无未知/部分/待返回项。收尾复核复用已判断来源，没有重复分析调用。以上是当前记录的供应商用量，不换算供应商完整账单。
|
||
|
||
### 本轮处理及接下来
|
||
|
||
本轮只读检查任务、截图、文件、事件、框架代码与纯函数复现；没有改运行代码、修改任务或知识、重启桌面、重跑模型/平台、关注私信。脱敏审计 `data/ui-verification/latest-task-audit-20261029.json`，原日志/来源/文件/失败记录保留。
|
||
|
||
建议先修原话语义提取、评论区推进及真实作者入口，再补按同页面/同作者/操作族的无进展保护、脱敏schema字段路径/类型和准确停止原因、新建内嵌会话追溯参数。分别用本地回归覆盖本次完整原话、悬浮卡/节点索引变化、解析失败序列及新建内嵌分支，不能只测试续跑。通过后沿原任务已存来源补验身份与讨论，不自动把已确认人数1改回2；再由不同对象的新任务验证召回和独立计数。继续原样长跑只会重复当前卡点，不能靠任务数量达到3次就称完整链路已复用。
|
||
|
||
---
|
||
|
||
## 2026-10-29 D38：原话理解、评论/主页推进与故障保护修复
|
||
|
||
### 问题与实际修改
|
||
|
||
- **原话理解**：人数以指令、量词和候选对象绑定，支持中间长修饰语，不跨短句接价格、型号或团队规模；范围、否定、引用和代码仍不擅取端点。原任务整句现在为2位、csv+explicit_demand，账号号可选、地区不额外必填。跨逗号“能取得就记录，没有就说明”作为条件记录语义；“必须有”“才计入”仍是必要条件，不被一般继续找的语句放松。
|
||
- **旧任务继续**：`reground_requirements`纯函数只重核字段；编排仅在明确继续时用原用户会话修正旧编译值。保留卡片后确认的1位、追加旧目标版本和纠正记录，不修改原话/旧验收/旧文件或给历史补目标版本。标记 `request-fields-v2` 保证幂等，新解释与结构化计划记录版本。复核失败后的继续分支也先重核；没有用户原话依据则不改。此修正没有在本轮实际用户任务上执行。
|
||
- **评论推进**：来源观察明确 `comments_not_in_view`，底部101等计数不当作评论已读；`advance_comments(enter|next)`只点击当前唯一可见评论入口或对刚观察的实际容器做一次原生滚动，模型不传坐标/CSS/猜造URL，无新增不宣称读完。重复无变化保留未读范围，已有来源摘要提供当前笔记source_id，续跑能补作者关联而不重复存原文。
|
||
- **作者入口与归属**：`open_source_profile(source_id)`重新核对原笔记、独立原话、作者及实际唯一profile锚点，再原生点击和观察目的页。已保存comment/reply有稳定source_key时，缺失或变化均拒绝，避免同昵称同原话冒认；不把悬浮卡当完整主页，不为未知入口拼URL。旧来源可补新观察的主页关联，原事实不回写；原地hover/未推进禁重复点击。`navigation_attempts`带稳定ID并进恢复、检查点和最终产物，尚不直接计知识成功或扩大触达权限。
|
||
- **无进展保护**：新增 `progress_guard.py`，按当前页面和各操作目标分开累计，脱离临时DOM索引/悬浮文本。穿插wait/inspect、失败navigate/back、空scroll、负或未知reply日志不清零；实际页面/滚动位置、当前来源/主页关联及成功展开事实才重置。保留无默认总步数/阅读配额，程序失败也不自动记方法反证。
|
||
- **动作诊断及停止原因**：新增 `diagnostics.py`，仅记录Schema声明字段路径与Pydantic标准错误type，未知字段替换，剔除input/msg/context/原始响应和异常链；诊断写失败不触发模型重试。安全纠错提示随原有下一步请求提供，不加修复模型调用。当前run记录 `program_failure_limit` 和有界 `model_diagnostics`，区分 `model_schema_error`/`model_failure_limit`，实际401/402/429继续具体呈现，早期已恢复错误不能覆盖最后原因；失败收尾模型自报成功也不能覆盖程序事实。新进度URL去掉userinfo/query/fragment，完整实际URL只留任务来源证据。旧8次错误具体字段未保存，无法事后补造或断言已根治其全部实际格式成因。
|
||
- **追溯和界面**：新建内嵌会话与独立/续跑分支都传实际goal_version，测试覆盖真实新建embedded分支。知识页把场景不兼容标“本阶段不适用”，与未解决反证的“当前场景暂停”分别筛选；不把其他阶段的有效成功显示成整体归零，不改后台选择及验证计数。
|
||
|
||
### 验证结果
|
||
|
||
最终完整后端 **928项 / 6.82秒通过**，类型检查、桌面构建、8项粒子调度器和差异检查通过。新增回归覆盖整段原话及自然表达/负例、后确认人数与版本/文件/事件保留、review_error继续分支、导航恢复并集、窄视口/悬浮卡/稳定评论ID、实际原生点击/滚动调用、交错等待与空滚动的循环保护、新建embedded追溯、诊断脱敏/失败存储及连续失败原因。Node内存DOM夹具实际执行三个页面观察脚本，确认note作者header、评论/回复独立容器及歧义拒绝；没有打开真实浏览器或执行平台动作。
|
||
|
||
确认5条历史无运行任务、活动网页为空后正常退出旧实例，`npm start`加载最终后端PID14337，API及原生桌面均已连接，deepseek-flash及原Key保留。CUA只读打开最新任务，核对5条历史、当前仍0/1与原文件、正文方法1次真实成功、导出本阶段不适用及旧历史缺统计；未点击继续/复核/导出。已恢复待命首页。截图 `data/ui-verification/d38-desktop-stage-applicability.png`、`d38-desktop-home-live.png`。原生截图/滚动接口曾有一次临时捕捉失败，重新绑定后读取和界面状态正常，没有将工具错误当应用故障。启动早期请求先于后端ready有ECONNREFUSED，随后健康及界面正常；既有Vite/FastAPI提醒未阻断。
|
||
|
||
### 接下来与真实边界
|
||
|
||
本轮没有真实模型、Search/Fetch、小红书采集、关注或私信，没有提交推送。用户任务、旧通用草稿、新方法/验证事件/业务反馈分别做数据库内容摘要对比，修复与测试未修改真实记录；仍只有正文保存和导出两条trial、各1独立成功，未虚增为跨任务复用。新版未自动重写旧任务的错误条件或停止原因，也未给旧事实补版本。
|
||
|
||
脱敏验收汇总 `data/ui-verification/d38-implementation-verification.json`，包含原话新任务target2/字段csv+explicit_demand、纯重核旧任务保留target1，以及5张真实业务表内容摘要一致。旧任务仍为目标版本2、原26次模型请求/385275总tokens，本轮未增加调用；后续明确继续才进入新的修正版本。
|
||
|
||
下一步用户可打开上一条任务点继续：按原话修正字段且保留已确认1位，先验证评论区推进与作者主页归属，检查新日志的实际变化、格式错误字段及停止原因。真实页面适配与模型输出改善仍待这次实际任务验收，不能仅由本地夹具宣称全链路已通。当前任务跑稳后，再用不同对象的新任务验证召回与独立计数；触达继续沿原有对象和话术授权约束。
|
||
|
||
---
|
||
|
||
## 2026-10-29 D39：续跑任务达标审计、持续执行图标与浅色标题栏
|
||
|
||
### 最新任务实际执行到哪
|
||
|
||
只读复查用户已续跑的 `task_94db43a81241`：当前目标版本3、1位，11:52:02结束为completed/results。原话重核已将必要字段改为csv+explicit_demand，账号号仍可选；保留用户卡片后来确认的1位，没有改回原请求的2位。新增正文有本人需求原话及现场观察的作者主页锚点关联，当前1位满足条件、另1组旧来源身份未知。当前版本CSV真实存在、含2行，分别为1位满足条件及1组身份未知；旧版本文件继续保留，不把两行当两位达标。
|
||
|
||
程序历史明确记录 `program_stop.code=target_reached,current=1,target=1`，是在保存及增量判断后停止；上游并未自行done，不能把本轮解释为预算耗尽或异常强停。新段8次浏览器模型尝试、2次增量判断，共新增10次调用；新增输入116705、输出1919、总118624 tokens，其中缓存命中85248。任务累计36次记录调用、503899总tokens，仍为deepseek-flash；这里只报告实际usage，不当完整供应商账单。新增段没有Schema错误，原8次历史错误仍保留，不能推断所有格式场景已根治。首次navigate 30秒超时后通过等待恢复，搜索输入/提交仍有多次尝试，未阻断本轮达标。
|
||
|
||
实际覆盖仍只有2篇正文，评论0、回复0、展开回复0、完整主页打开工具0。新增作者身份来自正文现场锚点，并非已完成主页账号核对；可选小红书号未取得不阻止本次交付。正文先达到1位终点，因此本轮不能用于验收评论推进、回复展开或完整主页工具，也无需为已经完成的1位任务继续采集。
|
||
|
||
### 沉淀及复用核对
|
||
|
||
本次续跑召回1条正文保存方法，新增正文保存与CSV导出事件均携带目标版本3，前后证据引用可读。当前共享结构化方法2条、验证事件4条；两方法覆盖对象增加，但各仍只有1个独立成功任务，保持可试用。重复续跑同一任务不能增加独立任务数，也不能称已完成跨任务优先复用。旧通用记录385保留，未替其补造统计或升级。方法是否可用与交付是否完成分别判断，不要求用户人工审批沉淀内容来凑验证。
|
||
|
||
### 两处界面问题与修改
|
||
|
||
- 输入框此前仅依据短暂的HTTP `busy` 展示提交状态，后台持续执行后又显示发送箭头。现以实际 `task.status=running` 或正在提交消息/必要补充作为转圈依据；反馈、导出等其他短请求不误表示Agent持续执行。空输入时图标仍显示执行中，输入补充后仍可发送，停止沿用任务内按钮。完成、暂停、等待补充或取消恢复发送图标；`aria-busy`及描述随状态更新，减少动态设置保留静态进度图标。
|
||
- macOS此前使用系统深色居中标题栏，与浅色界面不一致。现采用 `hiddenInset` 保留原生红黄绿按钮，按钮位置16/14，渲染40px的 `#eef2f7` 可拖动栏，标题在按钮右侧92px起排。通过预加载只读静态平台标记判断，不增加窗口控制IPC；Windows/Linux保留原生栏，普通浏览器无桌面栏。内容与浏览器插槽按实际DOM边界下移，未改原生WebContentsView的2px park及缩放逻辑。
|
||
|
||
### 验证与运行
|
||
|
||
类型检查、桌面构建、8项粒子调度器及差异检查通过。本轮仅修改前端和窗口外观，没有重跑已在D38通过的928项后端测试，也不将其写成本轮新结果。
|
||
|
||
隔离CUA夹具实际检查：HTTP返回后任务仍为running且转圈、可输入并发送补充、完成后恢复箭头、运行中使用现有停止后恢复箭头；普通浏览器未显示桌面标题栏。运行、暂停、等待补充、受阻及完成五类状态投影也分别核对。夹具不连接真实模型、平台或用户数据库，临时18795服务和浏览器页已关闭。截图 `data/ui-verification/d39-composer-running-cua.png`、`d39-composer-completed-cua.png`，请求记录 `d39-composer-calls.json`。
|
||
|
||
已确认没有执行中任务后，仅结束并重启本项目旧实例。`npm start` 再次构建成功，新Electron主进程46178、后端46183，health正常、无live session，仍为deepseek-flash且Key已配置。启动早期出现后端尚未监听的短暂ECONNREFUSED，后续meta/tasks轮询均200；不把启动瞬间当作任务执行错误。
|
||
|
||
**原生画面验收受限**：CUA在重启前后累计四次按bundle ID或本项目应用路径读取原生窗口，均30秒超时并重置工具内核；新版进程正常提供服务，但本轮未取得真实标题栏截图，也未验收拖动、红黄绿按钮及全屏效果。浅色栏及左侧标题代码已构建并随重启加载，不能据此声称原生外观已目视验收；浏览器夹具结果只用于输入框状态切换。
|
||
|
||
重启前后，当前工作区tasks5、learned_entries2、prospecting_methods2、validation_events4及business_feedback0全行规范化SHA256一致；任务详情API快照亦完全相同（累计36次调用、503899 tokens），未修改任务、名单或沉淀，也没有新增模型调用。摘要及本轮脱敏核对记录保存于忽略目录 `data/ui-verification/d39-user-data-baseline.json`、`d39-user-data-after.json` 及 `d39-implementation-verification.json`。
|
||
|
||
### 接下来
|
||
|
||
先用“指定一篇笔记、按明确有限范围检查评论及展开回复”的只读专项任务验收讨论容器和父根关系，必要时再核对该来源作者主页，逐段检查实际工具、前后快照与停止原因；不设候选人数作为这一专项的提前停止条件。随后用不同对象的新任务验证方法召回和独立计数。当前已完成的1位结果保留，无需为了测试重复复核或导出；实际关注/私信继续需要独立对象及话术授权。Search/Fetch仍按D31记录暂缓。
|
||
|
||
本轮开发及审计没有追加真实模型、小红书采集、关注或私信，没有提交或推送；用户自己触发的上述续跑与本轮工程验证分开记录。
|
||
|
||
---
|
||
|
||
## 2026-10-29 D40：真实桌面有限评论验证、原生标题栏核对与范围缺口
|
||
|
||
### 验证范围与实际结果
|
||
|
||
用户要求由助手控制桌面自行验证，或给出可直接输入的验证话术。本轮通过CUA从待命首页新建 `task_a2c05ef42e53`，指定已有任务中的一个实际笔记链接，只检查这一页，评论与回复合计最多8条；不按候选人数停止，不搜索其他笔记，不关注、点赞、评论或私信。程序编译为intent=inspect、subject_urls1、target_candidates=null、max_notes=null、max_comments_per_note=8、目标版本1，没有继承原任务的1位目标。此8条是本次明确测试范围，不是新增应用默认业务配额；当前参数约束的是评论及回复合计保存上限。
|
||
|
||
任务13:18:59开始、13:20:12结束为completed/results，stop_reason=agent_done；实际保存正文1、评论5、回复3，合计8条讨论来源，动作账本无触达。`advance_comments`一次返回not_moved，随后真实滚动及来源保存取得进展，未持续空转。原已交付的 `task_94db43a81241` 未被续跑或重写，仍为已确认1位的原结果。
|
||
|
||
### 问题与不能判通过的部分
|
||
|
||
3条reply虽然有独立可见原文及作者，parent_source_selector、root_source_selector、parent_source_id、root_source_id和reply_to均为空；程序post_snapshot明确relations_checked=False。这些来源只证明取得回复文字，不能证明父根关系及回复对象正确。`reply_expansions`为空、专用expand_replies调用0；历史有1次通用click，但没有该父讨论的前后展开证据，不能据此推断已经展开。本次页面已有可见子回复，读取它们也不等于验证了“展开X条回复”分支。
|
||
|
||
当前完成判定对指定页面、模型结束及已有来源分析做检查，尚未硬性核验用户明确要求的回复归属、展开与未读范围；因此completed不能作为本次完整需求通过的依据，整体完成表达过强。完整讨论链路仍未通过。`_OBSERVE_SOURCE`依赖评论祖先关系，且contentFor要求`.content,.note-text`匹配唯一；这些是父根为空的排查位置，尚未取得足够真实DOM结构确认具体成因，不能把代码假设写成已确定根因。本轮没有修改实现，也没有回填旧关系。
|
||
|
||
### 沉淀与模型用量核对
|
||
|
||
任务召回1条正文保存方法；新增11条验证事件，7条success、4条unknown。其中正文保存1次及5条独立评论保存通过程序验收，3条回复保存均因关系未核实保持unknown；另有模型经验回执，不增加程序成功。正文方法现有2个独立成功任务、仍为trial；同篇对象重查不当作新增对象。评论方法1个独立成功任务、trial；回复方法0成功及3次unknown、exploration；正文与评论组合虽有1次阶段成功，但依赖版本未确认而保持paused，不将其升级成完整展开、主页或触达链路。
|
||
|
||
本次真实模型22次调用：意图1、网页20、分析1。供应商实际usage共394701 tokens，输入385677、输出9024、缓存命中292608、缓存未命中93069；不推算供应商费用或当完整账单。Schema诊断事件0、连续Schema错误0；一次report_learning_outcome因缺少当前页面逐字证据被拒，随后confirmed回执被接受，但相应模型回执仍不构成程序成功。脱敏只读审计 `data/ui-verification/d40-real-comments-audit.json` 不含来源原话、个人信息或完整签名链接。
|
||
|
||
### 桌面界面核对
|
||
|
||
CUA原生捕捉曾报SCStream3811，重新绑定应用后恢复读取。真实截图 `data/ui-verification/d40-desktop-titlebar-live.png` 可见40px浅色栏及左侧标题，补充了D39未取得原生画面的缺项。原生红黄绿控制在AX中存在，但当前捕捉像素未显示，不能据此认定其视觉或可操作性已验收；未检查拖动及全屏。
|
||
|
||
真实任务运行期间AX中输入框按钮为“任务执行中”，结束并重新绑定后为“发送消息”；结束截图 `data/ui-verification/d40-composer-real-completed.png`。运行中截图曾异常缩小或捕捉失败，因此本轮只确认实际任务的状态标签切换，不能把它写成持续旋转像素已完整验证；该部分仍引用D39隔离CUA的验证范围。
|
||
|
||
### 接下来
|
||
|
||
优先取得实际讨论DOM归属依据并修复父根关联，再让明确的评论/展开/归属要求进入范围完成校验：缺失时交付已有资料并说明未完成分支，不能只按模型done显示整体完成。随后重复同类指定笔记、有限条数、只读任务，检查真实父根ID、同讨论展开前后证据及程序停止原因；没有实际展开入口只能记该分支未覆盖，不能补造成功。独立对象的新任务再验证方法复用与排名。
|
||
|
||
本轮只执行上述明确范围的真实验证并更新记录，没有改代码、重启应用或重跑后端/构建测试，也没有关注、私信、提交或推送。
|
||
|
||
---
|
||
|
||
## 2026-10-29 D41：控制桌面复测讨论归属、专用展开与真实部分交付
|
||
|
||
### 已确认的问题与实现
|
||
|
||
用户明确继续由助手控制桌面测试，沿D40暴露的问题做聚焦修复，再通过CUA新建两条真实只读任务。每次只检查原历史的一篇笔记、一个讨论组，评论与回复合计最多4条；intent=inspect、subject_urls1、target_candidates=null，不继承原来的候选人数，不搜索其他笔记，不执行触达。4条是本次测试上限，不是必须读满4条或应用默认配额。
|
||
|
||
- 来源候选原先分别尝试`.content`和`.note-text`，保存观察却合并两类后要求恰好一个节点；嵌套文本节点会导致候选可读但父根定位空。现统一选择独立发言记录内唯一最外层原文节点；同一原文包装不当两条，独立并列内容继续拒绝。嵌套记录沿实际祖先关联父根；明确`.parent-comment`等讨论组内唯一根评论与回复列表为兄弟时也能核对根讨论。平级回复有回复对象标记或“回复”前缀、却没有唯一实际评论引用时，直接父评论保持未知；不按昵称、顺序或相邻位置猜。明确DOM父评论ID也须在同组唯一匹配，冲突不回退猜根。
|
||
- 展开原先仅扫描button/a/span等，要求入口处在评论记录祖先内，可能漏掉同组兄弟容器的div文字入口。现按唯一实际讨论组限定入口与结果，支持div入口及原生点击；根ID缺失时只在当前笔记唯一根原文能够核对的情况下继续。检查结果提供已渲染入口的in_view/position及白名单label/rendered/viewport/owner/leaf/unique计数；先把入口推进视口，再调用expand_replies，不让反复find_elements或通用click代替取证。
|
||
- 5条来源批量只供分段阅读，不能作为展开前完整回复集合。展开同组前后另核对最多100个可见回复定位及集合完整性，快照不完整保持unknown；同组数量增加及新增独立回复均成立才有程序成功。100是单次内部观察边界，不是业务阅读上限。源信息、快照及指纹保留在任务证据，共享知识仍只有引用与摘要。
|
||
- 新增独立的讨论范围校验：仅对指定页面/明确篇数的inspect/research，从用户直接要求提取评论、回复、展开及关系，忽略引用和网页文字、保留后续明确取消。必须有实际保存事件、同讨论展开前后证据和真实父根链；模型done、评论数量或正文已读不能代替。缺项仍交付已有资料，但必要条件显示未满足和阶段成果，不再统一报“已完成要求”。
|
||
|
||
### 第一轮真实复测
|
||
|
||
`task_3677303e5c3c` 13:40:24开始、13:42:06结束。保存正文1、评论1、回复1；回复已正确关联实际根评论，直接父评论及回复对象仍未知，因此回复保存事件保持unknown。最初comments_not_in_view、advance_comments(enter)未推进，模型又重复检查与find_elements，直到一次实际滚动后取得讨论来源；没有把DOM中存在评论当作已进入视口。
|
||
|
||
实际可见“展开4条回复”，但检查返回无reply_controls，模型使用一次通用click后取得新内容。专用expand_replies0、展开事件0，不能据模型点击总结验收展开。此结果促成后续入口视口元信息、筛选计数和完整owner快照修复。最终运行状态completed/agent_done，但交付投影正确为partial，分别显示展开及回复关系条件未满足，程序完成范围没有被模型done覆盖。
|
||
|
||
本次26次模型调用：意图1、网页24、分析1；有返回usage的总433240 tokens，输入424176、输出9064、缓存命中346752、未命中77424。4次结构错误（action missing1、json_invalid3）、1次连接错误；1次调用没有返回usage，不能把上述总数当完整供应商账单。连续结构错误最终0不代表此前错误不存在。召回4条方法、新增4条验证事件（3success、1unknown）；同组重复评论覆盖任务增加，但独立对象成功不增加，回复仍0成功。
|
||
|
||
### 第二轮真实复测及新发现
|
||
|
||
`task_d94d216b8b20` 13:51:29开始、13:52:27结束。仍为同篇、同组、最多4条讨论来源；保存正文1、评论1、回复1，无触达。13:51:48检查的label/rendered/viewport/owner/leaf/unique计数均为1；模型使用专用expand_replies一次，程序确认同owner新增1条、reply_count从1到2、前后快照完整及parent_scope_checked=true，展开操作验收success。展开后入口计数0为状态变化，不能再记成此前的入口漏检。
|
||
|
||
保存回复的根讨论正确，直接父评论仍为空；该平级回复带有回复对象前缀，当前没有足够唯一引用核实直接父评论，保守保留未知。不能把根讨论已知当作父子关系全通过。实际任务最终显示partial，回复关系未完成继续保留。
|
||
|
||
另发现一处合法摘录的匹配假阴性：展开事件按完整候选原文生成指纹，而保存来源允许经程序逐字校验的短摘录。当前43字摘录与新增全文指纹直接比较不相等。只读复核发现该来源定位不在完整的展开前回复集合中；同一稳定来源key在D40有已核验54字全文，当前43字为其原样子串。将该既有全文按实际文本节点可能的空白边界组合对照，128种中有且仅有一种精确命中本次程序新增全文指纹，确认实际保存了新增回复的合法摘录。该离线核对没有改写来源、事件、方法或虚增成功；当前程序展开条件仍因全文与摘录差异为false，需要用程序观察的完整容器规范指纹关联摘录，而非比较模型摘录全文。
|
||
|
||
本次17次调用：意图1、网页15、分析1；usage完整返回，总293148 tokens，输入285910、输出7238、缓存命中235136、未命中50774。4次结构错误（action missing1、json_invalid3），另2次report_learning_outcome因缺少当前页面逐字证据被拒。模型重复提交学习回执6次仍未构成程序成功；实际召回4条方法、新增6事件（4success、2unknown）。专用展开方法有首次程序成功，回复方法继续0成功；同组重查不增加独立对象覆盖，正文与评论组合仍受依赖状态约束，未抬成完整展开/主页/触达链路。
|
||
|
||
### 工程验证、界面及数据保护
|
||
|
||
首批完整后端990项及类型/构建/8项粒子检查通过；补充控件计数、视口状态与owner完整快照后完整1000项通过，随后一行owner隐私收紧的相关16项通过。新增真实观察脚本内存DOM回归覆盖嵌套文本、兄弟讨论组、重名与歧义拒绝、直接回复及未知目标、同owner展开、跨讨论新增与完整快照等；这些本机结果与上述真实任务分别报告。
|
||
|
||
最终已增加程序容器规范指纹：原话校验通过后，保存操作前快照记录当前完整独立容器的规范指纹；展开后仅对最多5条实际新增候选重新只读核对同篇、reply类型及逐字包含，保存相同规范指纹。额外观察失败仅缺少附加证据，不重试点击或模型。交付匹配当前目标版本、来源ID、定位、原话校验和持久保存的程序事实，允许合法短摘录关联完整容器；旧精确全文指纹仍兼容。不补两轮历史事实，不把旧缺证据翻成通过。
|
||
|
||
最终完整后端 **1017项 / 7.82秒通过**，新增回归覆盖合法摘录、不同帖子/来源/定位/目标版本、坏原话与模型伪造指纹拒绝、附加观察失败不重试。类型、构建、8项粒子检查及差异检查通过。最后容器指纹修复仅由本机回归验证，没有第三轮付费任务；脱敏汇总 `data/ui-verification/d41-implementation-verification.json`。
|
||
|
||
修复前已确认空闲，仅重启本项目实例；第一轮重启前后工作区tasks6、learned_entries4、methods5、validation_events15及business_feedback0全行摘要一致，记录 `data/ui-verification/d41-user-data-before-restart.json`、`d41-user-data-after-restart.json`。实际新任务及其证据正常追加，不能拿新增业务记录后的整表摘要与旧基线要求相等；最终排除本轮两个新任务后的原6条任务内容摘要与基线一致。当前tasks8、learned_entries4、methods6、validation_events25、business_feedback0，核对见 `data/ui-verification/d41-original-task-integrity.json`。
|
||
|
||
CUA实际截图 `data/ui-verification/d41-partial-delivery-live.png` 已显示浅色栏、左侧标题及原生红黄绿三个按钮，补齐D40的按钮像素缺项；未测试拖动、全屏或按钮操作。真实任务状态标签与结束后的发送箭头恢复得到核对，不能由静态截图断言持续旋转轨迹。末次原生读取出现cgWindowNotFound；在任务结束且空闲后重启本项目加载最终后端47044，API健康、无live session、Key保留、模型仍为deepseek-flash。重启后CUA两次getApp各30秒超时，未取得收尾新截图；不把窗口控制工具错误当业务执行失败，也不声称末次原生画面已验收。启动早期短暂ECONNREFUSED在API就绪后恢复。
|
||
|
||
两轮脱敏审计为 `data/ui-verification/d41-real-discussion-audit.json`、`d41-second-real-discussion-audit.json`，不含来源原话、个人信息及完整签名链接。没有修改Key、模型或配置，仍使用deepseek-flash；没有关注、点赞、发评论、私信、提交或推送。
|
||
|
||
### 接下来
|
||
|
||
后续正常任务验证新的程序容器指纹绑定，并按现场证据核对直接父评论和回复对象。不能因这次真实专用展开通过就宣称完整父子链路通过；没有唯一直接父依据时继续保留未知。模型结构错误和重复学习回执造成额外调用仍是待优化项，应按实际错误和使用量继续定位，不增加隐藏业务配额或额外模型修复轮。不同对象的正常任务再验证知识独立覆盖与复用，不重复当前同组仅为提高排名。
|
||
|
||
---
|
||
|
||
## 2026-10-29 D42：回复对象归属、原生结构协议与桌面再验收
|
||
|
||
### 本轮范围与修复
|
||
|
||
用户明确要求把回复归属和模型结构错误继续修好，并由助手直接控制桌面端复测。本轮沿原项目开发、启动及只读验收，保留DeepSeek模型、Key、端点和原有业务资料；没有关注、点赞、收藏、发评论或私信，不触碰同级项目。
|
||
|
||
- **回复对象与来源归属**：D41对平级回复只能确认根讨论，带“回复某人”前缀时直接父对象仍未知。本轮增加实际目标头部/标记/链接及稳定属性的只读观察，只有同组唯一评论引用，或实际目标主页身份与同组唯一候选相符时才归属；同名、多个目标、多个候选或冲突继续未知。来源保存留parent_resolution及有界白名单计数，并按实际source_key/定位核对已保存父根。重新观察可形成新的当前事实，但旧原话及不可变操作事件不改、不根据昵称补造历史关系。最终的回复→回复分支仍必须由实页样本验收，不能拿根评论→直接回复替代。
|
||
- **模型结构协议**：此前手工把Schema放入提示并使用自由文本JSON模式，诊断显示json_invalid及action缺失，旧原始响应未保存，无法事后断言具体坏字符。现通过标准端点强制一次命名函数 `return_structured_output` 提交完整Agent输出Schema，本地Pydantic仍完整校验；保持截图、关闭思考、实际usage和max_retries=0。系统契约合并原system消息，不改变最后消息角色，不从content猜动作，不为不合格结果补参数或修JSON。空/多/错名调用、非法参数JSON、重复键、NaN、非对象和空动作都拒绝。结构拒绝在程序中用422表示，避免被当作供应商502；它不代表上游真实返回HTTP422。官方依据：[Tool Calls](https://api-docs.deepseek.com/zh-cn/guides/tool_calls/)、[Chat Completions](https://api-docs.deepseek.com/zh-cn/api/create-chat-completion/)。本轮未启用Beta strict或修改base URL。
|
||
- **正常下一步纠错**：pinned framework会把无有效model_output的历史压成通用格式失败文字，具体安全字段/类型提示可能丢失。`diagnostics.pending_correction_hint()`只暴露当前run尚未纠正的程序诊断；GoalBasedAgent在原有正常下一步加入该提示，不额外发起模型修复调用，不把失败动作拿去执行。成功响应清零、不同任务及运行隔离；诊断不保存原始提示/响应、原话、凭据或任意字段名。
|
||
- **明确组范围**：首轮实测暴露“一个讨论组”只在提示中约束、仍可能跨组。新增 `discussion_bounds.py` 从真实用户会话识别“第一组/首组”与“一个组”，忽略引用、示例和否定，允许后来明确取消。来源检查及保存都核对当前目标版本的真实根key；“one”先唯一选择根，再约束后续保存，“first”不以当前滚动后遇到的任意组替代最初首组。续跑只刷新正式请求消息和版本上下文，不以旧快照覆盖未落盘来源/展开/操作事实。组范围是本次明确限制，不是应用默认业务配额。
|
||
- **完成要求语义**：补识别“完整回复链”“逐条核对发言人、直接父评论或父回复、根讨论”等明确归属要求。另加 `discussion_reply_to_reply` 条件，只在“回复该父回复/回复另一条回复/回复父回复的子回复”等明确二级分支要求时触发；泛称完整链或“父评论或父回复”不要求二级样本。该分支必须是当前目标真正展开新增且保存的子回复、parent确为已保存reply，子/父均有本目标成功关系事实并通到同篇根评论；普通根→回复不能代替。条数上限仍是上限，不变最低数量。
|
||
- **展开点击与命中**：沿D41同组前后完整回复集合及程序容器指纹继续核对新增，合法短摘录与完整容器身份分开。本轮两次实测都出现实际有入口却未通过旧完整几何/视口检查的问题；日志不足以确定是哪个DOM祖先或坐标变化导致，不能硬写成精确根因。最终改为浏览器 `elementFromPoint` 的paint/hit测试，在当前视口交集中的有界探针找实际可命中位置，重新核对笔记、组身份及指纹后，使用当前原生mouse坐标点击。没有用手工祖先裁剪推定可见，也不让会自动滚动的Element.click使用预滚动坐标。遮挡、入口变化、位置无依据等仍拒绝，保留具体白名单原因；此最终处理的真实验收结果见本节收尾。
|
||
- **原生目标核对与主页弹窗**：增加 `resolve_reply_target`，只从重新观察到的实际回复前缀入口出发，先原生移入，再重新核对来源、全文、目标、当前命中点及运行上下文后点击。仅实际进入具有可见身份头部的主页，再原生返回且重新核对原来源成功，才允许将本轮短期身份依据用于同组唯一父回复；无导航、未返回、候选冲突及同作者多条发言均保持未知，不构造主页URL。Electron原先拒绝所有新窗口；现只允许实际页面触发的小红书HTTPS主页入口在同一视图打开，其他弹窗继续拒绝，并只记白名单分类和动作。手动点击实际作者头部已验证该弹窗分支；回复前缀入口本身未导航，不能用作者主页替代回复目标身份。
|
||
|
||
### 第一轮真实任务：结构协议通过，组范围和展开仍有缺口
|
||
|
||
`task_ecb1d68bc3dc` 最终completed/results，结束时间14:23:50。取得正文1、评论3、回复2，讨论保存合计5条；同篇但跨讨论组，未满足用户仅一组的要求。第一条直接回复的父/root均正确关联已保存根评论并形成程序成功；另一组回复虽然现场有父根key，原父来源未完成对应保存，关系仍未知。没有实际回复→回复样本。
|
||
|
||
31次模型调用为意图1、网页29、分析1，全部成功记录；浏览器29次finish_reason均为tool_calls，Schema诊断0、结构错误0，没有因新协议发生HTTP400。usage总676458 tokens，输入662387、输出14071、缓存命中523776、未命中138611。此结果只证明本轮原生协议实际被供应商接受并通过结构校验，不能推断后续永远零格式错误。
|
||
|
||
专用展开工具调用5次，仅1条持久展开事件，状态no_new_content、同组核对成立但未取得新增；其余为重复无新增/入口重核拒绝。共有5条工具错误（重复无新增2、入口重核2、经验逐字证据拒绝1），不是模型Schema错误。最终partial，展开条件未满足；当时“完整回复链”未命中关系必要条件，随后修复纯读取投影，不改任务原运行状态或旧事实。知识新增11事件（success6、unknown4、unused1），没有把方法整体升为完整二级链路。
|
||
|
||
### 第二轮真实任务：组范围生效，入口误拒与二级要求继续修正
|
||
|
||
`task_efca3c7539c5` 仅当前指定组，保存正文1、评论1、回复1；已保存回复正确指向根评论，仍只有根→直接回复，不能充当用户要的“回复该父回复”的新增子回复。任务因内部no_progress结束为blocked/stage_results，没有外部登录、验证码或平台限制依据，不能写成平台封禁或配额耗尽。
|
||
|
||
23次模型调用为意图1、网页21、分析1，全部成功、结构诊断0。usage总461500 tokens，输入453006、输出8494、缓存命中366336、未命中86670。前两轮合计54次实际模型调用（浏览器50次），Schema错误及新协议HTTP400均0。实际用量逐轮保留，不推算账单或把程序拒绝当未消耗tokens。
|
||
|
||
折叠入口的label/rendered/owner/leaf/unique计数均存在，viewport计数始终0，专用展开4次均在点击前被旧入口可见性检查拒绝，没有展开事件。不能把这4次调用记成功，也不能因页面有“展开”文字就记已展开。组范围不是本次过滤失败原因；后续paint/hit测试取代旧几何判定，精确DOM因果仍待实证。原回复关系条件1/1只说明根→回复已关联，另增显式二级分支条件，避免今后只完成一级就报完整用户要求。任务保持partial；本轮知识新增6条事件，无触达。
|
||
|
||
### 第三至第七段：同篇续跑与真实点击边界
|
||
|
||
以下均为第二个任务的续跑，不算新的独立任务或独立对象验证；条数上限仍是本次用户明确的讨论取证范围。
|
||
|
||
| 段次及调用区间 | 模型调用 | 实际结果与边界 |
|
||
| --- | --- | --- |
|
||
| 第三段 `[23:47]` | 24次，均成功、Schema 0 | 保存正文1、评论1、回复4且都在指定组；3条回复直接关联根评论，带回复目标前缀的子回复仍只有根、无直接父依据。普通点击出现展开，但没有对应程序展开事件，不能计专用展开成功。 |
|
||
| 第四段 `[47:54]` | 7次，均成功、Schema 0 | 来源不变；专用展开仍被可见性核对拒绝，没有目标身份核对调用。内部执行失败，不推断外部平台拦截。 |
|
||
| 第五段 `[54:64]` | 10次，均成功、Schema 0 | 专用展开取得同组回复增量4、新可见3及完整前后集合，合法摘录按程序容器指纹成功绑定。本轮首次原生目标点击为 `not_moved`，未进入主页或返回，直接父仍未知。 |
|
||
| 第六段 `[64:68]` | 4次：成功3、连接错误1、Schema 0 | 接管后停止。CUA手动展开4条回复，点击回复前缀名字无导航、无悬浮卡；当时宿主仍拒绝所有弹窗。没有新增归属事实，不把手动动作当程序验收；连接错误的具体外部原因没有证据。 |
|
||
| 第七段 `[68:80]` | 12次：网页10、意图1、分析1，均成功、Schema 0 | 未新增来源或调用目标身份工具。展开事件虽观察到同组增量3、新可见2，但前后集合不完整，正确保持unknown。后来补充网页回查被 `reuse_existing_sources` 误路由到已有资料分析，进入目标版本2；该路由随后已完成工程修正及本地回归，尚未再跑实页任务。 |
|
||
|
||
第七段手动CUA再次确认回复前缀点击无导航、无弹窗；实际作者头部的真实主页链接则产生 `open_same_view`、`opened_same_view` 各1条安全诊断，并显示完整主页。两者不是同一目标，不能据此填子回复的父身份。手动返回键未成功，主页→原笔记返回与目标重新核对仍未验收。
|
||
|
||
截至收尾，第二个任务运行状态为completed/results，但交付投影仍为partial：所存4条回复的关系为3/4，展开后回复→父回复为0/1。新目标版本2不能沿用目标版本1的展开成功，当前展开条件为0/1；没有把运行结束或名单已显示等同于完整专项通过。
|
||
|
||
### 工程验证、用量与资料完整性
|
||
|
||
原生命中、移入后重新核对、身份冲突与返回失败保留未知等完成后，全后端1173项通过；补充回查路由修正后，最终全量1209项通过（18.63秒）。原生弹窗Node检查11项、TypeScript检查及最终桌面构建通过。原生函数适配、范围/语言和显式二级条件均有定向验证。本机夹具与真实平台分别验收，测试通过不替代未完成的实际回复→回复和返回分支。
|
||
|
||
新增 `request_routing.py` 按真实追加指令识别明确网页回查、原生历史返回及实际回复对象工具；意图落地、准备和执行三处不再仅信模型 `reuse_existing_sources`。明确回查时“已保存、不新增来源”不等于禁止网页；引用、否定和纯离线复核仍走各自正常路径。回查提示从当前页/原生历史核对，避免默认重新打开首页及搜索。仅在明确网页回查且明确禁止分析的窄范围，结束后保留旧分析、目标版本、缓存、判断及名单，不追加付费分析；未知关系不补造。该修正有145项相关回归及上述完整后端结果，没有追加付费或真实平台任务。
|
||
|
||
两任务累计111次模型调用：意图3、网页103、分析5；110次成功、1次连接错误、Schema错误0。102次成功网页响应均为tool_calls，没有新协议HTTP400证据。已返回usage合计2221427 tokens（输入2177463、输出43964、缓存命中1732352、未命中445111）；连接错误的1次没有返回usage，因此这不是完整供应商账单，不能把未知消耗当零。第七段为218606 tokens。模型仍为deepseek-flash，未改Key、模型或端点，也未为修结构增加额外独立模型修复轮。
|
||
|
||
CUA实际截图 `data/ui-verification/d42-running-live.png` 能核对执行中进度图标、产品标识和原生红黄绿按钮，不从单张画面断言完整动画轨迹。真实点击验证时后端PID68697、主启动会话53919；只读收尾时无live任务。最终构建并重启加载全部修正，后端PID90298、主启动会话56878，health=ok；CUA重新打开原验证对话，能看到“部分交付”和保留的80次调用，未点击继续或启动新模型任务。结束截图为 `data/ui-verification/d42-final-desktop-state.png`。旧运行事实不因重启重新判成功，用户无须再为加载本轮修正手动重启。
|
||
|
||
`data/ui-verification/d42-final-integrity.json` 精确核对原8条任务完整行摘要与基线一致，原6条方法、原25条验证事件及空业务反馈表也一致。当前tasks10、learned_entries4、methods7、validation_events48、business_feedback0，即正常新增任务2、方法1、验证事件23。learned_entries条数未变但整表摘要已变：3条既有draft操作草稿由第二任务正常复盘刷新，不能宣称所有表均未改变；没有手工改库或回填历史关系。当前正文方法独立对象2、评论/回复/展开方法各1，方法仍trial、阶段链路paused，不把同篇多次续跑抬为独立覆盖或完整链路成功。
|
||
|
||
分段审计从 `d42-first-real-audit.json` 至 `d42-seventh-phase-real-audit.json`，最终汇总 `d42-final-verification.json`，均在忽略的 `data/ui-verification/`，只保留程序状态、计数及摘要，不写姓名原话、凭据或完整签名链接。原记录、失败及用量保留。没有提交、推送或关注、点赞、收藏、发评论、私信。
|
||
|
||
### 收尾与后续边界
|
||
|
||
结构协议已取得111次实际调用中零Schema错误的本轮证据；组范围、同组专用展开和新容器绑定也分别获得实际验证。二级直接父身份、主页返回与目标重新核对仍未通过，不能宣称回复归属整链路已修通。下一步先确保用户追加网页回查进入浏览器，再以真实可操作入口核对唯一父身份；若前缀本身不可跳转且没有唯一评论引用，应清楚交付未知，不能靠昵称、顺序或作者主页猜。只有当前目标真正新增并保存的子回复、已保存父回复、程序前后证据和归属完成条件同时成立，才验收二级分支。缺项继续部分交付；不为凑成功继续同篇付费重跑或抬高知识排名。
|
||
|
||
|
||
---
|
||
|
||
## 2026-10-29 D43：新样本现场预检、登录暂停及本人接续
|
||
|
||
### 阶段范围与暂停证据
|
||
|
||
本轮寻找不同于D42缺少唯一直接父依据的样本，先以桌面端有限只读任务做现场预检，再判断是否具备可核对的二级回复链。新任务 `task_97f09ffb24c4` 经UI启动，初始目标版本1允许候选笔记浏览最多2篇，限定一个讨论组，正文最多1条、评论与回复合计最多4条，不分析名单、不互动；程序为discover、max_notes=2、max_comments_per_note=4、target_candidates=null、目标版本1，没有新增默认配额。
|
||
|
||
首次搜索在17:38:13暂停为paused/login_or_question，stop_reason=awaiting_user。只读检查保存的 `data/tasks/task_97f09ffb24c4/steps/step_003.png`，实际可见“登录后查看搜索结果”及登录控件，确认是当前搜索入口的登录门槛，而非仅根据模型话术或状态名猜测。没有把它解释为封号、风控或Key故障；CUA曾出现cgWindowNotFound是独立窗口捕捉问题，不能拿它解释平台登录原因。审计不复制二维码或认证信息。
|
||
|
||
截至这一暂停阶段，来源0、关注/点赞/收藏/评论/私信0；4次模型调用（意图1、网页3）全部成功，Schema及浏览器错误0。已返回usage52479 tokens，输入51265、输出1214、缓存命中41728、未命中9537；没有名单分析调用。原生会话保留，未为暂停空转重试。记录 `data/ui-verification/d43-login-pause-audit.json`。
|
||
|
||
### 原生窗口准备与本人接续
|
||
|
||
随后通过CUA接管并Raise到前台，刷新已过期二维码；最新AX核对loginPromptVisible=true、qrExpired=false、humanTakeover=true。没有代替用户登录、填写凭据或点击继续。只读API核对仍为paused、live_session=true、takeover=true，来源及模型调用未新增。用户之后已回复本人完成登录；这是恢复验证中的阶段记录，不以等待登录作为本轮最终收尾，登录后页面和新样本的二级回复关系仍须现场核对。
|
||
|
||
### 资料及沉淀完整性
|
||
|
||
本轮开始基线 `data/ui-verification/d43-baseline.json` 保存原10条任务逐行及整表规范摘要、经验/方法/验证事件/反馈摘要、各任务用量文件摘要及原调用状态。暂停准备后原10条任务完整行摘要全部一致，learned_entries4、methods7及business_feedback0摘要不变。验证事件整表由48增至54，原48条行内容摘要完全一致；新增6条均属于新暂停任务且outcome=unused，不是新的技术成功，不能宣称事件整表未变化，也不能当作方法已试用成功。当前task总数11，只正常新增该暂停任务，未修改旧任务。核对见 `data/ui-verification/d43-paused-takeover-integrity.json`。
|
||
|
||
以上为初始登录暂停阶段记录：当时没有业务代码或配置修改，也未人工改库，真实任务及unused回执按正常流程追加。本人登录后继续现场验证及工程修复的结果如下，不能把暂停准备当作二级回复分支验收。
|
||
|
||
|
||
### 登录后续跑误入应用页与工程修复
|
||
|
||
本人回复已登录后，CUA确认搜索正常，并从实际搜索结果手动打开一篇不同于D42的笔记；预检时没有展开、保存或触达。随后通过UI补充“当前实际页面核对、仅该新笔记第一组、正文最多1条、评论与回复合计最多4条、不重新搜索或分析”。该目标版本2确实进入浏览器而非已有资料分析：新增8次调用为意图1、网页7，分析0。但没有取得来源，模型三次尝试导航 `app://ui/index.html` 并收到site unavailable，不能据此说新小红书笔记不可访问或又需登录。此前复用路径没有像新建路径一样重新聚焦本任务受管target；原始焦点事件未存，不能把具体时序竞态写成已观测事实。
|
||
|
||
该段有1次命名函数响应未通过本地动作union校验，安全诊断为extra_forbidden/missing，坏动作未执行；其余7次成功。没有保存原始响应，不能反推具体额外字段、错名或多键内容。已返回usage112977 tokens（输入110592、输出2385、缓存命中102528、未命中8064）。记录 `data/ui-verification/d43-after-login-first-browser-audit.json`，不把这次拒绝从全轮错误数抹掉。
|
||
|
||
本轮新增受管目标保护：在新建、复用、每步上下文准备和实际工具act边界，按task→view→targetId映射核对业务页，重新聚焦时使旧DOM/selector缓存失效；应用UI、其它任务、丢失target或地址变化不允许隐式接管。状态采集后焦点或URL改变，拒绝基于旧状态的动作并要求正常下一步重新观察；不从模型猜测恢复地址。明确给出实际入口时才允许新blank开始，进入业务页后不再把blank当合法回退。
|
||
|
||
显式“当前页”目标修订时，取消旧job的窄上下文会保护其已有受管view，待旧job完成取消后复用该页，避免后台清理先销毁用户刚打开的真实页面。该修订及逐act竞态边界有本地回归；下述目标版本3是明确实际入口模式，不能用它声称“正在执行中修订并保留原liveview”边界也已得到实页验收。
|
||
|
||
输出契约继续使用标准端点的强制命名函数及完整本地校验。对已声明的非空action数组，移除framework的非标准min_items并导出JSON Schema minItems；对已是闭合单动作分支的项加minProperties/maxProperties=1，保留原union和每个参数Schema，不靠补动作、改参数或修坏JSON凑通过。模型、Key、端点、图像输入和实际usage记录不变，安全字段/类型提示仍随正常下一步，没有独立付费修复轮。
|
||
|
||
最终全后端 **1251项通过**，TypeScript、桌面构建及原生弹窗Node检查11项通过。普通目标锁、丢失/错误绑定、UI/其它任务拒绝、上下文与每动作之间竞态、初始blank及显式实际入口、旧job取消期间view保护和标准Schema约束分别回归。本机检查与真实页面证据分开，不为文档修改再造额外测试或模型请求。
|
||
|
||
### 目标版本3：正确业务页与新样本实测
|
||
|
||
重启加载最终保护后，使用CUA在同任务提交实际已经观察过的笔记入口，明确只读、只当前新笔记第一组，正文最多1条、评论与回复合计最多4条；允许新blank打开这一真实入口，不搜索、不换篇、不分析名单、不互动；只有实际目标入口和唯一依据时才调用一次回复对象核对。目标版本3新增13次模型调用（意图1、网页12）全部成功，Schema 0，分析0。所有实际来源均属于该新笔记，没有把应用页或D42旧笔记当成此轮取证。
|
||
|
||
真实保存正文1、根评论1、回复2，共4条来源，讨论取证3条，没有把最多4条当最低4条，也没有采集其它讨论组。首条回复的parent/root均正确关联已保存根评论，保存事件success；展开后新增子回复能关联根讨论，但实际目标头部只有文字元素，没有唯一目标主页身份（target_header=1、target_elements=1、target_profile_links=0、target_identities=0），parent_resolution=target_identity_missing，直接父仍空，对应保存事件unknown。
|
||
|
||
专用展开工具实际调用一次，程序确认同owner新增2条可见回复、数量增量2，前后完整集合及parent_scope_checked均成立，新增容器规范指纹2条；当前目标版本的展开条件1/1，合法摘录绑定亦有真实证据。真实子回复对象核对调用一次，原生点击后未确认导航到完整主页，记录not_moved；没有完整主页→返回原笔记→同来源重新核对的通过证据。不按昵称、顺序或根作者主页补写直接父，也不把不同笔记的新样本自动当作具备唯一二级身份的合格样本。
|
||
|
||
本段结束为completed/stage_results，实际交付partial：评论及回复读取满足、展开1/1，关系1/2、回复→父回复0/1。没有名单分析调用、decisions0、leads0、analysis_batches0，符合本次仅页面专项的范围。CUA核对实际UI为“阶段资料已交付 共4条来源”“部分交付”“尚无候选名单”、25次已记录调用及只读回放，截图 `data/ui-verification/d43-final-desktop-state.png`。期间原生捕捉有CUA3811/3812错误，不把捕捉工具错误算作程序或小红书故障。
|
||
|
||
### D43实际用量、沉淀和资料保护
|
||
|
||
目标版本1、2、3均为同一 `task_97f09ffb24c4` 的递增修订，不是三个新任务。初始候选浏览最多2篇，后两版明确只当前新笔记第一组；本轮实际仅这一新笔记形成一个独立对象样本，不按分段次数、目标版本或四条来源增加独立任务数。
|
||
|
||
本段13次调用已返回usage264185 tokens，输入258435、输出5750、缓存命中194560、未命中63875。D43整个任务累计25次调用（意图3、网页22、分析0）：24次成功、1次结构拒绝，usage429641 tokens，输入420292、输出9349、缓存命中338816、未命中81476，25次均有返回usage。不能只报告最后13次零结构错误而掩盖此前误目标段的1次拒绝；这仍是供应商实际usage记录，不推算费用账单。全程关注、点赞、收藏、发评论及私信0。
|
||
|
||
新任务累计形成12条验证事件：unused6、success5、unknown1；其中unused不算技术成功，二级子回复未知不计成功。当前版本引用7个事件，不能把当前引用数量误当累计事件数。正文保存方法达到3个独立成功任务、3个不同对象，按现有规则进入preferred；评论、直接回复保存和展开方法各2个独立任务/2个对象，仍为trial，不能拿多次同篇恢复凑优先覆盖。两条阶段pipeline因dependency_versions_unconfirmed继续paused，既有成功不能替代未验证的完整二级链。
|
||
|
||
最终原10条任务逐行及整表摘要与D43开始基线完全一致；methods7行摘要及空业务反馈表不变，原48条验证事件内容也一致。当前tasks11、learned_entries4、methods7、validation_events60、business_feedback0：只正常新增本任务及其12条事件。legacy learned_entries条数仍4但摘要变化，任务正常复盘报告merged3，不宣称既有草稿全文未改变；没有人工改库或回填缺失关系。方法状态和独立计数来自新验证事件投影，不等于方法行被手工升级。
|
||
|
||
日志 `/tmp/juzi-d43-runtime.log` 与API均核对最终后端PID40834、live session0；模型仍deepseek-flash、Key已配置、未启用兜底。主启动会话1649；没有为收尾追加付费续跑，没有提交或推送。安全审计包括 `d43-goal3-real-audit.json` 与 `d43-final-verification.json`，均在忽略的 `data/ui-verification/`，只含程序计数、关系状态及摘要，不写客户原话、身份、二维码或完整签名链接。
|
||
|
||
### 本轮收尾与待验边界
|
||
|
||
本轮已实测正确受管业务页、正常网页回查不追加名单分析、首组取证、普通根→回复、同组专用展开及合法摘录绑定。明确二级回复仍缺唯一目标身份，直接父和主页返回重核未通过；新样本只是不同笔记，不等于该分支已经具备足够页面依据。完成卡保留部分交付，不能声称整条回复归属链路已修通。保留liveview修订等窄边界只报告本地回归，不把它们混成实页成功。后续只对预检已具真实唯一评论引用或实际可确认目标入口的样本验收二级分支，不在同类缺证据页面反复付费凑结果；未知关系继续如实保留。
|
||
|
||
|
||
---
|
||
|
||
## 2026-10-29 D44：只读选样预检与范围、交付及遥测修正（阶段记录）
|
||
|
||
### 目标与初始基线
|
||
|
||
本轮先在不同样本中寻找真实且唯一的二级直接父依据，合格后才另行进入取证，并区分知识召回、实际执行与成功验收。纯预检不保存正文或讨论来源、不保存学习、不展开折叠回复、不点击回复对象、不调用目标身份工具、不分析名单、不触达。最多篇数和每次可见回复数均来自本轮明确指令，不新增默认业务配额。
|
||
|
||
`data/ui-verification/d44-baseline.json` 保存原11条任务逐行及整表摘要，以及learned_entries4、methods7、validation_events60、business_feedback0逐行摘要；当时无running或live会话，后端PID40834、deepseek-flash、主Key已配置、兜底未配置/未启用。历史已记录237次调用、235次响应，218成功、17结构拒绝、2连接错误，其中2次未返回usage，不当作零消耗或完整账单。
|
||
|
||
新增 `inspect_reply_relations` 为只读当前视口的选样检查，先核对同笔记、实际组、根/父/子来源key与容器，再重读稳定性；只有直接父确为另一条回复且具有稳定DOM唯一依据，分类才为unique_dom_deep_reply、eligible=true。needs_native_identity、ambiguous及unknown均不合格，不按昵称、排列或根归属猜二级父。eligible只表示可以继续取证，不证明保存、展开、返回或业务目标已完成。
|
||
|
||
### 首个真实预检：两篇新样本，误入排除旧页且缺少程序计数
|
||
|
||
`task_a9989f752b6d` 经CUA新建，搜索杭州装修，最多两篇不同的新笔记，排除D42/D43已测两篇；每篇只第一组当前可见讨论，每次最多5条回复，只预检不取证。真实动作含两次inspect_reply_relations；浏览器访问记录却显示两篇新笔记之间还打开了一篇明确排除的D42旧笔记，随后立即返回。因此严格排除及最多两篇的执行不能判通过，不把退回抹成从未访问，也不靠后续工程修正改写该任务历史。
|
||
|
||
当时工具返回只在运行内，compact_history只保存动作名，evidence没有独立预检计数。两篇no_visible_reply、checked_count=0、eligible_count=0仅见模型后续回执，不能作为已保存的程序结果；同样不能据此断言页面完全没有二级回复。未授权的折叠区域没有展开。
|
||
|
||
13次实际调用（意图1、网页12）全部成功，Schema 0、analysis 0，usage233047 tokens（输入228619、输出4428、缓存命中177792、未命中50827）。另有一次源码常量可核对的动作保护拒绝：“页面焦点或地址已变化，本步旧动作未执行；请重新观察受管页面后定位。”这是旧动作没有执行，不是模型结构错误、登录或平台限制。任务为blocked/stage_results，浏览器报告is_successful=true；普通“无来源→blocked”映射不能准确表达纯预检结束。
|
||
|
||
来源、来源观察、操作事实、展开、学习候选和触达均0。实际召回6项方法（正文preferred，其余所选为trial），最终全部unused，程序成功0；注入不等于采用或加分。只读审计 `data/ui-verification/d44-first-preflight-audit.json` 固定calls[0:13]，保留越界、缺遥测及13次真实用量。
|
||
|
||
### 工程修正与本机检查
|
||
|
||
增加独立 `preflight_observations`：只保留状态、当前run/目标版本、笔记身份、checked/eligible与四类分类计数、讨论是否到视口及仍有折叠的布尔；不保存昵称原话、签名地址、候选DOM或跨任务知识，不生成来源或operation成功。首次未到视口不能叫已预检；后续同笔记最新可确认记录覆盖的是本段可见预检展示，不把同页多次检查相加成多篇。
|
||
|
||
增加明确只读预检策略与实际访问gate，读取当前真实入口及stable DOM节点的实际祖先链接核对目标，先拒绝排除笔记、超篇数、用户主页及无法核对的入口；实际页面超范围时停止而不是猜URL恢复。访问事件及当前run标记独立保存；历史未记录、缺标记或旧版范围不完整继续保留未知，不回填成功。纯预检路径应清空保存型方法注入，跳过名单分析及知识复盘成功记账。
|
||
|
||
增加预检专属完成投影与展示：只有实际讨论进入视口且当前运行访问范围完整，零eligible也能交付“预检完成，可见范围未发现合格样本”；仍有未展开部分明确未知。缺可确认记录、未到视口、访问缺项、越界及真实失败不显示完整完成，也不生成名单或业务客户数。已运行的旧任务不因新展示而获得原来缺失的程序事实。
|
||
|
||
本阶段后端 **1400项通过**，TypeScript、桌面构建及预检卡片SSR检查4项通过。此前首工具与路由阶段为1273项后端及37项定向检查。这些是各阶段的本机结果；后述真实措辞仍有漏识别，不能仅凭测试数宣称修复完成。解析回归正在补充，最终测试数及第三次独立实测结果待后续记录。
|
||
|
||
### 第二个独立真实预检：已有程序遥测，但自然措辞未激活策略
|
||
|
||
`task_5d916c913284` 经CUA新建，只访问此前实际观察过的一篇入口，不搜索、不换篇、排除两篇旧笔记；只首组当前可见讨论，每次最多5条回复，不保存、展开、分析或互动。实际访问记录仅该指定新笔记，没有打开排除旧页。动作是navigate、advance_comments、inspect_reply_relations、scroll、inspect_reply_relations、done。
|
||
|
||
本次独立程序遥测已保存两条同run/目标版本1记录：先为comments_not_in_view、no_visible_reply、checked0/eligible0；滚动后为visible_comments、checked1/eligible0，classification_counts.unknown=1，当前可见评论数2、仍有折叠回复。后一条有程序依据，不能仍说全部无遥测；但仅一条未知，不是取得合格二级链，也不证明折叠部分已读。
|
||
|
||
对真实输入离线重编译确认 `compile_preflight_policy.active=false`，排除列表及篇数也未生效。原话“独立做一轮只读预检”未匹配 `_ONLY`，而不保存前缀已正确匹配；所以没有preflight_run，preflight_navigation为空，范围gate、预检专属交付及知识过滤没有启用，仍落到普通无来源blocked/stage_results。没有已确认程序异常、模型结构或平台故障；浏览器主动done且报告成功不能代替策略落地。
|
||
|
||
该任务6次调用（意图1、网页5）全部成功，Schema 0、analysis 0，usage100997 tokens（输入98532、输出2465、缓存命中70784、未命中27748）。来源、来源观察、operation、学习、展开、名单及触达均0；仍召回6项保存型方法并各记unused，成功0。审计 `data/ui-verification/d44-second-preflight-audit.json` 固定calls[0:6]，保留本次解析缺口及实际可见1/0，不将它判作完整修复验收。
|
||
|
||
### 资料保护与下一步边界
|
||
|
||
截至前两任务，原11任务逐行摘要全部一致，既有learned4、methods7、原60条验证事件及空业务反馈表也逐行一致。当前tasks13、learned4、methods7、validation_events72、feedback0；只正常新增两个真实任务和12条unused事件，没有技术成功或独立对象成功加分。预检安全遥测的正常追加不是来源或知识成功。首任务仍blocked、13次用量文件摘要与首次审计一致、遥测0，没有把旧越界和缺证据补成成功。
|
||
|
||
下一步先用本次真实自然原话补解析回归，不依赖把用户措辞改成固定口令；在提交第三个独立任务前，离线确认active=true、最多1篇、排除2篇。第三次仍使用真实已观察入口，只读且不保存，不更改前两任务或借续跑修饰旧结果。先验收程序访问记录、当前run遥测、预检专属完成与保存方法不注入；只有真实eligible样本才另行验证根/父/子保存和二级归属，届时再以程序事实核对知识执行及独立对象计分。当前不宣称最终修复或二级完整链通过，没有提交或推送。
|
||
|
||
|
||
---
|
||
|
||
## 2026-10-30 P0：纠偏冻结与默认止损
|
||
|
||
### 1. 问题出在哪
|
||
|
||
按用户《橘子拓客 纠偏方案 v1》只执行P0。D40–D44专项把回复直接父核对与预检混进默认拓客工具、路由和交付：默认注册两个实验工具，`compile_preflight_policy`可依据自然语言正则将意图改为inspect；回复原话已逐字核对并落盘，仍会因父关系未知记保存unknown，并引导补父容器、重存回复。主链路正常10位规模及单候选成本尚无基线，P0不能声称降本或候选产出改善。
|
||
|
||
开始时核对分支 `wip/d20-d44`、HEAD `5be86a4`，保留快照后原有4个未提交文件：prompts、request_routing及其两份测试。先跑完整后端，1452项通过后才开始修改。停止旧D44桌面复测和任何新回复关系/预检功能；未commit/push。
|
||
|
||
### 2. 怎么修复、结果如何
|
||
|
||
- `backend/config.py`新增同一开关 `reply_relation_preflight_enabled=False`（`REPLY_RELATION_PREFLIGHT_ENABLED`），默认不注册 `inspect_reply_relations`、`resolve_reply_target`，显式开启保持原实现；不删除工具代码。
|
||
- `backend/prospecting/orchestrator.py`、`request_routing.py`、`prompts.py`、`dialogue.py`、`delivery.py`统一门控：默认不调用预检编译、不因其正则改意图或篇数，不注入关闭工具指引，不走预检交付投影。普通网页回查保持原路径，P4正则替换不在本阶段展开。
|
||
- `backend/browser/runner.py`同开关忽略显式或旧会话预检策略；续跑清除旧Agent注册表中的关闭工具并用框架原方法刷新Schema，保留已有浏览器。没有改动端口、视图绑定或2px park。
|
||
- `backend/browser/tools.py`的 `_save_source` 保存成功仅代表容器原话校验与持久化；父/根引用、`parent_resolution`、诊断及 `relations_checked`继续单独记录。public next_action不再要求补父/重存。逐字核验、去重、原evidence恢复及关系交付校验保留；不补旧记录、不把保存成功称作父关系成功。
|
||
- 预检专用测试用模块内fixture显式打开开关，新增默认关闭路由/提示/投影、工具动作Schema、旧会话续跑及未知父关系正常保存等回归。没有全局开启开关来迁就旧测试。
|
||
|
||
| 核对项 | 程序结果 | 验证边界 |
|
||
|---|---|---|
|
||
| 修改前完整后端 | 1452 passed，15.49秒 | 本机，含现有数据库集成测试 |
|
||
| 最终完整后端 | 1468 passed，14.87秒 | `npm test -- -o addopts='' -q`；无跳过或失败 |
|
||
| 已有真实发现任务的当前模型契约 | 25个动作；两个实验工具均不存在 | 只读重建，task_94db43a81241；不是付费请求回执 |
|
||
| 本轮真实模型调用 / 平台动作 / 新业务任务 | 0 / 0 / 0 | 未继续D44、未开始P1或触达 |
|
||
| Git分支 / HEAD | wip/d20-d44 / 5be86a4 | 无新提交或推送，原dirty修改保留 |
|
||
|
||
Schema审计使用已存在的真实discover任务、当前内嵌工具排除表、browser-use 0.13.10动态动作模型及 `request_contract` 最终函数Schema，安全报告在 `data/ui-verification/p0-default-tool-schema.json`（已忽略）。不打印用户原话、昵称、链接、Key或.env，不修改被审计任务；报告记录动作名、SHA256、开关、零模型调用及零平台动作。
|
||
|
||
**严格真实请求侧工具列表验收尚未取得**：上述证据只证明当前代码将发送的契约，不能证明历史请求或尚未重启的桌面进程已更新。本轮没有为取得该回执另开付费任务或进入P1；需向监督明确汇报此边界。保存方法的旧v1文案仍有层级措辞，方法定义不可变，本轮不以改同版本模板导致注册冲突；保存success不得推导父关系或完整链路成功，P3按新流程版本处理语义。
|
||
|
||
### 3. 接下来怎么走
|
||
|
||
停在P0等待监督确认，不进入P1，不继续D44。后续在获准的P1前重载本项目后端配置，先向用户确认本次商品与目标客户，之后运行已授权的只读discover，目标10位去重候选、不加篇数上限，按现有达标停止规则执行。首轮实际请求同时核对默认模型工具列表，不能用本次离线审计替代真实上游回执。当前不替用户选择商品、行业或关键词。
|
||
|
||
P1按usage、browser-budget、steps产出任务内baseline.json及完整指标表，身份稳定/未知分列，按intent/browser/compression/analysis列调用与token，记录笔记、评论、回复、工具分布、墙钟、停止原因和单候选成本。未达标如实报告缺口与原因，不调参凑数；P2/P3以后才依据同等规模数据评价降本和可执行流程复用。登录、验证码、平台限制、余额或鉴权异常立即暂停；任何真实触达或提交代码仍须明确授权。
|
||
|
||
### 4. 可复用的方法
|
||
|
||
工程规则：用一个默认关闭的开关同步门控工具Schema、路由、提示、执行和交付；关闭还要覆盖旧Agent续跑。来源保存与关系解析分别记录事实及验收，未知关系不抵消已保存原话。用程序Schema审计验证工具边界，明确区分离线契约、真实请求及真实平台。没有新增业务流程复用或降本成功证据。
|
||
|
||
|
||
---
|
||
|
||
## 2026-10-30 P1：装修服务真实只读主链路基线（2/10位，未达标）
|
||
|
||
### 1. 问题出在哪
|
||
|
||
用户确认进入下一阶段，并明确“装修服务，目标客户是近期要装修的用户”，未限定地区。通过真实桌面UI创建 `task_76d551192d7e`，目标10位、discover、max_notes和max_comments_per_note均null、无地区筛选、公开资料补充关闭。当前模型deepseek-flash，主Key已配置、无兜底；本轮没有登录、验证码、平台、余额或鉴权暂停。
|
||
|
||
本轮实际只交付2位，缺8位，任务blocked/stage_results，浏览器verdict=failed，程序stop_reason=evidence_stalled：同一笔记多次取证失败且没有新增来源，其他路线未视为完成。按原规则停止后没有续跑、改参数或更换目标凑数，未进入P2。
|
||
|
||
已确认的问题及依据：
|
||
|
||
- 人数提取重复追问：输入已有“10位去重候选”，程序仍将target_candidates留空。按用户既定10位在补充卡填写10后继续，无第二次意图模型调用；没有修改识别逻辑。补问及等待计入总墙钟时间。
|
||
- runtime第256/447/474行共3次save_source提示实际原话未在当前可见来源容器找到，逐字校验拒绝不匹配保存；12次实际保存调用只形成9条成功保存事实。
|
||
- runtime第746/760/772行对应Step42–44，连续3次inspect_source_candidates返回可见正文/评论/回复容器无法核对，末尾实际动作台账也为这3次检查，触发evidence_stalled。不能从模型thinking断言底层是渲染、选择器还是页面结构；具体observer错误分支未独立持久化，仍待查。
|
||
- advance_comments实际4次，有3条持久化推进尝试均not_moved；其余一次不能据缺attempt记录断言失败。8条去重观察出现回复入口，但in_view均为false，涉及上方/下方/遮挡；展开0、保存回复0，未展开范围没有读完。
|
||
- 44次浏览模型调用只有50次实际工具调用，平均约1.14个动作/调用；inspect18加save12占工具调用60%。浏览阶段占总tokens约97.8%，支持P2优先批处理确定性动作，但不构成已降本结论。
|
||
|
||
分析在停止后执行一次，原因是现有增量批次阈值 `min(12, max(1, remaining))`：本次remaining=10，实际保存9条未满阈值，所以运行中decisions=0属正常批次等待，不是分析模块没接上。最终9条决策为keep2/exclude6/unclear1，不能把尚未分析时的0候选解释为无需求。
|
||
|
||
### 2. 怎么修复、结果如何
|
||
|
||
本轮不修采集或路由行为，只补基线测量所缺的观测，再运行一次真实任务：
|
||
|
||
- `backend/browser/diagnostics.py`、`llm_factory.py`：实际发送前记录最终动作Schema的函数名、动作名、SHA256、call_id/phase/时间到任务内model-request-contracts.jsonl；不保存完整Schema、参数、提示词、客户身份、URL或Key。prepared需关联同call_id的供应商response才算有真实回执。
|
||
- `backend/browser/runner.py`：在原工具执行边界记录browser-actions.jsonl，区分invoked/blocked/returned/error；只记录名字与程序ID，不改工具参数、模型选项、推进逻辑、校验或停止规则。returned不等于业务成功。
|
||
- 新增 `scripts/measure-prospecting-baseline.py` 与测试，读取DB及usage/browser-budget/progress/evidence/actions/contracts，写任务目录baseline.json。未知usage保持缺项，0候选分母null，拟议动作与实际调用分开统计，不取模型总结当数据。
|
||
- 新增/更新 `tests/test_request_contract_audit_p1.py`、`test_baseline_measurement_p1.py`及动作边界回归；完整后端 **1480 passed，17.34秒**。没有UI源码修改；桌面以当前代码重新启动，后端PID88132、运行日志 `/tmp/juzi-p1-runtime.log`，当前live_sessions为空。
|
||
|
||
真实平台及程序台账指标：
|
||
|
||
| 项目 | 实测值 | 口径 |
|
||
|---|---:|---|
|
||
| 目标 / 稳定身份交付候选 / 身份未知候选 | 10 / 2 / 0 | 身份未知0只针对候选组；稳定来源身份不等于已核对小红书号 |
|
||
| 缺口 | 8位 | 未达标，不外推10位完整成本 |
|
||
| 实际访问 / DOM检查及核验摘录笔记 | 4 / 3篇 | 第4篇只访问，不能算已读；不称3篇全部讨论读完 |
|
||
| 保存正文 / 评论 / 回复 | 3 / 6 / 0 | 共9条独立来源与保存事实 |
|
||
| 分析保留 / 排除 / 不清楚 | 2 / 6 / 1 | 共9条决策，analysis_batches=1 |
|
||
| 主页号核对 / 展开 / 触达 | 0 / 0 / 0 | 未执行关注、点赞、收藏、发评论或私信 |
|
||
| 浏览器总步骤 | 44 | browser-budget累计attempt，44条步骤回调/44张截图 |
|
||
| 实际工具调用 | 50 | 按action_id的invoked统计，全部有returned，无boundary blocked/exception；不等于50次业务成功 |
|
||
| 总LLM调用 / 总token | 47 / 1140485 | 全部有供应商usage及succeeded，结构失败/未知usage/待完成均0 |
|
||
| 总输入 / 输出token | 1123701 / 16784 | 输入中缓存命中858496、未命中265205；未换算供应商费用账单 |
|
||
| 墙钟时间 | 197.77秒 | task_start10:47:06.825至末次analysis finished10:50:24.595，包含人数补问及等待 |
|
||
| 单候选调用 / token / 时间 | 23.5 / 570242.5 / 98.885秒 | 分母为本次实际交付2位，不是目标10位 |
|
||
| 停止原因 | evidence_stalled | 程序记录，不采用模型总结；不是预算耗尽 |
|
||
|
||
分阶段供应商用量：
|
||
|
||
| 阶段 | 调用数 | 输入token | 输出token | 合计token |
|
||
|---|---:|---:|---:|---:|
|
||
| intent | 1 | 1843 | 326 | 2169 |
|
||
| browser | 44 | 1100091 | 14914 | 1115005 |
|
||
| compression | 1 | 15388 | 755 | 16143 |
|
||
| analysis | 1 | 6379 | 789 | 7168 |
|
||
| 合计 | 47 | 1123701 | 16784 | 1140485 |
|
||
|
||
本轮review没有额外模型调用；分析增量调用0，没有将不存在的调用填入费用。所有已发生调用均含完整usage，无需将未知用量当0。
|
||
|
||
实际工具调用分布：
|
||
|
||
| 工具 | invoked次数 |
|
||
|---|---:|
|
||
| inspect_source_candidates | 18 |
|
||
| save_source | 12 |
|
||
| click | 6 |
|
||
| advance_comments | 4 |
|
||
| scroll | 4 |
|
||
| go_back | 2 |
|
||
| navigate | 1 |
|
||
| input | 1 |
|
||
| send_keys | 1 |
|
||
| wait | 1 |
|
||
| 合计 | 50 |
|
||
|
||
steps回调记录52个拟议动作，compact_history含初始navigate共53个；其中3个拟议save未进入实际调用边界，不计实际调用，也不能记成boundary blocked。source_observations按连续同内容去重，11条观察不等于18次inspect里有7次失败。动作事实trace.action_id与边界日志action_id为不同命名域，未用它们直接join造失配结论。
|
||
|
||
**P0真实回执补齐**：44条唯一request_prepared，全部关联同call_id供应商response及finished=succeeded；实际同一Schema、24个动作，inspect_reply_relations/resolve_reply_target均出现0次。相对P0离线25个动作少了screenshot，由本轮实际框架动作Schema决定，不能用离线列表冒充真实出站。未启用实验开关、未重跑D44。
|
||
|
||
最终基线：`data/tasks/task_76d551192d7e/baseline.json`；原始依据包括model-usage.jsonl、browser-budget.json、progress.md、evidence.json、browser-actions.jsonl和model-request-contracts.jsonl，baseline内留SHA256。基线脚本只读DB，不回填任务证据。真实UI已核对为“阶段成果已交付 共2位 / 目标10位”、部分交付、剩余8位，以及取证停滞停止说明。未调整或重跑旧任务，未提交或推送。
|
||
|
||
### 3. 接下来怎么走
|
||
|
||
P1测量完成，业务未达标；停在本阶段等待监督确认。建议下一步P2围绕本次实测的取证停滞、评论区未推进及检查/保存调用密度，程序化当前笔记的推进、批读取、逐字保存、真实展开与无新增退出；模型只决定哪篇、是否继续及需求判断。必要的失败分类应对应本次已发生的具体拒绝，不追加关系证明或预检约束。
|
||
|
||
P2保持同一商品、客户标准和10位目标，验收同等候选交付下的单候选调用/token是否降低至少50%；本轮未完成10位基线，必须保留对比缺口，不直接用2位均值外推10位，不改变目标人数制造达标。底层失败原因不足时先如实定位，不承诺宏工具本身一定解决全部DOM问题。任何阶段遇登录、验证码、平台限制或供应商鉴权/余额问题立即暂停。P2尚未实现，也未获得本轮自动进入P2的授权。
|
||
|
||
### 4. 可复用的方法
|
||
|
||
任务内使用真实出站契约关联usage响应，验证开关落实到实际模型请求；工具执行边界计数避免把模型提议或普通返回当成功。基线指标由不可变台账重算，保存成功、候选身份、需求判断及任务达标分别报告。业务流程复用及实际降本结论：无，待P2/P3验证。
|