 ThearchyHelios
|
b2f6d8d7d2
|
README、部署说明补上用 PostgreSQL：AGENTLAB_DATABASE_URL、断点、连接池（含 PgBouncer）、和 SQLite 一致的那几条、从 SQLite 导入的步骤（copy-to-postgres，先停服务、先 --dry-run）、备份（pg_dump 加数据目录）、多台机器要把数据目录挂在共享存储的同一个路径上，以及实话：数据目录里的 SQLite 文件（记录表原地追加写、上传表格版本库的 flock）在网络文件系统上并发写不安全，眼下仍按单进程部署
- 依赖与锁文件：[postgres] 里装的是什么、为什么 langgraph-checkpoint 单独卡小版本、checkpoint-postgres 锁在 3.1.2；数据位置：PostgreSQL 时不再用 agentlab.db / checkpoints.db；开发与验证：scripts/test-postgres.sh
- environment.yml 带上 [postgres]；.env.example 补应用库一节
- deploy.sh：数据目录里没有 agentlab.db（库在 PostgreSQL）时，认 .secret_key、uploads/ 也算 AgentLab 的数据目录，不再拒绝改属主
- 断点库的连接串不带只给 asyncpg 看的参数（prepared_statement_cache_size 之类，psycopg 不认）；地址规范化、启动日志不带密码的测试
|
2026-10-19 10:13:58 +08:00 |
|
|
ThearchyHelios
|
95ff6470d1
|
后端依赖锁到测过的那一套：pyproject 卡版本范围，requirements.lock 写精确版本
langgraph 和四个 langchain 包原来完全不写版本，fastapi、sqlalchemy、aiosqlite 只有下限，
uv.lock 还在 .gitignore 里。按旧写法今天新装，22 个包和测过的版本不同，其中 sqlalchemy
会从 2.0.52 跳到 2.1.1。
1. pyproject.toml：LangGraph / LangChain 一族放行到下一个小版本——引擎依赖它们的断点
格式、interrupt / resume、流式事件和 thinking 块，这些在小版本里也改过行为。aiosqlite
与 SQLAlchemy 同样卡小版本：db/base.py 给 aiosqlite 0.22 的 stop() 打了补丁，连接池
强制断开时会走到它。mcp 卡在大版本 1。
2. backend/requirements.lock：后端全部依赖（含间接依赖、全部 extras）的精确版本，
--universal 跨平台。锁的是 473 条测试跑过的那个 conda 环境：本机要装的 96 个包逐一
对上，另外 3 个只在 Windows / emscripten 上装。
3. environment.yml 装包时以锁文件为约束（-c），换机器装到的是同一套。
4. scripts/lock-deps.sh 重新生成锁文件：已锁的版本默认不动，升级用 --upgrade-package /
--upgrade。README 补了用法，补装 extras 的命令都带上 -c。
验证：用同版本 Python 新建空环境，照 conda 的方式按 environment.yml 的 pip 行安装——
装到的 96 个包和测过的环境完全一致，473 passed。
|
2026-09-26 09:49:16 +08:00 |
|
|
ThearchyHelios
|
901d840b86
|
Word / PDF 真的传得进来了，表格切开也还读得懂
上一轮做了解析，但那条路在产品上够不着：
- environment.yml 装的是 [microvm,dev,db]，没有 docs——新机器起来，传 PDF
只会得到一句"要先装解析库"
- 文件选择框的 accept 里压根没有 .pdf / .docx，点上传根本选不中这些文件
两处都补上。表格类（xlsx）故意不放进 accept：它进知识库会被切成文本，
聚合算不了、数字也无法回指，那条路该走数据源。
装上依赖实测各格式：Word（含表格）、PDF（含中文，扫描件会明说要先 OCR）、
HTML、txt/md/csv/json 都通；Excel 和 PPT 不认得，报错说得清楚。
**切块对表格的处理是这次的主要工作。** 一份 60 行的 Word 表格切出来长这样：
块1 首行 | 上海 | 172151 | 13%
门店名被切没了，也没有表头——召回到这块，模型看到的是一列没有主语的数字。
两个毛病：
1. 重叠按字符切（buf[-120:]），会从行中间断开。改成只在行边界取，
整段没有换行就宁可不要重叠
2. 表格横跨多块时，除第一块外都没有列名。改成开新块时把表头补在最前面
第二条我第一版写成了 tail+header+block，表头被夹在重叠的那几行后面成了中间
一行——"表头在不在"查出来是 True，看着修好了，块的开头其实仍然是一串没有
主语的数。测试里专门有一条盯着表头必须领头，就是为这个。
端到端验过：60 行表格的 Word 传上去切成 3 段，搜"门店销售额"召回的片段
第一行就是"门店 | 城市 | 销售额 | 同比"。
|
2026-09-19 22:58:01 +08:00 |
|
|
ThearchyHelios
|
39e7a5b014
|
数据源接入：MySQL / Oracle / PostgreSQL / SQLite
阶段①。产品原先能取数的只有 http_request 和沙箱里自己写代码——面对"分析上季度
华东区销量下滑"这类需求，用户得自己知道数据在哪张表、字段叫什么，再手写 SQL 塞进
代码节点。最难的部分留给了用户。
## 连接层（app/data/）
方言差异全收敛在 engine.py 一处：Oracle 要 service_name/sid、MySQL 要 charset、
各家默认端口不同。三个驱动都是 asyncio 原生且免装客户端——oracledb 走 thin 模式，
不需要 Instant Client。密码复用 app/core/crypto 的 Fernet，和 Provider 同一套；
build_url 默认把密码替换成星号，日志和错误信息里用这个版本。
introspect.py 产出两种粒度：summary()（表名+代表字段，几百 token，给 Copilot 的
system prompt 用）和 describe_table()（单表完整字段，按需取）。分两种是因为一个
中等业务库全量塞进 prompt 轻松几万 token，既贵又会把真正的需求淹掉。
## 守卫（app/data/guard.py）
这是唯一不能出错的地方：SQL 由模型生成，模型会写出什么事前无法穷举，防线不能
建立在"它应该不会这么干"上。三层：
- 只读判定用**白名单**而非黑名单——黑名单永远漏，MERGE/CALL/GRANT/各家私货写不完
- 多语句在到达驱动前就断掉，不赌驱动默认只跑第一条（MySQL 开了
CLIENT_MULTI_STATEMENTS 就会全跑）
- 行数/字节/超时三重上限，一条 SELECT * 不该把内存和模型上下文一起打爆
刻意不引 sqlparse：完整解析 SQL 方言是无底洞，而这里的判断很窄——"首关键字是
什么"和"有没有第二条语句"。窄问题用窄解法。难点是不能误杀：`SELECT ';'` 只是
一条语句，简单 split(";") 会把它切两半然后拒掉，那比漏杀更让人无从下手。
## 工具（app/tools/datasource.py）
每个数据源动态生成一对 db_query__<源> / db_schema__<源>，而不是一个通用工具带
datasource 参数：工具名自带语义，模型不会把查销售库的 SQL 发给财务库；description
里直接塞表清单，省掉"先问有哪些表"那一轮。接进 registry.build_tools 作为第四来源
（前三个是内置/MCP/自定义）。
查询结果落 put_json(kind="query_snapshot")，把 SQL 原文 + 结果集 + 数据源一起存，
出具体系的数字回指能下钻到"这个数是哪条 SQL 查出来的"。
## 实测
真实 SQLite 业务库（600 行订单，埋了华东 6 月断崖的信号）+ 真实模型：
agent 8 轮自主查询——列表 → 查三张表结构 → 探数据时间范围 → 查地区维度 →
按月汇总 → 按地区+月份下钻，准确定位到华东 6 月从 1187 件跌到 354 件。
只读守卫在 agent 路径上同样生效（UPDATE/DROP/多语句全被拒且数据未变）。
测试 55 项：守卫 30 项（含"字符串里的分号不能误杀"）、连接与探查 15 项、
URL 构造 6 项、Copilot 流式 4 项。
|
2026-09-17 10:39:23 +08:00 |
|
|
ThearchyHelios
|
1756476a30
|
Copilot 等待期不再是黑箱，外加项目第一组测试
从点"生成"到第一个节点落到画布上，本机实测 31.7 秒（DeepSeek V4 pro，中等
复杂度需求）。这段时间界面上只有"正在起草…"五个字一动不动——用户没法判断
是在想还是已经卡死。生成质量本身没问题，瓶颈全在这段等待的体验。
三处改动：
## 思考转发
_iter_ops 原先只取正文、丢掉其余一切，模型的 thinking 块也一并丢了。现在用
thinking_text() 抽出来单独转成 thinking 事件，前端可折叠地实时显示。
刻意不用"把非 JSON 行当成思考"这种取巧写法：那会把模型的 markdown 注释、
协议跑偏时的乱输出一并当作思考展示出来，反而误导。不支持 thinking 的模型
就只有心跳，不硬凑假的思考。
注意这条只对支持 adaptive thinking 的模型（Claude 4.6+）生效，当前默认的
DeepSeek V4 pro 不会产出——代码路径用构造的 chunk 验证过，但端到端触发需要
启用 Anthropic provider。
## 心跳与阶段
模型沉默时每 3 秒补一拍，带阶段和已用时长。必须在 _with_heartbeat 这一层做：
模型不吐 chunk 时 _iter_ops 里那个 async for 的循环体根本不执行，在里面判断
时间差轮不到。阶段跟着实际操作走（planning → building → wiring → finalizing），
阶段会变本身就是"它还活着"的信号。实测那 31.7 秒里补了 10 拍。
## 失败后不用重敲需求
生成失败只有一个 ✕，重试得重新打开 Modal 把需求再敲一遍——而失败多半跟需求
本身无关（模型抽风、协议跑偏、网断了）。store 里留住 lastInstruction，
错误浮条上直接给"用同一需求重试"。
## 顺带：项目第一组测试
这组守的是体验契约不是实现细节——thinking 和 heartbeat 两路反馈只要断了就是
回归，而这种回归在界面上表现为"又变回干等"，很难被注意到。4 个用例覆盖：
thinking 块转发、纯文本模型不伪造思考、沉默期补心跳、阶段随进度推进。
pytest 走 [dev] extra，environment.yml 一并带上。
|
2026-09-14 16:01:06 +08:00 |
|
|
ThearchyHelios
|
4e901be0ec
|
改用 conda 管理后端环境，移除 uv
environment.yml 只负责把解释器和依赖装进具名环境 agentlab，依赖清单仍以
backend/pyproject.toml 为准，不在两处各写一遍。dev.sh 通过 conda run 解析出
真实解释器路径再启动 uvicorn，环境不存在时自动按 environment.yml 创建。
uv.lock 一并删掉：留着会和 conda 装出来的环境慢慢漂移，两套锁反而更难查问题。
|
2026-09-14 14:09:51 +08:00 |
|