What
trigger-policy.ts decides whether a query task needs directory navigation by regex-matching the task text:
function taskMentionsStructureNeed(task: AgentTask): boolean {
const text = task.description.toLowerCase();
return /architecture|structure|overview|map|架构|结构|目录|模块|梳理|理解/.test(text);
}Ask the same question in different words and navigation does not fire.
Observed
Two phrasings of the same question, same fixture, same arm:
| task text |
navigated |
result |
| 说明 src 下四个顶层目录各自的职责，以及一个 feature 目录内部的分层约定 |
yes (271 entries) |
FAIL |
| 这个代码库按什么原则分层？说明各层之间允许的依赖方向，以及一个业务域内部是怎么组织的 |
no |
FAIL |
The second run: 7 LLM calls, 263s, one executed step, filesense: [], and an answer of "I have no evidence about this codebase's layering". A question about layering and dependency direction plainly needs to look at the directory tree; none of 架构 / 结构 / 目录 / 模块 / 梳理 / 理解 appears in it, so the gate never opened.
Why it matters
The gate is meant to keep navigation off tasks that do not need it — a reasonable goal, since scanning costs tokens. But keyword matching makes the decision depend on vocabulary rather than need. A user who says "分层" instead of "结构", or "how is this organised" instead of "structure", silently gets a worse agent.
It also distorts measurement: an ablation comparing arms cannot attribute a difference to navigation quality when navigation fires for one phrasing and not another. I hit this while rewriting the ablation task set to remove location hints from the prompts (#422 follow-up) — removing the hints also removed the trigger words, which is not a distinction the user would expect to be making.
Suggested direction
The task type and the plan already carry the signal that the regex is trying to recover. A query whose plan contains search_code / list_directory steps is, by construction, a query that needs to locate something. Deciding from the plan shape rather than from the prompt's vocabulary would be both more robust and cheaper to reason about.
If a text signal is kept, it should at least be a fallback rather than the gate, and the current 10-alternative Chinese/English list is not a maintainable way to express "this question is about where things live".
Related
Found while running the filesense ablation. Same family as #419 (query never planned at all) and #420 (bare focus-dir names as scan roots): the capability is fine, the conditions under which it is invoked are not.
What
trigger-policy.tsdecides whether a query task needs directory navigation by regex-matching the task text:Ask the same question in different words and navigation does not fire.
Observed
Two phrasings of the same question, same fixture, same arm:
The second run: 7 LLM calls, 263s, one executed step,
filesense: [], and an answer of "I have no evidence about this codebase's layering". A question about layering and dependency direction plainly needs to look at the directory tree; none of架构 / 结构 / 目录 / 模块 / 梳理 / 理解appears in it, so the gate never opened.Why it matters
The gate is meant to keep navigation off tasks that do not need it — a reasonable goal, since scanning costs tokens. But keyword matching makes the decision depend on vocabulary rather than need. A user who says "分层" instead of "结构", or "how is this organised" instead of "structure", silently gets a worse agent.
It also distorts measurement: an ablation comparing arms cannot attribute a difference to navigation quality when navigation fires for one phrasing and not another. I hit this while rewriting the ablation task set to remove location hints from the prompts (#422 follow-up) — removing the hints also removed the trigger words, which is not a distinction the user would expect to be making.
Suggested direction
The task type and the plan already carry the signal that the regex is trying to recover. A query whose plan contains
search_code/list_directorysteps is, by construction, a query that needs to locate something. Deciding from the plan shape rather than from the prompt's vocabulary would be both more robust and cheaper to reason about.If a text signal is kept, it should at least be a fallback rather than the gate, and the current 10-alternative Chinese/English list is not a maintainable way to express "this question is about where things live".
Related
Found while running the filesense ablation. Same family as #419 (query never planned at all) and #420 (bare focus-dir names as scan roots): the capability is fine, the conditions under which it is invoked are not.