长程任务很容易卡住，有人注意到了吗？尤其是自主规划的任务列表，任务时间长，执行轮次多后卡在那里不动，以为在执行，实际并没有输出

[DoACake]

如题。

[argszero]

Yes — and I'd separate "the loop is stuck" from "the loop is busy but shows nothing", because those have different owners and one of them is bounded by design while the other is not. The good news is that one artifact names the class, and it survives the freeze: the tail of the durable session log.

Everything below is read from dsh-v0.1.6-alpha.2 (ddefc45fbc).

What the harness actually bounds (and what it doesn't)

The model call is bounded — by silence, not by wall clock. Both shipped providers arm an idle watchdog per chunk, DEFAULT_STREAM_IDLE_TIMEOUT_MS = 300_000 (packages/llm/llm-deepseek/src/common/defaults.ts:4, packages/llm/llm-pi-ai/src/config.ts:46), armed on each wait and cleared when a chunk arrives (packages/util/timeout/src/index.ts:140-158). So a hang in the model call announces itself as an LlmError TIMEOUT after 5 minutes of no bytes; a long prefill is fine because bytes keep arriving.

That gives you a free discriminator: a session that stays frozen for tens of minutes without an error is almost certainly not the model call. It would already have failed loudly.

A tool call is bounded only if that tool opted in. ToolDefinition.timeoutMs (packages/core/tools/src/index.ts:249) is enforced by tool-call-timeout-policy, which is mounted in the base bundle (packages/bundle/base/cordis.patch.yml). Its own docstring states the limit of the mechanism: it arms a deadline on exec.signal and maps expiry to TOOL_TIMEOUT "without racing or abandoning the tool promise" (packages/guard/timeout-policy/src/index.ts). Concretely:

const timeoutMs = ctx.tools.get(exec.name, exec.agent)?.timeoutMs
if (timeoutMs === undefined) return next()   // no budget declared → no deadline

So there are two independent ways for a tool call to have no upper bound: it never declared a budget, or it declared one and ignores exec.signal (the enforcer still awaits the tool to completion, so a non-cooperative tool outlives its own timeout).

How common is the first case? Of the 39 source files calling defineTool(, 25 contain no timeoutMs anywhere:

for f in $(grep -rl "defineTool(" --include=*.ts packages/*/*/src/); do
  grep -q timeoutMs "$f" || echo "$f"; done

The complement is not exotic. It includes packages/subagent/tool-subagent/src/index.ts (delegation), packages/mcp/mcp-resources/src/tools.ts (third-party MCP tools), packages/terminal/tool-terminal/src/index.ts, tool-ask-user, fs read/write/edit, workflow/ralph, todo, plan-mode.

Two of the three places a long-horizon run spends its time therefore have no bound at all: delegating to a subagent, and calling a third-party MCP tool. For "long task, many rounds, then frozen", delegation is the one I would look at first, because it is the only one where the work is another agent in the same process:

• subagent's execute awaits settleForegroundRun (packages/subagent/tool-subagent/src/index.ts:208-237) — Promise.allSettled([run.result…]) and then await run.dispose(), with no deadline anywhere; the only signal it forwards is the caller's exec.signal, and since the tool declares no timeoutMs, nothing arms one.
• So if the child wedges, the parent waits forever and renders as running. That is the same shape as the already-reported unbounded disposal path (Bug: subagent-codex runs intermittently never settle - the child completes its turn and exits, but the dsh-side run hangs until a server restart #6226): a disposal/observation transaction with no deadline of its own.

The "autonomously planned task list" half

That part is capped, and the cap is worth knowing: rounds default to 256 (defaultMaxGoalRounds, packages/goal/goal/src/index.ts:244/:253), the round prompt carries Round: n/256 (goal-round-driver/src/prompt.ts:17), and the driver blocks with code: 'round-limit' at the cap (goal-round-driver/src/index.ts:166-171). Two honest caveats:

• the cap counts rounds, not cost — one round can be arbitrarily expensive, so "it ran all night" is not excluded by it;
• the model's own blocked action is gated: it requires a reason, and inside goal-round authority it requires at least blockedAfterConsecutiveRounds rounds to have started (default 3, packages/goal/tool-goal/src/index.ts:32, gate at :307) — so an unattended run that should stop on its own is a configuration question (round cap + block policy), not something a stall detector currently provides.

What to collect, and what each answer rules out

The log lives at session.jsonl / session.vN.jsonl, possibly .jsonl.zstd (packages/session/session-format/src/filename.ts:5-16). Read the last ~20 events:

last durable event	what is really running	what bounds it
tool/call with no matching tool/result	one tool call	only that tool's timeoutMs, if it declared one — else nothing
step/start/turn/start, no open tool call, no turn/end	the model call	the 5-minute idle watchdog, so a freeze longer than that contradicts this reading
turn/end present while the UI still says running	nothing	the log is the truth; treat it as a projection problem, not a hang
last turn has no turn/end at all and the process restarted	nothing	on resume the loop appends turn/end {reason: {kind: 'interrupted'}} — TurnEndReasonMap.interrupted is documented as "the loop never emits this marker live", and the client does render that status

Two cheap side observations sharpen it further: is the process CPU actually idle, and are tokens still being billed? "Spending while rendering nothing" (a loop that keeps taking steps) and "neither spending nor stepping" (one outstanding await) are different classes, and only the first is about loop construction.

Plugin-mountable surface (scanned, so it doesn't have to be re-scanned)

A stall itself is not plugin-mountable: a plugin cannot write a durable session event (Session.append carries only surfaceOp/sourceEventSeqs; there is no ignorable write path), so a watchdog could observe a stuck call but could not leave a durable record of why. What already exists in plugin form around this:

• @argszero/cordis-plugin-orphan-tool-call-guard — the durable shape "tool/call committed with no tool/result" is exactly what a wedge plus restart leaves behind, and every later turn then fails pairing validation (工具分发抛错后未补合成 tool/result，会话被永久毒死且无恢复路径 #7129).
• @argszero/cordis-plugin-thinking-loop-guard — for the "running, spending, rendering nothing" class, guarded mid-stream.
• @argszero/cordis-plugin-session-audit — offline reading/validation of the log above, which is how that tail gets inspected when the session won't load.

The gap this thread exposes is narrower and real: a deployment-level default deadline for the tools that declare none. The seam already exists and is public — tools/execute, the same one timeout-policy uses — so a plugin can arm a budget for exactly those tools without touching core. Its honest limit: the seam cannot race, so it upgrades a signal-honoring overrun into a structured error, and cannot unblock a tool that ignores its signal. Racing would unblock it, at the price of a still-running tool plus a committed result — i.e. it would manufacture the orphan shape the first plugin above exists to repair. Worth it only if the thing you are missing is the bound, not the abort.

[argszero]

A follow-up to the diagnosis above, because the first row of that table — tool/call with no matching tool/result, bounded "only by that tool's timeoutMs, if it declared one — else nothing" — turned out to be reachable from a plugin after all. It is published:

• npm: @argszero/cordis-plugin-tool-deadline-guard (0.1.0)
• source: https://github.com/argszero/cordis-plugin-tool-deadline-guard

Its whole scope is the set of tools that post identified as unbounded. Mounted on the same public tools/execute waterfall the core enforcer uses, it arms a budget for exactly the calls whose definition declares no timeoutMs (26 of the 40 non-test files calling defineTool( at dsh-v0.1.6-alpha.2 — the 25 you counted under packages/, plus apps/desktop-host/src/workspace-dependencies.ts), and leaves every other call untouched, so it never races the core policy over a budget that policy already owns.

npm install @argszero/cordis-plugin-tool-deadline-guard

- insert:
    - id: tool-deadline-guard
      name: '@argszero/cordis-plugin-tool-deadline-guard'
      # config:
      #   defaultTimeoutMs: 600000      # budget for a tool that declares none (10 minutes)
      #   perTool: { subagent: 900000 } # or per tool
      #   exempt: [ workflow ]          # never bound
      #   onExpiry: cooperative         # or `replace`; see below

An expiry becomes a model-visible, retryable tool result — isError: true with error.info.code === 'TOOL_DEADLINE_EXCEEDED', naming the tool and the budget — instead of an await that never returns:

tool_result [error] "tool call to "subagent" timed out: it exceeded the 600000ms
            deadline supplied by the tool-deadline-guard mount, and the tool
            declares no timeoutMs of its own"

The code is deliberately not the core policy's TOOL_TIMEOUT. A deployment can then tell "the tool declared a budget and blew it" (a tool bug) from "this mount supplied a budget the tool never declared" (a deployment policy), and anything routing on TOOL_TIMEOUT keeps meaning what it meant.

What it does not do

Worth stating as plainly as the earlier post stated the bound, because the interesting half of this gap is not solvable from any plugin:

• It does not race by default. timeoutMs is a cooperative contract: a tool that never looks at exec.signal cannot be unblocked from this seam, because a wrapper waits on the tool's promise and a promise that never settles keeps the wrapper waiting. In the default mode the expiry is converted after the call has settled, which preserves the invariant that a recorded tool/result corresponds to work that has stopped. Measured on a fixture that ignores its signal with a 60 ms budget: the call returned at 402 ms and only then did the wrapper report.
• onExpiry: 'replace' is the mode for the case the cooperative rule cannot reach — it returns the failure as soon as the timer fires and leaves the call running. It does not leave an orphan call in the log (the loop records a tool/result for the call it dispatched, packages/core/agent-loop/src/tool-calls.ts:282, so the transcript stays balanced and the next request is accepted), but a tool's side effects then land after the model was told it failed, so a retry can duplicate them.
• It writes nothing to the session log, for the reason the earlier post gave: a plugin has no ignorable write path. The diagnostic a plugin can produce durably is the tool result itself, which is what this does — so the "read the tail of the log" advice is unchanged, and the tail now contains a tool/result where it previously contained nothing.
• The core-side counterpart is still open. A deployment-level default budget in tool-call-timeout-policy itself would cover every tool without a second mount; this plugin is the version that needs no core change.

Evidence

• test/cordis.spec.mjs mounts a real Cordis context, a real ToolRuntime and a real tools/execute waterfall, with an unmounted control arm that reproduces the defect exactly as described here: with no plugin, a tool that declares no budget and never settles stays pending and nothing reports it.
• mutations.py edits the built artifact (never the source) and requires the suite to go red for each of 8 mutations — including "the caller signal is not restored for post-execute" and "an upstream abort is reported as this plugin's deadline" — so no claim can pass without a test holding it.
• The published tarball was installed by name into an empty directory and the same behaviour suite ran green against the installed copy (15/15), the only shape that catches a runtime import declared in the wrong section.
• Version compatibility was checked by unpacking the published tarballs of @deepseek-ai/dsh-tools for 0.1.2-rc.1, 0.1.3-alpha.2, 0.1.5-rc.2 and 0.1.6-alpha.2: tools/execute, ToolDispatchExecution, ToolDefinition.timeoutMs and ctx.tools.get(name, agent) are all present in each.