 ThearchyHelios
|
87f0d62f9b
|
多进程协调（W2-b）第一步：新增 app/cluster——工作进程在库里登记、心跳续租约（属主随进程，进程没了它认领的行一起到期），调度当班的租约，发给属主进程的停止 / 记事件请求，PostgreSQL 的 LISTEN/NOTIFY 叫醒，跨进程的互斥锁（咨询锁），SQLite 单进程守卫（第二个进程拒绝启动）；运行、问数据一轮、起草 / 剖析 / 探查 / 评测 / 影子起草、文档、发布单记 owner，启动整理改成只接手属主不在了的行，当班进程隔一会儿再接手一次；运行的并发名额改成库里按交互 / 应用 / 定时 / 系统四类发（各有全站上限和优先级，设置里可调），替掉进程内的信号量；同源队记在库里；运行停止、记事件跨进程交给属主；运行事件、问数据事件跨进程转发（库里按 seq 追，不落库的流式增量和保活心跳只转给在看的进程）；每日花费账先占住那一行再读写；访问密钥限流、登录失败计数在 PostgreSQL 时记在库里；登录设置、对外地址、向量模型、能力快照、数据源连接池、应用页面缓存跨进程失效；上传版本库、记录表、按需探查、出具、召回、补算、按需视图、个人刷新、定时发起的锁换成跨进程的锁
|
2026-10-19 11:40:33 +08:00 |
|
|
ThearchyHelios
|
2e7d6103ea
|
应用库可移植到 PostgreSQL：AGENTLAB_DATABASE_URL 设成 postgresql+asyncpg://… 时整个应用库用 PostgreSQL，断点用官方的 langgraph-checkpoint-postgres（同一个库，AGENTLAB_CHECKPOINT_URL 可另给）；不设时照旧是数据目录里的 SQLite，行为不变
- 配置：database_url、checkpoint_url（启动时校验写法，只认 PostgreSQL）、连接池四项；启动日志写用的是哪种库（主机、库名、用户，不写密码）
- 引擎（db/base.make_engine）：SQLite 照旧 WAL、外键、忙等；PostgreSQL 用连接池、探活、会话时区 UTC，装上方言调整（db/postgres.py）：建表时 String(n) 是不限长的 VARCHAR（SQLite 从不查长度，导过来的存量也可能超长）、ORDER BY 里可空列的 NULL 位置照 SQLite 补写（升序在前、降序在后，窗口函数里同样）；Integer 列在 PostgreSQL 上是 BIGINT（列挂到表上时换成 with_variant，绑定参数跟着列按 BIGINT 转换）；JSON 列两边都存原文（PostgreSQL 的 json，不用 JSONB：JSONB 重排对象里的键，快照的列序、表的先后读回来就变了）；JSON 里的 NaN 写成 null、NUL 去掉（PostgreSQL 不收）
- 迁移按方言：已有的列和索引用 inspector 认；PostgreSQL 上补列的类型取模型里这一列的、缺省值取迁移表里的（布尔 0/1 换成 false/true），ADD COLUMN IF NOT EXISTS；去重语句里的布尔按方言写；部分唯一索引补 postgresql_where；init_db 在 PostgreSQL 上拿咨询锁（几个进程同时启动不撞）
- 应用库上的 SQLite 专用写法改成按方言编译的表达式（db/portable.py）：json_extract 的十几处（口径召回、出具、对账、个人应用、幂等键、访问控制、数据源变化通知、剖析任务、待办超时）换成 json_eq / json_flag / json_text，json_type 换成 json_is_string（两种库同一套带类型的比较）；能力登记的 sqlite insert 换成按会话方言的 insert_ignore；能力使用次数的 json_each 按方言分支；附件「没绑记录」的条件不靠 json 的等号；按报错文字认唯一约束的地方换成 unique_violation（按表和列认，两种库的报错都认得）
- 断点（engine/checkpoints.py）：PostgreSQL 时开 psycopg 连接池、在咨询锁里 setup；runner 只认 BaseCheckpointSaver，读断点仍只走 saver 的公开接口
- 依赖：新 extra postgres（asyncpg、psycopg[binary] 3、psycopg-pool、langgraph-checkpoint-postgres 3.1.2）；langgraph-checkpoint 卡在 <4.3（断点格式就在这个包里，postgres 包新版要 4.3，不动已装的 4.2.0）；锁文件补上新包
- 运行收尾：记 action.unknown、安排核实做完才把运行摘掉（以前先摘掉，等「不在跑了」再读事件的一方在库慢时读不到这一条）
- 测试：AGENTLAB_TEST_DATABASE_URL 时跑在 PostgreSQL 上（每个 xdist 进程建自己的库、按事件循环分的连接池 tests/pgpool.py），不设时盖掉环境里的数据库地址照旧用 SQLite；scripts/test-postgres.sh 起临时的 postgres:16 容器跑全量；sqlite_only 标记；另开连接改库的几个竞态测试、触发器测试改成两种库都能跑（tests/appdb.py）；新增 test_db_portable 守着方言调整、JSON 键序、超长字符串、大整数、NULL 排序、时区、PostgreSQL 老库迁移
|
2026-10-19 09:52:09 +08:00 |
|
|
ThearchyHelios
|
fc57ed0e32
|
追加事件收紧几处，封存后追加的质询不计进运行用量。复核提出：停在审批时追加只看运行还停着，关于第一张审批卡的质询问完时运行可能已经批过它、停到了第二张上，问答照样写进去；没有终态事件的老封存运行追加之后 verify 由一致变成不一致；返回给调用方的事件 id 和库里的不一样；测试证明不了先落库再广播；封存后追加的质询平时不计用量，继续运行之后又被计进去。
- append_events 加 approval_id（只用于 interrupted）：问的是哪张审批卡，那张卡仍待审批才写。核对放在和其余条件同一次条件更新里（EXISTS 待审批的那条），批过了、不是这次运行的卡都不写、返回 None。条件更新写明不同步会话里的运行：条件里带了 EXISTS 时 SQLAlchemy 会悄悄换一种同步办法、给语句加上 RETURNING
- manifest_seq 为空的老封存运行，封到哪一条是 verify_manifest 按事件类型推出来的：有终态事件的封到最后一条终态事件，追加在后面不碍事，照旧追加；没有终态事件的封到最后一行，追加一条范围就挪到它身上，我们自己写的批注被当成篡改，现在不追加
- _stage 落库时用事件自己的 id：广播出去的、交回给调用方的和库里的是同一个 id
- 运行用量不计数据带 post_seal 的质询：运行用量是这次运行自己花的，结束时就定下了、写进了终态事件；封存后的批注另有自己的账，同按需裁判的判定。继续运行之后它落进新的封存范围，照样不计
测试：两道审批的运行批过第一道、停在第二道，钉住第一道的质询不写、钉住第二道的写，读完运行之后那张卡被批了也不写，返回的 id 和序号与落库的一致；广播时查库，每条都已落库，落空的一条都不广播（把广播挪到条件更新之前这条就变红，以前的测试照样通过）；老封存三种（无终态、run.finished、run.failed）追加前后 verify 都一致，无终态的不写；失败封存的运行追加 post_seal 质询后继续运行，运行用量里没有它。去掉审批卡的核对、改回老封存一律追加、改回计 post_seal、去掉落库 id，对应的测试各自变红
|
2026-10-05 01:18:03 +08:00 |
|
|
ThearchyHelios
|
f8b2857630
|
进程重启后接号不再撞上已有的序号：以前恢复、继续运行、放弃、启动时补日志都只按 run.last_seq 接号，而 last_seq 会被写小。按需裁判记判定（api/evidence.py 的 _append_judged）的条件更新不带 last_seq 条件：它取了号还没写，封存后追加（run_append）抢先提交了，它再提交时把 last_seq 写回自己那个更小的号。同一进程里序号计数只增不减，不碍事；重启后计数从 0 起，继续运行写出的 run.resumed 就和封存后追加的事件同号，重新封存时两条同号的事件一起进了清单，而清单按序号排序算哈希。
- runner 加 _seq_floor：接号起点取 last_seq 和库里实际最大序号中大的那个。恢复、继续运行、放弃都改用它，run_append 原来手写的同一段兜底也换成它
- 启动时（setup）先把落后的 last_seq 按库里实际的最后一条改正，再处理上次留下的运行中记录。_append_judged 规格不许改，它重启后也只按 last_seq 接号，不改正的话它第一次追加就撞号；有 (run_id, seq) 索引，五千次运行、一百五十万条事件实测约 7 毫秒。updated_at 不动，这是补记录，不是运行有了变化
- _stage 不带运行对象时的更新只往大里改：另开会话记的事件和执行任务同时在写，号大的先提交、号小的后提交，以前会把 last_seq 写小
测试：last_seq 写小、清掉本进程计数之后继续运行、恢复、放弃都接在实际的最后一条后面，全流无重复序号、verify 通过；_stage 先提交大号再提交小号，last_seq 不变；按真实的交错（裁判停在条件更新之前，封存后追加先提交）把 last_seq 写小，重启（shutdown、清计数、setup）后 last_seq 改正、别的运行原样不动，再裁判、继续运行都不撞号。去掉启动时的改正，只有裁判那条变红；去掉 _seq_floor，继续运行、恢复、放弃三条变红；_stage 改回无条件写，对应那条变红
|
2026-10-05 01:17:18 +08:00 |
|
|
ThearchyHelios
|
3dbd69b561
|
往停下的运行里追加事件统一走 engine/run_append.py 的 append_events(run_id, items, *, require, seal=None)：审批质询要在运行停在审批时把问答写进运行、随运行结束一起封存，探索运行封存之后还要能追加批注。事件流是封存的依据，清单按 seq 排序、run_events 的 (run_id, seq) 又不唯一，撞号会让封存核对时对时不对，所以照 _append_judged 的做法：同一运行在进程内排队，读 last_seq 后从 bus 接号（另取库里实际的最大序号兜底，last_seq 被别处写小了也不撞号），写事件和条件更新 last_seq 在同一事务里——interrupted 要求运行仍停在审批，sealed 要求仍是终态且封存没变，任一条落空就回滚、返回 None，调用方据此说明未写入运行记录；提交之后才广播。sealed 的事件带 post_seal: true；运行记录上的封存若早于最后一条结束事件（继续运行后又结束、还没重新封存的那一下），不算现在的封存，不追加，免得事件被接下来的封存收进去；调用方可传 seal 固定开始时看到的封存。事件类型加 approval.inquiry。测试用人工审批停住的运行：追加两条后批准、封存，verify 通过且改动追加的事件 verify 就对不上；恢复、继续运行、重新封存、别处写入抢在中间时都不写、last_seq 不动；连续和并发追加序号严格递增、全流无重复；恢复后前面的节点不重复执行，Agent 里批过的工具不重复执行（含升级前写下的断点）
|
2026-10-05 00:14:40 +08:00 |
|