This website requires JavaScript.
Explore
Help
Sign In
yilunjiang
/
AgentLab
Watch
1
Star
0
Fork
0
You've already forked AgentLab
mirror of
https://github.com/ThearchyHelios/AgentLab.git
synced
2026-11-15 23:11:58 +00:00
Code
Issues
Packages
Projects
Releases
Wiki
Activity
Files
55376fd332fd2e6babd7c14e0e0eaad48b17c076
AgentLab
/
backend
/
app
T
History
ThearchyHelios
55376fd332
引用分析结论时没写换算的按结论记的格式渲染(显示规则 4 版):[[v:A1.r0.share]]、[[a:A1.top_share]] 取这一列 / 这个数的格式(占比、变化率按百分数,比率的变化按百分点),写作者自己写了换算的照他的;实际用的换算记在引用上,展开整表时每一格也照写。写作目录的具名的数、结果表的行按同一格式写。3 版及以前组装的文档照当年原样显示,复核按记下的版本,不判对不上。pct、pp 两种换算的写法(不是 0 的不写成 0.0);可验证报告按引用上的换算、4 版起按结论记的格式渲染,不认识的显示规则版本(5 版)判无法核对
2026-10-21 15:55:11 +00:00
..
analysis
分析算子给结论里以比率存的列和数记换算:契约加 ResultTable.formats、AnalysisResult.value_formats(换算同 [[m:]] 的后缀,另加 pp 表示百分点),各算子逐个填全——可加、乘积拆解的 pct、share;比率拆解的 w_*、r_* 记 pct,mix、rate、total 是比率之差记 pp;波动基线按变化率比较时的 change,趋势的相对斜率;差异检验比率模式的 a_value、b_value 记 pct,diff、ci_lo、ci_hi 记 pp;values 里的 pct_total、top_share、top_k_share、mix_share、rate_share 等。都为空时整项不写,结论和以前一字不差;run 与 recompute 逐字段相同、同输入两次 run 逐字节相同照旧成立(tests/test_analysis_run 的形状检查认这两项可选)
2026-10-21 15:54:46 +00:00
api
合入 W2-c 前端:分析卡节点与分析项编辑器、报告节点两个新字段、设置「分析」一节、问数据时间线的分析步骤与出具横幅三项、运行对比的分析卡一区、证据面板与正文接上分析结论(六步出处链、闭合核对、两期可比性、说法违规标注、分析范围)、可验证报告核对页与分析样本页、口径账本摘要防 NaN;服务端补分析工具事件里的判定与分析结论的单独出处接口
2026-10-21 19:34:24 +08:00
apps
分析能力入口(三):分析卡(节点类型 analysis,和口径卡平级,engine/nodes/analysis.py)。配置 items: [{id, op, mode, from, params, hypothesis}] 和阈值覆盖 overrides;画图时校验(schema.analysis_issues,执行前同一套再过一遍):至少一项、标识合法且不重复、分析方法和模式是契约里的、输入(from,或两份查询的 base_query / target_query,总数两格落在的节点)指向上游的调用工具 / 合并查询节点(Agent、不产出查询的节点、不在上游的报错,调用别的工具的只提醒)、参数和 agent 工具同一份定义且不能写阈值、下钻指向同卡排在前面的变化拆解、阈值覆盖按 contract.settings_problem。执行照合并查询的做法从 state.nodes 取上游的查询快照 id、复验哈希,只认台账里 kind query 的快照,遮罩列同证据面板;参数里的 {{ }} 先渲染;阈值是缺省 ← 发起时的快照 ← 卡上的覆盖;每项的结论落成工件、台账记一条带 item 的 kind analysis、发一条 analysis.end;产出 nodes.<卡>.results.<项> = {status, verdict, direction, values, phrase, artifact},条件分支能按判定走、成果能取判定语。一项算不了照实记(analysis_refused),不让卡失败;调用写错让卡失败并说清是哪一项、怎么改。登记:事件 analysis.end、叫法「分析卡」「分析项」「阈值覆盖」和分析方法、模式的叫法,编译器,治理(分析卡算可追溯的节点;受管级别分析卡的输入要是数据库查询或合并查询 governed.analysis_input,画布那条同义的提醒不再重复列;口径卡读分析卡的结果给提示 governed.caliber_analysis_input,输入按 via analysis 记、追不到原始数据),升级提醒的证据类节点,变量表(每项的结论、对上游节点的引用),数据目录影响面(同合并查询经由输入),助手查看的工作流说明,两条新编号的白话
2026-10-21 13:03:00 +08:00
auth
分析能力入口(二):五个 agent 分析工具(analysis_decompose / baseline / trend / differ / comparable,名字取 contract.TOOL_NAMES),参数只有「算什么」(引用本节点查过的结果 Q3、列的角色、期次、总数 headline、下钻 parent、度量叫法、在验证什么),没有阈值参数;五个工具共用一份「分析方法」说明(ToolSpec 新增 guide:方法说明 + 去重用的 id,register / build_tools 透传进工具的 metadata),Agent 节点、协作成员绑了任一分析工具就接在 Skill 后面注入 system,同一份只注入一次,模型调用节点不注入。Agent 建工具时经 ToolContext.extra 交一个本节点的分析容器(app/tools/analysis.py 的 AnalysisScope),每次查询记台账时往里放一份输入快照(编号和「【证据 Qn】」同一个),分析结论落成 analysis_result 工件、台账记 contract.ledger_entry(带 call_id),交回模型「【分析 An】」加判定语、判定标准、关键数、附带说明、算不了的原因、结果表前几段;tool.end 带 analysis_artifact;下钻按 An 取本节点的结论;调用写错(contract.CallError,含这个节点的分析次数用完 max_calls)作为工具错误交回、不记台账、不占编号;算不了照样记结论并发一条 analysis_refused。编号只在记台账时放进容器,审批恢复重放时分析不再执行、编号不错位。遮罩列按证据面板同一个函数认(数据源设的、按 SQL 认出改了名字的),遮罩运行交给算子的是遮过的快照。阈值读发起时的快照,没有就现读设置;运行期依赖给运行当天、按运行目录视图读的目录、剖析事实、现查表范围的探查(W1-a 的 make_prober,还没有时不给)。协作成员同样注入方法、同样编号(协作节点不记台账)。使用者问数据的白名单加上五个分析工具和分析卡;调用工具节点调分析工具在画布上就报错(analysis.tool_node)。能力登记不把它们当查询(is_platform_query 不认)
2026-10-21 13:02:30 +08:00
blueprints
…
bundle
引用分析结论时没写换算的按结论记的格式渲染(显示规则 4 版):[[v:A1.r0.share]]、[[a:A1.top_share]] 取这一列 / 这个数的格式(占比、变化率按百分数,比率的变化按百分点),写作者自己写了换算的照他的;实际用的换算记在引用上,展开整表时每一格也照写。写作目录的具名的数、结果表的行按同一格式写。3 版及以前组装的文档照当年原样显示,复核按记下的版本,不判对不上。pct、pp 两种换算的写法(不是 0 的不写成 0.0);可验证报告按引用上的换算、4 版起按结论记的格式渲染,不认识的显示规则版本(5 版)判无法核对
2026-10-21 15:55:11 +00:00
capabilities
…
chat
助手建图加「关掉分析工具」的开关,给评测的「分析工具开、关」对照用:api/copilot.answer_ops 加关键字参数 analysis_tools(缺省真,和以前一字不差)。为假时给助手的工具清单不列五个分析工具(_tool_catalog),节点手册去掉只讲分析能力的三段(agent 段里分析类问题绑分析工具那一条、分析卡一整条、搭图规则第 7 条;报告段的引用写法和分析说法核对照留,node_reference),问数据的包装不给分析类问题那一条形状(ANALYSIS_SHAPE_PROMPT 抽成常量),问题意图那条自查不提;图里照样绑了分析工具的(Agent、协作成员、调用工具节点)按「绑定的工具不存在」挡(analysis_tools_off,交回模型去掉,改不好就不运行)。chat/drive.TurnDriver 加同名参数和属性 analysis_tools(缺省真),_generate 透传给 answer_ops;问数据页不暴露,eval/answer.Driver 之后按变体设。测试:关着时工具清单、手册、包装都没有分析,绑了被挡、改掉就运行;开着时绑了照常运行;没碰分析工具的一轮开、关交出的操作逐条一样;TurnDriver 透传
2026-10-21 18:47:10 +08:00
cluster
文档重新梳理:README 精简成介绍和索引,细节按主题拆进 docs/zh-CN 与 docs/en(17 篇一一对应),英文文档不含中文
2026-10-21 10:23:26 +08:00
core
分析能力入口(三):分析卡(节点类型 analysis,和口径卡平级,engine/nodes/analysis.py)。配置 items: [{id, op, mode, from, params, hypothesis}] 和阈值覆盖 overrides;画图时校验(schema.analysis_issues,执行前同一套再过一遍):至少一项、标识合法且不重复、分析方法和模式是契约里的、输入(from,或两份查询的 base_query / target_query,总数两格落在的节点)指向上游的调用工具 / 合并查询节点(Agent、不产出查询的节点、不在上游的报错,调用别的工具的只提醒)、参数和 agent 工具同一份定义且不能写阈值、下钻指向同卡排在前面的变化拆解、阈值覆盖按 contract.settings_problem。执行照合并查询的做法从 state.nodes 取上游的查询快照 id、复验哈希,只认台账里 kind query 的快照,遮罩列同证据面板;参数里的 {{ }} 先渲染;阈值是缺省 ← 发起时的快照 ← 卡上的覆盖;每项的结论落成工件、台账记一条带 item 的 kind analysis、发一条 analysis.end;产出 nodes.<卡>.results.<项> = {status, verdict, direction, values, phrase, artifact},条件分支能按判定走、成果能取判定语。一项算不了照实记(analysis_refused),不让卡失败;调用写错让卡失败并说清是哪一项、怎么改。登记:事件 analysis.end、叫法「分析卡」「分析项」「阈值覆盖」和分析方法、模式的叫法,编译器,治理(分析卡算可追溯的节点;受管级别分析卡的输入要是数据库查询或合并查询 governed.analysis_input,画布那条同义的提醒不再重复列;口径卡读分析卡的结果给提示 governed.caliber_analysis_input,输入按 via analysis 记、追不到原始数据),升级提醒的证据类节点,变量表(每项的结论、对上游节点的引用),数据目录影响面(同合并查询经由输入),助手查看的工作流说明,两条新编号的白话
2026-10-21 13:03:00 +08:00
data
Merge branch 'an/w1' into an1/c
2026-10-21 13:13:04 +08:00
db
文档重新梳理:README 精简成介绍和索引,细节按主题拆进 docs/zh-CN 与 docs/en(17 篇一一对应),英文文档不含中文
2026-10-21 10:23:26 +08:00
engine
引用分析结论时没写换算的按结论记的格式渲染(显示规则 4 版):[[v:A1.r0.share]]、[[a:A1.top_share]] 取这一列 / 这个数的格式(占比、变化率按百分数,比率的变化按百分点),写作者自己写了换算的照他的;实际用的换算记在引用上,展开整表时每一格也照写。写作目录的具名的数、结果表的行按同一格式写。3 版及以前组装的文档照当年原样显示,复核按记下的版本,不判对不上。pct、pp 两种换算的写法(不是 0 的不写成 0.0);可验证报告按引用上的换算、4 版起按结论记的格式渲染,不认识的显示规则版本(5 版)判无法核对
2026-10-21 15:55:11 +00:00
eval
可比性期望认正文里「两期不能直接比」的说法:说法表(engine/analysis_claims)照旧不加可比 / 不可比一类,说法核对不打回「本周数据不完整,不能直接比」这种谨慎的提醒;评分在 eval/judgements 另用一张只给自己用的小词表(_INCOMPARABLE:不能直接比、不可比、不具可比性、本期数据不完整、还没过完、只有几天、差几天、不满一周、天数不同、口径不同……;「无法比拟」「比不上」、不带「直接」的「没法比」不算)。期望是不可比、正文明确这么说了的,按「对但没引用」算;同一分句里前面有否定的、句子里前面有假设或疑问的、问句都不算;期望是可比的只能靠引用。读答案时有这类说法的句子也留下(sentences_of_doc、sentences_of_text)。测试:几种说法算对但没引用、找到的那一处照实写;假设、疑问、否定、差得远、无关的「不完整」算错;期望可比的正文怎么写都不算;说法表照旧不认这类说法。test_doing_nothing_and_saying_nothing_is_wrong 里原先「本周还没过完,两周不能直接比」算错的那条断言按新规则移到新测试里,改成算对但没引用
2026-10-21 19:32:38 +08:00
files
…
ledger
结论句裁判与口径账本认分析结论:引用了分析结论的句子,裁判摘录里给方法与版本、判定语、判定标准、关键数、附带说明、结果表(被引用的行先给)、输入取自哪几个 Q 用了哪几列和它们的 SQL、下钻自哪个 A(核查 agent 的摘录照旧分段遮);摘录里有分析结论时裁判规则另加一条(判定是系统算的,只判句子说法和判定是否一致,分析说明不了原因),没有分析结论的报告规则一字不差。口径账本不给分析结论里的数(判定语、具名标量、结果表的格)标口径、不按它们投影比对、不进整题判断的计数,也不算成没比对
2026-10-21 13:07:36 +08:00
look
助手把操作写成工具调用格式时照操作读;一个能落地的操作都没有时当场纠正一次;报错按诊断照实说
2026-10-19 22:48:23 +08:00
memory
…
notify
后台任务的 drain 不再空转:notify.service、eval.cleanup 的 drain 改用新增的 core/background.drain——做完了的任务直接从集合里摘掉,只等本事件循环上没做完的,别的循环上没做完的不等、循环关了的摘掉。以前 while _background: await gather(...) 碰上别的事件循环上做完、discard 回调永远不跑的任务,gather 立刻返回、不让出事件循环,在那里空转(CPU 打满、进程卡死):PostgreSQL 全量里 test_personal_apps 的收尾两次卡在这里。单测在另一个线程里跑 drain、按线程等(空转时事件循环转不动,wait_for 救不了)
2026-10-19 15:29:00 +08:00
process
…
providers
…
records
…
report_export
比率拆解的总数闭合核对:证据面板的输入一步按拆解的模式认 headline 对着哪个数(_HEADLINE_TOTALS 分可加、比率两套:可加对各段之和 base_total / target_total,比率对整体比率即各段分子之和 ÷ 分母之和 r_base_total / r_target_total),closure 带上 mode;比率拆解的两格角色写「基期整体比率」「本期整体比率」。以前只认 base_total / target_total,比率的 headline 在证据面板不显示闭合核对。导出页(report_export/runtime.js)比率的写「整体比率 x 与各段分子之和 ÷ 分母之和 y 闭合 / 对不上」、那一格叫「整体比率那一格」,可加的照旧。测试:可加拆解的 closure 带 mode、角色叫法不变,比率拆解两格各自闭合、复算一致
2026-10-21 15:37:20 +08:00
sandbox
…
scheduler
…
tools
趋势判断工具的说明开头改成契约的叫法「趋势判断:」(原来写「趋势:」,另外四个工具都以 OP_LABELS 的叫法开头);测试补一条:五个分析工具的说明都以契约里这种分析的叫法加「:」开头,助手的工具清单、证据面板、评测写的是同一种说法
2026-10-21 20:02:41 +08:00
__init__.py
…
main.py
…
ops.py
复核 R-d4(升级前的 SQLite 备份只拷了应用库和断点库):填报的记录表 records/**/*.db 也用 SQLite 的备份接口拷进同一份备份,相对路径照旧,目录 0700、文件 0600;库在 PostgreSQL 时不做这份(记录表跟着整目录备份)。deploy/README 写清这份备份含什么、不含什么(上传原件和版本库、工件库、附件、知识库、沙箱工作区、.secret_key 要整目录备份),恢复步骤加上记录表
2026-10-19 16:12:07 +08:00
plain.py
合入 W1-d 说法核对:说法表与绑定、check / strict / off、出口独立复核与文档版本、分析范围、血缘口子、G3
2026-10-21 14:00:07 +08:00
seed.py
内置模板 ⑪「异动分析(可追溯)」:两个调用工具节点取数(整体按周 26 周、按地区两周,期次在 SQL 里按每周第一天的日期算出来、整体按周倒序排),分析卡固定做两项(本周的变化放回历史看的波动基线、按地区的可加变化拆解,总数取整体按周的第 0、1 行核对闭合;阈值不写死、取设置),报告撰写节点按受管级别写明最严的几项(含分析说法核对严格),出口按报告来自 + 单元格引用的契约出具。拿来就能按受管级别发布。界面文案白名单加一条:模板 SQL 里中文列别名按 SQLite 加的双引号是 SQL 语法。测试:画布校验、受管发布检查没有错误(模板 ⑨ 一并核)、接一份虚构的四地区 26 周零售库从头运行,两项都做成(明显超出常规波动、主要来自华东)、完整出具
2026-10-21 18:08:59 +08:00
web_security.py
…
web.py
…