 ThearchyHelios
|
5641d0631f
|
循环变量不再被报成"未定义"：错的是分析器，不是模板
模板⑦「批量处理（循环）」是唯一一个装好就红着的内置模板——新用户点开第一眼
看到「1 个错误」，运行按钮还是灰的：
{{ vars.item }} 没有任何节点产出，是不是想写 {{ vars.items }}？
**但模板是对的。** 循环节点配的 item_var 就叫 item，control.py:142 每轮往
vars 里注入 vars.item 和 vars.item_index。错的是静态分析器：产出侧只登记了
input.*、vars.<assign_to>、nodes.<id>，从来没登记过循环注入的那两个。
kind="loop" 在 _KIND_ORDER 里一直占着位置，只是没人产出过——漏实现，
不是设计如此。
顺着修下来一共三处误报，都是同一类：
**一、循环变量没登记。** 补上 vars.<item_var> 和 vars.<item_var>_index，
只在 foreach 模式（while 不遍历列表，自然没有"当前项"）。
**二、顺序判定被回边搞乱。** 补上之后错误降成警告，但换了一句同样不对的话：
"{{ vars.item }} 由「逐条循环」产出，但那一步在这之后才跑"。循环体末尾有一条
回到循环节点的边，于是循环节点的拓扑深度被推高、反而排在自己的体后面。
改成先算出每个循环的"体"（从 body 出口走可达闭包，遇到循环节点自己就停），
体内引用不套先后判定。体**外面**引用它确实取不到值，那条留着，
并换成说得清的措辞："只在循环体内部有值"。
**三、表达式字段里的裸引用没扫。** transform 的 expression、branch 的
cases[].condition、skip_if 写的是裸 vars.x，没有 {{ }}，而扫描只认模板语法。
于是模板⑦里 `(vars.collected or '') + str(vars.one)` 一个引用都认不出来，
vars.one 被报成"产出了但没有任何地方引用"——它明明在用。
顺带把"没人用"这条收窄到**作者声明过的**变量：循环的 item_index 和入口字段的
vars.<name> 别名都是系统自动提供的，报它们等于噪音（内置变量没有 produced_by，
本来就不在这条路上）。而真正未引用的 assign_to 照报不误——⑤⑥⑧ 还各有一两条。
误报是 linter 最坏的失败模式：它会让人把整个校验一起无视掉。这条理由本来就
写在这个文件的注释里，只是自己没做到。
现在 8 个内置模板全部零错误。验证：后端 284 passed（test_variables.py 新增
8 条，含"体外引用仍然要警告"和"while 模式没有当前项"两条反向断言）；
三个前端 check 不回归。
|
2026-09-20 21:30:42 +08:00 |
|
|
ThearchyHelios
|
fa6a8a2ffe
|
问数据页：问题终于传进图里了，而且不再被误报卡住
两条日志（e3c2f743 / 61655cfe，相隔 30 秒）是同一件事的两半，指向三个问题。
**一、用户的问题根本没进图。** store/chat.ts 的 launch 里写死 `input: {}`。
Copilot 只要给入口声明了一个必填字段（它有时候会，比如 topic），这次运行就
在第一个节点上立刻挂掉："缺少必填输入：topic"——用户刚问完就看到报错，而且
错误里那个字段名他从来没见过，那是生成的图里的东西。e3c2f743 就是这么死的。
之前"能跑"纯属运气：那几次 Copilot 恰好没声明字段。
**二、把提问当成了流程描述。** 两个入口共用一句 "请设计一个工作流：<原话>"。
画布上这是对的（用户在描述流程），但在问数据页用户是在**提问**。于是
"shop 里都有哪些数据？"被设计成了一个"给这段文字生成摘要"的流程，跑完把
用户的问题原样复述一遍还回去（61655cfe 的成果就是这个）。加 intent 区分：
answer 意图下明说"流程是手段，用户要的是答案"，并把注入契约写死成
{{ input.question }}——不说死键名，模型会自己编一个（见过 input.text），
下游取到空字符串，而模板取不到值不报错。
**三、我上一个功能把整条对话路径卡住了。** 变量分析器把 `{{ input }}` 报成
"没有任何节点产出"——那是完全合法的写法（template_context 里 input 就是顶层
键），而 runs 启动前要过校验，一条假错误意味着什么都跑不了。这正是我自己在
上个 commit 里写的"误报是 linter 最坏的失败模式"，隔天就踩了。
修的时候连着踩了三步，每步都是测试当场抓的：
- 注册裸根之后，input.quesiton 回退到根被当成合法，拼写检查整个失效
- 收紧后 {{ vars.rows[0].name }} 被误报——那是在往值内部钻，结构枚举不了
- 再收紧后 {{ input.question }} 被误报——问数据页的入口**故意不声明字段**
最终规则：裸根合法；input/vars/nodes 只校验到第二段（再往下是值内部）；
**入口声明了字段才是闭集，没声明就是开放的**（运行时传什么键都行）；
根本不认识的根降成 warning——能穷举才配报 error，假错误比漏报贵得多。
端到端验证：问 "shop 里都有哪些数据？挑一个最大的表说说"，现在生成
input→tool→tool→llm→output（带 db_query__shop），input 带着问题，
真查出 backend_log 481,242 行 / 528.64 MB 并列出全部字段。
|
2026-09-18 13:52:43 +08:00 |
|
|
ThearchyHelios
|
4cc19730cb
|
变量的运行时取值如实落进事件，并修掉一处误报
两件事，都是实际跑了一遍才发现的。
**vars 的值原先不在任何落库事件里。** node.finished 的 preview 只取
updates["nodes"][node_id]，不含 updates["vars"]。界面上要做"变量当前值"
这一列，就只能从 preview 反推（data ?? text ?? 整个 output）——那个推断
大多数时候对，而一个"大多数时候对"的调试工具比没有更糟：它会在你最需要它
的那一次骗你。改成如实带上，只多一个已截断的值，且只有真赋了值的节点才有
（截断比 preview 更狠，要全文有工件库；事件是审计凭证，能省则省）。
**输入节点还会把每个字段同时写进 vars**（run_input 的返回里 input 和 vars
是同一份）。上一版的分析器不知道，于是 {{ vars.topic }} 这种完全合法的写法
被报成"未定义"。误报是 linter 最坏的失败模式——它会让人把整个校验一起
无视掉，那就比没有校验还糟。
现在实跑验证：
start | vars={"topic": "变量表"}
t | vars={"note": "主题是 变量表"}
out | vars=null （没赋值就不带这个字段）
校验：{{ vars.topic }} 干净，{{ vars.tpoic }} 报错并建议 {{ vars.topic }}。
|
2026-09-18 10:32:09 +08:00 |
|
|
ThearchyHelios
|
66b8969bc5
|
变量静态分析：把拼错一个变量名的静默失败说破
这套编排靠 {{ }} 串数据流，而模板取不到值时**渲染成空字符串**
（resolve_path 返回 None → _stringify → ""）。那是为了让半成品的图也能跑，
代价是：拼错一个变量名不报错、不警告、不留任何痕迹——下游拿到一段空文本，
然后模型基于空内容一本正经地编一段回答出来。这是这套东西最大的调试黑洞，
而界面上此前没有任何地方提过它。
app/engine/variables.py 做纯静态分析（不用跑图、不用有运行记录——用户在
编排到一半时最需要它，而那时候还没有任何一次运行可看）：
- 产出侧：input 字段、各节点的 assign_to、每个节点的 nodes.<id>
- 引用侧：递归扫所有配置字符串（output.fields[].value、code 的 files 都是
嵌套的，只扫顶层等于没扫），认得过滤器和下标
- 三类问题：
· 引用了没人产出的 —— 十有八九是拼错，用 difflib 给出"是不是想写…"
· 引用早于产出 —— 变量确实存在、名字也对，但那一步在这之后才跑，这里
取到的是空。这类最难查，因为表里查得到
· 产出了没人用 —— 只报 info，不拦着跑
前两类接进 validate_graph，画布上直接标红/标黄。另外开了
POST /api/workflows/variables 返回完整的变量表（谁产出、谁在哪个字段引用），
给接下来的变量表界面和输入补全用。
tests/test_variables.py 8 条，包括循环图不死循环（loop 的 body 连回自身很
常见）、节点读自己上一轮写的变量不该误报。
|
2026-09-18 10:08:45 +08:00 |
|