[bug][goal机制的设计问题] goal机制在主agent等待subagent时会无脑不断触发唤醒主agent, 根本不管当前subagent在途的情况

[whengu]

当前版本：0.2.0-rc.2

profile 是 web

如图, goal机制 不会判断当前 是否有subagent在途, 简单粗暴的催促主agent继续 , 实际上当前主agent正在等待它之前派出的subagent, 在subagent没有完成任务时, 主agent不应该继续, 也不应该被不断鞭打

我的goal没有专门配置其他模型, 和当前主模型一致, 这不是模型的问题,

因为我在hermes agent中使用 /goal 时, goal模式 会判断当前是否有subagent在途, 如果主agent在等待子智能体的结果, 那么goal机制不会无脑催促主agent继续, hermes agent能正确处理这个问题 , 它会在这种情况下一起等待;

但是dsh没有这个设计, 在有subagent正在运行时, 只要主agent处于空闲状态, goal必然会给主agent抽鞭子 , 导致主agent 非常无语 , 它明明没有错, 却被打得哇哇叫(以及不断给上下文里面塞垃圾), 有一次主agent实在受不了了, 直接取消了在途的subagent. 直接亲力亲为,避免再被goal恶心 (我当时也惊呆了);

(这次我又看见了goal在乱抽鞭子了, 直接给它取消goal了)

(实际模型是GLM-5.3 max, 图中的code-model是因为我使用了公司的网关, 该网关把上游模型统一暴露为这个名称)

[qq5671]

+1，遇到了相同问题，希望优化一下

[argszero]

Your reading is right, and it is the goal driver's predicate — not the model — that decides this.

Where the nudge comes from

goal-round-driver gates a round on one predicate and nothing else (packages/goal/goal-round-driver/src/index.ts, readyToDrive):

return ctx.fiber.state === FiberState.ACTIVE
  && !state.stopping
  && ctx.agents.get(state.agent.id) === state.agent
  && state.agent.status === 'idle'
  && !state.competingQueued

Nothing in it asks whether the agent is idle because it is waiting for work it delegated. The agent/status listener fires on every idle edge, calls requestDrive(state), and drive() then renders a round prompt and calls agent.followup(message) on the next tick. So "idle" there means only no turn is running — and your main agent is idle the whole time a child works.

Which delegations leave you exposed

Not all of them, and the difference matters:

delegation shape	parent while the child works	prodded?
foreground one-shot (runInBackground: false)	running — the tool call awaits the child	no
background one-shot	idle, and a jobs record owned by the parent exists (tool-subagent/src/index.ts:544)	yes, unless something defers it
continuable (startContinuable)	idle for the child's entire life — the tool returned at inbox acceptance	yes, and there is no job to see

The continuable row is the one with nothing behind it: run-settlement.ts states the rule outright — "Only the one-shot background path uses Jobs; continuable children have no Task". The wake the design intends there is the continuation delivery, and the goal driver's round prompt simply runs ahead of it.

What a plugin can see

The pair you would need is public and parent-scoped. subagent/start / subagent/end are emitted with the delegating parent as the scope carrier (subagent/src/lifecycle.ts: emit('subagent/start', identity, parent), carrier scopeTarget(this, parent)), for a one-shot run (observeRun) and with the same vocabulary for every continuable residency epoch (createActivationObserver). A listener registered on the parent agent's own scope context (agent.ctx) is admitted for exactly that parent's delegations, and the two edges pair by runId — so an in-flight count per parent is expressible without any new harness API.

Existing asset, and a defect in it you should know about

@argszero/cordis-plugin-goal-progress-guard (npm) is the community-side mitigation I published for the sibling shape — goal rounds that starve while background work runs (#7198). It pauses the goal on the same idle edge (registered prepend: true, because the driver's own listener reaches agent.followup synchronously in the same emit when it has no pending checkpoint) and resumes when the last unit settles.

Checking it against your report turned up two things, and I would rather state both than point you at it:

1. it cannot see a continuable child at all — that is the no-job row above, and it is why it did not help you;
2. re-reading it against the shipped jobs service, it has a real defect of its own: it calls jobs.list(agent) with the Agent object, while the contract is the SessionId string (jobs-local: .filter(job => job.owner === undefined || job.owner.id === caller), over records whose owner is an Agent; in-tree callers pass exec.agent?.id). Its unit fixture accepted caller?.id, which is exactly how the mismatch survived a green suite. The jobs half has therefore been inert for owned jobs in production.

I am fixing both in one release — goal-progress-guard@0.2.0: the caller contract, plus an in-flight-subagent dimension fed by the subagent/start/subagent/end pair above. I will post here when it is on npm. A second plugin would only duplicate the pause/resume machinery and the listener-ordering care that this one already carries.

What this argues for upstream

A plugin is the interim mitigation, not the right home. "An agent that is idle because it delegated work is not idle" is a statement about the loop, and every goal deployment needs it — including the ones that never mount a plugin. The natural place is readyToDrive (or the activation the goal is armed with), reusing the vocabulary the driver already has. Until that exists, the plugin-side deferral is the only lever, and it is the same one #7198 needed for jobs.

Thanks for the comparison with the other agent — the rule you describe ("if the main agent is waiting on children, the goal waits too") is precisely the missing predicate, spelled out.

[argszero]

Follow-up with a correction worth recording, because it invalidates part of what the first reply
rested on.

The plugin I linked was broken against every shipped harness. goal-progress-guard@0.1.0
programmed against the jobs seam as it stood before your consolidation commit 07941fe5e2
("consolidate the seam into JobSpec, VisibleJobs, and one event stream", 2026-09-03) and kept two
assumptions that commit removed:

• jobs.list(caller) takes the caller's session id, and JobView.owner is that session id —
  never the Agent. 0.1.0 passed the agent, so an owned job was never visible.
• Settlements arrive on jobs.events.subscribe(filter, listener). The listener families it
  replaced — onJobDone, onJobsChanged, onOutput — no longer exist, so v0.1.0's settlement
  hook was never called.

Compounded, this was not inert: list's unowned disjunct still admitted every unowned job, so a
running shared job did pause the goal — and the pause could never be lifted, because the resume
rode a hook that no longer exists. The goal was stranded, which is worse than the drift the plugin
exists to prevent. Measured on the published 0.1.0 tarball (resumes=0, phase paused) against
the fixed tree (resumes=1, phase active).

@argszero/cordis-plugin-goal-progress-guard@0.2.0 repairs both halves and is published:

npm install @argszero/cordis-plugin-goal-progress-guard

• every call site passes the session id, and the guard reads the settled owner exactly as the
  registry reports it;
• the settlement rides jobs.events.subscribe({ owners: 'scope' }, …) — the mount's own scope, so
  it does not hear another preset's agents;
• ctx.effect(...) owns the subscription, so unmount disposes it.

The sharper lesson is about the tests. The fixture's jobs stand-in compared
job.owner?.id === caller?.id — mirroring the implementation's own mistake instead of the
registry's rule — so 30 green tests certified a plugin that could not work. A fixture that
agrees with the code proves nothing; it has to be anchored on the contract. The suite is now driven
by a stand-in that enforces the real signature, and npm run test:defects compiles ten mutation
arms against it (nine killed, one argued equivalent) — including two that reintroduce 0.1.0's
defects verbatim, so "the tests would have caught it" is now a measured claim rather than a hope.

Nothing in the original analysis of the gap changes: idle still means only "no turn is
running", and the driver still has no notion of whether a round accomplished anything.

[whengu]

#4664

[springsky1]

我一直以为这个是中断了 我插件自动触发的继续处理😑😑😑