[BUG] Error: Client Cordis inspect Slots.listSubTree rejected input: "input" must be an object

[R1yanW1ang]

思考过程里出现这个bug，而且agent多轮loop后也无法解决。

[goatliamia]

这个问题我们这边刚好有一个现成的处理方式。

Slots.listSubTree rejected input: "input" must be an object 本身看起来还是 cordis_inspect_query 的参数/schema normalization 问题，这个根因应该在 tool contract 那一层修。

但你提到的：

agent 多轮 loop 后也无法解决

这一部分其实不需要等根因修复。

如果连续出现：

same tool path
+ same deterministic error
+ no relevant state change

Harness 已经知道这条 execution path 没有产生新的信息了，后面的：

retry
→ same error
→ reasoning
→ retry
→ same error

应该直接停掉，而不是继续交给模型自己判断。

我们最近做的 no-progress Circuit 就是处理这种情况的。

受控实验里：

failed attempts:      3.33 → 2.00
post-open attempts:   1.33 → 0
steps:                9.00 → 3.67

后来在开放任务里也碰到了不是预先设计出来的另一种循环：

tool denied
→ retry
→ tool denied
→ retry

一样可以被同一个机制截断。

所以我觉得你这个 case 可以明确分成两层：

Slots.listSubTree 参数为什么错
→ tool schema / argument normalization

为什么同一个确定性错误还能让 Agent loop 很多轮
→ no-progress Circuit

第二个问题我们现在已经有一个 DSH Plugin 实现，可以直接试：

https://github.com/goatliamia/dsh-runtime-capabilities

如果你这个 session 还方便复现，我很建议直接拿真实场景跑一下。

理想情况下应该是：

first failure
→ Agent 有机会修正参数

same failure + no progress again
→ Circuit opens
→ 后续同一路径不再继续消耗 Model turns

如果这个真实 case 没有被识别出来，或者你修改了参数以后 Circuit 反而误挡了，也可以直接在仓库开 Issue。

如果你愿意自己改 fingerprint / rule，PR 也欢迎；只提交脱敏 trajectory 或实验结果也可以，不一定需要改代码。

这个 case 很适合拿来验证 Circuit 在真实 Cordis 场景里的边界。